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.
この文書は、第1のアクセスノード制御機構が適切であり得るためのユースケースの数を識別する。これは、プロトコルの設計時に考慮しなければならないアクセスノード制御プロトコル（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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]のようないくつかの文書は、これらのアクセスネットワークのための可能なアーキテクチャについて説明します。これらの仕様の範囲は、音声、ビデオ、およびデータサービスの提供から構成されています。このドキュメントによって定義されたフレームワークは、（ATM / DSLによって、またはイーサネット（登録商標）/ 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上に構成された第1の層3デバイス（例えば、ブロードバンドリモートアクセスサーバ（BRAS））で終端されています。データプレーンの横に、モデル要素、ネットワーク、およびサービス管理のためのアーキテクチャを定義します。管理面でのインターワーキングがあるため、IPネットワークを操作するローカル・ループを操作する部署、ATMネットワークを動作部門、および部門間の組織の境界を常に可能ではありません。また、管理ネットワークは通常、リアルタイムで異なるエンティティ間の管理データを送信するように設計されていません。
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））サービスに関連する操作を実行するためにマルチサービス参照アーキテクチャでは、品質とアクセスノード制御機構が必要とされていますサービス、および加入者。アクセスノード制御機構は、情報の送信は、個別要素マネージャを介してなく直接デバイス・デバイス通信を使用してむしろ行く必要がないことを保証します。これは、既存のOSSesへの影響を回避しながら、これらのネットワーク要素内のアクセス・リンクに関連する操作を実行することを可能にします。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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ネットワーク・アクセス・サーバ（NAS）：アクセスノードの数からの多重化加入者トラフィックを集約するネットワークデバイス。 NASは、加入者ごとのポリシーの施行及びサービス品質（QoS）において中心的な役割を果たしています。多くの場合、ブロードバンドネットワークゲートウェイ（BNG）またはブロードバンドリモートアクセスサーバ（BRAS）と呼ばれます。 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
O「正味データレート」：ユーザー情報（例えば、ATMセルまたはイーサネットフレーム）を送信するために使用することができる総データレートの部分、セクション3.39、すなわち、ITU-T G. 993.2 [G. 993.2]によって定義されます。これは、物理的な伝送機構（例えば、トレリスDSLの場合に符号化）に関連するオーバーヘッドを排除します。それは、
TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 64/65 encapsulation.
TPS-TC（トランスポートプロトコルは、特定 - 送信収束）カプセル化。これは64/65カプセル化のためのATMカプセル化、および非ゼロはゼロです。
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つのまたは複数のANおよび1台のまたは複数のNASの間で制御情報を拡張可能通信方式を持つ複数のネットワークシナリオのための方法。
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の間の関係。隣接関係は、アクセスノード制御隣接プロトコルの動作の結果に応じて、上下のいずれであってもよいです。
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]で、「参加」とは、異なるフィルタモード変更（ASM）とSource-一覧-変更レコードを使用して、「メンバーシップ・レポート」を通じて示されています。
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まま：それはマルチキャストフローの受信を停止することを望むユーザ機器からのシグナリング。 、「去る」とは、異なるフィルタモード変更（ASM）を使用して、「IGMPv3メンバシップレポート」を通じてメッセージを示され、ソース・リスト・変更レコードされたIGMPv3の中にいる間はIGMPv2では、これは、「リーブ・グループ」のメッセージ内に搬送されます。
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).
ホームゲートウェイ（HGW）は、アクセスノードとアクセスネットワークに異なる顧客宅内機器（CPE）を接続します。 DSLの場合には、HGWは、レイヤ2ブリッジとしてまたはレイヤ3ルータとして動作することができるいずれかのDSLネットワーク終端（NT）です。後者の場合には、そのようなデバイスはまた、ルーティングゲートウェイ（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のは、）、（[RFC894]で定義され、イーサネットオーバーIP（IPoEで））IP架橋覆い、（[RFC2225]で定義され、ATMオーバーIP（IPOA））IPルーテッド。これに続いて、[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.
アクセスノード（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.
このドキュメントによって定義されたフレームワークは、（ATM / DSLによって、またはイーサネット（登録商標）/ DSLなどのいずれか）DSLベースのアクセスを対象としています。フレームワークは、受動光ネットワーク（PONの）および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へのトラフィック集約を提供します。アグリゲーション技術は、（TR-059のアーキテクチャの場合）またはATM（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.
イーサネットフレームのためのトランスポート・インタフェース（例えば、ギガビットイーサネット（ギガビットイーサネット）、同期光ネットワーク上のイーサネット（SONETによるネットワークアクセスサーバ（NAS）標準ATMまたはイーサネットインターフェイスによってアグリゲーションネットワークへのインターフェイス、および地域ネットワークに向かって））。 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.).
地域ネットワークは、ネットワークサービスプロバイダ（NSPの）およびアプリケーション・サービス・プロバイダ（ASP）への1台のまたは複数のNASおよび関連するアクセスネットワークを接続しています。 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セルの損失を回避または最小化されるように、これらのATM PVCは、次に高い優先順位を与えられます。これは、ルートにそのVPは、ベストエフォート型のQoSクラス（例えば、未指定ビットレート（UBR））で構成されている場合にも、顧客の接続を運ぶ仮想パス（VP）内のアクセスノード制御プロトコルメッセージを落胆されます。複数のアクセスノード制御隣接関係のPVCは高い優先順位を与えられ、集約ネットワークを介して実行されているVPに集約することができます。これは、VCのVPを終端集約ノードでクロスコネクトの存在を必要とします。
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）を介してアクセスノード制御プロトコルメッセージを送信することです。これは、アクセスノードとするための1つのサービスVLAN（S-VLAN）ごとに各アクセスノードごとに異なるVLAN IDを使用して達成、または、多くのアクセス・ノードと凝集度の高いネットワークでは、1つの顧客VLAN（C-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.
アクセスノード制御メカニズムを使用して、NASは、加入者に関連するパラメータの数を取得し、制御します。それはパラメータを追跡し、それらにポリシーを適用できるように、NASは、中央のポリシーまたはAAAサーバにこの情報を通信するように決定することができます。 Serverは、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は、一般的にNAS-ポートID、NAS-ポート、またはRADIUSサーバ（複数可）に送信されたRADIUS認証およびアカウンティングパケットでCalling-Station-Idアトリビュートを含んでいます。そのような属性は、アクセス・ループを識別する順番にでき、この加入者のATM VCの識別を含みます。
In an Ethernet-based aggregation network, a new addressing scheme is defined in [TR-101]. Two mechanisms can be used:
イーサネットベースのアグリゲーションネットワークにおいて、新たなアドレス指定スキームは[TR-101]で定義されています。 2つのメカニズムが使用できます。
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.
最初のアプローチoをすべてのアクセスポート（例えば、DSLポート）とアクセスポート上の回路（例えば、ADSLポートのATM PVC）のための一対一のVLAN割当モデルを使用することです。これは、直接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のアプローチは、多対一VLAN割り当てモデルを使用して、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、ネットワーク資源の有効活用のために許可します。むしろ、それだけでアクセスノードでドロップするアグリゲーションネットワークを通過させるよりも早い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アップリンクの容量）、それにもかかわらず、厳密にアップリンクの実際の容量とBRASはそれを持っている画像との間の同期を維持する必要が変化します。
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のシステムは、典型的には、組織の境界を越え、信頼性と拡張性の高い方法でそのようなデータの一貫性を強制するために設計されていません。アクセストポロジ検出機能は、NASは、OSSシステムとの統合に依存することなく、これらの機能を実行できるようにするためのものです。
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)
DSLアクセスループ（すなわち、正味データレート）の同定および速度（データレート）O
o The identification and speed (data rate) of the Remote Terminal (RT) / Access Node uplink (when relevant)
リモート端末（RT）/アクセスノードのアップリンク（関連）のO識別および速度（データレート）
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 [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.
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プロファイルは）エレメントマネージャは、アクセスノードを管理することにより、事前に設定されています。 NASは、アクセス・ノードへの権利プロファイルへの参照を送信する設定要求メッセージを使用することができます。 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.
アクセス・ループ構成メカニズムは、アクセス・ループ技術に固有ではないパラメータの設定のために有用である可能性があります。例としては、アクセス・ノードは、IGMPスヌーピングまたはIGMPプロキシ機能を実行しているIPTVアプリケーションに使用されるアクセス・ループのために使用されるQoSプロファイル、またはごとの加入マルチキャストチャネル資格情報を含みます。後者はまた、セクション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回路はBRASとDSLAMまたはDSL NT間のポイントツーポイント接続です。レイヤ2、適切な運用、管理、および保守（OAM）機能上の接続をテストするために動作し、トラブルシューティングのために使用されます。エンドツーエンドOAMループバックは、ブロードバンドアクセスネットワークのエッジ装置（NASとHGW）との間で行われます。
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で指定されるように）アクセス・ループ接続テストおよび障害分離を提供することができます。しかし、ほとんどのHGWsはまだこれらの標準のイーサネットOAMの手続きをサポートしていません。されている、または異なる標準団体で標準化されている自分のリンク・ベースのOAMメカニズムを有し、また、様々なアクセス技術は、例えば、等ファーストマイル（EFM）これらのアクセス技術の各々におけるATM / DSL、イーサネット（登録商標）として存在します。
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ベースのアーキテクチャで使用されるような接続性をテストし、トラブルシューティングするために同じ方法を維持することが望ましいです。エンドツーエンドのイーサネットOAMメカニズムがより広く利用可能になるまでATMベースのアプローチとの整合性に到達するために、NASとアクセスノードとの間のアクセスノード制御機構を使用することができます。
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.
ATMアクセス/アグリゲーション・ネットワークの場合には、ブロードバンドフォーラム[TR-059]で指定された参照アーキテクチャのような、マルチキャストトラフィックの複製は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は、効率的なマルチキャストレプリケーション用のANにレプリケーション状態を作成するためにANCPを使用することができます。 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.
マルチキャスト条件付きアクセスが必要な場合はANはその後、自律的に、条件付きアクセス決定を行うことができますので、それがANに必要な条件付きアクセス情報いくつかのケースでは、提供することが可能です。 ANが参加または参加尊重しないことを称えるために局部的に決めることができるように、これらの例では、NASが提供するANに必要な情報をANCPを使用することができます。これは、制御要求と制御応答メッセージで行うことができます。
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).
要求されたマルチキャストフローは、白色、灰色の部分、又はそのアクセスポートに関連付けられたブラックリストである場合は、アクセスポートで加入メッセージを受信すると、アクセス・ノードは、最初のチェックであろう。それはホワイトリストの一部である場合、ANは、自律的にマルチキャストトラフィックを複製開始します。それはブラックリストの一部である場合、ANは、要求が許可されていないため、自律メッセージを破棄し、したがって、NASに通知し、それに応じて要求をログに記録することができます。それは、グレーリストの一部である場合ANは、順番に参加を光栄する（したがって、ANによって行わ複製）するかどうかを示すANに応答したり、拒否された（それゆえ行われていない複製することを、NASを照会するANCPを使用しています）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 = *>）を追加しても、リストには他の試合を持っていないマルチキャストフローのためのJoinメッセージを受け入れるようにデフォルトの動作になるだろう。デフォルトの動作は、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>);
（*、G）ASMグループのためのマスクベースの範囲の一致O（例えば、<G = g.h.i.l /マスク>）。
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>);
（S、G）SSMチャネルのためのマスクベースの範囲の一致O（例えば、<S = s.t.u.v /マスク、G = g.h.i.l /マスク>）。
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：（1 <= iが= Nを<）に参加（S = *、G = GI）を除いて、すべてのメッセージを拒否
* 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シナリオ3：ANは、いくつかのチャンネルの自律的意思決定を行い、他のチャネルのためのNASを要求
* 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
*グレーリスト= {<S = Sで、G = Gmの>} M> Nのために
* black list = {<S=*,G=*>}
*ブラックリスト= {<S = *、G = *>}
* ==> Join (S=*,G=Gi) gets honored by AN (1<=i<=n)
* ==>参加（S = *、G = Giは）ANによって表彰されます（1 <= iが= N <）
* ==> Join (S=s,G=Gm) triggers ANCP Admission Request to NAS
* ==>（S = sで、G = GM）参加NASにANCP許可要求をトリガ
* ==> everything else gets rejected by AN
* ==>他のすべては、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.
ホワイトリストとブラックリストの使用は（例えば、DSL）加入者を広帯域するためにアクセス・プロバイダによって提供される定期的なIPTVサービス（すなわち、放送TV）に、例えば、適用することができます。この用途のために、IPTVサブスクリプションは、典型的には、特定のDSL回線に結合され、およびサブスクリプションの一部でマルチキャストフローは、予め周知です。それらは、サブスクリプションにバインドされているので、条件付きアクセス情報への変更は、まれです。したがって、アクセスノードは、IPTVサービスに関連する条件付きアクセス情報をプロビジョニングすることができます。
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またはPolicy Serverによって取られて、条件付きアクセスの決定を有することが望ましいです。これは、条件付きアクセス情報は頻繁に変更、又はマルチキャストグループが事前にクライアントアプリケーションに知られていない場合場合であってもよいです。条件付きアクセス制御は、例えば、時間帯アクセス、ロケーションベースのアクセス、より複雑なポリシー/許可機構に接続することができ、またはリモート認証サーバを起動します。これらのケースについては、ANは、順番に参加を拒否または光栄（ひいてはANによって行わ複製）するかどうかを示すANに応答するNASを照会するANCPを使用することができます。これは、アドミッション要求と入場応答メッセージで行うことができます。
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「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の組み合わせに参加するユーザの要求を尊重する前に、アクセス回線上で特に入場コントロールを考慮すると（アクセス回線を介して送信され、他のすべてのマルチキャストおよびユニキャストビデオストリームに加えて）ストリーム。溶液は、アクセスラインごとに複数の流れに対処する必要があり、アクセス回線の帯域幅が動的マルチキャストとユニキャストトラフィック（ユニキャスト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をサポートする（例えば、NASまたはAN）、ユニキャストCAC（例えば、ポリシーサーバ）を実行するエンティティ、およびエンティティが実際にマルチキャストレプリケーションを強制マルチキャスト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.
アクセス回線のためにそのアドミッション制御は、NASによって、またはNAS経由ANと対話するポリシーサーバによって実行されるように、ANは、NASを照会するためにO一つのアプローチはあります。 ANは、順番に新しいマルチキャストフローのためのマルチキャストアドミッション制御チェックを実行し、参加を拒否または光栄（ひいてはANによって行わ複製）するかどうかを示すANに応答することをNASを照会するANCPを使用することができます。 NASは、ローカル（ユニキャストまたはマルチキャスト）ビデオフローのために利用可能であるアクセス・ループ正味データレートの部分を追跡し、アクセス・ループを占めるビデオ帯域幅を実行することができます。 ANから入場要求を受信すると、NASは、マルチキャストフローの認否の前に利用可能なアクセス・ループ帯域幅を確認することができます。プロセスでは、NASは、ポリシーサーバと通信することができます。それはユニキャストフローに対するアドミッション制御を実行し、残りの利用可能なアクセスを更新できるように、そのようなビデオオンデマンド（VOD）として、ユニキャストビデオサービスの場合、NASはまた、（ポリシーサーバによってまたはオンパスCACシグナリングを介して）照会することができます-loop帯域幅。このアプローチをサポートするための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を使用してANにレプリケーション状態を設定することができます。ユニキャストビデオサービスの場合、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.
アクセス回線のためのユニキャストとマルチキャストの両方のCACは、ANによって実行されるように、O最後のアプローチでは、ポリシーサーバは、NASを介して直接的または間接的にANを問い合わせます。この場合には、ユニキャストフロー（例えば、オンデマンドセッションにビデオ）に対する加入者の要求は、ポリシーサーバに向けてリソース要求メッセージをトリガします。後者は、その後、ユニキャスト要求が光栄または拒否されるべきかどうかを示す、順番にアクセス回線のためのユニキャストCACを実行し、応答すること、（おそらくNASを介して）ANを照会します。上記のモデルは、「認可の委任」の概念を強化することができました。このようなモデルでは、アクセス・ノードへのポリシーサーバを委任権限はアクセスループ上のマルチキャストアドミッション制御を実行します。ポリシーサーバが直接ANを照会する場合には、アプローチがANCPを使用する必要はありません。したがって、このドキュメントの範囲を超えています。ポリシーサーバは、NASを介して間接的ANを問い合わせる場合に、アプローチは、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は、アドミッション制御は、与えられたアクセスポート上の特定のマルチキャストフローのために必要とされているかどうかをANに示すためにANCPを使用しています。場合はアドミッション制御が必要とされ、アクセス・ノードは、（で「委任」、すなわち、どのくらいの帯域幅が、アドミッション制御自体を実行する権限があるかどうかを知る必要がありますと、もしそうなら、そうすることを許可されている境界、その中NASまたはポリシーサーバ）。マルチキャストフローの種類に応じて、アドミッション制御はまたはでANによって行われていない場合があります。アクセスノードによって実行される条件付きアクセス操作を必要とするマルチキャストフローが黒または白のリストに入れているoを。また、アクセス・ノードは、そうすることを認可されているホワイトリストでこれらのフローのためのアドミッション制御を行います。
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.
NASまたはポリシーサーバによって実行される条件付きアクセス操作を必要とするマルチキャストフローO、グレーリストに入れています。また、アクセス・ノードは、アドミッション制御を実行すべき対象のグレーリストでこれらのフローのために、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は、追加の委任マルチキャスト帯域幅を要求するためにNASを照会するANCPを使用することができます。これは、アドミッション制御を実行するためにANの承認を拡張する形です。 NASまたはポリシーサーバは、より多くの帯域幅の要求を満たすことができる場合を決定し、更新委任マルチキャスト帯域幅を示すANへの応答を送信するためにANCPを使用しています。この場合には、手続きを完了するのにかかる時間は、ザッピング遅延の増加分であることは注目に値します。要求された追加のマルチキャスト帯域幅の最小量と好ましい追加量：参加要求を将来のためにザッピング遅延を最小限に抑えるために、ANは、要求メッセージ内の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は、マルチキャスト帯域幅の量を減少させるために、ANを照会するANCPを使用（または指示する）ことができます以前に与えられたアクセスポートに委任。これは、アドミッション制御を実行する権限を引き出す/制限の形です。 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は、以前に委任された未使用のマルチキャスト帯域幅の一部のすべてを解放するためにNASにメッセージを送信するためにANCPを使用することができます。このプロセスでは、アクセスノードは、マルチキャストサービスのための帯域幅の最小量を保持するように決定することができます。
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.
未知のストリームのアドミッションコントロールを無効にするアクセスノードホワイトリストまたはグレーリストに「キャッチオール声明」を追加することによって達成することができます。場合、アクセス・ノードは、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は、ベストエフォートとして提供されることはありませんサービスの一例であるが、サービスの品質保証のいくつかのレベルが必要です。これは、マルチキャストアドミッションコントロールを使用する必要があります。アクセス・ノードが自律的に入場処理を実行したい場合したがって、それはマルチキャストフローの帯域幅特性を認識する必要があります。そうでない場合は、アクセス・ノードは、（グレーリストの動作ごとに）マルチキャストアドミッション制御のためのNASを照会する必要があります。これは、白と黒のリストを使用しての目的を台無しにしてしまいます。
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;
ANは、中央会計システムに送信する前に、所定のマルチキャストフローがスタートのための複製または指定されたアクセスポートに終了したときを追跡し、時間および/またはアクセスポートあたりおよびマルチキャストフローごとのボリュームベースの課金情報を生成し、oをロギング用。 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は、NASへのANからの情報を送信するために使用することができます。これは、このドキュメントの残りの部分で説明します。
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に通知するだけでなく。これは、レプリケーションの終了時に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によって複製マルチキャストフローに関連する瞬時の状況報告を取得するために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マルチキャストフローが現在アクセスポートの各々上で送信されている（すなわち、一つのアクセスノードのグローバルレポート）
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.
動的マルチキャストフローの複製を停止する機能は、さまざまなシナリオに役立つことができます。たとえば利用可能なクレジットの有効期限が切れたプリペイドサービスの場合には、サービスプロバイダは、のために指定されたアクセスポート上のマルチキャストレプリケーションを停止できるようにしたい場合があります特定のユーザー。この場合には、マルチキャストコンテンツは、単に一定の時間のために配信されます。この機能の適用の別の例は、サービスプロバイダは、「コンテンツのプレビュー」を表示したいと思いシナリオです。
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アドミッション要求以外の手段によるマルチキャストフローを残すために、エンドユーザの要求を認識して行うことができます。このモデルは、アクセス・ノードは、IGMPは（それらがトンネリングされているので、例えば、）エンドユーザーからのメッセージを残す/参加処理しない場合で適用されますが、NASに転送する一つの可能な展開シナリオ。そのような環境では、NAS（すなわち、対応する許可要求の前に受領することなく、NASによって送信された）自発入場応答の使用を介してANCPを介してANにマルチキャスト複製を制御することができます。
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（これは例えば、PONアクセスノード、DSLAM異なるアクセスノードの使用を含む）は、現在、本書で取り上げたものを超えて使用事例をサポートするために新しいメッセージタイプの定義またはTLVを介して容易に拡張可能でなければなりません。
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ザ・アクセスノード制御相互作用は、（アクセスノード制御プロトコルメッセージのために、または信頼性がANCPを設計することにより、信頼性の高いトランスポートプロトコル（例えば、TCP）のいずれかを使用して）信頼できるものでなければなりません。
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.
NASは、アクセスノードからの情報を要求するための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は、少なくとも5000個のアクセスノードを制御するために与えられたNASを可能にするのに十分にスケーラブルでなければなりません。
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マルチキャストフローは、特定のアクセスポートに複製することができるか否かを示す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がANは、予め与えられたアクセスポートに委任帯域幅の量を減らすために照会する（又は指示する）を許可しなければなりません。
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は、NASは、マルチキャスト会計は、特定のアクセスポート上のマルチキャストフローのために必要とされているかどうかを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は、アクセス・ノードは、自然状態のNAS変化と通信するための「レポート」モデルを含むべきです。
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).
レイヤ2トランスポート技術はATMに基づいている場合、R-35、次いで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).
レイヤ2トランスポート技術は、イーサネット（登録商標）に基づいている場合、R-36、次いで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.
このセクションでは、この文書で定義されたユースケースをサポートしていANための要件を示します。この文書は、ネットワーク要素上の絶対的な要件を課すことを意図していないことに注意してください。したがって、このセクションで使用される「はずです」、「しなければならない」という言葉は資産ではありません。
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の間で動作するように定義されます。いくつかのケースでは、一方のANは、（例えば、場合に異なるホールセールサービスプロバイダが異なるNAS装置を有する）複数の物理NASデバイスに接続することができます。このようなモデルでは、物理的なANは、それぞれが独自のアクセスノード制御報告および/または執行機能を備え、仮想のANに分割する必要があります。
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つのパーティションに一意に割り当てなければなりません。
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ザ・アクセス・ノードは、優先度の高い（例えば、可変ビットレート - リアルタイム（VBR-RT）ATMセルのため、イーサネットパケットのためのpビット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ネットワークアーキテクチャでは、ANを識別するアクセス回線識別子（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はその参加が光栄または拒否されるべきかどうかを示す応答を受信するNASを照会するANCPの使用をサポートしなければならないため、マルチキャストフローに加入受信します。この場合、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は、その参加は光栄するか拒否するかどうかを示す応答を受け取るためにNASを照会するANCPを使用してサポートしている必要があります。
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は、ユーザがマルチキャストフローを離れるときに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は、与えられたアクセスポートの追加委任マルチキャストの帯域幅を要求するためにNASを照会するANCPを使用してサポートしている必要があります。 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の帯域幅委任とアドミッション制御の場合には、指定されたアクセスポートに委任マルチキャスト帯域幅のためにANを照会NASからの帯域委任要求を受信すると、ANは示し、帯域幅委任応答を送信するANCPの使用をサポートしなければなりません現在、委任マルチキャスト帯域幅。
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は、与えられたアクセスポート上の未使用の委任マルチキャスト帯域幅を解放するために、NASへの帯域幅のリリースメッセージを送信するために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は、NASたび、複製開始または終了に情報レポートメッセージを送信するためにANCPを使用してサポートしている必要があります。
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は、そのポートに複製されたマルチキャストトラフィック量を示すNASに情報レポートメッセージを送信するためにANCPを使用してサポートする必要があります。
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は、マルチキャストフローが現在与えられたアクセスポートに複製されているかを示す、NASに情報レポートメッセージを送信するためにANCPを使用してサポートしている必要があります。
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は、ポートは現在、特定のマルチキャストフローを受信しているかを示すアクセス、NASへの情報レポートメッセージを送信するためにANCPを使用してサポートしている必要があります。
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は、マルチキャストフローが現在各アクセスポートで複製されているかを示す、NASに情報レポートメッセージを送信するANCPの使用をサポートしなければなりません。
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.
当然のことながら、アクセスノード制御機構は、アクセス・ノードを管理するエレメントマネージャを置き換えるために設計されていません。こうしただけエレメントマネージャを経由して、ANCPまたは任意の他の制御セッションを介して変更することが許可されていないDSLのノイズマージンおよびDSLパワースペクトル密度（PSD）、などのアクセスノードのパラメータがあります。これは、アクセス・ノードによって確保し、保護する必要があります。
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.
ANCPを介してアクセスループ構成が必要な場合、R-75、EMSは、パラメータ・セット（単数または複数）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によって有効化されていないパラメータセット（S）に変更を適用してはなりません。
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は同時に、ネットワーク内の複数のANと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から学ん超えないように、特定のアクセスループに向けたトラフィックを形作るサポートしている必要があります。
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.
* 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.
* ANへOAMメッセージ内で運ばパラメータの一部として、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は、応答が一定期間後に受信されない場合、要求は失敗したとみなします。タイムアウト値は、ANにOAMメッセージ内で送信された一つ又はパラメータが送信されなかった計算されたタイムアウト値のいずれかであるべきです。
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秒0.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は、高優先度としてアクセスノード制御プロトコルメッセージ（例えば、適切に設定Diffservのコードポイント（DSCP）、イーサネット優先ビット、またはATMセル廃棄優先（CLP）ビット）をマークしなければならないようにNASの間に集約ネットワークと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 NASおよびアクセス・ノードは、機能の共通セットに同意することはできません場合は、ANCPの能力交渉手順の一部として、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.
その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
* 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はアドミッション制御は、所定のアクセスポート上のいくつかのマルチキャストフローのために必要とされているか否かをANに示すためにANCPを使用して、どこでアクセスノードがアドミッションコントロール自体（すなわち、実行を許可されているかどうかを必要に応じて、かどうかをサポートしなければなりませんかない帯域幅委任）が適用されます。
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.
特定のアクセスポートにマルチキャストフローを複製する要求をANからクエリを受信するとR-97、およびNO AN帯域幅委任がそのフローのために使用されていない、NASは、必要なチェックを実行することができなければならない（条件付きアクセスおよび/またはまたは新しいフローのためのアドミッション制御）。 NASは、要求が光栄か拒否するかどうかを示すANに返信するANCPを使用してサポートしている必要があります。これは、ポリシーサーバとしてローカルまたは外部のシステムを検索判断を伴うことがあります。
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は、（もし条件付きアクセス・チェックを実行することができなければなりません）必要に応じて、与えられたアクセスポートのためのANに一定量の帯域幅を委任するANCPを使用してサポートしている必要があります。
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は、以前に与えられたアクセスポートに委任マルチキャスト帯域幅の量を減少させるためにANに要求を送信するためにANCPを使用してサポートしている必要があります。 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帯域Releaseメッセージを受信すると、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は、追加のボリューム課金情報が必要であるか否かをANに示すためにANCPの使用をサポートしなければなりません。
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は、現在、所与のアクセスポートで複製されたマルチキャストどのフローに関する情報を取得するためにANを照会するANCPの使用をサポートしなければなりません。
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は現在、特定のマルチキャストフローを受信しているかアクセスポートに関する情報を取得するためにANを照会するANCPを使用してサポートしている必要があります。
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は現在、各アクセスポート上で複製されているマルチキャストどのようなフローに関する情報を取得するためにANを照会するANCPを使用してサポートしている必要があります。
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.
マルチキャスト複製はANに発生するとR-109は、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はマルチキャストフローの複製は、以前にANから対応する許可要求を受信したことなく、ANの所与のアクセスポートで起動または停止することをANに示すためにANCPの使用をサポートしなければなりません。
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).
小売プロバイダのネットワークゲートウェイは、対応する加入者を所有し、アクセスノード制御機構（またはそのような属性から導出される値）を介してANから学習R-113卸売アクセスの場合には、ネットワークプロバイダのNASは、アクセス・ループ属性の報告をサポートしなければなりません（複数可）。
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ザNAS 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;
* 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制御チャネルの動作状態が（>上下>上下に）変更されたリンクダウン/リンクアップトラップが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ザ・アクセス・ノードは、特定のアクセスノード制御隣接関係を有する個々のDSL回線を関連付けるためにSNMPを使用する可能性を提供しなければなりません。
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ザ・アクセス・ノードは、タイムリーに、AN使用ANCPに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ザ・アクセス・ノードは、いくつかのマネージャ（ANCPを介してSNMP、NASを介してEMS）から同じリソースに同時アクセスを可能にするメカニズムを提供しなければなりません。唯一の管理者は、特定の時間に変更を行うことができます。
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によって行われた構成変更についてNASに通知する通知メカニズムを提供してもよいです。これは、ユースケース「アクセス・ループの設定」（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 / AN上のANCPメッセージの処理が比較的効率的で、輻輳から保護限り透明であるとき、加入者から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の関与なしレベルで拒否することができますのためにこの方法では、参加します。
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
作者はこのドキュメントへのコメントや入力を提供してきたすべての人に感謝したいと思います。ジェロームMoisand、ヴォイチェフ12月、ピーターアーベルク、およびOLE Hellebergアンデルセン：特に、著者はブロードバンドフォーラムに関連する活動への貢献者によって行われた仕事を認めています。著者らはまた、ロベルタマリオーネ、アンジェロ・ガロファロ、フランソワ・ル・Faucheurが提供する入力を認識し、
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エッカート。最後に、著者はコメントを提供するためのバーラト・ジョシ、StefaanデCnodder、Kirubaharan Dorairaj、マルクスFreudenberger、フォーチュン黄、およびローターReithの感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]グロスマン、D.とJ. Heinanen、RFC 2684、1999年9月 "ATMアダプテーションレイヤ5以上のマルチプロトコルカプセル化"。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5713] Moustafa、H.、Tschofenig、H.、およびS.デCnodder、 "アクセスノード制御プロトコルのためのセキュリティの脅威とセキュリティ要件（ANCP）"、RFC 5713、2010年1月。
[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]コーエン、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勧告。 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.
[997.1] ITU-T、ITU-T REC "デジタル加入者線（DSL）送受信機のための物理層管理"。 997.1、2005年9月。
[RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[RFC2225]ラウバッハ、M.及びJ.アルペルン、 "古典IPおよびATM上ARP"、RFC 2225、1998年4月。
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364]グロス、G.、Kaycee、M.、リン、A.、Malis、A.、およびJ.スティーブンス、 "PPPオーバー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.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[RFC2881]ミトン、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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "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]エリアス、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]アンシュッツ、T.、 "DSL進化 - 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]フォークト、N.、Ooghe、S.、およびM. Platnic、 "ブロードバンドマルチサービスアーキテクチャ用のレイヤ2制御機構"、ブロードバンドフォーラムTR-147、2008年11月。
Authors' Addresses
著者のアドレス
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerpen Belgium
スヴェンOogheアルカテル・ルーセントCopernicuslaan 50 B-2018アントワープ、ベルギー
Phone: +32 3 240 42 26 EMail: sven.ooghe@alcatel-lucent.com
電話：+32 3 240 42 26 Eメール：sven.ooghe@alcatel-lucent.com
Norbert Voigt Nokia Siemens Networks Siemensallee 1 17489 Greifswald Germany
ノルベルト・フォークトノキアシーメンスネットワークスSiemensallee 1 17489グライフスヴァルト、ドイツ
Phone: +49 3834 555 771 EMail: norbert.voigt@nsn.com
電話：+49 3834 555 771 Eメール：norbert.voigt@nsn.com
Michel Platnic ECI Telecom 30 Hasivim Street 49517 Petakh Tikva Israel
ミシェルplatinikテレコムAC 30 hasivimストリート49517 petyak tikvaイスラエル
Phone: + 972 54 33 81 567 EMail: mplatnic@gmail.com
電話：+ 972 54 33 81 567 Eメール：mplatnic@gmail.com
Thomas Haag Deutsche Telekom Heinrich-Hertz-Strasse 3-7 64295 Darmstadt Germany
トーマス・ハーグドイツテレコム・ハインリッヒ・ヘルツ・シュトラーセ3-7 64295ダルムシュタットドイツ
Phone: +49 6151 628 2088 EMail: haagt@telekom.de
電話：+49 6151 628 2088 Eメール：haagt@telekom.de
Sanjay Wadhwa Juniper Networks 10 Technology Park Drive Westford, MA 01886 US
サンジャイWadhwaジュニパーネットワークスの10テクノロジーパークドライブウェストフォード、マサチューセッツ州01886米国
Phone: EMail: swadhwa@juniper.net
電話番号：Eメール：swadhwa@juniper.net