GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5515

Network Working Group V. Mammoliti Request for Comments: 5515 C. Pignataro Category: Informational Cisco Systems

                                                             P. Arberg
                                                      Redback Networks
                                                            J. Gibbons
                                                      Juniper Networks
                                                             P. Howard
                                                              May 2009
     Layer 2 Tunneling Protocol (L2TP) Access Line Information
               Attribute Value Pair (AVP) Extensions

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 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 in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract

 This document describes a set of Layer 2 Tunneling Protocol (L2TP)
 Attribute Value Pair (AVP) extensions designed to carry the
 subscriber Access Line identification and characterization
 information that arrives at the Broadband Remote Access Server (BRAS)
 with L2TP Access Concentrator (LAC) functionality.  It also describes
 a mechanism to report connection speed changes, after the initial
 connection speeds are sent during session establishment.  The primary
 purpose of this document is to provide a reference for DSL equipment
 vendors wishing to interoperate with other vendors' products.  The
 L2TP AVPs defined in this document are applicable to both L2TPv2 and
 L2TPv3.

Mammoliti, et al. Informational [Page 1] RFC 5515 L2TP Access Line AVP Extensions May 2009

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

Mammoliti, et al. Informational [Page 2] RFC 5515 L2TP Access Line AVP Extensions May 2009

1. Introduction

 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:
 o  Vendor-Specific Point-to-Point Protocol over Ethernet (PPPoE) Tags
    [RFC2516].
 o  DHCP Relay Options [RFC3046] and Vendor-Specific Information
    Suboptions [RFC4243].
 o  Access Node Control Protocol [ANCP].
 Currently, this information is been collected on the BRAS and
 forwarded to a radius server via [RFC4679].
 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 [RFC2661] or L2TPv3 [RFC3931] 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.

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].

Mammoliti, et al. Informational [Page 3] RFC 5515 L2TP Access Line AVP Extensions May 2009

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.

Mammoliti, et al. Informational [Page 4] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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.  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
    [RFC3931].)
 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 [RFC2661] and [RFC3931].)

3. Access Line Information L2TP AVP Operation

 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.

Mammoliti, et al. Informational [Page 5] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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 4, 4.1, and
 4.2).
 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
 Section 4.1).  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 Section 6.2), 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.

4. Additional L2TP Messages

 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
 Section 4.1).  A new AVP, Connect Speed Update AVP (see Section 6.1),
 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

Mammoliti, et al. Informational [Page 6] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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:
 o  Dampens the rate of changes sent to the LNS when Access Line
    parameter updates are received at a high rate for a given line.
 o  Efficiently forwards speed updates when Access Line parameter
    updates are received for many lines at the same time.
 o  Supports failover [RFC4951] 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
 Section 4.2) 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 Section 4.1) 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 3
 and 6.2).
 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 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, to allow for
 an L2TP Control Connection Endpoint (LCCE) to maintain the control
 connection if the message type is unknown.

Mammoliti, et al. Informational [Page 7] RFC 5515 L2TP Access Line AVP Extensions May 2009

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

 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.

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

 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.

Mammoliti, et al. Informational [Page 8] RFC 5515 L2TP Access Line AVP Extensions May 2009

5. Access Line Information L2TP Attribute Value Pair Extensions

 The Access Line information was initially defined in the DSL Forum
 Technical Report TR-101 [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 [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
 that of 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 stipulated:
    Incoming-Call-Request (ICRQ)
 The Value of the AVP contains information about the Access Line to
 which the subscriber is attached.

Mammoliti, et al. Informational [Page 9] RFC 5515 L2TP Access Line AVP Extensions May 2009

 With the exception of the Connect Speed Update AVP (see Section 6.1),
 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 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 subsequent
 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
 have the following meanings:
 o  Actual      Actual rate or delay of an access loop
 o  Attainable  Maximum value that can be achieved by the equipment
 o  Minimum     Minimum value configured by the operator
 o  Maximum     Maximum value configured by the operator

5.1. Access Line Agent-Circuit-Id AVP

 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-

Mammoliti, et al. Informational [Page 10] RFC 5515 L2TP Access Line AVP Extensions May 2009

 Circuit-Id contains a locally administered string representing 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].
 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 [TR-101].
 Default syntax for the string is defined in [TR-101].  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 [TR-101].  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).

5.2. Access Line Agent-Remote-Id AVP

 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.

Mammoliti, et al. Informational [Page 11] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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 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-Remote-Id.
 The Agent-Remote-Id contains information sent from the Access Node/
 DSLAM from which the subscriber is attached, to further refine the
 access loop logical port identification with a user.  The content of
 this message is entirely open to the service provider's discretion.
 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 is encoded in the UTF-8 charset [RFC3629].

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

 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.

Mammoliti, et al. Informational [Page 12] RFC 5515 L2TP Access Line AVP Extensions May 2009

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

 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.

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

 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.

Mammoliti, et al. Informational [Page 13] RFC 5515 L2TP Access Line AVP Extensions May 2009

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

 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.

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

 The Access Line Attainable-Data-Rate-Upstream AVP, Attribute Type
 133, contains the subscriber's actual attainable 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Attainable-Data-Rate-Upstream
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ... in bps (64 bits)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Attainable-Data-Rate-Upstream AVP contains an 8-octet unsigned
 integer, indicating 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

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

Mammoliti, et al. Informational [Page 14] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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, indicating 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

 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.

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

 The Access Line Maximum-Data-Rate-Downstream AVP, Attribute Type 136,
 contains the subscriber's maximum downstream data rate, as configured
 by the operator.

