[要約] RFC 7767は、Port Control Protocol（PCP）を使用してアプリケーションがチェックポイントを開始するための方法を提供します。目的は、ネットワーク上でのアプリケーションの状態の保存と復元を容易にすることです。
Independent Submission S. Vinapamula
Request for Comments: 7767 Juniper Networks
Category: Informational S. Sivakumar
ISSN: 2070-1721 Cisco Systems
M. Boucadair
Orange
T. Reddy
Cisco
February 2016
Application-Initiated Check-Pointing via the Port Control Protocol (PCP)
ポート制御プロトコル（PCP）を介したアプリケーション起動チェックポイント
Abstract
概要
This document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.
このドキュメントでは、ネットワーク障害からどの接続を保護する必要があるかを、ポート制御プロトコル（PCP）を介してホストが示すメカニズムを指定します。これらの接続は、ネットワーク側で有効になっている高可用性メカニズムの影響を受けます。
This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed.
このアプローチでは、アプリケーションやユーザーが機密接続について、ネットワーク側で有効にしてどの接続をチェックポイントにするかを推測できるヒューリスティックよりも可視性が高いと想定しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7767.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7767で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Issues with the Existing Implementations . . . . . . . . . . 4
3. CHECKPOINT_REQUIRED PCP Option . . . . . . . . . . . . . . . 4
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Additional Considerations . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
The risk of Internet service disruption is critical in service providers and enterprise networking environments. Such a risk is often mitigated with the introduction of active/backup systems. Such designs not only contribute to minimize the risk of service disruption, but also facilitate maintenance operations (e.g., hitless hardware or software upgrades).
インターネットサービスの中断のリスクは、サービスプロバイダーおよびエンタープライズネットワーキング環境で重要です。このようなリスクは、多くの場合、アクティブ/バックアップシステムを導入することで軽減されます。このような設計は、サービス中断のリスクを最小限に抑えるだけでなく、メンテナンス操作（ハードウェアやソフトウェアの無停止アップグレードなど）も容易にします。
In addition, the nature of some connections leads to the establishment and the maintenance of connection-specific states by some of the network functions invoked when the connection is established. During active/backup failover in case of a network failure, the said states need to be check-pointed by the backup system. Additional issues are discussed in Section 2.
さらに、一部の接続の性質により、接続が確立されたときに呼び出される一部のネットワーク機能によって、接続固有の状態が確立および維持されます。ネットワーク障害が発生した場合のアクティブ/バックアップフェイルオーバー中に、上記の状態はバックアップシステムによってチェックポイントされる必要があります。追加の問題については、セクション2で説明します。
Heuristics based on the protocol, mapping lifetime, etc., are used in the network to elect which connections need to be check-pointed (e.g., by means of high-availability (HA) techniques). This document advocates for an application-initiated approach that would allow applications and/or users to signal to the network which of their connections are critical.
プロトコル、マッピングの有効期間などに基づくヒューリスティックがネットワークで使用され、どの接続をチェックポイントする必要があるかを選択します（たとえば、高可用性（HA）技術を使用して）。このドキュメントは、アプリケーションまたはユーザー、あるいはその両方が、どの接続が重要であるかをネットワークに通知できるようにする、アプリケーション起動のアプローチを提唱しています。
Within this document, "check-pointing" refers to a process of state replication and synchronization between active and backup PCP-controlled devices. When the active PCP-controlled device fails, the backup PCP-controlled device will take over all the existing established sessions that were check-pointed. This process is transparent to internal hosts.
このドキュメントでは、「チェックポイント」とは、アクティブなPCP制御デバイスとバックアップPCP制御デバイス間の状態の複製と同期のプロセスを指します。アクティブなPCP制御のデバイスに障害が発生すると、バックアップPCP制御のデバイスが、チェックポイントされた既存の確立済みセッションをすべて引き継ぎます。このプロセスは、内部ホストに対して透過的です。
This document specifies how PCP [RFC6887] can be extended to indicate which connection should be check-pointed for high availability (Section 3). A set of use cases are provided for illustrative purposes in Section 4. This document does not make any assumptions about the PCP-controlled device that will process the PCP-formatted signaling information from PCP clients. These devices are likely to be flow aware.
このドキュメントでは、PCP [RFC6887]を拡張して、高可用性を実現するためにどの接続にチェックポイントを設定する必要があるかを示します（セクション3）。一連の使用例は、セクション4で説明のために提供されています。このドキュメントでは、PCPクライアントからのPCP形式のシグナリング情報を処理するPCP制御デバイスについての想定は行いません。これらのデバイスは、フローに対応している可能性があります。
The approach in this document is aligned with the networking trends advocating for open network APIs to interact with applications/ services (e.g., [RFC7149]). For instance, the decision-making process about policy on the network side will be enriched with information provided by applications using PCP.
このドキュメントのアプローチは、オープンネットワークAPIがアプリケーション/サービスとやり取りすることを推奨するネットワーキングトレンドに沿ったものです（[RFC7149]など）。たとえば、ネットワーク側のポリシーに関する意思決定プロセスは、PCPを使用するアプリケーションによって提供される情報で強化されます。
The CHECKPOINT_REQUIRED PCP option (Section 3) is defined in the "Specification Required" range (see Section 6). In order to be assigned a code point in that range, a permanent publication is required as per Section 4.1 of [RFC5226]. Publication of an RFC is an ideal means of achieving this requirement and also to ease interoperability.
CHECKPOINT_REQUIRED PCPオプション（セクション3）は、「必要な仕様」の範囲で定義されています（セクション6を参照）。その範囲のコードポイントを割り当てるには、[RFC5226]のセクション4.1に従って永続的な公開が必要です。 RFCの公開は、この要件を達成し、相互運用性を容易にする理想的な手段です。
Note, this work was presented to the Port Control Protocol (PCP) WG, but there was no consensus to define this option in the "Standards Action" range despite positive feedback that was received from the working group. Technical comments that were received during PCP meetings and those received on the mailing list were addressed.
この作業はPort Control Protocol（PCP）WGに提示されましたが、ワーキンググループから受け取った肯定的なフィードバックにもかかわらず、このオプションを「Standards Action」の範囲で定義することに合意はありませんでした。 PCPミーティング中に受け取ったテクニカルコメントとメーリングリストで受け取ったコメントへの対処が行われました。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Regardless of the selected technology or design like HA-based designs, reliably securing connections is expensive in terms of memory, CPU usage, and other resources. Also, check-pointing may not be required for all connections, as all connections may not be critical. But, this leaves a challenge to identify what connections to check-point.
選択したテクノロジーやHAベースの設計などの設計に関係なく、接続を確実に保護するには、メモリ、CPU使用率、およびその他のリソースの点でコストがかかります。また、すべての接続が重要であるとは限らないため、すべての接続にチェックポイントが必要なわけではありません。しかし、これはチェックポイントへの接続を特定するのに課題を残します。
Typically, this is addressed by identifying long-lived connections and check-pointing the state of only those connections that lived long enough, to the backup for service continuity.
通常、これは、長期間の接続を識別し、サービスの継続性を確保するために、十分に長く持続した接続のみの状態をバックアップにチェックポイントすることで対処されます。
However, check-pointing long-lived connections raises the following issues:
ただし、長期間有効な接続をチェックポイントすると、次の問題が発生します。
1. It is hard for a network to identify (or guess) which connection is (business) critical. This characterization is often customer-specific: a flow can be sensitive for a User #1, while it is not for another User #2. Furthermore, this characterization can vary over time: a flow can be sensitive during hour X, while it is not during other times.
1. ネットワークが、どの接続が（ビジネス）クリティカルであるかを特定（または推測）することは困難です。この特徴付けは、多くの場合、お客様固有のものです。フローは、ユーザー＃1には影響されますが、別のユーザー＃2には影響されません。さらに、この特性は時間の経過とともに変化する可能性があります。フローは、時間Xの間は敏感であり、他の時間の間はそうではありません。
2. Heuristics are not deterministic.
2. ヒューリスティックは確定的ではありません。
3. A potentially long-lived connection may experience disruption upon failure of the active system, but before it is check-pointed.
3. 潜在的に長命の接続では、アクティブなシステムの障害時に、チェックポイントされる前に中断が発生する可能性があります。
4. A connection may not be long-lived but it may be critical, e.g., for Voice over IP (VoIP) conversations.
4. 接続は長寿命ではないかもしれませんが、たとえば、Voice over IP（VoIP）会話では重要な場合があります。
5. Likewise, not all long-lived connections are deemed critical: for example, connections that pertain to free Internet services are usually considered not critical compared to the equivalent connections for paid services. Only the latter need to be check-pointed.
5. 同様に、すべての長期接続がクリティカルであるとは限りません。たとえば、無料のインターネットサービスに関連する接続は、有料サービスの同等の接続と比較して、通常はクリティカルではないと見なされます。後者のみをチェックポイントする必要があります。
The solution is based on the assumption that an application or user is the best judge of which of its connections are critical.
ソリューションは、アプリケーションまたはユーザーが、どの接続が重要であるかを最もよく判断するという仮定に基づいています。
An application or user may explicitly identify the connections that need to be check-pointed by means of a PCP client, using the CHECKPOINT_REQUIRED option as described in Figure 1.
アプリケーションまたはユーザーは、図1で説明されているCHECKPOINT_REQUIREDオプションを使用して、PCPクライアントによってチェックポイントが必要な接続を明示的に識別できます。
The entry to be backed up is indicated by the content of a MAP or PEER message.
バックアップされるエントリは、MAPまたはPEERメッセージの内容によって示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Code=192| Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Name: CHECKPOINT_REQUIRED Number: 192 Purpose: Indicate if an entry needs to be check-pointed. Valid for Opcodes: MAP, PEER Length: 0. May appear in: Request and response. Maximum occurrences: 1.
オプション名：CHECKPOINT_REQUIRED番号：192目的：エントリをチェックポイントする必要があるかどうかを示します。オペコードに有効：MAP、PEER長さ：0。表示される可能性があるもの：要求と応答。最大発生回数：1。
Figure 1: CHECKPOINT_REQUIRED PCP Option
図1：CHECKPOINT_REQUIRED PCPオプション
The description of the fields is as follows:
フィールドの説明は次のとおりです。
o Option Code: 192 (see Section 6).
o オプションコード：192（セクション6を参照）。
o Reserved: This field is initialized as specified in Section 7.3 of [RFC6887].
o 予約済み：このフィールドは、[RFC6887]のセクション7.3で指定されているように初期化されます。
o Option Length: 0. This means no data is included in the option.
o オプションの長さ：0。これは、オプションにデータが含まれていないことを意味します。
An application or user can take advantage of this PCP option to explicitly indicate which of the connections need to be check-pointed and should not be disrupted. The processing of this option by the PCP server will then yield the check-pointing of the corresponding states by the relevant devices or functions dynamically controlled by the PCP server.
アプリケーションまたはユーザーは、このPCPオプションを利用して、どの接続をチェックポイントする必要があり、中断してはならないかを明示的に示すことができます。 PCPサーバーによるこのオプションの処理は、PCPサーバーによって動的に制御される関連デバイスまたは機能による対応する状態のチェックポイントを生成します。
Communication between application/user and PCP client is implementation specific.
アプリケーション/ユーザーとPCPクライアント間の通信は実装固有です。
Support of the CHECKPOINT_REQUIRED option by PCP servers and PCP clients is optional. This option (Code 192; see Figure 1) may be included in a PCP MAP or PEER request to indicate a connection is to be protected against network failures.
PCPサーバーおよびPCPクライアントによるCHECKPOINT_REQUIREDオプションのサポートはオプションです。このオプション（コード192、図1を参照）は、PCP MAPまたはPEER要求に含まれ、接続がネットワーク障害から保護されることを示します。
There is a risk that every PCP client may wish to check-point every connection; this can potentially load the system. Administration SHOULD restrict the number of connections that can be elected to be backed up and the rate of check-pointing per network attachment point (e.g., Customer Premises Equipment (CPE), host). To that aim, the PCP server should unambiguously identify the network attachment point a PCP client belongs to. For example, the PCP server may rely on the PCP identity [RFC7652], the assigned prefix to a CPE or host, the subscriber-mask [PREFIX-BINDING], or other identification means.
すべてのPCPクライアントがすべての接続をチェックポイントする可能性があるというリスクがあります。これにより、システムに負荷がかかる可能性があります。管理は、バックアップ対象として選択できる接続の数と、ネットワーク接続ポイント（顧客宅内機器（CPE）、ホストなど）ごとのチェックポイントの頻度を制限する必要があります（SHOULD）。そのために、PCPサーバーは、PCPクライアントが属するネットワーク接続ポイントを明確に識別する必要があります。たとえば、PCPサーバーは、PCP ID [RFC7652]、CPEまたはホストに割り当てられたプレフィックス、サブスクライバーマスク[PREFIX-BINDING]、または他の識別手段に依存する場合があります。
The PCP client includes a CHECKPOINT_REQUIRED option in a MAP or PEER request to signal that the corresponding mapping is to be protected.
PCPクライアントのMAPまたはPEER要求には、対応するマッピングが保護されることを通知するCHECKPOINT_REQUIREDオプションが含まれています。
If the PCP client does not receive a CHECKPOINT_REQUIRED option in response to a PCP request that enclosed the CHECKPOINT_REQUIRED option, this means that either the PCP server does not support the option, or the PCP server is configured to ignore the option, or the PCP server cannot satisfy the request expressed in this option (e.g., because of a lack of resources).
PCPクライアントがCHECKPOINT_REQUIREDオプションを含むPCP要求に応答してCHECKPOINT_REQUIREDオプションを受信しない場合、これは、PCPサーバーがオプションをサポートしていないか、PCPサーバーがオプションを無視するように構成されているか、PCPサーバーが構成されていることを意味しますこのオプションで表現された要求を満たすことができません（リソースの不足など）。
If the CHECKPOINT_REQUIRED option is not included in the PCP client request, the PCP server MUST NOT include the CHECKPOINT_REQUIRED option in the associated response.
CHECKPOINT_REQUIREDオプションがPCPクライアント要求に含まれていない場合、PCPサーバーは関連する応答にCHECKPOINT_REQUIREDオプションを含めてはなりません（MUST NOT）。
When the PCP server receives a CHECKPOINT_REQUIRED option, the PCP server checks if it can honor this request depending on whether resources are available for check-pointing. If there are no resources available for check-pointing, but there are resources available to honor the MAP or PEER request, a response is sent back to the PCP client without including the CHECKPOINT_REQUIRED option (i.e., the request is processed as any MAP or PEER request that does not convey a CHECKPOINT_REQUIRED option). If check-pointing resources are still available and the quota for this PCP client has not been reached, the PCP server tags the corresponding entry as eligible to the HA mechanism and sends back the CHECKPOINT_REQUIRED option in the positive answer to the PCP client.
PCPサーバーは、CHECKPOINT_REQUIREDオプションを受信すると、リソースがチェックポイントに使用できるかどうかに応じて、この要求を受け入れることができるかどうかを確認します。チェックポイントに使用できるリソースはないが、MAPまたはPEER要求を受け入れるために使用できるリソースがある場合、CHECKPOINT_REQUIREDオプションを含めずに応答がPCPクライアントに送り返されます（つまり、要求はMAPまたはPEERとして処理されます） CHECKPOINT_REQUIREDオプションを伝えないリクエスト）。チェックポイントリソースがまだ利用可能で、このPCPクライアントの割り当てに達していない場合、PCPサーバーは対応するエントリにHAメカニズムに適格であるとタグ付けし、肯定応答のCHECKPOINT_REQUIREDオプションをPCPクライアントに送り返します。
To update the check-pointing behavior of a mapping maintained by the PCP server, the PCP client generates a PCP MAP or PEER renewal request that includes a CHECKPOINT_REQUIRED option to indicate this mapping has to be check-pointed or that doesn't include a CHECKPOINT_REQUIRED option to indicate this mapping does not need be check-pointed anymore. Upon receipt of the PCP request, the PCP server proceeds with the same operations to validate a MAP or PEER request to update an existing mapping. If validation checks are passed, the PCP server updates the check-point flag associated with that mapping accordingly (i.e., it is set if a CHECKPOINT_REQUIRED option was included in the update request or it is cleared if no CHECKPOINT_REQUIRED option was included), and the PCP server returns the response to the PCP client accordingly.
PCPサーバーによって維持されるマッピングのチェックポイント動作を更新するために、PCPクライアントは、このマッピングをチェックポイントする必要があるか、またはCHECKPOINT_REQUIREDを含まないことを示すCHECKPOINT_REQUIREDオプションを含むPCP MAPまたはPEER更新要求を生成します。このマッピングをチェックポイントする必要がないことを示すオプション。 PCP要求を受信すると、PCPサーバーは同じ操作を続行して、MAPまたはPEER要求を検証し、既存のマッピングを更新します。検証チェックに合格すると、PCPサーバーはそのマッピングに関連付けられたチェックポイントフラグを適宜更新します（つまり、更新リクエストにCHECKPOINT_REQUIREDオプションが含まれていた場合に設定され、CHECKPOINT_REQUIREDオプションが含まれていなかった場合はクリアされます）。 PCPサーバーは、それに応じてPCPクライアントに応答を返します。
What information to check-point and how to check-point are outside the scope of this document and are left for implementations. Also, the mechanism for users or applications to indicate check-pointing in a PCP request may be automatic, semiautomatic, or require human intervention. This behavior is also left for application implementations. For managed CPEs, a service provider may influence what connections are to be check-pointed.
チェックポイントする情報とチェックポイントする方法は、このドキュメントの範囲外であり、実装に残します。また、ユーザーまたはアプリケーションがPCP要求のチェックポイントを示すメカニズムは、自動、半自動、または人間の介入が必要な場合があります。この動作は、アプリケーションの実装にも任されています。マネージドCPEの場合、サービスプロバイダーがチェックポイントの対象となる接続に影響を与える場合があります。
For honored requests, it is RECOMMENDED to check-point state on backup before a response is sent to the PCP client.
受け入れられた要求の場合、PCPクライアントに応答が送信される前に、バックアップ時に状態をチェックポイントすることをお勧めします。
Below are provided some examples for illustrative purposes:
以下に、説明のためにいくつかの例を示します。
Example 1: Consider a streaming service such as live TV broadcasting, or any other media streaming, that supports check-pointing signaling functionality. Suppose this application is installed in three hosts A, B and C. For A, the application is critical and should not be interrupted, while for B it is not. While for C, only some programs are of interest. At the time of installing this application's software, corresponding preferences can be provisioned. When the application starts streaming:
例1：チェックポインティングシグナリング機能をサポートする、ライブTV放送やその他のメディアストリーミングなどのストリーミングサービスを検討します。このアプリケーションが3つのホストA、B、Cにインストールされているとします。Aの場合、アプリケーションは重要であり、中断されるべきではありませんが、Bの場合は中断されません。 Cの場合、関心があるのは一部のプログラムのみです。このアプリケーションのソフトウェアをインストールするときに、対応する設定をプロビジョニングできます。アプリケーションがストリーミングを開始すると：
* All the flows associated with the streaming application are critical for A. Limiting the number of flows to be backed up will ensure that host doesn't exceed the user's limit.
* ストリーミングアプリケーションに関連付けられているすべてのフローはAにとって重要です。バックアップするフローの数を制限すると、ホストがユーザーの制限を超えないようになります。
* For B, none of these flows are critical for check-pointing. The CHECKPOINT_REQUIRED option is not included in the PCP requests.
* Bの場合、これらのフローはいずれもチェックポイントにとって重要ではありません。 CHECKPOINT_REQUIREDオプションは、PCP要求に含まれていません。
* For C, the user is invited to interact with the application by means of a configuration option that is provided to dynamically select which streaming to check-point, based on the user's interest.
* Cの場合、ユーザーは、ユーザーの興味に基づいて、チェックポイントするストリーミングを動的に選択するために提供される構成オプションを使用して、アプリケーションと対話するように求められます。
Example 2: Consider a streaming service offered by a provider. Suppose three levels of subscriptions are offered by that provider, e.g., gold, silver, and bronze. To guarantee a certain level of quality of service for each subscription, policies are configured such that:
例2：プロバイダーが提供するストリーミングサービスを検討します。そのプロバイダーが3つのレベルのサブスクリプション（ゴールド、シルバー、ブロンズなど）を提供しているとします。サブスクリプションごとに一定レベルのサービス品質を保証するために、ポリシーは次のように構成されています。
* All flows associated with a gold subscription should be check-pointed.
* ゴールドサブスクリプションに関連付けられているすべてのフローは、チェックポイントする必要があります。
* Only some flows associated with a silver subscription are check-pointed.
* シルバーサブスクリプションに関連付けられている一部のフローのみがチェックポイントされます。
* None of the flows associated with a bronze subscription are check-pointed.
* ブロンズサブスクリプションに関連付けられているフローはチェックポイントされません。
When a user invokes the streaming service, he/she may fall into one of those buckets, and according to the configured policy, his/ her associated streaming flows are automatically check-pointed. Login credentials can be used as a trigger to determine the subscription level (and therefore the associated check-pointing behavior).
ユーザーがストリーミングサービスを呼び出すと、ユーザーはこれらのバケットの1つに分類される可能性があり、構成されたポリシーに従って、ユーザーに関連付けられたストリーミングフローは自動的にチェックポイントされます。ログイン資格情報をトリガーとして使用して、サブスクリプションレベル（および関連するチェックポイント動作）を決定できます。
Example 3: Consider a VoIP application that is able to request that its flows be check-pointed. No matter what is configured by the user, some calls such as emergency calls should be check-pointed. The application has to identify such calls.
例3：フローのチェックポイントを要求できるVoIPアプリケーションを考えます。ユーザーの設定に関係なく、緊急コールなどの一部のコールはチェックポイントする必要があります。アプリケーションはそのような呼び出しを識別する必要があります。
Example 4: In the context of an enterprise network, applications are customized by the administrator. Instructions about whether a CHECKPOINT_REQUIRED option is to be included are determined by the administrator. Only the subset of applications identified by the administrator will make use of this option in conformance with the enterprise network's management policies. Any misbehavior can be considered as abuse.
例4：企業ネットワークのコンテキストでは、アプリケーションは管理者によってカスタマイズされます。 CHECKPOINT_REQUIREDオプションを含めるかどうかに関する指示は、管理者が決定します。管理者によって識別されたアプリケーションのサブセットのみが、エンタープライズネットワークの管理ポリシーに準拠してこのオプションを使用します。不正行為は乱用と見なすことができます。
In order to prevent every application from including a CHECKPOINT_REQUIRED option in its PCP requests, the following items are assumed:
すべてのアプリケーションがPCP要求にCHECKPOINT_REQUIREDオプションを含めないようにするために、次の項目が想定されています。
o Applications may be delivered with some default settings for check-pointing, and these settings should be programmable by end user.
o アプリケーションは、チェックポイント用のいくつかのデフォルト設定で提供される場合があり、これらの設定はエンドユーザーがプログラムできる必要があります。
o Exposing and enforcing these settings is application specific.
o これらの設定の公開と適用はアプリケーション固有です。
o The end user may customize these settings based on the requirements.
o エンドユーザーは、要件に基づいてこれらの設定をカスタマイズできます。
PCP-related security considerations are discussed in [RFC6887].
PCP関連のセキュリティの考慮事項は、[RFC6887]で説明されています。
The CHECKPOINT_REQUIRED option can be used by an attacker to identify critical flows; this is sensitive from a privacy standpoint. Also, an attacker can cause critical flows to not be check-pointed by stripping the CHECKPOINT_REQUIRED option or by consuming the quota by adding the option to other flows.
CHECKPOINT_REQUIREDオプションは、重要なフローを識別するために攻撃者が使用できます。これはプライバシーの観点から敏感です。また、攻撃者は、CHECKPOINT_REQUIREDオプションを削除するか、他のフローにオプションを追加してクォータを消費することにより、重要なフローがチェックポイントされないようにすることができます。
These two issues can be mitigated if the network on which the PCP messages are to be sent is fully trusted. Means to defend against attackers who can intercept packets between the PCP server and the PCP client should be enabled. In some deployments, access control lists (ACLs) can be installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications between trusted PCP elements. If the networking environment between the PCP client and the PCP server is not secure, PCP authentication [RFC7652] MUST be enabled.
これら2つの問題は、PCPメッセージが送信されるネットワークが完全に信頼されている場合に軽減できます。 PCPサーバーとPCPクライアント間のパケットを傍受できる攻撃者を防御する手段を有効にする必要があります。一部の展開では、アクセス制御リスト（ACL）をPCPクライアント、PCPサーバー、およびそれらの間のネットワークにインストールできるため、これらのACLは信頼できるPCP要素間の通信のみを許可します。 PCPクライアントとPCPサーバー間のネットワーク環境が安全でない場合、PCP認証[RFC7652]を有効にする必要があります。
A network device can always override the end-user signaling, i.e., what is signaled by the PCP client, if the instructions conflict with the network policies.
指示がネットワークポリシーと競合する場合、ネットワークデバイスは常にエンドユーザーシグナリング、つまり、PCPクライアントによってシグナリングされるものをオーバーライドできます。
The following PCP Option Code has been allocated in the "Specification Required" range of the "PCP Options" registry (http://www.iana.org/assignments/pcp-parameters):
次のPCPオプションコードは、「PCPオプション」レジストリ（http://www.iana.org/assignments/pcp-parameters）の「Specification Required」の範囲に割り当てられています。
192 CHECKPOINT_REQUIRED (see Section 3.1)
192 CHECKPOINT_REQUIRED（セクション3.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>。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、DOI 10.17487 / RFC6887、2013年4月、<http://www.rfc-editor.org/info/rfc6887>。
[RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port Control Protocol (PCP) Authentication Mechanism", RFC 7652, DOI 10.17487/RFC7652, September 2015, <http://www.rfc-editor.org/info/rfc7652>.
[RFC7652] Cullen、M.、Hartman、S.、Zhang、D。、およびT. Reddy、「Port Control Protocol（PCP）Authentication Mechanism」、RFC 7652、DOI 10.17487 / RFC7652、2015年9月、<http：// www.rfc-editor.org/info/rfc7652>。
[PREFIX-BINDING] Vinapamula, S. and M. Boucadair, "Recommendations for Prefix Binding in the Softwire DS-Lite Context", Work in Progress, draft-vinapamula-softwire-dslite-prefix-binding-12, October 2015.
[プレフィックスバインディング] Vinapamula、S。およびM. Boucadair、「Softwire DS-Liteコンテキストでのプレフィックスバインディングの推奨事項」、作業中、draft-vinapamula-softwire-dslite-prefix-binding-12、2015年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <http://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M。およびC. Jacquenet、「Software-Defined Networking：A Perspective from a Service Provider Environment」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<http：//www.rfc-editor。 org / info / rfc7149>。
It was tempting to include additional fields in the option but this would lead to a more complex design that is not justified. For example, we considered the following.
オプションに追加のフィールドを含めるのは魅力的でしたが、これは正当化されないより複雑な設計につながるでしょう。たとえば、次のことを検討しました。
o Define a dedicated field to indicate a priority level. This priority is intended to be used by the PCP server as a hint when processing a request with a CHECKPOINT_REQUIRED option. Nevertheless, an application may systematically choose to set the priority level to the highest value so that it increases its chance to be serviced!
o 優先レベルを示す専用フィールドを定義します。この優先順位は、CHECKPOINT_REQUIREDオプションを使用して要求を処理するときのヒントとしてPCPサーバーによって使用されることを目的としています。それにもかかわらず、アプリケーションは、サービスを受ける可能性を高めるために、優先度レベルを最高値に設定することを体系的に選択する場合があります。
o Return a more granular failure error code to the requesting PCP client. However, this would require extra processing at both the PCP client and server sides for handling the various error codes without any guarantee that the PCP client would have its mappings check-pointed.
o より詳細な障害エラーコードを要求側のPCPクライアントに返します。ただし、PCPクライアントのマッピングがチェックポイントされていることを保証せずに、さまざまなエラーコードを処理するには、PCPクライアントとサーバーの両方で追加の処理が必要になります。
Acknowledgments
謝辞
Thanks to Reinaldo Penno, Stuart Cheshire, Dave Thaler, Prashanth Patil, and Christian Jacquenet for their comments.
コメントを提供してくれたReinaldo Penno、Stuart Cheshire、Dave Thaler、Prashanth Patil、およびChristian Jacquenetに感謝します。
Authors' Addresses
著者のアドレス
Suresh Vinapamula Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 United States
Suresh Vinapamula Juniper Networks 1194 North Mathilda Avenue Sunnyvale、CA 94089アメリカ合衆国
Phone: +1 408 936 5441
Email: sureshk@juniper.net
Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, NC 27760 United States
Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park、NC 27760アメリカ合衆国
Phone: +1 919 392 5158
Email: ssenthil@cisco.com
Mohamed Boucadair Orange Rennes 35000 France
Mohamed Boucadair Orange Rennes 35000フランス
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems、Inc. Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 India
Email: tireddy@cisco.com