Internet Engineering Task Force (IETF) S. Wadhwa
Request for Comments: 6320 Alcatel-Lucent
Category: Standards Track J. Moisand
ISSN: 2070-1721 Juniper Networks
T. Haag
Deutsche Telekom
N. Voigt
Nokia Siemens Networks
T. Taylor, Ed.
Huawei Technologies
October 2011
Internet Engineering Task Force (IETF) S. Wadhwa
Request for Comments: 6320 Alcatel-Lucent
Category: Standards Track J. Moisand
ISSN: 2070-1721 Juniper Networks
T. Haag
Deutsche Telekom
N. Voigt
Nokia Siemens Networks
T. Taylor, Ed.
Huawei Technologies
October 2011
Protocol for Access Node Control Mechanism in Broadband Networks
宽带网络接入节点控制机制协议
Abstract
摘要
This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.
本文档描述了访问节点控制协议（ANCP）。ANCP在多业务参考体系结构中在网络接入服务器（NAS）和接入节点（例如，数字用户线路接入多路复用器（DSLAM））之间操作，以便执行与服务质量、服务和用户相关的操作。ANCP的用例记录在RFC 5851中。除了描述基本ANCP协议外，本文档还规定了数字用户线路（DSL）拓扑发现、线路配置和远程线路连接测试的功能。ANCP的设计允许在其他文档中进行协议扩展，如果它们需要支持其他用例和其他访问技术。
ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it.
ANCP基于RFC 3292中描述的通用交换机管理协议版本3（GSMPv3），但经过许多修改和扩展，这两个协议不可互操作。出于这个原因，ANCP被分配了一个单独的版本号来区分它。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6320.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6320.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Historical Note ............................................6
1.2. Requirements Language ......................................6
1.3. Terminology ................................................6
2. Broadband Access Aggregation ....................................8
2.1. ATM-Based Broadband Aggregation ............................8
2.2. Ethernet-Based Broadband Aggregation .......................9
3. Access Node Control Protocol -- General Aspects ................10
3.1. Protocol Version ..........................................10
3.2. ANCP Transport ............................................10
3.3. Encoding of Text Fields ...................................11
3.4. Treatment of Reserved and Unused Fields ...................12
3.5. The ANCP Adjacency Protocol ...............................12
3.5.1. ANCP Adjacency Message Format ......................12
3.5.2. ANCP Adjacency Procedures ..........................18
3.6. ANCP General Message Formats ..............................29
3.6.1. The ANCP Message Header ............................29
3.6.2. The ANCP Message Body ..............................36
3.7. General Principles for the Design of ANCP Messages ........37
1. Introduction ....................................................5
1.1. Historical Note ............................................6
1.2. Requirements Language ......................................6
1.3. Terminology ................................................6
2. Broadband Access Aggregation ....................................8
2.1. ATM-Based Broadband Aggregation ............................8
2.2. Ethernet-Based Broadband Aggregation .......................9
3. Access Node Control Protocol -- General Aspects ................10
3.1. Protocol Version ..........................................10
3.2. ANCP Transport ............................................10
3.3. Encoding of Text Fields ...................................11
3.4. Treatment of Reserved and Unused Fields ...................12
3.5. The ANCP Adjacency Protocol ...............................12
3.5.1. ANCP Adjacency Message Format ......................12
3.5.2. ANCP Adjacency Procedures ..........................18
3.6. ANCP General Message Formats ..............................29
3.6.1. The ANCP Message Header ............................29
3.6.2. The ANCP Message Body ..............................36
3.7. General Principles for the Design of ANCP Messages ........37
4. Generally Useful ANCP Messages and TLVs ........................38
4.1. Provisioning Message ......................................38
4.2. Generic Response Message ..................................39
4.3. Target TLV ................................................41
4.4. Command TLV ...............................................41
4.5. Status-Info TLV ...........................................42
5. Introduction to ANCP Capabilities for Digital
Subscriber Lines (DSLs) ........................................43
5.1. DSL Access Line Identification ............................44
5.1.1. Control Context (Informative) ......................44
5.1.2. TLVs for DSL Access Line Identification ............45
6. ANCP-Based DSL Topology Discovery ..............................48
6.1. Control Context (Informative) .............................48
6.2. Protocol Requirements .....................................50
6.2.1. Protocol Requirements on the AN Side ...............50
6.2.2. Protocol Requirements on the NAS Side ..............50
6.3. ANCP Port Up and Port Down Event Message Descriptions .....51
6.4. Procedures ................................................52
6.4.1. Procedures on the AN Side ..........................52
6.4.2. Procedures on the NAS Side .........................53
6.5. TLVs for DSL Line Attributes ..............................53
6.5.1. DSL-Line-Attributes TLV ............................53
6.5.2. DSL-Type TLV .......................................54
6.5.3. Actual-Net-Data-Rate-Upstream TLV ..................54
6.5.4. Actual-Net-Data-Rate-Downstream TLV ................54
6.5.5. Minimum-Net-Data-Rate-Upstream TLV .................55
6.5.6. Minimum-Net-Data-Rate-Downstream TLV ...............55
6.5.7. Attainable-Net-Data-Rate-Upstream TLV ..............55
6.5.8. Attainable-Net-Data-Rate-Downstream TLV ............55
6.5.9. Maximum-Net-Data-Rate-Upstream TLV .................56
6.5.10. Maximum-Net-Data-Rate-Downstream TLV ..............56
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV ......56
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV ....56
6.5.13. Maximum-Interleaving-Delay-Upstream TLV ...........57
6.5.14. Actual-Interleaving-Delay-Upstream TLV ............57
6.5.15. Maximum-Interleaving-Delay-Downstream TLV .........57
6.5.16. Actual-Interleaving-Delay-Downstream ..............57
6.5.17. DSL-Line-State TLV ................................58
6.5.18. Access-Loop-Encapsulation TLV .....................58
7. ANCP-Based DSL Line Configuration ..............................59
7.1. Control Context (Informative) .............................59
7.2. Protocol Requirements .....................................61
7.2.1. Protocol Requirements on the NAS Side ..............61
7.2.2. Protocol Requirements on the AN Side ...............61
7.3. ANCP Port Management (Line Configuration) Message Format ..62
7.4. Procedures ................................................64
7.4.1. Procedures on the NAS Side .........................64
7.4.2. Procedures on the AN Side ..........................64
4. Generally Useful ANCP Messages and TLVs ........................38
4.1. Provisioning Message ......................................38
4.2. Generic Response Message ..................................39
4.3. Target TLV ................................................41
4.4. Command TLV ...............................................41
4.5. Status-Info TLV ...........................................42
5. Introduction to ANCP Capabilities for Digital
Subscriber Lines (DSLs) ........................................43
5.1. DSL Access Line Identification ............................44
5.1.1. Control Context (Informative) ......................44
5.1.2. TLVs for DSL Access Line Identification ............45
6. ANCP-Based DSL Topology Discovery ..............................48
6.1. Control Context (Informative) .............................48
6.2. Protocol Requirements .....................................50
6.2.1. Protocol Requirements on the AN Side ...............50
6.2.2. Protocol Requirements on the NAS Side ..............50
6.3. ANCP Port Up and Port Down Event Message Descriptions .....51
6.4. Procedures ................................................52
6.4.1. Procedures on the AN Side ..........................52
6.4.2. Procedures on the NAS Side .........................53
6.5. TLVs for DSL Line Attributes ..............................53
6.5.1. DSL-Line-Attributes TLV ............................53
6.5.2. DSL-Type TLV .......................................54
6.5.3. Actual-Net-Data-Rate-Upstream TLV ..................54
6.5.4. Actual-Net-Data-Rate-Downstream TLV ................54
6.5.5. Minimum-Net-Data-Rate-Upstream TLV .................55
6.5.6. Minimum-Net-Data-Rate-Downstream TLV ...............55
6.5.7. Attainable-Net-Data-Rate-Upstream TLV ..............55
6.5.8. Attainable-Net-Data-Rate-Downstream TLV ............55
6.5.9. Maximum-Net-Data-Rate-Upstream TLV .................56
6.5.10. Maximum-Net-Data-Rate-Downstream TLV ..............56
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV ......56
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV ....56
6.5.13. Maximum-Interleaving-Delay-Upstream TLV ...........57
6.5.14. Actual-Interleaving-Delay-Upstream TLV ............57
6.5.15. Maximum-Interleaving-Delay-Downstream TLV .........57
6.5.16. Actual-Interleaving-Delay-Downstream ..............57
6.5.17. DSL-Line-State TLV ................................58
6.5.18. Access-Loop-Encapsulation TLV .....................58
7. ANCP-Based DSL Line Configuration ..............................59
7.1. Control Context (Informative) .............................59
7.2. Protocol Requirements .....................................61
7.2.1. Protocol Requirements on the NAS Side ..............61
7.2.2. Protocol Requirements on the AN Side ...............61
7.3. ANCP Port Management (Line Configuration) Message Format ..62
7.4. Procedures ................................................64
7.4.1. Procedures on the NAS Side .........................64
7.4.2. Procedures on the AN Side ..........................64
7.5. TLVs for DSL Line Configuration ...........................64
7.5.1. Service-Profile-Name TLV ...........................65
8. ANCP-Based DSL Remote Line Connectivity Testing ................65
8.1. Control Context (Informative) .............................65
8.2. Protocol Requirements .....................................66
8.2.1. Protocol Requirements on the NAS Side ..............66
8.2.2. Protocol Requirements on the AN Side ...............66
8.3. Port Management (OAM) Message Format ......................67
8.4. Procedures ................................................68
8.4.1. NAS-Side Procedures ................................68
8.4.2. AN-Side Procedures .................................69
8.5. TLVs for the DSL Line Remote Connectivity Testing
Capability ................................................70
8.5.1. OAM-Loopback-Test-Parameters TLV ...................70
8.5.2. Opaque-Data TLV ....................................71
8.5.3. OAM-Loopback-Test-Response-String TLV ..............71
9. IANA Considerations ............................................71
10. IANA Actions ..................................................72
10.1. ANCP Message Type Registry ...............................72
10.2. ANCP Result Code Registry ................................73
10.3. ANCP Port Management Function Registry ...................74
10.4. ANCP Technology Type Registry ............................75
10.5. ANCP Command Code Registry ...............................75
10.6. ANCP TLV Type Registry ...................................75
10.7. ANCP Capability Type Registry ............................77
10.8. Joint GSMP / ANCP Version Registry .......................77
11. Security Considerations .......................................77
12. Contributors ..................................................79
13. Acknowledgements ..............................................79
14. References ....................................................79
14.1. Normative References .....................................79
14.2. Informative References ...................................80
7.5. TLVs for DSL Line Configuration ...........................64
7.5.1. Service-Profile-Name TLV ...........................65
8. ANCP-Based DSL Remote Line Connectivity Testing ................65
8.1. Control Context (Informative) .............................65
8.2. Protocol Requirements .....................................66
8.2.1. Protocol Requirements on the NAS Side ..............66
8.2.2. Protocol Requirements on the AN Side ...............66
8.3. Port Management (OAM) Message Format ......................67
8.4. Procedures ................................................68
8.4.1. NAS-Side Procedures ................................68
8.4.2. AN-Side Procedures .................................69
8.5. TLVs for the DSL Line Remote Connectivity Testing
Capability ................................................70
8.5.1. OAM-Loopback-Test-Parameters TLV ...................70
8.5.2. Opaque-Data TLV ....................................71
8.5.3. OAM-Loopback-Test-Response-String TLV ..............71
9. IANA Considerations ............................................71
10. IANA Actions ..................................................72
10.1. ANCP Message Type Registry ...............................72
10.2. ANCP Result Code Registry ................................73
10.3. ANCP Port Management Function Registry ...................74
10.4. ANCP Technology Type Registry ............................75
10.5. ANCP Command Code Registry ...............................75
10.6. ANCP TLV Type Registry ...................................75
10.7. ANCP Capability Type Registry ............................77
10.8. Joint GSMP / ANCP Version Registry .......................77
11. Security Considerations .......................................77
12. Contributors ..................................................79
13. Acknowledgements ..............................................79
14. References ....................................................79
14.1. Normative References .....................................79
14.2. Informative References ...................................80
This document defines a new protocol, the Access Node Control Protocol (ANCP), to realize a control plane between a service-oriented layer 3 edge device (the Network Access Server, NAS) and a layer 2 Access Node (e.g., Digital Subscriber Line Access Multiplexer, DSLAM) in order to perform operations related to quality of service (QoS), services, and subscriptions. The requirements for ANCP and the context within which it operates are described in [RFC5851].
本文件定义了一种新的协议，即接入节点控制协议（ANCP），用于实现面向服务的第3层边缘设备（网络接入服务器，NAS）和第2层接入节点（例如，数字用户线接入多路复用器，DSLAM）之间的控制平面，以便执行与服务质量（QoS）、服务、，和订阅。[RFC5851]中描述了ANCP的要求及其运行环境。
ANCP provides its services to control applications operating in the AN and NAS, respectively. This relationship is shown in Figure 1. Specification of the control applications is beyond the scope of this document, but informative partial descriptions are provided as necessary to give a context for the operation of the protocol.
ANCP提供服务，分别控制在AN和NAS中运行的应用程序。这种关系如图1所示。控制应用的规范超出了本文件的范围，但提供了必要的信息性部分说明，以提供协议操作的上下文。
Access Node Network Access Server
+--------------------+ +--------------------+
| +----------------+ | | +----------------+ |
| | AN Control | | | | NAS Control | |
| | Application | | | | Application | |
| +----------------+ | | +----------------+ |
| +----------------+ | | +----------------+ |
| | ANCP Agent | | ANCP Messages | | ANCP Agent | |
| | (AN side) |<----------------------->| (NAS side) | |
| +----------------+ | | +----------------+ |
+--------------------+ +--------------------+
Access Node Network Access Server
+--------------------+ +--------------------+
| +----------------+ | | +----------------+ |
| | AN Control | | | | NAS Control | |
| | Application | | | | Application | |
| +----------------+ | | +----------------+ |
| +----------------+ | | +----------------+ |
| | ANCP Agent | | ANCP Messages | | ANCP Agent | |
| | (AN side) |<----------------------->| (NAS side) | |
| +----------------+ | | +----------------+ |
+--------------------+ +--------------------+
Figure 1: Architectural Context for the Access Node Control Protocol
图1：访问节点控制协议的体系结构上下文
At various points in this document, information flows between the control applications and ANCP are described. The purpose of such descriptions is to clarify the boundary between this specification and, for example, [TR-147]. There is no intention to place limits on the degree to which the control application and the protocol implementation are integrated.
在本文件的不同点上，描述了控制应用程序和ANCP之间的信息流。此类说明的目的是澄清本规范与例如[TR-147]之间的界限。无意对控制应用程序和协议实现的集成程度进行限制。
This specification specifies ANCP transport over TCP/IP. TCP encapsulation for ANCP is as defined in Section 3.2.
本规范规定了TCP/IP上的ANCP传输。ANCP的TCP封装如第3.2节所述。
The organization of this document is as follows:
本文件的组织结构如下：
o Sections 1.2 and 1.3 introduce some terminology that will be useful in understanding the rest of the document.
o 第1.2节和第1.3节介绍了一些有助于理解本文件其余部分的术语。
o Section 2 provides a description of the access networks within which ANCP will typically be deployed.
o 第2节描述了通常部署ANCP的接入网络。
o Section 3 specifies generally applicable aspects of ANCP.
o 第3节规定了ANCP的一般适用方面。
o Section 4 specifies some messages and TLVs intended for use by multiple capabilities spanning multiple technologies.
o 第4节指定了一些消息和TLV，这些消息和TLV旨在由跨越多种技术的多种功能使用。
o Section 5 and the three following sections describe and specify the ANCP implementation of three capabilities applicable to the control of DSL access technology: topology discovery, line configuration, and remote line connectivity testing.
o 第5节和以下三节描述并指定了适用于控制DSL接入技术的三种功能的ANCP实现：拓扑发现、线路配置和远程线路连接测试。
o Section 9 is the IANA Considerations section. This section defines a number of new ANCP-specific registries as well as the joint GSMP/ANCP version registry mentioned below.
o 第9节是IANA注意事项部分。本节定义了许多新的特定于ANCP的注册中心以及下面提到的GSMP/ANCP联合版本注册中心。
o Section 11 addresses security considerations relating to ANCP, beginning with the requirements stated in [RFC5713].
o 第11节从[RFC5713]中规定的要求开始，阐述了与ANCP相关的安全注意事项。
Initial implementations of the protocol that became ANCP were based on the General Switch Management Protocol version 3 (GSMPv3) [RFC3292]. The ANCP charter required the Working Group to develop its protocol based on these implementations. In the end, ANCP introduced so many extensions and modifications to GSMPv3 that the two protocols are not interoperable. Nevertheless, although this specification has no normative dependencies on [RFC3292], the mark of ANCP's origins can be seen in the various unused fields within the ANCP message header.
成为ANCP的协议的初始实现基于通用交换机管理协议版本3（GSMPv3）[RFC3292]。《非国大宪章》要求工作组根据这些实施情况制定其协议。最后，ANCP对GSMPv3进行了大量的扩展和修改，这两个协议无法互操作。尽管如此，尽管本规范对[RFC3292]没有规范性依赖关系，但在ANCP消息头中的各种未使用字段中可以看到ANCP来源的标记。
Early in ANCP's development, the decision was made to use the same TCP port and encapsulation as GSMPv3, and by the time ANCP was finished, it was too late to reverse that decision because of existing implementations. As a result, it is necessary to have a way for an ANCP peer to quickly distinguish ANCP from GSMP during initial adjacency negotiations. This has been provided by a joint registry of GSMP and ANCP version numbers. GSMP has version numbers 1 through 3. ANCP has the initial version number 50.
在ANCP开发的早期，决定使用与GSMPv3相同的TCP端口和封装，而在ANCP完成时，由于现有的实现，改变这一决定为时已晚。因此，有必要让ANCP对等方在初始邻接协商期间快速区分ANCP和GSMP。这是由GSMP和ANCP版本号联合登记处提供的。GSMP的版本号为1到3。ANCP的初始版本号为50。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section repeats some definitions from [RFC5851], but it also adds definitions for terms used only in this document.
本节重复了[RFC5851]中的一些定义，但也添加了仅在本文档中使用的术语的定义。
Access Node (AN): [RFC5851] Network device, usually located at a service provider central office or street cabinet that terminates access (local) loop connections from subscribers. In case the access loop is a Digital Subscriber Line (DSL), the Access Node provides DSL signal termination and is referred to as a DSL Access Multiplexer (DSLAM).
接入节点（AN）：[RFC5851]网络设备，通常位于服务提供商中央办公室或街道机柜，用于终止来自订阅者的接入（本地）环路连接。在接入环路是数字用户线（DSL）的情况下，接入节点提供DSL信号终端，并被称为DSL接入多路复用器（DSLAM）。
Network Access Server (NAS): [RFC5851] Network element that aggregates subscriber traffic from a number of Access Nodes. The NAS is an enforcement point for policy management and IP QoS in the access network. It is also referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS).
网络访问服务器（NAS）：[RFC5851]聚合来自多个访问节点的订户流量的网元。NAS是接入网络中策略管理和IP QoS的实施点。它也被称为宽带网络网关（BNG）或宽带远程访问服务器（BRAS）。
Home Gateway (HGW): Network element that connects subscriber devices to the Access Node and the access network. In the case of DSL, the Home Gateway is a DSL network termination that may operate either as a layer 2 bridge or as a layer 3 router. In the latter case, such a device is also referred to as a Routing Gateway (RG).
家庭网关（HGW）：将用户设备连接到接入节点和接入网络的网络元件。在DSL的情况下，家庭网关是可以作为第2层网桥或第3层路由器操作的DSL网络终端。在后一种情况下，这种设备也称为路由网关（RG）。
ANCP agent: A logical entity that implements ANCP in the Access Node (AN-side) or NAS (NAS-side).
ANCP代理：在访问节点（AN端）或NAS（NAS端）中实现ANCP的逻辑实体。
Access Node control adjacency: (modified from [RFC5851]) The relationship between the AN-side ANCP agent and the NAS-side ANCP agent for the purpose of exchanging Access Node Control Protocol messages. The adjacency may be either up or down, depending on the result of the Access Node Control adjacency protocol operation.
接入节点控制邻接：（由[RFC5851]修改）AN侧ANCP代理和NAS侧ANCP代理之间的关系，用于交换接入节点控制协议消息。根据接入节点控制邻接协议操作的结果，邻接可以是向上或向下。
ANCP capability: A specific set of ANCP messages, message content, and procedures required to implement a specific use case or set of use cases. Some ANCP capabilities are applicable to just one access technology while others are technology independent. The capabilities applicable to a given ANCP adjacency are negotiated during adjacency startup.
ANCP能力：实现特定用例或用例集所需的一组特定的ANCP消息、消息内容和过程。一些ANCP功能仅适用于一种接入技术，而其他功能则与技术无关。适用于给定ANCP邻接的能力在邻接启动期间协商。
Type-Length-Value (TLV): A data structure consisting of a 16-bit type field, a sixteen-bit length field, and a variable-length value field padded to the nearest 32-bit word boundary, as described in Section 3.6.2. The value field of a TLV can contain other TLVs. An IANA registry is maintained for values of the ANCP TLV Type field.
类型长度值（TLV）：由16位类型字段、16位长度字段和填充到最近32位字边界的可变长度值字段组成的数据结构，如第3.6.2节所述。TLV的值字段可以包含其他TLV。为ANCP TLV类型字段的值维护IANA注册表。
Net data rate: [RFC5851] Defined by ITU-T G.993.2 [G.993.2], Section 3.39, i.e., the portion of the total data rate that can be used to transmit user information (e.g., ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g., trellis coding in the case of DSL). It includes
净数据速率：[RFC5851]由ITU-T G.993.2[G.993.2]第3.39节定义，即可用于传输用户信息（例如ATM信元或以太网帧）的总数据速率部分。它排除了与物理传输机制相关的开销（例如，DSL情况下的网格编码）。它包括
TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation and non-zero for 64/65 encapsulation.
TPS-TC（传输协议专用-传输汇聚）封装；这对于ATM封装是零，对于64/65封装是非零。
Line rate: [RFC5851] Defined by ITU-T G.993.2. It contains the complete overhead including Reed-Solomon and trellis coding.
线路速率：[RFC5851]由ITU-T G.993.2定义。它包含完整的开销，包括Reed-Solomon和网格编码。
DSL multi-pair bonding: Method for bonding (or aggregating) multiple xDSL access lines into a single bidirectional logical link, henceforth referred to in this document as "DSL bonded circuit". DSL "multi-pair" bonding allows an operator to combine the data rates on two or more copper pairs, and deliver the aggregate data rate to a single customer. ITU-T recommendations G.998.1 [G.998.1] and G.998.2 [G.998.2], respectively, describe ATM- and Ethernet-based multi-pair bonding.
DSL多线对连接：将多条xDSL接入线连接（或聚合）成一条双向逻辑链路的方法，在本文件中称为“DSL连接电路”。DSL“多对”连接允许运营商组合两个或多个铜线对上的数据速率，并向单个客户提供聚合数据速率。ITU-T建议G.998.1[G.998.1]和G.998.2[G.998.2]分别描述了基于ATM和以太网的多对连接。
The end-to-end DSL network consists of network service provider (NSP) and application service provider (ASP) networks, regional/access network, and customer premises network. Figure 2 shows ATM broadband access network components.
端到端DSL网络由网络服务提供商（NSP）和应用服务提供商（ASP）网络、区域/接入网络和客户场所网络组成。图2显示了ATM宽带接入网络组件。
The regional/access network consists of the regional network, Network Access Server (NAS), and the access network as shown in Figure 2. Its primary function is to provide end-to-end transport between the customer premises and the NSP or ASP.
区域/接入网络由区域网络、网络接入服务器（NAS）和接入网络组成，如图2所示。其主要功能是提供客户场所与NSP或ASP之间的端到端传输。
The Access Node terminates the DSL signal. It may be in the form of a DSLAM in the central office, a remote DSLAM, or a Remote Access Multiplexer (RAM). The Access Node is the first point in the network where traffic on multiple DSL access lines will be aggregated onto a single network.
接入节点终止DSL信号。它可以是中央办公室中的DSLAM、远程DSLAM或远程接入多路复用器（RAM）的形式。接入节点是网络中的第一个点，其中多条DSL接入线路上的流量将聚合到单个网络上。
The NAS performs multiple functions in the network. The NAS is the aggregation point for subscriber traffic. It provides aggregation capabilities (e.g., IP, PPP, ATM) between the Regional/Access Network and the NSP or ASP. These include traditional ATM-based offerings and newer, more native IP-based services. This includes support for Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services encapsulated over an appropriate layer 2 transport.
NAS在网络中执行多种功能。NAS是订户流量的聚合点。它在区域/接入网络和NSP或ASP之间提供聚合功能（如IP、PPP、ATM）。这些服务包括传统的基于ATM的服务和更新的、更基于本地IP的服务。这包括支持ATM上的点对点协议（PPPoA）和以太网上的点对点协议（PPPoE），以及通过适当的第2层传输封装的直接IP服务。
Beyond aggregation, the NAS is also the enforcement point for policy management and IP QoS in the regional/access networks. To allow IP QoS support over an existing non-IP-aware layer 2 access network
除了聚合之外，NAS也是区域/接入网络中策略管理和IP QoS的实施点。允许通过现有的非IP感知的第2层访问网络提供IP QoS支持
without using multiple layer 2 QoS classes, a mechanism based on hierarchical scheduling is used. This mechanism, defined in [TR-059], preserves IP QoS over the ATM network between the NAS and the Routing Gateway (RG) at the edge of the subscriber network, by carefully controlling downstream traffic in the NAS, so that significant queuing and congestion do not occur farther down the ATM network. This is achieved by using a Diffserv-aware hierarchical scheduler in the NAS that will account for downstream trunk bandwidths and DSL synchronization rates.
在不使用多个第2层QoS类的情况下，使用了基于分层调度的机制。[TR-059]中定义的这种机制通过仔细控制NAS中的下游流量，在NAS和用户网络边缘的路由网关（RG）之间的ATM网络上保持IP QoS，从而使ATM网络下游不会出现明显的排队和拥塞。这是通过在NAS中使用区分服务感知的分层调度器实现的，该调度器将考虑下游中继带宽和DSL同步速率。
[RFC5851] provides detailed definitions of the functions of each network element in the broadband reference architecture.
[RFC5851]提供了宽带参考体系结构中每个网元功能的详细定义。
Access Customer
<--- Aggregation --> <------- Premises ------->
Network Network
Access Customer
<--- Aggregation --> <------- Premises ------->
Network Network
+------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband| | +---+ | +------+ | |+-----+ +----------+|
ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+
---+ | | +---+ | +--------------------------+
| | | +---+ | |+-----+ +---+ +----------+|
+---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber||
+---+ ||Modem| +---+ |Devices ||
|+-----+ +----------+|
+--------------------------+
HGW: Home Gateway
NAS: Network Access Server
+------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband| | +---+ | +------+ | |+-----+ +----------+|
ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+
---+ | | +---+ | +--------------------------+
| | | +---+ | |+-----+ +---+ +----------+|
+---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber||
+---+ ||Modem| +---+ |Devices ||
|+-----+ +----------+|
+--------------------------+
HGW: Home Gateway
NAS: Network Access Server
Figure 2: ATM Broadband Aggregation Topology
图2:ATM宽带聚合拓扑
The Ethernet aggregation network architecture builds on the Ethernet bridging/switching concepts defined in IEEE 802. The Ethernet aggregation network provides traffic aggregation, class of service distinction, and customer separation and traceability. VLAN tagging, defined in [IEEE802.1Q] and enhanced by [IEEE802.1ad], is used as the standard virtualization mechanism in the Ethernet aggregation network. The aggregation devices are "provider edge bridges" defined in [IEEE802.1ad].
The Ethernet aggregation network architecture builds on the Ethernet bridging/switching concepts defined in IEEE 802. The Ethernet aggregation network provides traffic aggregation, class of service distinction, and customer separation and traceability. VLAN tagging, defined in [IEEE802.1Q] and enhanced by [IEEE802.1ad], is used as the standard virtualization mechanism in the Ethernet aggregation network. The aggregation devices are "provider edge bridges" defined in [IEEE802.1ad].translate error, please retry
Stacked VLAN tags provide one possible way to create an equivalent of "virtual paths" and "virtual circuits" in the aggregation network. The "outer" VLAN can be used to create a form of "virtual path"
堆叠的VLAN标签提供了一种可能的方法，可以在聚合网络中创建“虚拟路径”和“虚拟电路”的等价物。“外部”VLAN可用于创建一种形式的“虚拟路径”
between a given DSLAM and a given NAS. "Inner" VLAN tags create a form of "virtual circuit" on a per-DSL-line basis. This is the 1:1 VLAN allocation model. An alternative model is to bridge sessions from multiple subscribers behind a DSLAM into a single VLAN in the aggregation network. This is the N:1 VLAN allocation model. Section 1.6 of [TR-101] provides brief definitions of these two models, while Section 2.5.1 describes them in more detail.
在给定的DSLAM和给定的NAS之间。“内部”VLAN标签以每DSL线路为基础创建一种形式的“虚拟电路”。这是1:1 VLAN分配模型。另一种模式是将DSLAM后面的多个订户的会话桥接到聚合网络中的单个VLAN中。这是N:1 VLAN分配模型。[TR-101]的第1.6节提供了这两个模型的简要定义，而第2.5.1节对其进行了更详细的描述。
This section specifies aspects of the Access Node Control Protocol (ANCP) that are generally applicable.
本节规定了通常适用的访问节点控制协议（ANCP）的各个方面。
ANCP messages contain an 8-bit protocol version field. For the protocol version specified in this document, the value of that field MUST be set to 50.
ANCP消息包含一个8位协议版本字段。对于本文档中指定的协议版本，该字段的值必须设置为50。
This document specifies the use of TCP / IPsec+IKEv2 / IP for transport of ANCP messages. For further discussion of the use of IPsec and IKEv2, see Section 11. The present section deals with the TCP aspects. Other specifications may introduce additional transports in the future.
本文件规定使用TCP/IPsec+IKEv2/IP传输ANCP消息。有关IPsec和IKEv2使用的进一步讨论，请参阅第11节。本节讨论TCP方面。其他规范可能会在将来引入其他传输。
In the case of ATM access, a separate permanent virtual circuit (PVC) that is a control channel and is capable of transporting IP MAY be configured between the NAS and the AN for ANCP messages.
在ATM接入的情况下，可以在NAS和AN之间为ANCP消息配置作为控制信道并且能够传输IP的单独的永久虚拟电路（PVC）。
In the case of an Ethernet access/aggregation network, a typical practice is to send the Access Node Control Protocol messages over a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN identifier (VLAN ID).
在以太网接入/聚合网络的情况下，典型实践是使用单独的VLAN标识符（VLAN ID）通过专用以太网虚拟LAN（VLAN）发送接入节点控制协议消息。
When transported over TCP, ANCP messages MUST use an encapsulation consisting of a 4-byte header field prepended to the ANCP message as shown in Figure 3.
当通过TCP传输时，ANCP消息必须使用一个封装，该封装包含一个4字节的头字段，在ANCP消息前面，如图3所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (0x880C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ANCP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (0x880C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ANCP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Encapsulation of ANCP Messages over TCP/IP
图3:TCP/IP上ANCP消息的封装
The fields of the encapsulating header are as follows:
封装头的字段如下所示：
Identifier (16 bits): This identifies a GSMP or ANCP message. It MUST be set to 0x880C.
标识符（16位）：标识GSMP或ANCP消息。必须将其设置为0x880C。
Length (16 bits): Total length of the ANCP message in bytes, not including the 4-byte encapsulating header.
长度（16位）：ANCP消息的总长度（字节），不包括4字节的封装头。
The Access Node MUST initiate the TCP session to the NAS, using destination port 6068.
接入节点必须使用目标端口6068启动到NAS的TCP会话。
This is necessary to avoid static address provisioning on the NAS for all the ANs that are being served by the NAS. It is easier to configure a given AN with the single IP address of the NAS that serves the AN.
这对于避免在NAS上为NAS提供服务的所有AN提供静态地址是必要的。使用为AN提供服务的NAS的单个IP地址配置给定AN更容易。
The NAS MUST listen on port 6068 for incoming connections from the Access Nodes.
NAS必须在端口6068上侦听来自访问节点的传入连接。
In the event of an ANCP transport protocol failure, all pending ANCP messages destined to the disconnected recipient SHOULD be discarded until the transport connection is re-established.
在ANCP传输协议失败的情况下，所有发送给断开连接的收件人的挂起ANCP消息都应丢弃，直到重新建立传输连接。
In ANCP, all text fields use UTF-8 encoding [RFC3629]. Note that US-ASCII characters have the same representation when coded as UTF-8 as they do when coded according to [US_ASCII].
在ANCP中，所有文本字段都使用UTF-8编码[RFC3629]。请注意，当按照UTF-8编码时，US-ASCII字符的表示形式与按照[US_ASCII]编码时的表示形式相同。
When extracting text fields from a message, the ANCP agent MUST NOT assume that the fields are zero-terminated.
从消息中提取文本字段时，ANCP代理不得假定字段以零结尾。
ANCP messages contain a number of fields that are unused or reserved. Some fields are always unused (typically because they were inherited from GSMPv3 but are not useful in the ANCP context). Others are reserved in the current specification, but are provided for flexibility in future extensions to ANCP. Both reserved and unused fields MUST be set to zeroes by the sender and MUST be ignored by the receiver.
ANCP消息包含许多未使用或保留的字段。某些字段始终未使用（通常是因为它们是从GSMPv3继承的，但在ANCP上下文中不有用）。当前规范中保留了其他规范，但提供这些规范是为了在将来扩展到ANCP时具有灵活性。发送方必须将保留字段和未使用字段设置为零，接收方必须忽略这些字段。
Unused bits in a flag field are shown in figures as 'x'. The above requirement (sender set to zero, receiver ignore) applies to such unused bits.
标志字段中未使用的位在图中显示为“x”。上述要求（发送方设置为零，接收方忽略）适用于此类未使用位。
ANCP uses the adjacency protocol to synchronize the NAS and Access Nodes and maintain the ANCP session. After the TCP connection is established, adjacency protocol messages MUST be exchanged as specified in this section. ANCP messages other than adjacency protocol messages MUST NOT be sent until the adjacency protocol has achieved synchronization.
ANCP使用邻接协议来同步NAS和访问节点，并维护ANCP会话。TCP连接建立后，必须按照本节的规定交换邻接协议消息。在邻接协议实现同步之前，不得发送邻接协议消息以外的ANCP消息。
The ANCP adjacency message format is shown in Figure 4 below.
ANCP邻接消息格式如下图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType |P Flag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | # of Caps | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capability Fields ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType |P Flag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | # of Caps | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capability Fields ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ANCP Adjacency Message Format
图4:ANCP邻接消息格式
The fields of the ANCP adjacency message are as follows:
ANCP邻接信息的字段如下所示：
Version (8 bits): ANCP version, which is subject to negotiation. This is the key parameter by means of which ANCP messages can be distinguished from GSMP messages received over the same port.
版本（8位）：ANCP版本，以协商为准。这是一个关键参数，通过该参数可以将ANCP消息与通过同一端口接收的GSMP消息区分开来。
Message Type (8 bits): Always has value 10 (adjacency protocol).
消息类型（8位）：始终具有值10（邻接协议）。
Timer (8 bits): The Timer field is used to negotiate the timer value used in the adjacency protocol with the peer. The timer specifies the nominal time between periodic adjacency protocol messages. It is a constant for the duration of an ANCP session. The Timer field is specified in units of 100 ms, with a default value of 250 (i.e., 25 seconds).
计时器（8位）：计时器字段用于与对等方协商邻接协议中使用的计时器值。计时器指定周期性邻接协议消息之间的标称时间。在ANCP会议期间，这是一个常数。计时器字段以100 ms为单位指定，默认值为250（即25秒）。
M flag (1 bit): Used in the SYN message to prevent the NAS from synchronizing with another NAS and the AN from synchronizing with another AN. In the SYN message, it is always set to 1 by the NAS and to 0 by the AN. In other adjacency message types, it is always set to 0 by the sender and ignored by the receiver.
M标志（1位）：在SYN消息中使用，以防止NAS与另一个NAS同步以及AN与另一个AN同步。在SYN消息中，NAS始终将其设置为1，AN始终将其设置为0。在其他邻接消息类型中，发送方总是将其设置为0，接收方则忽略它。
Code (7 bits): The adjacency protocol message type. It MUST have one of the following values:
代码（7位）：邻接协议消息类型。它必须具有以下值之一：
Code = 1: SYN;
Code = 1: SYN;
Code = 2: SYNACK;
Code = 2: SYNACK;
Code = 3: ACK;
Code = 3: ACK;
Code = 4: RSTACK.
代码=4:RSTACK。
Sender Name (48 bits): For the SYN, SYNACK, and ACK messages, is the identifier of the entity sending the message. The Sender Name is a 48-bit quantity that is unique within the operational context of the device. A 48-bit IEEE 802 Media Access Control (MAC) address, if available, may be used for the Sender Name. If the Ethernet encapsulation is used, the Sender Name MUST be the Source Address from the MAC header. For the RSTACK message, the Sender Name field is set to the value of the Receiver Name field from the incoming message that caused the RSTACK message to be generated.
发送方名称（48位）：对于SYN、SYNACK和ACK消息，是发送消息的实体的标识符。发送方名称是48位的数量，在设备的操作上下文中是唯一的。48位IEEE 802媒体访问控制（MAC）地址（如果可用）可用于发送方名称。如果使用以太网封装，发送方名称必须是MAC头中的源地址。对于RSTACK消息，发送方名称字段设置为导致生成RSTACK消息的传入消息的接收方名称字段的值。
Receiver Name (48 bits) For the SYN, SYNACK, and ACK messages, is the name of the entity that the sender of the message believes is at the far end of the link. If the sender of the message does not know the name of the entity at the far end of the link, this field SHOULD be set to zero. For the RSTACK message, the Receiver Name field is set to the value of the Sender Name field from the incoming message that caused the RSTACK message to be generated.
SYN、SYNACK和ACK消息的接收方名称（48位）是消息发送方认为位于链路远端的实体的名称。如果消息的发送者不知道链接远端实体的名称，则此字段应设置为零。对于RSTACK消息，接收方名称字段设置为导致生成RSTACK消息的传入消息的发送方名称字段的值。
Sender Port (32 bits): For the SYN, SYNACK, and ACK messages, is the local port number of the link across which the message is being sent. For the RSTACK message, the Sender Port field is set to the value of the Receiver Port field from the incoming message that caused the RSTACK message to be generated.
发送方端口（32位）：对于SYN、SYNACK和ACK消息，是发送消息的链路的本地端口号。对于RSTACK消息，发送方端口字段设置为导致生成RSTACK消息的传入消息的接收方端口字段的值。
Receiver Port (32 bits): For the SYN, SYNACK, and ACK messages, is what the sender believes is the local port number for the link, allocated by the entity at the far end of the link. If the sender of the message does not know the port number at the far end of the link, this field SHOULD be set to zero. For the RSTACK message, the Receiver Port field is set to the value of the Sender Port field from the incoming message that caused the RSTACK message to be generated.
接收方端口（32位）：对于SYN、SYNACK和ACK消息，发送方认为是链路的本地端口号，由链路远端的实体分配。如果消息发送方不知道链路远端的端口号，则此字段应设置为零。对于RSTACK消息，接收方端口字段设置为导致生成RSTACK消息的传入消息的发送方端口字段的值。
PType (4 bits): PType is used to specify if partitions are used and how the Partition ID is negotiated.
PType（4位）：PType用于指定是否使用分区以及如何协商分区ID。
Type of partition being requested:
请求的分区类型：
0 - no partition;
0-无分区；
1 - fixed partition request;
1-固定分区请求；
2 - fixed partition assigned.
2-固定分区分配。
P Flag (4 bits): Used to indicate the type of partition request.
P标志（4位）：用于指示分区请求的类型。
1 - new adjacency;
1-新邻接；
2 - recovered adjacency.
2-恢复邻接。
In case of a conflict between the peers' views of the value of the P Flag, the lower value is used.
如果对等方对P标志值的看法存在冲突，则使用较低的值。
Sender Instance (24 bits): For the SYN, SYNACK, and ACK messages, is the sender's instance number for the link to the peer. It is used to detect when the link comes back up after going down or when the identity of the entity at the other end of the link changes. The instance number is a 24-bit number that is guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number. For the RSTACK message, the Sender Instance field is set to the value of the Receiver Instance field from the incoming message that caused the RSTACK message to be generated.
发送方实例（24位）：对于SYN、SYNACK和ACK消息，是指向对等方的链接的发送方实例号。它用于检测链路在下降后何时恢复，或者链路另一端的实体标识何时更改。实例号是一个24位的数字，保证在最近的时间内是唯一的，并且在链路或节点关闭后恢复时会发生变化。零不是有效的实例号。对于RSTACK消息，发送方实例字段设置为导致生成RSTACK消息的传入消息的接收方实例字段的值。
Partition ID (8 bits): Field used to associate the message with a specific partition of the AN. The value of this field is negotiated during the adjacency procedure. The AN makes the final decision, but will consider a request from the NAS. If the AN does not support partitions, the value of this field MUST be 0. Otherwise, it MUST be non-zero.
分区ID（8位）：用于将消息和特定分区关联的字段。此字段的值在邻接过程中协商。AN做出最终决定，但会考虑NAS的请求。如果AN不支持分区，则此字段的值必须为0。否则，它必须是非零的。
Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages, is what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. If the sender of the message does not know the current instance number at the far end of the link, this field SHOULD be set to zero. For the RSTACK message, the Receiver Instance field is set to the value of the Sender Instance field from the incoming message that caused the RSTACK message to be generated.
接收方实例（24位）：对于SYN、SYNACK和ACK消息，发送方认为是链路的当前实例号，由链路远端的实体分配。如果消息的发送者不知道链接远端的当前实例号，则此字段应设置为零。对于RSTACK消息，Receiver Instance字段设置为导致生成RSTACK消息的传入消息的Sender Instance字段的值。
Reserved (8 bits): Reserved for use by a future version of this specification.
保留（8位）：保留供本规范未来版本使用。
# of Caps (8 bits): Indicates the number of Capability fields that follow.
#CAP的数量（8位）：表示后面的能力字段的数量。
Total Length (16 bits): Indicates the total number of bytes occupied by the Capability fields that follow.
总长度（16位）：表示后面的功能字段占用的字节总数。
Capability Fields: Each Capability field indicates one ANCP capability supported by the sender of the adjacency message. Negotiation of a common set of capabilities to be supported within the ANCP session is described below. The detailed format of a Capability field is shown in Figure 5 and described below.
能力字段：每个能力字段表示邻接消息发送方支持的一个ANCP能力。下文描述了在ANCP会话中支持的一组通用功能的协商。能力字段的详细格式如图5所示，如下所述。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Capability Field
图5：能力领域
The sub-fields of this structure are as follows:
此结构的子字段如下所示：
Capability Type (16 bits): Indicates the specific capability supported. An IANA registry exists for values of this sub-field. The values specified by this document are listed below.
能力类型（16位）：表示支持的特定能力。此子字段的值存在IANA注册表。本文件规定的值如下所示。
Capability Length (16 bits): The number of bytes of data contained in the Capability Data sub-field, excluding padding. If the definition of a particular capability includes no capability data, the value of the Capability Length sub-field is zero.
Capability Length（16位）：Capability data子字段中包含的数据字节数，不包括填充。如果特定能力的定义不包括能力数据，则能力长度子字段的值为零。
Capability Data (as indicated by Capability Length): Contains data associated with the capability as specified for that capability. If the definition of a particular capability includes no capability data, the Capability Data sub-field is absent (has zero length). Otherwise, the Capability Data sub-field MUST be padded with zeroes as required to terminate on a 4-byte word boundary. The possibility of specifying capability data provides the flexibility to advertise more than the mere presence or absence of a capability if needed.
能力数据（由能力长度表示）：包含与为该能力指定的能力相关联的数据。如果特定能力的定义不包含能力数据，则不存在能力数据子字段（长度为零）。否则，必须根据需要使用零填充Capability Data子字段，以在4字节字边界上终止。如果需要的话，指定功能数据的可能性提供了灵活性，不仅仅是显示或不显示功能。
The following capabilities are defined for ANCP as applied to DSL access:
针对应用于DSL接入的ANCP定义了以下功能：
o Capability Type: DSL Topology Discovery = 0x01
o 能力类型：DSL拓扑发现=0x01
Access technology: DSL
接入技术：DSL
Length (in bytes): 0
长度（字节）：0
Capability Data: NULL
能力数据：空
For the detailed protocol specification of this capability, see Section 6.
有关此功能的详细协议规范，请参见第6节。
o Capability Type: DSL Line Configuration = 0x02
o 能力类型：DSL线路配置=0x02
Access technology: DSL
接入技术：DSL
Length (in bytes): 0
长度（字节）：0
Capability Data: NULL
能力数据：空
For the detailed protocol specification of this capability, see Section 7.
有关此功能的详细协议规范，请参见第7节。
o Capability Type: DSL Remote Line Connectivity Testing = 0x04
o 能力类型：DSL远程线路连接测试=0x04
Access technology: DSL
接入技术：DSL
Length (in bytes): 0
长度（字节）：0
Capability Data: NULL
能力数据：空
For the detailed protocol specification of this capability, see Section 8.
有关此功能的详细协议规范，请参见第8节。
In addition to the adjacency messages whose format is shown in Figure 6, ANCP adjacency procedures use the Adjacency Update message (Figure 6) to inform other NASs controlling the same AN partition when a particular NAS joins or loses an adjacency with that partition.
除了格式如图6所示的邻接消息外，ANCP邻接过程还使用邻接更新消息（图6）在特定NAS加入或丢失与该分区的邻接时通知控制同一分区的其他NAS。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Adjacency Update Message
图6：邻接更新消息
The Adjacency Update message is identical to the general ANCP message header described in Section 3.6, but the field settings are in part specific to the Adjacency Update message. The fields in this message are as follows:
邻接更新消息与第3.6节中描述的通用ANCP消息头相同，但字段设置部分特定于邻接更新消息。此消息中的字段如下所示：
Version (8 bits): The ANCP version negotiated and running in this adjacency.
版本（8位）：协商并在此邻接中运行的ANCP版本。
Message Type (8 bits): Always 85.
消息类型（8位）：始终为85。
Result (4 bits): Set to Ignore (0).
结果（4位）：设置为忽略（0）。
Code (12 bits): Set to the total number of adjacencies currently established on this partition, from the point of view of the AN.
代码（12位）：设置为当前在此分区上建立的邻接总数，从。
Partition ID (8 bits): The partition identifier of the partition for which this notification is being sent.
分区ID（8位）：为其发送此通知的分区的分区标识符。
Transaction Identifier (24 bits): MUST be set to 0.
事务标识符（24位）：必须设置为0。
I (1 bit), SubMessage number (15 bits): Set as described in Section 3.6.1.7.
I（1位），子消息编号（15位）：按照第3.6.1.7节所述进行设置。
Length (16 bits): Set as described in Section 3.6.1.8.
长度（16位）：如第3.6.1.8节所述设置。
The ANCP adjacency protocol operates symmetrically between the NAS and the AN. In the absence of errors or race conditions, each peer sends a SYN message, receives a SYNACK message in acknowledgement, and completes the establishment of the adjacency by sending an ACK message. Through this exchange, each peer learns the values of the Name, Port, and Instance parameters identifying the other peer, and
ANCP邻接协议在NAS和AN之间对称运行。在没有错误或竞争条件的情况下，每个对等方发送SYN消息，在确认中接收SYNACK消息，并通过发送ACK消息完成邻接的建立。通过此交换，每个对等方学习标识其他对等方的名称、端口和实例参数的值，以及
the two peers negotiate the values of the Version, Timer, P Flag, and Partition ID parameters and the set of capabilities that the adjacency will support.
这两个对等点协商版本、计时器、P标志和分区ID参数的值以及邻接将支持的功能集。
Once the adjacency has been established, its liveness is periodically tested. The peers engage in an ACK message exchange at a frequency determined by the negotiated value of the Timer field.
一旦建立了邻接关系，它的活性就会定期进行测试。对等方以定时器字段的协商值确定的频率参与ACK消息交换。
If an inconsistency, loss of contact, or protocol violation is detected, the detecting peer can force a restart of the synchronization process by sending an RSTACK message to the other end.
如果检测到不一致、失去联系或违反协议，则检测对等方可以通过向另一端发送RSTACK消息来强制重新启动同步过程。
Once an adjacency has been established, if more than one NAS has established an adjacency to the same partition, then the AN sends an Adjacency Update message to each such NAS to let it know how many established adjacencies the partition currently supports. Similarly, if an adjacency is lost, the AN sends an Adjacency Update message to each of the remaining adjacent NASs to let them know about the change in status.
一旦建立了邻接关系，如果多个NAS已经建立了与同一分区的邻接关系，则an将向每个这样的NAS发送邻接更新消息，让其知道分区当前支持多少个已建立的邻接关系。类似地，如果邻接丢失，an将向剩余的每个相邻NAS发送邻接更新消息，让它们知道状态的变化。
The adjacency protocol is described by the following rules and state tables. It begins with the sending of a SYN by each end as soon as the transport connection has been established. If at any point the operations A, B, C, or "Verify Adjacent State" defined below detect a mismatch, a log SHOULD be generated, identifying the fields concerned and the expected and received values for each.
邻接协议由以下规则和状态表描述。它从传输连接建立后，每端发送SYN开始。如果操作A、B、C或下面定义的“验证相邻状态”在任何时候检测到不匹配，则应生成日志，确定相关字段以及每个字段的预期值和接收值。
The rules and state tables use the following operations:
规则和状态表使用以下操作：
o The "Record Adjacency State" operation is defined in Section 3.5.2.3.2.
o 第3.5.2.3.2节定义了“记录邻接状态”操作。
o The "Verify Adjacency State" operation consists of verifying that the contents of the incoming SYNACK message match the adjacency state values previously recorded.
o “验证邻接状态”操作包括验证传入SYNACK消息的内容是否与先前记录的邻接状态值匹配。
o The procedure "Reset the link" is defined as:
o “重置链接”程序定义为：
1. Generate a new instance number for the link.
1. 为链接生成新的实例号。
2. Delete the peer verifier (set to zero the values of Sender Instance, Sender Port, and Sender Name previously stored by the "Record Adjacency State" operation).
2. 删除对等验证器（将“记录邻接状态”操作之前存储的发送方实例、发送方端口和发送方名称的值设置为零）。
3. Send a SYN message (Section 3.5.2.3.1).
3. 发送SYN消息（第3.5.2.3.1节）。
4. Enter the SYNSENT state.
4. 输入SYNSENT状态。
o The state tables use the following Boolean terms and operators.
o 状态表使用以下布尔术语和运算符。
A. The Sender Instance in the incoming message matches the value stored from a previous message by the "Record Adjacency State" operation.
A.传入消息中的发送方实例与通过“记录邻接状态”操作从先前消息中存储的值相匹配。
B. The Sender Instance, Sender Port, Sender Name, and Partition ID fields in the incoming message match the values stored from a previous message by the "Record Adjacency State" operation.
B.传入消息中的发送方实例、发送方端口、发送方名称和分区ID字段与通过“记录邻接状态”操作从以前的消息中存储的值相匹配。
C. The Receiver Instance, Receiver Port, Receiver Name, and Partition ID fields in the incoming message match the values of the Sender Instance, Sender Port, Sender Name, and Partition ID currently sent in outgoing SYN, SYNACK, and ACK messages, except that the NAS always accepts the Partition ID value presented to it in a SYN or SYNACK message.
C.传入消息中的接收方实例、接收方端口、接收方名称和分区ID字段与当前在传出SYN、SYNACK和ACK消息中发送的发送方实例、发送方端口、发送方名称和分区ID的值相匹配，但NAS始终接受在SYN或SYNACK消息中呈现给它的分区ID值。
"&&" Represents the logical AND operation.
“&&”表示逻辑“与”运算。
"||" Represents the logical OR operation.
“| |”表示逻辑OR操作。
"!" Represents the logical negation (NOT) operation.
“！”表示逻辑否定（NOT）操作。
o A timer is required for the periodic generation of SYN, SYNACK, and ACK messages. The value of the timer is negotiated in the Timer field. The period of the timer is unspecified, but a value of 25 seconds is suggested. Note that since ANCP uses a reliable transport protocol, the timer is unlikely to expire in any state other than ESTAB.
o 定期生成SYN、SYNACK和ACK消息需要计时器。计时器的值在计时器字段中协商。未指定计时器的周期，但建议使用25秒的值。请注意，由于ANCP使用可靠的传输协议，因此计时器不太可能在ESTAB以外的任何状态下过期。
There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are:
有两个独立的事件：计时器过期和数据包到达。这些事件的处理规则是：
Timer Expires: Reset Timer
计时器过期：重置计时器
If state = SYNSENT Send SYN
如果state=SYNSENT-Send-SYN
If state = SYNRCVD Send SYNACK
如果状态=SYNRCVD发送SYNACK
If state = ESTAB Send ACK
如果状态=ESTAB发送确认
Packet Arrives:
数据包到达：
If incoming message is an RSTACK:
如果传入消息是RSTACK：
If (A && C && !SYNSENT) Reset the link
如果（A&&C&&！SYNSENT）重置链接
Else discard the message.
否则将丢弃该消息。
If incoming message is a SYN, SYNACK, or ACK:
如果传入消息是SYN、SYNACK或ACK：
Response defined by the following state tables.
由以下状态表定义的响应。
If incoming message is any other ANCP message and state != ESTAB:
如果传入消息是任何其他ANCP消息和状态！=ESTAB：
Discard incoming message.
丢弃传入消息。
If state = SYNSENT Send SYN (Note 1)
如果state=synsen-Send-SYN（注1）
If state = SYNRCVD Send SYNACK (Note 1)
如果状态=SYNRCVD发送SYNACK（注1）
Note 1: No more than two SYN or SYNACK messages should be sent within any time period of length defined by the timer.
注1：在计时器定义的任何时间段内，发送的SYN或SYNACK消息不得超过两条。
o State synchronization across a link is considered to be achieved when the protocol reaches the ESTAB state. All ANCP messages, other than adjacency protocol messages, that are received before synchronization is achieved will be discarded.
o 当协议达到ESTAB状态时，链路上的状态同步被认为是实现的。在实现同步之前接收到的所有ANCP消息（邻接协议消息除外）将被丢弃。
State: SYNSENT
国家：SYNSENT
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+-----------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+===================================================================+
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+-----------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+===================================================================+
State: SYNRCVD
州：SYNRCVD
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYNACK && C | Verify Adjacency State; Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| SYN | Record Adjacency State; Send SYNACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && !(B && C)| Send RSTACK | SYNRCVD |
+===================================================================+
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYNACK && C | Verify Adjacency State; Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| SYN | Record Adjacency State; Send SYNACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && !(B && C)| Send RSTACK | SYNRCVD |
+===================================================================+
State: ESTAB
州：ESTAB
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYN || SYNACK | Send ACK (Note 2) | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (Note 3) | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && !(B && C)| Send RSTACK | ESTAB |
+===================================================================+
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYN || SYNACK | Send ACK (Note 2) | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (Note 3) | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && !(B && C)| Send RSTACK | ESTAB |
+===================================================================+
Note 2: No more than two ACKs should be sent within any time period of length defined by the timer. Thus, one ACK MUST be sent every time the timer expires. In addition, one further ACK may be sent between timer expirations if the incoming message is a SYN or SYNACK. This additional ACK allows the adjacency protocol to reach synchronization more quickly.
注2：在计时器定义的任何时间段内，发送的ACK不得超过两个。因此，每次计时器过期时必须发送一个ACK。此外，如果传入消息是SYN或SYNACK，则可以在计时器到期之间发送另一个ACK。这个额外的ACK允许邻接协议更快地达到同步。
Note 3: No more than one ACK should be sent within any time period of length defined by the timer.
注3：在计时器定义的任何时间段内，不应发送超过一个ACK。
The SYN message is sent in accordance with the state tables just described. The sender sets the individual fields as follows:
SYN消息是根据刚才描述的状态表发送的。发件人按如下方式设置各个字段：
Version: SHOULD be set to the highest version of ANCP that the sender supports.
版本：应设置为发送方支持的ANCP的最高版本。
Message Type: MUST be set to 10.
消息类型：必须设置为10。
Timer: SHOULD be set to the value configured in the AN or NAS sending the message.
定时器：应设置为发送消息的AN或NAS中配置的值。
M Flag: MUST be set to 1 by the NAS, and 0 by the AN.
M标志：NAS必须将其设置为1，AN必须将其设置为0。
Code: MUST be set to 1 (SYN).
代码：必须设置为1（SYN）。
Sender Name: Set as described in Section 3.5.1.
发送方名称：如第3.5.1节所述设置。
Receiver Name: SHOULD be set to 0.
接收方名称：应设置为0。
Sender Port: Set as described in Section 3.5.1.
发送方端口：如第3.5.1节所述设置。
Receiver Port: SHOULD be set to 0.
接收器端口：应设置为0。
PType: Set according to the following rules:
p类型：根据以下规则设置：
Settings by the AN:
由AN进行的设置：
0 - the AN does not support partitions;
0-AN不支持分区；
2 - the value of Partition ID contained in this message is assigned to the current partition.
2-将此消息中包含的分区ID的值分配给当前分区。
Settings by the NAS:
NAS的设置：
0 - the NAS leaves the decision on partitioning to the AN (RECOMMENDED setting);
0-NAS将分区决定权留给AN（推荐设置）；
1 - the NAS requests that the AN use the value of Partition ID contained in this message for the current partition. The NAS MAY use this setting even if it has already received a SYN message from the AN, provided that the AN has indicated support for partitions. The NAS MUST be prepared to use whatever value it receives in a subsequent SYN or SYNACK message, even if this differs from the requested value.
1-NAS请求AN将此消息中包含的分区ID值用于当前分区。NAS可以使用此设置，即使它已从AN接收到SYN消息，但前提是AN已指示支持分区。NAS必须准备好使用其在后续SYN或SYNACK消息中接收到的任何值，即使这与请求的值不同。
P Flag: Set to the mode of adjacency setup (new adjacency vs. recovered adjacency) requested by the sender. Warning: setting P Flag=1 runs the risk of state mismatch because ANCP does not provide the means for the NAS to audit the current state of the AN.
P标志：设置为发送方请求的邻接设置模式（新邻接与恢复邻接）。警告：设置P Flag=1有状态不匹配的风险，因为ANCP不提供NAS审核AN当前状态的方法。
Sender Instance: Set as described in Section 3.5.1.
发送方实例：如第3.5.1节所述进行设置。
Partition ID: MUST be set to 0 if PType=0; otherwise, set to the assigned or requested partition identifier value.
分区ID:如果PType=0，则必须设置为0；否则，设置为分配的或请求的分区标识符值。
Receiver Instance: SHOULD be set to 0.
接收器实例：应设置为0。
# of Caps: MUST be set to the number of Capability fields that follow.
#CAP的数量：必须设置为后面的功能字段的数量。
Total Length: MUST be set to the total number of bytes in the Capability fields that follow.
Total Length:必须设置为后面的功能字段中的总字节数。
Capability Fields: One Capability field MUST be present for each ANCP capability for which the sender wishes to advertise support.
能力字段：发送方希望公布支持的每个ANCP能力必须有一个能力字段。
Upon receiving a validly formed SYN message, the receiver first checks the value of the Version field. If this value is not within the range of ANCP versions that the receiver supports, the message MUST be silently ignored. Similarly, the message is silently ignored if the M flag is 0 and the receiver is an AN or if the M flag is 1 and the receiver is a NAS. If these checks are passed and the receiver is in ESTAB state, it returns an ACK (as indicated by the ESTAB state table in Section 3.5.2.2.1). The contents of the ACK MUST reflect the adjacency state as previously recorded by the receiver.
接收到有效格式的SYN消息后，接收方首先检查版本字段的值。如果该值不在接收器支持的ANCP版本范围内，则必须以静默方式忽略该消息。类似地，如果M标志为0且接收方为an，或者如果M标志为1且接收方为NAS，则消息将被静默忽略。如果这些检查通过且接收器处于ESTAB状态，则返回ACK（如第3.5.2.2.1节中的ESTAB状态表所示）。ACK的内容必须反映接收机先前记录的邻接状态。
Otherwise, the receiver MUST perform the "Record Adjacency State" operation by recording the following fields:
否则，接收器必须通过记录以下字段来执行“记录邻接状态”操作：
Version: The supported Version value received in the SYN message. This value MUST be used for all subsequent ANCP messages sent during the life of the adjacency.
版本：在SYN消息中接收到的支持的版本值。该值必须用于邻接生命周期内发送的所有后续ANCP消息。
Timer: The larger of the Timer value received in the SYN message and the value with which the receiver is configured.
定时器：SYN消息中接收到的定时器值与接收机配置值中的较大值。
Sender Name: The value of the Sender Name field in the SYN message just received.
Sender Name：刚刚收到的SYN消息中Sender Name字段的值。
Receiver Name: The value used by the receiver in the Sender Name field of SYN, SYNACK, and ACK messages it sends in this adjacency.
接收方名称：接收方在此邻接中发送的SYN、SYNACK和ACK消息的发送方名称字段中使用的值。
Sender Port: The value of the Sender Port field in the SYN message just received.
Sender Port：刚刚收到的SYN消息中Sender Port字段的值。
Receiver Port: The value used by the receiver in the Sender Port field of SYN, SYNACK, and ACK messages it sends in this adjacency.
接收方端口：接收方在此邻接中发送的SYN、SYNACK和ACK消息的发送方端口字段中使用的值。
Sender Instance: The value of the Sender Instance field in the SYN message just received.
Sender Instance：刚刚收到的SYN消息中Sender Instance字段的值。
P Flag: The lesser of the value determined by local policy and the value received in the SYN message. That is, preference is given to "0 - New adjacency" if there is a conflict.
P标志：本地策略确定的值与SYN消息中接收到的值中的较小值。也就是说，如果存在冲突，则优先选择“0-新邻接”。
Partition ID: If the SYN receiver is the AN, this is set to 0 if the AN does not support partitions or to the non-zero value of the partition identifier it chooses to assign otherwise. If the SYN receiver is the NAS, this is set to the value of the Partition ID field copied from the SYN.
分区ID：如果SYN接收器是AN，如果AN不支持分区，则将其设置为0，或者设置为它选择分配的分区标识符的非零值。如果SYN接收器是NAS，则设置为从SYN复制的分区ID字段的值。
Receiver Instance: The value used by the receiver in the Sender Instance field of SYN, SYNACK, and ACK messages it sends in this adjacency.
Receiver Instance：接收方在此邻接中发送的SYN、SYNACK和ACK消息的Sender Instance字段中使用的值。
Capabilities: The set of ANCP capabilities that were offered in the SYN and are supported by the receiver.
能力：在SYN中提供并由接收器支持的ANCP能力集。
The SYNACK is sent in response to a successfully received SYN message, as indicated by the state tables. The Version, Timer, P Flag, and Partition ID fields MUST be populated with the values recorded as part of adjacency state. The # of Caps, Total Length, and Capability fields MUST also be populated in accordance with the Capabilities recorded as part of adjacency state. The remaining fields of the SYNACK message MUST be populated as follows:
SYNACK是响应成功接收的SYN消息而发送的，如状态表所示。版本、计时器、P标志和分区ID字段必须填充作为邻接状态一部分记录的值。CAP的#、总长度和能力字段也必须根据作为邻接状态一部分记录的能力进行填充。SYNACK消息的其余字段必须按如下方式填充：
Message Type: MUST be 10.
消息类型：必须为10。
M flag: MUST be set to 0.
M标志：必须设置为0。
Code: MUST be 2 (SYNACK).
代码：必须为2（SYNACK）。
PType: MUST be 0 if the Partition ID value is 0 or 2 if the Partition ID value is non-zero.
p类型：如果分区ID值为0，则必须为0；如果分区ID值非零，则必须为2。
Sender Name: MUST be set to the Receiver Name value recorded as part of adjacency state.
发送方名称：必须设置为作为邻接状态的一部分记录的接收方名称值。
Receiver Name: MUST be set to the Sender Name value recorded as part of adjacency state.
接收方名称：必须设置为作为邻接状态的一部分记录的发送方名称值。
Sender Port: MUST be set to the Receiver Port value recorded as part of adjacency state.
发送方端口：必须设置为作为邻接状态的一部分记录的接收方端口值。
Receiver Port: MUST be set to the Sender Port value recorded as part of adjacency state.
接收方端口：必须设置为作为邻接状态的一部分记录的发送方端口值。
Sender Instance: MUST be set to the Receiver Instance value recorded as part of adjacency state.
发送方实例：必须设置为作为邻接状态的一部分记录的接收方实例值。
Receiver Instance: MUST be set to the Sender Instance value recorded as part of adjacency state.
Receiver Instance:必须设置为作为邻接状态的一部分记录的发送方实例值。
If the set of capabilities recorded in the adjacency state is empty, then after sending the SYNACK the sender MUST raise an alarm to management, halt the adjacency procedure, and tear down the TCP session if it is not being used by another adjacency. The sender MAY also terminate the IPsec security association if no other adjacency is using it.
如果邻接状态中记录的功能集为空，则在发送SYNACK后，发送方必须向管理层发出警报，停止邻接过程，如果TCP会话未被其他邻接使用，则必须中断TCP会话。如果没有其他邻接使用IPsec安全关联，发送方也可以终止该关联。
As indicated by the state tables, the receiver of a SYNACK first checks that the Receiver Name, Receiver Port, and Receiver Instance values match the Sender Name, Sender Port, and Sender Instance values it sent in SYN message that is being acknowledged. The AN also checks that the PType and Partition ID match. If any of these checks fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1.
如状态表所示，SYNACK的接收方首先检查接收方名称、接收方端口和接收方实例值是否与它在正在确认的SYN消息中发送的发送方名称、发送方端口和发送方实例值匹配。AN还检查PType和分区ID是否匹配。如果这些检查中的任何一项失败，接收器将发送一个RSTACK，如第3.5.2.6.1节所述。
The receiver next checks whether the set of capabilities provided in the SYNACK is empty. If so, the receiver MUST raise an alarm to management and halt the adjacency procedure.
接收机接下来检查SYNACK中提供的功能集是否为空。如果是这样，接收器必须向管理层发出警报，并停止邻接程序。
Assuming that the SYNACK passes these checks, two cases arise. The first possibility is that the receiver has already recorded adjacency state. This will occur if the SYNACK is received while the receiver is in SYNRCVD state. In this case, the Version, Timer, Sender Name, Sender Port, Sender Instance, P Flag, and capability-related fields in the SYNACK MUST match those recorded as part of adjacency state. If a mismatch is detected, the receiver sends an RSTACK. This is the "Verify Adjacency State" procedure shown in the SYNRCVD state table.
假设SYNACK通过了这些检查，则会出现两种情况。第一种可能性是接收器已经记录了邻接状态。如果在接收器处于SYNRCVD状态时接收到SYNACK，则会发生这种情况。在这种情况下，SYNACK中的版本、计时器、发送方名称、发送方端口、发送方实例、P标志和功能相关字段必须与作为邻接状态一部分记录的字段相匹配。如果检测到不匹配，接收器将发送RSTACK。这是SYNRCVD状态表中显示的“验证邻接状态”程序。
If, on the other hand, the SYNACK is received while the receiver is in SYNSENT state, the receiver MUST record session state as described in Section 3.5.2.3.2.
另一方面，如果在接收机处于SYNSET状态时接收到SYNACK，则接收机必须按照第3.5.2.3.2节所述记录会话状态。
In either case, if the receiver is the NAS, it MUST accept the Partition ID value provided in the SYNACK, updating its recorded adjacency state if necessary.
在任何一种情况下，如果接收器是NAS，它必须接受SYNACK中提供的分区ID值，并在必要时更新其记录的邻接状态。
As indicated by the state tables, the ACK message is sent in a number of different circumstances. The main-line usages are as a response to SYNACK, leading directly to the ESTAB state, and as a periodic test of liveness once the ESTAB state has been reached.
如状态表所示，ACK消息在许多不同的情况下发送。主线的使用是作为对SYNACK的响应，直接导致ESTAB状态，并且作为达到ESTAB状态后的活动性定期测试。
The sender MUST populate the ACK from recorded adjacency state, exactly as described in Section 3.5.2.4.1. The only difference is that Code MUST be set to 3 (ACK).
发送方必须按照第3.5.2.4.1节中的描述，从记录的邻接状态填充ACK。唯一的区别是代码必须设置为3（ACK）。
The required actions by the receiver are specified by the state tables. In addition to the checks B and C, the receiver SHOULD verify that the remaining contents of the ACK match the recorded adjacency state at the receiver. If that check fails, the receiver MUST send an RSTACK as described in Section 3.5.2.6.1.
接收方所需的操作由状态表指定。除了检查B和C之外，接收器还应验证ACK的剩余内容是否与接收器处记录的邻接状态相匹配。如果该检查失败，接收器必须发送第3.5.2.6.1节所述的RSTACK。
Once the adjacency has been established, either peer can initiate the ACK exchange that tests for liveness. To meet the restrictions on ACK frequency laid down in the notes to the state tables, it is desirable that only one such exchange occur during any one interval. Hence, if a peer receives an ACK when in ESTAB state, it MUST reply to that ACK as directed by the state tables, but SHOULD NOT initiate another ACK exchange in the same interval. To meet this objective, the receiver MUST reset its timer when it receives an ACK while in ESTAB state.
一旦建立了邻接关系，任何一个对等方都可以启动测试活动性的ACK交换。为了满足状态表注释中规定的对ACK频率的限制，希望在任何一个间隔期间仅发生一次这样的交换。因此，如果对等方在处于ESTAB状态时收到ACK，则它必须按照状态表的指示回复该ACK，但不应在同一时间间隔内启动另一个ACK交换。为了达到这一目标，接收器在ESTAB状态下收到ACK时必须重置其计时器。
It is, of course, possible that two exchanges happen because of race conditions.
当然，由于种族条件的原因，有可能发生两次交换。
The RSTACK is sent in response to various error conditions as indicated by the state tables. In general, it leads to a restart of adjacency negotiations (although this takes a few steps when the original sender of the RSTACK is in ESTAB state).
发送RSTACK以响应状态表指示的各种错误条件。通常，它会导致邻接协商的重新开始（尽管当RSTACK的原始发送方处于ESTAB状态时，这会采取一些步骤）。
As indicated in Section 3.5.1, the Sender Name, Port, and Instance fields in the RSTACK MUST be copied from the Receiver, Name, Port, and Instance fields in the message that caused the RSTACK to be sent. Similarly, the Receiver identifier fields in the RSTACK MUST be copied from the corresponding Sender identifier fields in the message that triggered the RSTACK.
如第3.5.1节所述，RSTACK中的发送方名称、端口和实例字段必须从导致发送RSTACK的消息中的接收方、名称、端口和实例字段复制。同样，RSTACK中的接收方标识符字段必须从触发RSTACK的消息中相应的发送方标识符字段复制。
If the sender has recorded adjacency state, the Version, Timer, PType, P Flag, Partition ID, and capability-related fields SHOULD be set based on the recorded adjacency state. Otherwise, they SHOULD be the same as the sender would send in a SYN message. The Message Type MUST be 10, the M flag MUST be 0, and Code MUST be 4 (RSTACK).
如果发送方记录了邻接状态，则应根据记录的邻接状态设置版本、计时器、PType、P标志、分区ID和功能相关字段。否则，它们应该与发送方在SYN消息中发送的相同。消息类型必须为10，M标志必须为0，代码必须为4（RSTACK）。
The receiver of an RSTACK MAY attempt to diagnose the problem that caused the RSTACK to be generated by comparing its own adjacency state with the contents of the RSTACK. However, the primary purpose of the RSTACK is to trigger action as prescribed by Section 3.5.2.2.
RSTACK的接收器可通过将其自身的邻接状态与RSTACK的内容进行比较，尝试诊断导致生成RSTACK的问题。然而，RSTACK的主要目的是触发第3.5.2.2节规定的行动。
Loss of synchronization MAY be declared if after synchronization is achieved:
如果在实现同步后：
o no valid ANCP messages are received in any period of time in excess of three times the value of the Timer field negotiated in the adjacency protocol messages, or
o 在任何超过邻接协议消息中协商的计时器字段值三倍的时间段内，均未收到有效的ANCP消息，或
o a mismatch in adjacency state is detected.
o 检测到邻接状态不匹配。
In either case, the peer detecting the condition MUST send an RSTACK to the other peer, as directed in Section 3.5.2.6.1, in order to initiate resynchronization.
在任何一种情况下，检测到该情况的对等方必须按照第3.5.2.6.1节的指示向另一对等方发送RSTACK，以便启动重新同步。
While re-establishing synchronization with a controller, a switch SHOULD maintain its connection state, deferring the decision about resetting the state until after synchronization is re-established.
在与控制器重新建立同步时，交换机应保持其连接状态，将重置状态的决定推迟到重新建立同步之后。
Once synchronization is re-established, the decision about resetting the connection state SHOULD be made based on the negotiated value of the P Flag.
一旦重新建立同步，应根据P标志的协商值来决定重置连接状态。
This section describes the general format of ANCP messages other than the adjacency messages. See Figure 7.
本节介绍ANCP消息的一般格式，而不是相邻消息。参见图7。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ANCP General Message Format
图7:ANCP通用消息格式
A complete explanation of the ANCP general message header fields follows.
ANCP通用消息头字段的完整说明如下。
This field carries the version of ANCP that was agreed upon for the session during adjacency negotiation.
此字段包含邻接谈判期间为会话商定的ANCP版本。
This field indicates the ANCP message type. Message type values are registered in an IANA registry.
此字段表示ANCP消息类型。消息类型值在IANA注册表中注册。
In request messages, the Result field indicates the circumstances under which a response is required. ANCP specifies what Result value each request message type should have. In responses, the Result field indicates either Success (0x3) or Failure (0x4), as the case may be.
在请求消息中，结果字段指示需要响应的情况。ANCP指定每个请求消息类型应具有的结果值。在响应中，结果字段根据具体情况指示成功（0x3）或失败（0x4）。
Ignore: Res = 0x0 - Treat this field as a "no operation" and follow the response procedures specified for the received message type.
忽略：Res=0x0-将此字段视为“无操作”，并遵循为收到的消息类型指定的响应过程。
Nack: Res = 0x1 - Result value indicating that a response is expected to the request only in cases of failure caused during the processing of the message contents or of the contained directive(s).
Nack:Res=0x1-结果值，表示只有在处理消息内容或包含的指令过程中出现故障时，才会对请求进行响应。
AckAll: Res = 0x2 - Result value indicating that a response to the message is requested in all cases.
AckAll:Res=0x2-结果值，指示在所有情况下都请求对消息的响应。
Success: Res = 0x3 - Result value indicating that this is a response and that the request was executed successfully. The Result Code field for a successful result is typically 0, but it MAY take on other values as specified for particular message types.
Success:Res=0x3-结果值，指示这是一个响应并且请求已成功执行。成功结果的结果代码字段通常为0，但它可能采用为特定消息类型指定的其他值。
Failure: Res = 0x4 - Result value indicating that this is a response and that the request was not executed successfully. The receiver of the response SHOULD take further action as indicated by the Result Code value and any diagnostic data contained in a Status-Info TLV included in the response.
失败：Res=0x4-结果值，指示这是一个响应，并且请求未成功执行。响应接收器应采取响应中包含的结果代码值和状态信息TLV中包含的任何诊断数据指示的进一步措施。
This field gives further information concerning the result in a response message. It is mostly used to pass an error code in a failure response, but it can also be used to give further information in a success response message or an event message. In a request message, the Result Code field is not used and MUST be set to 0x0 (No result).
此字段提供有关响应消息中结果的更多信息。它主要用于在故障响应中传递错误代码，但也可用于在成功响应消息或事件消息中提供更多信息。在请求消息中，不使用结果代码字段，必须将其设置为0x0（无结果）。
A number of Result Code values are specified below. Specification of additional Result Code values in extensions or updates to this document MUST include the following information:
下面指定了许多结果代码值。本文档扩展或更新中的其他结果代码值的规范必须包括以下信息：
o Result Code value;
o 结果代码值；
o One-line description;
o 一行描述；
o Where condition detected (control application or ANCP agent);
o 如果检测到条件（控制应用程序或ANCP代理）；
o Further description (if any);
o 进一步说明（如有）；
o Required additional information in the response message;
o 响应消息中所需的附加信息；
o Target (control application or ANCP agent at the peer that sent the original request);
o 目标（发送原始请求的对等方的控制应用程序或ANCP代理）；
o Action RECOMMENDED for the receiving ANCP agent.
o 建议接收ANCP代理的行动。
In addition to any suggested action in the text that follows, a count of the number of times a given non-zero Result Code value was received SHOULD be provided for management. Where an action includes the re-sending of a request, a given request SHOULD NOT be re-sent more than once.
除了下文中提出的任何建议措施外，还应为管理层提供收到给定非零结果代码值的次数计数。如果操作包括重新发送请求，则给定的请求不应重新发送一次以上。
This document specifies the following Result Code values.
本文档指定以下结果代码值。
Result Code value: 0x2
结果代码值：0x2
* One-line description: Invalid request message
* 单行说明：无效的请求消息
* Where condition detected: ANCP agent
* 检测到的情况：ANCP代理
* Further description: The request was a properly formed message that violates the protocol through its timing or direction of transmission. The most likely reason for this outcome in the field will be a race condition.
* 进一步说明：该请求是一条格式正确的消息，在传输的时间或方向上违反了协议。比赛结果最可能的原因是比赛条件。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 响应消息中需要的其他信息：无，如果响应消息与请求的类型相同。如第4.2节所述，如果响应消息为一般响应消息。
* Target: ANCP agent at the peer that sent the original request
* 目标：发送原始请求的对等方的ANCP代理
* Action RECOMMENDED for the receiving ANCP agent: The original request MAY be re-sent once only after a short delay. Inform the control application with appropriate identification of the failed transaction if the second attempt fails or no second attempt is made.
* 建议接收ANCP代理采取的措施：只有在短暂延迟后，才能重新发送一次原始请求。如果第二次尝试失败或未进行第二次尝试，则通知控制应用程序适当标识失败的事务。
Result Code value: 0x6
结果代码值：0x6
* One-line description: One or more of the specified ports are down
* 单行说明：一个或多个指定端口关闭
* Where condition detected: Control application
* 检测到条件的位置：控制应用程序
* Further description (if any): This Result Code value indicates a state mismatch between the NAS and AN control applications, possibly due to a race condition.
* 进一步说明（如有）：此结果代码值表示NAS和控制应用程序之间的状态不匹配，可能是由于竞争条件造成的。
* Required additional information in the response message: If the request identified multiple access lines or the response is a Generic Response message, then the response MUST contain a Status-Info TLV encapsulating TLV(s) containing the line identifier(s) of the access lines that are not operational.
* 响应消息中所需的附加信息：如果请求标识了多条接入线或响应是一般响应消息，则响应必须包含一个状态信息TLV，该TLV封装了TLV，其中包含不可操作的接入线的线路标识符。
* Target: Control application at the peer that sent the original request
* 目标：在发送原始请求的对等方控制应用程序
* Action RECOMMENDED for the receiving ANCP agent: Indicate the error and forward the line identifier(s) to the control application.
* 建议接收ANCP代理的操作：指示错误并将线路标识符转发给控制应用程序。
Result Code value: 0x13
结果代码值：0x13
* One-line description: Out of resources
* 单行说明：资源不足
* Where condition detected: ANCP protocol layer or control application
* 检测到的条件：ANCP协议层或控制应用程序
* Further description (e.g., memory exhausted): This Result Code value MUST be reported only by the AN, and indicates a condition that is probably unrelated to specific access lines (although it may be related to the specific request).
* 进一步说明（例如，内存耗尽）：此结果代码值必须仅由AN报告，并指示可能与特定访问线无关的情况（尽管可能与特定请求相关）。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 响应消息中需要的其他信息：无，如果响应消息与请求的类型相同。如第4.2节所述，如果响应消息为一般响应消息。
* Target: ANCP agent at the peer that sent the original request
* 目标：发送原始请求的对等方的ANCP代理
* Action RECOMMENDED for the receiving ANCP agent: If the NAS receives this Result Code value from multiple requests for the same AN in a short interval, it SHOULD reduce the rate at which it sends requests in proportion to the rate at which requests are failing with Result Code = 19. It MAY retry individual requests. If only a specific request is failing with Result Code = 19, the ANCP agent in the NAS MAY request the control application to decompose the request into simpler components if this is possible.
* 建议接收ANCP代理采取的措施：如果NAS在短时间间隔内从同一AN的多个请求中接收到此结果代码值，则应将其发送请求的速率与结果代码为19的请求失败的速率成比例降低。它可能会重试个别请求。如果只有一个特定请求失败，且结果代码=19，则NAS中的ANCP代理可能会请求控制应用程序将请求分解为更简单的组件（如果可能）。
Result Code value: 0x51
结果代码值：0x51
* One-line description: Request message type not implemented
* 单行说明：未实现请求消息类型
* Where condition detected: ANCP agent
* 检测到的情况：ANCP代理
* Further description: This could indicate a mismatch in protocol version or capability state. It is also possible that support of a specific message is optional within some ANCP capability.
* 进一步说明：这可能表示协议版本或功能状态不匹配。在某些ANCP功能中，对特定消息的支持也是可选的。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 响应消息中需要的其他信息：无，如果响应消息与请求的类型相同。如第4.2节所述，如果响应消息为一般响应消息。
* Target: ANCP agent at the peer that sent the original request
* 目标：发送原始请求的对等方的ANCP代理
* Action RECOMMENDED for the receiving ANCP agent: If the receiver of this Result Code value expects that support of the message type concerned is mandatory according to the capabilities negotiated for the session, it MAY re-send the message in case the message was corrupted in transit the first time. If that fails, and use of the message type cannot be avoided, the ANCP agent MAY reset the adjacency by sending an RSTACK adjacency message as described in Section 3.5.2.6.1, where Sender and Receiver Name, Port, and Instance are taken from recorded adjacency state. If a reset does not eliminate the problem, the receiving ANCP agent SHOULD raise an alarm to management and then cease to operate.
* 建议接收ANCP代理采取的措施：如果此结果代码值的接收者期望根据会话协商的能力，必须支持相关的消息类型，则如果消息在传输过程中第一次损坏，它可能会重新发送消息。如果失败，并且无法避免使用消息类型，ANCP代理可通过发送第3.5.2.6.1节所述的RSTACK邻接消息重置邻接，其中发送方和接收方名称、端口和实例取自记录的邻接状态。如果重置不能消除问题，接收ANCP代理应向管理层发出警报，然后停止运行。
Result Code value: 0x53
结果代码值：0x53
* One-line description: Malformed message
* 单行说明：格式不正确的消息
* Where condition detected: ANCP agent
* 检测到的情况：ANCP代理
* Further description: This could be the result of corruption in transit, or an error in implementation at one end or the other.
* 进一步说明：这可能是由于传输过程中的损坏，或一端或另一端的执行错误造成的。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 响应消息中需要的其他信息：无，如果响应消息与请求的类型相同。如第4.2节所述，如果响应消息为一般响应消息。
* Target: ANCP agent at the peer that sent the original request
* 目标：发送原始请求的对等方的ANCP代理
* Action RECOMMENDED for the receiving ANCP agent: The request SHOULD be re-sent once to eliminate the possibility of in-transit corruption.
* 建议接收ANCP代理采取的措施：请求应重新发送一次，以消除在途腐败的可能性。
Result Code value: 0x54
结果代码值：0x54
* One-line description: Mandatory TLV missing
* 单行说明：缺少强制TLV
* Where condition detected: ANCP agent
* 检测到的情况：ANCP代理
* Further description: None
* 进一步说明：无
* Required additional information in the response message: The response message MUST contain a Status-Info message that encapsulates an instance of each missing mandatory TLV, where the length is set to zero and the value field is empty (i.e., only the 4-byte TLV header is present).
* 响应消息中需要的其他信息：响应消息必须包含一条状态信息消息，该消息封装了每个缺失的强制TLV的实例，其中长度设置为零，值字段为空（即，仅存在4字节TLV标头）。
* Target: ANCP agent at the peer that sent the original request
* 目标：发送原始请求的对等方的ANCP代理
* Action RECOMMENDED for the receiving ANCP agent: Re-send the message with the missing TLV(s), if possible. Otherwise, report the error to the control application with an indication of the missing information required to construct the missing TLV(s).
* 建议接收ANCP代理采取的措施：如有可能，重新发送带有缺失TLV的消息。否则，向控制应用程序报告错误，并指出构建缺失TLV所需的缺失信息。
Result Code value: 0x55
结果代码值：0x55
* One-line description: Invalid TLV contents
* 单行说明：TLV内容无效
* Where condition detected: ANCP agent
* 检测到的情况：ANCP代理
* Further description: The contents of one or more TLVs in the request do not match the specifications provided for the those TLVs.
* 进一步说明：请求中一个或多个TLV的内容与为这些TLV提供的规范不匹配。
* Required additional information in the response message: The response MUST contain a Status-Info TLV encapsulating the erroneous TLVs copied from the original request.
* 响应消息中需要的其他信息：响应必须包含一个状态信息TLV，封装从原始请求复制的错误TLV。
* Target: ANCP agent at the peer that sent the original request
* 目标：发送原始请求的对等方的ANCP代理
* Action RECOMMENDED for the receiving ANCP agent: Correct the error and re-send the request, if possible. Otherwise, report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
* 建议接收ANCP代理的操作：纠正错误并重新发送请求（如果可能）。否则，向控制应用程序报告错误，并指示与无效TLV相关的错误信息。
Result Code value: 0x500
结果代码值：0x500
* One-line description: One or more of the specified ports do not exist
* 单行说明：一个或多个指定端口不存在
* Where condition detected: Control application
* 检测到条件的位置：控制应用程序
* Further description (if any): This may indicate a configuration mismatch between the AN and the NAS or Authentication, Authorization, and Accounting (AAA).
* 进一步说明（如果有）：这可能表示AN和NAS之间的配置不匹配，或者身份验证、授权和记帐（AAA）不匹配。
* Required additional information in the response message: If the request identified multiple access lines or the response is a Generic Response message, then the response MUST contain a Status-Info TLV encapsulating TLV(s) containing the rejected line identifier(s).
* 响应消息中所需的附加信息：如果请求标识了多个访问线路或响应是一般响应消息，则响应必须包含一个状态信息TLV，该TLV封装了包含被拒绝线路标识符的TLV。
* Target: Control application at the peer that sent the original request
* 目标：在发送原始请求的对等方控制应用程序
* Action RECOMMENDED for the receiving ANCP agent: Indicate the error and forward the line identifiers to the control application.
* 建议接收ANCP代理的操作：指示错误并将线路标识符转发给控制应用程序。
The Partition ID field MUST contain the value that was negotiated for Partition ID during the adjacency procedure as described above.
分区ID字段必须包含在如上所述的邻接过程中为分区ID协商的值。
The Transaction ID is set by the sender of a request message to associate a response message with the original request message. Unless otherwise specified for a given message type, the Transaction ID in request messages MUST be set to a value in the range (1, 2^24 - 1). When used in this manner, the Transaction ID sequencing MUST be maintained independently for each message type within each ANCP adjacency. Furthermore, it SHOULD be incremented by 1 for each new message of the given type, cycling back to 1 after running the full range. For event messages, the Transaction ID SHOULD be set to zero.
事务ID由请求消息的发送者设置，以将响应消息与原始请求消息相关联。除非为给定的消息类型另行指定，否则请求消息中的事务ID必须设置为范围（1，2^24-1）内的值。以这种方式使用时，必须为每个ANCP邻接中的每个消息类型独立维护事务ID序列。此外，对于给定类型的每个新消息，它应该增加1，在运行全范围后循环回1。对于事件消息，事务ID应设置为零。
Unless otherwise specified, the default behavior for all ANCP responses is that the value of the Transaction ID MUST be copied from the corresponding request message.
除非另有规定，否则所有ANCP响应的默认行为是必须从相应的请求消息复制事务ID的值。
In GSMPv3, these provide a mechanism for message fragmentation. Because ANCP uses TCP transport, this mechanism is unnecessary. An ANCP agent MUST set the I Flag and subMessage Number fields to 1 to signify "no fragmentation".
在GSMPv3中，它们提供了一种消息分段机制。因为ANCP使用TCP传输，所以这种机制是不必要的。ANCP代理必须将I标志和子消息编号字段设置为1，以表示“无碎片”。
This field MUST be set to the length of the ANCP message in bytes, including its header fields and message body but excluding the 4-byte encapsulating header defined in Section 3.2.
该字段必须设置为ANCP消息的字节长度，包括其标题字段和消息正文，但不包括第3.2节中定义的4字节封装标题。
The detailed contents of the message payload portion of a given ANCP message can vary with the capability in the context of which it is being used. However, the general format consists of zero or more fixed fields, followed by a variable amount of data in the form of Type-Length-Value (TLV) data structures.
给定ANCP消息的消息有效负载部分的详细内容可以随其使用上下文中的能力而变化。但是，通用格式由零个或多个固定字段组成，后跟以类型长度值（TLV）数据结构形式表示的可变数据量。
The general format of a TLV is shown in Figure 8:
TLV的一般格式如图8所示：
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 (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: General TLV Format
图8：通用TLV格式
The fields of a TLV are defined as follows:
TLV的字段定义如下：
Type (16 bits): The TLV Type is an unsigned value identifying the TLV type and nature of its contents. An IANA registry has been established for ANCP TLV Type codes.
类型（16位）：TLV类型是一个无符号值，用于标识TLV类型及其内容的性质。已经为ANCP TLV类型代码建立了IANA注册中心。
Length (16 bits): The number of bytes of data in the Value field of the TLV, excluding any padding required to bring this TLV to a 4-byte word boundary (see "Value" below). If a TLV contains other TLVs, any padding in the contained TLVs MUST be included in the value of Length. Depending on the specification of the TLV, the value of Length can be zero, a constant for all instances of the TLV, or a varying quantity.
长度（16位）：TLV值字段中的数据字节数，不包括将此TLV设置为4字节字边界所需的任何填充（请参阅下面的“值”）。如果TLV包含其他TLV，则包含的TLV中的任何填充都必须包含在长度值中。根据TLV的规格，长度的值可以是零、TLV的所有实例的常数或变化量。
Value (variable): The actual data carried by the TLV, if any. The Value field in each TLV MUST be padded with zeroes as required to align with a 4-byte word boundary. The Value field of a TLV MAY include fixed fields and/or other TLVs.
值（变量）：TLV携带的实际数据（如有）。每个TLV中的值字段必须根据需要用零填充，以与4字节字边界对齐。TLV的值字段可以包括固定字段和/或其他TLV。
Unless otherwise specified, TLVs MAY be added to a message in any order. If the recipient of a message does not understand a particular TLV, it MUST silently ignore it.
除非另有规定，TLV可按任何顺序添加到消息中。如果消息的接收者不理解特定的TLV，它必须默默地忽略它。
A number of TLVs are specified in the remainder of this document.
本文件其余部分规定了许多TLV。
ANCP allows for two messaging constructs to support request/response interaction:
ANCP允许两种消息传递结构来支持请求/响应交互：
a. The same message type is used for both the request message and the response message. The Result and Result Code field settings are used to differentiate between request and response messages.
a. 请求消息和响应消息使用相同的消息类型。结果和结果代码字段设置用于区分请求和响应消息。
b. The request and response messages use two different message types.
b. 请求和响应消息使用两种不同的消息类型。
The first approach is illustrated by the protocol specifications in Section 8.4, the second by specifications in Section 6.4. The purpose of this section is to provide more details about the second approach in order to allow the use of this messaging construct for the development of additional ANCP extensions.
第一种方法由第8.4节中的协议规范说明，第二种方法由第6.4节中的规范说明。本节的目的是提供关于第二种方法的更多详细信息，以便允许使用此消息传递结构来开发额外的ANCP扩展。
As Section 3.6 indicated, all ANCP messages other than adjacency messages share a common header format. When the response message type is different from that of the request, the specification of the request message will typically indicate that the Result field is set to Ignore (0x0) and provide procedures indicating explicitly when the receiver should generate a response and what message type it should use.
如第3.6节所述，除邻接消息外，所有ANCP消息共享一个通用的报头格式。当响应消息类型不同于请求类型时，请求消息的规范通常将指示结果字段设置为忽略（0x0），并提供明确指示接收方何时应生成响应以及应使用何种消息类型的过程。
The Transaction ID field is used to distinguish between multiple request messages of the same type and to associate a response message to a request. Specifications of ANCP messages for applications not requiring response correlation SHOULD indicate that the Transaction ID MUST be set to zero in requests. Applications that require response correlation SHOULD refer to the Transaction ID behavior described in Section 3.6.1.
事务ID字段用于区分相同类型的多个请求消息，并将响应消息与请求关联。对于不需要响应关联的应用程序，ANCP消息的规范应指示在请求中必须将事务ID设置为零。需要响应关联的应用程序应参考第3.6.1节中描述的事务ID行为。
The specification for a response message SHOULD indicate in all cases that the value of the Transaction Identifier MUST be set to that of the corresponding request message. This allows the requester to establish whether or not correlation is needed (by setting a non-zero or zero value for the Transaction ID).
响应消息的规范应指出，在所有情况下，事务标识符的值必须设置为相应请求消息的值。这允许请求者确定是否需要关联（通过为事务ID设置非零值或零值）。
This section defines two messages and a number of TLVs that could be useful in multiple capabilities. In some cases, the content is under-specified, with the intention that particular capabilities spell out the remaining details.
本节定义了两条消息和许多TLV，它们在多个功能中可能很有用。在某些情况下，未对内容进行详细说明，目的是让特定功能详细说明其余细节。
The Provisioning message is sent by the NAS to the AN to provision information of global scope (i.e., not associated with specific access lines) on the AN. The Provisioning message has the format shown in Figure 9. Support of the Provisioning message is OPTIONAL unless the ANCP agent claims support for a capability that requires its use.
配置消息由NAS发送到AN，以在AN上提供全局范围的信息（即，不与特定访问线路关联）。配置消息的格式如图9所示。提供消息的支持是可选的，除非ANCP代理声称支持需要使用它的功能。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of the Provisioning Message
图9：配置消息的格式
The message header field settings given below are REQUIRED in the Provisioning message. The remaining message header fields MUST be set as specified in Section 3.6.1. Which TLVs to carry in the Provisioning message is specified as part of the specification of the capabilities that use that message. The Provisioning message MAY be used to carry data relating to more than one capability at once, assuming that the capabilities concerned can coexist and have all been negotiated during adjacency establishment.
设置消息中需要以下给出的消息头字段设置。其余消息头字段必须按照第3.6.1节的规定进行设置。将在配置消息中携带哪些TLV指定为使用该消息的功能规范的一部分。供应消息可用于一次携带与多个能力相关的数据，假设相关能力可以共存，并且在邻接建立期间已协商所有能力。
Message Type: MUST be set to 93.
消息类型：必须设置为93。
Result: MUST be set to 0x0 (Ignore).
结果：必须设置为0x0（忽略）。
Result Code: MUST be set to zero.
结果代码：必须设置为零。
Transaction ID: MUST be populated with a non-zero value chosen in the manner described in Section 3.6.1.6.
事务ID：必须使用按照第3.6.1.6节所述方式选择的非零值填充。
If the AN can process the message successfully and accept all the provisioning directives contained in it, the AN MUST NOT send any response.
如果AN可以成功处理消息并接受其中包含的所有设置指令，则AN不得发送任何响应。
Unless otherwise specified for a particular capability, if the AN fails to process the message successfully it MUST send a Generic Response message (Section 4.2) indicating failure and providing appropriate diagnostic information.
除非针对特定功能另有规定，否则如果AN未能成功处理消息，则必须发送一条通用响应消息（第4.2节），指示故障并提供适当的诊断信息。
This section defines the Generic Response message. The Generic Response message MAY be specified as the appropriate response to a message defined in an extension to ANCP, instead of a more specific response message. As a general guideline, specification of the Generic Response message as a response is appropriate where no data needs to be returned to the peer other than a result (success or failure), plus, in the case of a failure, a code indicating the reason for failure and a limited amount of diagnostic data. Depending on the particular use case, the Generic Response message MAY be sent by either the NAS or the AN.
本节定义了通用响应消息。通用响应消息可以指定为对ANCP扩展中定义的消息的适当响应，而不是更具体的响应消息。作为一般指南，如果不需要向对等方返回结果（成功或失败）以外的任何数据，并且在发生故障的情况下，加上指示故障原因的代码和有限数量的诊断数据，则将通用响应消息指定为响应是合适的。根据特定的用例，通用响应消息可以由NAS或AN发送。
Support of the Generic Response message, both as sender and as receiver, is REQUIRED for all ANCP agents, regardless of what capabilities they support.
所有ANCP代理都需要作为发送方和接收方支持通用响应消息，无论它们支持什么功能。
The AN or NAS MAY send a Generic Response message indicating a failure condition independently of a specific request before closing the adjacency as a consequence of that failure condition. In this case, the sender MUST set the Transaction ID field in the header and the Message Type field within the Status-Info TLV to zeroes. The receiver MAY record the information contained in the Status-Info TLV for management use.
AN或NAS可在作为故障条件的结果关闭邻接之前，独立于特定请求发送指示故障条件的通用响应消息。在这种情况下，发送方必须将标头中的事务ID字段和状态信息TLV中的消息类型字段设置为零。接收方可记录状态信息TLV中包含的信息以供管理使用。
The format of the Generic Response message is shown in Figure 10.
通用响应消息的格式如图10所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access line identifying TLV(s) |
+ (copied from original request) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV |
~ (Section 4.5) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access line identifying TLV(s) |
+ (copied from original request) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV |
~ (Section 4.5) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this figure.
注：TLV的顺序可能与本图所示不同。
Figure 10: Structure of the Generic Response Message
图10：通用响应消息的结构
This document specifies the following header fields. The remaining fields in the ANCP general message header MUST be set as specified in Section 3.6.1.
此文档指定以下标题字段。ANCP通用消息头中的其余字段必须按照第3.6.1节的规定进行设置。
Message Type: MUST be set to 91.
消息类型：必须设置为91。
Result: MUST be set to 0x3 (Success) or 0x4 (Failure).
结果：必须设置为0x3（成功）或0x4（失败）。
Result Code: MUST be set to zero for success or an appropriate non-zero value for failure.
结果代码：成功必须设置为零，失败必须设置为适当的非零值。
Transaction ID: MUST be copied from the message to which this message is a response.
事务ID：必须从该消息作为响应的消息中复制。
If the original request applied to a specific access line or set of lines, the TLVs identifying the line(s) and possibly the user MUST be copied into the Generic Response message at the top level.
如果原始请求应用于特定的访问线路或线路集，则必须将识别线路（可能还有用户）的TLV复制到顶层的通用响应消息中。
The Status-Info TLV MAY be present in a success response, to provide a warning as defined for a specific request message type. It MUST be present in a failure response. See Section 4.5 for a detailed description of the Status-Info TLV. The actual contents will depend on the request message type this message is responding to and the value of the Result Code field.
状态信息TLV可能出现在成功响应中，以提供针对特定请求消息类型定义的警告。它必须出现在故障响应中。有关状态信息TLV的详细说明，请参见第4.5节。实际内容将取决于此消息响应的请求消息类型和结果代码字段的值。
To prevent an infinite loop of error responses, if the Generic Response message is itself in error, the receiver MUST NOT generate an error response in return.
为了防止错误响应的无限循环，如果通用响应消息本身出错，则接收方不得生成错误响应作为返回。
Type: 0x1000 to 0x1020 depending on the specific content. Only 0x1000 has been assigned in this specification (see below). Support of any specific variant of the Target TLV is OPTIONAL unless the ANCP agent claims support for a capability that requires its use.
类型：0x1000到0x1020，具体取决于具体内容。本规范中仅分配了0x1000（见下文）。对目标TLV的任何特定变体的支持都是可选的，除非ANCP代理声称支持需要其使用的能力。
Description: The Target TLV (0x1000 - 0x1020) is intended to be a general means to represent different types of objects.
描述：目标TLV（0x1000-0x1020）旨在作为表示不同类型对象的通用方法。
Length: Variable, depending on the specific object type.
长度：变量，取决于特定的对象类型。
Value: Target information as defined for each object type. The Value field MAY consist of sub-TLVs.
值：为每个对象类型定义的目标信息。值字段可能由子TLV组成。
TLV Type 0x1000 is assigned to a variant of the Target TLV representing a single access line and encapsulating one or more sub-TLVs identifying the target. Figure 11 is an example illustrating the TLV format for a single port identified by an Access-Loop-Circuit-ID TLV (0x0001) (Section 5.1.2.1).
TLV类型0x1000分配给目标TLV的一个变体，该变体表示一条接入线，并封装一个或多个子TLV以识别目标。图11是一个示例，说明了由接入回路电路ID TLV（0x0001）标识的单个端口的TLV格式（第5.1.2.1节）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example of Target TLV for Single Access Line
图11：单个接入线的目标TLV示例
Type: 0x0011
类型：0x0011
Description: The Command TLV (0x0011) is intended to be a general means of encapsulating one or more command directives in a TLV-oriented message. The semantics of the command can be specified for each message type using it. That is, the specification of
说明：命令TLV（0x0011）是将一个或多个命令指令封装在面向TLV的消息中的通用方法。可以使用命令为每个消息类型指定命令的语义。也就是说，规范
each message type that can carry the Command TLV is expected to define the meaning of the content of the payload, although re-use of specifications is, of course, permissible when appropriate. Support of any specific variant of the Command TLV is OPTIONAL unless the ANCP agent claims support for a capability that requires its use.
可以携带命令TLV的每种消息类型预计将定义有效载荷内容的含义，当然，在适当的时候允许重复使用规范。对命令TLV的任何特定变体的支持都是可选的，除非ANCP代理声称支持需要其使用的功能。
Length: Variable, depending on the specific contents.
长度：可变，取决于具体内容。
Value: Command information as defined for each message type. The field MAY include sub-TLVs. The contents of this TLV MUST be specified as one "command" or alternatively a sequence of one or more "commands", each beginning with a 1-byte Command Code and possibly including other data following the Command Code. An IANA registry has been established for Command Code values. This document reserves the Command Code value 0 as an initial entry in the registry.
值：为每种消息类型定义的命令信息。该字段可能包括子TLV。该TLV的内容必须指定为一个“命令”或一个或多个“命令”的序列，每个“命令”以1字节的命令代码开头，可能包括命令代码后面的其他数据。已为命令代码值建立IANA注册表。此文档将命令代码值0保留为注册表中的初始项。
Name: Status-Info
姓名：状态信息
Type: 0x0106
类型：0x0106
Description: The Status-Info-TLV is intended to be a general container for warning or error diagnostics relating to commands and/or requests. It is a supplement to the Result Code field in the ANCP general header. The specifications for individual message types MAY indicate the use of this TLV as part of responses, particularly for failures. As mentioned above, the Generic Response message will usually include an instance of the Status-Info TLV. Support of the Status-Info TLV, both as sender and as receiver, is REQUIRED for all ANCP agents, regardless of what capabilities they support.
描述：状态信息TLV是一个通用容器，用于与命令和/或请求相关的警告或错误诊断。它是ANCP通用标题中结果代码字段的补充。个别消息类型的规范可能指示将此TLV用作响应的一部分，特别是在故障时。如上所述，通用响应消息通常包括状态信息TLV的实例。无论ANCP代理支持何种功能，所有ANCP代理都需要作为发送方和接收方支持状态信息TLV。
Length: Variable, depending on the specific contents.
长度：可变，取决于具体内容。
Value: The following fixed fields. In addition, sub-TLVs MAY be appended to provide further diagnostic information.
值：以下固定字段。此外，可以附加子TLV以提供进一步的诊断信息。
Reserved (8 bits): See Section 3.4 for handling of reserved fields.
保留（8位）：有关保留字段的处理，请参见第3.4节。
Msg Type (8 bits): Message Type of the request for which this TLV is providing diagnostics.
Msg类型（8位）：此TLV为其提供诊断的请求的消息类型。
Error Message Length (16 bits): Number of bytes in the error message, excluding padding, but including the language tag and delimiter. This MAY be zero if no error message is provided.
错误消息长度（16位）：错误消息中的字节数，不包括填充，但包括语言标记和分隔符。如果未提供错误消息，则该值可能为零。
Error Message: Human-readable string providing information about the warning or error condition. The initial characters of the string MUST be a language tag as described in [RFC5646], terminated by a colon (":"). The actual text string follows the delimiter. The field is padded at the end with zeroes as necessary to extend it to a 4-byte word boundary.
错误消息：人类可读的字符串，提供有关警告或错误条件的信息。字符串的初始字符必须是[RFC5646]中描述的语言标记，以冒号（：）结尾。实际文本字符串位于分隔符之后。根据需要，该字段在末尾用零填充，以将其扩展到4字节的字边界。
Section 3.6.1.4 provides recommendations for what TLVs to add in the Status-Info TLV for particular values of the message header Result Code field.
第3.6.1.4节为消息头结果代码字段的特定值在状态信息TLV中添加哪些TLV提供了建议。
Figure 12 illustrates the Status-Info TLV.
图12说明了状态信息TLV。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4-byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4-byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Status-Info TLV
图12：状态信息TLV
5. Introduction to ANCP Capabilities for Digital Subscriber Lines (DSLs)
5. 数字用户线（DSL）的ANCP功能介绍
DSL is a widely deployed access technology for Broadband Access for Next Generation Networks. Specifications such as [TR-059], [TR-058], and [TR-092] describe possible architectures for these access networks. The scope of these specifications includes the delivery of voice, video, and data services.
DSL是为下一代网络宽带接入而广泛部署的接入技术。[TR-059]、[TR-058]和[TR-092]等规范描述了这些接入网络的可能架构。这些规范的范围包括语音、视频和数据服务的交付。
The next three sections of this document specify basic ANCP capabilities for use specifically in controlling Access Nodes serving DSL access (Tech Type = 0x05). The same ANs could be serving other access technologies (e.g., Metro-Ethernet, Passive Optical Networking, WiMax), in which case the AN will also have to support the corresponding other-technology-specific capabilities. Those additional capabilities are outside the scope of the present document.
本文档接下来的三节具体说明了用于控制为DSL接入服务的接入节点的基本ANCP功能（Tech Type=0x05）。相同的AN可以服务于其他接入技术（例如，城域以太网、无源光网络、WiMax），在这种情况下，AN还必须支持相应的其他特定于技术的能力。这些额外能力不在本文件的范围之内。
Most ANCP messages involve actions relating to a specific access line. Thus, it is necessary to describe how access lines are identified within those messages. This section defines four TLVs for that purpose and provides an informative description of how they are used.
大多数ANCP消息涉及与特定访问线路相关的操作。因此，有必要描述如何在这些消息中识别访问线。本节为此定义了四种TLV，并提供了如何使用它们的详细说明。
Three types of identification are described in [TR-101] and provided for in the TLVs defined in this section:
[TR-101]中描述了三种类型的标识，并在本节定义的TLV中提供：
o identification of an access line by its logical appearance on the user side of the Access Node;
o 通过接入线在接入节点的用户侧的逻辑外观来识别接入线；
o identification of an access line by its logical appearance on the NAS side of the Access Node; and
o 通过其在接入节点的NAS侧的逻辑外观来识别接入线；和
o identification down to the user or host level as a supplement to access line identification in one of the other two forms.
o 用户或主机级别的标识，作为其他两种形式之一的接入线标识的补充。
All of these identifiers originate with the AN control application, during the process of DSL topology discovery. The control application chooses which identifiers to use and the values to place into them on a line-by-line basis, based on AN configuration and deployment considerations.
在DSL拓扑发现过程中，所有这些标识符都源自控制应用程序。控制应用程序根据配置和部署考虑，逐行选择要使用的标识符以及要放入其中的值。
Aside from its use in ANCP signalling, access line identification is also used in DHCP ([RFC2131], [RFC3315]) transactions involving hosts served by DSL. Either the AN or the NAS can serve as a DHCP relay node. [TR-101] requires the AN or NAS in this role to add access line identification in Option 82 (Information) ([RFC3046], with its IPv6 equivalent in [RFC4649]) to each DHCP request it forwards to the DHCP server. It is desirable for efficiency that the identification used in this signalling should be the same as the identification used in ANCP messages.
除了在ANCP信令中使用外，接入线标识还用于涉及DSL服务的主机的DHCP（[RFC2131]、[RFC3315]）事务中。AN或NAS都可以用作DHCP中继节点。[TR-101]要求担任此角色的AN或NAS在选项82（信息）（[RFC3046]中添加接入线标识，其IPv6等价物在[RFC4649]中）添加到它转发给DHCP服务器的每个DHCP请求中。为了提高效率，此信令中使用的标识应与ANCP消息中使用的标识相同。
From the point of view of ANCP itself, the identifiers are opaque. From the point of view of the AN control application, the syntax for the user-side access line identifier is the same as specified in Section 3.9.3 of [TR-101] for DHCP Option 82. The syntax for the ASCII form of the NAS-side access line identifier will be similar.
从ANCP本身的角度来看，标识符是不透明的。从控制应用程序的角度来看，用户侧接入线标识符的语法与[TR-101]第3.9.3节中针对DHCP选项82规定的相同。NAS侧接入线标识符的ASCII格式的语法将类似。
Access line identification by logical appearance on the user side of the Access Node will always identify a DSL access line uniquely. Identification by the logical appearance on the NAS side of the Access Node is unique only if there is a one-to-one mapping between
通过接入节点的用户侧上的逻辑外观进行的接入线标识将始终唯一地标识DSL接入线。仅当访问节点的NAS侧存在一对一映射时，通过逻辑外观进行的标识才是唯一的
the appearances on the two sides and no identity-modifying aggregation between the AN and the NAS. In other cases, and in particular in the case of Ethernet aggregation using the N:1 VLAN model, the user-side access line identification is necessary, but the NAS-side identification is potentially useful information allowing the NAS to build up a picture of the aggregation network topology.
AN和NAS之间在两侧的外观和无身份修改聚合。在其他情况下，特别是在使用N:1 VLAN模型的以太网聚合的情况下，用户侧接入线标识是必要的，但是NAS侧标识是允许NAS建立聚合网络拓扑图的潜在有用信息。
Additional identification down to the user or host level is intended to supplement rather than replace either of the other two forms of identification.
用户或主机级别的附加标识旨在补充而不是取代其他两种形式的标识。
Sections 3.8 and 3.9 of [TR-101] are contradictory on this point. It is assumed here that Section 3.9 is meant to be authoritative.
[TR-101]第3.8节和第3.9节在这一点上相互矛盾。此处假设第3.9节具有权威性。
The user-level identification takes the form of an administered string that again is opaque at the ANCP level.
用户级标识采用受管字符串的形式，在ANCP级也是不透明的。
The NAS control application will use the identifying information it receives from the AN directly for some purposes. For examples, see the introductory part of Section 3.9 of [TR-101]. For other purposes, the NAS will build a mapping between the unique access line identification provided by the AN, the additional identification of the user or host (where provided), and the IP interface on a particular host. For access lines with static IP address assignment, that mapping could be configured instead.
NAS控制应用程序将直接从AN接收到的标识信息用于某些目的。例如，参见[TR-101]第3.9节的介绍部分。出于其他目的，NAS将在AN提供的唯一接入线标识、用户或主机的附加标识（如提供）和特定主机上的IP接口之间建立映射。对于具有静态IP地址分配的访问线路，可以配置该映射。
This section provides a normative specification of the TLVs that ANCP provides to carry the types of identification just described. The Access-Loop-Circuit-ID TLV identifies an access line by its logical appearance on the user side of the Access Node. Two alternatives, the Access-Aggregation-Circuit-ID-ASCII TLV and the Access-Aggregation-Circuit-ID-Binary TLV, identify an access line by its logical appearance on the NAS side of the Access Node. It is unlikely that a given AN uses both of these TLVs, either for the same line or for different lines, since they carry equivalent information. Finally, the Access-Loop-Remote-ID TLV contains an operator-configured string that uniquely identifies the user on the associated access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].
本节提供了ANCP提供的TLV的规范性规范，用于承载刚才描述的标识类型。接入环路ID TLV通过其在接入节点的用户侧上的逻辑外观来识别接入线。两个备选方案，即访问聚合电路ID ASCII TLV和访问聚合电路ID Binary TLV，通过其在访问节点NAS侧的逻辑外观来识别访问线。给定的AN不太可能对同一条线路或不同的线路同时使用这两种TLV，因为它们携带相同的信息。最后，如[TR-101]第3.9.1节和第3.9.2节所述，接入环路远程ID TLV包含一个操作员配置的字符串，该字符串唯一标识相关接入线上的用户。
ANCP agents conforming to this section MUST satisfy the following requirements:
符合本节要求的ANCP代理必须满足以下要求：
o ANCP agents MUST be able to build and send the Access-Loop-Circuit-ID TLV, the Access-Loop-Remote-ID TLV, and either the Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation-Circuit-ID-Binary TLV (implementation choice), when passed the associated information from the AN control application.
o 当从控制应用程序传递相关信息时，ANCP代理必须能够构建和发送访问回路回路ID TLV、访问回路远程ID TLV以及访问聚合回路ID ASCII TLV或访问聚合回路ID二进制TLV（实现选项）。
o ANCP agents MUST be able to receive all four TLV types, extract the relevant information, and pass it to the control application.
o ANCP代理必须能够接收所有四种TLV类型，提取相关信息，并将其传递给控制应用程序。
o If the Access-Loop-Remote-ID TLV is present in a message, it MUST be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-Binary TLV with two VLAN identifiers.
o 如果消息中存在访问环路远程ID TLV，则必须随附带有两个VLAN标识符的访问环路电路ID TLV和/或访问聚合电路ID ASCII TLV或访问聚合电路ID二进制TLV。
The Access-Loop-Remote-ID TLV is not enough to identify an access line uniquely on its own. As indicated above, an Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-Binary TLV with two VLAN identifiers may or may not identify an access line uniquely, but this is up to the control application to decide.
访问环路远程ID TLV不足以单独识别访问线路。如上所述，具有两个VLAN标识符的接入聚合电路ID ASCII TLV或接入聚合电路ID二进制TLV可以唯一地标识接入线，也可以不唯一地标识接入线，但这由控制应用程序决定。
o If the Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-Binary TLV is present in a message with just one VLAN identifier, it MUST be accompanied by an Access-Loop-Circuit-ID TLV.
o 如果只有一个VLAN标识符的消息中存在访问聚合电路ID ASCII TLV或访问聚合电路ID Binary TLV，则必须随附访问环路ID TLV。
Type: 0x0001
类型：0x0001
Description: A locally administered human-readable string generated by or configured on the Access Node, identifying the corresponding access loop logical port on the user side of the Access Node.
描述：由接入节点生成或在接入节点上配置的本地管理的人类可读字符串，用于标识接入节点用户端的相应接入环路逻辑端口。
Length: Up to 63 bytes
长度：最多63字节
Value: ASCII string
值：ASCII字符串
Type: 0x0002
类型：0x0002
Description: An operator-configured string that uniquely identifies the user on the associated access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].
描述：操作员配置的字符串，用于唯一标识相关接入线路上的用户，如[TR-101]第3.9.1节和第3.9.2节所述。
Length: Up to 63 bytes
长度：最多63字节
Value: ASCII string
值：ASCII字符串
Type: 0x0006
类型：0x0006
Description: This TLV identifies or partially identifies a specific access line by means of its logical circuit identifier on the NAS side of the Access Node.
描述：该TLV通过其在接入节点NAS侧的逻辑电路标识符来标识或部分标识特定接入线。
For Ethernet access aggregation, where a per-subscriber (stacked) VLAN can be applied (1:1 model as defined in [TR-101]), the TLV contains two value fields. Each field carries a 12-bit VLAN identifier (which is part of the VLAN tag defined by [IEEE802.1Q]). The first field MUST carry the inner VLAN identifier, while the second field MUST carry the outer VLAN identifier.
对于以太网接入聚合，可应用每个订户（堆叠）VLAN（如[TR-101]中定义的1:1模型），TLV包含两个值字段。每个字段都带有一个12位VLAN标识符（它是[IEEE802.1Q]定义的VLAN标记的一部分）。第一个字段必须携带内部VLAN标识符，而第二个字段必须携带外部VLAN标识符。
When the N:1 VLAN model is used, only one VLAN tag is available. For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV contains a single value field, which MUST carry the 12-bit VLAN identifier derived from the single available VLAN tag.
使用N:1 VLAN模型时，只有一个VLAN标记可用。对于N:1模型，访问聚合电路ID二进制TLV包含一个单值字段，该字段必须携带从单个可用VLAN标记派生的12位VLAN标识符。
In the case of an ATM aggregation network, where the DSLAM is directly connected to the NAS (without an intermediate ATM switch), the Virtual Path Identifier (VPI) and Virtual Circuit Identifier (VCI) on the DSLAM uplink correspond uniquely to the DSL access line on the DSLAM. The Access-Aggregation-Circuit-ID-Binary TLV MAY be used to carry the VPI and VCI. The first value field of the TLV MUST carry the VCI, while the second value field MUST carry the VPI.
在ATM聚合网络的情况下，其中DSLAM直接连接到NAS（没有中间ATM交换机），DSLAM上行链路上的虚拟路径标识符（VPI）和虚拟电路标识符（VCI）唯一地对应于DSLAM上的DSL接入线。接入聚合电路ID二进制TLV可用于承载VPI和VCI。TLV的第一个值字段必须携带VCI，而第二个值字段必须携带VPI。
Each identifier MUST be placed in the low-order bits of its respective 32-bit field, with the higher-order bits set to zero. The ordering of the bits of the identifier MUST be the same as when the identifier is transmitted on the wire to identify an Ethernet frame or ATM cell.
每个标识符必须置于其各自32位字段的低阶位，高阶位设置为零。标识符位的顺序必须与在导线上传输标识符以识别以太网帧或ATM信元时相同。
The Access-Aggregation-Circuit-ID-Binary is illustrated in Figure 13.
访问聚合电路ID二进制如图13所示。
Length: 4 or 8 bytes
长度：4或8字节
Value: One or two 32-bit binary fields.
值：一个或两个32位二进制字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0006 | Length = 4 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single VLAN Identifier, inner VLAN identifier, or VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer VLAN identifier or VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0006 | Length = 4 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single VLAN Identifier, inner VLAN identifier, or VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer VLAN identifier or VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: The Access-Aggregation-Circuit-ID-Binary TLV
图13：访问聚合电路ID二进制TLV
Type: 0x0003
类型：0x0003
Description: This TLV transmits the ASCII equivalent of the Access-Aggregation-Circuit-ID-Binary TLV. As mentioned in the previous section, the AN control application will use a format similar to that specified in Section 3.9.3 of [TR-101] for the format of the "circuit-id".
描述：此TLV传输访问聚合电路ID二进制TLV的ASCII等效值。如前一节所述，控制应用程序将使用与[TR-101]第3.9.3节中规定的“电路id”格式类似的格式。
As an extension to the present document, the Access Node could convey to the NAS the characteristics (e.g., bandwidth) of the uplink on the Access Node. This TLV or the binary equivalent defined above then serves the purpose of uniquely identifying the uplink whose characteristics are being defined. The present document does not specify the TLVs needed to convey the uplink characteristics.
作为本文档的扩展，接入节点可以向NAS传送接入节点上的上行链路的特性（例如，带宽）。然后，上述TLV或二进制等效物用于唯一识别正在定义其特性的上行链路。本文件未规定传达上行链路特性所需的TLV。
Length: Up to 63 bytes
长度：最多63字节
Value: ASCII string
值：ASCII字符串
Section 3.1 of [RFC5851] describes the requirements for the DSL Topology Discovery capability.
[RFC5851]第3.1节描述了DSL拓扑发现能力的要求。
The AN control application in the DSLAM requests ANCP to send a DSL-specific Port Up message to the NAS under the following circumstances:
在以下情况下，DSLAM中的AN控制应用程序请求ANCP向NAS发送DSL特定端口向上消息：
o when a new adjacency with the NAS is established, for each DSL loop that is synchronized at that time;
o 当与NAS建立新的邻接时，对于当时同步的每个DSL环路；
o subsequent to that, whenever a DSL access line resynchronizes; and
o 随后，每当DSL接入线重新同步时；和
o whenever the AN control application wishes to signal that a line attribute has changed.
o 每当控件应用程序希望发出线属性已更改的信号时。
The AN control application in the DSLAM requests ANCP to send a DSL-specific Port Down message to the NAS under the following circumstances:
在以下情况下，DSLAM中的AN控制应用程序请求ANCP向NAS发送DSL特定端口关闭消息：
o when a new adjacency with the NAS is established, for each DSL loop that is provisioned but not synchronized at that time;
o 当与NAS建立新的邻接时，对于当时已供应但未同步的每个DSL环路；
o whenever a DSL access line that is equipped in an AN but administratively disabled is signaled as "IDLE"; and
o 当在an中装备但被管理禁用的DSL接入线被发信号称为“空闲”时；和
o subsequent to that, whenever a DSL access line loses synchronization.
o 此后，每当DSL接入线失去同步时。
The AN control application passes information to identify the DSL loop to ANCP to include in the Port Up or Port Down message, along with information relating to DSL access line attributes.
a控制应用程序将识别DSL环路的信息以及与DSL接入线路属性相关的信息传递给ANCP，以包括在Port-Up或Port-Down消息中。
In the case of bonded copper loops to the customer premise (as per DSL multi-pair bonding described by [G.998.1] and [G.998.2]), the AN control application requests that ANCP send DSL-specific Port Up and Port Down messages for the aggregate "DSL bonded circuit" (represented as a single logical port) as well as the individual DSL access lines of which it is comprised. The information relating to DSL access line attributes that is passed by the AN control application is aggregate information.
对于连接到客户场所的铜缆环路（根据[G.998.1]和[G.998.2]中描述的DSL多对连接），AN控制应用程序请求ANCP为聚合“DSL连接电路”（表示为单个逻辑端口）发送DSL特定端口向上和端口向下消息以及由其组成的各个DSL接入线。控制应用程序传递的与DSL接入线属性相关的信息是聚合信息。
ANCP generates the DSL-specific Port Up or Port Down message and transfers it to the NAS. ANCP on the NAS side passes an indication to the NAS control application that a DSL Port Up or Port Down message has been received along with the information contained in the message.
ANCP生成DSL特定的端口向上或端口向下消息，并将其传输到NAS。NAS侧的ANCP向NAS控制应用程序传递一个指示，表明已接收到DSL端口向上或端口向下消息以及消息中包含的信息。
The NAS control application updates its view of the DSL access line state, performs any required accounting operations, and uses any included line attributes to adjust the operation of its queuing/ scheduling mechanisms as they apply to data passing to and from that DSL access line.
NAS控制应用程序更新其DSL接入线状态视图，执行任何所需的记帐操作，并使用任何包含的线路属性来调整其排队/调度机制的操作，因为它们适用于进出该DSL接入线的数据。
Figure 14 summarizes the interaction.
图14总结了交互作用。
1. Home Access NAS Gateway Node
1. 家庭访问NAS网关节点
-----------> -------------------------->
DSL Port Up (Event message)
Signal (default line parameters)
-----------> -------------------------->
DSL Port Up (Event message)
Signal (default line parameters)
2. Home Access NAS Gateway Node
2. 家庭访问NAS网关节点
-----------> -------------------------->
DSL Port Up (Event message)
Resynch (updated line parameters)
-----------> -------------------------->
DSL Port Up (Event message)
Resynch (updated line parameters)
3. Home Access NAS Gateway Node
3. 家庭访问NAS网关节点
-----------> -------------------------->
Loss of Port Down (Event message)
DSL Signal (selected line parameters)
-----------> -------------------------->
Loss of Port Down (Event message)
DSL Signal (selected line parameters)
Figure 14: ANCP Message Flow for DSL Topology Discovery
图14:DSL拓扑发现的ANCP消息流
The DSL topology discovery capability is assigned capability type 0x0001. No capability data is associated with this capability.
DSL拓扑发现能力被分配为能力类型0x0001。没有与此功能关联的功能数据。
The AN-side ANCP agent MUST be able to create DSL-specific Port Up and Port Down messages according to the format specified in Section 6.3.
AN端ANCP代理必须能够根据第6.3节中指定的格式创建DSL特定的端口向上和端口向下消息。
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
AN侧ANCP代理必须符合第5.1.2节的规范要求。
The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Up and Port Down messages as they are specified in Section 6.4.
AN端ANCP代理必须遵循第6.4节中规定的与DSL特定端口向上和端口向下消息相关联的AN端程序。
The NAS-side ANCP agent MUST be able to receive and validate DSL-specific Port Up and Port Down messages according to the format specified in Section 6.3.
NAS端ANCP代理必须能够根据第6.3节规定的格式接收和验证DSL特定的端口上升和端口下降消息。
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
NAS侧ANCP代理必须符合第5.1.2节的规范要求。
The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Up and Port Down messages as they are specified in Section 6.4.
NAS端ANCP代理必须遵循第6.4节中规定的与DSL特定端口上升和端口下降消息相关的NAS端程序。
The format of the ANCP Port Up and Port Down Event messages is shown in Figure 15.
ANCP Port Up和Port Down事件消息的格式如图15所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (20 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSL-Line-Attributes TLV |
~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (20 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSL-Line-Attributes TLV |
~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this figure.
注：TLV的顺序可能与本图所示不同。
Figure 15: Format of the ANCP Port Up and Port Down Event Messages for DSL Topology Discovery
图15:DSL拓扑发现的ANCP向上端口和向下端口事件消息的格式
See Section 3.6.1 for a description of the ANCP general message header. The Message Type field MUST be set to 80 for Port Up, 81 for Port Down. The 4-bit Result field MUST be set to zero (signifying Ignore). The 12-bit Result Code field and the 24-bit Transaction
有关ANCP通用消息头的说明，请参见第3.6.1节。消息类型字段必须设置为80（端口向上），81（端口向下）。4位结果字段必须设置为零（表示忽略）。12位结果代码字段和24位事务
Identifier field MUST also be set to zeroes. Other fields in the general header MUST be set a as described in Section 3.6.
标识符字段也必须设置为零。通用标题中的其他字段必须按照第3.6节的说明设置为a。
The five-word Unused field is a historical leftover. The handling of unused/reserved fields is described in Section 3.4.
“未使用的五个字”字段是历史遗留下来的。第3.4节描述了未使用/保留字段的处理。
The remaining message fields belong to the "extension block", and are described as follows:
其余消息字段属于“扩展块”，描述如下：
Extension Flags (8 bits): The flag bits denoted by 'x' are currently unspecified and reserved.
扩展标志（8位）：由“x”表示的标志位当前未指定并保留。
Message Type (8 bits): Message Type has the same value as in the general header (i.e., 80 or 81).
消息类型（8位）：消息类型的值与常规标头中的值相同（即80或81）。
Tech Type (8 bits): MUST be set to 0x05 (DSL).
技术类型（8位）：必须设置为0x05（DSL）。
Reserved (8 bits): set as described in Section 3.4.
保留（8位）：如第3.4节所述设置。
# of TLVs (16 bits): The number of TLVs that follow, not counting TLVs encapsulated within other TLVs.
#TLV数量（16位）：后面的TLV数量，不包括封装在其他TLV中的TLV。
Extension Block Length (16 bits): The total length of the TLVs carried in the extension block in bytes, including any padding within individual TLVs.
扩展块长度（16位）：扩展块中携带的TLV的总长度（字节），包括单个TLV中的任何填充。
TLVs: One or more TLVs to identify a DSL access line and zero or more TLVs to define its characteristics.
TLV：一个或多个TLV用于标识DSL接入线，零个或多个TLV用于定义其特性。
The AN-side ANCP agent creates and transmits a DSL-specific Port Up or Port Down message when requested by the AN control application and presented with the information needed to build a valid message. It is RECOMMENDED that the Access Node use a dampening mechanism per DSL access line to control the rate at which state changes are communicated to the NAS.
当控制应用程序请求并提供构建有效消息所需的信息时，AN侧ANCP代理创建并传输DSL特定的端口向上或端口向下消息。建议接入节点使用每个DSL接入线的阻尼机制来控制状态更改传送到NAS的速率。
At the top level, the extension block within a DSL-specific Port Up or Port Down message MUST include TLVs from Section 5.1.2 to identify the DSL access line.
在顶层，DSL特定端口向上或端口向下消息中的扩展块必须包括第5.1.2节中的TLV，以识别DSL接入线。
TLVs presenting DSL access line attributes (i.e., the TLVs specified in Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV. When the DSL-Line-Attributes TLV is present in a message, it MUST contain at least one such TLV and will generally contain more
表示DSL接入线路属性的TLV（即第6.5节中规定的TLV）必须封装在DSL线路属性TLV中。当DSL线路属性TLV出现在消息中时，它必须至少包含一个这样的TLV，并且通常包含更多
than one. In the Port Up message, the DSL-Line-Attributes TLV MUST be present. In the Port Down message, the DSL-Line-Attributes TLV MAY be present.
不止一个。在Port Up消息中，DSL线路属性TLV必须存在。在端口关闭消息中，可能存在DSL线路属性TLV。
The NAS-side ANCP agent MUST be prepared to receive Port Up and Port Down messages for a given DSL access line or logical port at any time after negotiation of an adjacency has been completed. It is possible for two Port Up messages in succession to be received for the same DSL access line without an intervening Port Down message, and vice versa.
NAS端ANCP代理必须准备好在邻接协商完成后的任何时间接收给定DSL接入线路或逻辑端口的端口上升和端口下降消息。对于同一DSL接入线，可以连续接收两个端口向上消息，而不需要插入端口向下消息，反之亦然。
The NAS-side ANCP agent SHOULD validate each message against the specifications given in Section 6.3 and the TLV specifications given in Sections 5.1.2 and 6.5. If it finds an error, it MAY generate a Generic Response message containing an appropriate Result Code value. If it does so, the message MUST contain copies of all of the identifier TLVs from Section 5.1.2 that were present in the Port Up or Port Down message. The message MUST also contain a Status-Info TLV that in turn contains other information appropriate to the message header Result Code value as described in Section 3.6.1.4.
NAS端ANCP代理应根据第6.3节中给出的规范以及第5.1.2和6.5节中给出的TLV规范验证每条消息。如果发现错误，它可能会生成包含适当结果代码值的通用响应消息。如果这样做，则消息必须包含第5.1.2节中出现在端口上升或端口下降消息中的所有标识符TLV的副本。消息还必须包含状态信息TLV，该状态信息TLV又包含与第3.6.1.4节所述消息头结果代码值相适应的其他信息。
As specified above, the DSL-Line-Attributes TLV is inserted into the Port Up or Port Down message at the top level. The remaining TLVs defined below are encapsulated within the DSL-Line-Attributes TLV.
如上所述，DSL线路属性TLV在顶层插入到端口向上或端口向下消息中。下面定义的其余TLV封装在DSL线路属性TLV中。
Type: 0x0004
类型：0x0004
Description: This TLV encapsulates attribute values for a DSL access line serving a subscriber.
描述：此TLV封装为用户提供服务的DSL接入线的属性值。
Length: Variable (up to 1023 bytes)
长度：变量（最多1023字节）
Value: One or more encapsulated TLVs corresponding to DSL access line attributes. The DSL-Line-Attributes TLV MUST contain at least one TLV when it is present in a Port Up or Port Down message. The actual contents are determined by the AN control application.
值：对应于DSL接入线属性的一个或多个封装TLV。DSL线路属性TLV在端口向上或端口向下消息中出现时必须至少包含一个TLV。实际内容由控制应用程序确定。
Type: 0x0091
类型：0x0091
Description: Indicates the type of transmission system in use.
说明：表示正在使用的变速箱系统的类型。
Length: 4 bytes
长度：4字节
Value: 32-bit unsigned integer
值：32位无符号整数
ADSL1 = 1
ADSL1 = 1
ADSL2 = 2
ADSL2 = 2
ADSL2+ = 3
ADSL2+=3
VDSL1 = 4
VDSL1 = 4
VDSL2 = 5
VDSL2 = 5
SDSL = 6
SDSL = 6
OTHER = 0
OTHER = 0
Type: 0x0081
类型：0x0081
Description: Actual upstream net data rate on a DSL access line.
描述：DSL接入线上的实际上行净数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0082
类型：0x0082
Description: Actual downstream net data rate on a DSL access line.
描述：DSL接入线上的实际下游净数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0083
类型：0x0083
Description: Minimum upstream net data rate desired by the operator.
说明：操作员所需的最小上游净数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0084
类型：0x0084
Description: Minimum downstream net data rate desired by the operator.
说明：操作员所需的最小下游净数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0085
类型：0x0085
Description: Maximum net upstream rate that can be attained on the DSL access line.
描述：DSL接入线上可达到的最大净上行速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0086
类型：0x0086
Description: Maximum net downstream rate that can be attained on the DSL access line.
描述：DSL接入线上可达到的最大净下行速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0087
类型：0x0087
Description: Maximum net upstream data rate desired by the operator.
描述：操作员所需的最大净上游数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0088
类型：0x0088
Description: Maximum net downstream data rate desired by the operator.
描述：操作员所需的最大净下游数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x0089
类型：0x0089
Description: Minimum net upstream data rate desired by the operator in low power state.
说明：操作员在低功率状态下所需的最小净上游数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x008A
类型：0x008A
Description: Minimum net downstream data rate desired by the operator in low power state.
说明：操作员在低功率状态下所需的最小净下游数据速率。
Length: 4 bytes
长度：4字节
Value: Rate in kbits/s as a 32-bit unsigned integer
值：以kbits/s为单位的32位无符号整数的速率
Type: 0x008B
类型：0x008B
Description: Maximum one-way interleaving delay.
描述：最大单向交织延迟。
Length: 4 bytes
长度：4字节
Value: Time in ms as a 32-bit unsigned integer
值：32位无符号整数形式的时间（毫秒）
Type: 0x008C
类型：0x008C
Description: Value corresponding to the interleaver setting.
描述：与交织器设置相对应的值。
Length: 4 bytes
长度：4字节
Value: Time in ms as a 32-bit unsigned integer
值：32位无符号整数形式的时间（毫秒）
Type: 0x008D
类型：0x008D
Description: Maximum one-way interleaving delay.
描述：最大单向交织延迟。
Length: 4 bytes
长度：4字节
Value: Time in ms as a 32-bit unsigned integer
值：32位无符号整数形式的时间（毫秒）
Type: 0x008E
类型：0x008E
Description: Value corresponding to the interleaver setting.
描述：与交织器设置相对应的值。
Length: 4 bytes
长度：4字节
Value: Time in ms as a 32-bit unsigned integer
值：32位无符号整数形式的时间（毫秒）
Type: 0x008F
类型：0x008F
Description: The state of the DSL access line.
描述：DSL接入线路的状态。
Length: 4 bytes
长度：4字节
Value: 32-bit unsigned integer
值：32位无符号整数
SHOWTIME = 1
SHOWTIME = 1
IDLE = 2
IDLE = 2
SILENT = 3
SILENT = 3
Type: 0x0090
类型：0x0090
Description: The data link protocol and, optionally, the encapsulation overhead on the access loop. When this TLV is present, at least the data link protocol MUST be indicated. The encapsulation overhead MAY be indicated. The Access Node MAY choose to not convey the encapsulation on the access loop by specifying values of 0 (NA) for the two encapsulation fields.
描述：数据链路协议和（可选）访问环路上的封装开销。当存在该TLV时，必须至少指示数据链路协议。可以指示封装开销。接入节点可以通过为两个封装字段指定0（NA）的值来选择不在接入环路上传送封装。
Length: 3 bytes
长度：3字节
Value: The 3 bytes (most to least significant) and valid set of values for each byte are defined as follows:
值：3个字节（最高到最低有效）和每个字节的有效值集定义如下：
Byte 1: Data Link
字节1：数据链路
ATM AAL5 = 0
ATM AAL5=0
ETHERNET = 1
ETHERNET = 1
Byte 2: Encapsulation 1
字节2：封装1
NA = 0
NA = 0
Untagged Ethernet = 1
未标记以太网=1
Single-tagged Ethernet = 2
单标签以太网=2
Double-tagged Ethernet = 3
双标签以太网=3
Byte 3: Encapsulation 2
字节3：封装2
NA = 0
NA = 0
PPPoA LLC = 1
PPPoA LLC=1
PPPoA Null = 2
PPPoA Null=2
IPoA LLC = 3
IPoA有限责任公司=3
IPoA Null = 4
IPoA Null=4
Ethernet over AAL5 LLC with FCS = 5
通过AAL5 LLC的以太网，FCS=5
Ethernet over AAL5 LLC without FCS = 6
不带FCS的AAL5 LLC以太网=6
Ethernet over AAL5 NULL with FCS = 7
AAL5上的以太网为空，FCS=7
Ethernet over AAL5 NULL without FCS = 8
AAL5上的以太网为空，无FCS=8
The Access-Loop-Encapsulation TLV is illustrated in Figure 16.
访问环路封装TLV如图16所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0090 | Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data link | Encaps 1 | Encaps 2 | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0090 | Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data link | Encaps 1 | Encaps 2 | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: The Access-Loop-Encapsulation TLV
图16：访问环路封装TLV
The use case for ANCP-based DSL Line Configuration is described in Section 3.2 of [RFC5851].
[RFC5851]第3.2节描述了基于ANCP的DSL线路配置的用例。
Triggered by topology information reporting a new DSL access line or triggered by a subsequent user session establishment (via PPP or DHCP), RADIUS/AAA sends service parameters to the NAS control application for configuration on the access line. The NAS control application passes the request on to the NAS-side agent, which sends the information to the AN by means of a Port Management (line configuration) message. The AN-side agent passes this information up to the AN control application, which applies it to the line. Figure 17 summarizes the interaction.
RADIUS/AAA由报告新DSL接入线的拓扑信息触发，或由后续用户会话建立（通过PPP或DHCP）触发，向NAS控制应用程序发送服务参数，以在接入线上进行配置。NAS控制应用程序将请求传递给NAS端代理，后者通过端口管理（线路配置）消息将信息发送给AN。AN端代理将此信息传递给AN控制应用程序，后者将其应用于线路。图17总结了交互作用。
Home Access NAS RADIUS/AAA Gateway Node Policy Server
家庭访问NAS RADIUS/AAA网关节点策略服务器
-----------> --------------->
DSL Port Up message)
Signal (line parameters)
-----------> --------------->
DSL Port Up message)
Signal (line parameters)
--------------------------------> -------------->
PPP/DHCP Session Authentication &
authorization
--------------------------------> -------------->
PPP/DHCP Session Authentication &
authorization
<----------------
Port Management message
(line configuration)
<----------------
Port Management message
(line configuration)
Figure 17: Message Flow - ANCP Mapping for Initial Line Configuration
图17：消息流-初始行配置的ANCP映射
The NAS could update the line configuration as a result of a subscriber service change (e.g., triggered by the policy server). Figure 18 summarizes the interaction.
NAS可能会因订户服务更改（例如，由策略服务器触发）而更新线路配置。图18总结了交互。
User Home Access NAS Gateway Node
用户家庭访问NAS网关节点
-------------------------->
PPP/DHCP Session
-------------------------->
PPP/DHCP Session
----------------------------------------------------> Web portal,
Service on demand OSS, etc.
|
<----------- RADIUS/AAA
Change of Policy Server
authorization
----------------------------------------------------> Web portal,
Service on demand OSS, etc.
|
<----------- RADIUS/AAA
Change of Policy Server
authorization
<------------
Port Management
message
(new profile)
<------------
Port Management
message
(new profile)
OSS: Operations Support System
操作支持系统
Figure 18: Message Flow - ANCP Mapping for Updated Line Configuration
图18：更新行配置的消息流-ANCP映射
The DSL access line configuration capability is assigned capability type 0x0002. No capability data is associated with this capability.
DSL接入线配置能力被分配为能力类型0x0002。没有与此功能关联的功能数据。
The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (line configuration) messages according to the format specified in Section 7.3.
NAS端ANCP代理必须能够根据第7.3节中指定的格式创建DSL特定端口管理（线路配置）消息。
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
NAS侧ANCP代理必须符合第5.1.2节的规范要求。
The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Management (line configuration) messages as they are specified in Section 7.4.
NAS端ANCP代理必须遵循第7.4节中规定的与DSL特定端口管理（线路配置）消息相关的NAS端程序。
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
AN侧ANCP代理必须符合第5.1.2节的规范要求。
The AN-side ANCP agent MUST be able to receive and validate DSL-specific Port Management (line configuration) messages according to the format specified in Section 7.3.
AN端ANCP代理必须能够根据第7.3节规定的格式接收和验证DSL特定端口管理（线路配置）消息。
The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Management (line configuration) messages as specified in Section 7.4.
AN端ANCP代理必须遵循第7.4节中规定的与DSL特定端口管理（线路配置）消息相关的AN端程序。
The ANCP Port Management message for DSL access line configuration has the format shown in Figure 19.
DSL接入线配置的ANCP端口管理消息的格式如图19所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (12 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=8 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Line configuration TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (12 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=8 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Line configuration TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this figure.
注：TLV的顺序可能与本图所示不同。
Figure 19: Port Management Message for DSL Line Configuration
图19:DSL线路配置的端口管理消息
See Section 3.6 for a description of the ANCP general message header. The Message Type field MUST be set to 32. The 12-bit Result Code field MUST be set to 0x0. The 4-bit Result field MUST be set to either 0x1 (Nack) or 0x2 (AckAll), as determined by policy on the NAS. The 24-bit Transaction Identifier field MUST be set to a positive value. Other fields in the general header MUST be set as described in Section 3.6.
有关ANCP通用消息头的说明，请参见第3.6节。消息类型字段必须设置为32。12位结果代码字段必须设置为0x0。根据NAS上的策略，必须将4位结果字段设置为0x1（Nack）或0x2（AckAll）。24位事务标识符字段必须设置为正值。通用标题中的其他字段必须按照第3.6节的说明进行设置。
The handling of the various unused/reserved fields is described in Section 3.4.
第3.4节描述了各种未使用/保留字段的处理。
The remaining message fields are described as follows:
其余的消息字段描述如下：
Function (8 bits): Action to be performed. For line configuration, Function MUST be set to 8 (Configure Connection Service Data). This action type requests the Access Node (i.e., DSLAM) to apply service configuration data contained in the line configuration TLVs to the DSL access line designated by the access line identifying TLVs.
功能（8位）：要执行的操作。对于线路配置，功能必须设置为8（配置连接服务数据）。该动作类型请求接入节点（即DSLAM）将线路配置tlv中包含的服务配置数据应用于由接入线路标识tlv指定的DSL接入线路。
X-Function (8 bits): Qualifies the action set by Function. For DSL access line configuration, this field MUST be set to 0.
X函数（8位）：限定函数设置的操作。对于DSL接入线配置，此字段必须设置为0。
Extension Flags (8 bits): The flag bits denoted by 'x' before the Message Type field are reserved for future use.
扩展标志（8位）：在消息类型字段之前由“x”表示的标志位保留供将来使用。
Message Type (8 bits): Message Type has the same value as in the general header (i.e., 32).
消息类型（8位）：消息类型的值与常规头中的值相同（即32位）。
Reserved (16 bits): Reserved for future use.
保留（16位）：保留供将来使用。
# of TLVs (16 bits): The number of TLVs that follow, not counting TLVs encapsulated within other TLVs.
#TLV数量（16位）：后面的TLV数量，不包括封装在其他TLV中的TLV。
Extension Block Length (16 bits): The total length of the TLVs carried in the extension block in bytes, including any padding within individual TLVs.
扩展块长度（16位）：扩展块中携带的TLV的总长度（字节），包括单个TLV中的任何填充。
TLVs: Two or more TLVs to identify a DSL access line and configure its service data.
TLV：两个或多个TLV，用于识别DSL接入线路并配置其服务数据。
Other ANCP capabilities, either specific to DSL or technology-independent, MAY reuse the Port Management message for service configuration. If the settings of the fixed fields are compatible with the settings just described, the same Port Management message that is used for DSL access line configuration MAY be used to carry TLVs relating to the other capabilities that apply to the same DSL access line.
其他特定于DSL或独立于技术的ANCP功能可以重用端口管理消息进行服务配置。如果固定字段的设置与刚才描述的设置兼容，则用于DSL接入线配置的相同端口管理消息可用于承载与应用于相同DSL接入线的其他能力相关的tlv。
Use of the Port Management message for configuration MAY also be generalized to other access technologies, if the respective capabilities specify use of access line identifiers appropriate to those technologies in place of the identifiers defined in Section 5.1.2.
如果相应的功能指定使用适合于这些技术的接入线标识符来代替第5.1.2节中定义的标识符，则用于配置的端口管理消息的使用也可推广到其他接入技术。
Service configuration MAY be performed on an access line regardless of its current state.
可以在接入线路上执行服务配置，而不管其当前状态如何。
When requested by the NAS control application and presented with the necessary information to do so, the NAS-side agent MUST create and send a Port Management message with the fixed fields set as described in the previous section. The message MUST contain one or more TLVs to identify an access line according the requirements of Section 5.1.2. The NAS MUST include one or more TLVs to configure line service parameters for that line. Section 7.5 currently identifies only one such TLV, Service-Profile-Name, but other TLVs MAY be added by extensions to ANCP.
当NAS控制应用程序请求并提供执行此操作所需的信息时，NAS端代理必须创建并发送一条端口管理消息，其中固定字段的设置如前一节所述。消息必须包含一个或多个TLV，以根据第5.1.2节的要求识别接入线。NAS必须包括一个或多个TLV，以配置该线路的线路服务参数。第7.5节目前只确定了一个这样的TLV，即服务配置文件名称，但其他TLV可以通过扩展添加到ANCP中。
The AN-side ANCP agent MUST be prepared to receive Port Management (line configuration) messages for a given DSL access line or logical port at any time after negotiation of an adjacency has been completed.
AN端ANCP代理必须准备好在邻接协商完成后的任何时间接收给定DSL接入线路或逻辑端口的端口管理（线路配置）消息。
The AN-side ANCP agent SHOULD validate each message against the specifications given in Section 7.3 and the TLV specifications given in Sections 5.1.2 and 7.5. If it finds an error it MUST return a Port Management response message that copies the Port Management request as it was received, but has the Result header field set to 0x04 (Failure) and the Result Code field set to the appropriate value. The AN-side agent MAY add a Status-Info TLV (Section 4.5) to provide further information on the error, particularly if this is recommended in Section 3.6.1.4 for the given Result Code value. If it does so, the various length fields and the # of TLVs field within the message MUST be adjusted accordingly.
AN侧ANCP代理应根据第7.3节中给出的规范以及第5.1.2和7.5节中给出的TLV规范验证每条消息。如果发现错误，则必须返回端口管理响应消息，该消息在收到端口管理请求时复制该请求，但将结果标头字段设置为0x04（失败），并将结果代码字段设置为适当的值。AN侧代理可以添加状态信息TLV（第4.5节），以提供有关错误的进一步信息，特别是如果第3.6.1.4节建议针对给定结果代码值这样做。如果这样做，则必须相应地调整消息中的各种长度字段和#of TLVs字段。
Currently, only the following TLV is specified for DSL access line configuration. More TLVs may be defined in a future version of this specification or in ANCP extensions for individual service attributes of a DSL access line (e.g., rates, interleaving delay, multicast channel entitlement access-list).
目前，仅为DSL接入线配置指定以下TLV。更多tlv可在本规范的未来版本中或在针对DSL接入线的各个服务属性（例如，速率、交织延迟、多播信道授权接入列表）的ANCP扩展中定义。
Type: 0x0005
类型：0x0005
Description: Reference to a pre-configured profile on the DSLAM that contains service-specific data for the subscriber.
描述：指DSLAM上预配置的配置文件，其中包含订户的特定于服务的数据。
Length: Up to 64 bytes
长度：最多64字节
Value: ASCII string containing the profile name (which the NAS learns from a policy server after a subscriber is authorized).
值：包含配置文件名称的ASCII字符串（NAS在授权订阅服务器后从策略服务器学习该名称）。
The use case and requirements for ANCP-Based DSL remote line connectivity testing are specified in Section 3.3 of [RFC5851].
[RFC5851]第3.3节规定了基于ANCP的DSL远程线路连接测试的用例和要求。
The NAS control application initiates a request for remote connectivity testing for a given access line. The NAS control application can provide loop count and timeout test parameters and opaque data for its own use with the request. The loop count parameter indicates the number of test messages or cells to be used. The timeout parameter indicates the longest that the NAS control application will wait for a result.
NAS控制应用程序为给定的接入线路发起远程连接测试请求。NAS控制应用程序可以提供循环计数和超时测试参数以及不透明数据，供自己在请求中使用。循环计数参数指示要使用的测试消息或单元的数量。timeout参数表示NAS控制应用程序等待结果的最长时间。
The request is passed in a Port Management (Operations, Administration, and Maintenance, OAM) message. If the NAS control application has supplied test parameters, they are used; otherwise, the AN control application uses default test parameters. If a loop count parameter provided by the NAS is outside the valid range, the AN does not execute the test, but returns a result indicating that the test has failed due to an invalid parameter. If the test takes longer than the timeout value (default or provided by the NAS), the AN control application can return a failure result indicating timeout or else can send no response. The AN control application can provide a human-readable string describing the test results, for both failures and successes. If provided, this string is included in the response. Responses always include the opaque data, if any, provided by the NAS control application.
请求通过端口管理（操作、管理和维护，OAM）消息传递。如果NAS控制应用程序提供了测试参数，则使用这些参数；否则，控制应用程序将使用默认测试参数。如果NAS提供的循环计数参数超出有效范围，则AN不会执行测试，但会返回一个结果，表明测试因参数无效而失败。如果测试花费的时间超过超时值（默认值或NAS提供的时间），则控制应用程序可以返回指示超时的故障结果，或者不发送响应。控制应用程序可以提供一个人类可读的字符串来描述失败和成功的测试结果。如果提供了此字符串，则该字符串将包含在响应中。响应始终包括NAS控制应用程序提供的不透明数据（如果有）。
Figure 20 summarizes the interaction.
图20总结了交互作用。
+-------------+ +-----+ +-------+ +----------------+
|Radius/AAA |----|NAS |------| DSLAM |----------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ |Routing Gateway)|
+----------------+
Port Management Message
(Remote Loopback ATM loopback
Trigger Request) or EFM Loopback
1. ----------------> 2. -------->
<-------+
3. <---------------
Port Management Message
(Remote Loopback Test Response)
+-------------+ +-----+ +-------+ +----------------+
|Radius/AAA |----|NAS |------| DSLAM |----------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ |Routing Gateway)|
+----------------+
Port Management Message
(Remote Loopback ATM loopback
Trigger Request) or EFM Loopback
1. ----------------> 2. -------->
<-------+
3. <---------------
Port Management Message
(Remote Loopback Test Response)
CPE: Customer Premises Equipment EFM: Ethernet First Mile
CPE：客户场所设备EFM：以太网第一英里
Figure 20: Message Flow for ANCP-Based OAM
图20：基于ANCP的OAM的消息流
The DSL remote line connectivity testing capability is assigned capability type 0x0004. No capability data is associated with this capability.
DSL远程线路连接测试能力被分配为能力类型0x0004。没有与此功能关联的功能数据。
The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (OAM) messages according to the format specified in Section 8.3.
NAS端ANCP代理必须能够根据第8.3节中指定的格式创建DSL特定端口管理（OAM）消息。
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
NAS侧ANCP代理必须符合第5.1.2节的规范要求。
The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Management (OAM) messages as they are specified in Section 8.4.
NAS端ANCP代理必须遵循第8.4节中规定的与DSL特定端口管理（OAM）消息相关联的NAS端程序。
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
AN侧ANCP代理必须符合第5.1.2节的规范要求。
The AN-side ANCP agent MUST be able to receive and validate DSL-specific Port Management (OAM) messages according to the format specified in Section 8.3.
AN端ANCP代理必须能够根据第8.3节规定的格式接收和验证DSL特定端口管理（OAM）消息。
The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Management (OAM) messages as specified in Section 8.4.
AN端ANCP代理必须遵循第8.4节中规定的与DSL特定端口管理（OAM）消息相关联的AN端程序。
The Port Management message for DSL access line testing has the same format as for DSL access line configuration (see Section 7.3), with the following differences:
DSL接入线测试的端口管理消息具有与DSL接入线配置相同的格式（见第7.3节），但有以下区别：
o The Result field in the request SHOULD be set to AckAll (0x2), to allow the NAS to receive the information contained in a successful test response.
o 请求中的结果字段应设置为AckAll（0x2），以允许NAS接收成功测试响应中包含的信息。
o The Function field MUST be set to 9 (Remote Loopback). (The X-Function field continues to be 0.)
o 功能字段必须设置为9（远程环回）。（X函数字段继续为0。）
o The appended TLVs in the extension value field include testing-related TLVs rather than subscriber service information.
o 扩展值字段中附加的TLV包括测试相关的TLV，而不是订户服务信息。
The Port Management (OAM) message is illustrated in Figure 21.
端口管理（OAM）消息如图21所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (12 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=9 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Testing-related TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (12 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=9 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Testing-related TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this figure.
注：TLV的顺序可能与本图所示不同。
Figure 21: Port Management Message for DSL Line Remote Connectivity Testing
图21:DSL线路远程连接测试的端口管理消息
From the point of view of ANCP, it is permissible to attempt line connectivity testing regardless of the state of the line. However, testing could fail in some states due to technology limitations.
从ANCP的角度来看，无论线路的状态如何，都可以尝试进行线路连通性测试。然而，由于技术限制，测试可能会在某些州失败。
When requested by the NAS control application and presented with the necessary information to do so, the NAS-side agent creates and sends a Port Management (OAM) request with the fixed fields set as described in the previous section. The message MUST contain one or
当NAS控制应用程序请求并提供执行此操作所需的信息时，NAS端代理将创建并发送一个端口管理（OAM）请求，其中固定字段的设置如前一节所述。消息必须包含一个或多个
more TLVs to identify an access line according the requirements of Section 5.1.2. The NAS MAY include the Opaque-Data TLV and/or the OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to configure the loopback test for that line.
更多TLV，以根据第5.1.2节的要求确定接入线。NAS可能包括不透明数据TLV和/或OAM环回测试参数TLV（在第8.5节中定义），以配置该线路的环回测试。
The AN-side ANCP agent SHOULD validate each message against the specifications given in Section 8.3 and the TLV specifications given in Sections 5.1.2 and 8.5. If it finds an error it MUST return a Port Management response message that copies the Port Management request as it was received, but has the Result header field set to 0x04 (Failure) and the Result Code field set to the appropriate value. Result Code value 0x509 as described below MAY apply, as well as the other Result Code values documented in Section 3.6.1.4. Result Code value 0x509 SHOULD be used if the OAM-Loopback-Test-Parameters TLV is present with an invalid value of the Count field. The AN-side agent MAY add a Status-Info TLV (Section 4.5) to provide further information on the error, particularly if this is recommended in Section 3.6.1.4 for the given Result Code value. If it does so, the various length fields and the # of TLVs field within the message MUST be adjusted accordingly.
AN侧ANCP代理应根据第8.3节中给出的规范以及第5.1.2和8.5节中给出的TLV规范验证每条消息。如果发现错误，则必须返回端口管理响应消息，该消息在收到端口管理请求时复制该请求，但将结果标头字段设置为0x04（失败），并将结果代码字段设置为适当的值。结果代码值0x509（如下所述）可能适用，以及第3.6.1.4节中记录的其他结果代码值。如果OAM环回测试参数TLV的计数字段值无效，则应使用结果代码值0x509。AN侧代理可以添加状态信息TLV（第4.5节），以提供有关错误的进一步信息，特别是如果第3.6.1.4节建议针对给定结果代码值这样做。如果这样做，则必须相应地调整消息中的各种长度字段和#of TLVs字段。
If the received message passes validation, the AN-side ANCP agent extracts the information from the TLVs contained in the message and presents that information to the AN control application. It MUST NOT generate an immediate response to the request, but it MUST instead wait for the AN control application to indicate that the response should be sent.
如果接收到的消息通过验证，AN侧ANCP代理将从消息中包含的TLV中提取信息，并将该信息提供给AN控制应用程序。它不能生成对请求的即时响应，但必须等待控制应用程序指示应发送响应。
When requested by the AN control application and presented with the necessary information to do so, the AN-side agent creates and sends a Port Management (OAM) response to the original request. The Result field MUST be set to Success (0x3) or Failure (0x4), and the Result Code field SHOULD be set to one of the following values, as indicated by the AN control application.
当控制应用程序请求并提供执行此操作所需的信息时，AN端代理将创建端口管理（OAM）响应并发送给原始请求。结果字段必须设置为成功（0x3）或失败（0x4），结果代码字段应设置为以下值之一，如控制应用程序所示。
0x500: Specified access line does not exist. See the documentation of Result Code 0x500 in Section 3.6.1.4 for more information. The Result header field MUST be set to Failure (0x4).
0x500:指定的访问线不存在。有关更多信息，请参阅第3.6.1.4节中结果代码0x500的文档。结果标头字段必须设置为失败（0x4）。
0x501: Loopback test timed out. The Result header field MUST be set to Failure (0x4).
0x501:环回测试超时。结果标头字段必须设置为失败（0x4）。
0x503: DSL access line status showtime
0x503:DSL接入线路状态显示时间
0x504: DSL access line status idle
0x504:DSL接入线状态空闲
0x505: DSL access line status silent
0x505:DSL接入线状态静默
0x506: DSL access line status training
0x506:DSL接入线路状态培训
0x507: DSL access line integrity error
0x507:DSL接入线完整性错误
0x508: DSLAM resource not available. The Result header field MUST be set to Failure (0x04).
0x508:DSLAM资源不可用。结果标题字段必须设置为失败（0x04）。
0x509: Invalid test parameter. The Result header field MUST be set to Failure (0x4).
0x509:测试参数无效。结果标头字段必须设置为失败（0x4）。
All other fields of the request including the TLVs MUST be copied into the response unchanged, except that in a successful response the OAM-Loopback-Test-Parameters TLV MUST NOT appear. If the AN control application has provided the necessary information, the AN-side agent MUST also include an instance of the OAM-Loopback-Test-Response-String TLV in the response.
请求的所有其他字段（包括TLV）必须原封不动地复制到响应中，但在成功响应中，OAM环回测试参数TLV不得出现。如果A控制应用程序提供了必要的信息，则A端代理还必须在响应中包含OAM环回测试响应字符串TLV的实例。
The following TLVs have been defined for use with the DSL access line testing capability.
以下TLV已定义为与DSL接入线测试功能一起使用。
Type: 0x0007
类型：0x0007
Description: Parameters intended to override the default values for this loopback test.
描述：用于覆盖此环回测试的默认值的参数。
Length: 2 bytes
长度：2字节
Value: Two unsigned 1-byte fields described below (listed in order of most to least significant).
值：下面描述的两个无符号1字节字段（按从最高到最低有效的顺序列出）。
Byte 1: Count. Number of loopback cells/messages that should be generated on the local loop as part of the loopback test. The Count value SHOULD be greater than 0 and less than or equal to 32.
字节1：计数。作为环回测试的一部分，应在本地环路上生成的环回单元/消息数。计数值应大于0且小于或等于32。
Byte 2: Timeout. Upper bound on the time in seconds that the NAS will wait for a response from the DSLAM. The value 0 MAY be used to indicate that the DSLAM MUST use a locally determined value for the timeout.
字节2：超时。NAS等待DSLAM响应的时间上限（秒）。值0可用于指示DSLAM必须使用本地确定的超时值。
The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22.
OAM环回测试参数TLV如图22所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0007 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Timeout | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0007 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Timeout | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: The OAM-Loopback-Test-Parameters TLV
图22:OAM环回测试参数TLV
Type: 0x0008
类型：0x0008
Description: An 8-byte opaque field used by the NAS control application for its own purposes (e.g., response correlation). The procedures in Section 8.4.2 ensure that if it is present in the request it is copied unchanged to the response.
描述：NAS控制应用程序出于自身目的（如响应相关性）使用的8字节不透明字段。第8.4.2节中的程序确保，如果请求中存在，则将其复制到响应中，不作更改。
Length: 8 bytes
长度：8字节
Value: Two 32-bit unsigned integers.
值：两个32位无符号整数。
Type: 0x0009
类型：0x0009
Description: Suitably formatted string containing useful details about the test that the NAS will display for the operator, exactly as received from the DSLAM (no manipulation or interpretation by the NAS).
描述：适当格式化的字符串，包含NAS将向操作员显示的有关测试的有用详细信息，与从DSLAM接收的内容完全相同（NAS不进行操作或解释）。
Length: Up to 128 bytes
长度：最多128字节
Value: UTF-8 encoded string of text.
值：UTF-8编码的文本字符串。
This section documents the following IANA actions:
本节记录了以下IANA行动：
o establishment of the following new ANCP registries:
o 建立以下新的非国大登记处：
ANCP Message Types;
ANCP报文类型；
ANCP Result Codes;
ANCP结果码；
ANCP Port Management Functions;
港口管理职能；
ANCP Technology Types;
ANCP技术类型；
ANCP Command Codes;
ANCP命令码；
ANCP TLV Types;
ANCP-TLV型；
ANCP Capabilities.
ANCP能力。
o establishment of a new joint GSMP/ANCP version registry;
o 建立新的GSMP/ANCP联合版本登记册；
o addition of ANCP as another user of TCP port 6068 in the port number registry available from http://www.iana.org. The current user is GSMP.
o 在端口号注册表中添加ANCP作为TCP端口6068的另一个用户，可从http://www.iana.org. 当前用户是GSMP。
All of these actions are described in detail below except for the port registration, for which the final point above provides sufficient information.
下面将详细描述所有这些操作，但端口注册除外，上面的最后一点提供了足够的信息。
IANA has created a new registry, ANCP Message Types. Additions to that registry are permitted by Standards Action, as defined by [RFC5226]. The values for Message Type MAY range from 0 to 255, but new Message Types SHOULD be assigned values sequentially from 90 onwards (noting that 91 and 93 are already assigned). The initial contents of the ANCP Message Types registry are as follows:
IANA创建了一个新的注册表ANCP消息类型。[RFC5226]定义的标准行动允许添加到该注册表中。消息类型的值可能在0到255之间，但新消息类型应从90开始依次赋值（注意，91和93已经赋值）。ANCP消息类型注册表的初始内容如下：
+--------------+--------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------+-----------+
| 10 | Adjacency Protocol | RFC 6320 |
| 32 | Port Management | RFC 6320 |
| 80 | Port Up | RFC 6320 |
| 81 | Port Down | RFC 6320 |
| 85 | Adjacency Update | RFC 6320 |
| 91 | Generic Response | RFC 6320 |
| 93 | Provisioning | RFC 6320 |
+--------------+--------------------+-----------+
+--------------+--------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------+-----------+
| 10 | Adjacency Protocol | RFC 6320 |
| 32 | Port Management | RFC 6320 |
| 80 | Port Up | RFC 6320 |
| 81 | Port Down | RFC 6320 |
| 85 | Adjacency Update | RFC 6320 |
| 91 | Generic Response | RFC 6320 |
| 93 | Provisioning | RFC 6320 |
+--------------+--------------------+-----------+
IANA has created a new registry, ANCP Result Codes. The documentation of new Result Codes MUST include the following information:
IANA创建了一个新的注册表，ANCP结果代码。新结果代码的文件必须包括以下信息：
o Result Code value (as assigned by IANA);
o 结果代码值（由IANA指定）；
o One-line description;
o 一行描述；
o Where condition detected (control application or ANCP agent);
o 如果检测到条件（控制应用程序或ANCP代理）；
o Further description (if any);
o 进一步说明（如有）；
o Required additional information in the response message;
o 响应消息中所需的附加信息；
o Target (control application or ANCP agent at the peer that sent the original request);
o 目标（发送原始请求的对等方的控制应用程序或ANCP代理）；
o Action RECOMMENDED for the receiving ANCP agent.
o 建议接收ANCP代理的行动。
The values for Result Code are expressed in hexadecimal and MAY range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is allocated by the criterion of IETF Review, as defined by [RFC5226]. IANA SHOULD allocate new Result Code values from this range sequentially beginning at 0x100. The range 0x1000 onwards is allocated by the criterion of Specification Required, as defined by [RFC5226]. IANA SHOULD allocate new Result Code values from this range sequentially beginning at 0x1000. The initial contents of the ANCP Message Types registry are as follows:
结果代码的值以十六进制表示，范围从0x0到0xFFFF。范围0x0到0xFFF由[RFC5226]定义的IETF评审标准分配。IANA应从0x100开始按顺序从此范围分配新的结果代码值。0x1000以上的范围由[RFC5226]定义的所需规范标准分配。IANA应从0x1000开始按顺序从此范围分配新的结果代码值。ANCP消息类型注册表的初始内容如下：
+------------+------------------------------------------+-----------+
| Result | One-line description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x0 | No result | RFC 6320 |
| 0x2 | Invalid request message | RFC 6320 |
| 0x6 | One or more of the specified ports are | RFC 6320 |
| | down | |
| 0x13 | Out of resources | RFC 6320 |
| 0x51 | Request message type not implemented | RFC 6320 |
| 0x53 | Malformed message | RFC 6320 |
| 0x54 | Mandatory TLV missing | RFC 6320 |
| 0x55 | Invalid TLV contents | RFC 6320 |
| 0x500 | One or more of the specified ports do | RFC 6320 |
| | not exist | |
| 0x501 | Loopback test timed out | RFC 6320 |
| 0x502 | Reserved | RFC 6320 |
| 0x503 | DSL access line status showtime | RFC 6320 |
| 0x504 | DSL access line status idle | RFC 6320 |
| 0x505 | DSL access line status silent | RFC 6320 |
| 0x506 | DSL access line status training | RFC 6320 |
| 0x507 | DSL access line integrity error | RFC 6320 |
| 0x508 | DSLAM resource not available | RFC 6320 |
| 0x509 | Invalid test parameter | RFC 6320 |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Result | One-line description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x0 | No result | RFC 6320 |
| 0x2 | Invalid request message | RFC 6320 |
| 0x6 | One or more of the specified ports are | RFC 6320 |
| | down | |
| 0x13 | Out of resources | RFC 6320 |
| 0x51 | Request message type not implemented | RFC 6320 |
| 0x53 | Malformed message | RFC 6320 |
| 0x54 | Mandatory TLV missing | RFC 6320 |
| 0x55 | Invalid TLV contents | RFC 6320 |
| 0x500 | One or more of the specified ports do | RFC 6320 |
| | not exist | |
| 0x501 | Loopback test timed out | RFC 6320 |
| 0x502 | Reserved | RFC 6320 |
| 0x503 | DSL access line status showtime | RFC 6320 |
| 0x504 | DSL access line status idle | RFC 6320 |
| 0x505 | DSL access line status silent | RFC 6320 |
| 0x506 | DSL access line status training | RFC 6320 |
| 0x507 | DSL access line integrity error | RFC 6320 |
| 0x508 | DSLAM resource not available | RFC 6320 |
| 0x509 | Invalid test parameter | RFC 6320 |
+------------+------------------------------------------+-----------+
IANA has created a new ANCP Port Management Function registry, with the following initial entries. Additions to this registry will be by Standards Action, as defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD assign values sequentially beginning with 1, taking account of the values already assigned below.
IANA创建了一个新的ANCP端口管理功能注册表，初始条目如下。按照[RFC5226]的定义，将通过标准行动向该注册中心添加内容。值的范围从0到255。IANA应考虑到下面已经分配的值，从1开始依次分配值。
NOTE: Future extensions of ANCP may need to establish sub-registries of permitted X-Function values for specific values of Function.
注：ANCP的未来扩展可能需要为特定功能值建立允许X功能值的子注册表。
+----------------+-----------------------------------+-----------+
| Function Value | Function Name | Reference |
+----------------+-----------------------------------+-----------+
| 0 | Reserved | RFC 6320 |
| 8 | Configure Connection Service Data | RFC 6320 |
| 9 | Remote Loopback | RFC 6320 |
+----------------+-----------------------------------+-----------+
+----------------+-----------------------------------+-----------+
| Function Value | Function Name | Reference |
+----------------+-----------------------------------+-----------+
| 0 | Reserved | RFC 6320 |
| 8 | Configure Connection Service Data | RFC 6320 |
| 9 | Remote Loopback | RFC 6320 |
+----------------+-----------------------------------+-----------+
IANA has created a new ANCP Technology Type registry, with additions by Expert Review, as defined by [RFC5226]. The Technology Type MUST designate a distinct access transport technology. Values may range from 0 to 255. IANA SHOULD assign new values sequentially beginning at 2, taking into account of the values already assigned below. The initial entries are as follows:
IANA已经创建了一个新的ANCP技术类型登记册，并根据[RFC5226]的定义，通过专家评审进行了添加。技术类型必须指定不同的访问传输技术。值的范围从0到255。IANA应从2开始按顺序分配新值，同时考虑以下已分配的值。初始条目如下：
+-----------------+-------------------------------+-----------+
| Tech Type Value | Tech Type Name | Reference |
+-----------------+-------------------------------+-----------+
| 0 | Not technology dependent | RFC 6320 |
| 1 | Passive Optical Network (PON) | RFC 6320 |
| 5 | Digital Subscriber Line (DSL) | RFC 6320 |
| 255 | Reserved | RFC 6320 |
+-----------------+-------------------------------+-----------+
+-----------------+-------------------------------+-----------+
| Tech Type Value | Tech Type Name | Reference |
+-----------------+-------------------------------+-----------+
| 0 | Not technology dependent | RFC 6320 |
| 1 | Passive Optical Network (PON) | RFC 6320 |
| 5 | Digital Subscriber Line (DSL) | RFC 6320 |
| 255 | Reserved | RFC 6320 |
+-----------------+-------------------------------+-----------+
IANA has created a new ANCP Command Code registry, with additions by Standards Action, as defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD assign new values sequentially beginning with 1. The initial entry is as follows:
IANA已经创建了一个新的ANCP命令代码注册表，并按照[RFC5226]的定义，添加了标准操作。值的范围从0到255。IANA应该从1开始按顺序分配新值。初始条目如下：
+--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+
| 0 | Reserved | RFC 6320 |
+--------------------+-----------------------------+-----------+
+--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+
| 0 | Reserved | RFC 6320 |
+--------------------+-----------------------------+-----------+
IANA has created a new ANCP TLV Type registry. Values are expressed in hexadecimal and may range from 0x0000 to 0xFFFF. Additions in the range 0x0000 to 0x1FFF are by IETF Review, as defined by [RFC5226]. IANA SHOULD assign new values in this range sequentially beginning at 0x100, taking account of the assignments already made below. Additions in the range 0x2000 to 0xFFFF are by Specification Required, again as defined by [RFC5226]. IANA SHOULD assign new values in this range sequentially beginning at 0x2000. In both cases, the documentation of the TLV MUST provide:
IANA已经创建了一个新的ANCP TLV类型注册表。值以十六进制表示，范围从0x0000到0xFFFF。按照[RFC5226]的定义，范围0x0000至0x1FF的新增内容由IETF审查。IANA应该从0x100开始按顺序分配此范围内的新值，同时考虑到下面已经进行的分配。根据规范要求，0x2000至0xFFFF范围内的添加也是由[RFC5226]定义的。IANA应该从0x2000开始按顺序分配此范围内的新值。在这两种情况下，TLV的文件必须提供：
o a TLV name following the convention used for the initial entries (capitalized words separated by hyphens);
o 遵循用于初始条目的约定的TLV名称（用连字符分隔的大写单词）；
o a brief description of the intended use;
o 对预期用途的简要说明；
o a precise description of the contents of each fixed field, including its length, type, and units (if applicable);
o 每个固定字段内容的精确描述，包括其长度、类型和单位（如适用）；
o identification of any mandatory encapsulated TLVs;
o 任何强制性封装TLV的标识；
o an indication of whether optional TLVs may be encapsulated, with whatever information is available on their identity (could range from a general class of information to specific TLV names, depending on the nature of the TLV being defined).
o 指示是否可以封装可选的TLV，以及关于其标识的任何可用信息（根据定义的TLV的性质，可以从一般信息类到特定的TLV名称）。
The initial entries are as follows:
初始条目如下：
+----------+--------------------------------------------+-----------+
| Type Code| TLV Name | Reference |
+----------+--------------------------------------------+-----------+
| 0x0000 | Reserved | RFC 6320 |
| 0x0001 | Access-Loop-Circuit-ID | RFC 6320 |
| 0x0002 | Access-Loop-Remote-ID | RFC 6320 |
| 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFC 6320 |
| 0x0004 | DSL-Line-Attributes | RFC 6320 |
| 0x0005 | Service-Profile-Name | RFC 6320 |
| 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFC 6320 |
| 0x0007 | OAM-Loopback-Test-Parameters | RFC 6320 |
| 0x0008 | Opaque-Data | RFC 6320 |
| 0x0009 | OAM-Loopback-Test-Response-String | RFC 6320 |
| 0x0011 | Command | RFC 6320 |
| 0x0081 | Actual-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0082 | Actual-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0083 | Minimum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0084 | Minimum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0085 | Attainable-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0086 | Attainable-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0087 | Maximum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0088 | Maximum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstream | RFC 6320 |
| 0x008A | Minimum-Net-Low-Power-Data-Rate-Downstream | RFC 6320 |
| 0x008B | Maximum-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008C | Actual-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008D | Maximum-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008E | Actual-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008F | DSL-Line-State | RFC 6320 |
| 0x0090 | Access-Loop-Encapsulation | RFC 6320 |
| 0x0091 | DSL-Type | RFC 6320 |
| 0x0106 | Status-Info | RFC 6320 |
| 0x1000 | Target (single access line variant) | RFC 6320 |
| 0x1001 - | Reserved for Target variants | RFC 6320 |
| 0x1020 | | |
+----------+--------------------------------------------+-----------+
+----------+--------------------------------------------+-----------+
| Type Code| TLV Name | Reference |
+----------+--------------------------------------------+-----------+
| 0x0000 | Reserved | RFC 6320 |
| 0x0001 | Access-Loop-Circuit-ID | RFC 6320 |
| 0x0002 | Access-Loop-Remote-ID | RFC 6320 |
| 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFC 6320 |
| 0x0004 | DSL-Line-Attributes | RFC 6320 |
| 0x0005 | Service-Profile-Name | RFC 6320 |
| 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFC 6320 |
| 0x0007 | OAM-Loopback-Test-Parameters | RFC 6320 |
| 0x0008 | Opaque-Data | RFC 6320 |
| 0x0009 | OAM-Loopback-Test-Response-String | RFC 6320 |
| 0x0011 | Command | RFC 6320 |
| 0x0081 | Actual-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0082 | Actual-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0083 | Minimum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0084 | Minimum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0085 | Attainable-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0086 | Attainable-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0087 | Maximum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0088 | Maximum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstream | RFC 6320 |
| 0x008A | Minimum-Net-Low-Power-Data-Rate-Downstream | RFC 6320 |
| 0x008B | Maximum-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008C | Actual-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008D | Maximum-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008E | Actual-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008F | DSL-Line-State | RFC 6320 |
| 0x0090 | Access-Loop-Encapsulation | RFC 6320 |
| 0x0091 | DSL-Type | RFC 6320 |
| 0x0106 | Status-Info | RFC 6320 |
| 0x1000 | Target (single access line variant) | RFC 6320 |
| 0x1001 - | Reserved for Target variants | RFC 6320 |
| 0x1020 | | |
+----------+--------------------------------------------+-----------+
IANA has created a new ANCP Capability Type registry, with additions by Standards Action as defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD assign values sequentially beginning at 5. The specification for a given capability MUST indicate the Technology Type value with which it is associated. The specification MUST further indicate whether the capability is associated with any capability data. Normally, a capability is expected to be defined in the same document that specifies the implementation of that capability in protocol terms. The initial entries in the ANCP capability registry are as follows:
IANA已经创建了一个新的ANCP能力类型注册表，并根据[RFC5226]定义的标准行动进行了添加。值的范围从0到255。IANA应该从5开始按顺序赋值。给定能力的规范必须指明与其关联的技术类型值。规范必须进一步指出能力是否与任何能力数据相关联。通常情况下，功能应在同一文档中定义，该文档以协议的形式指定该功能的实现。ANCP能力注册表中的初始条目如下：
+-------+------------------------+--------+-------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+------------------------+--------+-------------+-----------+
| 0 | Reserved | | | RFC 6320 |
| 1 | DSL Topology Discovery | 5 | No | RFC 6320 |
| 2 | DSL Line Configuration | 5 | No | RFC 6320 |
| 3 | Reserved | | | RFC 6320 |
| 4 | DSL Line Testing | 5 | No | RFC 6320 |
+-------+------------------------+--------+-------------+-----------+
+-------+------------------------+--------+-------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+------------------------+--------+-------------+-----------+
| 0 | Reserved | | | RFC 6320 |
| 1 | DSL Topology Discovery | 5 | No | RFC 6320 |
| 2 | DSL Line Configuration | 5 | No | RFC 6320 |
| 3 | Reserved | | | RFC 6320 |
| 4 | DSL Line Testing | 5 | No | RFC 6320 |
+-------+------------------------+--------+-------------+-----------+
IANA has created a new joint GSMP / ANCP Version registry. Additions to this registry are by Standards Action as defined by [RFC5226]. Values may range from 0 to 255. Values for the General Switch Management Protocol (GSMP) MUST be assigned sequentially beginning with 4 for the next version. Values for the Access Network Control Protocol (ANCP) MUST be assigned sequentially beginning with 50 for the present version. The initial entries are as follows:
IANA已经创建了一个新的GSMP/ANCP联合版本注册表。根据[RFC5226]中定义的标准行动向该注册表添加内容。值的范围从0到255。通用交换机管理协议（GSMP）的值必须从下一版本的4开始依次分配。对于当前版本，访问网络控制协议（ANCP）的值必须从50开始依次分配。初始条目如下：
+---------+----------------+-----------+
| Version | Description | Reference |
+---------+----------------+-----------+
| 1 | GSMP Version 1 | RFC 1987 |
| 2 | GSMP Version 2 | RFC 2297 |
| 3 | GSMP Version 3 | RFC 3292 |
| 50 | ANCP Version 1 | RFC 6320 |
+---------+----------------+-----------+
+---------+----------------+-----------+
| Version | Description | Reference |
+---------+----------------+-----------+
| 1 | GSMP Version 1 | RFC 1987 |
| 2 | GSMP Version 2 | RFC 2297 |
| 3 | GSMP Version 3 | RFC 3292 |
| 50 | ANCP Version 1 | RFC 6320 |
+---------+----------------+-----------+
Security of ANCP is discussed in [RFC5713]. A number of security requirements on ANCP are stated in Section 8 of that document. Those applicable to ANCP itself are copied to the present document:
[RFC5713]中讨论了ANCP的安全性。该文件第8节规定了ANCP的一些安全要求。适用于ANCP本身的文件复制到本文件中：
o The protocol solution MUST offer authentication of the AN to the NAS.
o 协议解决方案必须向NAS提供AN的身份验证。
o The protocol solution MUST offer authentication of the NAS to the AN.
o 协议解决方案必须向AN提供NAS身份验证。
o The protocol solution MUST allow authorization to take place at the NAS and the AN.
o 协议解决方案必须允许在NAS和AN上进行授权。
o The protocol solution MUST offer replay protection.
o 协议解决方案必须提供重播保护。
o The protocol solution MUST provide data-origin authentication.
o 协议解决方案必须提供数据源身份验证。
o The protocol solution MUST be robust against denial-of-service (DoS) attacks. In this context, the protocol solution MUST consider a specific mechanism for the DoS that the user might create by sending many IGMP messages.
o 协议解决方案必须能够抵御拒绝服务（DoS）攻击。在这种情况下，协议解决方案必须考虑通过发送许多IGMP消息来为用户创建的DOS的特定机制。
o The protocol solution SHOULD offer confidentiality protection.
o 协议解决方案应提供保密保护。
o The protocol solution SHOULD ensure that operations in default configuration guarantee a low number of AN/NAS protocol interactions.
o 协议解决方案应确保默认配置中的操作可保证低数量的AN/NAS协议交互。
Most of these requirements relate to secure transport of ANCP. Robustness against denial-of-service attacks partly depends on transport and partly on protocol design. Ensuring a low number of AN/NAS protocol interactions in default mode is purely a matter of protocol design.
这些要求大多与ANCP的安全运输有关。对拒绝服务攻击的鲁棒性部分取决于传输，部分取决于协议设计。在默认模式下确保低数量的AN/NAS协议交互纯粹是协议设计的问题。
For secure transport, either the combination of IPsec with IKEv2 (references below) or the use of TLS [RFC5246] will meet the requirements listed above. However, the use of TLS has been rejected. The deciding point is a detail of protocol design that was unavailable when [RFC5713] was written. The ANCP adjacency is a major point of vulnerability for denial-of-service attacks. If the adjacency can be shut down, either the AN clears its state pending reestablishment of the adjacency, or the possibility of mismatches between the AN's and NAS's view of state on the AN is opened up. Two ways to cause an adjacency to be taken down are to modify messages so that the ANCP agents conclude that they are no longer synchronized, or to attack the underlying TCP session. TLS will protect message contents but not the TCP connection. One has to use either IPsec or the TCP authentication option [RFC5925] for that. Hence, the conclusion that ANCP MUST run over IPsec with IKEv2 for authentication and key management.
对于安全传输，IPsec与IKEv2的组合（参考下文）或TLS[RFC5246]的使用将满足上述要求。然而，TLS的使用已被拒绝。决定点是在编写[RFC5713]时不可用的协议设计细节。ANCP邻接是拒绝服务攻击的一个主要漏洞。如果邻接可以关闭，则AN会清除其状态，等待邻接的重新建立，或者AN上的AN和NAS状态视图之间可能存在不匹配。有两种方法可以消除相邻关系，即修改消息，使ANCP代理断定它们不再同步，或者攻击底层TCP会话。TLS将保护消息内容，但不会保护TCP连接。为此，必须使用IPsec或TCP身份验证选项[RFC5925]。因此，ANCP必须使用IKEv2在IPsec上运行以进行身份验证和密钥管理的结论。
In greater detail: the ANCP stack MUST include IPsec [RFC4301] running in transport mode, since the AN and NAS are the endpoints of the path. The Encapsulating Security Payload (ESP) [RFC4303] MUST be used, in order to satisfy the requirement for data confidentiality. ESP MUST be configured for the combination of confidentiality, integrity, and anti-replay capability. The traffic flow confidentiality service of ESP is unnecessary and, in fact, unworkable in the case of ANCP.
更详细地说：ANCP堆栈必须包括在传输模式下运行的IPsec[RFC4301]，因为AN和NAS是路径的端点。必须使用封装安全有效负载（ESP）[RFC4303]，以满足数据机密性要求。ESP必须配置为机密性、完整性和防重播功能的组合。ESP的交通流保密服务是不必要的，事实上，在ANCP的情况下是不可行的。
IKEv2 [RFC5996] is also REQUIRED, to meet the requirements for mutual authentication and authorization. Since the NAS and AN MAY be in different trust domains, the use of certificates for mutual authentication could be the most practical approach. However, this is up to the operator(s) concerned.
还需要IKEv2[RFC5996]，以满足相互认证和授权的要求。由于NAS和AN可能位于不同的信任域中，因此使用证书进行相互身份验证可能是最实际的方法。然而，这取决于相关运营商。
The AN MUST play the role of initiator of the IKEv2 conversation.
AN必须扮演IKEv2对话的发起人角色。
Swami Subramanian was an early member of the authors' team. The ANCP Working Group is grateful to Roberta Maglione, who served as design team member and primary editor of this document for two years before stepping down.
Swami Subramanian是作者团队的早期成员。ANCP工作组感谢Roberta Maglione，她在卸任前担任设计团队成员和本文件主要编辑两年。
The authors would like to thank everyone who provided comments or inputs to this document. The authors acknowledge the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic, and the further comments provided by Mykyta Yevstifeyev, Brian Carter, Ben Campbell, Alexey Melnikov, Adrian Farrel, Robert Sparks, Peter St. Andre, Sean Turner, Dan Romascanu, Brian Carter, and Michael Scott.
作者要感谢为本文件提供评论或意见的所有人。作者感谢Wojciech Dec、Peter Arberg、Josef Froehler、Derek Harkness、Kim Hydgaard、Sandy Ng、Robert Peschi和Michel Platnic提供的投入，以及Mykyta Yevstifeyev、Brian Carter、Ben Campbell、Alexey Melnikov、Adrian Farrel、Robert Sparks、Peter St.Andre、Sean Turner和Romascanu提供的进一步评论，布莱恩·卡特和迈克尔·斯科特。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
[RFC3292]Doria，A.，Hellstrand，F.，Sundell，K.，和T.Worster，“通用交换机管理协议（GSMP）V3”，RFC 3292，2002年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[G.993.2] "ITU-T Recommendation G.993.2, Very high speed digital subscriber line transceivers 2 (VDSL2)", 2006.
[G.993.2]“ITU-T建议G.993.2，甚高速数字用户线收发器2（VDSL2）”，2006年。
[G.998.1] "ITU-T Recommendation G.998.1, ATM-based multi-pair bonding", 2005.
[G.998.1]“ITU-T建议G.998.1，基于ATM的多对键合”，2005年。
[G.998.2] "ITU-T Recommendation G.998.2, Ethernet-based multi-pair bonding,", 2005.
[G.998.2]“ITU-T建议G.998.2，基于以太网的多对连接”，2005年。
[IEEE802.1Q] IEEE, "IEEE 802.1Q-2005, IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Revision", 2005.
[IEEE802.1Q]IEEE，“IEEE 802.1Q-2005，IEEE局域网和城域网标准-虚拟桥接局域网-修订版”，2005年。
[IEEE802.1ad] IEEE, "IEEE 802.1ad-2005, Amendment to IEEE 802.1Q-2005. IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Revision - Amendment 4: Provider Bridges", 2005.
[IEEE802.1ad]IEEE，“IEEE 802.1ad-2005，对IEEE 802.1Q-2005的修订。局域网和城域网IEEE标准-虚拟桥接局域网-修订版-修订件4：提供商网桥”，2005年。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649]Volz，B.，“IPv6（DHCPv6）中继代理远程ID选项的动态主机配置协议”，RFC 4649，2006年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5713]Moustafa，H.，Tschofenig，H.，和S.De Cnodder，“接入节点控制协议（ANCP）的安全威胁和安全要求”，RFC 5713，2010年1月。
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010.
[RFC5851]Ooghe，S.，Voigt，N.，Platnic，M.，Haag，T.，和S.Wadhwa，“宽带多业务网络中接入节点控制机制的框架和要求”，RFC 58512010年5月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[TR-058] Broadband Forum, "TR-058, Multi-Service Architecture & Framework Requirements", September 2003.
[TR-058]宽带论坛，“TR-058，多业务架构和框架要求”，2003年9月。
[TR-059] Broadband Forum, "TR-059, DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", September 2003.
[TR-059]宽带论坛，“TR-059，DSL演进-支持QoS支持IP服务的架构要求”，2003年9月。
[TR-092] Broadband Forum, "TR-092, Broadband Remote access server requirements document", 2005.
[TR-092]宽带论坛，“TR-092，宽带远程访问服务器要求文件”，2005年。
[TR-101] Broadband Forum, "TR-101, Architecture & Transport: Migration to Ethernet Based DSL Aggregation", 2005.
[TR-101]宽带论坛，“TR-101，体系结构与传输：迁移到基于以太网的DSL聚合”，2005年。
[TR-147] Broadband Forum, "TR-147, Layer 2 Control Mechanism For Broadband Multi-Service Architectures", 2008.
[TR-147]宽带论坛，“TR-147，宽带多业务架构的第2层控制机制”，2008年。
[US_ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X.34, 1986.
[US_ASCII]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X.341986。
Authors' Addresses
作者地址
Sanjay Wadhwa Alcatel-Lucent 701 E Middlefield Rd Mountain View, CA 94043-4079 USA
美国加利福尼亚州米德尔菲尔德山景大道东701号桑杰·瓦德瓦阿尔卡特朗讯94043-4079
EMail: sanjay.wadhwa@alcatel-lucent.com
EMail: sanjay.wadhwa@alcatel-lucent.com
Jerome Moisand Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA
美国马萨诸塞州韦斯特福德科技园大道10号Jerome Moisand Juniper Networks邮编：01886
EMail: jmoisand@juniper.net
EMail: jmoisand@juniper.net
Thomas Haag Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany
托马斯·哈格德国电信海因里希·赫兹大街3-7号达姆施塔特64295德国
EMail: haagt@telekom.de
EMail: haagt@telekom.de
Norbert Voigt Nokia Siemens Networks Siemensallee 1 Greifswald 17489 Germany
诺伯特·沃伊特诺基亚西门子网络西门萨尔1格雷夫斯瓦尔德17489德国
EMail: norbert.voigt@nsn.com
EMail: norbert.voigt@nsn.com
Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave Ottawa Canada
汤姆泰勒（编辑）华为技术1852加拿大渥太华洛林大道
EMail: tom111.taylor@bell.net
EMail: tom111.taylor@bell.net