[要約] 要約：RFC 6934は、パッシブ光ネットワーク（PON）に基づくブロードバンドネットワークにおけるアクセスノード制御メカニズムの適用可能性について説明しています。目的：このRFCの目的は、PONベースのブロードバンドネットワークにおいて、アクセスノード制御メカニズムの利点と課題を明確にし、ネットワークの効率性と信頼性を向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) N. Bitar, Ed.
Request for Comments: 6934 Verizon
Category: Informational S. Wadhwa, Ed.
ISSN: 2070-1721 Alcatel-Lucent
T. Haag
Deutsche Telekom
H. Li
Huawei Technologies
June 2013
Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
パッシブ光ネットワーク（PON）に基づくブロードバンドネットワークへのアクセスノード制御メカニズムの適用性
Abstract
概要
The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives.
このドキュメントの目的は、パッシブ光ネットワーク（PON）に基づくブロードバンドアクセスへのアクセスノード制御メカニズムの適用性を提供することです。光回線終端（OLT）要素と光ネットワーク終端（ONT）要素の組み合わせで構成される、ネットワークアクセスサーバー（NAS）とアクセスノードコンプレックスの間のアクセスノード制御メカニズムの必要性は、マルチサービスリファレンスで説明されています。 QoS関連、サービス関連、および加入者関連の操作を実行するためのアーキテクチャ。アクセスノード制御メカニズムは、アクセスノードコンプレックスのコンポーネント（OLTとONT）間の相互作用のためにも拡張されています。アクセスノードコントロールメカニズムは、NASとアクセスノードコンプレックス（ANX）間、およびANX内のOLTとONT間の情報の送信が、個別の要素マネージャーを経由する必要がなく、デバイス間の直接通信を使用することを保証します。ネットにとどまります。これにより、これらのネットワーク要素内でアクセスリンク関連の操作を実行して、パフォーマンス目標を達成できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6934.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6934で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 ....................................................3
2. Terminology .....................................................4
3. Motivation for Explicit Extension of ANCP to FTTx PON ...........6
4. Reference Model for PON-Based Broadband Access Network ..........7
4.1. Functional Blocks ..........................................9
4.1.1. Home Gateway ........................................9
4.1.2. PON Access ..........................................9
4.1.3. Access Node Complex ................................10
4.1.4. Access Node Complex Uplink to the NAS ..............10
4.1.5. Aggregation Network ................................10
4.1.6. Network Access Server ..............................10
4.1.7. Regional Network ...................................10
4.2. Access Node Complex Control Reference Architecture
Options ...................................................11
4.2.1. ANCP+OMCI ANX Control ..............................11
4.2.2. All-ANCP ANX Control ...............................12
5. Concept of Access Node Control Mechanism for PON-Based Access ..13
6. Multicast ......................................................16
6.1. Multicast Conditional Access ..............................16
6.2. Multicast Admission Control ...............................18
6.3. Multicast Accounting ......................................30
7. Remote Connectivity Check ......................................31
8. Access Topology Discovery ......................................32
9. Access Loop Configuration ......................................34
10. Security Considerations .......................................34
11. Differences in ANCP Applicability between DSL and PON .........35
12. ANCP versus OMCI between the OLT and ONT/ONU ..................36
13. Acknowledgements ..............................................37
14. References ....................................................37
14.1. Normative References .....................................37
14.2. Informative References ...................................38
Passive Optical Networks (PONs) based on Broadband PON (BPON) [G.983.1] and Gigabit PON (GPON) [G.984.1] are being deployed across carrier networks. There are two models for PON deployment: Fiber to the Building/Curb (FTTB/FTTC) and Fiber to the Premises (FTTP). In the FTTB/C deployment, the last-mile connectivity to the subscriber premises is provided over the local copper loop, often using Very High Speed Digital Subscriber Line (VDSL). In the FTTP case, PON extends to the premises of the subscriber. In addition, there are four main PON technologies: (1) BPON, (2) GPON, (3) 10-Gigabit PON (XG-PON), and (4) Ethernet PON (EPON). This document describes the applicability of the Access Node Control Protocol (ANCP) in the context of FTTB/C and FTTP deployments, focusing on BPON, GPON, and XG-PON. Architectural considerations lead to different ANCP compositions. Therefore, the composition of ANCP communication between Access Nodes (ANs) and Network Access Servers (NASs) is described using different models.
ブロードバンドPON（BPON）[G.983.1]とギガビットPON（GPON）[G.984.1]に基づくパッシブ光ネットワーク（PON）は、キャリアネットワーク全体に配備されています。 PON展開には、Fiber to the Building / Curb（FTTB / FTTC）とFiber to the Premises（FTTP）の2つのモデルがあります。 FTTB / C展開では、加入者構内へのラストマイル接続は、ローカルの銅線ループを介して提供され、多くの場合超高速デジタル加入者線（VDSL）を使用します。 FTTPの場合、PONは加入者の構内にまで及びます。さらに、4つの主要なPONテクノロジーがあります。（1）BPON、（2）GPON、（3）10ギガビットPON（XG-PON）、および（4）イーサネットPON（EPON）です。このドキュメントでは、BTB、GPON、およびXG-PONに焦点を当てて、FTTB / CおよびFTTP展開のコンテキストにおけるアクセスノード制御プロトコル（ANCP）の適用性について説明します。アーキテクチャ上の考慮事項により、ANCP構成が異なります。したがって、アクセスノード（AN）とネットワークアクセスサーバー（NAS）間のANCP通信の構成は、異なるモデルを使用して説明されています。
BPON, GPON, and XG-PON in FTTP deployments provide large bandwidth in the first mile, bandwidth that is an order of magnitude larger than that provided by xDSL. In the downstream direction, BPON provides 622 Mbit/s per PON, GPON provides 2.4 Gbit/s, and XG-PON provides 10 Gbit/s.
FTTP展開のBPON、GPON、およびXG-PONは、最初の1マイルで大きな帯域幅を提供します。この帯域幅は、xDSLで提供されるものよりも1桁大きくなります。ダウンストリーム方向では、BPONはPONあたり622 Mbit / sを提供し、GPONは2.4 Gbit / sを提供し、XG-PONは10 Gbit / sを提供します。
In residential deployments, the number of homes sharing the same PON is limited by the technology and the network engineering rules. Typical deployments have 32-64 homes per PON.
住宅への展開では、同じPONを共有する家の数は、テクノロジーとネットワークエンジニアリングルールによって制限されます。一般的な展開では、PONあたり32〜64の家があります。
The motive behind BPON, GPON, and XG-PON deployment is to provide triple-play services over IP: voice, video, and data. Voice is generally low bandwidth but has requirements for low delay, low jitter, and low packet loss. Data services (e.g., Internet services) often require high throughput and can tolerate medium latency. Data services may include multimedia content download such as video. However, in that case, the video content is not required to be real-time, and/or it is low-quality video. Video services, on the other hand, are targeted to deliver Standard Definition or High Definition video content in real time or near real time, depending on the service model. Standard Definition content using MPEG2 encoding requires on the order of 3.75 Mbit/s per stream while High Definition content using MPEG2 encoding requires 15-19 Mbit/s depending on the level of compression used. Video services require low jitter and low packet loss with low start-time latency. There are two types of video services: on demand and broadcast (known also as linear programming content). While linear programming content can be provided over Layer 1 on the PON, the focus in this document is on delivering linear programming content over IP to the subscriber using IP multicast. Video on Demand (VoD) is also considered for delivery to the subscriber over IP using a unicast session model.
BPON、GPON、およびXG-PON展開の背後にある動機は、IPを介したトリプルプレイサービス（音声、ビデオ、およびデータ）を提供することです。音声は一般的に低帯域幅ですが、低遅延、低ジッター、低パケット損失の要件があります。データサービス（インターネットサービスなど）は、多くの場合、高いスループットを必要とし、中程度のレイテンシを許容できます。データサービスには、ビデオなどのマルチメディアコンテンツのダウンロードが含まれる場合があります。ただし、その場合、ビデオコンテンツはリアルタイムである必要はなく、低品質のビデオです。一方、ビデオサービスは、サービスモデルに応じて、標準解像度または高解像度のビデオコンテンツをリアルタイムまたはほぼリアルタイムで配信することを目的としています。 MPEG2エンコーディングを使用する標準解像度コンテンツには、ストリームあたり3.75 Mbit / sのオーダーが必要ですが、MPEG2エンコーディングを使用する高解像度コンテンツには、使用される圧縮レベルに応じて15〜19 Mbit / sが必要です。ビデオサービスは、低いジッターと低いパケット損失を必要とし、開始時間のレイテンシが低くなります。ビデオサービスには、オンデマンドとブロードキャスト（リニアプログラミングコンテンツとも呼ばれる）の2つのタイプがあります。リニアプログラミングコンテンツはPONのレイヤ1を介して提供できますが、このドキュメントでは、IPマルチキャストを使用してIP経由でリニアプログラミングコンテンツを加入者に配信することに焦点を当てています。ビデオオンデマンド（VoD）は、ユニキャストセッションモデルを使用してIP経由で加入者に配信することも考慮されます。
Providing simultaneous triple-play services over IP with unicast video and multicast video, VoIP, and data requires an architecture that preserves the quality of service of each service. Fundamental to this architecture is ensuring that the video content (unicast and multicast) delivered to the subscriber does not exceed the bandwidth allocated to the subscriber for video services. Architecture models often ensure that data is guaranteed a minimum bandwidth and that VoIP is guaranteed its own bandwidth. In addition, QoS control across services is often performed at a Network Access Server (NAS), often referred to as Broadband Network Gateway (BNG) for subscriber management, per subscriber and shared link resources. Efficient multicast video services require enabling multicast services in the access network between the subscriber and the subscriber management platform. In the FTTP/B/C PON environment, this implies enabling IP multicast on the ANX composed of the Optical Network Terminal (ONT) or Unit (ONU) and Optical Line Terminal (OLT), as applicable. This is as opposed to Digital Subscriber Line (DSL) deployments where multicast is enabled on the DSL Access Multiplexer (DSLAM) only. The focus in this document will be on the ANCP requirements needed for coordinated admission control of unicast and multicast video in FTTP/B/C PON environments between the ANX and the NAS, specifically focusing on bandwidth dedicated for multicast and shared bandwidth between multicast and unicast.
ユニキャストビデオとマルチキャストビデオ、VoIP、およびデータを使用してIP上の同時トリプルプレイサービスを提供するには、各サービスのサービス品質を維持するアーキテクチャが必要です。このアーキテクチャの基本は、サブスクライバに配信されるビデオコンテンツ（ユニキャストおよびマルチキャスト）が、ビデオサービス用にサブスクライバに割り当てられた帯域幅を超えないようにすることです。多くの場合、アーキテクチャモデルでは、データの最小帯域幅とVoIPの独自の帯域幅が保証されています。さらに、サービス全体のQoS制御は、ネットワークアクセスサーバー（NAS）で実行されることが多く、ブロードバンドネットワークゲートウェイ（BNG）とも呼ばれ、サブスクライバーおよび共有リンクリソースごとにサブスクライバーを管理します。効率的なマルチキャストビデオサービスには、加入者と加入者管理プラットフォーム間のアクセスネットワークでマルチキャストサービスを有効にする必要があります。 FTTP / B / C PON環境では、これは、光ネットワーク端末（ONT）またはユニット（ONU）と光回線端末（OLT）で構成されるANXでIPマルチキャストを有効にすることを意味します。これは、DSLアクセスマルチプレクサー（DSLAM）でのみマルチキャストが有効になっているデジタル加入者線（DSL）配置とは対照的です。このドキュメントでは、ANXとNAS間のFTTP / B / C PON環境でユニキャストビデオとマルチキャストビデオの協調アドミッション制御に必要なANCP要件に焦点を当て、特にマルチキャスト専用の帯域幅とマルチキャストとユニキャスト間の共有帯域幅に焦点を当てます。
[RFC5851] provides the framework and requirements for coordinated admission control between a NAS and an AN with special focus on DSL deployments. This document extends that framework and the related requirements to explicitly address PON deployments.
[RFC5851]は、DSL配置に特に重点を置いて、NASとAN間の協調型アドミッションコントロールのフレームワークと要件を提供します。このドキュメントは、そのフレームワークと関連する要件を拡張して、PON展開に明示的に対処します。
- PON (Passive Optical Network) [G.983.1][G.984.1]: a point-to-multipoint FTTP network architecture in which unpowered splitters are used to enable the splitting of an optical signal from a central office on a single optical fiber to multiple premises. Up to 32-128 may be supported on the same PON. A PON configuration consists of an Optical Line Terminal (OLT) at the service provider's central office (CO) and a number of Optical Network Units or Terminals (ONUs/ONTs) near end users, with an Optical Distribution Network (ODN) composed of fibers and splitters between them. A PON configuration reduces the amount of fiber and CO equipment required compared with point-to-point architectures.
- PON（パッシブ光ネットワーク）[G.983.1] [G.984.1]：電力供給されていないスプリッターを使用して、セントラルオフィスからの光信号を1本の光ファイバーで分割できるようにするポイントツーマルチポイントFTTPネットワークアーキテクチャ複数の施設。同じPONで最大32〜128をサポートできます。 PON構成は、サービスプロバイダーのセントラルオフィス（CO）にある光回線端末（OLT）と、エンドユーザーの近くにある多数の光ネットワークユニットまたは端末（ONU / ONT）で構成され、光配信ネットワーク（ODN）がファイバーで構成されています。そしてそれらの間のスプリッター。 PON構成では、ポイントツーポイントアーキテクチャと比較して、必要なファイバーおよびCO機器の量が削減されます。
- Access Node Complex (ANX): composed of two geographically separated functional elements -- OLT and ONU/ONT. The general term Access Node Complex (ANX) will be used when describing a functionality that does not depend on the physical location but rather on the "black box" behavior of OLT and ONU/ONT.
- Access Node Complex（ANX）：地理的に離れた2つの機能要素（OLTとONU / ONT）で構成されます。一般的な用語Access Node Complex（ANX）は、物理的な場所ではなく、OLTおよびONU / ONTの「ブラックボックス」動作に依存する機能を説明するときに使用されます。
- Optical Line Terminal (OLT): is located in the service provider's central office (CO). It terminates and aggregates multiple PONs (providing fiber access to multiple premises or neighborhoods) on the subscriber side and interfaces with the Network Access Server (NAS) that provides subscriber management.
- 光回線ターミナル（OLT）：サービスプロバイダーのセントラルオフィス（CO）にあります。加入者側の複数のPONを終端して集約し（複数の構内または近隣へのファイバーアクセスを提供）、加入者管理を提供するネットワークアクセスサーバー（NAS）とインターフェイスします。
- Optical Network Terminal (ONT): terminates PON on the network side and provides PON adaptation. The subscriber side interface and the location of the ONT are dictated by the type of network deployment. For an FTTP deployment (with fiber all the way to the apartment or living unit), ONT has Ethernet (Fast Ethernet (FE) / Gigabit Ethernet (GE) / Multimedia over Coax Alliance (MoCA)) connectivity with the Home Gateway (HGW) / Customer Premises Equipment (CPE). In certain cases, one ONT may provide connections to more than one Home Gateway at the same time.
- 光ネットワーク端末（ONT）：ネットワーク側でPONを終端し、PON適応を提供します。加入者側のインターフェイスとONTの場所は、ネットワーク配置のタイプによって決まります。 FTTP展開（アパートまたはリビングユニットまでのファイバー）の場合、ONTには、ホームゲートウェイ（HGW）とのイーサネット（ファストイーサネット（FE）/ギガビットイーサネット（GE）/マルチメディアオーバー同軸アライアンス（MoCA））接続があります。 /顧客宅内機器（CPE）。場合によっては、1つのONTが同時に複数のホームゲートウェイへの接続を提供することがあります。
- Optical Network Unit (ONU): a generic term denoting a device that terminates any one of the distributed (leaf) endpoints of an Optical Distribution Network (ODN), implements a PON protocol, and adapts PON PDUs to subscriber service interfaces. In the case of a multi-dwelling unit (MDU) or multi-tenant unit (MTU), a multi-subscriber ONU typically resides in the basement or a wiring closet (FTTB case) and has FE/GE/Ethernet over native Ethernet link or over xDSL (typically VDSL) connectivity with each CPE at the subscriber premises. In the case where fiber is terminated outside the premises (neighborhood or curb side) on an ONT/ONU, the last-leg-premises connections could be via existing or new copper, with xDSL physical layer (typically VDSL). In this case, the ONU effectively is a "PON-fed DSLAM".
- 光ネットワークユニット（ONU）：光配信ネットワーク（ODN）の分散（リーフ）エンドポイントのいずれか1つを終端し、PONプロトコルを実装し、加入者サービスインターフェイスにPON PDUを適合させるデバイスを表す一般的な用語。集合住宅ユニット（MDU）またはマルチテナントユニット（MTU）の場合、通常、マルチサブスクライバーONUは地下または配線クローゼット（FTTBの場合）に常駐し、ネイティブイーサネットリンク上のFE / GE /イーサネットを備えています。または加入者構内の各CPEとのxDSL（通常はVDSL）接続。 ONT / ONUの構内外（近隣または縁石側）でファイバーが終端されている場合、最後の構内接続は、xDSL物理層（通常はVDSL）の既存または新しい銅線を介して接続できます。この場合、ONUは事実上「PON給電DSLAM」です。
- Network Access Server (NAS): network element that aggregates subscriber traffic from a number of ANs or ANXs. The NAS is often an injection point for policy management and IP QoS in the access network. It is also referred to as Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS).
- ネットワークアクセスサーバー（NAS）：複数のANまたはANXからの加入者トラフィックを集約するネットワーク要素。 NASは、多くの場合、アクセスネットワークにおけるポリシー管理とIP QoSの注入ポイントです。ブロードバンドネットワークゲートウェイ（BNG）またはブロードバンドリモートアクセスサーバー（BRAS）とも呼ばれます。
- Home Gateway (HGW): network element that connects subscriber devices to the AN or ANX and the access network. In the case of xDSL, the Home Gateway is an xDSL network termination that could either operate as a Layer 2 bridge or as a Layer 3 router. In the latter case, such a device is also referred to as a Routing Gateway (RG). In the case of PON, it is often a Layer 3 routing device with the ONT performing PON termination.
-ホームゲートウェイ（HGW）：サブスクライバーデバイスをANまたはANXおよびアクセスネットワークに接続するネットワーク要素。 xDSLの場合、ホームゲートウェイは、レイヤー2ブリッジまたはレイヤー3ルーターとして動作できるxDSLネットワーク終端です。後者の場合、そのようなデバイスはルーティングゲートウェイ（RG）とも呼ばれます。 PONの場合、それは多くの場合、PON終端を実行するONTを備えたレイヤ3ルーティングデバイスです。
- PON-Customer-ID: identifier that uniquely identifies the ANX and the access loop logical port on the ANX to the subscriber (customer) premises and is used in any interaction between NAS and ANX that relates to access loops. Logically, it is composed of information containing identification of the OLT (the OLT may be physically and directly connected to the NAS), the PON port on the OLT, the ONT/ONU, and the port on the ONT/ONU connecting to the subscriber HGW. When acting as a DHCP relay agent, the OLT can encode PON-Customer-ID in the "Agent Circuit ID" sub-option in Option 82 of the DHCP messages [RFC3046].
- PON-Customer-ID：ANXおよび加入者（顧客）施設へのANX上のアクセスループ論理ポートを一意に識別し、アクセスループに関連するNASとANX間の相互作用で使用される識別子。論理的には、OLT（OLTは物理的に直接NASに接続されている場合があります）、OLTのPONポート、ONT / ONU、および加入者に接続しているONT / ONUのポートを含む情報で構成されます。 HGW。 DHCPリレーエージェントとして機能する場合、OLTはDHCPメッセージの[Option 82]の[Agent Circuit ID]サブオプションでPON-Customer-IDをエンコードできます[RFC3046]。
The fundamental difference between PON and DSL is that a PON is an optical broadcast network by definition. That is, at the PON level, every ONT on the same PON sees the same signal. However, the ONT filters only those PON frames addressed to it. Encryption is used on the PON to prevent eavesdropping.
PONとDSLの基本的な違いは、PONが定義上、光ブロードキャストネットワークであることです。つまり、PONレベルでは、同じPON上のすべてのONTが同じ信号を認識します。ただし、ONTは、自分宛のPONフレームのみをフィルタリングします。暗号化は、盗聴を防ぐためにPONで使用されます。
The broadcast PON capability is very suitable for delivering multicast content to connected premises, maximizing bandwidth usage efficiency on the PON. Similar to DSL deployments, enabling multicast on the Access Node Complex (ANX) provides for bandwidth use efficiency on the path between the Access Node and the NAS as well as improves the scalability of the NAS by reducing the amount of multicast traffic being replicated at the NAS. However, the broadcast capability on the PON enables the AN (OLT) to send one copy on the PON as opposed to one copy to each receiver on the PON. The PON multicast capability can be leveraged in the case of GPON and BPON as discussed in this document.
ブロードキャストPON機能は、マルチキャストコンテンツを接続された構内に配信するのに非常に適しており、PONでの帯域幅使用効率を最大化します。 DSL展開と同様に、アクセスノードコンプレックス（ANX）でマルチキャストを有効にすると、アクセスノードとNASの間のパスで帯域幅の使用効率が提供されるとともに、複製されるマルチキャストトラフィックの量が減ることにより、NASのスケーラビリティが向上します。 NAS。ただし、PONのブロードキャスト機能により、AN（OLT）は、PONの各受信機に1つのコピーを送信するのではなく、PONに1つのコピーを送信できます。このドキュメントで説明するように、PONマルチキャスト機能は、GPONおよびBPONの場合に活用できます。
Fundamental to leveraging the broadcast capability on the PON for multicast delivery is the ability to assign no key, a single encryption key for all PON frames carrying all multicast channels, or a key per set of multicast channels that correspond to a service package. When supporting encryption for multicast channels, the encryption key is generated by the OLT and sent by the OLT to each targeted ONT via the ONT Management and Control Interface (OMCI) as described in Section 15.5.2 of ITU-T G.987.3 [G.987.3] for XG-PON. It should be noted that the ONT can be a multi-dwelling unit (MDU) ONT with multiple Ethernet ports, each connected to a living unit. Thus, the ONT must not only be able to receive a multicast frame but must also be able to forward that frame only to the Ethernet port with receivers for the corresponding channel.
マルチキャスト配信のためにPONのブロードキャスト機能を活用するための基本は、キーを割り当てない機能、すべてのマルチキャストチャネルを伝送するすべてのPONフレームに単一の暗号化キー、またはサービスパッケージに対応するマルチキャストチャネルのセットごとにキーを割り当てる機能です。マルチキャストチャネルの暗号化をサポートする場合、暗号化キーはOLTによって生成され、ITU-T G.987.3 [G.987.3 [Gのセクション15.5.2で説明されているように、ONT管理および制御インターフェイス（OMCI）を介して各ターゲットONTに送信されます。 .987.3] XG-PONの場合。 ONTは、それぞれがリビングユニットに接続された複数のイーサネットポートを備えた集合住宅（MDU）ONTである可能性があることに注意してください。したがって、ONTはマルチキャストフレームを受信できるだけでなく、対応するチャネルのレシーバーがあるイーサネットポートにのみそのフレームを転送できなければなりません。
In order to implement triple-play service delivery with necessary "quality-of-experience", including end-to-end bandwidth optimized multicast video delivery, there needs to be tight coordination between the NAS and the ANX. This interaction needs to be near real-time as services are requested via application- or network-level signaling by broadband subscribers. ANCP, as defined in [RFC5851] for DSL based networks, is very suitable to realize a control protocol (with transactional exchange capabilities) between the PON-enabled ANX and the NAS and also between the components comprising the ANX, i.e., between the OLT and the ONT. Typical use cases for ANCP in the PON environment include the following:
エンドツーエンドの帯域幅最適化マルチキャストビデオ配信を含む、必要な「体験の質」を備えたトリプルプレイサービス配信を実装するには、NASとANXの間の緊密な調整が必要です。ブロードバンド加入者によるアプリケーションレベルまたはネットワークレベルのシグナリングを介してサービスが要求されるため、この相互作用はほぼリアルタイムである必要があります。 DSLベースのネットワークの[RFC5851]で定義されているANCPは、PON対応のANXとNAS間、およびANXを構成するコンポーネント間、つまりOLT間で制御トランザクション（トランザクション交換機能を使用）を実現するのに非常に適しています。とONT。 PON環境でのANCPの一般的な使用例は次のとおりです。
- Access topology discovery - Access loop configuration - Multicast - Optimized multicast delivery - Unified video resource control - NAS-based provisioning of ANX - Remote connectivity check
- アクセストポロジの検出-アクセスループ構成-マルチキャスト-最適化されたマルチキャスト配信-統合ビデオリソース制御-ANXのNASベースのプロビジョニング-リモート接続チェック
An overall end-to-end reference architecture of a PON access network is depicted in Figures 1 and 2 with ONT serving a single HGW, and ONT/ONU serving multiples HGWs, respectively. An OLT may provide FTTP and FTTB/C access at the same time but most likely not on the same PON port. Specifically, the following PON cases are addressed in the context of this reference architecture:
PONアクセスネットワークの全体的なエンドツーエンドのリファレンスアーキテクチャを図1および2に示します。ONTは1つのHGWに対応し、ONT / ONUは複数のHGWに対応しています。 OLTは、FTTPとFTTB / Cアクセスを同時に提供する可能性がありますが、同じPONポート上ではない可能性があります。具体的には、次のPONケースは、このリファレンスアーキテクチャのコンテキストで対処されます。
- BPON with Ethernet uplink to the NAS and ATM on the PON side - GPON/XG-PON with Ethernet uplink to the NAS and Ethernet on the PON side
- NASへのイーサネットアップリンクとPON側のATMを備えたBPON-PON側のNASとイーサネットへのイーサネットアップリンクを備えたGPON / XG-PON
In the case of an Ethernet aggregation network that supports new QoS-enabled IP services (including Ethernet multicast replication), the architecture builds on the reference architecture specified in the Broadband Forum (BBF) [TR-101]. The Ethernet aggregation network between a NAS and an OLT may be degenerated to one or more direct physical Ethernet links.
新しいQoS対応のIPサービス（イーサネットマルチキャストレプリケーションを含む）をサポートするイーサネットアグリゲーションネットワークの場合、アーキテクチャは、ブロードバンドフォーラム（BBF）[TR-101]で指定されたリファレンスアーキテクチャに基づいて構築されます。 NASとOLT間のイーサネットアグリゲーションネットワークは、1つ以上の直接物理イーサネットリンクに縮退する場合があります。
Given the industry move towards Ethernet as the new access and aggregation technology for triple-play services, the primary focus throughout this document is on GPON/XG-PON and BPON with Ethernet between the NAS and the OLT.
トリプルプレイサービスの新しいアクセスおよびアグリゲーションテクノロジーとして業界がイーサネットに移行していることを考えると、このドキュメント全体の主な焦点は、NASとOLT間のイーサネットを備えたGPON / XG-PONおよびBPONです。
Access Customer
<---------Aggregation-------><-Prem->
Network Network
+------------------+
| Access Node |
| Complex (ANX) |
+---------+ +---+ +-----+ |+---+ +---+ | +---+
| | +-|NAS|--|Eth |--||OLT|-<PON>-|ONT|-|--|HGW|
NSP---+Regional | | +---+ |Agg | |+---+ +---+ | +---+
|Broadband| | +---+ +-----+ +------------------+
|Network |-+-|NAS| |
ASP---+ | | +---+ |
| | | +---+ |
+---------+ +-|NAS| | +---+ +---+
+---| +-<PON>-|ONT|--|HGW|
| +---+ +---+
|
| +---+ +---+
+---|ONT|--|HGW|
+---+ +---+
HGW : Home Gateway
NAS : Network Access Server
PON : Passive Optical Network
OLT : Optical Line Terminal
ONT : Optical Network Terminal
Figure 1: Access Network with PON
図1：PONを使用したアクセスネットワーク
FE/GE/VDSL
+---+ +---+
+----------------+ | |-|HGW|
+---------+ +-----+ | +-----+ +----+| | | +---+
| | +-|NAS |--| |Eth |--|OLT||-<PON>- | |
NSP---+Regional | | +-----+ | |Agg | | || | |ONT| +---+
|Broadband| | | | | | || | | or|-|HGW|
|Network | | +-----+ | +-----+ +----+| | |ONU| +---+
| |-+-|NAS | +----------------+ | | |
ASP---+ | | +-----+ | | | +---+
| | | +-----+ | | |-|HGW|
+---------+ +-|NAS | | +---+ +---+
+-----+ |
| +---+ +---+
+-|ONT|-|HGW|
+---+ +---+
Figure 2: FTTP/FTTB/C with Multi-Subscriber ONT/ONU Serving MTUs/MDUs
The following sections describe the functional blocks and network segments in the PON access reference architecture.
次のセクションでは、PONアクセスリファレンスアーキテクチャの機能ブロックとネットワークセグメントについて説明します。
The Home Gateway (HGW) connects the different CPEs to the ANX and the access network. In the case of PON, the HGW is a Layer 3 router. In this case, the HGW performs IP configuration of devices within the home via DHCP and performs Network Address and Port Translation (NAPT) between the LAN and WAN side. In the case of FTTP/B/C, the HGW connects to the ONT/ONU over an Ethernet interface. That Ethernet interface could be over an Ethernet physical port or over another medium. In the case of FTTP, it is possible to have a single box GPON CPE solution where the ONT encompasses the HGW functionality as well as the GPON adaptation function.
ホームゲートウェイ（HGW）は、さまざまなCPEをANXおよびアクセスネットワークに接続します。 PONの場合、HGWはレイヤー3ルーターです。この場合、HGWはDHCPを介してホーム内のデバイスのIP構成を実行し、LANとWAN側の間でネットワークアドレスとポート変換（NAPT）を実行します。 FTTP / B / Cの場合、HGWはイーサネットインターフェイスを介してONT / ONUに接続します。そのイーサネットインターフェイスは、イーサネットの物理ポートまたは別のメディア上にある可能性があります。 FTTPの場合、ONTがHGW機能とGPON適応機能を含むシングルボックスGPON CPEソリューションを使用できます。
PON access is composed of the ONT/ONU and OLT. PON ensures physical connectivity between the ONT/ONU at the customer premises and the OLT. PON framing can be BPON or GPON. The protocol encapsulation on BPON is based on multi-protocol encapsulation over ATM Adaptation Layer 5 (AAL5), defined in [RFC2684]. This covers PPP over Ethernet (PPPoE, defined in [RFC2516]) or IP over Ethernet (IPoE). The protocol encapsulation on GPON is always IPoE. In all cases, the connection between the AN (OLT) and the NAS (or BNG) is assumed to be Ethernet in this document.
PONアクセスは、ONT / ONUとOLTで構成されます。 PONは、顧客構内のONT / ONUとOLTの間の物理的な接続を保証します。 PONフレーミングはBPONまたはGPONです。 BPONのプロトコルカプセル化は、[RFC2684]で定義されている、ATMアダプテーションレイヤー5（AAL5）上のマルチプロトコルカプセル化に基づいています。これはPPP over Ethernet（PPPoE、[RFC2516]で定義）またはIP over Ethernet（IPoE）をカバーしています。 GPONのプロトコルカプセル化は常にIPoEです。このドキュメントでは、すべての場合において、AN（OLT）とNAS（またはBNG）の間の接続はイーサネットであると想定しています。
The Access Node Complex (ANX) is composed of OLT and ONT/ONU and is defined in Section 2.
Access Node Complex（ANX）はOLTとONT / ONUで構成され、セクション2で定義されています。
The ANX uplink connects the OLT to the NAS. The fundamental requirements for the ANX uplink are to provide traffic aggregation, Class of Service distinction, customer separation, and traceability. This can be achieved using an ATM or an Ethernet-based technology. As stated earlier, the focus in this document is on Ethernet.
ANXアップリンクは、OLTをNASに接続します。 ANXアップリンクの基本的な要件は、トラフィック集約、サービスクラスの区別、顧客の分離、およびトレーサビリティを提供することです。これは、ATMまたはイーサネットベースのテクノロジーを使用して実現できます。前述したように、このドキュメントではイーサネットに焦点を当てています。
The aggregation network provides traffic aggregation towards the NAS. The aggregation network is assumed to be Ethernet in this document.
集約ネットワークは、NASへのトラフィック集約を提供します。このドキュメントでは、集約ネットワークはイーサネットであると想定しています。
The NAS is a network device that aggregates multiplexed subscriber traffic from a number of ANXs. The NAS plays a central role in per-subscriber policy enforcement and QoS. It is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in [RFC2881]. The NAS interfaces to the aggregation network by means of 802.1Q or 802.1 Q-in-Q Ethernet interfaces and towards the Regional Network by means of transport interfaces (e.g., GigE, PPP over Synchronous Optical Network (SONET)). The NAS functionality corresponds to the BNG functionality described in BBF TR-101 [TR-101]. In addition, the NAS supports the Access Node Control functionality defined for the respective use cases in this document.
NASは、多数のANXからの多重化された加入者トラフィックを集約するネットワークデバイスです。 NASは、加入者ごとのポリシーの適用とQoSにおいて中心的な役割を果たします。多くの場合、ブロードバンドネットワークゲートウェイ（BNG）またはブロードバンドリモートアクセスサーバー（BRAS）と呼ばれます。 NASの詳細な定義は[RFC2881]に記載されています。 NASは、802.1Qまたは802.1 Q-in-Qイーサネットインターフェイスを介して集約ネットワークに接続し、トランスポートインターフェイス（GigE、PPP over Synchronous Optical Network（SONET）など）を使用してリージョナルネットワークに接続します。 NAS機能は、BBF TR-101 [TR-101]で説明されているBNG機能に対応しています。さらに、NASは、このドキュメントのそれぞれのユースケースに対して定義されたアクセスノード制御機能をサポートしています。
The Regional Network connects one or more NASs and associated access networks to Network Service Providers (NSPs) and Application Service Providers (ASPs). The NSP authenticates access and provides and manages the IP address to subscribers. It is responsible for overall service assurance and includes Internet Service Providers (ISPs). The ASP provides application services to the application subscriber (gaming, video, content on demand, IP telephony, etc.). The NAS can be part of the NSP network. Similarly, the NSP can be the ASP.
リージョナルネットワークは、1つ以上のNASおよび関連するアクセスネットワークをネットワークサービスプロバイダー（NSP）およびアプリケーションサービスプロバイダー（ASP）に接続します。 NSPはアクセスを認証し、IPアドレスを加入者に提供および管理します。全体的なサービス保証を担当し、インターネットサービスプロバイダー（ISP）が含まれます。 ASPはアプリケーションサブスクライバーにアプリケーションサービスを提供します（ゲーム、ビデオ、オンデマンドコンテンツ、IPテレフォニーなど）。 NASはNSPネットワークの一部にすることができます。同様に、NSPはASPにすることができます。
Section 3 details the differences between xDSL access and PON access and the implication of these differences on DSLAM control versus OLT and ONT/ONU (ANX) control. The following sections describe two reference models: (1) ANCP+OMCI ANX control and (2) All-ANCP ANX control. That is, the two models differ in the ONT/ONU control within the ANX. Choosing which model to implement may be based on the ONT/ONU type and the capabilities of the ONT/ONU and OLT; this is an implementation-specific decision that is outside the scope of this document. It is possible for an OLT or an OLT PON port to connect to ONTs/ONUs with different capabilities and for these two models to co-exist on the same OLT and same PON. Section 12 describes the differences between OMCI and ANCP in controlling the ONU/ONT.
セクション3では、xDSLアクセスとPONアクセスの違いと、DSLAM制御とOLTおよびONT / ONU（ANX）制御とのこれらの違いの影響について詳しく説明します。次のセクションでは、2つの参照モデルについて説明します。（1）ANCP + OMCI ANX制御と（2）All-ANCP ANX制御。つまり、2つのモデルでは、ANX内のONT / ONU制御が異なります。実装するモデルの選択は、ONT / ONUタイプと、ONT / ONUおよびOLTの機能に基づいて行うことができます。これは実装固有の決定であり、このドキュメントの範囲外です。 OLTまたはOLT PONポートを異なる機能のONT / ONUに接続し、これら2つのモデルを同じOLTと同じPONで共存させることができます。セクション12では、ONU / ONTの制御におけるOMCIとANCPの違いについて説明します。
OMCI is designed as a protocol between the OLT and ONT/ONU. It enables the OLT to configure and administer capabilities on the ONT/ONU in BPON, GPON, and XG-PON. ANCP is designed as a protocol between the NAS and Access Node. Among other functions, it enables the NAS to enforce dynamic policies on the Access Node and the Access Node to report events to the NAS.
OMCIは、OLTとONT / ONU間のプロトコルとして設計されています。これにより、OLTはBPON、GPON、およびXG-PONのONT / ONUの機能を構成および管理できます。 ANCPは、NASとアクセスノード間のプロトコルとして設計されています。特に、NASはアクセスノードとアクセスノードに動的ポリシーを適用して、イベントをNASに報告できるようにします。
Figure 3 depicts the reference model for ANCP+OMCI ANX control. In this model, ANCP is enabled between the NAS and a connected OLT, and OMCI is enabled between the OLT and an attached ONT/ONU. NAS communicates with the ANX via ANCP. The OLT acts as an ANCP/OMCI gateway for communicating necessary events and policies between the OLT and ONT/ONU within the ANX and for communicating relevant policies and events between the ONT/ONU and the NAS. The functionality performed by the OLT as an ANCP/OMCI gateway will be application dependent (e.g., multicast control, topology discovery) and should be specified in a related specification. It should be noted that some applications are expected to require ANCP and/or OMCI extensions to map messages between OMCI and ANCP. OMCI extensions are likely to be defined by the ITU-T. It should also be noted that in addition to configuration and administration, OMCI provides the capability to report status changes on an ONT/ONU with AVC (Attribute Value Change) notifications. When the ONT/ONU's DSL or Ethernet User-Network Interface (UNI) attributes change, a related Management Entity will send a corresponding notification (AVC) to the OLT. The OLT interworks such a notification into an ANCP report and sends it to the connected NAS via the ANCP session between the OLT and the NAS. As the ANCP report contains information of ONT/ONU's UNI and OLT's PON port, NAS can obtain accurate information of access topology.
図3は、ANCP + OMCI ANXコントロールの参照モデルを示しています。このモデルでは、NASと接続されたOLTの間でANCPが有効になり、OLTと接続されたONT / ONUの間でOMCIが有効になります。 NASはANCPを介してANXと通信します。 OLTはANCP / OMCIゲートウェイとして機能し、ANX内のOLTとONT / ONUの間で必要なイベントとポリシーを通信し、ONT / ONUとNASの間で関連するポリシーとイベントを通信します。 ANCP / OMCIゲートウェイとしてOLTによって実行される機能は、アプリケーションに依存し（マルチキャスト制御、トポロジー検出など）、関連する仕様で指定する必要があります。一部のアプリケーションでは、OMCIとANCPの間でメッセージをマップするためにANCPまたはOMCI拡張機能、あるいはその両方が必要になることが予想されます。 OMCI拡張は、ITU-Tによって定義される可能性があります。 OMCIは、構成と管理に加えて、ONT / ONUのステータス変更をAVC（属性値変更）通知で報告する機能を提供することにも注意してください。 ONT / ONUのDSLまたはイーサネットユーザーネットワークインターフェイス（UNI）属性が変更されると、関連する管理エンティティが対応する通知（AVC）をOLTに送信します。 OLTはそのような通知をANCPレポートにインターワークし、OLTとNAS間のANCPセッションを介して接続されたNASに送信します。 ANCPレポートにはONT / ONUのUNIおよびOLTのPONポートの情報が含まれているため、NASはアクセストポロジの正確な情報を取得できます。
+----------------------+
| ANX |
+---------+ +---+ +---+ |+---+ +-------+ | +---+
| | +-|NAS|--|Eth|--||OLT|-<PON>-|ONU/ONT|-|-|HGW|
NSP---+Regional | | +---+ |Agg| |+---+ +-------+ | +---+
|Broadband| | +---+ +---+ +----------------------+
|Network |-+-|NAS| |
ASP---+ | | +---+ |
| | | +---+ |
+---------+ +-|NAS| | +-------+ +---+
+---| +-<PON>-|ONU/ONT|-|HGW|
| +-------+ +---+
| +---+ +---+
+--|ONT|-----|HGW|
+---+ +---+
ANCP OMCI
+<--------------->+<----------->+
HGW: Home Gateway NAS: Network Access Server PON: Passive Optical Network OLT: Optical Line Terminal ONT: Optical Network Terminal ONU: Optical Network Unit
HGW：ホームゲートウェイNAS：ネットワークアクセスサーバーPON：パッシブ光ネットワークOLT：光回線ターミナルONT：光ネットワークターミナルONU：光ネットワークユニット
Figure 3: Access Network with Single ANCP+OMCI Control
図3：単一のANCP + OMCI制御によるアクセスネットワーク
Figure 4 depicts the All-ANCP ANX control reference model. In this model, an ANCP session is enabled between a NAS and a connected OLT, and another ANCP session is enabled between the OLT and a connected ONT/ONU. ANCP enables communication of policies and events between the OLT and the ANX. The OLT acts as a gateway to relay policies and events between the NAS and ONT/ONU within the ANX in addition to communicating policies and events between the OLT and ONT/ONU. It should be noted that in this model, OMCI (not shown) is expected to be simultaneously enabled between the ONT and OLT, supporting existing OMCI capabilities and applications on the PON, independent of ANCP or applications intended to be supported by ANCP.
図4は、All-ANCP ANX制御参照モデルを示しています。このモデルでは、NASと接続されたOLTの間でANCPセッションが有効になり、OLTと接続されたONT / ONUの間で別のANCPセッションが有効になります。 ANCPは、OLTとANX間のポリシーとイベントの通信を可能にします。 OLTは、OLTとONT / ONU間のポリシーとイベントの通信に加えて、NASとANX内のONT / ONU間のポリシーとイベントを中継するゲートウェイとして機能します。このモデルでは、OMCI（図示せず）がONTとOLTの間で同時に有効になり、既存のOMCI機能と、PONPでサポートされる予定のアプリケーションとは無関係に、PON上のアプリケーションをサポートすることに注意してください。
+----------------------+
| Access Node Complex |
| (ANX) |
+---------+ +---+ +---+ |+---+ +-------+ | +---+
| | +-|NAS|--|Eth|--||OLT|-<PON>-|ONU/ONT| |--|HGW|
NSP---+Regional | | +---+ |Agg| |+---+ +-------+ | +---+
|Broadband| | +---+ +---+ +----------------------+
|Network |-+-|NAS| |
ASP---+ | | +---+ |
| | | +---+ |
+---------+ +-|NAS| | +-------+ +---+
+---| +-<PON>-|ONU/ONT|--|HGW|
| +-------+ +---+
|
| +-------+ +---+
+---|ONU/ONT|--|HGW|
+-------+ +---+
ANCP ANCP
+<----------------->+<---------->+
HGW: Home Gateway NAS: Network Access Server PON: Passive Optical Network OLT: Optical Line Terminal ONT: Optical Network Terminal ONU: Optical Network Unit
HGW：ホームゲートウェイNAS：ネットワークアクセスサーバーPON：パッシブ光ネットワークOLT：光回線ターミナルONT：光ネットワークターミナルONU：光ネットワークユニット
Figure 4: All-ANCP ANX Control Reference Model
図4：All-ANCP ANX制御参照モデル
The high-level communication framework for an Access Node Control Mechanism is shown in Figure 5 for the All-ANCP ANX control model. The Access Node Control Mechanism defines a quasi-real-time, general-purpose method for multiple network scenarios with an extensible communication scheme, addressing the different use cases that are described in the sections that follow. The Access Node Control Mechanism is also extended to run between OLT and ONT/ONU. The mechanism consists of a controller function and a reporting and/or enforcement function. The controller function is used to receive status information or admission requests from the reporting function. It is also used to trigger a certain behavior in the network element where the reporting and/or enforcement function resides.
All-ANCP ANX制御モデルのアクセスノード制御メカニズムの高レベルの通信フレームワークを図5に示します。アクセスノード制御メカニズムは、拡張可能な通信スキームを使用して複数のネットワークシナリオに準リアルタイムで汎用的な方法を定義し、以下のセクションで説明するさまざまな使用例に対応します。アクセスノード制御メカニズムも拡張され、OLTとONT / ONUの間で実行されます。このメカニズムは、コントローラー機能とレポートおよび/または実施機能で構成されます。コントローラ機能は、レポート機能からステータス情報または承認要求を受信するために使用されます。また、レポート機能や適用機能が存在するネットワーク要素で特定の動作をトリガーするためにも使用されます。
The reporting function is used to convey status information to the controller function that requires the information for executing local functions. The enforcement function can be contacted by the controller function to enforce a specific policy or trigger a local action. The messages shown in Figure 5 show the conceptual message flow. The actual use of these flows, and the times or frequencies when these messages are generated, depend on the actual use cases, which are described in later sections.
レポート機能は、ローカル機能を実行するための情報を必要とするコントローラー機能にステータス情報を伝えるために使用されます。実施機能は、特定のポリシーを実施したり、ローカルアクションをトリガーしたりするために、コントローラー機能からアクセスできます。図5に示すメッセージは、概念的なメッセージフローを示しています。これらのフローの実際の使用、およびこれらのメッセージが生成される時間または頻度は、後のセクションで説明する実際の使用例によって異なります。
+--------+
| Policy | +----+
| Server | +--<PON>---|ONT |------- HGW
+--------+ + +----+ +---+
| + +----------|ONT|----HGW
| + | +---+
| +----------------|-------------+
+----+ | +----+ | +-----+ | +---+
|NAS |---------------| | | | |-|----|HGW|
| |<------------->| | | | ONU | | +---+
+----+ ANCP | |OLT |------<PON>----| | |
| | | | | | | +---+
| | | |<------------->| |------|HGW|
| | +----+ ANCP +-----+ | +---+
| +------------------------------+
| | Access Node |
| Control Request | |
| ------------------>| Control Request |
| |-------------------->|
| | Control Response |
| Control Response |<------------------- |
|<-------------------| |
| |Admission Request |
| Admission Request |<--------------------|
|<-------------------| |
|Admission Response | |
|------------------->|Admission Response |
| |-------------------->|
|Information Report | |
|<-------------------| |
Access Node Control Access Node Control
Mechanism Mechanism
<--------------------><-------------------->
PPP, DHCP, IP
<------------------------------------------------------>
Figure 5: Conceptual Message Flow for Access Node Control Mechanism in All-ANCP ANX Control Model
図5：All-ANCP ANX制御モデルのアクセスノード制御メカニズムの概念的なメッセージフロー
As discussed previously, in different PON deployment scenarios, ANCP may be used in variant ways and may interwork with other protocols, e.g., OMCI. In the ANCP+OMCI control model described earlier, the NAS maintains ANCP adjacency with the OLT while the OLT controls the ONT/ONU via OMCI. The messages shown in Figure 6 show the conceptual message flow for this model. The actual use of these flows, and the times or frequencies when these messages are generated, depend on the actual use cases.
前述のように、さまざまなPON展開シナリオでは、ANCPはさまざまな方法で使用でき、他のプロトコル（OMCIなど）と相互に作用します。前述のANCP + OMCI制御モデルでは、OLTがOMCIを介してONT / ONUを制御している間、NASはOLTとのANCP隣接を維持します。図6に示すメッセージは、このモデルの概念的なメッセージフローを示しています。これらのフローの実際の使用、およびこれらのメッセージが生成される時間または頻度は、実際の使用例によって異なります。
+--------+
| Policy |
| Server |
+--------+ +---+ +---+
| +---- |ONT|--------|HGW|
| | +---+ +---+
| +--------------- |-------------+
+----+ | +----+ | +-----+ | +---+
|NAS |---------------| | | | |-|----|HGW|
| |<------------->| | | | ONU | | +---+
+----+ ANCP | |OLT |------<PON>----| | |
| | | | | | | +---+
| | | |<------------->| |------|HGW|
| | +----+ OMCI +-----+ | +---+
| +-----------------------------+
| | Access Node |
| Control Request | |
| ------------------>| Control Request |
| |-------------------->|
| | Control Response |
| Control Response |<------------------- |
|<-------------------| |
| |Admission Request |
| Admission Request |<--------------------|
|<-------------------| |
|Admission Response | |
|------------------->|Admission Response |
| |-------------------->|
|Information Report | |
|<-------------------| |
Access Node Control Operating Maintenance
Mechanism Control Interface (OMCI)
<--------------------><-------------------->
PPP, DHCP, IP
<------------------------------------------------------->
Figure 6: Conceptual Message Flow for ANCP+OMCI ANX Control Model
図6：ANCP + OMCI ANX制御モデルの概念的なメッセージフロー
With the rise of supporting IPTV services in a resource-efficient way, multicast services are becoming increasingly important.
リソース効率の高い方法でのIPTVサービスのサポートの台頭により、マルチキャストサービスはますます重要になっています。
In order to gain bandwidth optimization with multicast, the replication of multicast content per access loop needs to be distributed to the ANX. This can be done by ANX (OLT and ONT/ONU) becoming multicast aware by implementing an IGMP [RFC3376] snooping and/or proxy function [RFC4605]. The replication thus needs to be distributed between NAS, aggregation nodes, and ANX. In the case of GPON and in the case of BPON with Ethernet uplink, this is very viable. By introducing IGMP processing on the ANX and aggregation nodes, the multicast replication process is now divided between the NAS, the aggregation node(s), and ANX. This is in contrast to the ATM-based model where NAS is the single element responsible for all multicast control and replication. In order to ensure backward compatibility with the ATM-based model, the NAS, aggregation node, and ANX 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 ANX and the NAS.
マルチキャストで帯域幅を最適化するには、アクセスループごとのマルチキャストコンテンツのレプリケーションをANXに配布する必要があります。これは、IGMP [RFC3376]スヌーピングおよび/またはプロキシ機能[RFC4605]を実装することにより、ANX（OLTおよびONT / ONU）がマルチキャスト対応になることで実行できます。したがって、レプリケーションは、NAS、集約ノード、およびANX間で分散する必要があります。 GPONの場合とイーサネットアップリンクを使用するBPONの場合、これは非常に実行可能です。 ANXおよび集約ノードでIGMP処理を導入することにより、マルチキャストレプリケーションプロセスは、NAS、集約ノード、およびANXの間で分割されます。これは、NASがすべてのマルチキャスト制御と複製を担当する単一の要素であるATMベースのモデルとは対照的です。 ATMベースのモデルとの下位互換性を確保するために、NAS、集約ノード、およびANXは単一の論理デバイスとして動作する必要があります。この論理デバイスは、ATMアクセス/集約ネットワークのNASとまったく同じ機能を備えている必要があります。アクセスノード制御メカニズムを使用して、ANXとNASの間で必要な情報を交換することにより、この論理的/機能的同等性を確実に実現できます。
An alternative to multicast awareness in the ANX is for the subscriber to communicate the IGMP "join/leave" messages with the NAS, while the ANX is being transparent to these messages. In this scenario, the NAS can use ANCP to create replication state in the ANX for efficient multicast replication. The NAS sends a single copy of the multicast stream towards the ANX. The NAS can perform network-based conditional access and multicast admission control on multicast joins and create replication state in the ANX if the request is admitted by the NAS.
ANXでのマルチキャスト認識の代替手段は、ANXがこれらのメッセージに対して透過的である間に、加入者がIGMPの「参加/脱退」メッセージをNASと通信することです。このシナリオでは、NASはANCPを使用してANXにレプリケーション状態を作成し、効率的なマルチキャストレプリケーションを実現できます。 NASは、マルチキャストストリームの単一のコピーをANXに送信します。 NASは、マルチキャスト結合でネットワークベースの条件付きアクセスとマルチキャストアドミッション制御を実行し、要求がNASによって許可された場合、ANXにレプリケーション状態を作成できます。
The following sections describe various use cases related to multicast.
次のセクションでは、マルチキャストに関連するさまざまな使用例について説明します。
In a broadband FTTP/B/C access scenario, service providers may want to dynamically control, at the network level, access to some multicast flows on a per user basis. This may be used in order to differentiate among multiple Service Offers or to realize/reinforce conditional access based on customer subscription. Note that, in some environments, application-layer conditional access by means of Digital Rights Management (DRM), for instance, may provide sufficient control so that network-based multicast conditional access may not be needed. However, network-level access control may add to the service security by preventing the subscriber from receiving a non-subscribed channel. In addition, it enhances network security by preventing a multicast stream from being sent on a link or a PON based on a non-subscriber request.
ブロードバンドFTTP / B / Cアクセスシナリオでは、サービスプロバイダーは、ネットワークレベルで、ユーザーごとにいくつかのマルチキャストフローへのアクセスを動的に制御する必要があります。これは、複数のサービスオファーを区別するため、または顧客のサブスクリプションに基づいて条件付きアクセスを実現/強化するために使用できます。一部の環境では、たとえば、デジタル著作権管理（DRM）によるアプリケーション層の条件付きアクセスが十分な制御を提供し、ネットワークベースのマルチキャスト条件付きアクセスが不要になる場合があることに注意してください。ただし、ネットワークレベルのアクセス制御は、サブスクライバがサブスクライブされていないチャネルを受信できないようにすることで、サービスのセキュリティを強化する場合があります。さらに、非加入者の要求に基づいてリンクまたはPONでマルチキャストストリームが送信されるのを防ぐことにより、ネットワークのセキュリティを強化します。
Where network-based channel conditional access is desired, there are two approaches. First, it can be done on the NAS along with bandwidth-based admission control. The NAS can control the replication state on the ANX based on the outcome of access and bandwidth-based admission control. This is covered in a later section. A second approach is to provision the necessary conditional access information on the ANX (ONT/ONU and/or OLT) so the ANX can perform the conditional access decisions autonomously. For these cases, the NAS can use ANCP to provision black and white lists as defined in [RFC5851] on the ANX so that the ANX can decide locally to honor a join or not. It should be noted that in the PON case, the ANX is composed of the ONT/ONU and OLT. Thus, this information can be programmed on the ONT/ONU and/or OLT. Programming this information on the ONT/ONU prevents illegitimate joins from propagating further into the network. A third approach, outside of the scope of this document, may be to program the HGW with the access list. A white list associated with an Access Port identifies the multicast channels that are allowed to be replicated to that port. A black list associated with an Access Port identifies the multicast channels that are not allowed to be replicated to that port. It should be noted that the black list, if not explicitly programmed, is the complement of the white list and vice versa.
ネットワークベースのチャネル条件付きアクセスが必要な場合、2つのアプローチがあります。 1つは、帯域幅ベースのアドミッションコントロールとともにNASで実行できることです。 NASは、アクセスの結果と帯域幅ベースのアドミッションコントロールに基づいて、ANXのレプリケーション状態を制御できます。これについては、後のセクションで説明します。 2番目のアプローチは、ANX（ONT / ONUまたはOLT、あるいはその両方）に必要な条件付きアクセス情報をプロビジョニングして、ANXが条件付きアクセスの決定を自律的に実行できるようにすることです。これらの場合、NASはANCPを使用してANXの[RFC5851]で定義されているブラックリストとホワイトリストをプロビジョニングできるため、ANXはローカルで参加を受け入れるかどうかを決定できます。 PONの場合、ANXはONT / ONUとOLTで構成されることに注意してください。したがって、この情報はONT / ONUやOLTにプログラムできます。 ONT / ONUでこの情報をプログラミングすることにより、不正な結合がネットワークにさらに伝播することを防ぎます。このドキュメントの範囲外の3番目のアプローチは、アクセスリストを使用してHGWをプログラムすることです。アクセスポートに関連付けられたホワイトリストは、そのポートに複製できるマルチキャストチャネルを識別します。アクセスポートに関連付けられたブラックリストは、そのポートへの複製が許可されていないマルチキャストチャネルを識別します。ブラックリストは、明示的にプログラムされていない場合、ホワイトリストの補足であり、その逆も同様です。
If the ONT/ONU performs IGMP snooping and is programmed with a channel access list, the ONT/ONU will first check if the requested multicast channel is part of a white list or a black list associated with the Access Port on which the IGMP join is received. If the channel is part of a white list, the ONT/ONU will pass the join request upstream towards the NAS. The ONT/ONU must not start replicating the associated multicast stream to the Access Port if such a stream is received until it gets confirmation that it can do so from the upstream node (NAS or OLT). Passing the channel access list is one of the admission control criteria whereas bandwidth-based admission control is another. If the channel is part of a black list, the ONT/ONU can autonomously discard the message because the channel is not authorized for that subscriber.
ONT / ONUがIGMPスヌーピングを実行し、チャネルアクセスリストを使用してプログラムされている場合、ONT / ONUは最初に、要求されたマルチキャストチャネルが、IGMP参加のアクセスポートに関連付けられているホワイトリストまたはブラックリストの一部であるかどうかをチェックします受け取った。チャネルがホワイトリストの一部である場合、ONT / ONUは参加要求をNASに向けて上流に渡します。 ONT / ONUは、アップストリームノード（NASまたはOLT）からマルチキャストストリームを受信できることを確認するまで、そのストリームが受信された場合、関連するマルチキャストストリームのアクセスポートへの複製を開始しないでください。チャネルアクセスリストを渡すことはアドミッション制御基準の1つですが、帯域幅ベースのアドミッション制御はもう1つです。チャネルがブラックリストの一部である場合、チャネルはそのサブスクライバーに対して承認されていないため、ONT / ONUは自律的にメッセージを破棄できます。
The ONT/ONU, in addition to forwarding the IGMP join, sends an ANCP admission request to the OLT identifying the channel to be joined and the premises. Premises identification to the OLT can be based on a Customer-Port-ID that maps to the Access Port on the ONT/ONU and is known at the ONT/ONU and OLT. If the ONT/ONU has a white list and/or a black list per premises, the OLT need not have such a list. If the ONT/ONU does not have such a list, the OLT may be programmed with such a list for each premises. In the latter case, the OLT would perform the actions described earlier on the ONT/ONU. Once the outcome of admission control (conditional access and bandwidth-based admission control) is determined by the OLT (either by interacting with the NAS or locally), it is informed to the ONT/ONU. OLT bandwidth-based admission control scenarios are defined in a later section.
ONT / ONUは、IGMP参加の転送に加えて、参加するチャネルと施設を識別するANCP許可要求をOLTに送信します。 OLTに対する前提の識別は、ONT / ONU上のアクセスポートにマップされ、ONT / ONUおよびOLTで認識されているCustomer-Port-IDに基づくことができます。 ONT / ONUに施設ごとのホワイトリストまたはブラックリスト、あるいはその両方がある場合、OLTはそのようなリストを持つ必要はありません。 ONT / ONUにそのようなリストがない場合、OLTは施設ごとにそのようなリストを使用してプログラムできます。後者の場合、OLTはONT / ONUで前に説明したアクションを実行します。アドミッション制御（条件付きアクセスおよび帯域幅ベースのアドミッション制御）の結果がOLTによって（NASとのやり取りまたはローカルで）決定されると、ONT / ONUに通知されます。 OLT帯域幅ベースのアドミッション制御シナリオは、後のセクションで定義されています。
The white list and black list can contain entries allowing:
ホワイトリストとブラックリストには、次のことを可能にするエントリを含めることができます。
- An exact match for a (*,G) Any-Source Multicast (ASM) group (e.g., <G=g.h.i.l>)
- （*、G）Any-Source Multicast（ASM）グループの完全一致（例：<G = g.h.i.l>）
- An exact match for a (S,G) Source-Specific Multicast (SSM) channel (e.g., <S=s.t.u.v,G=g.h.i.l>)
- （S、G）Source-Specific Multicast（SSM）チャネルの完全一致（例：<S = s.t.u.v、G = g.h.i.l>）
- A mask-based range match for a (*,G) ASM group (e.g., <G=g.h.i.l/Mask>)
- （*、G）ASMグループのマスクベースの範囲一致（例：<G = g.h.i.l / Mask>）
- A mask-based range match for a (S,G) SSM channel (e.g., <S=s.t.u.v,G=g.h.i.l/Mask>)
- （S、G）SSMチャネルのマスクベースの範囲一致（例：<S = s.t.u.v、G = g.h.i.l / Mask>）
The use of a white list and black list may be applicable, for instance, to regular IPTV services (i.e., Broadcast TV) offered by an Access Provider to broadband (e.g., FTTP) subscribers. For this application, the IPTV subscription is typically bound to a specific FTTP home, and the multicast channels that are part of the subscription are well-known beforehand. Furthermore, changes to the conditional access information are infrequent, since they are bound to the subscription. Hence, the ANX can be provisioned with the conditional access information related to the IPTV service.
ホワイトリストとブラックリストの使用は、たとえば、アクセスプロバイダーがブロードバンド（FTTPなど）の加入者に提供する通常のIPTVサービス（ブロードキャストTVなど）に適用できます。このアプリケーションの場合、IPTVサブスクリプションは通常、特定のFTTPホームにバインドされ、サブスクリプションの一部であるマルチキャストチャネルは事前によく知られています。さらに、条件付きアクセス情報はサブスクリプションにバインドされているため、変更はほとんどありません。したがって、ANXには、IPTVサービスに関連する条件付きアクセス情報をプロビジョニングできます。
Instead of including the channel list(s) at the ONT/ONU, the OLT or NAS can be programmed with these access lists. Having these access lists on the ONT/ONU prevents forwarding of unauthorized joins to the OLT or NAS, reducing unnecessary control load on these network elements. Similarly, performing the access control at the OLT instead of the NAS, if not performed on the ONT/ONU, will reduce unnecessary control load on the NAS.
ONT / ONUにチャネルリストを含める代わりに、OLTまたはNASをこれらのアクセスリストでプログラムできます。 ONT / ONUにこれらのアクセスリストがあると、OLTまたはNASへの不正な結合の転送が防止され、これらのネットワーク要素に対する不要な制御負荷が軽減されます。同様に、NASの代わりにOLTでアクセス制御を実行すると、ONT / ONUで実行しない場合、NASの不要な制御負荷が軽減されます。
The successful delivery of triple-play broadband services is quickly becoming a big capacity-planning challenge for most of the service providers nowadays. Solely increasing available bandwidth is not always practical, cost-economical, and/or sufficient to satisfy end- user experience given not only the strict QoS requirements of unicast applications like VoIP and Video on Demand but also the fast growth of multicast interactive applications such as "video conferencing", digital TV, and digital audio. These applications typically require low delay, low jitter, low packet loss, and high bandwidth. These applications are also typically "non-elastic", which means that they operate at a fixed bandwidth that cannot be dynamically adjusted to the currently available bandwidth.
トリプルプレイブロードバンドサービスの配信の成功は、現在、ほとんどのサービスプロバイダーにとって、容量計画の大きな課題となっています。 VoIPやビデオオンデマンドなどのユニキャストアプリケーションの厳密なQoS要件だけでなく、マルチキャストインタラクティブアプリケーションなどのマルチキャストインタラクティブアプリケーションの急速な成長を考えると、利用可能な帯域幅を増やすだけでは、必ずしも実用的でコスト効率がよく、エンドユーザーエクスペリエンスを満たすのに十分ではありません。 「ビデオ会議」、デジタルTV、デジタルオーディオ。これらのアプリケーションは通常、低遅延、低ジッター、低パケット損失、高帯域幅を必要とします。これらのアプリケーションも通常「非弾性」です。つまり、現在利用可能な帯域幅に動的に調整できない固定帯域幅で動作します。
An Admission Control (AC) Mechanism covering admission of multicast traffic for the FTTP/B/C access is required in order to avoid over-subscribing the available bandwidth and negatively impacting the end-user experience. Before honoring a user request to join a new multicast flow, the combination of ANX and NAS must ensure admission control is performed to validate that there is enough video bandwidth remaining on the PON and on the uplink between the OLT and NAS to carry the new flow (in addition to all other existing multicast and unicast video traffic) and that there is enough video bandwidth for the subscriber to carry that flow. The solution needs to cope with multiple flows per premises and needs to allow bandwidth to be dynamically shared across multicast and unicast video traffic per subscriber, PON, and uplink (irrespective of whether unicast AC is performed by the NAS or by some off-path policy server). It should be noted that the shared bandwidth between multicast and unicast video is under operator control. That is, in addition to the shared bandwidth, some video bandwidth could be dedicated to Video on Demand, while other video bandwidth could be dedicated for multicast.
FTTP / B / Cアクセスのマルチキャストトラフィックのアドミッションをカバーするアドミッションコントロール（AC）メカニズムは、利用可能な帯域幅のオーバーサブスクライブとエンドユーザーエクスペリエンスへの悪影響を回避するために必要です。新しいマルチキャストフローに参加するユーザーリクエストを受け入れる前に、ANXとNASの組み合わせにより、アドミッションコントロールが実行され、PONとOLTとNASの間のアップリンクに、新しいフローを伝送するのに十分なビデオ帯域幅が残っていることを確認する必要があります。 （他のすべての既存のマルチキャストおよびユニキャストビデオトラフィックに加えて）、サブスクライバーがそのフローを伝送するのに十分なビデオ帯域幅があること。ソリューションは、施設ごとに複数のフローに対処する必要があり、帯域幅をマルチキャストおよびユニキャストビデオトラフィック全体で加入者、PON、およびアップリンクごとに動的に共有できるようにする必要があります（ユニキャストACがNASによって実行されるか、パス外ポリシーによって実行されるかに関係なく）サーバ）。マルチキャストビデオとユニキャストビデオの間の共有帯域幅は、オペレーターの制御下にあることに注意してください。つまり、共有帯域幅に加えて、一部のビデオ帯域幅はビデオオンデマンド専用になり、他のビデオ帯域幅はマルチキャスト専用になります。
The focus in this document is on multicast-allocated bandwidth including the shared unicast and multicast bandwidth. Thus, supporting admission control requires some form of synchronization between the entities performing multicast AC (e.g., the ANX and/or NAS), the entity performing unicast AC (e.g., the NAS or a policy server), and the entity actually enforcing the multicast replication (i.e., the NAS and the ANX). This synchronization can be achieved in a number of ways.
このドキュメントでは、共有ユニキャストおよびマルチキャスト帯域幅を含むマルチキャスト割り当て帯域幅に焦点を当てています。したがって、アドミッションコントロールをサポートするには、マルチキャストAC（ANXやNASなど）を実行するエンティティ、ユニキャストAC（NASまたはポリシーサーバーなど）を実行するエンティティ、およびマルチキャストを実際に実行するエンティティの間で何らかの同期が必要です。レプリケーション（つまり、NASとANX）。この同期は、いくつかの方法で実現できます。
One approach is for the NAS to perform bandwidth-based admission control on all multicast video traffic and unicast video traffic that requires using the shared bandwidth with multicast. Based on the outcome of admission control, NAS then controls the replication state on the ANX. The subscriber generates an IGMP join for the desired stream on its logical connection to the NAS. The NAS terminates the IGMP message and performs conditional access and bandwidth-based admission control on the IGMP request. The bandwidth admission control is performed against the following: 1. Available video bandwidth on the link to OLT
1つのアプローチは、NASがすべてのマルチキャストビデオトラフィックとマルチキャストで共有帯域幅を使用する必要があるユニキャストビデオトラフィックに対して帯域幅ベースのアドミッションコントロールを実行することです。アドミッションコントロールの結果に基づいて、NASはANXのレプリケーション状態を制御します。加入者は、NASへの論理接続で目的のストリームのIGMP加入を生成します。 NASはIGMPメッセージを終了し、IGMP要求に対して条件付きアクセスと帯域幅ベースのアドミッション制御を実行します。帯域幅アドミッション制御は、以下に対して実行されます。1. OLTへのリンクで利用可能なビデオ帯域幅
2. Available video bandwidth on the PON interface
2. PONインターフェースで利用可能なビデオ帯域幅
3. Available video bandwidth on the last mile (Access Port on the ONT/ONU)
3. ラストマイルで利用可能なビデオ帯域幅（ONT / ONUのアクセスポート）
The NAS can locally maintain and track video bandwidth it manages for all the three levels mentioned above. The NAS can maintain identifiers corresponding to the PON interface and the last mile (customer interface). It also maintains a channel map, associating every channel (or a group of channels sharing the same bandwidth requirement) with a data rate. For instance, in the case of 1:1 VLAN representation of the premises, the outer tag (S-VLAN) could be inserted by the ANX to correspond to the PON interface on the OLT, and the inner-tag could be inserted by the ANX to correspond to the access-line towards the customer. Bandwidth tracking and maintenance for the PON interface and the last mile could be done on these VLAN identifiers. In the case of N:1 representation, the single VLAN inserted by ANX could correspond to the PON interface on the OLT. The access loop is represented via Customer-Port-ID received in the "Agent Circuit ID" sub-option in DHCP messages.
NASは、上記の3つのレベルすべてに対して管理するビデオ帯域幅をローカルで維持および追跡できます。 NASは、PONインターフェイスとラストマイル（カスタマーインターフェイス）に対応する識別子を維持できます。また、チャネルマップを維持し、すべてのチャネル（または同じ帯域幅要件を共有するチャネルのグループ）をデータレートに関連付けます。たとえば、施設の1：1 VLAN表現の場合、外側のタグ（S-VLAN）はANXによって挿入され、OLT上のPONインターフェースに対応し、内側のタグはANXはお客様へのアクセスラインに対応します。 PONインターフェースとラストマイルの帯域幅の追跡とメンテナンスは、これらのVLAN識別子で実行できます。 N：1表現の場合、ANXによって挿入された単一のVLANは、OLT上のPONインターフェイスに対応する可能性があります。アクセスループは、DHCPメッセージの「Agent Circuit ID」サブオプションで受信したCustomer-Port-IDによって表されます。
The NAS can perform bandwidth accounting on received IGMP messages. The video bandwidth is also consumed by any unicast video being delivered to the CPE. NAS can perform video bandwidth accounting and control on both IGMP messages and on requests for unicast video streams when either all unicast admission control is done by the NAS or an external policy server makes a request to the NAS for using shared bandwidth with multicast as described later in the document.
NASは、受信したIGMPメッセージで帯域幅アカウンティングを実行できます。ビデオ帯域幅は、CPEに配信されるユニキャストビデオによっても消費されます。 NASは、すべてのユニキャストアドミッション制御がNASによって行われるか、外部ポリシーサーバーがNASに要求して、マルチキャストで共有帯域幅を使用するよう要求した場合、IGMPメッセージとユニキャストビデオストリームの要求の両方でビデオ帯域幅のアカウンティングと制御を実行できます。ドキュメント内。
This particular scenario assumes the NAS is aware of the bandwidth on the PON and can track the changes in available bandwidth on the PON under all conditions. On receiving an IGMP join message, NAS will perform bandwidth check on the subscriber bandwidth. If this passes and the stream is already being forwarded on the PON by the OLT (which also means that it is already forwarded by the NAS to the OLT), NAS will admit the join, update the available subscriber bandwidth, and transmit an ANCP message to the OLT and in turn to the ONT/ONU to start replication on the customer port. If the stream is not already being replicated to the PON by the OLT, the NAS will also check the available bandwidth on the PON, and if it is not already being replicated to the OLT, it will check the bandwidth on the link towards the OLT. If this passes, the available PON bandwidth and the bandwidth on the link towards the OLT are updated. The NAS adds the OLT as a leaf to the multicast tree for that stream. On receiving the message to start replication, the OLT will add the PON interface to its replication state if the stream is not already being forwarded on that PON. Also, the OLT will send an ANCP message to direct the ONT/ONU to add or update its replication state with the customer port for that channel. The interaction between ANX and NAS is shown in Figures 7 and 8. For unicast video streams, application-level signaling from the CPE typically triggers an application server to request bandwidth-based admission control from a policy server. The policy server can, in turn, interact with the NAS to request the bandwidth for the unicast video flow if it needs to use shared bandwidth with multicast. If the bandwidth is available, NAS will reserve the bandwidth; update the bandwidth pools for subscriber bandwidth, the PON bandwidth, and the bandwidth on the link towards the OLT; and send a response to the policy server, which is propagated back to the application server to start streaming. Otherwise, the request is rejected.
この特定のシナリオでは、NASがPONの帯域幅を認識しており、すべての条件下でPONの使用可能な帯域幅の変化を追跡できると想定しています。 IGMP加入メッセージを受信すると、NASは加入者の帯域幅の帯域幅チェックを実行します。これが成功し、ストリームがOLTによってPONですでに転送されている場合（つまり、NASによってOLTにすでに転送されている場合）、NASは参加を許可し、利用可能なサブスクライバー帯域幅を更新し、ANCPメッセージを送信しますOLT、次にONT / ONUに接続して、カスタマーポートでレプリケーションを開始します。ストリームがOLTによってPONにまだ複製されていない場合、NASはPONで利用可能な帯域幅もチェックし、OLTにまだ複製されていない場合は、OLTへのリンクの帯域幅をチェックします。これが成功すると、使用可能なPON帯域幅とOLTへのリンクの帯域幅が更新されます。 NASは、そのストリームのマルチキャストツリーにリーフとしてOLTを追加します。レプリケーションを開始するメッセージを受信すると、ストリームがまだそのPONで転送されていない場合、OLTはPONインターフェースをレプリケーション状態に追加します。また、OLTはANCPメッセージを送信して、ONT / ONUにそのチャネルのカスタマーポートでレプリケーション状態を追加または更新するように指示します。 ANXとNAS間の相互作用を図7および8に示します。ユニキャストビデオストリームの場合、CPEからのアプリケーションレベルのシグナリングは、通常、アプリケーションサーバーをトリガーして、ポリシーサーバーに帯域幅ベースのアドミッション制御を要求します。次に、ポリシーサーバーは、NASと対話して、マルチキャストで共有帯域幅を使用する必要がある場合、ユニキャストビデオフローの帯域幅を要求できます。帯域幅が利用可能な場合、NASは帯域幅を予約します。加入者帯域幅、PON帯域幅、およびOLTへのリンク上の帯域幅の帯域幅プールを更新します。そして、応答をポリシーサーバーに送信します。ポリシーサーバーは、ストリーミングを開始するためにアプリケーションサーバーに伝達されます。それ以外の場合、要求は拒否されます。
+----+
+---<PON>---------- |ONT |------ HGW
+ +----+
+ +----+
+ +--------- |ONT |------ HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |----- HGW
| | | | |
| | |<------------------>| ONU |------HGW
| +----+ ANCP | | +---+
| | | |-----|HGW|
| | +-----+ +---+
| 1.IGMP join (S/*,G) | |
|<---------------------------------------------------------- |
2.| | | |
+=======================+ | |
[Access Control & ] | |
[Subscriber B/W ] | |
[PON B/W & OLT link B/W ] | |
[based Admission Control] | |
+=======================+ | |
| | | |
|-------------------> | | |
3.ANCP Replication-Start| | |
(<S/*,G> or Multicast | | |
|MAC,Customer-Port-ID)| --------------------> | |
| |4.ANCP Replication-Start |
| (<S/*,G> or Multicast MAC,Customer-Port-ID)
|-------------------> | | |
|5.Multicast Flow(S,G)| | |
|on Multicast VLAN |---------------------> | |
| |6.Multicast Flow (S,G) | |
| |forwarded on | |
| |Unidirectional | |
| |<Multicast GEM-PORT> | |
| |on the PON by OLT |------------->|
7.Multicast Flow
forwarded on |
Customer-Port by|
|ONT/OLT. |
| |
Figure 7: Interactions for NAS-Based Multicast Admission Control (No IGMP Processing on ANX and NAS Maintains Available Video Bandwidth for PON) upon Channel Join
図7：チャネル加入時のNASベースのマルチキャストアドミッション制御の相互作用（ANXでIGMP処理なし、NASはPONで利用可能なビデオ帯域幅を維持）
+----+
+---<PON>---------- |ONT |----- HGW
+ +----+
+ +----+
+ +--------- |ONT |----- HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |---- HGW
| | | | |
| | |<------------------>| ONU |-----HGW
| +----+ ANCP | | +---+
| | | |-----|HGW|
| | +-----+ +---+
| | | |
| IGMP leave (S/*,G) | |
|<-----------------------------------------------------------|
| | | |
+====================+ | | |
[Admission Control ] | | |
[<Resource Released> ] | | |
+====================+ | | |
| | | |
| | | |
| | | |
|-------------------> | | |
ANCP Replication-Stop | | |
(<S/*,G> or Multicast MAC,Customer-Port-ID) | |
| | | |
| |---------------------> | |
| | ANCP Replication-Stop | |
(<S/*,G> or Multicast MAC,Customer-Port-ID)
Figure 8: Interactions for NAS-Based Multicast Admission Control (No IGMP Processing on ANX and NAS Maintains Available Video Bandwidth for PON) upon Channel Leave
図8：チャネル離脱時のNASベースのマルチキャストアドミッション制御の相互作用（ANXではIGMP処理なし、NASはPONで利用可能なビデオ帯域幅を維持）
An alternate approach is required if the NAS is not aware of the bandwidth on the PON. In this case, the OLT does the PON bandwidth management and requests NAS to perform bandwidth admission control on subscriber bandwidth and the bandwidth on the link to the OLT. Following are operations of various elements:
NASがPONの帯域幅を認識していない場合は、別の方法が必要です。この場合、OLTはPON帯域幅管理を行い、NASに加入者帯域幅とOLTへのリンク上の帯域幅の帯域幅アドミッション制御を実行するように要求します。以下は、さまざまな要素の操作です。
ANX operation:
ANXオペレーション：
- ONT/ONU can snoop IGMP messages. If conditional access is configured and the channel is in the black list (or it is not on the white list), ONT will drop the IGMP join. If the channel passes the conditional access check, the ONT will forward the IGMP join and will send a bandwidth admission control request to the OLT. If the multicast stream is already being received on the PON, the ONT/ONU does not forward the stream to the Access Port where IGMP is received until it has received a positive admission control response from the OLT.
-ONT / ONUはIGMPメッセージをスヌープできます。条件付きアクセスが構成されていて、チャネルがブラックリストにある（またはホワイトリストにない）場合、ONTはIGMP参加をドロップします。チャネルが条件付きアクセスチェックに合格すると、ONTはIGMP加入を転送し、帯域幅アドミッション制御要求をOLTに送信します。マルチキャストストリームがすでにPONで受信されている場合、ONT / ONUは、OLTから肯定的なアドミッション制御応答を受信するまで、IGMPが受信されるアクセスポートにストリームを転送しません。
- OLT can snoop IGMP messages. It also receives a bandwidth admission control request from the ONT/ONU for the requested channel. It can be programmed with a channel bandwidth map. If the multicast channel is already being streamed on the PON or the channel bandwidth is less than the available multicast bandwidth on the PON, the OLT forwards the IGMP request to the NAS and keeps track of the subscriber (identified by Customer-Port-ID) as a receiver. If the channel is not already being streamed on the PON but the PON has sufficient bandwidth for that channel, the OLT reduces the PON multicast video bandwidth by the channel bandwidth and may optionally add the PON to the multicast tree without activation for that channel. This is biased towards a forward expectation that the request will be accepted at the NAS. The OLT forwards the IGMP join to the NAS. It also sends a bandwidth admission request to the NAS identifying the channel and the premises for which the request is made. It sets a timer for the subscriber multicast entry within which it expects to receive a request from the NAS that relates to this request. If the available PON bandwidth is less than the bandwidth of the requested channel, the OLT sends an admission response (with a reject) to the ONT/ONU and does not forward the IGMP join to the NAS.
- OLTはIGMPメッセージをスヌープできます。また、要求されたチャネルのONT / ONUから帯域幅アドミッション制御要求を受信します。チャネル帯域幅マップを使用してプログラムできます。マルチキャストチャネルがすでにPONでストリーミングされている場合、またはチャネル帯域幅がPONで利用可能なマルチキャスト帯域幅よりも小さい場合、OLTはIGMP要求をNASに転送し、加入者（Customer-Port-IDで識別）を追跡します受信機として。チャネルがまだPONでストリーミングされていないが、PONがそのチャネルに対して十分な帯域幅を持っている場合、OLTはPONマルチキャストビデオ帯域幅をチャネル帯域幅で削減し、オプションで、そのチャネルをアクティブ化せずにPONをマルチキャストツリーに追加できます。これは、要求がNASで受け入れられるという前方の期待に偏っています。 OLTはIGMP加入をNASに転送します。また、帯域幅許可要求をNASに送信して、要求が行われたチャネルと施設を識別します。これは、この要求に関連するNASからの要求を受信することを期待している加入者マルチキャストエントリのタイマーを設定します。使用可能なPON帯域幅が要求されたチャネルの帯域幅よりも小さい場合、OLTはアドミッション応答（拒否あり）をONT / ONUに送信し、IGMP加入をNASに転送しません。
NAS operation:
米国の事業：
The NAS receives the IGMP join from the subscriber on the subscriber connection. When NAS receives the admission control request from ANX (also signifying the bandwidth on the PON is available), it performs admission control against the subscriber's available multicast bandwidth. If this check passes, and the NAS is already transmitting that channel to the OLT, the request is accepted. If the check passes and the NAS is not transmitting the channel to the OLT yet, it performs admission control against the available multicast video bandwidth (this includes the dedicated multicast bandwidth and the shared bandwidth between multicast and Video on Demand) on the link(s) to the OLT. If the check passes, the request is accepted, the available video bandwidth for the subscriber and downlink to the OLT are reduced by the channel bandwidth, and the NAS sends an ANCP admission control response (indicating accept) to the OLT, requesting the addition of the subscriber to the multicast tree for that channel. The OLT activates the corresponding multicast entry if not active and maintains state of the subscriber in the list of receivers for that channel. The OLT also sends an ANCP request to the ONT/ONU to enable reception of the multicast channel and forwarding to the subscriber Access Port. Otherwise, if the request is rejected, the NAS will send an admission reject to the OLT, which, in turn, removes the subscriber as a receiver for that channel (if it was added) and credits back the channel bandwidth to the PON video bandwidth if there is no other receiver on the PON for that channel. The interactions between ANX and NAS are shown in Figures 9 and 10.
NASは、加入者接続で加入者からIGMP加入を受信します。 NASがANXからアドミッション制御要求を受信すると（PONの帯域幅が利用可能であることも示す）、NASは加入者の利用可能なマルチキャスト帯域幅に対してアドミッション制御を実行します。このチェックに合格し、NASがすでにそのチャネルをOLTに送信している場合、要求は受け入れられます。チェックに合格し、NASがまだチャネルをOLTに送信していない場合、NASはリンクで利用可能なマルチキャストビデオ帯域幅（専用マルチキャスト帯域幅とマルチキャストとビデオオンデマンド間の共有帯域幅を含む）に対してアドミッションコントロールを実行します。 ）OLTに。チェックに合格すると、要求が受け入れられ、加入者およびOLTへのダウンリンクに使用可能なビデオ帯域幅がチャネル帯域幅によって削減され、NASがANCPアドミッションコントロール応答（受け入れを示す）をOLTに送信し、追加を要求します。そのチャネルのマルチキャストツリーの加入者。 OLTは、アクティブでない場合に対応するマルチキャストエントリをアクティブにし、そのチャネルのレシーバーのリストにあるサブスクライバーの状態を維持します。また、OLTはANCP要求をONT / ONUに送信して、マルチキャストチャネルの受信と加入者のアクセスポートへの転送を可能にします。それ以外の場合、要求が拒否されると、NASはアドミッション拒否をOLTに送信し、OLTは加入者をそのチャネルの受信者として削除し（追加されている場合）、チャネル帯域幅をPONビデオ帯域幅にクレジットします。そのチャネルのPONに他の受信機がない場合。 ANXとNAS間の相互作用を図9および10に示します。
If the OLT does not receive a response from the NAS within a set timer, the OLT removes the subscriber from the potential list of receivers for the indicated channel. It also returns the allocated bandwidth to the available PON bandwidth if there are no other receivers. In this case, the NAS may send a response to the OLT with no matching entry as the entry has been deleted. The OLT must perform admission control against the available PON bandwidth and may accept the request and send an ANCP request to the ONT/ONU to activate the corresponding multicast entry as described earlier. If it does not accept the request, it will respond back to the NAS with a reject. The NAS shall credit back the channel bandwidth to the subscriber. It shall also stop sending the channel to the OLT if that subscriber was the last leaf on the multicast tree towards the OLT.
OLTが設定されたタイマー内でNASから応答を受信しない場合、OLTは指定されたチャネルの受信者の潜在的なリストから加入者を削除します。また、他に受信機がない場合は、割り当てられた帯域幅を使用可能なPON帯域幅に戻します。この場合、エントリが削除されているため、NASは一致するエントリがない状態でOLTに応答を送信する場合があります。 OLTは、利用可能なPON帯域幅に対してアドミッション制御を実行する必要があり、前述のように、要求を受け入れ、ANCP要求をONT / ONUに送信して、対応するマルチキャストエントリをアクティブにします。要求を受け入れない場合、NASに拒否で応答します。 NASは、チャネル帯域幅を加入者にクレジットバックします。また、その加入者がOLTへのマルチキャストツリーの最後のリーフであった場合、OLTへのチャネルの送信も停止します。
On processing an IGMP leave, the OLT will send an ANCP request to NAS to release resources. NAS will release the subscriber bandwidth. If this leave causes the stream to be no longer required by the OLT, the NAS will update its replication state and release the bandwidth on the NAS to OLT link.
IGMP脱退の処理時に、OLTはANCP要求をNASに送信してリソースを解放します。 NASは加入者の帯域幅を解放します。このままにすると、OLTでストリームが不要になった場合、NASはレプリケーション状態を更新し、NASからOLTへのリンクの帯域幅を解放します。
If the subscriber makes a request for a unicast video stream (i.e., Video on Demand), the request results in appropriate application-level signaling, which typically results in an application server requesting a policy server for bandwidth-based admission control for the VoD stream. After authorizing the request, the policy server can send a request to the NAS for the required bandwidth if it needs to use bandwidth that is shared with multicast. This request may be based on a protocol outside of the scope of this document. The NAS checks if the available video bandwidth (accounting for both multicast and unicast) per subscriber and for the link to the OLT is sufficient for the request. If it is, it temporarily reserves the bandwidth and sends an ANCP admission request to the OLT for the subscriber, indicating the desired VoD bandwidth. If the OLT has sufficient bandwidth on the corresponding PON, it reserves that bandwidth and returns an accept response to the NAS. If not, it returns a reject to the NAS. If the NAS receives an accept, it returns an accept to the policy server, which, in turn, returns an accept to the application server, and the video stream is streamed to the subscriber. This interaction is shown in Figure 11. If the NAS does not accept the request from the policy server, it returns a reject. If the NAS receives a reject from the OLT, it returns the allocated bandwidth to the subscriber and the downlink to the OLT.
サブスクライバーがユニキャストビデオストリーム（つまり、ビデオオンデマンド）を要求すると、その要求によって適切なアプリケーションレベルのシグナリングが行われ、通常、アプリケーションサーバーがVoDストリームの帯域幅ベースのアドミッション制御をポリシーサーバーに要求します。 。リクエストを承認した後、ポリシーサーバーは、マルチキャストと共有される帯域幅を使用する必要がある場合、NASに必要な帯域幅のリクエストを送信できます。この要求は、このドキュメントの範囲外のプロトコルに基づいている場合があります。 NASは、サブスクライバーごとおよびOLTへのリンクに対して利用可能なビデオ帯域幅（マルチキャストとユニキャストの両方を考慮）が要求に対して十分かどうかを確認します。そうである場合は、一時的に帯域幅を予約し、加入者のOCPにANCP許可要求を送信して、必要なVoD帯域幅を示します。 OLTが対応するPONで十分な帯域幅を持っている場合、その帯域幅を予約し、NASに受け入れ応答を返します。そうでない場合は、NASに拒否を返します。 NASが受け入れを受信すると、ポリシーサーバーに受け入れを返し、ポリシーサーバーは受け入れをアプリケーションサーバーに返し、ビデオストリームがサブスクライバにストリーミングされます。この相互作用を図11に示します。NASがポリシーサーバーからの要求を受け入れない場合は、拒否を返します。 NASがOLTから拒否を受信すると、割り当てられた帯域幅を加入者に返し、ダウンリンクをOLTに返します。
It should be noted that similar functionality to that described in this section and depicted in Figures 9, 10, and 11 will be required when OMCI is enabled between the OLT and ONT/ONU in the ANCP+OMCI ANX control model. In the latter case, the OLT will act as an ANCP-OMCI gateway.
ANCP + OMCI ANX制御モデルでOLTとONT / ONUの間でOMCIが有効になっている場合、このセクションで説明し、図9、10、および11に示したものと同様の機能が必要になることに注意してください。後者の場合、OLTはANCP-OMCIゲートウェイとして機能します。
+----+
+-------- |ONT |-------- HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->|OLT | + +-----+
+----+ ANCP | | ANCP +--------- | ONU |------ HGW
| +----+<------------------>+-----+-------HGW
| | | |
|1.IGMP join(S/*,G) +=============+ +=============+ |
|<------------------[IGMP Snooping]---------[IGMP snooping]--|
| +=============+ +=============+ |
| |2.Admission-Request | |
| |(Flow,Customer-Port-ID) | |
| |<---------------------- | |
| 3.+===============+ | |
| [ Access Ctrl ] | |
| [ & PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|4.Admission-Request | | |
| <Flow, | | |
| Customer-Port-ID> | | |
|<--------------------| | |
5.| | | |
+=================+ | | |
[Subscriber B/W ] | | |
[& OLT link B/W ] | | |
[Admission Ctrl ] | | |
+=================+PASS | | |
|6.Admission-Reply-Pass | |
|<Flow,Customer-Port-ID> | |
|-------------------->| | |
| 7.+========================+ | |
| [Update Replication State] | |
| +========================+ | |
| | 8.Admission-Reply-Pass | |
| |(<Flow,Cust-Port-ID> | |
| |----------------------> | |
| | 9.+============+ |
| | [Update Repl.] |
| | [ State ] |
| | +============+ |
Figure 9: Interaction between NAS & ANX for Multicast Bandwidth Admission Control in the All-ANCP ANX Control Model upon Success
図9：成功時の全ANCP ANX制御モデルにおけるマルチキャスト帯域幅アドミッション制御のためのNASとANX間の相互作用
+----+
+--------- |ONT |------ HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->|OLT | + +-----+
+----+ ANCP | | ANCP +----------| ONU |----- HGW
| +----+<----------------->+-----+------HGW
| | | |
|1.IGMP join(S/*,G) +=============+ +=============+ |
|<------------------[IGMP Snooping]--------[IGMP snooping]-- |
| +=============+ +=============+ |
| |2.Admission-Request | |
| |(Flow,Customer-Port-ID) | |
| |<---------------------- | |
| 2.+===============+ | |
| [ Access Ctrl ] | |
| [ & PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|3.Admission-Request | | |
| <Flow,Customer-Port-ID> | |
|<--------------------| | |
4.| | | |
+==================+ | | |
[Subscriber B/W ] | | |
[& OLT link B/W ] | | |
[Admission Ctrl ] | | |
+==================+FAIL | |
| | | |
|5.Admission-Reply-Fail | |
|<Flow,Cust-Port-ID> | | |
|-------------------->| | |
| 6.+==================+ | |
| [Release PON B/W ] | |
| [Remove Repl.State ] | |
| +==================+ | |
| | 7.Admission-Reply-Fail | |
| |<Flow,Cust-Port-ID> | |
| |----------------------> | |
| | 8.+============+ |
| | [Remove Repl.] |
| | [ State ] |
| | +============+ |
Figure 10: Interaction between NAS and ANX for Multicast Bandwidth Admission Control in the All-ANCP ANX Control Model upon Failure
図10：障害時の全ANCP ANX制御モデルでのマルチキャスト帯域幅アドミッション制御のためのNASとANX間の相互作用
+------------+ 1. VoD Request
| App. Server|<-----------------------------------------------
| Server |
+------------+
| 2. Admission-Request (VoD-Flow)
+-------+
|Policy |
|Server |
+-------+
| +
|<-|---3. Admission-Request
| |
+ | 8. Admission-Reply
+----+ + +----+ +-----+
|NAS |---------------|OLT |------<PON>-------|ONT |---HGW--CPE
| |<------------->| | +-----+ |
+----+ ANCP +----+ | |
| | | |
4.| | | |
+=================+ | | |
[Subscriber B/W ] | | |
[& OLT link B/W ] | | |
[Admission Ctrl ] | | |
+=================+PASS | | |
| | | |
| 5.Admission-Request | | |
|(Bandwidth,PON-Port-ID) | |
|-------------------> | | |
| | | |
| 6.+===============+ | |
| [ PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|7.Admission-Reply | | |
| <PON-Port-ID> | | |
|<------------------- | | |
| | | |
Figure 11: Interactions for VoD Bandwidth Admission Control in the All-ANCP ANX Control Model
図11：All-ANCP ANX制御モデルでのVoD帯域幅アドミッション制御の相互作用
A third possible approach is where the ANX is assumed to have full knowledge to make an autonomous decision on admitting or rejecting a multicast and a unicast join. With respect to the interaction between ONT/ONU and OLT, the procedure is similar to the first approach (i.e., NAS-controlled replication). However, when the OLT receives an IGMP request from a subscriber, it performs admission control against that subscriber multicast video bandwidth (dedicated and shared with Video on Demand), the PON, and uplink to the NAS. It should be noted in this case that if there are multiple NAS-OLT links, either the link on which the multicast stream must be sent is pre-determined, needs to be selected by the OLT based on downstream bandwidth from NAS to OLT and the selection is communicated to the NAS, or the OLT has to be ready to receive the stream on any link. If the check passes, the OLT updates the available video bandwidth per PON and subscriber. The OLT adds the subscriber to the list of receivers and the PON to the multicast tree if it is not already on it. It also sends an ANCP request to the ONT/ONU to add the subscriber Access Port to that channel multicast tree and sends an ANCP message to the NAS informing it of the subscriber and link available video bandwidth and the channel the subscriber joined. The NAS, upon receiving the ANCP information message, updates the necessary information, including the OLT to the multicast tree if it is not already on it. It should be noted in this case that the ANCP message from the OLT to the NAS is being used to add the OLT to a multicast tree as opposed to an IGMP message. The IGMP message can also be sent by the OLT with the OLT acting as an IGMP proxy at the expense of added messages. In this option, the OLT acts as the network IGMP router for the subscriber.
3番目の可能なアプローチは、ANXがマルチキャストとユニキャスト参加の許可または拒否について自律的な決定を行うための完全な知識を持っていると想定される場合です。 ONT / ONUとOLT間の相互作用に関しては、手順は最初のアプローチ（つまり、NAS制御のレプリケーション）と同様です。ただし、OLTはサブスクライバーからIGMP要求を受信すると、そのサブスクライバーマルチキャストビデオ帯域幅（ビデオオンデマンドで専用および共有）、PON、およびNASへのアップリンクに対してアドミッションコントロールを実行します。この場合、NAS-OLTリンクが複数ある場合、マルチキャストストリームを送信する必要のあるリンクが事前に決定されているか、NASからOLTへのダウンストリーム帯域幅に基づいてOLTが選択する必要があることに注意してください。選択がNASに伝達されるか、OLTが任意のリンクでストリームを受信する準備ができている必要があります。チェックに合格した場合、OLTはPONおよび加入者ごとに使用可能なビデオ帯域幅を更新します。 OLTは、サブスクライバーをレシーバーのリストに追加し、PONがまだ存在しない場合はマルチキャストツリーに追加します。また、加入者アクセスポートをそのチャネルマルチキャストツリーに追加するためにANCP要求をONT / ONUに送信し、加入者を通知するANCPメッセージをNASに送信して、利用可能なビデオ帯域幅と加入者が参加したチャネルをリンクします。 NASは、ANCP情報メッセージを受信すると、OLTを含む必要な情報をマルチキャストツリーに更新します（OLTがまだない場合）。この場合、OLTからNASへのANCPメッセージは、IGMPメッセージではなく、OLTをマルチキャストツリーに追加するために使用されていることに注意してください。 IGMPメッセージは、追加のメッセージを犠牲にしてOLTがIGMPプロキシとして機能するOLTによって送信することもできます。このオプションでは、OLTはサブスクライバーのネットワークIGMPルーターとして機能します。
For unicast video streams, the policy server receiving an admission request from an application server, as described before, may query the OLT for admission control as it has all information. If the OLT has sufficient bandwidth for the stream, it reserves that bandwidth for the subscriber, the PON, and OLT uplink to the NAS and returns an accept to the policy server. It also updates the NAS (via an ANCP message) of the subscriber's available video bandwidth. If the OLT rejects the policy server request, it will return a reject to the policy server.
ユニキャストビデオストリームの場合、前述のように、アプリケーションサーバーからアドミッション要求を受信するポリシーサーバーは、OLTがすべての情報を持っているため、アドミッション制御についてOLTにクエリを実行できます。 OLTがストリームに対して十分な帯域幅を持っている場合、加入者、PON、およびNASへのOLTアップリンク用にその帯域幅を予約し、ポリシーサーバーに受け入れを返します。また、加入者が利用できるビデオ帯域幅のNASを（ANCPメッセージを介して）更新します。 OLTがポリシーサーバー要求を拒否すると、拒否がポリシーサーバーに返されます。
It should be noted that if the policy server adjacency is with the NAS, the policy server may make the admission request to the NAS. The NAS then sends an ANCP admission request to the OLT on behalf of the policy server. The NAS returns an accept or reject to the policy server if it gets a reject or accept, respectively, from the OLT.
ポリシーサーバーの隣接がNASと隣接している場合、ポリシーサーバーはNASへの許可要求を行う可能性があることに注意してください。次に、NASは、ポリシーサーバーに代わってANCP許可要求をOLTに送信します。 NASは、OLTから拒否または受け入れをそれぞれ受け取った場合、ポリシーサーバーに受け入れまたは拒否を返します。
It may be desirable to perform accurate time- or volume-based accounting per user or per access loop. If the ANX is performing the traffic replication process, it knows when replication of a multicast flow to a particular Access Port or user starts and stops. Multicast accounting can be addressed in two ways:
ユーザーごとまたはアクセスループごとに、正確な時間ベースまたはボリュームベースのアカウンティングを実行することが望ましい場合があります。 ANXがトラフィックレプリケーションプロセスを実行している場合、特定のアクセスポートまたはユーザーへのマルチキャストフローのレプリケーションがいつ開始および停止するかがわかります。マルチキャストアカウンティングは、次の2つの方法で対処できます。
- ANX keeps track of when replication starts or stops and reports this information to the NAS for further processing. In this case, ANCP can be used to send the information from the ANX to the NAS. This can be done with the Information Report message. The NAS can then generate the appropriate time and/or volume accounting information per access loop and per multicast flow to be sent to the accounting system. The ANCP requirements to support this approach are specified in [RFC5851]. If the replication function is distributed between the OLT and ONT/ONU, a query from the NAS will result in OLT generating a query to the ONT/ONU.
- ANXはレプリケーションがいつ開始または停止したかを追跡し、この情報をNASに報告してさらに処理します。この場合、ANCPを使用して、ANXからNASに情報を送信できます。これは、情報レポートメッセージで実行できます。次に、NASは、アクセスループごと、およびマルチキャストフローごとに、アカウンティングシステムに送信される適切な時間またはボリュームアカウンティング情報を生成できます。このアプローチをサポートするためのANCP要件は、[RFC5851]で指定されています。レプリケーション機能がOLTとONT / ONUの間に分散されている場合、NASからのクエリにより、OLTはONT / ONUへのクエリを生成します。
- ANX keeps track of when replication starts or stops and generates the time- and/or volume-based accounting information per access loop and per multicast flow, before sending it to a central accounting system for logging. Since ANX communicates with this accounting system directly, the approach does not require the use of ANCP. It is therefore beyond the scope of this document. It may also be desirable for the NAS to have the capability to asynchronously query the ANX to obtain an instantaneous status report related to multicast flows currently replicated by the ANX. Such a reporting functionality could be useful for troubleshooting and monitoring purposes. If the replication function in the ANX is distributed between the OLT and the ONT/ONU, then for some of the information required by the NAS (such as the list of Access Ports on which a flow is being forwarded or list of flows being forwarded on an Access Port), a query to the OLT from the NAS will result in a query from the OLT to the ONT/ONU. The OLT responds back to the NAS when it receives the response from the ONT/ONU. Also, if the list of PONs on which replication is happening for a multicast channel or the list of channels being replicated on a PON is what is desired, the OLT can return this information.
- ANXは、レプリケーションがいつ開始または停止するかを追跡し、アクセスループごと、およびマルチキャストフローごとに時間ベースまたはボリュームベースのアカウンティング情報を生成してから、ロギングのために中央のアカウンティングシステムに送信します。 ANXはこの会計システムと直接通信するため、このアプローチではANCPを使用する必要はありません。したがって、このドキュメントの範囲を超えています。また、NASがANXに非同期でクエリを実行して、ANXによって現在複製されているマルチキャストフローに関連する瞬時のステータスレポートを取得する機能を備えていることが望ましい場合もあります。このようなレポート機能は、トラブルシューティングや監視の目的で役立ちます。 ANXのレプリケーション機能がOLTとONT / ONUの間に分散されている場合、NASが必要とする情報の一部（フローが転送されているアクセスポートのリストや転送されているフローのリストなど）アクセスポート）、NASからOLTへのクエリは、OLTからONT / ONUへのクエリになります。 OLTは、ONT / ONUからの応答を受信すると、NASに応答します。また、マルチキャストチャネルで複製が発生しているPONのリスト、またはPONで複製されているチャネルのリストが必要な場合、OLTはこの情報を返すことができます。
In an end-to-end Ethernet aggregation network, end-to-end Ethernet Operations, Administration, and Maintenance (OAM), as specified in IEEE 802.1ag [802.1ag] and ITU-T Recommendation Y.1730/1731 [Y.1731], can provide access loop connectivity testing and fault isolation. However, most HGWs do not yet support these standard Ethernet OAM procedures. Also, in a mixed Ethernet and ATM access network (e.g., Ethernet-based aggregation upstream from the OLT and BPON downstream), interworking functions for end-to-end OAM are not yet standardized or widely available. Until such mechanisms become standardized and widely available, the Access Node Control Mechanism between NAS and ANX can be used to provide a simple mechanism to test connectivity of an access loop from the NAS.
エンドツーエンドのイーサネットアグリゲーションネットワークでは、IEEE 802.1ag [802.1ag]およびITU-T勧告Y.1730 / 1731 [Y. 1731]は、アクセスループ接続テストと障害分離を提供できます。ただし、ほとんどのHGWは、これらの標準イーサネットOAM手順をまだサポートしていません。また、イーサネットとATMの混合アクセスネットワーク（OLTからアップストリームのイーサネットベースの集約やダウンストリームのBPONなど）では、エンドツーエンドOAMのインターワーキング機能はまだ標準化されていないか、広く利用されていません。このようなメカニズムが標準化されて広く利用できるようになるまで、NASとANX間のアクセスノード制御メカニズムを使用して、NASからのアクセスループの接続をテストする簡単なメカニズムを提供できます。
Triggered by a local management interface, the NAS can use the Access Node Control Mechanism (Control Request message) to initiate an access loop test between an Access Node and a HGW or ONT/ONU. On reception of the ANCP message, the OLT can trigger native OAM procedures defined for BPON in [G.983.1] and for GPON in [G.984.1]. The Access Node can send the result of the test to the NAS via a Control Response message.
ローカル管理インターフェースによってトリガーされるNASは、アクセスノード制御メカニズム（制御要求メッセージ）を使用して、アクセスノードとHGWまたはONT / ONUの間のアクセスループテストを開始できます。 ANCPメッセージを受信すると、OLTは[G.983.1]のBPONと[G.984.1]のGPONに対して定義されたネイティブOAMプロシージャをトリガーできます。アクセスノードは、制御応答メッセージを介してテストの結果をNASに送信できます。
In order to avoid congestion in the network, manage and utilize the network resources better, and ensure subscriber fairness, NAS performs hierarchical shaping and scheduling of the traffic by modeling different congestion points in the network (such as the last mile, Access Node uplink, and the access-facing port).
ネットワークの輻輳を回避し、ネットワークリソースをより適切に管理および利用し、加入者の公平性を確保するために、NASはネットワークのさまざまな輻輳ポイント（ラストマイル、アクセスノードアップリンクなど）をモデル化することにより、トラフィックの階層型シェーピングとスケジューリングを実行します。およびアクセス用ポート）。
Such mechanisms require that the NAS gains knowledge about the topology of the access network, the various links being used, and their respective rates. Some of the information required is somewhat dynamic in nature (e.g., DSL line rate if the last mile is xDSL based, such as in the case of "PON-fed DSLAMs" for FTTC/FTTB scenarios) and hence cannot come from a provisioning and/or inventory management Operations Support System (OSS). Some of the information varies less frequently (e.g., capacity of the OLT uplink) but nevertheless needs to be kept strictly in sync between the actual capacity of the uplink and the image the NAS has of it.
このようなメカニズムでは、NASがアクセスネットワークのトポロジ、使用されているさまざまなリンク、およびそれぞれの速度についての知識を得る必要があります。必要な情報の一部は本質的にやや動的であり（たとえば、FTTC / FTTBシナリオの「PON給電DSLAM」の場合のように、ラストマイルがxDSLベースの場合のDSLラインレート）、したがって、プロビジョニングおよび/または在庫管理運用サポートシステム（OSS）。一部の情報はそれほど頻繁には変化しません（たとえば、OLTアップリンクの容量）が、それでも、アップリンクの実際の容量とNASが持っているイメージとの間で厳密に同期を保つ必要があります。
OSSs are rarely able to enforce the consistency of such data in a reliable and scalable manner, notably across organizational boundaries under certain deployment scenarios. The Access Topology Discovery function allows the NAS to perform these advanced functions without having to depend on an error-prone and possibly complex integration with an OSS.
OSSは、信頼性が高くスケーラブルな方法で、特に特定の展開シナリオの下で組織の境界を越えて、そのようなデータの一貫性を強制することはめったにありません。 Access Topology Discovery機能により、NASは、エラーが発生しやすく、OSSとの複雑な統合に依存する必要なく、これらの高度な機能を実行できます。
The rate of the access loop can be communicated via ANCP (Information Report message) from the ONT/ONU to the OLT in the All-ANCP ANX control model or via OMCI in the ANCP+OMCI ANX control model, and then from OLT to the NAS via ANCP. Additionally, during the time the DSL NT is active, data rate changes can occur due to environmental conditions (the DSL access loop can get "out of sync" and can retrain to a lower value, or the DSL access loop could use Seamless Rate Adaptation to make the actual data rate fluctuate while the line is active). In this case, ANX sends an additional Information Report to the NAS each time the access loop attributes change above a threshold value. Existing DSL procedures are not applicable in this case because an adapted message flow and additional TLVs are needed.
アクセスループのレートは、ANCP（情報レポートメッセージ）を介してONT / ONUからAll-ANCP ANX制御モデルのOLTに、またはANCP + OMCI ANX制御モデルのOMCIを介して、OLTからANCP経由のNAS。さらに、DSL NTがアクティブである間、環境条件が原因でデータレートの変化が発生する可能性があります（DSLアクセスループが「非同期」になり、低い値に再トレーニングするか、DSLアクセスループがシームレスレート適応を使用する可能性があります。ラインがアクティブな間に実際のデータレートを変動させるため）。この場合、アクセスループ属性がしきい値を超えるたびに、ANXは追加の情報レポートをNASに送信します。この場合、適応されたメッセージフローと追加のTLVが必要になるため、既存のDSL手順は適用できません。
+--------+
| Policy |
| Server |
+--------+ +---+ +---+
| +-----------|ONT|---|HGW|
| | +---+ +---+
| +--------------- |-----------------+
+----+ | +----+ | +-----+ | +---+
|NAS |------------ | | | | | |-|-|HGW|
| |<----------> | | | | |ONT/ | | +---+
+----+ ANCP | |OLT |------<PON>--------|ONU | |
| | | | | | | +---+
| | | |<----------------->| |---|HGW|
| | +----+ OMCI +-----+ | +---+
| +----------------------------------+
| | Access Node |
| | |
| |------GPON Ranging------|
| Port Status Message| ONT Port UP |
|<------------------ |<-----------------------|
|Port Configuration GPON Line/Service Profile|
|------------------> |<---------------------->|
| ONT/ONI Port UP| |
|<------------------ | |
| | |
| ANCP | OMCI |
<-------------------><----------------------->|
PPP, DHCP, IP
<------------------------------------------------------>
Figure 12: Message Flow for the Use Case of Topology Discovery for the ANCP+OMCI Control Model
図12：ANCP + OMCI制御モデルのトポロジー検出のユースケースのメッセージフロー
Figure 12 depicts a message flow for topology discovery when using the ANCP+OMCI control model. Basically, when an ONT/ONU gets connected to a PON, the OLT detects a new device and a GPON Ranging process starts. During this process, the ONT/ONU becomes authorized by the OLT and identified by ONT/ONU ID, PON Port ID, and max Bandwidth. This port status is reported via ANCP to the NAS and then potentially the policy server via another mechanism that is out of scope of this document. In a second step, after the GPON service profile is assigned from OLT to ONT/ONU, the OLT reports the final status to NAS with information about the service profile and other information such as the ONT/ONU port rate to the subscriber, for instance.
図12は、ANCP + OMCI制御モデルを使用する場合のトポロジー検出のメッセージフローを示しています。基本的に、ONT / ONUがPONに接続されると、OLTが新しいデバイスを検出し、GPONレンジングプロセスが開始されます。このプロセス中に、ONT / ONUはOLTによって承認され、ONT / ONU ID、PONポートID、および最大帯域幅によって識別されます。このポートステータスはANCPを介してNASに報告され、その後、このドキュメントの範囲外の別のメカニズムを介してポリシーサーバーに報告される可能性があります。 2番目のステップでは、GPONサービスプロファイルがOLTからONT / ONUに割り当てられた後、OLTは、サービスプロファイルに関する情報とONT / ONUポートレートなどの他の情報を含む最終ステータスを加入者にNASに報告します。 。
Topology Discovery provides Access Port Identification to the NAS when sending an Access Port Discovery message. This informs NAS identification of a PON port on an Access Node. Based on Access Port Identification and on customer identification, service-related parameters could be configured on an OLT and an ONU/ONT.
トポロジディスカバリは、アクセスポートディスカバリメッセージを送信するときに、NASにアクセスポート識別を提供します。これは、アクセスノード上のPONポートの識別をNASに通知します。アクセスポートIDと顧客IDに基づいて、OLTおよびONU / ONTでサービス関連のパラメータを設定できます。
Service-related parameters could be sent to OLT via ANCP before or after an ONU/ONT is up. Sending of ANCP loop configuration messages from NAS can be triggered by a management system or by customer identification and authentication after Topology Discovery. It may be used for first-time configuration (zero touch) or for updating/upgrading customer's profile like C-VLAN ID, S-VLAN ID, and service bandwidth.
ONU / ONTの起動前または起動後に、サービス関連のパラメータをANCP経由でOLTに送信できます。 NASからのANCPループ構成メッセージの送信は、管理システムまたはトポロジー検出後の顧客の識別と認証によってトリガーできます。初回構成（ゼロタッチ）、またはC-VLAN ID、S-VLAN ID、サービス帯域幅などの顧客のプロファイルの更新/アップグレードに使用できます。
Parameters of the User-Network Interface (UNI), which is the subscriber interface to HGW/CPE of ONU/ONT, can also be configured via ANCP. When the ONU/ONT supports ANCP, parameters of the UNI on ONU/ONT are sent to the ONU/ONT via ANCP. If the ONU/ONT does not support ANCP but only OMCI, parameters have to be sent from the NAS to the OLT via ANCP first. Then, the OLT translates such configuration into OMCI and sends it to the ONU/ONT.
ONU / ONTのHGW / CPEへのサブスクライバーインターフェイスであるユーザーネットワークインターフェイス（UNI）のパラメーターも、ANCPを介して構成できます。 ONU / ONTがANCPをサポートしている場合、ONU / ONTのUNIのパラメータはANCPを介してONU / ONTに送信されます。 ONU / ONTがANCPをサポートせずOMCIのみをサポートする場合、パラメーターは最初にANCPを介してNASからOLTに送信される必要があります。次に、OLTはそのような構成をOMCIに変換し、ONU / ONTに送信します。
[RFC5713] lists the ANCP-related security threats that could be encountered on the Access Node and the NAS. It develops a threat model for ANCP security and lists the security functions that are required at the ANCP level.
[RFC5713]は、アクセスノードとNASで発生する可能性のあるANCP関連のセキュリティの脅威を示しています。 ANCPセキュリティの脅威モデルを開発し、ANCPレベルで必要なセキュリティ機能をリストします。
With multicast handling as described in this document, ANCP protocol activity between the ANX and the NAS is triggered by join/leave requests coming from the end-user equipment. This could potentially be used for a denial-of-service attack against the ANX and/or the NAS.
このドキュメントで説明されているマルチキャスト処理では、ANXとNASの間のANCPプロトコルアクティビティは、エンドユーザー機器からの参加/脱退要求によってトリガーされます。これは、ANXやNASに対するサービス拒否攻撃に使用される可能性があります。
To mitigate this risk, the NAS and ANX may implement control plane protection mechanisms such as limiting the number of multicast flows a given user can simultaneously join or limiting the maximum rate of join/leave from a given user.
このリスクを軽減するために、NASおよびANXは、特定のユーザーが同時に参加できるマルチキャストフローの数を制限したり、特定のユーザーからの参加/脱退の最大レートを制限したりするなど、コントロールプレーン保護メカニズムを実装する場合があります。
Protection against invalid or unsubscribed flows can be deployed via provisioning black lists as close to the subscriber as possible (e.g., in the ONT).
無効またはサブスクライブされていないフローに対する保護は、サブスクライバーのできるだけ近くに（たとえば、ONTで）プロビジョニングブラックリストを使用して展開できます。
User activity logging for accounting or tracking purposes could raise privacy concerns if not appropriately protected. To protect such information, logging/accounting information can be exchanged with the corresponding server over a secure channel, and the information can be stored securely with policy-driven controlled access.
アカウンティングまたは追跡を目的としたユーザーアクティビティロギングは、適切に保護されていないとプライバシーの問題を引き起こす可能性があります。そのような情報を保護するために、ロギング/アカウンティング情報を対応するサーバーと安全なチャネルを介して交換し、情報をポリシー主導の制御されたアクセスで安全に保存できます。
As it currently stands, both ANCP framework [RFC5851] and protocol [RFC6320] are defined in the context of DSL access. Due to inherent differences between PON and DSL access technologies, ANCP needs a few extensions for supporting the use cases outlined in this document for PON-based access. These specific differences and extensions are outlined below.
現在のところ、ANCPフレームワーク[RFC5851]とプロトコル[RFC6320]の両方がDSLアクセスのコンテキストで定義されています。 PONアクセステクノロジーとDSLアクセステクノロジーには固有の違いがあるため、PONPアクセスのこのドキュメントで概説されているユースケースをサポートするには、ANCPにいくつかの拡張機能が必要です。これらの特定の違いと拡張機能の概要を以下に示します。
- In PON, the access-node functionality is split between OLT and ONT. Therefore, ANCP interaction between NAS and AN translates to transactions between NAS and OLT and between OLT and ONT. The processing of ANCP messages (e.g., for multicast replication control) on the OLT can trigger generation of ANCP messages from OLT to ONT. Similarly, ANCP messages from ONT to the OLT can trigger ANCP exchange between the OLT and the NAS (e.g., admission request messages). This is illustrated in the generic message flows in Figures 5 and 6 of Section 5. In the case of DSL, the ANCP exchange is contained between two network elements (NAS and the DSLAM).
- PONでは、アクセスノード機能はOLTとONTの間で分割されます。したがって、NASとANの間のANCP相互作用は、NASとOLTの間、およびOLTとONTの間のトランザクションに変換されます。 OLTでのANCPメッセージの処理（マルチキャストレプリケーション制御など）により、OLTからONTへのANCPメッセージの生成をトリガーできます。同様に、ONTからOLTへのANCPメッセージは、OLTとNASの間のANCP交換をトリガーすることができます（たとえば、アドミッション要求メッセージ）。これは、セクション5の図5および6の一般的なメッセージフローに示されています。DSLの場合、ANCP交換は2つのネットワーク要素（NASとDSLAM）の間に含まれます。
- The PON connection to the ONT is a shared medium between multiple ONTs on the same PON. In the case of DSL, the local loop is point-to-point. In the case of a DSL access network, the access-facing port on the NAS (i.e., port to the network between NAS and the DSLAM) and the access-facing ports on the DSLAM (i.e., customer's local loop) are the two bandwidth constraint points that need to be considered for performing bandwidth-based admission control for multicast video and VoD delivered to the customer. In the case of PON access, in addition to the bandwidth constraint on the NAS to OLT facing ports and the subscriber-allocated bandwidth for video services, the bandwidth available on the PON for video is an additional constraint that needs to be considered for bandwidth-based admission control. If the bandwidth control is centralized in the NAS (as described in the first approach in Section 6.2), then the NAS needs to support additional logic to consider available PON bandwidth before admitting a multicast request or a VoD request by the user. Accordingly, ANCP needs to identify the customer Access Port and the PON on which the customer ONT is. If the PON bandwidth control is performed on the OLT (as defined in the second approach in Section 6.2), then additional ANCP request and response
- ONTへのPON接続は、同じPON上の複数のONT間で共有される媒体です。 DSLの場合、ローカルループはポイントツーポイントです。 DSLアクセスネットワークの場合、NASのアクセスに面したポート（つまり、NASとDSLAMの間のネットワークへのポート）とDSLAMのアクセスに面したポート（つまり、お客様のローカルループ）は、2つの帯域幅です。顧客に配信されるマルチキャストビデオとVoDの帯域幅ベースのアドミッションコントロールを実行するために考慮する必要がある制約ポイント。 PONアクセスの場合、NASからOLTに面するポートの帯域幅制約およびビデオサービスの加入者が割り当てた帯域幅に加えて、ビデオのPONで利用可能な帯域幅は、帯域幅について考慮する必要がある追加の制約です-ベースのアドミッションコントロール。帯域幅制御がNASに集中している場合（セクション6.2の最初のアプローチで説明）、NASは、ユーザーがマルチキャスト要求またはVoD要求を許可する前に、利用可能なPON帯域幅を考慮する追加のロジックをサポートする必要があります。したがって、ANCPは、カスタマーアクセスポートとカスタマーONTが存在するPONを識別する必要があります。 OLTでPON帯域幅制御が実行される場合（セクション6.2の2番目のアプローチで定義）、追加のANCP要求と応答
messages are required for NAS to query the OLT to determine available PON bandwidth when a request to admit a VoD flow is received on the NAS (as shown in Figure 9 in Section 6.2) or for the OLT to inform the NAS what stream bandwidth is sent to the subscriber for the NAS to take appropriate action (e.g., bandwidth adjustment for various types of traffic).
NASでVoDフローを許可する要求が受信されたときにNASがOLTにクエリして利用可能なPON帯域幅を決定する（セクション6.2の図9に示すように）、またはOLTがNASに送信するストリーム帯域幅を通知するためのメッセージが必要ですNASがサブスクライバに適切なアクション（たとえば、さまざまなタイプのトラフィックの帯域幅調整）を行う
- In PON, the multicast replication can potentially be performed on three different network elements: (1) on the NAS, (2) on the OLT for replication to multiple PON ports, and (3) on the ONT/ONU for replication to multiple customer ports. In the case of DSL, the replication can potentially be performed on NAS and/or the DSLAM. Section 6.2 defines options for multicast replication in the case of PON. In the first option, the multicast replication is done on the AN but is controlled from NAS via ANCP (based on the reception of per-customer IGMP messages on the NAS). In this option, the NAS needs to supply the OLT the set of PON-customer-IDs (as defined in Section 2) to which the multicast stream needs to be replicated. The PON-customer-ID identifies the OLT and the PON ports on the OLT as well as the ONT and the Access Ports on the ONT where the multicast stream needs to be replicated. Upon receiving the request to update its multicast replication state, the OLT must update its replication state with the indicated PON ports but may also need to interact with the ONT via ANCP to update the multicast replication state on the ONT with the set of Access Ports (as indicated by the NAS). In the case of DSL, the DSLAM only needs to update its own replication state based on the set of Access Ports indicated by the NAS.
- PONでは、マルチキャストレプリケーションは3つの異なるネットワーク要素で実行できる可能性があります。（1）NASで、（2）複数のPONポートへのレプリケーション用のOLTで、（3）複数の顧客へのレプリケーション用のONT / ONUでポート。 DSLの場合、NASやDSLAM、あるいはその両方でレプリケーションが実行される可能性があります。セクション6.2では、PONの場合のマルチキャスト複製のオプションを定義します。最初のオプションでは、マルチキャストレプリケーションはANで行われますが、ANCPを介してNASから制御されます（NASでの顧客ごとのIGMPメッセージの受信に基づく）。このオプションでは、NASは、OLTにマルチキャストストリームを複製する必要があるPONカスタマーIDのセット（セクション2で定義）を提供する必要があります。 PON-customer-IDは、OLTのOLTポートとPONポート、およびマルチキャストストリームを複製する必要があるONTのONTとアクセスポートを識別します。マルチキャストレプリケーション状態を更新する要求を受信すると、OLTは指定されたPONポートでレプリケーション状態を更新する必要がありますが、ANCPを介してONTと対話して、アクセスポートのセットでONTのマルチキャストレプリケーション状態を更新する必要がある場合もあります（ NASが示すとおり）。 DSLの場合、DSLAMは、NASによって示されたアクセスポートのセットに基づいて、自身の複製状態を更新するだけで済みます。
- For reporting purposes, ANCP must enable the NAS to query the OLT for channels replicated on a PON or a list of PONs and to specific Access Ports. The latter should trigger the OLT to query the ONT for a list of channels being replicated on all Access Ports or on specific Access Ports to the premises. In a DSL case, it is sufficient to query the DSLAM for a list of channels being replicated on an Access Port or a list of Access Ports.
- レポートのために、ANCPは、NASがOLTにPONまたはPONのリストおよび特定のアクセスポートに複製されたチャネルを照会できるようにする必要があります。後者は、OLTをトリガーして、すべてのアクセスポートまたは構内への特定のアクセスポートで複製されるチャネルのリストをONTに照会する必要があります。 DSLの場合、アクセスポートで複製されているチャネルのリストまたはアクセスポートのリストをDSLAMに照会するだけで十分です。
ONT Management and Control Interface (OMCI) [OMCI] is specified for in-band ONT management via the OLT. This includes configuring parameters on the ONT/ONU. Such configuration can include adding an Access Port on the ONT to a multicast tree and the ONT to a multicast tree. Thus, OMCI can be a potential replacement for ANCP between the OLT and ONT/ONU, albeit it may not be a suitable protocol for dynamic transactions as required for the multicast application.
ONT管理および制御インターフェース（OMCI）[OMCI]は、OLTを介したインバンドONT管理用に指定されています。これには、ONT / ONUでのパラメータの設定が含まれます。このような構成には、ONT上のアクセスポートをマルチキャストツリーに追加し、ONTをマルチキャストツリーに追加することが含まれます。したがって、OMCIは、マルチキャストアプリケーションに必要な動的トランザクションに適したプロトコルではないかもしれませんが、OLTとONT / ONUの間のANCPの潜在的な置き換えになる可能性があります。
If OMCI is selected to be enabled between the OLT and ONT/ONU to carry the same information elements that would be carried over ANCP, the OLT must perform the necessary translation between ANCP and OMCI for replication control messages received via ANCP. OMCI is an already available control channel, while ANCP requires a TCP/IP stack on the ONT/ONU that can be used by an ANCP client, and accordingly, it requires that the ONT/ONU be IP addressable for ANCP. Most ONTs/ONUs today have a TCP/IP stack used by certain applications (e.g., VoIP and IGMP snooping). ANCP may use the same IP address that is often assigned for VoIP or, depending on the implementation, may require a different address. Sharing the same IP address between VoIP and ANCP may have other network implications on how the VoIP agent is addressed and on traffic routing. For instance, the VoIP traffic to/from the ONT is often encapsulated in a VLAN-tagged Ethernet frame and switched at Layer 2 through the OLT to the NAS where it is routed. The VoIP agent in this case looks like another subscriber to the NAS. On the other hand, the ANCP session between the ONT and OLT is terminated at the OLT. Thus, the OLT must be able to receive/send IP traffic to/from the OLT, which will not work using this setting. Using a separate IP address for the purpose of ONT/ONU management or ANCP specifically may often be required when supporting ANCP. These considerations may favor OMCI in certain environments. However, OMCI will not allow some of the transactions required in approach 2, where the ONT/ONU sends unsolicited requests to the OLT rather than being queried or configured by OLT requests.
ANCPを介して伝送されるのと同じ情報要素を伝送するためにOLTとONT / ONUの間でOMCIを有効にするように選択した場合、OLPはANCPを介して受信した複製制御メッセージに対してANCPとOMCI間の必要な変換を実行する必要があります。 OMCIはすでに使用可能な制御チャネルですが、ANCPは、ANCPクライアントが使用できるONT / ONU上のTCP / IPスタックを必要とします。したがって、ONT / ONUがANCPに対してIPアドレス指定可能である必要があります。今日のほとんどのONT / ONUには、特定のアプリケーション（VoIPやIGMPスヌーピングなど）で使用されるTCP / IPスタックがあります。 ANCPは、VoIPに割り当てられることが多い同じIPアドレスを使用することも、実装によっては別のアドレスが必要になることもあります。 VoIPとANCP間で同じIPアドレスを共有すると、VoIPエージェントのアドレス指定方法やトラフィックルーティングに関して、他のネットワークに影響を与える可能性があります。たとえば、ONTとの間のVoIPトラフィックは、VLANタグ付きイーサネットフレームにカプセル化され、レイヤー2でOLTを介してルーティングされ、NASにルーティングされます。この場合のVoIPエージェントは、NASの別のサブスクライバーのように見えます。一方、ONTとOLTの間のANCPセッションは、OLTで終了します。したがって、OLTはOLTとの間でIPトラフィックを送受信できる必要があります。これは、この設定では機能しません。 ANCPをサポートする場合、ONT / ONU管理またはANCPの目的で別のIPアドレスを使用することが特に必要になる場合があります。これらの考慮事項は、特定の環境でOMCIを支持する場合があります。ただし、OMCIはアプローチ2で必要なトランザクションの一部を許可しません。この場合、ONT / ONUは、OLT要求によって照会または設定されるのではなく、非送信請求要求をOLTに送信します。
The authors thank Rajesh Yadav and Francois Le Faucheur for their valuable comments and discussions.
著者は、Rajesh YadavとFrancois Le Faucheurの貴重なコメントと議論に感謝します。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516] Mamakos、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D.、R。Wheeler、「A Method for Transmitting PPP over Ethernet（PPPoE）」、RFC 2516、2月1999
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684] Grossman、D。およびJ. Heinanen、「ATMアダプテーションレイヤ5上のマルチプロトコルカプセル化」、RFC 2684、1999年9月。
[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月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「Internet Group Management Protocol（IGMP）/ Multicast Listener Discovery（MLD）-Based Multicast Forwarding（ "IGMP / MLD Proxying"） "、RFC 4605、2006年8月。
[802.1ag] IEEE 802.1ag, "Connectivity Fault Management", December 2007.
[802.1ag] IEEE 802.1ag、「Connectivity Fault Management」、2007年12月。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[RFC2881] Mitton、D。およびM. Beadles、「ネットワークアクセスサーバー要件次世代（NASREQNG）NASモデル」、RFC 2881、2000年7月。
[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。
[G.983.1] ITU-T G.983.1, "Broadband optical access systems based on Passive Optical Networks (PON)", January 2005.
[G.983.1] ITU-T G.983.1、「受動光ネットワーク（PON）に基づくブロードバンド光アクセスシステム」、2005年1月。
[G.984.1] ITU-T G.984.1, "Gigabit-capable Passive Optical Networks (GPON): General characteristics", March 2008.
[G.984.1] ITU-T G.984.1、「Gigabit-capable Passive Optical Networks（GPON）：General features」、2008年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL Aggregation", DSL Forum TR-101, May 2006.
[TR-101] Cohen、A。およびE. Shrum、「Migration to Ethernet-Based DSL Aggregation」、DSLフォーラムTR-101、2006年5月。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5713] Moustafa、H.、Tschofenig、H。、およびS. De Cnodder、「セキュリティ脅威とアクセスノードコントロールプロトコル（ANCP）のセキュリティ要件」、RFC 5713、2010年1月。
[OMCI] ITU-T G.984.4, "Gigabit-capable passive optical networks (G-PON): ONT management and control interface specification", February 2008.
[OMCI] ITU-T G.984.4、「ギガビット対応パッシブ光ネットワーク（G-PON）：ONT管理および制御インターフェース仕様」、2008年2月。
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, Ed., "Protocol for Access Node Control Mechanism in Broadband Networks", RFC 6320, October 2011.
[RFC6320] Wadhwa、S.、Moisand、J.、Haag、T.、Voigt、N.、and T. Taylor、Ed。、 "Protocol for Access Node Control Mechanism in Broadband Networks"、RFC 6320、October 2011。
[G.987.3] ITU-T G.987.3, "10-Gigabit-capable passive optical networks(XG-PON): Transmission convergence (TC) layer specification", October 2010.
[G.987.3] ITU-T G.987.3、「10ギガビット対応パッシブ光ネットワーク（XG-PON）：伝送収束（TC）層の仕様」、2010年10月。
[Y.1731] ITU-T Y.1731, "OAM functions and mechanisms for Ethernet based networks", May 2006.
[Y.1731] ITU-T Y.1731、「イーサネットベースのネットワークのOAM機能とメカニズム」、2006年5月。
Authors' Addresses
著者のアドレス
Nabil Bitar (editor) Verizon 60 Sylvan Road Waltham, MA 02451 EMail: nabil.n.bitar@verizon.com
Nabil Bitar（編集者）Verizon 60 Sylvan Road Waltham、MA 02451 Eメール：nabil.n.bitar@verizon.com
Sanjay Wadhwa (editor) Alcatel-Lucent 701 East Middlefield Road Mountain View, CA, 94043 EMail: sanjay.wadhwa@alcatel-lucent.com
Sanjay Wadhwa（編集者）アルカテルルーセント701 East Middlefield Road Mountain View、CA、94043 Eメール：sanjay.wadhwa@alcatel-lucent.com
Thomas Haag Deutsche Telekom EMail: HaagT@telekom.de
Thomas Haag Deutsche Telekomメール：HaagT@telekom.de
Hongyu Li Huawei Technologies EMail: hongyu.lihongyu@huawei.com
hongとL IH UAはテクノロジーメールです：Hongyu.Li Hongyu@Huawei.com