[要約] RFC 6320は、ブロードバンドネットワークにおけるアクセスノード制御メカニズムのプロトコルに関するものです。このRFCの目的は、アクセスノードの制御を効果的に行うためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) S. Wadhwa
Request for Comments: 6320 Alcatel-Lucent
Category: Standards Track J. Moisand
ISSN: 2070-1721 Juniper Networks
T. Haag
Deutsche Telekom
N. Voigt
Nokia Siemens Networks
T. Taylor, Ed.
Huawei Technologies
October 2011
Protocol for Access Node Control Mechanism in Broadband Networks
ブロードバンドネットワークのアクセスノード制御メカニズムのプロトコル
Abstract
概要
This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.
このドキュメントでは、アクセスノード制御プロトコル（ANCP）について説明します。ANCPは、ネットワークアクセスサーバー（NAS）とアクセスノード（たとえば、デジタルサブスクライバーラインアクセスマルチプレクサ（DSLAM））で動作し、サービスの品質、サービス、および加入者に関連する操作を実行するために、マルチサービスリファレンスアーキテクチャで動作します。ANCPのユースケースはRFC 5851で文書化されています。また、ベースANCPプロトコルの説明と同様に、このドキュメントは、デジタルサブスクライバーライン（DSL）トポロジの発見、ライン構成、リモートライン接続テストの機能を指定します。ANCPの設計により、他のユースケースや他のアクセステクノロジーをサポートするために必要な場合、他のドキュメントのプロトコル拡張が可能になります。
ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it.
ANCPは、RFC 3292で説明されている一般的なスイッチ管理プロトコルバージョン3（GSMPV3）に基づいていますが、多くの変更と拡張があり、2つのプロトコルが相互運用できない点までです。このため、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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].
このドキュメントでは、新しいプロトコルであるAccessノード制御プロトコル（ANCP）を定義して、サービス指向のレイヤー3エッジデバイス（ネットワークアクセスサーバー、NAS）とレイヤー2アクセスノード（例：デジタルサブスクライバーラインの間の制御プレーンを実現します。アクセスマルチプレクサ、DSLAM）。サービス品質（QO）、サービス、およびサブスクリプションに関連する操作を実行するため。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輸送を指定します。ANCPのTCPカプセル化は、セクション3.2で定義されています。
The organization of this document is as follows:
このドキュメントの組織は次のとおりです。
o Sections 1.2 and 1.3 introduce some terminology that will be useful in understanding the rest of the document.
o セクション1.2および1.3では、文書の残りの部分を理解するのに役立ついくつかの用語を紹介します。
o Section 2 provides a description of the access networks within which ANCP will typically be deployed.
o セクション2では、ANCPが通常展開されるアクセスネットワークの説明を提供します。
o Section 3 specifies generally applicable aspects of ANCP.
o セクション3は、ANCPの一般的に適用可能な側面を指定します。
o Section 4 specifies some messages and TLVs intended for use by multiple capabilities spanning multiple technologies.
o セクション4では、複数のテクノロジーにまたがる複数の機能が使用することを目的としたいくつかのメッセージとTLVを指定します。
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].
o セクション11では、[RFC5713]に記載されている要件から始めて、ANCPに関連するセキュリティに関する考慮事項に対処します。
Initial implementations of the protocol that became ANCP were based on the General Switch Management Protocol version 3 (GSMPv3) [RFC3292]. The ANCP charter required the Working Group to develop its protocol based on these implementations. In the end, ANCP introduced so many extensions and modifications to GSMPv3 that the two protocols are not interoperable. Nevertheless, although this specification has no normative dependencies on [RFC3292], the mark of ANCP's origins can be seen in the various unused fields within the ANCP message header.
ANCPになったプロトコルの初期実装は、一般的なスイッチ管理プロトコルバージョン3（GSMPV3）[RFC3292]に基づいていました。ANCPチャーターは、これらの実装に基づいてプロトコルを開発することをワーキンググループに要求しました。最終的に、ANCPはGSMPV3に非常に多くの拡張と変更を導入したため、2つのプロトコルは相互運用できません。それにもかかわらず、この仕様には[RFC3292]には規範的な依存関係はありませんが、ANCPの起源のマークはANCPメッセージヘッダー内のさまざまな未使用のフィールドで見ることができます。
Early in ANCP's development, the decision was made to use the same TCP port and encapsulation as GSMPv3, and by the time ANCP was finished, it was too late to reverse that decision because of existing implementations. As a result, it is necessary to have a way for an ANCP peer to quickly distinguish ANCP from GSMP during initial adjacency negotiations. This has been provided by a joint registry of GSMP and ANCP version numbers. GSMP has version numbers 1 through 3. ANCP has the initial version number 50.
ANCPの開発の初期には、GSMPV3と同じTCPポートとカプセル化を使用するという決定が下され、ANCPが終了するまでに、既存の実装のためにその決定を逆転させるには遅すぎました。その結果、ANCPピアが最初の隣接交渉中にANCPをGSMPとすばやく区別する方法が必要です。これは、GSMPとANCPバージョン番号の共同レジストリによって提供されています。GSMPにはバージョン番号1〜3にあります。ANCPには初期バージョン番号50があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 QOの執行ポイントです。また、ブロードバンドネットワークゲートウェイ（BNG）またはブロードバンドリモートアクセスサーバー（BRA）とも呼ばれます。
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).
Home Gateway（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]から変更された）ANSIDE ANCPエージェントと、アクセスノード制御プロトコルメッセージを交換する目的でNAS側ANCPエージェントとの関係。Access Node Control隣接プロトコル操作の結果に応じて、隣接性は上またはダウンのいずれかです。
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はテクノロジーが独立しています。特定の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ビットワード境界にパディングされた可変長値フィールドで構成されるデータ構造.2。TLVの値フィールドには、他のTLVを含めることができます。IANAレジストリは、ANCP TLVタイプフィールドの値に対して維持されます。
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 TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation and non-zero for 64/65 encapsulation.
ネットデータレート：[RFC5851] ITU-T G.993.2 [G.993.2]、セクション3.39、つまりユーザー情報の送信に使用できる総データレートの部分（ATMセルまたはイーサネットフレームなど）で定義されています。。物理伝達メカニズム（DSLの場合のTrellisコーディングなど）に関係するオーバーヘッドは除外されます。これには、TPS -TC（輸送プロトコル固有の - 伝送収束）カプセル化が含まれます。これは、ATMカプセル化の場合はゼロで、64/65カプセル化の場合はゼロではありません。
Line rate: [RFC5851] Defined by ITU-T G.993.2. It contains the complete overhead including Reed-Solomon and trellis coding.
ラインレート：[RFC5851] ITU-T G.993.2で定義されています。リードソロモンやトレリスコーディングを含む完全なオーバーヘッドが含まれています。
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の「マルチペア」ボンディングにより、オペレーターは2つ以上の銅ペアのデータレートを組み合わせて、単一の顧客に集計データレートを配信できます。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.
リージョナル/アクセスネットワークは、図2に示すように、地域ネットワーク、ネットワークアクセスサーバー（NAS）、およびアクセスネットワークで構成されています。その主な機能は、顧客施設とNSPまたはASP間のエンドツーエンドトランスポートを提供することです。
The Access Node terminates the DSL signal. It may be in the form of a DSLAM in the central office, a remote DSLAM, or a Remote Access Multiplexer (RAM). The Access Node is the first point in the network where traffic on multiple DSL access lines will be aggregated onto a single network.
アクセスノードはDSL信号を終了します。中央オフィスのDSLAM、リモートDSLAM、またはリモートアクセスマルチプレクサ（RAM）の形である場合があります。アクセスノードは、複数のDSLアクセスラインのトラフィックが単一のネットワークに集約されるネットワークの最初のポイントです。
The NAS performs multiple functions in the network. The NAS is the aggregation point for subscriber traffic. It provides aggregation capabilities (e.g., IP, PPP, ATM) between the Regional/Access Network and the NSP or ASP. These include traditional ATM-based offerings and newer, more native IP-based services. This includes support for Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services encapsulated over an appropriate layer 2 transport.
NASは、ネットワーク内で複数の機能を実行します。NASは、サブスクライバートラフィックの集約点です。地域/アクセスネットワークとNSPまたはASPの間に集約機能（IP、PPP、ATMなど）を提供します。これらには、従来のATMベースの製品と、より新しい、ネイティブIPベースのサービスが含まれます。これには、ATM（PPPOA）および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 QOの施行ポイントでもあります。複数のレイヤー2 QoSクラスを使用せずに、既存の非IPアウェアレイヤー2アクセスネットワーク上でIP QoSサポートを許可するために、階層スケジューリングに基づくメカニズムが使用されます。[TR-059]で定義されているこのメカニズムは、NASとサブスクライバーネットワークの端にあるNASとルーティングゲートウェイ（RG）の間のATMネットワーク上のIP QOを保存し、NASの下流トラフィックを慎重に制御することにより、重要なキューイングとその重要なキューイングと輻輳はATMネットワークをはるかに下回ることはありません。これは、下流のトランク帯域幅とDSL同期率を説明するNASのDiffserv-Aware階層スケジューラーを使用することによって達成されます。
[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：1 VLAN割り当てモデルです。別のモデルは、DSLAMの背後にある複数のサブスクライバーから集合ネットワークの単一のVLANにセッションを橋渡しすることです。これはN：1 VLAN割り当てモデルです。[TR-101]のセクション1.6では、これら2つのモデルの簡単な定義を示し、セクション2.5.1では詳細について説明します。
This section specifies aspects of the Access Node Control Protocol (ANCP) that are generally applicable.
このセクションでは、一般的に適用されるアクセスノード制御プロトコル（ANCP）の側面を指定します。
ANCP messages contain an 8-bit protocol version field. For the protocol version specified in this document, the value of that field MUST be set to 50.
ANCPメッセージには、8ビットプロトコルバージョンフィールドが含まれています。このドキュメントで指定されたプロトコルバージョンの場合、そのフィールドの値は50に設定する必要があります。
This document specifies the use of TCP / IPsec+IKEv2 / IP for transport of ANCP messages. For further discussion of the use of IPsec and IKEv2, see Section 11. The present section deals with the TCP aspects. Other specifications may introduce additional transports in the future.
このドキュメントは、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）をNASとANのANSPメッセージの間で構成できます。
In the case of an Ethernet access/aggregation network, a typical practice is to send the Access Node Control Protocol messages over a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN identifier (VLAN ID).
イーサネットアクセス/集約ネットワークの場合、典型的なプラクティスは、別のVLAN識別子（VLAN ID）を使用して、専用のイーサネット仮想LAN（VLAN）を介してアクセスノード制御プロトコルメッセージを送信することです。
When transported over TCP, ANCP messages MUST use an encapsulation consisting of a 4-byte header field prepended to the ANCP message as shown in Figure 3.
TCPを介して輸送される場合、ANCPメッセージは、図3に示すように、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ビット）：4バイトのカプセル化ヘッダーは含まれないバイトでのANCPメッセージの全長。
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が提供されているすべてのANSについて、NASでの静的アドレスプロビジョニングを避けるために必要です。ANにサービスを提供するNASの単一のIPアドレスで与えられたAを構成する方が簡単です。
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]を使用しています。US-ASCII文字は、[US_ASCII]に従ってコーディングされた場合と同じようにUTF-8とコーディングされた場合、同じ表現を持っていることに注意してください。
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セッションの期間中は一定です。タイマーフィールドは100ミリ秒のユニットで指定され、デフォルト値は250（つまり25秒）です。
M flag (1 bit): Used in the SYN message to prevent the NAS from synchronizing with another NAS and the AN from synchronizing with another AN. In the SYN message, it is always set to 1 by the NAS and to 0 by the AN. In other adjacency message types, it is always set to 0 by the sender and ignored by the receiver.
Mフラグ（1ビット）：Synメッセージで使用されて、NASが別のNASと同期するのを防ぎ、ANが別のANと同期するのを防ぎます。Synメッセージでは、常にNASによって1に設定され、ANによって0に設定されます。他の隣接するメッセージタイプでは、送信者によって常に0に設定され、受信機によって無視されます。
Code (7 bits): The adjacency protocol message type. It MUST have one of the following values:
コード（7ビット）：隣接プロトコルメッセージタイプ。次の値のいずれかが必要です。
Code = 1: SYN;
Code = 2: SYNACK;
Code = 3: ACK;
Code = 4: RSTACK.
コード= 4：rstack。
Sender Name (48 bits): For the SYN, SYNACK, and ACK messages, is the identifier of the entity sending the message. The Sender Name is a 48-bit quantity that is unique within the operational context of the device. A 48-bit IEEE 802 Media Access Control (MAC) address, if available, may be used for the Sender Name. If the Ethernet encapsulation is used, the Sender Name MUST be the Source Address from the MAC header. For the RSTACK message, the Sender Name field is set to the value of the Receiver Name field from the incoming message that caused the RSTACK message to be generated.
送信者名（48ビット）：Syn、Synack、およびACKメッセージの場合、メッセージを送信するエンティティの識別子です。送信者名は、デバイスの運用コンテキスト内で一意の48ビット数量です。48ビットIEEE 802メディアアクセスコントロール（MAC）アドレスを使用可能な場合は、送信者名に使用できます。イーサネットのカプセル化が使用される場合、送信者名はMacヘッダーのソースアドレスでなければなりません。RSTACKメッセージの場合、送信者名フィールドは、RSTACKメッセージを生成した着信メッセージから受信者名フィールドの値に設定されます。
Receiver Name (48 bits) For the SYN, SYNACK, and ACK messages, is the name of the entity that the sender of the message believes is at the far end of the link. If the sender of the message does not know the name of the entity at the far end of the link, this field SHOULD be set to zero. For the RSTACK message, the Receiver Name field is set to the value of the Sender Name field from the incoming message that caused the RSTACK message to be generated.
Syn、Synack、およびACKメッセージのレシーバー名（48ビット）は、メッセージの送信者がリンクの遠端にあると信じているエンティティの名前です。メッセージの送信者がリンクの遠端にあるエンティティの名前を知らない場合、このフィールドはゼロに設定する必要があります。RSTACKメッセージの場合、RECEVER名フィールドは、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メッセージの場合、RECEVERポートフィールドは、RSTACKメッセージが生成された着信メッセージから送信者ポートフィールドの値に設定されます。
PType (4 bits): PType is used to specify if partitions are used and how the Partition ID is negotiated.
PTYPE（4ビット）：PTYPEは、パーティションが使用されているかどうか、およびパーティションIDのネゴシエーション方法を指定するために使用されます。
Type of partition being requested:
要求されるパーティションのタイプ：
0 - no partition;
0-パーティションなし;
1 - fixed partition request;
1-パーティションリクエストを修正しました。
2 - fixed partition assigned.
2-固定パーティションが割り当てられました。
P Flag (4 bits): Used to indicate the type of partition request.
Pフラグ（4ビット）：パーティション要求のタイプを示すために使用されます。
1 - new adjacency;
1-新しい隣接。
2 - recovered adjacency.
2-隣接する回復。
In case of a conflict between the peers' views of the value of the P Flag, the lower value is used.
Pフラグの値に対するピアの見解間の競合の場合、低い値が使用されます。
Sender Instance (24 bits): For the SYN, SYNACK, and ACK messages, is the sender's instance number for the link to the peer. It is used to detect when the link comes back up after going down or when the identity of the entity at the other end of the link changes. The instance number is a 24-bit number that is guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number. For the RSTACK message, the Sender Instance field is set to the value of the Receiver Instance field from the incoming message that caused the RSTACK message to be generated.
Senderインスタンス（24ビット）：Syn、Synack、およびACKメッセージの場合、ピアへのリンクの送信者のインスタンス番号です。これは、リンクが下がった後、またはリンクの反対側のエンティティの身元が変わる時期を検出するために使用されます。インスタンス番号は、最近の過去内に一意であることが保証され、リンクまたはノードが下がった後に戻ると変更されることが保証されている24ビット番号です。ゼロは有効なインスタンス番号ではありません。RSTACKメッセージの場合、送信者インスタンスフィールドは、RSTACKメッセージを生成した着信メッセージから受信機インスタンスフィールドの値に設定されます。
Partition ID (8 bits): Field used to associate the message with a specific partition of the AN. The value of this field is negotiated during the adjacency procedure. The AN makes the final decision, but will consider a request from the NAS. If the AN does not support partitions, the value of this field MUST be 0. Otherwise, it MUST be non-zero.
パーティションID（8ビット）：メッセージをANの特定のパーティションに関連付けるために使用されるフィールド。このフィールドの価値は、隣接手続き中に交渉されます。ANは最終決定を下しますが、NASからの要求を検討します。ANがパーティションをサポートしていない場合、このフィールドの値は0でなければなりません。そうでなければ、非ゼロでなければなりません。
Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages, is what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. If the sender of the message does not know the current instance number at the far end of the link, this field SHOULD be set to zero. For the RSTACK message, the Receiver Instance field is set to the value of the Sender Instance field from the incoming message that caused the RSTACK message to be generated.
レシーバーインスタンス（24ビット）：Syn、Synack、およびACKメッセージの場合、リンクの遠端でエンティティによって割り当てられたリンクの現在のインスタンス番号であると送信者が信じているものです。メッセージの送信者がリンクの遠端にある現在のインスタンス番号を知らない場合、このフィールドはゼロに設定する必要があります。RSTACKメッセージの場合、Receiver Instanceフィールドは、RSTACKメッセージを生成した着信メッセージから送信者インスタンスフィールドの値に設定されます。
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隣接手順は隣接更新メッセージ（図6）を使用して、特定のNASがそのパーティションと隣接するまたは失ったときに同じANパーティションを制御する他のNASSを通知します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Adjacency Update Message
図6：隣接する更新メッセージ
The Adjacency Update message is identical to the general ANCP message header described in Section 3.6, but the field settings are in part specific to the Adjacency Update message. The fields in this message are as follows:
隣接更新メッセージは、セクション3.6で説明されている一般的なANCPメッセージヘッダーと同一ですが、フィールド設定は隣接更新メッセージに一部固有です。このメッセージのフィールドは次のとおりです。
Version (8 bits): The ANCP version negotiated and running in this adjacency.
バージョン（8ビット）：ANCPバージョンは、この隣接でネゴシエートして実行されています。
Message Type (8 bits): Always 85.
メッセージタイプ（8ビット）：常に85。
Result (4 bits): Set to Ignore (0).
結果（4ビット）：無視するように設定（0）。
Code (12 bits): Set to the total number of adjacencies currently established on this partition, from the point of view of the AN.
コード（12ビット）：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メッセージを送信し、ACKメッセージを送信することで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.
隣接が確立されると、その活気が定期的にテストされます。ピアは、タイマーフィールドの交渉値によって決定される周波数で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 「隣接状態の検証」操作は、着信シナックメッセージの内容が以前に記録された隣接状態の値と一致することを確認することで構成されています。
o The procedure "Reset the link" is defined as:
o 「リンクのリセット」の手順は、次のように定義されています。
1. Generate a new instance number for the link.
1. リンクの新しいインスタンス番号を生成します。
2. Delete the peer verifier (set to zero the values of Sender Instance, Sender Port, and Sender Name previously stored by the "Record Adjacency State" operation).
2. ピアベリファイヤーを削除します（「レコード隣接状態」操作によって以前に保存されていた送信者インスタンス、送信者ポート、および送信者名の値をゼロに設定します）。
3. Send a SYN message (Section 3.5.2.3.1).
3. Synメッセージを送信します（セクション3.5.2.3.1）。
4. Enter the SYNSENT state.
4. Synsent Stateを入力します。
o The state tables use the following Boolean terms and operators.
o 状態テーブルは、次のブール項と演算子を使用します。
A. The Sender Instance in the incoming message matches the value stored from a previous message by the "Record Adjacency State" operation.
A.着信メッセージの送信者インスタンスは、「レコード隣接状態」操作によって以前のメッセージから保存された値と一致します。
B. The Sender Instance, Sender Port, Sender Name, and Partition ID fields in the incoming message match the values stored from a previous message by the "Record Adjacency State" operation.
B.送信者インスタンス、送信者ポート、送信者名、およびパーティションIDフィールドは、「レコード隣接状態」操作によって以前のメッセージから保存された値と一致します。
C. The Receiver Instance, Receiver Port, Receiver Name, and Partition ID fields in the incoming message match the values of the Sender Instance, Sender Port, Sender Name, and Partition ID currently sent in outgoing SYN, SYNACK, and ACK messages, except that the NAS always accepts the Partition ID value presented to it in a SYN or SYNACK message.
C.受信者インスタンス、受信機ポート、レシーバー名、およびパーティションIDフィールドは、送信者インスタンスの値、送信者ポート、送信者名、および現在送信されているSyn、Synack、およびACKメッセージで現在送信されているパーティションIDの値と一致します。NASは、SynまたはSynackメッセージで提示されたパーティションID値を常に受け入れること。
"&&" Represents the logical AND operation.
「&&」は論理と操作を表します。
"||" Represents the logical OR operation.
「||」論理または操作を表します。
"!" Represents the logical negation (NOT) operation.
「！」論理的否定（非）操作を表します。
o A timer is required for the periodic generation of SYN, SYNACK, and ACK messages. The value of the timer is negotiated in the Timer field. The period of the timer is unspecified, but a value of 25 seconds is suggested. Note that since ANCP uses a reliable transport protocol, the timer is unlikely to expire in any state other than ESTAB.
o Syn、Synack、およびACKメッセージの周期生成にはタイマーが必要です。タイマーの値は、タイマーフィールドでネゴシエートされます。タイマーの期間は特定されていませんが、25秒の値が提案されています。ANCPは信頼できる輸送プロトコルを使用しているため、タイマーがESTAB以外のどの状態でも期限切れになる可能性は低いことに注意してください。
There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are:
2つの独立したイベントがあります。タイマーが期限切れになり、パケットが到着します。これらのイベントの処理ルールは次のとおりです。
Timer Expires: Reset Timer
タイマーの有効期限：リセットタイマー
If state = SYNSENT Send SYN
state = synsent Send syn
If state = SYNRCVD Send SYNACK
state = synrcvdはシナックを送信します
If state = ESTAB Send ACK
state = estabがackを送信する場合
Packet Arrives:
パケットが到着します：
If incoming message is an RSTACK:
着信メッセージがrstackである場合：
If (A && C && !SYNSENT) Reset the link
if（a && c &&！synsent）リンクをリセットする
Else discard the message.
それ以外の場合はメッセージを破棄します。
If incoming message is a SYN, SYNACK, or ACK:
着信メッセージがsyn、synack、またはackである場合：
Response defined by the following state tables.
次の状態表で定義された応答。
If incoming message is any other ANCP message and state != ESTAB:
着信メッセージが他のANCPメッセージとstate！= estabの場合：
Discard incoming message.
着信メッセージを破棄します。
If state = SYNSENT Send SYN (Note 1)
state = synsent send syn（注1）の場合
If state = SYNRCVD Send SYNACK (Note 1)
state = synrcvdを送信する場合（注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を送信する必要があります。したがって、タイマーが期限切れになるたびに1つの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: Version: SHOULD be set to the highest version of ANCP that the sender supports.
Synメッセージは、説明された州のテーブルに従って送信されます。送信者は、個々のフィールドを次のように設定します。バージョン：送信者がサポートするANCPの最高バージョンに設定する必要があります。
Message Type: MUST be set to 10.
メッセージタイプ：10に設定する必要があります。
Timer: SHOULD be set to the value configured in the AN or NAS sending the message.
タイマー：メッセージを送信するANまたはNASで構成された値に設定する必要があります。
M Flag: MUST be set to 1 by the NAS, and 0 by the AN.
Mフラグ：NASが1に、ANで0に設定する必要があります。
Code: MUST be set to 1 (SYN).
コード：1（syn）に設定する必要があります。
Sender Name: Set as described in Section 3.5.1.
送信者名：セクション3.5.1で説明されているように設定。
Receiver Name: SHOULD be set to 0.
受信者名：0に設定する必要があります。
Sender Port: Set as described in Section 3.5.1.
送信者ポート：セクション3.5.1で説明されているように設定します。
Receiver Port: SHOULD be set to 0.
受信ポート：0に設定する必要があります。
PType: Set according to the following rules:
PTYPE：次のルールに従って設定します。
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は、現在のパーティションのこのメッセージに含まれるパーティションIDの値を使用することを要求します。NASは、ANがパーティションのサポートを示している場合、ANからsynメッセージを既に受信している場合でも、この設定を使用する場合があります。NASは、これが要求された値とは異なる場合でも、後続のSynまたはSynackメッセージで受け取る価値を使用する準備をする必要があります。
P Flag: Set to the mode of adjacency setup (new adjacency vs. recovered adjacency) requested by the sender. Warning: setting P Flag=1 runs the risk of state mismatch because ANCP does not provide the means for the NAS to audit the current state of the AN.
Pフラグ：送信者から要求された隣接セットアップのモード（新しい隣接対隣接順）に設定します。警告：Pフラグ= 1の設定は、ANCPがANの現在の状態を監査する手段を提供しないため、状態の不一致のリスクを実行します。
Sender Instance: Set as described in Section 3.5.1.
送信者インスタンス：セクション3.5.1で説明されているように設定します。
Partition ID: MUST be set to 0 if PType=0; otherwise, set to the assigned or requested partition identifier value.
パーティションID：ptype = 0の場合は0に設定する必要があります。それ以外の場合は、割り当てられたまたは要求されたパーティション識別子値に設定します。
Receiver Instance: SHOULD be set to 0.
レシーバーインスタンス：0に設定する必要があります。
# of Caps: MUST be set to the number of Capability fields that follow.
キャップの＃：続く機能フィールドの数に設定する必要があります。
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機能に1つの機能フィールドが存在する必要があります。
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であり、受信機がAまたはMフラグが1で、レシーバーがNASである場合、メッセージは静かに無視されます。これらのチェックが渡され、受信機がESTAB状態にある場合、ACKを返します（セクション3.5.2.2.1のESTAB状態テーブルで示されています）。ACKの内容は、レシーバーによって以前に記録されたように、隣接する状態を反映する必要があります。
Otherwise, the receiver MUST perform the "Record Adjacency State" operation by recording the following fields:
それ以外の場合、受信者は、次のフィールドを記録することにより、「隣接状態」操作を実行する必要があります。
Version: The supported Version value received in the SYN message. This value MUST be used for all subsequent ANCP messages sent during the life of the adjacency.
バージョン：Synメッセージで受信されたサポートされているバージョン値。この値は、隣接の存続期間中に送信されるすべての後続のANCPメッセージに使用する必要があります。
Timer: The larger of the Timer value received in the SYN message and the value with which the receiver is configured.
タイマー：Synメッセージで受信されたタイマー値の大きいほど、および受信機が構成されている値。
Sender Name: The value of the Sender Name field in the SYN message just received.
送信者名：受信した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がパーティションをサポートしない場合、またはそれ以外の場合は割り当てを選択するパーティション識別子の非ゼロ値に設定されます。Syn Receiverが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値が0または2の場合、パーティションID値がゼロではない場合は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.
隣接状態に記録された一連の機能が空である場合、シナックを送信した後、送信者は管理にアラームを上げ、隣接手順を停止し、別の隣接官が使用していない場合は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メッセージで送信されたSender Instance値と一致することを最初にチェックします。ANは、PTYPEとパーティション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.
レシーバーは次に、シナックで提供される一連の機能が空であるかどうかを確認します。その場合、受信者は管理にアラームを上げ、隣接手順を停止する必要があります。
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つのケースが発生します。最初の可能性は、受信者がすでに隣接状態を記録していることです。これは、受信者がSynrcvd状態にある間にシナックが受信された場合に発生します。この場合、シナック内のバージョン、タイマー、送信者ポート、送信者ポート、送信者インスタンス、Pフラグ、および機能関連のフィールドは、隣接状態の一部として記録されたものと一致する必要があります。不一致が検出された場合、レシーバーはRSTACKを送信します。これは、synrcvd状態テーブルに示されている「隣接状態の検証」手順です。
If, on the other hand, the SYNACK is received while the receiver is in SYNSENT state, the receiver MUST record session state as described in Section 3.5.2.3.2.
一方、レシーバーがシンセント状態にある間にシナックが受信された場合、受信者はセクション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である場合、シナックで提供されるパーティションID値を受け入れ、必要に応じて記録された隣接状態を更新する必要があります。
As indicated by the state tables, the ACK message is sent in a number of different circumstances. The main-line usages are as a response to SYNACK, leading directly to the ESTAB state, and as a periodic test of liveness once the ESTAB state has been reached.
状態テーブルで示されているように、ACKメッセージはさまざまな状況で送信されます。メインラインの使用法は、Synackへの対応として、Estab状態に直接つながり、ESTAB状態に到達した後の定期的な活性のテストとしてです。
The sender MUST populate the ACK from recorded adjacency state, exactly as described in Section 3.5.2.4.1. The only difference is that Code MUST be set to 3 (ACK).
送信者は、セクション3.5.2.4.1で説明されているとおり、記録された隣接状態からACKを入力する必要があります。唯一の違いは、コードを3（ACK）に設定する必要があることです。
The required actions by the receiver are specified by the state tables. In addition to the checks B and C, the receiver SHOULD verify that the remaining contents of the ACK match the recorded adjacency state at the receiver. If that check fails, the receiver MUST send an RSTACK as described in Section 3.5.2.6.1.
受信機による必要なアクションは、状態テーブルによって指定されます。チェックBとCに加えて、受信者は、ACKの残りの内容がレシーバーの記録された隣接状態と一致することを確認する必要があります。そのチェックが失敗した場合、セクション3.5.2.6.1で説明されているように、レシーバーはRSTACKを送信する必要があります。
Once the adjacency has been established, either peer can initiate the ACK exchange that tests for liveness. To meet the restrictions on ACK frequency laid down in the notes to the state tables, it is desirable that only one such exchange occur during any one interval. Hence, if a peer receives an ACK when in ESTAB state, it MUST reply to that ACK as directed by the state tables, but SHOULD NOT initiate another ACK exchange in the same interval. To meet this objective, the receiver MUST reset its timer when it receives an ACK while in ESTAB state.
隣接が確立されると、どちらのピアも、活性をテストするACK交換を開始できます。状態テーブルのメモに定められたACK周波数の制限を満たすために、1つの間隔でそのような交換が1つだけ発生することが望ましいです。したがって、PEERが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 Stateにある場合にいくつかのステップが必要です）。
As indicated in Section 3.5.1, the Sender Name, Port, and Instance fields in the RSTACK MUST be copied from the Receiver, Name, Port, and Instance fields in the message that caused the RSTACK to be sent. Similarly, the Receiver identifier fields in the RSTACK MUST be copied from the corresponding Sender identifier fields in the message that triggered the RSTACK.
セクション3.5.1に示されているように、RSTACK内の送信者名、ポート、およびインスタンスフィールドは、RSTACKを送信したメッセージ内の受信機、名前、ポート、インスタンスフィールドからコピーする必要があります。同様に、rstack内の受信機識別子フィールドは、RSTACKをトリガーしたメッセージ内の対応する送信者識別子フィールドからコピーする必要があります。
If the sender has recorded adjacency state, the Version, Timer, PType, P Flag, Partition ID, and capability-related fields SHOULD be set based on the recorded adjacency state. Otherwise, they SHOULD be the same as the sender would send in a SYN message. The Message Type MUST be 10, the M flag MUST be 0, and Code MUST be 4 (RSTACK).
送信者が隣接状態を記録した場合、バージョン、タイマー、PTYPE、Pフラグ、パーティションID、および機能関連のフィールドを記録した隣接状態に基づいて設定する必要があります。それ以外の場合、送信者がSynメッセージを送信するのと同じである必要があります。メッセージタイプは10、Mフラグは0、コードは4（rstack）でなければなりません。
The receiver of an RSTACK MAY attempt to diagnose the problem that caused the RSTACK to be generated by comparing its own adjacency state with the contents of the RSTACK. However, the primary purpose of the RSTACK is to trigger action as prescribed by Section 3.5.2.2.
RSTACKの受信機は、RSTACKの内容とRSTACKの内容を比較することにより、RSTACKを生成する問題を診断しようとする場合があります。ただし、RSTACKの主な目的は、セクション3.5.2.2で規定されているようにアクションをトリガーすることです。
Loss of synchronization MAY be declared if after synchronization is achieved:
同期が達成された後に同期の喪失が宣言される場合があります。
o no valid ANCP messages are received in any period of time in excess of three times the value of the Timer field negotiated in the adjacency protocol messages, or
o 有効なANCPメッセージは、隣接プロトコルメッセージでネゴシエートされたタイマーフィールドの値の3倍を超える任意の期間に受信されません。
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-結果値は、これが応答であり、リクエストが正常に実行されなかったことを示しています。応答の受信者は、結果コード値と、応答に含まれるステータスおよびfo tlvに含まれる診断データで示されるように、さらなるアクションを実行する必要があります。
This field gives further information concerning the result in a response message. It is mostly used to pass an error code in a failure response, but it can also be used to give further information in a success response message or an event message. In a request message, the Result Code field is not used and MUST be set to 0x0 (No result).
このフィールドは、応答メッセージの結果に関するさらなる情報を提供します。主に障害応答でエラーコードを渡すために使用されますが、成功応答メッセージまたはイベントメッセージの詳細情報を提供するためにも使用できます。リクエストメッセージでは、結果コードフィールドは使用されず、0x0に設定する必要があります（結果なし）。
A number of Result Code values are specified below. Specification of additional Result Code values in extensions or updates to this document MUST include the following information:
多くの結果コード値を以下に指定します。このドキュメントの拡張機能または更新における追加の結果コード値の指定には、次の情報を含める必要があります。
o Result Code value;
o 結果コード値。
o One-line description;
o 一線の説明;
o Where condition detected (control application or ANCP agent);
o 条件が検出された場合（制御アプリケーションまたはANCPエージェント）。
o Further description (if any);
o 詳細な説明（ある場合）;
o Required additional information in the response message;
o 応答メッセージに必要な追加情報。
o Target (control application or ANCP agent at the peer that sent the original request);
o ターゲット（元のリクエストを送信したピアの制御アプリケーションまたはANCPエージェント）;
o Action RECOMMENDED for the receiving ANCP agent.
o 受信ANCPエージェントに推奨されるアクション。
In addition to any suggested action in the text that follows, a count of the number of times a given non-zero Result Code value was received SHOULD be provided for management. Where an action includes the re-sending of a request, a given request SHOULD NOT be re-sent more than once.
次のテキストで提案されたアクションに加えて、特定の非ゼロ結果コード値が受信された回数の数のカウントを管理に提供する必要があります。アクションにリクエストの再整理が含まれる場合、特定のリクエストを複数回再セントするべきではありません。
This document specifies the following Result Code values.
このドキュメントは、次の結果コード値を指定します。
Result Code value: 0x2
結果コード値：0x2
* One-line description: Invalid request message
* 一線の説明：無効な要求メッセージ
* Where condition detected: ANCP agent
* 条件が検出された場合：ANCPエージェント
* Further description: The request was a properly formed message that violates the protocol through its timing or direction of transmission. The most likely reason for this outcome in the field will be a race condition.
* 詳細な説明：リクエストは、そのタイミングまたは送信方向を通じてプロトコルに違反する適切に形成されたメッセージでした。このフィールドでのこの結果の最も可能性の高い理由は、人種状態になります。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 応答メッセージに必要な追加情報：なし、応答メッセージがリクエストと同じタイプの場合。セクション4.2で指定されているように、応答メッセージが一般的な応答メッセージである場合。
* Target: ANCP agent at the peer that sent the original request
* ターゲット：元のリクエストを送信したピアのANCPエージェント
* Action RECOMMENDED for the receiving ANCP agent: The original request MAY be re-sent once only after a short delay. Inform the control application with appropriate identification of the failed transaction if the second attempt fails or no second attempt is made.
* 受信ANCPエージェントに推奨されるアクション：元のリクエストは、短い遅延の後にのみ1回再配置される場合があります。2回目の試行が失敗するか、2回目の試行が行われない場合、失敗したトランザクションを適切に識別して、制御アプリケーションに通知します。
Result Code value: 0x6
結果コード値：0x6
* One-line description: One or more of the specified ports are down
* 一線の説明：指定されたポートの1つ以上がダウンしています
* Where condition detected: Control application
* 条件が検出された場合：制御アプリケーション
* Further description (if any): This Result Code value indicates a state mismatch between the NAS and AN control applications, possibly due to a race condition.
* 詳細な説明（ある場合）：この結果コード値は、おそらく人種条件によるNASと制御アプリケーションの間の状態の不一致を示しています。
* Required additional information in the response message: If the request identified multiple access lines or the response is a Generic Response message, then the response MUST contain a Status-Info TLV encapsulating TLV(s) containing the line identifier(s) of the access lines that are not operational.
* 応答メッセージの必要な追加情報：リクエストが複数のアクセス行を特定するか、応答が汎用応答メッセージである場合、応答には、アクセスラインのライン識別子を含むTLVをカプセル化するステータスとfo TLVを含める必要があります。それは動作していません。
* Target: Control application at the peer that sent the original request
* ターゲット：元のリクエストを送信したピアでのコントロールアプリケーション
* Action RECOMMENDED for the receiving ANCP agent: Indicate the error and forward the line identifier(s) to the control application.
* 受信ANCPエージェントに推奨されるアクション：エラーを示し、ライン識別子を制御アプリケーションに転送します。
Result Code value: 0x13
結果コード値：0x13
* One-line description: Out of resources
* 一線の説明：リソースから
* Where condition detected: ANCP protocol layer or control application
* 検出された条件：ANCPプロトコル層または制御アプリケーション
* Further description (e.g., memory exhausted): This Result Code value MUST be reported only by the AN, and indicates a condition that is probably unrelated to specific access lines (although it may be related to the specific request).
* 詳細な説明（例：メモリが使い果たされたメモリ）：この結果コード値は、ANによってのみ報告される必要があり、特定のアクセス行とはおそらく無関係の条件を示します（ただし、特定のリクエストに関連している可能性があります）。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 応答メッセージに必要な追加情報：なし、応答メッセージがリクエストと同じタイプの場合。セクション4.2で指定されているように、応答メッセージが一般的な応答メッセージである場合。
* Target: ANCP agent at the peer that sent the original request
* ターゲット：元のリクエストを送信したピアのANCPエージェント
* Action RECOMMENDED for the receiving ANCP agent: If the NAS receives this Result Code value from multiple requests for the same AN in a short interval, it SHOULD reduce the rate at which it sends requests in proportion to the rate at which requests are failing with Result Code = 19. It MAY retry individual requests. If only a specific request is failing with Result Code = 19, the ANCP agent in the NAS MAY request the control application to decompose the request into simpler components if this is possible.
* 受信ANCPエージェントに推奨されるアクション：NASが短い間隔で同じanの複数の要求からこの結果コード値を受信した場合、結果が結果で失敗しているレートに比例して要求を送信するレートを減らす必要がありますコード= 19.個々のリクエストを再試行する場合があります。結果コード= 19で特定の要求のみが失敗している場合、NASのANCPエージェントは、これが可能であれば、コントロールアプリケーションにリクエストを単純なコンポーネントに分解するよう要求することができます。
Result Code value: 0x51
結果コード値：0x51
* One-line description: Request message type not implemented
* ワンラインの説明：リクエストメッセージタイプは実装されていません
* Where condition detected: ANCP agent
* 条件が検出された場合：ANCPエージェント
* Further description: This could indicate a mismatch in protocol version or capability state. It is also possible that support of a specific message is optional within some ANCP capability.
* 詳細な説明：これは、プロトコルバージョンまたは機能状態の不一致を示している可能性があります。また、特定のメッセージのサポートが一部のANCP機能内でオプションである可能性もあります。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 応答メッセージに必要な追加情報：なし、応答メッセージがリクエストと同じタイプの場合。セクション4.2で指定されているように、応答メッセージが一般的な応答メッセージである場合。
* Target: ANCP agent at the peer that sent the original request
* ターゲット：元のリクエストを送信したピアのANCPエージェント
* Action RECOMMENDED for the receiving ANCP agent: If the receiver of this Result Code value expects that support of the message type concerned is mandatory according to the capabilities negotiated for the session, it MAY re-send the message in case the message was corrupted in transit the first time. If that fails, and use of the message type cannot be avoided, the ANCP agent MAY reset the adjacency by sending an RSTACK adjacency message as described in Section 3.5.2.6.1, where Sender and Receiver Name, Port, and Instance are taken from recorded adjacency state. If a reset does not eliminate the problem, the receiving ANCP agent SHOULD raise an alarm to management and then cease to operate.
* 受信ANCPエージェントに推奨されるアクション：この結果コード値の受信者が、関係するメッセージタイプのサポートがセッションのために交渉された機能に応じて必須であると予想している場合、メッセージが輸送中に破損した場合にメッセージを再供給する可能性があります初めて。それが失敗し、メッセージタイプの使用を回避できない場合、ANCPエージェントは、セクション3.5.2.6.1で説明されているRSTACK隣接メッセージを送信して隣接することをリセットできます。隣接する状態を記録しました。リセットが問題を排除しない場合、受信ANCPエージェントは管理にアラームを上げて、操作を停止する必要があります。
Result Code value: 0x53
結果コード値：0x53
* One-line description: Malformed message
* 一線の説明：奇形のメッセージ
* Where condition detected: ANCP agent
* 条件が検出された場合：ANCPエージェント
* Further description: This could be the result of corruption in transit, or an error in implementation at one end or the other.
* 詳細な説明：これは、輸送中の腐敗の結果、または一方の端または他方での実装のエラーの結果である可能性があります。
* Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
* 応答メッセージに必要な追加情報：なし、応答メッセージがリクエストと同じタイプの場合。セクション4.2で指定されているように、応答メッセージが一般的な応答メッセージである場合。
* Target: ANCP agent at the peer that sent the original request
* ターゲット：元のリクエストを送信したピアのANCPエージェント
* Action RECOMMENDED for the receiving ANCP agent: The request SHOULD be re-sent once to eliminate the possibility of in-transit corruption.
* 受信ANCPエージェントに推奨されるアクション：輸送中の破損の可能性を排除するために、リクエストを1回再配置する必要があります。
Result Code value: 0x54
結果コード値：0x54
* One-line description: Mandatory TLV missing
* 一線の説明：必須のTLVがありません
* Where condition detected: ANCP agent
* 条件が検出された場合：ANCPエージェント
* Further description: None
* 詳細な説明：なし
* Required additional information in the response message: The response message MUST contain a Status-Info message that encapsulates an instance of each missing mandatory TLV, where the length is set to zero and the value field is empty (i.e., only the 4-byte TLV header is present).
* 応答メッセージの必要な追加情報：応答メッセージには、欠落している各必須TLVのインスタンスをカプセル化するステータス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でメッセージを再送信します。それ以外の場合は、欠落しているTLV（S）を構築するために必要な欠落情報を示して、コントロールアプリケーションにエラーを報告します。
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をカプセル化するステータスおよびfo TLVを含める必要があります。
* Target: ANCP agent at the peer that sent the original request
* ターゲット：元のリクエストを送信したピアのANCPエージェント
* Action RECOMMENDED for the receiving ANCP agent: Correct the error and re-send the request, if possible. Otherwise, report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
* 受信ANCPエージェントに推奨されるアクション：可能であれば、エラーを修正し、リクエストを再送信します。それ以外の場合は、無効なTLVに関連する誤った情報を示して、コントロールアプリケーションにエラーを報告します。
Result Code value: 0x500
結果コード値：0x500
* One-line description: One or more of the specified ports do not exist
* 一線の説明：指定されたポートの1つ以上が存在しません
* Where condition detected: Control application
* 条件が検出された場合：制御アプリケーション
* Further description (if any): This may indicate a configuration mismatch between the AN and the NAS or Authentication, Authorization, and Accounting (AAA).
* 詳細な説明（ある場合）：これは、ANとNASの間の構成の不一致を示している場合があります。
* 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をカプセル化するステータスおよびfo TLVを含める必要があります。
* Target: Control application at the peer that sent the original request
* ターゲット：元のリクエストを送信したピアでのコントロールアプリケーション
* Action RECOMMENDED for the receiving ANCP agent: Indicate the error and forward the line identifiers to the control application.
* 受信ANCPエージェントに推奨されるアクション：エラーを示し、ライン識別子を制御アプリケーションに転送します。
The Partition ID field MUST contain the value that was negotiated for Partition ID during the adjacency procedure as described above.
パーティションIDフィールドには、上記のように隣接手続き中にパーティションIDに対して交渉された値を含める必要があります。
The Transaction ID is set by the sender of a request message to associate a response message with the original request message. Unless otherwise specified for a given message type, the Transaction ID in request messages MUST be set to a value in the range (1, 2^24 - 1). When used in this manner, the Transaction ID sequencing MUST be maintained independently for each message type within each ANCP adjacency. Furthermore, it SHOULD be incremented by 1 for each new message of the given type, cycling back to 1 after running the full range. For event messages, the Transaction ID SHOULD be set to zero.
トランザクションIDは、リクエストメッセージの送信者によって設定され、応答メッセージを元のリクエストメッセージに関連付けます。特定のメッセージタイプに特に指定されていない限り、リクエストメッセージのトランザクションIDは、範囲（1、2^24-1）の値に設定する必要があります。この方法で使用する場合、各ANCP隣接内の各メッセージタイプについて、トランザクションIDシーケンスを個別に維持する必要があります。さらに、指定されたタイプの新しいメッセージごとに1個ずつインクリメントし、フルレンジを実行した後に1に戻ります。イベントメッセージの場合、トランザクションIDをゼロに設定する必要があります。
Unless otherwise specified, the default behavior for all ANCP responses is that the value of the Transaction ID MUST be copied from the corresponding request message.
特に指定されていない限り、すべてのANCP応答のデフォルトの動作は、トランザクションIDの値を対応するリクエストメッセージからコピーする必要があることです。
In GSMPv3, these provide a mechanism for message fragmentation. Because ANCP uses TCP transport, this mechanism is unnecessary. An ANCP agent MUST set the I Flag and subMessage Number fields to 1 to signify "no fragmentation".
GSMPv3では、これらはメッセージの断片化のメカニズムを提供します。ANCPはTCPトランスポートを使用しているため、このメカニズムは不要です。ANCPエージェントは、「断片化なし」を意味するために、iフラグとサブメッサージ番号フィールドを1に設定する必要があります。
This field MUST be set to the length of the ANCP message in bytes, including its header fields and message body but excluding the 4-byte encapsulating header defined in Section 3.2.
このフィールドは、ヘッダーフィールドやメッセージ本文を含むバイトのANCPメッセージの長さに設定する必要がありますが、セクション3.2で定義されている4バイトのカプセル化ヘッダーは除外します。
The detailed contents of the message payload portion of a given ANCP message can vary with the capability in the context of which it is being used. However, the general format consists of zero or more fixed fields, followed by a variable amount of data in the form of Type-Length-Value (TLV) data structures.
特定のANCPメッセージのメッセージペイロード部分の詳細な内容は、使用されているコンテキストの機能によって異なる場合があります。ただし、一般的な形式は、ゼロ以上の固定フィールドで構成され、その後、型長値（TLV）データ構造の形式で変数のデータが使用されます。
The general format of a TLV is shown in Figure 8:
TLVの一般的な形式を図8に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビット）：TLVの値フィールドのデータのバイト数。このTLVを4バイトワード境界にするために必要なパディングを除く（以下の「値」を参照）。TLVに他のTLVが含まれている場合、含まれるTLVのパディングは長さの値に含める必要があります。TLVの仕様に応じて、長さの値はゼロ、TLVのすべてのインスタンスの定数、またはさまざまな量になります。
Value (variable): The actual data carried by the TLV, if any. The Value field in each TLV MUST be padded with zeroes as required to align with a 4-byte word boundary. The Value field of a TLV MAY include fixed fields and/or other TLVs.
値（変数）：TLVが運ぶ実際のデータ（ある場合）。各TLVの値フィールドは、4バイトの単語境界に合わせて必要に応じて、ゼロでパッドでパッドで付与する必要があります。TLVの値フィールドには、固定フィールドおよび/または他のTLVが含まれる場合があります。
Unless otherwise specified, TLVs MAY be added to a message in any order. If the recipient of a message does not understand a particular TLV, it MUST silently ignore it.
特に指定されていない限り、TLVは任意の順序でメッセージに追加される場合があります。メッセージの受信者が特定のTLVを理解していない場合、静かに無視する必要があります。
A number of TLVs are specified in the remainder of this document.
このドキュメントの残りの部分では、多くのTLVが指定されています。
ANCP allows for two messaging constructs to support request/response interaction:
ANCPでは、2つのメッセージングコンストラクトがリクエスト/応答の相互作用をサポートすることを可能にします。
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. リクエストと応答のメッセージは、2つの異なるメッセージタイプを使用します。
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のプロトコル仕様、2番目のアプローチはセクション6.4の仕様によって説明されています。このセクションの目的は、追加のANCP拡張機能の開発のためにこのメッセージングコンストラクトを使用するために、2番目のアプローチに関する詳細を提供することです。
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メッセージは共通のヘッダー形式を共有しています。応答メッセージタイプがリクエストのタイプと異なる場合、リクエストメッセージの指定は通常、結果フィールドが無視するように設定されていることを示し、レシーバーが応答を生成する時期とそれを明示的に示す手順を提供します使用する必要があります。
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にANに送信します。プロビジョニングメッセージには、図9に示す形式があります。ANCPエージェントがその使用を必要とする機能をサポートしない限り、プロビジョニングメッセージのサポートはオプションです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of the Provisioning Message
図9：プロビジョニングメッセージの形式
The message header field settings given below are REQUIRED in the Provisioning message. The remaining message header fields MUST be set as specified in Section 3.6.1. Which TLVs to carry in the Provisioning message is specified as part of the specification of the capabilities that use that message. The Provisioning message MAY be used to carry data relating to more than one capability at once, assuming that the capabilities concerned can coexist and have all been negotiated during adjacency establishment.
以下に示すメッセージヘッダーフィールド設定は、プロビジョニングメッセージに必要です。残りのメッセージヘッダーフィールドは、セクション3.6.1で指定されているように設定する必要があります。プロビジョニングメッセージに携帯するTLVは、そのメッセージを使用する機能の仕様の一部として指定されています。プロビジョニングメッセージは、関係する機能が共存し、隣接施設中にすべて交渉されたと仮定して、一度に複数の機能に関連するデータを一度に伝達するために使用できます。
Message Type: MUST be set to 93.
メッセージタイプ：93に設定する必要があります。
Result: MUST be set to 0x0 (Ignore).
結果：0x0に設定する必要があります（無視）。
Result Code: MUST be set to zero.
結果コード：ゼロに設定する必要があります。
Transaction ID: MUST be populated with a non-zero value chosen in the manner described in Section 3.6.1.6.
トランザクションID：セクション3.6.1.6で説明されている方法で選択された非ゼロ値を入力する必要があります。
If the AN can process the message successfully and accept all the provisioning directives contained in it, the AN MUST NOT send any response.
ANがメッセージを正常に処理し、その中に含まれるすべてのプロビジョニング指令を受け入れることができる場合、ANは応答を送信してはなりません。
Unless otherwise specified for a particular capability, if the AN fails to process the message successfully it MUST send a Generic Response message (Section 4.2) indicating failure and providing appropriate diagnostic information.
特定の機能に特に指定されていない限り、ANがメッセージを正常に処理できなかった場合、障害を示す一般的な応答メッセージ（セクション4.2）を送信し、適切な診断情報を提供する必要があります。
This section defines the Generic Response message. The Generic Response message MAY be specified as the appropriate response to a message defined in an extension to ANCP, instead of a more specific response message. As a general guideline, specification of the Generic Response message as a response is appropriate where no data needs to be returned to the peer other than a result (success or failure), plus, in the case of a failure, a code indicating the reason for failure and a limited amount of diagnostic data. Depending on the particular use case, the Generic Response message MAY be sent by either the NAS or the AN.
このセクションでは、一般的な応答メッセージを定義します。一般的な応答メッセージは、より具体的な応答メッセージの代わりに、ANCPの拡張機能で定義されたメッセージに対する適切な応答として指定される場合があります。一般的なガイドラインとして、結果としての一般的な応答メッセージの指定は、結果（成功または失敗）以外のピアにデータを返す必要がない場合に適切です。障害と限られた量の診断データ。特定のユースケースに応じて、汎用応答メッセージはNASまたはANによって送信される場合があります。
Support of the Generic Response message, both as sender and as receiver, is REQUIRED for all ANCP agents, regardless of what capabilities they support.
送信者と受信者としての一般的な応答メッセージのサポートは、どの機能をサポートする機能に関係なく、すべてのANCPエージェントに必要です。
The AN or NAS MAY send a Generic Response message indicating a failure condition independently of a specific request before closing the adjacency as a consequence of that failure condition. In this case, the sender MUST set the Transaction ID field in the header and the Message Type field within the Status-Info TLV to zeroes. The receiver MAY record the information contained in the Status-Info TLV for management use.
ANまたはNASは、その障害条件の結果として隣接を閉じる前に、特定の要求とは無関係に障害条件を示す汎用応答メッセージを送信する場合があります。この場合、送信者はヘッダーにトランザクションIDフィールドを設定する必要があり、メッセージタイプフィールドはステータスINFO TLVからゼロに設定する必要があります。受信者は、管理の使用のためにステータスとfo 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.
このドキュメントは、次のヘッダーフィールドを指定します。ANCP一般メッセージヘッダーの残りのフィールドは、セクション3.6.1で指定されているように設定する必要があります。
Message Type: MUST be set to 91.
メッセージタイプ：91に設定する必要があります。
Result: MUST be set to 0x3 (Success) or 0x4 (Failure).
結果：0x3（成功）または0x4（失敗）に設定する必要があります。
Result Code: MUST be set to zero for success or an appropriate non-zero value for failure.
結果コード：成功のためにゼロに設定する必要があります。
Transaction ID: MUST be copied from the message to which this message is a response.
トランザクションID：このメッセージが応答であるメッセージからコピーする必要があります。
If the original request applied to a specific access line or set of lines, the TLVs identifying the line(s) and possibly the user MUST be copied into the Generic Response message at the top level.
元のリクエストが特定のアクセスラインまたは行のセットに適用された場合、TLVが行を識別し、場合によってはユーザーを上部レベルの汎用応答メッセージにコピーする必要があります。
The Status-Info TLV MAY be present in a success response, to provide a warning as defined for a specific request message type. It MUST be present in a failure response. See Section 4.5 for a detailed description of the Status-Info TLV. The actual contents will depend on the request message type this message is responding to and the value of the Result Code field.
Status-info TLVは、特定のリクエストメッセージタイプに対して定義された警告を提供するために、成功応答に存在する場合があります。障害応答に存在する必要があります。Status-info TLVの詳細な説明については、セクション4.5を参照してください。実際の内容は、このメッセージが応答しているリクエストメッセージタイプと結果コードフィールドの値によって異なります。
To prevent an infinite loop of error responses, if the Generic Response message is itself in error, the receiver MUST NOT generate an error response in return.
エラー応答の無限のループを防ぐために、一般的な応答メッセージ自体がエラーである場合、受信者は見返りにエラー応答を生成してはなりません。
Type: 0x1000 to 0x1020 depending on the specific content. Only 0x1000 has been assigned in this specification (see below). Support of any specific variant of the Target TLV is OPTIONAL unless the ANCP agent claims support for a capability that requires its use.
タイプ：特定のコンテンツに応じて、0x1000〜0x1020。この仕様には0x1000のみが割り当てられています（以下を参照）。ターゲットTLVの特定のバリアントのサポートは、ANCPエージェントがその使用を必要とする機能に対するサポートを請求しない限り、オプションです。
Description: The Target TLV (0x1000 - 0x1020) is intended to be a general means to represent different types of objects.
説明：ターゲットTLV（0x1000-0x1020）は、異なるタイプのオブジェクトを表す一般的な手段であることを目的としています。
Length: Variable, depending on the specific object type.
長さ：変数、特定のオブジェクトタイプに応じて。
Value: Target information as defined for each object type. The Value field MAY consist of sub-TLVs.
値：各オブジェクトタイプに対して定義されているターゲット情報。値フィールドは、サブTLVで構成されている場合があります。
TLV Type 0x1000 is assigned to a variant of the Target TLV representing a single access line and encapsulating one or more sub-TLVs identifying the target. Figure 11 is an example illustrating the TLV format for a single port identified by an Access-Loop-Circuit-ID TLV (0x0001) (Section 5.1.2.1).
TLVタイプ0x1000は、単一のアクセスラインを表すターゲットTLVのバリアントに割り当てられ、ターゲットを識別する1つ以上のサブTLVをカプセル化します。図11は、Access-Loop-Circuit-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を運ぶことができる各メッセージタイプの仕様は、ペイロードのコンテンツの意味を定義することが期待されますが、もちろん、必要に応じて仕様の再利用は許容されます。Command TLVの特定のバリアントのサポートは、ANCPエージェントがその使用を必要とする機能をサポートしない限り、オプションです。
Length: Variable, depending on the specific contents.
長さ：変数、特定の内容に応じて。
Value: Command information as defined for each message type. The field MAY include sub-TLVs. The contents of this TLV MUST be specified as one "command" or alternatively a sequence of one or more "commands", each beginning with a 1-byte Command Code and possibly including other data following the Command Code. An IANA registry has been established for Command Code values. This document reserves the Command Code value 0 as an initial entry in the registry.
値：各メッセージタイプに対して定義されているコマンド情報。フィールドにはサブTLVが含まれる場合があります。このTLVの内容は、1つの「コマンド」または1つ以上の「コマンド」のシーケンスとして指定する必要があります。それぞれが1バイトコマンドコードで始まり、おそらくコマンドコードに従って他のデータを含める必要があります。コマンドコード値のためにIANAレジストリが確立されています。このドキュメントは、レジストリの初期エントリとしてコマンドコード値0を留保します。
Name: Status-Info
名前：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.
説明：Status-INFO-TLVは、コマンドやリクエストに関連する警告またはエラー診断の一般的なコンテナであることを目的としています。これは、ANCP一般ヘッダーの結果コードフィールドのサプリメントです。個々のメッセージタイプの仕様は、特に障害に対する応答の一部としてこのTLVの使用を示している場合があります。上記のように、一般的な応答メッセージには、通常、ステータスインフーTLVのインスタンスが含まれます。送信者としておよび受信者としてのステータスINFO 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.
MSGタイプ（8ビット）：メッセージタイプこのTLVが診断を提供しているリクエストのタイプ。
Error Message Length (16 bits): Number of bytes in the error message, excluding padding, but including the language tag and delimiter. This MAY be zero if no error message is provided.
エラーメッセージの長さ（16ビット）：パディングを除くが、言語タグとデリミッターを含むエラーメッセージのバイト数。エラーメッセージが提供されていない場合、これはゼロになる場合があります。
Error Message: Human-readable string providing information about the warning or error condition. The initial characters of the string MUST be a language tag as described in [RFC5646], terminated by a colon (":"). The actual text string follows the delimiter. The field is padded at the end with zeroes as necessary to extend it to a 4-byte word boundary.
エラーメッセージ：警告またはエラーの状態に関する情報を提供する人間読み取り可能な文字列。文字列の最初の文字は、コロン（ "："）で終了した[RFC5646]で説明されている言語タグでなければなりません。実際のテキスト文字列は、区切り文字に従います。フィールドは、必要に応じてゼロで端にパッドにされており、4バイトワードの境界に拡張します。
Section 3.6.1.4 provides recommendations for what TLVs to add in the Status-Info TLV for particular values of the message header Result Code field.
セクション3.6.1.4では、メッセージヘッダー結果コードフィールドの特定の値に対してステータスインフェトTLVに追加するTLVの推奨事項を示します。
Figure 12 illustrates the Status-Info TLV.
図12は、ステータスとfo 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. デジタルサブスクライバーライン（DSLS）のANCP機能の紹介
DSL is a widely deployed access technology for Broadband Access for Next Generation Networks. Specifications such as [TR-059], [TR-058], and [TR-092] describe possible architectures for these access networks. The scope of these specifications includes the delivery of voice, video, and data services.
DSLは、次世代ネットワーク向けのブロードバンドアクセスのための広く展開されているアクセステクノロジーです。[TR-059]、[TR-058]、[TR-092]などの仕様は、これらのアクセスネットワークの可能なアーキテクチャを説明しています。これらの仕様の範囲には、音声、ビデオ、およびデータサービスの配信が含まれます。
The next three sections of this document specify basic ANCP capabilities for use specifically in controlling Access Nodes serving DSL access (Tech Type = 0x05). The same ANs could be serving other access technologies (e.g., Metro-Ethernet, Passive Optical Networking, WiMax), in which case the AN will also have to support the corresponding other-technology-specific capabilities. Those additional capabilities are outside the scope of the present document.
このドキュメントの次の3つのセクションでは、DSLアクセスを提供するアクセスノードの制御に特に使用するための基本的なANCP機能を指定します（Tech Type = 0x05）。同じANSは、他のアクセステクノロジー（メトロエテルネット、パッシブ光ネットワーク、WIMAXなど）を提供することもできます。この場合、ANは対応する他の技術固有の機能もサポートする必要があります。これらの追加機能は、現在のドキュメントの範囲外です。
Most ANCP messages involve actions relating to a specific access line. Thus, it is necessary to describe how access lines are identified within those messages. This section defines four TLVs for that purpose and provides an informative description of how they are used.
ほとんどのANCPメッセージには、特定のアクセスラインに関連するアクションが含まれます。したがって、これらのメッセージ内でアクセスラインがどのように識別されるかを説明する必要があります。このセクションでは、その目的のために4つのTLVを定義し、使用方法の有益な説明を提供します。
Three types of identification are described in [TR-101] and provided for in the TLVs defined in this section:
[TR-101]で3種類の識別が記載され、このセクションで定義されている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 他の2つのフォームのいずれかでアクセスライン識別のサプリメントとして、ユーザーまたはホストレベルまでの識別。
All of these identifiers originate with the AN control application, during the process of DSL topology discovery. The control application chooses which identifiers to use and the values to place into them on a line-by-line basis, based on AN configuration and deployment considerations.
これらの識別子はすべて、DSLトポロジの発見のプロセス中に、制御アプリケーションから発生します。制御アプリケーションは、使用する識別子と、構成と展開の考慮事項に基づいて、行ごとに配置する値を選択します。
Aside from its use in ANCP signalling, access line identification is also used in DHCP ([RFC2131], [RFC3315]) transactions involving hosts served by DSL. Either the AN or the NAS can serve as a DHCP relay node. [TR-101] requires the AN or NAS in this role to add access line identification in Option 82 (Information) ([RFC3046], with its IPv6 equivalent in [RFC4649]) to each DHCP request it forwards to the DHCP server. It is desirable for efficiency that the identification used in this signalling should be the same as the identification used in ANCP messages.
ANCPシグナル伝達での使用は別として、DSLが提供するホストを含むDHCP（[RFC2131]、[RFC3315]）トランザクションでもアクセスラインの識別が使用されています。ANまたはNASのいずれかがDHCPリレーノードとして機能します。[TR-101]は、この役割のANまたはNASに、オプション82（[RFC4649]に相当するIPv6を使用して、オプション82（[RFC3046]）にアクセスライン識別を追加する必要があります。このシグナル伝達で使用されている識別は、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自体の観点から、識別子は不透明です。ANコントロールアプリケーションの観点から、ユーザー側アクセスライン識別子の構文は、DHCPオプション82の[TR-101]のセクション3.9.3で指定されているものと同じです。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アクセスラインを一意に識別します。アクセスノードのNAS側の論理的な外観による識別は、両側の外観の間に1対1のマッピングがあり、ANとNASの間にアイデンティティ修飾集約がない場合にのみ一意です。他の場合、特にN：1 VLANモデルを使用したイーサネット集約の場合、ユーザー側のアクセスラインの識別が必要ですが、NAS側の識別は潜在的に有用な情報であり、NASがの写真を構築できるようにすることができます。集約ネットワークトポロジ。
Additional identification down to the user or host level is intended to supplement rather than replace either of the other two forms of identification.
ユーザーまたはホストレベルまでの追加の識別は、他の2つの形式の識別のいずれかを置き換えるのではなく、補足することを目的としています。
Sections 3.8 and 3.9 of [TR-101] are contradictory on this point. It is assumed here that Section 3.9 is meant to be authoritative.
[TR-101]のセクション3.8および3.9は、この点で矛盾しています。ここでは、セクション3.9は権威あることを意図していると想定されています。
The user-level identification takes the form of an administered string that again is opaque at the ANCP level.
ユーザーレベルの識別は、ANCPレベルで再び不透明である管理された文字列の形を取得します。
The NAS control application will use the identifying information it receives from the AN directly for some purposes. For examples, see the introductory part of Section 3.9 of [TR-101]. For other purposes, the NAS will build a mapping between the unique access line identification provided by the AN, the additional identification of the user or host (where provided), and the IP interface on a particular host. For access lines with static IP address assignment, that mapping could be configured instead.
NAS制御アプリケーションは、いくつかの目的のために直接ANから受け取る識別情報を使用します。たとえば、[TR-101]のセクション3.9の紹介部分を参照してください。他の目的のために、NASは、ANが提供する一意のアクセスライン識別、ユーザーまたはホストの追加識別（提供されている場合）、および特定のホストのIPインターフェイスの間のマッピングを構築します。静的IPアドレス割り当てのアクセスラインの場合、そのマッピングを代わりに構成できます。
This section provides a normative specification of the TLVs that ANCP provides to carry the types of identification just described. The Access-Loop-Circuit-ID TLV identifies an access line by its logical appearance on the user side of the Access Node. Two alternatives, the Access-Aggregation-Circuit-ID-ASCII TLV and the Access-Aggregation-Circuit-ID-Binary TLV, identify an access line by its logical appearance on the NAS side of the Access Node. It is unlikely that a given AN uses both of these TLVs, either for the same line or for different lines, since they carry equivalent information. Finally, the Access-Loop-Remote-ID TLV contains an operator-configured string that uniquely identifies the user on the associated access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].
このセクションでは、ANCPが提供するTLVの規範的な仕様を、これまでに説明した識別の種類を運ぶことができます。Access-Loop-Circuit-ID TLVは、アクセスノードのユーザー側での論理的な外観によってアクセスラインを識別します。2つの代替手段、アクセスアグレジョン - サーキット-ID-ASCII TLVとAccess-Aggregation-Circuit-ID-Binary TLVは、アクセスノードのNAS側での論理的な外観によるアクセスラインを識別します。同等の情報を携帯するため、同じラインまたは異なる線でこれらのTLVの両方を使用する可能性は低いです。最後に、Access-Loop-Remote-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エージェントは、Access-Loop-Circuit-ID TLV、Access-Loop-Remote-ID TLV、およびAccess-Aggregation-Circuit-ID-Ascii TLVまたはAccess-Aggregation-Circuit-を構築して送信できる必要があります。ID-Binary 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.
o アクセスループリモートID TLVがメッセージに存在している場合、アクセスループ回路ID TLVおよび/またはアクセスアグレジェレーション - サーキット-ID-ASCII TLVまたはアクセスアグレジョンサーキットを添付する必要があります-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.
Access-Loop-Remote-ID TLVは、アクセスラインを単独で識別するのに十分ではありません。上記のように、2つのVLAN識別子を備えたアクセスアグリジェレーション - 回路-ID-ASCII TLVまたはアクセスアグリレジェリュテーション - アシド - ID-ID-バイナリTLVは、アクセスラインを一意に識別する場合と識別できない場合がありますが、これは制御アプリケーション次第です。。
o If the Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-Binary TLV is present in a message with just one VLAN identifier, it MUST be accompanied by an Access-Loop-Circuit-ID TLV.
o Access-Aggregation-Circuit-ID-Ascii TLVまたはAccess-Aggregation-Circuit-ID-Binary TLVが、1つのVLAN識別子のみのメッセージに存在する場合、アクセスループ回路ID TLVを添付する必要があります。
Type: 0x0001
タイプ：0x0001
Description: A locally administered human-readable string generated by or configured on the Access Node, identifying the corresponding access loop logical port on the user side of the Access Node.
説明：アクセスノードで生成または構成されたローカルに管理されたヒューマン読み取り可能な文字列。アクセスノードのユーザー側に対応するアクセスループ論理ポートを識別します。
Length: Up to 63 bytes
長さ：最大63バイト
Value: ASCII string
値：ASCII文字列
Type: 0x0002
タイプ：0x0002
Description: An operator-configured string that uniquely identifies the user on the associated access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].
説明：[TR-101]のセクション3.9.1および3.9.2で説明されているように、関連するアクセスライン上のユーザーを一意に識別するオペレーター構成文字列。
Length: Up to 63 bytes
長さ：最大63バイト
Value: ASCII string
値：ASCII文字列
Type: 0x0006
タイプ：0x0006
Description: This TLV identifies or partially identifies a specific access line by means of its logical circuit identifier on the NAS side of the Access Node.
説明：このTLVは、アクセスノードのNAS側にある論理回路識別子を使用して、特定のアクセスラインを識別または部分的に識別します。
For Ethernet access aggregation, where a per-subscriber (stacked) VLAN can be applied (1:1 model as defined in [TR-101]), the TLV contains two value fields. Each field carries a 12-bit VLAN identifier (which is part of the VLAN tag defined by [IEEE802.1Q]). The first field MUST carry the inner VLAN identifier, while the second field MUST carry the outer VLAN identifier.
イーサネットアクセス集約の場合、Subscriber（積み上げ）VLANを適用できる（[TR-101]で定義されている1：1モデル）、TLVには2つの値フィールドが含まれています。各フィールドには、12ビットVLAN識別子（[IEEE802.1Q]で定義されたVLANタグの一部）が搭載されています。最初のフィールドは内側のVLAN識別子を運ぶ必要があり、2番目のフィールドは外側の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モデルを使用すると、1つの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がNASに直接接続されているATM集合ネットワークの場合（中間ATMスイッチなし）、DSLAMアップリンクの仮想パス識別子（VPI）と仮想回路識別子（VCI）がDSLアクセスに一意に対応しますdslamの線。Access-Aggregation-Circuit-ID-Binary TLVを使用して、VPIおよびVCIを運ぶことができます。TLVの最初の値フィールドはVCIを運ぶ必要があり、2番目の値フィールドはVPIを運ぶ必要があります。
Each identifier MUST be placed in the low-order bits of its respective 32-bit field, with the higher-order bits set to zero. The ordering of the bits of the identifier MUST be the same as when the identifier is transmitted on the wire to identify an Ethernet frame or ATM cell.
各識別子は、それぞれの32ビットフィールドの低次ビットに配置する必要があり、高次ビットがゼロに設定されています。識別子のビットの順序は、識別子がワイヤに送信されてイーサネットフレームまたはATMセルを識別する場合と同じでなければなりません。
The Access-Aggregation-Circuit-ID-Binary is illustrated in Figure 13.
Access-Aggregation-Circuit-ID-Binaryを図13に示します。
Length: 4 or 8 bytes
長さ：4バイトまたは8バイト
Value: One or two 32-bit binary fields.
値：1つまたは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は、ASCIIに相当するASCIIに相当する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の制御アプリケーションは、ANCPに、次の状況でDSL固有のポートアップメッセージをNASに送信するよう要求します。
o when a new adjacency with the NAS is established, for each DSL loop that is synchronized at that time;
o NASとの新しい隣接が確立されると、その時点で同期されている各DSLループについて。
o subsequent to that, whenever a DSL access line resynchronizes; and
o それに続いて、DSLアクセスラインが再同期するたびに。と
o whenever the AN control application wishes to signal that a line attribute has changed.
o 制御アプリケーションが、行属性が変更されたことを信号することを望んでいるときはいつでも。
The AN control application in the DSLAM requests ANCP to send a DSL-specific Port Down message to the NAS under the following circumstances:
DSLAMの制御アプリケーションは、ANCPに、次の状況でDSL固有のポートをNASに送信するよう要求します。
o when a new adjacency with the NAS is established, for each DSL loop that is provisioned but not synchronized at that time;
o NASとの新しい隣接が確立された場合、プロビジョニングされているがその時点では同期していない各DSLループについて。
o whenever a DSL access line that is equipped in an AN but administratively disabled is signaled as "IDLE"; and
o ANに装備されているDSLアクセスラインはいつでも、管理上無効にされている場合は「アイドル」として信号を送られます。と
o subsequent to that, whenever a DSL access line loses synchronization.
o それに続いて、DSLアクセスラインが同期を失うたびに。
The AN control application passes information to identify the DSL loop to ANCP to include in the Port Up or Port Down message, along with information relating to DSL access line attributes.
AN Controlアプリケーションは、情報を渡してDSLループを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マルチペアボンディングに従って）の結合銅ループの場合、ANCがDSL固有のポートを送信してポートダウンすることをコントロールアプリケーションが要求します。集約「DSLボンデッド回路」（単一の論理ポートとして表される）およびそれが構成されている個々のDSLアクセスラインのメッセージ。制御アプリケーションによって渡されるDSLアクセスライン属性に関する情報は、集計情報です。
ANCP generates the DSL-specific Port Up or Port Down message and transfers it to the NAS. ANCP on the NAS side passes an indication to the NAS control application that a DSL Port Up or Port Down message has been received along with the information contained in the message.
ANCPは、DSL固有のポートアップまたはポートダウンメッセージを生成し、NASに転送します。NAS側のANCPは、DSLがメッセージに含まれる情報とともに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エージェントは、DSL固有のポートUPに関連付けられたAN側の手順に従って、セクション6.4で指定されているように、ポートダウンメッセージに従う必要があります。
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エージェントは、DSL固有のポートアップに関連するNAS側の手順に従って、セクション6.4で指定されているようにメッセージを下げなければなりません。
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 Identifier field MUST also be set to zeroes. Other fields in the general header MUST be set a as described in Section 3.6.
ANCP一般メッセージヘッダーの説明については、セクション3.6.1を参照してください。メッセージタイプフィールドは、ポートアップで80、ポートダウンの場合は81に設定する必要があります。4ビット結果フィールドはゼロに設定する必要があります（Ingroreを意味します）。12ビット結果コードフィールドと24ビットトランザクション識別子フィールドもゼロに設定する必要があります。一般的なヘッダーの他のフィールドは、セクション3.6で説明されているようにAを設定する必要があります。
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).
Tech Type（8ビット）：0x05（DSL）に設定する必要があります。
Reserved (8 bits): set as described in Section 3.4.
予約済み（8ビット）：セクション3.4で説明されているように設定します。
# of TLVs (16 bits): The number of TLVs that follow, not counting TLVs encapsulated within other TLVs.
＃TLVS（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.
TLVS：DSLアクセスラインを識別する1つ以上のTLVと、その特性を定義するゼロ以上の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固有のポートアップまたはポートダウンメッセージを作成および送信します。アクセスノードは、DSLアクセスラインごとの減衰メカニズムを使用して、状態の変更がNASに通信される速度を制御することをお勧めします。
At the top level, the extension block within a DSL-specific Port Up or Port Down message MUST include TLVs from Section 5.1.2 to identify the DSL access line.
上部レベルでは、DSL固有のポートアップまたはポートダウンメッセージ内の拡張ブロックには、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（つまり、セクション6.5で指定されたTLV）は、DSL-Line-Attributes TLV内でカプセル化する必要があります。dsl-line-attributes TLVがメッセージに存在する場合、少なくとも1つのそのようなTLVを含める必要があり、通常は複数を含みます。ポートアップメッセージには、DSL-Line-Attributes TLVが存在する必要があります。ポートダウンメッセージには、DSL-Line-Attributes TLVが存在する可能性があります。
The NAS-side ANCP agent MUST be prepared to receive Port Up and Port Down messages for a given DSL access line or logical port at any time after negotiation of an adjacency has been completed. It is possible for two Port Up messages in succession to be received for the same DSL access line without an intervening Port Down message, and vice versa.
NAS側のANCPエージェントは、隣接の交渉が完了した後、いつでも特定のDSLアクセスラインまたは論理ポートのポートアップおよびポートダウンメッセージを受信し、ポートダウンメッセージを受信する必要があります。介在するポートダウンメッセージなしで、同じDSLアクセスラインに対して2つのポートアップメッセージが受信される可能性があります。その逆も同様です。
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で説明されているように、メッセージヘッダー結果コード値に適した他の情報が含まれるステータスおよびfo 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-Line-Attributes TLVは、トップレベルのポートアップまたはポートダウンメッセージに挿入されます。以下に定義されている残りのTLVは、DSL-Line-Attributes TLV内でカプセル化されています。
Type: 0x0004
タイプ：0x0004
Description: This TLV encapsulates attribute values for a DSL access line serving a subscriber.
説明：このTLVは、サブスクライバーを提供するDSLアクセスラインの属性値をカプセル化します。
Length: Variable (up to 1023 bytes)
長さ：変数（最大1023バイト）
Value: One or more encapsulated TLVs corresponding to DSL access line attributes. The DSL-Line-Attributes TLV MUST contain at least one TLV when it is present in a Port Up or Port Down message. The actual contents are determined by the AN control application.
値：DSLアクセスライン属性に対応する1つ以上のカプセル化されたTLV。DSL-Line-Attributes TLVには、ポートアップまたはポートダウンメッセージに存在する場合、少なくとも1つのTLVを含める必要があります。実際の内容は、制御アプリケーションによって決定されます。
Type: 0x0091
タイプ：0x0091
Description: Indicates the type of transmission system in use.
説明：使用中の伝送システムのタイプを示します。
Length: 4 bytes
長さ：4バイト
Value: 32-bit unsigned integer
値：32ビットの符号なし整数
ADSL1 = 1
ADSL2 = 2
ADSL2+ = 3
ADSL2 = 3
VDSL1 = 4
VDSL2 = 5
SDSL = 6
OTHER = 0
Type: 0x0081
タイプ：0x0081
Description: Actual upstream net data rate on a DSL access line.
説明：DSLアクセスラインの実際の上流のネットデータレート。
Length: 4 bytes
長さ：4バイト
Value: Rate in kbits/s as a 32-bit unsigned integer
値：32ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
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ビットの符号なし整数としてのkbits/sのレート
Type: 0x008B
タイプ：0x008b
Description: Maximum one-way interleaving delay.
説明：最大片道インターリーブ遅延。
Length: 4 bytes
長さ：4バイト
Value: Time in ms as a 32-bit unsigned integer
値：32ビットの符号なし整数としてのMSの時間
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ビットの符号なし整数としてのMSの時間
Type: 0x008D
タイプ：0x008d
Description: Maximum one-way interleaving delay.
説明：最大片道インターリーブ遅延。
Length: 4 bytes
長さ：4バイト
Value: Time in ms as a 32-bit unsigned integer
値：32ビットの符号なし整数としてのMSの時間
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ビットの符号なし整数としてのMSの時間
Type: 0x008F
タイプ：0x008f
Description: The state of the DSL access line.
説明：DSLアクセスラインの状態。
Length: 4 bytes
長さ：4バイト
Value: 32-bit unsigned integer
値：32ビットの符号なし整数
SHOWTIME = 1
IDLE = 2
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
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 null = 2
IPoA LLC = 3
IPOA LLC = 3
IPoA Null = 4
IPOA null = 4
Ethernet over AAL5 LLC with FCS = 5
FCS = 5でAAL5 LLCを超えるイーサネット
Ethernet over AAL5 LLC without FCS = 6
fcs = 6なしでAAL5 LLCを超えるイーサネット
Ethernet over AAL5 NULL with FCS = 7
FCS = 7を使用したAAL5 null上のイーサネット
Ethernet over AAL5 NULL without FCS = 8
fcs = 8なしの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コントロールアプリケーションは、NAS側エージェントにリクエストを渡し、ポート管理（ライン構成）メッセージによって情報をANに送信します。ANサイドエージェントは、この情報を制御アプリケーションに渡し、ラインに適用します。図17は、相互作用をまとめたものです。
Home Access NAS RADIUS/AAA
Gateway Node Policy Server
-----------> --------------->
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
-------------------------->
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 Access Line構成機能には、機能タイプ0x0002が割り当てられています。この機能に関連付けられている機能はありません。
The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (line configuration) messages according to the format specified in Section 7.3.
NAS側ANCPエージェントは、セクション7.3で指定された形式に従って、DSL固有のポート管理（ライン構成）メッセージを作成できる必要があります。
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
NAS側ANCPエージェントは、セクション5.1.2の規範的要件に準拠する必要があります。
The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Management (line configuration) messages as they are specified in Section 7.4.
NAS側ANCPエージェントは、セクション7.4で指定されているDSL固有のポート管理（ライン構成）メッセージに関連するNAS側の手順に従う必要があります。
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
ANサイドANCPエージェントは、セクション5.1.2の規範的要件に準拠する必要があります。
The AN-side ANCP agent MUST be able to receive and validate DSL-specific Port Management (line configuration) messages according to the format specified in Section 7.3.
ANサイドANCPエージェントは、セクション7.3で指定された形式に従って、DSL固有のポート管理（ライン構成）メッセージを受信および検証できる必要があります。
The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Management (line configuration) messages as specified in Section 7.4.
ANサイドANCPエージェントは、セクション7.4で指定されているように、DSL固有のポート管理（ライン構成）メッセージに関連付けられたAN側の手順に従う必要があります。
The ANCP Port Management message for DSL access line configuration has the format shown in Figure 19.
DSLアクセスライン構成のANCPポート管理メッセージには、図19に示す形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (12 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=8 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Line configuration TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に設定する必要があります。4ビット結果フィールドは、NASのポリシーによって決定されるように、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.
＃TLVS（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.
TLVS：DSLアクセスラインを識別し、そのサービスデータを構成する2つ以上のTLV。
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であるService-Profile-Nameのみを識別していますが、ANCPへの拡張機能によって他のTLVが追加される場合があります。
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.
ANSIDE 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）を追加する場合があります。そうする場合、メッセージ内のさまざまな長さフィールドとTLVSフィールドの＃をそれに応じて調整する必要があります。
Currently, only the following TLV is specified for DSL access line configuration. More TLVs may be defined in a future version of this specification or in ANCP extensions for individual service attributes of a DSL access line (e.g., rates, interleaving delay, multicast channel entitlement access-list).
現在、DSLアクセスライン構成には次のTLVのみが指定されています。より多くのTLVは、この仕様の将来のバージョンまたはDSLアクセスラインの個々のサービス属性のANCP拡張機能（レート、インターリーブ遅延、マルチキャストチャネルの資格アクセスリスト）で定義されます。
Type: 0x0005
タイプ：0x0005
Description: Reference to a pre-configured profile on the DSLAM that contains service-specific data for the subscriber.
説明：サブスクライバーのサービス固有のデータを含むDSLAM上の事前に構成されたプロファイルへの参照。
Length: Up to 64 bytes
長さ：最大64バイト
Value: ASCII string containing the profile name (which the NAS learns from a policy server after a subscriber is authorized).
値：プロファイル名を含むASCII文字列（NASは、サブスクライバーが許可された後にポリシーサーバーから学習します）。
The use case and requirements for ANCP-Based DSL remote line connectivity testing are specified in Section 3.3 of [RFC5851].
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制御アプリケーションは、リクエストで独自の使用のために、ループカウントおよびタイムアウトテストパラメーターと不透明なデータを提供できます。ループカウントパラメーターは、使用するテストメッセージまたはセルの数を示します。タイムアウトパラメーターは、NAS制御アプリケーションが結果を待つ最も長いことを示します。
The request is passed in a Port Management (Operations, Administration, and Maintenance, OAM) message. If the NAS control application has supplied test parameters, they are used; otherwise, the AN control application uses default test parameters. If a loop count parameter provided by the NAS is outside the valid range, the AN does not execute the test, but returns a result indicating that the test has failed due to an invalid parameter. If the test takes longer than the timeout value (default or provided by the NAS), the AN control application can return a failure result indicating timeout or else can send no response. The AN control application can provide a human-readable string describing the test results, for both failures and successes. If provided, this string is included in the response. Responses always include the opaque data, if any, provided by the NAS control application.
リクエストは、ポート管理（運用、管理、メンテナンス、OAM）メッセージで渡されます。NAS制御アプリケーションがテストパラメーターを提供している場合、それらが使用されます。それ以外の場合、制御アプリケーションはデフォルトのテストパラメーターを使用します。NASが提供するループカウントパラメーターが有効な範囲外である場合、ANはテストを実行しませんが、無効なパラメーターのためにテストが失敗したことを示す結果を返します。テストがタイムアウト値（デフォルトまたはNASによって提供される）よりも時間がかかる場合、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.
NAS側ANCPエージェントは、セクション8.4で指定されているDSL固有のポート管理（OAM）メッセージに関連するNAS側の手順に従う必要があります。
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
ANサイドANCPエージェントは、セクション5.1.2の規範的要件に準拠する必要があります。
The AN-side ANCP agent MUST be able to receive and validate DSL-specific Port Management (OAM) messages according to the format specified in Section 8.3.
ANSIDE 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
図21：DSLラインリモート接続テストのポート管理メッセージ
From the point of view of ANCP, it is permissible to attempt line connectivity testing regardless of the state of the line. However, testing could fail in some states due to technology limitations.
ANCPの観点から見ると、ラインの状態に関係なく、ライン接続テストを試みることが許可されています。ただし、技術の制限により、一部の州ではテストが失敗する可能性があります。
When requested by the NAS control application and presented with the necessary information to do so, the NAS-side agent creates and sends a Port Management (OAM) request with the fixed fields set as described in the previous section. The message MUST contain one or 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で文書化された他の結果コード値が適用される場合があります。結果コード値0x509を使用する必要があります。OAM-Loopback-Test-Parameters TLVにカウントフィールドの無効な値が存在する場合。ANサイドエージェントは、特にこれが指定された結果コード値のセクション3.6.1.4で推奨される場合、エラーに関する詳細情報を提供するために、ステータスインフーTLV（セクション4.5）を追加する場合があります。そうする場合、メッセージ内のさまざまな長さフィールドとTLVSフィールドの＃をそれに応じて調整する必要があります。
If the received message passes validation, the AN-side ANCP agent extracts the information from the TLVs contained in the message and presents that information to the AN control application. It MUST NOT generate an immediate response to the request, but it MUST instead wait for the AN control application to indicate that the response should be sent.
受信したメッセージが検証に合格した場合、ANSIDE ANCPエージェントはメッセージに含まれるTLVから情報を抽出し、その情報を制御アプリケーションに提示します。リクエストに対する即時の応答を生成してはなりませんが、代わりに、制御アプリケーションが応答を送信する必要があることを示すのを待つ必要があります。
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-SIDEエージェントは、元のリクエストに対してポート管理（OAM）応答を作成および送信します。結果フィールドは、成功（0x3）または障害（0x4）に設定する必要があり、結果コードフィールドは、制御アプリケーションで示されるように、次の値のいずれかに設定する必要があります。
0x500: Specified access line does not exist. See the documentation of Result Code 0x500 in Section 3.6.1.4 for more information. The Result header field MUST be set to Failure (0x4).
0x500：指定されたアクセスラインは存在しません。詳細については、セクション3.6.1.4の結果コード0x500のドキュメントを参照してください。結果ヘッダーフィールドは、障害（0x4）に設定する必要があります。
0x501: Loopback test timed out. The Result header field MUST be set to Failure (0x4).
0x501：ループバックテストがタイムアウトしました。結果ヘッダーフィールドは、障害（0x4）に設定する必要があります。
0x503: DSL access line status showtime 0x504: DSL access line status idle
0x503：DSLアクセスラインステータスショータイム0x504：DSLアクセスラインステータスアイドル
0x505: DSL access line status silent
0x505：DSLアクセスラインステータスサイレント
0x506: DSL access line status training
0x506：DSLアクセスラインステータストレーニング
0x507: DSL access line integrity error
0x507：DSLアクセスラインの整合性エラー
0x508: DSLAM resource not available. The Result header field MUST be set to Failure (0x04).
0x508：DSLAMリソースは利用できません。結果ヘッダーフィールドは、障害に設定する必要があります（0x04）。
0x509: Invalid test parameter. The Result header field MUST be set to Failure (0x4).
0x509：無効なテストパラメーター。結果ヘッダーフィールドは、障害（0x4）に設定する必要があります。
All other fields of the request including the TLVs MUST be copied into the response unchanged, except that in a successful response the OAM-Loopback-Test-Parameters TLV MUST NOT appear. If the AN control application has provided the necessary information, the AN-side agent MUST also include an instance of the OAM-Loopback-Test-Response-String TLV in the response.
TLVを含むリクエストの他のすべてのフィールドは、OAM-Loopback-Test-Parameters TLVが表示されてはならないことを除いて、TLVを含むすべての応答にコピーする必要があります。制御アプリケーションが必要な情報を提供している場合、ANSIDEエージェントには、応答に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.
バイト1：カウント。ループバックテストの一部としてローカルループで生成する必要があるループバックセル/メッセージの数。カウント値は0を超え、32以下でなければなりません。
Byte 2: Timeout. Upper bound on the time in seconds that the NAS will wait for a response from the DSLAM. The value 0 MAY be used to indicate that the DSLAM MUST use a locally determined value for the timeout.
バイト2：タイムアウト。NASがDSLAMからの応答を待つ数秒での時間の上限。値0を使用して、DSLAMがタイムアウトにローカルに決定された値を使用する必要があることを示すことができます。
The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22.
OAM-Loopback-Test-Parameters 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 -Loopback-Test-Parameters 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).
説明：DSLAMから受け取ったとおりに、NASがオペレーターに表示するテストに関する有用な詳細を含む適切にフォーマットされた文字列（NASによる操作または解釈なし）。
Length: Up to 128 bytes
長さ：最大128バイト
Value: UTF-8 encoded string of text.
値：UTF-8エンコードされたテキストの文字列。
This section documents the following IANA actions:
このセクションでは、次のIANAアクションを文書化します。
o establishment of the following new ANCP registries:
o 次の新しいANCPレジストリの確立：
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;
o 新しいジョイントGSMP/ANCPバージョンレジストリの確立。
o addition of ANCP as another user of TCP port 6068 in the port number registry available from http://www.iana.org. The current user is GSMP.
o http://www.iana.orgから入手可能なポート番号レジストリでTCPポート6068の別のユーザーとしてANCPを追加します。現在のユーザーはGSMPです。
All of these actions are described in detail below except for the port registration, for which the final point above provides sufficient information.
これらのアクションはすべて、上記の最終ポイントで十分な情報を提供するポート登録を除き、以下で詳しく説明します。
IANA has created a new registry, ANCP Message Types. Additions to that registry are permitted by Standards Action, as defined by [RFC5226]. The values for Message Type MAY range from 0 to 255, but new Message Types SHOULD be assigned values sequentially from 90 onwards (noting that 91 and 93 are already assigned). The initial contents of the ANCP Message Types registry are as follows:
IANAは、新しいレジストリ、ANCPメッセージタイプを作成しました。[RFC5226]で定義されているように、そのレジストリへの追加は標準訴訟によって許可されます。メッセージタイプの値は0〜255の範囲ですが、新しいメッセージタイプは90以降の値を順番に割り当てる必要があります（91と93がすでに割り当てられていることに注意してください）。ANCPメッセージタイプレジストリの初期コンテンツは次のとおりです。
+--------------+--------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------+-----------+
| 10 | Adjacency Protocol | RFC 6320 |
| 32 | Port Management | RFC 6320 |
| 80 | Port Up | RFC 6320 |
| 81 | Port Down | RFC 6320 |
| 85 | Adjacency Update | RFC 6320 |
| 91 | Generic Response | RFC 6320 |
| 93 | Provisioning | RFC 6320 |
+--------------+--------------------+-----------+
IANA has created a new registry, ANCP Result Codes. The documentation of new Result Codes MUST include the following information:
IANAは、新しいレジストリ、ANCP結果コードを作成しました。新しい結果コードのドキュメントには、次の情報を含める必要があります。
o Result Code value (as assigned by IANA);
o 結果コード値（IANAによって割り当てられています）;
o One-line description;
o 一線の説明;
o Where condition detected (control application or ANCP agent);
o 条件が検出された場合（制御アプリケーションまたはANCPエージェント）。
o Further description (if any);
o 詳細な説明（ある場合）;
o Required additional information in the response message;
o 応答メッセージに必要な追加情報。
o Target (control application or ANCP agent at the peer that sent the original request);
o ターゲット（元のリクエストを送信したピアの制御アプリケーションまたはANCPエージェント）;
o Action RECOMMENDED for the receiving ANCP agent.
o 受信ANCPエージェントに推奨されるアクション。
The values for Result Code are expressed in hexadecimal and MAY range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is allocated by the criterion of IETF Review, as defined by [RFC5226]. IANA SHOULD allocate new Result Code values from this range sequentially beginning at 0x100. The range 0x1000 onwards is allocated by the criterion of Specification Required, as defined by [RFC5226]. IANA SHOULD allocate new Result Code values from this range sequentially beginning at 0x1000. The initial contents of the ANCP Message Types registry are as follows:
結果コードの値は16進数で表され、0x0〜0xffffffの範囲です。[RFC5226]で定義されているように、範囲0x0〜0xFFFはIETFレビューの基準によって割り当てられます。IANAは、この範囲から0x100から順番に新しい結果コード値を割り当てる必要があります。範囲0x1000以降は、[RFC5226]で定義されているように、必要な仕様の基準によって割り当てられます。IANAは、この範囲から0x1000から順番に新しい結果コード値を割り当てる必要があります。ANCPメッセージタイプレジストリの初期コンテンツは次のとおりです。
+------------+------------------------------------------+-----------+
| Result | One-line description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x0 | No result | RFC 6320 |
| 0x2 | Invalid request message | RFC 6320 |
| 0x6 | One or more of the specified ports are | RFC 6320 |
| | down | |
| 0x13 | Out of resources | RFC 6320 |
| 0x51 | Request message type not implemented | RFC 6320 |
| 0x53 | Malformed message | RFC 6320 |
| 0x54 | Mandatory TLV missing | RFC 6320 |
| 0x55 | Invalid TLV contents | RFC 6320 |
| 0x500 | One or more of the specified ports do | RFC 6320 |
| | not exist | |
| 0x501 | Loopback test timed out | RFC 6320 |
| 0x502 | Reserved | RFC 6320 |
| 0x503 | DSL access line status showtime | RFC 6320 |
| 0x504 | DSL access line status idle | RFC 6320 |
| 0x505 | DSL access line status silent | RFC 6320 |
| 0x506 | DSL access line status training | RFC 6320 |
| 0x507 | DSL access line integrity error | RFC 6320 |
| 0x508 | DSLAM resource not available | RFC 6320 |
| 0x509 | Invalid test parameter | RFC 6320 |
+------------+------------------------------------------+-----------+
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から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:
IANAは、[RFC5226]で定義されているように、Expert Reviewによる追加を伴う新しい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:
IANAは、[RFC5226]で定義されているように、標準アクションごとに追加された新しいANCPコマンドコードレジストリを作成しました。値は0〜255の範囲です。IANAは、1から順次開始する新しい値を割り当てる必要があります。初期エントリは次のとおりです。
+--------------------+-----------------------------+-----------+
| 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進数で表され、0x0000〜0xffffの範囲です。[RFC5226]で定義されているように、0x0000〜0x1FFFの範囲の追加はIETFレビューによるものです。IANAは、以下に既に行われた割り当てを考慮して、0x100から順次開始するこの範囲の新しい値を割り当てる必要があります。0x2000〜0xffffの範囲の追加は、[RFC5226]で定義されているように、必要な仕様によるものです。IANAは、0x2000から順番にこの範囲に新しい値を割り当てる必要があります。どちらの場合も、TLVのドキュメントは次のことを提供する必要があります。
o a TLV name following the convention used for the initial entries (capitalized words separated by hyphens);
o 初期エントリに使用された条約に続くTLV名（ハイフンによって区切られた大文字の単語）;
o a brief description of the intended use;
o 意図した使用の簡単な説明。
o a precise description of the contents of each fixed field, including its length, type, and units (if applicable);
o その長さ、タイプ、および単位を含む各固定フィールドの内容の正確な説明（該当する場合）。
o identification of any mandatory encapsulated TLVs;
o 必須のカプセル化されたTLVの識別。
o an indication of whether optional TLVs may be encapsulated, with whatever information is available on their identity (could range from a general class of information to specific TLV names, depending on the nature of the TLV being defined).
o オプションのTLVがカプセル化されているかどうかを示しており、そのアイデンティティで利用可能な情報を使用して（一般的なクラスの情報から特定のTLV名にまで及ぶ可能性があります。
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機能タイプレジストリを作成しました。値は0〜255の範囲です。IANAは、5から順次値を割り当てる必要があります。特定の機能の仕様は、関連するテクノロジータイプの値を示す必要があります。仕様は、機能が機能データに関連付けられているかどうかをさらに示す必要があります。通常、その機能は、プロトコル用語でその機能の実装を指定する同じドキュメントで定義される可能性があります。ANCP機能レジストリの初期エントリは次のとおりです。
+-------+------------------------+--------+-------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+------------------------+--------+-------------+-----------+
| 0 | Reserved | | | RFC 6320 |
| 1 | DSL Topology Discovery | 5 | No | RFC 6320 |
| 2 | DSL Line Configuration | 5 | No | RFC 6320 |
| 3 | Reserved | | | RFC 6320 |
| 4 | DSL Line Testing | 5 | No | RFC 6320 |
+-------+------------------------+--------+-------------+-----------+
IANA has created a new joint GSMP / ANCP Version registry. Additions to this registry are by Standards Action as defined by [RFC5226]. Values may range from 0 to 255. Values for the General Switch Management Protocol (GSMP) MUST be assigned sequentially beginning with 4 for the next version. Values for the Access Network Control Protocol (ANCP) MUST be assigned sequentially beginning with 50 for the present version. The initial entries are as follows:
IANAは、新しいジョイントGSMP / ANCPバージョンレジストリを作成しました。このレジストリへの追加は、[RFC5226]で定義されている標準アクションによるものです。値は0〜255の範囲です。一般的なスイッチ管理プロトコル（GSMP）の値は、次のバージョンの4から順次開始する必要があります。アクセスネットワーク制御プロトコル（ANCP）の値は、現在のバージョンの50から順次開始する必要があります。最初のエントリは次のとおりです。
+---------+----------------+-----------+
| Version | Description | Reference |
+---------+----------------+-----------+
| 1 | GSMP Version 1 | RFC 1987 |
| 2 | GSMP Version 2 | RFC 2297 |
| 3 | GSMP Version 3 | RFC 3292 |
| 50 | ANCP Version 1 | RFC 6320 |
+---------+----------------+-----------+
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自体に適用できるものは、現在のドキュメントにコピーされます。oプロトコルソリューションは、NASにANの認証を提供する必要があります。
o The protocol solution MUST offer authentication of the NAS to the AN.
o プロトコルソリューションは、ANにNASの認証を提供する必要があります。
o The protocol solution MUST allow authorization to take place at the NAS and the AN.
o プロトコルソリューションは、NASおよびANで認可を行うことを許可する必要があります。
o The protocol solution MUST offer replay protection.
o プロトコルソリューションは、リプレイ保護を提供する必要があります。
o The protocol solution MUST provide data-origin authentication.
o プロトコルソリューションは、データオリジン認証を提供する必要があります。
o The protocol solution MUST be robust against denial-of-service (DoS) attacks. In this context, the protocol solution MUST consider a specific mechanism for the DoS that the user might create by sending many IGMP messages.
o プロトコルソリューションは、サービス拒否（DOS）攻撃に対して堅牢でなければなりません。これに関連して、プロトコルソリューションは、多くのIGMPメッセージを送信することでユーザーが作成する可能性のあるDOSの特定のメカニズムを考慮する必要があります。
o The protocol solution SHOULD offer confidentiality protection.
o プロトコルソリューションは、機密保護を提供する必要があります。
o The protocol solution SHOULD ensure that operations in default configuration guarantee a low number of AN/NAS protocol interactions.
o プロトコルソリューションは、デフォルトの構成での操作により、AN/NASプロトコルの相互作用が少ないことを保証する必要があります。
Most of these requirements relate to secure transport of ANCP. Robustness against denial-of-service attacks partly depends on transport and partly on protocol design. Ensuring a low number of AN/NAS protocol interactions in default mode is purely a matter of protocol design.
これらの要件のほとんどは、ANCPの安全な輸送に関連しています。サービス拒否攻撃に対する堅牢性は、部分的に輸送に依存し、部分的にプロトコル設計に依存します。デフォルトモードでのAN/NASプロトコルの相互作用の数が少ないことは、純粋にプロトコル設計の問題です。
For secure transport, either the combination of IPsec with IKEv2 (references below) or the use of TLS [RFC5246] will meet the requirements listed above. However, the use of TLS has been rejected. The deciding point is a detail of protocol design that was unavailable when [RFC5713] was written. The ANCP adjacency is a major point of vulnerability for denial-of-service attacks. If the adjacency can be shut down, either the AN clears its state pending reestablishment of the adjacency, or the possibility of mismatches between the AN's and NAS's view of state on the AN is opened up. Two ways to cause an adjacency to be taken down are to modify messages so that the ANCP agents conclude that they are no longer synchronized, or to attack the underlying TCP session. TLS will protect message contents but not the TCP connection. One has to use either IPsec or the TCP authentication option [RFC5925] for that. Hence, the conclusion that ANCP MUST run over IPsec with IKEv2 for authentication and key management.
安全な輸送の場合、IPSECとIKEV2（以下の参照）の組み合わせまたはTLS [RFC5246]の使用のいずれかが、上記の要件を満たします。ただし、TLSの使用は拒否されています。決定点は、[RFC5713]が書かれたときに利用できなかったプロトコル設計の詳細です。ANCPの隣接は、サービス拒否攻撃の脆弱性の主要なポイントです。隣接を停止できる場合、ANは隣接の再確立が保留されている状態をクリアするか、ANとNASのANの国家の見解との間の不一致の可能性が開かれます。ANCPエージェントが同期しなくなったと結論付けるか、基礎となるTCPセッションを攻撃するために、隣接性を削除する2つの方法は、メッセージを変更することです。TLSはメッセージの内容を保護しますが、TCP接続は保護しません。そのためには、IPSECまたはTCP認証オプション[RFC5925]のいずれかを使用する必要があります。したがって、ANCPは、認証と主要な管理のためにIKEV2を使用してIPSECを介して実行しなければならないという結論です。
In greater detail: the ANCP stack MUST include IPsec [RFC4301] running in transport mode, since the AN and NAS are the endpoints of the path. The Encapsulating Security Payload (ESP) [RFC4303] MUST be used, in order to satisfy the requirement for data confidentiality. ESP MUST be configured for the combination of confidentiality, integrity, and anti-replay capability. The traffic flow confidentiality service of ESP is unnecessary and, in fact, unworkable in the case of ANCP.
さらに詳しく説明する：ANCPスタックには、ANとNASがパスのエンドポイントであるため、輸送モードで実行される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とAは異なる信頼ドメインにある可能性があるため、相互認証のために証明書を使用することが最も実用的なアプローチになる可能性があります。ただし、これは関係者次第です。
The AN MUST play the role of initiator of the IKEv2 conversation.
ANは、IKEV2会話のイニシエーターの役割を果たさなければなりません。
Swami Subramanian was an early member of the authors' team. The ANCP Working Group is grateful to Roberta Maglione, who served as design team member and primary editor of this document for two years before stepping down.
Swami Subramanianは、著者チームの初期のメンバーでした。ANCPワーキンググループは、辞任する前にこのドキュメントのデザインチームメンバーおよび主要な編集者を務めたロベルタマグリオーネに感謝しています。
The authors would like to thank everyone who provided comments or inputs to this document. The authors acknowledge the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic, and the further comments provided by Mykyta Yevstifeyev, Brian Carter, Ben Campbell, Alexey Melnikov, Adrian Farrel, Robert Sparks, Peter St. Andre, Sean Turner, Dan Romascanu, Brian Carter, and Michael Scott.
著者は、この文書にコメントや入力を提供してくれたすべての人に感謝したいと思います。著者は、Wojciech Dec、Peter Arberg、Josef Froehler、Derek Harkness、Kim Hyldgaard、Sandy Ng、Robert Peschi、Michel Platnicによって提供されたインプット、およびMykyta Yevstifeev、Brian Carter、Ben Campbell、Alexey Melnikovによって提供されたさらなるコメントを認めています。エイドリアン・ファレル、ロバート・スパークス、ピーター・セント・アンドレ、ショーン・ターナー、ダン・ロマスカヌ、ブライアン・カーター、マイケル・スコット。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
[RFC3292] Doria、A.、Hellstrand、F.、Sundell、K。、およびT. Worster、「General Switch Management Protocol（GSMP）V3」、RFC 3292、2002年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン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] Patrick、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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649] Volz、B。、「IPv6（DHCPV6）リレーエージェントリモートIDオプションの動的ホスト構成プロトコル」、RFC 4649、2006年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5713] Moustafa、H.、Tschofenig、H.、およびS. de Cnodder、「Access Node Control Protocol（ANCP）のセキュリティ脅威とセキュリティ要件」、RFC 5713、2010年1月。
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010.
[RFC5851] Ooghe、S.、Voigt、N.、Platnic、M.、Haag、T。、およびS. Wadhwa、「ブロードバンドマルチサービスネットワークのアクセスノード制御メカニズムのフレームワークと要件」、RFC 5851、5月2010年。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、RFC 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 Evolution- QOS対応IPサービスのサポートのためのアーキテクチャ要件」、2003年9月。
[TR-092] Broadband Forum, "TR-092, Broadband Remote access server requirements document", 2005.
[TR-092]ブロードバンドフォーラム、「TR-092、ブロードバンドリモートアクセスサーバー要件ドキュメント」、2005。
[TR-101] Broadband Forum, "TR-101, Architecture & Transport: Migration to Ethernet Based DSL Aggregation", 2005.
[TR-101]ブロードバンドフォーラム、「TR-101、アーキテクチャとトランスポート：イーサネットベースのDSL集約への移行」、2005年。
[TR-147] Broadband Forum, "TR-147, Layer 2 Control Mechanism For Broadband Multi-Service Architectures", 2008.
[TR-147]ブロードバンドフォーラム、「TR-147、レイヤー2ブロードバンドマルチサービスアーキテクチャの制御メカニズム」、2008年。
[US_ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X.34, 1986.
[US_ASCII] American National Standards Institute、「コード化された文字セット-7ビットの情報インターチェンジのためのアメリカ標準コード」、ANSI X.34、1986。
Authors' Addresses
著者のアドレス
Sanjay Wadhwa Alcatel-Lucent 701 E Middlefield Rd Mountain View, CA 94043-4079 USA
Sanjay Wadhwa Alcatel-Lucent 701 E Middlefield Rd Mountain View、CA 94043-4079 USA
EMail: sanjay.wadhwa@alcatel-lucent.com
Jerome Moisand Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA
Jerome Moisand Juniper Networks 10 Technology Park Drive Westford、MA 01886 USA
EMail: jmoisand@juniper.net
Thomas Haag Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany
Thomas Haag Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64295ドイツ
EMail: haagt@telekom.de
Norbert Voigt Nokia Siemens Networks Siemensallee 1 Greifswald 17489 Germany
Norbert Voigt Nokia Siemens Networks Siemensallee 1 Greifswald 17489ドイツ
EMail: norbert.voigt@nsn.com
Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave Ottawa Canada
トム・テイラー（編集者）Huawei Technologies 1852 Lorraine Ave Ottawa Canada
EMail: tom111.taylor@bell.net