Mammoliti, et al. Informational [Page 15] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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.

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

 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.

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

 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.

Mammoliti, et al. Informational [Page 16] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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.

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

 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 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-Interleaving-Delay-Upstream               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Maximum-Interleaving-Delay-Upstream AVP contains a 4-octet
 unsigned integer, indicating the numeric value in milliseconds of the
 subscriber's Access Line maximum one-way upstream interleaving delay.
 The Length (before hiding) of this AVP is 10.

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

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

Mammoliti, et al. Informational [Page 17] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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-Interleaving-Delay-Upstream                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Actual-Interleaving-Delay-Upstream AVP contains a 4-octet
 unsigned integer, indicating the numeric value in milliseconds of the
 subscriber's Access Line actual upstream interleaving delay.
 The Length (before hiding) of this AVP is 10.

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

 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 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-Interleaving-Delay-Downstream               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Maximum-Interleaving-Delay-Downstream AVP contains a 4-octet
 unsigned integer, indicating the numeric value in milliseconds of the
 subscriber's Access Line maximum one-way downstream interleaving
 delay.
 The Length (before hiding) of this AVP is 10.

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

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

Mammoliti, et al. Informational [Page 18] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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-Interleaving-Delay-Downstream               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Actual-Interleaving-Delay-Downstream AVP contains a 4-octet
 unsigned integer, indicating the numeric value in milliseconds of the
 subscriber's Access Line actual downstream interleaving delay.
 The Length (before hiding) of this AVP is 10.

5.17. Access Line Access-Loop-Encapsulation AVP

 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

Mammoliti, et al. Informational [Page 19] RFC 5515 L2TP Access Line AVP Extensions May 2009

    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

 The ANCP Access Line Type AVP, Attribute Type 145, describes the
 transmission systems on access loop to 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      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 used.

Mammoliti, et al. Informational [Page 20] RFC 5515 L2TP Access Line AVP Extensions May 2009

 The ANCP Access Line Type AVP contains a 1-octet field encoding the
 Transmission System, followed by a 3-octet reserved field (MUST be
 zero), and is 4 octets in length.  It indicates the transmission
 systems on access loop to the subscriber.  The current valid values
 only utilize the 1-octet field.
 Valid values are as follows:
    Transmission system:
       0x01 ADSL1
       0x02 ADSL2
       0x03 ADSL2+
       0x04 VDSL1
       0x05 VDSL2
       0x06 SDSL
       0x07 UNKNOWN

5.19. Access Line IWF-Session AVP

 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 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Inter-Working Function                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Inter-Working Function is a 4-octet value.
    Valid values for this field are as follows:
       0x00 IWF not performed
       0x01 IWF performed
 The Length (before hiding) of this AVP is 10.

Mammoliti, et al. Informational [Page 21] RFC 5515 L2TP Access Line AVP Extensions May 2009

6. Connect Speed Update L2TP Attribute Value Pair Extensions

 The following sections define Connect Speed Update related AVPs.
 These AVPs (Section 6.1 and Section 6.2) 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
 [RFC2661] and Section 5.2 of [RFC3931].

6.1. Connect Speed Update AVP (CSUN, CSURQ)

 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                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mammoliti, et al. Informational [Page 22] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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).

6.2. Connect Speed Update Enable AVP (ICRQ)

 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 Section 4.1) during the life of the
 session, and the LNS SHOULD query for the current connection speed
 via the CSURQ (see Section 4.2) during failover synchronization.
 Absence of this AVP indicates that the LAC will not be sending speed
 updates using CSUN (see Section 4.1) during the life of 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.

Mammoliti, et al. Informational [Page 23] RFC 5515 L2TP Access Line AVP Extensions May 2009

7. Access Line Information AVP Mapping

 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:
 o  Vendor-Specific PPPoE Tags [RFC2516].
 o  DHCP Relay Options [RFC3046] and Vendor-Specific Information
    Suboptions [RFC4243].
 o  ANCP [ANCP].

7.1. Summary of Access Line AVPs

 Table 1 summarizes 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

Mammoliti, et al. Informational [Page 24] RFC 5515 L2TP Access Line AVP Extensions May 2009

8. IANA Considerations

 Sections 8.1 and 8.2 describe request for new values in
 [IANA.l2tp-parameters], for registries already managed by IANA
 assignable through Expert Review according to [RFC3438].  Section 8.3
 describes number spaces not managed by IANA.

8.1. Message Type AVP Values

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

 This number space is managed by IANA as per [RFC3438].  There are two
 new AVPs, defined in Sections 6.1 and 6.2, 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 (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.

9. Security Considerations

 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.

Mammoliti, et al. Informational [Page 25] RFC 5515 L2TP Access Line AVP Extensions May 2009

 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 [RFC2661] and
 Section 8.l of [RFC3931].  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 [RFC2661] and Section 5.3
 of [RFC3931].
 The Attributes described in this document neither increase nor
 decrease the security of the L2TP protocol.
 It is possible to utilize [RFC3193] "Securing L2TP with IPsec" to
 increase the security by utilizing IPsec to provide 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 together this document.

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.

Mammoliti, et al. Informational [Page 26] RFC 5515 L2TP Access Line AVP Extensions May 2009

 [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.

Mammoliti, et al. Informational [Page 27] RFC 5515 L2TP Access Line AVP Extensions May 2009

Authors' Addresses

 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

Mammoliti, et al. Informational [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5515.txt · Last modified: 2009/05/05 19:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki