RFC 8084 - Network Transport Circuit Breakers 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8084
タイトル : RFC 8084 - ネットワーク転送遮断器
翻訳編集 : 自動生成

[要約] RFC 8084は、ネットワークトランスポート回路ブレーカーに関するガイドラインであり、ネットワークの過負荷や障害を回避するためのメカニズムを提供します。目的は、ネットワークの信頼性とパフォーマンスを向上させることです。

Internet Engineering Task Force (IETF)                      G. Fairhurst
Request for Comments: 8084                        University of Aberdeen
BCP: 208                                                      March 2017
Category: Best Current Practice
ISSN: 2070-1721

Network Transport Circuit Breakers

ネットワーク転送遮断器

Abstract

概要

This document explains what is meant by the term "network transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion-controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.

このドキュメントでは、「ネットワーク転送回路ブレーカー」という用語の意味について説明します。輻輳制御されていないトラフィックを使用する場合のネットワークトンネルおよびアプリケーション用のサーキットブレーカー（CB）の必要性について説明し、CBが必要な場所と不要な場所について説明します。また、CBを構築するための要件と、インターネット内でCBを使用した場合に予想される結果を定義します。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 7841のセクション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/rfc8084.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8084で入手できます。

著作権表示

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 ....................................................2
      1.1. Types of CBs ...............................................5
   2. Terminology .....................................................6
   3. Design of a CB (What makes a good CB?) ..........................6
      3.1. Functional Components ......................................6
      3.2. Other Network Topologies ...................................9
           3.2.1. Use with a Multicast Control/Routing Protocol ......10
           3.2.2. Use with Control Protocols Supporting
                  Pre-provisioned Capacity ...........................11
           3.2.3. Unidirectional CBs over Controlled Paths ...........11
   4. Requirements for a Network Transport CB ........................12
   5. Examples of CBs ................................................15
      5.1. A Fast-Trip CB ............................................15
           5.1.1. A Fast-Trip CB for RTP .............................16
      5.2. A Slow-Trip CB ............................................16
      5.3. A Managed CB ..............................................17
           5.3.1. A Managed CB for SAToP Pseudowires .................17
           5.3.2. A Managed CB for Pseudowires (PWs) .................18
   6. Examples in Which CBs May Not Be Needed ........................19
      6.1. CBs over Pre-provisioned Capacity .........................19
      6.2. CBs with Tunnels Carrying Congestion-Controlled Traffic ...19
      6.3. CBs with Unidirectional Traffic and No Control Path .......20
   7. Security Considerations ........................................20
   8. References .....................................................22
      8.1. Normative References ......................................22
      8.2. Informative References ....................................22
   Acknowledgments ...................................................24
   Author's Address ..................................................24

1. Introduction

1. はじめに

The term "Circuit Breaker" originates in electricity supply, and has nothing to do with network circuits or virtual circuits. In electricity supply, a Circuit Breaker (CB) is intended as a protection mechanism of last resort. Under normal circumstances, a CB ought not to be triggered; it is designed to protect the supply network and attached equipment when there is overload. People do not expect an electrical CB (or fuse) in their home to be triggered, except when there is a wiring fault or a problem with an electrical appliance.

「回路ブレーカー」という用語は電力供給に由来し、ネットワーク回路や仮想回路とは関係ありません。電力供給では、サーキットブレーカー（CB）は最後の手段の保護メカニズムとして意図されています。通常の状況下では、CBはトリガーされるべきではありません。過負荷時に供給ネットワークと接続機器を保護するように設計されています。人々は、配線障害や電気製品に問題がある場合を除いて、自宅の電気CB（またはヒューズ）がトリガーされることを期待していません。

In networking, the CB principle can be used as a protection mechanism of last resort to avoid persistent excessive congestion impacting other flows that share network capacity. Persistent congestion was a feature of the early Internet of the 1980s. This resulted in excess traffic starving other connections from access to the Internet. It was countered by the requirement to use congestion control (CC) in the Transmission Control Protocol (TCP) [Jacobson88]. These mechanisms operate in Internet hosts to cause TCP connections to "back off" during congestion. The addition of a congestion control to TCP (currently documented in [RFC5681]) ensured the stability of the Internet, because it was able to detect congestion and promptly react. This was effective in an Internet where most TCP flows were long lived (ensuring that they could detect and respond to congestion before the flows terminated). Although TCP was, by far, the dominant traffic, this is no longer the always the case, and non-congestion-controlled traffic, including many applications using the User Datagram Protocol (UDP), can form a significant proportion of the total traffic traversing a link. To avoid persistent excessive congestion, the current Internet therefore requires consideration of the way that non-congestion-controlled traffic is forwarded.

ネットワーキングでは、CBの原則は、ネットワーク容量を共有する他のフローに影響を与える永続的な過度の輻輳を回避するための最後の手段の保護メカニズムとして使用できます。持続的な輻輳は、1980年代の初期のインターネットの特徴でした。これにより、インターネットへのアクセスから他の接続を奪う過剰なトラフィックが発生しました。これは、伝送制御プロトコル（TCP）[Jacobson88]で輻輳制御（CC）を使用する必要があるという要求によって対抗されました。これらのメカニズムはインターネットホストで動作し、輻輳時にTCP接続を「バックオフ」します。 TCP（現在[RFC5681]に文書化されている）に輻輳制御を追加すると、輻輳を検出して迅速に対応できるため、インターネットの安定性が確保されました。これは、ほとんどのTCPフローが長持ちするインターネットで効果的でした（フローが終了する前に輻輳を検出して対応できることを保証します）。 TCPは圧倒的に主要なトラフィックでしたが、これはもはや常に当てはまるわけではなく、ユーザーデータグラムプロトコル（UDP）を使用する多くのアプリケーションを含む非輻輳制御トラフィックは、全トラフィックトラバースのかなりの部分を占める可能性がありますリンク。したがって、現在のインターネットでは、継続的な過度の輻輳を回避するために、輻輳が制御されていないトラフィックを転送する方法を考慮する必要があります。

A network transport CB is an automatic mechanism that is used to continuously monitor a flow or aggregate set of flows. The mechanism seeks to detect when the flow(s) experience persistent excessive congestion. When this is detected, a CB terminates (or significantly reduces the rate of) the flow(s). This is a safety measure to prevent starvation of network resources denying other flows from access to the Internet. Such measures are essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance. Avoiding persistent excessive congestion is important to reduce the potential for "Congestion Collapse" [RFC2914].

ネットワークトランスポートCBは、フローまたはフローの集約セットを継続的に監視するために使用される自動メカニズムです。このメカニズムは、フローが永続的な過度の輻輳を経験するときを検出しようとします。これが検出されると、CBはフローを終了します（またはフローのレートを大幅に低下させます）。これは、他のフローによるインターネットへのアクセスを拒否するネットワークリソースの枯渇を防ぐための安全対策です。このような対策は、異種混合のインターネットや事前に予測するのが難しいトラフィックにとって不可欠です。持続的な過度の輻輳を回避することは、「輻輳の崩壊」[RFC2914]の可能性を減らすために重要です。

There are important differences between a transport CB and a congestion control method. Congestion control (as implemented in TCP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP)) operates on a timescale on the order of a packet Round-Trip Time (RTT): the time from sender to destination and return. Congestion at a network link can also be detected using Explicit Congestion Notification (ECN) [RFC3168], which allows the network to signal congestion by marking ECN-capable packets with a Congestion Experienced (CE) mark. Both loss and reception of CE-marked packets are treated as congestion events. Congestion control methods are able to react to a congestion event by continuously adapting to reduce their transmission rate. The goal is usually to limit the transmission rate to a maximum rate that reflects a fair use of the available capacity across a network path. These methods typically operate on individual traffic flows (e.g., a 5-tuple that includes the IP addresses, protocol, and ports).

トランスポートCBと輻輳制御方法の間には重要な違いがあります。輻輳制御（TCP、ストリーム制御伝送プロトコル（SCTP）、およびデータグラム輻輳制御プロトコル（DCCP）で実装されている）は、パケットの順序のタイムスケールで動作します。ラウンドトリップ時間（RTT）：送信者から宛先までの時間。戻ります。ネットワークリンクでの輻輳は、明示的輻輳通知（ECN）[RFC3168]を使用して検出することもできます。これにより、ネットワークは、ECN対応パケットにCongestion Experienced（CE）マークを付けることで、輻輳を通知できます。 CEマークの付いたパケットの損失と受信の両方が、輻輳イベントとして扱われます。輻輳制御方法は、伝送速度を下げるように継続的に適応することで、輻輳イベントに対応できます。通常、目標は、伝送速度を、ネットワークパス全体で利用可能な容量の公平な使用を反映する最大速度に制限することです。これらの方法は通常、個々のトラフィックフロー（たとえば、IPアドレス、プロトコル、ポートを含む5タプル）で動作します。

In contrast, CBs are recommended for non-congestion-controlled Internet flows and for traffic aggregates, e.g., traffic sent using a network tunnel. They operate on timescales much longer than the packet RTT, and trigger under situations of abnormal (excessive) congestion. People have been implementing what this document characterizes as CBs on an ad hoc basis to protect Internet traffic. This document therefore provides guidance on how to deploy and use these mechanisms. Later sections provide examples of cases where CBs may or may not be desirable.

対照的に、CBは、輻輳が制御されていないインターネットフローや、ネットワークトンネルを使用して送信されるトラフィックなどのトラフィック集約に推奨されます。これらは、パケットRTTよりもはるかに長いタイムスケールで動作し、異常な（過度の）輻輳の状況でトリガーされます。人々は、インターネットトラフィックを保護するために、このドキュメントの特徴であるCBをアドホックベースで実装しています。したがって、このドキュメントでは、これらのメカニズムを展開して使用する方法に関するガイダンスを提供します。後のセクションでは、CBが望ましい場合と望ましくない場合の例を示します。

A CB needs to measure (meter) some portion of the traffic to determine if the network is experiencing congestion and needs to be designed to trigger robustly when there is persistent excessive congestion.

CBは、ネットワークの輻輳が発生しているかどうかを判別するためにトラフィックの一部を測定（メーター）する必要があり、持続的な過度の輻輳が発生したときに堅牢にトリガーするように設計する必要があります。

A CB trigger will often utilize a series of successive sample measurements metered at an ingress point and an egress point (either of which could be a transport endpoint). The trigger needs to operate on a timescale much longer than the path RTT (e.g., seconds to possibly many tens of seconds). This longer period is needed to provide sufficient time for transport congestion control or applications to adjust their rate following congestion, and for the network load to stabilize after any adjustment. Congestion events can be common when a congestion-controlled transport is used over a network link operating near capacity. Each event results in reduction in the rate of the transport flow experiencing congestion. The longer period seeks to ensure that a CB is not accidentally triggered following a single (or even successive) congestion event(s).

CBトリガーは、多くの場合、入口ポイントと出口ポイント（どちらもトランスポートエンドポイントである可能性があります）で測定される一連の連続するサンプル測定を利用します。トリガーは、パスRTTよりもはるかに長いタイムスケールで動作する必要があります（例：数秒から数十秒）。このより長い期間は、トランスポートの輻輳制御またはアプリケーションが輻輳後にレートを調整し、調整後にネットワーク負荷が安定するのに十分な時間を提供するために必要です。輻輳イベントは、輻輳によって制御されたトランスポートが、容量の近くで動作するネットワークリンクを介して使用される場合によく発生します。各イベントにより、輻輳が発生しているトランスポートフローのレートが低下します。より長い期間は、単一の（または連続した）輻輳イベントの後にCBが誤ってトリガーされないようにすることを目的としています。

Once triggered, the CB needs to provide a control function (called the "reaction"). This removes traffic from the network, either by disabling the flow or by significantly reducing the level of traffic. This reaction provides the required protection to prevent persistent excessive congestion being experienced by other flows that share the congested part of the network path.

トリガーされると、CBは制御機能（「反応」と呼ばれる）を提供する必要があります。これにより、フローを無効にするか、トラフィックのレベルを大幅に下げることにより、ネットワークからトラフィックが削除されます。この反応は、ネットワークパスの輻輳している部分を共有する他のフローによって永続的な過度の輻輳が発生するのを防ぐために必要な保護を提供します。

Section 4 defines requirements for building a CB.

セクション4では、CBを構築するための要件を定義します。

The operational conditions that cause a CB to trigger ought to be regarded as abnormal. Examples of situations that could trigger a CB include:

CBをトリガーする操作条件は異常と見なされるべきです。 CBをトリガーする可能性のある状況の例は次のとおりです。

o anomalous traffic that exceeds the provisioned capacity (or whose traffic characteristics exceed the threshold configured for the CB);

o プロビジョニングされた容量を超える異常なトラフィック（またはトラフィック特性がCBに構成されたしきい値を超える）

o traffic generated by an application at a time when the provisioned network capacity is being utilized for other purposes;

o プロビジョニングされたネットワーク容量が他の目的で使用されているときにアプリケーションによって生成されるトラフィック。

o routing changes that cause additional traffic to start using the path monitored by the CB;

o CBが監視するパスを使用して追加のトラフィックを開始させるルーティング変更。

o misconfiguration of a service/network device where the capacity available is insufficient to support the current traffic aggregate;

o 利用可能な容量が現在のトラフィック集約をサポートするには不十分であるサービス/ネットワークデバイスの設定ミス。

o misconfiguration of an admission controller or traffic policer that allows more traffic than expected across the path monitored by the CB.

o アドミッションコントローラまたはトラフィックポリサーの設定ミスにより、CBが監視するパス全体で予想よりも多くのトラフィックが許可されます。

Other mechanisms could also be available to network operators to detect excessive congestion (e.g., an observation of excessive utilization for a port on a network device). Utilizing such information, operational mechanisms could react to reduce network load over a shorter timescale than those of a network transport CB. The role of the CB over such paths remains as a method of last resort. Because it acts over a longer timescale, the CB ought to be triggered only when other reactions did not succeed in reducing persistent excessive congestion.

ネットワークオペレーターが他のメカニズムを使用して、過度の輻輳を検出することもできます（たとえば、ネットワークデバイスのポートの過剰な使用状況の観察）。このような情報を利用して、運用メカニズムは、ネットワークトランスポートCBよりも短いタイムスケールでネットワーク負荷を軽減するように対応できます。そのような経路におけるCBの役割は、最後の手段として残っています。それはより長いタイムスケールで作用するため、CBは、他の反応が持続的な過度の輻輳の低減に成功しなかった場合にのみトリガーされるべきです。

In many cases, the reason for triggering a CB will not be evident to the source of the traffic (user, application, endpoint, etc.). A CB can be used to limit traffic from applications that are unable, or choose not, to use congestion control or in cases in which the congestion control properties of the traffic cannot be relied upon (e.g., traffic carried over a network tunnel). In such circumstances, it is all but impossible for the CB to signal back to the impacted applications. In some cases, applications could therefore have difficulty in determining that a CB has been triggered and where in the network this happened.

多くの場合、CBをトリガーする理由は、トラフィックのソース（ユーザー、アプリケーション、エンドポイントなど）には明らかではありません。 CBを使用して、輻輳制御を使用できない、または使用しないことを選択したアプリケーションからのトラフィックを制限したり、トラフィックの輻輳制御プロパティに依存できない場合（ネットワークトンネルで伝送されるトラフィックなど）を使用したりできます。このような状況では、CBが影響を受けるアプリケーションに信号を返すことはほとんど不可能です。したがって、場合によっては、CBがトリガーされたこと、およびネットワーク内のどこでこれが発生したかをアプリケーションが判断するのが難しい場合があります。

Application developers are therefore advised, where possible, to deploy appropriate congestion control mechanisms. An application that uses congestion control will be aware of congestion events in the network. This allows it to regulate the network load under congestion, and it is expected to avoid triggering a network CB. For applications that can generate elastic traffic, this will often be a preferred solution.

したがって、アプリケーション開発者は、可能であれば、適切な輻輳制御メカニズムを配備するようにアドバイスされます。輻輳制御を使用するアプリケーションは、ネットワーク内の輻輳イベントを認識します。これにより、輻輳時にネットワーク負荷を調整でき、ネットワークCBのトリガーを回避することが期待されます。弾性トラフィックを生成できるアプリケーションの場合、これは多くの場合、推奨されるソリューションです。

1.1. Types of CBs

1.1. CBのタイプ

There are various forms of network transport CBs. These are differentiated mainly on the timescale over which they are triggered, but also in the intended protection they offer:

ネットワーク転送CBにはさまざまな形式があります。これらは、主にトリガーされるタイムスケールで区別されますが、提供される意図された保護でも異なります。

o Fast-Trip CBs: The relatively short timescale used by this form of CB is intended to provide protection for network traffic from a single flow or related group of flows.

o Fast-Trip CB：この形式のCBで使用される比較的短いタイムスケールは、単一のフローまたは関連するフローのグループからのネットワークトラフィックを保護することを目的としています。

o Slow-Trip CBs: This CB utilizes a longer timescale and is designed to protect network traffic from congestion by traffic aggregates.

o スロートリップCB：このCBは、より長いタイムスケールを使用し、ネットワークトラフィックをトラフィック集約による輻輳から保護するように設計されています。

o Managed CBs: Utilize the operations and management functions that might be present in a managed service to implement a CB.

o マネージドCB：マネージドサービスに存在する可能性のある操作と管理機能を利用して、CBを実装します。

Examples of each type of CB are provided in Section 4.

各タイプのCBの例は、セクション4に記載されています。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Design of a CB (What makes a good CB?)

3. CBの設計（優れたCBを構成するものは何ですか？）

Although CBs have been talked about in the IETF for many years, there has not yet been guidance on the cases where CBs are needed or upon the design of CB mechanisms. This document seeks to offer advice on these two topics.

CBはIETFで長年話題になっていますが、CBが必要な場合やCBメカニズムの設計に関するガイダンスはまだありません。このドキュメントでは、これら2つのトピックについてアドバイスを提供することを目的としています。

CBs are RECOMMENDED for IETF protocols and tunnels that carry non-congestion-controlled Internet flows and for traffic aggregates. This includes traffic sent using a network tunnel. Designers of other protocols and tunnel encapsulations also ought to consider the use of these techniques as a last resort to protect traffic that shares the network path being used.

CBは、輻輳が制御されていないインターネットフローを伝送するIETFプロトコルとトンネル、およびトラフィックの集約に推奨されます。これには、ネットワークトンネルを使用して送信されたトラフィックが含まれます。他のプロトコルとトンネルカプセル化の設計者も、使用されているネットワークパスを共有するトラフィックを保護するための最後の手段として、これらの技術の使用を検討する必要があります。

This document defines the requirements for the design of a CB and provides examples of how a CB can be constructed. The specifications of individual protocols and tunnel encapsulations need to detail the protocol mechanisms needed to implement a CB.

このドキュメントでは、CBの設計の要件を定義し、CBを構築する方法の例を示します。個々のプロトコルとトンネルカプセル化の仕様は、CBの実装に必要なプロトコルメカニズムの詳細を示す必要があります。

Section 3.1 describes the functional components of a CB and Section 3.2 defines requirements for implementing a CB.

セクション3.1では、CBの機能コンポーネントについて説明し、セクション3.2では、CBを実装するための要件を定義します。

3.1. Functional Components

3.1. 機能部品

The basic design of a CB involves communication between an ingress point (a sender) and an egress point (a receiver) of a network flow or set of flows. A simple picture of operation is provided in Figure 1. This shows a set of routers (each labeled R) connecting a set of endpoints.

CBの基本設計には、ネットワークフローまたはフローのセットの入口ポイント（送信側）と出口ポイント（受信側）の間の通信が含まれます。動作の簡単な図を図1に示します。これは、一連のエンドポイントを接続する一連のルーター（それぞれRのラベルが付いている）を示しています。

A CB is used to control traffic passing through a subset of these routers, acting between the ingress and a egress point network devices. The path between the ingress and egress could be provided by a tunnel or other network-layer technique. One expected use would be at the ingress and egress of a service, where all traffic being considered terminates beyond the egress point; hence, the ingress and egress carry the same set of flows.

