[要約] RFC 6245は、Mobile IPv4における汎用ルーティングカプセル化(GRE)キー拡張に関する仕様です。このRFCの目的は、Mobile IPv4ネットワークでGREキー拡張を使用するための標準化と指針を提供することです。
Internet Engineering Task Force (IETF) P. Yegani Request for Comments: 6245 Juniper Networks Category: Standards Track K. Leung ISSN: 2070-1721 Cisco Systems A. Lior Bridgewater Systems K. Chowdhury J. Navali Cisco Systems May 2011
Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4
モバイルIPv4の一般的なルーティングカプセル化(GRE)キー拡張機能
Abstract
概要
The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses. When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling.
汎用ルーティングカプセル化(GRE)仕様には、特定のGREデータストリームを識別するために使用される値が含まれる可能性のあるキーフィールドが含まれています。この仕様は、GREキーフィールドで使用する値を交換するために使用される新しいモバイルIP拡張機能を定義します。この拡張機能により、モバイルノードトラフィックを受信する前に、モビリティエージェントが必要なプロトコルインターフェイスを設定することができます。新しい拡張機能により、外国人エージェントは、モバイルIPv4に指定されたホームエージェントの動作を乱すことなくGREトンネルを要求できます。キーフィールドを使用したGREトンネルにより、オペレーターは複数の仮想プライベートネットワーク(VPN)で構成されるホームネットワークを持つことができます。Tuple <住所、ホームアドレス、およびホームエージェントアドレスのケア>が複数のサブスクライバーセッションで同じ場合、GREトンネリングは、外国人エージェントとホームエージェントがGREキーに基づいて個々のセッションのデータストリームを特定する手段を提供します。このキー識別子がない場合、データストリームは互いに区別することはできません。これは、IP-in-IPトンネリングを使用する場合の重要な欠点です。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ(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/rfc6245.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc6245で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2011 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ドキュメント(http://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2 2. Terminology .....................................................3 3. GRE Key Extension ...............................................3 4. Operation and Use of the GRE Key Extension ......................3 4.1. Foreign Agent Requirements for GRE Tunneling Support .......3 4.2. Home Agent Requirements for GRE Tunneling Support ..........4 4.3. Mobile Node Requirements for GRE Tunneling Support .........5 5. GRE Key Extension and Tunneling Procedures ......................5 6. IANA Considerations .............................................6 7. Security Considerations .........................................6 8. Acknowledgements ................................................7 9. Normative References ............................................7
This document specifies a new extension for use by a Foreign Agent (FA) operating Mobile IP for IPv4. The new extension allows a Foreign Agent to request Generic Routing Encapsulation (GRE) [RFC2784] tunneling without disturbing the Home Agent (HA) behavior specified for Mobile IPv4 [RFC5944]. This extension contains the GRE key [RFC2890] required for establishing a GRE tunnel between the FA and the HA.
このドキュメントは、IPv4のモバイルIPを操作する外国人エージェント(FA)が使用するための新しい拡張機能を指定します。新しい拡張機能により、外国人エージェントは、モバイルIPv4 [RFC5944]に指定されたホームエージェント(HA)の動作を乱すことなく、ジェネリックルーティングカプセル化(GRE)[RFC2784]トンネリングを要求できます。この拡張には、FAとHAの間にGREトンネルを確立するために必要なGREキー[RFC2890]が含まれています。
GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses. When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across multiple subscriber sessions, GRE tunneling will provide a means for the FA and the HA to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling.
キーフィールドを使用したGREトンネルにより、オペレーターは複数の仮想プライベートネットワーク(VPN)で構成されるホームネットワークを持つことができます。Tuple <住所、ホームアドレス、およびホームエージェントアドレスのケア>が複数のサブスクライバーセッションで同じ場合、GREトンネリングはFAとHAがGREキーに基づく個々のセッションのデータストリームを特定する手段を提供します。このキー識別子がない場合、データストリームは互いに区別することはできません。これは、IP-in-IPトンネリングを使用する場合の重要な欠点です。
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]. Other terminology is used as already defined in [RFC5944].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。他の用語は、[RFC5944]ですでに定義されているように使用されています。
The format of the GRE Key Extension conforms to the extension format specified for Mobile IPv4 [RFC5944]. This extension option is used by the Foreign Agent to supply GRE key and other necessary information to the Home Agent to establish a GRE tunnel between the FA and the HA.
GREキー拡張の形式は、モバイルIPv4 [RFC5944]に指定された拡張形式に準拠しています。この拡張オプションは、外国人エージェントがGREキーやその他の必要な情報をホームエージェントに提供して、FAとHAの間にGREトンネルを確立するために使用されます。
The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4 [RFC5944]. The FA may support GRE tunneling that can be used, for example, to allow for overlapping private home IP addresses (Section 4.2.2.5 of [X.S0011-E]). If the FA is capable of supporting GRE encapsulation, it should set the 'G' (GRE encapsulation) bit in the Flags field in the Agent Advertisement message sent to the Mobile Node (MN) during the Mobile IP session establishment.
FAは、モバイルIPv4 [RFC5944]のデータグラムのIP-in-IPトンネルをサポートする必要があります。FAは、たとえば、プライベートホームIPアドレスのオーバーラップを可能にするために使用できるGREトンネルをサポートする場合があります([X.S0011-E]のセクション4.2.2.5)。FAがGREカプセル化をサポートできる場合、モバイルIPセッションの確立中にモバイルノード(MN)に送信されたエージェント広告メッセージのフラグフィールドに「G」(GREカプセル化)ビットを設定する必要があります。
If the MN does not set the 'G' bit, the FA MAY fall back to using IP-in-IP encapsulation for the session per [RFC5944].
MNが「G」ビットを設定しない場合、FAは[RFC5944]ごとにセッションのIP-in-IPカプセル化の使用に戻る可能性があります。
If the MN does not set the 'G' bit and does not set the 'D' (Decapsulation by mobile node) bit (i.e., the mobile node does not request GRE tunneling and is not using a co-located care-of address), and the local policy allows the FA to override the 'G' bit setting received from the MN, the FA MUST include the GRE Key Extension as defined in this memo in the Registration Request (RRQ) that it propagates to the HA. The presence of this extension is a request for GRE encapsulation that takes precedence over the setting of the 'G' bit in the Registration Request. The FA MUST NOT modify the 'G' bit in the Registration Request because it is protected by the Mobile-Home Authentication extension.
MNが「G」ビットを設定せず、「D」(モバイルノードによる脱カプセル化)ビットを設定しない場合(つまり、モバイルノードはGREトンネリングを要求せず、共同配置されたケアオブアドレスを使用していません)また、ローカルポリシーにより、FAはMNから受信した「G」ビット設定をオーバーライドすることができます。FAは、HAに伝播する登録要求(RRQ)のこのメモで定義されているGREキー拡張機能を含める必要があります。この拡張機能の存在は、登録要求の「G」ビットの設定よりも優先されるGREカプセル化の要求です。FAは、モバイルホーム認証拡張機能によって保護されているため、登録要求で「G」ビットを変更してはなりません。
If the FA does not support GRE encapsulation, the FA MUST reset the 'G' bit in the Agent Advertisement message. In this case, if the MN sets the 'G' bit in the Registration Request message, the FA returns a Registration Reply (RRP) message to the MN with code 'requested encapsulation unavailable' (72) per [RFC5944].
FAがGREのカプセル化をサポートしていない場合、FAはエージェント広告メッセージに「G」ビットをリセットする必要があります。この場合、MNが登録要求メッセージに「G」ビットを設定すると、FAは登録返信(RRP)メッセージをMNに返信します。
If the FA allows GRE encapsulation, and either the MN requested GRE encapsulation or local policy dictates using GRE encapsulation for the session, and the 'D' bit is not set (i.e., the mobile node is not using a co-located care-of address), the FA MUST include the GRE Key in the GRE Key Extension in all Mobile IP Registration Requests (including initial, renewal, and de-registration requests) before forwarding the request to the HA. The FA may include a GRE key of value zero in the GRE Key Extension to signal that the HA assigns GRE keys in both directions. The GRE key assignment in the FA and the HA is outside the scope of this memo.
FAがGREのカプセル化を許可し、MNがセッションのGREカプセル化を使用してGREのカプセル化を要求するか、ローカルポリシーが「D」ビットが設定されていない場合(つまり、モバイルノードは共同ロケートのケアを使用していませんアドレス)、FAは、リクエストをHAに転送する前に、すべてのモバイルIP登録要求(初期、更新、および登録解除リクエストを含む)にGREキー拡張機能にGREキーを含める必要があります。FAには、GREキーエクステンションに値ゼロのGREキーが含まれている場合があり、HAが両方向にGREキーを割り当てることを示します。FAとHAのGREキー割り当ては、このメモの範囲外です。
The GRE Key Extension SHALL follow the format defined in [RFC5944]. This extension SHALL be added after the MN-HA and MN-FA Challenge and MN-AAA (Mobile Node - Authentication, Authorization, and Accounting) extensions (if any) and before the FA-HA Auth extension (if any).
GREキー拡張は、[RFC5944]で定義されている形式に従うものとします。この拡張機能は、MN-HAおよびMN-FAチャレンジおよびMN-AAA(モバイルノード - 認証、認証、および会計)拡張(存在する場合)およびFA-HA Auth拡張の前(ある場合)の後に追加されます。
The HA MUST follow the procedures specified in [RFC5944] in processing this extension in Registration Request messages.
HAは、[RFC5944]で指定された手順に従って、登録要求メッセージでこの拡張機能を処理する必要があります。
If the HA receives the GRE Key Extension in a Registration Request and does not recognize this non-skippable extension, it MUST silently discard the message. The HA MUST use other alternative forms of encapsulation (e.g., IP-in-IP tunneling), when requested by the mobile node per [RFC5944].
HAが登録要求でGREキー拡張機能を受け取り、このスキップ不可能な拡張機能を認識しない場合、メッセージを静かに破棄する必要があります。HAは、[RFC5944]ごとにモバイルノードで要求された場合、他の代替形式のカプセル化(例:IP-in-IPトンネリング)を使用する必要があります。
If the HA receives the GRE Key Extension in a Registration Request and recognizes the GRE Key Extension but is not configured to support GRE encapsulation, it MUST send an RRP with code 'requested encapsulation unavailable (139)' [RFC3024].
HAが登録要求でGREキー拡張機能を受信し、GREキー拡張機能を認識しているが、GREカプセル化をサポートするように構成されていない場合、コード「要求されたカプセル化は利用できない」[RFC3024]を使用してRRPを送信する必要があります。
If the HA receives a Registration Request with a GRE Key Extension but without the 'G' bit set, the HA SHOULD treat this as if the 'G' bit is set in the Registration Request; i.e., the presence of a GRE Key Extension indicates a request for GRE encapsulation.
HAがGREキーエクステンションで登録要求を受け取ったが、「G」ビットセットがない場合、HAは登録要求に「G」ビットが設定されているかのようにこれを扱う必要があります。つまり、GREキー拡張の存在は、GREカプセル化の要求を示しています。
If the HA receives the GRE Key Extension in a Registration Request, and it recognizes the GRE Key Extension as well as supports GRE encapsulation, the following procedures should apply: o The HA SHOULD accept the RRQ and send an RRP with code 'registration accepted (0)'.
HAが登録要求でGREキー拡張機能を受信し、GREキー拡張機能とGREカプセル化をサポートする場合、次の手順を適用する必要があります。OHAはRRQを受け入れ、コード '登録を受け入れたRRPを送信する必要があります。0) '。
o The HA MUST assign a GRE key and include the GRE Key Extension in the RRP before sending it to the FA.
o HAはGREキーを割り当て、FAに送信する前にRRPにGREキー拡張機能を含める必要があります。
o The HA MUST include the GRE Key Extension in all RRPs in response to any RRQ that included the GRE Key Extension, when a GRE key is available for the registration.
o HAには、GREキーが登録に使用できる場合、GREキー拡張機能を含む任意のRRQに応じて、すべてのRRPにGREキー拡張機能を含める必要があります。
If the HA receives the GRE Key Extension in the initial Registration Request and recognizes the GRE Key Extension carrying a GRE key value of zero, it SHOULD accept the RRQ and send an RRP with code 'registration accepted (0)', and the following procedures apply:
HAが最初の登録要求でGREキー拡張機能を受信し、ゼロのGREキー値を運ぶGREキーエクステンションを認識している場合、RRQを受け入れ、コード「登録が受け入れられた(0)」と次の手順でRRPを送信する必要があります。申し込み:
o The HA MUST assign GRE keys for both directions and include these keys in the GRE Key Extension in the RRP before sending it to the FA.
o HAは、両方向にGREキーを割り当て、FAに送信する前にRRPのGREキーエクステンションにこれらのキーを含める必要があります。
o The HA MUST include the GRE Key Extension in the RRP in response to the initial RRQ that included the GRE Key Extension, when a GRE key is available for the registration.
o HAには、GREキーが登録に使用できる場合、GREキー拡張機能を含む初期RRQに応じて、RRPにGREキー拡張機能を含める必要があります。
If the MN is capable of supporting GRE encapsulation, it SHOULD set the 'G' bit in the Flags field in the Registration Request per [RFC5944].
MNがGREカプセル化をサポートできる場合、[RFC5944]ごとに登録要求のフラグフィールドに「G」ビットを設定する必要があります。
GRE tunneling support for Mobile IP will permit asymmetric GRE keying; i.e., the FA assigns a GRE key for use in encapsulated traffic, and the HA can assign its own GRE key. Once the GRE keys have been exchanged, the FA uses the HA-assigned key in the encapsulating GRE header for reverse tunneling, and the HA uses the FA-assigned key in the encapsulating GRE header.
モバイルIPのトンネルサポートは、非対称GREキーイングを可能にします。つまり、FAはカプセル化されたトラフィックで使用するためのGREキーを割り当て、HAは独自のGREキーを割り当てることができます。GREキーが交換されると、FAは逆トンネリングのためにカプセル化GREヘッダーのHA割り当てされたキーを使用し、HAはカプセル化GREヘッダーのFA割り当てされたキーを使用します。
The format of the GRE Key Extension is as shown below.
GREキーエクステンションの形式は、以下に示すとおりです。
The GRE Key Extension MAY be included in Registration Requests or Registration Replies [RFC5944]. The GRE Key Extension is used to inform the recipient of the Mobile IP request of the value to be used in the GRE Key field.
GREキーエクステンションは、登録リクエストまたは登録返信に含まれる場合があります[RFC5944]。GREキー拡張機能は、GREキーフィールドで使用される値のモバイルIP要求を受信者に通知するために使用されます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: GRE Key Extension
図1:GREキーエクステンション
Type
タイプ
48 - An 8-bit identifier of the GRE Key Extension type (non-skippable)
48-GREキーエクステンションタイプの8ビット識別子(スキップできない)
Sub-Type
サブタイプ
0
0
Length
長さ
4
4
Key Identifier
キー識別子
This is a four-octet value assigned during registration and inserted in every GRE packet of the user traffic.
これは、登録中に割り当てられ、ユーザートラフィックのすべてのGREパケットに挿入された4オクテット値です。
The GRE Key Extension defined in this memo is a Mobile IP extension as defined in [RFC5944]. IANA has assigned a Type value (48) for this extension from the non-skippable range (0-127).
このメモで定義されているGREキー拡張は、[RFC5944]で定義されているモバイルIP拡張です。IANAは、この拡張に対して、スキップ不可の範囲(0-127)からこの拡張にタイプ値(48)を割り当てました。
The GRE Key Extension introduces a new sub-type numbering space, where the value 0 has been assigned from the range 0 to 255. Approval of new GRE Key Extension sub-type values is to be made through Expert Review with Specification Required.
GREキー拡張では、値0が0から255の範囲から割り当てられている新しいサブタイプの番号付けスペースを導入します。新しいGREキーエクステンションサブタイプの値の承認は、必要な仕様とともに専門家のレビューを通じて行われます。
This specification does not introduce any new security considerations, beyond those described in [RFC5944].
この仕様では、[RFC5944]に記載されているものを超えて、新しいセキュリティ上の考慮事項は導入されません。
Despite its name, the GRE Key Extension has little to do with security. The word "Key" here is not used in the cryptographic sense of a shared secret that must be protected but rather in the sense of an "index" or demultiplexing value that can be used to distinguish packets belonging to a given flow within a GRE tunnel.
その名前にもかかわらず、GREキーエクステンションはセキュリティとはほとんど関係ありません。ここでの「キー」という言葉は、保護されなければならない共有された秘密の暗号化の意味ではなく、むしろ、グリーンネル内の特定のフローに属するパケットを区別するために使用できる「インデックス」または非複数の値の意味で使用されます。
Thanks to Jun Wang, Gopal Dommety, and Sri Gundavelli for their helpful comments, offline discussions, and review of the initial draft version of this document. Also, Pete McCann and Simon Mizikovsky provided valuable review comments.
Jun Wang、Gopal Dommety、およびSri Gundavelliに、このドキュメントの最初のドラフトバージョンの有益なコメント、オフラインディスカッション、レビューに感謝します。また、ピート・マッキャンとサイモン・ミジコフスキーは貴重なレビューのコメントを提供しました。
[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月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化(GRE)」、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G。、「Key and Sequence Number GREへの拡張」、RFC 2890、2000年9月。
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G。、編、「モバイルIPの逆トンネル、改訂」、RFC 3024、2001年1月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944] Perkins、C.、ed。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年11月。
[X.S0011-E] 3rd Generation Partnership Project 2, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services", 3GPP2 X.S0011-002-E Version 1.0, November 2009, <http://www.3gpp2.org/Public_html/specs/ X.S0011-002-E_v1.0_091116.pdf>.
[X.S0011-E]第3世代パートナーシッププロジェクト2、「CDMA2000ワイヤレスIPネットワーク標準:シンプルIPおよびモバイルIPアクセスサービス」、3GPP2 X.S0011-002-Eバージョン1.0、2009年11月、<http:// www。3gpp2.org/public_html/specs/ x.s0011-002-e_v1.0_091116.pdf>。
Authors' Addresses
著者のアドレス
Parviz Yegani Juniper Networks 1194 North Mathilda Ave. Sunnyvale, California 94089 USA Phone: +1 408-759-1973 EMail: pyegani@juniper.net
Parviz Yegani Juniper Networks 1194 North Mathilda Ave. Sunnyvale、California 94089 USA電話:1 408-759-1973メール:pyegani@juniper.net
Kent Leung Cisco Systems Incorporated 170 West Tasman Drive San Jose, California 95134 USA Phone: +1 408 526 5030 EMail: kleung@cisco.com
Kent Leung Cisco Systems Incorporated 170 West Tasman Drive San Jose、California 95134 USA電話:1 408 526 5030メール:kleung@cisco.com
Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 EMail: avi@bridgewatersystems.com
Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa、オンタリオK2K 3J1カナダ電話:1 613-591-6655メール:avi@bridgewatersystems.com
Kuntal Chowdhury Cisco Systems Incorporated 170 West Tasman Drive San Jose, California 95134 USA EMail: kchowdhu@cisco.com
Kuntal Chowdhury Cisco Systems Incorporated 170 West Tasman Drive San Jose、California 95134 USAメール:kchowdhu@cisco.com
Jay Navali Cisco Systems Incorporated 170 West Tasman Drive San Jose, California 95134 USA EMail: jnavali@cisco.com
Jay Navali Cisco Systems Incorporated 170 West Tasman Drive San Jose、California 95134 USAメール:jnavali@cisco.com