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
汎用ルーティングカプセル化（GRE）モバイルIPv4の主な拡張
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）、から構成ホームネットワークを持つことができます。タプル<アドレスのケア、ホームアドレス、ホームエージェントアドレス>は、複数の加入者セッション間で同じである場合には、GREトンネリングはGREキーに基づいて個々のセッションのためのデータストリームを識別するために、外部エージェントとホームエージェントのための手段を提供します。 IPイン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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）、から構成ホームネットワークを持つことができます。タプル<アドレスのケア、ホームアドレス、ホームエージェントアドレス>は、複数の加入者セッション間で同じである場合には、GREトンネリングは、FAとHAは、GREキーに基づいて個々のセッションのためのデータストリームを識別するための手段を提供します。 IPイン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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]に指定された拡張フォーマットに準拠しています。この拡張オプションは、FAとHA間のGREトンネルを確立するためにホームエージェントに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インIPトンネリングをサポートしなければなりません。 FAは、個人の家のIPアドレス（[X.S0011-E]のセクション4.2.2.5）をオーバーラップを可能にするために、例えば、使用することができますGREトンネリングをサポートすることができます。 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」ビットを設定しないと（すなわち、モバイルノードは、GREトンネリングを要求しないと同一位置気付アドレスを使用していない）「D」（モバイルノードによって脱カプセル化）ビットを設定していない場合それはHAに伝播することを登録要求（RRQ）で、このメモで定義され、そしてローカルポリシーは、FA「がG」ビットはMNから受信した設定オーバーライドすることができ、FAは、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は[RFC5944]あたりの（72）「利用できないカプセル化を要求した」コードとMNに登録応答（RRP）メッセージを返します。
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は、HAは、両方向にGREキーを割り当てることを知らせるためにGREキー拡張の値がゼロの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]で定義されたフォーマットに従わなければなりません。拡張機能（もしあれば）及びFA-HA認証拡張（もしあれば）前 - この拡張機能は、MN-HAとMN-FAチャレンジおよびMN-AAA（認証、許可、アカウンティングモバイルノード）の後に添加することがSHALL。
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キー拡張を受け取り、この非スキップ可能な拡張子を認識しない場合、それは静かにメッセージを捨てなければなりません。 [RFC5944]あたりの移動ノードによって要求されたとき、HAは、カプセル化（例えば、IPイン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カプセル化をサポートするように設定されていない場合、それはコードとRRP「要求されたカプセル使用できません（139）」[RFC3024]を送らなければなりません。
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」ビットが設定されていない登録要求を受信した場合「G」ビットが登録要求に設定されているかのように、HAはこれを扱うべきです。すなわち、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カプセル化をサポートしている場合は、以下の手順が適用されるべきである：HA O（登録が受け入れられた」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に応じて、すべてのRRPsで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を受け入れ、コードでRRPを送るべきである「登録受理（0）」、そして次の手順適用されます。
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がFAに送信する前に、RRPにGREキー拡張でこれらのキーを両方向のための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トンネリングのサポートは、非対称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
０
Length
長さ
4
４
Key Identifier
キー識別子
This is a four-octet value assigned during registration and inserted in every GRE packet of the user traffic.
これは、登録時に割り当てられた4オクテットの値であり、ユーザトラフィックのすべてのGREパケット内に挿入しました。
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).
[RFC5944]で定義されるように、このメモで定義されたGREキー拡張は、モバイル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が範囲から新しいGREキー拡張サブタイプ値の0〜255の承認を割り当てられている新しいサブタイプの番号スペースを紹介する仕様が必要であると専門家レビューを通じて行われるべきです。
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キー拡張は、セキュリティとはほとんどされています。ここでは、単語「キー」は保護されなければならない共有秘密の暗号化という意味ではなく、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.
彼らの有益なコメント、オフラインでの議論、およびこのドキュメントの最初のドラフト版のレビューのために6月王、ゴパルDommety、およびスリランカGundavelliに感謝します。また、ピートマッキャンとサイモンMizikovskyは、貴重なレビューコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、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.、 "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]パーキンス、C.、エド。、 "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ジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、カリフォルニア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
ケント・レオンシスコシステムズ株式会社170西タスマン・ドライブサンノゼ、カリフォルニア95134 USA電話：+1 408 526 5030 Eメール：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
アビLIORブリッジウォーターシステムズ社303テリー・フォックスドライブオタワ、オンタリオ州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チョードリーシスコシステムズ株式会社170西タスマン・ドライブサンノゼ、カリフォルニア95134 USA Eメール：kchowdhu@cisco.com
Jay Navali Cisco Systems Incorporated 170 West Tasman Drive San Jose, California 95134 USA EMail: jnavali@cisco.com
ジェイNavaliシスコシステムズ株式会社170西タスマン・ドライブサンノゼ、カリフォルニア95134 USA Eメール：jnavali@cisco.com