Internet Engineering Task Force                             V. Mammoliti
Internet-Draft                                              C. Pignataro
Intended status: Informational                             Cisco Systems
Expires: May 20, 2008                                          P. Arberg
                                                        Redback Networks
                                                              J. Gibbons
                                                        Juniper Networks
                                                               P. Howard
                                                       November 17, 2007


  Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute
                      Value Pair (AVP) Extensions
                 draft-mammoliti-l2tp-accessline-avp-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 20, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a set of Layer 2 Tunneling Protocol (L2TP)
   Attribute Value Pair (AVP) extensions designed to carry the Access



Mammoliti, et al.         Expires May 20, 2008                  [Page 1]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   Line information which is not currently available by the existing
   L2TP AVP set.  It is expected that this document will be updated if
   and when new line information is available, since its primary purpose
   is to provide a reference for DSL equipment vendors wishing to
   interoperate with other vendors' products.














































Mammoliti, et al.         Expires May 20, 2008                  [Page 2]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
     2.2.  Technical Terms and Acronyms . . . . . . . . . . . . . . .  6

   3.  Access Line Information L2TP AVP Operation . . . . . . . . . .  6

   4.  Additional L2TP Messages . . . . . . . . . . . . . . . . . . .  8
     4.1.  Connect-Speed-Update-Notification (CSUN) . . . . . . . . .  9
     4.2.  Connect-Speed-Update-Request (CSURQ) . . . . . . . . . . .  9

   5.  Access Line Information L2TP Attribute Value Pair
       Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Access Line Agent-Circuit-Id AVP . . . . . . . . . . . . . 11
     5.2.  Access Line Agent-Remote-Id AVP  . . . . . . . . . . . . . 12
     5.3.  Access Line Actual-Data-Rate-Upstream AVP  . . . . . . . . 13
     5.4.  Access Line Actual-Data-Rate-Downstream AVP  . . . . . . . 13
     5.5.  Access Line Minimum-Data-Rate-Upstream AVP . . . . . . . . 14
     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  . . . . . 15
     5.9.  Access Line Maximum-Data-Rate-Upstream AVP . . . . . . . . 15
     5.10. Access Line Maximum-Data-Rate-Downstream AVP . . . . . . . 16
     5.11. Access Line Minimum-Data-Rate-Upstream-Low-Power AVP . . . 16
     5.12. Access Line Minimum-Data-Rate-Downstream-Low-Power AVP . . 17
     5.13. Access Line Maximum-Interleaving-Delay-Upstream AVP  . . . 17
     5.14. Access Line Actual-Interleaving-Delay-Upstream AVP . . . . 18
     5.15. Access Line Maximum-Interleaving-Delay-Downstream AVP  . . 18
     5.16. Access Line Actual-Interleaving-Delay-Downstream AVP . . . 19
     5.17. Access Line Access-Loop-Encapsulation AVP  . . . . . . . . 19
     5.18. ANCP Access Line Type AVP  . . . . . . . . . . . . . . . . 21
     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

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25



Mammoliti, et al.         Expires May 20, 2008                  [Page 3]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     11.2. Informative References . . . . . . . . . . . . . . . . . . 26

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 29











































Mammoliti, et al.         Expires May 20, 2008                  [Page 4]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


1.  Introduction

   Access Nodes/Digital Subscriber Line Access Multiplexers (DSLAM) are
   adding enhancement features to forward, via in-band signaling,
   subscribers Access Line identification and characterization
   information to their connected upstream Broadband Remote Access
   Server (BRAS) with LAC functionality.

   The Access Node/DSLAM may forward the information via one or more of
   the following methods:

   o  Vendor-Specific PPPoE Tags [RFC2516].

   o  DHCP Relay Options [RFC3046] and Vendor-Specific Information
      Suboptions [RFC4243].

   o  ANCP [I-D.ietf-ancp-protocol].

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

   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.

   Discussion of this draft may be directed to the authors.


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.         Expires May 20, 2008                  [Page 5]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


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 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 PPPoA
      traffic over PPPoE.


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



Mammoliti, et al.         Expires May 20, 2008                  [Page 6]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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 MUST establish
   the L2TP session without waiting for the Access Line Information.  In
   this case, the LAC SHOULD not send any of the Access Line AVPs to the
   LNS.  The LAC MAY, as local policy, wait for the Access Line
   information from one or more of the methods before forwarding the
   information in the Access Line L2TP AVPs to the LNS.

   It is possible that the Access Node will only send a subset of the
   currently available line information defined.  The LAC MUST be able
   to limit and/or filter which AVPs, if any, are sent to the LNS.

   It is also possible that the LAC may receive Access Line information
   from multiple sources and at different time intervals.  Local policy
   SHOULD determine which source(s) the LAC will accept.  The LAC SHOULD
   default to accepting ANCP sourced parameters.

   The Access Line AVPs are sent as part of the L2TP Incoming-Call-
   Request (ICRQ) control message.  Connect Speed Update AVPs MAY be
   sent as part of the L2TP Connect-Speed-Update-Notification (CSUN)
   message (see Section 4).

   It is also possible to send updated Connect Speed characteristics
   from the LAC to the LNS via the L2TP Connect-Speed-Update-
   Notification (CSUN) control message (see Section 4.1) if the Access
   line information changes and the session is still maintained.  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 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,
   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-



Mammoliti, et al.         Expires May 20, 2008                  [Page 7]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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 a connect speed update for
   a specific 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  Dampen 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 forward speed updates when Access Line parameter
      updates are received for many lines at the same time.

   o  Address 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: The LAC SHOULD only respond to a known Session ID for
   which it issued a Connect Speed Update Enable AVP in the prior
   Incoming-Call-Request (ICRQ) control message for the session (see
   Section 3 and Section 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):







Mammoliti, et al.         Expires May 20, 2008                  [Page 8]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


      MSG-TBD1:  (CSUN) Connect-Speed-Update-Notification

      MSG-TBD2:  (CSURQ) Connect-Speed-Update-Request

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 update for one or more sessions.  The connection
   speed MAY change at any time during the life of the call, thus the
   LNS MUST 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 re-synchronization 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 only respond to known
   sessions in which it issued a Connect Speed Update Enable AVP in the
   prior Incoming-Call-Request (ICRQ) control message for each of those



Mammoliti, et al.         Expires May 20, 2008                  [Page 9]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   sessions.


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 LNS 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 AVP (Section 5.1 through
   Section 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)




