+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
136 (0x88) for Maximum-Data-Rate-Downstream
Vendor-Length
6
Value
This field is a 4-byte unsigned integer, indicating the numeric
value of the subscriber’s DSL maximum downstream data rate. The
rate is coded in bits per second.
3.3.11. Minimum-Data-Rate-Upstream-Low-Power
Description
This Attribute contains the subscriber’s minimum upstream data
rate in low power state, as configured by the operator. It MAY be
included in Accounting-Request packets.
A summary of the Minimum-Data-Rate-Upstream-Low-Power Attribute
format is shown below. The fields are transmitted from left to
right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
137 (0x89) for Minimum-Data-Rate-Upstream-Low-Power
Vendor-Length
6
Value
This field is a 4-byte unsigned integer, indicating the numeric
value of the subscriber’s DSL minimum upstream data rate when in
low power state (L1/L2). The rate is coded in bits per second.
3.3.12. Minimum-Data-Rate-Downstream-Low-Power
Description
This Attribute contains the subscriber’s minimum downstream data
rate in low power state, as configured by the operator. It MAY be
included in Accounting-Request packets.
A summary of the Minimum-Data-Rate-Downstream-Low-Power Attribute
format is shown below. The fields are transmitted from left to
right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
138 (0x8A) for Minimum-Data-Rate-Downstream-Low-Power
Vendor-Length
6
Value
This field is a 4-byte unsigned integer, indicating the numeric
value of the subscriber’s DSL minimum downstream data rate. The
rate is coded in bits per second.
3.3.13. Maximum-Interleaving-Delay-Upstream
Description
This Attribute contains the subscriber’s maximum one-way upstream
interleaving delay, as configured by the operator. It MAY be
included in Accounting-Request packets.
A summary of the Maximum-Interleaving-Delay-Upstream Attribute format
is shown below. The fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
139 (0x8B) for Maximum-Interleaving-Delay-Upstream
Vendor-Length
6
Value
This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber’s DSL maximum one-way
upstream interleaving delay.
3.3.14. Actual-Interleaving-Delay-Upstream
Description
This Attribute contains the subscriber’s actual one-way upstream
interleaving delay. It MAY be included in Accounting-Request
packets.
A summary of the Actual-Interleaving-Delay-Upstream Attribute format
is shown below. The fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
140 (0x8C) for Actual-Interleaving-Delay-Upstream
Vendor-Length
6
Value
This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber’s DSL actual upstream
interleaving delay.
3.3.15. Maximum-Interleaving-Delay-Downstream
Description
This Attribute contains the subscriber’s maximum one-way
downstream interleaving delay, as configured by the operator. It
MAY be included in Accounting-Request packets.
A summary of the Maximum-Interleaving-Delay-Downstream Attribute
format is shown below. The fields are transmitted from left to
right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
141 (0x8D) for Maximum-Interleaving-Delay-Downstream
Vendor-Length
6
Value
This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber’s DSL maximum one-way
downstream interleaving delay.
3.3.16. Actual-Interleaving-Delay-Downstream
Description
This Attribute contains the subscriber’s actual one-way downstream
interleaving delay. It MAY be included in Accounting-Request
packets.
A summary of the Actual-Interleaving-Delay-Downstream Attribute
format is shown below. The fields are transmitted from left to
right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
142 (0x8E) for Actual-Interleaving-Delay-Downstream
Vendor-Length
6
Value
This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber’s DSL actual downstream
interleaving delay.
3.3.17. Access-Loop-Encapsulation
Description
This Attribute describes the encapsulation(s) used by the
subscriber on the DSL access loop. It MAY be present in both
Access-Request and Accounting-Request packets.
A summary of the Access-Loop-Encapsulation Attribute format is shown
below. The fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont’d) |
+-+-+-+-+-+-+-+-+
Vendor-Type
144 (0x90) for Access-Loop-Encapsulation
Vendor-Length
5
Value
This field is a string 3 bytes in length, logically divided into
three 1-byte sub-fields 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
0x01 AAL5
0x02 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
3.3.18. IWF-Session
Description
The presence of this Attribute indicates that the IWF has been
performed with respect to the subscriber’s session; note that no
data field is necessary. It MAY be included in both Access-
Request and Accounting-Request packets.
A summary of the IWF-Session Attribute format is shown below. The
fields are transmitted from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
254 (0xFE) for IWF-Session
Vendor-Length
2
4. Table of Attributes
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity; note that since none
of the DSL Forum VSAs may be present in the Access-Accept, Access-
Reject or Access-Challenge packets, those columns have been omitted
from the table.
Request Acct-Request # Attribute
0-1 0-1 1 Agent-Circuit-Id
0-1 0-1 2 Agent-Remote-Id
0-1 0-1 129 Actual-Data-Rate-Upstream
0-1 0-1 130 Actual-Data-Rate-Downstream
0 0-1 131 Minimum-Data-Rate-Upstream
0 0-1 132 Minimum-Data-Rate-Downstream
0 0-1 133 Attainable-Data-Rate-Upstream
0 0-1 134 Attainable-Data-Rate-Downstream
0 0-1 135 Maximum-Data-Rate-Upstream
0 0-1 136 Maximum-Data-Rate-Downstream
0 0-1 137 Minimum-Data-Rate-Upstream-Low-Power
0 0-1 138 Minimum-Data-Rate-Downstream-Low-Power
0 0-1 139 Maximum-Interleaving-Delay-Upstream
0 0-1 140 Actual-Interleaving-Delay-Upstream
0 0-1 141 Maximum-Interleaving-Delay-Downstream
0 0-1 142 Actual-Interleaving-Delay-Downstream
0-1 0-1 144 Access-Loop-Encapsulation
0-1 0-1 254 IWF-Session
The following table defines the meaning of the above table entries.
0 This Attribute MUST NOT be present in packet.
0-1 Zero or one instances of this Attribute MAY be present in
packet.
5. Security Considerations
The security of these Attributes relies on an implied trust
relationship between the Access Node/DSLAM and the BRAS. 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. These Attributes are intended to be
used in environments in which the network infrastructure (the Access
Node/DSLAM, the BRAS, and the entire network in which those two
devices reside) is trusted and secure.
As used in this document, the word "trusted" implies that
unauthorized traffic cannot enter the network except through secured
and trusted devices and that all devices internal to the network are
secure and trusted. Careful consideration should be given to the
potential security vulnerabilities that are present in this model
before deploying this option in actual networks.
The Attributes described in this document neither increase nor
decrease the security of the RADIUS protocol. For discussions of
various RADIUS vulnerabilities, see [RFC2607], [RFC3579], [RFC3162],
and [RFC3580].
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
6.2. Informative References
[IANA] Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE
NUMBERS", January 2006,
<http://www.iana.org/assignments/enterprise-numbers>.
[ITU.I363-5.1996]
International Telecommunications Union, "B-ISDN ATM
Adaptation Layer Specification: Type 5 AAL", ITU-T
Recommendation I.363.5, August 1996.
[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.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 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.
Authors’ Addresses
Vince Mammoliti
Cisco Systems
181 Bay Street, Suite 3400
Toronto, ON M5J 2T3
Canada
EMail: vince@cisco.com
Glen Zorn
Cisco Systems
2901 Third Avenue, Suite 600
SEA1/5/
Seattle, WA 98121
USA
Phone: +1 (425) 344 8113
EMail: gwz@cisco.com
Peter Arberg
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
USA
EMail: parberg@redback.com
Robert Rennison
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
USA
EMail: robert.rennison@ecitele.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).