CBは、これらのルーターのサブセットを通過するトラフィックを制御するために使用され、入口と出口のネットワークデバイス間で動作します。入力と出力の間のパスは、トンネルまたは他のネットワーク層技術によって提供できます。予想される用途の1つは、サービスの入口と出口であり、考慮されているすべてのトラフィックは出口ポイントを超えて終端します。したがって、入力と出力は同じフローのセットを伝送します。

 +--------+                                                   +--------+
 |Endpoint|                                                   |Endpoint|
 +--+-----+          >>> circuit breaker traffic >>>          +--+-----+
    |                                                            |
    | +-+  +-+  +---------+  +-+  +-+  +-+  +--------+  +-+  +-+ |
    +-+R+--+R+->+ Ingress +--+R+--+R+--+R+--+ Egress |--+R+--+R+-+
      +++  +-+  +------+--+  +-+  +-+  +-+  +-----+--+  +++  +-+
       |         ^     |                          |      |
       |         |  +--+------+            +------+--+   |
       |         |  | Ingress |            | Egress  |   |
       |         |  | Meter   |            | Meter   |   |
       |         |  +----+----+            +----+----+   |
       |         |       |                      |        |
  +-+  |         |  +----+----+                 |        |  +-+
  |R+--+         |  | Measure +<----------------+        +--+R|
  +++            |  +----+----+      Reported               +++
   |             |       |           Egress                  |
   |             |  +----+----+      Measurement             |
+--+-----+       |  | Trigger +                           +--+-----+
|Endpoint|       |  +----+----+                           |Endpoint|
+--------+       |       |                                +--------+
                 +---<---+
                  Reaction

Figure 1: A CB controlling the part of the end-to-end path between an ingress point and an egress point. Note in some cases, the trigger and measurement functions could alternatively be located at other locations (e.g., at a network operations center).

図1：入力ポイントと出力ポイント間のエンドツーエンドパスの一部を制御するCB。場合によっては、トリガー機能と測定機能を別の場所（ネットワークオペレーションセンターなど）に配置することもできます。

In the context of a CB, the ingress and egress functions could be implemented in different places. For example, they could be located in network devices at a tunnel ingress and at the tunnel egress. In some cases, they could be located at one or both network endpoints (see Figure 2), implemented as components within a transport protocol.

CBのコンテキストでは、入口と出口の機能を異なる場所に実装できます。たとえば、ネットワークデバイスのトンネルの入口と出口に配置できます。場合によっては、1つまたは両方のネットワークエンドポイント（図2を参照）に配置し、トランスポートプロトコル内のコンポーネントとして実装することもできます。

    +----------+                 +----------+
    | Ingress  |  +-+  +-+  +-+  | Egress   |
    | Endpoint +->+R+--+R+--+R+--+ Endpoint |
    +--+----+--+  +-+  +-+  +-+  +----+-----+
       ^    |                         |
       | +--+------+             +----+----+
       | | Ingress |             | Egress  |
       | | Meter   |             | Meter   |
       | +----+----+             +----+----+
       |      |                       |
       | +--- +----+                  |
       | | Measure +<-----------------+
       | +----+----+      Reported
       |      |           Egress
       | +----+----+      Measurement
       | | Trigger |
       | +----+----+
       |      |
       +---<--+
       Reaction

Figure 2: An endpoint CB implemented at the sender (ingress) and receiver (egress).

図2：送信者（入力）と受信者（出力）に実装されたエンドポイントCB。

The set of components needed to implement a CB are:

CBの実装に必要なコンポーネントのセットは次のとおりです。

1. An ingress meter (at the sender or tunnel ingress) that records the number of packets/bytes sent in each measurement interval. This measures the offered network load for a flow or set of flows. For example, the measurement interval could be many seconds (or every few tens of seconds or a series of successive shorter measurements that are combined by the CB Measurement function).

1. 各測定間隔で送信されたパケット数/バイト数を記録する入力メーター（送信側またはトンネル入力側）。これは、フローまたはフローのセットに対して提供されるネットワーク負荷を測定します。たとえば、測定間隔は数秒（または数十秒ごと、またはCB測定機能によって組み合わされた一連の連続した短い測定）にすることができます。

2. An egress meter (at the receiver or tunnel egress) that records the number/bytes received in each measurement interval. This measures the supported load for the flow or set of flows, and it could utilize other signals to detect the effect of congestion (e.g., loss/congestion marking [RFC3168] experienced over the path). The measurements at the egress could be synchronized (including an offset for the time of flight of the data, or referencing the measurements to a particular packet) to ensure any counters refer to the same span of packets.

2. 各測定間隔で受信した数/バイトを記録する（受信機またはトンネル出力での）出力メーター。これは、フローまたはフローのセットでサポートされている負荷を測定し、他の信号を利用して、輻輳の影響（パス上で発生した損失/輻輳マーキング[RFC3168]など）を検出できます。出口での測定値を同期して（データの飛行時間のオフセットを含むか、測定値を特定のパケットを参照して）、カウンターが同じパケットスパンを参照するようにします。

3. A method that communicates the measured values at the ingress and egress to the CB Measurement function. This could use several methods including sending return measurement packets (or control messages) from a receiver to a trigger function at the sender; an implementation using Operations, Administration and Management (OAM); or sending an in-band signaling datagram to the trigger function. This could also be implemented purely as a control-plane function, e.g., using a software-defined network controller.

3. 入力と出力の測定値をCB Measurement関数に伝達する方法。これは、受信側から送信側のトリガー機能に戻り測定パケット（または制御メッセージ）を送信するなど、いくつかの方法を使用できます。運用、管理、管理（OAM）を使用した実装。または、インバンドシグナリングデータグラムをトリガー機能に送信します。これは、たとえばソフトウェア定義のネットワークコントローラーを使用して、純粋にコントロールプレーン機能として実装することもできます。

4. A measurement function that combines the ingress and egress measurements to assess the present level of network congestion. (For example, the loss rate for each measurement interval could be deduced from calculating the difference between ingress and egress counter values.) Note the method does not require high accuracy for the period of the measurement interval (or therefore the measured value, since isolated and/or infrequent loss events need to be disregarded).

4. 入力と出力の測定値を組み合わせて、ネットワークの輻輳の現在のレベルを評価する測定機能。（たとえば、各測定間隔の損失率は、入力と出力のカウンター値の差の計算から推定できます。）この方法では、測定間隔の期間（または分離されているため、測定値）の高精度は必要ありません。および/またはまれな損失イベントは無視する必要があります）。

5. A trigger function that determines whether the measurements indicate persistent excessive congestion. This function defines an appropriate threshold for determining that there is persistent excessive congestion between the ingress and egress. This preferably considers a rate or ratio, rather than an absolute value (e.g., more than 10% loss, but other methods could also be based on the rate of transmission as well as the loss rate). The CB is triggered when the threshold is exceeded in multiple measurement intervals (e.g., three successive measurements). Designs need to be robust so that single or spurious events do not trigger a reaction.

5. 測定が永続的な過度の輻輳を示しているかどうかを判別するトリガー機能。この関数は、入力と出力の間に永続的な過度の輻輳があると判断するための適切なしきい値を定義します。これは、絶対値ではなく、速度または比率を考慮することが好ましい（たとえば、10％を超える損失。ただし、他の方法も、伝送速度と損失速度に基づくことができる）。 CBは、複数の測定間隔（たとえば、3回の連続した測定）でしきい値を超えたときにトリガーされます。設計は堅牢である必要があり、単一または偽のイベントが反応を引き起こさないようにする必要があります。

6. A reaction that is applied at the ingress when the CB is triggered. This seeks to automatically remove the traffic causing persistent excessive congestion.

6. CBがトリガーされたときに入口で適用される反応。これは、永続的な過度の輻輳を引き起こすトラフィックを自動的に削除しようとします。

7. A feedback control mechanism that triggers when either the ingress and egress measurements are not available, since this also could indicate a loss of control packets (also a symptom of heavy congestion or inability to control the load).

7. 入力と出力のどちらかの測定値が使用できない場合にトリガーするフィードバック制御メカニズム。これは、制御パケットの損失を示している可能性もあります（輻輳が重いか、負荷を制御できないことの症状）。

3.2. Other Network Topologies

3.2. その他のネットワークトポロジ

A CB can be deployed in networks with topologies different from that presented in Figures 1 and 2. This section describes examples of such usage and possible places where functions can be implemented.

CBは、図1および2に示したものとは異なるトポロジのネットワークに展開できます。このセクションでは、そのような使用例と、機能を実装できる場所について説明します。

3.2.1. Use with a Multicast Control/Routing Protocol

3.2.1. マルチキャスト制御/ルーティングプロトコルでの使用

    +----------+                 +--------+  +----------+
    | Ingress  |  +-+  +-+  +-+  | Egress |  |  Egress  |
    | Endpoint +->+R+--+R+--+R+--+ Router |--+ Endpoint +->+
    +----+-----+  +-+  +-+  +-+  +---+--+-+  +----+-----+  |
         ^         ^    ^    ^       |  ^         |        |
         |         |    |    |       |  |         |        |
    +----+----+    + - - - < - - - - +  |    +----+----+   | Reported
    | Ingress |      multicast Prune    |    | Egress  |   | Ingress
    | Meter   |                         |    | Meter   |   | Measurement
    +---------+                         |    +----+----+   |
                                        |         |        |
                                        |    +----+----+   |
                                        |    | Measure +<--+
                                        |    +----+----+
                                        |         |
                                        |    +----+----+
                              multicast |    | Trigger |
                              Leave     |    +----+----+
                              Message   |         |
                                        +----<----+

Figure 3: An example of a multicast CB controlling the end-to-end path between an ingress endpoint and an egress endpoint.

図3：入力エンドポイントと出力エンドポイント間のエンドツーエンドパスを制御するマルチキャストCBの例。

Figure 3 shows one example of how a multicast CB could be implemented at a pair of multicast endpoints (e.g., to implement a Fast-Trip CB, Section 5.1). The ingress endpoint (the sender that sources the multicast traffic) meters the ingress load, generating an ingress measurement (e.g., recording timestamped packet counts), and it sends this measurement to the multicast group together with the traffic it has measured.

図3は、マルチキャストCBを一対のマルチキャストエンドポイントで実装する方法の一例を示しています（たとえば、Fast-Trip CBを実装するために、セクション5.1）。入力エンドポイント（マルチキャストトラフィックを送信する送信者）は、入力負荷を測定し、入力測定（タイムスタンプ付きパケットカウントの記録など）を生成し、測定したトラフィックとともにこの測定をマルチキャストグループに送信します。

Routers along a multicast path forward the multicast traffic (including the ingress measurement) to all active endpoint receivers. Each last hop (egress) router forwards the traffic to one or more egress endpoints.

マルチキャストパスに沿ったルーターは、すべてのアクティブなエンドポイントレシーバーにマルチキャストトラフィック（入力測定を含む）を転送します。各最終ホップ（出力）ルーターは、トラフィックを1つ以上の出力エンドポイントに転送します。

In Figure 3, each endpoint includes a meter that performs a local egress load measurement. An endpoint also extracts the received ingress measurement from the traffic and compares the ingress and egress measurements to determine if the CB ought to be triggered. This measurement has to be robust to loss (see the previous section). If the CB is triggered, it generates a multicast leave message for the egress (e.g., an IGMP or MLD message sent to the last-hop router), which causes the upstream router to cease forwarding traffic to the egress endpoint [RFC1112].

図3では、各エンドポイントに、ローカルの出力負荷測定を実行するメーターが含まれています。エンドポイントは、受信した入力測定値をトラフィックから抽出し、入力測定値と出力測定値を比較して、CBをトリガーする必要があるかどうかを判断します。この測定は、損失に対して堅牢でなければなりません（前のセクションを参照）。 CBがトリガーされると、CBは出力用のマルチキャストLeaveメッセージ（たとえば、ラストホップルーターに送信されるIGMPまたはMLDメッセージ）を生成します。これにより、上流ルーターが出力エンドポイントへのトラフィックの転送を停止します[RFC1112]。

Any multicast router that has no active receivers for a particular multicast group will prune traffic for that group, sending a prune message to its upstream router. This starts the process of releasing the capacity used by the traffic and is a standard multicast routing function (e.g., using Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol [RFC7761]). Each egress operates autonomously, and the CB "reaction" is executed by the multicast control plane (e.g., by PIM) requiring no explicit signaling by the CB along the communication path used for the control messages. Note there is no direct communication with the ingress; hence, a triggered CB only controls traffic downstream of the first-hop multicast router. It does not stop traffic flowing from the sender to the first-hop router; this is common practice for multicast deployment.

特定のマルチキャストグループのアクティブなレシーバがないマルチキャストルータは、そのグループのトラフィックをプルーニングし、プルーニングメッセージをアップストリームルータに送信します。これは、トラフィックで使用されている容量を解放するプロセスを開始し、標準のマルチキャストルーティング機能です（たとえば、プロトコルに依存しないマルチキャスト-スパースモード（PIM-SM）ルーティングプロトコル[RFC7761]を使用）。各出口は自律的に動作し、CBの「反応」は、制御メッセージに使用される通信パスに沿ったCBによる明示的なシグナリングを必要としないマルチキャスト制御プレーン（PIMなど）によって実行されます。イングレスとは直接通信しないことに注意してください。したがって、トリガーされたCBは、ファーストホップマルチキャストルーターのダウンストリームトラフィックのみを制御します。送信者からファーストホップルーターへのトラフィックフローは停止しません。これは、マルチキャスト展開の一般的な方法です。

The method could also be used with a multicast tunnel or subnetwork (e.g., Section 5.2, Section 5.3), where a meter at the ingress generates additional control messages to carry the measurement data towards the egress where the egress metering is implemented.

この方法は、マルチキャストトンネルまたはサブネットワーク（セクション5.2、セクション5.3など）でも使用できます。この場合、入口のメーターが追加の制御メッセージを生成して、出口メータリングが実装されている出口に向けて測定データを伝送します。

3.2.2. Use with Control Protocols Supporting Pre-provisioned Capacity

3.2.2. 事前にプロビジョニングされた容量をサポートする制御プロトコルでの使用

Some paths are provisioned using a control protocol, e.g., flows provisioned using the Multiprotocol Label Switching (MPLS) services, paths provisioned using the Resource Reservation Protocol (RSVP), networks utilizing Software-Defined Network (SDN) functions, or admission-controlled Differentiated Services. Figure 1 shows one expected use case, where in this usage a separate device could be used to perform the measurement and trigger functions. The reaction generated by the trigger could take the form of a network-control message sent to the ingress and/or other network elements causing these elements to react to the CB. Examples of this type of use are provided in Section 5.3.

一部のパスは、制御プロトコルを使用してプロビジョニングされます。たとえば、マルチプロトコルラベルスイッチング（MPLS）サービスを使用してプロビジョニングされたフロー、リソース予約プロトコル（RSVP）を使用してプロビジョニングされたパス、ソフトウェア定義ネットワーク（SDN）機能を利用したネットワーク、またはアドミッション制御の差別化サービス。図1は、予想される1つの使用例を示しています。この使用方法では、別のデバイスを使用して測定およびトリガー機能を実行できます。トリガーによって生成された反応は、入力および/または他のネットワーク要素に送信されるネットワーク制御メッセージの形式を取り、これらの要素をCBに反応させることができます。このタイプの使用例は、セクション5.3に記載されています。

3.2.3. Unidirectional CBs over Controlled Paths

3.2.3. 制御されたパス上の単方向CB

A CB can be used to control unidirectional UDP traffic, providing that there is a communication path that can be used for control messages to connect the functional components at the ingress and egress. This communication path for the control messages can exist in networks for which the traffic flow is purely unidirectional. For example, a multicast stream that sends packets across an Internet path and can use multicast routing to prune flows to shed network load. Some other types of subnetwork also utilize control protocols that can be used to control traffic flows.

CBを使用して単方向UDPトラフィックを制御できます。ただし、制御メッセージが入力と出力で機能コンポーネントを接続するために使用できる通信パスがある場合に限ります。制御メッセージのこの通信パスは、トラフィックフローが純粋に単方向であるネットワークに存在できます。たとえば、インターネットパスを介してパケットを送信し、マルチキャストルーティングを使用してフローをプルーニングしてネットワーク負荷を軽減できるマルチキャストストリーム。他のいくつかのタイプのサブネットワークも、トラフィックフローの制御に使用できる制御プロトコルを利用します。

4. Requirements for a Network Transport CB

4. ネットワークトランスポートCBの要件

The requirements for implementing a CB are:

CBを実装するための要件は次のとおりです。

1. There needs to be a communication path for control messages to carry measurement data from the ingress meter and from the egress meter to the point of measurement. (Requirements 16-18 relate to the transmission of control messages.)

1. 制御メッセージが入力メーターから、および出力メーターから測定ポイントまで測定データを伝送するための通信パスが必要です。（要件16〜18は、制御メッセージの送信に関連しています。）

2. A CB is REQUIRED to define a measurement period over which the CB Measurement function measures the level of congestion or loss. This method does not have to detect individual packet loss, but it MUST have a way to know that packets have been lost/marked from the traffic flow.

2. CBは、CB Measurement機能が輻輳または損失のレベルを測定する測定期間を定義するために必要です。この方法は個々のパケット損失を検出する必要はありませんが、トラフィックフローからパケットが失われた/マークされたことを知る方法が必要です。

3. An egress meter can also count ECN [RFC3168] Congestion Experienced (CE) marks as a part of measurement of congestion, but in this case, loss MUST also be measured to provide a complete view of the level of congestion. For tunnels, [CONGESTION-FEEDBACK] describes a way to measure both loss and ECN-marking; these measurements could be used on a relatively short timescale to drive a congestion control response and/or aggregated over a longer timescale with a higher trigger threshold to drive a CB. Subsequent bullet items in this section discuss the necessity of using a longer timescale and a higher trigger threshold.

3. 出口メーターは、ECN [RFC3168] Congestion Experienced（CE）マークを輻輳の測定の一部としてカウントすることもできますが、この場合、輻輳のレベルの完全なビューを提供するために損失も測定する必要があります。トンネルの場合、[CONGESTION-FEEDBACK]は、損失とECNマーキングの両方を測定する方法を説明しています。これらの測定値は、比較的短いタイムスケールで使用して輻輳制御応答を駆動したり、トリガーしきい値が高い長いタイムスケールで集計してCBを駆動したりできます。このセクションの後続の箇条書き項目では、より長いタイムスケールとより高いトリガーしきい値を使用する必要性について説明します。

4. The measurement period used by a CB Measurement function MUST be longer than the time that current Congestion Control algorithms need to reduce their rate following detection of congestion. This is important because end-to-end Congestion Control algorithms require at least one RTT to notify and adjust the traffic when congestion is experienced, and congestion bottlenecks can share traffic with a diverse range of end-to-end RTTs. The measurement period is therefore expected to be significantly longer than the RTT experienced by the CB itself.

4. CB Measurement機能で使用される測定期間は、現在の輻輳制御アルゴリズムが輻輳の検出後にレートを下げる必要がある時間より長くなければなりません（MUST）。エンドツーエンドの輻輳制御アルゴリズムは、輻輳が発生したときにトラフィックを通知および調整するために少なくとも1つのRTTを必要とし、輻輳のボトルネックはさまざまなエンドツーエンドRTTとトラフィックを共有できるため、これは重要です。したがって、測定期間は、CB自体が経験するRTTよりも大幅に長くなることが予想されます。

5. If necessary, a CB MAY combine successive individual meter samples from the ingress and egress to ensure observation of an average measurement over a sufficiently long interval. (Note when meter samples need to be combined, the combination needs to reflect the sum of the individual sample counts divided by the total time/volume over which the samples were measured. Individual samples over different intervals cannot be directly combined to generate an average value.)

5. 必要に応じて、CBは、入力と出力からの連続する個々のメーターサンプルを組み合わせて、十分に長い間隔での平均測定値の観測を保証できます。（メーターサンプルを組み合わせる必要がある場合、組み合わせは、個々のサンプルカウントの合計を、サンプルが測定された合計時間/ボリュームで割ったものを反映する必要があります。異なる間隔の個々のサンプルを直接組み合わせて平均値を生成することはできません。。）

6. A CB MUST be constructed so that it does not trigger under light or intermittent congestion (see requirements 7-9).

6. CBは、軽いまたは断続的な輻輳の下でトリガーされないように構築する必要があります（要件7-9を参照）。

7. A CB is REQUIRED to define a threshold to determine whether the measured congestion is considered excessive.

7. CBは、測定された輻輳が過度であると見なされるかどうかを決定するためのしきい値を定義する必要があります。

8. A CB is REQUIRED to define the triggering interval, defining the period over which the trigger uses the collected measurements. CBs need to trigger over a sufficiently long period to avoid additionally penalizing flows with a long path RTT (e.g., many path RTTs).

