[要約] RFC 5851は、広帯域マルチサービスネットワークにおけるアクセスノード制御メカニズムの枠組みと要件に関するものです。このRFCの目的は、ネットワークの効率性と信頼性を向上させるために、アクセスノードの制御方法を定義することです。
Internet Engineering Task Force (IETF) S. Ooghe
Request for Comments: 5851 Alcatel-Lucent
Category: Informational N. Voigt
ISSN: 2070-1721 Nokia Siemens Networks
M. Platnic
ECI Telecom
T. Haag
Deutsche Telekom
S. Wadhwa
Juniper Networks
May 2010
Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks
ブロードバンドマルチサービスネットワークのアクセスノード制御メカニズムのフレームワークと要件
Abstract
概要
The purpose of this document is to define a framework for an Access Node Control Mechanism 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 service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.
このドキュメントの目的は、ネットワークアクセスサーバー（NAS）とアクセスノード（例えば、デジタルサブスクライバーラインアクセスマルチプレクサ（DSLAM））の間のアクセスノード制御メカニズムのフレームワークをマルチサービスリファレンスアーキテクチャの順に定義することです。サービス、サービスの品質、および加入者に関連する運用を実行します。アクセスノード制御メカニズムにより、情報の送信が異なる要素マネージャーを通過する必要がなく、直接的なデバイスデバイス通信を使用することが保証されます。これにより、既存の運用サポートシステムへの影響を避けながら、これらのネットワーク要素内でアクセスリンク関連操作を実行できます。
This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements.
このドキュメントは、最初にアクセスノード制御メカニズムが適切である可能性のある多くのユースケースを識別します。次に、プロトコル設計中に考慮する必要があるアクセスノード制御プロトコル（ANCP）の要件を提示します。最後に、ANCPと説明されたユースケースをサポートする必要があるネットワーク要素の要件について説明します。これらの要件は、絶対要件としてではなく、ガイドラインと見なす必要があります。したがって、RFC 2119は節点の要件には適用されません。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc5851.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5851で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. General Architecture Aspects . . . . . . . . . . . . . . . . . 7
2.1. Concept of an Access Node Control Mechanism . . . . . . . 7
2.2. Reference Architecture . . . . . . . . . . . . . . . . . . 8
2.2.1. Home Gateway . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Access Loop . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Access Node . . . . . . . . . . . . . . . . . . . . . 9
2.2.4. Access Node Uplink . . . . . . . . . . . . . . . . . . 10
2.2.5. Aggregation Network . . . . . . . . . . . . . . . . . 10
2.2.6. Network Access Server . . . . . . . . . . . . . . . . 10
2.2.7. Regional Network . . . . . . . . . . . . . . . . . . . 10
2.3. Prioritizing Access Node Control Traffic . . . . . . . . . 11
2.4. Interaction with Management Systems . . . . . . . . . . . 12
2.5. Circuit Addressing Scheme . . . . . . . . . . . . . . . . 12
3. Use Cases for Access Node Control Mechanism . . . . . . . . . 13
3.1. Access Topology Discovery . . . . . . . . . . . . . . . . 13
3.2. Access-Loop Configuration . . . . . . . . . . . . . . . . 15
3.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 16
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1. Multicast Conditional Access . . . . . . . . . . . . . 18
3.4.2. Multicast Admission Control . . . . . . . . . . . . . 21
3.4.3. Multicast Accounting and Reporting . . . . . . . . . . 26
3.4.4. Spontaneous Admission Response . . . . . . . . . . . . 27
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. ANCP Functional Requirements . . . . . . . . . . . . . . . 28
4.2. ANCP Multicast Requirements . . . . . . . . . . . . . . . 29
4.3. Protocol Design Requirements . . . . . . . . . . . . . . . 30
4.4. Access Node Control Adjacency Requirements . . . . . . . . 31
4.5. ANCP Transport Requirements . . . . . . . . . . . . . . . 31
4.6. Access Node Requirements . . . . . . . . . . . . . . . . . 32
4.6.1. General Architecture . . . . . . . . . . . . . . . . . 32
4.6.2. Control Channel Attributes . . . . . . . . . . . . . . 33
4.6.3. Capability Negotiation Failure . . . . . . . . . . . . 33
4.6.4. Adjacency Status Reporting . . . . . . . . . . . . . . 33
4.6.5. Identification . . . . . . . . . . . . . . . . . . . . 34
4.6.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 34
4.6.7. Message Handling . . . . . . . . . . . . . . . . . . . 36
4.6.8. Parameter Control . . . . . . . . . . . . . . . . . . 37
4.7. Network Access Server Requirements . . . . . . . . . . . . 37
4.7.1. General Architecture . . . . . . . . . . . . . . . . . 37
4.7.2. Control Channel Attributes . . . . . . . . . . . . . . 39
4.7.3. Capability Negotiation Failure . . . . . . . . . . . . 39
4.7.4. Adjacency Status Reporting . . . . . . . . . . . . . . 40
4.7.5. Identification . . . . . . . . . . . . . . . . . . . . 40
4.7.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 40
4.7.7. Message Handling . . . . . . . . . . . . . . . . . . . 42
4.7.8. Wholesale Model . . . . . . . . . . . . . . . . . . . 42
5. Management-Related Requirements . . . . . . . . . . . . . . . 43
6. Security Considerations . . . . . . . . . . . . . . . . . . . 44
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Normative References . . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . . 45
Digital Subscriber Line (DSL) technology is widely deployed for Broadband Access for Next Generation Networks. Several documents like Broadband Forum TR-058 [TR-058], Broadband Forum TR-059 [TR-059], and Broadband Forum TR-101 [TR-101] describe possible architectures for these access networks. The scope of these specifications consists of the delivery of voice, video, and data services. The framework defined by this document is targeted at DSL-based access (either by means of ATM/DSL or as Ethernet/DSL). The framework shall be open to other access technologies, such as Passive Optical Networks using DSL technology at the Optical Network Unit (ONU), or wireless technologies like IEEE 802.16. Several use cases such as Access Topology Discovery, Remote Connectivity Test, and Multicast may be applied to these access technologies, but the details of this are outside the scope of this document.
デジタルサブスクライバーライン（DSL）テクノロジーは、次世代ネットワークのブロードバンドアクセスのために広く展開されています。ブロードバンドフォーラムTR-058 [TR-058]、ブロードバンドフォーラムTR-059 [TR-059]、ブロードバンドフォーラムTR-101 [TR-101]などのいくつかのドキュメントは、これらのアクセスネットワークの可能なアーキテクチャを説明しています。これらの仕様の範囲は、音声、ビデオ、およびデータサービスの配信で構成されています。このドキュメントで定義されたフレームワークは、DSLベースのアクセスを対象としています（ATM/DSLまたはイーサネット/DSLとして）。このフレームワークは、光ネットワークユニット（ONU）のDSLテクノロジーを使用したパッシブ光学ネットワーク、またはIEEE 802.16のようなワイヤレステクノロジーなど、他のアクセステクノロジーに開かれているものとします。アクセストポロジの発見、リモート接続テスト、マルチキャストなどのいくつかのユースケースがこれらのアクセステクノロジーに適用される場合がありますが、この詳細はこのドキュメントの範囲外です。
Traditional architectures require Permanent Virtual Circuit(s) per subscriber. Such a virtual circuit is configured on layer 2 and terminated at the first layer 3 device (e.g., Broadband Remote Access Server (BRAS)). Beside the data plane, the models define the architectures for element, network, and service management. Interworking at the management plane is not always possible because of the organizational boundaries between departments operating the local loop, departments operating the ATM network, and departments operating the IP network. Besides, management networks are usually not designed to transmit management data between the different entities in real time.
従来のアーキテクチャには、サブスクライバーあたりの永続的な仮想回路が必要です。このような仮想回路は、レイヤー2で構成され、最初のレイヤー3デバイス（ブロードバンドリモートアクセスサーバー（BRA）など）で終了します。データプレーンの横にあるモデルは、要素、ネットワーク、およびサービス管理のアーキテクチャを定義します。ローカルループを運営する部門、ATMネットワークを運営する部門、およびIPネットワークを運営する部門間の組織の境界があるため、管理機でのインターワーキングは常に可能ではありません。また、管理ネットワークは通常、異なるエンティティ間でリアルタイムで管理データを送信するように設計されていません。
When deploying value-added services across DSL access networks, special attention regarding quality of service and service control is required, which implies a tighter coordination between Network Nodes (e.g., Access Nodes and Network Access Server (NAS)), without burdening the Operational Support System (OSS) with unpractical expectations.
DSLアクセスネットワーク全体に付加価値サービスを展開する場合、サービスの品質とサービス制御に関する特別な注意が必要です。これは、ネットワークノード（例：アクセスノードとネットワークアクセスサーバー（NAS）など）間のより緊密な調整を意味します。非実用的な期待を伴うシステム（OSS）。
Therefore, there is a need for an Access Node Control Mechanism between a 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 service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing OSSes.
したがって、サービス、品質に関連する操作を実行するために、NASとアクセスノード（例：デジタルサブスクライバーラインアクセスマルチプレクサ（DSLAM））の間のアクセスノード制御メカニズム（例：デジタルサブスクライバーラインアクセスマルチプレクサ（DSLAM））が必要です。サービス、および購読者。アクセスノード制御メカニズムにより、情報の送信は、個別の要素マネージャーを通過する必要がなく、直接的なデバイスデバイス通信を使用する必要があります。これにより、既存のオスへの影響を避けながら、これらのネットワーク要素内でアクセスリンク関連操作を実行できます。
This document provides a framework for such an Access Node Control Mechanism and identifies a number of use cases for which this mechanism can be justified. Next, it presents a number of requirements for the Access Node Control Protocol (ANCP) and the network elements that need to support it.
このドキュメントは、このようなアクセスノード制御メカニズムのフレームワークを提供し、このメカニズムを正当化できる多くのユースケースを識別します。次に、アクセスノード制御プロトコル（ANCP）とサポートする必要があるネットワーク要素の多くの要件を提示します。
The requirements spelled out in this document are based on the work that is performed by the Broadband Forum [TR-147].
このドキュメントで説明されている要件は、ブロードバンドフォーラム[TR-147]によって実行される作業に基づいています。
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]に記載されているように解釈される。
o Access Node (AN): network device, usually located at a service provider central office or street cabinet, that terminates access-loop connections from subscribers. In case the access loop is a Digital Subscriber Line (DSL), this is often referred to as a DSL Access Multiplexer (DSLAM).
o アクセスノード（AN）：通常はサービスプロバイダー中央オフィスまたはストリートキャビネットにあるネットワークデバイスは、加入者からのアクセスループ接続を終了します。アクセスループがデジタルサブスクライバーライン（DSL）である場合、これはしばしばDSLアクセスマルチプレクサ（DSLAM）と呼ばれます。
o Network Access Server (NAS): network device that aggregates multiplexed subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and quality of service (QoS). Often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in [RFC2881].
o Network Access Server（NAS）：多数のアクセスノードから多重化されたサブスクライバートラフィックを集約するネットワークデバイス。NASは、潜水艦ごとの政策執行とサービス品質（QOS）において中心的な役割を果たしています。多くの場合、ブロードバンドネットワークゲートウェイ（BNG）またはブロードバンドリモートアクセスサーバー（BRA）と呼ばれます。NASの詳細な定義は[RFC2881]に記載されています。
o "Net Data Rate": 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.
o 「ネットデータレート」：ITU-T G.993.2 [G.993.2]、セクション3.39、つまりユーザー情報の送信に使用できる総データレートの部分（ATMセルまたはイーサネットフレームなど）で定義されています。物理伝達メカニズム（DSLの場合のTrellisコーディングなど）に関係するオーバーヘッドは除外されます。これには、TPS -TC（輸送プロトコル固有の - 伝送収束）カプセル化が含まれます。これは、ATMカプセル化の場合はゼロ、64/65カプセルの場合はゼロではありません。
o "Line Rate": defined by ITU-T G.993.2. It contains the complete overhead including Reed-Solomon and Trellis coding.
o 「ラインレート」：ITU-T G.993.2で定義されています。リードソロモンやトレリスコーディングを含む完全なオーバーヘッドが含まれています。
o Access Node Control Mechanism: a method for multiple network scenarios with an extensible communication scheme that conveys status and control information between one or more ANs and one or more NASes without using intermediate element managers.
o アクセスノード制御メカニズム：中間要素マネージャーを使用せずに1つ以上のANSと1つ以上のnase間のステータスと制御情報を伝える拡張可能な通信スキームを備えた複数のネットワークシナリオの方法。
o Control Channel: a bidirectional IP communication interface between the controller function (in the NAS) and the reporting/ enforcement function (in the AN). It is assumed that this interface is configured (rather than discovered) on the AN and the NAS.
o コントロールチャネル：コントローラー関数（NAS）とレポート/執行関数（AN）の間の双方向IP通信インターフェイス。このインターフェイスは、ANおよびNASで（発見されたのではなく）構成されていると想定されています。
o Access Node Control Adjacency: the relationship between an Access Node and a NAS for the purpose of exchanging Access Node Control Protocol messages. The adjacency may either be up or down, depending on the result of the Access Node Control Adjacency protocol operation.
o アクセスノード制御隣接：アクセスノード制御プロトコルメッセージを交換する目的で、アクセスノードとNASの関係。Accessノード制御隣接プロトコル操作の結果に応じて、隣接性は上下にある場合があります。
o Multicast Flow: designates datagrams sent to a group from a set of sources for which multicast reception is desired. A distinction can be made between Any Source Multicast (ASM) and Source-Specific Multicast (SSM).
o マルチキャストフロー：マルチキャストレセプションが望まれるソースのセットからグループに送信されたデータグラムを指定します。任意のソースマルチキャスト（ASM）とソース固有のマルチキャスト（SSM）を区別できます。
o Join: signaling from the user equipment that it wishes to start receiving a new multicast flow. In ASM, it is referred to as a "Join". In SSM [RFC4607], it is referred to as a "subscribe". In IGMPv2, "joins" are indicated through an "IGMPv2 membership report". In IGMPv3 [RFC3376], "join" is indicated through "membership report" using different Filter-Mode-Change (ASM) and Source-List-Change Records.
o 結合：ユーザー機器からの信号は、新しいマルチキャストフローの受信を開始したいということです。ASMでは、「結合」と呼ばれます。SSM [RFC4607]では、「サブスクライブ」と呼ばれます。IGMPV2では、「IGMPV2メンバーシップレポート」を通じて「結合」が示されています。IGMPV3 [RFC3376]では、「Join」は、異なるフィルターモード変更（ASM）とソースリスト変更レコードを使用して「メンバーシップレポート」を通じて示されています。
o Leave: signaling from the user equipment that it wishes to stop receiving a multicast flow. With IGMPv2, this is conveyed inside the "Leave Group" message, while in IGMPv3, "leave" is indicated through the "IGMPv3 membership report" message using different Filter-Mode-Change (ASM) and Source-List-Change Records.
o 休暇：マルチキャストフローの受信を停止したいというユーザー機器からの信号。IGMPV2を使用すると、これは「leaveグループ」メッセージ内で伝えられますが、Igmpv3では、「Igmpv3メンバーシップレポート」メッセージを介して「leave」は、異なるフィルターモード変更（ASM）とソースリストチェンジレコードを使用して表示されます。
This section introduces the basic concept of the Access Node Control Mechanism and describes the reference architecture where it is being applied. Based on the reference architecture, the section then describes how Access Node Control messages are to be prioritized over other data traffic, and the interaction between ANCP and the network management system. Finally, the addressing schemes are described that allow identifying an Access Port in Access Node Control messages.
このセクションでは、アクセスノード制御メカニズムの基本概念を紹介し、適用されている参照アーキテクチャについて説明します。参照アーキテクチャに基づいて、このセクションでは、アクセスノード制御メッセージが他のデータトラフィックよりも優先される方法、およびANCPとネットワーク管理システム間の相互作用について説明します。最後に、アクセスノード制御メッセージのアクセスポートを識別できるアドレス指定スキームが説明されています。
The high-level communication framework for an Access Node Control Mechanism is defined in Figure 1. The Access Node Control Mechanism defines a quasi-real-time, general-purpose method for multiple network scenarios with an extensible communication scheme, addressing the different use cases that are described throughout this document.
アクセスノード制御メカニズムの高レベルの通信フレームワークは、図1に定義されています。アクセスノード制御メカニズムは、異なるユースケースに対処する拡張可能な通信スキームを備えた複数のネットワークシナリオの準リアルタイム、汎用法を定義します。このドキュメント全体で説明されています。
+--------+
| Policy |
| Server |
+--------+
|
|
+-----+ +-----+ +--------+ +-----+ +----------+
| CPE |--| HGW |--| | | | | |
+-----+ +-----+ | Access | +-------------+ | | | Regional |
| Node |---| Aggregation |---| NAS |--| Network |
+-----+ +-----+ | | | Network | | | | |
| CPE |--| HGW |--| | +-------------+ | | | |
+-----+ +-----+ +--------+ +-----+ +----------+
Information Report / Admission Request
------------------------------>
Admission Response / Control Request
<------------------------------
Control Response
------------------------------>
Access Node Control Mechanism
<----------------------------->
PPP, DHCP, IP
<---------><----------------------------------------->
CPE: Customer Premises Equipment HGW: Home Gateway
CPE：顧客施設機器HGW：ホームゲートウェイ
Figure 1: Access Network Architecture
図1：アクセスネットワークアーキテクチャ
A number of functions can be identified:
多くの機能を特定できます。
o A controller function: this function is used either to send out requests for information to be used by the network element where the controller function resides, or to trigger a certain behavior in the network element where the reporting and/or enforcement function resides.
o コントローラー関数：この関数は、コントローラー関数が存在するネットワーク要素によって使用される情報のリクエストを送信するか、レポートおよび/または施行機能が存在するネットワーク要素の特定の動作をトリガーするために使用されます。
o A reporting function: this function is used to convey status information to the controller function. An example of this is the transmission of the access-loop data rate from an Access Node to a Network Access Server (NAS) tasked with shaping traffic to that rate.
o レポート関数：この関数は、ステータス情報をコントローラー関数に伝えるために使用されます。この例は、アクセスノードからネットワークアクセスサーバー（NAS）へのアクセスループデータレートの送信で、トラフィックをそのレートに格付けすることを担当しています。
o An enforcement function: this function is contacted by the controller function to trigger a remote action on the Access Node. An example is the initiation of a port-testing mechanism on an Access Node. Another example is enforcing whether a multicast join is to be honored or denied.
o 施行機能：この関数は、コントローラー関数によって連絡され、アクセスノードのリモートアクションをトリガーします。例は、アクセスノードでのポートテストメカニズムの開始です。別の例は、マルチキャストの結合が尊重されるか拒否されるかを強制することです。
The messages shown in Figure 1 show the conceptual message flow. The actual use of these flows, and the times or frequencies when these messages are generated depends on the actual use cases, which are described in Section 3.
図1に示すメッセージは、概念的なメッセージフローを示しています。これらのフローの実際の使用、およびこれらのメッセージが生成されたときの時間または周波数は、セクション3で説明されている実際のユースケースによって異なります。
The use cases in this document are described in an abstract way, independent from any actual protocol mapping. The actual protocol specification is out of scope of this document, but there are certain characteristics of the protocol that are required to simplify specification, implementation, debugging and troubleshooting, and to extend support for additional use cases.
このドキュメントのユースケースは、実際のプロトコルマッピングとは独立した抽象的な方法で説明されています。実際のプロトコル仕様はこのドキュメントの範囲外ですが、仕様、実装、デバッグ、トラブルシューティングを簡素化し、追加のユースケースのサポートを拡張するために必要なプロトコルの特定の特性があります。
The reference architecture used in this document can be based on ATM or Ethernet access/aggregation. Specifically:
このドキュメントで使用される参照アーキテクチャは、ATMまたはイーサネットアクセス/集約に基づいています。具体的には：
o In case of a legacy ATM aggregation network that is to be used for the introduction of new QoS-enabled IP services, the architecture builds on the reference architecture specified in the Broadband Forum [TR-059];
o 新しいQoS対応IPサービスの導入に使用されるレガシーATM集約ネットワークの場合、アーキテクチャはブロードバンドフォーラム[TR-059]で指定された参照アーキテクチャに基づいて構築されます。
o In case of an Ethernet aggregation network that supports new QoS-enabled IP services (including Ethernet multicast replication), the architecture builds on the reference architecture specified in the Broadband Forum [TR-101].
o 新しいQoS対応IPサービス（イーサネットマルチキャストレプリケーションを含む）をサポートするイーサネット集約ネットワークの場合、アーキテクチャはブロードバンドフォーラム[TR-101]で指定された参照アーキテクチャに基づいて構築されます。
Given the industry's move towards Ethernet as the new access and aggregation technology for triple-play services, the primary focus throughout this document is on a TR-101 architecture. However the concepts are equally applicable to an ATM architecture based on TR-059.
トリプルプレイサービスの新しいアクセスおよび集約技術としてのイーサネットへの業界の動きを考えると、このドキュメント全体の主な焦点はTR-101アーキテクチャにあります。ただし、概念は、TR-059に基づくATMアーキテクチャに等しく適用できます。
The Home Gateway (HGW) connects the different Customer Premises Equipment (CPE) to the Access Node and the access network. In case of DSL, the HGW is a DSL Network Termination (NT) that could either operate 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）は、さまざまな顧客施設機器（CPE）をアクセスノードとアクセスネットワークに接続します。DSLの場合、HGWはDSLネットワーク終了（NT）であり、レイヤー2ブリッジとして動作するか、レイヤー3ルーターとして動作します。後者の場合、そのようなデバイスはルーティングゲートウェイ（RG）とも呼ばれます。
The access loop ensures physical connectivity between the HGW at the customer premises and the Access Node. In case of DSL, the access-loop physical layer could be, e.g., ADSL, ADSL2+, VDSL, VDSL2, or SHDSL. In order to increase bandwidth, it is also possible that multiple DSL links are grouped together to form a single virtual link; this process is called "DSL bonding". The protocol encapsulation on the access loop could be based on multi-protocol encapsulation over ATM Adaption Layer 5 (AAL5) defined in [RFC2684]. This covers PPP over Ethernet (PPPoE, defined in [RFC2516]), bridged IP (IP over Ethernet (IPoE), defined in [RFC894]) and routed IP (IP over ATM (IPoA), defined in [RFC2225]). Next to this, PPP over AAL5 (PPPoA) as defined in [RFC2364] can be used. Future scenarios include cases where the access loop supports direct Ethernet encapsulation (e.g., when using VDSL or VDSL2).
アクセスループにより、顧客施設のHGWとアクセスノードの間の物理的な接続が保証されます。DSLの場合、アクセスループの物理層は、ADSL、ADSL2、VDSL、VDSL2、またはSHDSLなどです。帯域幅を増やすために、複数のDSLリンクをグループ化して単一の仮想リンクを形成する可能性もあります。このプロセスは「DSLボンディング」と呼ばれます。アクセスループのプロトコルカプセル化は、[RFC2684]で定義されているATM適応層5（AAL5）を介したマルチプロトコルカプセル化に基づいている可能性があります。これは、イーサネット上のPPP（[RFC2516]で定義されているPPPOE）、ブリッジIP（イーサネット上のIP（IPOE）、[RFC894]で定義）、および[RFC2225]で定義されたIP（IPOA）上のIP（IP（IPOA））（IP（IPOA））をカバーします。これに加えて、[RFC2364]で定義されているAAL5（PPPOA）上のPPPを使用できます。将来のシナリオには、アクセスループが直接イーサネットのカプセル化をサポートする場合（たとえば、VDSLまたはVDSL2を使用する場合）。
The Access Node (AN) may support one or more access-loop technologies and allow them to interwork with a common aggregation network technology. Besides the access-loop termination, the AN can also aggregate traffic from other Access Nodes using ATM or Ethernet.
Accessノード（AN）は、1つ以上のアクセスループテクノロジーをサポートし、共通の集約ネットワークテクノロジーと対話できるようにすることができます。アクセスループ終了に加えて、ANはATMまたはイーサネットを使用して他のアクセスノードからトラフィックを集約することもできます。
The framework defined by this document is targeted at DSL-based access (either by means of ATM/DSL or as Ethernet/DSL). The framework shall be open to non-DSL technologies, like Passive Optical Networks (PONs) and IEEE 802.16 (WiMAX), but the details of this are outside the scope of this document.
このドキュメントで定義されたフレームワークは、DSLベースのアクセスを対象としています（ATM/DSLまたはイーサネット/DSLとして）。フレームワークは、パッシブ光学ネットワーク（ポン）やIEEE 802.16（WIMAX）などの非DSLテクノロジーに対して開かれている必要がありますが、この詳細はこのドキュメントの範囲外です。
The reporting and/or enforcement function defined in Section 2.1 typically resides in an Access Node.
セクション2.1で定義されているレポートおよび/または執行機能は、通常、アクセスノードに存在します。
The fundamental requirements for the Access Node uplink are to provide traffic aggregation, Class of Service (CoS) distinction, and customer separation and traceability. This can be achieved using an ATM- or Ethernet-based technology.
アクセスノードアップリンクの基本的な要件は、トラフィックの集約、サービスのクラス（COS）の区別、顧客の分離とトレーサビリティを提供することです。これは、ATMまたはイーサネットベースのテクノロジーを使用して実現できます。
The aggregation network provides traffic aggregation towards the NAS. The aggregation technology can be based on ATM (in case of a TR-059 architecture) or Ethernet (in case of a TR-101 architecture).
集約ネットワークは、NASへのトラフィック集約を提供します。集約技術は、ATM（TR-059アーキテクチャの場合）またはイーサネット（TR-101アーキテクチャの場合）に基づいています。
The Network Access Server (NAS) interfaces to the aggregation network by means of standard ATM or Ethernet interfaces, and towards the Regional Network by means of transport interfaces for Ethernet frames (e.g., Gigabit Ethernet (GigE), Ethernet over Synchronous Optical Network (SONET)). The NAS functionality corresponds to the BNG functionality described in Broadband Forum TR-101. In addition to this, the NAS supports the Access Node Control functionality defined for the respective use cases throughout this document.
ネットワークアクセスサーバー（NAS）は、標準ATMまたはイーサネットインターフェイスを使用した集約ネットワークへのインターフェイス、およびイーサネットフレームの輸送インターフェイス（例：ギガビットイーサネット（GIGE）、同期光ネットワーク上のイーサネット（SONET）のイーサネットによる地域ネットワークへのインターフェイス）））。NAS機能は、ブロードバンドフォーラムTR-101で説明されているBNG機能に対応しています。これに加えて、NASは、このドキュメント全体でそれぞれのユースケースに対して定義されたアクセスノード制御機能をサポートしています。
The controller function defined in Section 2.1 typically resides in a NAS.
セクション2.1で定義されているコントローラー関数は、通常、NASに存在します。
The Regional Network connects one or more NAS and associated Access Networks to Network Service Providers (NSPs) and Application Service Providers (ASPs). The NSP authenticates access and provides and manages the IP address to subscribers. It is responsible for overall service assurance and includes Internet Service Providers (ISPs). The ASP provides application services to the application subscriber (gaming, video, content on demand, IP telephony, etc.).
リージョナルネットワークは、1つ以上のNASと関連するアクセスネットワークをネットワークサービスプロバイダー（NSP）およびアプリケーションサービスプロバイダー（ASP）に接続します。NSPはアクセスを認証し、サブスクライバーにIPアドレスを提供および管理します。全体的なサービス保証を担当し、インターネットサービスプロバイダー（ISP）が含まれます。ASPは、アプリケーションサブスクライバー（ゲーム、ビデオ、オンデマンド、IPテレフォニーなど）にアプリケーションサービスを提供します。
The Regional Network supports aggregation of traffic from multiple Access Networks and hands off larger geographic locations to NSPs and ASPs -- relieving a potential requirement for them to build infrastructure to attach more directly to the various Access Networks.
リージョナルネットワークは、複数のアクセスネットワークからトラフィックの集約をサポートし、より大きな地理的位置をNSPおよびASPに引き渡します。
When sending Access Node Control messages across the aggregation network, care is needed that messages won't get lost. The connectivity between the Access Node and the NAS may differ depending on the actual layer 2 technology used (ATM or Ethernet). This section briefly outlines how network connectivity can be established.
集約ネットワーク全体にアクセスノード制御メッセージを送信するとき、メッセージが失われないように注意する必要があります。アクセスノードとNAS間の接続性は、使用される実際のレイヤー2テクノロジー（ATMまたはイーサネット）によって異なる場合があります。このセクションでは、ネットワークの接続をどのように確立できるかを簡単に概説します。
In case of an ATM access/aggregation network, a typical practice is to send the Access Node Control Protocol messages over a dedicated Permanent Virtual Circuit (PVC) configured between the AN and the NAS. These ATM PVCs would then be given a high priority so that at times of network congestion, loss of the ATM cells carrying the Access Node Control Protocol is avoided or minimized. It is discouraged to route the Access Node Control Protocol messages within the Virtual Path (VP) that also carries the customer connections, if that VP is configured with a best-effort QoS class (e.g., Unspecified Bitrate (UBR)). The PVCs of multiple Access Node Control Adjacencies can be aggregated into a VP that is given a high priority and runs across the aggregation network. This requires the presence of a VC cross-connect in the aggregation node that terminates the VP.
ATMアクセス/集約ネットワークの場合、典型的なプラクティスは、ANとNASの間で構成された専用の永続的仮想回路（PVC）を介してアクセスノード制御プロトコルメッセージを送信することです。これらのATM PVCには優先度が高くなるため、ネットワークの混雑の時に、アクセスノード制御プロトコルを運ぶATMセルの喪失が回避または最小化されます。VPがBest-Eftort QOSクラス（例：不特定のビットレート（UBR））で構成されている場合、顧客接続も搭載する仮想パス（VP）内のアクセスノード制御プロトコルメッセージをルーティングすることは落胆します。複数のアクセスノード制御隣接のPVCは、優先度が高く、集約ネットワーク全体で実行されるVPに集約できます。これには、VPを終了する集約ノードにVCクロスコネクトが存在する必要があります。
In 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). This can be achieved using a different VLAN ID for each Access Node, or, in networks with many Access Nodes and a high degree of aggregation, one Customer VLAN (C-VLAN) per Access Node and one Service VLAN (S-VLAN) for the Access Node Control Adjacencies of all Access Nodes. The traffic should be given a high priority (e.g., by using a high CoS value) so that the frame loss of Ethernet frames carrying the Access Node Control Protocol messages is minimized in the event of network congestion.
イーサネットアクセス/集約ネットワークの場合、典型的なプラクティスは、別のVLAN識別子（VLAN ID）を使用して、専用のイーサネット仮想LAN（VLAN）を介してアクセスノード制御プロトコルメッセージを送信することです。これは、アクセスノードごとに異なるVLAN IDを使用して達成できます。または、多くのアクセスノードと高度な集約を備えたネットワークでは、アクセスノードごとに1つの顧客VLAN（C-VLAN）と1つのサービスVLAN（S-VLAN）すべてのアクセスノードのアクセスノード制御隣接。ネットワークの輻輳が発生した場合にアクセスノード制御プロトコルメッセージを運ぶイーサネットフレームのフレーム損失が最小化されるように、トラフィックには高い優先度（たとえば、高いCOS値を使用して）を与えられる必要があります。
In both cases, the Control Channel between NAS and Access Node could use the same physical network and routing resources as the subscriber traffic. This means that the connection is an inband connection between the involved network elements. Therefore, there is no need for an additional physical interface to establish the Control Channel.
どちらの場合も、NASとアクセスノードの間の制御チャネルは、サブスクライバートラフィックと同じ物理ネットワークとルーティングリソースを使用できます。これは、接続が関係するネットワーク要素間のインバンド接続であることを意味します。したがって、制御チャネルを確立するための追加の物理インターフェイスは必要ありません。
Note that these methods for transporting Access Node Control Protocol messages are typical examples; they do not rule out other methods that achieve the same behavior.
アクセスノード制御プロトコルメッセージを輸送するこれらの方法は、典型的な例であることに注意してください。彼らは同じ動作を達成する他の方法を除外しません。
The Access Node Control Adjacency interactions must be reliable. In addition to this, some of the use cases described in Section 3 require the interactions to be performed in a transactional fashion, i.e., using a "request/response" mechanism. This is required so that the network elements always remain in a known state, irrespective of whether or not the transaction is successful.
アクセスノード制御の隣接対話は信頼できる必要があります。これに加えて、セクション3で説明されているユースケースの一部は、トランザクションの方法で、つまり「要求/応答」メカニズムを使用して相互作用を実行する必要があります。これは、トランザクションが成功したかどうかに関係なく、ネットワーク要素が常に既知の状態にとどまるように必要です。
When introducing an Access Node Control Mechanism, care is needed to ensure that the existing management mechanisms remain operational as before.
アクセスノード制御メカニズムを導入するときは、既存の管理メカニズムが以前と同じように動作し続けるように注意する必要があります。
Specifically, when using the Access Node Control Mechanism for performing a configuration action on a network element, one gets confronted with the challenge of supporting multiple managers for the same network element: both the Element Manager as well as the Access Node Control Mechanism may now perform configuration actions on the same network element. Therefore, conflicts need to be avoided.
具体的には、ネットワーク要素で構成アクションを実行するためにアクセスノード制御メカニズムを使用する場合、同じネットワーク要素の複数のマネージャーをサポートするという課題に直面します。要素マネージャーとアクセスノード制御メカニズムの両方が実行できるようになりました。同じネットワーク要素での構成アクション。したがって、競合を避ける必要があります。
Using the Access Node Control Mechanism, the NAS retrieves and controls a number of subscriber-related parameters. The NAS may decide to communicate this information to a central Policy or AAA Server so that it can keep track of the parameters and apply policies on them. The Server can then enforce those policies on the NAS. For instance, in case a subscriber is connected to more than one NAS, the policy server could be used to coordinate the bandwidth available on a given Access Port for use amongst the different NAS devices.
Accessノード制御メカニズムを使用して、NASは多くのサブスクライバー関連パラメーターを取得および制御します。NASは、この情報を中央ポリシーまたはAAAサーバーに伝えることを決定し、パラメーターを追跡し、それらにポリシーを適用できるようにすることができます。サーバーは、NASに関するこれらのポリシーを実施できます。たとえば、サブスクライバーが複数のNASに接続されている場合、ポリシーサーバーを使用して、さまざまなNASデバイスで使用するために特定のアクセスポートで利用可能な帯域幅を調整できます。
Guidelines related to management will be addressed in Section 5.
管理に関連するガイドラインは、セクション5で説明されます。
In order to associate subscriber parameters to a particular Access Port, the NAS needs to be able to uniquely identify the Access Port (or a specific circuit on an Access Port) using an addressing scheme.
サブスクライバーパラメーターを特定のアクセスポートに関連付けるために、NASはアドレス指定スキームを使用してアクセスポート（またはアクセスポートの特定の回路）を一意に識別できる必要があります。
In deployments using an ATM aggregation network, the ATM PVC on an access loop connects the subscriber to a NAS. Based on this property, the NAS typically includes a NAS-Port-Id, NAS-Port, or Calling-Station-Id attribute in RADIUS authentication and accounting packets sent to the RADIUS server(s). Such attribute includes the identification of the ATM VC for this subscriber, which allows in turn identifying the access loop.
ATM集約ネットワークを使用した展開では、アクセスループ上のATM PVCがサブスクライバーをNASに接続します。このプロパティに基づいて、NASには通常、RADIUS認証とRADIUSサーバーに送信されたRADIUS認証と会計パケットにNAS-Port-ID、NASポート、または呼び出しステーション-ID属性が含まれます。このような属性には、このサブスクライバーのATM VCの識別が含まれます。これにより、アクセスループを識別できます。
In an Ethernet-based aggregation network, a new addressing scheme is defined in [TR-101]. Two mechanisms can be used: o A first approach is to use a one-to-one VLAN assignment model for all Access Ports (e.g., a DSL port) and circuits on an Access Port (e.g., an ATM PVC on an ADSL port). This enables directly deriving the port and circuit identification from the VLAN tagging information, i.e., S-VLAN ID or <S-VLAN ID, C-VLAN ID> pair.
イーサネットベースの集約ネットワークでは、[TR-101]で新しいアドレス指定スキームが定義されています。2つのメカニズムを使用できます。o最初のアプローチは、すべてのアクセスポート（DSLポートなど）に1対1のVLAN割り当てモデルを使用し、アクセスポートの回路（ADSLポートのATM PVCなど）を使用することです。。これにより、VLANタグ付け情報、つまりS-VLAN IDまたは<S-VLAN ID、C-VLAN ID>ペアからポートと回路の識別を直接導出することができます。
o A second approach is to use a many-to-one VLAN assignment model and to encode the Access Port and circuit identification in the "Agent Circuit ID" sub-option to be added to a DHCP or PPPoE message. The details of this approach are specified in [TR-101].
o 2番目のアプローチは、DHCPまたはPPPOEメッセージに追加される「エージェント回路ID」サブオプションのアクセスポートと回路の識別をエンコードすることです。このアプローチの詳細は[TR-101]で指定されています。
This document reuses the addressing scheme specified in TR-101. It should be noted however that the use of such a scheme does not imply the actual existence of a PPPoE or DHCP session, nor the presence of the specific interworking function in the Access Node. In some cases, no PPPoE or DHCP session may be present, while port and circuit addressing would still be desirable.
このドキュメントは、TR-101で指定されたアドレス指定スキームを再利用します。ただし、このようなスキームの使用は、PPPOEまたはDHCPセッションの実際の存在やアクセスノード内の特定のインターワーキング関数の存在を意味するものではないことに注意する必要があります。場合によっては、PPPOEまたはDHCPセッションは存在しない場合がありますが、ポートと回路のアドレス指定は依然として望ましいでしょう。
[TR-059] and [TR-101] discuss various queuing/scheduling mechanisms to avoid congestion in the access network while dealing with multiple flows with distinct QoS requirements. One technique that can be used on a NAS is known as "Hierarchical Scheduling" (HS). This option is applicable in a single NAS scenario (in which case the NAS manages all the bandwidth available on the access loop) or in a dual NAS scenario (in which case the NAS manages some fraction of the access loop's bandwidth). The HS must, at a minimum, support 3 levels modeling the NAS port, Access Node uplink, and access-loop sync rate. The rationale for the support of HS is as follows:
[TR-059]および[TR-101]は、異なるQoS要件を備えた複数のフローを扱いながら、アクセスネットワークの輻輳を回避するために、さまざまなキューイング/スケジューリングメカニズムについて議論します。NASで使用できる1つの手法は、「階層スケジューリング」（HS）として知られています。このオプションは、単一のNASシナリオ（この場合、NASはアクセスループで利用可能なすべての帯域幅を管理する）またはデュアルNASシナリオ（この場合、NASはアクセスループの帯域幅の一部を管理します）で適用されます。HSは、少なくとも、NASポートをモデル化する3レベル、アクセスノードアップリンク、アクセスループの同期レートをサポートする必要があります。HSのサポートの理論的根拠は次のとおりです。
o Provide fairness of network resources within a class.
o クラス内でネットワークリソースの公平性を提供します。
o Allow for a better utilization of network resources. Drop traffic early at the NAS rather than letting it traverse the aggregation network just to be dropped at the Access Node.
o ネットワークリソースのより良い利用を可能にします。Accessノードでドロップするためだけに、集約ネットワークを通過させるのではなく、NASのトラフィックを早期にドロップします。
o Enable more flexible CoS behaviors than only strict priority.
o 厳格な優先度よりも柔軟なCOS動作を可能にします。
o The HS system could be augmented to provide per-application admission control.
o HSシステムを増強して、アプリケーションごとの入場制御を提供することができます。
o Allow fully dynamic bandwidth partitioning between the various applications (as opposed to static bandwidth partitioning).
o さまざまなアプリケーション間の完全に動的な帯域幅パーティションを許可します（静的帯域幅パーティションとは対照的に）。
o Support "per-user weighted scheduling" to allow differentiated Service Level Agreements (e.g., business services) within a given traffic class.
o 「ユーザーごとの加重スケジューリング」をサポートして、特定のトラフィッククラス内で差別化されたサービスレベル契約（ビジネスサービスなど）を許可します。
Such mechanisms require that the NAS gains knowledge about the topology of the access network, the various links being used, and their respective rates. Some of the information required is somewhat dynamic in nature (e.g., DSL line rate -- thus also the net data rate); hence, it cannot come from a provisioning and/or inventory management OSS system. Some of the information varies less frequently (e.g., capacity of a DSLAM uplink), but nevertheless needs to be kept strictly in sync between the actual capacity of the uplink and the image the BRAS has of it.
このようなメカニズムは、NASがアクセスネットワークのトポロジー、使用されているさまざまなリンク、およびそれぞれのレートに関する知識を得ることを要求しています。必要な情報の一部は、本質的にやや動的です（たとえば、DSLラインレート - したがって、ネットデータレートも）。したがって、プロビジョニングおよび/または在庫管理OSSシステムから来ることはできません。情報の一部は頻繁に変化しません（例：DSLAMアップリンクの容量）が、それでもアップリンクの実際の容量とブラジャーが持っている画像の間で厳密に同期する必要があります。
OSS systems are typically not designed to enforce the consistency of such data in a reliable and scalable manner across organizational boundaries. The Access Topology Discovery function is intended to allow the NAS to perform these functions without having to rely on an integration with an OSS system.
通常、OSSシステムは、組織の境界を越えて信頼できるスケーラブルな方法でそのようなデータの一貫性を強制するように設計されていません。Access Topology Discovery関数は、OSSシステムとの統合に依存することなく、NASがこれらの機能を実行できるようにすることを目的としています。
Communicating access-loop attributes is specifically important in case the rate of the access loop changes overtime. The DSL actual data rate may be different every time the DSL NT is turned on. In this case, the Access Node sends an Information Report message to the NAS after the DSL line has resynchronized.
アクセスループ属性の通信は、アクセスループのレートが時間外に変化する場合に特に重要です。DSLの実際のデータレートは、DSL NTがオンになるたびに異なる場合があります。この場合、アクセスノードは、DSLラインが再同期した後、NASに情報レポートメッセージを送信します。
Additionally, during the time the DSL NT is active, data rate changes can occur due to environmental conditions (the DSL access loop can get "out of sync" and can retrain to a lower value, or the DSL access loop could use Seamless Rate Adaptation making the actual data rate fluctuate while the line is active). In this case, the Access Node sends an additional Information Report to the NAS each time the access-loop attributes change above a threshold value.
さらに、DSL NTがアクティブになっている間、環境条件によりデータレートの変更が発生する可能性があります（DSLアクセスループは「同期しない」ことができ、値を低くするか、DSLアクセスループがシームレスレートの適応を使用できますラインがアクティブになっている間に実際のデータレートを変動させます）。この場合、アクセスノードは、アクセスループ属性がしきい値を上回るたびに、追加情報レポートをNASに送信します。
The hierarchy and the rates of the various links to enable the NAS hierarchical scheduling and policing mechanisms are the following:
NAS階層スケジューリングとポリシングメカニズムを有効にするためのさまざまなリンクの階層とレートは次のとおりです。
o The identification and speed (data rate) of the DSL access loop (i.e., the net data rate)
o DSLアクセスループの識別と速度（データレート）（つまり、ネットデータレート）
o The identification and speed (data rate) of the Remote Terminal (RT) / Access Node uplink (when relevant)
o リモート端子（RT） /アクセスノードアップリンクの識別と速度（データレート）（関連する場合）
The NAS can adjust downstream shaping to the Access Loop's current actual data rate, and more generally reconfigure the appropriate nodes of its hierarchical scheduler (support of advanced capabilities according to TR-101).
NASは、ダウンストリームシェーピングをアクセスループの現在の実際のデータレートに調整し、より一般的には階層スケジューラの適切なノード（TR-101に従って高度な機能のサポート）を再構成できます。
This use case may actually include more information than link identification and corresponding data rates. In case of DSL access loops, the following access-loop characteristics can be sent to the NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]):
このユースケースには、実際には、リンク識別と対応するデータレートよりも多くの情報が含まれる場合があります。DSLアクセスループの場合、次のアクセスループ特性をNASに送信できます（ITU-T推奨G.997.1 [G.997.1]）：
o DSL Type (e.g., ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2)
o DSLタイプ（ADSL1、ADSL2、SDSL、ADSL2、VDSL、VDSL2など）
o Framing mode (e.g., ATM, ITU-T Packet Transfer Mode (PTM), IEEE 802.3 Ethernet in the First Mile (EFM))
o フレーミングモード（ATM、ITU-Tパケット転送モード（PTM）、IEEE 802.3イーサネットの最初のマイル（EFM））
o DSL port state (e.g., synchronized/showtime, low power, no power/ idle)
o DSLポート状態（例えば、同期/ショータイム、低電力、パワー/アイドルなし）
o Actual net data rate (upstream/downstream)
o 実際のネットデータレート（上流/下流）
o Maximum achievable/attainable net data rate (upstream/downstream)
o 最大達成可能/達成可能なネットデータレート（上流/下流）
o Minimum net data rate configured for the access loop (upstream/ downstream)
o アクセスループ用に構成された最小ネットデータレート（上流/下流）
o Maximum net data rate configured for the access loop (upstream/ downstream)
o アクセスループ用に構成された最大ネットデータレート（上流/下流）
o Minimum net data rate in low power state configured for the access loop (upstream/downstream)
o アクセスループ用に構成された低電力状態の最小ネットデータレート（上流/下流）
o Maximum achievable interleaving delay (upstream/downstream)
o 最大達成可能なインターリーブ遅延（上流/下流）
o Actual interleaving delay (upstream/downstream)
o 実際のインターリーブ遅延（上流/下流）
The NAS MUST be able to receive access-loop characteristics information, and share such information with AAA/policy servers.
NASは、アクセスループ特性情報を受信し、AAA/ポリシーサーバーとそのような情報を共有できる必要があります。
access-loop rates are typically configured in a static way. When a subscriber wants to change its access-loop rate, the network operator needs to reconfigure the Access Port configuration, possibly implying a business-to-business transaction between an Internet Service Provider (ISP) and an Access Provider. From an Operating Expenditures (OPEX) perspective this is a costly operation.
アクセスループレートは通常、静的な方法で構成されます。サブスクライバーがアクセスループレートを変更したい場合、ネットワークオペレーターはアクセスポート構成を再構成する必要があります。これは、おそらくインターネットサービスプロバイダー（ISP）とアクセスプロバイダー間の企業間トランザクションを意味します。運用支出（OPEX）の観点から、これは費用のかかる操作です。
Using the Access Node Control Mechanism to change the access-loop rate from the NAS avoids those cross-organization business-to-business interactions and allows to centralize subscriber-related service data in e.g., a policy server. More generally, several access-loop parameters (e.g., minimum data rate, interleaving delay) could be changed by means of the Access Node Control Mechanism.
Accessノード制御メカニズムを使用してNASからアクセスループレートを変更すると、これらのクロス組織化のビジネス間の相互作用が回避され、サブスクライバー関連のサービスデータをポリシーサーバーなどで集中させることができます。より一般的には、アクセスノード制御メカニズムにより、いくつかのアクセスループパラメーター（最小データレート、インターリーブ遅延）を変更できます。
Triggered by the communication of the access-loop attributes described in Section 3.1, the NAS could query a Policy or AAA Server to retrieve access-loop configuration data. The best way to change access-loop parameters is by using profiles. These profiles (e.g., DSL profiles for different services) are pre-configured by the Element Manager managing the Access Nodes. The NAS may then use the Configure Request message to send a reference to the right profile to the Access Node. The NAS may also update the access-loop configuration due to a subscriber service change (e.g., triggered by the policy server).
セクション3.1で説明されているアクセスループ属性の通信によってトリガーされ、NASはポリシーまたはAAAサーバーを照会してアクセスループ構成データを取得できます。アクセスループパラメーターを変更する最良の方法は、プロファイルを使用することです。これらのプロファイル（さまざまなサービスのDSLプロファイルなど）は、アクセスノードを管理するElement Managerによって事前に構成されています。NASは、Configure Requestメッセージを使用して、アクセスノードに正しいプロファイルへの参照を送信できます。NASは、サブスクライバーサービスの変更（ポリシーサーバーによってトリガーされるなど）のために、アクセスループ構成を更新することもできます。
The access-loop configuration mechanism may also be useful for configuration of parameters that are not specific to the access-loop technology. Examples include the QoS profile to be used for an access loop, or the per-subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. The latter is also discussed in Section 3.4.
アクセスループ構成メカニズムは、アクセスループテクノロジーに固有のパラメーターの構成にも役立つ場合があります。例には、アクセスループに使用されるQoSプロファイル、またはアクセスノードがIGMPスヌーピングまたはIGMPプロキシ関数を実行しているIPTVアプリケーションに使用されるサブスクリバーマルチリキャストチャネルの資格情報が含まれます。後者については、セクション3.4でも説明します。
It may be possible that a subscriber wants to change its access-loop rate, and that the operator wants to enforce this updated access-loop rate on the Access Node using ANCP, but that the Access Node Control Adjacency is down. In such a case, the NAS will not be able to request the configuration change on the Access Node. The NAS should then report this failure to the external management system, which could use application-specific signaling to notify the subscriber of the fact that the change could not be performed at this time.
サブスクライバーがアクセスループレートを変更したいと考えている可能性があり、オペレーターはANCPを使用してアクセスノードのこの更新されたアクセスループレートを実施したいが、アクセスノードコントロールの隣接性が低下している可能性があります。そのような場合、NASはアクセスノードの構成の変更を要求することができません。その後、NASはこの障害を外部管理システムに報告する必要があります。外部管理システムは、アプリケーション固有の信号を使用して、現時点で変更を実行できないという事実をサブスクライバーに通知することができます。
Traditionally, ATM circuits are point-to-point connections between the BRAS and the DSLAM or DSL NT. In order to test the connectivity on layer 2, appropriate Operations, Administration, and Maintenance (OAM) functionality is used for operation and troubleshooting. An end-to-end OAM loopback is performed between the edge devices (NAS and HGW) of the broadband access network.
従来、ATM回路は、ブラジャーとDSLAMまたはDSL NTの間のポイントツーポイント接続です。レイヤー2の接続性をテストするために、適切な操作、管理、およびメンテナンス（OAM）機能が操作とトラブルシューティングに使用されます。ブロードバンドアクセスネットワークのエッジデバイス（NASとHGW）の間でエンドツーエンドのOAMループバックが実行されます。
When migrating to an Ethernet-based aggregation network (as defined by TR-101), end-to-end ATM OAM functionality is no longer applicable. Ideally in an Ethernet aggregation network, end-to-end Ethernet OAM (as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731) can provide access-loop connectivity testing and fault isolation. However, most HGWs do not yet support these standard Ethernet OAM procedures. Also, various access technologies exist such as ATM/DSL, Ethernet in the First Mile (EFM), etc. Each of these access technologies have their own link-based OAM mechanisms that have been or are being standardized in different standard bodies.
イーサネットベースの集約ネットワーク（TR-101で定義されている）に移行する場合、エンドツーエンドのATM OAM機能は適用できなくなります。理想的にはイーサネット集約ネットワークでは、エンドツーエンドのイーサネットOAM（IEEE 802.1AGおよびITU-Tの推奨Y.1730/1731で指定）は、アクセスループ接続テストと障害分離を提供できます。ただし、ほとんどのHGWは、これらの標準イーサネットOAM手順をまだサポートしていません。また、ATM/DSL、イーサネット、最初のマイル（EFM）などのさまざまなアクセステクノロジーが存在します。これらの各アクセステクノロジーには、異なる標準体で標準化されている、または標準化されている独自のリンクベースのOAMメカニズムがあります。
In a mixed Ethernet and ATM access network (including the local loop), it is desirable to keep the same ways to test and troubleshoot connectivity as those used in an ATM-based architecture. To reach consistency with the ATM-based approach, an Access Node Control Mechanism between NAS and Access Node can be used until end-to-end Ethernet OAM mechanisms are more widely available.
混合イーサネットとATMアクセスネットワーク（ローカルループを含む）では、ATMベースのアーキテクチャで使用されているアーキテクチャと同じ方法をテストおよびトラブルシューティングする方法を維持することが望ましいです。ATMベースのアプローチとの一貫性に到達するために、NASとアクセスノードの間のアクセスノード制御メカニズムを使用して、エンドツーエンドのイーサネットOAMメカニズムがより広く利用可能になるまで使用できます。
Triggered by a local management interface, the NAS can use the Access Node Control Mechanism to initiate an access-loop test between Access Node and HGW. In case of an ATM-based access loop, the Access Node Control Mechanism can trigger the Access Node to generate ATM (F4/F5) loopback cells on the access loop. In case of Ethernet, the Access Node can perform a port synchronization and administrative test for the access loop. The Access Node can send the result of the test to the NAS via a Control Response message. The NAS may then send the result via a local management interface. Thus, the connectivity between the NAS and the HGW can be monitored by a single trigger event.
ローカル管理インターフェイスによってトリガーされたNASは、アクセスノード制御メカニズムを使用して、アクセスノードとHGW間のアクセスループテストを開始できます。ATMベースのアクセスループの場合、アクセスノード制御メカニズムがアクセスノードをトリガーして、アクセスループでATM（F4/F5）ループバックセルを生成できます。イーサネットの場合、アクセスノードはアクセスループのポート同期と管理テストを実行できます。アクセスノードは、コントロール応答メッセージを介してテストの結果をNASに送信できます。NASは、ローカル管理インターフェイスを介して結果を送信する場合があります。したがって、NASとHGW間の接続性は、単一のトリガーイベントによって監視できます。
With the rise of supporting IPTV services in a resource efficient way, multicast services are getting increasingly important.
IPTVサービスをリソース効率の良い方法でサポートすることにより、マルチキャストサービスはますます重要になっています。
In case of an ATM access/aggregation network, such as the reference architecture specified in Broadband Forum [TR-059], multicast traffic replication is performed in the NAS. In this model, typically IGMP is used to control the multicast replication process towards the subscribers. The NAS terminates and processes IGMP signaling messages sent by the subscribers; towards the Regional Network, the NAS typically uses a multicast routing protocol such as Protocol Independent Multicast (PIM). The ATM Access Nodes and aggregation switches don't perform IGMP processing, nor do they perform multicast traffic replication. As a result, network resources are wasted within the access/aggregation network.
ブロードバンドフォーラム[TR-059]で指定された参照アーキテクチャなどのATMアクセス/集約ネットワークの場合、NASでマルチキャストトラフィックの複製が実行されます。このモデルでは、通常、IGMPを使用して、加入者に対するマルチキャスト複製プロセスを制御します。NASは、加入者が送信したIGMPシグナリングメッセージを終了および処理します。地域ネットワークに向けて、NASは通常、プロトコル独立マルチキャスト（PIM）などのマルチキャストルーティングプロトコルを使用します。ATMアクセスノードと集約スイッチは、IGMP処理を実行せず、マルチキャストトラフィックレプリケーションを実行しません。その結果、ネットワークリソースはアクセス/集約ネットワーク内で無駄になります。
To overcome this resource inefficiency, the Access Node, aggregation node(s), and the NAS must all be involved in the multicast replication process. This prevents several copies of the same stream from being sent within the access/aggregation network. In case of an Ethernet-based access/aggregation network, this may, for example, be achieved by means of IGMP snooping or IGMP proxy in the Access Node and aggregation node(s).
このリソースの非効率性を克服するには、アクセスノード、集約ノード、およびNASがすべてマルチキャスト複製プロセスに関与する必要があります。これにより、同じストリームのいくつかのコピーがアクセス/集約ネットワーク内で送信されるのを防ぎます。イーサネットベースのアクセス/集約ネットワークの場合、これは、たとえば、アクセスノードおよび集約ノードのIGMPスヌーピングまたはIGMPプロキシによって達成される場合があります。
By introducing IGMP processing in the access/aggregation nodes, the multicast replication process is now divided between the NAS, the aggregation node(s), and Access Nodes. In order to ensure backward compatibility with the ATM-based model, the NAS, aggregation node, and Access Node need to behave as a single logical device. This logical device must have exactly the same functionality as the NAS in the ATM access/aggregation network. The Access Node Control Mechanism can be used to make sure that this logical/functional equivalence is achieved by exchanging the necessary information between the Access Node and the NAS.
アクセス/集約ノードにIGMP処理を導入することにより、マルチキャスト複製プロセスは、NAS、集約ノード、およびアクセスノードの間で分割されるようになりました。ATMベースのモデルとの後方互換性を確保するには、NAS、集約ノード、およびアクセスノードが単一の論理デバイスとして動作する必要があります。この論理デバイスは、ATMアクセス/集約ネットワークのNASとまったく同じ機能を持つ必要があります。アクセスノード制御メカニズムを使用して、アクセスノードとNASの間で必要な情報を交換することにより、この論理的/機能的等価性が達成されるようにすることができます。
Another option is for the subscriber to communicate the "join/leave" information with the NAS. This can for instance be done by terminating all subscriber IGMP signaling on the NAS. Another example could be a subscriber using some form of application-level signaling, which is redirected to the NAS. In any case, this option is transparent to the access and aggregation network. In this scenario, the NAS can use ANCP to create replication state in the AN for efficient multicast replication. The NAS sends a single copy of the multicast stream towards the AN. The NAS can perform conditional access and multicast admission control on multicast joins, and create replication state in the AN if the flow is admitted by the NAS.
別のオプションは、サブスクライバーがNASと「結合/残し」情報を伝えることです。これは、たとえば、NASのすべてのサブスクライバーIGMPシグナル伝達を終了することで実行できます。別の例は、NASにリダイレクトされる何らかの形式のアプリケーションレベルのシグナル伝達を使用したサブスクライバーです。いずれにせよ、このオプションはアクセスおよび集約ネットワークに対して透過的です。このシナリオでは、NASはANCPを使用して、効率的なマルチキャスト複製のためにANで複製状態を作成できます。NASは、マルチキャストストリームの単一のコピーをANに向けて送信します。NASは、マルチキャスト結合で条件付きアクセスとマルチキャストの入場制御を実行し、NASによってフローが認められている場合、ANで複製状態を作成できます。
The following subsections describe the different use cases related to multicast.
次のサブセクションでは、マルチキャストに関連するさまざまなユースケースについて説明しています。
In a DSL broadband access scenario, service providers may want to dynamically control, at the network level, access to some multicast flows on a per-user basis. This may be used in order to differentiate among multiple Service Offers or to realize/reinforce conditional access for sensitive content. Note that, in some environments, application-layer conditional access by means of Digital Rights Management (DRM) may provide sufficient control, so that Multicast Conditional Access may not be needed.
DSLブロードバンドアクセスシナリオでは、サービスプロバイダーは、ネットワークレベルで、ユーザーごとにいくつかのマルチキャストフローへのアクセスを動的に制御したい場合があります。これは、複数のサービスオファーを区別したり、機密コンテンツの条件付きアクセスを実現/強化するために使用できます。一部の環境では、デジタル権利管理（DRM）によるアプリケーション層の条件付きアクセスが十分な制御を提供しているため、マルチキャスト条件付きアクセスは必要ない場合があることに注意してください。
Where Multicast Conditional Access is required, it is possible, in some cases, to provision the necessary conditional access information into the AN so the AN can then perform the conditional access decisions autonomously. For these cases, the NAS can use ANCP to provision the necessary information in the AN so that the AN can decide locally to honor a join or to not honor a join. This can be done with the Control Request and Control Response messages.
マルチキャスト条件付きアクセスが必要な場合、場合によっては、必要な条件付きアクセス情報をAに提供することが可能です。これらの場合、NASはANCPを使用して必要な情報をANで提供できます。これにより、ANが参加を尊重したり、参加を尊重したりしないようにローカルに決定できます。これは、制御要求および制御応答メッセージで実行できます。
Provisioning the conditional access information on the AN can be done using a "white list", "grey list", and/or a "black list". A white list associated with an Access Port identifies the multicast flows that are allowed to be replicated to that port. A black list associated with an Access Port identifies the multicast flows that are not allowed to be replicated to that port. A grey list associated with an Access Port identifies the multicast flows for which the AN on receiving a join message, before starting traffic replication queries the NAS for further authorization. Each list contains zero, one, or multiple entries, and each entry may specify a single flow or contain ranges (i.e., mask on Group address and/or mask on Source address).
ANでの条件付きアクセス情報のプロビジョニングは、「白いリスト」、「グレーリスト」、および/または「ブラックリスト」を使用して実行できます。アクセスポートに関連付けられた白いリストは、そのポートに複製できるマルチキャストフローを識別します。アクセスポートに関連付けられた黒いリストは、そのポートに複製することが許可されていないマルチキャストフローを識別します。アクセスポートに関連付けられた灰色のリストは、トラフィックレプリケーションを開始する前に、ANが参加メッセージを受信すると、NASをさらに許可するために照会するマルチキャストフローを識別します。各リストにはゼロ、1つ、または複数のエントリが含まれており、各エントリは単一のフローを指定するか、範囲を含むことができます（つまり、グループアドレスにマスクおよび/またはソースアドレスにマスク）。
Upon receiving a join message on an Access Port, the Access Node will first check if the requested multicast flow is part of a white, grey, or a black list associated with that Access Port. If it is part of a white list, the AN autonomously starts replicating multicast traffic. If it is part of a black list, the AN autonomously discards the message because the request is not authorized, and may thus inform the NAS and log the request accordingly. If it is part of a grey list the AN uses ANCP to query the NAS, that in turn will respond to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied (and hence replication not performed by the AN).
アクセスポートで結合メッセージを受信すると、アクセスノードはまず、要求されたマルチキャストフローがそのアクセスポートに関連付けられた白、グレー、またはブラックリストの一部であるかどうかを確認します。それが白いリストの一部である場合、Aは自律的にマルチキャストトラフィックの複製を開始します。それが黒いリストの一部である場合、リクエストが承認されていないため、Aはメッセージを自律的に破棄し、したがってNASに通知し、それに応じてリクエストを記録することができます。灰色のリストの一部である場合、ANはANCPを使用してNASを照会します。これは、結合が尊重される（したがってANによって実行されるレプリケーション）または拒否（したがってレプリケーションが実行されないかどうかを示すANに応答します。An）。
If the requested multicast flow is part of multiple lists associated with the Access Port, then the most specific match will be used. If the most specific match occurs in multiple lists, the black list entry takes precedence over the grey list, which takes precedence over the white list.
要求されたマルチキャストフローがアクセスポートに関連付けられた複数のリストの一部である場合、最も具体的な一致が使用されます。最も具体的な一致が複数のリストで発生した場合、黒いリストエントリが灰色のリストよりも優先され、ホワイトリストよりも優先されます。
If the requested multicast flow is not part of any list, the message should be discarded. This default behavior can easily be changed by means of a "catch-all" statement in either the white list or the grey list. For instance, adding (<S=*,G=*>) in the white list would make the default behavior to accept join messages for a multicast flow that has no other match on any list. Similarly, if the default behavior should be to send a request to the NAS, then adding (<S=*,G=*>) in the grey list accomplishes that.
要求されたマルチキャストフローがリストの一部ではない場合、メッセージを破棄する必要があります。このデフォルトの動作は、ホワイトリストまたは灰色のリストの「キャッチオール」ステートメントによって簡単に変更できます。たとえば、白いリストに（<s =*、g =*>）を追加すると、デフォルトの動作により、リストに他の一致がないマルチキャストフローの参加メッセージを受け入れるようになります。同様に、デフォルトの動作がNASにリクエストを送信する必要がある場合、灰色のリストに（<s =*、g =*>）を追加することを達成します。
The white list, black list, and grey list can contain entries allowing:
ホワイトリスト、ブラックリスト、灰色のリストには、以下を許可するエントリを含めることができます。
o an exact match for a (*,G) ASM group (e.g., <G=g.h.i.l>);
o （*、g）ASMグループの正確な一致（例：<g = g.h.i.l>）;
o an exact match for a (S,G) SSM channel (e.g., <S=s.t.u.v,G=g.h.i.l>);
o （s、g）SSMチャネルの正確な一致（例：<s = s.t.u.v、g = g.h.i.l>）;
o a mask-based range match for a (*,G) ASM group (e.g., <G=g.h.i.l/ Mask>);
o （*、g）ASMグループのマスクベースの範囲マッチ（例：<g = g.h.i.l/ mask>）;
o a mask-based range match for a (S,G) SSM channel (e.g., <S=s.t.u.v/Mask,G=g.h.i.l/Mask>);
o （s、g）SSMチャネルのマスクベースの範囲マッチ（例：<s = s.t.u.v/mask、g = g.h.i.l/mask>）;
The following are some example configurations:
以下は、構成の例です。
o Scenario 1: reject all messages
o シナリオ1：すべてのメッセージを拒否します
* black list = {<S=*,G=*>}
* ブラックリスト= {<s =*、g =*>}
o Scenario 2: reject all messages, except Join (S=*,G=Gi) (1<=i<=n)
o シナリオ2：JOIN（S =*、G = GI）（1 <= i <= n）を除くすべてのメッセージを拒否します。
* white list = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn>}
* 白いリスト= {<s =*、g = g1>、<s =*、g = g2>、... <s =*、g = gn>}
* black list = {<S=*,G=*>}
* ブラックリスト= {<s =*、g =*>}
o Scenario 3: AN performs autonomous decisions for some channels, and asks the NAS for other channels
o
* white list = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn>}
* 白いリスト= {<s =*、g = g1>、<s =*、g = g2>、... <s =*、g = gn>}
* grey list = { <S=s,G=Gm>} for m>n
*
* black list = {<S=*,G=*>}
* ブラックリスト= {<s =*、g =*>}
* ==> Join (S=*,G=Gi) gets honored by AN (1<=i<=n)
* ==> Join (S=s,G=Gm) triggers ANCP Admission Request to NAS
* ==> everything else gets rejected by AN
The use of a white list and black list may be applicable, for instance, to regular IPTV services (i.e., broadcast TV) offered by an Access Provider to broadband (e.g., DSL) subscribers. For this application, the IPTV subscription is typically bound to a specific DSL line, and the multicast flows that are part of the subscription are well-known beforehand. Furthermore, changes to the conditional access information are infrequent, since they are bound to the subscription. Hence, the Access Node can be provisioned with the conditional access information related to the IPTV service.
In some other cases, it may be desirable to have the conditional access decision being taken by the NAS or a Policy Server. This may be the case when conditional access information changes frequently, or when the multicast groups are not known to a client application in advance. The conditional access control could be tied to a more complex policy/authorization mechanism, e.g., time-of-day access, location-based access, or to invoke a remote authorization server. For these cases, the AN can use ANCP to query the NAS that in turn will respond to the AN indicating whether the join is to be denied or honored (and hence replication performed by the AN). This can be done with the Admission Request and Admission Response messages.
他の場合には、NASまたはポリシーサーバーによって条件付きアクセス決定が行われることが望ましい場合があります。これは、条件付きアクセス情報が頻繁に変更される場合、またはマルチキャストグループが事前にクライアントアプリケーションに知られていない場合に当てはまる場合があります。条件付きアクセス制御は、より複雑なポリシー/承認メカニズム、たとえば、日時のアクセス、ロケーションベースのアクセス、またはリモート認証サーバーを呼び出すことができます。これらの場合、ANはANCPを使用してNASを照会し、結合が拒否されるか尊敬されるか（したがってANによって実行される複製）を示すANに応答します。これは、入場リクエストと入学応答メッセージで実行できます。
Some examples of using NAS querying are the following:
NASクエリを使用する例は次のとおりです。
o Roaming users: a subscriber that logs in on different wireless hotspots and would like to receive multicast content he is entitled to receive;
o ローミングユーザー：さまざまなワイヤレスホットスポットにログインし、受け取る権利があるマルチキャストコンテンツを受信したいサブスクライバー。
o Mobility or seamless handover (a related example): in both cases, the burden of (re)configuring access nodes with white lists or black lists may be too high;
o モビリティまたはシームレスなハンドオーバー（関連例）：どちらの場合も、白いリストまたは黒いリストを使用してアクセスノードを構成する（再）構成する負担が高すぎる場合があります。
o "Over-the-top video partnerships": service providers may choose to partner with Internet video providers to provide video content. In this case, the multicast group mappings may not be known in advance, or may be reused for different content in succession.
o 「オーバーザビデオパートナーシップ」：サービスプロバイダーは、ビデオコンテンツを提供するためにインターネットビデオプロバイダーと提携することを選択できます。この場合、マルチキャストグループマッピングは事前に知られていないか、異なるコンテンツに対して連続して再利用される場合があります。
o "Pay Per View": a subscriber chooses a specific IPTV channel which is made available for a given amount of time.
o 「Pay Per View」：サブスクライバーは、特定の時間の間利用可能になる特定のIPTVチャネルを選択します。
The successful delivery of triple-play broadband services is quickly becoming a big capacity planning challenge for most of the Service Providers nowadays. Solely increasing available bandwidth is not always practical, cost-economical, and/or sufficient to satisfy end-user experience given not only the strict requirements of unicast delay sensitive applications like VoIP and video, but also the fast growth of multicast interactive applications such as videoconferencing, digital TV, digital audio, online movies, and networked gaming. These applications are typically characterized by a delay-sensitive nature, an extremely loss-sensitive nature, and intensive bandwidth requirements. They are also typically "non-elastic", which means that they operate at a fixed bandwidth that cannot be dynamically adjusted to the currently available bandwidth.
トリプルプレイブロードバンドサービスの提供の成功は、最近のほとんどのサービスプロバイダーにとって急速に大きな能力計画の課題になりつつあります。利用可能な帯域幅の増加のみが、VoIPやビデオなどのユニキャスト遅延敏感なアプリケーションの厳格な要件だけでなく、マルチキャストインタラクティブアプリケーションの急速な成長を考慮して、エンドユーザーエクスペリエンスを満たすのに十分な実用的、コスト経済的、および/または十分なものではありません。ビデオ会議、デジタルテレビ、デジタルオーディオ、オンライン映画、ネットワークゲーム。これらのアプリケーションは通常、遅延に敏感な性質、非常に損失に敏感な性質、および集中的な帯域幅要件によって特徴付けられます。また、通常は「非弾性」です。つまり、現在利用可能な帯域幅に動的に調整できない固定帯域幅で動作します。
Therefore, a Connection Admission Control (CAC) mechanism covering admission of video traffic over the DSL broadband access is required, in order to avoid oversubscribing the available bandwidth and negatively impacting the end-user experience.
したがって、利用可能な帯域幅をオーバーサブスクライブし、エンドユーザーエクスペリエンスに悪影響を与えることを避けるために、DSLブロードバンドアクセスを介したビデオトラフィックの入場をカバーする接続接続制御（CAC）メカニズムが必要です。
Considering specifically admission control over the access line, before honoring a user request to join a new multicast flow, the combination of AN and NAS must ensure admission control is performed to validate that there is sufficient bandwidth remaining on the access line to carry the new video stream (in addition to all other multicast and unicast video streams sent over the access line). The solution needs to cope with multiple flows per access line and needs to allow access-line bandwidth to be dynamically shared across multicast and unicast traffic (the unicast CAC is performed either by the NAS or by some off-path policy server).
新しいマルチキャストフローに参加するユーザーのリクエストを尊重する前に、アクセスラインの特別な入場制御を考慮すると、ANとNASの組み合わせが、新しいビデオを運ぶためにアクセスラインに十分な帯域幅が残っていることを検証するために入学制御を実行する必要がありますストリーム（アクセスライン上に送信される他のすべてのマルチキャストおよびユニキャストビデオストリームに加えて）。このソリューションは、アクセスラインごとに複数のフローに対処する必要があり、アクセスライン帯域幅をマルチキャストトラフィックとユニキャストトラフィック間で動的に共有できるようにする必要があります（Unicast CACは、NASまたは一部のオフパスポリシーサーバーによって実行されます）。
Thus, supporting CAC for the access line requires some form of synchronization between the entity performing multicast CAC (e.g., the NAS or the AN), the entity performing unicast CAC (e.g., the policy server), and the entity actually enforcing the multicast replication (i.e., the AN). This synchronization can be achieved in a number of ways:
したがって、アクセスラインのCACをサポートするには、マルチキャストCAC（NASまたはANなど）を実行するエンティティ間の何らかの形の同期、ユニキャストCAC（ポリシーサーバーなど）を実行するエンティティ、および実際にマルチキャストレプリケーションを施行するエンティティが必要です。（すなわち、AN）。この同期は、さまざまな方法で達成できます。
o One approach is for the AN to query the NAS so that Admission Control for the access line is performed by the NAS, or by the policy server which interacts with the AN via NAS. The AN can use ANCP to query the NAS that in turn performs a multicast Admission Control check for the new multicast flow and responds to the AN indicating whether the join is to be denied or honored (and hence replication performed by the AN). The NAS may locally keep track of the portion of the access-loop net data rate that is available for (unicast or multicast) video flows and perform video bandwidth accounting for the access loop. Upon receiving an Admission Request from the AN, the NAS can check available access-loop bandwidth before admitting or denying the multicast flow. In the process, the NAS may communicate with the policy server. For unicast video services such as Video on Demand (VoD), the NAS may also be queried (by a policy server or via on-path CAC signaling), so that it can perform admission control for the unicast flow and update the remaining available access-loop bandwidth. The ANCP requirements to support this approach are specified in this document.
o 1つのアプローチは、ANがNASを照会し、アクセスラインの入場制御がNASによって実行されるか、AN Via NASと対話するポリシーサーバーによって実行されることです。ANはANCPを使用してNASを照会し、その結果、新しいマルチキャストフローのマルチキャスト入場制御チェックを実行し、結合が拒否されるか尊敬されるか（したがってANによって実行される複製）を示すANに応答します。NASは、（ユニキャストまたはマルチキャスト）ビデオフローで利用可能なアクセスループネットデータレートの部分を局所的に追跡し、アクセスループを占めるビデオ帯域幅を実行することができます。ANから入場リクエストを受信すると、NASは、マルチキャストフローを認めたり拒否したりする前に、利用可能なアクセスループ帯域幅を確認できます。その過程で、NASはポリシーサーバーと通信する場合があります。Video On Demand（VOD）などのユニキャストビデオサービスの場合、NASは（ポリシーサーバーまたはオンパスCACシグナリングを介して）照会される可能性があるため、ユニキャストフローのアミズミコントロールを実行し、残りの利用可能なアクセスを更新できます。 - ループ帯域幅。このアプローチをサポートするためのANCP要件は、このドキュメントで指定されています。
o The above model could be enhanced with the notion of "Delegation of Authorization". In such a model, the NAS or the policy server delegates authority to the Access Node to perform multicast Admission Control on the access loop. This is sometimes referred to as "Bandwidth Delegation", referring to the portion of the total access-loop bandwidth that can be used by the Access Node for multicast Admission Control. In this model, the NAS or the policy server manages the total access-line bandwidth, performs unicast admission control, and uses ANCP to authorize the Access Node to perform multicast Admission Control within the bounds of the "delegated bandwidth". Upon receiving a request for a multicast flow replication that matches an entry in the white or grey list, the AN performs the necessary bandwidth admission control check for the new multicast flow, before starting the multicast flow replication. At this point, there is typically no need for the Access Node to communicate with the NAS or the policy server via the NAS. The ANCP requirements to support this approach are also specified in this document.
o 上記のモデルは、「承認の委任」の概念で強化できます。このようなモデルでは、NASまたはポリシーサーバーは、アクセスループでマルチキャスト入場制御を実行するためにアクセスノードに当局を委任します。これは「帯域幅の委任」と呼ばれることもあります。これは、マルチキャスト入場制御のためにアクセスノードで使用できる総アクセスループ帯域幅の部分を指します。このモデルでは、NASまたはポリシーサーバーは、総アクセスライン帯域幅を管理し、ユニキャスト入場制御を実行し、ANCPを使用してアクセスノードを承認して、「委任された帯域幅」の範囲内でマルチキャスト接続コントロールを実行します。白または灰色のリストのエントリと一致するマルチキャストフローレプリケーションのリクエストを受信すると、ANはマルチキャストフローレプリケーションを開始する前に、新しいマルチキャストフローに必要な帯域幅の入場制御チェックを実行します。この時点で、通常、NASを介してNASまたはポリシーサーバーと通信するアクセスノードが必要ありません。このアプローチをサポートするためのANCP要件もこのドキュメントで指定されています。
o In case the subscriber communicates the "join/leave" information with the NAS (e.g., by terminating all subscriber IGMP signaling on the NAS or by using some form of application-level signaling), the approach is very similar. In this case, the NAS may locally keep track of the portion of the access-loop bandwidth that is available for video flows, perform CAC for unicast and multicast flows, and perform video bandwidth management. The NAS can set the replication state on the AN using ANCP if the flow is admitted. For unicast video services, the NAS may be queried (by a policy server or via on-path CAC signaling) to perform admission control for the unicast flow, and update the remaining available access-loop bandwidth. The ANCP requirements to support this approach are specified in this document.
o サブスクライバーがNASと「結合/休暇」情報を通信した場合（たとえば、NASのすべてのサブスクライバーIGMPシグナリングを終了するか、何らかの形式のアプリケーションレベルシグナル伝達を使用することにより）、アプローチは非常に似ています。この場合、NASは、ビデオフローに使用できるアクセスループ帯域幅の部分を局所的に追跡し、ユニキャストとマルチキャストフローのCACを実行し、ビデオ帯域幅管理を実行することができます。NASは、フローが認められている場合、ANCPを使用して複製状態を設定できます。ユニキャストビデオサービスの場合、NASは（ポリシーサーバーまたはオンパスCACシグナリングを介して）照会されて、ユニキャストフローの入場制御を実行し、残りの利用可能なアクセスループ帯域幅を更新できます。このアプローチをサポートするためのANCP要件は、このドキュメントで指定されています。
o In the last approach, the policy server queries the AN directly or indirectly via the NAS, so that both unicast and multicast CAC for the access line are performed by the AN. In this case, a subscriber request for a unicast flow (e.g., a Video on Demand session) will trigger a resource request message towards a policy server; the latter will then query the AN (possibly via the NAS), that in turn will perform unicast CAC for the access line and respond, indicating whether the unicast request is to be honored or denied. The above model could also be enhanced with the notion of "Delegation of Authorization". In such a model, the policy server delegates authority to the Access Node to perform multicast Admission Control on the access loop. In the case when the policy server queries the AN directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document. In the case when the policy server queries the AN indirectly via the NAS, the approach requires the use of ANCP and is therefore in the scope of this document.
o 最後のアプローチでは、ポリシーサーバーはANをNASを介して直接または間接的に照会し、アクセスラインのユニキャストとマルチキャストCACの両方がANによって実行されるようにします。この場合、ユニキャストフローのサブスクライバーリクエスト（たとえば、ビデオオンデマンドセッションなど）は、ポリシーサーバーへのリソース要求メッセージをトリガーします。後者はAN（おそらくNAS経由）を照会し、それがアクセスラインに対してユニキャストCACを実行し、応答し、ユニキャスト要求が尊重されるか拒否されるかを示します。上記のモデルは、「承認の委任」の概念によって強化することもできます。このようなモデルでは、ポリシーサーバーはアクセスノードに権限を委任し、アクセスループでマルチキャスト入場制御を実行します。ポリシーサーバーがANを直接照会する場合、アプローチはANCPの使用を必要としません。したがって、このドキュメントの範囲を超えています。ポリシーサーバーがNASを介して間接的にAを照会する場合、アプローチはANCPの使用を必要とするため、このドキュメントの範囲にあります。
The NAS uses ANCP to indicate to the AN whether or not Admission Control is required for a particular multicast flow on a given Access Port. In case Admission Control is required, the Access Node needs to know whether or not it is authorized to perform Admission Control itself and, if so, within which bounds it is authorized to do so (i.e., how much bandwidth is "delegated" by the NAS or the policy server). Depending on the type of multicast flow, Admission Control may or may not by done by the AN: o Multicast flows that require a Conditional Access operation to be performed by the Access Node are put in the black or white list. In addition, the Access Node performs Admission Control for those flows in the white list for which it is authorized to do so.
NASはANCPを使用して、特定のアクセスポートの特定のマルチキャストフローに入場制御が必要かどうかをANに示します。入場制御が必要な場合、アクセスノードは、入場制御自体を実行することが許可されているかどうかを知る必要があります。NASまたはポリシーサーバー）。マルチキャストフローのタイプに応じて、AN：oアクセスノードによって実行される条件付きアクセス操作を必要とするマルチキャストフローによって行われる場合とそうでない場合があります。さらに、Accessノードは、それが許可されているホワイトリストにあるこれらのフローの入場制御を実行します。
o Multicast flows that require a Conditional Access operation to be performed by the NAS or the policy server, are put in the grey list. In addition, for those flows in the grey list for which the Access Node should perform Admission Control, the NAS or the policy server will delegate authority to the AN.
o NASまたはポリシーサーバーが実行する条件付きアクセス操作を必要とするマルチキャストフローは、グレーリストに入れられます。さらに、アクセスノードが入場制御を実行する灰色リストに流れるように、NASまたはポリシーサーバーはANに当局を委任します。
In some cases, the bandwidth that the NAS or the policy server initially delegated to the AN may not be enough to satisfy a multicast request for a new flow. In this scenario, the AN can use ANCP to query the NAS in order to request additional delegated multicast bandwidth. This is a form of extending the AN authorization to perform Admission Control. The NAS or the policy server decides if the request for more bandwidth can be satisfied and uses ANCP to send a response to the AN indicating the updated delegated multicast bandwidth. It is worth noting that in this case, the time taken to complete the procedure is an increment to the zapping delay. In order to minimize the zapping delay for future join requests, the AN can insert in the request message two values: the minimum amount of additional multicast bandwidth requested and the preferred additional amount. The first value is the amount that allows the present join request to be satisfied, the second value an amount that anticipates further join requests.
場合によっては、NASまたはポリシーサーバーが最初にANに委任された帯域幅は、新しいフローのマルチキャストリクエストを満たすのに十分ではない可能性があります。このシナリオでは、ANはANCPを使用してNASを照会して、追加の委任されたマルチキャスト帯域幅を要求します。これは、入場制御を実行する許可を拡張する一形態です。NASまたはポリシーサーバーは、より多くの帯域幅のリクエストが満たされるかどうかを決定し、ANCPを使用してANに応答を送信します。この場合、手順を完了するのにかかった時間がザッピング遅延の増加であることは注目に値します。将来の参加要求のザッピング遅延を最小限に抑えるために、ANはリクエストメッセージに挿入できます2つの値：要求された追加のマルチキャスト帯域幅の最小量と優先される追加量。最初の値は、現在の結合要求を満たすことを可能にする金額、2番目の値は、さらに結合リクエストを予想する金額です。
In some cases, the NAS or the policy server may not have enough unicast bandwidth to satisfy a new incoming video request: in these scenarios, the NAS can use ANCP to query (or instruct) the AN in order to decrease the amount of multicast bandwidth previously delegated on a given Access Port. This is a form of limiting/ withdrawing AN authorization to perform Admission Control. The NAS can use ANCP to send a response to AN indicating the updated delegated multicast bandwidth. Based on considerations similar to those of the previous paragraph, it indicates the minimum amount of multicast bandwidth that it needs released and a preferred amount, which may be larger.
場合によっては、NASまたはポリシーサーバーは、新しい着信ビデオリクエストを満たすのに十分なユニキャスト帯域幅を持たない場合があります。これらのシナリオでは、NASはANCPを使用して、マルチキャスト帯域幅の量を減らすためにAをクエリ（または指示する）ことができます。以前は特定のアクセスポートに委任されました。これは、入場制御を実行する許可を制限/撤回する一形態です。NASはANCPを使用して、更新された委任されたマルチキャスト帯域幅を示す応答を送信できます。前の段落の考慮事項と同様の考慮事項に基づいて、リリースが必要なマルチキャスト帯域幅の最小量と優先額が大きいことを示しています。
Note: in order to avoid impacting existing multicast traffic, the NAS must not decrease the amount of delegated multicast bandwidth to a value lower than the bandwidth that is currently in use. This requires the NAS to be aware of this information (e.g., by means of a separate query action).
注：既存のマルチキャストトラフィックに影響を与えることを避けるために、NASは、委任されたマルチキャスト帯域幅の量を現在使用中の帯域幅より低い値に減らしてはなりません。これには、NASがこの情報を認識する必要があります（たとえば、別のクエリアクションによって）。
In addition, in some cases, upon receiving a leave for a specific multicast flow, the AN may decide that it has an excess of delegated but uncommitted bandwidth. In such case, the AN can use ANCP to send a message to the NAS to release all of part of the unused multicast bandwidth that was previously delegated. In this process, the Access Node may decide to retain a minimum amount of bandwidth for multicast services.
さらに、場合によっては、特定のマルチキャストフローの休暇を受け取ると、ANは、委任されたがコミットされていない過剰な帯域幅があると判断する場合があります。そのような場合、ANはANCPを使用してNASにメッセージを送信して、以前に委任された未使用のマルチキャスト帯域幅のすべての部分をリリースします。このプロセスでは、アクセスノードは、マルチキャストサービスの最小帯域幅を保持することを決定する場合があります。
In general, the Access Node and NAS may not be aware of all possible multicast groups that will be streamed in the access network. For instance, it is likely that there will be multicast streams offered across the Internet. For these unknown streams, performing bandwidth Admission Control may be challenging.
一般に、アクセスノードとNASは、アクセスネットワークでストリーミングされる可能性のあるすべてのマルチキャストグループを認識していない場合があります。たとえば、インターネット全体でマルチキャストストリームが提供される可能性があります。これらの未知のストリームの場合、帯域幅の入場制御を実行するのは困難な場合があります。
To solve this, these requests could be accepted without performing Admission Control. This solution works, provided that the network handles the streams as best effort, so that other streams (that are subject to Admission Control) are not impacted at times of congestion.
これを解決するために、これらのリクエストは、入場制御を実行せずに受け入れることができます。このソリューションは、ネットワークがストリームを最善の努力として処理することを条件に機能し、他のストリーム（入場制御の対象）が混雑の時に影響を受けないようにします。
Disabling Admission Control for an unknown stream can be achieved by adding a "catch-all statement" in the Access Node white list or grey list. In case the Access Node queries the NAS, the NAS on his turn will have to accept the request. That way, the unknown streams are not blocked by default.
不明なストリームの入場制御の無効化は、アクセスノードホワイトリストまたはグレーリストに「キャッチオールステートメント」を追加することで実現できます。AccessノードがNASを照会した場合、NASは彼のターンのリクエストを受け入れる必要があります。そうすれば、不明なストリームはデフォルトでブロックされていません。
Next, in order to ensure that the streams are handled as best effort, the flow must be marked as such when entering the service provider network. This way, whenever congestion occurs somewhere in the access/aggregation network, this stream will be kicked out before the access provider's own premium content.
次に、ストリームが最善の努力として処理されるようにするために、サービスプロバイダーネットワークに入るときにフローをそのようにマークする必要があります。このようにして、渋滞がアクセス/集約ネットワークのどこかで発生するたびに、このストリームはアクセスプロバイダー自身のプレミアムコンテンツの前に追い出されます。
The above concept is applicable beyond the notion of "Internet streams" or other unknown streams; it can be applied to known multicast streams as well. In this case, the Access Node or NAS will accept the stream even when bandwidth may not be sufficient to support the stream. This again requires that the stream be marked as best-effort traffic before entering the access/aggregation network.
上記の概念は、「インターネットストリーム」または他の未知のストリームの概念を超えて適用されます。既知のマルチキャストストリームにも適用できます。この場合、アクセスノードまたはNASは、帯域幅がストリームをサポートするのに十分でない場合でも、ストリームを受け入れます。これも、アクセス/集約ネットワークに入る前に、ストリームを最高のトラフィックとしてマークする必要があります。
As mentioned in Section 3.4.1, conditional access to popular IPTV channels can be achieved by means of a white and black list configured on the Access Node. This method allows the Access Node to autonomously decide whether or not access can be granted to a multicast flow.
セクション3.4.1で述べたように、人気のあるIPTVチャネルへの条件付きアクセスは、アクセスノードで構成された白と黒のリストを使用して実現できます。この方法により、アクセスノードがマルチキャストフローにアクセスを許可できるかどうかを自律的に決定できます。
IPTV is an example of a service that will not be offered as best effort, but requires some level of guaranteed quality of service. This requires the use of Multicast Admission Control. Hence, if the Access Node wants to autonomously perform the admission process, it must be aware of the bandwidth characteristics of multicast flows. Otherwise, the Access Node would have to query the NAS for Multicast Admission Control (per the grey list behavior); this would defeat the purpose of using a white and black list.
IPTVは、最善の努力として提供されないが、ある程度の保証されたサービス品質を必要とするサービスの例です。これには、マルチキャスト入場制御の使用が必要です。したがって、アクセスノードが入場プロセスを自律的に実行したい場合、マルチキャストフローの帯域幅特性に注意する必要があります。それ以外の場合、アクセスノードは、マルチキャストの入場制御を（グレーのリストの動作ごと）に照会する必要があります。これは、白と黒のリストを使用する目的を打ち負かすでしょう。
Some network deployments may combine the use of white list, black list, and grey list. The implications of such a model to the overall Multicast Admission Control model are not fully explored in this document.
一部のネットワーク展開では、白いリスト、ブラックリスト、グレーリストの使用を組み合わせることができます。このドキュメントでは、このようなモデルのマルチキャスト入場制御モデル全体に対する意味は完全には検討されていません。
It may be desirable to perform time- and/or volume-based accounting for certain multicast flows sent on particular Access Ports. In case the AN is performing the traffic replication process, it knows when replication of a multicast flow to a particular Access Port or user start and stops. Multicast accounting can be addressed in two ways:
特定のアクセスポートで送信される特定のマルチキャストフローについて、時間および/またはボリュームベースの会計を実行することが望ましい場合があります。ANがトラフィックレプリケーションプロセスを実行している場合、特定のアクセスポートまたはユーザーの開始と停止へのマルチキャストフローの複製がいつ発生するかがわかります。マルチキャスト会計は、2つの方法で対処できます。
o The AN keeps track of when replication for a given multicast flow starts or ends on a specified Access Port, and generates time-and/or volume-based accounting information per Access Port and per multicast flow, before sending it to a central accounting system for logging. Given that the AN communicates with the accounting system directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document;
o ANは、特定のマルチキャストフローのレプリケーションが指定されたアクセスポートで起動または終了する時期を追跡し、アクセスポートおよびマルチキャストフローごとに時間および/またはボリュームベースの会計情報を生成してから、中央の会計システムに送信します。ロギング。ANが会計システムと直接通信することを考えると、アプローチはANCPの使用を必要としません。したがって、このドキュメントの範囲を超えています。
o The AN keeps track of when replication for a given multicast flow starts or ends on a specified Access Port, and reports this information to the NAS for further processing. In this case, ANCP can be used to send the information from the AN to the NAS. This will be discussed in the remainder of this document.
o ANは、特定のマルチキャストフローの複製が指定されたアクセスポートで開始または終了する時期を追跡し、この情報をさらに処理するためにNASに報告します。この場合、ANCPを使用してANからNASに情報を送信できます。これについては、このドキュメントの残りの部分で説明します。
The Access Node can send multicast accounting information to the NAS using the Information Report message. A distinction can be made between two cases:
アクセスノードは、情報レポートメッセージを使用して、マルチキャスト会計情報をNASに送信できます。2つのケースの間で区別を行うことができます。
o Basic accounting information: the Access Node informs the NAS whenever replication starts or ends for a given multicast flow on a particular Access Port;
o 基本的な会計情報：アクセスノードは、特定のアクセスポートの特定のマルチキャストフローのレプリケーションが開始または終了するたびにNASに通知します。
o Detailed accounting information: the Access Node not only informs the NAS when replication starts or ends, but also informs the NAS about the multicast traffic volume replicated on the Access Port for that multicast flow. This is done by adding a byte count in the Information Report message that is sent to the NAS when replication ends.
o 詳細な会計情報：アクセスノードは、複製が開始または終了したときにNASに通知するだけでなく、そのマルチキャストフローのアクセスポートで複製されたマルチキャストトラフィックボリュームについても通知します。これは、複製が終了したときにNASに送信される情報レポートメッセージにバイトカウントを追加することによって行われます。
Upon receiving the Information Report messages, the NAS generates the appropriate time- and/or volume-based accounting records per access loop and per multicast flow to be sent to the accounting system.
情報レポートメッセージを受信すると、NASはアクセスループごとに適切な時間および/またはボリュームベースの会計レコードを生成し、マルチキャストフローごとに会計システムに送信されます。
The NAS should inform the Access Node about the type of accounting needed for a given multicast flow on a particular Access Port:
NASは、特定のアクセスポートの特定のマルチキャストフローに必要な会計のタイプについてアクセスノードに通知する必要があります。
o No reporting messages need to be sent to the NAS.
o 報告メッセージをNASに送信する必要はありません。
o Basic accounting is required.
o 基本的な会計が必要です。
o Detailed accounting is required.
o 詳細な会計が必要です。
Note that in case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high.
非常に速いチャネルの変更がある場合、NASに送信される情報を報告する情報の量が高くなる可能性があることに注意してください。
The ANCP requirements to support this use case are specified below in this document.
このユースケースをサポートするためのANCP要件は、このドキュメントで以下に指定されています。
It may also be desirable for the NAS to have the capability to asynchronously query the AN to obtain an instantaneous status report related to multicast flows currently replicated by the AN. Such a reporting functionality could be useful for troubleshooting and monitoring purposes. The NAS can query the AN to know the following:
また、NASがANによって現在複製されているマルチキャストフローに関連する瞬間的なステータスレポートを取得するために非同期的にクエリする能力を持つことが望ましい場合があります。このようなレポート機能は、トラブルシューティングと監視の目的に役立つ可能性があります。NASは、次を知るためにANを照会できます。
o Which flows are currently being sent on a specific Access Port (i.e., a report for one Access Port)
o 現在、どのフローが特定のアクセスポートで送信されています（つまり、1つのアクセスポートのレポート）
o On which Access Ports a specified multicast flow is currently being sent (i.e., a report for one multicast flow)
o アクセスポート指定されたマルチキャストフローが現在送信されています（つまり、1つのマルチキャストフローのレポート）
o Which multicast flows are currently being sent on each of the Access Ports (i.e., a global report for one Access Node)
o 現在、各アクセスポート（つまり、1つのアクセスノードのグローバルレポート）でどのマルチキャストフローが送信されていますか？
The capability to dynamically stop the replication of a multicast flow can be useful in different scenarios: for example in case of prepaid service, when available credit expires, the Service Provider may want to be able to stop multicast replication on a specified Access Port for a particular user. Another example of applicability for this functionality is a scenario where a Service Provider would like to show a "Content Preview": in this case, a multicast content will be delivered just for a fixed amount of time.
マルチキャストフローの複製を動的に停止する機能は、さまざまなシナリオで役立ちます。たとえば、プリペイドサービスの場合、利用可能なクレジットが期限切れになった場合、サービスプロバイダーは、指定されたアクセスポートでマルチキャスト複製を停止できるようにすることができます。特定のユーザー。この機能への適用性のもう1つの例は、サービスプロバイダーが「コンテンツプレビュー」を表示したいシナリオです。この場合、マルチキャストコンテンツは固定期間だけ配信されます。
In both cases, an external entity (for example, a policy server or an external application entity) can instruct the NAS to interrupt the multicast replication of a specified multicast flow to a specified Access Port or user. The NAS can then use ANCP to communicate this decision to the Access Node. This can be done with the Admission Response message.
どちらの場合も、外部エンティティ（たとえば、ポリシーサーバーや外部アプリケーションエンティティ）は、指定されたマルチキャストフローのマルチキャストレプリケーションを指定されたアクセスポートまたはユーザーへのマルチキャストレプリケーションを中断するようにNASに指示できます。NASはANCPを使用して、この決定をアクセスノードに伝えることができます。これは、入場応答メッセージで実行できます。
In some deployment scenarios, the NAS may be made aware of end-users' requests to join/leave a multicast flow by other means than ANCP Admission Requests sent by the AN. One possible deployment scenario where this model applies is the case where the Access Node doesn't process the IGMP join/leave messages from the end-user (e.g., because they are tunneled), but forwards them to the NAS. In such environments, the NAS can control multicast replication on the AN via ANCP through the use of Spontaneous Admission Responses (i.e., sent by the NAS without prior receipt of a corresponding Admission Request).
いくつかの展開シナリオでは、NASは、ANが送信したANCP入学要求以外のマルチキャストフローに参加/残すというエンドユーザーの要求を認識させることができます。このモデルが適用される可能性のある展開シナリオの1つは、アクセスノードがIGMPの結合/放送メッセージをエンドユーザーから処理しない場合（たとえば、それらがトンネルされているため）、それらをNASに転送する場合です。このような環境では、NASは、自発的な入院応答を使用して（つまり、対応する入場リクエストを事前に受信せずにNASによって送信される）を使用して、ANV via ANCPのマルチキャストレプリケーションを制御できます。
R-1 The ANCP MUST be easily extensible through the definition of new message types or TLVs to support use cases beyond those currently addressed in this document (this includes the use of Access Nodes different from a DSLAM, e.g., a PON Access Node).
R-1 ANCPは、新しいメッセージタイプまたはTLVの定義を通じて簡単に拡張できる必要があります。これは、このドキュメントで現在扱われているケースを超えるユースケースをサポートする必要があります（これには、DSLAM、たとえばPONアクセスノードとは異なるアクセスノードの使用が含まれます）。
R-2 The ANCP MUST be flexible enough to accommodate the various technologies that can be used in an access network and in the Access Node; this includes both ATM and Ethernet.
R-2 ANCPは、アクセスネットワークおよびアクセスノードで使用できるさまざまなテクノロジーに対応するのに十分柔軟でなければなりません。これには、ATMとイーサネットの両方が含まれます。
R-3 The Access Node Control interactions MUST be reliable (using either a reliable transport protocol (e.g., TCP) for the Access Node Control Protocol messages, or by designing ANCP to be reliable).
R-3アクセスノード制御インタラクションは信頼できる必要があります（アクセスノード制御プロトコルメッセージに信頼できる輸送プロトコル（TCPなど）、またはANCPを信頼できるように設計することにより）。
R-4 The ANCP MUST support "request/response" transaction-based interactions for the NAS to communicate control decisions to the Access Node, or for the NAS to request information from the Access Node. Transactions MUST be atomic, i.e., they are either fully completed, or rolled back to the previous state. This is required so that the network elements always remain in a known state, irrespective of whether or not the transaction is successful.
R-4 ANCPは、NASがアクセスノードに制御決定を通知するための「要求/応答」トランザクションベースのインタラクションをサポートする必要があります。トランザクションは原子でなければなりません。つまり、それらは完全に完了するか、前の状態に戻っています。これは、トランザクションが成功したかどうかに関係なく、ネットワーク要素が常に既知の状態にとどまるように必要です。
In case the NAS wants to communicate a bulk of independent control decisions to the Access Node, the transaction (and notion of atomicity) applies to the individual control decisions. This avoids having to roll back all control decisions. Similarly, if the NAS wants to request a bulk of independent information elements from the Access Node, the notion of transaction applies to the individual information elements.
NASがアクセスノードに独立した制御決定の大部分を伝えたい場合、トランザクション（および原子性の概念）が個々の制御決定に適用されます。これにより、すべての制御決定をロールバックする必要がありません。同様に、NASがアクセスノードから大量の独立した情報要素を要求したい場合、トランザクションの概念は個々の情報要素に適用されます。
R-5 The ANCP MUST be scalable enough to allow a given NAS to control at least 5000 Access Nodes.
R-5 ANCPは、特定のNASが少なくとも5000アクセスノードを制御できるように十分にスケーラブルでなければなりません。
R-6 The operation of the ANCP in the NAS and Access Nodes MUST be controllable via a management station (e.g., via SNMP). This MUST allow a management station to retrieve statistics and alarms related to the operation of the ANCP, as well as to allow it to initiate OAM operations and retrieve corresponding results.
R-6 NASおよびアクセスノードでのANCPの動作は、管理ステーション（例：SNMPを介して）を介して制御可能でなければなりません。これにより、管理ステーションがANCPの動作に関連する統計とアラームを取得し、OAM操作を開始し、対応する結果を取得できるようにする必要があります。
R-7 The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using black, grey, and white lists.
R-7 ANCPは、黒、グレー、および白のリストを使用して、アクセスノード上のアクセスポートにアクセスするためのマルチキャスト条件付きアクセス情報を提供するサポートをサポートする必要があります。
R-8 The ANCP MUST support binding a particular black, grey, and white List to a given Access Port.
R-8 ANCPは、特定の黒、灰色、および白のリストを特定のアクセスポートにバインドすることをサポートする必要があります。
R-9 Upon receiving a join to a multicast flow that matches the grey list, the ANCP MUST allow the AN to query the NAS to request an admission decision for replicating that multicast flow to a particular Access Port.
R-9灰色のリストに一致するマルチキャストフローへの結合を受信すると、ANCPはANがNASを照会して、そのマルチキャストフローを特定のアクセスポートに複製するための入場決定を要求することを許可する必要があります。
R-10 The ANCP MUST allow the NAS to send an admission decision to the AN indicating whether or not a multicast flow may be replicated to a particular Access Port.
R-10 ANCPは、NASがMulticastフローを特定のアクセスポートに複製できるかどうかを示すANに入学決定を送信できるようにする必要があります。
R-11 The ANCP MUST allow the NAS to indicate to the AN whether or not Admission Control is needed for some multicast flows on a given Access Port, and (where needed) whether or not the Access Node is authorized to perform Admission Control itself (i.e., whether or not AN Bandwidth Delegation applies).
R-11 ANCPは、NASが特定のアクセスポートのいくつかのマルチキャストフローに入場制御が必要かどうかをANに示すことを許可する必要があります。つまり、帯域幅の代表団が適用されるかどうか）。
R-12 In case of Admission Control without AN Bandwidth Delegation, the ANCP MUST allow the NAS to reply to a query from the AN indicating whether or not a multicast flow is allowed to be replicated to a particular Access Port.
R-12帯域幅の代表団のない入場制御の場合、ANCPは、NASがANからのクエリに応答することを許可する必要があります。
R-13 In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the NAS to delegate a certain amount of bandwidth to the AN for a given Access Port for multicast services only.
R-13帯域幅代表団を伴う入学制御の場合、ANCPは、NASがマルチキャストサービスのみの特定のアクセスポートに対してANに一定量の帯域幅を委任できるようにする必要があります。
R-14 In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the AN to query the NAS to request additional multicast bandwidth on a given Access Port.
R-14帯域幅の代表団を備えた入場制御の場合、ANCPはANがNASを照会して、特定のアクセスポートで追加のマルチキャスト帯域幅を要求することを許可する必要があります。
R-15 In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the NAS to query (or to instruct) the AN to reduce the amount of bandwidth previously delegated on a given Access Port.
R-15帯域幅代表団を伴う入学制御の場合、ANCPは、NASが特定のアクセスポートに委任された以前に委任された帯域幅の量を減らす（または指示する）ことを許可する必要があります。
R-16 In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the AN to inform the NAS if it autonomously releases redundant multicast bandwidth on a given Access Port.
R-16帯域幅代表団を伴う入学制御の場合、ANCPは、特定のアクセスポートで冗長なマルチキャスト帯域幅を自律的にリリースする場合、ANにNASに通知できるようにする必要があります。
R-17 The ANCP MUST allow the AN to send an Information Report message to the NAS whenever replication of a multicast flow on a particular Access Port starts or ends.
R-17 ANCPは、特定のアクセスポートが開始または終了するマルチキャストフローを複製するたびに、ANがNASに情報レポートメッセージを送信できるようにする必要があります。
R-18 The ANCP MUST allow the AN to send an Information Report message to the NAS indicating the multicast traffic volume that has been replicated on that port.
R-18 ANCPは、ANがNASに情報レポートメッセージを送信して、そのポートで複製されたマルチキャストトラフィックボリュームを示すことを許可する必要があります。
R-19 The ANCP MUST allow the NAS to indicate to the AN whether or not multicast accounting is needed for a multicast flow on a particular Access Port.
R-19 ANCPは、特定のアクセスポートのマルチキャストフローにマルチキャスト会計が必要かどうかをANに示すことを許可する必要があります。
R-20 In case multicast accounting is needed for a multicast flow on a particular Access Port, the ANCP MUST allow the NAS to indicate to the AN whether or not additional volume accounting information is required.
R-20特定のアクセスポートのマルチキャストフローにマルチキャストアカウンティングが必要な場合、ANCPはNASがANに追加のボリュームアカウンティング情報が必要かどうかを示すことを許可する必要があります。
R-21 The ANCP MUST allow the NAS to revoke a decision to replicate a multicast flow to a particular Access Port, which had been conveyed earlier to an AN.
R-21 ANCPは、NASが以前にANに伝えられていた特定のアクセスポートにマルチキャストフローを複製する決定を取り消すことを許可する必要があります。
R-22 The ANCP MUST support partial updates of the white, grey, and black lists.
R-22 ANCPは、白、灰色、黒のリストの部分的な更新をサポートする必要があります。
R-23 The ANCP MUST allow the NAS to query the AN to obtain information on what multicast flows are currently being replicated on a given Access Port, what Access Ports are currently receiving a given multicast flow, or what multicast flows are currently replicated on each Access Port.
R-23 ANCPは、NASがANを照会して、特定のアクセスポートで現在複製されているマルチキャストフロー、特定のマルチキャストフローを受信しているアクセスポート、またはそれぞれで現在複製されているマルチキャストフローに関する情報を取得できるようにする必要があります。アクセスポート。
R-24 The ANCP SHOULD provide a "shutdown" sequence allowing the protocol to inform the peer that the system is gracefully shutting down.
R-24 ANCPは、「シャットダウン」シーケンスを提供し、プロトコルがシステムが優雅にシャットダウンしていることをピアに通知できるようにする必要があります。
R-25 The ANCP SHOULD include a "report" model for the Access Node to spontaneously communicate to the NAS changes of states.
R-25 ANCPには、Accessノードの「レポート」モデルを含める必要があります。
R-26 The ANCP SHOULD support a graceful restart mechanism to enable it to be resilient to network failures between the AN and NAS.
R-26 ANCPは、ANとNASの間のネットワーク障害に回復力があるように、優雅な再起動メカニズムをサポートする必要があります。
R-27 The ANCP MUST provide a means for the AN and the NAS to inform each peer about the supported use cases (either use cases defined in this document or future use cases yet to be defined), and to negotiate a common subset.
R-27 ANCPは、ANとNASが各ピアにサポートされているユースケース（このドキュメントで定義されているユースケースまたはまだ定義されている将来のユースケースのいずれか）を通知し、共通のサブセットを交渉するための手段を提供する必要があります。
The notion of an Access Node Control Adjacency is defined in Section 1.2.
アクセスノード制御隣接の概念は、セクション1.2で定義されています。
R-28 The ANCP MUST support an adjacency protocol in order to automatically synchronize its operational state between its peers, to agree on which version of the protocol to use, to discover the identity of its peers, and to detect when they change.
R-28 ANCPは、ピア間の運用状態を自動的に同期し、使用するプロトコルのバージョンに同意し、ピアのアイデンティティを発見し、いつ変更するかを検出するために、隣接プロトコルをサポートする必要があります。
R-29 The ANCP MUST include a mechanism to automatically detect adjacency loss.
R-29 ANCPには、隣接する損失を自動的に検出するメカニズムを含める必要があります。
R-30 A loss of the Access Node Control Adjacency MUST NOT affect subscriber connectivity.
R-30アクセスノード制御隣接の損失は、サブスクライバーの接続に影響してはなりません。
R-31 If the Access Node Control Adjacency is lost, it MUST leave the network elements in a known state, irrespective of whether or not the ongoing transaction was successful.
R-31アクセスノード制御の隣接性が失われた場合、進行中のトランザクションが成功したかどうかに関係なく、ネットワーク要素を既知の状態にしておく必要があります。
R-32 The ANCP MUST support a mechanism to synchronize access port configuration and status information between ANCP peers as part of establishing or recovering the Access Node Control Adjacency.
R-32 ANCPは、アクセスノード制御隣接の確立または回復の一環として、ANCPピア間のアクセスポート構成とステータス情報を同期するメカニズムをサポートする必要があります。
R-33 The Access Node Control Mechanism MUST be defined in a way that is independent of the underlying layer 2 transport technology. Specifically, the Access Node Control Mechanism MUST support transmission over an ATM as well as over an Ethernet aggregation network.
R-33アクセスノード制御メカニズムは、基礎となるレイヤー2輸送技術とは独立した方法で定義する必要があります。具体的には、アクセスノード制御メカニズムは、ATM上およびイーサネット集約ネットワークを介した送信をサポートする必要があります。
R-34 The ANCP MUST use the IP protocol stack.
R-34 ANCPはIPプロトコルスタックを使用する必要があります。
R-35 If the layer 2 transport technology is based on ATM, then the ANCP peers must use the encapsulation according to [RFC2684] (IPoA).
R-35レイヤー2輸送技術がATMに基づいている場合、ANCPピアは[RFC2684]（IPOA）に従ってカプセル化を使用する必要があります。
R-36 If the layer 2 transport technology is based on Ethernet, then the ANCP peers must use the encapsulation according to [RFC894] (IPoE).
R-36レイヤー2トランスポートテクノロジーがイーサネットに基づいている場合、ANCPピアは[RFC894]（IPOE）に従ってカプセル化を使用する必要があります。
This section lists the requirements for an AN that supports the use cases defined in this document. Note that this document does not intend to impose absolute requirements on network elements. Therefore, the words "must" and "should" used in this section are not capitalized.
このセクションには、このドキュメントで定義されているユースケースをサポートするAの要件をリストします。このドキュメントは、ネットワーク要素に絶対要件を課すつもりはないことに注意してください。したがって、このセクションで使用される「必須」と「必要」という言葉は大文字ではありません。
The Access Node Control Mechanism is defined to operate between an Access Node (AN) and a NAS. In some cases, one AN can be connected to more than one physical NAS device (e.g., in case different wholesale service providers have different NAS devices). In such a model, the physical AN needs to be split in virtual ANs, each having its own Access Node Control reporting and/or enforcement function.
アクセスノード制御メカニズムは、アクセスノード（AN）とNASの間で動作するように定義されています。場合によっては、1つは複数の物理NASデバイスに接続できます（たとえば、卸売サービスプロバイダーが異なるNASデバイスを持っている場合）。このようなモデルでは、物理ANを仮想ANSで分割する必要があり、それぞれが独自のアクセスノード制御レポートおよび/または施行機能を備えています。
R-37 An Access Node as physical device can be split in logical partitions. Each partition may have its independent NAS. Therefore, the Access Node must support at least 2 partitions. The Access Node should support 8 partitions.
R-37物理デバイスとしてのアクセスノードは、論理パーティションで分割できます。各パーティションには、独立したNASがある場合があります。したがって、アクセスノードは少なくとも2つのパーティションをサポートする必要があります。アクセスノードは8つのパーティションをサポートする必要があります。
R-38 One partition is grouped of several Access Ports. Each Access Port on an Access Node must be assigned uniquely to one partition.
R-38 1つのパーティションには、いくつかのアクセスポートがグループ化されています。アクセスノードの各アクセスポートは、1つのパーティションに一意に割り当てる必要があります。
It is assumed that all circuits (i.e., ATM PVCs or Ethernet VLANs) on top of the same physical Access Port are associated with the same partition. In other words, partitioning is performed at the level of the physical Access Port only.
同じ物理アクセスポートの上にあるすべての回路（つまり、ATM PVCまたはイーサネットVLAN）は同じパーティションに関連付けられていると想定されています。つまり、パーティション化は、物理アクセスポートのレベルでのみ実行されます。
R-39 Each AN partition must have a separate Access Node Control Adjacency to a NAS.
R-39各パーティションには、NASへの個別のアクセスノード制御隣接が必要です。
R-40 Each AN partition must be able to enforce access of the controllers to their designated partitions.
R-40各パーティションは、指定されたパーティションへのコントローラーのアクセスを強制できる必要があります。
R-41 The Access Node should be able to establish and maintain ANCP Adjacencies to redundant controllers.
R-41アクセスノードは、ANCPの隣接を冗長コントローラーに確立および維持できる必要があります。
The Control Channel is a bidirectional IP communication interface between the controller function (in the NAS) and the reporting/ enforcement function (in the AN). It is assumed that this interface is configured (rather than discovered) on the AN and the NAS.
コントロールチャネルは、コントローラー関数（NAS）とレポート/執行関数（AN）の間の双方向IP通信インターフェイスです。このインターフェイスは、ANおよびNASで（発見されたのではなく）構成されていると想定されています。
Depending on the network topology, the Access Node can be located in a street cabinet or in a central office. If an Access Node in a street cabinet is connected to a NAS, all user traffic and Access Node Control data can use the same physical link.
ネットワークトポロジに応じて、アクセスノードは街路キャビネットまたは中央オフィスに配置できます。通りキャビネットのアクセスノードがNASに接続されている場合、すべてのユーザートラフィックとアクセスノード制御データは同じ物理リンクを使用できます。
R-42 The Control Channel should use the same facilities as the ones used for the data traffic. Note that this is actually a deployment consideration, which has no impact on the actual protocol design.
R-42制御チャネルは、データトラフィックに使用される機能と同じ機能を使用する必要があります。これは実際には展開考慮事項であり、実際のプロトコル設計に影響を与えないことに注意してください。
R-43 The Access Node must process control transactions in real-time (i.e., with a specific response latency).
R-43アクセスノードは、リアルタイムで制御トランザクションを処理する必要があります（つまり、特定の応答レイテンシを使用）。
R-44 The Access Node should mark Access Node Control Protocol messages with a high priority (e.g., Variable Bit Rate - Real Time (VBR-RT) for ATM cells, p-bit 6 or 7 for Ethernet packets) in order to avoid or reduce the likelihood of dropping packets in case of network congestion.
R-44アクセスノードは、ATMセルの可変ビットレート - リアルタイム（VBR-RT）、イーサネットパケットのP-BIT 6または7）を回避または回避するために、アクセスノード制御プロトコルメッセージをマークする必要があります。ネットワークの混雑の場合にパケットを落とす可能性を減らします。
R-45 If ATM interfaces are used, then any Virtual Path Identifier (VPI) and Virtual Circuit Identifier (VCI) value must be able to be used for the purpose of supporting the Access Node Control Channel.
R-45 ATMインターフェイスを使用する場合、仮想パス識別子（VPI）および仮想回路識別子（VCI）値を使用することができなければなりません。
R-46 If Ethernet interfaces are used then any C-VID and S-VID must be able to be used for the purpose of supporting the Access Node Control Channel.
R-46イーサネットインターフェイスを使用する場合、C-VIDおよびS-VIDを使用することができなければなりません。アクセスノード制御チャネルをサポートする目的で使用する必要があります。
R-47 In case the Access Node and NAS cannot agree on a common set of capabilities, as part of the ANCP capability negotiation procedure, the Access Node must report this to network management.
R-47アクセスノードとNASが、ANCP機能交渉手順の一部として、共通の機能セットに同意できない場合、アクセスノードはこれをネットワーク管理に報告する必要があります。
R-48 The Access Node should support generating an alarm to a management station upon loss or malfunctioning of the Access Node Control Adjacency with the NAS.
R-48アクセスノードは、NASとのアクセスノード制御隣接の損失または誤動作時に、管理ステーションへのアラームの生成をサポートする必要があります。
R-49 To identify the Access Node and Access Port within a control domain, a unique identifier is required. This identifier must be in line with the addressing scheme principles specified in Section 3.9.3 of TR-101.
R-49コントロールドメイン内のアクセスノードとアクセスポートを識別するには、一意の識別子が必要です。この識別子は、TR-101のセクション3.9.3で指定されたアドレス指定スキームの原則に沿っている必要があります。
R-50 In a Broadband Forum TR-101 network architecture, an Access Circuit Identifier (ACI) identifying an AN and Access Port is added to DHCP and PPPoE messages. The NAS must use the same ACI format in ANCP messages in order to allow the NAS to correlate this information with the information present in DHCP and PPPoE messages.
R-50ブロードバンドフォーラムTR-101ネットワークアーキテクチャでは、アクセス回路識別子（ACI）の識別とアクセスポートがDHCPおよびPPPOEメッセージに追加されます。NASは、NASがこの情報をDHCPおよびPPPOEメッセージに存在する情報と相関させるために、ANCPメッセージで同じACI形式を使用する必要があります。
R-51 The AN must deny any join to a multicast flow matching the black list for the relevant Access Port.
R-51 ANは、関連するアクセスポートのブラックリストに一致するマルチキャストフローへの結合を拒否しなければなりません。
R-52 The AN must accept any join to a multicast flow matching the white list and for which no Bandwidth Delegation is used.
R-52 ANは、白いリストに一致するマルチキャストフローへの結合を受け入れ、帯域幅の委任は使用されません。
R-53 Upon receiving a join to a multicast flow that matches the white list and for which Bandwidth Delegation is used, the AN must perform the necessary bandwidth admission control check for the new flow before starting the multicast flow replication. This may involve a decision made locally, or querying the NAS or external system such as a policy server, to request additional delegated multicast bandwidth on a given Access Port.
R-53白いリストと一致するマルチキャストフローへの結合を受信し、帯域幅代表団が使用されるために、ANはマルチキャストフローレプリケーションを開始する前に、必要な帯域幅の入場制御チェックを新しいフローに実行する必要があります。これには、ローカルで行われた決定、またはNASまたはポリシーサーバーなどの外部システムを照会するために、特定のアクセスポートに追加の委任されたマルチキャスト帯域幅を要求することが含まれます。
R-54 Upon receiving a join to a multicast flow which matches the grey list and for which no Bandwidth Delegation is used, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied. In this case, the NAS will perform both the necessary conditional access and the admission control checks for the new flow.
R-54グレーリストに一致し、帯域幅の委任が使用されないマルチキャストフローへの結合を受信すると、ANはANCPを使用してNASを照会して、その結合が尊重されるか拒否されるかを示す応答を受け取る必要があります。この場合、NASは必要な条件付きアクセスと新しいフローの入場制御チェックの両方を実行します。
R-55 Upon receiving a join to a multicast flow that matches the grey list and for which Bandwidth Delegation is used, the AN must first perform the necessary bandwidth admission control check for the new flow. If successful, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied.
R-55灰色のリストと一致するマルチキャストフローへの結合を受信し、帯域幅代表団が使用されるために、ANは最初に新しいフローに必要な帯域幅の入場制御チェックを実行する必要があります。成功した場合、ANはANCPを使用してNASを照会して、その結合が尊重されるか拒否されるかを示す応答を受け取るためにサポートする必要があります。
R-56 In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to notify the NAS when the user leaves the multicast flow.
R-56帯域幅代表団を伴う入学制御の場合、ANはANCPを使用してマルチキャストフローを離れるときにNASに通知するためにANCPを使用する必要があります。
R-57 In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to query the NAS to request additional delegated multicast bandwidth on a given Access Port; the AN should be able to specify both the minimum and the preferred amount of additional multicast bandwidth requested.
R-57帯域幅代表団を伴う入学制御の場合、ANはANCPを使用してNASを照会して、特定のアクセスポートに追加の委任されたマルチキャスト帯域幅を要求する必要があります。ANは、要求された追加のマルチキャスト帯域幅の最小値と優先額の両方を指定できるはずです。
R-58 In case of Admission Control with AN Bandwidth Delegation, upon receiving a Bandwidth Delegation Request from the NAS querying the AN for the delegated multicast bandwidth on a given Access Port, the AN must support using ANCP to send a Bandwidth Delegation Response, indicating the currently delegated multicast bandwidth.
R-58帯域幅代表団の入場制御の場合、NASから帯域幅の委任要求を受け取ったときに、特定のアクセスポートの委任マルチキャスト帯域幅を照会するANを照会すると、ANを使用してANを使用して帯域幅の委任応答を送信し、現在委任されているマルチキャスト帯域幅。
R-59 In case of Admission Control with AN Bandwidth Delegation, it may happen that the NAS wants to "revoke" all or part of the delegated bandwidth. Part of the previously delegated bandwidth may however be in use by multicast services. Therefore, upon receiving a Bandwidth Delegation Request from the NAS instructing to decrease the delegated multicast bandwidth on a given Access Port, the AN must support using ANCP to send a Bandwidth Delegation Response, indicating the delegated multicast bandwidth after the decrease (indicating how much of the delegated bandwidth can be returned to the NAS without impacting multicast services that are currently running).
R-59帯域幅代表団を伴う入学制御の場合、NASは委任された帯域幅のすべてまたは一部を「取り消す」ことを望んでいるかもしれません。ただし、以前に委任された帯域幅の一部は、マルチキャストサービスで使用されている場合があります。したがって、NASからの帯域幅の委任要求を受信して、特定のアクセスポートの委任されたマルチキャスト帯域幅を減らすよう指示するように指示すると、ANはANCPを使用して帯域幅の委任応答を送信する必要があります。委任された帯域幅は、現在実行中のマルチキャストサービスに影響を与えることなく、NASに返すことができます）。
R-60 In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to send a Bandwidth Release message to the NAS in order to release unused delegated multicast bandwidth on a given Access Port.
R-60帯域幅の代表団を備えた入場制御の場合、ANはANCPを使用して帯域幅のリリースメッセージを送信して、特定のアクセスポートに使用されていない委任されたマルチキャスト帯域幅をリリースするためにサポートする必要があります。
R-61 If the requested multicast flow is not part of any list associated with the Access Port, the AN must discard the message.
R-61要求されたマルチキャストフローがアクセスポートに関連付けられたリストの一部ではない場合、ANはメッセージを破棄する必要があります。
R-62 If the requested multicast flow is part of multiple lists associated with the Access Port, the AN must use the most specific match.
R-62要求されたマルチキャストフローがアクセスポートに関連付けられた複数のリストの一部である場合、ANは最も特定の一致を使用する必要があります。
R-63 If the requested multicast flow has the same most specific match in multiple lists, the AN must give precedence to the black list, followed by the grey list, and then the white list.
R-63要求されたマルチキャストフローが複数のリストで同じ最も特定の一致を持っている場合、ANはブラックリストに優先され、その後に灰色のリスト、そして白いリストが続きます。
R-64 The AN must support configuring a "catch-all" statement in the black, white, or grey list in order to enforce a default behavior for a join to a multicast flow which doesn't match any other entry in a list for the relevant Access Port.
R-64は、ANが黒、白、またはグレーのリストで「キャッチオール」ステートメントの構成をサポートする必要があります。関連するアクセスポート。
R-65 Upon querying the NAS, the AN must not propagate the join message before the successful authorization from the NAS is received.
R-65 NASを照会すると、ANはNASからの成功した許可を受信する前に参加メッセージを伝播してはなりません。
R-66 Upon receiving a leave for a multicast flow that matches the grey list, the AN should be able to autonomously stop replication and advertise this event to the NAS.
R-66灰色のリストに一致するマルチキャストフローの休暇を受け取ると、ANはレプリケーションを自律的に停止し、このイベントをNASに宣伝できるはずです。
R-67 The AN must support using ANCP to send an Information Report message to the NAS whenever replication starts or ends.
R-67 ANは、ANCPを使用して、複製が開始または終了するたびに情報レポートメッセージをNASに送信する必要があります。
R-68 The AN should support using ANCP to send an Information Report message to the NAS indicating the multicast traffic volume that has been replicated on that port.
R-68 ANは、ANCPを使用してNASに情報レポートメッセージを送信して、そのポートで複製されたマルチキャストトラフィックボリュームを示していることをサポートする必要があります。
R-69 Upon request by the NAS, the AN must support using ANCP to send an Information Report message to the NAS, indicating what multicast flows are currently being replicated on a given Access Port.
R-69 NASからの要求に応じて、ANはANCPを使用してNASに情報レポートメッセージを送信する必要があり、特定のアクセスポートで現在どのマルチキャストフローが複製されているかを示します。
R-70 Upon request by the NAS, the AN must support using ANCP to send an Information Report message to the NAS, indicating what Access Ports are currently receiving a given multicast flow.
R-70 NASがリクエストすると、ANはANCPを使用してNASに情報レポートメッセージを送信する必要があり、現在どのアクセスポートが特定のマルチキャストフローを受信しているかを示します。
R-71 Upon request by the NAS, the AN must support using ANCP to send an Information Report message to the NAS, indicating what multicast flows are currently being replicated on each Access Port.
R-71 NASからの要求に応じて、ANはANCPを使用してNASに情報レポートメッセージを送信する必要があり、各アクセスポートで現在どのマルチキャストフローが複製されているかを示します。
R-72 Upon receiving an Admission Response from the NAS, indicating that replication of a multicast flow is to start or stop on a given access port of the AN, the AN must enforce this decision. This decision must be taken irrespective of whether or not a corresponding Admission Request was issued by the AN earlier.
R-72 NASから入場応答を受信すると、マルチキャストフローの複製がANの特定のアクセスポートで開始または停止することであることを示し、ANはこの決定を強制しなければなりません。この決定は、以前のANが対応する入学要求が発行されたかどうかに関係なく実行する必要があります。
R-73 The Access Node must be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds.
R-73アクセスノードは、数十ミリ秒の大きさでANCP操作を迅速に完了できるように設計する必要があります。
R-74 The Access Node should avoid sending bursts of ANCP messages related to notification of line attributes or line state, by spreading message transmission over time.
R-74アクセスノードは、メッセージの送信を時間の経過とともに広めることにより、行属性またはライン状態の通知に関連するANCPメッセージのバーストを送信しないでください。
Naturally, the Access Node Control Mechanism is not designed to replace an Element Manager managing the Access Node. There are parameters in the Access Node, such as the DSL noise margin and DSL Power Spectral Density (PSD), which are not allowed to be changed via ANCP or any other control session, but only via the Element Manager. This has to be ensured and protected by the Access Node.
当然、アクセスノード制御メカニズムは、アクセスノードを管理する要素マネージャーを置き換えるように設計されていません。DSLノイズマージンやDSLパワースペクトル密度（PSD）など、アクセスノードにはパラメーターがあり、ANCPまたはその他のコントロールセッションを介して変更されませんが、Element Managerを介してのみ変更できます。これは、アクセスノードによって保護され、保護される必要があります。
When using ANCP for access-loop configuration, the EMS needs to configure on the Access Node which parameters may or may not be modified using the Access Node Control Mechanism. Furthermore, for those parameters that may be modified using ANCP, the EMS needs to specify the default values to be used when an Access Node comes up after recovery.
ANCPをアクセスループ構成に使用する場合、EMSはアクセスノードにアクセスノードを構成する必要があります。これは、アクセスノード制御メカニズムを使用してパラメーターを変更する場合と変更できない場合があります。さらに、ANCPを使用して変更される可能性のあるパラメーターの場合、EMSは、回復後にアクセスノードが表示されるときに使用するデフォルト値を指定する必要があります。
R-75 When access-loop configuration via ANCP is required, the EMS must configure on the Access Node which parameter set(s) may be changed/controlled using ANCP.
R-75 ANCPを介したアクセスループ構成が必要な場合、EMSはAccessノードでANCPを使用して変更/制御するパラメーターセットを設定する必要があります。
R-76 Upon receiving an Access Node Control Request message, the Access Node must not apply changes to the parameter set(s) that have not been enabled by the EMS.
R-76アクセスノード制御要求メッセージを受信すると、アクセスノードはEMSによって有効になっていないパラメーターセットに変更を適用してはなりません。
This section lists the requirements for a NAS that supports the use cases defined in this document. Note that this document does not intend to impose absolute requirements on network elements. Therefore, the words "must" and "should" used in this section are not capitalized.
このセクションには、このドキュメントで定義されているユースケースをサポートするNASの要件をリストします。このドキュメントは、ネットワーク要素に絶対要件を課すつもりはないことに注意してください。したがって、このセクションで使用される「必須」と「必要」という言葉は大文字ではありません。
R-77 The NAS must establish ANCP Adjacencies only with authorized ANCP peers.
R-77 NASは、ANCPピアを使用してのみANCPの隣接を確立する必要があります。
R-78 The NAS must support the capability to simultaneously run ANCP with multiple ANs in a network.
R-78 NASは、ネットワーク内の複数のANSを使用してANCPを同時に実行する機能をサポートする必要があります。
R-79 The NAS must be able to establish an Access Node Control Adjacency to a particular partition on an AN and control the access loops belonging to such a partition.
R-79 NASは、AN上の特定のパーティションへのアクセスノード制御隣接を確立し、そのようなパーティションに属するアクセスループを制御できる必要があります。
R-80 The NAS must support obtaining access-loop information (e.g., net data rate), from its peer Access Node partitions via the Access Node Control Mechanism.
R-80 NASは、アクセスノード制御メカニズムを介してピアアクセスノードパーティションから、アクセスループ情報（ネットデータレートなど）の取得をサポートする必要があります。
R-81 The NAS must support shaping traffic directed towards a particular access loop to not exceed the net data rate learned from the AN via the Access Node Control Mechanism.
R-81 NASは、AN VIAアクセスノード制御メカニズムから学習したネットデータレートを超えないように、特定のアクセスループに向けられたトラフィックの形成をサポートする必要があります。
R-82 The NAS should support reducing or disabling the shaping limit used in the Hierarchical Scheduling process, according to per-subscriber authorization data retrieved from a AAA or policy server.
R-82 NASは、AAAまたはポリシーサーバーから取得されたサブスクリバーごとの認可データに従って、階層スケジューリングプロセスで使用される形状の削減または無効化をサポートする必要があります。
R-83 The NAS must support reporting of access-loop attributes learned via the Access Node Control Mechanism to a Policy or AAA Server using RADIUS Vendor-Specific Attributes (VSAs).
R-83 NASは、RADIUSベンダー固有の属性（VSA）を使用して、アクセスノード制御メカニズムまたはAAAサーバーへのアクセスノード制御メカニズムを介して学習したアクセスループ属性のレポートをサポートする必要があります。
R-84 In a TR-059/TR-101 network architecture, the NAS shapes traffic sent to a particular Access Port according to the bitrate available on that port. The NAS should take into account the layer 1 and layer 2 encapsulation overhead on the Access Port, retrieved from the AN via the Access Node Control Mechanism.
R-84 TR-059/TR-101ネットワークアーキテクチャでは、NASは、そのポートで利用可能なビットレートに従って特定のアクセスポートに送信されるトラフィックを形作ります。NASは、アクセスノード制御メカニズムを介してANから取得したアクセスポートのオーバーヘッドのレイヤー1とレイヤー2カプセル化を考慮する必要があります。
R-85 The NAS should support dynamically configuring and reconfiguring discrete service parameters for access loops that are controlled by the NAS. The configurable service parameters for access loops could be driven by local configuration on the NAS or by a policy server.
R-85 NASは、NASによって制御されるアクセスループの離散サービスパラメーターの動的に構成および再構成することをサポートする必要があります。アクセスループ用の構成可能なサービスパラメーターは、NASのローカル構成またはポリシーサーバーによって駆動される可能性があります。
R-86 The NAS should support triggering an AN via the Access Node Control Mechanism to execute local OAM procedures on an access loop that is controlled by the NAS. If the NAS supports this capability, then the following applies:
R-86 NASは、NASによって制御されるアクセスループでローカルOAM手順を実行するために、アクセスノード制御メカニズムを介してANをトリガーすることをサポートする必要があります。NASがこの機能をサポートしている場合、次のことが適用されます。
* The NAS must identify the access loop on which OAM procedures need to be executed by specifying an Access Circuit Identifier (ACI) in the request message to the AN.
* NASは、ANへの要求メッセージにアクセス回路識別子（ACI）を指定することにより、OAM手順を実行する必要があるアクセスループを識別する必要があります。
* The NAS should support processing and reporting of the remote OAM results learned via the Access Node Control Mechanism.
* NASは、アクセスノード制御メカニズムを介して学習したリモートOAM結果の処理と報告をサポートする必要があります。
* As part of the parameters conveyed within the OAM message to the AN, the NAS should send the list of test parameters pertinent to the OAM procedure. The AN will then execute the OAM procedure on the specified access loop according to the specified parameters. In case no test parameters are conveyed, the AN and NAS must use default and/or appropriately computed values.
* OAMメッセージ内でANに伝えられるパラメーターの一部として、NASはOAMプロシージャに関連するテストパラメーターのリストを送信する必要があります。ANは、指定されたパラメーターに従って指定されたアクセスループでOAMプロシージャを実行します。テストパラメーターが伝達されない場合、ANとNASはデフォルトおよび/または適切に計算された値を使用する必要があります。
* After issuing an OAM request, the NAS will consider the request to have failed if no response is received after a certain period of time. The timeout value should be either the one sent within the OAM message to the AN, or the computed timeout value when no parameter was sent.
* OAMリクエストを発行した後、NASは、一定期間後に応答がない場合、リクエストが失敗したと考慮します。タイムアウト値は、OAMメッセージ内でANに送信される値、またはパラメーターが送信されなかったときに計算されたタイムアウト値のいずれかである必要があります。
The exact set of test parameters mentioned above depends on the particular OAM procedure executed on the access loop. An example of a set of test parameters is the number of loopbacks to be performed on the access loop and the timeout value for the overall test. In this case, and assuming an ATM-based access loop, the default value for the timeout parameter would be equal to the number of F5 loopbacks to be performed, multiplied by the F5 loopback timeout (i.e., 5 seconds per the ITU-T I.610 standard).
上記のテストパラメーターの正確なセットは、アクセスループで実行される特定のOAM手順に依存します。一連のテストパラメーターの例は、アクセスループで実行されるループバックの数と、テスト全体のタイムアウト値です。この場合、ATMベースのアクセスループを仮定すると、タイムアウトパラメーターのデフォルト値は、実行されるF5ループバックの数に等しく、F5ループバックタイムアウトを掛けます（つまり、ITU-T Iごとに5秒.610標準）。
R-87 The NAS must treat PPP or DHCP session state independently from any Access Node Control Adjacency state. The NAS must not bring down the PPP or DHCP sessions just because the Access Node Control Adjacency goes down.
R-87 NASは、PPPまたはDHCPセッション状態を、アクセスノード制御隣接状態とは独立して扱う必要があります。NASは、アクセスノード制御隣接が減少するという理由だけで、PPPまたはDHCPセッションを倒してはなりません。
R-88 The NAS should internally treat Access Node Control traffic in a timely and scalable fashion.
R-88 NASは、アクセスノード制御トラフィックをタイムリーでスケーラブルな方法で内部的に処理する必要があります。
R-89 The NAS should support protection of Access Node Control communication to an Access Node in case of line card failure.
R-89 NASは、ラインカードの障害が発生した場合にアクセスノードのアクセスノードへのアクセス制御通信の保護をサポートする必要があります。
R-90 The NAS must mark Access Node Control Protocol messages as high priority (e.g., appropriately set Diffserv Code Point (DSCP), Ethernet priority bits, or ATM Cell Loss Priority (CLP) bit) such that the aggregation network between the NAS and the AN can prioritize the Access Node Control Protocol messages over user traffic in case of congestion.
R-90 NASは、Accessノード制御プロトコルメッセージを高い優先度（たとえば、DiffServコードポイント（DSCP）、イーサネット優先ビット、またはATM細胞損失優先順位（CLP）ビットを適切に設定したものとしてマークする必要があります。ANは、混雑の場合にユーザートラフィックを介したアクセスノード制御プロトコルメッセージに優先順位を付けることができます。
R-91 In case the NAS and Access Node cannot agree on a common set of capabilities, as part of the ANCP capability negotiation procedure, the NAS must report this to network management.
R-91 ANCP機能交渉手順の一部として、NASとAccessノードが共通の機能セットに同意できない場合、NASはこれをネットワーク管理に報告する必要があります。
R-92 The NAS must only commence Access Node Control information exchange and state synchronization with the AN when there is a non-empty common set of capabilities with that AN.
R-92 NASは、アクセスノード制御情報交換とANとの状態同期を開始する必要があります。
R-93 The NAS must support generating an alarm to a management station upon loss or malfunctioning of the Access Node Control Adjacency with the Access Node.
R-93 NASは、アクセスノードを使用したアクセスノード制御隣接の損失または誤動作時に、管理ステーションへのアラームの生成をサポートする必要があります。
R-94 The NAS must support correlating Access Node Control Protocol messages pertaining to a given access loop with subscriber session(s) over that access loop. This correlation must be achieved by either:
R-94 NASは、そのアクセスループを介したサブスクライバーセッションを使用した特定のアクセスループに関連するアクセスノード制御プロトコルメッセージの相関をサポートする必要があります。この相関は、次のいずれかによって達成されなければなりません。
* Matching an Access Circuit Identifier (ACI) inserted by the AN in Access Node Control Protocol messages with the corresponding ACI value received in subscriber signaling (e.g., PPPoE and DHCP) messages as inserted by the AN. The format of ACI is defined in [TR-101]; or
* ANによって挿入されたサブスクライバーシグナル（PPPOEやDHCPなど）メッセージで受信される対応するACI値を使用して、AN IN ACACESノード制御プロトコルメッセージによって挿入されたアクセス回路識別子（ACI）を一致させます。ACIの形式は[TR-101]で定義されています。また
* Matching an ACI inserted by the AN in Access Node Control Protocol messages with an ACI value locally configured for a static subscriber on the NAS.
* NASの静的サブスクライバーに対してローカルに構成されたACI値を使用して、ANアクセスノード制御プロトコルメッセージによって挿入されたACIを一致させます。
R-95 The NAS must support using ANCP to configure multicast conditional access information to Access Ports on an Access Node, using black lists, grey lists, and white lists.
R-95 NASは、ANCPを使用してマルチキャスト条件付きアクセス情報を構成するためにサポートする必要があります。アクセスノードのアクセスポート、黒いリスト、グレーリスト、白いリストを使用してください。
R-96 The NAS must support using ANCP to indicate to the AN whether or not Admission Control is needed for some multicast flows on a given Access Port and where needed whether or not the Access Node is authorized to perform Admission Control itself (i.e., whether or not AN Bandwidth Delegation applies).
R-96 NASは、ANCPを使用してANにサポートして、特定のアクセスポート上のいくつかのマルチキャストフローに入場制御が必要かどうか、およびアクセスノードがAndimment Control自体を実行することを許可されているかどうか（つまり、帯域幅の代表団が適用されない）。
R-97 Upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port, and no AN Bandwidth Delegation is used for that flow, the NAS must be able to perform the necessary checks (conditional access and/or admission control) for the new flow. The NAS must support using ANCP to reply to the AN indicating whether the request is to be honored or denied. This may involve a decision made locally or querying an external system such as a policy server.
R-97マルチキャストフローを特定のアクセスポートに複製するリクエストのためにANからクエリを受信すると、そのフローに帯域幅の代表団が使用されていないため、NASは必要なチェックを実行できる必要があります（条件付きアクセスと/または新しいフローのための入場制御）。NASは、ANCPを使用して、要求が尊重されるか拒否されるかを示すANに返信するためにサポートする必要があります。これには、ローカルで行われた決定またはポリシーサーバーなどの外部システムを照会する決定が含まれる場合があります。
R-98 Upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port, and Admission Control with AN Bandwidth Delegation is used for that flow, the NAS must be able to perform the conditional access checks (if needed), and must support using ANCP to delegate a certain amount of bandwidth to the AN for a given Access Port.
R-98は、特定のアクセスポートにマルチキャストフローを複製するリクエストのためにANからクエリを受信すると、帯域幅の代表団を備えた入場制御がそのフローに使用されます。NASは条件付きアクセスチェックを実行できる必要があります（必要）、およびANCPを使用して、特定のアクセスポートに対して一定量の帯域幅をAに委任する必要があります。
R-99 In case of Admission Control with AN Bandwidth Delegation, upon receiving a Bandwidth Delegation Request from the AN requesting to increase the delegated multicast bandwidth on a given Access Port, the NAS must support using ANCP to send a Bandwidth Delegation Response indicating the new delegating multicast bandwidth.
R-99帯域幅代表団の入場制御の場合、ANから帯域幅の委任要求を受け取ったときに、特定のアクセスポートで委任されたマルチキャスト帯域幅を増やすことを要求すると、NASはANCPを使用して帯域幅の委任応答を送信するためにサポートする必要があります。マルチキャスト帯域幅の委任。
R-100 In case of Admission Control with AN Bandwidth Delegation, the NAS must support using ANCP to send a request to the AN to decrease the amount of multicast bandwidth previously delegated on a given Access Port; the NAS should be able to specify both the minimum and the preferred amount of decrement of multicast bandwidth requested.
R-100帯域幅の代表団を伴う入学制御の場合、NASはANCPを使用してANにリクエストを送信して、特定のアクセスポートに委任されたマルチキャスト帯域幅の量を減らす必要があります。NASは、要求されたマルチキャスト帯域幅の減少の最小値と優先量の両方を指定できるはずです。
R-101 In case of Admission Control with AN Bandwidth Delegation, upon receiving an ANCP Bandwidth Release message, the NAS must be able to update accordingly its view of the multicast bandwidth delegated to the AN.
R-101帯域幅の代表団を伴う入学制御の場合、ANCP帯域幅のリリースメッセージを受信すると、NASはANに委任されたマルチキャスト帯域幅のビューをそれに応じて更新できる必要があります。
R-102 The NAS must support using ANCP to configure the Access Node with the "maximum number of multicast streams" allowed to be received concurrently per Access Port.
R-102 NASは、ANCPを使用して、アクセスポートごとに同時に受信できる「マルチキャストストリームの最大数」でアクセスノードを構成するためにサポートする必要があります。
R-103 The NAS must support using ANCP to incrementally add, remove, and modify individual entries in white, black, and grey lists.
R-103 NASは、ANCPを使用して、個々のエントリを白、黒、灰色のリストに段階的に追加、削除、変更することをサポートする必要があります。
R-104 The NAS must support using ANCP to indicate to the AN whether or not multicast accounting is needed for a multicast flow on a particular Access Port.
R-104 NASは、特定のアクセスポートのマルチキャストフローにマルチキャストアカウンティングが必要かどうかをANに示すためにANCPを使用してサポートする必要があります。
R-105 In case multicast accounting is needed for a multicast flow on a particular Access Port, the NAS should support using ANCP to indicate to the AN whether or not additional volume accounting information is required.
R-105特定のアクセスポートのマルチキャストフローにマルチキャストアカウンティングが必要な場合、NASはANCPを使用してANに追加のボリュームアカウンティング情報が必要かどうかを示す必要があります。
R-106 The NAS must support using ANCP to query the AN to obtain information on what multicast flows are currently replicated on a given Access Port.
R-106 NASは、ANCPを使用してANを照会して、特定のアクセスポートで現在複製されているマルチキャストフローに関する情報を取得するためにサポートする必要があります。
R-107 The NAS must support using ANCP to query the AN to obtain information on what Access Ports are currently receiving a given multicast flow.
R-107 NASは、ANCPを使用してANを照会して、特定のマルチキャストフローを現在受信しているアクセスポートに関する情報を取得するためにサポートする必要があります。
R-108 The NAS must support using ANCP to query the AN to obtain information on what multicast flows are currently replicated on each Access Port.
R-108 NASは、ANCPを使用してANを照会して、各アクセスポートで現在複製されているマルチキャストフローに関する情報を取得する必要があります。
R-109 When Multicast replication occurs on the AN, the NAS must support using ANCP to revoke the authorization to replicate a multicast flow to a particular Access Port.
R-109マルチキャスト複製がANで発生する場合、NASはANCPを使用して特定のアクセスポートにマルチキャストフローを複製する許可を取り消す必要があります。
R-110 The NAS should support using ANCP to indicate to the AN that replication of a multicast flow is to start or stop on a given access port of the AN, without having received a corresponding Admission Request from the AN earlier on.
R-110 NASは、ANCPを使用してANに、マルチキャストフローの複製がANの特定のアクセスポートを起動または停止することを示すことをサポートする必要があります。
R-111 The NAS must be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds.
R-111 NASは、数十ミリ秒の大きさでANCP操作を迅速に完了できるように設計する必要があります。
R-112 The NAS should protect its resources from misbehaving Access Node Control peers by providing a mechanism to dampen information related to an Access Node partition.
R-112 NASは、アクセスノードパーティションに関連する情報を減衰させるメカニズムを提供することにより、アクセスノード制御ピアを誤動作することからリソースを保護する必要があります。
Broadband Forum TR-058 [TR-058], Broadband Forum TR-059 [TR-059], and Broadband Forum TR-101 [TR-101] describe a DSL broadband access architecture and how it enables wholesaling. In such a model, the broadband access provider has a wholesale agreement with one or more service providers. The access provider owns the broadband access network and manages connectivity to the service providers. This allows service providers to provide broadband services to retail customers without having to own the access network infrastructure itself.
ブロードバンドフォーラムTR-058 [TR-058]、ブロードバンドフォーラムTR-059 [TR-059]、およびブロードバンドフォーラムTR-101 [TR-101]は、DSLブロードバンドアクセスアーキテクチャを説明し、どのように卸売りを可能にしますか。このようなモデルでは、ブロードバンドアクセスプロバイダーは、1つ以上のサービスプロバイダーと卸売り契約を結んでいます。アクセスプロバイダーはブロードバンドアクセスネットワークを所有し、サービスプロバイダーへの接続を管理します。これにより、サービスプロバイダーは、アクセスネットワークインフラストラクチャ自体を所有することなく、小売顧客にブロードバンドサービスを提供できます。
When applying the Access Node Control Mechanism to a wholesale network architecture, a number of additional requirements apply.
アクセスノード制御メカニズムを卸売ネットワークアーキテクチャに適用する場合、多くの追加要件が適用されます。
R-113 In case of wholesale access, the network provider's NAS should support reporting of access-loop attributes learned from the AN via the Access Node Control Mechanism (or values derived from such attributes), to a retail provider's network gateway owning the corresponding subscriber(s).
R-113卸売アクセスの場合、ネットワークプロバイダーのNASは、ANから学習したアクセスノード制御メカニズム（またはそのような属性から派生した値）から学習したアクセスループ属性のレポートをサポートする必要があります。（s）。
R-114 In case of Layer 2 Tunneling Protocol (L2TP) wholesale, the NAS must support a proxy architecture that gives different providers conditional access to dedicated Access Node Control resources on an Access Node.
R-114レイヤー2トンネルプロトコル（L2TP）卸売の場合、NASは、アクセスノードの専用アクセスノード制御リソースへの異なるプロバイダーに条件付きアクセスを提供するプロキシアーキテクチャをサポートする必要があります。
R-115 The NAS when acting as an L2TP Access Concentrator (LAC) must communicate generic access-line-related information to the L2TP Network Server (LNS) in a timely fashion.
R-115 L2TPアクセス濃縮器（LAC）として機能する場合は、一般的なアクセスライン関連情報をL2TPネットワークサーバー（LNS）にタイムリーに通知する必要があります。
R-116 The NAS when acting as a LAC may asynchronously notify the LNS of updates to generic access-line-related information.
R-116 NASは、LACとして機能する場合、一般的なアクセスライン関連情報に対する更新のLNSに非同期に通知する場合があります。
This section lists the management-related requirements for the AN and NAS. Note that this document does not intend to impose absolute requirements on network elements. Therefore, the words "must" and "should" used in this section are not capitalized.
このセクションには、ANとNASの管理関連の要件をリストします。このドキュメントは、ネットワーク要素に絶対要件を課すつもりはないことに注意してください。したがって、このセクションで使用される「必須」と「必要」という言葉は大文字ではありません。
R-117 It must be possible to configure the following parameters on the Access Node and the NAS:
R-117アクセスノードとNASで次のパラメーターを構成することが可能である必要があります。
* Parameters related to the Control Channel transport method: these include the VPI/VCI and transport characteristics (e.g., VBR-RT or Constant Bitrate (CBR)) for ATM networks, or the C-VLAN ID, S-VLAN ID, and p-bit marking for Ethernet networks;
* 制御チャネル輸送方法に関連するパラメーター：これらには、ATMネットワークのVPI/VCIおよび輸送特性（VBR-RTまたは一定のビットレート（CBR））、またはC-VLAN ID、S-VLAN ID、およびP-が含まれます。イーサネットネットワークのビットマーキング。
* Parameters related to the Control Channel itself: these include the IP address of the IP interface on the Access Node and the NAS.
* 制御チャネル自体に関連するパラメーター：これらには、アクセスノードとNAS上のIPインターフェイスのIPアドレスが含まれます。
R-118 When the operational status of the Control Channel is changed (up>down, down>up) a linkdown/linkup trap should be sent towards the EMS. This requirement applies to both the AN and the NAS.
R-118制御チャネルの動作ステータスが変更された場合（> up> down> up）、リンクダウン/リンクアップトラップをEMSに向けて送信する必要があります。この要件は、ANとNASの両方に適用されます。
R-119 The Access Node must provide the possibility using SNMP to associate individual DSL lines with specific Access Node Control Adjacencies.
R-119アクセスノードは、SNMPを使用して個々のDSLラインを特定のアクセスノード制御隣接に関連付ける可能性を提供する必要があります。
R-120 The Access Node must notify the EMS of configuration changes made by the NAS on the AN using ANCP, in a timely manner.
R-120アクセスノードは、ANSPを使用してNASが行った構成変更のEMSにタイムリーに通知する必要があります。
R-121 The Access Node must provide a mechanism that allows the concurrent access on the same resource from several managers (EMS via SNMP, NAS via ANCP). Only one manager may perform a change at a certain time.
R-121アクセスノードは、複数のマネージャー（SNMPを介したEMS、ANCPを介してNAS）からの同じリソースの同時アクセスを可能にするメカニズムを提供する必要があります。特定の時間に変更を行うことができるマネージャーは1人だけです。
R-122 The ANCP may provide a notification mechanism to inform the NAS about configuration changes done by an EMS, in a timely manner. This applies only to changes of parameters that are part of the use case "Access-Loop Configuration" (Section 3.2).
R-122 ANCPは、EMSによって行われた構成の変更についてタイムリーに通知するための通知メカニズムを提供する場合があります。これは、ユースケース「アクセスループ構成」の一部であるパラメーターの変更にのみ適用されます（セクション3.2）。
[RFC5713] lists the ANCP-related security threats that could be encountered on the Access Node and the NAS. It develops a threat model and identifies requirements for ANCP security, aiming to decide which security functions are required at the ANCP level.
[RFC5713]は、アクセスノードとNASで発生する可能性のあるANCP関連のセキュリティの脅威をリストしています。脅威モデルを開発し、ANCPセキュリティの要件を特定し、ANCPレベルで必要なセキュリティ関数を決定することを目指しています。
With multicast handling as described in this document, ANCP protocol activity between the AN and the NAS is triggered by join/leave requests coming from the end-user equipment. This could potentially be used for denial-of-service attacks against the AN and/or the NAS.
このドキュメントで説明されているマルチキャスト処理により、ANとNASの間のANCPプロトコルアクティビティは、エンドユーザー機器からの結合/休暇要求によってトリガーされます。これは、ANおよび/またはNASに対するサービス拒否攻撃に使用される可能性があります。
This is not a new class of risk over already possible IGMP messages sent from subscribers to the NAS when the AN uses no IGMP snooping, and thus is transparent as long as processing of ANCP messages on the NAS/AN is comparably efficient and protected against congestion.
これは、ANがIGMPスヌーピングを使用しない場合に加入者からNASに送信されるすでに可能なIGMPメッセージに対する新しいクラスのリスクではありません。。
To mitigate this risk, the AN MAY implement control-plane protection mechanisms such as limiting the number of multicast flows a given user can simultaneously join, or limiting the maximum rate of join/ leave from a given user.
このリスクを軽減するために、ANは、特定のユーザーが同時に結合することができるマルチキャストフローの数を制限するなどの制御面保護メカニズムを実装したり、特定のユーザーからの結合/休暇を制限することができます。
We also observe that an operator can easily deploy some protection against attacks using invalid multicast flows by taking advantage of the mask-based match in the black list. This way, joins for invalid multicast flows can be denied at the AN level without any ANCP protocol interactions and without NAS involvement.
また、オペレーターは、ブラックリストのマスクベースの一致を利用することにより、無効なマルチキャストフローを使用して攻撃に対する保護を簡単に展開できることも観察します。このようにして、無効なマルチキャストフローの結合は、ANCPプロトコルの相互作用やNASの関与なしにANレベルで拒否される可能性があります。
R-123 The ANCP MUST comply with the security requirements spelled out in RFC 5713.
R-123 ANCPは、RFC 5713で説明されているセキュリティ要件に準拠する必要があります。
R-124 The Access Node MUST NOT allow the sending of Access Node Control Messages towards the customer premises.
R-124アクセスノードは、顧客の施設にアクセスノード制御メッセージを送信することを許可してはなりません。
The authors would like to thank everyone that has provided comments or input to this document. In particular, the authors acknowledge the work done by the contributors to the activities related to the Broadband Forum: Jerome Moisand, Wojciech Dec, Peter Arberg, and Ole Helleberg Andersen. The authors also acknowledge the inputs provided by Roberta Maglione, Angelo Garofalo, Francois Le Faucheur, and Toerless Eckert regarding multicast. Finally, the authors thank Bharat Joshi, Stefaan De Cnodder, Kirubaharan Dorairaj, Markus Freudenberger, Fortune Huang, and Lothar Reith for providing comments.
著者は、このドキュメントへのコメントや入力を提供したすべての人に感謝したいと思います。特に、著者は、ブロードバンドフォーラムに関連する活動に貢献した作業を認めています。著者はまた、マルチキャストに関するロベルタ・マグリオーネ、アンジェロ・ガロファロ、フランソワ・ル・フォーシュール、およびToerless Eckertが提供するインプットを認めています。最後に、著者は、コメントを提供してくれたBharat Joshi、Stefaan de Cnodder、Kirubaharan Doriaraj、Markus Freudenberger、Fortune Huang、Lothar Reithに感謝します。
[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月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684] Grossman、D。およびJ. Heinanen、「ATM適応層5に対するマルチプロトコルカプセル化」、RFC 2684、1999年9月。
[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月。
[RFC894] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", STD 41, RFC 894, April 1984.
[RFC894] Hornig、C。、「イーサネットネットワークを介したIPデータグラムの送信の標準」、STD 41、RFC 894、1984年4月。
[TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL Aggregation", Broadband Forum TR-101, May 2006.
[TR-101] Cohen、A。およびE. Shrum、「イーサネットベースのDSL凝集への移行」、ブロードバンドフォーラムTR-101、2006年5月。
[G.993.2] ITU-T, "Very high speed digital subscriber line transceivers 2 (VDSL2)", ITU-T Rec. G.993.2, Feb 2006.
[G.993.2] ITU-T、「非常に高速デジタルサブスクライバーライントランシーバー2（VDSL2）」、ITU-T Rec。G.993.2、2006年2月。
[G.997.1] ITU-T, "Physical layer management for digital subscriber line (DSL) transceivers", ITU-T Rec. G.997.1, Sep 2005.
[G.997.1] ITU-T、「デジタルサブスクライバーライン（DSL）トランシーバーの物理層管理」、ITU-T Rec。G.997.1、2005年9月。
[RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[RFC2225] Laubach、M。and J. Halpern、「Classical IP and ARP Over ATM」、RFC 2225、1998年4月。
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364] Gross、G.、Kaycee、M.、Lin、A.、Malis、A。、およびJ. Stephens、「PPP Over AAL5」、RFC 2364、1998年7月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516] Mamakos、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPをイーサネット上に送信する方法」、RFC 2516、2月1999年。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[RFC2881] Mitton、D。およびM. Beadles、「ネットワークアクセスサーバー要件次世代（NasReqng）NASモデル」、RFC 2881、2000年7月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[TR-058] Elias, M. and S. Ooghe, "Multi-Service Architecture & Framework Requirements", Broadband Forum TR-058, September 2003.
[TR-058] Elias、M。およびS. Ooghe、「マルチサービスアーキテクチャとフレームワークの要件」、ブロードバンドフォーラムTR-058、2003年9月。
[TR-059] Anschutz, T., "DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", Broadband Forum TR-059, September 2003.
[TR-059] Anschutz、T。、「DSL Evolution- QOS対応IPサービスのサポートのためのアーキテクチャ要件」、ブロードバンドフォーラムTR-059、2003年9月。
[TR-147] Voigt, N., Ooghe, S., and M. Platnic, "Layer 2 Control Mechanism For Broadband Multi-Service Architectures", Broadband Forum TR-147, November 2008.
[TR-147] Voigt、N.、Ooghe、S。、およびM. Platnic、「ブロードバンドマルチサービスアーキテクチャのレイヤー2制御メカニズム」、ブロードバンドフォーラムTR-147、2008年11月。
Authors' Addresses
著者のアドレス
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerpen Belgium
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerpen Belgium
Phone: +32 3 240 42 26
EMail: sven.ooghe@alcatel-lucent.com
Norbert Voigt Nokia Siemens Networks Siemensallee 1 17489 Greifswald Germany
Norbert Voigt Nokia Siemens Networks Siemensallee 1 17489 Greifswaldドイツ
Phone: +49 3834 555 771 EMail: norbert.voigt@nsn.com Michel Platnic ECI Telecom 30 Hasivim Street 49517 Petakh Tikva Israel
電話：49 3834 555 771メール：norbert.voigt@nsn.com Michel Platnic ECI Telecom 30 Hasivim Street 49517 Petakh Tikva Israel
Phone: + 972 54 33 81 567
EMail: mplatnic@gmail.com
Thomas Haag Deutsche Telekom Heinrich-Hertz-Strasse 3-7 64295 Darmstadt Germany
Thomas Haag Deutsche Telekom Heinrich-Hertz-Strasse 3-7 64295 Darmstadtドイツ
Phone: +49 6151 628 2088
EMail: haagt@telekom.de
Sanjay Wadhwa Juniper Networks 10 Technology Park Drive Westford, MA 01886 US
Sanjay Wadhwa Juniper Networks 10 Technology Park Drive Westford、MA 01886 US
Phone: EMail: swadhwa@juniper.net
電話：電子メール：swadhwa@juniper.net