[要約] RFC 7256は、ANCPのためのマルチキャスト制御拡張機能に関する規格です。このRFCの目的は、ANCPを使用してアクセスノードでマルチキャストトラフィックを制御するための拡張機能を提供することです。
Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 7256 R. Maglione
Updates: 6320 Cisco
Category: Standards Track T. Taylor
ISSN: 2070-1721 Huawei
July 2014
Multicast Control Extensions for the Access Node Control Protocol (ANCP)
Access Node Control Protocol（ANCP）のマルチキャスト制御拡張
Abstract
概要
This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities:
このドキュメントでは、アクセスノードコントロールプロトコルフレームワークドキュメント（RFC 5851）で定義されているマルチキャストユースケースのサポートに必要なアクセスノードコントロールプロトコル（ANCP）（RFC 6320）の拡張と、このドキュメントで説明されている1つの追加のユースケースについて説明します。これらの使用例は、次のANCP機能に編成されています。
o multicast replication initiated by the Network Access Server (NAS);
o ネットワークアクセスサーバー（NAS）によって開始されるマルチキャストレプリケーション。
o conditional access and admission control with white and black lists;
o ホワイトリストとブラックリストによる条件付きアクセスとアドミッションコントロール。
o conditional access and admission control with grey lists;
o グレーリストによる条件付きアクセスとアドミッションコントロール。
o bandwidth delegation; and
o 帯域幅の委任;そして
o committed bandwidth reporting.
o コミットされた帯域幅レポート。
These capabilities may be combined according to the rules given in this specification.
これらの機能は、この仕様で規定されている規則に従って組み合わせることができます。
This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.
このドキュメントでは、機能タイプ3をこのドキュメントで指定された機能に割り当て、IETFコンセンサスによって決定された結果コードのIANA割り当ての開始点を0x100から0x64に変更することにより、RFC 6320を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 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/rfc7256.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2を参照してください。このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/infoで入手できます。 / rfc7256。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
1.1. A Note on Scope ............................................7
2. Terminology .....................................................7
3. Multicast Use Cases .............................................7
3.1. NAS-Initiated Multicast Replication Control Use Case .......8
3.1.1. Goals ...............................................8
3.1.2. Message Flow ........................................9
3.2. Conditional Access and Admission Control Use Case ..........9
3.2.1. Goals ...............................................9
3.2.2. Message Flow .......................................10
3.3. Multicast Flow Reporting Use Case .........................11
3.3.1. Goals ..............................................11
3.3.2. Message Flow .......................................11
3.4. Committed Bandwidth Reporting Use Case ....................11
3.4.1. Goals ..............................................11
3.4.2. Message Flow .......................................12
4. ANCP Messages ..................................................13
4.1. Provisioning Message ......................................13
4.1.1. Sender Behavior ....................................14
4.1.2. Receiver Behavior ..................................14
4.2. Port Management Message ...................................15
4.2.1. Sender Behavior ....................................16
4.2.2. Receiver Behavior ..................................16
4.3. Multicast Replication Control Message .....................17
4.3.1. Sender Behavior ....................................21
4.3.2. Receiver Behavior ..................................21
4.4. Multicast Admission Control Message .......................24
4.4.1. Sender Behavior ....................................25
4.4.2. Receiver Behavior ..................................26
4.5. Bandwidth Reallocation Request Message ....................27
4.5.1. Sender Behavior ....................................28
4.5.2. Receiver Behavior ..................................28
4.6. Bandwidth Transfer Message ................................31
4.6.1. Sender Behavior ....................................32
4.6.2. Receiver Behavior ..................................32
4.7. Delegated Bandwidth Query Request Message .................34
4.7.1. Sender Behavior ....................................34
4.7.2. Receiver Behavior ..................................34
4.8. Delegated Bandwidth Query Response Message ................34
4.8.1. Sender Behavior ....................................35
4.8.2. Receiver Behavior ..................................35
4.9. Multicast Flow Query Request and Response Messages ........36
4.9.1. Sender Behavior ....................................36
4.9.2. Receiver Behavior ..................................37
4.10. Committed Bandwidth Report Message .......................38
4.10.1. Sender Behavior ...................................38
4.10.2. Receiver Behavior .................................39
5. ANCP TLVs For Multicast ........................................39
5.1. Multicast-Service-Profile TLV .............................39
5.2. Multicast-Service-Profile-Name TLV ........................41
5.3. List-Action TLV ...........................................41
5.4. Sequence-Number TLV .......................................44
5.5. Bandwidth-Allocation TLV ..................................45
5.6. White-List-CAC TLV ........................................45
5.7. MRepCtl-CAC TLV ...........................................46
5.8. Bandwidth-Request TLV .....................................46
5.9. Request-Source-IP TLV .....................................47
5.10. Request-Source-MAC TLV ...................................48
5.11. Request-Source-Device-Id TLV .............................48
5.12. Multicast-Flow TLV .......................................49
5.13. Report-Buffering-Time TLV ................................50
5.14. Committed-Bandwidth TLV ..................................51
6. Multicast Capabilities .........................................51
6.1. Required Protocol Support .................................52
6.1.1. Protocol Requirements for NAS-Initiated
Multicast Replication ..............................52
6.1.2. Protocol Requirements for Committed
Multicast Bandwidth Reporting ......................54
6.1.3. Protocol Requirements for Conditional
Access and Admission Control with White
and Black Lists ....................................55
6.1.4. Protocol Requirements for Conditional
Access and Admission Control with Grey Lists .......56
6.1.5. Protocol Requirements for Bandwidth Delegation .....57
6.2. Capability-Specific Procedures for Providing
Multicast Service .........................................57
6.2.1. Procedures for NAS-Initiated Multicast
Replication ........................................58
6.2.2. Procedures for Committed Bandwidth Reporting .......58
6.2.3. Procedures for Conditional Access and
Admission Control with Black and White Lists .......59
6.2.4. Procedures for Conditional Access and
Admission Control with Grey Lists ..................61
6.2.5. Procedures for Bandwidth Delegation ................63
6.3. Combinations of Multicast Capabilities ....................64
6.3.1. Combination of Conditional Access and
Admission Control with White and Black Lists
and Conditional Access and Admission Control
with Grey Lists ....................................64
6.3.2. Combination of Conditional Access and
Admission Control with Bandwidth Delegation ........65
6.3.3. Combination of NAS-Initiated Replication
with Other Capabilities ............................65
6.3.4. Combinations of Committed Bandwidth
Reporting with Other Multicast Capabilities ........66
7. Miscellaneous Considerations ...................................66
7.1. Report Buffering Considerations ...........................66
7.2. Congestion Considerations .................................67
8. Security Considerations ........................................67
9. IANA Considerations ............................................69
10. Acknowledgements ..............................................72
11. References ....................................................73
11.1. Normative References .....................................73
11.2. Informative References ...................................73
Appendix A. Example of Messages and Message Flows ................75
A.1. Provisioning Phase ........................................75
A.2. Handling Grey-Listed Flows ................................81
A.3. Handling White-Listed Flows ...............................87
A.4. Handling of Black-Listed Join Requests ....................92
A.5. Handling of Requests to Join and Leave the On-Line Game ...92
A.6. Example Flow for Multicast Flow Reporting .................95
[RFC5851] defines a framework and requirements for an Access Node (AN) 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 QoS-related, service-related, and subscriber-related operations. [RFC6320] specifies a protocol for Access Node Control in broadband networks in line with this framework.
[RFC5851]は、ネットワークアクセスサーバー（NAS）とアクセスノード（たとえば、デジタル加入者線アクセスマルチプレクサー（DSLAM））間のアクセスノード（AN）制御メカニズムのフレームワークと要件を、マルチサービスリファレンスアーキテクチャで定義します。 QoS関連、サービス関連、および加入者関連の操作を実行するためのオーダー。 [RFC6320]は、このフレームワークに沿ったブロードバンドネットワークでのアクセスノード制御のプロトコルを指定します。
[RFC6320] supports, specifically for DSL access, three use cases defined in [RFC5851]: the Topology Discovery use case, the Line Configuration use case, and the Remote Connectivity Test use case. However, it does not support the multicast use cases defined in [RFC5851]. The present document specifies the extensions to the Access Node Control Protocol required for support of these multicast use cases. In addition, it supports the Committed Bandwidth Reporting use case, described below. In terms of ANCP, these use cases are organized into five capabilities:
[RFC6320]は、特にDSLアクセスについて、[RFC5851]で定義されている3つのユースケースをサポートしています。トポロジディスカバリのユースケース、ライン構成のユースケース、およびリモート接続テストのユースケースです。ただし、[RFC5851]で定義されているマルチキャストの使用例はサポートしていません。このドキュメントでは、これらのマルチキャストの使用例をサポートするために必要なAccess Node Control Protocolの拡張について説明します。さらに、以下で説明するCommitted Bandwidth Reportingの使用例もサポートしています。 ANCPの観点から、これらの使用例は5つの機能に編成されています。
o NAS-initiated multicast replication;
o NASが開始するマルチキャスト複製。
o conditional access and admission control with white and black lists;
o ホワイトリストとブラックリストによる条件付きアクセスとアドミッションコントロール。
o conditional access and admission control with grey lists;
o グレーリストによる条件付きアクセスとアドミッションコントロール。
o bandwidth delegation; and
o 帯域幅の委任;そして
o committed bandwidth reporting.
o コミットされた帯域幅レポート。
NAS-initiated multicast replication assumes that multicast join and leave requests are terminated on the NAS or that the NAS receives requests to establish multicast sessions through other means (e.g., application-level signaling). The NAS sends commands to the AN to start or stop replication of specific multicast flows on specific subscriber ports. This use case is described briefly in the next-to-last paragraph of Section 3.4 of [RFC5851].
NASが開始するマルチキャストレプリケーションは、NASでマルチキャスト参加および脱退要求が終了するか、NASが他の手段（たとえば、アプリケーションレベルのシグナリング）を通じてマルチキャストセッションを確立する要求を受信することを前提としています。 NASはコマンドをANに送信して、特定の加入者ポートで特定のマルチキャストフローの複製を開始または停止します。この使用例は、[RFC5851]のセクション3.4の最後から2番目の段落で簡単に説明されています。
Conditional access is described in Section 3.4.1 of [RFC5851]. Section 3.4.2.2 of [RFC5851] mentions a way in which conditional access can be combined with admission control to allow best-effort multicast flows, and Section 3.4.2.3 points out the necessary conditions for using both conditional access and admission control.
条件付きアクセスについては、[RFC5851]のセクション3.4.1で説明されています。 [RFC5851]のセクション3.4.2.2は、条件付きアクセスをアドミッション制御と組み合わせてベストエフォートマルチキャストフローを可能にする方法を述べており、セクション3.4.2.3は、条件付きアクセスとアドミッション制御の両方を使用するために必要な条件を指摘しています。
In the case of "conditional access and admission control with white and black lists", multicast join and leave requests are terminated at the AN and accepted or ignored in accordance with the direction provided by white and black lists, respectively. The white and black lists are provisioned per port at startup time and may be modified thereafter. The NAS may combine conditional access with admission control of white-listed flows by appropriate provisioning.
「ホワイトリストとブラックリストを使用した条件付きアクセスとアドミッションコントロール」の場合、マルチキャストの参加要求と脱退要求はANで終了し、ホワイトリストとブラックリストの指示に従ってそれぞれ受け入れられるか無視されます。ホワイトリストとブラックリストは、起動時にポートごとにプロビジョニングされ、その後変更できます。 NASは、適切なプロビジョニングにより、条件付きアクセスとホワイトリストフローのアドミッションコントロールを組み合わせることができます。
Conditional access and admission control with grey lists is similar to conditional access and admission control with white lists, except that before accepting any request matching a grey list entry, the AN sends a request to the NAS for permission to replicate the flow. Again, the NAS can enable admission control of grey-listed flows at the AN.
グレーリストを使用した条件付きアクセスとアドミッションコントロールは、ホワイトリストを使用した条件付きアクセスとアドミッションコントロールに似ていますが、グレイリストエントリに一致するリクエストを受け入れる前に、ANがリクエストをNASに送信して、フローを複製するための許可を求めます。この場合も、NASは、ANでグレーリストのフローのアドミッション制御を有効にすることができます。
Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851]. It allows flexible sharing of total video bandwidth on an access line between the AN and the NAS. One application of such bandwidth sharing is where the AN does multicast admission control, while the NAS or Policy Server does unicast admission control. In that case, bandwidth delegation allows dynamic sharing of bandwidth between unicast and multicast video traffic on each access line.
帯域幅の委任については、[RFC5851]のセクション3.4.2.1で説明されています。これにより、ANとNASの間のアクセス回線でビデオ帯域幅全体を柔軟に共有できます。このような帯域幅共有の1つのアプリケーションは、ANがマルチキャストアドミッション制御を実行する一方で、NASまたはポリシーサーバーがユニキャストアドミッション制御を実行する場合です。その場合、帯域幅の委任により、各アクセス回線上のユニキャストビデオトラフィックとマルチキャストビデオトラフィック間で帯域幅を動的に共有できます。
Committed bandwidth reporting is described in Section 3.4. The AN reports the amount of multicast bandwidth it has granted to a given access line each time that value changes. These reports may be buffered for a NAS-provisionable interval so that reports for multiple access lines can be bundled into the same message.
コミットされた帯域幅のレポートについては、セクション3.4で説明しています。 ANは、値が変化するたびに、所定のアクセス回線に許可したマルチキャスト帯域幅の量を報告します。これらのレポートは、NASでプロビジョニング可能な間隔でバッファリングされるため、複数のアクセス回線のレポートを同じメッセージにまとめることができます。
The formal specification of the behaviors associated with each of these capabilities, singly and in combination, is given in Section 6.
これらの各機能に関連付けられた動作の正式な仕様は、単独で、または組み合わせて、セクション6に記載されています。
In addition to the multicast service processing behavior just sketched, the definition of each capability includes support for the multicast accounting and reporting services described in Section 3.4.3 of [RFC5851]. Because of this common content and because of other protocol overlaps between the different capabilities, the protocol descriptions for the multicast extensions specified in this document are merged into a single non-redundant narrative. Tables in Section 6 then indicate the specific sub-sections of the protocol description that have to be implemented to support each capability.
スケッチしたばかりのマルチキャストサービス処理動作に加えて、各機能の定義には、[RFC5851]のセクション3.4.3で説明されているマルチキャストアカウンティングおよびレポートサービスのサポートが含まれています。この共通の内容と、異なる機能間で他のプロトコルが重複しているため、このドキュメントで指定されているマルチキャスト拡張のプロトコルの説明は、1つの非冗長な説明にマージされています。セクション6の表は、各機能をサポートするために実装する必要があるプロトコルの説明の特定のサブセクションを示しています。
This document updates RFC 6320 by assigning capability type 3 to the NAS-initiated multicast replication capability and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.
このドキュメントでは、機能タイプ3をNASが開始するマルチキャストレプリケーション機能に割り当て、IETFコンセンサスによって決定された結果コードのIANA割り当ての開始点を0x100から0x64に変更することにより、RFC 6320を更新します。
The requirements in [RFC5851] were formulated with the IPTV application in mind. Two basic assumptions underlie the use case descriptions:
[RFC5851]の要件は、IPTVアプリケーションを考慮して策定されました。ユースケースの説明の基礎となる2つの基本的な仮定：
o that the Home Gateway operates in bridged mode, and
o ホームゲートウェイがブリッジモードで動作すること。
o that multicast signaling uses IGMP ([RFC2236] [RFC3376]) or Multicast Listener Discovery (MLD) [RFC3810] rather than PIM [RFC4601].
o そのマルチキャストシグナリングは、PIM [RFC4601]ではなく、IGMP（[RFC2236] [RFC3376]）またはマルチキャストリスナーディスカバリ（MLD）[RFC3810]を使用します。
Without the first assumption the AN may lose sight of individual subscriber devices making requests for multicast service. This has a very minor effect on the capabilities described below but prevents the application of per-device policies at the NAS. Changing the second assumption would require that, in applications where the AN is responsible for snooping IGMP and MLD, it now also monitors for PIM signaling. The capabilities described in the present document do not depend explicitly on what type of multicast signaling is used, but the multiple phases of PIM setup could add complexity to their implementation.
最初の想定がなければ、ANは、マルチキャストサービスを要求する個々の加入者デバイスを見失う可能性があります。これは、以下で説明する機能にはほとんど影響しませんが、NASでのデバイスごとのポリシーの適用を妨げます。 2番目の仮定を変更するには、ANがIGMPおよびMLDのスヌーピングを担当するアプリケーションでは、PIMシグナリングも監視する必要があります。本書で説明する機能は、使用されるマルチキャストシグナリングのタイプに明示的に依存するものではありませんが、PIMセットアップの複数のフェーズにより、実装が複雑になる可能性があります。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the terms "connection admission control" ("CAC" or simply "admission control") and "conditional access" as they are used in [RFC5851].
このドキュメントでは、[RFC5851]で使用されている「接続アドミッション制御」（「CAC」または単に「アドミッション制御」）および「条件付きアクセス」という用語を使用します。
The expression "delegated bandwidth" is used as a shorter way of saying: "the total amount of video bandwidth delegated to the AN for multicast admission control".
「委任された帯域幅」という表現は、「マルチキャストアドミッション制御のためにANに委任されたビデオ帯域幅の総量」という短い言い方で使用されます。
Quoting from [RFC5851]:
[RFC5851]からの引用：
... 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の間で必要な情報を交換することにより、アクセスノード制御メカニズムを使用して、この論理的/機能的同等性が確実に達成されるようにすることができます。
[RFC5851] describes the use cases for ANCP associated with such multicast operations and identifies the associated ANCP requirements. This section describes a subset of these use cases as background to facilitate reading of this document, but the reader is referred to [RFC5851] for a more exhaustive description of the ANCP multicast use cases. Detailed example message flows can also be found in Appendix A.
[RFC5851]は、そのようなマルチキャスト操作に関連するANCPの使用例を説明し、関連するANCP要件を識別します。このセクションでは、このドキュメントを読みやすくするための背景として、これらの使用例のサブセットについて説明しますが、ANCPマルチキャストの使用例の詳細については、[RFC5851]を参照してください。メッセージフローの詳細な例は、付録Aにもあります。
In the diagrams below, participation of the Home Gateway is optional, depending on whether it is operating in bridged or routed mode. Note that devices behind the Home Gateway may require the Home Gateway to operate in routed mode to ensure that they can obtain access to non-IPTV multicast services.
以下の図では、ホームゲートウェイがブリッジモードで動作しているか、ルーテッドモードで動作しているかに応じて、ホームゲートウェイの参加はオプションです。ホームゲートウェイの背後にあるデバイスは、非IPTVマルチキャストサービスへのアクセスを確実に取得できるように、ホームゲートウェイをルーテッドモードで動作させる必要がある場合があります。
One option for multicast handling is for the subscriber to communicate the join/leave information to the NAS. This can be done, for instance, by terminating all subscriber IGMP ([RFC3376]) or MLD ([RFC2710] [RFC3810]) 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 uses ANCP to create and remove replication state in the AN for efficient multicast replication. Thus, the NAS only sends a single copy of the multicast stream towards the AN, which, in turn, performs replication to multiple subscribers as instructed by the NAS via ANCP. The NAS performs conditional access and admission control when processing multicast join requests and only creates replication state in the AN if admission succeeds.
マルチキャスト処理の1つのオプションは、加入者が参加/脱退情報をNASに通信することです。これは、たとえば、NASですべてのサブスクライバーIGMP（[RFC3376]）またはMLD（[RFC2710] [RFC3810]）シグナリングを終了することによって実行できます。別の例としては、NASにリダイレクトされる、なんらかの形式のアプリケーションレベルシグナリングを使用するサブスクライバがあります。いずれの場合も、このオプションはアクセスおよび集約ネットワークに対して透過的です。このシナリオでは、NASはANCPを使用してANでレプリケーション状態を作成および削除し、効率的なマルチキャストレプリケーションを実現します。したがって、NASはANに向けてマルチキャストストリームの単一のコピーのみを送信し、ANCPを介してNASの指示に従って複数のサブスクライバにレプリケーションを実行します。 NASは、マルチキャスト参加要求の処理時に条件付きアクセスとアドミッション制御を実行し、アドミッションが成功した場合にのみ、ANにレプリケーション状態を作成します。
With the NAS-initiated use case, a Multicast Replication Control message is sent by the NAS to the AN with a directive to either join or leave one (or more) multicast flow(s). In the example message flow, the AN uses a Generic Response message to convey the outcome of the directive. Figure 1 illustrates such an ANCP message exchange as well as the associated AN behavior.
NASが開始するユースケースでは、マルチキャストレプリケーションコントロールメッセージは、1つ（または複数）のマルチキャストフローに参加または脱退するディレクティブを使用して、NASからANに送信されます。メッセージフローの例では、ANはGeneric Responseメッセージを使用して、ディレクティブの結果を伝えます。図1は、このようなANCPメッセージ交換と関連するANの動作を示しています。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | (*)
| | | Multicast-Replication-Ctl |
| | | (Target, add, Flow 1) |
| | |<--------------------------|
| Mcast Flow 1 | |
|<===========+==============+ |
| | | Generic Response |
| | |-------------------------->|
| | | |
| | | |
~ ~ ~ ~
| | | |
| | | Multicast-Replication-Ctl |
| | | (Target,delete, Flow 1) |
| | |<--------------------------|
| | | |
| <Stop Replication of X |
| Mcast Flow 1> | Generic Response |
| | |-------------------------->|
(*) The NAS may optionally seek direction from an external Authorization/Policy Server before admitting the flow.
（*）NASはオプションで、フローを許可する前に外部の承認/ポリシーサーバーから指示を求めることができます。
Figure 1: NAS-Initiated Multicast Replication Control
図1：NASが開始するマルチキャストレプリケーションコントロール
One option for multicast handling is for the access/aggregation nodes to participate in IGMP/MLD processing (e.g., via IGMP/MLD snooping). In this scenario, on detecting a join/leave request from an end user for a multicast flow (in the grey list), the AN uses ANCP to request a conditional access and admission control decision from the NAS. In turn, after conditional access and admission control checks, the NAS uses ANCP to instruct the AN to change the replication states accordingly.
マルチキャスト処理の1つのオプションは、アクセス/集約ノードがIGMP / MLD処理に（たとえば、IGMP / MLDスヌーピングを介して）参加することです。このシナリオでは、（グレーリストの）マルチキャストフローに対するエンドユーザーからの参加/脱退要求を検出すると、ANはANCPを使用して、NASに条件付きアクセスとアドミッション制御の決定を要求します。次に、条件付きアクセスおよびアドミッションコントロールチェックの後、NASはANCPを使用して、それに応じてレプリケーション状態を変更するようANに指示します。
For support of the conditional access and admission control use case, on detection of an IGMP/MLD join request, the AN sends a Multicast Admission Control message to the NAS to request a conditional access and admission control check. In the case of a positive outcome, the NAS sends a Multicast Replication Control message to the AN with a directive to replicate the multicast flow to the corresponding user. Similarly, on detection of an IGMP/MLD leave, a Multicast Admission Control message is sent by the AN to the NAS to keep the NAS aware of user departure for the flow. This message flow is illustrated in Figure 2.
条件付きアクセスおよびアドミッションコントロールの使用例をサポートするために、IGMP / MLD加入要求を検出すると、ANはマルチキャストアドミッションコントロールメッセージをNASに送信して、条件付きアクセスおよびアドミッションコントロールチェックを要求します。肯定的な結果の場合、NASは、対応するユーザーにマルチキャストフローを複製するように指示するマルチキャスト複製制御メッセージをANに送信します。同様に、IGMP / MLDの離脱を検出すると、マルチキャストアドミッションコントロールメッセージがANからNASに送信され、フローに対するユーザーの離脱をNASに認識させます。このメッセージフローを図2に示します。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,add,Gr-Flow1) |
| | |-------------------------->|
| | | (*)
| | | Multicast-Replication-Crl |
| | | (Target,add,Gr-Flow1) |
| | |<--------------------------|
| Mcast Gr-Flow1 | |
|<===========+===========+ |
| | | |
~ ~ ~ ~
| | | |
| Leave(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,delete,Gr-Flow1) |
| | |-------------------------->|
| <Stop Replication of X |
| Mcast Gr-Flow1> | |
| | | |
Gr-Flow1: a multicast flow matching the grey list for that port
Gr-Flow1：そのポートのグレーリストに一致するマルチキャストフロー
(*) The NAS may optionally seek direction from an external Authorization/Policy Server before admitting the flow.
（*）NASはオプションで、フローを許可する前に外部の承認/ポリシーサーバーから指示を求めることができます。
Figure 2: Multicast Conditional Access and Admission Control
図2：マルチキャスト条件付きアクセスとアドミッションコントロール
The multicast flow reporting use case allows the NAS to asynchronously query the AN to obtain an instantaneous status report related to multicast flows currently replicated by the AN.
マルチキャストフローレポートの使用例では、NASがANに非同期でクエリを実行して、ANによって現在複製されているマルチキャストフローに関連する瞬時のステータスレポートを取得できます。
The NAS sends a Multicast Flow Query Request message to the AN in order to query the AN about information such as which multicast flows are currently active on a given AN port or which ports are currently replicating a given multicast flow. The AN conveys the requested information to the NAS in a Multicast Flow Query Response message. This message flow is illustrated in Figure 3.
NASは、マルチキャストフロークエリ要求メッセージをANに送信して、特定のANポートで現在アクティブなマルチキャストフローや、特定のマルチキャストフローを現在複製しているポートなどの情報をANにクエリします。 ANは要求された情報をマルチキャストフロークエリ応答メッセージでNASに伝えます。このメッセージフローを図3に示します。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | |------------------>|
| | | |
| | | |
Figure 3: Multicast Flow Reporting
図3：マルチキャストフローレポート
The committed bandwidth reporting use case allows the NAS to maintain current awareness of how much multicast bandwidth the AN has committed to a given access line, so that the NAS can adjust its forwarding scheduler to ensure the associated QoS. Note that this involves a finer level of detail than provided by bandwidth delegation, since the amount of delegated bandwidth is an upper limit on the amount of bandwidth committed rather than an actual value. To reduce the volume of messaging, reports from the AN may be buffered so that one message reports on changes for multiple access lines.
コミットされた帯域幅レポートのユースケースにより、NASは、ANが特定のアクセス回線にコミットしたマルチキャスト帯域幅の現在の認識を維持できるため、NASは転送スケジューラを調整して、関連するQoSを確保できます。委任された帯域幅の量は実際の値ではなくコミットされた帯域幅の量の上限であるため、これには帯域幅の委任によって提供されるよりも詳細なレベルが含まれることに注意してください。メッセージングの量を減らすために、ANからのレポートがバッファリングされ、1つのメッセージが複数のアクセス回線の変更についてレポートするようになります。
The message flow associated with this use case is shown in Figure 4. The figure assumes that a non-zero buffering interval was previously provisioned on the AN.
この使用例に関連付けられたメッセージフローを図4に示します。この図は、以前にANでゼロ以外のバッファリング間隔がプロビジョニングされていることを前提としています。
+-----+ +-------+ +-----+ ANCP +-----+
|Subs |+ | Home |+ | AN |<---------->| NAS |
|1,2 || |GW 1,2 || +-----+ +-----+
+-----+| +-------+| | |
+|----+ +|------+ | |
| | | | | |
| |Join(Subs1, Ch1) | |
|----------+--------------->| Start buffering |
| | | Multicast flow | timer. Create |
|<=========+================| message with |
| | | | | initial contents |
| | | | | reporting new |
| | | | | Subs1 bandwidth. |
| | Join(Subs2, Ch2) | |
| |----------+------------->| Add report for |
| | | Multicast flow | new Subs2 b/w. |
| |<=========+==============| |
| | | | | |
| |Leave(Subs1, Ch1) | |
|----------+--------------->| Replace report |
| | | | | for Subs1 with |
| | Stop replication X new value (which |
| | | | | happens to be |
| | | | | the same as the |
| | | | | starting value). |
| | | | | |
| | | | >|< TIMER expires |
| | | | | |
| | | | |Committed |
| | | | | Bandwidth Report |
| | | | |------------------>|
| | | | | (for latest |
| | | | | Subs1 and Subs2 |
| | | | | bandwidth) |
| | | | | |
Figure 4: Message Flow for Committed Bandwidth Reporting
図4：コミットされた帯域幅レポートのメッセージフロー
This section defines new ANCP messages and new usage of existing ANCP messages as well as procedures associated with the use of these messages.
このセクションでは、新しいANCPメッセージと既存のANCPメッセージの新しい使用法、およびこれらのメッセージの使用に関連する手順を定義します。
Unless stated otherwise, receivers MUST ignore message contents that are not supported by the set of capabilities negotiated between the NAS and the Access Node.
特に明記しない限り、受信者は、NASとアクセスノード間でネゴシエートされた機能のセットでサポートされていないメッセージコンテンツを無視する必要があります。
Section 4.1 of [RFC6320] defines the Provisioning message that is sent by the NAS to the AN to provision information in the AN.
[RFC6320]のセクション4.1は、AN内の情報をプロビジョニングするためにNASからANに送信されるプロビジョニングメッセージを定義しています。
The present document specifies that the Provisioning message MAY be used by the NAS to provision multicast-related information (e.g., multicast service profiles). The ANCP Provisioning message payload MAY contain:
このドキュメントは、NASがマルチキャスト関連情報（たとえば、マルチキャストサービスプロファイル）をプロビジョニングするためにプロビジョニングメッセージを使用できることを指定しています。 ANCPプロビジョニングメッセージのペイロードには、以下が含まれる場合があります。
o one or more instances of the Multicast-Service-Profile TLV. The Multicast-Service-Profile TLV is defined in the present document in Section 5.1. Each instance of the Multicast-Service-Profile TLV contains a multicast service profile name and one or more list actions. A list action consists of an action (add, delete, replace), a list type (white, black, or grey), and list content (multicast source and group addresses).
o Multicast-Service-Profile TLVの1つ以上のインスタンス。 Multicast-Service-Profile TLVは、本書のセクション5.1で定義されています。 Multicast-Service-Profile TLVの各インスタンスには、マルチキャストサービスプロファイル名と1つ以上のリストアクションが含まれています。リストアクションは、アクション（追加、削除、置換）、リストタイプ（白、黒、またはグレー）、およびリストコンテンツ（マルチキャストソースとグループアドレス）で構成されます。
o an instance of the White-List-CAC TLV. The White-List-CAC TLV is defined in Section 5.6. If present, this TLV indicates that the AN is required to do admission control before replicating white-listed flows.
o ホワイトリストCAC TLVのインスタンス。ホワイトリストCAC TLVはセクション5.6で定義されています。存在する場合、このTLVは、ANがホワイトリストフローを複製する前にアドミッションコントロールを実行する必要があることを示します。
o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is defined in Section 5.7. If present, this TLV indicates that the AN is required to do admission control before replicating flows specified in Multicast Replication Control messages.
o MRepCtl-CAC TLVのインスタンス。 MRepCtl-CAC TLVはセクション5.7で定義されています。存在する場合、このTLVは、ANがマルチキャストレプリケーションコントロールメッセージで指定されたフローを複製する前にアドミッションコントロールを実行する必要があることを示します。
o an instance of the Report-Buffering-Time TLV. The Report-Buffering-Time TLV is defined in Section 5.13. If present, this TLV indicates Committed Bandwidth Report messages should be buffered for the amount of time given by the TLV before being transmitted to the NAS.
o Report-Buffering-Time TLVのインスタンス。 Report-Buffering-Time TLVはセクション5.13で定義されています。存在する場合、このTLVは、Committed Bandwidth Reportメッセージが、NASに送信される前に、TLVによって指定された時間バッファされる必要があることを示します。
See Section 6 for information on which multicast capabilities require support of these TLVs in the Provisioning message.
プロビジョニングメッセージでこれらのTLVのサポートが必要なマルチキャスト機能については、セクション6を参照してください。
When directed by the Policy Server or by management action, the NAS sends the Provisioning message to initially provision or to update the white, black, and/or grey multicast channel lists associated with a set of named multicast service profiles or to direct the AN to perform admission control for specific classes of flows.
ポリシーサーバまたは管理アクションによって指示された場合、NASはプロビジョニングメッセージを送信して、最初にプロビジョニングするか、名前付きマルチキャストサービスプロファイルのセットに関連付けられたホワイト、ブラック、またはグレーのマルチキャストチャネルリストを更新するか、ANをフローの特定のクラスのアドミッションコントロールを実行します。
To provision or update a multicast service profile, the NAS MUST include within the message one or more instances of the Multicast-Service-Profile TLV specifying the content to be provisioned or updated. The NAS MUST NOT include any list type (white, black, or grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN. The NAS MUST NOT use the Provisioning message to send instances of the Multicast-Service-Profile TLV to the AN unless the Multicast-Service-Profile TLV is supported by the set of multicast capabilities negotiated between the NAS and the AN.
マルチキャストサービスプロファイルをプロビジョニングまたは更新するには、NASは、プロビジョニングまたは更新されるコンテンツを指定するMulticast-Service-Profile TLVの1つ以上のインスタンスをメッセージ内に含める必要があります。 NASは、NASとANの間でネゴシエートされたマルチキャスト機能のセットでサポートされていないリストタイプ（白、黒、または灰色）を含めてはなりません（MUST NOT）。 NASとANの間でネゴシエートされたマルチキャスト機能のセットによってMulticast-Service-Profile TLVがサポートされていない限り、NASはプロビジョニングメッセージを使用してMulticast-Service-Profile TLVのインスタンスをANに送信してはなりません（MUST NOT）。
To require admission control to be performed at the AN on white-listed flows, the NAS MUST include a copy of the White-List-CAC TLV in the Provisioning message. The White-List-CAC TLV MUST NOT be provided unless the negotiated set of capabilities includes conditional access and admission control with white and black lists.
ホワイトリストに記載されたフローのANでアドミッションコントロールを実行する必要があるため、NASはプロビジョニングメッセージにホワイトリストCAC TLVのコピーを含める必要があります。ホワイトリストCAC TLVは、ネゴシエートされた機能のセットに条件付きアクセスとホワイトリストとブラックリストによるアドミッションコントロールが含まれていない限り、提供してはなりません（MUST NOT）。
To require admission control to be performed at the AN on grey-listed flows or on NAS-initiated flows, the NAS MUST include a copy of the MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV MUST NOT be provided unless the negotiated set of capabilities includes NAS-initiated multicast replication or conditional access and admission control with grey lists.
グレーリストのフローまたはNASが開始したフローのANでアドミッションコントロールを実行するように要求するには、NASはプロビジョニングメッセージにMRepCtl-CAC TLVのコピーを含める必要があります。 MRepCtl-CAC TLVは、ネゴシエートされた機能のセットに、NASが開始したマルチキャストレプリケーションまたは条件付きアクセスとグレーリストによるアドミッションコントロールが含まれていない限り、提供されてはなりません（MUST NOT）。
To require buffering of Committed Bandwidth Report messages so that reports for multiple access lines can be included in the same message, the NAS MUST include a copy of the Report-Buffering-Time TLV containing a non-zero time value in a Provisioning message sent to the AN. The Report-Buffering-Time TLV MUST NOT be provided unless the negotiated set of capabilities includes committed bandwidth reporting.
複数のアクセス回線のレポートを同じメッセージに含めることができるように、Committed Bandwidth Reportメッセージのバッファリングを要求するには、NASは、送信されるプロビジョニングメッセージにゼロ以外の時間値を含むReport-Buffering-Time TLVのコピーを含める必要があります。 AN。 Report-Buffering-Time TLVは、ネゴシエートされた機能のセットにコミットされた帯域幅レポートが含まれていない限り、提供されてはなりません（MUST NOT）。
The receiving AN provisions/updates the white, black, and/or grey lists associated with the multicast service profile names contained in the Multicast-Service-Profile TLV instances within the message according to the contents of the associated List-Action TLVs. The AN MUST process List-Action TLVs in the order in which they appear within the message. In keeping with the general rule stated in
受信ANは、関連付けられたリストアクションTLVの内容に従って、メッセージ内のMulticast-Service-Profile TLVインスタンスに含まれるマルチキャストサービスプロファイル名に関連付けられたホワイトリスト、ブラックリスト、またはグレーリストをプロビジョニング/更新します。 ANは、リストアクションTLVをメッセージ内に表示される順序で処理する必要があります。に記載されている一般的なルールに沿って
Section 4, the AN MUST ignore instances of the List-Action TLV referring to any list type (white, black, or grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN.
セクション4、ANは、NASとANの間でネゴシエートされたマルチキャスト機能のセットでサポートされていないリストタイプ（白、黒、または灰色）を参照するList-Action TLVのインスタンスを無視する必要があります。
When a new multicast service profile is identified by a Multicast-Service-Profile TLV, the initial state of all lists associated with that profile according to the negotiated set of multicast capabilities is empty until changed by the contents of Multicast-Service-Profile TLVs.
新しいマルチキャストサービスプロファイルがMulticast-Service-Profile TLVによって識別されると、ネゴシエートされたマルチキャスト機能のセットに従ってそのプロファイルに関連付けられたすべてのリストの初期状態は、Multicast-Service-Profile TLVの内容によって変更されるまで空です。
The receipt of a Provisioning message containing updates to an existing multicast service profile subsequent to startup will cause the AN to review the status of active flows on all ports to which that profile has been assigned. For further details, see Section 6.
起動後に既存のマルチキャストサービスプロファイルへの更新を含むプロビジョニングメッセージを受信すると、ANは、そのプロファイルが割り当てられているすべてのポートのアクティブフローのステータスを確認します。詳細については、セクション6を参照してください。
If the White-List-CAC and/or MRepCtl-CAC TLV is present in the Provisioning message and the respective associated capabilities have been negotiated, the AN prepares (or continues) to do admission control on the indicated class(es) of flow. If one or both of these TLVs was present in an earlier Provisioning message but is absent in the latest message received, the AN ceases to do admission control on the indicated class(es) of flow.
ホワイトリストCACおよび/またはMRepCtl-CAC TLVがプロビジョニングメッセージに存在し、それぞれの関連機能がネゴシエートされている場合、ANはフローの指定されたクラスでアドミッション制御を行う準備をします（または続行します）。これらのTLVのいずれかまたは両方が以前のプロビジョニングメッセージに存在していたが、受信した最新のメッセージには存在しない場合、ANは示されたフローのクラスでアドミッション制御を停止します。
The buffering time specified in an instance of the Report-Buffering-Time TLV will not be applied until the current accumulation process of Committed Bandwidth Report messages finishes.
Report-Buffering-Time TLVのインスタンスで指定されたバッファリング時間は、Committed Bandwidth Reportメッセージの現在の累積プロセスが完了するまで適用されません。
As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning message if it processed it successfully. If an error prevents successful processing of the message content, the AN MUST return a Generic Response message as defined in [RFC6320], containing a Status-Info TLV with the appropriate content describing the error. For this purpose, the presence of a list type in a Multicast-Service-Profile TLV, which was ignored because it was not supported by the negotiated set of capabilities, is not considered to be an error.
[RFC6320]に示されているように、ANは正常に処理した場合、プロビジョニングメッセージに応答してはなりません（MUST NOT）。エラーがメッセージコンテンツの正常な処理を妨げる場合、ANは[RFC6320]で定義されているGeneric Responseメッセージを返さなければならず、エラーを説明する適切なコンテンツを含むStatus-Info TLVを含んでいる必要があります。この目的のために、ネゴシエートされた機能のセットでサポートされていなかったために無視されたMulticast-Service-Profile TLVのリストタイプの存在は、エラーとは見なされません。
As specified in [RFC6320], the NAS may send DSL line configuration information to the AN (ANCP-based DSL line configuration use case) using ANCP Port Management messages. See Section 7.3 of [RFC6320] for the format of the Port Management message in that usage.
[RFC6320]で指定されているように、NASはANCPポート管理メッセージを使用して、DSLライン構成情報をAN（ANCPベースのDSLライン構成の使用例）に送信できます。その使用におけるポート管理メッセージの形式については、[RFC6320]のセクション7.3を参照してください。
This document specifies that the Port Management message MAY be used to convey either or both of the following TLVs: o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This TLV associates a Multicast Service Profile with the access line specified by the extension block and, in the case of white and black lists, delegates conditional access to the AN for the specified access line and channels.
このドキュメントでは、ポート管理メッセージを使用して、次のTLVのいずれかまたは両方を伝達する場合があることを明記しています：o Multicast-Service-Profile-Name TLV（セクション5.2で定義）。このTLVは、マルチキャストサービスプロファイルを拡張ブロックで指定されたアクセス回線に関連付け、ホワイトリストとブラックリストの場合、指定されたアクセス回線とチャネルのANへの条件付きアクセスを委任します。
o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV specifies the total multicast bandwidth available to the AN for admission control at the access line.
o 帯域幅割り当てTLV（セクション5.5で定義）。このTLVは、アクセス回線でのアドミッション制御のためにANが使用できる総マルチキャスト帯域幅を指定します。
When the Port Management message is used for this purpose:
ポート管理メッセージがこの目的で使用される場合：
o the Function field in the Port Management message MUST be set to 8, "Configure Connection Service Data".
o ポート管理メッセージの機能フィールドは8、「接続サービスデータの構成」に設定する必要があります。
o the message MUST include TLV(s) to identify the access line concerned. If the access line is a DSL loop, the line-identifying TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320]. For non-DSL access lines, the appropriate alternative line-identifying TLV(s) MUST be present. Line configuration data other than the two TLVs listed in the previous paragraph MAY be present.
o メッセージには、関係するアクセス回線を識別するためのTLVを含める必要があります。アクセス回線がDSLループの場合、回線を識別するTLVは、[RFC6320]のセクション5.1.2に指定されているとおりである必要があります。非DSLアクセス回線の場合、適切な代替回線識別TLVが存在する必要があります。前の段落にリストされている2つのTLV以外のライン構成データが存在する場合があります。
The NAS sends the Port Management message at startup time to initialize parameters associated with the access line specified in the message and with the multicast capabilities negotiated between the NAS and the AN. The NAS MAY send additional Port Management messages subsequent to startup, to update or, in the case of the Bandwidth-Allocation TLV, reset these parameters. If the NAS includes a Multicast-Service-Profile-Name TLV in the Port Management message, the name MUST match a profile name provided in a Multicast-Service-Profile TLV in a prior Provisioning message. The NAS MUST NOT include a TLV unless it is supported by the set of multicast capabilities negotiated between the NAS and the AN. See Section 6 for further information.
NASは起動時にポート管理メッセージを送信して、メッセージで指定されたアクセス回線と、NASとANの間でネゴシエートされたマルチキャスト機能に関連するパラメータを初期化します。 NASは、起動、更新、または帯域幅割り当てTLVの場合はこれらのパラメーターをリセットするために、追加のポート管理メッセージを送信する場合があります。 NASがポート管理メッセージにMulticast-Service-Profile-Name TLVを含める場合、名前は、以前のプロビジョニングメッセージのMulticast-Service-Profile TLVで提供されたプロファイル名と一致する必要があります。 NASとANの間でネゴシエートされたマルチキャスト機能のセットによってサポートされていない限り、NASにTLVを含めてはなりません（MUST NOT）。詳細については、セクション6を参照してください。
If the Port Management message contains a Multicast-Service-Profile-Name TLV, the AN associates the named profile with the specified access line. This association replaces any previous association. That is, a given access line is associated with at most one multicast service profile. The replacement of one multicast service profile with another will cause the AN to review the status of all active flows on the target port. For further details see Section 6.
ポート管理メッセージにMulticast-Service-Profile-Name TLVが含まれている場合、ANは指定されたプロファイルを指定されたアクセス回線に関連付けます。この関連付けは、以前の関連付けを置き換えます。つまり、特定のアクセス回線は最大で1つのマルチキャストサービスプロファイルに関連付けられます。あるマルチキャストサービスプロファイルを別のプロファイルに置き換えると、ANはターゲットポート上のすべてのアクティブフローのステータスを確認します。詳細については、セクション6を参照してください。
If the Port Management message contains a Bandwidth-Allocation TLV, the AN adopts this as the current value of its total multicast bandwidth limit for the target port. If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV.
ポート管理メッセージに帯域幅割り当てTLVが含まれている場合、ANはこれを、ターゲットポートのマルチキャスト帯域幅制限の現在の値として採用します。帯域幅割り当てTLVで指定された量を超えるマルチキャスト帯域幅をANがすでにコミットしている場合、ローカルポリシーでそのようなアクションが必要でない限り、ANは帯域幅を新しい制限内に下げるためにマルチキャストストリームを中断しないでください。ただし、ANは、帯域幅割り当てTLVで指定された制限内で許可できるまで、アドミッション制御の対象となる新しいマルチキャストストリームを許可してはなりません。
If the Port Management request cannot be processed due to error and the Result field of the request is Nack (0x1) or AckAll (0x2), the AN SHOULD add a Status-Info TLV to the Extension Value field in its reply if this will provide useful information beyond what is provided by the Result Code value returned in the response header. In particular, if the name within the Multicast-Service-Profile-Name TLV does not match a profile name given in a prior Provisioning message, the AN SHOULD return a reply where the Result Code field in the header indicates 0x55, "Invalid TLV contents", the Error Message field in the Status-Info TLV contains the text "Multicast profile name not provisioned", and the Status-Info TLV contains a copy of the Multicast-Service-Profile-Name TLV.
エラーが原因でポート管理要求を処理できず、要求のResultフィールドがNack（0x1）またはAckAll（0x2）の場合、ANは、応答で拡張値フィールドにStatus-Info TLVを追加する必要があります（これが提供される場合）。応答ヘッダーで返される結果コード値によって提供されるものを超えた有用な情報。特に、Multicast-Service-Profile-Name TLV内の名前が前のプロビジョニングメッセージで指定されたプロファイル名と一致しない場合、ANは、ヘッダーの結果コードフィールドが0x55、「無効なTLVコンテンツ"、Status-Info TLVのエラーメッセージフィールドには、テキスト" Multicast profile name not provisioned "が含まれ、Status-Info TLVにはMulticast-Service-Profile-Name TLVのコピーが含まれます。
This section defines a new message called the Multicast Replication Control message. The Multicast Replication Control message is sent by the NAS to the AN with one or more directives to add (join) or delete (leave) a multicast flow on a target object identified in the content of the message.
このセクションでは、マルチキャスト複製制御メッセージと呼ばれる新しいメッセージを定義します。マルチキャストレプリケーションコントロールメッセージは、メッセージのコンテンツで識別されたターゲットオブジェクトのマルチキャストフローを追加（参加）または削除（脱退）するための1つ以上のディレクティブとともに、NASからANに送信されます。
The Message Type for the Multicast Replication Control message is 144.
マルチキャストレプリケーションコントロールメッセージのメッセージタイプは144です。
The ANCP Multicast Replication Control message payload contains the following TLVs:
ANCPマルチキャストレプリケーションコントロールメッセージのペイロードには、次のTLVが含まれています。
o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320]. It MUST appear once and only once. It is encoded as specified in [RFC6320] or extensions and identifies the AN port subject to the request for admission or release.
o ターゲットTLV：ターゲットTLVは、[RFC6320]のセクション4.3で定義されています。一度だけ出現する必要があります。 [RFC6320]または拡張で指定されたとおりにエンコードされ、アドミッションまたはリリースの要求の対象となるANポートを識別します。
o Command TLV: The Command TLV is defined in Section 4.4 of [RFC6320]. It MUST be present. It MAY appear multiple times.
o コマンドTLV：コマンドTLVは、[RFC6320]のセクション4.4で定義されています。存在する必要があります。複数回出現する場合があります。
As [RFC6320] indicates, the contents of the Command Info field within the Command TLV are specific to the message in which the TLV occurs. For the Multicast Replication Control message, these contents consist of:
[RFC6320]が示すように、コマンドTLV内のコマンド情報フィールドの内容は、TLVが発生するメッセージに固有です。マルチキャスト複製制御メッセージの場合、これらの内容は次のとおりです。
o a Command Code field;
o コマンドコードフィールド。
o an Accounting field; and
o 会計フィールド。そして
o an instance of the Multicast-Flow TLV.
o マルチキャストフローTLVのインスタンス。
Figure 5 illustrates the complete Command TLV with the contents specific to the Multicast Replication Control message.
図5は、マルチキャストレプリケーションコントロールメッセージに固有の内容を含む完全なコマンドTLVを示しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Command Code | Accounting | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other embedded TLV Type | Other embedded TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Other embedded TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Contents of the Command TLV in the Multicast Replication Control Message
図5：マルチキャストレプリケーションコントロールメッセージのコマンドTLVの内容
o Command Code: One of the following command directives:
o コマンドコード：次のコマンドディレクティブのいずれか：
1 "Add"
1「追加」
2 "Delete"
2「削除」
3 "Delete All"
3「すべて削除」
4 "Admission Control Reject"
4「アドミッションコントロール拒否」
5 "Conditional Access Reject"
5「条件付きアクセス拒否」
6 "Admission Control and Conditional Access Reject"
6「アドミッションコントロールと条件付きアクセス拒否」
Directives 4 through 6 are used as described in Section 4.4.2.
ディレクティブ4〜6は、セクション4.4.2で説明されているように使用されます。
o Accounting: Meaningful only when the Command Code is "Add" (1). In that case, 0 indicates flow accounting is disabled, and 1 indicates that octet accounting for the flow is requested. The sender MUST set the Accounting field to 0, and the receiver MUST ignore the Accounting field for other Command Code values.
o アカウンティング：コマンドコードが「追加」（1）の場合にのみ意味があります。その場合、0はフローアカウンティングが無効であることを示し、1はフローのオクテットアカウンティングが要求されていることを示します。送信者はアカウンティングフィールドを0に設定する必要があり、受信者は他のコマンドコード値のアカウンティングフィールドを無視する必要があります。
o Reserved: Reserved for future use. MUST be set to zeroes by the sender and ignored by the receiver.
o 予約済み：将来の使用のために予約されています。送信者はゼロに設定し、受信者は無視する必要があります。
o Multicast-Flow TLV: An instance of the Multicast-Flow TLV (Section 5.12) specifying the flow to be added or deleted. The Multicast-Flow TLV is omitted if the Command Code has value "Delete All" (3).
o マルチキャストフローTLV：追加または削除するフローを指定するマルチキャストフローTLV（セクション5.12）のインスタンス。コマンドコードの値が「すべて削除」（3）の場合、マルチキャストフローTLVは省略されます。
o Other embedded TLV data: No other embedded TLVs are currently specified within the Multicast Replication Control message and Command TLV. However, see the description of the Multicast Admission Control message (Section 4.4). Unrecognized embedded TLVs SHOULD be silently discarded.
o その他の埋め込みTLVデータ：現在、マルチキャストレプリケーションコントロールメッセージとコマンドTLV内に他の埋め込みTLVは指定されていません。ただし、マルチキャストアドミッションコントロールメッセージの説明を参照してください（セクション4.4）。認識されない埋め込みTLVは警告なしに破棄されるべきです。
The figure below is an example of a Multicast Replication Control message that would result in a swap from multicast Source-Specific Multicast (SSM) flows 2001:DB8::1, FF34::2 to 2001:DB8::2, FF34::3 on the target identified by the Access Loop Circuit ID:
次の図は、マルチキャストSource-Specific Multicast（SSM）フロー2001：DB8 :: 1、FF34 :: 2から2001：DB8 :: 2、FF34 ::へのスワップをもたらすマルチキャストレプリケーションコントロールメッセージの例です。アクセスループ回路IDで識別されるターゲット上で3：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MsgType=144 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command-TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Change of Source Flow Using Multicast Replication Control Message
図6：マルチキャストレプリケーションコントロールメッセージを使用したソースフローの変更例
The NAS MAY issue a Multicast Replication Control message to the AN to convey one or more directives to add (join) or delete (leave) one or more multicast flows.
NASは、1つ以上のマルチキャストフローを追加（参加）または削除（脱退）するための1つ以上のディレクティブを伝達するために、ANにマルチキャストレプリケーションコントロールメッセージを発行する場合があります。
The NAS MAY send this message on its own initiative to support the NAS-initiated multicast control use case presented in [RFC5851] and summarized in Section 3.1. In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1) according to its requirements.
NASは、[RFC5851]で提示され、セクション3.1で要約されている、NASが開始するマルチキャスト制御の使用事例をサポートするために、独自のイニシアチブでこのメッセージを送信する場合があります。その場合、NASはその要件に従って結果フィールドをAckAll（0x2）またはNack（0x1）に設定する必要があります。
The NAS MAY also send this message in response to a Multicast Admission Control message (defined in Section 4.4) received from the AN to support the conditional access and admission control use case presented in [RFC5851] and summarized in Section 3.2. In that case, the NAS MUST set the Result field to Nack (0x1).
NASは、ANから受信したマルチキャストアドミッションコントロールメッセージ（セクション4.4で定義）への応答としてこのメッセージを送信して、[RFC5851]で提示され、セクション3.2に要約されている条件付きアクセスとアドミッションコントロールの使用例をサポートする場合があります。その場合、NASは結果フィールドをNack（0x1）に設定する必要があります。
In either case, the sender MUST populate the Result Code field with the value 0 and the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
どちらの場合も、[RFC6320]のセクション3.6.1.6で説明されているように、送信者は結果コードフィールドに値0を、ANCPトランザクション識別子フィールドに一意の値を設定する必要があります。
Each Multicast Replication Control message MUST contain one or more commands, each encapsulated in its own Command TLV. The sender MUST use a separate Command TLV for each distinct multicast flow.
各マルチキャストレプリケーションコントロールメッセージには、1つ以上のコマンドが含まれている必要があり、各コマンドは独自のコマンドTLVにカプセル化されています。送信者は、個別のマルチキャストフローごとに個別のコマンドTLVを使用する必要があります。
When the order of processing of two commands does not matter, the commands MUST be transmitted in separate Multicast Replication Control messages.
2つのコマンドの処理順序が重要でない場合は、コマンドを個別のマルチキャストレプリケーションコントロールメッセージで送信する必要があります。
When successive commands (in the same or different messages) relate to the same target and multicast flow, the state of each feature controlled or affected by attributes received in the Multicast Replication Control message SHALL be as set by the last command or message referring to that target and flow and containing the controlling attribute. As an example, successive Multicast Replication Control messages containing add commands for a given port and flow but differing only in the Accounting field update the state of the accounting feature to what is set in the final command received, but all other features are unaffected by the second message.
（同じまたは異なるメッセージ内の）連続するコマンドが同じターゲットとマルチキャストフローに関連している場合、マルチキャストレプリケーションコントロールメッセージで受信された属性によって制御または影響を受ける各機能の状態は、それを参照する最後のコマンドまたはメッセージによって設定されるものとする（SHALL）ターゲットとフロー、および制御属性を含みます。例として、特定のポートとフローのaddコマンドを含むが、Accountingフィールドのみが異なる一連のマルチキャストレプリケーションコントロールメッセージは、アカウンティング機能の状態を、受信した最後のコマンドで設定されたものに更新しますが、他のすべての機能は、 2番目のメッセージ。
If more than one Command TLV is present in a Multicast Replication Control message, the AN MUST act on the commands in the order in which they are presented in the message. The AN SHALL assign a sequence number to each command in a given Multicast Replication Control message, starting from 1 for the first command.
マルチキャストレプリケーションコントロールメッセージに複数のコマンドTLVが存在する場合、ANは、メッセージに表示されている順序でコマンドを実行する必要があります。 ANは、所定のマルチキャストレプリケーションコントロールメッセージ内の各コマンドに、最初のコマンドの1から始まるシーケンス番号を割り当てます。
If a Command TLV adds one or more flows and the AN is performing admission control for Multicast Replication Control messages, then the AN MUST perform admission control before replicating the flows. If the admission control check fails, the AN MUST treat the failure as an error as described below. The appropriate Result Code value for the response is 0x13 "Out of resources".
コマンドTLVが1つ以上のフローを追加し、ANがマルチキャストレプリケーションコントロールメッセージのアドミッション制御を実行している場合、ANはフローを複製する前にアドミッション制御を実行する必要があります。アドミッションコントロールチェックが失敗した場合、ANは、以下で説明するように、失敗をエラーとして処理する必要があります。応答の適切な結果コード値は0x13 "リソース不足"です。
If the AN processes the complete Multicast Replication Control message successfully and the Result field of the Multicast Replication Control message was set to AckAll (0x2), the AN MUST respond with a Generic Response message where the Result field is set to Success (0x3), the Result Code field is set to 0, and the Transaction Identifier field is copied from the Multicast Replication Control message. The body of the response MAY be empty or MAY be copied from the Multicast Replication Control message.
ANが完全なマルチキャストレプリケーションコントロールメッセージを正常に処理し、マルチキャストレプリケーションコントロールメッセージのResultフィールドがAckAll（0x2）に設定されている場合、ANは、ResultフィールドがSuccess（0x3）に設定されているGeneric Responseメッセージで応答する必要があります。結果コードフィールドは0に設定され、トランザクション識別子フィールドはマルチキャストレプリケーションコントロールメッセージからコピーされます。応答の本文は空であるか、マルチキャスト複製制御メッセージからコピーされる場合があります。
If the AN processes the complete Multicast Replication Control message successfully and the Result field of the Multicast Replication Control message was set to Nack (0x1), the AN MUST NOT respond to the message.
ANが完全なマルチキャスト複製制御メッセージを正常に処理し、マルチキャスト複製制御メッセージの結果フィールドがNack（0x1）に設定されている場合、ANはメッセージに応答してはなりません（MUST NOT）。
The processing/execution of multiple commands contained in a single Multicast Replication Control message MUST be interrupted at the first error encountered and the remaining commands in the Multicast Replication Control message discarded. Similarly, if a given command specifies multiple Single-Source Multicast (SSM) flows and an error occurs, processing MUST be interrupted at that point, and the remainder of the Command TLV discarded.
単一のマルチキャストレプリケーションコントロールメッセージに含まれる複数のコマンドの処理/実行は、最初に発生したエラーで中断されなければならず、マルチキャストレプリケーションコントロールメッセージの残りのコマンドは破棄されなければなりません。同様に、特定のコマンドが複数のシングルソースマルチキャスト（SSM）フローを指定してエラーが発生した場合、その時点で処理を中断し、コマンドTLVの残りを破棄する必要があります。
If the AN detects an error in a received Multicast Replication Control message and the Result field in that message was set to Nack (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message providing error information to the NAS. This specification identifies the following new Result Code values beyond those specified in [RFC6320], which MAY be used in a Generic Response sent in reply to a Multicast Replication Control message: 0x64 Command error.
ANが受信したマルチキャストレプリケーションコントロールメッセージでエラーを検出し、そのメッセージのResultフィールドがNack（0x1）またはAckAll（0x2）に設定されている場合、ANはエラー情報をNASに提供するGeneric Responseメッセージを生成する必要があります。この仕様は、[RFC6320]で指定されているものを超える、次の新しい結果コード値を識別します。これらは、マルチキャストレプリケーションコントロールメッセージへの応答として送信されるGeneric Responseで使用できます：0x64コマンドエラー。
Where detected: ANCP agent at the AN.
検出された場所：ANのANCPエージェント。
Further description: an invalid command code has been received.
詳細説明：無効なコマンドコードを受け取りました。
Required additional information in the message: see below.
メッセージに必要な追加情報：以下を参照してください。
Target: ANCP agent at the NAS.
ターゲット：NASのANCPエージェント。
Action RECOMMENDED for the receiving ANCP agent: Report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
受信側ANCPエージェントに推奨されるアクション：無効なTLVに関連する誤った情報を示して、制御アプリケーションにエラーを報告します。
0x65 Invalid flow address.
0x65無効なフローアドレス。
Where detected: ANCP agent at the AN.
検出された場所：ANのANCPエージェント。
Further description: either inconsistent flow address information has been provided or the address family is unsupported.
詳細説明：一貫性のないフローアドレス情報が提供されたか、アドレスファミリがサポートされていません。
Required additional information in the message: see below.
メッセージに必要な追加情報：以下を参照してください。
Target: ANCP agent at the NAS.
ターゲット：NASのANCPエージェント。
Action RECOMMENDED for the receiving ANCP agent: Report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
受信側ANCPエージェントに推奨されるアクション：無効なTLVに関連する誤った情報を示して、制御アプリケーションにエラーを報告します。
0x66 Multicast flow does not exist.
0x66マルチキャストフローが存在しません。
Where detected: control application at the AN.
検出された場所：ANでの制御アプリケーション。
Further description: the NAS has attempted to delete a flow that is not active on the given access line.
詳細説明：NASは、指定されたアクセス回線でアクティブでないフローを削除しようとしました。
Required additional information in the message: see below.
メッセージに必要な追加情報：以下を参照してください。
Target: control application at the NAS.
ターゲット：NASでの制御アプリケーション。
Action RECOMMENDED for the receiving ANCP agent: report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
受信ANCPエージェントに推奨されるアクション：無効なTLVに関連する誤った情報を示して、制御アプリケーションにエラーを報告します。
A Generic Response message responding to the Multicast Replication Control message and containing one of the above Result Code values MUST include a Status-Info TLV, which includes one or two embedded TLVs as follows:
マルチキャストレプリケーションコントロールメッセージに応答し、上記の結果コード値の1つを含むGeneric Responseメッセージには、次のように1つまたは2つの埋め込みTLVを含むStatus-Info TLVを含める必要があります。
o a Sequence-Number TLV as described in Section 5.4, giving the sequence number of the failed command, MUST be included; and
o セクション5.4で説明されているシーケンス番号TLVには、失敗したコマンドのシーケンス番号が含まれている必要があります。そして
o the failed Command TLV itself SHOULD be included.
o 失敗したコマンドTLV自体を含める必要があります。
Note: The Error Message field of the Status-Info TLV MAY be used to report more details than implied by the Result Code value in the message header. For example, the Result Code value could be 0x65, and the Error Message field could contain the text: "Source address present for ASM flow".
注：Status-Info TLVのエラーメッセージフィールドを使用して、メッセージヘッダーの結果コードの値が示すよりも多くの詳細を報告できます。たとえば、結果コードの値は0x65で、エラーメッセージフィールドには「ASMフローに存在する送信元アドレス」というテキストを含めることができます。
This section defines a new message called the Multicast Admission Control message. The Multicast Admission Control message is sent by the AN to the NAS to request admission of a multicast flow, or to notify of the removal of a multicast flow, for a given target.
このセクションでは、マルチキャストアドミッションコントロールメッセージと呼ばれる新しいメッセージを定義します。マルチキャストアドミッション制御メッセージは、所定のターゲットについて、ANからNASに送信され、マルチキャストフローの承認を要求するか、マルチキャストフローの削除を通知します。
The Message Type for the Multicast Admission Control message is 145.
マルチキャストアドミッションコントロールメッセージのメッセージタイプは145です。
The ANCP Multicast Admission Control message payload contains two TLVs:
ANCPマルチキャストアドミッションコントロールメッセージペイロードには、2つのTLVが含まれています。
o Target TLV: The Target TLV is defined in [RFC6320]. It MUST appear once and only once in the Multicast Admission Control message. It is encoded as specified in [RFC6320] or extensions and identifies the AN port subject to the request for admission or release.
o ターゲットTLV：ターゲットTLVは[RFC6320]で定義されています。これは、マルチキャストアドミッションコントロールメッセージに1回だけ出現する必要があります。 [RFC6320]または拡張で指定されたとおりにエンコードされ、アドミッションまたはリリースの要求の対象となるANポートを識別します。
o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be present. If it appears more than once, only the first instance is considered meaningful in the present version of this specification, and the other instances are ignored.
o コマンドTLV：コマンドTLVは[RFC6320]で定義されています。存在する必要があります。複数回出現する場合、この仕様の現在のバージョンでは最初のインスタンスのみが意味があると見なされ、他のインスタンスは無視されます。
Note: In the future, the specification of the Multicast Admission Control message may be extended to allow transport of more than a single directive (e.g., to carry both a leave from one group and a join to another group for the same target). It is expected that this would support a similar notion of strict sequenced processing as currently defined for handling multiple directives in the Multicast Replication Control message whereby all directives following the first directive that cannot be executed are not executed either. When the strict sequenced processing of the directives is not required, the directives are distributed across separate messages.
注：将来、マルチキャストアドミッションコントロールメッセージの仕様が拡張され、複数のディレクティブを転送できるようになる可能性があります（たとえば、1つのグループからの脱退と、同じターゲットの別のグループへの参加の両方を実行するため）。これは、マルチキャスト複製制御メッセージの複数のディレクティブを処理するために現在定義されている厳密なシーケンス処理の同様の概念をサポートし、実行できない最初のディレクティブに続くすべてのディレクティブも実行されないことが期待されます。ディレクティブの厳密なシーケンス処理が不要な場合、ディレクティブは個別のメッセージに分散されます。
The Command TLV has the same contents as were described above for the Multicast Replication Control message, with the following additions:
コマンドTLVの内容は、マルチキャスト複製制御メッセージについて上記で説明したものと同じですが、次の点が追加されています。
o A Request-Source-IP TLV MAY be appended to the Command TLV as an additional embedded TLV.
o Request-Source-IP TLVは、追加の埋め込みTLVとしてコマンドTLVに追加される場合があります。
o Similarly, a Request-Source-MAC TLV MAY be appended to the Command TLV as an additional embedded TLV.
o 同様に、Request-Source-MAC TLVは、追加の埋め込みTLVとしてコマンドTLVに追加される場合があります。
o Finally and preferably, a Request-Source-Device-Id TLV MAY be appended to the Command TLV as an additional embedded TLV.
o 最後に、できれば、Request-Source-Device-Id TLVを追加の埋め込みTLVとしてコマンドTLVに追加してもよい（MAY）。
Note that the Command TLV length includes the length of any embedded TLVs, including the embedded TLV headers.
コマンドTLVの長さには、埋め込みTLVヘッダーを含む、埋め込みTLVの長さが含まれることに注意してください。
The AN sending the Multicast Admission Control message MUST set the Result field to Ignore (0x0).
マルチキャストアドミッションコントロールメッセージを送信するANは、結果フィールドを無視（0x0）に設定する必要があります。
The AN MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
[RFC6320]のセクション3.6.1.6で説明されているように、ANはANCPトランザクション識別子フィールドに一意の値を設定する必要があります。
The AN MUST encode the Command TLV as specified in Section 4.3 with the following additional rules:
ANは、セクション4.3で指定されているように、次の追加ルールを使用してコマンドTLVをエンコードする必要があります。
o The Accounting field MUST be set to 0.
o Accountingフィールドは0に設定する必要があります。
o The Command Code field MUST be set to "Add" (1) when the message conveys a join request, to "Delete" (2) when the message conveys a leave, and to "Delete All" (3) when the message conveys a leave of all channels (on the target).
o コマンドコードフィールドは、メッセージが参加要求を伝える場合は「追加」（1）、休暇を伝える場合は「削除」（2）、メッセージが休暇を伝える場合は「すべて削除」（3）に設定する必要があります。 （ターゲット上で）すべてのチャネルを離れます。
o The Multicast-Flow TLV within the Command TLV identifies the multicast flow subject to the request for admission or release. When the Command Code is 3, the Multicast-Flow TLV is omitted.
o コマンドTLV内のマルチキャストフローTLVは、アドミッションまたはリリースの要求の対象となるマルチキャストフローを識別します。コマンドコードが3の場合、Multicast-Flow TLVは省略されます。
o The Request-Source-IP embedded TLV MAY be included by the AN to convey the IP address of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it appears more than once, only the first instance is considered meaningful, and the other instances are ignored.
o Request-Source-IP埋め込みTLVは、ANが対応するコマンドTLVをに含めるようにトリガーした参加/脱退メッセージ（IGMP / MLD参加/脱退など）の送信者のIPアドレスを伝えるために、ANに含めることができます（MAY）。マルチキャストアドミッションコントロールメッセージ。複数回出現する場合、最初のインスタンスのみが意味があると見なされ、他のインスタンスは無視されます。
o The Request-Source-MAC embedded TLV MAY be included by the AN to convey the Media Access Control (MAC) address of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it appears more than once, only the first instance is considered meaningful, and the other instances are ignored.
o Request-Source-MAC埋め込みTLVは、ANがトリガーされた参加/脱退メッセージ（IGMP / MLD参加/脱退など）の送信者のメディアアクセス制御（MAC）アドレスを伝えるために、ANに含めることができます（MAY）。マルチキャストアドミッションコントロールメッセージの対応するコマンドTLV。複数回出現する場合、最初のインスタンスのみが意味があると見なされ、他のインスタンスは無視されます。
o As a third alternative, the Request-Source-Device-Id embedded TLV MAY be included by the AN to convey a local identifier of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it appears more than once, only the first instance is considered meaningful, and the other instances are ignored.
o 3番目の代替案として、ANをトリガーした加入/脱退メッセージ（IGMP / MLD加入/脱退など）の送信者のローカル識別子を伝えるために、Request-Source-Device-Id埋め込みTLVをANに含めることができます（MAY）。マルチキャストアドミッションコントロールメッセージに対応するコマンドTLVを含めます。複数回出現する場合、最初のインスタンスのみが意味があると見なされ、他のインスタンスは無視されます。
The inclusion of Request-Source-IP or Request-Source-MAC in the Multicast Admission Control message is typically done to allow the application of policies applicable to specific devices within the customer's network. However, transmission of either of these fields beyond the AN introduces potential privacy issues. Instead of transmitting either of these identifiers, it is RECOMMENDED that the AN map the required identifier to a local value known to the AN and Authentication, Authorization, and Accounting (AAA) but not to the NAS, as discussed in Section 8. The local identifier is transmitted using the Request-Source-Device-Id TLV.
マルチキャストアドミッションコントロールメッセージにRequest-Source-IPまたはRequest-Source-MACを含めることは、通常、顧客のネットワーク内の特定のデバイスに適用可能なポリシーを適用できるようにするために行われます。ただし、これらのフィールドのいずれかがANを超えて送信されると、プライバシーの問題が発生する可能性があります。これらの識別子のいずれかを送信する代わりに、セクション8で説明されているように、ANが必要な識別子をANおよび認証、承認、アカウンティング（AAA）ではなく、NASには知らないローカル値にマップすることをお勧めします。識別子は、Request-Source-Device-Id TLVを使用して送信されます。
On receipt of a Multicast Admission Control message:
マルチキャストアドミッションコントロールメッセージの受信時：
o The NAS MUST ignore the Result field.
o NASは結果フィールドを無視する必要があります。
o If the directive in the Multicast Admission Control message is "Delete" (2) or "Delete All" (3) and is processed correctly by the NAS, the NAS MUST NOT generate any ANCP message in response to the Multicast Admission Control message.
o マルチキャストアドミッションコントロールメッセージのディレクティブが「削除」（2）または「すべて削除」（3）であり、NASによって正しく処理される場合、NASはマルチキャストアドミッションコントロールメッセージに応答してANCPメッセージを生成してはなりません（MUST NOT）。
o If the directive in the Multicast Admission Control message is "Add" (1) and is accepted by the NAS, the NAS MUST generate a Multicast Replication Control message in response to the Multicast Admission Control message. The Multicast Replication Control message:
o マルチキャストアドミッションコントロールメッセージのディレクティブが「追加」（1）であり、NASによって受け入れられる場合、NASはマルチキャストアドミッションコントロールメッセージに応答してマルチキャストレプリケーションコントロールメッセージを生成する必要があります。マルチキャスト複製制御メッセージ：
* MUST contain a Result set to Nack (0x1);
* 結果セットをNack（0x1）に含める必要があります。
* MUST contain a Transaction ID with a unique value, as described in Section 3.6.1.6 of [RFC6320]; and
* [RFC6320]のセクション3.6.1.6で説明されているように、一意の値を持つトランザクションIDを含める必要があります。そして
* MUST contain the directive as accepted by the NAS. The NAS MAY modify the Accounting field if flow accounting is required.
* NASによって承認されたディレクティブを含める必要があります。フローアカウンティングが必要な場合、NASはアカウンティングフィールドを変更する場合があります。
o If the directive in the Multicast Admission Control message is "Add" (1) and is processed correctly but not accepted by the NAS (i.e., it does not pass the conditional access and admission control check), the NAS MAY generate a Multicast Replication Control message in response to the Multicast Admission Control message. This optional message can be used by the AN to maintain statistics about admission control rejections. When used in this situation, the Multicast Replication Control message:
o マルチキャストアドミッションコントロールメッセージのディレクティブが「追加」（1）であり、正しく処理されてもNASで受け入れられない場合（つまり、条件付きアクセスおよびアドミッションコントロールチェックに合格しない場合）、NASはマルチキャストレプリケーションコントロールを生成できます（MAY）。マルチキャストアドミッションコントロールメッセージに応答するメッセージ。このオプションのメッセージは、アドミッションコントロールの拒否に関する統計を維持するためにANで使用できます。この状況で使用される場合、マルチキャストレプリケーションコントロールメッセージ：
* MUST contain a Result set to 0x0;
* Resultセットを0x0に設定する必要があります。
* MUST contain a Transaction ID with a unique value, as described in Section 3.6.1.6 of [RFC6320]; and
* [RFC6320]のセクション3.6.1.6で説明されているように、一意の値を持つトランザクションIDを含める必要があります。そして
* MUST contain the directive rejected by the NAS (i.e., Target TLV and Command TLV) but with a Command Code set to "Admission Control Reject" (4), "Conditional Access Reject" (5), or "Admission Control and Conditional Access Reject" (6) as applicable.
* NASによって拒否されたディレクティブ（つまり、ターゲットTLVおよびコマンドTLV）を含む必要がありますが、コマンドコードは「アドミッション制御拒否」（4）、「条件付きアクセス拒否」（5）、または「アドミッション制御および条件付きアクセス拒否」に設定されています"（6）該当する場合。
o If the Multicast Admission Control message cannot be processed correctly by the NAS (e.g., the message is malformed, the multicast flow does not exist, etc.), the NAS MUST generate a Generic Response message (defined in Section 4.2 of [RFC6320]) with appropriate content indicating the reason for the failure.
o マルチキャストアドミッションコントロールメッセージをNASが正しく処理できない場合（メッセージの形式が正しくない、マルチキャストフローが存在しないなど）、NASはGeneric Responseメッセージを生成する必要があります（[RFC6320]のセクション4.2で定義）。失敗の理由を示す適切なコンテンツ。
The Bandwidth Reallocation Request message is used when the bandwidth delegation capability is included in the negotiated set. It MAY be sent either by the NAS or by the AN to request an adjustment in the amount of delegated bandwidth. It will be sent by the NAS typically to reduce the multicast bandwidth allocated to the AN in order for the NAS to satisfy a request to add one or more flows. Conversely, the AN will send a Bandwidth Reallocation Request message to obtain additional bandwidth to satisfy a request to add a multicast channel. In each case, the requestor has a minimum requirement for additional bandwidth and MAY ask for additional bandwidth beyond this amount (e.g., to handle anticipated future requests).
帯域幅再割り当て要求メッセージは、帯域幅委任機能がネゴシエートされたセットに含まれている場合に使用されます。委任された帯域幅の量の調整を要求するために、NASまたはANによって送信される場合があります。これは、NASが1つ以上のフローを追加する要求を満たすために、通常、ANに割り当てられたマルチキャスト帯域幅を削減するために送信されます。逆に、ANは帯域幅再割り当て要求メッセージを送信して、マルチキャストチャネルを追加する要求を満たすために追加の帯域幅を取得します。いずれの場合も、リクエスタには追加の帯域幅の最小要件があり、この量を超える追加の帯域幅を要求することができます（たとえば、予想される将来の要求を処理するため）。
The Bandwidth Reallocation Request message contains two TLVs:
Bandwidth Reallocation Requestメッセージには2つのTLVが含まれています。
o the Target TLV (Section 4.3 of [RFC6320] or an extension), specifying a single access line; and
o 単一のアクセス回線を指定するターゲットTLV（[RFC6320]のセクション4.3または拡張）。そして
o the Bandwidth-Request TLV (Section 5.8), specifying the required and preferred amounts of delegated bandwidth.
o 帯域幅要求TLV（セクション5.8）。委任された帯域幅の必要な優先量を指定します。
The Message Type for the Bandwidth Reallocation Request message is 146.
Bandwidth Reallocation Requestメッセージのメッセージタイプは146です。
The Result field in the header of the Bandwidth Reallocation Request message is not used, and the sender MUST set it to Ignore (0x0).
Bandwidth Reallocation RequestメッセージのヘッダーのResultフィールドは使用されず、送信者はそれを無視（0x0）に設定する必要があります。
The bandwidth values in the Bandwidth-Request TLV are expressed in terms of total multicast bandwidth allocated to the AN.
Bandwidth-Request TLVの帯域幅値は、ANに割り当てられたマルチキャスト帯域幅の合計で表されます。
Note: The choice of "total bandwidth" rather than "incremental bandwidth" was made so that it would be easier for the AN and NAS to keep their respective views of the current amount of delegated bandwidth synchronized.
注：「増分帯域幅」ではなく「合計帯域幅」を選択したのは、ANとNASが委任された帯域幅の現在の量のそれぞれのビューを同期しやすくするためです。
Because the values are totals rather than desired increments/ decrements, the relationship between the required amount and the preferred amount will differ depending on whether the Bandwidth Reallocation Request message is issued by the NAS or the AN.
値は望ましい増分/減分ではなく合計であるため、必要な量と推奨される量の関係は、Bandwidth Reallocation RequestメッセージがNASまたはANによって発行されるかどうかによって異なります。
o If the NAS is making the request, the preferred amount MUST be less than or equal to the required amount. The required amount MUST be less than the current amount of delegated bandwidth.
o NASが要求を行っている場合、推奨量は必要量以下でなければなりません。必要な量は、委任された帯域幅の現在の量よりも少ない必要があります。
o If the AN is making the request, the preferred amount MUST be greater than or equal to the required amount. The required amount MUST be greater than the current amount of delegated bandwidth.
o ANが要求を行っている場合、推奨量は必要量以上である必要があります。必要な量は、委任された帯域幅の現在の量よりも大きい必要があります。
When the peer receives a valid Bandwidth Reallocation Request message, it SHOULD determine whether it can satisfy the request from its existing allocation of unused video bandwidth. If it decides that it can reallocate bandwidth to the peer, it MAY choose to return any amount between the required and the preferred amounts indicated in the Bandwidth Reallocation Request message.
ピアが有効な帯域幅再割り当て要求メッセージを受信すると、未使用のビデオ帯域幅の既存の割り当てからの要求を満たすことができるかどうかを判断する必要があります。ピアに帯域幅を再割り当てできると判断した場合、Bandwidth Reallocation Requestメッセージに示されている必要量と推奨量の間の任意の量を返すことを選択できます。
The peer MUST return a Bandwidth Transfer message (Section 4.6) indicating its decision. If the request is met, the Result field of the Bandwidth Transfer message MUST be set to Success (0x3), the Result Code field MUST be set to 0x000, and the Bandwidth-Allocation TLV (Section 5.5) MUST contain the new value of total multicast bandwidth. This new value MUST lie between the required and preferred values, inclusive, from the request message. If the request is not met, the Result field of the Bandwidth Transfer message MUST be set to Failure (0x4), the Result Code field MUST be set to 0, and the Bandwidth-Allocation TLV MUST contain the value of the currently allocated amount of delegated bandwidth as the responder views it.
ピアは、その決定を示す帯域幅転送メッセージ（セクション4.6）を返さなければなりません（MUST）。要求が満たされる場合、帯域幅転送メッセージの結果フィールドを成功（0x3）に設定する必要があり、結果コードフィールドを0x000に設定する必要があり、帯域幅割り当てTLV（セクション5.5）に新しい合計値を含める必要があります。マルチキャスト帯域幅。この新しい値は、要求メッセージからの必須値と優先値の間にある必要があります。要求が満たされない場合、帯域幅転送メッセージの結果フィールドを失敗（0x4）に設定する必要があり、結果コードフィールドを0に設定する必要があります。また、帯域幅割り当てTLVには、現在割り当てられている量の値を含める必要があります。レスポンダがそれを見るときの委任された帯域幅。
The following cases indicate that the sender holds a different view of the amount of delegated bandwidth from the receiver:
次の場合は、送信者が受信者からの委任された帯域幅の量について異なる見方をしていることを示しています。
o The NAS receives a request where the required amount is less than its view of the current amount of delegated bandwidth.
o NASは、必要な量が、委任された帯域幅の現在の量のビューよりも少ない要求を受け取ります。
o The AN receives a request where the required amount is greater than its view of the current amount of delegated bandwidth.
o ANは、要求された量が、委任された帯域幅の現在の量のビューよりも大きい要求を受け取ります。
If one of these cases occurs, the receiver, with one exception, MUST send a Bandwidth Transfer message indicating Success.
これらのケースのいずれかが発生した場合、1つの例外を除き、受信者は成功を示す帯域幅転送メッセージを送信する必要があります。
o If the NAS received the request, the allocated amount in the NAS's response MUST be at least equal to the NAS's view of the current amount of delegated bandwidth.
o NASが要求を受信した場合、NASの応答で割り当てられた量は、少なくとも委任された帯域幅の現在の量に関するNASの見解と等しくなければなりません。
o If the AN received the request, the allocated amount in the AN's response MUST be no greater than the AN's view of the current amount of delegated bandwidth.
o ANが要求を受信した場合、ANの応答で割り当てられた量は、委任された帯域幅の現在の量に関するANの見解よりも大きくてはなりません（MUST）。
The exception is when the NAS receives a request while it has a request of its own outstanding. Handling of that case is described below.
例外は、NASが独自の未処理の要求を持っているときにNASが要求を受信した場合です。その場合の扱いを以下に示します。
Note: While the cases just described are an error condition, the success response achieves a graceful recovery.
注：今説明したケースはエラー条件ですが、成功の応答によって正常な回復が実現されます。
To avoid deadlock due to race conditions, the following rules MUST be applied:
競合状態によるデッドロックを回避するには、次のルールを適用する必要があります。
a. If the NAS receives a Bandwidth Reallocation Request message while it has a Bandwidth Reallocation Request message of its own outstanding for the same access line, the NAS MUST provide an immediate failure response to the request from the AN, with a Result Code value set to 0x68 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth request conflict" as applicable. (See below for more information).
a. NASが同じアクセス回線に対して独自の未処理の帯域幅再割り当て要求メッセージを持っているときに、帯域幅再割り当て要求メッセージを受信した場合、NASは、ANからの要求に対して、結果コード値を0x68に設定して、即時の失敗応答を提供する必要があります。 「委任された帯域幅の量の一貫性のないビュー」または0x69「帯域幅要求の競合」（該当する場合）。 （詳細については、以下を参照してください）。
b. If the AN receives a Bandwidth Reallocation Request message while it has a Bandwidth Reallocation Request message of its own outstanding for the same access line, the AN MUST release any bandwidth it has already committed to an outstanding join request while it is awaiting a response from the NAS. It MUST decide upon and send its response to the NAS taking the released bandwidth into account.
b。 ANが同じアクセス回線に対して独自の未解決の帯域幅再割り当て要求メッセージを持っているときに、ANが帯域幅再割り当て要求メッセージを受信した場合、ANは、ANからの応答を待っている間に、未処理の参加要求にすでにコミットしている帯域幅を解放する必要があります。 NAS。解放された帯域幅を考慮して、応答を決定し、NASに送信する必要があります。
If the receiver is unable to process the Bandwidth Reallocation Request message due to an error, then the receiver MUST return a Bandwidth Transfer message where:
エラーが原因で受信者が帯域幅再割り当て要求メッセージを処理できない場合、受信者は次の場合に帯域幅転送メッセージを返す必要があります。
o the Result field is set to Failure (0x4),
o 結果フィールドは失敗（0x4）に設定されます。
o the Result Code field is set appropriately to indicate the type of error that was detected,
o 結果コードフィールドが適切に設定され、検出されたエラーのタイプを示します。
o the Bandwidth-Allocation TLV contains the value of the current amount of delegated bandwidth as the responder views it, and
o Bandwidth-Allocation TLVには、レスポンダが表示するときの委任された帯域幅の現在の値が含まれます。
o a Status-Info TLV MAY follow the Bandwidth-Allocation TLV giving further information about the error.
o Status-Info TLVは、帯域幅割り当てTLVの後に続き、エラーに関する詳細情報を提供する場合があります。
This specification provides three new Result Code values applicable specifically to the contents of the Bandwidth-Request TLV. These Result Code values by their nature MUST only be used when the error is being reported in a Bandwidth Transfer message rather than a Generic Response message.
この仕様は、Bandwidth-Request TLVのコンテンツに特に適用可能な3つの新しい結果コード値を提供します。これらの結果コードの値は、その性質上、Generic ResponseメッセージではなくBandwidth Transferメッセージでエラーが報告されている場合にのみ使用する必要があります。
0x67 Invalid preferred bandwidth amount.
0x67無効な優先帯域幅の量。
Where detected: control application at the receiver of the Bandwidth Reallocation Request message.
検出された場所：帯域幅再割り当て要求メッセージの受信側の制御アプリケーション。
Further description: the preferred and required amounts of bandwidth in the TLV do not have the numerical relationship described above.
詳細説明：TLVの帯域幅の推奨量と必要量には、上記の数値関係はありません。
Required additional information in the message: as described above.
メッセージに必要な追加情報：上記のとおり。
Target: control application at the sender of the Bandwidth Reallocation Request message.
ターゲット：帯域幅再割り当て要求メッセージの送信側のアプリケーションを制御します。
Action RECOMMENDED for the receiving ANCP agent: report the error to the control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
受信側のANCPエージェントに推奨されるアクション：帯域幅割り当てTLVの戻り値を使用して、制御アプリケーションにエラーを報告します。セクション4.6.2.2も参照してください。
0x68 Inconsistent views of delegated bandwidth amount.
0x68委任された帯域幅の量の一貫性のないビュー。
Where detected: control application at the NAS.
検出された場所：NASでのアプリケーションの制御。
Further description: the NAS has an outstanding Bandwidth Reallocation Request, so it is rejecting a similar request from the AN. In the AN request, the required amount was less than the NAS's view of the current amount of delegated bandwidth.
詳細説明：NASには未処理の帯域幅再割り当て要求があるため、ANからの同様の要求を拒否しています。 AN要求では、必要な量は、委任された帯域幅の現在の量に関するNASの見解よりも少なかった。
Required additional information in the message: as described above.
メッセージに必要な追加情報：上記のとおり。
Target: control application at the AN.
ターゲット：ANでの制御アプリケーション。
Action RECOMMENDED for the receiving ANCP agent: report the error to the AN control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
受信側のANCPエージェントに推奨されるアクション：エラーを帯域幅割り当てTLVの戻り値とともにAN制御アプリケーションに報告します。セクション4.6.2.2も参照してください。
0x69 Bandwidth request conflict.
0x69帯域幅要求の競合。
Where detected: control application at the NAS.
検出された場所：NASでのアプリケーションの制御。
Further description: the NAS has an outstanding Bandwidth Reallocation Request, so it is rejecting a similar, valid request from the AN.
詳細説明：NASには未処理の帯域幅再割り当て要求があるため、ANからの同様の有効な要求を拒否しています。
Required additional information in the message: as described above.
メッセージに必要な追加情報：上記のとおり。
Target: control application at the AN.
ターゲット：ANでの制御アプリケーション。
Action RECOMMENDED for the receiving ANCP agent: report the error to the AN control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
受信側のANCPエージェントに推奨されるアクション：エラーを帯域幅割り当てTLVの戻り値とともにAN制御アプリケーションに報告します。セクション4.6.2.2も参照してください。
The Bandwidth Transfer message is used to transfer video bandwidth from the sender to the peer for a specific access line. This message MAY be sent either from the AN or from the NAS. As described in the previous section, it is the required response to a valid Bandwidth Reallocation Request message.
Bandwidth Transferメッセージは、送信者から特定のアクセス回線のピアにビデオ帯域幅を転送するために使用されます。このメッセージは、ANまたはNASから送信される場合があります。前のセクションで説明したように、これは有効な帯域幅再割り当て要求メッセージに対する必須の応答です。
The Bandwidth Transfer message MAY also be used to transfer bandwidth autonomously from one peer to another. One example of this usage is to release bandwidth borrowed earlier by means of the Bandwidth Reallocation Request message. When the message is used in this way, the Result field in the Bandwidth Transfer message MUST be set to Ignore (0x0).
帯域幅転送メッセージは、1つのピアから別のピアに自律的に帯域幅を転送するためにも使用される場合があります。この使用法の1つの例は、Bandwidth Reallocation Requestメッセージを使用して以前に借用した帯域幅を解放することです。この方法でメッセージを使用する場合、帯域幅転送メッセージの結果フィールドを無視（0x0）に設定する必要があります。
Note: This allows the receiver to distinguish between an autonomous transfer and a response to a previous Bandwidth Reallocation Request message, for purposes of validation.
注：これにより、受信者は検証のために、自律転送と前の帯域幅再割り当て要求メッセージへの応答を区別できます。
The Message Type for the Bandwidth Transfer message is 147. The Bandwidth Transfer message contains the following TLVs:
Bandwidth Transferメッセージのメッセージタイプは147です。BandwidthTransferメッセージには、次のTLVが含まれています。
o the Target TLV, designating the access line concerned;
o 関連するアクセス回線を指定するターゲットTLV。
o an instance of the Bandwidth-Allocation TLV (Section 5.5). The bandwidth value in the Bandwidth-Allocation TLV is the new amount of delegated bandwidth allocated to the target.
o 帯域幅割り当てTLVのインスタンス（セクション5.5）。 Bandwidth-Allocation TLVの帯域幅の値は、ターゲットに割り当てられた新しい委任された帯域幅の量です。
When sending a Bandwidth Transfer message where the Result value is Ignore (0x0) or Success (0x3), the following relationships MUST hold:
結果値が無視（0x0）または成功（0x3）である帯域幅転送メッセージを送信するときは、次の関係が保持されている必要があります。
o If the message is sent by the NAS, the bandwidth value in the Bandwidth-Allocation TLV MUST be greater than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned.
o メッセージがNASによって送信される場合、Bandwidth-Allocation TLVの帯域幅値は、関係するアクセス回線の委任された帯域幅の現在の量の送信者の見解以上である必要があります。
o If the message is sent by the AN, the bandwidth value in the Bandwidth-Allocation TLV MUST be less than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned.
o メッセージがANによって送信される場合、Bandwidth-Allocation TLVの帯域幅の値は、関係するアクセス回線の委任された帯域幅の現在の量についての送信者のビュー以下である必要があります。
Further sender behavior is specified above, in Section 4.5.2.
送信者のさらなる動作は、セクション4.5.2で指定されています。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is not greater than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Bandwidth Transfer message. This is required regardless of whether the Result field of that message indicates Success or Failure.
Bandwidth-Allocation TLVで提供される委任された帯域幅の量が、NASの現在の委任された帯域幅の量のビューよりも大きくない場合、NASは現在の委任された帯域幅の量のビューを帯域幅転送メッセージで示された量に更新する必要があります。 。これは、そのメッセージのResultフィールドが成功か失敗かを問わず必要です。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new value of delegated bandwidth. Alternatively, the NAS MAY force the AN to modify its view of the amount of delegated bandwidth to that held by the NAS by sending a Port Management message for the target access line concerned that contains a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wishes to enforce.
Bandwidth-Allocation TLVで提供される委任された帯域幅の量が、現在の委任された帯域幅の量のNASのビューよりも大きい場合、NASは指定された値を委任された帯域幅の新しい値として受け入れることができます。あるいは、NASは、ANに、委任された帯域幅の量のビューを、NASが保持するものに強制的に変更し、量に等しい値を持つBandwidth-Allocation TLVを含む、関連するターゲットアクセス回線のポート管理メッセージを送信することができます。 NASが強制したい委任された帯域幅の。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV of the Bandwidth Transfer message differs from the AN's view of the current amount of delegated bandwidth, the AN MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Bandwidth Transfer message. This is required with the exception of a Bandwidth Transfer message with a Result field equal to Failure (0x4) and a Result Code field equal to 0x68 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth request conflict". If Result Code value 0x68 is received, the AN MUST issue a Delegated Bandwidth Query Request message to determine the NAS's current view of the amount of delegated bandwidth. The AN MUST update its own view based on the value returned in the Delegated Bandwidth Query Response message. If Result Code value 0x69 is received, the AN SHOULD carry out this procedure unless it can account for the discrepancy as a result of a transfer of bandwidth to the NAS that was carried out just before the incoming Bandwidth Transfer message was processed.
帯域幅転送メッセージの帯域幅割り当てTLVで提供される委任された帯域幅の量が、委任された帯域幅の現在の量に関するANの見解と異なる場合、ANは、委任された帯域幅の現在の量の見解を、帯域幅転送メッセージ。これは、結果フィールドが失敗（0x4）であり、結果コードフィールドが0x68 "委任された帯域幅量の一貫性のないビュー"または0x69 "帯域幅要求の競合"である帯域幅転送メッセージを除いて必要です。結果コード値0x68が受信された場合、ANは委任された帯域幅クエリ要求メッセージを発行して、委任された帯域幅の量に関するNASの現在のビューを決定する必要があります。 ANは、Delegated Bandwidth Query Responseメッセージで返された値に基づいて、独自のビューを更新する必要があります。結果コード値0x69を受信した場合、着信帯域幅転送メッセージが処理される直前に実行されたNASへの帯域幅の転送の結果としての不一致を説明できない限り、ANはこの手順を実行する必要があります（SHOULD）。
Note: The two Result Code values indicate a race condition where the AN may have just completed a transfer of bandwidth to the NAS. As a result, the value given in the Bandwidth Transfer message may be outdated, and the AN needs to query the NAS to find its latest view. The procedure assumes that ordering is preserved between the Bandwidth Transfer message sent by the AN in response to the NAS's request and the subsequent Delegated Bandwidth Query Request message.
注：2つの結果コード値は、ANが帯域幅のNASへの転送を完了したばかりの競合状態を示しています。その結果、Bandwidth Transferメッセージで指定された値が古くなっている可能性があり、ANはNASに照会して最新のビューを見つける必要があります。この手順では、NASの要求に応答してANから送信された帯域幅転送メッセージと後続の委任帯域幅クエリ要求メッセージの間で順序が保持されることを前提としています。
If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN MAY attempt to correct the situation by sending a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message.
帯域幅割り当てTLVで指定された量を超えるマルチキャスト帯域幅をANがすでにコミットしている場合、ローカルポリシーでそのようなアクションが必要でない限り、ANは帯域幅を新しい制限内に下げるためにマルチキャストストリームを中断しないでください。ただし、ANは、帯域幅割り当てTLVで指定された制限内で許可できるまで、アドミッション制御の対象となる新しいマルチキャストストリームを許可してはなりません。セクション6.2.5.2で指定されているように、ANは、Bandwidth Reallocation Requestメッセージを使用して委任された帯域幅の割り当ての増加を求める要求をNASに送信することにより、状況を修正しようとします。
The Message Type for the Delegated Bandwidth Query Request (and Response) messages is 148.
Delegated Bandwidth Query Request（and Response）メッセージのメッセージタイプは148です。
The Delegated Bandwidth Query Request message MAY be sent either by the NAS or by the AN to retrieve the peer's view of the amount of delegated bandwidth. The request contains one TLV:
委任された帯域幅クエリ要求メッセージは、委任された帯域幅の量のピアのビューを取得するために、NASまたはANのいずれかによって送信される場合があります。リクエストには1つのTLVが含まれています。
o a Target TLV designating the access line for which the information is requested.
o 情報が要求されるアクセス回線を指定するターゲットTLV。
The sender MUST set the Result field in the header of the Delegated Bandwidth Query Request message to AckAll (0x2). The Result Code value MUST be set to 0. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
送信者は、Delegated Bandwidth Query RequestメッセージのヘッダーのResultフィールドをAckAll（0x2）に設定する必要があります。 [RFC6320]のセクション3.6.1.6で説明されているように、結果コードの値は0に設定する必要があります。送信者は、ANCPトランザクション識別子フィールドに一意の値を設定する必要があります。
If the AN or NAS receives a valid Delegated Bandwidth Query Request message, it MUST respond with a Delegated Bandwidth Query Response message. The Result field in the header of the response MUST be set to Success (0x3). The Result Code field MUST be set to 0. The Transaction Identifier field MUST be copied from the request message. The body of the response MUST contain the Target TLV, copied from the request message. Finally, the body of the response MUST contain a Bandwidth-Allocation TLV, containing the current amount of delegated bandwidth from the point of view of the receiver of the request.
ANまたはNASが有効な委任帯域幅クエリ要求メッセージを受信した場合、それは委任帯域幅クエリ応答メッセージで応答する必要があります。応答のヘッダーの結果フィールドは成功（0x3）に設定する必要があります。結果コードフィールドは0に設定する必要があります。トランザクション識別子フィールドは、要求メッセージからコピーする必要があります。応答の本文には、要求メッセージからコピーされたターゲットTLVが含まれている必要があります。最後に、応答の本文には、要求の受信者の観点からの委任された帯域幅の現在の量を含むBandwidth-Allocation TLVを含める必要があります。
If the contents of the Delegated Bandwidth Query Request message are in error, the receiver MUST return a Delegated Bandwidth Query Response message with the Result field in the header set to Failure (0x3). The Result Code field MUST be set to the value that indicates the nature of the error (e.g., 0x500 "One or more of the specified ports do not exist"). The Transaction Identifier field MUST be copied from the request. The body of the response MUST contain the Target TLV copied from the request. This MAY be followed by a Status-Info TLV giving further information about the error.
Delegated Bandwidth Query Requestメッセージの内容にエラーがある場合、受信者はヘッダーのResultフィールドがFailure（0x3）に設定されたDelegated Bandwidth Query Responseメッセージを返す必要があります。結果コードフィールドは、エラーの性質を示す値に設定する必要があります（例：0x500「指定されたポートの1つ以上が存在しません」）。 Transaction Identifierフィールドは、リクエストからコピーする必要があります。応答の本文には、要求からコピーされたターゲットTLVが含まれている必要があります。この後には、エラーに関する詳細情報を提供するStatus-Info TLVが続く場合があります。
The Delegated Bandwidth Query Response message is sent in reply to a Delegated Bandwidth Query Request message. The response to a valid request contains two TLVs: o the Target TLV, copied from the request; and
Delegated Bandwidth Query Responseメッセージは、Delegated Bandwidth Query Requestメッセージへの応答として送信されます。有効な要求への応答には、2つのTLVが含まれます。o要求からコピーされたターゲットTLV。そして
o a Bandwidth-Allocation TLV, giving the responder's view of the current amount of multicast bandwidth delegated to the AN.
o 帯域幅割り当てTLV。ANに委任されたマルチキャスト帯域幅の現在の量をレスポンダに表示します。
The Message Type for the Delegated Bandwidth Query Response message is 148.
Delegated Bandwidth Query Responseメッセージのメッセージタイプは148です。
Sender behavior for the Delegated Bandwidth Query Response message is specified in Section 4.7.2.
Delegated Bandwidth Query Responseメッセージの送信者の動作は、セクション4.7.2で指定されています。
If the Delegated Bandwidth Query Response message indicates Success (0x3), the actions described in Sections 4.8.2.1 and 4.8.2.2 apply.
Delegated Bandwidth Query ResponseメッセージがSuccess（0x3）を示している場合は、セクション4.8.2.1および4.8.2.2で説明されているアクションが適用されます。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is less than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Delegated Bandwidth Query Response message.
Bandwidth-Allocation TLVで提供された委任された帯域幅の量が、NASの現在の委任された帯域幅の量のビューよりも少ない場合、NASは、委任された帯域幅の現在の量のビューを委任された帯域幅クエリ応答で示された量に更新する必要があります。メッセージ。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new value of delegated bandwidth. Alternatively, the NAS MAY force the AN to modify its view of the amount of delegated bandwidth to that held by the NAS by sending a Port Management message for the target access line concerned that contains a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wishes to enforce.
Bandwidth-Allocation TLVで提供される委任された帯域幅の量が、現在の委任された帯域幅の量のNASのビューよりも大きい場合、NASは指定された値を委任された帯域幅の新しい値として受け入れることができます。あるいは、NASは、ANに、委任された帯域幅の量のビューを、NASが保持するものに強制的に変更し、量に等しい値を持つBandwidth-Allocation TLVを含む、関連するターゲットアクセス回線のポート管理メッセージを送信することができます。 NASが強制したい委任された帯域幅の。
The AN SHOULD accept the value returned in the Bandwidth-Allocation TLV of the Delegated Bandwidth Query Response message as the correct value of the current amount of delegated bandwidth. If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN
ANは、委任された帯域幅クエリ応答メッセージの帯域幅割り当てTLVで返された値を、委任された帯域幅の現在の量の正しい値として受け入れる必要があります（SHOULD）。帯域幅割り当てTLVで指定された量を超えるマルチキャスト帯域幅をANがすでにコミットしている場合、ローカルポリシーでそのようなアクションが必要でない限り、ANは帯域幅を新しい制限内に下げるためにマルチキャストストリームを中断しないでください。ただし、ANは、帯域幅割り当てTLVで指定された制限内で許可できるまで、アドミッション制御の対象となる新しいマルチキャストストリームを許可してはなりません。セクション6.2.5.2で指定されているように、AN
MAY attempt to correct the situation by sending a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message.
Bandwidth Reallocation Requestメッセージを使用して委任された帯域幅の割り当ての増加を求める要求をNASに送信することにより、状況を修正しようとする場合があります。
Note: A race condition is possible where the AN sends a query, the NAS requests more bandwidth, then receives and responds to the query, and then receives the Bandwidth Transfer message responding to its request. It is up to the AN to take appropriate action in this case. The best action appears to be not to act on the result of the first query but to repeat the query after sending the Bandwidth Transfer message. Similar considerations apply to a race between queries from both sides.
注：ANがクエリを送信し、NASがより多くの帯域幅を要求し、クエリを受信して応答し、その要求に応答する帯域幅転送メッセージを受信する場合、競合状態が発生する可能性があります。この場合に適切なアクションをとるのはANです。最良のアクションは、最初のクエリの結果ではなく、帯域幅転送メッセージを送信した後にクエリを繰り返すことです。同様の考慮事項が、両側からのクエリ間の競合にも適用されます。
This section defines two new messages called the Multicast Flow Query Request and Multicast Flow Query Response. The Multicast Flow Query Request message is sent by the NAS to request information about the multicast flows that are active on the AN. The Multicast Flow Query Response message is sent in response by the AN to provide the requested information to the NAS.
このセクションでは、マルチキャストフロークエリ要求とマルチキャストフロークエリ応答と呼ばれる2つの新しいメッセージを定義します。マルチキャストフロークエリ要求メッセージは、ANでアクティブなマルチキャストフローに関する情報を要求するためにNASによって送信されます。マルチキャストフロークエリ応答メッセージは、要求された情報をNASに提供するために、ANからの応答として送信されます。
The Message Type for the Multicast Flow Query Request and Multicast Flow Query Response messages is 149.
マルチキャストフロークエリ要求およびマルチキャストフロークエリ応答メッセージのメッセージタイプは149です。
The contents of the Multicast Flow Query Request and Multicast Flow Query Response messages depend on the nature of the query, as described below.
マルチキャストフロークエリ要求メッセージとマルチキャストフロークエリ応答メッセージの内容は、以下で説明するように、クエリの性質によって異なります。
The sender of a Multicast Flow Query Request message MUST set the Result field to AckAll (0x2). The Result Code field MUST be set to 0x000. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
マルチキャストフロークエリ要求メッセージの送信者は、結果フィールドをAckAll（0x2）に設定する必要があります。結果コードフィールドは0x000に設定する必要があります。 [RFC6320]のセクション3.6.1.6で説明されているように、送信者はANCPトランザクション識別子フィールドに一意の値を設定する必要があります。
The Multicast Flow Query Request message MAY be used by the NAS to retrieve:
マルチキャストフロークエリ要求メッセージは、NASが次のものを取得するために使用できます。
o the AN's view of which multicast flows are currently active on a specified set of access ports; or
o 指定されたアクセスポートのセットで現在アクティブなマルチキャストフローに関するANのビュー。または
o the AN's view of the access ports on which a specified set of multicast flows are currently active; or
o 指定されたマルチキャストフローのセットが現在アクティブであるアクセスポートのANのビュー。または
o the AN's view of all the multicast flows currently active on each access port of the AN.
o ANの各アクセスポートで現在アクティブなすべてのマルチキャストフローのANのビュー。
To retrieve the AN's view of which multicast flows are currently active on a given port of the AN, the NAS MUST include a Target TLV in the Multicast Flow Query Request payload identifying that port. The Target TLV is encoded as specified in [RFC6320].
どのマルチキャストフローが現在ANの特定のポートでアクティブであるかについてのANのビューを取得するには、NASは、そのポートを識別するマルチキャストフロークエリ要求ペイロードにターゲットTLVを含める必要があります。ターゲットTLVは、[RFC6320]で指定されているようにエンコードされます。
To retrieve the AN's view of the ports currently receiving a given multicast flow, the NAS MUST include a Multicast-Flow TLV in the Multicast Flow Query Request payload identifying that flow. The Multicast-Flow TLV is encoded as specified in Section 5.12.
特定のマルチキャストフローを現在受信しているポートのANのビューを取得するには、NASは、そのフローを識別するマルチキャストフロークエリ要求ペイロードにマルチキャストフローTLVを含める必要があります。 Multicast-Flow TLVは、セクション5.12で指定されているようにエンコードされます。
The NAS MAY include multiple Target TLVs or multiple Multicast-Flow TLVs in the Multicast Flow Query Request message but MUST NOT include both Target and Multicast-Flow TLVs in the same message.
NASは、マルチキャストフロークエリリクエストメッセージに複数のターゲットTLVまたは複数のマルチキャストフローTLVを含めることができますが、同じメッセージにターゲットTLVとマルチキャストフローTLVの両方を含めることはできません。
To retrieve the AN's view of all of the multicast flows currently active on each port of the AN, the NAS MUST send a Multicast Flow Query Request message that does not contain any instance of the Target TLV or the Multicast-Flow TLV.
ANの各ポートで現在アクティブなすべてのマルチキャストフローのANのビューを取得するには、NASは、ターゲットTLVまたはマルチキャストフローTLVのインスタンスを含まないマルチキャストフロークエリ要求メッセージを送信する必要があります。
The AN MUST respond to a Multicast Flow Query Request message that has a valid format and a valid content with a Multicast Flow Query Response message. The Result field in the response MUST be set to Success (0x3). The Result Code field MUST be set to 0. The Transaction Identifier field MUST be copied from the request.
ANは、有効なフォーマットと有効なコンテンツを持つマルチキャストフロークエリ要求メッセージにマルチキャストフロークエリ応答メッセージで応答する必要があります。応答のResultフィールドは成功（0x3）に設定する必要があります。結果コードフィールドは0に設定する必要があります。トランザクション識別子フィールドはリクエストからコピーする必要があります。
If the Multicast Flow Query Request contains one (or more) Target TLVs, the AN MUST include, for each of these Target TLVs, the following set of TLVs:
マルチキャストフロークエリ要求に1つ（または複数）のターゲットTLVが含まれている場合、ANはこれらの各ターゲットTLVについて、次のTLVセットを含める必要があります。
o Target TLV. This MUST be identical to the Target TLV in the received Multicast Flow Query Request message.
o ターゲットTLV。これは、受信したマルチキャストフロークエリ要求メッセージのターゲットTLVと同一である必要があります。
o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per multicast flow that is currently active on the AN port identified in the preceding Target TLV.
o マルチキャストフローTLV。マルチキャストフローTLVは、先行するターゲットTLVで識別されたANポートで現在アクティブなマルチキャストフローごとに1回出現する必要があります。
The Target TLVs MUST appear in the response from the AN in the same order as in the query from the NAS.
ターゲットTLVは、NASからのクエリと同じ順序でANからの応答に表示される必要があります。
If the Multicast Flow Query Request message contains one (or more) Multicast-Flow TLVs, the AN MUST include, for each of these Multicast-Flow TLVs, the following set of TLVs:
マルチキャストフロークエリ要求メッセージに1つ（または複数）のマルチキャストフローTLVが含まれている場合、ANは、これらのマルチキャストフローTLVごとに、次のTLVセットを含める必要があります。
o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow TLV in the received Multicast Flow Query Request message.
o マルチキャストフローTLV。これは、受信したマルチキャストフロークエリ要求メッセージのマルチキャストフローTLVと同一である必要があります。
o Target TLV(s). The Target TLV MUST appear once per AN port on which the multicast flow identified in the preceding Multicast-Flow TLV is active.
o ターゲットTLV。ターゲットTLVは、前述のマルチキャストフローTLVで識別されたマルチキャストフローがアクティブなANポートごとに1回出現する必要があります。
The Multicast-Flow TLVs MUST appear in the response from the AN in the same order as in the query from the NAS.
マルチキャストフローTLVは、NASからのクエリと同じ順序でANからの応答に表示される必要があります。
If the Multicast Flow Query Request message contains no Target TLV and no Multicast Flow TLV, the AN MUST include, for each AN port currently receiving multicast flow(s), the following set of TLVs:
マルチキャストフロークエリ要求メッセージにターゲットTLVとマルチキャストフローTLVが含まれていない場合、ANは、現在マルチキャストフローを受信している各ANポートに対して、次のTLVセットを含める必要があります。
o Target TLV. This MUST identify one AN port.
o ターゲットTLV。これは1つのANポートを識別する必要があります。
o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per Multicast Flow that is currently active on the AN port identified in the preceding Target TLV.
o マルチキャストフローTLV。マルチキャストフローTLVは、先行するターゲットTLVで識別されたANポートで現在アクティブなマルチキャストフローごとに1回出現する必要があります。
If the contents of the Multicast Flow Query Request message are in error, the AN MUST reply with a Multicast Flow Query Response message with the Result field set to Failure (0x4) and the Result Code field set to indicate the nature of the error. If the request contained multiple instances of the Target TLV or the Multicast-Flow TLV and one of these is in error, the response message MUST contain the results for the preceding instances of the TLV as if there had been no error. These successful results MUST be followed by the TLV in error, copied from the request. The AN MUST NOT do further processing of the request. The AN MAY add a Status-Info TLV to provide further information on the nature of the error.
マルチキャストフロークエリリクエストメッセージのコンテンツにエラーがある場合、ANは、結果フィールドがエラー（0x4）に設定され、結果コードフィールドがエラーの性質を示すように設定されたマルチキャストフロークエリ応答メッセージで応答する必要があります。リクエストにターゲットTLVまたはマルチキャストフローTLVの複数のインスタンスが含まれていて、これらの1つがエラーである場合、エラーがないかのように、応答メッセージにTLVの先行インスタンスの結果が含まれている必要があります。これらの成功した結果には、要求からコピーされた、エラーのあるTLVが続く必要があります。 ANはリクエストのさらなる処理を行ってはなりません。 ANは、Status-Info TLVを追加して、エラーの性質に関する詳細情報を提供できます。
This section describes the Committed Bandwidth Report message, which is sent from the AN to the NAS to report the most recent amount of multicast bandwidth usage committed to one or more access lines.
このセクションでは、1つまたは複数のアクセス回線にコミットされた最新のマルチキャスト帯域幅使用量を報告するためにANからNASに送信されるCommitted Bandwidth Reportメッセージについて説明します。
The Message Type for the Committed Bandwidth Report message is 150.
Committed Bandwidth Reportメッセージのメッセージタイプは150です。
The Committed Bandwidth Report message contains one or more instances of the Committed-Bandwidth TLV, as described in Section 5.14.
認定帯域幅レポートメッセージには、セクション5.14で説明されているように、認定帯域幅TLVの1つ以上のインスタンスが含まれています。
The sender of a Committed Bandwidth Report message MUST set the Result field to Ignore (0x0). The Result Code field MUST be set to 0x000. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
Committed Bandwidth Reportメッセージの送信者は、ResultフィールドをIgnore（0x0）に設定する必要があります。結果コードフィールドは0x000に設定する必要があります。 [RFC6320]のセクション3.6.1.6で説明されているように、送信者はANCPトランザクション識別子フィールドに一意の値を設定する必要があります。
Each instance of the Committed-Bandwidth TLV included in the message MUST identify an access line for which the amount of committed multicast bandwidth has changed since the previous Committed Bandwidth Report message was sent and MUST report the latest amount of multicast bandwidth committed to that line. There MUST be only one instance of the Committed-Bandwidth TLV present in the message for any given access line. The message MUST include an instance of the Committed-Bandwidth TLV for every access line for which committed multicast bandwidth has changed since the previous Committed Bandwidth Report message was sent.
メッセージに含まれるCommitted-Bandwidth TLVの各インスタンスは、前のCommitted Bandwidth Reportメッセージが送信されてからコミットされたマルチキャスト帯域幅の量が変更されたアクセス回線を識別し、その回線にコミットされたマルチキャスト帯域幅の最新の量を報告する必要があります。特定のアクセス回線のメッセージには、Committed-Bandwidth TLVのインスタンスが1つだけ存在している必要があります。メッセージには、以前のCommitted Bandwidth Reportメッセージが送信されてからコミットされたマルチキャスト帯域幅が変更されたすべてのアクセス回線のCommitted-Bandwidth TLVのインスタンスが含まれている必要があります。
Further behavior at the AN is specified in Section 6.2.2.
ANでのさらなる動作は、セクション6.2.2で指定されています。
The usage of the contents of a Committed Bandwidth Report message received by the NAS is implementation-dependent. One example is that the NAS uses the reports of multicast bandwidth commitments to adjust its forwarding scheduler operation to provide the intended level of QoS.
NASが受信したCommitted Bandwidth Reportメッセージの内容の使用は、実装によって異なります。 1つの例は、NASがマルチキャスト帯域幅コミットメントのレポートを使用して、転送スケジューラーの動作を調整し、意図したレベルのQoSを提供することです。
The NAS MUST NOT reply to a valid Committed Bandwidth Report message. The NAS MAY send a Generic Response message indicating the nature of any errors detected in a Committed Bandwidth Report message that it has received.
NASは、有効なCommitted Bandwidth Reportメッセージに応答してはなりません（MUST NOT）。 NASは、受信したCommitted Bandwidth Reportメッセージで検出されたエラーの性質を示すGeneric Responseメッセージを送信する場合があります。
This section defines new ANCP TLVs for the control of multicast flows.
このセクションでは、マルチキャストフローを制御するための新しいANCP TLVを定義します。
This document defines the new Multicast-Service-Profile TLV.
このドキュメントでは、新しいMulticast-Service-Profile TLVを定義しています。
The Multicast-Service-Profile TLV MAY be included in a Provisioning message as specified in Section 4.1.
マルチキャストサービスプロファイルTLVは、セクション4.1で指定されているように、プロビジョニングメッセージに含めることができます。
The Multicast-Service-Profile TLV is illustrated in Figure 7. It consists of a TLV header encapsulating a single instance of the Multicast-Service-Profile-Name TLV and one or more instances of the List-Action TLV.
Multicast-Service-Profile TLVを図7に示します。これは、Multicast-Service-Profile-Name TLVの単一インスタンスと、List-Action TLVの1つ以上のインスタンスをカプセル化するTLVヘッダーで構成されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Multicast-Service-Profile TLV
図7：マルチキャストサービスプロファイルTLV
The Multicast-Service-Profile TLV has the following fields:
Multicast-Service-Profile TLVには次のフィールドがあります。
o TLV Type: 0x0013
o TLVタイプ：0x0013
o TLV Length: determined by the contents following the TLV header.
o TLV長：TLVヘッダーに続く内容によって決定されます。
o Multicast-Service-Profile-Name TLV: described in Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain an identifier that is unique over all profiles provisioned to the same AN partition. This identifier will be used to refer to the profile when activating it for a given target within a Port Management message (see Section 4.2).
o Multicast-Service-Profile-Name TLV：セクション5.2で説明。 Multicast-Service-Profile-Name TLVには、同じANパーティションにプロビジョニングされたすべてのプロファイルで一意の識別子を含める必要があります。この識別子は、ポート管理メッセージ内の特定のターゲットに対してプロファイルをアクティブにするときにプロファイルを参照するために使用されます（セクション4.2を参照）。
o List-Action TLV: described in Section 5.3. The List-Action TLV(s) provide the content of a newly defined multicast service profile or modify the existing content. If more than one List-Action TLV is present, the order of the TLVs may be significant, since List-Action TLVs are processed in the order in which they appear.
o List-Action TLV：セクション5.3で説明。 List-Action TLVは、新しく定義されたマルチキャストサービスプロファイルのコンテンツを提供するか、既存のコンテンツを変更します。複数のリストアクションTLVが存在する場合、リストアクションTLVは出現順に処理されるため、TLVの順序が重要になることがあります。
The Multicast-Service-Profile-Name TLV carries the identifier of a multicast service profile provisioned on the AN. It is illustrated in Figure 8.
Multicast-Service-Profile-Name TLVは、ANでプロビジョニングされたマルチキャストサービスプロファイルの識別子を伝達します。これを図8に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Multicast-Service-Profile-Name TLV
図8：Multicast-Service-Profile-Name TLV
The Multicast-Service-Profile-Name TLV has the following fields:
Multicast-Service-Profile-Name TLVには次のフィールドがあります。
o TLV Type: 0x0018
o TLVタイプ：0x0018
o TLV Length: up to 255 octets.
o TLV長：最大255オクテット。
o Multicast service profile identifier: an opaque sequence of octets identifying a specific multicast service profile.
o マルチキャストサービスプロファイル識別子：特定のマルチキャストサービスプロファイルを識別するオクテットの不透明なシーケンス。
Note: The identifier could have the form of human-readable text or an arbitrary binary value, depending on the operator's practices.
注：識別子は、オペレーターの慣例に応じて、人間が読める形式のテキストまたは任意のバイナリ値を持つことができます。
The List-Action TLV identifies multicast flows to be added to or removed from a list of white-, black-, or grey-listed flows. It is meaningful only in association with a Multicast-Service-Profile-Name TLV identifying the profile to which the List-Action TLV applies. Such an association can be achieved by placing both TLVs in the same base message payload or as embedded TLVs of another TLV such as the Multicast-Service-Profile TLV. The List-Action TLV is shown in Figure 9.
リストアクションTLVは、ホワイト、ブラック、またはグレーリストのフローのリストに追加または削除されるマルチキャストフローを識別します。これは、List-Action TLVが適用されるプロファイルを識別するMulticast-Service-Profile-Name TLVとの関連でのみ意味があります。このような関連付けは、両方のTLVを同じベースメッセージペイロードに配置するか、Multicast-Service-Profile TLVなどの別のTLVの埋め込みTLVとして配置することで実現できます。リストアクションTLVを図9に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation | List Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: List-Action TLV
図9：リストアクションTLV
The List-Action TLV contains the following fields:
List-Action TLVには、次のフィールドが含まれています。
o TLV Type: 0x0021
o TLVタイプ：0x0021
o TLV Length: length of the subsequent contents.
o TLV長：後続のコンテンツの長さ。
o Operation: operation to be performed upon the white, black, or grey list identified by the List Type field within the profile identified by the associated Multicast-Service-Profile-Name embedded TLV. The possible values are:
o 操作：関連するMulticast-Service-Profile-Name埋め込みTLVで識別されるプロファイル内のリストタイプフィールドで識別されるホワイト、ブラック、またはグレーリストに対して実行される操作。可能な値は次のとおりです。
* 1 "Add": the multicast flow fields are to be added to the list.
* 1「追加」：マルチキャストフローフィールドをリストに追加します。
* 2 "Delete": the multicast flow fields are to be removed from the list. Each multicast flow field in the List-Action MUST match exactly an existing entry in the list concerned. Thus, to remove part of the range provided by a wildcarded list entry, it is necessary to remove the entire entry and add back the remaining partial range(s).
* 2「削除」：マルチキャストフローフィールドをリストから削除します。 List-Actionの各マルチキャストフローフィールドは、関係するリストの既存のエントリと正確に一致する必要があります。したがって、ワイルドカードリストエントリによって提供される範囲の一部を削除するには、エントリ全体を削除して、残りの部分的な範囲を追加し直す必要があります。
* 3 "Replace": the multicast flow fields replace the existing contents of the list.
* 3 "Replace"：マルチキャストフローフィールドは、リストの既存のコンテンツを置き換えます。
o List Type: the list type being modified by this List-Action TLV. The possible values are 1 "White", 2 "Black", or 3 "Grey".
o リストタイプ：このリストアクションTLVによって変更されるリストタイプ。可能な値は、1 "白"、2 "黒"、または3 "灰色"です。
o Reserved: a sender MUST set this field to zeroes. A receiver MUST ignore the contents of this field.
o 予約済み：送信者はこのフィールドをゼロに設定する必要があります。受信者は、このフィールドの内容を無視する必要があります。
o Address Family: the IP version of the set of multicast flow fields that follow, encoded according to [PIMreg]. Possible values are 1 "IPv4" or 2 "IPv6". Either an IPv4 list or an IPv6 list or both MAY be present in the List-Action TLV.
o アドレスファミリ：後続のマルチキャストフローフィールドのセットのIPバージョン。[PIMreg]に従ってエンコードされます。可能な値は、1 "IPv4"または2 "IPv6"です。 IPv4リストまたはIPv6リストのいずれか、あるいは両方がList-Action TLVに存在する場合があります。
o Number of flow fields: the number of multicast flow fields of the given address family that follows.
o フローフィールドの数：後に続く特定のアドレスファミリのマルチキャストフローフィールドの数。
o Multicast flow field: a field identifying one or more multicast flows. It consists of an 8-bit group address prefix length, an 8-bit source address prefix length, a group prefix of 0-16 octets, and a source prefix of 0-16 octets, as shown in Figure 10.
o マルチキャストフローフィールド：1つ以上のマルチキャストフローを識別するフィールド。これは、図10に示すように、8ビットのグループアドレスプレフィックス長、8ビットのソースアドレスプレフィックス長、0-16オクテットのグループプレフィックス、および0-16オクテットのソースプレフィックスで構成されます。
Each multicast flow field refers either to a Source-Specific Multicast (SSM) channel or to an Any-Source Multicast (ASM) group. The scope of the designation may be broadened to multiple channels or groups through use of prefix length values smaller than the total address length for the given address family. Multicast flow fields MUST be placed consecutively within the embedded TLV without intervening padding except to round out individual addresses to the nearest octet boundary.
各マルチキャストフローフィールドは、Source-Specific Multicast（SSM）チャネルまたはAny-Source Multicast（ASM）グループを参照します。指定の範囲は、特定のアドレスファミリの合計アドレス長よりも小さいプレフィックス長の値を使用することにより、複数のチャネルまたはグループに拡大できます。マルチキャストフローフィールドは、個々のアドレスを最も近いオクテット境界に丸める場合を除いて、埋め込みパディングなしで埋め込みTLV内に連続して配置する必要があります。
A multicast flow field consists of two single-octet prefix lengths followed by zero to two prefix values as shown in Figure 10:
マルチキャストフローフィールドは、図10に示すように、2つの単一オクテットプレフィックス長とそれに続く0〜2つのプレフィックス値で構成されます。
+-+-+-+-+-+-+-+-+
| Group PrefLen |
+-+-+-+-+-+-+-+-+
| Source PrefLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Prefix (multicast) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix (unicast, SSM only) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Organization of a Single Multicast Flow Field
図10：単一のマルチキャストフローフィールドの構成
The prefix length has its usual meaning. It is the number of most-significant bits specified within the corresponding prefix. The prefix length MAY vary from 0 to 32 in the IPv4 sub-list and from 0 to 128 in the IPv6 sub-list.
プレフィックス長には通常の意味があります。これは、対応するプレフィックス内で指定された最上位ビットの数です。プレフィックス長は、IPv4サブリストでは0から32まで、IPv6サブリストでは0から128までさまざまです（MAY）。
A value of 0 for either the Group PrefLen (prefix length) or the Source PrefLen indicates that any value of the corresponding address will match (wildcard). If the value 0 is provided for a particular prefix length, the corresponding prefix MUST be omitted from the field contents.
Group PrefLen（プレフィックス長）またはSource PrefLenのいずれかの値が0の場合、対応するアドレスの任意の値が一致することを示します（ワイルドカード）。特定のプレフィックス長に値0が指定されている場合は、対応するプレフィックスをフィールドの内容から省略する必要があります。
The length of a Source or Group Prefix field is equal to (PrefLen + 7)/8 octets, truncated to the nearest integer. Unused bits at the end of the prefix MUST be set to zeroes.
SourceまたはGroup Prefixフィールドの長さは、（PrefLen + 7）/ 8オクテットに等しく、最も近い整数に切り捨てられます。プレフィックスの最後の未使用ビットはゼロに設定する必要があります。
The Sequence-Number TLV conveys a sequence number of some sort. The specific meaning of the sequence number is message-specific. Within this specification, the Sequence-Number TLV is used as an embedded TLV in a Status-Info TLV in a Generic Response message reporting a failed command in a Multicast Replication Control or Multicast Admission Request message. It identifies the sequence number within the message of the command that failed.
シーケンス番号TLVは、ある種のシーケンス番号を伝えます。シーケンス番号の具体的な意味はメッセージ固有です。この仕様では、シーケンス番号TLVは、マルチキャストレプリケーションコントロールまたはマルチキャストアドミッションリクエストメッセージの失敗したコマンドを報告するGeneric ResponseメッセージのStatus-Info TLVの埋め込みTLVとして使用されます。失敗したコマンドのメッセージ内のシーケンス番号を識別します。
The Sequence-Number TLV has the format shown in Figure 11.
シーケンス番号TLVの形式は、図11に示されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Sequence-Number 0x0022 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Sequence-Number TLV
図11：シーケンス番号TLV
The Sequence-Number TLV has the following fields:
シーケンス番号TLVには次のフィールドがあります。
o TLV Type: 0x0022
o TLVタイプ：0x0022
o TLV Length: 4
o TLV長：4
o Sequence number: the sequence number of a specific entity within a series, where numbering starts from 1 for the first entity in the series. Represented as a 32-bit binary number, most significant bit first.
o シーケンス番号：シリーズ内の特定のエンティティのシーケンス番号。シリーズの最初のエンティティの番号は1から始まります。 32ビットの2進数として表され、最上位ビットが最初です。
The Bandwidth-Allocation TLV is used to indicate the total amount of video bandwidth delegated to the AN for multicast admission control for a given access line, in kilobits per second. The TLV has the format shown in Figure 12.
帯域幅割り当てTLVは、所定のアクセス回線のマルチキャストアドミッション制御のためにANに委任されたビデオ帯域幅の総量をキロビット/秒で示すために使用されます。 TLVのフォーマットは、図12に示されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Bandwidth-Allocation TLV
図12：帯域幅割り当てTLV
The Bandwidth-Allocation TLV has the following fields:
帯域幅割り当てTLVには次のフィールドがあります。
o TLV Type: 0x0015
o TLVタイプ：0x0015
o TLV Length: 4
o TLV長：4
o Delegated amount: the bandwidth amount delegated to the AN for admission of multicast video on a given port, kilobits per second. Represented as a 32-bit binary value, most significant bit first.
o 委任された量：特定のポートでのマルチキャストビデオのアドミッションのためにANに委任された帯域幅の量（キロビット/秒）。 32ビットのバイナリ値として表され、最上位ビットが最初です。
The White-List-CAC TLV is used to indicate that the NAS wishes the AN to do admission control for white-listed flows. Details on when the White-List-CAC TLV may be provisioned are specified in Section 6. The White-List-CAC TLV is illustrated in Figure 13.
ホワイトリストCAC TLVは、NASがANにホワイトリストフローのアドミッション制御を行うことを希望することを示すために使用されます。ホワイトリストCAC TLVがプロビジョニングされるタイミングの詳細については、セクション6で説明します。ホワイトリストCAC TLVを図13に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: White-List-CAC TLV
図13：ホワイトリストCAC TLV
The White-List-CAC TLV contains the following fields:
ホワイトリストCAC TLVには、次のフィールドが含まれています。
o TLV Type: 0x0024
o TLVタイプ：0x0024
o TLV Length: 0, since the TLV contains no data other than the TLV header.
o TLVの長さ：0。TLVにはTLVヘッダー以外のデータが含まれていないため。
The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to do admission control for flows added by the Multicast Replication Control message. Details on when the MRepCtl-CAC TLV may be provisioned are specified in Section 6. The MRepCtl-CAC TLV is illustrated in Figure 14.
MRepCtl-CAC TLVは、NASがANにマルチキャストレプリケーションコントロールメッセージによって追加されたフローのアドミッションコントロールを行うことを希望することを示すために使用されます。 MRepCtl-CAC TLVがプロビジョニングされるタイミングの詳細については、セクション6で説明します。MRepCtl-CACTLVを図14に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: MRepCtl-CAC TLV
図14：MRepCtl-CAC TLV
The MRepCtl-CAC TLV contains the following fields:
MRepCtl-CAC TLVには、次のフィールドが含まれています。
o TLV Type: 0x0025
o TLVタイプ：0x0025
o TLV Length: 0, since the TLV contains no data other than the TLV header.
o TLVの長さ：0。TLVにはTLVヘッダー以外のデータが含まれていないため。
The Bandwidth-Request TLV is used to request an adjustment of the total amount of video bandwidth allocated to the AN for multicast admission control for a given line. The "Required amount" field indicates the minimum adjustment required to meet the request. The "Preferred amount" field indicates the adjustment the requestor would prefer to have, if possible. Section 4.5 discusses the required relationships between the "Required amount", "Preferred amount", and current values of total bandwidth allocated to the AN.
Bandwidth-Request TLVは、所定の回線のマルチキャストアドミッション制御のためにANに割り当てられたビデオ帯域幅の総量の調整を要求するために使用されます。 「必要量」フィールドは、要求を満たすために必要な最小調整を示します。 「希望額」フィールドは、可能であれば、依頼者が希望する調整を示します。セクション4.5では、「必要な量」、「好ましい量」、およびANに割り当てられた合計帯域幅の現在の値の間の必要な関係について説明します。
The Bandwidth-Request TLV has the format shown in Figure 15.
Bandwidth-Request TLVの形式は、図15に示されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Bandwidth-Request TLV
図15：帯域幅要求TLV
The Bandwidth-Request TLV has the following fields:
Bandwidth-Request TLVには次のフィールドがあります。
o TLV Type: 0x0016
o TLVタイプ：0x0016
o TLV Length: 8 octets
o TLV長：8オクテット
o Required amount: the minimum or maximum amount, depending on whether the sender is the AN or the NAS respectively, of delegated video bandwidth that is being requested, in kilobits per second. Represented as a 32-bit binary value, most significant bit first.
o 必要な量：要求されている委任されたビデオ帯域幅の送信者がそれぞれANであるかNASであるかに応じて、1秒あたりのキロビット単位の最小または最大量。 32ビットのバイナリ値として表され、最上位ビットが最初です。
o Preferred amount: the preferred amount of delegated video bandwidth that is being requested, in kilobits per second. Represented as a 32-bit binary value, most significant bit first.
o 推奨量：要求されている委任されたビデオ帯域幅の推奨量（キロビット/秒）。 32ビットのバイナリ値として表され、最上位ビットが最初です。
The Request-Source-IP TLV provides the IP address of the entity that originated a specific request to join or leave a multicast channel. The TLV is illustrated in Figure 16.
Request-Source-IP TLVは、マルチキャストチャネルに参加または脱退するための特定の要求を発信したエンティティのIPアドレスを提供します。 TLVを図16に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Request-Source-IP | TLV Length = 4 or 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Request-Source-IP TLV
図16：要求元IP TLV
The Request-Source-IP TLV contains the following fields:
Request-Source-IP TLVには、次のフィールドが含まれています。
o TLV Type: 0x0092
o TLVタイプ：0x0092
o TLV Length: 4 for an IPv4 address or 16 for an IPv6 address.
o TLV長：IPv4アドレスの場合は4、IPv6アドレスの場合は16。
o Unicast address: IP address of the source of a multicast flow join request, in network byte order.
o ユニキャストアドレス：マルチキャストフロー参加要求の送信元のIPアドレス（ネットワークバイト順）。
The Request-Source-MAC TLV provides the MAC address of the entity that originated a specific request to join or leave a multicast channel. The TLV is illustrated in Figure 17.
Request-Source-MAC TLVは、マルチキャストチャネルに参加または脱退するための特定の要求を発信したエンティティのMACアドレスを提供します。 TLVを図17に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Request-Source-MAC | TLV Length = 6 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+- IEEE MAC Address +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Request-Source-MAC TLV
図17：Request-Source-MAC TLV
The Request-Source-MAC TLV contains the following fields:
Request-Source-MAC TLVには、次のフィールドが含まれています。
o TLV Type: 0x0093.
o TLVタイプ：0x0093。
o TLV Length: either 6 octets (MAC-48 or EUI-48) or 8 octets (EUI-64).
o TLV長：6オクテット（MAC-48またはEUI-48）または8オクテット（EUI-64）。
o IEEE MAC Address: MAC address of the device originating the request to join a multicast flow. Within the address, bytes and bits, respectively, shall be ordered from most to least significant, consistent with [IEEE48] for MAC-48 and EUI-48 and with [IEEE64] for EUI-64.
o IEEE MACアドレス：マルチキャストフローに参加する要求を発信したデバイスのMACアドレス。アドレス内では、バイトとビットはそれぞれ、最上位から最下位の順に並べられ、MAC-48とEUI-48の[IEEE48]およびEUI-64の[IEEE64]と一致します。
Note: EUI-48 and EUI-64 are registered trademarks of the IEEE.
注：EUI-48およびEUI-64は、IEEEの登録商標です。
The Request-Source-Device-Id TLV provides a local identifier of the entity that originated a specific request to join or leave a multicast channel. The TLV is illustrated in Figure 18.
Request-Source-Device-Id TLVは、マルチキャストチャネルに参加または脱退する特定の要求を発信したエンティティのローカル識別子を提供します。 TLVを図18に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-Source-Device-Id | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Request-Source-Device-Id TLV
図18：Request-Source-Device-Id TLV
The Request-Source-Device-Id TLV contains the following fields:
Request-Source-Device-Id TLVには、次のフィールドが含まれています。
o TLV Type: 0x0096.
o TLVタイプ：0x0096。
o TLV Length: 4
o TLV長：4
o Identifier value: local device identifier value, known to the AN and AAA. Given that the scope of the identifier is a single customer network, 32 bits is a more-than-sufficient numbering space.
o 識別子の値：ローカルデバイスの識別子の値。ANおよびAAAで認識されています。識別子のスコープが単一の顧客ネットワークであることを考えると、32ビットは十分な番号付けスペースではありません。
IGMPv3 [RFC3376] and MLDv2 [RFC3810] allow multicast listeners to specify multiple source addresses for the same multicast group. Similarly, the Multicast-Flow TLV specifies a multicast flow in terms of its multicast group address and, if applicable, one or more unicast source addresses. The Multicast-Flow TLV is illustrated in Figure 19.
IGMPv3 [RFC3376]およびMLDv2 [RFC3810]では、マルチキャストリスナーが同じマルチキャストグループに複数の送信元アドレスを指定できます。同様に、Multicast-Flow TLVは、マルチキャストグループアドレス、および該当する場合は1つ以上のユニキャスト送信元アドレスの観点からマルチキャストフローを指定します。マルチキャストフローTLVを図19に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Addr Family | Number of Source Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Unicast Source Address (for SSM flows only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Multicast-Flow TLV
図19：マルチキャストフローTLV
The Multicast-Flow TLV has the following fields:
Multicast-Flow TLVには次のフィールドがあります。
o TLV Type: 0x0019
o TLVタイプ：0x0019
o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) upwards. Total length is 4 + 4*(Number of Source Addresses +1) for IPv4 or 4 + 16*(Number of Source Addresses + 1) for IPv6.
o TLVの長さ：最小8（ASM IPv4フローの場合）以上の範囲。全長は、IPv4の場合は4 + 4 *（送信元アドレスの数+1）、IPv6の場合は4 + 16 *（送信元アドレスの数+ 1）です。
o Flow Type: 1 "Any-Source Multicast (ASM)", 2 "Source-Specific Multicast (SSM)".
o フロータイプ：1 "Any-Source Multicast（ASM）"、2 "Source-Specific Multicast（SSM）"。
o Addr Family: address family of the multicast source and group addresses, encoded in accordance with the IANA "PIM Address Family" registry ([PIMreg]). 1 indicates IPv4; 2 indicates IPv6.
o Addrファミリ：IANAの「PIMアドレスファミリ」レジストリ（[PIMreg]）に従ってエンコードされた、マルチキャストソースおよびグループアドレスのアドレスファミリ。 1はIPv4を示します。 2はIPv6を示します。
o Number of Source Addresses: 0 for ASM, 1 or more for SSM.
o 送信元アドレスの数：ASMの場合は0、SSMの場合は1以上。
o Multicast Group Address: a multicast group address within the given address family. The group address MUST always be present.
o マルチキャストグループアドレス：指定されたアドレスファミリ内のマルチキャストグループアドレス。グループアドレスは常に存在している必要があります。
o Unicast Source Address: unicast address within the given address family. If the Flow Type is "ASM" (1), a source address MUST NOT be present. If the Flow Type is "SSM" (2), the number of source addresses given by the Number of Source Addresses field MUST be present.
o ユニキャスト送信元アドレス：指定されたアドレスファミリ内のユニキャストアドレス。フロータイプが「ASM」（1）の場合、送信元アドレスが存在してはなりません。フロータイプが「SSM」（2）の場合、[送信元アドレスの数]フィールドで指定された送信元アドレスの数が存在する必要があります。
The full versions of IGMPv3 and MLDv2 support both INCLUDE and EXCLUDE modes for specifying the desired sources for SSM flows. The Multicast-Flow TLV supports INCLUDE mode only. [RFC5790] (Lightweight IGMPv3 and MLDv2) provides guidance on converting EXCLUDE mode IGMP/MLD records to INCLUDE mode for the Multicast-Flow TLV.
IGMPv3とMLDv2の完全バージョンは、SSMフローに必要なソースを指定するためのINCLUDEモードとEXCLUDEモードの両方をサポートしています。 Multicast-Flow TLVは、INCLUDEモードのみをサポートします。 [RFC5790]（軽量IGMPv3およびMLDv2）は、マルチキャストフローTLVのEXCLUDEモードのIGMP / MLDレコードをINCLUDEモードに変換するためのガイダンスを提供します。
The Report-Buffering-Time TLV provides the time for which a Committed Bandwidth Report message must be held with the intention of accumulating multiple reports of changed committed multicast bandwidth in one report, to reduce the volume of messages sent to the NAS. For further information see Section 6.2.2. The TLV is illustrated in Figure 20.
Report-Buffering-Time TLVは、NASに送信されるメッセージの量を減らすために、変更されたコミット済みマルチキャスト帯域幅の複数のレポートを1つのレポートに蓄積する目的で、Committed Bandwidth Reportメッセージを保持する必要がある時間を提供します。詳細については、セクション6.2.2を参照してください。 TLVを図20に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Buffering-Time 0x0094 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffering Time (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Report-Buffering-Time TLV
図20：レポートバッファリング時間TLV
The Report-Buffering-Time TLV contains the following fields:
Report-Buffering-Time TLVには、次のフィールドが含まれています。
o TLV Type: 0x0094
o TLVタイプ：0x0094
o TLV Length: 4 octets
o TLV長：4オクテット
o Buffering Time is a 32-bit unsigned integer containing a time value in milliseconds (ms).
o バッファリング時間は、ミリ秒（ms）単位の時間値を含む32ビットの符号なし整数です。
The Committed-Bandwidth TLV identifies an access line and provides the current amount of multicast bandwidth that the AN has committed to it. The TLV is illustrated in Figure 21.
Committed-Bandwidth TLVはアクセス回線を識別し、ANがそれにコミットしたマルチキャスト帯域幅の現在の量を提供します。 TLVを図21に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed-Bandwidth 0x0095 | TLV Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Multicast Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Committed-Bandwidth TLV
図21：認定帯域幅TLV
The Committed-Bandwidth TLV contains the following fields:
認定帯域幅TLVには、次のフィールドが含まれています。
o TLV Type: 0x0095
o TLVタイプ：0x0095
o TLV Length: 4 octets plus the length of the Target TLV, including its header and any padding.
o TLVの長さ：4オクテットとターゲットTLVの長さ（ヘッダーとパディングを含む）。
o Committed Multicast Bandwidth: a 32-bit unsigned integer providing a bandwidth amount in kbits/s.
o 認定マルチキャスト帯域幅：32ビットの符号なし整数で、帯域幅の量をキロビット/秒で提供します。
o Target TLV: identifies the access line to which this amount of multicast bandwidth is currently committed.
o ターゲットTLV：この量のマルチキャスト帯域幅が現在コミットされているアクセス回線を識別します。
Section 3.5 of [RFC6320] defines a capability negotiation mechanism as well as a number of capabilities. This section defines five new capabilities in support of different modes of multicast operation:
[RFC6320]のセクション3.5は、機能ネゴシエーションメカニズムといくつかの機能を定義しています。このセクションでは、さまざまなモードのマルチキャスト操作をサポートする5つの新しい機能を定義します。
o NAS-initiated multicast replication (capability type 3);
o NASが開始するマルチキャスト複製（機能タイプ3）。
o committed bandwidth reporting (capability type 5);
o 認定帯域幅レポート（機能タイプ5）。
o conditional access and admission control with white and black lists (capability type 6);
o ホワイトリストとブラックリストを使用した条件付きアクセスとアドミッションコントロール（機能タイプ6）。
o conditional access and admission control with grey lists (capability type 7); and
o グレーリストを使用した条件付きアクセスとアドミッションコントロール（機能タイプ7）。そして
o bandwidth delegation (capability type 8).
o 帯域幅の委任（機能タイプ8）。
The "Capability Data" field within the Capability TLV for all of these capabilities is empty. All of these capabilities are independent of the access technology.
これらすべての機能の機能TLV内の「機能データ」フィールドは空です。これらの機能はすべて、アクセステクノロジーから独立しています。
The remainder of this section consists of three sub-sections. Section 6.1 specifies the protocol elements that must be implemented in order to support each capability. Section 6.2 specifies the procedures that apply to each capability on its own. Section 6.3 specifies how the capabilities interact if more than one multicast capability is included in the set of capabilities negotiated between the AN and the NAS.
このセクションの残りの部分は、3つのサブセクションで構成されています。セクション6.1では、各機能をサポートするために実装する必要があるプロトコル要素を指定しています。セクション6.2では、各機能に独自に適用される手順を指定します。セクション6.3では、ANとNASの間でネゴシエートされる機能のセットに複数のマルチキャスト機能が含まれている場合に、機能がどのように相互作用するかを指定します。
This section specifies the protocol elements that MUST be implemented to support each of the five multicast capabilities. Support of multiple multicast capabilities requires implementation of the union of the sets of protocol elements applying to each of the individual capabilities in the supported set.
このセクションでは、5つのマルチキャスト機能のそれぞれをサポートするために実装する必要があるプロトコル要素を指定します。複数のマルチキャスト機能をサポートするには、サポートされているセットの個々の機能のそれぞれに適用されるプロトコル要素のセットの和集合を実装する必要があります。
In addition to the elements listed below, implementation of the Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the capabilities specified in this document.
以下に示す要素に加えて、このドキュメントで指定されているすべての機能について、ターゲットTLV（[RFC6320]のセクション4.3）の実装が必要です。
Table 1 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the NAS-initiated multicast replication capability. Additionally, implementation of the Multicast Replication Control message requires implementation of the Command TLV (Section 4.4 of [RFC6320] with additional details in Section 4.3 of this document).
表1は、NASが開始するマルチキャストレプリケーション機能をサポートするために実装する必要があるセクション4およびセクション5内のプロトコル要素を示しています。さらに、マルチキャストレプリケーションコントロールメッセージの実装には、コマンドTLVの実装が必要です（[RFC6320]のセクション4.4、このドキュメントのセクション4.3に詳細が記載されています）。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 1: Protocol Requirements for NAS-Initiated Multicast Replication
表1：NASが開始するマルチキャストレプリケーションのプロトコル要件
6.1.2. Protocol Requirements for Committed Multicast Bandwidth Reporting
6.1.2. コミットされたマルチキャスト帯域幅レポートのプロトコル要件
Table 2 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the committed multicast bandwidth reporting capability.
表2は、セクション4およびセクション5内のプロトコル要素を示しています。これらの要素は、コミットされたマルチキャスト帯域幅レポート機能をサポートするために実装する必要があります。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Report-Buffering-Time |
| | TLV |
| | |
| Section 4.10 | Committed Bandwidth Report message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.13 | Report-Buffering-Timer TLV |
| | |
| Section 5.14 | Committed-Bandwidth TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 2: Protocol Requirements for Committed Multicast Bandwidth Reporting
表2：コミットされたマルチキャスト帯域幅レポートのプロトコル要件
6.1.3. Protocol Requirements for Conditional Access and Admission Control with White and Black Lists
6.1.3. ホワイトリストとブラックリストを使用した条件付きアクセスとアドミッションコントロールのプロトコル要件
Table 3 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the conditional access and admission control with white and black lists multicast capability.
表3は、ホワイトリストとブラックリストのマルチキャスト機能を使用した条件付きアクセスとアドミッション制御をサポートするために実装する必要があるセクション4およびセクション5内のプロトコル要素を示しています。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, white and black lists only, and |
| | White-List-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, white and black lists only |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.6 | White-List-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 3: Protocol Requirements for Conditional Access and Admission Control with White and Black Lists
表3：ホワイトリストとブラックリストを使用した条件付きアクセスとアドミッションコントロールのプロトコル要件
6.1.4. Protocol Requirements for Conditional Access and Admission Control with Grey Lists
6.1.4. グレーリストを使用した条件付きアクセスおよびアドミッションコントロールのプロトコル要件
Table 4 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the conditional access and admission control with grey lists multicast capability. Additionally, implementation of the Multicast Replication Control message requires implementation of the Command TLV (Section 4.4 of [RFC6320] with additional details in Section 4.3 of this document).
表4は、セクション4およびセクション5内のプロトコル要素を示しています。これらは、グレーリストマルチキャスト機能を使用した条件付きアクセスおよびアドミッションコントロールをサポートするために実装する必要があります。さらに、マルチキャストレプリケーションコントロールメッセージの実装には、コマンドTLVの実装が必要です（[RFC6320]のセクション4.4、このドキュメントのセクション4.3に詳細が記載されています）。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, grey lists only, and MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.4 | Multicast Admission Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV, grey lists only |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, grey lists only |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.9 | Request-Source-IP TLV |
| | |
| Section 5.10 | Request-Source-MAC TLV |
| | |
| Section 5.11 | Request-Source-Device-Id TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 4: Protocol Requirements for Conditional Access and Admission Control with Grey Lists
表4：グレーリストを使用した条件付きアクセスおよびアドミッションコントロールのプロトコル要件
Table 5 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the bandwidth delegation capability.
表5は、帯域幅委譲機能をサポートするために実装する必要があるセクション4およびセクション5内のプロトコル要素を示しています。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.5 | Bandwidth Reallocation Request message |
| | |
| Section 4.6 | Bandwidth Transfer message |
| | |
| Section 4.7 | Delegated Bandwidth Query Request message |
| | |
| Section 4.8 | Delegated Bandwidth Query Response message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.8 | Bandwidth-Request TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 5: Protocol Requirements for Bandwidth Delegation
表5：帯域幅委譲のプロトコル要件
This section describes multicast service procedures for each capability as if it were the only multicast capability within the negotiated set. Procedures involving combinations of multicast capabilities are described in Section 6.3.
このセクションでは、ネゴシエートされたセット内の唯一のマルチキャスト機能であるかのように、各機能のマルチキャストサービス手順について説明します。マルチキャスト機能の組み合わせを含む手順については、セクション6.3で説明します。
The use of the Multicast Flow Query Request and Response messages to determine the association between multicast flows and ports is common to all multicast capabilities. No additional text is required here, beyond that already given in Section 4.9 to describe the use of those messages.
マルチキャストフロークエリ要求および応答メッセージを使用して、マルチキャストフローとポート間の関連付けを決定することは、すべてのマルチキャスト機能に共通です。ここでは、これらのメッセージの使用法を説明するためにセクション4.9で既に示したものを超える追加のテキストは必要ありません。
NAS-initiated multicast replication may be negotiated to support a mode of operation where IGMP/MLD requests are terminated on the NAS. Alternatively, it may be negotiated to allow the NAS to respond to requests sent by other means (e.g., through application signaling) that require the replication of multicast channels to a given access line.
NASで開始されたマルチキャストレプリケーションは、IGMP / MLD要求がNASで終了する動作モードをサポートするためにネゴシエートされる場合があります。または、特定のアクセス回線へのマルチキャストチャネルの複製を必要とする他の手段（アプリケーションシグナリングなど）によって送信された要求にNASが応答できるように交渉することもできます。
The NAS MAY perform admission control for NAS-initiated replication. In this case, it MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. Alternatively, the NAS MAY enable admission control at the AN for NAS-initiated multicast replication. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN, and it MUST also include a Bandwidth-Allocation TLV in a Port Management message for each access line.
NASは、NASが開始したレプリケーションのアドミッションコントロールを実行できます（MAY）。この場合、ANに送信されるプロビジョニングメッセージにMRepCtl-CAC TLVを含めてはなりません（MUST NOT）。または、NASは、NASが開始するマルチキャストレプリケーションのANでアドミッションコントロールを有効にすることができます（MAY）。これを行うには、ANに送信されるプロビジョニングメッセージにMRepCtl-CAC TLVを含める必要があり、各アクセス回線のポート管理メッセージに帯域幅割り当てTLVを含める必要があります。
The procedures associated with NAS-initiated multicast replication are straightforward. To initiate replication, the NAS MUST send a Multicast Replication Control message to the AN, containing one or more commands adding flows, as described in Section 4.3.1. To terminate replication, the NAS MUST send a Multicast Replication Control message where the commands delete instead of adding the flows. The AN acts upon these messages as specified in Section 4.3.2.
NASが開始するマルチキャスト複製に関連する手順は簡単です。レプリケーションを開始するには、NASは、セクション4.3.1で説明されているように、フローを追加する1つ以上のコマンドを含むマルチキャストレプリケーションコントロールメッセージをANに送信する必要があります。レプリケーションを終了するには、NASは、コマンドを削除してフローを追加する代わりに、マルチキャストレプリケーションコントロールメッセージを送信する必要があります。 ANは、4.3.2項で指定されているように、これらのメッセージに作用します。
Committed bandwidth reporting may be negotiated if the NAS requires current knowledge of the amount of multicast bandwidth committed to each access line and cannot obtain this information by other means.
NASが各アクセス回線にコミットされたマルチキャスト帯域幅の量に関する現在の知識を必要とし、他の手段でこの情報を取得できない場合、コミットされた帯域幅の報告が交渉される場合があります。
The default buffering time when committed bandwidth reporting is enabled is zero (immediate reporting). To change this, the NAS MAY send an instance of the Report-Buffering-Time TLV containing a non-zero time value to the AN in a Provisioning message. If the NAS subsequently wishes to change the buffering time again, it MAY do so in another Provisioning message.
コミットされた帯域幅レポートが有効になっている場合のデフォルトのバッファリング時間はゼロ（即時レポート）です。これを変更するために、NASはゼロ以外の時間値を含むReport-Buffering-Time TLVのインスタンスをプロビジョニングメッセージのANに送信する場合があります。その後、NASがバッファリング時間を再度変更したい場合は、別のプロビジョニングメッセージで変更できます。
If the buffering time for committed bandwidth reporting is zero, the AN MUST send a Committed Bandwidth Report message to the NAS each time the amount of multicast bandwidth committed to any access line under its control changes.
認定帯域幅レポートのバッファリング時間がゼロの場合、ANは、制御下のアクセス回線にコミットされるマルチキャスト帯域幅の量が変化するたびに、認定帯域幅レポートメッセージをNASに送信する必要があります。
If a non-zero value is provided in the Report-Buffering-Time TLV, the AN is in one of two states at any given moment: not-buffering or buffering. The AN enters buffering state if it is in not-buffering state and the multicast bandwidth amount committed to some access line changes. It leaves buffering state when the AN sends a Committed Bandwidth Report message.
Report-Buffering-Time TLVにゼロ以外の値が指定されている場合、ANは常に、非バッファリングまたはバッファリングの2つの状態のいずれかになります。 ANが非バッファリングステートであり、一部のアクセス回線にコミットされたマルチキャスト帯域幅の量が変化すると、ANはバッファリングステートになります。 ANがCommitted Bandwidth Reportメッセージを送信すると、バッファリング状態のままになります。
Upon entry to the buffering state, the AN MUST start a buffering timer and create a Committed Bandwidth Report message containing a Committed-Bandwidth TLV for the triggering access line, but it MUST NOT send it. If a multicast bandwidth change occurs for another access line, the AN MUST add a new Committed-Bandwidth TLV to the message for that additional line. If a multicast bandwidth change occurs for a line for which a Committed-Bandwidth TLV is already present in the buffered report, the AN MUST update the corresponding Committed-Bandwidth TLV to contain the new bandwidth value rather than adding another Committed-Bandwidth TLV for the same access line.
バッファリング状態に入ると、ANはバッファリングタイマーを開始して、トリガーアクセス回線のCommitted-Bandwidth TLVを含むCommitted Bandwidth Reportメッセージを作成する必要がありますが、送信してはなりません（MUST NOT）。別のアクセス回線でマルチキャスト帯域幅の変更が発生した場合、ANはその追加回線のメッセージに新しいCommitted-Bandwidth TLVを追加する必要があります。 Committed-Bandwidth TLVがバッファリングされたレポートにすでに存在する回線でマルチキャスト帯域幅の変更が発生した場合、ANは、対応するCommitted-Bandwidth TLVを更新して、同じアクセス回線。
The buffering timer expires after the period provided by the Report-Buffering-Time TLV. When it expires, the AN MUST send the Committed Bandwidth Report message that it has been accumulating to the NAS. Exceptionally, the AN MAY choose to send the message before the timer expires, in which case it MUST clear the buffering timer when the message is sent. In either case, the AN enters the not-buffering state as a result.
バッファリングタイマーは、Report-Buffering-Time TLVで指定された期間が経過すると期限切れになります。それが期限切れになると、ANは、蓄積していることを認定帯域幅レポートメッセージとしてNASに送信する必要があります。例外的に、ANはタイマーが期限切れになる前にメッセージを送信することを選択できます。その場合、メッセージが送信されるときにバッファリングタイマーをクリアする必要があります。どちらの場合も、結果として、ANは非バッファリング状態になります。
Note: Report buffering implies that NAS reaction to changes in multicast bandwidth usage is delayed by the amount of the buffering period. The choice of buffering period must take this into consideration.
注：レポートのバッファリングは、マルチキャスト帯域幅の使用状況の変化に対するNASの反応が、バッファリング期間の分だけ遅れることを意味します。バッファリング期間の選択では、これを考慮する必要があります。
6.2.3. Procedures for Conditional Access and Admission Control with Black and White Lists
6.2.3. ブラックリストとホワイトリストを使用した条件付きアクセスとアドミッションコントロールの手順
The NAS provisions named multicast service profiles containing white and black lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required by sending additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing white and black lists or replacements for them.
NASは、1つ以上のMulticast-Service-Profile TLVを含むプロビジョニングメッセージを使用して、ANのホワイトリストとブラックリストを含む名前付きマルチキャストサービスプロファイルをプロビジョニングします。 NASは、既存のホワイトリストとブラックリストへの増分変更またはそれらの代替を含むMulticast-Service-Profile TLVを使用して追加のプロビジョニングメッセージを送信することにより、必要に応じてこれらのプロファイルのコンテンツを随時更新します。
The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast-Service-Profile-Name TLV. The NAS MAY change the multicast service profile for a given access line at any time by sending a Port Management message identifying a new multicast service profile.
NASは、Multicast-Service-Profile-Name TLVを含むポート管理メッセージを使用して、特定のマルチキャストサービスプロファイルを個々のアクセス回線に割り当てます。 NASは、新しいマルチキャストサービスプロファイルを識別するポート管理メッセージを送信することにより、特定のアクセス回線のマルチキャストサービスプロファイルをいつでも変更できます。
The NAS MAY choose to enable admission control at the AN for white-listed flows. To do this, it MUST send a Provisioning message as described in Section 4.1, which includes the White-List-CAC TLV, and it MUST provide a multicast bandwidth allocation for each access line by including a Bandwidth-Allocation TLV in a Port Management message.
NASは、ホワイトリストフローのANでアドミッションコントロールを有効にすることを選択できます。これを行うには、セクション4.1で説明されているように、ホワイトリストCAC TLVを含むプロビジョニングメッセージを送信する必要があり、ポート管理メッセージに帯域幅割り当てTLVを含めることにより、各アクセス回線にマルチキャスト帯域幅割り当てを提供する必要があります。 。
The conditional access and admission control with white and black lists capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it MUST check to see whether the requested flow is white-listed or black-listed as described below. Requests for black-listed flows MUST be discarded. If the NAS has enabled admission control on the AN as described in the previous section, but a white-listed flow would cause the amount of committed multicast bandwidth to exceed the provisioned limit, the request MUST be discarded. The AN replicates flows passing these checks to the access line.
ホワイトリストおよびブラックリスト機能を使用した条件付きアクセスおよびアドミッションコントロールは、IGMP / MLD要求がANで終了することを前提としています。 ANは参加要求を受信すると、要求されたフローが以下に説明するようにホワイトリストにあるかブラックリストにあるかを確認する必要があります。ブラックリストフローのリクエストは破棄する必要があります。前のセクションで説明したように、NASがANでアドミッションコントロールを有効にしているが、ホワイトリストのフローにより、コミットされたマルチキャスト帯域幅の量がプロビジョニングされた制限を超える場合は、要求を破棄する必要があります。 ANは、これらのチェックに合格したフローをアクセス回線に複製します。
To determine if a requested flow is white-listed, the AN searches for a best match to the flow in the applicable multicast service profile. Matching is done on the prefixes specified in the profile, ignoring the address bits of lower order than those in the prefix.
要求されたフローがホワイトリストに登録されているかどうかを判断するために、ANは、該当するマルチキャストサービスプロファイルでフローに最も一致するものを検索します。マッチングは、プロファイルで指定されたプレフィックスで行われ、プレフィックスよりも下位のアドレスビットは無視されます。
If the requested multicast flow matches multiple lists associated with the access line, then the most specific match will be considered by the AN. If the most specific match occurs in multiple lists, the black list entry takes precedence over the white list. In this context, the most specific match is defined as:
要求されたマルチキャストフローがアクセス回線に関連付けられた複数のリストと一致する場合、最も具体的な一致がANによって考慮されます。複数のリストで最も具体的な一致が発生した場合、ブラックリストのエントリがホワイトリストよりも優先されます。このコンテキストでは、最も具体的な一致は次のように定義されます。
o first, most specific match (longest prefix length) on the multicast group address (i.e., on G of <S,G>), and
o 最初に、マルチキャストグループアドレス（つまり、<S、G>のG）で最も具体的な一致（最長のプレフィックス長）、および
o then, most specific match (longest prefix length) on the unicast source address (i.e., on S of <S,G>).
o 次に、ユニキャスト送信元アドレス（つまり、<S、G>のS）で最も具体的な一致（最長のプレフィックス長）。
If the requested multicast flow is not part of any list, the join message SHOULD be discarded by the AN. This default behavior can easily be changed by means of a "catch-all" statement in the white 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.
要求されたマルチキャストフローがどのリストにも含まれていない場合、参加メッセージはANによって破棄される必要があります（SHOULD）。このデフォルトの動作は、ホワイトリストの「catch-all」ステートメントを使用して簡単に変更できます。たとえば、ホワイトリストに（<S = *、G = *>）を追加すると、他のどのリストにも一致しないマルチキャストフローの参加メッセージを受け入れるデフォルトの動作になります。
When the AN receives a leave request, it terminates replication of the multicast flow.
ANが脱退要求を受信すると、ANはマルチキャストフローの複製を終了します。
If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile is currently assigned. Similarly, if a Port Management message assigns a new multicast service profile to a given port, the AN MUST review all active flows on that port. If the most specific match for any flow is a black list entry, the flow MUST be terminated immediately. If any of the remaining flows do not match an entry in the white list, they also MUST be terminated immediately. White-listed flows MUST be allowed to continue.
ANが既存のマルチキャストサービスプロファイルを更新するプロビジョニングメッセージを受信した場合、ANは、更新されたプロファイルが現在割り当てられているすべてのポートのアクティブフローのステータスを確認する必要があります。同様に、ポート管理メッセージが特定のポートに新しいマルチキャストサービスプロファイルを割り当てる場合、ANはそのポートのすべてのアクティブフローを確認する必要があります。フローの最も具体的な一致がブラックリストエントリである場合、フローは直ちに終了する必要があります。残りのフローのいずれかがホワイトリストのエントリと一致しない場合、それらもすぐに終了する必要があります。ホワイトリストに記載されたフローは続行を許可する必要があります。
6.2.4. Procedures for Conditional Access and Admission Control with Grey Lists
6.2.4. グレーリストを使用した条件付きアクセスとアドミッションコントロールの手順
The NAS provisions named multicast service profiles containing grey lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required by sending additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing grey lists or replacements for them.
NASは、1つ以上のMulticast-Service-Profile TLVを含むプロビジョニングメッセージを使用して、AN上のグレーリストを含む名前付きマルチキャストサービスプロファイルをプロビジョニングします。 NASは、既存のグレーリストへの増分変更またはそれらの置換を含むMulticast-Service-Profile TLVを使用して追加のプロビジョニングメッセージを送信することにより、必要に応じてこれらのプロファイルのコンテンツを随時更新する場合があります。
The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast-Service-Profile-Name TLV. The NAS MAY change profiles on the line by sending a subsequent Port Management message identifying a new profile.
NASは、Multicast-Service-Profile-Name TLVを含むポート管理メッセージを使用して、特定のマルチキャストサービスプロファイルを個々のアクセス回線に割り当てます。 NASは、新しいプロファイルを識別する後続のポート管理メッセージを送信して、回線上のプロファイルを変更する場合があります。
The NAS MAY perform admission control for grey-listed flows. In that case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. Alternatively, the NAS MAY enable admission control at the AN for grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST also provide a Bandwidth-Allocation TLV in a Port Management message for each access line.
NASはグレーリストのフローのアドミッションコントロールを実行できます（MAY）。その場合、NASは、ANに送信されるプロビジョニングメッセージにMRepCtl-CAC TLVを含めてはなりません（MUST NOT）。あるいは、NASはグレーリストのフローのANでアドミッション制御を有効にすることができます（MAY）。これを行うには、ANに送信されるプロビジョニングメッセージにMRepCtl-CAC TLVを含める必要があり、各アクセス回線のポート管理メッセージに帯域幅割り当てTLVも提供する必要があります。
The conditional access and admission control with grey lists capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it MUST determine whether there is a match to the requested flow in the grey list of the multicast service profile provisioned against the given access line. If there is no match, the request is discarded. Otherwise, the AN MUST send a Multicast Admission Control message to the NAS with content identifying the access line and the multicast flow to be added. As indicated in Section 4.4, the AN MAY add information identifying the requesting device.
グレーリスト機能を備えた条件付きアクセスおよびアドミッションコントロールは、IGMP / MLD要求がANで終了することを前提としています。 ANは加入要求を受信すると、指定されたアクセス回線に対してプロビジョニングされたマルチキャストサービスプロファイルのグレーリストに、要求されたフローとの一致があるかどうかを判断する必要があります。一致しない場合、要求は破棄されます。それ以外の場合、ANは、追加するアクセス回線とマルチキャストフローを識別するコンテンツを含むマルチキャストアドミッションコントロールメッセージをNASに送信する必要があります。セクション4.4に示すように、ANは要求元デバイスを識別する情報を追加してもよい（MAY）。
If the NAS decides to enable the flow, it MUST send a Multicast Replication Control message to the AN to replicate the flow to the access line with the Result field set to Nack (0x1), as described in Section 4.3.1.
NASがフローを有効にすることを決定した場合、セクション4.3.1で説明されているように、結果フィールドがNack（0x1）に設定されたアクセスラインにフローを複製するために、マルチキャスト複製制御メッセージをANに送信する必要があります。
When the AN receives the Multicast Replication Control message, it performs admission control if that has been enabled as described in the previous section. If admitting the flow would cause the committed multicast bandwidth at the access line to exceed the provisioned limit, the AN reports an error to the NAS as described in Section 4.3.2. Otherwise, it replicates the multicast flow as requested.
ANがマルチキャストレプリケーションコントロールメッセージを受信すると、前のセクションで説明したようにアドミッションコントロールが有効になっている場合は、それを実行します。フローを許可すると、アクセス回線でコミットされたマルチキャスト帯域幅がプロビジョニングされた制限を超える場合、セクション4.3.2で説明されているように、ANはNASにエラーを報告します。それ以外の場合は、要求に応じてマルチキャストフローを複製します。
If the NAS decides not to permit the flow, it MAY send a Multicast Replication Control message in response to the Multicast Admission Control message to allow the AN to update its internal records. The content of this message is described in Section 4.4.2.
NASがフローを許可しないと決定した場合、NASはマルチキャストアドミッションコントロールメッセージに応答してマルチキャストレプリケーションコントロールメッセージを送信して、ANが内部レコードを更新できるようにする場合があります。このメッセージの内容については、セクション4.4.2で説明します。
When the AN receives a leave request, it MUST terminate replication of the flow to the access line. It MUST then send a Multicast Admission Control message to the NAS indicating the deletion. The NAS updates its internal records but MUST NOT respond to the message.
ANが脱退要求を受信すると、アクセス回線へのフローの複製を終了する必要があります。次に、削除を示すマルチキャストアドミッションコントロールメッセージをNASに送信する必要があります。 NASは内部レコードを更新しますが、メッセージに応答してはなりません（MUST NOT）。
If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile has been assigned. Similarly, if the AN receives a Port Management message that assigns a new profile to a given port, the AN MUST review all active flows on that port. In either case, if any flow does not match an entry in the grey list, it MUST be terminated immediately.
ANが既存のマルチキャストサービスプロファイルを更新するプロビジョニングメッセージを受信した場合、ANは、更新されたプロファイルが割り当てられているすべてのポートのアクティブフローのステータスを確認する必要があります。同様に、ANが新しいプロファイルを特定のポートに割り当てるポート管理メッセージを受信した場合、ANはそのポート上のすべてのアクティブフローを確認する必要があります。どちらの場合も、フローがグレイリストのエントリと一致しない場合、すぐに終了する必要があります。
The NAS SHOULD provision an initial amount of delegated multicast bandwidth for each access line using the Port Management message containing the Bandwidth-Allocation TLV.
NASは、帯域幅割り当てTLVを含むポート管理メッセージを使用して、各アクセス回線に委任されたマルチキャスト帯域幅の初期量をプロビジョニングする必要があります（SHOULD）。
Note: If it fails to do so and a value has not been provisioned on the AN by other means, the AN will be forced to request a bandwidth allocation as soon as it receives a join request.
注：それができず、値が他の方法でANにプロビジョニングされていない場合、ANは、参加要求を受信するとすぐに、帯域幅割り当てを要求するよう強制されます。
The NAS MAY, at any time, force an update of the amount of delegated bandwidth by the same means.
NASはいつでも、同じ方法で委任された帯域幅の量を強制的に更新できます。
The bandwidth delegation capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it checks whether it has sufficient remaining uncommitted multicast bandwidth on the access line to accommodate the new multicast flow. If not, it MAY send a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message. The NAS MUST return a Bandwidth Transfer message indicating whether it has granted the request and, if so, the new amount of delegated bandwidth.
帯域幅委任機能は、IGMP / MLD要求がANで終了することを前提としています。 ANは加入要求を受信すると、新しいマルチキャストフローに対応するために、アクセス回線にコミットされていないマルチキャスト帯域幅が十分に残っているかどうかを確認します。そうでない場合は、Bandwidth Reallocation Requestメッセージを使用して、委任された帯域幅の割り当ての増加を求める要求をNASに送信する場合があります。 NASは、要求を許可したかどうかを示す帯域幅転送メッセージを返す必要があります。許可した場合は、委任された新しい帯域幅の量が返されます。
If the AN has sufficient uncommitted multicast capacity to admit the request, either originally or as the result of a successful request to the NAS, it replicates the requested flow to the access line. Otherwise, it discards the request.
最初に、またはNASへの要求が成功した結果として、ANが要求を受け入れるのに十分な未確定のマルチキャスト容量を持っている場合、ANは要求されたフローをアクセス回線に複製します。それ以外の場合は、要求を破棄します。
When the AN receives a leave request for an active flow, it ceases replication.
ANはアクティブフローの脱退要求を受信すると、複製を中止します。
The NAS or AN MAY, at some point, detect that their respective views of the amount of delegated bandwidth are inconsistent. If so, they can recover using procedures described in Sections 4.5 and 4.6. As a further aid to synchronization, either the NAS or the AN MAY from time to time check the peer's view of the amount of delegated bandwidth using the Delegated Bandwidth Query message.
NASまたはANは、ある時点で、委任された帯域幅の量に関するそれぞれの見方に一貫性がないことを検出する場合があります。その場合は、セクション4.5および4.6で説明されている手順を使用して回復できます。同期をさらに支援するために、NASまたはANのいずれかが、委任された帯域幅クエリメッセージを使用して、委任された帯域幅の量についてピアのビューを時々チェックする場合があります。
The NAS or AN MAY, at any time, release bandwidth to the peer using an autonomous Bandwidth Transfer message. The contents of this message are described in Section 4.6.
NASまたはANは、自律帯域幅転送メッセージを使用して、いつでもピアに帯域幅を解放できます。このメッセージの内容については、セクション4.6で説明します。
6.3.1. Combination of Conditional Access and Admission Control with White and Black Lists and Conditional Access and Admission Control with Grey Lists
6.3.1. 条件付きアクセスおよびアドミッションコントロールとホワイトリストおよびブラックリストの組み合わせ、条件付きアクセスおよびアドミッションコントロールとグレーリストの組み合わせ
If conditional access and admission control with white and black lists is combined with conditional access and admission control with grey lists, provisioning of the multicast service profiles is as described in Section 6.2.3.1 except that multicast service profiles will also include grey lists. Admission control is enabled independently on the AN for white lists by including the White-List-CAC TLV in the Provisioning message and for grey lists by including the MRepCtl-CAC TLV in the Provisioning message. The Bandwidth-Allocation TLV provisions an amount that applies to both white- and grey-listed flows if admission control is enabled for both.
ホワイトリストとブラックリストを使用した条件付きアクセスとアドミッションコントロールをグレーリストを使用した条件付きアクセスとアドミッションコントロールと組み合わせる場合、マルチキャストサービスプロファイルのプロビジョニングはセクション6.2.3.1で説明したとおりですが、マルチキャストサービスプロファイルにはグレーリストも含まれます。アドミッションコントロールは、プロビジョニングメッセージにホワイトリストCAC TLVを含めることにより、ホワイトリストの場合はAN上で個別に有効になり、プロビジョニングメッセージにMRepCtl-CAC TLVを含める場合は、グレーリストの場合に有効になります。帯域幅割り当てTLVは、アドミッションコントロールが両方に対して有効になっている場合、ホワイトリストとグレーリストの両方のフローに適用される量をプロビジョニングします。
With regard to multicast service procedures, one point of difference from the individual capabilities must be noted. This is an interaction during the profile matching procedure. The AN MUST seek the best match among multiple lists as described in Section 6.2.3.2. However, if there are multiple matches of equal precision, the order of priority is black list first, grey list second, and white list last.
マルチキャストサービスの手順については、個々の機能との違いが1つあります。これは、プロファイル照合手順中の相互作用です。セクション6.2.3.2で説明されているように、ANは複数のリストの中から最適な一致を探す必要があります。ただし、同じ精度の一致が複数ある場合、優先順位は最初にブラックリスト、2番目にグレーリスト、最後にホワイトリストです。
Once profile matching has been completed, processing of a join request is as described in Section 6.2.3.2 for white- or black-listed flows or Section 6.2.4.2 for grey-listed flows. Requests that do not match any list SHOULD be discarded.
プロファイルの照合が完了すると、結合リクエストの処理は、ホワイトリストまたはブラックリストのフローの場合はセクション6.2.3.2に、グレーリストのフローの場合はセクション6.2.4.2に記載されています。どのリストにも一致しないリクエストは破棄する必要があります。
When the AN receives a leave request, it MUST terminate replication of the flow to the access line. If the flow was grey-listed, the AN MUST then send a Multicast Admission Control message to the NAS indicating the deletion.
ANが脱退要求を受信すると、アクセス回線へのフローの複製を終了する必要があります。フローがグレーリストに記載されている場合、ANは削除を示すマルチキャストアドミッションコントロールメッセージをNASに送信する必要があります。
If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile is currently assigned. Similarly, if a Port Management message assigns a new multicast service profile to a given port, the AN MUST review all active flows on that port. If any flow has its most specific match in a black list entry, it MUST be terminated immediately. If any of the remaining flows do not match an entry in the white or grey list, they MUST also be terminated immediately. Finally, if any remaining flows were originally admitted because they were white-listed but after the change they are grey-listed, the AN MUST generate a Multicast Flow Query Response message autonomously as if it were responding to a Multicast Flow Query Request message, listing all such flows. These flows MUST be allowed to continue until the NAS or the subscriber terminates them. Flows with their most specific match in the white list MUST be allowed to continue.
ANが既存のマルチキャストサービスプロファイルを更新するプロビジョニングメッセージを受信した場合、ANは、更新されたプロファイルが現在割り当てられているすべてのポートのアクティブフローのステータスを確認する必要があります。同様に、ポート管理メッセージが特定のポートに新しいマルチキャストサービスプロファイルを割り当てる場合、ANはそのポートのすべてのアクティブフローを確認する必要があります。フローのブラックリストエントリに最も具体的な一致がある場合、そのフローは直ちに終了する必要があります。残りのフローのいずれかがホワイトリストまたはグレーリストのエントリと一致しない場合、それらもすぐに終了する必要があります。最後に、残りのフローがホワイトリストに載っていたために元々許可されていたが、変更後はグレーリストに載っていた場合、ANは、マルチキャストフロークエリ要求メッセージに応答しているかのように、自律的にマルチキャストフロークエリ応答メッセージを生成する必要があります。そのようなすべてのフロー。これらのフローは、NASまたはサブスクライバーがフローを終了するまで継続する必要があります。ホワイトリストで最も具体的に一致するフローは続行を許可する必要があります。
The autonomously generated Multicast Flow Query Response message MUST be formatted as if it were a successful response to a request containing no Target and no Multicast-Flow TLV, as described in Section 4.9.2, with the exception that the Transaction Identifier field MUST be set to all zeroes.
自律的に生成されたマルチキャストフロークエリ応答メッセージは、セクション4.9.2で説明されているように、ターゲットおよびマルチキャストフローTLVを含まない要求に対する正常な応答であるかのようにフォーマットする必要があります。ただし、トランザクション識別子フィールドを設定する必要があります。すべてゼロに。
Note: The procedures in the previous paragraphs imply that the AN has to retain a memory of whether an admitted flow was white-listed or grey-listed at the time of its admission/readmission.
注：前の段落の手順は、許可されたフローが許可/再許可時にホワイトリストに登録されたか、グレーリストに登録されたかをANが記憶する必要があることを意味します。
6.3.2. Combination of Conditional Access and Admission Control with Bandwidth Delegation
6.3.2. 条件付きアクセスとアドミッション制御と帯域幅委譲の組み合わせ
The provisioning and bandwidth management procedures of Section 6.2.5 apply in addition to the procedures in Sections 6.2.3, 6.2.4, or 6.3.1 as applicable. Conditional access follows the rules given in those sections in terms of matching flows against white and black and/or grey lists. When admission control is enabled at the AN, the amount of bandwidth used by the AN is negotiable as described in Section 6.2.5.2.
セクション6.2.3、6.2.4、または6.3.1の手順に加えて、セクション6.2.5のプロビジョニングおよび帯域幅管理手順が適用されます。条件付きアクセスは、ホワイトリスト、ブラックリスト、および/またはグレーリストに対するフローのマッチングに関して、これらのセクションに記載されているルールに従います。アドミッションコントロールがANで有効になっている場合、セクション6.2.5.2で説明されているように、ANが使用する帯域幅の量は交渉可能です。
NAS-initiated multicast replication can coexist with the other capabilities, but some means must exist to prevent double replication of flows. The simplest way to do this is to terminate all IGMP/MLD requests on the AN, so that NAS-initiated multicast replication is stimulated only by signaling through other channels. Other arrangements are possible but need not be discussed here.
NASが開始するマルチキャスト複製は他の機能と共存できますが、フローの二重複製を防ぐためにいくつかの手段が必要です。これを行う最も簡単な方法は、AN上のすべてのIGMP / MLD要求を終了することです。これにより、NASが開始するマルチキャストレプリケーションは、他のチャネルを介したシグナリングによってのみ刺激されます。他の配置も可能ですが、ここで説明する必要はありません。
Assuming the necessary separation of responsibilities, the only point of interaction between NAS-initiated multicast replication and the other multicast capabilities is in the area of admission control. Specifically, if the AN is to do admission control for flows added by Multicast Replication Control messages, regardless of whether they are part of NAS-initiated replication or grey list multicast service processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning message and the Bandwidth-Allocation TLV in a Port Management message. If, instead, the NAS will do admission control for flows added by Multicast Replication Control messages, regardless of whether they are part of NAS-initiated replication or grey list multicast service processing, it does not send the MRepCtl-CAC TLV in a Provisioning message to the AN. The NAS can independently enable admission control for white flows on the AN by including the White-List-CAC TLV in the Provisioning message.
必要な責任の分離を前提として、NASが開始するマルチキャストレプリケーションと他のマルチキャスト機能との間の相互作用の唯一のポイントは、アドミッションコントロールの領域にあります。具体的には、ANがマルチキャストレプリケーションコントロールメッセージによって追加されたフローのアドミッションコントロールを行う場合、それらがNASによって開始されたレプリケーションの一部であるか、グレイリストマルチキャストサービス処理の一部であるかに関係なく、NASはプロビジョニングメッセージにMRepCtl-CAC TLVを含めます。ポート管理メッセージの帯域幅割り当てTLV。代わりに、NASがマルチキャスト開始レプリケーションまたはグレイリストマルチキャストサービス処理の一部であるかどうかに関係なく、NASがマルチキャストレプリケーションコントロールメッセージによって追加されたフローのアドミッションコントロールを行う場合、プロビジョニングメッセージでMRepCtl-CAC TLVを送信しませんANに。 NASは、プロビジョニングメッセージにホワイトリストCAC TLVを含めることにより、AN上のホワイトフローのアドミッションコントロールを個別に有効にすることができます。
6.3.4. Combinations of Committed Bandwidth Reporting with Other Multicast Capabilities
6.3.4. 認定帯域幅レポートと他のマルチキャスト機能の組み合わせ
Committed bandwidth reporting can take place independently of other multicast capabilities that have been negotiated. However, some combinations do not make sense because of redundancy. In particular, the NAS obtains the same information that committed bandwidth reporting gives if the only other capabilities operating are NAS-initiated replication and/or conditional access and admission control with grey lists.
コミットされた帯域幅の報告は、ネゴシエートされた他のマルチキャスト機能とは無関係に実行できます。ただし、一部の組み合わせは冗長性のために意味がありません。特に、NASは、動作する他の機能がNASが開始したレプリケーションおよび/または条件付きアクセスとグレーリストによるアドミッションコントロールである場合に、コミットされた帯域幅レポートが提供するのと同じ情報を取得します。
This section deals with two sets of considerations. "Report Buffering Considerations" considers requirements for configuration in support of some of the committed bandwidth reporting capability. "Congestion Considerations" is a warning to implementors about the possibility of control-plane congestion, with suggestions for mitigation.
このセクションでは、2つの考慮事項について説明します。 「レポートバッファリングに関する考慮事項」では、一部の認定帯域幅レポート機能をサポートする構成の要件を考慮しています。 「輻輳に関する考慮事項」は、コントロールプレーンの輻輳の可能性に関する実装者への警告であり、緩和策が提案されています。
The committed bandwidth reporting capability allows the provisioning of a report buffering period to reduce the number of messages the AN passes to the NAS. An appropriate value for this period, if buffering is allowed at all, depends first on the effect of delay in reporting bandwidth changes and secondly on the rate at which bandwidth changes are expected to occur.
認定帯域幅レポート機能により、ANがNASに渡すメッセージの数を減らすためのレポートバッファリング期間のプロビジョニングが可能になります。バッファリングが許可されている場合、この期間の適切な値は、最初に帯域幅の変更の報告における遅延の影響に依存し、次に帯域幅の変更が発生すると予想される速度に依存します。
Let us assume, in the first instance, that a delay in adjusting hierarchical scheduling at the NAS causes additional bandwidth demand to be served momentarily on a best-effort basis, introducing the possibility of jitter and, more crucially, packet loss. Appendix IV of ITU-T Recommendation G.1080 [ITU-T_G.1080] indicates that the maximum tolerable duration of a loss episode is less than 16 ms. This would more likely apply in the middle of a program rather than when it was starting up but at least gives an (extremely conservative) order of magnitude for setting the buffering period.
最初に、NASでの階層型スケジューリングの調整の遅延により、ベストエフォートベースで一時的に追加の帯域幅需要が処理され、ジッターの可能性、さらに重要なことにパケット損失が発生するとします。 ITU-T勧告G.1080 [ITU-T_G.1080]の付録IVは、損失エピソードの最大許容期間が16ミリ秒未満であることを示しています。これは、起動時ではなくプログラムの途中で適用される可能性が高くなりますが、少なくともバッファリング期間を設定するための（非常に保守的な）桁を提供します。
The next question is whether enough messaging is likely to be generated that multiple bandwidth changes would be observed within such an interval. Let us consider a reasonable example in a DSL environment, where during the busiest hour of the day subscribers start watching at the rate of one program per subscriber per hour.
次の質問は、そのような間隔内で複数の帯域幅の変化が観察されるほど十分なメッセージングが生成される可能性があるかどうかです。 1日の最も忙しい時間帯に、加入者が1時間に1人の加入者につき1つのプログラムの割合で視聴を開始するDSL環境での妥当な例を考えてみましょう。
Typically, because of program scheduling, the new channel requests might be concentrated within a three-minute period, giving an effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second) * 16 ms = 0.00009 requests per buffering interval of 16 ms. With these figures, an AN serving 10,000 subscribers will report an average of 0.9 bandwidth changes per 16 ms buffering interval. It appears that buffering is worthwhile only for larger-scale deployments.
通常、プログラムのスケジュール設定により、新しいチャネルリクエストは3分以内に集中し、実効リクエストレートは1 /（3分* 60秒* 1000ミリ秒/秒）* 16ミリ秒=バッファリング間隔あたり0.00009リクエストになります。 16ミリ秒の。これらの数値により、10,000人の加入者にサービスを提供するANは、16ミリ秒のバッファリング間隔あたり平均0.9の帯域幅の変化を報告します。バッファリングは、大規模な展開でのみ価値があるようです。
Note that simple replacement of one channel with another -- channel surfing -- does not require reporting or adjustment at the NAS end.
あるチャネルを別のチャネルに単純に置き換える-チャネルサーフィン-には、NAS側でのレポートや調整は必要ありません。
Implementors must beware of the possibility that a single channel-surfing subscriber could generate enough control messaging to overload the AN or the messaging channel between the AN and the NAS. The implementation problem is to strike the right balance between minimizing the processing of requests that have been overtaken by subsequent events and meeting requirements for what is termed "channel zapping delay". Nominally, such a requirement is to be found in Section 8.1 of [ITU-T_G.1080], but unfortunately no quantitative value was available at the time of publication of this document. Implementors will therefore have to base their work on discussions with customers until standardized requirements become available. (It is possible that regional bodies or more specialized bodies have overtaken the ITU-T in this regard.)
実装者は、単一のチャネルサーフィンサブスクライバーが、ANまたはANとNASの間のメッセージングチャネルに過負荷をかけるのに十分な制御メッセージングを生成する可能性があることに注意する必要があります。実装の問題は、後続のイベントによって追い越された要求の処理を最小限に抑えることと、「チャネルザッピング遅延」と呼ばれるものの要件を満たすことの間の適切なバランスを取ることです。名目上、そのような要件は[ITU-T_G.1080]のセクション8.1に記載されていますが、残念ながら、このドキュメントの公開時点では、定量的な値はありませんでした。したがって、実装者は、標準化された要件が利用可能になるまで、顧客との話し合いに基づいて作業を行う必要があります。 （この点に関して、地域団体またはより専門的な団体がITU-Tを追い抜いた可能性があります。）
A typical strategy for minimizing the work associated with request processing includes deliberate buffering of join requests for a short period in case matching Release requests are detected, followed by discard of both requests. More generally, processing of requests from individual subscribers may be rate limited, and the global rate of messaging to the NAS can also be limited. If the AN gets overloaded, deliberate dropping of stale requests can be implemented, for some definitions of "stale".
リクエスト処理に関連する作業を最小限に抑えるための一般的な戦略には、一致するリリースリクエストが検出された場合に、ジョインリクエストを意図的に短期間バッファリングした後、両方のリクエストを破棄することが含まれます。より一般的には、個々のサブスクライバーからの要求の処理はレート制限される場合があり、NASへのメッセージングのグローバルレートも制限される場合があります。 ANが過負荷になった場合、「古い」の定義によっては、古い要求の意図的な削除を実装できます。
The security considerations of ANCP are discussed in [RFC6320] and in [RFC5713]. Multicast does not, in principle, introduce any new security considerations, although it does increase the attractiveness of ANCP as a means of denial of service (e.g., through direction of multicast streams onto the target) or theft of service.
ANCPのセキュリティに関する考慮事項は、[RFC6320]および[RFC5713]で説明されています。マルチキャストは原則として新しいセキュリティ上の考慮事項を導入しませんが、サービス拒否（たとえば、マルチキャストストリームをターゲットに送信することによる）またはサービスの盗難の手段としてANCPの魅力を高めます。
As mentioned in Section 4.4, the inclusion of the Request-Source-MAC TLV or Request-Source-IP TLV in the Multicast Admission Control message presents privacy issues. An attacker able to get access to the contents of this message would, like the content provider, be able to track consumption of multicast content to the individual device and potentially to individual persons if they are associated with particular devices. To make the connection between devices and individuals, the attacker needs to get information from sources other than ANCP, of course, but let us assume that this has happened.
セクション4.4で述べたように、マルチキャストアドミッションコントロールメッセージにRequest-Source-MAC TLVまたはRequest-Source-IP TLVを含めると、プライバシーの問題が発生します。このメッセージのコンテンツにアクセスできる攻撃者は、コンテンツプロバイダーのように、個々のデバイス、および特定のデバイスに関連付けられている場合は個人へのマルチキャストコンテンツの消費を追跡できます。デバイスと個人を接続するために、攻撃者はもちろんANCP以外のソースから情報を入手する必要がありますが、これが起こったと仮定します。
The protection specified for ANCP in [RFC6320] will apply to the transmission of the Multicast Admission Control message across the access network to the NAS. Hence, the attacker's potential points of access are between the subscriber and the AN, at the AN and at the NAS. Moreover, if the MAC or IP address are transmitted onwards from the NAS to AAA in a request for policy, that whole onward path has to be examined for vulnerability.
[RFC6320]でANCPに指定された保護は、NASへのアクセスネットワークを介したマルチキャストアドミッションコントロールメッセージの送信に適用されます。したがって、攻撃者の潜在的なアクセスポイントは、加入者とANの間、ANとNASの間です。さらに、ポリシーの要求でMACまたはIPアドレスがNASからAAAに前方に送信される場合、その前方パス全体の脆弱性を調べる必要があります。
The question is how many of these potential points of attack can be eliminated through operational practice. The segment from the subscriber through the AN itself seems out of the scope of this discussion -- protection of this segment is basic to subscriber privacy in any event and likely a business requirement. The segment from the AN to the NAS is covered by the basic ANCP protection specified in [RFC6320]. This leaves the NAS and the path between the NAS and AAA for consideration.
問題は、これらの潜在的な攻撃ポイントのいくつが運用上の実践を通じて排除できるかです。加入者からAN自体へのセグメントは、この説明の範囲外のようです。このセグメントの保護は、いかなる場合でも加入者のプライバシーの基本であり、おそらくビジネス要件です。 ANからNASへのセグメントは、[RFC6320]で指定されている基本的なANCP保護によってカバーされています。これにより、NASと、NASとAAAの間のパスが考慮されます。
The operator can eliminate the path between the NAS and AAA as a point where the attacker can access per-device information by downloading per-device policy to the NAS for all identified user devices for the particular subscriber. The NAS then selects the applicable policy based on the particular device identifier it has received. This is as opposed to the NAS sending the identifier of the device in question to AAA and getting policy just for that device.
オペレーターは、特定のサブスクライバーのすべての識別されたユーザーデバイスのデバイスごとのポリシーをNASにダウンロードすることにより、攻撃者がデバイスごとの情報にアクセスできるポイントとして、NASとAAA間のパスを排除できます。次に、NASは、受け取った特定のデバイス識別子に基づいて、該当するポリシーを選択します。これは、NASが問題のデバイスの識別子をAAAに送信し、そのデバイスのみのポリシーを取得するのとは対照的です。
The alternative is to protect the path between the NAS and AAA. If Diameter is used as the AAA protocol, Section 2.2 of [RFC6733] mandates use of IPsec, TLS/TCP, or DTLS/SCTP for that purpose. If RADIUS is used, the operator should deploy TLS transport as specified in [RFC6614].
代替策は、NASとAAA間のパスを保護することです。 DiameterがAAAプロトコルとして使用されている場合、[RFC6733]のセクション2.2では、その目的でIPsec、TLS / TCP、またはDTLS / SCTPを使用することが義務付けられています。 RADIUSを使用する場合、オペレーターは[RFC6614]で指定されているようにTLSトランスポートを展開する必要があります。
This leaves the NAS itself as a point of attack. In theory, the NAS could be eliminated if the AN remapped the requesting MAC or IP address to an identifier known to itself and AAA but not the NAS. This would require local configuration on the AN, which may be possible under some circumstances. The Request-Source-Device-Id TLV specified in Section 5.11 is available to transmit such an identifier in place of the Request-Source-MAC TLV or Request-Source-IP TLV.
これにより、NAS自体が攻撃のポイントになります。理論的には、ANが要求しているMACまたはIPアドレスを、それ自体およびAAAではなく、NASでは知られていない識別子に再マッピングした場合、NASを排除できます。これには、ANでのローカル設定が必要ですが、状況によっては可能です。セクション5.11で指定されたRequest-Source-Device-Id TLVは、Request-Source-MAC TLVまたはRequest-Source-IP TLVの代わりにそのような識別子を送信するために使用できます。
This document defines the following additional values within the "ANCP Message Types" registry:
このドキュメントでは、「ANCPメッセージタイプ」レジストリ内で次の追加の値を定義しています。
+--------------+--------------------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------------------+-----------+
| 144 | Multicast Replication Control | RFC 7256 |
| | | |
| 145 | Multicast Admission Control | RFC 7256 |
| | | |
| 146 | Bandwidth Reallocation Request | RFC 7256 |
| | | |
| 147 | Bandwidth Transfer | RFC 7256 |
| | | |
| 148 | Delegated Bandwidth Query | RFC 7256 |
| | | |
| 149 | Multicast Flow Query | RFC 7256 |
| | | |
| 150 | Committed Bandwidth Report | RFC 7256 |
+--------------+--------------------------------+-----------+
This document defines the following additional values for the "ANCP Result Codes" registry. In support of these assignments, IANA has changed the lower limit of 0x100 specified by [RFC6320] for assignments by IETF Consensus to 0x64.
このドキュメントでは、「ANCP結果コード」レジストリに次の追加の値を定義しています。これらの割り当てをサポートするために、IANAはIETFコンセンサスによる割り当ての[RFC6320]で指定された0x100の下限を0x64に変更しました。
+------------+------------------------------------------+-----------+
| Result | One-Line Description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x64 | Command error. | RFC 7256 |
| | | |
| 0x65 | Invalid flow address. | RFC 7256 |
| | | |
| 0x66 | Multicast flow does not exist. | RFC 7256 |
| | | |
| 0x67 | Invalid preferred bandwidth amount. | RFC 7256 |
| | | |
| 0x68 | Inconsistent views of delegated | RFC 7256 |
| | bandwidth amount. | |
| | | |
| 0x69 | Bandwidth request conflict. | RFC 7256 |
+------------+------------------------------------------+-----------+
This document defines the following additional values for the "ANCP
Command Codes" registry:
+----------------+--------------------------------------+-----------+
| Command Code | Command Code Directive Name | Reference |
| Value | | |
+----------------+--------------------------------------+-----------+
| 1 | Add | RFC 7256 |
| | | |
| 2 | Delete | RFC 7256 |
| | | |
| 3 | Delete All | RFC 7256 |
| | | |
| 4 | Admission Control Reject | RFC 7256 |
| | | |
| 5 | Conditional Access Reject | RFC 7256 |
| | | |
| 6 | Admission Control and Conditional | RFC 7256 |
| | Access Reject | |
+----------------+--------------------------------------+-----------+
This document defines the following additional values within the
"ANCP TLV Types" registry:
+-----------+--------------------------------+-----------+
| Type Code | TLV Name | Reference |
+-----------+--------------------------------+-----------+
| 0x0013 | Multicast-Service-Profile | RFC 7256 |
| | | |
| 0x0015 | Bandwidth-Allocation | RFC 7256 |
| | | |
| 0x0016 | Bandwidth-Request | RFC 7256 |
| | | |
| 0x0018 | Multicast-Service-Profile-Name | RFC 7256 |
| | | |
| 0x0019 | Multicast-Flow | RFC 7256 |
| | | |
| 0x0021 | List-Action | RFC 7256 |
| | | |
| 0x0022 | Sequence-Number | RFC 7256 |
| | | |
| 0x0024 | White-List-CAC | RFC 7256 |
| | | |
| 0x0025 | MRepCtl-CAC | RFC 7256 |
| | | |
| 0x0092 | Request-Source-IP | RFC 7256 |
| | | |
| 0x0093 | Request-Source-MAC | RFC 7256 |
| | | |
| 0x0094 | Report-Buffering-Time | RFC 7256 |
| | | |
| 0x0095 | Committed-Bandwidth | RFC 7256 |
| | | |
| 0x0096 | Request-Source-Device-Id | RFC 7256 |
+-----------+--------------------------------+-----------+
This document defines the following additional values for the "ANCP Capability Types" registry:
このドキュメントでは、「ANCP機能タイプ」レジストリに次の追加の値を定義しています。
+-------+-------------------------+--------+------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+-------------------------+--------+------------+-----------+
| 3 | NAS-Initiated Multicast | 0 | No | RFC 7256 |
| | Replication | | | |
| | | | | |
| 5 | Committed Bandwidth | 0 | No | RFC 7256 |
| | Reporting | | | |
| | | | | |
| 6 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | White and Black Lists | | | |
| | | | | |
| 7 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | Grey Lists | | | |
| | | | | |
| 8 | Bandwidth Delegation | 0 | No | RFC 7256 |
+-------+-------------------------+--------+------------+-----------+
The authors would like to acknowledge Wojciech Dec for providing useful input to this document, Robert Rennison for his help in shaping the definition of the Multicast-Service-Profile TLV, Shridhar Rao for his comments and suggestions, and Aniruddha A for his proposal that formed the base of the Multicast Flow Reporting solution. Philippe Champagne, Sanjay Wadhwa, and Stefaan De Cnodder provided substantial contributions on the solution for the NAS-initiated multicast control use case. Kristian Poscic provided the committed bandwidth reporting use case.
著者は、このドキュメントに有用な情報を提供してくれたWojciech Dec、Multicast-Service-Profile TLVの定義を形作ったRobert Rennison、コメントと提案にShridhar Rao、そして形成された彼の提案にAniruddha Aを認めたいと思います。マルチキャストフローレポートソリューションのベース。 Philippe Champagne、Sanjay Wadhwa、およびStefaan De Cnodderは、NASが開始するマルチキャスト制御の使用事例のソリューションに多大な貢献をしました。 Kristian Poscicは、コミットされた帯域幅レポートのユースケースを提供しました。
Thanks to the Document Shepherd, Matthew Bocci, and Area Director, Ted Lemon, for points raised by their reviews following Working Group Last Call.
Document ShepherdのMatthew BocciとArea DirectorのTed Lemonに感謝します。ワーキンググループのラストコールに続くレビューで指摘された点に感謝します。
Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg for their reviews on behalf of the Security, Operations, and Gen-Art directorates. Dacheng's comments led to changes at several points in the document, while Mehmet's led to creation of the Miscellaneous Considerations section. Finally, thanks to Brian Haberman for stimulating a review of the architectural assumptions and their relationship to the ability of user devices to obtain access to non-IPTV multicast services. This also led to changes in the document.
さらに、Dacheng Zhang、Mehmet Ersue、およびChrister Holmbergのセキュリティ、運用、およびGen-Artの各局のレビューに感謝します。 Dachengのコメントはドキュメントのいくつかの点で変更をもたらしましたが、Mehmetのコメントはその他の考慮事項セクションの作成につながりました。最後に、アーキテクチャの前提と、IPTV以外のマルチキャストサービスへのアクセスを取得するためのユーザーデバイスの機能との関係のレビューを刺激してくれたBrian Habermanに感謝します。これにより、ドキュメントも変更されました。
[PIMreg] IANA, "Protocol Independent Multicast (PIM) Parameters", <http://www.iana.org/assignments/pim-parameters>.
[PIMreg] IANA、「Protocol Independent Multicast（PIM）Parameters」、<http://www.iana.org/assignments/pim-parameters>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「Multicast Listener Discovery Version 2（MLDv2）for IPv6」、RFC 3810、2004年6月。
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.
[RFC5790] Liu、H.、Cao、W。、およびH. Asaeda、「Lightweight Internet Group Management Protocol Version 3（IGMPv3）and Multicast Listener Discovery Version 2（MLDv2）Protocols」、RFC 5790、2010年2月。
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, "Protocol for Access Node Control Mechanism in Broadband Networks", RFC 6320, October 2011.
[RFC6320] Wadhwa、S.、Moisand、J.、Haag、T.、Voigt、N。、およびT. Taylor、「Protocol for Access Node Control Mechanism in Broadband Networks」、RFC 6320、2011年10月。
[IEEE48] IEEE, "Guidelines for 48-Bit Global Identifier", <http://standards.ieee.org/regauth/oui/tutorials/ EUI48.html>.
[IEEE48] IEEE、「48ビットグローバルIDのガイドライン」、<http://standards.ieee.org/regauth/oui/tutorials/ EUI48.html>。
[IEEE64] IEEE, "Guidelines for 64-Bit Global Identifier", <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[IEEE64] IEEE、「64ビットグローバルIDのガイドライン」、<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[ITU-T_G.1080] ITU-T, "Quality of experience requirements for IPTV services", ITU-T Recommendation G.1080, December 2008.
[ITU-T_G.1080] ITU-T、「IPTVサービスのQuality of Experience要件」、ITU-T勧告G.1080、2008年12月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5713] Moustafa、H.、Tschofenig、H。、およびS. De Cnodder、「セキュリティ脅威とアクセスノードコントロールプロトコル（ANCP）のセキュリティ要件」、RFC 5713、2010年1月。
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010.
[RFC5851] Ooghe、S.、Voigt、N.、Platnic、M.、Haag、T。、およびS. Wadhwa、「フレームワークとブロードバンドマルチサービスネットワークにおけるアクセスノード制御メカニズムの要件」、RFC 5851、5月2010。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
[RFC6614] Winter、S.、McCauley、M.、Venaas、S.、and K. Wierenga、 "Transport Layer Security（TLS）Encryption for RADIUS"、RFC 6614、May 2012。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733] Fajardo、V.、Arkko、J.、Loughney、J。、およびG. Zorn、「Diameter Base Protocol」、RFC 6733、2012年10月。
This appendix provides an example in which most of the possible message flows for multicast control are illustrated. This appendix is for informational purposes only. In case of discrepancy with text in the body of this document, the text in the body of the document is to be considered as the normative text.
この付録では、マルチキャスト制御の可能なメッセージフローのほとんどが示されている例を示します。この付録は、情報提供のみを目的としています。このドキュメントの本文のテキストと不一致がある場合、ドキュメントの本文のテキストは規範的なテキストと見なされます。
Assume the following, for a given access port:
特定のアクセスポートについて、次のことを想定します。
o The basic subscribed service is white-listed. The AN will be responsible for admission control for this service.
o 基本購読サービスはホワイトリストに登録されています。 ANは、このサービスのアドミッションコントロールを担当します。
o Some premium services are available, but requests for these services must be referred to the Policy Server for proper credit processing. For this reason, they are grey-listed. The NAS will be responsible for admission control for these services.
o 一部のプレミアムサービスを利用できますが、これらのサービスのリクエストは、適切なクレジット処理のためにポリシーサーバーに参照する必要があります。このため、それらはグレーリストに記載されています。 NASはこれらのサービスのアドミッションコントロールを担当します。
o The subscriber has asked that certain services be blocked so that his children cannot view them. These services are black-listed.
o 加入者は、子供がそれらを見ることができないように、特定のサービスをブロックすることを要求しました。これらのサービスはブラックリストに載っています。
o All of the above services are Source-Specific Multicast (SSM). In addition, by means that bypass the AN, the subscriber can signal intent to join an on-line game service that is Any-Source Multicast (ASM). The NAS is responsible for admission control for this service.
o 上記のサービスはすべてSource-Specific Multicast（SSM）です。さらに、加入者は、ANをバイパスすることにより、Any-Source Multicast（ASM）であるオンラインゲームサービスに参加する意思を示すことができます。 NASは、このサービスのアドミッションコントロールを担当します。
o Bandwidth delegation is, in effect, to share video bandwidth between the AN and the NAS.
o 帯域幅の委任は、実質的に、ANとNASの間でビデオ帯域幅を共有することです。
The stated conditions require the use of four of the five capabilities specified in this memo.
記載されている条件では、このメモで指定されている5つの機能のうち4つを使用する必要があります。
Assume that capability negotiation has been completed between the AN and NAS and that the set of negotiated capabilities includes the following four multicast capabilities: NAS-initiated multicast replication, conditional access and admission control with white and black lists, conditional access and admission control with grey lists, and bandwidth delegation. At this point, the NAS can provision the service profiles on the AN and enable admission control at the AN for white-listed flows. To do this, the NAS sends the AN a Provisioning message containing this information. An example message providing the profile for our assumed subscriber is shown in Figure 22. The message has the following contents: o Message Type is 93.
ANとNASの間で機能ネゴシエーションが完了し、ネゴシエートされた機能のセットに次の4つのマルチキャスト機能が含まれていると想定します。NASが開始するマルチキャストレプリケーション、条件付きアクセスとアドミッション制御、ホワイトリストとブラックリスト、条件付きアクセスとアドミッション制御は灰色リスト、および帯域幅の委任。この時点で、NASはANでサービスプロファイルをプロビジョニングし、ANでホワイトリストフローのアドミッションコントロールを有効にできます。これを行うために、NASはこの情報を含むプロビジョニングメッセージをANに送信します。想定されるサブスクライバーのプロファイルを提供するメッセージの例を図22に示します。メッセージの内容は次のとおりです。oメッセージタイプは93です。
o The Result and Result Code fields in the header are set to zeroes, as specified [RFC6320].
o [RFC6320]で指定されているように、ヘッダーのResultおよびResult Codeフィールドはゼロに設定されます。
o A Transaction Identifier is assigned by the NAS.
o トランザクション識別子はNASによって割り当てられます。
o The Multicast-Service-Profile TLV (of which typically there would be multiple instances) contains a Multicast-Service-Profile-Name TLV (with a length of 20 octets assumed for the example) and three List-Action TLVs, one each for the white, grey, and black lists within the profile. The white list flows come in two sets of group addresses: 233.252.0.0/29, coming from a server at 192.0.2.15, and 233.252.0.32/29, coming from a server at 192.0.2.16. The grey-listed flows are in the band 233.252.0.64/29, coming from a server at 192.0.2.21. Finally, the black list flows are two individual flows that happen to overlap with the grey list band: 233.252.0.65 and 233.252.0.69, also with source 192.0.2.21.
o Multicast-Service-Profile TLV（通常、複数のインスタンスが存在します）には、Multicast-Service-Profile-Name TLV（長さは例では20オクテットと想定されています）と3つのList-Action TLVが含まれています。プロファイル内のホワイト、グレー、ブラックのリスト。ホワイトリストフローには、グループアドレスの2つのセットがあります。192.0.2.15のサーバーからの233.252.0.0/29と、192.0.2.16のサーバーからの233.252.0.32/29です。グレーリストのフローは、バンド233.252.0.64/29にあり、192.0.2.21のサーバーから送信されます。最後に、ブラックリストフローは、偶然にもグレーリストバンドと重複する2つの個別のフローであり、233.252.0.65および233.252.0.69であり、ソース192.0.2.21も含まれます。
o The White-List-CAC TLV indicates that the AN does admission control on white-listed flows.
o ホワイトリストCAC TLVは、ANがホワイトリストフローのアドミッション制御を行うことを示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 93 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length = 112 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | Embedded TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233.252.0.0 | Source prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.15 | G PrefLen = 29| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 3 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.64 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | Padding = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 32| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.65 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | G PrefLen = 32| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Example Provisioning Message
図22：プロビジョニングメッセージの例
Note that the padding after the middle List-Action TLV is counted as part of the length of the Multicast-Service-Profile TLV but is not included in the length of that List-Action TLV. Note also that the Length field in the message header, unlike those in the TLVs, includes the message header itself, as required by [RFC6320].
中間のList-Action TLVの後のパディングはMulticast-Service-Profile TLVの長さの一部としてカウントされますが、そのList-Action TLVの長さには含まれないことに注意してください。 [RFC6320]で要求されているように、TLVとは異なり、メッセージヘッダーの長さフィールドにはメッセージヘッダー自体が含まれることにも注意してください。
Finally, note that the Provisioning message does not include a MRepCtl-CAC TLV since in our example admission control for grey-listed flows and for NAS-initiated replication is performed by the NAS.
最後に、この例ではグレーリストのフローとNASが開始するレプリケーションのアドミッションコントロールがNASによって実行されるため、プロビジョニングメッセージにはMRepCtl-CAC TLVが含まれていないことに注意してください。
As soon as the AN port comes up, the AN sends an ANCP PORT_UP message to the NAS specifying the Access Loop Circuit ID. The NAS replies with an ANCP Port Management message that, together with the other parameters, includes the multicast service profile name to be associated to that port along with the initial amount of delegated bandwidth. The corresponding message flow is illustrated in Figure 23.
ANポートが起動するとすぐに、ANはアクセスループ回線IDを指定してANCP PORT_UPメッセージをNASに送信します。 NASはANCPポート管理メッセージで応答します。このメッセージには、他のパラメータと共に、そのポートに関連付けられるマルチキャストサービスプロファイル名と、委任された帯域幅の初期量が含まれています。対応するメッセージフローを図23に示します。
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |---------------->| |
| | |(M1)PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | |(M2) PORT_MNGT |
| | | (Port ID, |
| | |Mcast S Profile Name,|
| | |Bandwidth Allocation)|
| | |<--------------------|
(*) The NAS may optionally seek direction from an external Authorization/Policy Server
（*）NASはオプションで、外部の承認/ポリシーサーバーから指示を求めることができます。
Figure 23: Configuring an AN Port with Multicast Service Profile ID and Delegated Bandwidth Amount
図23：マルチキャストサービスプロファイルIDと委任された帯域幅量を使用したANポートの構成
The Port Management message will typically contain other TLVs, but our example (Figure 24) just shows the Target, Multicast-Service-Profile-Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the subscriber line, the Multicast-Service-Profile-Name TLV is identical to the one contained in the Provisioning message, and the Bandwidth-Allocation TLV provides just enough bandwidth (2000 kbits/s) for one channel to start with.
通常、ポート管理メッセージには他のTLVが含まれますが、この例（図24）には、ターゲット、マルチキャストサービスプロファイル名、および帯域幅割り当てTLVのみが示されています。ターゲットTLVは加入者線を識別し、Multicast-Service-Profile-Name TLVはプロビジョニングメッセージに含まれるものと同一であり、Bandwidth-Allocation TLVは、1つのチャネルを開始するのに十分な帯域幅（2000キロビット/秒）を提供します。
The following fields in the Port Management message header are shown with specific values either as directed by the base protocol document or for the sake of our example: o Message Type is 32.
ポート管理メッセージヘッダーの次のフィールドは、ベースプロトコルドキュメントによって指示されたとおり、またはこの例の目的で、特定の値とともに表示されます。oメッセージタイプは32です。
o Result is set to Nack (0x1) for this example.
o この例では、結果はNack（0x1）に設定されています。
o Result Code is 0.
o 結果コードは0です。
o A Transaction Identifier is assigned by the NAS.
o トランザクション識別子はNASによって割り当てられます。
o Port is set to 0.
o ポートは0に設定されています。
o Event Sequence Number, the R flag and the other bits marked x, Duration, the Event Flags, and the Flow Control Flags are all irrelevant for this function and are set to 0.
o イベントシーケンス番号、Rフラグ、xとマークされた他のビット、期間、イベントフラグ、およびフロー制御フラグはすべてこの機能には関係なく、0に設定されています。
o Function is set to "Configure Connection Service Data" (8).
o 機能は「接続サービスデータの構成」（8）に設定されます。
o X-Function is set to 0.
o Xファンクションは0に設定されています。
o Tech Type is "DSL" (5).
o Tech Typeは「DSL」です（5）。
o Block lengths are calculated assuming a Circuit-Id length of 4 in our example. Recall that the example Multicast-Service-Profile-Name TLV length is 20.
o この例では、Circuit-Idの長さを4として、ブロック長が計算されます。例のMulticast-Service-Profile-Name TLV長は20であることを思い出してください。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 32 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type=5 | Blk Len = 56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs = 3 | Extension Block length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth value = 2000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Example Port Management Message
図24：ポート管理メッセージの例
Suppose now that the subscriber chooses to watch the premium channel characterized by source 192.0.2.21, group 233.252.0.67. Upon receiving the join request, the AN matches it against the multicast service profile for the port and determines that it is a grey-listed flow. Figure 25 illustrates the resulting ANCP message flow for the case of a simple join and leave, when admission control for grey-listed flows is not activated on the AN.
ここで、加入者がソース192.0.2.21、グループ233.252.0.67を特徴とするプレミアムチャネルを視聴することを選択したとします。加入要求を受信すると、ANはそれをポートのマルチキャストサービスプロファイルと照合し、グレーリストのフローであると判断します。図25は、グレーリストのフローのアドミッション制御がANでアクティブ化されていない、単純な加入と脱退の場合の結果のANCPメッセージフローを示しています。
To start the flow, the AN sends a Multicast Admission Control message (M1) to the NAS. The NAS decides whether the flow can be admitted, applying both policy and bandwidth criteria. It returns its decision (positive in this example) in a Multicast Replication Control message (M2). Later, when the subscriber leaves the flow, the AN informs the NAS by sending another Multicast Admission Control message.
フローを開始するために、ANはマルチキャストアドミッションコントロールメッセージ（M1）をNASに送信します。 NASは、ポリシーと帯域幅の両方の基準を適用して、フローを許可できるかどうかを決定します。マルチキャストレプリケーションコントロールメッセージ（M2）で決定（この例では肯定）を返します。その後、加入者がフローを離れると、ANは別のマルチキャストアドミッションコントロールメッセージを送信してNASに通知します。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | | (NAS performs
| | | Multicast | admission
| | | Replication (*) control)
| | | Control (M2) |
| Mcast Grey Flow |<------------------|
|<======================+ |
| | | |
~ ~ ~ ~
| | | Multicast |
| Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) |
| | |------------------>|
| | | |
Grey-Fl: multicast flow matching an entry in grey list
Grey-Fl：グレーリストのエントリに一致するマルチキャストフロー
(*) The NAS may optionally seek direction from an external Authorization/Policy Server.
（*）NASはオプションで、外部の承認/ポリシーサーバーからの指示を求める場合があります。
Figure 25: Successful Join/Leave Operations, Grey-Listed Flow
図25：成功した参加/脱退操作、灰色のリストのフロー
The Multicast Admission Control message M1 contains:
マルチキャストアドミッションコントロールメッセージM1には以下が含まれます。
o an ANCP Header with:
o ANCPヘッダー：
* Message Type is 145;
* メッセージタイプは145です。
* Result = Ignore (0x0); and
* 結果=無視（0x0）;そして
* a Transaction Identifier assigned by the AN.
* ANによって割り当てられたトランザクション識別子。
o a Target TLV identifying the AN Port
o ANポートを識別するターゲットTLV
o a Command TLV containing:
o 以下を含むコマンドTLV：
* Command Code = "Add" (1);
* コマンドコード= "追加"（1）;
* Accounting = "No" (0);
* あっこうんちんｇ ＝ ”の” （０）；
* a Multicast-Flow embedded TLV indicating the multicast flow for which the AN received the IGMP join: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21; and
* ANがIGMP加入を受信したマルチキャストフローを示すMulticast-Flow組み込みTLV：フロータイプ "SSM"（2）、アドレスファミリ "IPv4"（1）、グループアドレス= 233.252.0.67、送信元アドレス= 192.0.2.21 ;そして
* a Request-Source-Device-Id embedded TLV containing the IGMP join source local device identifier value 5.
* IGMP結合ソースローカルデバイス識別子の値5を含むRequest-Source-Device-Id埋め込みTLV。
The Multicast Admission Control message M1 is illustrated in Figure 26:
マルチキャストアドミッションコントロールメッセージM1を図26に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Multicast Admission Control Message Seeking to Add a Flow
図26：フローの追加を求めるマルチキャストアドミッションコントロールメッセージ
The Multicast Replication Control message M2 contains:
マルチキャスト複製制御メッセージM2には、以下が含まれます。
o an ANCP Header with:
o ANCPヘッダー：
* Message Type = "Multicast Replication Control" (144);
* メッセージの種類= "マルチキャストレプリケーションコントロール"（144）;
* Result= 0x1 (Nack); and
* 結果= 0x1（Nack）;そして
* a Transaction Identifier assigned by the NAS;
* NASによって割り当てられたトランザクション識別子。
o a Target TLV identifying the AN Port
o ANポートを識別するターゲットTLV
o a Command TLV containing:
o 以下を含むコマンドTLV：
* Command Code = "Add" (1);
* コマンドコード= "追加"（1）;
* Accounting = "Yes" (1), since in our example the operator wants accounting on this flow; and
* Accounting = "Yes"（1）。これは、この例ではオペレーターがこのフローのアカウンティングを要求しているためです。そして
* a Multicast-Flow embedded TLV indicating the multicast flow that the NAS is admitting for this access line: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21.
* NASがこのアクセス回線で許可しているマルチキャストフローを示すMulticast-Flow組み込みTLV：フロータイプ「SSM」（2）、アドレスファミリ「IPv4」（1）、グループアドレス= 233.252.0.67、送信元アドレス= 192.0。 2.21。
The Multicast Admission Control message M2 is illustrated in Figure 27.
マルチキャストアドミッションコントロールメッセージM2を図27に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Type = 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Multicast Replication Control Message Admitting a Flow
図27：フローを許可するマルチキャストレプリケーション制御メッセージ
The Multicast Admission Control message M3 advising the NAS that the flow has been terminated contains:
フローが終了したことをNASに通知するマルチキャストアドミッションコントロールメッセージM3には、次のものが含まれます。
o an ANCP Header with:
o ANCPヘッダー：
* Message Type is 145;
* メッセージタイプは145です。
* Result = Ignore (0x0); and
* 結果=無視（0x0）;そして
* a Transaction Identifier assigned by the AN.
* ANによって割り当てられたトランザクション識別子。
o a Target TLV identifying the access line
o アクセス回線を識別するターゲットTLV
o a Command TLV containing:
o 以下を含むコマンドTLV：
* a Command Code = "Delete" (2);
* コマンドコード= "削除"（2）;
* Accounting = "No" (0);
* あっこうんちんｇ ＝ ”の” （０）；
* a Multicast-Flow embedded TLV indicating the multicast flow for which the AN received the IGMP leave: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21; and
* ANがIGMP脱退を受信したマルチキャストフローを示すMulticast-Flow組み込みTLV：フロータイプ "SSM"（2）、アドレスファミリ "IPv4"（1）、グループアドレス= 233.252.0.67、送信元アドレス= 192.0.2.21 ;そして
* a Request-Source-Device-Id embedded TLV containing the IGMP leave request source, the device identified by the local value 5.
* ローカル値5で識別されるデバイスであるIGMP脱退要求ソースを含むRequest-Source-Device-Id埋め込みTLV
The Multicast Admission Control message M3 is illustrated in Figure 28.
マルチキャストアドミッションコントロールメッセージM3を図28に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow Type = 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Multicast Admission Control Message Signaling Flow Termination
図28：マルチキャストアドミッションコントロールメッセージシグナリングフロー終了
The NAS has enabled white list admission control on the AN, and the bandwidth delegation capability has been negotiated. White-listed flows in themselves require no messages to the NAS, either upon admission or upon termination, but the AN may request an increase in the amount of delegated bandwidth if it needs the increase to admit a flow.
NASはANでホワイトリストアドミッションコントロールを有効にし、帯域幅委任機能がネゴシエートされました。ホワイトリストに記載されたフロー自体は、アドミッション時または終了時にNASへのメッセージを必要としませんが、フローを許可するために増加が必要な場合、ANは委任された帯域幅の量の増加を要求できます。
Consider an example where the AN has already admitted one white-listed flow, thereby using up the initially provisioned amount of delegated bandwidth (2000 kbits/s). A request is received to join a new flow in the white list range. The AN chooses to send a Bandwidth Reallocation Request message to the NAS, requesting that the delegated bandwidth allocation be increased to 4000 kbits/s at a minimum and preferably to 6000 kbits/s.
ANが1つのホワイトリストフローをすでに許可しているため、最初にプロビジョニングされた委任された帯域幅（2000キロビット/秒）を使い果たした例を考えてみます。ホワイトリスト範囲の新しいフローに参加する要求が受信されます。 ANは、帯域幅再割り当て要求メッセージをNASに送信することを選択し、委任された帯域幅割り当てを最低でも4000キロビット/秒、できれば6000キロビット/秒に増やすように要求します。
In our example, the NAS is managing bandwidth tightly, as witnessed by its minimal initial allocation of just enough for one flow. It is willing to provide the minimum additional amount only and therefore returns a Bandwidth Transfer message where the delegated bandwidth value is given as 4000 kbits/s. With this amount, the AN is able to admit the second white-listed flow. The AN could send a similar Bandwidth Transfer message back to the NAS bringing the delegated bandwidth amount back down to 2000 kbits/s when one of the flows is terminated, but this shows nothing new and is omitted.
この例では、NASは1つのフローに十分なだけの最小限の初期割り当てによって示されているように、帯域幅を厳しく管理しています。最小の追加量のみを提供する用意があるため、委任された帯域幅の値が4000 kbits / sとして指定されている帯域幅転送メッセージを返します。この量で、ANは2番目のホワイトリストフローを許可できます。フローの1つが終了すると、ANは同様の帯域幅転送メッセージをNASに送り返し、委任された帯域幅の量を2000キロビット/秒に戻しますが、これは新しいものを何も示さず、省略されています。
As one more point of illustration, suppose that the NAS chooses to audit the current amount of delegated bandwidth to ensure it is synchronized with the AN. It sends a Delegated Bandwidth Query Request message to the AN and receives a Delegated Bandwidth Query Response message with the current allocation as the AN sees it.
説明のもう1つのポイントとして、NASが委任された帯域幅の現在の量を監査して、それがANと同期していることを確認するとします。委任された帯域幅クエリ要求メッセージをANに送信し、現在の割り当てがANに認識された委任された帯域幅クエリ応答メッセージを受信します。
The complete message flow is shown in Figure 29.
完全なメッセージフローを図29に示します。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(White-F1) | |
|-----------+---------->| |
| | |AN performs |
| Mcast White Flow 1 | admission control |
|<======================+ |
| | | |
| Join(White-F2) | |
|-----------+---------->|No bandwidth left |
| | | |
| | |Bandwidth |
| | | Reallocation Req |
| | |------------------>|(M1)
| | | |
| | | (*)
| | |Bandwidth Transfer |
| AN can now |<------------------|(M2)
| admit flow | |
| Mcast White Flow 2 | |
|<======================+ |
| | | |
~ ~ ~ ~
| | |Delegated Bandwidth|
| | | Query request |
| | |<------------------|(M3)
| | | |
| | |Delegated Bandwidth|
| | | Query response |
| | |------------------>|(M4)
| | | |
(*) The NAS may optionally seek direction from an external Authorization/Policy Server.
（*）NASはオプションで、外部の承認/ポリシーサーバーからの指示を求める場合があります。
Figure 29: Successful Join/Leave Operations, White-Listed Flow
図29：成功した参加/脱退操作、ホワイトリストのフロー
The Bandwidth Reallocation Request message (M1) is shown in Figure 30. The contents require little explanation. The Message Type for the Bandwidth Reallocation Request is 146. The Result field is set to Ignore (0x0). Besides the Target TLV, the message has one other TLV, the Bandwidth-Request, with a TLV Type of 0x0016. The TLV contains Required Amount and Preferred Amount fields, set to 4000 and 6000 kbits/s respectively.
帯域幅再割り当て要求メッセージ（M1）を図30に示します。内容についての説明はほとんど必要ありません。 Bandwidth Reallocation Requestのメッセージタイプは146です。ResultフィールドはIgnore（0x0）に設定されています。メッセージには、ターゲットTLVの他に、TLVタイプ0x0016を持つもう1つのTLV、帯域幅要求があります。 TLVには、必要量フィールドと優先量フィールドが含まれ、それぞれ4000および6000 kbits / sに設定されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=146 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Amount = 6000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Bandwidth Reallocation Request Message
図30：帯域幅再割り当て要求メッセージ
The Bandwidth Transfer message (M2) is shown in Figure 31. Again, the contents are easily understood. The Message Type for the Bandwidth Transfer message is 147. The Result field is set to Success (0x3). The message contains the Target TLV and the Bandwidth-Allocation TLV. The latter has a TLV Type of 0x0015 and contains a Delegated Amount field, set to 4000 kbits/s.
帯域幅転送メッセージ（M2）を図31に示します。ここでも、内容は簡単に理解できます。 Bandwidth Transferメッセージのメッセージタイプは147です。ResultフィールドはSuccess（0x3）に設定されています。メッセージには、ターゲットTLVと帯域幅割り当てTLVが含まれています。後者のTLVタイプは0x0015で、4000キロビット/秒に設定された委任量フィールドが含まれています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=147 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: NAS Response, Bandwidth Transfer Message
図31：NAS応答、帯域幅転送メッセージ
The Delegated Bandwidth Query Request message (M3) is shown in Figure 32. The Message Type for the Delegated Bandwidth Query request message is 148. The Result field is set to AckAll (0x2). The message contains the Target TLV only.
Delegated Bandwidth Query Requestメッセージ（M3）を図32に示します。DelegatedBandwidth Query要求メッセージのメッセージタイプは148です。ResultフィールドはAckAll（0x2）に設定されています。メッセージにはターゲットTLVのみが含まれます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Delegated Bandwidth Query Request Message
図32：委任された帯域幅クエリ要求メッセージ
Finally, the Delegated Bandwidth Query Response message (M4) is shown in Figure 33. The Message Type for the Delegated Bandwidth Query response message is 148. The Result field is set to Success (0x3). The message contains the Target TLV and the Bandwidth-Allocation TLV with the Delegated Amount field set to 4000 kbits/s.
最後に、Delegated Bandwidth Query Responseメッセージ（M4）を図33に示します。DelegatedBandwidth Query応答メッセージのメッセージタイプは148です。ResultフィールドはSuccess（0x3）に設定されています。メッセージには、Delegated Amountフィールドが4000 kbits / sに設定されたターゲットTLVおよび帯域幅割り当てTLVが含まれています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier (copied from request) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: Delegated Bandwidth Query Response Message
図33：委任された帯域幅クエリ応答メッセージ
This section introduces no new messages, since requests for flows in the black list are simply ignored. The one thing to point out is the overlap in our example between the set of flows in the grey list and the flows in the black list. This does not create any ambiguity, since not only does the black list have priority for equally good matches, but also the black list entries are more specific (group prefix lengths of 32 versus 29 in the grey list) than the grey list flow prefixes.
ブラックリスト内のフローに対する要求は単に無視されるため、このセクションでは新しいメッセージを紹介しません。指摘すべきことの1つは、グレイリスト内のフローのセットとブラックリスト内のフローのセット間の重複です。これは曖昧さを引き起こしません。なぜなら、ブラックリストは同等に良い一致を優先するだけでなく、ブラックリストエントリは、グレーリストフロープレフィックスよりも具体的です（グループリストプレフィックス長が32対グレーリストでは29）。
The final class of multicast control actions in our example allows the subscriber to enter and leave the on-line game. As described at the beginning of this example, the game uses Any-Source Multicast (ASM). Subscriber signaling bypasses the AN, going directly to the NAS (e.g., through a web interface).
この例の最後のクラスのマルチキャスト制御アクションにより、加入者はオンラインゲームに出入りできます。この例の最初で説明したように、ゲームはAny-Source Multicast（ASM）を使用します。サブスクライバーシグナリングはANをバイパスし、直接（たとえば、Webインターフェイスを介して）NASに移動します。
When the subscriber requests to join the game, the NAS (after applying policy and bandwidth checks) sends a Multicast Replication Control message to the AN to enable the flow on the port concerned. The AN knows not to apply admission control, since it has not received an MRepCtl-CAC TLV in the Provisioning message. When the subscriber leaves, the NAS sends another Multicast Replication Control message to delete the flow. This message sequence is shown in Figure 34.
サブスクライバーがゲームへの参加を要求すると、NAS（ポリシーと帯域幅のチェックを適用した後）はマルチキャストレプリケーションコントロールメッセージをANに送信して、関係するポートでのフローを有効にします。 ANは、プロビジョニングメッセージでMRepCtl-CAC TLVを受信していないため、アドミッションコントロールを適用しないことを認識しています。サブスクライバが離れると、NASは別のマルチキャストレプリケーションコントロールメッセージを送信してフローを削除します。このメッセージシーケンスを図34に示します。
It is possible that the NAS finds that there is not enough bandwidth available to accommodate the subscriber's request. In this case, the NAS could send a Bandwidth Reallocation Request message to the AN, asking it to release some of the bandwidth delegated to it. This is not shown in the present example, since the messages are the same as those already presented with the exception that the Preferred Amount in the request will be *less than* or equal to the Required amount, rather than *greater than* or equal to it.
NASが、加入者の要求に対応するのに十分な帯域幅がないことを検出した可能性があります。この場合、NASは帯域幅再割り当て要求メッセージをANに送信し、委任された帯域幅の一部を解放するように要求できます。これは、現在の例では示されていません。メッセージは、要求の優先額が*以上*ではなく*必要な量と等しい*未満*であることを除いて、すでに提示されているメッセージと同じであるためです。それに。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join game | |
|-----------+------------------------------>|
| | | Multicast | NAS performs
| | | Replication (*) admission
| | | Control (M1) | control
| Mcast Game Flow |<------------------|
|<=====================>+ |
| | | |
~ ~ ~ ~
| | | |
| Leave game | |
|-----------+------------------------------>|
| | | Multicast |
| | | Replication |
| | | Control (M2) |
| Mcast Game Flow |<------------------|
| discontinued | |
| | | |
(*) The NAS may optionally seek direction from an external Authorization/Policy Server.
（*）NASはオプションで、外部の承認/ポリシーサーバーからの指示を求める場合があります。
Figure 34: NAS-Initiated Flows for On-Line Gaming
図34：オンラインゲーム用のNAS開始フロー
The Multicast Replication Control message (M1) in Figure 35 looks like the message in Figure 27 with two exceptions. The first is that the NAS has the option to set the Result field to AckAll (0x02) if it needs positive reassurance that the flow has been enabled. This was not done here to save having to depict a response differing only in the Result field. The larger difference in this example is that the flow description in the Multicast-Flow embedded TLV is that of an ASM multicast group (Flow Type = 1) with IPv4 (1) group address 233.252.0.100.
図35のマルチキャスト複製制御メッセージ（M1）は、2つの例外を除いて、図27のメッセージのようになります。 1つ目は、フローが有効になっていることを確実に再確認する必要がある場合、NASにResultフィールドをAckAll（0x02）に設定するオプションがあることです。これは、「結果」フィールドのみが異なる応答を表す必要をなくすために、ここでは行われていません。この例の大きな違いは、Multicast-Flow組み込みTLVのフローの説明が、IPv4（1）グループアドレス233.252.0.100のASMマルチキャストグループ（フロータイプ= 1）の説明であることです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 35: Enabling the Subscriber to Join an On-Line Game
図35：サブスクライバーがオンラインゲームに参加できるようにする
Message M2 terminating the flow when the subscriber leaves the game looks the same as the message in Figure 35 with two exceptions: the Command Code becomes "Delete" (2), and Accounting is set to "No" (0) to turn off flow accounting. Of course, the Transaction Identifier values will differ between the two messages.
サブスクライバーがゲームを離れるときにフローを終了するメッセージM2は、図35のメッセージと同じように見えますが、2つの例外があります。コマンドコードが「削除」（2）になり、アカウンティングが「いいえ」（0）に設定されてフローがオフになります。会計。もちろん、トランザクション識別子の値は2つのメッセージ間で異なります。
The example in this section is independent of the example in the preceding sections.
このセクションの例は、前のセクションの例とは関係ありません。
Figure 36 illustrates a message flow in a case where the NAS queries the AN about which multicast flows are active on port 10, port 11, and port 20 of the AN.
図36は、NASがANに問い合わせ、ANのポート10、ポート11、およびポート20でマルチキャストフローがアクティブである場合のメッセージフローを示しています。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | | (M1) |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | | (M2) |
| | |------------------>|
| | | |
| | | |
Figure 36: Per-Port Multicast Flow Reporting
図36：ポートごとのマルチキャストフローレポート
The Multicast Flow Query Request message (M1) is illustrated in Figure 37. The Message Type is 149. The Result field is set to AckAll (0x2). Three Target TLVs are present, identifying port 10, port 20, and port 11, respectively.
マルチキャストフロークエリ要求メッセージ（M1）を図37に示します。メッセージタイプは149です。結果フィールドはAckAll（0x2）に設定されています。 3つのターゲットTLVが存在し、それぞれポート10、ポート20、およびポート11を識別します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149| Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: Multicast Flow Query Request Message for Per-Port Multicast Flow Reporting
図37：ポートごとのマルチキャストフローレポートのマルチキャストフロークエリ要求メッセージ
The Multicast Flow Query Response message (M2) is illustrated in Figure 38. It indicates that there is one active multicast flow [(192.0.2.1, 233.252.0.4)] on port 10, no active multicast flow on port 20, and two active multicast flows [(192.0.2.1, 233.252.0.4) and (192.0.2.2, 233.252.0.10)] on port 11.
マルチキャストフロークエリ応答メッセージ（M2）を図38に示します。ポート10に1つのアクティブなマルチキャストフロー[（192.0.2.1、233.252.0.4）]があり、ポート20にアクティブなマルチキャストフローがなく、2つのアクティブなマルチキャストフローがあることを示しています。ポート11のマルチキャストフロー[（192.0.2.1、233.252.0.4）および（192.0.2.2、233.252.0.10）]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149|Rslt=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address: 233.252.0.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 38: Multicast Flow Query Response Message for Per-Port Multicast Flow Reporting
図38：ポートごとのマルチキャストフローレポートのマルチキャストフロークエリ応答メッセージ
Authors' Addresses
著者のアドレス
Francois Le Faucheur Cisco Systems 45 Allee des Ormes Mougins 06250 France
フランソワルフォシェールシスコシステムズ45アリーデオルムムジャン06250フランス
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Roberta Maglione Cisco Systems 181 Bay Street Toronto, ON M5J 2T3 Canada
Roberta Sweater Cisco Systems 181 Bay Street Toronto、ON M5J 2T3 Canada
EMail: robmgl@cisco.com
Tom Taylor Huawei Technologies Ottawa Canada
Tom Taylor Huawei Technologiesオタワカナダ
EMail: tom.taylor.stds@gmail.com