8. CBは、トリガー間隔を定義し、トリガーが収集された測定値を使用する期間を定義するために必要です。 CBは、長いパスRTT（たとえば、多くのパスRTT）を使用してフローに追加のペナルティを課すことを回避するために、十分に長い期間トリガーする必要があります。

9. A CB MUST be robust to multiple congestion events. This usually will define a number of measured persistent congestion events per triggering period. For example, a CB MAY combine the results of several measurement periods to determine if the CB is triggered (e.g., it is triggered when persistent excessive congestion is detected in three of the measurements within the triggering interval when more than three measurements were collected).

9. CBは、複数の輻輳イベントに対して堅牢でなければなりません。これは通常、トリガー期間ごとに測定された持続的な輻輳イベントの数を定義します。たとえば、CBは、複数の測定期間の結果を組み合わせて、CBがトリガーされているかどうかを判断できます（たとえば、3つ以上の測定が収集されたときに、トリガー間隔内の3つの測定で永続的な過度の輻輳が検出された場合にトリガーされます）。

10. The normal reaction to a trigger SHOULD disable all traffic that contributed to congestion (otherwise, see requirements 11 and 12).

10. トリガーに対する通常の反応は、輻輳の原因となったすべてのトラフィックを無効にする必要があります（そうでない場合は、要件11および12を参照してください）。

11. The reaction MUST be much more severe than that of a Congestion Control algorithm (such as TCP's congestion control [RFC5681] or TCP-Friendly Rate Control, TFRC [RFC5348]), because the CB reacts to more persistent congestion and operates over longer timescales (i.e., the overload condition will have persisted for a longer time before the CB is triggered).

11. CBはより永続的な輻輳に反応し、より長いタイムスケールで動作するため、反応は輻輳制御アルゴリズム（TCPの輻輳制御[RFC5681]またはTCP-Friendly Rate Control、TFRC [RFC5348]など）よりはるかに厳しくなければなりません（MUST）。つまり、CBがトリガーされる前に、過負荷状態が長時間持続します。

12. A reaction that results in a reduction SHOULD result in reducing the traffic by at least an order of magnitude. A response that achieves the reduction by terminating flows, rather than randomly dropping packets, will often be more desirable to users of the service. A CB that reduces the rate of a flow, MUST continue to monitor the level of congestion and MUST further react to reduce the rate if the CB is again triggered.

12. 削減につながる反応は、トラフィックを少なくとも1桁削減する必要があります（SHOULD）。ランダムにパケットをドロップするのではなく、フローを終了することによって削減を達成する応答は、多くの場合、サービスのユーザーにとってより望ましいでしょう。フローのレートを下げるCBは、輻輳のレベルを監視し続けなければならず、CBが再びトリガーされた場合、レートを下げるためにさらに反応する必要があります。

13. The reaction to a triggered CB MUST continue for a period that is at least the triggering interval. Operator intervention will usually be required to restore a flow. If an automated response is needed to reset the trigger, then this needs to not be immediate. The design of an automated reset mechanism needs to be sufficiently conservative that it does not adversely interact with other mechanisms (including other CB algorithms that control traffic over a common path). It SHOULD NOT perform an automated reset when there is evidence of continued congestion.

13. トリガーされたCBへの反応は、少なくともトリガー間隔である期間継続する必要があります。通常、フローを復元するにはオペレーターの介入が必要です。トリガーをリセットするために自動応答が必要な場合、これは即時である必要はありません。自動リセットメカニズムの設計は、他のメカニズム（共通パス上のトラフィックを制御する他のCBアルゴリズムを含む）と悪影響を与えないように十分に保守的である必要があります。継続的な輻輳の証拠がある場合は、自動リセットを実行しないでください。

14. A CB trigger SHOULD be regarded as an abnormal network event. As such, this event SHOULD be logged. The measurements that lead to triggering of the CB SHOULD also be logged.

14. CBトリガーは、異常なネットワークイベントと見なしてください。そのため、このイベントはログに記録する必要があります（SHOULD）。 CBのトリガーにつながる測定値もログに記録する必要があります。

15. The control communication needs to carry measurements (requirement 1) and, in some uses, also needs to transmit trigger messages to the ingress. This control communication may be in or out of band. The use of in-band communication is RECOMMENDED when either design would be possible. The preferred CB design is one that triggers when it fails to receive measurement reports that indicate an absence of congestion, in contrast to relying on the successful transmission of a "congested" signal back to the sender. (The feedback signal could itself be lost under congestion).

15. 制御通信は測定値を送信する必要があり（要件1）、場合によっては、トリガーメッセージを入力に送信する必要もあります。この制御通信は、帯域内または帯域外の場合があります。どちらかの設計が可能な場合は、帯域内通信の使用をお勧めします。送信者への「輻輳」信号の正常な送信に依存するのとは対照的に、好ましいCB設計は、輻輳がないことを示す測定レポートを受信できないときにトリガーするものです。（フィードバック信号自体は、輻輳下で失われる可能性があります）。

In Band: An in-band control method SHOULD assume that loss of control messages is an indication of potential congestion on the path, and repeated loss ought to cause the CB to be triggered. This design has the advantage that it provides fate-sharing of the traffic flow(s) and the control communications. This fate-sharing property is weaker when some or all of the measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic and control messages follow a different path due to use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic).

帯域内：帯域内制御方法は、制御メッセージの損失がパス上の潜在的な輻輳の指標であり、CBがトリガーされる原因となるはずの損失が繰り返されることを想定している必要があります。この設計には、トラフィックフローと制御通信の運命共有を提供するという利点があります。この運命共有プロパティは、測定されたトラフィックの一部またはすべてが、制御トラフィックがとるパスとは異なるパスを使用して送信される場合に弱くなります（たとえば、等コストマルチパスの使用によりトラフィックと制御メッセージが異なるパスをたどる場合）ルーティング、トラフィックエンジニアリング、または特定の種類のトラフィックのトンネル）。

Out of Band: An out-of-band control method SHOULD NOT trigger a CB reaction when there is loss of control messages (e.g., a loss of measurements). This avoids failure amplification/ propagation when the measurement and data paths fail independently. A failure of an out-of-band communication path SHOULD be regarded as an abnormal network event and be handled as appropriate for the network; for example, this event SHOULD be logged, and additional network operator action might be appropriate, depending on the network and the traffic involved.

アウトオブバンド：アウトオブバンド制御方法は、制御メッセージの喪失（たとえば、測定値の喪失）がある場合にCB反応をトリガーしてはなりません（SHOULD NOT）。これにより、測定パスとデータパスが独立して失敗した場合の失敗の増幅/伝播を回避できます。帯域外通信パスの障害は、異常なネットワークイベントと見なして、ネットワークに応じて適切に処理する必要があります（SHOULD）。たとえば、このイベントはログに記録する必要があり（SHOULD）、ネットワークと関連するトラフィックに応じて、追加のネットワークオペレーターアクションが適切な場合があります。

16. The control communication MUST be designed to be robust to packet loss. A control message can be lost if there is a failure of the communication path used for the control messages, loss is likely also to be experienced during congestion/ overload. This does not imply that it is desirable to provide reliable delivery (e.g., over TCP), since this can incur additional delay in responding to congestion. Appropriate mechanisms could be to duplicate control messages to provide increased robustness to loss and/or to regard a lack of control traffic as an indication that excessive congestion could be being experienced [RFC8085]. If control message traffic is sent over a shared path, it is RECOMMENDED that this control traffic is prioritized to reduce the probability of loss under congestion. Control traffic also needs to be considered when provisioning a network that uses a CB.

16.制御通信は、パケット損失に対してロバストになるように設計する必要があります。制御メッセージに使用される通信パスに障害が発生すると、制御メッセージが失われる可能性があり、輻輳/過負荷時にも失われる可能性があります。これは、輻輳への応答に追加の遅延が発生する可能性があるため、信頼できる配信（TCP経由など）を提供することが望ましいことを意味するものではありません。適切なメカニズムは、制御メッセージを複製して、損失に対するロバスト性を高めたり、制御トラフィックの欠如を過度の輻輳が発生している可能性があることを示すものと見なしたりすることです[RFC8085]。制御メッセージトラフィックが共有パスを介して送信される場合は、この制御トラフィックを優先して、輻輳下での損失の可能性を減らすことをお勧めします。 CBを使用するネットワークをプロビジョニングするときは、制御トラフィックも考慮する必要があります。

17. There are security requirements for the control communication between endpoints and/or network devices (Section 7). The authenticity of the source and integrity of the control messages (measurements and triggers) MUST be protected from off-path attacks. When there is a risk of an on-path attack, a cryptographic authentication mechanism for all control/ measurement messages is RECOMMENDED.

17. エンドポイントまたはネットワークデバイス（あるいはその両方）間の制御通信にはセキュリティ要件があります（セクション7）。発信元の信頼性と制御メッセージ（測定値とトリガー）の整合性は、オフパス攻撃から保護する必要があります。経路上の攻撃のリスクがある場合、すべての制御/測定メッセージの暗号化認証メカニズムが推奨されます。

5. Examples of CBs

5. CBの例

There are multiple types of CB that could be defined for use in different deployment cases. There could be cases where a flow becomes controlled by multiple CBs (e.g., when the traffic of an end-to-end flow is carried in a tunnel within the network). This section provides examples of different types of CB.

さまざまな展開ケースで使用するために定義できる複数のタイプのCBがあります。フローが複数のCBによって制御されるようになる場合があります（たとえば、エンドツーエンドフローのトラフィックがネットワーク内のトンネルで伝送される場合）。このセクションでは、さまざまなタイプのCBの例を示します。

5.1. A Fast-Trip CB

5.1. ファーストトリップCB

[RFC2309] discusses the dangers of congestion unresponsive flows and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms." Some applications do not use a full-featured transport (TCP, SCTP, DCCP). These applications (e.g., using UDP and its UDP-Lite variant) need to provide appropriate congestion avoidance. Guidance for applications that do not use congestion-controlled transports is provided in [RFC8085]. Such mechanisms can be designed to react on much shorter timescales than a CB, that only observes a traffic envelope. Congestion control methods can also interact with an application to more effectively control its sending rate.

[RFC2309]は、輻輳の無応答フローの危険性について説明し、「すべてのUDPベースのストリーミングアプリケーションに効果的な輻輳回避メカニズムを組み込む必要がある」と述べています。一部のアプリケーションは、フル機能のトランスポート（TCP、SCTP、DCCP）を使用しません。これらのアプリケーション（UDPとそのUDP-Liteバリアントを使用するなど）は、適切な輻輳回避を提供する必要があります。輻輳制御のトランスポートを使用しないアプリケーションのガイダンスは、[RFC8085]で提供されています。このようなメカニズムは、トラフィックエンベロープのみを監視するCBよりもはるかに短いタイムスケールで反応するように設計できます。輻輳制御メソッドは、アプリケーションと対話して、その送信速度をより効果的に制御することもできます。

A Fast-trip CB is the most responsive form of CB. It has a response time that is only slightly larger than that of the traffic that it controls. It is suited to traffic with well-understood characteristics (and could include one or more trigger functions specifically tailored the type of traffic for which it is designed). It is not suited to arbitrary network traffic and could be unsuitable for traffic aggregates, since it could prematurely trigger (e.g., when the combined traffic from multiple congestion-controlled flows leads to short-term overload).

Fast-trip CBは、CBの最も応答性の高い形式です。応答時間は、制御するトラフィックの応答時間よりもわずかに長くなります。これは、よく理解されている特性を持つトラフィックに適しています（設計されているトラフィックのタイプに特化した1つ以上のトリガー機能を含めることができます）。これは、任意のネットワークトラフィックには適しておらず、早期にトリガーされる可能性があるため（たとえば、複数の輻輳制御フローからの結合されたトラフィックが短期的な過負荷につながる場合）、トラフィックの集約には適さない可能性があります。

Although the mechanisms can be implemented in RTP-aware network devices, these mechanisms are also suitable for implementation in endpoints (e.g., as a part of the transport system) where they can also complement end-to-end congestion control methods. A shorter response time enables these mechanisms to triggers before other forms of CB (e.g., CBs operating on traffic aggregates at a point along the network path).

メカニズムはRTP対応のネットワークデバイスで実装できますが、エンドツーエンドの輻輳制御方法を補完できるエンドポイント（トランスポートシステムの一部など）での実装にも適しています。応答時間が短いと、これらのメカニズムは他の形式のCB（たとえば、ネットワークパスに沿ったポイントでトラフィック集約で動作するCB）の前にトリガーできます。

5.1.1. A Fast-Trip CB for RTP

5.1.1. RTPのFast-Trip CB

A set of Fast-Trip CB methods have been specified for use together by a Real-time Transport Protocol (RTP) flow using the RTP/AVP Profile [RFC8083]. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these CBs. An RTP Fast-Trip CB is therefore implemented as a fail-safe that, when triggered, will terminate RTP traffic.

RTP / AVPプロファイル[RFC8083]を使用したリアルタイムトランスポートプロトコル（RTP）フローで一緒に使用するFast-Trip CBメソッドのセットが指定されています。深刻な輻輳がない場合、ベストエフォートIPネットワークで実行されているすべてのRTPアプリケーションは、これらのCBをトリガーせずに実行できると予想されます。したがって、RTP Fast-Trip CBはフェールセーフとして実装され、トリガーされるとRTPトラフィックを終了します。

The sending endpoint monitors reception of in-band RTP Control Protocol (RTCP) reception report blocks, as contained in sender report (SR) or receiver report (RR) packets, that convey reception quality feedback information. This is used to measure (congestion) loss, possibly in combination with ECN [RFC6679].

送信エンドポイントは、受信品質フィードバック情報を伝達する送信者レポート（SR）または受信者レポート（RR）パケットに含まれる、インバンドRTP制御プロトコル（RTCP）受信レポートブロックの受信を監視します。これは、ECN [RFC6679]と組み合わせて、（輻輳）損失を測定するために使用されます。

The CB action (shutdown of the flow) triggers when any of the following trigger conditions are true:

CBアクション（フローのシャットダウン）は、以下のトリガー条件のいずれかに該当する場合にトリガーされます。

1. An RTP CB triggers on reported lack of progress.

1. RTP CBは、報告された進捗の欠如でトリガーされます。

2. An RTP CB triggers when no receiver reports messages are received.

2. RTP CBは、受信者がメッセージを受信したことを報告しないときにトリガーされます。

3. An RTP CB triggers when the long-term RTP throughput (over many RTTs) exceeds a hard upper limit determined by a method that resembles TCP-Friendly Rate Control (TFRC).

3. RTP CBは、長期的なRTPスループット（多くのRTTを超える）が、TCP-Friendly Rate Control（TFRC）に似た方法で決定されたハード上限を超えたときにトリガーされます。

4. An RTP CB includes the notion of Media Usability. This CB is triggered when the quality of the transported media falls below some required minimum acceptable quality.

4. RTP CBには、メディアユーザビリティの概念が含まれています。このCBは、転送されるメディアの品質が必要な最低許容品質を下回ったときにトリガーされます。

5.2. A Slow-Trip CB

5.2. スロートリップCB

A Slow-Trip CB could be implemented in an endpoint or network device. This type of CB is much slower at responding to congestion than a Fast-Trip CB. This is expected to be more common.

Slow-Trip CBは、エンドポイントまたはネットワークデバイスに実装できます。このタイプのCBは、Fast-Trip CBよりも輻輳への応答がはるかに遅いです。これはより一般的であると予想されます。

One example where a Slow-Trip CB is needed is where flows or traffic-aggregates use a tunnel or encapsulation and the flows within the tunnel do not all support TCP-style congestion control (e.g., TCP, SCTP, TFRC), see [RFC8085], Section 3.1.3. A use case is where tunnels are deployed in the general Internet (rather than "controlled environments" within an Internet service provider or enterprise network), especially when the tunnel could need to cross a customer access router.

Slow-Trip CBが必要となる1つの例は、フローまたはトラフィック集約がトンネルまたはカプセル化を使用し、トンネル内のフローがすべてTCPスタイルの輻輳制御（TCP、SCTP、TFRCなど）をサポートしない場合です。[RFC8085を参照してください。 ]、セクション3.1.3。ユースケースは、トンネルが（インターネットサービスプロバイダーまたはエンタープライズネットワーク内の「制御された環境」ではなく）一般的なインターネットに展開されている場合で、特にトンネルが顧客のアクセスルーターを通過する必要がある場合です。

5.3. A Managed CB

5.3. マネージドCB

A managed CB is implemented in the signaling protocol or management plane that relates to the traffic aggregate being controlled. This type of CB is typically applicable when the deployment is within a "controlled environment".

マネージドCBは、制御されているトラフィック集約に関連するシグナリングプロトコルまたは管理プレーンに実装されます。このタイプのCBは、通常、展開が「制御された環境」内にある場合に適用できます。

A CB requires more than the ability to determine that a network path is forwarding data or to measure the rate of a path -- which are often normal network operational functions. There is an additional need to determine a metric for congestion on the path and to trigger a reaction when a threshold is crossed that indicates persistent excessive congestion.

CBには、ネットワークパスがデータを転送していることを確認したり、パスの速度を測定したりする機能以上のものが必要です。これは、通常のネットワーク運用機能です。パス上の輻輳のメトリックを決定し、持続的な過度の輻輳を示すしきい値を超えたときに反応をトリガーする追加のニーズがあります。

The control messages can use either in-band or out-of-band communications.

制御メッセージは、帯域内通信または帯域外通信のいずれかを使用できます。

5.3.1. A Managed CB for SAToP Pseudowires

5.3.1. SAToP疑似配線用の管理されたCB

Section 8 of [RFC4553], SAToP Pseudowire Emulation Edge-to-Edge (PWE3), describes an example of a managed CB for isochronous flows.

[RFC4553]のセクション8、SAToP疑似配線エミュレーションエッジツーエッジ（PWE3）では、アイソクロナスフローのマネージドCBの例について説明しています。

If such flows were to run over a pre-provisioned (e.g., Multiprotocol Label Switching, MPLS) infrastructure, then it could be expected that the PW would not experience congestion, because a flow is not expected to either increase (or decrease) their rate. If, instead, PW traffic is multiplexed with other traffic over the general Internet, it could experience congestion. [RFC4553] states: "If SAToP PWs run over a PSN providing best-effort service, they SHOULD monitor packet loss in order to detect 'severe congestion'." The currently recommended measurement period is 1 second, and the trigger operates when there are more than three measured Severely Errored Seconds (SES) within a period. [RFC4553] goes on to state that "If such a condition is detected, a SAToP PW ought to shut down bi-directionally for some period of time...".

このようなフローが事前にプロビジョニングされた（たとえば、マルチプロトコルラベルスイッチング、MPLS）インフラストラクチャ上で実行される場合、フローがレートを増加（または減少）することはないと予想されるため、PWで輻輳が発生しないことが期待できます。。代わりに、PWトラフィックが一般的なインターネットを介して他のトラフィックと多重化されると、輻輳が発生する可能性があります。 [RFC4553]の状態：「SAToP PWがベストエフォートサービスを提供するPSNで実行される場合、「深刻な輻輳」を検出するためにパケット損失を監視する必要があります。」現在推奨されている測定期間は1秒です。トリガーは、期間内に測定された重大エラー秒数（SES）が4つを超えると動作します。 [RFC4553]は、「このような状態が検出された場合、SAToP PWは一定期間双方向にシャットダウンする必要がある...」と述べています。

The concept was that when the packet-loss ratio (congestion) level increased above a threshold, the PW was, by default, disabled. This use case considered fixed-rate transmission, where the PW had no reasonable way to shed load.

概念は、パケット損失率（輻輳）レベルがしきい値を超えて増加すると、PWがデフォルトで無効になるというものでした。この使用例では、PWが負荷を制限するための合理的な方法がなかった固定レートの送信を検討しました。

The trigger needs to be set at a rate at which the PW is likely to experience a serious problem, possibly making the service noncompliant. At this point, triggering the CB would remove the traffic preventing undue impact on congestion-responsive traffic (e.g., TCP). Part of the rationale was that high-loss ratios typically indicated that something was "broken" and ought to have already resulted in operator intervention and therefore now need to trigger this intervention.

トリガーは、PWが重大な問題を経験する可能性が高いレートで設定する必要があり、サービスが非準拠になる可能性があります。この時点で、CBをトリガーするとトラフィックが削除され、輻輳対応トラフィック（TCPなど）への過度の影響が防止されます。理論的根拠の一部は、高損失率は通常、何かが「壊れている」ことを示しており、すでにオペレーターの介入が必要であるため、この介入をトリガーする必要があるということです。

