以下で、添付図面を参照して本出願の技術的解決策を説明する。
図1は、本出願の一実施形態が適用され得るシステムの概略図である。図1に示すシステム100は、PEデバイス101、PEデバイス102、PEデバイス103、PEデバイス104、プロバイダ(Provider、P)デバイス110、Pデバイス111、Pデバイス112、顧客エッジ(Customer Edge、CE)デバイス、CEデバイス121、およびCEデバイス122を含む。
図2は、本出願の一実施形態による非イーサネットサービスネゴシエーションの概略フローチャートである。図2に示す方法を、図1に示すシステム100に適用してもよい。
201:第2のネットワークデバイスが、イーサネット自動発見ルート(Ethernet Auto-discovery Route)専用のEVPNネットワーク層到達可能性情報(Network Layer Reachability Information、NLRI)を第1のネットワークデバイスに送信する。これに対応して、第1のネットワークデバイスは、第2のネットワークデバイスによって送信された、イーサネット自動発見ルート専用のEVPN NLRIを受信する。
202:第2のネットワークデバイスは、EVPNレイヤ2属性拡張コミュニティ(EVPN Layer 2 Attributes Extended Community)を第1のネットワークデバイスに送信する。これに対応して、第1のネットワークデバイスは、第2のネットワークデバイスによって送信されたEVPNレイヤ2属性拡張コミュニティを受信する。
第1のネットワークデバイスは、図1に示すシステム100内のPEデバイスであってもよく、第2のネットワークデバイスもまた、図1に示すシステム100内のPEデバイスであってもよい。例えば、いくつかの実施形態では、第1のネットワークデバイスは、図1に示すシステム100内のPEデバイス101であってもよく、第2のネットワークデバイスは、図1に示すシステム100内のPEデバイス102であってもよい。別の例として、いくつかの実施形態では、第1のネットワークデバイスは、図1に示すシステム100内のPEデバイス101であってもよく、第2のネットワークデバイスは、図1に示すシステム100内のPEデバイス103であってもよい。
図3は、イーサネット自動発見ルート(Ethernet Auto-Discovery(AD)route)専用のEVPN NLRIに含まれる情報の概略図である。図3に示すように、イーサネット自動発見ルート専用のEVPN NLRIは、合計4つのフィールドを含む。4つのフィールドは、8オクテット(octet)の長さを有するルート識別部(Route Distinguisher、RD)フィールド、10オクテットの長さを有するイーサネットセグメント識別子(Ethernet Segment Identifier、ESI)フィールド、4オクテットの長さを有するイーサネットタグID(Ethernet Tag ID)フィールド、および3オクテットの長さを有するマルチプロトコルラベルスイッチング(Multi-Protocol Label Switching、MPLS)ラベル(Label)フィールドである。
Ethernet Tag IDフィールドには、非イーサネットサービスのサービスIDが設定される。サービスIDは、第2のネットワークデバイスで設定されたリモートサービスIDと同じである必要がある。
イーサネット自動発見ルート専用のEVPN NLRI内のEthernet Tag IDフィールド以外の他のフィールドの具体的な内容は、現在のプロトコルのものと一致してもよい。簡潔にするため、ここでは詳細を繰り返し説明しない。
EVPNレイヤ2属性拡張コミュニティはサービスタイプ指示情報を含み、サービスタイプ指示情報は、第2のネットワークデバイスによって確立されると予想される非イーサネットサービスのタイプを示すために使用される。説明を簡単にするために、第2のネットワークデバイスによって確立されると予想される非イーサネットサービスは、以下では第2の非イーサネットサービスと呼ばれる。これに対応して、第1のネットワークデバイスによって確立されると予想される非イーサネットサービスは、以下では第1の非イーサネットサービスと呼ばれる。
図4は、EVPNレイヤ2属性拡張コミュニティに含まれる情報の概略図である。図4に示すように、EVPNレイヤ2属性拡張コミュニティは4つのフィールドを含む。4つのフィールドは、2オクテットの長さを有するタイプ(Type)/サブタイプ(Sub-Type)フィールド、2オクテットの長さを有する制御フラグ(Control Flags)フィールド、2オクテットの長さを有するレイヤ2(Layer 2、L2)最大送信ユニット(Maximum Transmission Unit、MTU)、および2オクテットの長さを有する予約(Reserved)フィールドである。
制御フラグフィールドは、制御語インジケータビットCを含み、制御語インジケータビットは、制御語ネゴシエーションプロセスで使用される。例えば、制御語インジケータビットの値が1である場合、第2の非イーサネットサービスが制御語をサポートすることを示す。例えば、制御語インジケータビットの値が0である場合、第2の非イーサネットサービスが制御語をサポートしないことを示す。
第1のネットワークデバイスは、第1の非イーサネットサービスが制御語をサポートするかどうかを判定し、制御フラグフィールド内の制御語インジケータビットCの受信した指示結果に基づいてネゴシエーション結果を判定することができる。
制御フラグフィールドのフォーマットは、既存のプロトコルにおける制御フラグフィールドのフォーマットと同じである。簡潔にするため、ここでは詳細を繰り返し説明しない。
第2のネットワークデバイスが第1のネットワークデバイスと非イーサネットサービスをネゴシエーションするとき、第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNレイヤ2属性拡張コミュニティ内のL2 MTUフィールドの値はすべて0、すなわち0x0000である。制御フラグフィールドの設定は、既存のイーサネットサービスネゴシエーションプロセスで送信されるEVPNレイヤ2属性拡張コミュニティ内の制御フラグフィールドの設定と一致してもよい。サービスタイプ指示情報は、予約フィールドで搬送される。異なるサービスタイプは異なる値に対応する。サービスタイプと値との間の対応関係を表1に示すことができる。
EVPNレイヤ2属性拡張コミュニティ内の予約フィールドで搬送されるサービスタイプ指示情報は、表1に示す値(すなわち、0x0001~0x0019)であり得る。EVPNレイヤ2属性拡張コミュニティを受信した後、第1のネットワークデバイスは、予約フィールド内の値(すなわち、サービスタイプ指示情報)に基づいて第2の非イーサネットサービスのサービスタイプを決定することができる。加えて、予約フィールド内の値は第2の非イーサネットサービスのサービスタイプを示すので、第1のネットワークデバイスは、第2のネットワークデバイスとネゴシエーションされる必要があるサービスが非イーサネットサービスであるとさらに判定することができる。言い換えれば、第1のネットワークデバイスは、受信したEVPNレイヤ2属性拡張コミュニティに基づいて、第2のネットワークデバイスとネゴシエーションされる必要があるサービスが非イーサネットサービスであると判定し、ネゴシエーションされる必要がある非イーサネットサービスのサービスタイプを判定することができる。
203:第2のネットワークデバイスは、EVPNエミュレーテッドパラメータ拡張コミュニティ(EVPN emulated parameters extend community)を第1のネットワークデバイスに送信する。これに対応して、第1のネットワークデバイスは、第2のネットワークデバイスによって送信されたEVPNエミュレーテッドパラメータ拡張コミュニティを受信する。EVPNエミュレートパラメータ拡張コミュニティは、パラメータ指示情報を搬送し、パラメータ指示情報は、第2の非イーサネットサービスのパラメータを示すために使用される。
図5は、EVPNエミュレーテッドパラメータ拡張コミュニティに含まれる情報の概略図である。図5に示すように、EVPNエミュレーテッドパラメータ拡張コミュニティは6つのフィールドを含む。6つのフィールドは、タイプ(Type)フィールド、サブタイプ(Sub-Type)フィールド、長さ(Length)フィールド、サブ時間長値(time length value、tlv)タイプ(sub-tlv type)フィールド、長さ(Length)フィールド、および可変長値(Variable Length Value)フィールドである。最後の3つのフィールド(すなわち、サブtlvタイプフィールド、長さフィールド、および可変長フィールド)は、1つのサブtlvと考えることができる。図5に示すEVPNエミュレーテッドパラメータ拡張コミュニティはただ1つのサブtlvを含む。いくつかの他の実施形態では、EVPNエミュレーテッドパラメータ拡張コミュニティは、代替的に、2つ以上のサブtlvを含んでもよい。
Typeフィールドの値およびSub-Typeフィールドの値は、予め設定された固定値である。例えば、タイプフィールドの値は0x06であってもよい。サブタイプフィールドの後に位置する長さフィールドは、EVPNエミュレーテッドパラメータ拡張コミュニティの長さを示す。
パラメータ指示情報は、パラメータタイプとパラメータ値の2つの部分を含むことができる。各パラメータのパラメータタイプおよびパラメータ値は、1つのサブtlvによって搬送され得る。より具体的には、パラメータタイプは、サブtlvタイプフィールドによって搬送されてもよく、パラメータ値は、可変長値フィールド(すなわち、サブtlvの値フィールド)によって搬送されてもよい。サブtlvタイプフィールドの後に位置する長さフィールド(すなわち、サブtlvの長さフィールド)の値は、可変長値フィールドの長さである。
各パラメータタイプは、対応する値を有することができる。サブtlvタイプフィールドは、パラメータタイプに対応する値を含み得る。異なるパラメータタイプに対応する値の長さは異なっていてもよい。表2は、パラメータタイプ、値、および値の長さの対応関係を示す。
EVPNエミュレーテッドパラメータ拡張コミュニティを受信した後、第1のネットワークデバイスは、第2の非イーサネットサービスのパラメータタイプおよびパラメータ値を取得することができる。
203:第1のネットワークデバイスは、EVPNレイヤ2属性拡張コミュニティに基づいて第2のネットワークデバイスと非イーサネットサービスネゴシエーションを実行する。
上述したように、第1のネットワークデバイスは、EVPNレイヤ2属性拡張コミュニティに基づいて、第1のネットワークデバイスが第2のネットワークデバイスと非イーサネットサービスをネゴシエーションする必要があると判定し、第2の非イーサネットサービスのサービスタイプを判定することができる。第1のネットワークデバイスは、EVPNエミュレーテッドパラメータ拡張コミュニティに基づいて、第2の非イーサネットサービスのパラメータタイプおよびパラメータ値を決定することができる。
いくつかの実装形態では、第1のネットワークデバイスは、EVPNレイヤ2属性拡張コミュニティに基づいて第2のネットワークデバイスとの非イーサネットサービスネゴシエーションを実行することができる。
いくつかの他の実施形態では、第1のネットワークデバイスは、EVPNレイヤ2属性拡張コミュニティおよびEVPNエミュレーテッドパラメータ拡張コミュニティに基づいて第2のネットワークデバイスと非イーサネットサービスネゴシエーションを実行することができる。
いくつかの特定のサービス(ATMおよびハイレベルデータリンク制御(High-Level Data Link Control、HDLC)など)について、第1のネットワークデバイスは、非イーサネットサービスネゴシエーションプロセスにおける非イーサネットサービスのパラメータ値を第2のネットワークデバイスと比較する必要がない。したがって、この場合、第1のネットワークデバイスは、カスケードパラメータ、第1の非イーサネットサービスのサービスタイプ、および第2の非イーサネットサービスのサービスタイプに基づいて、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションを実行することができる。
いくつかの実施形態では、第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの値が1(すなわち、第2の非イーサネットサービスは制御語をサポートする)である場合、ネゴシエーション結果は、制御語がサポートされるというものである。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの値が0(すなわち、第2の非イーサネットサービスは制御語をサポートしない)である場合、ネゴシエーション結果は、制御語がサポートされないというものである。ネゴシエーション結果は、転送プレーンに配信される。転送プレーンは、ネゴシエーション結果に基づいて、制御語をパケットに追加するかどうかを決定する。制御語がサポートされていることをネゴシエーション結果が示す場合、転送プレーンは制御語をパケットに追加する。制御語がサポートされていないことをネゴシエーション結果が示す場合、転送プレーンは制御語をパケットに追加しない。第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの値が0(すなわち、第2の非イーサネットサービスは制御語をサポートしない)である場合、第1のネットワークデバイスによって第2のネットワークデバイスと実行される非イーサネットサービスネゴシエーションは失敗すると判定され得る。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの値が1(すなわち、第2の非イーサネットサービスは制御語をサポートする)である場合、第1のネットワークデバイスによって第2のネットワークデバイスと実行される非イーサネットサービスネゴシエーションは失敗すると判定され得る。以下、説明を簡単にするために、この制御語ネゴシエーションソリューションを制御語ネゴシエーションソリューション1と称する。
いくつかの他の実施形態では、第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの値が1(すなわち、第2の非イーサネットサービスは制御語をサポートする)である場合、ネゴシエーション結果は、制御語がサポートされるというものである。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの値が0(すなわち、第2の非イーサネットサービスは制御語をサポートしない)である場合、ネゴシエーション結果は、制御語がサポートされないというものである。ネゴシエーション結果は、転送プレーンに配信される。転送プレーンは、ネゴシエーション結果に基づいて、制御語をパケットに追加するかどうかを判定する。第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの値が0(すなわち、第2の非イーサネットサービスは制御語をサポートしない)である場合、ネゴシエーション結果は、制御語がサポートされるというものである。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの値が1(すなわち、第2の非イーサネットサービスは制御語をサポートする)である場合、ネゴシエーション結果は、制御語がサポートされるというものである。言い換えれば、上記のネゴシエーションソリューションでは、1つの非イーサネットサービスが制御語をサポートする限り、ネゴシエーション結果は、制御語がサポートされるというものである。制御語がサポートされていることをネゴシエーション結果が示す場合、転送プレーンは制御語をパケットに追加する。制御語がサポートされていないことをネゴシエーション結果が示す場合、転送プレーンは制御語をパケットに追加しない。以下、説明を簡単にするために、この制御語ネゴシエーションソリューションを制御語ネゴシエーションソリューション2と称する。
いくつかの他の実施形態では、第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの値が1(すなわち、第2の非イーサネットサービスは制御語をサポートする)である場合、ネゴシエーション結果は、制御語がサポートされるというものである。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの値が0(すなわち、第2の非イーサネットサービスは制御語をサポートしない)である場合、ネゴシエーション結果は、制御語がサポートされないというものである。ネゴシエーション結果は、転送プレーンに配信される。転送プレーンは、ネゴシエーション結果に基づいて、制御語をパケットに追加するかどうかを判定する。第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの値が0(すなわち、第2の非イーサネットサービスは制御語をサポートしない)である場合、ネゴシエーション結果は、制御語がサポートされないというものである。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの値が1(すなわち、第2の非イーサネットサービスは制御語をサポートする)である場合、ネゴシエーション結果は、制御語がサポートされないというものである。言い換えれば、上記のネゴシエーションソリューションでは、1つの非イーサネットサービスが制御語をサポートしない限り、ネゴシエーション結果は、制御語がサポートされないというものである。制御語がサポートされていることをネゴシエーション結果が示す場合、転送プレーンは制御語をパケットに追加する。制御語がサポートされていないことをネゴシエーション結果が示す場合、転送プレーンは制御語をパケットに追加しない。以下、説明を簡単にするために、この制御語ネゴシエーションソリューションを制御語ネゴシエーションソリューション3と称する。
第1のネットワークデバイスおよび第2のネットワークデバイスは、制御語ネゴシエーションソリューション1から制御語ネゴシエーションソリューション3のうちの1つを使用するように事前にネゴシエーションするか、または事前設定することができる。
第1のネットワークデバイスおよび第2のネットワークデバイスが制御語ネゴシエーションソリューション1を使用するとき、第1のネットワークデバイスは、カスケードパラメータ、第1の非イーサネットサービスのサービスタイプ、第2の非イーサネットサービスのサービスタイプ、第1の非イーサネットサービスが制御語をサポートするかどうか、および制御語インジケータビットであり第1のネットワークデバイスによって受信される指示結果に基づいて、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションを実行することができる。制御後インジケータビットの指示結果は、第2の非イーサネットサービスが制御語をサポートするか、または、第2の非イーサネットサービスが制御語をサポートしないというものであり得る。
具体的には、第1のネットワークデバイスは、カスケードパラメータが事前設定値を満たすかどうか、第1の非イーサネットサービスのサービスタイプが第2の非イーサネットサービスのサービスタイプと同じであるかどうか、および第1の非イーサネットサービスが制御語をサポートするかまたはサポートしない状況が、制御語インジケータビットによって指示される第2の非イーサネットサービスが制御語をサポートするかまたはサポートしない状況と同じであるかどうかを判定することができる。第1のネットワークデバイスは、判定結果に基づいて、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが成功するかどうかを判定することができる。第1の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況が、制御語インジケータビットによって指示される第2の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況と同じであるかどうかは、以下のことを意味する。第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの指示結果が、第2の非イーサネットサービスが制御語をサポートしているというものである場合、第1の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況は、制御語インジケータビットによって指示される第2の非イーサネットサービスが制御語をサポートしているかまたはサポートしていないかの状況と同じである。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの指示結果が、第2の非イーサネットサービスが制御語をサポートしていないというものである場合、第1の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況は、制御語インジケータビットによって指示される第2の非イーサネットサービスが制御語をサポートしているかまたはサポートしていないかの状況と同じである。第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの指示結果が、第2の非イーサネットサービスが制御語をサポートしていないというものである場合、第1の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況は、制御語インジケータビットによって指示される第2の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況と同じではない。そして、第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの指示結果が、第2の非イーサネットサービスが制御語をサポートしているというものである場合、第1の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況は、制御語インジケータビットによって指示される第2の非イーサネットサービスが制御語をサポートしているかまたはサポートしていない状況と同じではない。
すべての上記の判定結果が肯定である場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが成功すると判定することができる。言い換えれば、カスケードパラメータが事前設定値を満たし、第1の非イーサネットサービスのサービスタイプが第2の非イーサネットサービスのサービスタイプと同じであり、第1の非イーサネットサービスが制御語をサポートするかまたはサポートしない状況が、制御語インジケータビットによって指示される第2の非イーサネットサービスが制御語をサポートするかまたはサポートしない状況と同じであると判定する場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが成功すると判定する。
上記の判定結果のうちのいずれかが否定である場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。言い換えれば、カスケードパラメータが事前設定値を満たさないと判定すると、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。第1の非イーサネットサービスのサービスタイプが第2の非イーサネットサービスのサービスタイプとは異なると判定すると、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。第1の非イーサネットサービスが制御語をサポートせず、制御語インジケータビットの指示結果が、第2の非イーサネットサービスは制御語をサポートするというものである場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。第1の非イーサネットサービスが制御語をサポートし、制御語インジケータビットの指示結果が、第2の非イーサネットサービスは制御語をサポートしないというものである場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。
制御語ネゴシエーションソリューション1では、第1の非イーサネットサービスが制御語をサポートするかどうか、および制御語インジケータビットの指示結果は、非イーサネットサービスネゴシエーションが成功するかどうかに直接影響し得る。しかし、制御語ネゴシエーションソリューション2および制御語ネゴシエーションソリューション3では、第1の非イーサネットサービスが制御語をサポートするかどうか、および制御語インジケータビットの指示結果は、非イーサネットサービスネゴシエーションに影響しない。したがって、第1のネットワークデバイスおよび第2のネットワークデバイスが制御語ネゴシエーションソリューション2または制御語ネゴシエーションソリューション3を使用するとき、第1のネットワークデバイスは、カスケードパラメータ、第1の非イーサネットサービスのサービスタイプ、および第2の非イーサネットサービスのサービスタイプに基づいて、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションを実行することができる。具体的には、第1のネットワークデバイスは、カスケードパラメータが事前設定値を満たすかどうか、および第1の非イーサネットサービスのサービスタイプが第2の非イーサネットサービスのサービスタイプと同じであるかどうかを判定することができる。第1のネットワークデバイスは、判定結果に基づいて、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが成功するかどうかを判定することができる。すべての上記の判定結果が肯定である場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが成功すると判定することができる。言い換えれば、カスケードパラメータが事前設定値を満たし、第1の非イーサネットサービスのサービスタイプが第2の非イーサネットサービスのサービスタイプと同じであると判定する場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが成功すると判定する。上記の判定結果のうちのいずれかが否定である場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。言い換えれば、カスケードパラメータが事前設定値を満たさないと判定すると、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。第1の非イーサネットサービスのサービスタイプが第2の非イーサネットサービスのサービスタイプとは異なると判定すると、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。
いくつかの実施形態では、第1のネットワークデバイスは、第1の非イーサネットサービスのパラメータ値を第2の非イーサネットサービスのパラメータ値と比較する必要がある。例えば、パケット上の構造非依存型E3サービス、パケット上の構造非依存型T1(DS1)サービス、またはパケット上の構造非依存型E1サービスなどのサービスの場合、第1のネットワークデバイスは、第1の非イーサネットサービスのパラメータ値を第2の非イーサネットサービスのパラメータ値と比較する必要がさらにある。この場合、第1のネットワークデバイスが、第2の非イーサネットサービスのパラメータタイプが第1の非イーサネットサービスのパラメータタイプと同じであり、第2の非イーサネットサービスのパラメータ値が第1の非イーサネットサービスのパラメータ値と同じであると判定する場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが成功すると判定することができる。第1のネットワークデバイスが、第2の非イーサネットサービスのパラメータタイプが第1の非イーサネットサービスのパラメータタイプとは異なるか、または第2の非イーサネットサービスのパラメータが第1の非イーサネットサービスのパラメータとは異なると判定する場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションが失敗すると判定することができる。
第1のネットワークデバイスが第2のネットワークデバイスとの非イーサネットサービスネゴシエーションを実行する前に、第1のネットワークデバイスは、第1のネットワークデバイスおよび第2のネットワークデバイスが同じVPNインスタンスに属するとまず判定する必要があることが理解されよう。
具体的には、第1のネットワークデバイスは、インポートターゲット(Import Target)およびエクスポートターゲット(Export Target)に基づいて、第1のネットワークデバイスおよび第2のネットワークデバイスが同じVPNインスタンスに属するかどうかを判定することができる。インポートターゲットがエクスポートターゲットと一致する場合、第1のネットワークデバイスおよび第2のネットワークデバイスは同じVPNインスタンスに属する。インポートターゲットがエクスポートターゲットと一致しない場合、第1のネットワークデバイスおよび第2のネットワークデバイスは同じVPNインスタンスに属さない。イーサネットサービスネゴシエーションおよび非イーサネットサービスネゴシエーションは、同じVPNインスタンス内の異なるネットワークデバイス間で実行される。第1のネットワークデバイスおよび第2のネットワークデバイスが同じVPNインスタンスに属さない場合、第1のネットワークデバイスは、第2のネットワークデバイスとの非イーサネットサービスネゴシエーションを実行する必要がない。したがって、第1のネットワークデバイスおよび第2のネットワークデバイスが同じVPNインスタンスに属するときにのみ、第1のネットワークデバイスは、EVPNレイヤ2属性拡張コミュニティ、またはEVPNレイヤ2属性拡張コミュニティおよびEVPNエミュレーテッドパラメータ拡張コミュニティに基づいて、第2のネットワークデバイスと非イーサネットサービスネゴシエーションを実行することができる。
インポートターゲットは、第1のネットワークデバイスによって決定される。エクスポートターゲットは、第2のネットワークデバイスによって決定される。エクスポートターゲットを決定した後、第2のネットワークデバイスは、エクスポートターゲットを、ルートとともに、境界ゲートウェイプロトコル(Border Gateway Protocol、BGP)の拡張コミュニティとしてアドバタイズすることができる。第1のネットワークデバイスは、第2のネットワークデバイスによってアドバタイズされたエクスポートターゲットを受信することができる。
インポートターゲットがエクスポートターゲットと一致するかどうかは、インポートターゲットとエクスポートターゲットとの間に交差があることを意味する。インポートターゲットとエクスポートターゲットとの間に交差がある場合、インポートターゲットはエクスポートターゲットと一致する。インポートターゲットとエクスポートターゲットとの間に交差がない場合、インポートターゲットはエクスポートターゲットと一致しない。
例えば、インポートターゲットが100:1、200:1、および300:1であり、エクスポートターゲットが100:1、400:1、および500:1である場合、インポートターゲットはエクスポートターゲットと一致する。この場合、第1のネットワークデバイスおよび第2のネットワークデバイスは同じVPNインスタンスに属する。インポートターゲットが200:1、300:1、および400:1であり、エクスポートターゲットが100:1、500:1、および600:1である場合、インポートターゲットはエクスポートターゲットと一致しない。この場合、第1のネットワークデバイスおよび第2のネットワークデバイスは異なるVPNインスタンスに属する。
図2に示す方法は、イーサネット自動発見ルート専用の既存のEVPN NLRIを再利用し、EVPNレイヤ2属性拡張コミュニティおよびEVPNエミュレーテッドパラメータ拡張コミュニティを使用することにより、非イーサネットサービスネゴシエーションに必要な情報を送信する。言い換えれば、図2に示す方法では、非イーサネットサービスネゴシエーションプロセスは、イーサネットサービスのプロトコルを使用することにより実行される。このようにして、システム内のネットワークデバイスは、イーサネットサービスをサポートする関連プロトコルのみが構成されている場合に、非イーサネットサービスネゴシエーションをサポートすることができる。したがって、図2に示す方法は、サービスネゴシエーションコストを削減し、柔軟なネゴシエーションを実施することができる。
第1のネットワークデバイスによって第2のネットワークデバイスとネゴシエーションされる非イーサネットサービスは、確立されるべき非イーサネットサービスであることが理解されよう。ネゴシエーションが成功した場合、非イーサネットサービスが確立される。ネゴシエーションが失敗した場合、非イーサネットサービスは確立されない。
図6は、本出願の一実施形態による非イーサネットサービスネゴシエーションの別の概略フローチャートである。図6に示す方法を、図1に示すシステム100に適用してもよい。
601:第2のネットワークデバイスは、サービスネゴシエーションルート専用のEVPN NLRIを第1のネットワークデバイスに送信する。これに対応して、第1のネットワークデバイスは、第2のデバイスによって送信された、サービスネゴシエーションルート専用のEVPN NLRIを受信する。
図2に示した方法と同様に、図6に示す方法における第1のネットワークデバイスは、図1に示すシステム100内のPEデバイスであってもよく、第2のネットワークデバイスもまた、図1に示すシステム100内のPEデバイスであってもよい。例えば、いくつかの実施形態では、第1のネットワークデバイスは、図1に示すシステム100内のPEデバイス101であってもよく、第2のネットワークデバイスは、図1に示すシステム100内のPEデバイス102であってもよい。別の例として、いくつかの実施形態では、第1のネットワークデバイスは、図1に示すシステム100内のPEデバイス101であってもよく、第2のネットワークデバイスは、図1に示すシステム100内のPEデバイス103であってもよい。
図7は、サービスネゴシエーションルート専用のEVPN NLRIに含まれる情報の概略図である。図7に示すように、サービスネゴシエーションルートNLRIは合計4つのフィールドを含む。4つのフィールドは、8オクテットの長さを有するRDフィールド、2オクテットの長さを有するカプセル化タイプ(encapsulation Type、encapType)フィールド、4オクテットの長さを有するカプセル化サービスID(encapsulation service ID、encap-service-ID)フィールド、および3オクテットの長さを有するMPLSラベル(Label)フィールドである。
図7に示すサービスネゴシエーションルート専用のEVPN NLRIは、既存のEVPNで定義された5種類のルート専用のEVPN NLRIとは異なることが分かる。5種類のルート専用のEVPN NLRIは、イーサネット自動発見ルート(Ethernet Auto-Discovery(AD)route)専用のEVPN NLRI、MAC/IPアドバタイズメントルート(MAC/IP Advertisement route)専用のEVPN NLRI、包括的マルチキャストイーサネットタグルート(Inclusive Multicast Ethernet Tag route)専用のEVPN NLRI、イーサネットセグメントルート(Ethernet Segment route)専用のEVPN NLRI、およびIPプレフィクスルート(IP Prefix route)専用のEVPN NLRIを含む。言い換えれば、図6に示す方法は、新たに定義されたNLRI、すなわち、図7に示すサービスネゴシエーションルートNLRIを提案する。サービスネゴシエーションルート専用のEVPN NLRIは、非イーサネットサービスネゴシエーションプロセスに使用されてもよい。
図7に示すサービスネゴシエーションルート専用のEVPN NLRI内のencapTypeフィールドは、サービスタイプ指示情報を搬送するために使用され得る。異なるサービスタイプは異なる値に対応する。サービスタイプと値との間の対応関係を表1に示すことができる。
サービスネゴシエーションルート専用のEVPN NLRI内のencap-service-IDフィールドは、サービスタイプ識別子を搬送するために使用され得る。非イーサネットサービスをネゴシエーションする必要がある2つのネットワークデバイス間では、encap-service-IDフィールドで搬送されるサービス識別子は、ローカルエンドによって設定されたリモートencap-service-IDと同じである必要があり、その逆も同様である。言い換えれば、図7に示すサービスネゴシエーションルート専用であり、第2のネットワークデバイスによって送信されるEVPN NLRI内のencap-service-IDは、第2のネットワークデバイスによって設定されたリモートencap-service-IDと同じである。サービスネゴシエーションルート専用のEVPN NLRI内のRDフィールドの機能は、図3に示すイーサネット自動発見ルート専用のEVPN NLRI内のRDフィールドの機能と同じである。サービスネゴシエーションルート専用のEVPN NLRI内のMPLSラベルフィールドの機能は、図3に示すサービスネゴシエーションルート専用のEVPN NLRI内のMPLSラベルフィールドの機能と同じである。簡潔にするため、ここでは詳細を繰り返し説明しない。
図7に示すサービスネゴシエーションルート専用のEVPN NLRIは、非イーサネットサービスをネゴシエーションするために使用され、ルート専用の既存のEVPN NLRIとは異なる、ルート専用のEVPN NLRIの可能な実装形態にすぎないことが理解されよう。非イーサネットサービスをネゴシエーションするために使用され、ルート専用の既存のEVPN NLRIとは異なる、ルート専用のEVPN NLRIは、別の方法で実装されてもよい。例えば、イーサネットタグIDフィールドが、図7に示すサービスネゴシエーションルート専用のEVPN NLRIに追加される。別の例として、イーサネットセグメント識別子フィールドが、図7に示すサービスネゴシエーションルート専用のEVPN NLRIに追加される。別の例として、いくつかの実装形態では、サービスタイプ指示情報を搬送するために使用されるフィールドの名前は、図7に示すencapTypeとは異なり得る。同様に、サービス識別子を搬送するために使用されるフィールドの名前は、図7に示すencap-service-IDとは異なり得る。
602:第2のネットワークデバイスは、EVPNエミュレーテッドパラメータ拡張コミュニティ(EVPN emulated parameters extend community)を第1のネットワークデバイスに送信する。これに対応して、第1のネットワークデバイスは、第2のネットワークデバイスによって送信されたEVPNエミュレーテッドパラメータ拡張コミュニティを受信する。EVPNエミュレートパラメータ拡張コミュニティは、パラメータ指示情報を搬送し、パラメータ指示情報は、第2の非イーサネットサービスのパラメータを示すために使用される。
図8は、ステップ602において第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティに含まれる情報の概略図である。図2に示す方法のステップ203で第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティ(すなわち、図5に示すEVPNエミュレーテッドパラメータ拡張コミュニティ)と比較して、制御フラグ(Control Flags)フィールドが、図8に示すEVPNエミュレーテッドパラメータ拡張コミュニティに追加されることが分かる。Control Flagsフィールドの内容は、図4に示すEVPNレイヤ2属性拡張コミュニティに含まれる制御フラグフィールドに含まれる内容と同じである。言い換えれば、図8に示すEVPNエミュレーテッドパラメータ拡張コミュニティ内の制御フラグフィールドも1つの制御語インジケータビットCを含み、制御語指示ビットは、第2のネットワークデバイスが制御語(control word)をサポートするかどうかを示すために使用される。例えば、制御語インジケータビットの値が1である場合、第2のネットワークデバイスが制御語をサポートすることを示す。この場合、第2のネットワークデバイスは、制御語を送受信する能力を有する。別の例として、制御語インジケータビットの値が0である場合、第2のネットワークデバイスが制御語をサポートしないことを示す。この場合、第2のネットワークデバイスは、制御語を送受信する能力を有さない。
いくつかの実施形態では、第1のネットワークデバイスと第2のネットワークデバイスの両方が制御語をサポートする。いくつかの実施形態では、第1のネットワークデバイスと第2のネットワークデバイスのうちの一方が制御語をサポートする。いくつかの実施形態では、第1のネットワークデバイスと第2のネットワークデバイスのいずれも制御語をサポートしない。
図8に示すEVPNエミュレーテッドパラメータ拡張コミュニティ内の制御フラグフィールド以外の他のフィールドの機能は、図5に示すEVPNエミュレーテッドパラメータ拡張コミュニティ内の同じフィールドの機能と同じである。簡潔にするために、ここでは詳細を説明しない。
603:第1のネットワークデバイスは、サービスネゴシエーションルート専用のEVPN NLRIに基づいて第2のネットワークデバイスと非イーサネットサービスネゴシエーションを実行することができる。
図6に示す方法における非イーサネットサービスネゴシエーションに使用される情報は、図2に示す方法における非イーサネットサービスネゴシエーションに使用される情報と同じであることが分かる。違いは、情報を搬送するために使用されるメッセージが異なることである。したがって、ステップ603で第1のネットワークデバイスによって第2のネットワークデバイスと実行される非イーサネットサービスネゴシエーションの具体的な実装形態については、図2に示した方法の説明を参照されたい。簡潔にするため、ここでは詳細を繰り返し説明しない。
以下では、図2および図6の方法を参照して、第1のネットワークデバイスと第2のネットワークデバイスとの間の非イーサネットサービスネゴシエーションプロセスを説明するために、一例としてパケット上の構造非依存型E1(Structure-agnostic E1 over Packet)サービスを使用する。
第1のネットワークデバイスは、図2に示す方法を使用して第2のネットワークデバイスとSATOPサービスネゴシエーションを実行すると仮定する。
第2のネットワークデバイスによって第1のネットワークデバイスに送信される、イーサネット自動発見ルート(Ethernet Auto-discovery Route)専用のEVPNネットワーク層到達可能性情報(Network Layer Reachability Information、NLRI)内の各フィールドの具体的内容は、既存のプロトコルにおけるイーサネット自動発見ルート専用のEVPN NLRI内の各フィールドの具体的内容と一致する。簡潔にするために、ここでは詳細を説明しない。第2のネットワークデバイスによって第1のネットワークデバイスに送信される、EVPNレイヤ2属性拡張コミュニティ(EVPN Layer 2 Attributes Extended Community)内のL2 MTUフィールドは0x000に設定される。第2のネットワークデバイスが制御語をサポートすることを示すために、制御フラグフィールド内の制御語インジケータビットが1に設定され得る。第1のネットワークデバイスと第2のネットワークデバイスとは直接相互接続されていると仮定する。この場合、制御フラグフィールドは0x0003に設定されてもよい。表1に示すように、SATOPサービスに対応する値は0x0011である。したがって、EVPNレイヤ2属性拡張コミュニティ(EVPN Layer 2 Attributes Extended Community)の予約フィールドの値を0x0011に設定する必要がある。第1のネットワークデバイスは、予約フィールドの値に基づいて、第1のネットワークデバイスが第2のネットワークデバイスとSATOPサービスをネゴシエーションする必要があると判定することができる。
SATOPサービスは、2つのパラメータをネゴシエーションする必要がある。2つのパラメータは、TDMペイロードバイトおよびTDMビットレートである。表2に示すように、TDMペイロードバイトの値は0x04であり、TDMビットレートの値は0x07である。したがって、第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティ内のsub-tlv typeフィールドは、パラメータタイプを示すために使用される値、すなわち0x04および0x07を含む必要がある。
TDMペイロードバイトの長さ値は、EVPNエミュレーテッドパラメータ拡張コミュニティ内の可変長値フィールドに挿入されてもよい。TDMペイロードバイトの長さ値の長さは、EVPNエミュレーテッドパラメータ拡張コミュニティ内の長さ値フィールドに挿入されてもよい。TDMカプセル化番号(TDM-encapsulation-number)は8であると仮定する。この場合、可変長値フィールドに挿入されるTDMペイロードバイトの長さ値は0x0800である。これに対応して、長さフィールドに挿入されるTDMペイロードバイトの長さ値の長さは0x04である。
TDMビットレートはまた、可変長値フィールドにも挿入され得る。TDMビットレートは0x00000020に固定することができる(10進数値32はSATOPフローレートが2Mであることを示す)。これに対応して、TDMビットレートの長さ、すなわち0x06も、長さフィールドに挿入され得る。
このようにして、ネットワーク側の各SATOPサービスによって送信されるパケットのペイロードは2048バイトであり、送信レートは1000パケット毎秒(Packets per Second、pps)であり、トラフィックサイズは2Mである。
この場合、EVPNエミュレーテッドパラメータ拡張コミュニティの内容は図9に示すことができる。
第1のネットワークデバイスは、図6に示す方法を使用して第2のネットワークデバイスとSATOPサービスネゴシエーションを実行すると仮定する。
表1に示すように、SATOPサービスに対応する値は0x0011である。したがって、第2のネットワークデバイスによって第1のネットワークデバイスに送信される、サービスネゴシエーションルート専用のEVPN NLRI内のencapTypeフィールドで搬送される値は0x0011である。
第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティ内の制御フラグフィールドの値は0x0003である。第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティ内のサブtlvタイプフィールドは、パラメータタイプを示すために使用される値、すなわち0x04および0x07を含む必要がある。また、TDMカプセル化番号(TDM-encapsulation-number)は8であることも仮定する。この場合、EVPNエミュレーテッドパラメータ拡張コミュニティ内の可変長値フィールドに挿入されるTDMペイロードバイトの長さ値は0x0800である。これに対応して、長さフィールドに挿入されるTDMペイロードバイトの長さ値の長さは0x04である。TDMビットレートはまた、可変長値フィールドにも挿入され得る。TDBビットレートは0x00000020に固定されてもよい。これに対応して、TDMビットレートの長さ、すなわち0x06も、長さフィールドに挿入され得る。
この場合、第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティを図10に示すことができる。
第1のネットワークデバイスも制御語をサポートし、第1のネットワークデバイスのサービスタイプもSATOPであると判定したとき、ならびに第1のネットワークデバイスのTDMペイロードバイトおよびTDMビットレートが図9または図10に示すEVPNエミュレーテッドパラメータ拡張コミュニティで搬送されるTDMペイロードバイトおよびTDMビットレートと同じであるとき、第1のネットワークデバイスは、第2のネットワークデバイスとのSATOPサービスネゴシエーションが成功すると判定する。上記の内容のうちのいずれかが異なる場合、第1のネットワークデバイスは、第2のネットワークデバイスとSATOPサービスネゴシエーションが失敗すると判定することができる。
以下では、図2および図6の方法を参照して、第1のネットワークデバイスと第2のネットワークデバイスとの間の非イーサネットサービスネゴシエーションプロセスを説明するために、一例としてパケット上のATMトランスペアレントセルトランスポート(ATM transparent cell transport)サービスを使用する。
第1のネットワークデバイスは、図2に示す方法を使用して第2のネットワークデバイスとATMトランスペアレントセルトランスポート・ネゴシエーションを実行すると仮定する。
第2のネットワークデバイスによって第1のネットワークデバイスに送信される、イーサネット自動発見ルート専用のEVPNネットワーク層到達可能性情報(Network Layer Reachability Information、NLRI)内の各フィールドの具体的内容は、既存のプロトコルにおけるイーサネット自動発見ルート専用のEVPN NLRI内の各フィールドの具体的内容と一致する。簡潔にするために、ここでは詳細を説明しない。第2のネットワークデバイスによって第1のネットワークデバイスに送信される、EVPNレイヤ2属性拡張コミュニティ(EVPN Layer 2 Attributes Extended Community)内のL2 MTUフィールドは0x000に設定される。第2のネットワークデバイスが制御語をサポートすることを示すために、制御フラグフィールド内の制御語インジケータビットが1に設定され得る。第1のネットワークデバイスと第2のネットワークデバイスとは直接相互接続されていると仮定する。この場合、制御フラグフィールドは0x0003に設定されてもよい。表1に示すように、ATMトランスペアレントセルトランスポートサービスに対応する値は0x0003である。したがって、EVPNレイヤ2属性拡張コミュニティ(EVPN Layer 2 Attributes Extended Community)内の予約フィールドの値を0x0003に設定する必要がある。第1のネットワークデバイスは、予約フィールドの値に基づいて、第1のネットワークデバイスが第2のネットワークデバイスとATMトランスペアレントセルトランスポートサービスをネゴシエーションする必要があると判定することができる。
1つのパラメータ、すなわち、連結されたATMセルの最大数のみが、ATMトランスペアレントセルトランスポートのためにネゴシエーションされる必要がある。表2に示すように、連結されたATMセルの最大数の値は0x02である。したがって、第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティ内のsub-tlv typeフィールドは、パラメータタイプを示すために使用される値、すなわち0x02を含む必要がある。
連結されたATMセルの最大数は、EVPNエミュレーテッドパラメータ拡張コミュニティ内の可変長値フィールドに挿入されてもよい。連結されたATMセルの最大数の長さは、EVPNエミュレーテッドパラメータ拡張コミュニティ内の長さフィールドに挿入されてもよい。セル連結の量が16であると仮定する。この場合、可変長値フィールドに挿入される連結されたATMセルの最大数は0x0010である。これに対応して、長さフィールドに挿入される連結されたATMセルの最大数の長さは0x04である。
この場合、EVPNエミュレーテッドパラメータ拡張コミュニティの内容は図11に示すことができる。
第1のネットワークデバイスは、図6に示す方法を使用して第2のネットワークデバイスとATMトランスペアレントセルトランスポート・ネゴシエーションを実行すると仮定する。
表1に示すように、ATMトランスペアレントセルトランスポートサービスに対応する値は0x0003である。したがって、第2のネットワークデバイスによって第1のネットワークデバイスに送信される、サービスネゴシエーションルート専用のEVPN NLRI内のencapTypeフィールドで搬送される値は0x0003である。
第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティ内の制御フラグフィールドの値は0x0003である。したがって、第2のネットワークデバイスによって第1のネットワークデバイスに送信されるEVPNエミュレーテッドパラメータ拡張コミュニティ内のsub-tlv typeフィールドは、パラメータタイプを示すために使用される値、すなわち0x02を含む必要がある。セル連結の量が16であることも仮定する。この場合、可変長値フィールドに挿入される連結されたATMセルの最大数は0x0010である。これに対応して、長さフィールドに挿入される連結されたATMセルの最大数の長さは0x04である。
この場合、EVPNエミュレーテッドパラメータ拡張コミュニティの内容は図12に示すことができる。
第1のネットワークデバイスも制御語をサポートし、第1のネットワークデバイスのサービスタイプもATMトランスペアレントセルトランスポートであると判定した場合、第1のネットワークデバイスは、第2のデバイスとのATMトランスペアレントセルトランスポート・サービスネゴシエーションが成功すると判定することができる。上記の内容のうちのいずれかが異なる場合、第1のネットワークデバイスは、第2のネットワークデバイスとATMトランスペアレントセルトランスポート・サービスネゴシエーションが失敗すると判定することができる。第1のネットワークデバイスの連結されたATMセルの最大数が、図11または図12に示すEVPNエミュレートパラメータ拡張コミュニティで搬送される連結されたATMセルの最大数と同じであるかどうかは、ネゴシエーション結果に影響しない。いくつかの実施形態では、EVPNエミュレーテッドパラメータ拡張コミュニティは、連結されたATMセルの最大数を搬送しなくてもよい。
図13は、本出願の一実施形態による非イーサネットサービスを確立する方法の概略フローチャートである。
1301:第1のネットワークデバイスが、第2のネットワークデバイスによって送信された境界ゲートウェイプロトコルBGPメッセージを受信し、BGPメッセージはイーサネット仮想プライベートネットワークEVPNルーティング情報を搬送し、EVPNルーティング情報は第1の指示情報を含み、第1の指示情報はターゲット非イーサネットサービスのサービスタイプを示すために使用され、ターゲット非イーサネットサービスは第2のネットワークデバイスによって確立されると予想される非イーサネットサービスである。
1302:第1のネットワークデバイスは、第1の指示情報に基づいてターゲット非イーサネットサービスのサービスタイプを決定する。
1303:第1のネットワークデバイスは、ターゲット非イーサネットサービスのサービスタイプに基づいて、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立する。
上記の技術的解決策では、イーサネットサービスのプロトコルを使用して非イーサネットサービスネゴシエーションプロセスが実行され、非イーサネットサービスが確立される。このようにして、システム内のネットワークデバイスは、イーサネットサービスをサポートする関連プロトコルのみが構成されている場合に、非イーサネットサービスネゴシエーションをサポートすることができる。したがって、前述の技術的解決策は、サービスネゴシエーションコストを削減し、柔軟なネゴシエーションを実施することができる。
特定の実装形態では、いくつかの実施形態では、EVPNルーティング情報はEVPNネットワーク層到達可能性情報NLRIをさらに含み、EVPN NLRIはイーサネット自動発見ルートをアドバタイズするために使用される。言い換えれば、EVPN NLRIは、図2に示す方法におけるイーサネット自動発見ルート専用のEVPN NLRIであってもよい。
前述の技術的解決策で使用されるEVPN NLRIは、イーサネット自動発見ルート専用の既存のEVPN NLRIである。言い換えれば、前述の技術的解決策は、非イーサネットサービスネゴシエーションに使用されるEVPN NLRIとして、イーサネット自動発見ルート専用の既存のEVPN NLRIを再利用する。したがって、前述の技術的解決策は、既存のプロトコルに比較的小さな変更を加え、その結果、既存のネットワークデバイスは、本出願で提案される非イーサネットサービスネゴシエーション方法をサポートする。
いくつかの実施形態では、EVPNルーティング情報はEVPNレイヤ2属性拡張コミュニティを含み、EVPNレイヤ2属性拡張コミュニティは第1の指示情報を搬送するために使用される。
前述の技術的解決策は、既存のEVPNレイヤ2属性拡張コミュニティの予約フィールドを再利用して、非イーサネットサービスネゴシエーションを実行し、ネゴシエーションされることを必要とする非イーサネットサービスのサービスタイプを示す。したがって、前述の技術的解決策は、既存のプロトコルに比較的小さな変更を加え、その結果、既存のネットワークデバイスは、本出願で提案される非イーサネットサービスネゴシエーション方法をサポートする。
いくつかの実施形態では、EVPNルーティング情報はEVPN NLRIを含み、EVPN NLRIはサービスネゴシエーションルートをアドバタイズするために使用され、EVPN NLRIは第1の指示情報を搬送するために使用される。言い換えれば、EVPN NLRIは、図6に示す方法におけるサービスネゴシエーションルート専用のEVPN NLRIであってもよい。
前述の技術的解決策では、新たに追加された専用のEVPN NLRIを使用して、非イーサネットサービスネゴシエーションを実行し、ネゴシエーションされることを必要とする非イーサネットサービスのサービスタイプを示す。非イーサネットサービスネゴシエーションを実行し、ネゴシエーションされることを必要とする非イーサネットサービスのサービスタイプを示すために、追加の拡張コミュニティを使用する必要はない。したがって、前述の技術的解決策は、シグナリングオーバーヘッドを低減し、それによって非イーサネットサービスのネゴシエーション速度を改善することができる。
いくつかの実施形態では、EVPN NLRI内のルートタイプ(route type)フィールドは、EVPN NLRIによってアドバタイズされたルートのタイプがサービスネゴシエーションルートであることを示す。
いくつかの実施形態では、EVPN NLRIは、ルート識別部フィールド、カプセル化タイプフィールド、カプセル化サービスIDフィールド、およびマルチプロトコルラベルスイッチング・ラベルフィールドを含む。カプセル化タイプフィールドは、第1の指示情報を搬送するために使用される。ルート識別部フィールド、カプセル化タイプフィールド、カプセル化サービスIDフィールド、およびマルチプロトコルラベルスイッチング・ラベルフィールドは、TLV構造体内の値(Value)フィールドの内容とすることができる。EVPN NLRIによってアドバタイズされたルートのタイプを示すために使用される前述のルートタイプフィールドは、TLVフィールド内のタイプフィールドであり得る。
いくつかの実施形態では、EVPNルーティング情報は第2の指示情報をさらに含み、第2の指示情報はターゲット非イーサネットサービスのサービスパラメータを示すために使用される。第1のネットワークデバイスが、ターゲット非イーサネットサービスのサービスタイプに基づいて、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立することは、第1のネットワークデバイスが、ターゲット非イーサネットサービスのサービスタイプおよびターゲット非イーサネットサービスのサービスパラメータに基づいて、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立することを含む。
いくつかの実施形態では、EVPNルーティング情報はEVPNエミュレーテッドパラメータ拡張コミュニティを含み、EVPNエミュレーテッドパラメータ属性拡張コミュニティは第2の指示情報を搬送する。
いくつかの実施形態では、EVPNルーティング情報は第3の指示情報をさらに含み、第3の指示情報はターゲット非イーサネットサービスが制御語をサポートするかどうかを示すために使用される。第1のネットワークデバイスが第2のネットワークデバイスとのターゲット非イーサネットサービスを確立する前に、本方法は、第1のネットワークデバイスが、ターゲット非イーサネットサービスと第1のネットワークデバイスによって確立されると予想される非イーサネットサービスの両方が制御語をサポートするか、またはターゲット非イーサネットサービスと第1のネットワークデバイスによって確立されると予想される非イーサネットサービスのいずれも制御語をサポートしないと判定することをさらに含む。
いくつかの実施形態では、第3の指示情報は、EVPNレイヤ2属性拡張コミュニティによって搬送される。
前述の技術的解決策は、既存のEVPNレイヤ2属性拡張コミュニティを再利用して、第3の指示情報を搬送する。したがって、前述の技術的解決策は、既存のプロトコルに比較的小さな変更を加え、その結果、既存のネットワークデバイスは、本出願で提案される非イーサネットサービスネゴシエーション方法をサポートする。加えて、第3の指示情報および第1の指示情報は、同じ拡張コミュニティによって搬送されてもよい。したがって、シグナリングオーバーヘッドが低減され得る。
いくつかの実施形態では、第3の指示情報は、EVPNエミュレーテッドパラメータ拡張コミュニティによって搬送される。前述の技術的解決策では、同じ拡張コミュニティを使用して、第2の指示情報および第3の指示情報を搬送し、その結果、シグナリングオーバーヘッドが低減され得る。
いくつかの実施形態では、第1のネットワークデバイスが、ターゲット非イーサネットサービスのサービスタイプに基づいて、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立することは、ターゲット非イーサネットサービスのサービスタイプが第1のネットワークデバイスによって確立されると予想される非イーサネットサービスのサービスタイプと同じであると判定したとき、第1のネットワークデバイスが、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立することを含む。
いくつかの実施形態では、第1のネットワークデバイスが、ターゲット非イーサネットサービスのサービスタイプおよびターゲット非イーサネットサービスのサービスパラメータに基づいて、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立することは、ターゲット非イーサネットサービスのサービスタイプが第1のネットワークデバイスによって確立されると予想される非イーサネットサービスのサービスタイプと同じであり、ターゲット非イーサネットサービスのパラメータが第1のネットワークデバイスによって確立されると予想される非イーサネットサービスのパラメータと同じであると判定したとき、第1のネットワークデバイスが、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立することを含む。
非イーサネットサービスネゴシエーション情報の具体的な内容および機能については、図2~図6、図3~図6、および図7~図12に示す方法の説明を参照されたい。第1のネットワークデバイスが第2のネットワークデバイスとの非イーサネットサービスネゴシエーションを実行する具体的なプロセスについては、図2および図6に示した方法の説明を参照されたい。図13に示す方法におけるターゲット非イーサネットサービスは、図2および図6に示した方法における第2の非イーサネットサービスと同等であることが理解されよう。
図2に示す方法では、第1の指示情報はEVPNレイヤ2属性拡張コミュニティによって搬送されることが理解されよう。いくつかの他の実装形態では、第1の指示情報は、代替として、EVPNレイヤ2属性拡張コミュニティ以外の別の拡張コミュニティによって搬送されてもよい。例えば、第1の指示情報は、新たに設定された拡張コミュニティによって搬送されてもよい。あるいは、いくつかの他の実施形態では、第1の指示情報は、拡張コミュニティ以外の情報によって搬送されてもよい。簡潔にするために、ここでは詳細を説明しない。
同様に、図2および図6に示す方法では、第2の指示情報は、EVPNエミュレーテッドパラメータ拡張コミュニティによって搬送される。いくつかの他の実装形態では、第1の指示情報は、代替として、EVPNエミュレーテッドパラメータ拡張コミュニティ以外の別の拡張コミュニティによって搬送されてもよい。例えば、第1の指示情報は、新たに設定された拡張コミュニティによって搬送されてもよい。あるいは、いくつかの他の実施形態では、第1の指示情報は、拡張コミュニティ以外の情報によって搬送されてもよい。簡潔にするために、ここでは詳細を説明しない。
図2および図6に示す方法では、第3の指示情報は、制御フラグフィールド内の制御語インジケータビットである。より具体的には、図2に示す方法では、第3の指示情報は、EVPNレイヤ2属性拡張コミュニティ内の制御フラグフィールドの制御語インジケータビットである。これに対応して、第1のネットワークデバイスは、EVPNレイヤ2属性拡張コミュニティ内の制御フラグフィールドを取得することによって第3の指示情報を取得する。図6に示す方法では、第3の指示情報は、EVPNエミュレーテッドパラメータ拡張コミュニティ内の制御フラグフィールドの制御語インジケータビットである。これに対応して、第1のネットワークデバイスは、EVPNエミュレーテッドパラメータ拡張コミュニティ内の制御フラグフィールドを取得することによって第3の指示情報を取得する。同様に、他の可能な実装形態では、第3の指示情報は、EVPNレイヤ2属性拡張コミュニティまたはEVPNエミュレーテッドパラメータ拡張コミュニティ以外の拡張コミュニティを使用して搬送されてもよい。例えば、第3の指示情報は、新たに設定された拡張コミュニティによって搬送されてもよい。あるいは、いくつかの他の実施形態では、第3の指示情報は、拡張コミュニティ以外の情報によって搬送されてもよい。簡潔にするために、ここでは詳細を説明しない。加えて、いくつかの他の実施形態では、第3の指示情報は、制御フラグフィールド内の制御語インジケータビットに限定されなくてもよい。例えば、第3の指示情報は別個のフィールドであってもよく、そのフィールドは、ターゲット非イーサネットサービスが制御語をサポートするかどうかを示すために使用される。また、第3の指示情報は、1ビットに限定されずに示されてもよい。第3の指示情報は、2つ以上のビットを含み得る。
図14は、本出願の一実施形態によるネットワークデバイスの概略構造図である。ネットワークデバイスは、上述の方法におけるネットワークデバイスであってもよい。図14に示すように、通信装置1400は、処理ユニット1401および受信ユニット1402を含み得る。
受信ユニット1402が、第2のネットワークデバイスによって送信された境界ゲートウェイプロトコルBGPメッセージを受信するように構成され、BGPメッセージはイーサネット仮想プライベートネットワークEVPNルーティング情報を搬送し、EVPNルーティング情報は第1の指示情報を含み、第1の指示情報はターゲット非イーサネットサービスのサービスタイプを示すために使用され、ターゲット非イーサネットサービスは第2のネットワークデバイスによって確立されると予想される非イーサネットサービスである。
処理ユニット1401は、第1の指示情報に基づいてターゲット非イーサネットサービスのサービスタイプを決定するように構成される。
処理ユニット1401は、ターゲット非イーサネットサービスのサービスタイプに基づいて、第2のネットワークデバイスとのターゲット非イーサネットサービスを確立するようにさらに構成される。
可能な方式では、処理ユニット1401はプロセッサによって実装されてもよく、受信ユニット1402は受信器によって実装されてもよい。処理ユニット1401および受信ユニット1402の具体的な機能と有益な効果については、前述の方法における説明を参照されたい。簡潔にするため、ここでは詳細を繰り返し説明しない。
図15は、本出願の一実施形態によるネットワークデバイスの概略構造図である。ネットワークデバイスは、前述の方法における第2のネットワークデバイスであってもよいし、前述の方法における第2のネットワークデバイスで使用され得る構成要素(例えば、チップまたは回路)であってもよい。図15に示すように、通信装置1500は、処理ユニット1501および送信ユニット1502を含み得る。
処理ユニット1501が、境界ゲートウェイプロトコルBGPメッセージを決定するように構成され、BGPメッセージはイーサネット仮想プライベートネットワークEVPNルーティング情報を搬送し、EVPNルーティング情報は第1の指示情報を含み、第1の指示情報はターゲット非イーサネットサービスのサービスタイプを示すために使用される。ターゲット非イーサネットサービスは、第2のネットワークデバイスが第1のネットワークデバイスと確立されると予想される非イーサネットサービスである。
送信ユニット1502は、BGPメッセージを第1のネットワークデバイスに送信するように構成される。
可能な方式では、処理ユニット1501はプロセッサによって実装されてもよく、送信ユニット1502は送信器によって実装されてもよい。処理ユニット1501および送信ユニット1502の具体的な機能と有益な効果については、前述の方法における説明を参照されたい。簡潔にするため、ここでは詳細を繰り返し説明しない。
図16は、本出願の一実施形態によるネットワークデバイスの構造ブロック図である。図16に示すように、ネットワークデバイスは、プロセッサ1601と、メモリ1602と、トランシーバ1603とを含む。プロセッサ1601は、通信プロトコルおよび通信データを処理し、ネットワークデバイスを制御し、ソフトウェアプログラムを実行し、ソフトウェアプログラムのデータを処理するなどのために構成されてもよい。メモリ1602は、主に、ソフトウェアプログラムおよびデータを記憶するように構成される。トランシーバ1603は、別のデバイス(例えば、PEデバイス、Pデバイス、またはCEデバイス)によって送信された情報を受信し、または別のデバイスに情報を送信するように構成される。
説明を容易にするため、1個のメモリと1個のプロセッサだけを図16に示している。実際のネットワークデバイス製品では、1つまたは複数のプロセッサおよび1つまたは複数のメモリがあってもよい。メモリは、記憶媒体、記憶デバイスなどと呼ばれることもある。メモリは、プロセッサから独立して配置されてもよく、またはプロセッサと一体化されてもよい。これは、本出願のこの実施形態に限定されない。
トランシーバは、トランシーバユニット、トランシーバマシン、トランシーバ装置などと呼ばれることもある。処理ユニットは、プロセッサ、処理基板、処理モジュール、処理装置などと呼ばれることもある。トランシーバ1603内にあり、受信機能を実施するように構成された構成要素は、受信ユニットと見なされてもよく、トランシーバ1603内にあり、送信機能を実施するように構成された構成要素は、送信ユニットと見なされてもよい。言い換えれば、トランシーバ1603は、受信ユニットと送信ユニットとを含む。受信ユニットは、受信機、受信器、受信回路などと呼ばれる場合もある。送信ユニットは、送信機、送信器、送信回路などを呼ばれることもある。
プロセッサ1601、メモリ1602、およびトランシーバ1603は、制御および/またはデータ信号を転送するために、内部の接続経路を通じて互いに通信する。
本出願の前述した実施形態に開示される方法は、プロセッサ1601に適用されてもよく、またはプロセッサ1601によって実施されてもよい。プロセッサ1601は、集積回路チップであってもよく、信号処理能力を有する。実施プロセスでは、前述の方法におけるステップは、プロセッサ1601内のハードウェア集積論理回路を使用することによって、またはソフトウェアの形態の命令を使用することによって実施することができる。
本出願の実施形態におけるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ(digital signal processor、DSP)、特定用途向け集積回路(application specific integrated circuit、ASIC)、フィールド・プログラマブル・ゲート・アレイ(field programmable gate array、FPGA)もしくは別のプログラマブルロジックデバイス、単体のゲートもしくはトランジスタロジックデバイス、または単体のハードウェア構成要素であり得る。プロセッサは、本出願の実施形態で開示された方法、ステップ、および論理ブロック図を実装または実行することができる。汎用プロセッサはマイクロプロセッサであってもよく、またはプロセッサは任意の従来のプロセッサなどであってよい。本出願の実施形態を参照して開示された方法のステップは、ハードウェア復号プロセッサを使用して直接実行および遂行されてもよく、復号プロセッサ内のハードウェアモジュールとソフトウェアモジュールの組合せを使用して実行および遂行されてもよい。ソフトウェアモジュールは、当技術分野において成熟したコンピュータ可読記憶媒体、例えば、ランダムアクセスメモリ(random access memory、RAM)、フラッシュメモリ、読み出し専用メモリ(read-only memory、ROM)、プログラマブル読み出し専用メモリ、電気的消去可能プログラマブルメモリ、レジスタなどに配置され得る。コンピュータ可読記憶媒体はメモリに配置されてもよく、プロセッサは、メモリ内の命令を読み出し、プロセッサのハードウェアと併せて、上記の方法のステップを完了する。
いくつかの実施形態では、メモリ1602は、図2、図3、および/または図6に示す方法で第1のネットワークデバイスによって実行される方法を実行する命令を記憶することができる。プロセッサ1601はメモリ1602内に記憶された命令を遂行してもよく、対応する方法で第1のネットワークデバイスによって実行されるステップを他のハードウェア(例えば、トランシーバ1603)と共同で完遂してもよい。具体的な作業プロセスと有益な効果については、上記の実施形態における説明を参照されたい。
いくつかの実施形態では、メモリ1602は、図2、図3、および/または図6に示す方法で第2のネットワークデバイスによって実行される方法を実行する命令を記憶することができる。プロセッサ1601はメモリ1602内に記憶された命令を遂行してもよく、対応する方法で第2のネットワークデバイスによって実行されるステップを他のハードウェア(例えば、トランシーバ1603)と共同で完遂してもよい。具体的な作業プロセスと有益な効果については、上記の実施形態における説明を参照されたい。
いくつかの実施形態では、メモリ1602は、図2、図3、および/または図6に示す方法で第1のネットワークデバイスおよび第2のネットワークデバイスによって実行される方法を実行する命令を記憶することができる。プロセッサ1601はメモリ1602内に記憶された命令を遂行してもよく、対応する方法で第1のネットワークデバイスによって実行されるステップまたは第2のネットワークデバイスによって実行されるステップを他のハードウェア(例えば、トランシーバ1603)と共同で完遂してもよい。具体的な作業プロセスと有益な効果については、上記の実施形態における説明を参照されたい。
本出願の実施形態はチップをさらに提供し、チップはトランシーバユニットと処理ユニットとを含む。トランシーバユニットは、入力/出力回路または通信インタフェースであってもよい。処理ユニットは、チップに集積されたプロセッサ、マイクロプロセッサ、または集積回路である。チップは、前述の方法実施形態において第1のネットワークデバイスによって実行される方法を実行してもよい。
本出願の実施形態はチップをさらに提供し、チップはトランシーバユニットと処理ユニットとを含む。トランシーバユニットは、入力/出力回路または通信インタフェースであってもよい。処理ユニットは、チップに集積されたプロセッサ、マイクロプロセッサ、または集積回路である。チップは、前述の方法実施形態において第2のネットワークデバイスによって実行される方法を実行してもよい。
本出願の一実施形態はコンピュータ可読記憶媒体をさらに提供し、コンピュータ可読記憶媒体は命令を記憶し、命令が実行されると、前述の方法実施形態において第1のネットワークデバイスによって実行される方法が実行される。
本実施形態の別の形態では、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は命令を記憶する。命令が実行されると、前述の方法実施形態において第2のネットワークデバイスによって実行される方法が実行される。
本出願の一実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。命令が実行されると、前述の方法実施形態において第1のネットワークデバイスによって実行される方法が実行される。
本実施形態の別の形態では、命令を含むコンピュータプログラム製品が提供される。命令が実行されると、前述の方法実施形態において第2のネットワークデバイスによって実行される方法が実行される。
本出願の一実施形態は通信システムをさらに提供する。通信システムは、第1のネットワークデバイスおよび第2のネットワークデバイスを含む。
いくつかの実施形態では、通信システム内の第1のネットワークデバイスは、図13に示す方法における第1のネットワークデバイスによって実行されるステップを実行するように構成されてもよい。通信システム内の第2のネットワークデバイスは、図13に示す方法における第2のネットワークデバイスによって実行されるステップを実行するように構成されてもよい。
いくつかの実施形態では、通信システム内の第1のネットワークデバイスは、図2に示す方法における第1のネットワークデバイスによって実行されるステップを実行するように構成されてもよい。通信システム内の第2のネットワークデバイスは、図2に示す方法における第2のネットワークデバイスによって実行されるステップを実行するように構成されてもよい。
いくつかの実施形態では、通信システム内の第1のネットワークデバイスは、図6に示す方法における第1のネットワークデバイスによって実行されるステップを実行するように構成されてもよい。通信システム内の第2のネットワークデバイスは、図6に示す方法における第2のネットワークデバイスによって実行されるステップを実行するように構成されてもよい。
当業者は、本明細書に開示される実施形態で説明された例との組合せにおいて、ユニットおよびアルゴリズムステップが、電子ハードウェアまたはコンピュータソフトウェアと電子ハードウェアとの組合せによって実施され得ることを認識し得る。機能がハードウェアまたはソフトウェアのいずれによって実行されるかは、特定のアプリケーションおよび技術的解決策の設計制約に依存する。当業者はそれぞれの特定の用途について説明されている機能をさまざまな方法で実装できるが、その実装形態は本出願の範囲を超えてなされると見なすべきではない。
便利で簡潔な説明のために、前述のシステム、装置、およびユニットの詳細な動作プロセスについては、前述の方法実施形態内の対応するプロセスを参照することは、当業者には明確に理解されよう。詳細はここでは再度説明されない。
本出願で提供されるいくつかの実施形態では、開示されたシステム、装置、および方法は他の方法で実施され得ることを理解されたい。例えば、説明された装置の実施形態は一例にすぎない。例えば、ユニットへの分割は単なる論理的な機能分割であり、実際の実装形態では他の分割になり得る。例えば、複数のユニットまたは構成要素は、別のシステムに組み合わされ、もしくは統合されてもよく、またはいくつかの機能は無視されてもよく、もしくは実行されなくてもよい。加えて、表示または論述されている相互結合または直接結合または通信接続は、いくつかのインタフェースを介して実装されてもよい。装置間またはユニット間の間接結合または通信接続は、電子的、機械的、または他の形態で実装されてもよい。
別々の部分として記載されたユニットは、物理的に分離されていてもいなくてもよく、ユニットとして表示された部分は物理ユニットであってもなくてもよく、1つの場所に配置されてもよく、複数のネットワークユニットに分散されてもよい。ユニットの一部または全部は、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択されてもよい。
また、本出願の実施形態の機能ユニットは、1つの処理ユニットに統合されてもよく、ユニットのそれぞれが物理的に単独で存在してもよく、または2つ以上の部品が1つの部品に統合されてもよい。
機能が、ソフトウェア機能ユニットの形態で実施され、独立した製品として販売または使用される場合、機能は、コンピュータ可読記憶媒体に記憶されてもよい。そのような理解に基づいて、本出願の技術的解決策は本質的に、または従来技術に寄与する部分、もしくは技術的解決策の一部は、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は記憶媒体に記憶され、コンピュータデバイス(パーソナルコンピュータ、サーバ、またはネットワークデバイスであってもよい)に本出願の実施形態で説明されている方法のステップの全部または一部を実行するように指示するためのいくつかの命令を含む。前述の記憶媒体は、例えば、USBフラッシュドライブ、取り外し可能なハードディスク、読み出し専用メモリ(Read-Only Memory、ROM)、ランダムアクセスメモリ(Random Access Memory、RAM)、磁気ディスク、または光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。
前述の説明は、本出願の特定の実施態様にすぎず、本出願の保護範囲を限定することを意図していない。本出願で開示された技術的範囲内で当業者によって容易に考え出されるいかなる変形または置換も、本出願の保護範囲内にあるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うべきである。