[要約] RFC 6769は、S-VA（Simple Virtual Aggregation）の概要と目的を説明しています。S-VAは、ネットワークのアグリゲーションを簡素化するための手法であり、ルーティングテーブルのサイズを削減し、ネットワークの効率性を向上させることを目指しています。
Internet Engineering Task Force (IETF) R. Raszuk
Request for Comments: 6769 NTT MCL
Category: Informational J. Heitz
ISSN: 2070-1721 Ericsson
A. Lo
Arista
L. Zhang
UCLA
X. Xu
Huawei
October 2012
Simple Virtual Aggregation (S-VA)
シンプル仮想アグリゲーション（S-VA）
Abstract
概要
All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).
デフォルトフリーゾーン（DFZ）のすべてのBGPルーターは、デフォルトフリールーティングテーブル（DFRT）のすべてのルートを伝送する必要があります。このドキュメントでは、一部のBGPルーターがこれらすべてのルートを転送情報ベース（FIB）にインストールできないようにする手法、Simple Virtual Aggregation（S-VA）について説明します。
Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.
自律システム（AS）内の一部のルーターは、既にアナウンスしたルートに加えて、集約（VAプレフィックス）をアナウンスします。これにより、他のルーターは、VAプレフィックスと同じネクストホップを持っている限り、VAプレフィックスでカバーされるルートをFIBにインストールできません。
The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling.
AS内でアナウンスされるVAプレフィックスは、他のASにはアナウンスされません。ここで説明する機能は、ネットワーク全体の構成やドメイン内トンネリングの形式の要件に依存することなく、限定されたBGPスピーカーソリューションを提案するため、操作の複雑さが非常に低くなります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6769.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6769で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope of This Document .....................................3
1.2. Requirements Notation ......................................3
1.3. Terminology ................................................3
2. Operation of S-VA ...............................................4
3. Deployment Considerations .......................................6
4. Security Considerations .........................................7
5. Acknowledgements ................................................7
6. Normative References ............................................7
7. Informative References ..........................................7
This document describes a technique called Simple Virtual Aggregation (S-VA). It allows some routers not to store some routes in the Forwarding Information Base (FIB) while still advertising and receiving the full Default-Free Routing Table (DFRT) in BGP.
このドキュメントでは、Simple Virtual Aggregation（S-VA）と呼ばれる手法について説明します。これにより、一部のルーターはBGPで完全なデフォルトフリールーティングテーブル（DFRT）をアドバタイズおよび受信しながら、一部のルートを転送情報ベース（FIB）に格納できなくなります。
A typical scenario is as follows. Core routers in the ISP maintain the full DFRT in the FIB and Routing Information Base (RIB). Edge routers maintain the full DFRT in the BGP Local RIB (Loc-RIB), but do not install certain routes in the RIB and FIB. Edge routers may install a default route to core routers, to Area Border Routers (ABR) that are installed on the Point of Presence (POP), to core boundary routers, or to Autonomous System Border Routers (ASBRs).
典型的なシナリオは次のとおりです。 ISPのコアルーターは、FIBとルーティング情報ベース（RIB）で完全なDFRTを維持します。エッジルーターは、BGPローカルRIB（Loc-RIB）で完全なDFRTを維持しますが、RIBおよびFIBに特定のルートをインストールしません。エッジルーターは、コアルーター、Point of Presence（POP）にインストールされているエリアボーダールーター（ABR）、コア境界ルーター、または自律システムボーダールーター（ASBR）への既定のルートをインストールできます。
S-VA must be enabled on an edge router that needs to save its RIB and FIB space. The core routers must announce a new prefix called Virtual Aggregate (VA prefix).
S-VAは、RIBおよびFIBスペースを節約する必要があるエッジルーターで有効にする必要があります。コアルーターは、仮想アグリゲート（VAプレフィックス）と呼ばれる新しいプレフィックスを通知する必要があります。
The VA prefix is not intended to be announced from one AS into another, only between routers of the same AS.
VAプレフィックスは、あるASから別のASにアナウンスされることを意図しておらず、同じASのルーター間でのみアナウンスされます。
S-VA can be used for both IPv4 unicast and multicast address families and IPv6 unicast and multicast address families.
S-VAは、IPv4ユニキャストおよびマルチキャストアドレスファミリーとIPv6ユニキャストおよびマルチキャストアドレスファミリーの両方に使用できます。
S-VA does not need to operate on every router in an AS.
S-VAは、AS内のすべてのルーターで動作する必要はありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
RIB/FIB-Installing Router (FIR): A router that does not suppress any routes and announces the VA prefix. Typically, a core router, a POP to core boundary router, or an ASBR would be configured as an FIR.
RIB / FIB-Installing Router（FIR）：ルートを抑制せず、VAプレフィックスをアナウンスするルーター。通常、コアルーター、POPからコアへの境界ルーター、またはASBRはFIRとして構成されます。
RIB/FIB-Suppressing Router (FSR): An S-VA router that installs the VA prefix, but does not install routes that are covered by and have the same next-hop as the VA prefix into its FIB. Typically, an edge router would be configured as an FSR.
RIB / FIB-Suppressingルーター（FSR）：VAプレフィックスをインストールしますが、FIBへのVAプレフィックスと同じネクストホップでカバーされ、同じネクストホップを持つルートをインストールしません。通常、エッジルーターはFSRとして構成されます。
Suppress: Not to install a route that is covered by the VA prefix into the global RIB or FIB.
抑制：VAプレフィックスでカバーされるルートをグローバルRIBまたはFIBにインストールしません。
Legacy Router: A router that does not run S-VA and has no knowledge of S-VA.
レガシールーター：S-VAを実行せず、S-VAを認識しないルーター。
Global Routing Information Base (RIB): All routing protocols in a router install their selected routes into the RIB. The routes in the RIB are used to resolve next-hops for other routes, to be redistributed to other routing protocols, and to be installed into the FIB.
グローバルルーティング情報ベース（RIB）：ルーターのすべてのルーティングプロトコルは、選択したルートをRIBにインストールします。 RIBのルートは、他のルートのネクストホップの解決、他のルーティングプロトコルへの再配布、およびFIBへのインストールに使用されます。
Local/Protocol Routing Information Base (Loc-RIB): The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process as in [RFC4271].
ローカル/プロトコルルーティング情報ベース（Loc-RIB）：Loc-RIBには、[RFC4271]のようにローカルBGPスピーカーの決定プロセスによって選択されたルートが含まれています。
NLRI: Network Layer Reachability Information [RFC4271]
NLRI：ネットワーク層到達可能性情報[RFC4271]
There are three types of routers in S-VA: FIB-Installing routers (FIR), FIB-Suppressing routers (FSR), and, optionally, legacy routers. While any router can be an FIR or an FSR, the simplest form of deployment is for AS border routers to be configured as FIRs and for customer facing edge routers to be configured as FSRs.
S-VAには3種類のルーターがあります。FIB-Installingルーター（FIR）、FIB-Suppressingルーター（FSR）、およびオプションでレガシールーターです。どのルーターもFIRまたはFSRにすることができますが、展開の最も簡単な形式は、AS境界ルーターをFIRとして構成し、顧客向けエッジルーターをFSRとして構成することです。
When a FIR announces a VA prefix, it sets the path attributes as follows. The ORIGIN MUST be set to INCOMPLETE (value 2). The NEXT_HOP MUST be set to the same value as that of the routes that are intended to be covered by the VA prefix. The ATOMIC_AGGREGATE and AGGREGATOR attributes SHOULD NOT be included. The FIR MUST attach a NO_EXPORT community attribute [RFC1997]. The NLRI SHOULD be 0/0.
FIRがVAプレフィックスをアナウンスするとき、次のようにパス属性を設定します。 ORIGINはINCOMPLETE（値2）に設定する必要があります。 NEXT_HOPは、VAプレフィックスでカバーされることが意図されているルートの値と同じ値に設定する必要があります。 ATOMIC_AGGREGATEおよびAGGREGATOR属性は含まれるべきではありません。 FIRはNO_EXPORTコミュニティ属性を添付する必要があります[RFC1997]。 NLRIは0/0にする必要があります。
A FIR SHOULD NOT FIB-suppress any routes.
FIRはどのルートもFIB抑制しないでください。
An FSR must detect the VA prefix or prefixes (including 0/0) and install them in all of Loc-RIB, RIB, and FIB. The FSR MAY suppress any more-specific routes that carry the same next-hop as the VA prefix.
FSRは、VAプレフィックス（0/0を含む）を検出し、それらをすべてのLoc-RIB、RIB、およびFIBにインストールする必要があります。 FSRは、VAプレフィックスと同じネクストホップを運ぶより具体的なルートを抑制してもよい（MAY）。
Generally, any more-specific route that carries the same next-hop as the VA prefix is eligible for suppression. However, provided that there is at least one less-specific prefix with a different next-hop between the VA prefix and the suppressed prefixes, then those suppressed prefixes must be reinstalled.
一般に、VAプレフィックスと同じネクストホップを伝送するより具体的なルートは、抑制に適しています。ただし、VAプレフィックスと抑制されたプレフィックスの間に、次のホップが異なる、特定性の低いプレフィックスが少なくとも1つある場合は、抑制されたプレフィックスを再インストールする必要があります。
An example with three prefixes can be considered where the VA-prefix (prefix 1) is the least specific and covers prefix 2 and prefix 3.
VAプレフィックス（プレフィックス1）が最も限定的でなく、プレフィックス2とプレフィックス3をカバーする3つのプレフィックスを持つ例を検討できます。
Prefix 2 is less specific than prefix 3 and covers the latter. If all three have the same next-hop, then only the bigger one, i.e., VA-Prefix, is announced. However, if prefix 2 has a different next-hop, then it will need to be announced separately. In this case, it is important to also announce prefix 3 separately.
プレフィックス2はプレフィックス3よりも限定的ではなく、後者をカバーしています。 3つすべてに同じネクストホップがある場合、大きい方、つまりVA-Prefixだけがアナウンスされます。ただし、プレフィックス2のネクストホップが異なる場合は、個別にアナウンスする必要があります。この場合、プレフィックス3も個別にアナウンスすることが重要です。
Similarly, when Internal BGP (IBGP) multipath is enabled, and when multiple VA prefixes form a multipath, only those more-specific prefixes of which the set of next-hops are identical to the set of next-hops of the VA prefix multipath are subject to suppression.
同様に、内部BGP（IBGP）マルチパスが有効で、複数のVAプレフィックスがマルチパスを形成している場合、ネクストホップのセットがVAプレフィックスマルチパスのネクストホップのセットと同一である、より具体的なプレフィックスのみが抑制の対象となります。
The expected behavior is illustrated in Figure 1. This figure shows an AS with a FIR, FIR1, and an FSR, FSR1. FSR1 is an ASBR and is connected to two external ASBRs, EP1 and EP2.
予想される動作を図1に示します。この図は、FIR、FIR1、およびFSR、FSR1を備えたASを示しています。 FSR1はASBRであり、2つの外部ASBR、EP1とEP2に接続されています。
+------------------------------------------+
| Autonomous System | +----+
| | |EP1 |
| /---+---| |
| To ----\ +----+ +----+ / | +----+
| Other \|FIR1|----------|FSR1|/ |
|Routers /| | | |\ |
| ----/ +----+ +----+ \ | +----+
| \---+---|EP2 |
| | | |
| | +----+
+------------------------------------------+
Figure 1
図1
Suppose that FSR1 has been enabled to perform S-VA. Originally, it receives all routes from FIR1 (doing next-hop-self) as well as from EP1 and EP2. FIR1 now will advertise a VA prefix 0/0 with the next-hop set to itself. This will cause FSR1 to suppress all routes with the same next-hop as the VA prefix. However, FSR1 will not suppress any routes received from EP1 and EP2, because their next-hops are different from that of the VA prefix.
FSR1がS-VAを実行できるようになっているとします。もともとは、FIR1（next-hop-selfを実行）から、およびEP1とEP2からすべてのルートを受信します。 FIR1は、ネクストホップがそれ自体に設定されたVAプレフィックス0/0をアドバタイズします。これにより、FSR1は、VAプレフィックスと同じネクストホップを持つすべてのルートを抑制します。ただし、ネクストホップはVAプレフィックスのネクストホップとは異なるため、FSR1はEP1およびEP2から受信したルートを抑制しません。
Several FIRs may announce different S-VA prefixes. For example, in a POP, each edge router can announce into the POP an S-VA prefix that covers the addresses of the customers it services.
複数のFIRが異なるS-VAプレフィックスをアナウンスする場合があります。たとえば、POPでは、各エッジルーターは、サービスを提供する顧客のアドレスをカバーするS-VAプレフィックスをPOPに通知できます。
Several FIRs may announce the same S-VA prefix. In this case, an FSR must choose to install only one of them. For example, two redundant ASBRs, both of which announce the complete DFRT, may each also announce the default route as an S-VA prefix into the AS.
複数のFIRが同じS-VAプレフィックスをアナウンスする場合があります。この場合、FSRはそのうちの1つだけをインストールすることを選択する必要があります。たとえば、2つの冗長ASBRはどちらも完全なDFRTをアナウンスしますが、それぞれがデフォルトルートをS-VAプレフィックスとしてASにアナウンスする場合もあります。
S-VA may be used to split traffic among redundant exit routers. For example, suppose in Figure 1 that EP1 and EP2 are two redundant ASBRs that announce the complete DFRT. Each may also announce two S-VA prefixes into the AS: 0/1 and 128/1. EP1 might announce 0/1 with higher preference and EP2 might announce 128/1 with higher preference. FIR1 will now install into its FIB 0/1 pointing to EP1 and 128/1 pointing to EP2. If either EP1 or EP2 were to fail, then FSR1 would switch the traffic to the other exit router with a single FIB installation of one S-VA prefix.
S-VAを使用して、冗長出口ルーター間でトラフィックを分割できます。たとえば、図1で、EP1とEP2が完全なDFRTを通知する2つの冗長ASBRであるとします。また、ASに2つのS-VAプレフィックスをアナウンスすることもできます（0/1および128/1）。 EP1は優先度の高い0/1をアナウンスし、EP2は優先度の高い128/1をアナウンスする場合があります。 FIR1は、EP1を指すFIB 0/1およびEP2を指す128/1にインストールされます。 EP1またはEP2のいずれかで障害が発生した場合、FSR1は、1つのS-VAプレフィックスを1つのFIBインストールでトラフィックを他の出口ルーターに切り替えます。
BGP routes may be used to resolve next-hops for static routes or other BGP routes. Because the default route does not imply reachability of any destination, a router can be configured to not resolve next-hops using the default route. In this case, S-VA should not suppress a route that may be used to resolve a next-hop for another route from installation into the RIB. It may still suppress it from installation into the FIB.
BGPルートは、スタティックルートまたは他のBGPルートのネクストホップを解決するために使用できます。デフォルトルートは宛先への到達可能性を意味しないため、デフォルトルートを使用してネクストホップを解決しないようにルーターを構成できます。この場合、S-VAは、インストールからRIBへの別のルートのネクストホップを解決するために使用される可能性があるルートを抑制すべきではありません。それでも、FIBへのインストールが抑制される場合があります。
Selected BGP routes in the RIB may be redistributed to other protocols. If they no longer exist in the RIB, they will not be redistributed. This is especially important when the conditional redistribution is taking place based on the length of the prefix, community value, etc. In those cases where a redistribution policy is in place, S-VA implementation should refrain from suppressing installation into the RIB routes matching such policy. It may still suppress them from installation into the FIB.
RIBで選択されたBGPルートは、他のプロトコルに再配布される場合があります。それらがRIBに存在しない場合、それらは再配布されません。これは、プレフィックスの長さ、コミュニティ値などに基づいて条件付き再配布が行われている場合に特に重要です。再配布ポリシーが適用されている場合、S-VAの実装では、そのようなRIBルートに一致するRIBルートへのインストールを抑制しないでください。ポリシー。それでも、FIBへのインストールが抑制される場合があります。
A router may originate a network route or an aggregate route into BGP. Some addresses covered by such a route may not exist. If this router were to receive a packet for an unreachable address within an originated route, it must not send that packet to the VA prefix route. There are several ways to achieve this. One way is to have the FIR aggregate the routes instead of the FSR. Another way is to install a black hole route for the nonexistent addresses on the originating router. This issue is not specific to S-VA, but applicable to the general use of default routes.
ルーターは、ネットワークルートまたは集約ルートをBGPに発信する場合があります。このようなルートでカバーされる一部のアドレスは存在しない可能性があります。このルーターが発信ルート内の到達不能アドレスのパケットを受信する場合、そのルーターはそのパケットをVAプレフィックスルートに送信してはなりません。これを実現するにはいくつかの方法があります。 1つの方法は、FSRではなくFIRにルートを集約させることです。別の方法は、存在しないアドレス用のブラックホールルートを発信元ルーターにインストールすることです。この問題はS-VAに固有のものではありませんが、デフォルトルートの一般的な使用に該当します。
Like any aggregate, an S-VA prefix may include more address space than the sum of the prefixes it covers. As such, the S-VA prefix may provide a route for a packet for which no real destination exists. An FSR will forward such a packet to the FIR.
他の集約と同様に、S-VAプレフィックスには、対象となるプレフィックスの合計よりも多くのアドレス空間が含まれる場合があります。したがって、S-VAプレフィックスは、実際の宛先が存在しないパケットのルートを提供します。 FSRはそのようなパケットをFIRに転送します。
If an S-VA prefix changes its next-hop or is removed, then many routes may need to be downloaded into the FIB to achieve convergence.
S-VAプレフィックスがネクストホップを変更したり削除したりした場合、コンバージェンスを実現するために、多くのルートをFIBにダウンロードする必要がある場合があります。
The authors are not aware of any new security considerations due to S-VA. The local nature of the proposed optimization eliminates any external exposure of the functionality. The presence of more specifics that are used as VA prefixes is also a normal BGP behavior in current networks.
著者は、S-VAによる新しいセキュリティの考慮事項を認識していません。提案された最適化のローカルな性質により、機能が外部にさらされることがなくなります。 VAプレフィックスとして使用されるより特定の存在は、現在のネットワークにおける通常のBGP動作でもあります。
The concept for Virtual Aggregation comes from Paul Francis. In this document, the authors only simplified some aspects of its behavior to allow simpler adoption by some operators.
仮想アグリゲーションのコンセプトは、Paul Francisから来ています。このドキュメントでは、著者は一部のオペレーターがより簡単に採用できるように、その動作の一部の側面のみを簡略化しました。
The authors would like to thank Clarence Filsfils, Nick Hilliard, S. Moonesamy, and Tom Petch for their review and valuable input.
著者は、レビューと貴重な情報提供に対してClarence Filsfils、Nick Hilliard、S。Moonesamy、およびTom Petchに感謝します。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities Attribute」、RFC 1997、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
Authors' Addresses
著者のアドレス
Robert Raszuk NTT MCL 101 S Ellsworth Avenue Suite 350 San Mateo, CA 94401 USA
Robert Raszuk NTT MCL 101 S Ellsworth Avenue Suite 350 San Mateo、CA 94401 USA
EMail: robert@raszuk.net
Jakob Heitz Ericsson 300 Holger Way San Jose, CA 95134 USA
Jakob Heitz Ericsson 300 Holger Way San Jose、CA 95134 USA
EMail: jakob.heitz@ericsson.com
Alton Lo Arista Networks 5470 Great America Parkway Santa Clara, CA 95054 USA
Alton Lo Arista Networks 5470 Great America Parkway Santa Clara、CA 95054 USA
EMail: altonlo@aristanetworks.com
Lixia Zhang UCLA 3713 Boelter Hall Los Angeles, CA 90095 USA
l私は張UCLA 3713 boe老人ホールロサンゼルス、カリフォルニア90095米国を使用しました
EMail: lixia@cs.ucla.edu
Xiaohu Xu Huawei Technologies Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing 100085 P.R. China
ξアウトバックXええとUAはhu Aが構築している技術、no.3 XはRDです。shang-DI情報産業基盤、h love-Dイアン地区北京100085 P.R.中国
Phone: +86 10 82836073
EMail: xuxh@huawei.com