An operator-based response to the triggering of a CB provides an opportunity for other action to restore the service quality (e.g., by shedding other loads or assigning additional capacity) or to consciously avoid reacting to the trigger while engineering a solution to the problem. This could require the trigger function to send a control message to a third location (e.g., a network operations center, NOC) that is responsible for operation of the tunnel ingress, rather than the tunnel ingress itself.

CBのトリガーに対するオペレーターベースの応答は、サービス品質を復元する（他の負荷を削減する、または追加の容量を割り当てるなど）か、問題の解決策を設計する際にトリガーへの反応を意識的に回避する他のアクションの機会を提供します。これには、トリガー機能が、トンネル入力自体ではなく、トンネル入力の操作を担当する3番目の場所（ネットワークオペレーションセンター、NOCなど）に制御メッセージを送信する必要がある場合があります。

5.3.2. A Managed CB for Pseudowires (PWs)

5.3.2. 疑似配線（PW）のマネージドCB

Pseudowires (PWs) [RFC3985] have become a common mechanism for tunneling traffic, and they could compete for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows.

疑似配線（PW）[RFC3985]はトラフィックをトンネリングするための一般的なメカニズムになり、他のPWとTCP / IPフローなどの非PWトラフィックの両方でネットワークリソースを奪い合う可能性があります。

[RFC7893] discusses congestion conditions that can arise when PWs compete with elastic (i.e., congestion responsive) network traffic (e.g., TCP traffic). Elastic PWs carrying IP traffic (see [RFC4448]) do not raise major concerns because all of the traffic involved responds, reducing the transmission rate when network congestion is detected.

[RFC7893]は、PWがエラスティック（つまり、輻輳に応答する）ネットワークトラフィック（TCPトラフィックなど）と競合するときに発生する可能性がある輻輳条件について説明します。 IPトラフィック（[RFC4448]を参照）を伝送するエラスティックPWは大きな問題を引き起こしません。これは、関係するすべてのトラフィックが応答し、ネットワークの輻輳が検出されると伝送速度が低下するためです。

In contrast, inelastic PWs (e.g., a fixed-bandwidth Time Division Multiplex, TDM [RFC4553] [RFC5086] [RFC5087]) have the potential to harm congestion-responsive traffic or to contribute to excessive congestion because inelastic PWs do not adjust their transmission rate in response to congestion. [RFC7893] analyses TDM PWs, with an initial conclusion that a TDM PW operating with a degree of loss that could result in congestion-related problems is also operating with a degree of loss that results in an unacceptable TDM service. For that reason, the document suggests that a managed CB that shuts down a PW when it persistently fails to deliver acceptable TDM service is a useful means for addressing these congestion concerns. (See Appendix A of [RFC7893] for further discussion.)

対照的に、非弾性PWは送信を調整しないため、非弾性PW（例：固定帯域幅時分割多重、TDM [RFC4553] [RFC5086] [RFC5087]）は、輻輳応答トラフィックに害を及ぼしたり、過度の輻輳の一因となる可能性があります。混雑に応じて料金。 [RFC7893]はTDM PWを分析しますが、輻輳関連の問題を引き起こす可能性のあるある程度の損失で動作しているTDM PWも、許容できないTDMサービスをもたらす程度の損失で動作しているという最初の結論があります。そのため、このドキュメントでは、許容可能なTDMサービスを継続的に提供できない場合にPWをシャットダウンするマネージドCBが、これらの輻輳問題に対処するための有用な手段であることを示唆しています。（詳細については、[RFC7893]の付録Aをご覧ください）。

6. Examples in Which CBs May Not Be Needed

6. CBが不要な例

A CB is not required for a single congestion-controlled flow using TCP, SCTP, TFRC, etc. In these cases, the congestion control methods are already designed to prevent persistent excessive congestion.

TCP、SCTP、TFRCなどを使用する単一の輻輳制御フローでは、CBは必要ありません。これらの場合、輻輳制御方法は、永続的な過度の輻輳を防ぐようにすでに設計されています。

6.1. CBs over Pre-provisioned Capacity

6.1. 事前にプロビジョニングされた容量を超えるCB

One common question is whether a CB is needed when a tunnel is deployed in a private network with pre-provisioned capacity.

よくある質問の1つは、容量が事前にプロビジョニングされたプライベートネットワークにトンネルが展開されている場合にCBが必要かどうかです。

In this case, compliant traffic that does not exceed the provisioned capacity ought not to result in persistent congestion. A CB will hence only be triggered when there is noncompliant traffic. It could be argued that this event ought never to happen -- but it could also be argued that the CB equally ought never to be triggered. If a CB were to be implemented, it will provide an appropriate response, if persistent congestion occurs in an operational network.

この場合、プロビジョニングされた容量を超えない準拠トラフィックが原因で永続的な輻輳が発生することはありません。したがって、CBは、非準拠のトラフィックがある場合にのみトリガーされます。このイベントが発生してはならないと主張することもできますが、CBが同様にトリガーされるべきではないと主張することもできます。 CBが実装される場合、運用ネットワークで持続的な輻輳が発生した場合、適切な対応が提供されます。

Implementing a CB will not reduce the performance of the flows, but in the event that persistent excessive congestion occurs, it protects network traffic that shares network capacity with these flows. It also protects network traffic from a failure when CB traffic is (re)routed to cause additional network load on a non-pre-provisioned path.

CBを実装してもフローのパフォーマンスは低下しませんが、永続的な過度の輻輳が発生した場合、これらのフローとネットワーク容量を共有するネットワークトラフィックが保護されます。また、CBトラフィックが（再）ルーティングされて、事前にプロビジョニングされていないパスに追加のネットワーク負荷がかかる場合に、ネットワークトラフィックを障害から保護します。

6.2. CBs with Tunnels Carrying Congestion-Controlled Traffic

6.2. 輻輳制御トラフィックを運ぶトンネルを備えたCB

IP-based traffic is generally assumed to be congestion controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Therefore, a question arises when people deploy a tunnel that is thought to carry only an aggregate of TCP traffic (or traffic using some other congestion control method): Is there an advantage in this case in using a CB?

IPベースのトラフィックは一般に輻輳制御されていると想定されます。つまり、送信元でIPベースのトラフィックを生成するトランスポートプロトコルは、パス上の輻輳に対処するのに十分なメカニズムをすでに採用していると想定されます。したがって、TCPトラフィック（または他の輻輳制御方法を使用するトラフィック）の集約のみを伝送すると考えられるトンネルを人々が配備する場合、問題が発生します。この場合、CBを使用することには利点がありますか？

TCP (and SCTP) traffic in a tunnel is expected to reduce the transmission rate when network congestion is detected. Other transports (e.g., using UDP) can employ mechanisms that are sufficient to address congestion on the path [RFC8085]. However, even if the individual flows sharing a tunnel each implement a congestion control mechanism, and individually reduce their transmission rate when network congestion is detected, the overall traffic resulting from the aggregate of the flows does not necessarily avoid persistent congestion. For instance, most congestion control mechanisms require long-lived flows to react to reduce the rate of a flow. An aggregate of many short flows could result in many flows terminating before they experience congestion.

トンネル内のTCP（およびSCTP）トラフィックは、ネットワークの輻輳が検出されたときに伝送速度を低下させることが予想されます。他のトランスポート（UDPを使用するなど）は、パス上の輻輳に対処するのに十分なメカニズムを採用できます[RFC8085]。ただし、トンネルを共有する個々のフローがそれぞれ輻輳制御メカニズムを実装し、ネットワークの輻輳が検出されたときにそれらの伝送速度を個別に低下させたとしても、フローの集約から生じる全体的なトラフィックは必ずしも持続的な輻輳を回避するとは限りません。たとえば、ほとんどの輻輳制御メカニズムでは、フローのレートを下げるために反応するために、長寿命のフローが必要です。多くの短いフローの集約により、多くのフローが輻輳する前に終了する可能性があります。

It is also often impossible for a tunnel service provider to know that the tunnel only contains congestion-controlled traffic (e.g., Inspecting packet headers might not be possible). Some IP-based applications might not implement adequate mechanisms to address congestion. The important thing to note is that if the aggregate of the traffic does not result in persistent excessive congestion (impacting other flows), then the CB will not trigger. This is the expected case in this context -- so implementing a CB ought not to reduce performance of the tunnel, but in the event that persistent excessive congestion occurs, the CB protects other network traffic that shares capacity with the tunnel traffic.

また、トンネルサービスプロバイダーは、トンネルに輻輳が制御されたトラフィックのみが含まれていることを知ることもできません（たとえば、パケットヘッダーの検査ができない場合があります）。一部のIPベースのアプリケーションは、輻輳に対処するための適切なメカニズムを実装していない場合があります。注意すべき重要なことは、トラフィックの集約が永続的な過度の輻輳を引き起こさない場合（他のフローに影響を与える場合）、CBはトリガーされないということです。これは、このコンテキストで予想されるケースです。したがって、CBを実装してもトンネルのパフォーマンスは低下しませんが、永続的な過度の輻輳が発生した場合、CBは、トンネルトラフィックと容量を共有する他のネットワークトラフィックを保護します。

6.3. CBs with Unidirectional Traffic and No Control Path

6.3. 単方向トラフィックがあり、制御パスがないCB

A one-way forwarding path could have no associated communication path for sending control messages; therefore, it cannot be controlled using a CB (compare with Section 3.2.3).

一方向の転送パスには、制御メッセージを送信するための関連する通信パスがない場合があります。したがって、CBを使用して制御することはできません（セクション3.2.3と比較）。

A one-way service could be provided using a path with dedicated pre-provisioned capacity that is not shared with other elastic Internet flows (i.e., flows that vary their rate). A forwarding path could also be shared with other flows. One way to mitigate the impact of traffic on the other flows is to manage the traffic envelope by using ingress policing. Supporting this type of traffic in the general Internet requires operator monitoring to detect and respond to persistent excessive congestion.

一方向のサービスは、他の柔軟なインターネットフロー（つまり、レートが変化するフロー）と共有されていない専用の事前プロビジョニングされた容量を持つパスを使用して提供できます。転送パスは、他のフローと共有することもできます。他のフローへのトラフィックの影響を軽減する1つの方法は、入力ポリシングを使用してトラフィックエンベロープを管理することです。一般的なインターネットでこのタイプのトラフィックをサポートするには、継続的な過度の輻輳を検出して対応するためにオペレーターの監視が必要です。

