doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc5515.txt b/doc/rfc/rfc5515.txt
new file mode 100644
index 0000000..991ce84
--- /dev/null
+++ b/doc/rfc/rfc5515.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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]
+