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ためのユースケースは、この文書は、デジタル加入者線（DSL）、トポロジディスカバリ、ライン構成、およびリモート回線接続テストのための機能を指定し、RFC 5851.と同様にベースANCPプロトコルを説明する際に文書化されています。それらは他のユースケースと他のアクセス技術をサポートするために必要な場合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は、一般的なスイッチ管理プロトコルバージョン3（GSMPv3）に基づいて2つのプロトコルが相互運用可能ではないことをポイントに、RFC 3292ではなく、多くの修正および機能拡張して説明。このため、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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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
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アクセス・ノード（例えば、デジタル加入者回線との間の制御プレーンを実現しますサービスの品質（QoS）、サービス、およびサブスクリプションに関連する業務を行うためにアクセスマルチプレクサ、DSLAM）。 ANCPの要件と、それが動作するコンテキストは、[RFC5851]に記載されています。
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) | |
| +----------------+ | | +----------------+ |
+--------------------+ +--------------------+
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トランスポートを指定します。 3.2節で定義されているようANCPのTCPカプセル化があります。
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が複数のテクノロジにまたがる複数の機能が使用するためのもの。
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と3次のセクションでは説明し、DSLアクセス技術の制御に適用される3つの機能の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].
[RFC5713]に記載された要件で始まるANCPに関連するOセクション11個のアドレスのセキュリティの考慮事項、。
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憲章は、これらの実装に基づいて、そのプロトコルを開発するためのワーキンググループを必要としました。最後に、ANCPは、2つのプロトコルが相互運用可能ではないことを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が終了した時点で、ために既存の実装の決定を覆すには遅すぎました。その結果、すぐに最初の隣接交渉中にGSMPからANCPを区別するANCPピアのための方法を持っていることが必要です。これは、GSMPとANCPバージョン番号の共同レジストリによって提供されています。 GSMPは、最初のバージョン番号50を持つ3 ANCPてバージョン番号1を有しています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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能力は、ちょうど1アクセス技術にも適用可能です。与えられた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）：3.6節で説明したように16ビットのタイプフィールドからなるデータ構造は、16ビットの長さフィールド、および可変長値フィールドは、最も近い32ビットワード境界にパディング0.2。 TLVの値フィールドは、他のTLVを含めることができます。 IANAレジストリはANCP TLVのTypeフィールドの値が維持されます。
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（トランスポートプロトコルは、特定 - 送信収束）カプセル化。これは64/65カプセル化のためのATMのカプセル化と非ゼロはゼロです。
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によって定義されています。これは、リード・ソロモンとトレリス符号を含む完全なオーバーヘッドが含まれています。
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.
その主な機能は、顧客構内とNSPまたはASPとの間のエンドツーエンドのトランスポートを提供することにある図2に示すように、地域/アクセス・ネットワークは、地域ネットワーク、ネットワークアクセスサーバ（NAS）、アクセスネットワークから成ります。
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の）イーサネット上のPPP（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 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.
集約を超えて、NASは、地域/アクセスネットワークにおけるポリシー管理およびIP QoSの実施ポイントです。複数のレイヤ2つのQoSクラスを使用せずに、既存の非IP対応のレイヤ2アクセスネットワークを介したIP QoSサポートを可能にするには、階層的なスケジューリングに基づくメカニズムが使用されています。 [TR-059]で定義され、このメカニズムは、IP QoSはそのように重要なキューイング、注意深くNASでダウンストリームトラフィックを制御することにより、加入者ネットワークのエッジでNASおよびルーティングゲートウェイ（RG）との間にATMネットワーク上で保存および輻輳がATMネットワークダウン遠く発生しません。これは、下流のトランク帯域幅およびDSL同期率を占めることになるNASでのDiffservを意識した階層的なスケジューラを使用することによって達成されます。
[RFC5851] provides detailed definitions of the functions of each network element in the broadband reference architecture.
[RFC5851]は、広帯域参照アーキテクチャの各ネットワーク要素の機能の詳細な定義を提供します。
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
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].
イーサネットアグリゲーションネットワークアーキテクチャは、イーサネットブリッジ上に構築/イーサネットアグリゲーションネットワークは、トラフィックアグリゲーション、サービス区別のクラス、および顧客の分離及びトレーサビリティを提供するIEEE 802で定義された概念を切り替えます。 [IEEE802.1Q]及び[IEEE802.1ad]によって拡張で定義されたVLANタグは、イーサネットアグリゲーションネットワークにおける標準的な仮想化機構として使用されます。集約装置は、[IEEE802.1ad]で定義された「プロバイダ・エッジ・ブリッジ」です。
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" 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.
積み重ねられたVLANタグがアグリゲーションネットワークにおける「仮想パス」と「仮想回路」に相当するものを作成するための1つの可能な方法を提供します。 「外側」VLANは、所与のDSLAMと所定のNASの間の「仮想パス」のフォームを作成するために使用することができます。 「インナー」VLANタグごとのDSL回線毎に「仮想回線」のフォームを作成します。 1 VLAN割り当てモデル：これは1です。代替モデルは、アグリゲーションネットワークにおける単一のVLANにDSLAMの背後に複数の加入者からのセッションを埋めることです。これは、N：1 VLAN割り当てモデル。 2.5.1は、より詳細にそれらを説明しながら、[TR-101]の1.6節では、これら二つのモデルの簡単な定義を提供します。
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.
この文書では、ANCPメッセージの輸送のためのTCP / IPsecの+のIKEv2 / IPの使用を指定します。 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アクセスの場合には、制御チャネルであり、IPを輸送することができる別個の固定接続（PVC）はANCPメッセージにNASとANとの間に構成されるかもしれません。
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上で輸送すると、図3に示すように、ANCPメッセージは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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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によって提供されているすべてのANのためのNAS上の静的アドレスのプロビジョニングを回避する必要があります。 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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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セッションの間、一定です。タイマフィールド250（即ち、25秒）のデフォルト値を用いて、100ミリ秒の単位で指定されています。
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ビット）：他のANとの同期から別のNASとANとの同期からNASを防止するために、SYNメッセージで使用されます。 SYNメッセージに、それは常にANによってNASによって0に1に設定されています。他の隣接メッセージタイプでは、常に送信者によって0に設定され、受信機で無視します。
Code (7 bits): The adjacency protocol message type. It MUST have one of the following values:
コード（7ビット）：隣接プロトコルメッセージタイプ。これは、次のいずれかの値を持っている必要があります。
Code = 1: SYN;
コード= 1：SYN。
Code = 2: SYNACK;
コード= 2：SYNACK。
Code = 3: ACK;
コード= 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（Media Access Control）アドレス、可能な場合は、送信者名のために使用することができます。イーサネットカプセル化を使用する場合は、送信者名は、MACヘッダから送信元アドレスでなければなりません。 RSTACKメッセージを、送信者名フィールドはRSTACKメッセージが生成される原因となった着信メッセージから受信Nameフィールドの値に設定されています。
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.
P型（4ビット）：p型はパーティションが使用され、どのパーティション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メッセージは、ピアへのリンクのための送信者のインスタンス番号です。リンクは、リンクの変更のもう一方の端に下って行くとき、またはエンティティのID後に戻ってくるときを検出するために使用されます。インスタンス番号は、最近の過去内で一意であること、およびリンクまたはノードがダウン後に戻ったときに変更することが保証されて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の特定のパーティションのメッセージを関連付けるために使用されます。このフィールドの値は、隣接手順の間で交渉されます。 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メッセージを、受信インスタンスフィールドはRSTACKメッセージが生成される原因となった受信メッセージから送信者インスタンスフィールドの値に設定されています。
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.
キャップ（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.
能力フィールド：各機能のフィールドが隣接メッセージの送信者でサポートされている1つの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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
能力の長さ（16ビット）：パディングを除く能力データサブフィールドに含まれるデータのバイト数。特定の機能の定義がない能力データを含まない場合、能力長さサブフィールドの値はゼロです。
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.
能力データ（能力の長さによって示されるように）その能力のために指定されるように能力に関連するデータを含みます。特定の機能の定義がない能力データを含まない場合、能力データサブフィールドが存在しない（ゼロの長さを有します）。必要に応じてそれ以外の場合は、能力データサブフィールドは、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
能力データ：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
能力データ：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
能力データ：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隣接手順は、特定のNASは、結合またはそのパーティションに隣接関係を失ったときに同じパーティションを制御する他のNASに通知するために、隣接更新メッセージ（図6）を使用します。
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:
隣接Updateメッセージは、セクション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ビット）：ANの観点から、現在このパーティションに確立された隣接の合計数に設定します。
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 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.
ANCP隣接プロトコルはNASとANとの間に対称的に動作します。エラーまたは競合状態が存在しない状態で、各ピアは、SYNメッセージを送信し、確認応答にSYNACKメッセージを受信し、ACKメッセージを送信することにより、隣接の確立を完了する。この交換により、各ピアは他のピアを識別する名前、ポートの値、およびインスタンス・パラメータを学習し、2つのピアが版、タイマ、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.
隣接関係が確立されると、その生存性を定期的にテストされます。ピアはTimerフィールドのネゴシエートされた値によって決定される周波数で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手順「のリンクをリセット」を次のように定義されます
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.（以前は「レコード隣接状態」の操作によって記憶された送信者インスタンス、送信元ポート、および送信者名の値をゼロに設定）ピア検証を削除します。
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.
「&&」論理AND演算を表します。
"||" 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メッセージを定期的に生成するために必要とされます。タイマーの値は、Timerフィールドで交渉されます。タイマーの期間が指定されていないが、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
状態= SYNSENTは、SYNを送信した場合
If state = SYNRCVD Send SYNACK
状態= SYNRCVDはSYNACKを送信した場合
If state = ESTAB Send ACK
状態= ESTABはACKを送信した場合
Packet Arrives:
パケットが到着します。
If incoming message is an RSTACK:
受信メッセージはRSTACKの場合：
If (A && C && !SYNSENT) Reset the link
（&& 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)
状態= SYNSENTが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：これ以上の2以上の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 |
+===================================================================+
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 |
+===================================================================+
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 |
+===================================================================+
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：2個のACKは、タイマーによって定義された長さの任意の時間内に送られるべきであるに過ぎません。従って、一つのACKは、タイマーが切れるたびに送らなければなりません。着信メッセージがSYNまたはSYNACKであればさらに、1つの更なるACKタイマの期限切れの間で送信されてもよいです。この追加のACKは、隣接プロトコルは、より迅速に、同期に到達することができます。
Note 3: No more than one ACK should be sent within any time period of length defined by the timer.
注3：1 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フラグ：ANによってNASによって1に設定され、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フラグ：送信者から要求された（新しい隣接対は、隣接関係を回復）隣接セットアップのモードに設定してください。警告：ANCPはANの現在の状態を監査するNASのための手段を提供していないので、設定Pフラグ= 1は状態のミスマッチのリスクを実行します。
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.
キャップの＃は：従う能力フィールドの数に設定しなければなりません。
Total Length: MUST be set to the total number of bytes in the Capability fields that follow.
全長は：従う能力フィールドの総バイト数に設定しなければなりません。
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であり、Mフラグが1であり、受信機はNASである場合、受信機はAN場合、または同様に、メッセージは無視されます。これらのチェックを通過し、受信機がESTAB状態になっている場合（セクション3.5.2.2.1にESTAB状態テーブルによって示されるように）、それがACKを返します。以前に受信機によって記録された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.
送信者名：ちょうど受信SYNメッセージに送信者名フィールドの値。
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.
送信元ポート：SYNメッセージで送信元ポートフィールドの値がちょうど受け取りました。
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.
差出人インスタンス：SYNメッセージに送信者のインスタンスフィールドの値は、受信したばかり。
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.
レシーバインスタンス：それはこの隣接に送信SYN、SYNACK、およびACKメッセージの送信者インスタンスフィールドに受信機によって使用される値。
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フィールドは、隣接状態の一部として記録された値で埋めなければなりません。キャップ全長、及び機能項目の＃はまた、隣接状態の一部として記録する機能に応じて移入されなければなりません。次のように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.
PTYPE：パーティションID値が非ゼロであればパーティションID値が0又は2である場合は0でなければなりません。
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.
受信インスタンスは：隣接状態の一部として記録された送信者のインスタンスの値に設定しなければなりません。
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セッションを切断しなければなりません。他の隣接関係がそれを使用していない場合は、送信者はまた、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はまた、p型とパーティションIDが一致することを確認します。これらのチェックのいずれかが失敗した場合、セクション3.5.2.6.1に記載されているように、受信機はRSTACKを送信します。
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がこれらのチェックに合格すると仮定すると、2つのケースが発生します。第1の可能性は、受信機が既に隣接状態を記録したということです。受信機はSYNRCVD状態にある間SYNACKを受信した場合に発生します。この場合には、バージョン、タイマ、送信者名、送信元ポート、送信者インスタンス、Pフラグ、SYNACKの機能に関連するフィールドが隣接状態の一部として記録されたものと一致しなければなりません。不一致が検出された場合、受信機は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.
受信機はSYNSENT状態にある間、一方、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メッセージは、異なる状況の数に送られます。メインライン用途はESTAB状態に直接つながる、SYNACKに対する応答としてであり、ライブネスの周期的なテストとして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.
2人の交流があるため、競合状態の起こることを、もちろん可能です。
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).
送信者が隣接状態を記録している場合は、バージョンは、タイマー、p型、P旗、パーティションID、および能力の関連分野は、記録された隣接状態に基づいて設定されるべきです。それ以外の場合は、SYNメッセージで送信し、送信者と同じでなければなりません。メッセージタイプは、Mフラグが0でなければなりません、そしてコード4（RSTACK）である必要があり、10でなければなりません。
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
有効なANCPメッセージが隣接プロトコルメッセージで交渉Timerフィールドの値の3倍を超えて、任意の期間に受信されないO、または
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
成功：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に - これは応答され、要求が正常に実行されなかったことをことを示す結果値。応答に含まれる結果コード値とステータス-INFO 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の（Noの結果）に設定しなければなりません。
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 1行の記述。
o Where condition detected (control application or ANCP agent);
O WHERE条件検出（制御アプリケーション又は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エージェント推奨処置：元の要求だけ短い遅延の後に一度再送信されるかもしれません。 2回目も失敗したか、何秒の試みがなされない場合は、失敗したトランザクションの適切な識別と制御アプリケーションに通知します。
Result Code value: 0x6
結果コード値：0x6に
* One-line description: One or more of the specified ports are down
* 1行の記述：指定された1つ以上のポートがダウンしています
* Where condition detected: Control application
*コンディション検出：Controlアプリケーション
* 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.
*応答メッセージに追加情報を必要：要求は、複数のアクセス回線を同定または応答が汎用応答メッセージである場合、応答ステータス-INFO TLVが封入含まなければならないTLV（S）アクセスの回線識別子（複数可）を含有します動作していませんライン。
* Target: Control application at the peer that sent the original request
*対象：元の要求を送信したピアでControlアプリケーション
* 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
* 1行の記述：リソース不足
* 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
* 1行の記述：実装されていませんRequestメッセージのタイプ
* 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エージェント推奨処置：この結果コード値の受信機は、当該メッセージ・タイプのサポートがセッションのために交渉能力に応じて必須であることを想定している場合、それは再送信してもよい（MAY）メッセージのメッセージがで破損した場合にはトランジット初めて。それが失敗し、メッセージタイプの使用は避けることができない場合は、送信者と受信者名、ポート、およびインスタンスがから取られ、セクション3.5.2.6.1に記載されているように、ANCPエージェントはRSTACK隣接メッセージを送信することにより、隣接関係をリセットすることができ隣接状態を記録しました。リセットは、問題を解消しない場合は、受信ANCPエージェントが管理にアラームを上げた後、動作を止めるべきです。
Result Code value: 0x53
結果コード値：$ 53
* 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
* 1行の記述：必須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のインスタンスをカプセル化ステータス-Infoメッセージを含まなければならない（すなわち、唯一の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（S）とのメッセージを再送信します。そうでない場合は、不足している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.
*さらなる説明：要求内の1つのまたは複数の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（S）に関連付けられた誤った情報の表示と制御アプリケーションにエラーを報告します。
Result Code value: 0x500
結果コード値：0x500
* One-line description: One or more of the specified ports do not exist
* 1行の記述：指定されたポートの1つ以上が存在しません。
* Where condition detected: Control application
*コンディション検出：Controlアプリケーション
* 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をカプセル化（複数可）拒否の行識別子（S）を含むを含まなければなりません。
* Target: Control application at the peer that sent the original request
*対象：元の要求を送信したピアでControlアプリケーション
* 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）の値に設定しなければなりません。このようにして使用される場合、トランザクションIDの順序付けは、各ANCP隣接内の各メッセージタイプに対して独立に維持しなければなりません。また、全範囲を実行した後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エージェントは、「フラグメンテーション」を意味しないように1にIフラグとサブメッセージ番号フィールドを設定しなければなりません。
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.
このフィールドは、ヘッダフィールドおよびメッセージ本体を含むが、セクション3.2で定義された4バイトのカプセル化ヘッダを除いて、バイト単位でANCPメッセージの長さに設定しなければなりません。
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メッセージのメッセージのペイロード部分の詳細な内容は、それが使用されているの文脈における能力を変化させることができます。しかし、一般的な形式は、Type-Length-Value（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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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タイプと性質を識別する符号なしの値です。 IANAレジストリはANCP TLVタイプコードのために設立されました。
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ビット）：4バイトワード境界にこのTLVをもたらすために必要なパディングを除くTLVの値フィールド内のデータのバイト数（以下「値」を参照）。 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におけるValueフィールドは、4バイトワード境界に整列させるためにゼロでパディングされなければなりません。 TLVのValueフィールドは固定フィールドおよび/またはその他の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:
2つのメッセージング要求/応答対話をサポートするために構築するために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項の規定により、第2のプロトコル仕様で示されています。このセクションの目的は、このメッセージングの使用は、追加の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.
このセクションでは、2つのメッセージと、複数の機能に有用であり得るの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.
プロビジョニングメッセージがANに（すなわち、特定のアクセス回線に関連付けられていない）は、グローバルスコープの提供情報をANにNASによって送信されます。プロビジョニングメッセージはANCP剤は、その使用を必要とする機能のサポートを主張しない限り、プロビジョニング・メッセージの9のサポートはオプションである。図に示すフォーマットを有しています。
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がその障害状態の結果として隣接関係を閉じる前に独立して特定の要求の故障状態を示す一般的な応答メッセージを送信することができます。この場合、送信者はゼロにステータス・インフォメーションTLV内ヘッダ内のトランザクションIDフィールドとメッセージタイプフィールドを設定しなければなりません。受信機は、管理用にステータス・インフォメーション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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
このドキュメントは以下のヘッダフィールドを指定します。セクション3.6.1で指定されるようにANCP一般的なメッセージヘッダ内の残りのフィールドを設定しなければなりません。
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.
元の要求は、特定のアクセス回線に適用またはラインのセット場合、線（S）とおそらくユーザを特定の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.
タイプ：特定のコンテンツに応じて、0x1020に0x1000を。のみの0x1000は、本明細書に割り当てられている（下記参照）。 ANCPエージェントが使用する必要が機能するためのサポートを主張しない限り、ターゲットTLVのいずれかの特定の変異体のサポートはオプションです。
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.
値：各オブジェクト・タイプに対して定義されたような情報をターゲット。 Valueフィールドは、サブの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番地は、単一のアクセス回線を表すターゲットを識別する1つまたは複数のサブTLVを封入ターゲットTLVの変異体に割り当てられます。図11は、アクセス・ループ回路-ID TLV（0x0001に）（セクション5.1.2.1）によって識別される単一ポートの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 = 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 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（0x0011）は、TLV指向メッセージ内の1つまたは複数のコマンド指示をカプセル化する一般的な手段であることが意図されています。コマンドの意味は、それを使用してメッセージタイプごとに指定することができます。すなわち、仕様の再使用は、もちろん、適切な場合に許容されるものの、コマンドTLVを運ぶことができ、各メッセージタイプの仕様は、ペイロードのコンテンツの意味を定義することが期待されます。 ANCPエージェントが使用する必要が機能するためのサポートを主張しない限り、コマンドTLVのいずれかの特定の変異体のサポートはオプションです。
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つまたは複数の「コマンド」の配列、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のインスタンスが含まれます。ステータス - 情報TLVのサポートは、送信者としておよび受信機の両方に関係なく、それらがサポートするどのような機能を、すべてのANCPのエージェントに必要です。
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.
メッセージタイプ（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ビット）：パディングを除いたエラーメッセージのバイト数が、言語タグとデリミタを含みます。エラーメッセージが提供されていない場合、これは0であってもよいです。
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Status-Info TLV
図12：ステータス-情報TLV
5. Introduction to ANCP Capabilities for Digital Subscriber Lines (DSLs)
5.デジタル加入者回線用ANCP能力（のDSL）の概要に
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.
このドキュメントの次の3つのセクションでは、特にDSLアクセス（テックタイプ= 0x05の）を提供するアクセスノードを制御する際に使用するための基本的なANCP機能を指定します。同じANSは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メッセージは、特定のアクセス回線に関連するアクションを伴います。したがって、アクセス回線は、それらのメッセージ内で識別される方法を記述する必要があります。このセクションでは、その目的のための4つのTLVを定義し、それらが使用されているかの有益な説明を提供します。
Three types of identification are described in [TR-101] and provided for in the TLVs defined in this section:
識別の3種類[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トポロジ発見のプロセスの間に、AN制御アプリケーションに由来します。制御アプリケーションが使用すると値が設定と展開の考慮事項に基づいて、ラインごとにそれらに置くためにどの識別子を選択します。
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]オプション82にアクセス回線識別情報を追加するには、この役割にANまたはNASを必要とする（情報）（[RFC4649]でのIPv6の当量[RFC3046]）各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自体の観点から、識別子は不透明です。のASCII形式のためのDHCPオプション82構文[TR-101]のセクション3.9.3で指定されAN制御アプリケーションの観点から、ユーザ側のアクセス回線識別子の構文は同じですNAS側アクセス回線識別子は同様であろう。
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 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.
アクセスノードのユーザ側の論理的外観によるアクセス回線識別は常に一意DSLアクセス回線を識別する。両側の出現とANとNASの間には同一改質凝集の間に1対1のマッピングが存在する場合にのみ、アクセスノードの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.
セクション3.8および[TR-101]の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-バイナリTLVは、アクセスノードのNAS側の論理的な出現によってアクセス回線を識別する。彼らは同等の情報を運ぶので、与えられたANは、同じ行または別のラインのいずれかのために、これらのTLVの両方を使用することはほとんどありません。最後に、アクセス・ループ・リモートID TLVは、[TR-101]のセクション3.9.1および3.9.2に記載したように一意に関連付けられたアクセス回線上でユーザーを識別し、オペレータが設定した文字列を含んでいます。
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（実装の選択）、AN制御アプリケーションから関連する情報を渡されたとき。
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剤は、すべての4つの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.
アクセス - ループ - リモート-ID TLVがメッセージに存在している場合は、O、それはアクセス・ループ回路-ID TLVおよび/またはアクセス・集約サーキット-ID-ASCII TLVまたはアクセス-Aggregation-を添付しなければなりません回路-ID-バイナリ2つのVLAN 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.
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.
アクセス・集約サーキット-ID-ASCII TLVまたはアクセス・集約サーキット-ID-バイナリTLVはただ一つのVLAN IDを持つメッセージに存在している場合は、O、それはアクセス・ループ回路-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
タイプ：0×0002
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を適用することができるイーサネットアクセス集約、（1：1モデル[TR-101]で定義されるように）、TLVは、二つの値フィールドを含みます。各フィールドは、（[IEEE802.1Q]によって定義されたVLANタグの一部）12ビットのVLAN識別子を運びます。第2のフィールドは、外側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.
DSLAMは、直接（中間ATMスイッチなし）NASに接続されているATMアグリゲーションネットワークの場合には、DSLAMのアップリンク上の仮想パス識別子（VPI）及び仮想回線識別子（VCI）は、DSLアクセスに一意に対応しますDSLAM上のライン。アクセス・集約サーキット-ID-バイナリTLVは、VPIとVCIを運ぶために使用されるかもしれません。第2の値フィールドは、VPIを運ぶ必要がありますがTLVの最初の値フィールドは、VCIを運ばなければなりません。
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.
値：つまたは2つの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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は、Access-集約サーキット-ID-バイナリTLVのASCII文字を送信します。前節で述べたように、AN制御アプリケーションは、「回線ID」の形式の[TR-101]のセクション3.9.3で指定されたものと同様の形式を使用します。
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制御アプリケーションには、以下の状況でNASにDSL固有のポートアップメッセージを送信するためにANCPを要求します。
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たびAN制御アプリケーションは、ライン属性が変更されたことを知らせることを望みます。
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制御アプリケーションには、以下の状況でNASにDSL固有のポートダウンメッセージを送信するためにANCPを要求します。
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アクセス回線は、「IDLE」として通知されます。そして
o subsequent to that, whenever a DSL access line loses synchronization.
DSLアクセス回線が同期を失った時はいつでも、それ以降、O。
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.
AN制御アプリケーションは、DSLアクセス回線の属性に関する情報とともに、ポートUpまたはポートダウンメッセージに含めるANCPにDSLループを識別するための情報を渡します。
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多対結合あたりのような）顧客構内にANCPはDSL固有ポートアップとポートダウンを送信AN制御アプリケーションの要求をループ（単一の論理ポートとして表される）凝集「DSL結合回路」、並びにそれが構成された個別のDSLアクセス回線のメッセージ。 DSLアクセス回線に関連する情報は、情報を集約していることがAN制御アプリケーションによって渡される属性。
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固有のポートUpまたはポートダウンメッセージやNASに転送を生成します。 NAS側ANCPはDSLアップポートまたはポートのダウンメッセージは、メッセージに含まれる情報と一緒に受信されたNAS制御アプリケーションに指示を渡します。
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)
2. Home Access NAS Gateway Node
2.ホームアクセスNASゲートウェイノード
-----------> -------------------------->
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)
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ポートアップとポートダウンイベントメッセージのフォーマットは、図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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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を参照。メッセージタイプフィールドは、ポートダウンのためのポートアップ、81、80に設定しなければなりません。 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で説明したように一般的なヘッダ内の他のフィールドを設定しなければなりません。
The five-word Unused field is a historical leftover. The handling of unused/reserved fields is described in Section 3.4.
5ワード未使用のフィールドには、歴史的な残り物です。未使用/予約フィールドの取り扱いは、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ビット）：0×05（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：その特性を定義するためにDSLアクセス回線及びゼロ以上のTLVを識別するために、1つのまたは複数の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エージェントが作成され、AN制御アプリケーションによって要求され、有効なメッセージを構築するために必要な情報を提示する際DSL固有のポートUpまたはポートダウンメッセージを送信します。アクセス・ノードは、状態変化がNASに伝達される速度を制御するために、DSLアクセス回線当たり減衰機構を使用することをお勧めします。
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固有のポートUpまたはポートダウンメッセージは、DSLアクセス回線を識別するために、セクション5.1.2からTLVを含まなければなりません。
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 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.
DSLアクセス回線を提示するのTLVは、TLVをDSLラインは、属性内（セクション6.5で指定され、すなわち、のTLV）がカプセル化されなければならない属性。 TLVがメッセージに存在しているDSLラインが-属性の場合、それは少なくとも一つの、そのようなTLVを含まなければならないし、一般的に複数が含まれています。ポート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アクセス回線または論理ポートのポートアップとポートダウンメッセージを受信するために準備しなければなりません。連続して2件のポートアップメッセージがその逆介在ポートダウンメッセージを表示せずに同じ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のすべてのコピーを含まなければなりません。メッセージはまた、セクション3.6.1.4で説明したように順番にメッセージヘッダ結果コード値に適切な他の情報が含まれていることをステータス・インフォメーションTLVを含まなければなりません。
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は、トップレベルのポートUpまたはポートダウンメッセージに挿入されています。以下に定義され、残りのTLVが内にカプセル化されているTLVは、DSLライン-属性。
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に対応する1つ以上のカプセル化のTLV。それはポートUpまたはポートダウンメッセージに存在する場合TLVは、少なくとも一つのTLVを含まなければならないDSLラインは、属性。実際の内容は、AN制御アプリケーションによって決定されます。
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
その他= 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
値：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
値：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
値：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
値：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
値：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
値：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
値：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
値：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
値：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
値：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が存在する場合、少なくともデータリンクプロトコルが示されなければなりません。カプセル化のオーバーヘッドを示すことができます。アクセス・ノードは、2つのカプセル化のフィールドに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
な ＝ ０
Untagged Ethernet = 1
タグなしイーサネット= 1
Single-tagged Ethernet = 2
シングルタグ付きイーサネット= 2
Double-tagged Ethernet = 3
二重タグ付きイーサネット= 3
Byte 3: Encapsulation 2
バイト3：カプセル化2
NA = 0
な ＝ ０
PPPoA LLC = 1
PPPoA LLC = 1
PPPoA Null = 2
PPPoAのヌル= 2
IPoA LLC = 3
IPOA LLC = 3
IPoA Null = 4
IPOAヌル= 4
Ethernet over AAL5 LLC with FCS = 5
FCS = 5とAAL5 LLCオーバーイーサネット
Ethernet over AAL5 LLC without FCS = 6
FCSを含まないAAL5 LLCのEthernet over = 6
Ethernet over AAL5 NULL with FCS = 7
FCS = 7とAAL5のNULLオーバーイーサネット
Ethernet over AAL5 NULL without FCS = 8
= 8 FCSを含まないAAL5のNULLオーバーイーサネット
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
ANCPベースのDSL回線設定のためのユースケースは、[RFC5851]の3.2節に記述されています。
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.
新しいDSLアクセス回線を報告するトポロジ情報によってトリガまたは（PPPまたはDHCPを介して）、その後のユーザ・セッションの確立によってトリガ、RADIUS / AAAは、アクセス回線の設定のためのNAS制御アプリケーションにサービスパラメータを送ります。 NAS制御アプリケーションは、ポート管理（回線設定）メッセージにより、ANに情報を送信するNAS側エージェント、上に要求を渡します。 AN側エージェントは、ラインに印加AN制御アプリケーションまで、この情報を渡します。図17は、相互作用をまとめました。
Home Access NAS RADIUS/AAA Gateway Node Policy Server
ホームアクセスNAS RADIUS / AAAゲートウェイノードポリシーサーバ
-----------> --------------->
DSL Port Up message)
Signal (line parameters)
--------------------------------> -------------->
PPP/DHCP Session Authentication &
authorization
<----------------
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
----------------------------------------------------> Web portal,
Service on demand OSS, etc.
|
<----------- RADIUS/AAA
Change of Policy Server
authorization
<------------
Port Management
message
(new profile)
OSS: Operations Support System
OSS：オペレーションサポートシステム
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アクセス回線の設定機能は、機能タイプ0×0002が割り当てられます。いいえ能力データは、この機能に関連付けられていません。
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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を識別するアクセス回線によって指定DSLアクセス回線へ回線設定のTLVに含まれるサービスの構成データを適用するように要求します。
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側のエージェントが作成し、前のセクションで説明したように設定した固定フィールドでポート管理メッセージを送らなければなりません。メッセージは、セクション5.1.2の要件によるアクセス回線を識別するために、1つ以上のTLVを含まなければなりません。 NASは、その回線の回線サービスパラメータを設定するために、1つ以上の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-側エージェントが、これは与えられた結果コードの値については、セクション3.6.1.4で推奨される場合は特に、エラーに関する詳細な情報を提供するために、ステータス・インフォメーションTLV（4.5節）を追加するかもしれません。そうしなければ、様々な長さフィールドと、メッセージ内のTLVフィールドの＃は、それに応じて調整しなければなりません。
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).
現在のところ、以下のTLVは、DSLアクセス回線の設定に指定されています。より多くの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).
値：（加入者が認証された後、NASは、ポリシーサーバから学習）プロファイル名を含むASCII文字列。
The use case and requirements for ANCP-Based DSL remote line connectivity testing are specified in Section 3.3 of [RFC5851].
ユースケースとANCPベースDSLリモート回線接続試験のための要件は、[RFC5851]のセクション3.3で指定されています。
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制御アプリケーションは、テスト・パラメータを与えた場合、それらが使用されます。それ以外の場合は、AN制御アプリケーションは、デフォルトのテストパラメータを使用しています。 NASによって提供されるループカウントパラメータが有効範囲外である場合、ANは、テストを実行したが、試験は無効なパラメータが原因で失敗したことを示す結果を返しません。テストはタイムアウト値（デフォルトまたはNASによって提供される）よりも長くかかる場合は、AN制御アプリケーションがタイムアウトを示す失敗の結果を返すことができるか、誰応答を送信することはできません。 AN制御アプリケーションは失敗と成功の両方の試験結果を記述する人間可読文字列を、提供することができます。提供されている場合、この文字列は、応答に含まれています。応答は常に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)
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.
彼らは、セクション8.4で指定されているようNAS側ANCPエージェントは、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を要求に結果フィールドは、NASが成功したテスト応答に含まれる情報を受信できるように、AckAll（0x2という）に設定されるべきです。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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 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.
NAS制御アプリケーションによって要求され、そうするために必要な情報を提示する際、NAS側エージェントが作成され、前のセクションで説明したように設定された固定フィールドを持つポート管理（OAM）要求を送信します。メッセージは、セクション5.1.2の要件によるアクセス回線を識別するために、1つ以上のTLVを含まなければなりません。 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がCountフィールドの無効な値を持つ存在する場合、結果コード値0x509を使用する必要があります。 AN-側エージェントが、これは与えられた結果コードの値については、セクション3.6.1.4で推奨される場合は特に、エラーに関する詳細な情報を提供するために、ステータス・インフォメーションTLV（4.5節）を追加するかもしれません。そうしなければ、様々な長さフィールドと、メッセージ内のTLVフィールドの＃は、それに応じて調整しなければなりません。
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制御アプリケーションにその情報を提示します。これは、要求に即座に応答を生成してはならないが、それは代わりに応答が送られるべきであることを示すために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制御アプリケーションによって要求されたと、そうするために必要な情報を提示すると、AN側のエージェントが作成され、元の要求にポート管理（OAM）応答を送信します。結果フィールドは成功に設定しなければなりませんAN制御アプリケーションによって示されるように（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のリソースが利用できません。結果ヘッダフィールドは、障害（0×04）に設定しなければなりません。
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が現れてはならない正常な応答でことを除いて、そのまま応答にコピーする必要があります。 AN制御アプリケーションは、必要な情報を提供した場合、AN側エージェントは、応答における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).
値：以下の2つの符号なしの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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
値：2つの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:
次の新しいANCPレジストリのOの確立：
ANCP Message Types;
ANCPメッセージタイプ。
ANCP Result Codes;
ANCP結果コード。
ANCP Port Management Functions;
ANCPポートの管理機能。
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;
新共同GSMP / ANCPバージョンレジストリのO確立。
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.
http://www.iana.orgから使用可能なポート番号のレジストリでTCPポート6068の別のユーザーとしてANCPのO追加。現在のユーザーは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の範囲であってもよいが、新しいメッセージタイプは順次（91と93が既に割り当てられていることに注意）以降90からの値を割り当てられるべきです。次のように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 |
+--------------+--------------------+-----------+
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 1行の記述。
o Where condition detected (control application or ANCP agent);
O WHERE条件検出（制御アプリケーション又は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:
結果コードの値は、16進数で表現され、0xFFFFFFのには0x0の範囲であり得ます。 [RFC5226]で定義されるように0xFFFの範囲は0x0は、IETFレビューの基準によって割り当てられます。 IANAは、0x100ので始まり、この範囲から順次新しい結果コード値を割り当てる必要があります。 [RFC5226]で定義されるような範囲0x1000番地は、以降、指定必須の基準によって割り当てられます。 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 |
+------------+------------------------------------------+-----------+
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 |
+----------------+-----------------------------------+-----------+
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:
[RFC5226]で定義されているIANAは、専門家レビューによって追加して、新しいANCP技術タイプのレジストリを作成しました。テクノロジーのタイプは、異なるアクセス・トランスポート技術を指定する必要があります。値は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 |
+-----------------+-------------------------------+-----------+
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:
[RFC5226]で定義されているIANAは、標準化アクションによって追加して、新しいANCPコマンドコードレジストリを作成しました。値はIANAが順次1から始まる新しい値を割り当てる必要が0から255までの範囲であり得る最初のエントリは次の通りであります：
+--------------------+-----------------------------+-----------+
| 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タイプのレジストリを作成しました。値は16進数で表現され、0000から0xFFFFの範囲であり得ます。 [RFC5226]で定義されるように0x1FFFの範囲の0000に追加は、IETF口コミによるものです。 IANAは、すでに以下の作られた割り当てを考慮して、0x100ので始まり、この範囲の順で新しい値を割り当てる必要があります。 [RFC5226]で定義されるようには0xFFFFまでの範囲内の0x2000で添加は再び、仕様が必要によるものです。 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).
任意のTLVが何らかの情報と、カプセル化され得るかどうかの指示O（定義される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 | | |
+----------+--------------------------------------------+-----------+
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は[RFC5226]で定義された標準化アクションによって追加して、新しいANCP能力タイプのレジストリを作成しました。値は、順次5でそれが関連する技術タイプ値を示さなければなりません与えられた能力の仕様を開始する値を割り当てる必要があり、0から255 IANAの範囲であってもよいです。明細書はさらに、機能は、任意の能力データに関連付けられているかどうかを示す必要があります。通常、機能は、プロトコルの用語でその機能の実装を指定し、同じ文書で定義されることが期待されます。次のように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 |
+-------+------------------------+--------+-------------+-----------+
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]で定義された標準アクションです。値は、次のバージョンのために4で始まる順番に割り当てなければならない一般的なスイッチ管理プロトコル（GSMP）について0〜255の値の範囲とすることができます。アクセスネットワーク制御プロトコル（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 |
+---------+----------------+-----------+
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: o The protocol solution MUST offer authentication of the AN to the NAS.
ANCPのセキュリティは、[RFC5713]で議論されています。 ANCP上のセキュリティ要件の数は、そのドキュメントのセクション8に記載されています。自分自身をANCPを適用するものを、本文書にコピーされます：プロトコル・ソリューションは、NASにANの認証を提供しなければならないoを。
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の輸送を確保するために関連しています。 DoS攻撃に対する頑健性は、部分的に輸送上、一部のプロトコルの設計に依存します。デフォルトモードでは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.
安全な輸送のために、いずれかのIKEv2（以下参照）またはTLS [RFC5246]の使用とのIPsecの組み合わせは、上記の要件を満たします。しかし、TLSの使用が拒否されました。決定ポイントは、[RFC5713]が書き込まれたときに利用できなかったプロトコル設計の詳細図です。 ANCP隣接関係は、サービス妨害（DoS）攻撃の脆弱性の主要なポイントです。隣接関係がシャットダウンし、どちらかの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.
より詳細に：ANとNASは、パスのエンドポイントであるのでANCPスタックは、トランスポートモードで動作しているのIPsec [RFC4301]を含まなければなりません。カプセル化セキュリティペイロード（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は異なる信頼ドメインであってもよいので、相互認証のための証明書の使用が最も実用的なアプローチである可能性があります。しかし、これは、関係演算子（S）までです。
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.
スワミサブラマニアンは、著者のチームの早いメンバーでした。 ANCPワーキンググループは、辞任前の2年間、設計チームのメンバーと、この文書の主な編集者を務めロベルタマリオーネに感謝しています。
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.
作者はこのドキュメントへのコメントや入力を提供するすべての人に感謝したいと思います。著者は、Mykyta Yevstifeyev、ブライアン・カーター、ベン・キャンベル、アレクセイ・メルニコフが提供するヴォイチェフ12月、ピーター・アーベルク、ヨーゼフFroehler、デレク・ハークネス、キムHyldgaard、サンディン、ロバートPeschi、そしてミシェルPlatnicが提供する入力、およびさらなるコメントを認めますエードリアンファレル、ロバート・スパークス、ピーター・セント・アンドレ、ショーン・ターナー、ダンRomascanu、ブライアン・カーター、マイケル・スコット。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ドリア、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]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年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.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]パトリック、M.、 "DHCPリレーエージェント情報オプション"、RFC 3046、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649]フォルツ、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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.デ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.、フォークト、N.、Platnic、M.、ハーグ、T.、およびS. Wadhwa、 "フレームワークおよびブロードバンドマルチサービスネットワークにおけるアクセスノード制御機構のための要件"、RFC 5851、月2010。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]をタッチし、J.、マンキン、A.、およびR. Bonica、 "TCP認証オプション"、RFC 5925、2010年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.
「 - 情報交換のための7ビットの米国標準コードコード化文字セット」、ANSI X.34、1986 [US_ASCII]米国規格協会、。
Authors' Addresses
著者のアドレス
Sanjay Wadhwa Alcatel-Lucent 701 E Middlefield Rd Mountain View, CA 94043-4079 USA
サンジャイWadhwaアルカテル・ルーセント701 EミドルRdのマウンテンビュー、カリフォルニア州94043から4079 USA
EMail: sanjay.wadhwa@alcatel-lucent.com
メールアドレス：sanjay.wadhwa@alcatel-lucent.com
Jerome Moisand Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA
ジェロームMoisandジュニパーネットワークスの10テクノロジーパークドライブウェストフォード、MA 01886 USA
EMail: jmoisand@juniper.net
メールアドレス：jmoisand@juniper.net
Thomas Haag Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany
トーマス・ハーグドイツテレコム・ハインリッヒ・ヘルツ・シュトラーセ3-7 64295ダルムシュタットドイツ
EMail: haagt@telekom.de
メールアドレス：haagt@telekom.de
Norbert Voigt Nokia Siemens Networks Siemensallee 1 Greifswald 17489 Germany
ノルベルト・フォークトノキアシーメンスネットワークスSiemensallee 1グライフスヴァルト17489ドイツ
EMail: norbert.voigt@nsn.com
メールアドレス：norbert.voigt@nsn.com
Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave Ottawa Canada
トム・テイラー（エディタ）華為技術1852ロレーヌアベニューオタワカナダ
EMail: tom111.taylor@bell.net
メールアドレス：tom111.taylor@bell.net