Mammoliti, et al.         Expires May 20, 2008                 [Page 10]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   The Value of the AVP contains information about the Access line to
   which the subscriber is attached.

   With exception of the Connect Speed Update AVP (see section
   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.

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 ... (two to sixty three 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 an identifier for the
   subscriber's DSL port on that Access-Node/DSLAM.  The text string is
   encoded in the UTF-8 charset [RFC3629].

   Default syntax for the string is defined in [TR-101].  The exact
   syntax of the string is implementation dependant; 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)



Mammoliti, et al.         Expires May 20, 2008                 [Page 11]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


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

   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 which 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 which uniquely
   identifies the subscriber on the associated access loop of the Access
   Node/DSLAM.

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

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Agent-Remote-Id ... (two to sixty three 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.  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 text string is encoded in the UTF-8 charset [RFC3629].







Mammoliti, et al.         Expires May 20, 2008                 [Page 12]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


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 a 4-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.

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.






Mammoliti, et al.         Expires May 20, 2008                 [Page 13]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


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.

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.



Mammoliti, et al.         Expires May 20, 2008                 [Page 14]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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.

   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.







Mammoliti, et al.         Expires May 20, 2008                 [Page 15]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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.

   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.








Mammoliti, et al.         Expires May 20, 2008                 [Page 16]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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.

   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.






Mammoliti, et al.         Expires May 20, 2008                 [Page 17]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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.

   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.












Mammoliti, et al.         Expires May 20, 2008                 [Page 18]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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.

   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



Mammoliti, et al.         Expires May 20, 2008                 [Page 19]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   divided into three 1-octet sub-fields, each containing its own
   enumeration value, as shown in the following diagram:


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

   Valid values for the sub-fields are as follows:

      Data Link

         0x00 ATM AAL5

         0x01 Ethernet

      Encaps 1

         0x00 NA - Not Available

         0x01 Untagged Ethernet

         0x02 Single-Tagged Ethernet

      Encaps 2

         0x00 NA - Not Available

         0x01 PPPoA LLC

         0x02 PPPoA Null

         0x03 IPoA LLC

         0x04 IPoA Null

         0x05 Ethernet over AAL5 LLC with FCS

         0x06 Ethernet over AAL5 LLC without FCS

         0x07 Ethernet over AAL5 Null with FCS

         0x08 Ethernet over AAL5 Null without FCS






Mammoliti, et al.         Expires May 20, 2008                 [Page 20]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


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.

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






Mammoliti, et al.         Expires May 20, 2008                 [Page 21]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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.


6.  Connect Speed Update L2TP Attribute Value Pair Extensions

6.1.  Connect Speed Update AVP (CSUN, CSURQ)

   The Connect Speed Update AVP, Attribute Type AVP-TBD1, 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.         Expires May 20, 2008                 [Page 22]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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 AVP-TBD2,
   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.         Expires May 20, 2008                 [Page 23]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


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 [I-D.ietf-ancp-protocol].

7.1.  Summary of Access Line AVPs

   Table 1 summarizes the Access Line AVPs defined in Section 5.1
   through Section 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.         Expires May 20, 2008                 [Page 24]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


8.  IANA Considerations

   The following two subsections describe request for new values in
   [IANA.l2tp-parameters], for registries already managed by IANA
   assignable through Expert Review according to [RFC3438].

8.1.  Message Type AVP Values

   This number space is managed by IANA as per [RFC3438].  There are two
   new message types, defined in Section 4.1 and Section 4.2, to be
   allocated for this specification.

      Message Type AVP (Attribute Type 0) Values

      MSG-TBD1:  (CSUN) Connect-Speed-Update-Notification

      MSG-TBD2:  (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 Section 6.1 and Section 6.2, to be allocated for
   this specification.

      Control Message Attribute Value Pairs (AVPs)

      AVP-TBD1:  Connect Speed Update AVP

      AVP-TBD2:  Connect Speed Update Enable AVP


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 which are inserted by the Access Node/
   DSLAM are unconditionally trusted; the BRAS does not perform any
   validity check on the information received before forwarding the
   information.

   These AVP's 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.



Mammoliti, et al.         Expires May 20, 2008                 [Page 25]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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 Woj Dec and the others of the DSL Forum Architecture
   and Transport Working Group for there 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.

   [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.dslforum.org/techwork/tr/TR-101.pdf>.

11.2.  Informative References

   [I-D.ietf-ancp-protocol]
              Wadhwa, S., "Protocol for Access Node Control Mechanism in
              Broadband Networks", draft-ietf-ancp-protocol-01 (work in
              progress), July 2007.

   [IANA.enterprise-numbers]
              Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE
              NUMBERS", November 2007,



Mammoliti, et al.         Expires May 20, 2008                 [Page 26]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


              <http://www.iana.org/assignments/enterprise-numbers>.

   [IANA.l2tp-parameters]
              Internet Assigned Numbers Authority, "Layer Two Tunneling
              Protocol "L2TP"", October 2007,
              <http://www.iana.org/assignments/l2tp-parameters>.

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
              "Securing L2TP using IPsec", RFC 3193, November 2001.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC4243]  Stapp, M., Johnson, R., and T. Palaniappan, "Vendor-
              Specific Information Suboption for the Dynamic Host
              Configuration Protocol (DHCP) Relay Agent Option",
              RFC 4243, December 2005.

   [RFC4679]  Mammoliti, V., Zorn, G., Arberg, P., and R. Rennison, "DSL
              Forum Vendor-Specific RADIUS Attributes", RFC 4679,
              September 2006.

   [RFC4951]  Jain, V., "Fail Over Extensions for Layer 2 Tunneling
              Protocol (L2TP) "failover"", RFC 4951, August 2007.


Authors' Addresses

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

   Email: vince@cisco.com









Mammoliti, et al.         Expires May 20, 2008                 [Page 27]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


   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.         Expires May 20, 2008                 [Page 28]

Internet-Draft       L2TP Access Line AVP Extensions       November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Mammoliti, et al.         Expires May 20, 2008                 [Page 29]