7. Security Considerations

7. セキュリティに関する考慮事項

All CB mechanisms rely upon coordination between the ingress and egress meters and communication with the trigger function. This is usually achieved by passing network-control information (or protocol messages) across the network. Timely operation of a CB depends on the choice of measurement period. If the receiver has an interval that is overly long, then the responsiveness of the CB decreases. This impacts the ability of the CB to detect and react to congestion. If the interval is too short, the CB could trigger prematurely resulting in insufficient time for other mechanisms to act and potentially resulting in unnecessary disruption to the service.

すべてのCBメカニズムは、入力メーターと出力メーター間の調整とトリガー機能との通信に依存しています。これは通常、ネットワークを介してネットワーク制御情報（またはプロトコルメッセージ）を渡すことによって実現されます。 CBのタイムリーな操作は、測定期間の選択に依存します。レシーバーの間隔が長すぎると、CBの応答性が低下します。これは、CBが輻輳を検出して対応する能力に影響を与えます。間隔が短すぎると、CBが早期にトリガーされ、他のメカニズムが動作するための時間が不十分になり、サービスが不必要に中断される可能性があります。

A CB could potentially be exploited by an attacker to mount a Denial-of-Service (DoS) attack against the traffic being controlled by the CB. Therefore, mechanisms need to be implemented to prevent attacks on the network-control information that would result in DoS.

攻撃者がCBを悪用して、CBによって制御されているトラフィックに対してサービス拒否（DoS）攻撃を仕掛ける可能性があります。したがって、DoSを引き起こすネットワーク制御情報への攻撃を防ぐためのメカニズムを実装する必要があります。

The authenticity of the source and integrity of the control messages (measurements and triggers) MUST be protected from off-path attacks. Without protection, it could be trivial for an attacker to inject fake or modified control/measurement messages (e.g., indicating high packet loss rates) causing a CB to trigger and therefore to mount a DoS attack that disrupts a flow.

発信元の信頼性と制御メッセージ（測定値とトリガー）の整合性は、オフパス攻撃から保護する必要があります。保護がなければ、攻撃者が偽のまたは変更された制御/測定メッセージ（たとえば、高いパケット損失率を示す）を注入してCBをトリガーし、フローを妨害するDoS攻撃を開始することは簡単です。

Simple protection can be provided by using a randomized source port, or equivalent field in the packet header (such as the RTP SSRC value and the RTP sequence number) expected not to be known to an off-path attacker. Stronger protection can be achieved using a secure authentication protocol to mitigate this concern.

ランダムな送信元ポート、またはオフパスの攻撃者に知られていないと予想されるパケットヘッダー内の同等のフィールド（RTP SSRC値やRTPシーケンス番号など）を使用することで、単純な保護を提供できます。安全な認証プロトコルを使用してより強力な保護を実現し、この問題を軽減できます。

An attack on the control messages is relatively easy for an attacker on the control path when the messages are neither encrypted nor authenticated. Use of a cryptographic authentication mechanism for all control/measurement messages is RECOMMENDED to mitigate this concern, and would also provide protection from off-path attacks. There is a design trade-off between the cost of introducing cryptographic security for control messages and the desire to protect control communication. For some deployment scenarios, the value of additional protection from DoS attacks will therefore lead to a requirement to authenticate all control messages.

制御メッセージへの攻撃は、メッセージが暗号化も認証もされていない場合、制御パス上の攻撃者にとって比較的簡単です。すべての制御/測定メッセージに暗号化認証メカニズムを使用することは、この懸念を軽減するために推奨され、オフパス攻撃からの保護も提供します。制御メッセージに暗号セキュリティを導入するコストと、制御通信を保護したいという要望の間には、設計上のトレードオフがあります。したがって、一部の導入シナリオでは、DoS攻撃に対する追加の保護の価値により、すべての制御メッセージを認証する必要があります。

Transmission of network-control messages consumes network capacity. This control traffic needs to be considered in the design of a CB and could potentially add to network congestion. If this traffic is sent over a shared path, it is RECOMMENDED that this control traffic be prioritized to reduce the probability of loss under congestion. Control traffic also needs to be considered when provisioning a network that uses a CB.

ネットワーク制御メッセージの送信は、ネットワーク容量を消費します。この制御トラフィックは、CBの設計で考慮する必要があり、ネットワークの輻輳を追加する可能性があります。このトラフィックが共有パスを介して送信される場合、この制御トラフィックを優先して、輻輳下での損失の可能性を減らすことをお勧めします。 CBを使用するネットワークをプロビジョニングするときは、制御トラフィックも考慮する必要があります。

The CB MUST be designed to be robust to packet loss that can also be experienced during congestion/overload. Loss of control messages could be a side-effect of a congested network, but it also could arise from other causes Section 4.

CBは、輻輳/過負荷時にも発生する可能性があるパケット損失に対して堅牢になるように設計する必要があります。制御メッセージの喪失は、ネットワークの混雑の副作用である可能性がありますが、セクション4の他の原因からも発生する可能性があります。

The security implications depend on the design of the mechanisms, the type of traffic being controlled and the intended deployment scenario. Each design of a CB MUST therefore evaluate whether the particular CB mechanism has new security implications.

セキュリティへの影響は、メカニズムの設計、制御されるトラフィックのタイプ、および目的の展開シナリオによって異なります。したがって、CBの設計ごとに、特定のCBメカニズムに新しいセキュリティの影響があるかどうかを評価する必要があります。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.

[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.

[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<http://www.rfc-editor.org / info / rfc8085>。

8.2. Informative References

8.2. 参考引用

[CONGESTION-FEEDBACK] Wei, X., Zhu, L., and L. Deng, "Tunnel Congestion Feedback", Work in Progress, draft-ietf-tsvwg-tunnel-congestion-feedback-04, January 2017.

[CONGESTION-FEEDBACK] Wei、X.、Zhu、L。、およびL. Deng、「トンネル輻輳フィードバック」、進行中の作業、draft-ietf-tsvwg-tunnel-congestion-feedback-04、2017年1月。

[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM Symposium proceedings on Communications architectures and protocols, August 1988.

[Jacobson88] Jacobson、V.、「輻輳回避と制御」、通信アーキテクチャとプロトコルに関するSIGCOMMシンポジウム議事録、1988年8月。

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.

[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、1989年8月、<http://www.rfc-editor.org/info/rfc1112>。

[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, <http://www.rfc-editor.org/info/rfc2309>.

[RFC2309]ブレーデン、B。、クラーク、D。、クロウクロフト、J。、デイビー、B。、ディアリング、S。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、 C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、DOI 10.17487 / RFC2309、4月1998、<http://www.rfc-editor.org/info/rfc2309>。

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.

[RFC2914] Floyd、S。、「Congestion Control Principles」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<http://www.rfc-editor.org/info/rfc2914>。

[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.

[RFC3985]ブライアント、S。、エド。およびP. Pate、編、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<http://www.rfc-editor.org/info/rfc3985 >。

[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <http://www.rfc-editor.org/info/rfc4448>.

[RFC4448] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、DOI 10.17487 / RFC4448、April 2006 、<http://www.rfc-editor.org/info/rfc4448>。

[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, <http://www.rfc-editor.org/info/rfc4553>.

[RFC4553] Vainshtein、A.、Ed。とYJ。スタイン編、「構造にとらわれない時分割多重（TDM）over Packet（SAToP）」、RFC 4553、DOI 10.17487 / RFC4553、2006年6月、<http://www.rfc-editor.org/info/rfc4553> 。

[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, <http://www.rfc-editor.org/info/rfc5086>.

[RFC5086] Vainshtein、A.、Ed。、Sasson、I.、Metz、E.、Frost、T.、and P. Pate、 "Structure-Aware Time Division Multiplexed（TDM）Circuit Emulation Service over Packet Switched Network（CESoPSN ） "、RFC 5086、DOI 10.17487 / RFC5086、2007年12月、<http://www.rfc-editor.org/info/rfc5086>。

[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10.17487/RFC5087, December 2007, <http://www.rfc-editor.org/info/rfc5087>.

[RFC5087]スタイン、Y（J）、シャショーア、R。、インスラー、R。、およびM.アナビ、「IPを介した時分割多重化（TDMoIP）」、RFC 5087、DOI 10.17487 / RFC5087、2007年12月、<http ：//www.rfc-editor.org/info/rfc5087>。

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.

[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<http： //www.rfc-editor.org/info/rfc5348>。

[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.

[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。

[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.

[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.

[RFC7761] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：プロトコル仕様（改訂）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<http://www.rfc-editor.org/info/rfc7761>。

[RFC7893] Stein, Y(J)., Black, D., and B. Briscoe, "Pseudowire Congestion Considerations", RFC 7893, DOI 10.17487/RFC7893, June 2016, <http://www.rfc-editor.org/info/rfc7893>.

[RFC7893]スタイン、Y（J）。、ブラック、D。、およびB.ブリスコ、「疑似配線輻輳の考慮事項」、RFC 7893、DOI 10.17487 / RFC7893、2016年6月、<http://www.rfc-editor.org / info / rfc7893>。

[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <http://www.rfc-editor.org/info/rfc8083>.

[RFC8083] Perkins、C。およびV. Singh、「Multimedia Congestion Control：Circuit Breaks for Unicast RTP Sessions」、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<http://www.rfc-editor.org/info / rfc8083>。

Acknowledgments

謝辞

There are many people who have discussed and described the issues that have motivated this document. Contributions and comments included: Lars Eggert, Colin Perkins, David Black, Matt Mathis, Andrew McGregor, Bob Briscoe, and Eliot Lear. This work was partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700).

このドキュメントの動機となった問題について議論し、説明した多くの人々がいます。寄稿とコメントが含まれています：Lars Eggert、Colin Perkins、David Black、Matt Mathis、Andrew McGregor、Bob Briscoe、Eliot Lear。この作業の一部は、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）を通じて、その第7フレームワークプログラムの下で欧州共同体から資金提供を受けました。

Author's Address

著者のアドレス

Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen, Scotland AB24 3UE United Kingdom

Godred Fairhurst University of Aberdeen School of Engineeringフレーザーノーブルビルディングアバディーン、スコットランドAB24 3UEイギリス

   Email: gorry@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk