[要約] RFC 8992は、大規模ネットワークにおける自律的なIPv6エッジプレフィックス管理に関するものです。この文書の目的は、ネットワークのスケーラビリティと管理の自動化を向上させる方法を提供することにあります。利用場面としては、ISPや大企業のデータセンターなど、広範囲にわたるネットワーク環境での適用が想定されます。
From: draft-ietf-anima-prefix-management-07 Informational
IPR declarations
Errata exist
Internet Engineering Task Force (IETF) S. Jiang, Ed.
Request for Comments: 8992 Huawei Technologies Co., Ltd
Category: Informational Z. Du
ISSN: 2070-1721 China Mobile
B. Carpenter
Univ. of Auckland
Q. Sun
China Telecom
May 2021
Autonomic IPv6 Edge Prefix Management in Large-Scale Networks
大規模ネットワークにおけるオートノミックIPv6エッジプレフィックス管理
Abstract
概要
This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of this document is to use it for validation of the design of various components of the Autonomic Networking Infrastructure.
このドキュメントは、大規模ISPネットワークのエッジでIPv6プレフィックス管理のための2つの自律技術的な技術目標を定義し、拡張子はIPv4プレフィックスをサポートします。この文書の重要な目的は、自律型ネットワーキングインフラストラクチャのさまざまなコンポーネントの設計を検証するために使用することです。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8992.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8992で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Problem Statement
3.1. Intended User and Administrator Experience
3.2. Analysis of Parameters and Information Involved
3.2.1. Parameters Each Device Can Define for Itself
3.2.2. Information Needed from Network Operations
3.2.3. Comparison with Current Solutions
3.3. Interaction with Other Devices
3.3.1. Information Needed from Other Devices
3.3.2. Monitoring, Diagnostics, and Reporting
4. Autonomic Edge Prefix Management Solution
4.1. Behavior of a Device Requesting a Prefix
4.2. Behavior of a Device Providing a Prefix
4.3. Behavior after Successful Negotiation
4.4. Prefix Logging
5. Autonomic Prefix Management Objectives
5.1. Edge Prefix Objective Option
5.2. IPv4 Extension
6. Prefix Management Parameters
6.1. Example of Prefix Management Parameters
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Deployment Overview
A.1. Address and Prefix Management with DHCP
A.2. Prefix Management with ANI/GRASP
Acknowledgements
Authors' Addresses
The original purpose of this document was to validate the design of the Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows how the ANI can be applied to IP prefix delegation, and it outlines approaches to build a system to do this. A fully standardized solution would require more details, so this document is informational in nature.
この文書の元の目的は、現実的なユースケースのための自律技術ネットワーキングインフラストラクチャ（ANI）の設計を検証することでした。ANIをIPプレフィックス委任に適用できる方法を示し、これを行うシステムを構築するためのアプローチを概説します。完全に標準化された解決策はより多くの詳細を必要とするので、この文書は本質的に情報を表しています。
This document defines two autonomic technical objectives for IPv6 prefix management in large-scale networks, with an extension to support IPv4 prefixes. The background to Autonomic Networking is described in [RFC7575] and [RFC7576]. The GeneRic Autonomic Signaling Protocol (GRASP) is specified by [RFC8990] and can make use of the technical objectives to provide a solution for autonomic prefix management. An important purpose of the present document is to use it for validation of the design of GRASP and other components of the ANI as described in [RFC8993].
この文書は、大規模ネットワークでのIPv6プレフィックス管理用の2つの自律技術的な技術目標を定義し、拡張子はIPv4プレフィックスをサポートします。オートノミックネットワーキングの背景は[RFC7575]と[RFC7576]に説明されています。一般的な自律神経シグナリングプロトコル（GRASP）は[RFC8990]によって指定され、技術的な目的を利用して自律神秘的なプレフィックス管理のための解決策を提供することができます。本文書の重要な目的は、[RFC8993]に記載されているように、ANIの把握および他の構成要素の設計の検証のために使用することである。
This document is not a complete functional specification of an autonomic prefix management system, and it does not describe all detailed aspects of the GRASP objective parameters and Autonomic Service Agent (ASA) procedures necessary to build a complete system. Instead, it describes the architectural framework utilizing the components of the ANI, outlines the different deployment options and aspects, and defines GRASP objectives for use in building the system. It also provides some basic parameter examples.
この文書は、自律型プレフィックス管理システムの完全な機能仕様ではなく、完全なシステムを構築するのに必要な把握対象パラメータと自律サービスエージェント（ASA）手順のすべての詳細な側面を説明していません。代わりに、ANIのコンポーネントを利用するアーキテクチャフレームワークは、さまざまな展開オプションと側面の概要を説明し、システムの構築に使用するためのGRASP目標を定義します。また、基本的なパラメータの例も提供します。
This document is not intended to solve all cases of IPv6 prefix management. In fact, it assumes that the network's main infrastructure elements already have addresses and prefixes. This document is dedicated to how to make IPv6 prefix management at the edges of large-scale networks as autonomic as possible. It is specifically written for Internet Service Provider (ISP) networks. Although there are similarities between ISPs and large enterprise networks, the requirements for the two use cases differ. In any case, the scope of the solution is expected to be limited, like any Autonomic Network, to a single management domain.
この文書は、IPv6プレフィックス管理のすべてのケースを解決することを意図していません。実際、ネットワークの主インフラストラクチャ要素にはすでにアドレスとプレフィックスがあると仮定します。このドキュメントは、大規模ネットワークのエッジでできるだけ自律的なネットワークのエッジでIPv6プレフィックス管理をする方法専用です。これは具体的にはインターネットサービスプロバイダ（ISP）ネットワーク用に書かれています。ISPと大規模なエンタープライズネットワーク間に類似点がありますが、2つのユースケースの要件は異なります。いずれにせよ、解決策の範囲は、任意の自律型ネットワークと同様に、単一の管理ドメインに制限されると予想される。
However, the solution is designed in a general way. Its use for a broader scope than edge prefixes, including some or all infrastructure prefixes, is left for future discussion.
ただし、解決策は一般的な方法で設計されています。いくつかのインフラストラクチャプレフィックスを含むエッジプレフィックスよりも広い範囲の使用は、将来の議論のために残されています。
A complete solution has many aspects that are not discussed here. Once prefixes have been assigned to routers, they need to be communicated to the routing system as they are brought into use. Similarly, when prefixes are released, they need to be removed from the routing system. Different operators may have different policies regarding prefix lifetimes, and they may prefer to have centralized or distributed pools of spare prefixes. In an Autonomic Network, these are properties decided upon by the design of the relevant ASAs. The GRASP objectives are simply building blocks.
完全な解決策はここでは議論されていない多くの側面を持っています。プレフィックスがルータに割り当てられたら、それらが使用されたときにルーティングシステムに伝達される必要があります。同様に、プレフィックスが解放されると、それらをルーティングシステムから削除する必要があります。異なる演算子は、プレフィックスの寿命に関して異なるポリシーを持つことができ、それらは予備プレフィックスの集中型または分散プールを好むことができます。自律型ネットワークでは、これらは関連するASAの設計によって決定されたプロパティです。把握目的は単にブロックを構成することです。
A particular risk of distributed prefix allocation in large networks is that over time, it might lead to fragmentation of the address space and an undesirable increase in the size of the interior routing protocol tables. The extent of this risk depends on the algorithms and policies used by the ASAs. Mitigating this risk might even become an autonomic function in itself.
大規模ネットワークにおける分散プレフィックス割り当ての特定のリスクは、時間の経過とともに、アドレス空間の断片化と内部ルーティングプロトコルテーブルのサイズの望ましくない増加につながる可能性があります。このリスクの範囲は、ASASによって使用されるアルゴリズムとポリシーによって異なります。このリスクを軽減すると、自らの自律型関数になります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses terminology defined in [RFC7575].
この文書は[RFC7575]で定義されている用語を使用しています。
The Autonomic Networking use case considered here is autonomic IPv6 prefix management at the edge of large-scale ISP networks.
ここで考慮されるオートノミックネットワーキングユースケースは、大規模ISPネットワークのエッジでの自律型IPv6プレフィックス管理です。
Although DHCPv6-PD (DHCPv6 Prefix Delegation) [RFC8415] supports automated delegation of IPv6 prefixes from one router to another, prefix management still largely depends on human planning. In other words, there is no basic information or policy to support autonomic decisions on the prefix length that each router should request or be delegated, according to its role in the network. Roles could be defined separately for individual devices or could be generic (edge router, interior router, etc.). Furthermore, IPv6 prefix management by humans tends to be rigid and static after initial planning.
DHCPV6-PD（DHCPv6プレフィックス代表団）[RFC8415]は、あるルーターから別のルータへのIPv6プレフィックスの自動委任をサポートしていますが、プレフィックス管理はまだ人間の計画に大きく依存します。言い換えれば、ネットワーク内のその役割に応じて、各ルータが要求または委任されるべきプレフィックス長に対する自律的決定をサポートするための基本的な情報やポリシーはありません。役割は個々の装置に対して別々に定義することも、一般的な（エッジルータ、内部ルータなど）でもよい。さらに、ヒトによるIPv6プレフィックス管理は、最初の計画後に厳密で静的になる傾向があります。
The problem to be solved by Autonomic Networking is how to dynamically manage IPv6 address space in large-scale networks, so that IPv6 addresses can be used efficiently. Here, we limit the problem to assignment of prefixes at the edge of the network, close to access routers that support individual fixed-line subscribers, mobile customers, and corporate customers. We assume that the core infrastructure of the network has already been established with appropriately assigned prefixes. The Autonomic Networking approach discussed in this document is based on the assumption that there is a generic discovery and negotiation protocol that enables direct negotiation between intelligent IP routers. GRASP [RFC8990] is intended to be such a protocol.
オートノミックネットワーキングによって解決される問題は、大規模ネットワークでIPv6アドレス空間を動的に管理する方法であるため、IPv6アドレスを効率的に使用できます。ここでは、ネットワークの端にあるプレフィックスの割り当てに問題を制限し、個々の固定ライン加入者、モバイル顧客、および企業の顧客をサポートするアクセスルータに近い。ネットワークのコアインフラストラクチャがすでに適切に割り当てられたプレフィックスで確立されていると仮定します。この文書で説明されている自律神経ネットワーキングアプローチは、インテリジェントIPルータ間の直接交渉を可能にする一般的な発見とネゴシエーションプロトコルがあるという仮定に基づいています。把握[RFC8990]はそのようなプロトコルになることを目的としています。
The intended experience is, for the administrators of a large-scale network, that the management of IPv6 address space at the edge of the network can be run with minimum effort, as devices at the edge are added and removed and as customers of all kinds join and leave the network. In the ideal scenario, the administrators only have to specify a single IPv6 prefix for the whole network and the initial prefix length for each device role. As far as users are concerned, IPv6 prefix assignment would occur exactly as it does in any other network.
意図された経験は、大規模ネットワークの管理者にとって、ネットワークの端におけるIPv6アドレス空間の管理は、エッジのデバイスが追加および削除され、あらゆる種類の顧客として結合してネットワークを残します。理想的なシナリオでは、管理者はネットワーク全体の単一のIPv6プレフィックスと各デバイスロールの最初のプレフィックス長を指定する必要があります。ユーザーが懸念される限り、IPv6プレフィックスの割り当ては、他のネットワーク内でそうであるとおりに発生します。
The actual prefix usage needs to be logged for potential offline management operations, including audit and security incident tracing.
監査およびセキュリティのインシデントトレースを含む、オフライン管理業務の潜在的なオフライン管理操作に記録する必要があります。
For specific purposes of address management, each edge device will implement several parameters. (Some of them can be preconfigured before they are connected.) They include the following:
アドレス管理の特定の目的のために、各エッジデバイスはいくつかのパラメータを実装します。（それらの中には接続する前に事前設定できます。）それらは以下を含みます。
* Identity, authentication, and authorization of this device. This is expected to use the Autonomic Networking secure bootstrap process [RFC8995], following which the device could safely take part in autonomic operations.
* このデバイスのID、認証、および許可。これは、自律実体ネットワーキングセキュアブートストラッププロセス[RFC8995]を使用すると予想されます。その後、デバイスは安全に自律操作に参加できます。
* Role of this device. Some example roles are discussed in Section 6.1.
* この装置の役割ロールの例を6.1節で説明します。
* An IPv6 prefix length for this device.
* このデバイスのIPv6プレフィックス長。
* An IPv6 prefix that is assigned to this device and its downstream devices.
* このデバイスとそのダウンストリームデバイスに割り当てられているIPv6プレフィックス。
The network as a whole will implement the following parameters:
ネットワーク全体としては、以下のパラメータを実装します。
* Identity of a trust anchor, which is a certification authority (CA) maintained by the network administrators, used during the secure bootstrap process.
* Secure Bootstrapプロセス中に使用されるネットワーク管理者によって維持されている認証局（CA）である信頼アンカーのID。
* Total IPv6 address space available for edge devices. It is a pool of one or several IPv6 prefixes.
* エッジデバイスに使用できる総IPv6アドレス・スペース。1つまたは複数のIPv6プレフィックスのプールです。
* The initial prefix length for each device role.
* 各デバイスロールの最初のプレフィックス長。
This section identifies those of the above parameters that do not need external information in order for the devices concerned to set them to a reasonable default value after bootstrap or after a network disruption. They are as follows:
このセクションでは、ブートストラップ後またはネットワークの中断後にそれらを合理的なデフォルト値に設定することに関係するために外部情報を必要としない上記のパラメータの項目を識別します。それらは次のとおりです。
* Default role of this device.
* このデバイスのデフォルトの役割
* Default IPv6 prefix length for this device.
* このデバイスのデフォルトのIPv6プレフィックス長。
* Cryptographic identity of this device, as needed for secure bootstrapping [RFC8995].
* 安全なブートストラップ[RFC8995]に必要に応じて、このデバイスの暗号化ID。
The device may be shipped from the manufacturer with a preconfigured role and default prefix length, which could be modified by an autonomic mechanism. Its cryptographic identity will be installed by its manufacturer.
装置は製造業者から事前設定された役割およびデフォルトのプレフィックス長で出荷されてもよく、これは自律神経機構によって修正され得る。その暗号化されたアイデンティティは製造元によってインストールされます。
This section identifies those parameters that might need operational input in order for the devices concerned to set them to a non-default value.
このセクションでは、関係するデバイスがデフォルト以外の値に設定するために動作入力が必要なパラメータを識別します。
* Non-default value for the IPv6 prefix length for this device. This needs to be decided based on the role of this device.
* このデバイスのIPv6プレフィックス長のデフォルト以外の値。これはこの装置の役割に基づいて決定される必要があります。
* The initial prefix length for each device role.
* 各デバイスロールの最初のプレフィックス長。
* Whether to allow the device to request more address space.
* 装置がより多くのアドレス空間を要求できるかどうか。
* The policy regarding when to request more address space -- for example, if the address usage reaches a certain limit or percentage.
* たとえば、アドレス使用量が特定の制限またはパーセンテージに達すると、いつアドレス・スペースを要求するかに関するポリシー。
This section briefly compares the above use case with current solutions. Currently, the address management is still largely dependent on human planning. It is rigid and static after initial planning. Address requests will fail if the configured address space is used up.
このセクションでは、上記の使用例と現在のソリューションを簡単に比較します。現在、アドレス管理はまだ人間の計画に大きく依存しています。初期計画の後に硬くて静的です。設定されたアドレス・スペースが使用されている場合は、アドレス要求は失敗します。
Some autonomic and dynamic address management functions may be achievable by extending the existing protocols -- for example, extending DHCPv6-PD [RFC8415] to request IPv6 prefixes according to the device role. However, defining uniform device roles may not be a practical task, as some functions cannot be configured on the basis of role using existing prefix delegation protocols.
いくつかの自律型および動的アドレス管理機能は、デバイスロールに従ってIPv6プレフィックスを要求するために、既存のプロトコルを拡張することによって達成可能であり得る。ただし、一様なデバイスの役割を定義することは、既存のプレフィックス委任プロトコルを使用して役割に基づいて設定できないため、実用的なタスクではない場合があります。
Using a generic autonomic discovery and negotiation protocol instead of specific solutions has the advantage that additional parameters can be included in the autonomic solution without creating new mechanisms. This is the principal argument for a generic approach.
特定の解決策の代わりに一般的な自律神経発見およびネゴシエーションプロトコルを使用すると、新しいメカニズムを作成せずに追加のパラメータを自律型ソリューションに含めることができるという利点があります。これは一般的なアプローチの主な引数です。
This section identifies those of the above parameters that need external information from neighbor devices (including the upstream devices). In many cases, two-way dialogue with neighbor devices is needed to set or optimize them.
このセクションでは、隣接デバイス（アップストリームデバイスを含む）から外部情報が必要な上記のパラメータの項目を識別します。多くの場合、隣接デバイスとの双方向ダイアログは、それらを設定または最適化するために必要です。
* Information regarding the identity of a trust anchor is needed.
* 信頼アンカーの身元に関する情報が必要です。
* The device will need to discover another device from which it can acquire IPv6 address space.
* デバイスは、IPv6アドレス空間を取得できる別のデバイスを発見する必要があります。
* Information regarding the initial prefix length for the role of each device is needed, particularly for its own downstream devices.
* 各装置の役割のための初期接頭辞の長さに関する情報は、特にそれ自身のダウンストリーム装置のために必要とされる。
* The default value of the IPv6 prefix length may be overridden by a non-default value.
* IPv6プレフィックス長のデフォルト値は、デフォルト以外の値によって上書きされます。
* The device will need to request and acquire one or more IPv6 prefixes that can be assigned to this device and its downstream devices.
* このデバイスとそのダウンストリームデバイスに割り当てることができる1つ以上のIPv6プレフィックスを要求して取得する必要があります。
* The device may respond to prefix delegation requests from its downstream devices.
* デバイスは、その下流デバイスからのプレフィックス委任要求に応答することがあります。
* The device may require the assignment of more IPv6 address space if it used up its assigned IPv6 address space.
* デバイスは、割り当てられたIPv6アドレス・スペースを使用した場合、IPv6アドレス・スペースの割り当てを必要とする可能性があります。
This section discusses what role devices should play in monitoring, fault diagnosis, and reporting.
このセクションでは、監視、故障診断、および報告においてどの役割デバイスが再生されるべきかについて説明します。
* The actual address assignments need to be logged for potential offline management operations.
* 実際のアドレス割り当ては、潜在的なオフライン管理操作のために記録される必要があります。
* In general, the usage situation regarding address space should be reported to the network administrators in an abstract way -- for example, statistics or a visualized report.
* 一般に、アドレススペースに関する使用状況は、統計や視覚化されたレポートなどの抽象的な方法でネットワーク管理者に報告されるべきです。
* A forecast of address exhaustion should be reported.
* 住所の枯渇の予測が報告されるべきです。
This section introduces the building blocks for an autonomic edge prefix management solution. As noted in Section 1, this is not a complete description of a solution, which will depend on the detailed design of the relevant Autonomic Service Agents (ASAs). It uses the generic discovery and negotiation protocol defined by [RFC8990]. The relevant GRASP objectives are defined in Section 5.
このセクションでは、オートノミックエッジプレフィックス管理ソリューションのビルディングブロックについて説明します。セクション1で述べたように、これは解決策の完全な説明ではありません。これは、関連する自律型サービスエージェント（ASAS）の詳細設計に依存します。[RFC8990]で定義されている一般的な発見とネゴシエーションプロトコルを使用します。関連する把握目的はセクション5で定義されています。
The procedures described below are carried out by an ASA in each device that participates in the solution. We will refer to this as the PrefixManager ASA.
以下の手順は、その解決策に参加する各装置のASAによって行われる。これをPrefixManager ASAと呼びます。
If the device containing a PrefixManager ASA has used up its address pool, it can request more space according to its requirements. It should decide the length of the requested prefix and request it via the mechanism described in Section 6. Note that although the device's role may define certain default allocation lengths, those defaults might be changed dynamically, and the device might request more, or less, address space due to some local operational heuristic.
PrefixManager ASAを含むデバイスがそのアドレスプールを使用した場合、その要件に従ってさらにスペースを要求できます。それは要求されたプレフィックスの長さを決定し、セクション6で説明されているメカニズムを介してそれを要求する必要があります。地元の運用上のヒューリスティックによるアドレススペース。
A PrefixManager ASA that needs additional address space should firstly discover peers that may be able to provide extra address space. The ASA should send out a GRASP Discovery message that contains a PrefixManager Objective option (see Section 2 of [RFC8650] and Section 5.1) in order to discover peers also supporting that option. Then, it should choose one such peer, most likely the first to respond.
追加のアドレススペースを必要とするPrefixManager ASAは、最初に追加のアドレススペースを提供できる可能性があるピアを検出する必要があります。ASAは、そのオプションをサポートするピアを検出するために、PrefixManagerの目標オプションを含むGRASPディスカバリーメッセージを送信する必要があります（[RFC8650]およびセクション5.1のセクション2を参照）。それから、それはそのようなピアを1つ選択するべきです、おそらく最初の対応する可能性が高いです。
If the GRASP Discovery Response message carries a Divert option pointing to an off-link PrefixManager ASA, the requesting ASA may initiate negotiation with that ASA-diverted device to find out whether it can provide the requested length of the prefix.
Grasp Discovery ResponseメッセージがオフリンクプレフィックスマニュアルASAを指しているDivertオプションを搬送する場合、要求側ASAは、そのASAが宛先されたデバイスとの交渉を開始し、プレフィックスの要求された長さを提供できるかどうかを調べます。
In any case, the requesting ASA will act as a GRASP negotiation initiator by sending a GRASP Request message with a PrefixManager Objective option. The ASA indicates in this option the length of the requested prefix. This starts a GRASP negotiation process.
いずれにせよ、要求されたASAは、プレフィックスマネージャ目標オプションを使用してGRASS要求メッセージを送信することによって把握ネゴシエーションイニシエータとして機能します。ASAはこのオプションで要求されたプレフィックスの長さを示します。これは把握交渉プロセスを開始します。
During the subsequent negotiation, the ASA will decide at each step whether to accept the offered prefix. That decision, and the decision to end the negotiation, are implementation choices.
その後の交渉中、ASAは各ステップで提供されたプレフィックスを受け入れるかどうかを決定します。その決定、および交渉を終了する決定は、実装の選択肢です。
The ASA could alternatively initiate GRASP discovery in rapid mode with an embedded negotiation request, if it is implemented.
ASAは、それが実装されている場合、埋め込まれたネゴシエーション要求を用いて急速モードで把握を開始することができる。
At least one device on the network must be configured with the initial pool of available prefixes mentioned in Section 3.2. Apart from that requirement, any device may act as a provider of prefixes.
ネットワーク上の少なくとも1つのデバイスは、セクション3.2に記載されている利用可能なプレフィックスの初期プールで構成する必要があります。その要件とは別に、あらゆる装置は接頭辞のプロバイダーとして機能することがあります。
A device that receives a Discovery message with a PrefixManager Objective option should respond with a GRASP Response message if it contains a PrefixManager ASA. Further details of the discovery process are described in [RFC8990]. When this ASA receives a subsequent Request message, it should conduct a GRASP negotiation sequence, using Negotiate, Confirm Waiting, and Negotiation End messages as appropriate. The Negotiate messages carry a PrefixManager Objective option, which will indicate the prefix and its length offered to the requesting ASA. As described in [RFC8990], negotiation will continue until either end stops it with a Negotiation End message. If the negotiation succeeds, the ASA that provides the prefix will remove the negotiated prefix from its pool, and the requesting ASA will add it. If the negotiation fails, the party sending the Negotiation End message may include an error code string.
PrefixManagerの目標オプションを使用して検出メッセージを受信するデバイスは、PrefixManager ASAが含まれている場合は、把握応答メッセージで応答する必要があります。発見プロセスのさらなる詳細は[RFC8990]に記載されている。このASAが後続の要求メッセージを受信すると、交渉、待機、およびネゴシエーションの終了メッセージを使用して、把握交渉シーケンスを実行する必要があります。ネゴシエートメッセージはPrefixManagerの目標オプションを持ちます。これは、プレフィックスとその長さが要求されたASAに提供されます。[RFC8990]に記載されているように、ネゴシエーションはネゴシエーション終了メッセージでそれを停止するまで、ネゴシエーションは続行されます。ネゴシエーションが成功すると、接頭辞を提供するASAはそのプールからネゴシエートされたプレフィックスを削除し、要求しているASAが追加されます。ネゴシエーションが失敗した場合、ネゴシエーション終了メッセージを送信するパーティはエラーコード文字列を含み得る。
During the negotiation, the ASA will decide at each step how large a prefix to offer. That decision, and the decision to end the negotiation, are implementation choices.
交渉中、ASAは各ステップで提供するプレフィックスを決定します。その決定、および交渉を終了する決定は、実装の選択肢です。
The ASA could alternatively negotiate in response to GRASP discovery in rapid mode, if it is implemented.
ASAは、それが実装されている場合、迅速なモードでの発見の把握に応答して交渉することができます。
This specification is independent of whether the PrefixManager ASAs are all embedded in routers, but that would be a rather natural scenario. In a hierarchical network topology, a given router typically provides prefixes for routers below it in the hierarchy, and it is also likely to contain the first PrefixManager ASA discovered by those downstream routers. However, the GRASP discovery model, including its redirection feature, means that this is not an exclusive scenario, and a downstream PrefixManager ASA could negotiate a new prefix with a device other than its upstream router.
この仕様は、PrefixManager ASASがすべてルータに埋め込まれているかどうかとは無関係ですが、それはかなり自然なシナリオです。階層型ネットワークトポロジでは、特定のルータは通常、ルータのプレフィックスを階層内で提供し、それらの下流ルータによって検出された最初のPrefixManager ASAを含む可能性があります。ただし、リダイレクト機能を含むGrasp Discoveryモデルは、これが排他的シナリオではなく、ダウンストリームPrefixManager ASAはアップストリームルータ以外のデバイスとの新しいプレフィックスをネゴシエートできます。
A resource shortage may cause the gateway router to request more resources in turn from its own upstream device. This would be another independent GRASP discovery and negotiation process. During the processing time, the gateway router should send a Confirm Waiting message to the initial requesting router, to extend its timeout. When the new resource becomes available, the gateway router responds with a GRASP Negotiate message with a prefix length matching the request.
リソース不足は、ゲートウェイルータが独自のアップストリームデバイスから順番にもっとリソースを要求する可能性があります。これは別の独立した把握発見と交渉プロセスです。処理時間中に、ゲートウェイルータは最初の要求されたルータに確認待機メッセージを送信してタイムアウトを拡張する必要があります。新しいリソースが利用可能になると、ゲートウェイルータはリクエストに一致するプレフィックス長を持つ把握負荷メッセージで応答します。
The algorithm used to choose which prefixes to assign on the devices that provide prefixes is an implementation choice.
プレフィックスを提供するデバイスに割り当てるプレフィックスが実装の選択肢であるかを選択するために使用されるアルゴリズム。
Upon receiving a GRASP Negotiation End message that indicates that an acceptable prefix length is available, the requesting device may use the negotiated prefix without further messages.
許容可能なプレフィックス長が利用可能であることを示す把握ネゴシエーション終了メッセージを受信すると、要求側デバイスはそれ以上のメッセージなしにネゴシエートされたプレフィックスを使用することができる。
There are use cases where the ANI/GRASP-based prefix management approach can work together with DHCPv6-PD [RFC8415] as a complement. For example, the ANI/GRASP-based method can be used intra-domain, while the DHCPv6-PD method works inter-domain (i.e., across an administrative boundary). Also, ANI/GRASP can be used inside the domain, and DHCP/DHCPv6-PD can be used on the edge of the domain to clients (non-ANI devices). Another similar use case would be ANI/ GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to client devices.
ANI / GRASSベースのプレフィックス管理アプローチが、補数としてDHCPV6-PD [RFC8415]と一緒に機能する可能性があります。たとえば、ANI / GRASSベースの方法はドメイン内に使用できますが、DHCPV6-PDメソッドはドメイン間（すなわち、管理境界全体にわたって）。また、ANI / GRASPをドメイン内で使用でき、DHCP / DHCPV6-PDをドメインのエッジにクライアント（非ANIデバイス）に使用できます。もう1つの同様のユースケースは、ドメイン内部のANI / GRASS、RADIUS [RFC2865]がクライアントデバイスにプレフィックスを提供します。
Within the autonomic prefix management system, all prefix assignments are done by devices without human intervention. It may be required that all prefix assignment history be recorded -- for example, to detect or trace lost prefixes after outages or to meet legal requirements. However, the logging and reporting process is out of scope for this document.
自律型プレフィックス管理システム内では、すべてのプレフィックス割り当ては人間の介入なしのデバイスによって行われます。停止後のプレフィックスを検出または追跡するため、または法的要件を満たすために、すべてのプレフィックス割り当て履歴を記録する必要があるかもしれません。ただし、ロギングとレポート作成プロセスはこの文書に対して範囲外です。
This section defines the GRASP technical objective options that are used to support autonomic prefix management.
このセクションでは、オートノミックプレフィックス管理をサポートするために使用される把握の技術的目的オプションを定義します。
The PrefixManager Objective option is a GRASP Objective option conforming to the GRASP specification [RFC8990]. Its name is "PrefixManager" (see Section 8), and it carries the following data items as its value: the prefix length and the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Object Representation) [RFC8949], the format of the PrefixManager Objective option is described in the Concise Data Definition Language (CDDL) [RFC8610] as follows:
PrefixManager目的オプションは、GRASS仕様[RFC8990]に準拠した把握対象オプションです。その名前は "PrefixManager"です（セクション8を参照）、その値として次のデータ項目を搭載しています。プレフィックス長と実際のプレフィックスビット。GRASPはCBOR（簡潔なバイナリオブジェクト表現）[RFC8949]に基づいているので、PrefixManager目標オプションのフォーマットは、簡潔なデータ定義言語（CDDL）[RFC8610]に次のように説明されています。
objective = ["PrefixManager", objective-flags, loop-count,
[length, ?prefix]]
loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification
length = 0..128 ; requested or offered prefix length
prefix = bytes .size 16 ; offered prefix in binary format
The use of the "dry run" mode of GRASP is NOT RECOMMENDED for this objective, because it would require both ASAs to store state information about the corresponding negotiation, to no real benefit -- the requesting ASA cannot base any decisions on the result of a successful dry-run negotiation.
「ドライラン」モードの使用は、この目的には、対応する交渉に関する状態情報を保存するようにASAの両方が必要であるため、本当の利益を得ないようにするため、推奨されるものではありません。ドライラン交渉が成功しました。
This section presents an extended version of the PrefixManager objective that supports IPv4 by adding an extra flag:
このセクションでは、追加のフラグを追加してIPv4をサポートするPrefixManagerのObjectiveの拡張バージョンを示します。
objective = ["PrefixManager", objective-flags, loop-count, prefval]
loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification
prefval /= pref6val
pref6val = [version6, length, ?prefix]
version6 = 6
length = 0..128 ; requested or offered prefix length
prefix = bytes .size 16 ; offered prefix in binary format
prefval /= pref4val
pref4val = [version4, length4, ?prefix4]
version4 = 4
length4 = 0..32 ; requested or offered prefix length
prefix4 = bytes .size 4 ; offered prefix in binary format
Prefix and address management for IPv4 is considerably more difficult than for IPv6, due to the prevalence of NAT, ambiguous addresses [RFC1918], and address sharing [RFC6346]. These complexities might require further extending the objective with additional fields that are not defined by this document.
IPv4のプレフィックスとアドレス管理は、NAT、あいまいなアドレス[RFC1918]、およびアドレス共有[RFC6346]の有病率により、IPv6よりもかなり困難です。これらの複雑さは、この文書によって定義されていない追加のフィールドで目的をさらに拡張する必要があるかもしれません。
An implementation of a prefix manager MUST include default settings of all necessary parameters. However, within a single administrative domain, the network operator MAY change default parameters for all devices with a certain role. Thus, it would be possible to apply an intended policy for every device in a simple way, without traditional configuration files. As noted in Section 4.1, individual autonomic devices may also change their own behavior dynamically.
プレフィックスマネージャの実装には、必要なすべてのパラメータのデフォルト設定が含まれている必要があります。ただし、単一の管理ドメイン内では、ネットワークオペレータは特定の役割を持つすべてのデバイスのデフォルトパラメータを変更することがあります。したがって、従来の設定ファイルなしで、すべてのデバイスに対して意図したポリシーを簡単な方法で適用することが可能です。セクション4.1で述べたように、個々の自律型デバイスはそれら自身の振る舞いも動的に変化する可能性があります。
For example, the network operator could change the default prefix length for each type of role. A prefix management parameters objective, which contains mapping information of device roles and their default prefix lengths, MAY be flooded in the network, through the Autonomic Control Plane (ACP) [RFC8994]. The objective is defined in CDDL as follows:
たとえば、ネットワークオペレータは、ロールの種類ごとにデフォルトのプレフィックス長を変更できます。Prefix Management Parameters Abjectiveは、デバイスの役割のマッピング情報とそのデフォルトのプレフィックス長を含み、自律制御プレーン（ACP）[RFC8994]を介してネットワーク内にフラッディングすることができます。目的は次のようにCDDLで定義されています。
objective = ["PrefixManager.Params", objective-flags, any]
loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification
The "any" object would be the relevant parameter definitions (such as the example below) transmitted as a CBOR object in an appropriate format.
"any"オブジェクトは、適切な形式でCBORオブジェクトとして送信された関連パラメータ定義（以下の例など）です。
This could be flooded to all nodes, and any PrefixManager ASA that did not receive it for some reason could obtain a copy using GRASP unicast synchronization. Upon receiving the prefix management parameters, every device can decide its default prefix length by matching its own role.
これはすべてのノードにフラッディングすることができ、何らかの理由でそれを受け取っていなかったASAは、Graspユニキャスト同期を使用してコピーを取得することができます。プレフィックス管理パラメータを受信すると、すべてのデバイスは独自の役割を一致させることによってデフォルトのプレフィックス長を決定できます。
The parameters comprise mapping information of device roles and their default prefix lengths in an autonomic domain. For example, suppose an IPRAN (IP Radio Access Network) operator wants to configure the prefix length of a Radio Network Controller Site Gateway (RSG) as 34, the prefix length of an Aggregation Site Gateway (ASG) as 44, and the prefix length of a Cell Site Gateway (CSG) as 56. This could be described in the value of the PrefixManager.Params objective as:
パラメータは、自律ドメイン内のデバイスロールとそれらのデフォルトのプレフィックス長のマッピング情報を含む。たとえば、IPRAN（IP無線アクセスネットワーク）演算子は、ラジオネットワークコントローラサイトゲートウェイ（RSG）のプレフィックス長（RSG）を44としてのプレフィックス長（ASG）、およびプレフィックス長のプレフィックス長を設定したいとします。これは、PrefixManager.Paramsの目標の値に記載されているものとして説明することができます。
[
[["role", "RSG"],["prefix_length", 34]],
[["role", "ASG"],["prefix_length", 44]],
[["role", "CSG"],["prefix_length", 56]]
]
This example is expressed in JSON [RFC8259], which is easy to represent in CBOR.
この例は、CBORで表現するのは簡単なJSON [RFC8259]で表現されています。
An alternative would be to express the parameters in YANG [RFC7950] using the YANG-to-CBOR mapping [CORE-YANG-CBOR].
代替手段は、Yang-To-Cbor Mapping [Core-Yang-Cbor]を使用して、Yang [RFC7950]のパラメータを表現することです。
For clarity, the background of the example is introduced below and can also be regarded as a use case for the mechanism defined in this document.
明確にするために、例の背景は以下に紹介され、この文書で定義されたメカニズムのユースケースと見なすこともできます。
An IPRAN is used for mobile backhaul, including radio stations, RNCs (Radio Network Controllers) (in 3G) or the packet core (in LTE), and the IP network between them, as shown in Figure 1. The eNB (Evolved Node B) entities, the RNC, the SGW (Serving Gateway), and the MME (Mobility Management Entity) are mobile network entities defined in 3GPP. The CSGs, ASGs, and RSGs are entities defined in the IPRAN solution.
図1に示すように、無線局、RNC（無線ネットワークコントローラ）またはパケットコア（LTE）、およびそれらの間のIPネットワークなど、モバイルバックホールに使用されます。）エンティティ、RNC、SGW（サービングゲートウェイ）、およびMME（Mobility Management Entity）は、3GPPで定義されているモバイルネットワークエンティティです。CSG、ASGS、およびRSGは、IPRANソリューションで定義されているエンティティです。
The IPRAN topology shown in Figure 1 includes Ring1, which is the circle following ASG1->RSG1->RSG2->ASG2->ASG1; Ring2, following CSG1->ASG1->ASG2->CSG2->CSG1; and Ring3, following CSG3->ASG1->ASG2->CSG3. In a real deployment of an IPRAN, there may be more stations, rings, and routers in the topology, and normally the network is highly dependent on human design and configuration, which is neither flexible nor cost-effective.
図1に示すIPRANトポロジには、ASG1-> RSG1-> RSG2-> ASG2-> ASG1の後の円であるRing1が含まれています。CSG1-> ASG1-> ASG2-> CSG1→CSG1; Ring2。そして、CSG3-> ASG1-> ASG2-> CSG3に続いて、Ring3。IPRANの実際の展開では、トポロジー内の局、リング、およびルータが多くなる可能性があり、通常、ネットワークはヒューマンデザインと構成に大きく依存しており、これは柔軟でも費用対効果の高いものでもありません。
+------+ +------+
| eNB1 |---| CSG1 |\
+------+ +------+ \ +-------+ +------+ +-------+
| \ | ASG1 |-------| RSG1 |-----------|SGW/MME|
| Ring2 +-------+ +------+ \ /+-------+
+------+ +------+ / | | \ /
| eNB2 |---| CSG2 | \ / | Ring1 | \/
+------+ +------+ \ Ring3| | /\
/ \ | | / \
+------+ +------+ / \ +-------+ +------+/ \+-------+
| eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC |
+------+ +------+ +-------+ +------+ +-------+
Figure 1: IPRAN Topology Example
図1：IPRANトポロジの例
If ANI/GRASP is supported in the IPRAN, the network nodes should be able to negotiate with each other and make some autonomic decisions according to their own status and the information collected from the network. The prefix management parameters should be part of the information they communicate.
ANI / GRASSがIPRANでサポートされている場合、ネットワークノードは互いにネゴシエートすることができ、自らのステータスとネットワークから収集された情報に従っていくつかの自律的な決定を下す必要があります。接頭辞管理パラメータは、通信する情報の一部でなければなりません。
The routers should know the role of their neighbors, the default prefix length for each type of role, etc. An ASG should be able to request prefixes from an RSG, and a CSG should be able to request prefixes from an ASG. In each request, the ASG/CSG should indicate the required prefix length, or its role, which implies what length it needs by default.
ルータは、各タイプのロールのタイプのデフォルトのプレフィックス長など、隣接者の役割を知っている必要があります.ASGはRSGからプレフィックスを要求することができ、CSGはASGからプレフィックスを要求できるはずです。各要求では、ASG / CSGは必要なプレフィックス長、またはその役割を示す必要があります。その役割は、デフォルトでどの長さで必要な長さを意味します。
Relevant security issues are discussed in [RFC8990]. The preferred security model is that devices are trusted following the secure bootstrap procedure [RFC8995] and that a secure Autonomic Control Plane (ACP) [RFC8994] is in place.
[RFC8990]で関連するセキュリティ問題について説明します。好ましいセキュリティモデルは、セキュアブートストラップ手順[RFC8995]に従って、デバイスが信頼されており、安全なオートノミックコントロールプレーン（ACP）[RFC8994]が整っていることです。
It is RECOMMENDED that DHCPv6-PD, if used, should be implemented using DHCPv6 authentication or Secure DHCPv6.
DHCPv6-PDが使用されている場合は、DHCPv6認証またはSecure DHCPv6を使用して実装する必要があります。
This document defines two new GRASP Objective option names: "PrefixManager" and "PrefixManager.Params". The IANA has added these to the "GRASP Objective Names" registry defined by [RFC8990].
このドキュメントでは、「prefixmanager」と「prefixmanager.params」という2つの新しい把握対象オプション名を定義します。IANAは、[RFC8990]で定義されている「把握目的名の名称」レジストリにこれらを追加しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ED。、「Yang 1.1データモデリング言語」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.
[RFC8990] Bormann、C、Carpenter、B.、ED。、およびB.IU、ED。、「GENICAL自律型シグナリングプロトコル（GRASP）」、RFC 8990、DOI 10.17487 / RFC8990、2021年5月、<https：//www.rfc-editor.org/info/rfc8990>。
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.
[RFC8994] Eckert、T.、Ed。、Behringer、M.、Ed。、およびS.Bjarnason、「自律管理プレーン（ACP）」、RFC 8994、DOI 10.17487 / RFC8994、2021年5月、<https：//www.rfc-editor.org/info/rfc8994>。
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC8995] Pritikin、M.、Richardson、M.、Eckert、T.、Behringer、M.、およびK. Watsen、「ブートストラップリモートセキュリティキーインフラストラクチャ（Brski）」、RFC 8995、DOI 10.17487 / RFC8995、2021年5月<https://www.rfc-editor.org/info/rfc8995>。
[CORE-YANG-CBOR] Veillette, M., Ed., Petrov, I., Ed., and A. Pelov, "CBOR Encoding of Data Modeled with YANG", Work in Progress, Internet-Draft, draft-ietf-core-yang-cbor-15, 24 January 2021, <https://tools.ietf.org/html/draft-ietf-core-yang-cbor-15>.
[Core-Yang-Cbor] Veillette、M.、ED。、Petrov、I.、Ed。、およびA.ペローフ、「ヤンでモデル化されたデータのCBORエンコーディング」、進行中の作業、インターネットドラフト、ドラフト - IETF-Core-Yang-Cbor-15,11月24日、<https：//tools.ietf.org/html/draft-ietf-core-yang-cor--15>。
[DHCP-YANG-MODEL] Liu, B., Ed., Lou, K., and C. Chen, "Yang Data Model for DHCP Protocol", Work in Progress, Internet-Draft, draft-liu-dhc-dhcp-yang-model-07, 12 October 2018, <https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-07>.
[DHCP-YANG-MODEL] LIU、B、ED。、LOU、K。、およびC CHEN、「DHCPプロトコルのYangデータモデル」、進行中の作業、インターネットドラフト、ドラフトLIU-DHC-DHCP-Yang-Model-07,2018、<https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-07>
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、DE GROUT、GJ、およびE. Lear、「プライベートインターネットの住所配分」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C、Willens、S.、Rubens、A.、およびW.Simpson、「ユーザーサービス内のリモート認証ダイヤル（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：//www.rfc-editor.org/info/rfc2865>。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, <https://www.rfc-editor.org/info/rfc3046>.
[RFC3046]パトリック、M、「DHCPリレーエージェント情報オプション」、RFC 3046、DOI 10.17487 / RFC3046、2001年1月、<https：//www.rfc-editor.org/info/rfc3046>。
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <https://www.rfc-editor.org/info/rfc6221>.
[RFC6221]マイル、D.、ED。、Ooghe、S.、Dec、W.、Krishnan、S.、およびA. Kavanagh、 "Lightweight DHCPV6リレーエージェント"、RFC 6221、DOI 10.17487 / RFC6221、<https://www.rfc-editor.org/info/rfc6221>。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <https://www.rfc-editor.org/info/rfc6346>.
[RFC6346]ブッシュ、R。、「IPv4アドレス不足」、RFC 6346、DOI 10.17487 / RFC6346、2011年8月、<https：//ww.rfc-editor.org/ info / rfc6346>。
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.
[RFC7575] Behringer、M.、Pritikin、M.、Bjarnason、S.、Clemm、A.、Carpenter、B.、Jiang、S.、およびL. Ciavaglia、「オートノミックネットワーキング：定義とデザイン目標」、RFC 7575、DOI 10.17487 / RFC7575、2015年6月、<https：//www.rfc-editor.org/info/rfc7575>。
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, <https://www.rfc-editor.org/info/rfc7576>.
[RFC7576] Jiang、S.、Carpenter、B.およびM. Behringer、「自律ネットワーキングのための一般的なギャップ分析」、RFC 7576、DOI 10.17487 / RFC7576、2015年6月、<https：//www.rfc-editor.org/ info / rfc7576>。
[RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and A. Bierman, "Dynamic Subscription to YANG Events and Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, November 2019, <https://www.rfc-editor.org/info/rfc8650>.
[RFC8650] Voit、E.、Rahman、R.、Nilsen-Nygaard、E.、Clemm、A。、およびA. Bierman、「ヤン・イベントへの動的購読およびrestconf及びデータストアはRFC 8650、DOI 10.17487 / RFC8650」、2019年11月、<https：//www.rfc-editor.org/info/rfc8650>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, <https://www.rfc-editor.org/info/rfc8993>.
[RFC8993] Behringer、M.、Ed。、Carpenter、B.、Eckert、T.、Ciavaglia、L.、およびJ.Bobre、 "Autonomic Networkingのための参照モデル"、RFC 8993、DOI 10.17487 / RFC8993、2021年5月<https://www.rfc-editor.org/info/rfc8993>。
This appendix includes logical deployment models and explanations of the target deployment models. Its purpose is to help in understanding the mechanism described in this document.
この付録には、論理展開モデルとターゲット展開モデルの説明が含まれています。その目的は、この文書に記載されているメカニズムを理解するのを助けることです。
This appendix includes two subsections: Appendix A.1 for the two most common DHCP deployment models and Appendix A.2 for the PD deployment model described in this document. It should be noted that these are just examples, and there are many more deployment models.
この付録には、2つのサブセクションが含まれています。これらは単なる例であり、より多くの展開モデルがあることに注意してください。
Edge DHCP server deployment requires every edge router connecting to a Customer Premises Equipment (CPE) device to be a DHCP server assigning IPv4/IPv6 addresses to CPEs -- and, optionally, IPv6 prefixes via DHCPv6-PD for IPv6-capable CPEs that are routers and have LANs behind them.
Edge DHCPサーバーの展開では、CPESのIPv4 / IPv6アドレスを割り当てるDHCPサーバーに接続されているすべてのエッジルーターがCPESにIPv4 / IPv6アドレスを割り当てるDHCPサーバーに接続されているすべてのエッジルーターが必要です。そして彼らの後ろにLANを持っています。
edge
dynamic, "NETCONF/YANG" interfaces
<---------------> +-------------+
+------+ <- telemetry | edge router/|-+ ----- +-----+
|config| .... domain ... | DHCP server | | ... | CPE |+ LANs
|server| +-------------+ | ----- +-----+| (---| )
+------+ +--------------+ DHCP/ +-----+
DHCPv6-PD
Figure 2: DHCP Deployment Model without a Central DHCP Server
図2：Central DHCPサーバのないDHCP展開モデル
This requires various coordination functions via some backend system (depicted as the "config server" in Figure 2): the address prefixes on the edge interfaces should be slightly larger than required for the number of CPEs connected so that the overall address space is best used.
これはいくつかのバックエンドシステムを介してさまざまな調整機能を必要とします（図2の「Config Server」として示されています）。エッジインタフェース上のアドレスプレフィックスは、全体のアドレス空間が最も使用されるように接続されたCPEの数に必要なものよりわずかに大きくなければなりません。。
The config server needs to provision edge interface address prefixes and DHCP parameters for every edge router. If prefixes that are too fine-grained are used, this will result in large routing tables across the domain shown in the figure. If prefixes that are too coarse-grained are used, address space is wasted. (This is less of a concern for IPv6, but if the model includes IPv4, it is a very serious concern.)
Config Serverは、エッジルータごとにエッジインターフェイスアドレスプレフィックスとDHCPパラメータをプロビジョニングする必要があります。きめ細かいプレフィックスが使用されている場合は、図に示すドメイン間で大きなルーティングテーブルが発生します。粗粒が粗い接頭辞が使用されている場合は、アドレススペースが無駄になります。（これはIPv6にとって懸念はありませんが、モデルにIPv4が含まれている場合は非常に深刻な関心事です。）
There is no standard that describes algorithms for how configuration servers would best perform this ongoing dynamic provisioning to optimize routing table size and address space utilization.
ルーティングテーブルのサイズとアドレススペースの使用率を最適化するために、構成サーバーがこの継続的な動的プロビジョニングをどのように実行するかについてのアルゴリズムを説明する標準はありません。
There are currently no complete YANG data models that a config server could use to perform these actions (including telemetry of assigned addresses from such distributed DHCP servers). For example, a YANG data model for controlling DHCP server operations is still being developed [DHCP-YANG-MODEL].
Config Serverがこれらのアクションを実行するために使用できる完全なYangデータモデルは、（このような分散型DHCPサーバーから割り当てられたアドレスの遠隔測定を含む）。たとえば、DHCPサーバー操作を制御するためのYANDデータモデルはまだ開発されています[DHCP-YANG-MODEL]。
Due to these and other problems related to the above model, the more common DHCP deployment model is as follows:
上記のモデルに関連するこれらの問題やその他の問題により、より一般的なDHCP展開モデルは次のとおりです。
+------+ edge
|config| initial, "CLI" interfaces
|server| ----------------> +-------------+
+------+ | edge router/|-+ ----- +-----+
| .... domain ... | DHCP relay | | ... | CPE |+ LANs
+------+ +-------------+ | ----- +-----+| (---| )
|DHCP | +--------------+ DHCP/ +-----+
|server| DHCPv6-PD
+------+
Figure 3: DHCP Deployment Model with a Central DHCP Server
図3：Central DHCPサーバを備えたDHCP展開モデル
Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge routers is static. The DHCP relay function inserts an "edge interface" and/or subscriber-identifying options into DHCP requests from CPEs (e.g., [RFC3046] [RFC6221]), and the DHCP server has complete policies for address assignments and prefixes usable on every edge router / interface / subscriber group. When the DHCP relay sees the DHCP reply, it inserts static routes for the assigned address / address prefix into the routing table of the edge router; these routes are then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable across the domain shown in the figure.
エッジルータへの動的プロビジョニングの変更は、Central DHCPサーバを使用し、DHCPサーバからDHCPリレーへのエッジルータを削減することによって回避されます。エッジルータの「設定」は静的です。DHCPリレー機能は、「エッジインタフェース」および/または加入者識別オプションをCPESからDHCP要求に挿入します（例：[RFC3046] [RFC6221]）、DHCPサーバーにはアドレス割り当てのための完全なポリシーとすべてのエッジルーターで使用可能なプレフィックスがあります。/インターフェース/サブスクライバグループ。DHCPリレーがDHCP応答を見ていると、割り当てられたアドレス/アドレスプレフィックスの静的ルートをエッジルータのルーティングテーブルに挿入します。これらの経路は、図に示すドメイン全体でCPEとLANを到達可能にするために、ドメイン内のIGP（またはBGP）によって配布されます。
There is no comprehensive standardization of these solutions. For example, [RFC8415], Section 19.1.3 simply refers to "a [non-defined] protocol or other out-of-band communication to configure routing information for delegated prefixes on any router through which the client may forward traffic."
これらの解決策の包括的な標準化はありません。たとえば、[RFC8415]、セクション19.1.3は単に「非定義済み」プロトコルまたは他の帯域外通信を指して、クライアントがトラフィックを転送する可能性がある任意のルータの委任プレフィックスのルーティング情報を構成します。」
Using the ANI and prefix management ASAs (PM-ASAs) using GRASP, the deployment model is intended to look as follows:
GRASPを使用してANIとプレフィックス管理ASAS（PM-ASAS）を使用して、展開モデルは次のようになります。
|<............ ANI domain / ACP............>| (...) ........->
Roles
|
v "Edge routers"
GRASP parameter +----------+
Network-wide | PM-ASA | downstream
parameters/policies | (DHCP | interfaces
| |functions)| ------
v "central device" +----------+
+------+ ^ +--------+
|PM-ASA| <............GRASP .... .... | CPE |-+ (LANs)
+------+ . v |(PM-ASA)| | ---|
. +........+ +----------+ +--------+ |
+...........+ . PM-ASA . | PM-ASA | ------ +---------+
.DHCP server. +........+ | (DHCP | SLAAC/
+...........+ "intermediate |functions)| DHCP/DHCP-PD
router" +----------+
Figure 4: Deployment Model Using ANI/GRASP
図4：ANI / GRASSを使用した展開モデル
The network runs an ANI domain with an ACP [RFC8994] between some central device (e.g., a router or an ANI-enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch communication channel between the devices and enables the use of GRASP [RFC8990] not only for peer-to-peer communication but also for distribution/flooding.
ネットワークは、いくつかの中央装置（例えば、ルータまたはANI対応管理装置）とエッジルータとの間のACP [RFC8994]を有するANIドメインを実行する。ANI / ACPは、デバイス間の安全でゼロタッチ通信チャネルを提供し、ピアツーピア通信だけでなく配信/フラッディングにも把握することを可能にします。
The central devices and edge routers run software in the form of ASAs to support this document's autonomic IPv6 edge prefix management. PM-ASAs as discussed below together comprise the Autonomic Prefix Management Function.
中央装置とエッジルータは、このドキュメントの自律型IPv6エッジプレフィックス管理をサポートするためにASASの形でソフトウェアを実行します。後述するPM-ASASは、自律型プレフィックス管理機能を含みます。
Edge routers can have different roles based on the type and number of CPEs attaching to them. Each edge router could be an RSG, ASG, or CSG in mobile aggregation networks (see Section 6.1). Mechanisms outside the scope of this document make routers aware of their roles.
エッジルータは、それらに接続するCPEの種類と数に基づいて異なる役割を持つことができます。各エッジルータは、モバイルアグリゲーションネットワークのRSG、ASG、またはCSGでもかまいません（セクション6.1を参照）。この文書の範囲外のメカニズムは、ルーターが役割を認識しています。
Some considerations related to the deployment model are as follows.
展開モデルに関連するいくつかの考慮事項は次のとおりです。
1. In a minimum prefix management solution, the central device uses the PrefixManager.Params GRASP objective introduced in this document to disseminate network-wide, per-role parameters to edge routers. The PM-ASA uses the parameters that apply to its own role to locally configure preexisting addressing functions. Because the PM-ASA does not manage the dynamic assignment of actual IPv6 address prefixes in this case, the following options can be considered:
1. 最小プレフィックス管理ソリューションでは、中央装置はPrefixManager.Paramsはエッジルータに発信ネットワーク全体ごとの役割パラメータに本書に導入目的GRASP使用します。PM-ASAは、独自の役割に適用されるパラメータを使用して、既存のアドレッシング機能をローカルに設定します。PM-ASAは実際のIPv6アドレスプレフィックスの動的割り当てを管理しないため、次のオプションを考慮することができます。
1.a The edge router connects via downstream interfaces to each (host) CPE that requires an address. The PM-ASA sets up for each such interface a DHCP requesting router (according to [RFC8415]) to request an IPv6 prefix for the interface. The router's address on the downstream interface can be another parameter from the GRASP objective. The CPEs assign addresses in the prefix via Router Advertisements (RAs), or the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs. A central DHCP server acting as the DHCP delegating router (according to [RFC8415]) is required. Its address can be another parameter from the GRASP objective.
1. Aエッジルータは、下流のインターフェイスを介してアドレスを必要とする各（ホスト）CPEに接続します。PM-ASAは、そのようなインタフェースに、IPv6のIPv6プレフィックスを要求するために、DHCP要求ルータをリクエストする各インタフェースに設定します。ダウンストリームインターフェイス上のルータのアドレスは、GRASP対象から別のパラメータになることができます。CPESは、ルータアドバタイズメント（RAS）を介してプレフィックス内のアドレスを割り当てます.PM-ASAは、CPEにアドレスを割り当てるためのローカルDHCPv6サーバーを管理します。DHCP委任ルータとして機能する中央DHCPサーバ（[RFC8415]に従って）が必要です。そのアドレスは、GRASP目標から別のパラメータになる可能性があります。
1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are routers and act as DHCPv6 requesting routers. The need to support this could be derived from role or GRASP parameters, and the PM-ASA sets up a DHCP relay function to pass on requests to the central DHCP server as in point 1.a.
1.bエッジルータは、ダウンストリームインターフェイスを介してルータであり、DHCPv6を要求するDHCPv6として機能する（顧客管理）CPESにも接続します。これをサポートする必要性は、役割または把握パラメータから導き出され、PM-ASAはPoint 1.Aのように中央のDHCPサーバーへの要求を渡すためにDHCPリレー機能を設定します。
2. In a solution without a central DHCP server, the PM-ASA on the edge routers not only learns parameters from PrefixManager.Params but also utilizes GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP PrefixManager objective, as described in more detail below. In the simplest case, these prefixes are delegated via this GRASP objective from the PM-ASA in the central device. This device must be provisioned initially with a large pool of prefixes. The delegated prefixes are then used by the PM-ASA on the edge routers to configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in point 1.a) to assign addresses via DHCP to the CPEs from the prefixes it received. This includes both host CPEs requesting IPv6 addresses and router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the local DHCP servers it starts. It needs to monitor the address utilization and accordingly request more address prefixes if its existing prefixes are exhausted, or return address prefixes when they are unneeded.
2. Central DHCPサーバーのないソリューションでは、エッジルータのPM-ASAは、prefixmanager.paramsからのパラメータを学習するだけでなく、以下により詳細に説明されるように、Grasp PrefixManagerの目的を介して実際のIPv6プレフィックス委任を要求/ネゴシエートするためのGraspを利用します。最も単純な場合では、これらのプレフィックスは中央装置のPM-ASAからこの把握対象を介して委任されます。このデバイスは最初に大規模なプレフィックスプールを使用してプロビジョニングされている必要があります。委任されたプレフィックスは、RA / SLAACを介してアドレスをホストCPEに割り当てるために、エッジルータ上のPM-ASAによって使用されます。それらのダウンストリームインターフェイス上のプレフィックスを設定します。 PM-ASAは、ローカルDHCPサーバー（Point 1.Aのように）を開始して、受信したプレフィックスからDHCPを介してアドレスをCPEに割り当てることもできます。これには、IPv6のプレフィックスを要求するIPv6アドレスとルータのCPEを要求する両方のホストCPEが含まれます。 PM-ASAは、GRASSを介して要求されたアドレスプールを管理する必要があります。サブアドレスプールをインターフェイスと開始するローカルDHCPサーバーに割り当てます。既存の接頭辞がなくなった場合は、アドレス使用率を監視する必要があります。また、既存のプレフィックスが不要な場合はアドレスプレフィックスを要求する必要があります。
This solution is quite similar to the previous IPv6 DHCP deployment model without a central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provide the automation to make this approach work more easily than is possible today.
このソリューションは、Central DHCPサーバーのない以前のIPv6 DHCPデプロイメントモデルと非常に似ています。そして、ANI / ACP / GRASPとPM-ASA DOは、今日可能な限り簡単に機能するための自動化を提供する自動化を提供します。
3. The address pools from which prefixes are allocated do not all need to be taken from one central location. An edge-router PM-ASA that received a big (short) prefix from a central PM-ASA could offer smaller sub-prefixes to a neighboring edge-router PM-ASA. GRASP could be used in such a way that the PM-ASA would find and select the objective from the closest neighboring PM-ASA, therefore allowing aggregation to be maximized: a PM-ASA would only request further smaller prefixes when it exhausts its own pool (from the central location) and cannot get further large prefixes from that central location anymore. Because the overflow prefixes taken from a topologically nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited and the topological proximity increases the chances that aggregation of prefixes in the IGP can most likely limit the geography in which the longer prefixes need to be routed.
3. プレフィックスが割り当てられているアドレスプールは、すべて1つの中央位置から取得する必要がありません。中央PM-ASAから大きな（短い）接頭辞を受けたエッジルータPM-ASAは、隣接エッジルータPM-ASAに小さなサブプレフィックスを提供できます。PM-ASAが最も近いPM-ASAから目的を見つけて選択するように把握できるように使用することができます。したがって、集計を最大化することを可能にする。（中央の場所から）、もうその中心的な場所からさらに大きな接頭辞を取得できません。トポロジ的に近くのPM-ASAから取得されたオーバーフロープレフィックスは、ルーティングテーブルに注入されなければならない長いプレフィックスの数が制限され、トポロジの近接性がIGP内のプレフィックスの集約が最も可能性が高い可能性が高い可能性が高まります。より長い接頭辞をルーティングする必要があります。
4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASAs can be built (indicated in Figure 4 via a dotted intermediate router). This would require additional parameters in the PrefixManager objective to allow the creation of a hierarchy of PM-ASAs across which the prefixes can be delegated.
4. プレフィックス委任のピアツーピア最適化の代わりに、PM-ASAの階層を構築することができます（点線の中間ルータを介して図4に示されています）。これにより、プレフィックスマニュアルの目的で追加のパラメータが必要になり、プレフィックスを委任できるPM-ASASの階層の作成を可能にします。
5. In cases where CPEs are also part of the ANI domain (e.g., "managed CPEs"), then GRASP will extend into the actual customer sites and can also run a PM-ASA. All the options described in points 1 to 4 above would then apply to the CPE as the edge router, with the major changes being that (a) a CPE router will most likely not need to run DHCPv6-PD itself, but only DHCP address assignment and (b) the edge routers to which the CPE connects would most likely become ideal places on which to run a hierarchical instance of PD-ASAs, as outlined in point 1.
5. CPEがANIドメインの一部（例えば「管理CPE」）の一部である場合、GRASSは実際の顧客サイトに拡張され、PM-ASAを実行することもできます。上記の点1から4で説明されているすべてのオプションは、エッジルータとしてCPEに適用されます。これは（A）CPEルータがDHCPv6-PD自体を実行する必要がない可能性が高いですが、DHCPアドレス割り当てのみを実行する必要はありません。（b）CPEが接続するエッジルータは、PD - ASAの階層的インスタンスを実行する理想的な場所になる可能性が高い。
Acknowledgements
謝辞
Valuable comments were received from William Atwood, Fred Baker, Michael Behringer, Ben Campbell, Laurent Ciavaglia, Toerless Eckert, Joel Halpern, Russ Housley, Geoff Huston, Warren Kumari, Dan Romascanu, and Chongfeng Xie.
William Atwood、Fred Beaker、Michael Behringer、Ben Campbell、Laurent Ciavaglia、Toerless Eckert、Joel Halpern、Russ Oumley、Geoff Huston、Warren Kumari、Dan Romascanu、Chongfeng Xieから貴重なコメントが受けられました。
Authors' Addresses
著者の住所
Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus No. 156 Beiqing Road Hai-Dian District, Beijing 100095 China
Sheng Jiang（編集）Huawei Technologies Co.、Ltd Q14、Huawei Campus No. 156 Beiqing Road Hai-Dian District、北京100095中国
Email: jiangsheng@huawei.com
Zongpeng Du China Mobile 32 Xuanwumen West St Xicheng District, Beijing 100053 China
Zongpeng du China Mobile 32 Xuanwumen West St Xicheng地区、北京100053中国
Email: duzongpeng@chinamobile.com
Brian Carpenter University of Auckland School of Computer Science PB 92019 Auckland 1142 New Zealand
ブライアン大工オークランド大学コンピュータサイエンスPB 92019オークランド1142ニュージーランド
Email: brian.e.carpenter@gmail.com
Qiong Sun China Telecom 118 Xizhimennei St Beijing 100035 China
Qiong Sun China Telecom 118 Xizhimennei St Beijing 100035中国
Email: sunqiong@chinatelecom.cn