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

Access Nodes (ANs), referred to as Digital Subscriber Line Access Multiplexers (DSLAMs) in DSL, are adding enhancement features to forward, via in-band signaling, subscriber Access Line identification and characterization information to their connected upstream Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. The Access Node/DSLAM may forward the information via one or more of the following methods: Vendor-Specific Point-to-Point Protocol over Ethernet (PPPoE) Tags . DHCP Relay Options and Vendor-Specific Information Suboptions . Access Node Control Protocol . Currently, this information is been collected on the BRAS and forwarded to a radius server via . This document describes the new additional L2TP AVPs that were created to forward the subscriber line identification and characterization information received at the BRAS/LAC to the terminating L2TP Network Server (LNS). It also describes a mechanism by which the LAC may 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 or L2TPv3 implementation. The information acquired may be used to provide authentication, policy, and accounting functionality. It may also be collected and used for management and troubleshooting purposes.

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

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 .

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 and .) LCCE L2TP Control Connection Endpoint. An L2TP node that exists at either end of an L2TP control connection. May also be referred to as an LAC or LNS, depending on whether tunneled frames are processed at the data link (LAC) or network layer (LNS). (See .) LNS L2TP Network Server. If a given L2TP session is terminated at the L2TP node and the encapsulated network layer (L3) packet processed on a virtual interface, we refer to this L2TP node as an L2TP Network Server (LNS). (See and .)

When the BRAS with LAC functionality receives the Access Line information from the Access Node and has determined that the session will be established with an LNS, the LAC will forward the information that it has collected in the newly defined L2TP AVPs. The LAC will only forward the Access Line Information AVPs that have populated values. Access Line information from any of the above methods must be available at the BRAS prior to the start of session negotiation by the LAC. This ensures Access Line parameters are reliably provided to the LNS and avoids additional call set-up delays. Under the condition that the LAC has not received any Access Line information from any of the methods, as default behavior the LAC SHOULD establish the L2TP session without waiting for the Access Line information. In this case, the LAC MUST NOT send any of the Access Line AVPs to the LNS. The LAC MAY, as local policy, wait for the Access Line information from one or more of the methods before forwarding the information in the Access Line L2TP AVPs to the LNS. It is possible that the Access Node will only send a subset of the currently available line information defined. The LAC MUST be able to limit and/or filter which AVPs, if any, are sent to the LNS. It is also possible that the LAC may receive Access Line information from multiple sources and at different time intervals. Local policy SHOULD determine which source(s) the LAC will accept. The LAC SHOULD default to accepting ANCP-sourced parameters. The Access Line AVPs are sent as part of the L2TP Incoming-Call-Request (ICRQ) control message. Connect Speed Update AVPs are sent as part of the Connect-Speed-Update-Notification (CSUN) or Connect-Speed-Update-Request (CSURQ) L2TP messages (see Sections , , and ). It is possible for the LAC to send updated Connect Speed characteristics to the LNS via the Connect Speed Update AVP in an L2TP Connect-Speed-Update-Notification (CSUN) control message (see ). To avoid unnecessary L2TP Connect-Speed-Update-Request and Connect-Speed-Update-Notification message exchanges between the LAC and LNS (e.g., during failover protocol recovery and resynchronization), the LAC signals in the session establishment exchange its ability and desire to provide speed updates during the life of the session. This is achieved using a new AVP, Connect Speed Update Enable (see ), sent in the L2TP Incoming-Call-Request (ICRQ) control message. The absence of this AVP in the ICRQ message implies that the LAC will not be sending any speed updates during the life of the session. If the LAC is configured to accept ANCP-sourced parameters, and supports providing speed updates during the life of a session, it MUST send the Connect Speed Update Enable AVP in the ICRQ, since this implies that speed updates may occur over the life of the connection. If the LAC is configured to only accept PPPoE vendor-specific tags, it MUST NOT send the Connect Speed Update Enable AVP in the ICRQ, since the connection speed is only sent during PPPoE discovery and no further updates will occur during the life of the connection.

