📄 rfc4679.txt
字号:
Network Working Group V. MammolitiRequest for Comments: 4679 G. ZornCategory: Informational Cisco Systems P. Arberg Redback Networks, Inc. R. Rennison ECI Telecom September 2006 DSL Forum Vendor-Specific RADIUS AttributesStatus 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) The Internet Society (2006).IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.Abstract This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum. These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products.Mammoliti, et al. Informational [Page 1] RFC 4679 DSL Forum RADIUS VSA September 2006Table of Contents 1. Introduction ....................................................3 2. Terminology .....................................................3 2.1. Requirements Language ......................................3 2.2. Technical Terms and Acronyms ...............................3 3. Attributes ......................................................5 3.1. DSL Forum RADIUS VSA Definition ............................5 3.2. DSL Forum Vendor Specific Sub-Attribute Encoding ...........6 3.3. Sub-attribute Definitions ..................................6 3.3.1. Agent-Circuit-Id ....................................6 3.3.2. Agent-Remote-Id .....................................8 3.3.3. Actual-Data-Rate-Upstream ...........................9 3.3.4. Actual-Data-Rate-Downstream .........................9 3.3.5. Minimum-Data-Rate-Upstream .........................10 3.3.6. Minimum-Data-Rate-Downstream .......................11 3.3.7. Attainable-Data-Rate-Upstream ......................11 3.3.8. Attainable-Data-Rate-Downstream ....................12 3.3.9. Maximum-Data-Rate-Upstream .........................13 3.3.10. Maximum-Data-Rate-Downstream ......................13 3.3.11. Minimum-Data-Rate-Upstream-Low-Power ..............14 3.3.12. Minimum-Data-Rate-Downstream-Low-Power ............15 3.3.13. Maximum-Interleaving-Delay-Upstream ...............16 3.3.14. Actual-Interleaving-Delay-Upstream ................16 3.3.15. Maximum-Interleaving-Delay-Downstream .............17 3.3.16. Actual-Interleaving-Delay-Downstream ..............18 3.3.17. Access-Loop-Encapsulation .........................19 3.3.18. IWF-Session .......................................20 4. Table of Attributes ............................................21 5. Security Considerations ........................................21 6. References .....................................................22 6.1. Normative References ......................................22 6.2. Informative References ....................................22Mammoliti, et al. Informational [Page 2] RFC 4679 DSL Forum RADIUS VSA September 20061. Introduction The DSL Forum has created additional RADIUS [RFC2865] [RFC2866] vendor-specific attributes to carry DSL line identification and characterization information. This information is forwarded from the Access Node/DSLAM to the BRAS via Vendor-Specific PPPoE Tags [RFC2516], DHCP Relay Options [RFC3046], and Vendor-Specific Information Suboptions [RFC4243]. This document describes the subscriber line identification and characterization information and its mapping to RADIUS VSAs by the BRAS. The information acquired may be used to provide authentication 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].2.2. Technical Terms and Acronyms AAL5 ATM Adaption Layer 5 [ITU.I363-5.1996] Access Node/DSLAM The Access Node/DSLAM is a DSL signal terminator that contains a minimum of one Ethernet interface that serves as its northbound interface into which it aggregates traffic from several Asynchronous Transfer Mode (ATM)-based (subscriber ports) or Ethernet-based southbound 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.Mammoliti, et al. Informational [Page 3] RFC 4679 DSL Forum RADIUS VSA September 2006 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. FCS Frame Check Sequence. The FCS is a checksum added to an Ethernet frame for error detection/correction purposes. IPoA IP over ATM 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 PPP over ATM (PPPoA) traffic over PPPoE. LLC Logical Link ControlMammoliti, et al. Informational [Page 4] RFC 4679 DSL Forum RADIUS VSA September 20063. Attributes The following subsections describe the Attributes defined by this document. These Attributes MAY be transmitted in one or more RADIUS Attributes of type Vendor-Specific [RFC2865]. More than one attribute MAY be transmitted in a single Vendor-Specific Attribute; if this is done, the attributes SHOULD be packed as a sequence of Vendor-Type/Vendor-Length/Value triples following the initial Type, Length, and Vendor-Id fields.3.1. DSL Forum RADIUS VSA Definition Description This Attribute functions as a "container", encapsulating one or more vendor-specific sub-attributes; the encoding follows the recommendations in [RFC2865]. A summary of the generic DSL Forum VSA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | Sub-Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 26 for Vendor-Specific Length This field MUST be set equal to the sum of the Vendor-Length fields of the sub-attributes contained in the Vendor-Specific Attribute, plus six (Type + Length + Vendor-Id). Vendor-Id This field MUST be set to decimal 3561, the enterprise number assigned to the ADSL Forum [IANA]. Sub-Attributes This field MUST contain one or more DSL Forum Vendor-Specific sub-attributes, as specified below.Mammoliti, et al. Informational [Page 5] RFC 4679 DSL Forum RADIUS VSA September 20063.2. DSL Forum Vendor Specific Sub-Attribute Encoding A summary of the sub-attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type The Vendor-Type field is one octet in length and contains the sub-attribute type, as assigned by the DSL Forum. Vendor-Length The Vendor-Length field is one octet and indicates the length of the entire sub-attribute, including the Vendor-Type, Vendor-Length, and Value fields. Value The Value field is zero or more octets and contains information specific to the sub-attribute. The format and length of the Value field is determined by the Vendor-Type and Vendor-Length fields. The format of the value field is one of 2 data types, string or integer [RFC2865].3.3. Sub-attribute Definitions The following sub-sections define the DSL Forum vendor-specific sub- attributes.3.3.1. Agent-Circuit-Id Description This Attribute contains information describing the subscriber agent circuit identifier corresponding to the logical access loop port of the Access Node/DSLAM from which a subscriber's requests are initiated. It MAY be present in both Access-Request and Accounting-Request packets. A summary of the Agent-Circuit-Id Attribute format is shown below. The fields are transmitted from left to right.Mammoliti, et al. Informational [Page 6] RFC 4679 DSL Forum RADIUS VSA September 2006 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 1 for Agent-Circuit-Id Vendor-Length <= 65 String The String field contains information about the Access-Node to which the subscriber is attached, along with an identifier for the subscriber's DSL port on that Access-Node. 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) 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.Mammoliti, et al. Informational [Page 7] RFC 4679 DSL Forum RADIUS VSA September 2006 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).3.3.2. Agent-Remote-Id Description The Agent-Remote-Id Attribute contains an operator-specific, statically configured string that uniquely identifies the subscriber on the associated access loop of the Access Node/DSLAM. In a typical subscriber environment, multiple attributes can be used to identify the user, among others: Username (for example, as defined on a PPP client); Agent-Circuit-Id (a static, pre-defined string sent from the Access Node/DSLAM); Agent-Remote-Id (an operator-defined string configured on and sent by the Access Node/DSLAM). This Attribute MAY be included in both Access-Request and Accounting-Request packets. A summary of the Agent-Remote-Id 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 2 for Agent-Remote-Id Vendor-Length <= 65 String This value of this field is entirely open to the service provider's discretion. For example, it MAY contain a subscriber billing identifier or telephone number.Mammoliti, et al. Informational [Page 8] RFC 4679 DSL Forum RADIUS VSA September 20063.3.3. Actual-Data-Rate-Upstream Description This Attribute contains the actual upstream train rate of a subscriber's synchronized DSL link. It MAY be included in both Access-Request and Accounting-Request packets. A summary of the Actual-Data-Rate-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -