[要約] 要約：RFC 5671は、Path Computation Element（PCE）がPoint-to-Multipoint（P2MP）MPLSおよびGMPLS Traffic Engineering（TE）に適用可能であることを示しています。 目的：このRFCの目的は、PCEを使用してP2MP MPLSおよびGMPLS TEを効果的に実装するためのガイドラインを提供することです。
Network Working Group S. Yasukawa
Request for Comments: 5671 NTT
Category: Informational A. Farrel, Ed.
Old Dog Consulting
October 2009
Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)
ポイントツーマルチポイント（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）へのパス計算要素（PCE）の適用可能性
Abstract
概要
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
PATH計算要素（PCE）は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPL（GMPLS）ネットワークのトラフィックエンジニアリングをサポートするパス計算関数を提供します。
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs).
MPLSおよびGMPLSシグナリングおよびルーティングプロトコルへの拡張は、ポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）をサポートするために作成されています。
This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate.
このドキュメントでは、MPLSおよびGMPLSネットワークにおけるP2MP TE LSPのPCHへのPATH計算への適用性を調べます。PCEを使用してこれらのパスを計算する動機を説明し、どのPCEアーキテクチャモデルが適切であるかを調べます。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Architectural Considerations ....................................4
2.1. Offline Computation ........................................4
2.2. Online Computation .........................................4
2.2.1. LSR Loading .........................................5
2.2.2. PCE Overload ........................................6
2.2.3. PCE Capabilities ....................................6
3. Fragmenting the P2MP Tree .......................................7
4. Central Replication Points ......................................8
5. Reoptimization and Modification .................................9
6. Repair .........................................................10
7. Disjoint Paths .................................................11
8. Manageability Considerations ...................................11
8.1. Control of Function and Policy ............................11
8.2. Information and Data Models ...............................11
8.3. Liveness Detection and Monitoring .........................12
8.4. Verifying Correct Operation ...............................12
8.5. Requirements on Other Protocols and Functional
Components ................................................12
8.6. Impact on Network Operation ...............................13
9. Security Considerations ........................................13
10. Acknowledgments ...............................................13
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................13
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and of applying computational constraints. The intention is that the PCE is used to compute the path of Traffic Engineered Label Switched Paths (TE LSPs) within Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
[RFC4655]で定義されているパス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティです。PCEは、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワーク内のトラフィックエンジニアリングラベルスイッチ付きパス（TE LSP）のパスを計算するために使用されることです。
[RFC4655] defines various deployment models that place PCEs differently within the network. The PCEs may be collocated with the Label Switching Routers (LSRs), may be part of the management system that requests the LSPs to be established, or may be positioned as one or more computation servers within the network.
[RFC4655]は、ネットワーク内でPCESを異なる配置するさまざまな展開モデルを定義します。PCESは、ラベルスイッチングルーター（LSR）とcolocedされる場合があります。また、LSPを確立することを要求する管理システムの一部である場合もあれば、ネットワーク内の1つ以上の計算サーバーとして配置される場合もあります。
Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are documented in [RFC4461], and signaling protocol extensions for setting up P2MP MPLS TE LSPs are defined in [RFC4875]. In this document, P2MP MPLS TE networks are considered in support of various features including layer 3 multicast VPNs [RFC4834], video distribution, etc.
ポイントツーマルチポイント（P2MP）MPLS TE LSPの要件は[RFC4461]に文書化されており、P2MP MPLS TE LSPをセットアップするためのシグナル伝達プロトコル拡張は[RFC4875]で定義されています。このドキュメントでは、P2MP MPLS TEネットワークは、レイヤー3マルチキャストVPN [RFC4834]、ビデオ分布などを含むさまざまな機能をサポートしています。
Fundamental to the determination of the paths for P2MP LSPs within a network is the selection of branch points. Not only is this selection constrained by the network topology and available network resources, but it is determined by the objective functions that may be applied to path computation. For example, one standard objective is to minimize the total cost of the tree (that is, to minimize the sum of the costs of each link traversed by the tree) to produce what is known as a Steiner tree. Another common objective function requires that the cost to reach each leaf of the P2MP tree be minimized.
ネットワーク内のP2MP LSPのパスの決定の基本は、ブランチポイントの選択です。この選択は、ネットワークトポロジと利用可能なネットワークリソースによって制約されるだけでなく、パス計算に適用できる目的関数によって決定されます。たとえば、1つの標準的な目的は、ツリーの総コスト（つまり、ツリーが通過する各リンクのコストの合計を最小限に抑える）を最小化して、シュタイナーツリーとして知られているものを生成することです。別の一般的な目的関数では、P2MPツリーの各葉に到達するためのコストを最小限に抑える必要があります。
The selection of branch points within the network is further complicated by the fact that not all LSRs in the network are necessarily capable of performing branching functions. This information may be recorded in the Traffic Engineering Database (TED) that the PCE uses to perform its computations, and may have been distributed using extensions to the Interior Gateway Protocol (IGP) operating within the network [RFC5073].
ネットワーク内の分岐点の選択は、ネットワーク内のすべてのLSRが必ずしも分岐機能を実行できるわけではないという事実により、さらに複雑になります。この情報は、PCEが計算を実行するために使用するトラフィックエンジニアリングデータベース（TED）に記録され、ネットワーク内で動作するインテリアゲートウェイプロトコル（IGP）の拡張機能を使用して分布している可能性があります[RFC5073]。
Additionally, network policies may dictate specific branching behavior. For example, it may be decided that, for certain types of LSPs in certain types of networks, it is important that no branch LSR is responsible for handling more than a certain number of downstream branches for any one LSP. This might arise because the replication mechanism used at the LSRs is a round-robin copying process that delays the data transmission on each downstream branch by the time taken to replicate the data onto each previous downstream branch. Alternatively, administrative policies may dictate that replication should be concentrated on specific key replication nodes behaving like IP multicast rendezvous points (perhaps to ensure appropriate policing of receivers in the P2MP tree, or perhaps to make protection and resiliency easier to implement).
さらに、ネットワークポリシーは、特定の分岐動作を決定する場合があります。たとえば、特定のタイプのネットワークの特定のタイプのLSPについて、1つのLSPの特定の数の下流ブランチを超える分岐LSRが責任を負わないことが重要であることが決定される場合があります。これは、LSRSで使用される複製メカニズムがラウンドロビンのコピープロセスであり、各下流のブランチにデータを以前のダウンストリームブランチに複製するまでにかかる丸いロビンコピープロセスであるためです。あるいは、管理ポリシーは、IPマルチキャストランデブーポイントのように動作する特定のキーレプリケーションノードに複製する必要があることを決定する場合があります（おそらくP2MPツリーの受信機の適切なポリシングを確保するか、おそらく保護と回復力を実装しやすくするため）。
Path computation for P2MP TE LSPs presents a significant challenge because of the complexity of the computations described above. Determining disjoint protection paths for P2MP TE LSPs can add considerably to this complexity, while small modifications to a P2MP tree (such as adding or removing just one leaf) can completely change the optimal path. Reoptimization of a network containing multiple P2MP TE LSPs requires considerable computational resources. All of this means that an ingress LSR might not have sufficient processing power to perform the necessary computations, and even if it does, the act of path computation might interfere with the control and management plane operation necessary to maintain existing LSPs. The PCE architecture offers a way to offload such path computations from LSRs.
P2MP TE LSPのパス計算は、上記の計算の複雑さのために重要な課題を提示します。P2MP TE LSPの分離保護パスを決定すると、この複雑さが大幅に追加される可能性がありますが、P2MPツリーの小さな変更（1つの葉の追加または除去など）は、最適なパスを完全に変える可能性があります。複数のP2MP TE LSPを含むネットワークの再最適化には、かなりの計算リソースが必要です。これはすべて、侵入LSRが必要な計算を実行するのに十分な処理能力を持たない可能性があることを意味し、たとえそうであっても、パス計算の行為は、既存のLSPを維持するために必要な制御および管理プレーンの動作を妨げる可能性があります。PCEアーキテクチャは、LSRからこのようなパス計算をオフロードする方法を提供します。
Offline path computation is performed ahead of time, before the LSP setup is requested. That means that it is requested by, or performed as part of, a management application. This model can be seen in Section 5.5 of [RFC4655].
LSPセットアップが要求される前に、オフラインパス計算が事前に実行されます。つまり、管理アプリケーションの一部によって要求されるか、その一部として実行されることを意味します。このモデルは、[RFC4655]のセクション5.5で見ることができます。
The offline model is particularly appropriate to long-lived LSPs (such as those present in a transport network) or for planned responses to network failures. In these scenarios, more planning is normally a feature of LSP provisioning.
オフラインモデルは、長命のLSP（輸送ネットワークに存在するLSPなど）や、ネットワーク障害に対する計画された応答に特に適しています。これらのシナリオでは、通常、より多くの計画がLSPプロビジョニングの機能です。
This model may also be used where the network operator wishes to retain full manual control of the placement of LSPs, using the PCE only as a computation tool to assist the operator, not as part of an automated network.
このモデルは、自動化されたネットワークの一部としてではなく、オペレーターを支援するためのPCEのみを計算ツールとして使用して、ネットワークオペレーターがLSPの配置の完全な手動制御を保持したい場合に使用することもできます。
Offline path computation may be applied as a background activity for network reoptimization to determine whether and when the current LSP placements are significantly sub-optimal. See Section 5 for further discussions of reoptimization.
オフラインパス計算は、現在のLSPの配置が大幅に最適であるかどうか、いつ最適であるかを判断するために、ネットワーク再最適化のバックグラウンドアクティビティとして適用される場合があります。再最適化の詳細については、セクション5を参照してください。
Online path computation is performed on-demand as LSRs in the network determine that they need to know the paths to use for LSPs. Thus, each computation is triggered by a request from an LSR.
ネットワーク内のLSRSがLSPに使用するパスを知る必要があると判断しているため、オンラインパス計算はオンデマンドで実行されます。したがって、各計算は、LSRからの要求によってトリガーされます。
As described in [RFC4655], the path computation function for online computation may be collocated with the LSR that makes the request, or it may be present in a computation-capable PCE server within the network. The PCE server may be another LSR in the network, a dedicated server, or a functional component of a Network Management System (NMS). Furthermore, the computation is not necessarily achieved by a single PCE operating on its own, but may be the result of cooperation between several PCEs.
[RFC4655]で説明されているように、オンライン計算のパス計算関数は、リクエストを行うLSRとcolococedしている場合があります。または、ネットワーク内の計算対応PCEサーバーに存在する場合があります。PCEサーバーは、ネットワーク内の別のLSR、専用サーバー、またはネットワーク管理システム（NMS）の機能コンポーネントである場合があります。さらに、計算は必ずしも単一のPCEで動作することによって達成されるわけではありませんが、いくつかのPCE間の協力の結果である可能性があります。
The remainder of this document makes frequent reference to these different online models in order to indicate which is more appropriate in different P2MP scenarios.
このドキュメントの残りの部分は、さまざまなP2MPシナリオでより適切であることを示すために、これらの異なるオンラインモデルを頻繁に参照しています。
An important feature of P2MP path computation is the processing load that it places on the network element that is determining the path. Roughly speaking, the load to compute a least-cost-to-leaf tree is the same as the cost to compute a single optimal path to each leaf in turn. The load to compute a Steiner tree is approximately an order of magnitude greater, although algorithms exist to approximate Steiner trees in roughly the same order of magnitude of time as for a least-cost-to-leaf tree.
P2MPパス計算の重要な機能は、パスを決定しているネットワーク要素に配置する処理荷重です。大まかに言えば、最小コストから葉のツリーを計算する負荷は、各葉への単一の最適なパスを順番に計算するためのコストと同じです。シュタイナーツリーを計算するための荷重はほぼ数桁大きくなりますが、アルゴリズムは、少なくともコストから葉の木とほぼ同じ時間でシュタイナーツリーを近似するために存在します。
Whereas many LSRs are capable of simple Constrained Shortest Path First (CSPF) computations to determine a path for a single point-to-point (P2P) LSP, they rapidly become swamped if called on to perform multiple such computations, such as when recovering from a network failure. Thus, it is reasonable to expect that an LSR would struggle to handle a P2MP path computation for a tree with many destinations.
多くのLSRは、単一のポイントツーポイント（P2P）LSPのパスを決定するための単純な制約最短パス（CSPF）計算が可能ですが、回復するときなど、複数のそのような計算を実行するように呼び出された場合、それらは急速に沼地になります。ネットワークの障害。したがって、LSRが多くの目的地を持つツリーのP2MPパス計算を処理するのに苦労することを期待することは合理的です。
The result of an LSR becoming overloaded by a P2MP path computation may be two-fold. First, the LSR may be unable to provide timely computations of paths for P2P LSPs; this may impact LSP setup times for simple demand-based services and could damage the LSR's ability to recover services after network faults. Secondly, the LSR's processing capabilities may be diverted from other important tasks, not the least of which is maintaining the control plane protocols that are necessary to the support of existing LSPs and forwarding state within the network. It is obviously critically important that existing traffic should not be disrupted by the computation of a path for a new LSP.
LSRがP2MPパス計算によって過負荷になった結果は2倍になる可能性があります。まず、LSRはP2P LSPのパスのタイムリーな計算を提供できない場合があります。これは、単純な需要ベースのサービスのLSPセットアップ時間に影響を与える可能性があり、ネットワーク障害後にサービスを回復するLSRの能力を損なう可能性があります。第二に、LSRの処理機能は他の重要なタスクから転用される可能性がありますが、少なくともネットワーク内の既存のLSPと転送状態のサポートに必要なコントロールプレーンプロトコルを維持しています。新しいLSPのパスの計算によって既存のトラフィックを破壊することは明らかに非常に重要です。
It is also not reasonable to expect the ingress LSRs of P2MP LSRs to be specially powerful and capable of P2MP computations. Although a solution to the overloading problem would be to require that all LSRs that form the ingresses to P2MP LSPs be sufficiently high-capacity to perform P2MP computations, this is not an acceptable solution because, in all other senses, the ingress to a P2MP LSP is just a normal ingress LSR.
また、P2MP LSRの侵入LSRが特別に強力でP2MP計算が可能であると予想することは合理的ではありません。過負荷の問題の解決策は、P2MP LSPに侵入を形成するすべてのLSRがP2MP計算を実行するのに十分な大容量であることを要求することですが、これは許容可能な解決策ではありません。通常の侵入LSRです。
Thus, there is an obvious solution: off-load P2MP path computations from LSRs to remotely located PCEs. Such PCE function can be provided on dedicated or high-capacity network elements (such as dedicated servers, or high-end routers that might be located as Autonomous System Border Routers - ASBRs).
したがって、明らかな解決策があります：LSRからリモート位置のPCESへのオフロードP2MPパス計算。このようなPCE関数は、専用または大容量のネットワーク要素（専用サーバー、または自律システムの境界ルーター（ASBRS）として配置される可能性のあるハイエンドルーターなど）で提供できます。
Since P2MP path computations are resource-intensive, it may be that the introduction of P2MP LSPs into an established PCE network will cause overload at the PCEs. That is, the P2MP computations may block other P2P computations and might even overload the PCE.
P2MPパス計算はリソース集約型であるため、P2MP LSPを確立されたPCEネットワークに導入すると、PCESで過負荷が発生する可能性があります。つまり、P2MP計算により、他のP2P計算がブロックされ、PCEに過負荷される可能性があります。
Several measures can be taken within the PCE architecture to alleviate this situation as described in [RFC4655]. For example, path computation requests can be assigned priorities by the LSRs that issue them. Thus, the LSRs could assign lower priority to the P2MP requests, ensuring that P2P requests were serviced in preference. Furthermore, the PCEs are able to apply local and network-wide policy and this may dictate specific processing rules [RFC5394].
[RFC4655]に記載されているように、この状況を軽減するために、PCEアーキテクチャ内でいくつかの測定値をとることができます。たとえば、PATH計算要求は、それらを発行するLSRによって優先順位を割り当てることができます。したがって、LSRはP2MPリクエストの優先度を低い割り当てで割り当て、P2Pリクエストが優先されていることを確認できます。さらに、PCESはローカルおよびネットワーク全体のポリシーを適用することができ、これにより特定の処理ルールが決定される可能性があります[RFC5394]。
But ultimately, a network must possess sufficient path computation resources for its needs and this is achieved within the PCE architecture simply by increasing the number of PCEs.
しかし、最終的には、ネットワークはそのニーズに合った十分なパス計算リソースを所有する必要があり、これはPCEの数を増やすだけでPCEアーキテクチャ内で達成されます。
Once there are sufficient PCEs available within the network, the LSRs may choose between them and may use overload notification information supplied by the PCEs to spot which PCEs are currently over-loaded. Additionally, a PCE that is becoming over-loaded may redistribute its queue of computation requests (using the PCE cooperation model described in [RFC4655]) to other, less burdened PCEs within the network.
ネットワーク内で十分なPCEが利用可能になると、LSRはそれらを選択する場合があり、PCESが提供する過負荷通知情報を使用して、現在過負荷されているPCEを見つけることができます。さらに、過負荷になっているPCEは、ネットワーク内の他の、重荷の少ないPCESに、計算要求のキュー（[RFC4655]に記載されているPCE協力モデルを使用）を再配布する場合があります。
An LSR chooses between available PCEs to select the one most likely to be able to perform the requested path computation. This selection may be based on overload notifications from the PCEs, but could also consider other computational capabilities.
LSRは、利用可能なPCEを選択して、要求されたパス計算を実行できる可能性が最も高いものを選択します。この選択は、PCESからの過負荷通知に基づいている場合がありますが、他の計算機能を考慮することもできます。
For example, it is quite likely that only a subset of the PCEs in the network have the ability to perform P2MP computations since this requires advanced functionality. Some of those PCEs might have the ability to satisfy certain objective functions (for example, least cost to destination), but lack support for other objective functions (for example, Steiner). Additionally, some PCEs might not be capable of the more complex P2MP reoptimization functionality.
たとえば、ネットワーク内のPCESのサブセットのみが、高度な機能が必要なため、P2MP計算を実行する機能を備えている可能性が非常に高いです。これらのPCEの一部は、特定の目的関数（例えば、目的地のコストが最小）を満たす能力を持っている可能性がありますが、他の目的関数（たとえば、シュタイナー）のサポートがありません。さらに、一部のPCESは、より複雑なP2MP再発現機能を備えていない場合があります。
The PCE architecture allows an LSR to discover the capabilities of the PCEs within the network at the same time it discovers their existence. Further and more detailed exchanges of PCE capabilities can be made directly between the PCEs and the LSRs. This exchange of PCE capabilities information allows a Path Computation Client (PCC) to select the PCE that can best answer its computation requests.
PCEアーキテクチャにより、LSRはネットワーク内のPCEの機能を発見すると同時に、その存在を発見できます。PCEとLSRの間で、PCE機能のより詳細な交換をさらに詳しく行うことができます。このPCE機能情報の交換により、Path Computation Client（PCC）は、計算リクエストに最もよく答えることができるPCEを選択できます。
A way to reduce the computational burden of computing a large P2MP tree on a single PCE is to fragment or partition the tree. This may be particularly obvious in a multi-domain network (such as multiple routing areas), but is equally applicable in a single domain.
単一のPCEで大きなP2MPツリーを計算するという計算負担を減らす方法は、ツリーをフラグメントまたは分割することです。これは、マルチドメインネットワーク（複数のルーティング領域など）で特に明白な場合がありますが、単一のドメインでも同様に適用できます。
Consider the network topology in Figure 1. A P2MP LSP is required from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z. Using a single PCE model, LSR A may request the entire path of the tree and this may be supplied by the PCE. Alternatively, the PCE that is consulted by LSR A may only compute the first fragment of the tree (for example, from A to K, L, and M) and may rely on other PCEs to compute the three smaller trees from K to t, u, and v; from L to w and x; and from M to s, y, and z.
図1のネットワークトポロジを考えてみましょう。P2MPLSPは、Ingress LSR AからLSRS S、T、U、V、W、X、Y、およびZに出力する必要があります。単一のPCEモデルを使用して、LSR Aはツリーのパス全体を要求する場合があり、これはPCEによって提供される場合があります。あるいは、LSR Aによって相談されるPCEは、ツリーの最初のフラグメントのみを計算することができます（たとえば、AからK、L、およびM）、他のPCESに依存して3つの小さな木をKからTまで計算することができます。u、およびv;LからWおよびXへ。そして、MからS、Y、およびZから。
The LSR consulted by A may simply return the first subtree and leave LSRs K, L, and M to invoke PCEs in their turn in order to complete the signaling. Alternatively, the first PCE may cooperate with other PCEs to collect the paths for the later subtrees and return them in a single computation response to PCE A. The mechanisms for both of these approaches are described in the PCE architecture [RFC4655].
Aが相談したLSRは、単に最初のサブツリーを返し、LSRS K、L、およびMを残して、シグナリングを完了するためにPCEを呼び出します。あるいは、最初のPCEは他のPCEと協力して後のサブツリーのパスを収集し、PCE Aに対する単一の計算応答でそれらを返します。これらのアプローチの両方のメカニズムは、PCEアーキテクチャ[RFC4655]に記載されています。
t
/
/
n--u
/
/
e--f--h--K--o--v
/
/
A--b--c--d--g--i--L--p--w
\ \
\ \
j x
\
\
M--r--y
\ \
\ \
s z
Figure 1: A P2MP Tree with Intermediate Computation Points
図1：中間計算ポイントを備えたP2MPツリー
A further possibility is that LSRs at which the subtrees are stitched together (K, L, and M in this example) are selected from a set of potential such points using a cooperative PCE technique, such as the Backward Recursive Path Computation (BRPC) mechanism [RFC5441]. Indeed, if LSRs K, L, and M were ASBRs or Area Border Routers (ABRs), the BRPC technique would be particularly applicable.
さらなる可能性は、サブツリーが一緒に縫い合わされるLSR（この例ではk、l、およびm）が、後方再帰パス計算（BRPC）メカニズムなど、協同的PCE技術を使用してそのようなポイントのセットから選択されることです。[RFC5441]。実際、LSRS K、L、およびMがASBRSまたは面積境界ルーター（ABRS）である場合、BRPC技術は特に適用可能です。
Note, however, that while these mechanisms are superficially beneficial, it is far from obvious how the first LSR selects the transit LSRs K, L, and M, or how the leaf nodes are assigned to be downstream of particular downstream nodes. The computation to determine these questions may be no less intensive than the determination of the full tree unless there is some known property of the leaf node identifiers such as might be provided by address aggregation.
ただし、これらのメカニズムは表面的に有益ですが、最初のLSRがTransit LSRS K、L、およびMを選択する方法、または葉のノードが特定の下流ノードの下流に割り当てられていることは明らかではないことに注意してください。これらの質問を決定するための計算は、アドレス集約によって提供される可能性のある葉のノード識別子の既知の特性がない限り、完全なツリーの決定よりも集中的である可能性があります。
A deployment model for P2MP LSPs is to use centralized, well-known replication points. This choice may be made for administrative or security reasons, or because of particular hardware capability limitations within the network. Indeed, this deployment model can be achieved using P2P LSPs between ingress and replication point as well as between replication point and each leaf so as to achieve a P2MP service without the use of P2MP MPLS-TE.
P2MP LSPの展開モデルは、集中型のよく知られた複製ポイントを使用することです。この選択は、管理上またはセキュリティの理由で、またはネットワーク内の特定のハードウェア機能の制限のために行われる場合があります。実際、この展開モデルは、P2MP MPLS-TEを使用せずにP2MPサービスを実現するために、イングレスと複製ポイント間、および各葉の間でP2P LSPを使用して実現できます。
The motivations for this type of deployment are beyond the scope of this document, but it is appropriate to examine how PCE might be used to support this model.
このタイプの展開の動機はこのドキュメントの範囲を超えていますが、このモデルをサポートするためにPCEを使用する方法を調べることが適切です。
In Figure 2, a P2MP service is required from ingress LSR a to egress LSRs m, n, o, and p. There are four replication-capable LSRs in the network: D, E, J, and K.
図2では、Ingress LSR AからEgress LSRS M、N、O、およびPへのP2MPサービスが必要です。ネットワークには、D、E、J、K。
When LSR a consults a PCE, it could be given the full P2MP path from LSR a to the leaves, but in this model, the PCE simply returns a P2P path to the first replication point (in this case, LSR D). LSR D will consult a PCE in its turn and determine the P2P LSPs to egress LSRs m and p as well as the P2P LSP to the next replication point, LSR J. Finally, LSR J will use a PCE to determine P2P LSPs to egresses n and o.
LSR AがPCEに相談すると、LSR Aから葉までの完全なP2MPパスが与えられる可能性がありますが、このモデルでは、PCEはP2Pパスを最初の複製ポイント（この場合はLSR D）に戻すだけです。LSR Dは、その順番でPCEに相談し、P2P LSPをLSRS MおよびP、P2P LSPに次の複製ポイントに脱出させます。最後に、LSR JはPCEを使用してP2P LSPを使用してP2P LSPを脱出します。およびo。
f--i--m
/
/
a--b--c--D--g--J--n
\ \
\ \
E h K o
\
\
l--p
Figure 2: Using Centralized Replication Points
図2：集中レプリケーションポイントの使用
In this model of operation, it is quite likely that the PCE function is located at the replication points, which will be high-capacity LSRs. One of the main features of the computation activity is the selection of the replication points (for example, why is LSR D selected in preference to LSR E, and why is LSR J chosen over LSR K?). This selection may be made solely on the basis of path optimization as it would be for a P2MP computation, but may also be influenced by policy issues (for example, LSR D may be able to give better security to protect against rogue leaf attachment) or network loading concerns (for example, LSR E may already be handling a very large amount of traffic replication for other P2MP services).
この動作モデルでは、PCE関数が複製ポイントに配置されている可能性が非常に高く、これは大容量のLSRになります。計算アクティビティの主な特徴の1つは、複製ポイントの選択です（たとえば、LSR DがLSR Eよりも優先されて選択され、LSR JがLSR Kよりも選択されるのはなぜですか？）。この選択は、P2MP計算のためのパス最適化に基づいてのみ行われる場合がありますが、ポリシーの問題（たとえば、LSR Dが不正な葉の添付ファイルから保護するためのより良いセキュリティを提供できる場合もあります）、またはより良いセキュリティを提供できる場合があります）ネットワークの読み込み懸念（たとえば、LSR Eは、他のP2MPサービスの非常に大量のトラフィックレプリケーションをすでに処理している可能性があります）。
Once established, P2MP LSPs are more sensitive to modification than their P2P counterparts. If an egress is removed from a P2P LSP, the whole LSP is torn down. But egresses may be added to and removed from active P2MP LSPs as receivers come and go.
P2MP LSPは確立されると、P2Pの対応物よりも変更に敏感になります。出口がP2P LSPから除去された場合、LSP全体が取り壊されます。ただし、受信機が出入りするときに、出力がアクティブなP2MP LSPに追加され、削除される場合があります。
The removal of an egress from a P2MP LSP does not require any new path computation since the tree can be automatically pruned.
P2MP LSPからの出口の除去は、ツリーを自動的に剪定できるため、新しいパス計算を必要としません。
The addition of a new egress to a P2MP LSP can be handled as the computation of an appropriate branch point and the determination of a P2P path from the branch point to the new egress. This is a relatively simple computation and can be achieved by reverse-path CSPF, much as in the manner of some multicast IP routing protocols.
P2MP LSPへの新しい出口の追加は、適切な分岐点の計算と、分岐点から新しい出力までのP2Pパスの決定として処理できます。これは比較的単純な計算であり、一部のマルチキャストIPルーティングプロトコルのように、リバースパスCSPFによって達成できます。
However, repeated addition to and removal from a P2MP LSP will almost certainly leave it in a sub-optimal state. The tree shape that was optimal for the original set of destinations will be distorted by the changes and will not be optimal for the new set of destinations.
ただし、P2MP LSPへの繰り返しの追加と除去は、ほぼ確実に最適な状態になります。元の目的地のセットに最適なツリーの形状は、変更によって歪められ、新しい宛先のセットには最適ではありません。
Further, as resource availability changes in the network due to other LSPs being released or network resources being brought online, the path of the P2MP LSP may become sub-optimal.
さらに、他のLSPがリリースされているか、ネットワークリソースがオンラインになっているため、ネットワークのリソースの可用性が変化すると、P2MP LSPのパスが最適になる可能性があります。
Computing a new optimal path for the P2MP LSP is as simple as computing any optimal P2MP path, but selecting a path that can be applied within the network as a migration from the existing LSP may be more complex. Additional constraints may be applied by the network administrator so that only subsets of the egresses (or subtrees of the P2MP tree) are optimized at any time. In these cases, the computational load of reoptimization may be considerable, but fortunately reoptimization computations may be performed as background activities. Splitting the P2MP tree into subtrees, as described in Section 3, may further reduce the computation load and may assist with administrative preferences for partial tree reoptimization.
P2MP LSPの新しい最適パスを計算することは、最適なP2MPパスを計算するのと同じくらい簡単ですが、既存のLSPからの移行としてネットワーク内で適用できるパスを選択する方が複雑になる場合があります。ネットワーク管理者が追加の制約を適用できるため、出口のサブセット（またはP2MPツリーのサブツリー）のみがいつでも最適化されます。これらの場合、再最適化の計算負荷はかなりのものかもしれませんが、幸いなことに再最適化計算はバックグラウンドアクティビティとして実行される場合があります。セクション3で説明されているように、P2MPツリーをサブツリーに分割すると、計算負荷がさらに減少し、部分ツリーの再最適化の管理選好を支援する可能性があります。
Network-wide reoptimization of multiple LSPs [RFC5557] can achieve far greater improvements in optimality within overloaded networks than can be achieved by reoptimizing LSPs sequentially. Such computation would typically be performed offline and would usually require a dedicated processor such as a PCE invoked by the NMS.
複数のLSP [RFC557]のネットワーク全体の再最適化は、LSPを順次再発現することで達成できるよりも、過負荷ネットワーク内の最適性のはるかに大きな改善を達成できます。このような計算は通常、オフラインで実行され、通常、NMSによって呼び出されるPCEなどの専用プロセッサが必要です。
LSP repair is necessary when a network fault disrupts the ability of the LSP to deliver data to an egress. For a P2MP LSP, a network fault is (statistically) likely to only impact a small subset of the total set of egresses. Repair activity, therefore, does not need to recompute the path of the entire P2MP tree. Rather, it needs to quickly find suitable new branches that can be grafted onto the existing tree to reconnect the disconnected leaves.
ネットワーク障害がLSPが出口にデータを配信する能力を破壊する場合、LSP修復が必要です。P2MP LSPの場合、ネットワーク障害は（統計的に）出口の総セットの小さなサブセットにのみ影響する可能性があります。したがって、修復活動は、P2MPツリー全体の経路を再計算する必要はありません。むしろ、既存のツリーに接ぎ木して、切断された葉を再接続できる適切な新しい枝をすばやく見つける必要があります。
In fact, immediately after a network failure there may be a very large number of path computations required in order to restore multiple P2P and P2MP LSPs. The PCEs will be heavily loaded, and it is important that computation requests are restricted to only the 'essential'.
実際、ネットワークの障害の直後に、複数のP2PおよびP2MP LSPを復元するために必要な非常に多くのパス計算が必要になる場合があります。PCESは重度にロードされ、計算リクエストが「必須」のみに制限されることが重要です。
In this light, it is useful to note that the simple repair computations described in the first paragraph of this section may be applied to achieve a first repair of the LSPs, while more sophisticated reoptimization computations can be deferred until the network is stable and the load on the PCEs has been reduced. Those reoptimizations can be computed as described in Section 5.
この観点から、このセクションの最初の段落で説明されている簡単な修復計算を適用してLSPの最初の修復を実現することができますが、より洗練された再最適化計算は、ネットワークが安定して負荷になるまで延期できます。PCESは減少しました。これらの再最適化は、セクション5で説明されているように計算できます。
Disjoint paths are required for end-to-end protection services and sometimes for load balancing. They may require to be fully disjoint (except at the ingress and egress!), link disjoint (allowing common nodes on the paths), or best-effort disjoint (allowing shared links or nodes when no other path can be found).
エンドツーエンドの保護サービス、時には負荷分散には、隔離パスが必要です。彼らは、完全にばらばらであることを要求する場合があります（入り口と出口を除いて！）、リンクの分離（パスの一般的なノードを許可）、または最良の否定（他のパスが見つからない場合は共有リンクまたはノードを許可します）。
It is possible to compute disjoint paths sequentially, but this can lead to blocking problems where the second path cannot be placed. Such issues are more readily avoided if the paths are computed in parallel.
馬鹿げたパスを順番に計算することは可能ですが、これは2番目のパスを配置できない場合のブロッキング問題につながる可能性があります。パスが並行して計算されると、このような問題はより容易に回避されます。
The computation of link disjoint P2P paths may be non-trivial and may be the sort of task that an LSR offloads to a PCE because of its complexity. The computation of disjoint P2MP paths is considerably more difficult and is therefore a good candidate to be offloaded to a PCE that has dedicated resources. In fact, it may well be the case that not all P2MP-capable PCEs can handle disjoint path requests and it may be necessary to select between PCEs based on their capabilities.
リンクの分離P2Pパスの計算は、自明ではない場合があり、LSRがその複雑さのためにPCEにオフロードするようなタスクである可能性があります。馬鹿げたP2MPパスの計算はかなり困難であるため、専用のリソースを持つPCEにオフロードされるのに適した候補です。実際、すべてのP2MP対応PCEが馬鹿げたパス要求を処理できるわけではなく、機能に基づいてPCEを選択する必要がある場合があります。
The use of PCE to compute P2MP paths has many of the same manageability considerations as when it is used for P2P LSPs [RFC5440]. There may be additional manageability implications for the size of P2MP computation requests and the additional loading exerted on the PCEs.
P2MPパスを計算するためにPCEを使用するには、P2P LSP [RFC5440]に使用される場合と同じ管理可能性の考慮事項の多くがあります。P2MP計算リクエストのサイズと、PCESに加えられた追加の負荷には、追加の管理可能性への影響がある場合があります。
As already described, individual PCEs may choose to not be capable of P2MP computation, and where this function is available, it may be disabled by an operator, or may be automatically withdrawn when the PCE becomes loaded or based on other policy considerations.
すでに説明されているように、個々のPCEはP2MP計算が能力がないことを選択する場合があり、この関数が利用可能な場合、オペレーターによって無効になる場合があります。また、PCEがロードされたときに自動的に撤回されたり、他のポリシーの考慮事項に基づいて撤回されたりする場合があります。
Further, a PCE may refuse any P2MP computation request or pass it on to another PCE based on policy.
さらに、PCEは、P2MPの計算要求を拒否するか、ポリシーに基づいて別のPCEに渡すことがあります。
P2MP computation requests necessitate considerably more information exchange between the LSR and the PCE than is required for P2P computations. This will result in much larger data sets to be controlled and modeled, and will impact the utility of any management data models, such as MIB modules. Care needs to be taken in the design of such data models, and the use of other management protocols and data modeling structures, such as NETCONF [RFC4741] and the NETCONF Data Modeling Language (NETMOD), could be considered.
PCE liveness detection and monitoring is unchanged from P2P operation, but it should be noted that P2MP requests will take longer to process than P2P requests, meaning that the time between request and response will be, on average, longer. This increases the chance of a communications failure between request and response and means that liveness detection is more important.
PCE Livensionの検出と監視はP2P操作から変更されていませんが、P2MPリクエストはP2P要求よりも処理に時間がかかることに注意する必要があります。つまり、リクエストと応答の間の時間は平均して長くなります。これにより、リクエストと応答の間の通信障害の可能性が高まり、liveness liveness検出がより重要であることを意味します。
Correct operation of any communication between LSRs and PCEs is exactly as important as it is for P2P computations.
LSRとPCES間の通信の正しい動作は、P2P計算と同じくらい重要です。
The correct operation of path computation algorithms implemented at PCEs is out of scope, but LSRs that are concerned that PCE algorithms might not be operating correctly may make identical requests to separate PCEs and compare the responses.
PCESで実装されたパス計算アルゴリズムの正しい操作は範囲外ですが、PCEアルゴリズムが正しく動作していない可能性があることを懸念しているLSRは、PCESを分離して応答を比較するために同一の要求を行う可能性があります。
As is clear from the PCE architecture, a communications protocol is necessary to allow LSRs to send computation requests to PCEs and for PCEs to cooperate. Requirements for such a protocol to handle P2P path computations are described in [RFC4657], and additional requirements in support of P2MP computations are described in [PCE-P2MP]. The PCE Communication Protocol (PCEP) is defined in [RFC5440], but extensions will be necessary to support P2MP computation requests.
PCEアーキテクチャから明らかなように、LSRがPCESに計算リクエストを送信し、PCESが協力できるようにするには、通信プロトコルが必要です。P2Pパス計算を処理するためのこのようなプロトコルの要件は[RFC4657]で説明されており、P2MP計算をサポートする追加要件は[PCE-P2MP]で説明されています。PCE通信プロトコル（PCEP）は[RFC5440]で定義されていますが、P2MP計算要求をサポートするには拡張機能が必要です。
As described in the body of this document, LSRs need to be able to recognize which PCEs can perform P2MP computations. Capability advertisement is already present in the PCE Discovery protocols ([RFC5088] and [RFC5089]) and can also be exchanged in PCEP ([RFC5440]), but extensions will be required to describe P2MP capabilities.
このドキュメントの本文で説明されているように、LSRはどのPCEがP2MP計算を実行できるかを認識できる必要があります。機能広告は、PCEディスカバリープロトコル（[RFC5088]および[RFC5089]）にすでに存在し、PCEP（[RFC5440]）で交換することもできますが、P2MP機能を説明するには拡張が必要です。
As also described in this document, the PCE needs to know the branch capabilities of the LSRs and store this information in the TED. This information can be distributed using the routing protocols as described in [RFC5073].
このドキュメントで説明されているように、PCEはLSRのブランチ機能を知り、この情報をTEDに保存する必要があります。この情報は、[RFC5073]で説明されているように、ルーティングプロトコルを使用して配布できます。
The use of a PCE to perform P2MP computations may have a beneficial impact on network operation if it can offload processing from the LSRs, freeing them up to handle protocol operations.
P2MP計算を実行するためにPCEの使用は、LSRから処理をオフロードできる場合、ネットワーク操作に有益な影響を与える可能性があり、プロトコル操作を処理するためにそれらを解放します。
Furthermore, the use of a PCE may enable more dynamic behavior in P2MP LSPs (such as the addition of new egresses, reoptimization, and failure recovery) than is possible using more traditional management-based planning techniques.
さらに、PCEを使用すると、より従来の管理ベースの計画手法を使用して可能なP2MP LSP（新しい出口、再発現、障害回復など）でより動的な動作を可能にする可能性があります。
The use of PCE to compute P2MP paths does not raise any additional security issues beyond those that generally apply to the PCE architecture. See [RFC4655] for a full discussion.
P2MPパスを計算するためにPCEを使用しても、PCEアーキテクチャに一般的に適用されるものを超える追加のセキュリティ問題は発生しません。完全な議論については、[RFC4655]を参照してください。
Note, however, that P2MP computation requests are more CPU-intensive and also use more link bandwidth. Therefore, if the PCE was attacked by the injection of spurious path computation requests, it would be more vulnerable through a smaller number of such requests.
ただし、P2MP計算要求はCPU集約型であり、より多くのリンク帯域幅を使用することに注意してください。したがって、PCEがスプリアスパス計算リクエストの注入によって攻撃された場合、そのようなリクエストの数が少ないことにより、より脆弱になります。
Thus, the use of message integrity and authentication mechanisms within the PCE protocol should be used to mitigate attacks from devices that are not authorized to send requests to the PCE. It would be possible to consider applying different authorization policies for P2MP path computation requests compared to other requests.
したがって、PCEプロトコル内のメッセージの整合性と認証メカニズムの使用を使用して、PCEにリクエストを送信することが許可されていないデバイスからの攻撃を軽減する必要があります。他の要求と比較して、P2MPパス計算要求に異なる承認ポリシーを適用することを検討することができます。
The authors would like to thank Jerry Ash and Jean-Louis Le Roux for their thoughtful comments. Lars Eggert, Dan Romascanu, and Tim Polk provided useful comments during IESG review.
著者は、Jerry AshとJean-Louis Le Rouxの思慮深いコメントに感謝したいと思います。Lars Eggert、Dan Romascanu、およびTim Polkは、IESGレビュー中に有用なコメントを提供しました。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] Yasukawa、S.、ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] Enns、R.、ed。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834] Morin、T.、ed。、「レイヤー3プロバイダープロビジョニング仮想ネットワーク（PPVPNS）のマルチキャストの要件」、RFC 4834、2007年4月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.
[RFC5073] Vasseur、J.、ed。、およびJ. Le Roux、ed。、「トラフィックエンジニアリング機能の発見のためのIGPルーティングプロトコル拡張」、RFC 5073、2007年12月。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088] Le Roux、Jl。、ed。、vasseur、Jp。、ed。、ikejiri、Y.、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、RFC 5088、2008年1月。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089] Le Roux、Jl。、ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、およびR. Zhang、「IS-IS Path Computation Element（PCE）DiscoveryのIS-ISプロトコル拡張」、RFC 5089、1月2008年。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「ポリシー対応パス計算フレームワーク」、RFC 5394、2008年12月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、Jp。、ed。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短制約されたドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009.
[RFC5557] Lee、Y.、Le Roux、Jl。、King、D。、およびE. oki、「パス計算要素通信プロトコル（PCEP）要件とプロトコル拡張は、グローバルな同時最適化をサポートする」、RFC 5557、2009年7月。
[PCE-P2MP] Yasukawa, S., and Farrel, A., "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Work in Progress, May 2008.
[PCE-P2MP] Yasukawa、S。、およびFarrel、A。、「ポイントからマルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS-TE）のPCC-PCE通信要件」、2008年5月の作業。
Authors' Addresses
著者のアドレス
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan
Seisho Yasukawa NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585、日本
EMail: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
EMail: adrian@olddog.co.uk