If the Access Line information changes while the session is still maintained, connection speed updates MAY be sent from the LAC to the LNS via an L2TP Connect-Speed-Update-Notification (CSUN) Message (see ). A new AVP, Connect Speed Update AVP (see ), is included in the CSUN message to report connect speed updates for a specific session after the initial connection speeds are established (i.e., 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 established in the Connect Speed Update AVP (as well as the values for the initial Tx/Rx Connect Speeds AVPs) are based on LAC local policy. For example, the LAC's local policy may use the Actual-Data-Rate-Upstream and Actual-Data-Rate-Downstream as its policy to report connection speed updates. For consistency, the same local policy SHOULD equally apply both to the initial connect speeds (conveyed during session establishment) and to the (optional) connect speed updates (sent after the establishment of the session). The CSUN message MAY be sent periodically to the LNS based on local policy and may include more than one Connect Speed Update AVP. The bulking of more than one Connect Speed Update AVP into the CSUN message serves the following purposes: Dampens the rate of changes sent to the LNS when Access Line parameter updates are received at a high rate for a given line. Efficiently forwards speed updates when Access Line parameter updates are received for many lines at the same time. Supports failover protocol recovery and resynchronization. During failover recovery and resynchronization, to ensure the correct speeds have been applied to outstanding sessions on each tunnel, the LNS MAY issue a Connect-Speed-Update-Request (CSURQ) message (see ) to the LAC containing one or more Session IDs. In response to the CSURQ message, the LAC MUST issue a Connect-Speed-Update-Notification (CSUN) message (see ) containing 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 and ). This section defines two new Messages that are used with the IETF Vendor ID of 0 in the Message Type AVP. The following message types will be assigned to these new messages (see ): 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, to allow for an L2TP Control Connection Endpoint (LCCE) to maintain the control connection if the message type is unknown.

The Connect-Speed-Update-Notification (CSUN) is an L2TP control message sent by the LAC to the LNS to provide transmit and receive connection speed updates for one or more sessions. The connection speed may change at any time during the life of the call; thus, 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.

The Connect-Speed-Update-Request (CSURQ) is an L2TP control message sent by the LNS 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 MUST only be issued for each outstanding session on each tunnel on which the LNS has already received a Connect Speed Update Enable AVP in the prior Incoming-Call-Request (ICRQ) control message for the session. It is typically used as part of failover recovery and resynchronization to allow the LNS to verify 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.

The Access Line information was initially defined in the DSL Forum Technical Report TR-101 . TR-101 defines the line characteristic that are sent from an Access Node. The following sections contain a list of the Access Line Information L2TP AVPs. Included with each of the listed AVPs is a short description of the purpose of the AVPs.

The AVPs follow the standard method of encoding AVPs as follows: 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 to allow for backwards compatibility with LNSs that do not support the Access Line Information AVP extensions hereby defined. However, if it is desired to prevent the establishment of the L2TP session if the peer LNS does not support the Access Line Information AVP extensions, the M bit MAY be set to 1. See Section 4.2 of and Section 5.2 of . 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 through ) is that of the IANA assigned ADSL Forum Vendor ID, decimal 3561 . All the listed AVPs ( through ) MAY be present in the following messages unless otherwise stipulated: Incoming-Call-Request (ICRQ) The Value of the AVP contains information about the Access Line to which the subscriber is attached. With the exception of the Connect Speed Update AVP (see ), all new AVPs specifying a data rate or speed expressed in bits per second (bps) will be sent as 64-bits to provide extensibility to support future increases in subscriber connection speeds. These new AVPs that specify a 64-bit "Data-Rate" are defined from to , 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 subsequent Sections through are defined in Section 3.9.4 of . The qualifiers used with these Data-Rates and Interleaving-Delays have the following meanings: Actual rate or delay of an access loop Maximum value that can be achieved by the equipment Minimum value configured by the operator Maximum value configured by the operator

The Access Line Agent-Circuit-Id AVP, Attribute Type 1, contains information describing the subscriber agent circuit ID corresponding to the logical access loop port of the Access Node/DSLAM from which a subscriber's requests are initiated.

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 is of arbitrary length, but MUST be greater than 1 octet and not greater than 63 octets. The Length (before hiding) of this AVP is 6 plus the length of the Agent-Circuit-Id. The Agent-Circuit-Id contains information about the Access Node/DSLAM to which the subscriber is attached, along with a unique identifier for the subscriber's DSL port on that Access Node/DSLAM. The Agent-Circuit-Id contains a locally administered string representing the access loop logical port, and its syntax is defined in Section 3.9.3 of . The text string is encoded in the UTF-8 charset . An exemplary description of the Agent-Circuit-Id string format follows for background purposes. The LAC MUST treat the string as an opaque value and MUST NOT manipulate or enforce the format of the string based on the description here or in TR-101 . Default syntax for the string is defined in . The examples in this section are included only for illustrative purposes. The exact syntax of the string is implementation dependent; however, a typical practice is to subdivide it into two or more space-separated components, one to identify the Access Node and another the subscriber line on that node, with perhaps an indication of whether that line is Ethernet or ATM. Example formats for this string are shown 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 . An example showing the slot and port field encoding is given below: "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 syntax of the slot and port fields reflects typical practices currently 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 a delimiter. The exact manner in which slots are identified is Access Node/DSLAM implementation dependent. The vpi, vci, and vlan-id fields (when applicable) are related to a given access loop (U-interface).

The Access Line Agent-Remote-Id AVP, Attribute Type 2, contains an operator-specific, statically configured string that uniquely identifies the subscriber on the associated access loop of the Access Node/DSLAM.

The Access Line Actual-Data-Rate-Upstream AVP, Attribute Type 129, contains 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 contains an 8-octet unsigned integer, indicating the subscriber's actual data rate upstream of a synchronized Access link. The rate is coded in bits per second. The Length (before hiding) of this AVP is 14.

The Access Line Actual-Data-Rate-Downstream AVP, Attribute Type 130, 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, indicating the subscriber's actual data rate downstream of a synchronized Access link. The rate is coded in bits per second. The Length (before hiding) of this AVP is 14.

The Access Line Minimum-Data-Rate-Upstream AVP, Attribute Type 131, contains 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, indicating 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.

The Access Line Minimum-Data-Rate-Downstream AVP, Attribute Type 132, contains the subscriber's operator-configured minimum 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Data-Rate-Downstream +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... in bps (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Minimum-Data-Rate-Downstream AVP contains an 8-octet unsigned integer, indicating 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.

The Access Line Attainable-Data-Rate-Upstream AVP, Attribute Type 133, contains the subscriber's actual attainable upstream data rate.

The Access Line Attainable-Data-Rate-Downstream AVP, Attribute Type 134, contains the subscriber's actual attainable downstream data rate.

The Access Line Maximum-Data-Rate-Upstream AVP, Attribute Type 135, contains 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, indicating 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.

The Access Line Maximum-Data-Rate-Downstream AVP, Attribute Type 136, contains the subscriber's maximum downstream 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-Downstream +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... in bps (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Maximum-Data-Rate-Downstream AVP contains an 8-octet unsigned integer, indicating the numeric value of the subscriber's Access Line maximum downstream data rate. The rate is coded in bits per second. The Length (before hiding) of this AVP is 14.

The Access Line Minimum-Data-Rate-Upstream-Low-Power AVP, Attribute Type 137, contains the subscriber's minimum upstream data rate in low power state, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Data-Rate-Upstream-Low-Power +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... in bps (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Minimum-Data-Rate-Upstream-Low-Power AVP contains an 8-octet unsigned integer, indicating the numeric value of the subscriber's Access Line minimum upstream data rate when in low power state (L1/L2). The rate is coded in bits per second. The Length (before hiding) of this AVP is 14.

The Access Line Minimum-Data-Rate-Downstream-Low-Power AVP, Attribute Type 138, contains the subscriber's minimum downstream data rate in low power state, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Data-Rate-Downstream-Low-Power +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... in bps (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Minimum-Data-Rate-Downstream-Low-Power AVP contains an 8-octet unsigned integer, indicating the numeric value of the subscriber's Access Line minimum downstream data rate when in low power state (L1/L2). The rate is coded in bits per second. The Length (before hiding) of this AVP is 14.

The Access Line Maximum-Interleaving-Delay-Upstream AVP, Attribute Type 139, contains the subscriber's maximum one-way upstream interleaving delay, as configured by the operator.

The Access Line Actual-Interleaving-Delay-Upstream AVP, Attribute Type 140, contains the subscriber's actual one-way upstream interleaving delay.

The Access Line Maximum-Interleaving-Delay-Downstream AVP, Attribute Type 141, contains the subscriber's maximum one-way downstream interleaving delay, as configured by the operator.

The Access Line Actual-Interleaving-Delay-Downstream AVP, Attribute Type 142, contains the subscriber's actual one-way downstream interleaving delay.

The Access Line Access-Loop-Encapsulation AVP, Attribute Type 144, describes the encapsulation(s) used by the subscriber on the access loop. The Length (before hiding) of this AVP is 9. The Access-Loop-Encapsulation value is comprised of three 1-octet values representing the Data Link, Encapsulation 1, and Encapsulation 2, respectively. The Access-Loop-Encapsulation value is 3 octets in length, logically divided into three 1-octet sub-fields, each containing its own enumeration value, as shown in the following diagram:

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valid values for the sub-fields are as follows: 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

The ANCP Access Line Type AVP, Attribute Type 145, describes the transmission systems on access loop to the subscriber.

The Access Line IWF-Session AVP, Attribute Type 254, indicates if an Interworking Function has been performed with respect to the subscriber's session.

The following sections define Connect Speed Update related AVPs. These AVPs ( and ) use the IETF Vendor ID of 0. The M bit for these AVPs SHOULD be set to 0. However, if it is desired to prevent the establishment or tear down the established L2TP session if the peer LNS does not support the Connect Speed Update AVP extensions, the M bit MAY be set to 1. See Section 4.2 of and Section 5.2 of .

The Connect Speed Update AVP, Attribute Type 97, contains the updated connection speeds for this session. The format is consistent with that of the Tx Connect Speed and Rx Connect Speed AVPs for L2TPv2 (Attribute Types 24 and 38, respectively) and L2TPv3 (Attribute Types 74 and 75, respectively). Hence, there is a separate format defined for L2TPv2 and L2TPv3.

The Attribute Value field for this AVP has the following format for L2TPv2 Tunnels: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Attribute Value field for this AVP has the following format for L2TPv3 Tunnels: 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 (i.e., the identifier that was assigned to this session by the peer). The Current Tx Connect Speed is a 4-octet value (L2TPv2) or an 8-octet value (L2TPv3) representing the current transmit connect speed, from the perspective of the LAC (e.g., data flowing from the LAC to the remote system). The rate is encoded in bits per second. The Current Rx Connect Speed is a 4-octet value (L2TPv2) or an 8-octet value (L2TPv3) representing the current receive connect speed, from the perspective of the LAC (e.g., data flowing from the remote system to the LAC). The rate is encoded in bits per second. The Length (before hiding) of this AVP is 18 (L2TPv2) or 26 (L2TPv3).

The Connect Speed Update Enable AVP, Attribute Type 98, indicates whether the LAC intends to send speed updates to the LNS during the life of the session. The Connect Speed Update Enable AVP is a boolean AVP. Presence of this AVP indicates that the LAC MAY send speed updates using CSUN (see ) during the life of the session, and the LNS SHOULD query for the current connection speed via the CSURQ (see ) during failover synchronization. Absence of this AVP indicates that the LAC will not be sending speed updates using CSUN (see ) during the life of the session, and the LNS MUST NOT query for the current connection speed via the CSURQ (see ) during failover synchronization. The Length (before hiding) of this AVP is 6.

The Access Line information that is obtained from the Access Node/DSLAM is required to be mapped into the Access Line AVPs. The Access Line information can be obtained via: Vendor-Specific PPPoE Tags . DHCP Relay Options and Vendor-Specific Information Suboptions . ANCP .

summarizes the Access Line AVPs defined in Sections through . 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

Sections and describe request for new values in , for registries already managed by IANA assignable through Expert Review according to . describes number spaces not managed by IANA.

This number space is managed by IANA as per . There are two new message types, defined in Sections and , 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

This number space is managed by IANA as per . There are two new AVPs, defined in Sections and , to be allocated for this specification. Control Message Attribute Value Pairs (AVPs) 97: Connect Speed Update AVP 98: Connect Speed Update Enable AVP

The Access Line Information AVPs use the Vendor ID of 3561 for the ADSL Forum (now Broadband Forum). The number spaces in these Values and their new allocations (e.g., enumerated values for the Access Line Access-Loop-Encapsulation AVP and ANCP Access Line Type AVP) are managed by the Broadband Forum.

The security of these AVP relies on an implied trust relationship between the Access Node/DSLAM and the BRAS/LAC, and between the LAC and the LNS. The identifiers that are inserted by the Access Node/DSLAM are unconditionally trusted; the BRAS does not perform any validity check on the information received before forwarding the information. These AVPs are intended to be used in environments in which the network infrastructure (the Access Node/DSLAM, the BRAS/LAC, the LNS, and the entire network in which those devices reside) is trusted and secure. Careful consideration should be given to the potential security vulnerabilities that are present in this model before deploying this option in actual networks. The AVPs described in this document are used to carry identification and characterization of subscriber Access Line, and to report connection speed changes. If used in a non-secure environment, they could reveal such information. The Tunnel (Control Connection) security considerations are covered in Section 9.1 of and Section 8.l of . Additionally, the hiding of AVP attribute values mechanism can be used to hide the value of the AVPs described in this document, if they are deemed sensitive in some environments. AVP hiding is described in Section 4.3 of and Section 5.3 of . The Attributes described in this document neither increase nor decrease the security of the L2TP protocol. It is possible to utilize "Securing L2TP with IPsec" to increase the security by utilizing IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection.

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 together this document.