JP7536993B2 - ネットワーク内のトラフィック・エンジニアリング・トンネルの数を削減するためのデータ処理方法、装置、媒体、およびコンピュータプログラム - Google Patents

ネットワーク内のトラフィック・エンジニアリング・トンネルの数を削減するためのデータ処理方法、装置、媒体、およびコンピュータプログラム Download PDF

Info

Publication number
JP7536993B2
JP7536993B2 JP2023503020A JP2023503020A JP7536993B2 JP 7536993 B2 JP7536993 B2 JP 7536993B2 JP 2023503020 A JP2023503020 A JP 2023503020A JP 2023503020 A JP2023503020 A JP 2023503020A JP 7536993 B2 JP7536993 B2 JP 7536993B2
Authority
JP
Japan
Prior art keywords
network device
packet
route
network
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2023503020A
Other languages
English (en)
Other versions
JP2023534050A (ja
Inventor
志波 胡
▲カ▼ ▲張▼
晟 方
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN202011256894.2A external-priority patent/CN114024900A/zh
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2023534050A publication Critical patent/JP2023534050A/ja
Application granted granted Critical
Publication of JP7536993B2 publication Critical patent/JP7536993B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/748—Address table lookup; Address filtering using longest matching prefix
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

本出願は、2020年7月17日に出願された「ROUTING POLICY CONTROL METHOD，APPARATUS，AND SYSTEM」という名称の中国特許出願第202010692883．2号、2020年11月10日に出願された「DATA PROCESSING METHOD AND RELATED DEVICE」という名称の中国特許出願第202011248687．2号、および2020年11月11日に出願された「DATA PROCESSING METHOD AND RELATED DEVICE」という名称の中国特許出願第202011256894．2号の優先権を主張し、これらの全体が参照により本明細書に組み込まれる。
本出願は、通信技術の分野に関し、特に、データ処理方法および関連デバイスに関する。
クラウドコンピューティングは、コンピューティングタスクが大量のコンピュータを含むリソースプールに分散される新しいコンピューティングモデルであり、その結果、様々なアプリケーションシステムは、必要に応じてコンピューティング能力、ストレージスペース、および様々なソフトウェアサービスを取得することができる。クラウドコンピューティングシステムでは、クラウドサーバは集中的に配置されてもよく、すべてのアプリケーションシステムがクラウドサーバ上で実行されるので、その結果、ユーザ（個人ユーザまたは企業ユーザなど）が端末を使用してクラウドサーバにアクセスする。
ユーザが端末を使用してクラウドサーバにアクセスする方式は、ユーザの端末が位置されるメトロポリタン・エリア・ネットワークとクラウドサービスが位置されるバックボーンネットワークとの間にエンドツーエンド接続トンネルを通常、確立し、その結果、ユーザがトンネルに基づいてクラウドサーバにアクセスすることである。
しかしながら、このようにトンネルを確立するためには、異なるユーザまたは異なるサービスに対して異なるトンネルまたはトラフィック・エンジニアリング・トンネルが構成される必要が通常あり、これは大量のトンネルまたはトラフィック・エンジニアリング・トンネルおよび複雑なネットワークをもたらす。
本出願は、ネットワーク内のトラフィック・エンジニアリング・トンネルの数を削減するために、データ処理方法および関連デバイスを提供する。
第1の態様によれば、データ処理方法が提供され、本方法は、第1のネットワークデバイスが第1のサブネットプレフィックスを取得し、第1のサブネットプレフィックスがトラフィック・エンジニアリング・トンネルの宛先識別子であり、サブネットプレフィックスが2つのフィールド、すなわちIPアドレスおよびマスクを含んでもよいことを含む。例えば、サブネットプレフィックスはA1：：1／32であってもよい。第1のネットワークデバイスは、取得された第1のサブネットプレフィックスに基づいてデータ処理を実行する。トラフィック・エンジニアリング・トンネルの宛先識別子はサブネットプレフィックスを含むので、トラフィック・エンジニアリング・トンネルは、異なる宛先アドレスを有する複数のパケットを照合することができ、その結果、ネットワーク内のトラフィック・エンジニアリング・トンネルの数が低減され得、構成または管理の複雑さが回避され得る。
可能な実施態様では、第1のネットワークデバイスが第1のサブネットプレフィックスに基づいてデータ処理を実行することは、第1のネットワークデバイスが第1のパケットを取得することを含む。第1のアドレスと第1のサブネットプレフィックスとの間に最長一致がある場合には、第1のネットワークデバイスが、トラフィック・エンジニアリング・トンネルを介して第1のパケットを送信し、第1のアドレスが第1のパケットの宛先アドレスに基づいて取得される。
可能な実施態様では、第1のアドレスは、第1のパケットの宛先アドレスまたは第1のパケットに基づいて第1のネットワークデバイスによって決定されたネクストホップ転送アドレスを含む。
パケットを転送する場合、ネットワークデバイスは、パケットの転送情報とサブネットプレフィックスとの間の最長一致に基づいてパケットを転送する。これにより、パケットの特徴に基づいてトンネルなどの関連情報を1つずつ構成することを回避し、トンネルの数を削減し、パケット転送効率を向上させる。
可能な実施態様では、トラフィック・エンジニアリング・トンネルは、セグメント・ルーティング・ポリシー（Segment Routing Policy、SR Policy）またはセグメント・ルーティング・トラフィック・エンジニアリング（segment routing traffic engineering、SR TEトンネル）を含むことができる。
可能な実施態様では、第1のネットワークデバイスが第1のサブネットプレフィックスに基づいてデータ処理を実行することは、第1のネットワークデバイスが、第1のサブネットプレフィックスに基づいて第1のルーティングパケットを告知し、第1のルーティングパケットが第2のサブネットプレフィックスを含み、第2のサブネットプレフィックスの範囲が第1のサブネットプレフィックスの範囲を含むことを含む。
可能な実施態様では、第1のルーティングパケットは内部ゲートウェイプロトコルIGPパケットを含む。
可能な実施態様では、第1のルーティングパケットは経路識別子をさらに含む。
可能な実施態様では、経路識別子は、第1のネットワークデバイスに含まれるセグメント識別子SIDを含み、第1のルートは、SIDとネットワークスライス識別子との間のマッピング関係をさらに含む。
第2の態様によれば、データ処理方法が提供され、本方法は、第1のネットワークデバイスが第2のネットワークデバイスにトラフィック・エンジニアリング・トンネルを送信し、トラフィック・エンジニアリング・トンネルの宛先識別子がサブネットプレフィックスを含むことを含む。
トラフィック・エンジニアリング・トンネルは、第2のネットワークデバイスがサブネットプレフィックスの最長一致方式でトラフィック・エンジニアリング・トンネルと一致することを可能にするために使用されてもよく、その結果、ネットワーク内のトンネルの数が低減される。
可能な実施態様では、トラフィック・エンジニアリング・トンネルは、セグメント・ルーティング・ポリシーSR Policyまたはセグメント・ルーティング・トラフィック・エンジニアリングSR TEトンネルを含む。
第3の態様によれば、データ処理方法が提供され、本方法は、第1のネットワークデバイスが、第2のネットワークデバイスによって発行された第1のルートを取得し、第1のルートが第1のルートプレフィックスおよび第1のアドレスを含むことを含む。第1のネットワークデバイスは、中間ネットワークデバイスによって発行された第2のルートを取得し、第2のルートは第1のサブネットプレフィックスおよび経路識別子を含む。第1のサブネットプレフィックスの範囲は、第1のアドレスを含む。第1のネットワークデバイスは第1のパケットを受信し、第1のパケットの宛先アドレスと第1のルートプレフィックスとの間に最長一致がある。第1のネットワークデバイスは、第2のパケットを取得するために第1のパケットを更新する。第1のネットワークデバイスは出口を介して第2のパケットを送信し、出口は経路識別子に基づいて第1のネットワークデバイスによって決定される。
中間ネットワークデバイスによって発行された第2のルートが第2のネットワークデバイスによって発行された第1のルートに対応する方式では、パケットを受信した後に、第1のネットワークデバイスは、パケットの宛先アドレスが第1のルートに対応することに基づいて、第2のルートを使用してパケットを転送することを決定してもよい。すなわち、ネットワークでは、パケットを送信するためのトンネルまたは経路がサブネットプレフィックスの方式で決定され、これにより、ネットワーク内のトンネルまたはトラフィック・エンジニアリング・トンネルの数を減らし、構成または管理の複雑さを回避することができる。
可能な実施態様では、第1のアドレスは、ネクストホップアドレスまたは第1のセグメント識別子（Segment Identifier、SID）を含む。
可能な実施態様では、第1のネットワークデバイスが第2のパケットを取得するために第1のパケットを更新することは、第1のネットワークデバイスが、第1のパケットの宛先アドレスと第1のルートプレフィックスとの間の最長一致に基づいて、第1のパケットに対応するネクストホップアドレスが第1のSIDであると決定することを含む。第1のネットワークデバイスは、第2のパケットを取得するために第1のパケットを更新し、第2のパケットは第1のSIDを含む。
最長一致方式で、第1のパケットの宛先アドレスが第1のルートプレフィックスと一致すると決定した後に、第1のネットワークデバイスは、そのパケットにおいて、転送を示す第1のSIDをカプセル化する。これにより、後続のネットワークデバイスが第1のSIDに基づいてパケットを転送できることを保証し、第1のパケットが第1のSIDに基づいて転送され得ることを保証し、この解決策の実施可能性を向上させる。可能な実施態様では、経路識別子は、第1のネットワークスライス識別子または第2のSIDを含み、第2のSIDは中間ネットワークデバイスのSIDである。
可能な実施態様では、経路識別子が第2のSIDである場合には、第2のルートは、第2のSIDと第2のネットワークスライス識別子との間のマッピング関係をさらに含む。
第1のネットワークスライス識別子または第2のSIDは、経路識別子を表すために使用され、その結果、従来の技術に対する変更が最小限に抑えられ得、この解決策の実施可能性が改善される。
可能な実施態様では、第2のパケットは経路識別子をさらに含む。経路識別子がネットワークスライス識別子である場合、第2のパケットのホップバイホップヘッダはネットワークスライス識別子を含む。
可能な実施態様では、第1のネットワークデバイスが出口を介して第2のパケットを送信する前に、本方法は、第1のネットワークデバイスが、第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のアドレスと経路識別子との間の対応関係を生成することをさらに含む。
第1のネットワークデバイスは、第1のSIDと経路識別子との間の対応関係を事前生成し、その結果、第1のSIDを含む第2のパケットを取得する場合に、第1のネットワークデバイスは、対応関係に基づいて、経路識別子に対応する出口を決定することができる。これにより、第1のSIDと経路識別子とを照合する時間を節約し、転送効率を向上させる。
可能な実施態様では、本方法は、第1のネットワークデバイスが、第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のアドレスと出口の識別子との間の対応関係を生成することをさらに含む。
第1のネットワークデバイスは、第1のSIDと出口との間の対応関係を事前生成し、その結果、第1のSIDを含む第2のパケットを取得する場合、第1のネットワークデバイスは、対応関係に基づいて、第1のSIDに対応する出口を決定することができる。これは、転送中の経路計算時間を節約し、転送効率を改善する。
可能な実施態様では、経路識別子は、中間ネットワークデバイスに含まれるネットワークスライス識別子または第2のSIDを含む。ネットワークスライス識別子は、例えば、FlexAlgo IDであってもよく、第2のSIDは、例えば、END SIDであってもよい。
可能な実施態様では、第2のパケットは経路識別子をさらに含む。
可能な実施態様では、経路識別子はネットワークスライス識別子を含み、ネットワークスライス識別子は第2のパケットのホップバイホップヘッダで搬送される。
可能な実施態様では、第2のルートは内部ゲートウェイプロトコル（Interior Gateway Protocol、IGP）ルートである。中間ネットワークデバイスは、IGPプロトコルに従って第1のネットワークデバイスへのIGPルートを発行し、その結果、従来技術に対する修正が最小限に抑えられ得、この解決策の実施可能性が改善される。
可能な実施態様では、中間ネットワークデバイスは第1のネットワークデバイスと第2のネットワークデバイスとの間に配置され、第1のネットワークデバイスおよび第2のネットワークデバイスは異なるIGPドメインに属し、第1のネットワークデバイスおよび中間ネットワークデバイスは同じIGPドメインに属し、中間ネットワークデバイスはIGPドメイン内の境界ネットワークデバイスである。
可能な実施態様では、第1のネットワークデバイスはプロバイダエッジ（provider edge、PE）デバイスを含む。
可能な実施態様では、第2のネットワークデバイスはセグメントルーティングPEデバイスを含む。
可能な実施態様では、第1のSIDは、仮想プライベートネットワーク（virtual private network、VPN）セグメント識別子VPN SIDを含む。
第4の態様によれば、データ処理方法が提供され、本方法は、中間ネットワークデバイスが第1のサブネットプレフィックスおよび経路識別子を取得し、第1のサブネットプレフィックスが第1のトラフィック・エンジニアリング・トンネルの宛先識別子であり、第1のトラフィック・エンジニアリング・トンネルが経路識別子に対応することを含む。中間ネットワークデバイスはルート告知パケットを発行し、ルート告知パケットは第2のサブネットプレフィックスおよび経路識別子を含み、第2のサブネットプレフィックスの範囲は第1のサブネットプレフィックスの範囲を含む。
第2のサブネットプレフィックスを含む第1のトラフィック・エンジニアリング・トンネルを取得した後に、中間ネットワークデバイスは、第1のサブネットプレフィックスを搬送するルート告知パケットを発行し、第1のサブネットプレフィックスの範囲は第2のサブネットプレフィックスの範囲を含み、その結果、宛先アドレスが第2のサブネットプレフィックスと一致するパケットを受信すると、ルート告知パケットを受信したネットワークデバイスは、そのパケットを中間ネットワークデバイスに送信することができ、中間ネットワークデバイスは、次いで、第1のトラフィック・エンジニアリング・トンネルに基づいてそのパケットを転送する。これにより、ネットワーク内のトンネルまたはトラフィック・エンジニアリング・トンネルの数を低減し、構成または管理の複雑さを回避する。
可能な実施態様では、第1のトラフィック・エンジニアリング・トンネルはセグメント識別子リストをさらに含み、ルート告知パケットを発行するステップの後に、本方法は、中間ネットワークデバイスが第1のパケットを受信することをさらに含む。中間ネットワークデバイスは、第2のパケットを取得するために、第1のパケットの宛先アドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて第1のパケットを更新し、第2のパケットはセグメント識別子リストを含む。中間ネットワークデバイスは第2のパケットを送信する。
第1のSIDを含む第2のパケットを受信すると、中間ネットワークデバイスは、第3のパケットを取得するために、第1のトラフィック・エンジニアリング・トンネルに含まれるセグメント識別子リストに基づいて第2のパケットを更新することができ、中間ネットワークデバイスは、セグメント識別子リストに基づいて第3のパケットを転送することができる。これにより、第3のパケットが第2のネットワークデバイスに確実に転送され得る。
可能な実施態様では、第1のパケットの宛先アドレスは第1のセグメント識別子SIDを含む。
可能な実施態様では、ルート告知パケットは、第1のトラフィック・エンジニアリング・トンネルおよび経路識別子を取得することに応答して、第1のネットワークデバイスによって生成される。
可能な実施態様では、中間ネットワークデバイスは、対応関係に基づいて、第2のサブネットプレフィックスが経路識別子に対応すると決定する。
可能な実施態様では、第1のトラフィック・エンジニアリング・トンネルはセグメント・ルーティング・ポリシーSR Policyを含み、SR Policyは色識別子を含み、対応関係は色識別子と経路識別子との間の対応関係を含む。
可能な実施態様では、対応関係は、第1のサブネットプレフィックスと経路識別子との間の対応関係を含む。
中間ネットワークデバイスは、経路識別子と色識別子との間の対応関係に基づいて、SR Policyに対応する経路識別子を決定することができる。これにより、この解決策の実施可能性を向上させる。
可能な実施態様では、第1のトラフィック・エンジニアリング・トンネルはSR Policyを含み、中間ネットワークデバイスがルート告知パケットを発行する前に、本方法は、中間ネットワークデバイスが、第1のサブネットプレフィックスと経路識別子との間の対応関係を取得することをさらに含む。中間ネットワークデバイスは、第1のサブネットプレフィックスおよび対応関係に基づいて、SR Policyが経路識別子に対応すると決定する。
可能な実施態様では、中間ネットワークデバイスがルート告知パケットを発行する前に、本方法は、中間ネットワークデバイスが第2のトラフィック・エンジニアリング・トンネルを取得し、第2のトラフィック・エンジニアリング・トンネルが第3のサブネットプレフィックスを含むことをさらに含む。中間ネットワークデバイスは、第2のトラフィック・エンジニアリング・トンネルが経路識別子に対応すると決定する。中間ネットワークデバイスは、第1のサブネットプレフィックスおよび第3のサブネットプレフィックスに基づいて第2のサブネットプレフィックスを決定し、第2のサブネットプレフィックスの範囲は、第1のサブネットプレフィックスの範囲および第3のサブネットプレフィックスの範囲を含む。
複数のトラフィック・エンジニアリング・トンネルを取得すると、中間ネットワークデバイスは、複数のトラフィック・エンジニアリング・トンネルのサブネットプレフィックスに基づいて集約されたサブネットプレフィックスを取得することができ、その結果、集約されたサブネットプレフィックスは、ルート告知パケットを発行するプロセスで搬送される。これにより、ルート告知パケットの数を減少させ、パケットオーバーヘッドを節約する。
可能な実施態様では、経路識別子は、第1のネットワークスライス識別子または第2のSIDを含み、第2のSIDは中間ネットワークデバイスのSIDである。
可能な実施態様では、経路識別子が中間ネットワークデバイスに含まれる第2のSIDである場合、第2のルートは、第2のSIDと第2のネットワークスライス識別子との間のマッピング関係をさらに含む。
可能な実施態様では、中間ネットワークデバイスは、中間ネットワークデバイスが位置されるIGPドメインでルート告知パケットを発行する。
第5の態様によれば、データ処理方法が提供され、本方法は、第1のネットワークデバイスが、サブネットプレフィックスおよびセグメント識別子リストを取得し、サブネットプレフィックスがトラフィック・エンジニアリング・トンネルの宛先識別子であることを含む。第1のネットワークデバイスは、第2のネットワークデバイスによって発行された第1のルートを受信し、第1のルートはルートプレフィックスおよび第1のアドレスを含み、サブネットプレフィックスの範囲は第1のアドレスを含む。第1のネットワークデバイスは第1のパケットを受信し、第1のパケットの宛先アドレスとルートプレフィックスとの間に最長一致がある。第1のネットワークデバイスは第2のパケットを取得するために第1のパケットを更新し、第2のパケットはSIDおよびセグメント識別子リストを含む。第1のネットワークデバイスは第2のパケットを送信する。
可能な実施態様では、第1のアドレスは、第2のネットワークデバイスのネクストホップアドレスまたはセグメント識別子SIDを含む。
可能な実施態様では、第1のアドレスがSIDである場合、第2のパケットはSIDをさらに含む。
可能な実施態様では、本方法は、第1のネットワークデバイスが、ネクストホップアドレスとサブネットプレフィックスとの間の最長一致に基づいて、ルートプレフィックスおよびセグメント識別子リストを含む対応関係を生成することをさらに含む。
第1のネットワークデバイスは、ルートプレフィックスとセグメント識別子リストとの間の対応関係を事前生成し、その結果、宛先アドレスがルートプレフィックスと一致するパケットを受信すると、第1のネットワークデバイスは、そのパケットを転送するために、対応するセグメント識別子リストを決定することができる。これにより、パケット転送効率を向上させる。
可能な実施態様では、第1のネットワークデバイスが第1のパケットを更新することは、第1のネットワークデバイスが、第2のパケットを取得するために、第1のパケットの宛先アドレスとルートプレフィックスとの間の最長一致および対応関係に基づいて、第1のパケット内のセグメント識別子リストを更新することを含む。
可能な実施態様では、トラフィック・エンジニアリング・トンネルはSR Policyを含み、SR Policyは色識別子をさらに含み、第1のルートは経路識別子をさらに含み、第1のネットワークデバイスが第1のパケットを更新する前に、本方法は、第1のネットワークデバイスが、経路識別子が色識別子に対応することに基づいて、第1のルートがトラフィック・エンジニアリング・トンネルに対応することを決定することをさらに含む。
第1のルートがトラフィック・エンジニアリング・トンネルと一致するかどうか決定するプロセスでは、トラフィック・エンジニアリング・トンネルに対応するサービス要求が経路識別子に対応するサービス要求と同じであることを保証するために、トラフィック・エンジニアリング・トンネル内の色識別子が経路識別子と一致するかどうかがさらに比較される。これにより、パケット転送品質を保証する。
可能な実施態様では、経路識別子は、ネットワークスライス識別子または色識別子を含む。
可能な実施態様では、トラフィック・エンジニアリング・トンネルは、セグメント・ルーティング・トラフィック・エンジニアリングSR TEトンネルを含む。
可能な実施態様では、SIDは仮想プライベート・ネットワーク・セグメント識別子VPN SIDを含む。
可能な実施態様では、第1のネットワークデバイスはPEデバイスを含む。
可能な実施態様では、第2のネットワークデバイスはPEデバイスを含む。
第6の態様によれば、プロセッサおよび通信インターフェースを含むネットワークデバイスが提供される。プロセッサは命令を実行するように構成され、その結果、ネットワークデバイスが第1の態様の任意の実施態様による方法を実行する。
第7の態様によれば、プロセッサおよび通信インターフェースを含むネットワークデバイスが提供される。プロセッサは命令を実行するように構成され、その結果、ネットワークデバイスが第2の態様の任意の実施態様による方法を実行する。
第8の態様によれば、通信システムが提供される。ネットワークシステムは、第6の態様によるネットワークデバイスと、第7の態様によるネットワークデバイスと、を含む。
第9の態様によれば、プロセッサおよび通信インターフェースを含むネットワークデバイスが提供される。プロセッサは命令を実行するように構成され、その結果、ネットワークデバイスが第3の態様の任意の実施態様による方法を実行する。
第10の態様によれば、プロセッサおよび通信インターフェースを含む中間ネットワークデバイスが提供される。プロセッサは命令を実行するように構成され、その結果、中間ネットワークデバイスが第4の態様の任意の実施態様による方法を実行する。
第11の態様によれば、プロセッサおよび通信インターフェースを含むネットワークデバイスが提供される。プロセッサは命令を実行するように構成され、その結果、ネットワークデバイスが第5の態様の任意の実施態様による方法を実行する。
第12の態様によれば、ネットワークシステムが提供される。ネットワークシステムは、第9の態様によるネットワークデバイスおよび／または第10の態様による中間ネットワークデバイスを含む。
可能な実施態様では、ネットワークシステムは第11の態様によるネットワークデバイスをさらに含む。
第13の態様によれば、ネットワークシステムが提供される。ネットワークシステムは、第1のネットワークデバイスと、第1の中間ネットワークデバイスと、第2の中間ネットワークデバイスと、第2のネットワークデバイスと、を含む。第1の中間ネットワークデバイスは第1のサブネットプレフィックスおよび第2のサブネットプレフィックスを取得し、第1のサブネットプレフィックスは第1のトラフィック・エンジニアリング・トンネルの宛先識別子であり、第2のサブネットプレフィックスは第2のトラフィック・エンジニアリング・トンネルの宛先識別子である。第1の中間ネットワークデバイスは第1のルート告知パケットを送信し、第1のルート告知パケットは第3のサブネットプレフィックスを含み、第1の中間ネットワークデバイスは、第1のサブネットプレフィックスと第2のサブネットプレフィックスとを集約することによって第3のサブネットプレフィックスを取得する。第2の中間ネットワークデバイスは、第1のルート告知パケットを取得する。第2の中間ネットワークデバイスは、第2のネットワークデバイスによって送信された第1のパケットを受信し、パケットの宛先アドレスと第3のサブネットプレフィックスとの間に最長一致がある。第2の中間ネットワークデバイスは、第1のパケットに基づいて第2のパケットを取得し、第2のパケットを第1の中間ネットワークデバイスに送信する。
可能な実施態様では、第2の中間ネットワークデバイスが第2のネットワークデバイスによって送信されたパケットを受信する前に、本方法は、第2の中間ネットワークデバイスが、第3のサブネットプレフィックスに対応する第1のセグメント識別子SIDを取得することをさらに含む。第2の中間ネットワークデバイスは第2のルート告知パケットを発行し、第2のルート告知パケットは、第3のサブネットプレフィックス、第1のSID、および第1のアルゴリズム識別子を含み、第1のSIDは第1のアルゴリズム識別子に対応する。
可能な実施態様では、第1のパケットは第1のSIDをさらに含む。
可能な実施態様では、本方法は、第2の中間ネットワークデバイスが、第3のサブネットプレフィックスに対応する少なくとも1つのネットワークスライスを取得し、少なくとも1つのネットワークスライスが第2のネットワークスライスを含むことをさらに含む。第2の中間ネットワークデバイスは第3のルート告知パケットを発行し、第3のルート告知パケットは第3のサブネットプレフィックスおよび第2のネットワークスライスの識別子を含む。第2のネットワークデバイスは第3のルート告知パケットを取得し、第2のネットワークスライスの識別子に基づいて第3のサブネットプレフィックスの対応する出口を決定する。
可能な実施態様では、第1のパケットのホップバイホップヘッダは、第2のネットワークスライスの識別子を搬送する。
可能な実施態様では、第2の中間ネットワークデバイスおよび第2のネットワークデバイスは同じIGPドメインに属し、第1のネットワークデバイスおよび第2のネットワークデバイスは異なるIGPドメインに属する。
本出願の第14の態様はネットワークデバイスを提供し、ネットワークデバイスは、送信ユニット、処理ユニット、および受信ユニットを含む。受信ユニットは第1のサブネットプレフィックスを取得するように構成され、第1のサブネットプレフィックスはトラフィック・エンジニアリング・トンネルの宛先識別子である。処理ユニットは、第1のサブネットプレフィックスに基づいてデータ処理を実行するように構成される。
可能な実施態様では、受信ユニットは、第1のパケットを取得するようにさらに構成される。第1のアドレスと第1のサブネットプレフィックスとの間に最長一致がある場合には、送信ユニットは、トラフィック・エンジニアリング・トンネルを介して第1のパケットを送信するように構成され、第1のアドレスは第1のパケットの宛先アドレスに基づいて取得される。
可能な実施態様では、第1のアドレスは、第1のパケットの宛先アドレス、または宛先アドレスに基づいてネットワークデバイスによって決定されたネクストホップ転送アドレスを含む。
可能な実施態様では、送信ユニットは、第1のサブネットプレフィックスに基づいて第1のルーティングパケットを告知するようにさらに構成され、第1のルーティングパケットは第2のサブネットプレフィックスを含み、第2のサブネットプレフィックスの範囲は第1のサブネットプレフィックスの範囲を含む。
可能な実施態様では、第1のルーティングパケットは内部ゲートウェイプロトコルIGPパケットを含む。
可能な実施態様では、トラフィック・エンジニアリング・トンネルは、セグメント・ルーティング・ポリシーSR Policyトンネルまたはセグメント・ルーティング・トラフィック・エンジニアリングSR TEトンネルを含む。
本出願の第15の態様はネットワークデバイスを提供し、ネットワークデバイスは、送信ユニット、処理ユニット、および受信ユニットを含む。送信ユニットは、トラフィック・エンジニアリング・トンネルを第2のネットワークデバイスに送信するように構成され、トラフィック・エンジニアリング・トンネルの宛先識別子はサブネットプレフィックスを含む。
可能な実施態様では、トラフィック・エンジニアリング・トンネルは、セグメント・ルーティング・ポリシーSR Policyまたはセグメント・ルーティング・トラフィック・エンジニアリングSR TEトンネルを含む。
本出願の第16の態様はネットワークデバイスを提供し、ネットワークデバイスは、送信ユニット、処理ユニット、および受信ユニットを含む。受信ユニットは、第2のネットワークデバイスによって告知された第1のルートを取得するように構成され、第1のルートは第1のルートプレフィックスおよび第1のアドレスを含む。受信ユニットは、中間ネットワークデバイスによって発行された第2のルートを取得するようにさらに構成され、第2のルートは第1のサブネットプレフィックスおよび経路識別子を含み、第1のサブネットプレフィックスの範囲は第1のアドレスを含む。受信ユニットは第1のパケットを受信するように構成され、第1のパケットの宛先アドレスと第1のルートプレフィックスとの間に最長一致がある。処理ユニットは、第1のパケットを更新して第2のパケットを取得するように構成される。送信ユニットは出口を介して第2のパケットを送信するように構成され、出口は経路識別子に基づいて第1のネットワークデバイスによって決定される。
可能な実施態様では、第1のアドレスはネクストホップアドレスまたは第1のセグメント識別子SIDである。
可能な実施態様では、処理ユニットは、第1のパケットの宛先アドレスと第1のルートプレフィックスとの間の最長一致に基づいて、第1のパケットに対応するアドレスが第1のSIDであると決定するようにさらに構成される。処理ユニットは、第2のパケットを取得するために第1のパケットを更新するようにさらに構成され、第2のパケットは第1のSIDを含む。
可能な実施態様では、経路識別子は、第1のネットワークスライス識別子または第2のSIDを含み、第2のSIDは中間ネットワークデバイスのSIDである。
可能な実施態様では、経路識別子が第2のSIDである場合には、第2のルートは、第2のSIDと第2のネットワークスライス識別子との間のマッピング関係をさらに含む。
可能な実施態様では、第2のパケットは経路識別子をさらに含む。
可能な実施態様では、経路識別子はネットワークスライス識別子を含み、第2のパケットのホップバイホップヘッダはネットワークスライス識別子を含む。
可能な実施態様では、第2のルートは内部ゲートウェイプロトコルIGPルートである。
可能な実施態様では、中間ネットワークデバイスは第1のネットワークデバイスと第2のネットワークデバイスとの間に配置され、第1のネットワークデバイスおよび第2のネットワークデバイスは異なるIGPドメインに属し、第1のネットワークデバイスおよび中間ネットワークデバイスは同じIGPドメインに属し、中間ネットワークデバイスはIGPドメイン内の境界ネットワークデバイスである。
可能な実施態様では、第1のネットワークデバイスはプロバイダエッジPEデバイスである。
可能な実施態様では、第2のネットワークデバイスはPEデバイスを含む。
可能な実施態様では、第1のSIDは仮想プライベート・ネットワーク・セグメント識別子VPN SIDを含む。
可能な実施態様では、処理ユニットは、第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のアドレスと経路識別子との間の対応関係を生成するようにさらに構成される。
可能な実施態様では、処理ユニットは、第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のアドレスと出口の識別子との間の対応関係を生成するようにさらに構成される。
本出願の第17の態様はネットワークデバイスを提供し、ネットワークデバイスは、送信ユニット、処理ユニット、および受信ユニットを含む。受信ユニットは、第1のサブネットプレフィックスおよび経路識別子を取得するように構成され、第1のサブネットプレフィックスは第1のトラフィック・エンジニアリング・トンネルの宛先識別子であり、第1のトラフィック・エンジニアリング・トンネルは経路識別子に対応する。送信ユニットはルート告知パケットを発行するように構成され、ルート告知パケットは第2のサブネットプレフィックスおよび経路識別子を含み、第2のサブネットプレフィックスの範囲は第1のサブネットプレフィックスの範囲を含む。
可能な実施態様では、第1のトラフィック・エンジニアリング・トンネルはセグメント識別子リストをさらに含み、受信ユニットは第1のパケットを受信するようにさらに構成される。処理ユニットは、第2のパケットを取得するために、第1のパケットの宛先アドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて第1のパケットを更新するようにさらに構成され、第2のパケットはセグメント識別子リストを含む。送信ユニットは、第2のパケットを送信するようにさらに構成される。
可能な実施態様では、第1のパケットの宛先アドレスは第1のセグメント識別子SIDを含む。
可能な実施態様では、ルート告知パケットは、第1のトラフィック・エンジニアリング・トンネルを取得することに応答して、第1のネットワークデバイスによって生成される。
可能な実施態様では、処理ユニットは、対応関係に基づいて、第2のサブネットプレフィックスが経路識別子に対応すると決定するようにさらに構成される。
可能な実施態様では、第1のトラフィック・エンジニアリング・トンネルはセグメント・ルーティング・ポリシーSR Policyを含み、SR Policyは色識別子を含み、対応関係は色識別子と経路識別子との間の対応関係を含む。
可能な実施態様では、対応関係は、第1のサブネットプレフィックスと経路識別子との間の対応関係を含む。
可能な実施態様では、受信ユニットは、第2のトラフィック・エンジニアリング・トンネルを取得するようにさらに構成され、第2のトラフィック・エンジニアリング・トンネルは第3のサブネットプレフィックスを含む。処理ユニットは、第2のトラフィック・エンジニアリング・トンネルが経路識別子に対応すると決定するようにさらに構成される。処理ユニットは、第1のサブネットプレフィックスおよび第3のサブネットプレフィックスに基づいて第2のサブネットプレフィックスを決定するようにさらに構成され、第2のサブネットプレフィックスの範囲は、第1のサブネットプレフィックスの範囲および第3のサブネットプレフィックスの範囲を含む。
可能な実施態様では、経路識別子は、第1のネットワークスライス識別子または第2のSIDを含み、第2のSIDは中間ネットワークデバイスのSIDである。
可能な実施態様では、経路識別子が中間ネットワークデバイスに含まれる第2のSIDである場合、第2のルートは、第2のSIDと第2のネットワークスライス識別子との間のマッピング関係をさらに含む。
可能な実施態様では、受信ユニットは、ネットワークデバイスが位置されるIGPドメインでルート告知パケットを発行する。
本出願の第18の態様はネットワークデバイスを提供し、ネットワークデバイスは、送信ユニット、処理ユニット、および受信ユニットを含む。受信ユニットはサブネットプレフィックスおよびセグメント識別子リストを取得するように構成され、サブネットプレフィックスはトラフィック・エンジニアリング・トンネルの宛先識別子である。受信ユニットは第1のルートを取得するようにさらに構成され、第1のルートはルートプレフィックスおよび第1のアドレスを含み、サブネットプレフィックスの範囲は第1のアドレスを含む。受信ユニットは第1のパケットを受信するようにさらに構成され、第1のパケットの宛先アドレスとルートプレフィックスとの間には最長一致がある。処理ユニットは、第2のパケットを取得するために第1のパケットを更新するようにさらに構成され、第2のパケットはセグメント識別子リストを含む。送信ユニットは、第2のパケットを送信するようにさらに構成される。
可能な実施態様では、第1のアドレスは第2のネットワークデバイスのネクストホップアドレスまたはセグメント識別子SIDを含む。
可能な実施態様では、第1のアドレスがSIDである場合、第2のパケットはSIDをさらに含む。
可能な実施態様では、処理ユニットは、第1のアドレスとサブネットプレフィックスとの間の最長一致に基づいて、ルートプレフィックスおよびセグメント識別子リストを含む対応関係を生成するようにさらに構成される。
可能な実施態様では、処理ユニットは、第2のパケットを取得するために、第1のパケットの宛先アドレスとルートプレフィックスとの間の最長一致および対応関係に基づいて、第1のパケット内のセグメント識別子リストを更新するようにさらに構成される。
可能な実施態様では、トラフィック・エンジニアリング・トンネルはSR Policyを含み、SR Policyは色識別子をさらに含み、第1のルートは経路識別子をさらに含む。処理ユニットは、経路識別子が色識別子に対応することに基づいて、第1のルートがトラフィック・エンジニアリング・トンネルに対応すると決定するようにさらに構成される。
可能な実施態様では、経路識別子は色識別子を含む。
可能な実施態様では、トラフィック・エンジニアリング・トンネルは、セグメント・ルーティング・トラフィック・エンジニアリングSR TEトンネルを含む。
可能な実施態様では、SIDは仮想プライベート・ネットワーク・セグメント識別子VPN SIDを含む。
可能な実施態様では、ネットワークデバイスおよび／または第2のネットワークデバイスはPEデバイスを含む。
第19の態様によれば、ルート告知方法が提供される。本方法は、第1のネットワークデバイスが第1のルートを取得し、第1のルートが第1のルートプレフィックスを含むことを含む。第1のネットワークデバイスは第2のルートを告知し、第2のルートはサブネットプレフィックスおよび経路識別子を含み、サブネットプレフィックスの範囲は第1のルートプレフィックスの範囲を含む。
サブネットプレフィックスおよび経路識別子は、ルート告知方式で告知され、これにより、ネットワークで必要とされる構成を削減することができ、特に、ネットワーク内のトンネル関連構成を削減することができる。
可能な実施態様では、第1のネットワークデバイスは第3のルートをさらに取得し、第3のルートは第2のルートプレフィックスを含む。第1のネットワークデバイスは、第2のルートプレフィックスおよび第1のルートプレフィックスに基づいてサブネットプレフィックスを取得する。ルートは集約方式で告知され、これにより、ネットワーク内のトンネルの数をさらに削減することができる。
可能な実施態様では、経路識別子はネットワークスライス識別子を含む。
可能な実施態様では、ネットワークスライス識別子は柔軟なアルゴリズム識別子を含む。
ネットワークスライス識別子はルート内で搬送され、その結果、ネットワーク内のデバイスが、ネットワークスライス識別子に基づいて対応するパケットをさらに転送することができる。これにより、ネットワーク構成の複雑さをさらに低減する。
可能な実施態様では、第2のルートは、内部ゲートウェイプロトコルIGPパケットを使用して告知される。IGPパケットは告知に使用され、これにより、この解決策を実施する困難性を低減することができる。
可能な実施態様では、第1のルートは、第2のネットワークデバイスによって告知される。
可能な実施態様では、第2のネットワークデバイスと第1のネットワークデバイスとは異なるIGPドメインに属するか、または第2のネットワークデバイスと第1のネットワークデバイスとは異なるBGPドメインに属する。
異なるドメインからのルートが導入され、次いで発行され、これにより、ネットワーク間構成の複雑さを低減することができる。
第20の態様によれば、ルート告知装置が提供される。本装置は、第2のネットワークデバイスによって告知された第1のルートを取得するように構成された受信ユニットであって、第1のルートが第1のルートプレフィックスを含む、受信ユニットと、第2の経路を告知するように構成された送信ユニットであって、第2の経路がサブネットプレフィックスおよび経路識別子を含み、サブネットプレフィックスの範囲が第1のルートプレフィックスの範囲を含む、送信ユニットと、を含む。
可能な実施態様では、装置は処理ユニットをさらに含む。受信ユニットは、第3のルートを取得するようにさらに構成され、第3のルートは第2のルートプレフィックスを含む。処理ユニットは、第2のルートプレフィックスおよび第1のルートプレフィックスに基づいてサブネットプレフィックスを取得するように構成される。
可能な実施態様では、経路識別子はネットワークスライス識別子を含む。
可能な実施態様では、ネットワークスライス識別子は柔軟なアルゴリズム識別子を含む。
可能な実施態様では、第2のルートは、内部ゲートウェイプロトコルIGPパケットを使用して告知される。
第21の態様によれば、プロセッサおよび通信インターフェースを含むネットワークデバイスが提供される。プロセッサは命令を実行するように構成され、その結果、ネットワークデバイスが第1の態様による方法を実行する。
第22の態様によれば、ネットワークシステムが提供される。ネットワークシステムは、第2の態様または第3の態様のネットワークデバイスを含む。
本出願の第23の態様は、コンピュータ記憶媒体を提供する。コンピュータ記憶媒体は不揮発性であってもよい。コンピュータ記憶媒体は、コンピュータ可読命令を記憶する。コンピュータ可読命令がプロセッサによって実行されると、第1の態様、第2の態様、第3の態様、第4の態様、第5の態様、または第19の態様のいずれかの実施態様による方法が実施される。
本出願の第24の態様は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で実行されると、コンピュータは、第1の態様、第2の態様、第3の態様、第4の態様、第5の態様、または第19の態様のいずれかの実施態様による方法を実行することを可能にされる。
本出願の第25の態様はチップシステムを提供する。チップシステムは、前述の態様における機能、例えば、前述の方法におけるデータおよび／または情報を送信または処理する際にネットワークデバイスをサポートするように構成されたプロセッサを含む。可能な設計では、チップシステムはメモリをさらに含む。メモリは、ネットワークデバイスに必要なプログラム命令およびデータを記憶するように構成される。チップシステムは、チップを含んでもよく、またはチップと他の別個のデバイスとを含んでもよい。
本出願の一実施形態によるネットワークアーキテクチャの概略図である。 本出願の一実施形態によるデータ処理方法200の概略フローチャートである。 本出願の一実施形態によるデータ処理方法300の概略フローチャートである。 本出願の一実施形態によるデータ処理方法400の概略フローチャートである。 本出願の一実施形態によるパケット転送の概略図である。 本出願の一実施形態によるパケット転送の概略図である。 本出願の一実施形態によるデータ処理方法600の概略フローチャートである。 本出願の一実施形態によるデータ処理方法700の概略フローチャートである。 本出願の一実施形態による別のパケット転送の概略図である。 本出願の一実施形態によるネットワークデバイス900の構造の概略図である。 本出願の一実施形態によるネットワークデバイス1000の構造の概略図である。 本出願の一実施形態によるネットワークデバイス1100の構造の概略図である。 本出願の一実施形態によるネットワークシステム1200の構造の概略図である。 本出願の一実施形態によるネットワークシステム1300の構造の概略図である。
本出願の明細書、特許請求の範囲、および添付の図面において、「第1」、「第2」、「第3」、および「第4」など（存在する場合）の用語は、同様の対象を区別することを意図されているが、必ずしも特定の順番または順序を示さない。そのように呼ばれるデータは、適切な状況では交換可能であり、その結果、本明細書に記載された本出願の実施形態は、本明細書に図示または記載された順序以外の順序で実施され得ることを理解されたい。さらに、「含む」、「対応する」という用語およびそれらの任意の他の変形は、非排他的包含を網羅することが意図されている。例えば、ステップまたはユニットのリストを含むプロセス、方法、システム、製品、またはデバイスは、必ずしも明示的に列挙されたステップまたはユニットに限定されず、明示的に列挙されていない、またはプロセス、方法、製品、もしくはデバイスに固有の他のステップまたはユニットを含んでもよい。
本出願の実施形態では、「例えば」などの単語は、例、例示、または説明を与えることを表すために使用される。本出願の実施形態において「例」または「例えば」として記載されている任意の実施形態または設計解決策は、別の実施形態または設計解決策よりも好ましいまたはより多くの利点を有するとして説明されるべきではない。正確には、「例」、「例えば」などの単語の使用は、関連する概念を特定の方式で提示することを目的とされている。
理解を容易にするために、以下では、本出願の実施形態における技術用語について最初に説明する。
セグメントルーティング（Segment Routing、SR）は、ネットワーク内でデータパケットを転送するためのソースルーティングの概念に基づいて設計されたプロトコルである。SRは、ネットワーク経路をセグメントに分割し、セグメント識別子（Segment ID、SID）をセグメントおよびネットワークノードに割り当てる。SIDリスト（SID List、SR－MPLSのラベルスタックとも呼ばれる）は、SIDを順番にソートすることによって取得されてもよい。SID Listは、転送経路を示すことができる。SR技術では、トラフィック最適化要件を満たすために、SID Listを搬送するデータパケットが通過するノードおよび経路が指定されてもよい。類推を行うために、データパケットは荷物と比較されてもよく、SRはラベルを荷物に取り付けることと比較されてもよい。荷物を領域Aから領域Bおよび領域Cを通って領域Dに送る必要がある場合には、「最初に領域Bに行き、次に領域Cに行き、最後に領域Dに行く」ことを示すラベルが起点領域Aの荷物に取り付けられ得る。このようにして、荷物上のラベルは各領域で識別されるだけでよく、荷物のラベルに基づいてある領域から別の領域に荷物が転送され得る。SR技術では、ヘッドエンドはデータパケットにラベルを付加し、中間ノードは、データパケットが宛先ノードに到着するまで、ラベルに基づいてデータパケットを次のノードに転送することができる。例えば、＜SID 1、SID 2、SID 3＞は、データパケットのpacketヘッダに挿入され、データパケットは、最初にSID 1に対応するノードに転送され、次いでSID 2に対応するノードに転送され、次いでSID 3に対応するノードに転送される。SR－MPLSは、セグメント・ルーティング・マルチプロトコル・ラベル・スイッチング（Segment Routing Multi－Protocol Label Switching）の略称である。
インターネット・プロトコル・バージョン6（Internet Protocol Version 6、IPv6）ベースのセグメントルーティング（SRv6）は、IPv6ネットワークにSR技術を適用することを示す。SIDの表現には、IPv6アドレス（128 bits）が用いられる。データパケットを転送するとき、SRv6をサポートしているネットワークデバイスは、データパケットの宛先アドレス（Destination Address、DA）に基づいてローカルセグメント識別子テーブル（local SID table）に問い合わせる。データパケットの宛先アドレスとローカルセグメント識別子テーブル内の任意のSIDとの間に最長一致がある場合には、ネットワークデバイスは、ローカルセグメント識別子テーブル内のSIDに関連するポリシーに従って、ポリシーに対応する動作を実行し、例えば、SIDに対応するアウトバウンドインターフェースを介してデータパケットを転送することができる。データパケットの宛先アドレスとローカルセグメント識別子テーブル内の各SIDとの間に最長一致がない場合には、ネットワークデバイスは、IPv6転送テーブルに問い合わせ、IPv6転送テーブルに基づいて最長一致転送を実行する。
セグメントルーティングヘッダ（Segment Routing Header、SRH）：IPv6パケットは、IPv6標準ヘッダ、拡張ヘッダ（0、．．．、n）、およびペイロードPayloadを含む。IPv6転送プレーンに基づいてSRv6を実装するために、SRH拡張ヘッダと呼ばれるIPv6拡張ヘッダが追加される。拡張ヘッダは、IPv6明示的経路を指定し、IPv6 Segment List情報を記憶する。拡張ヘッダの機能は、SR－MPLSにおけるSegment Listと同様である。ヘッドエンドは、SRH拡張ヘッダをIPv6パケットに追加し、その結果、中間ノードは、SRH拡張ヘッダに含まれる経路情報に基づいてパケットを転送することができる。具体的には、SRHは2つの鍵情報を有する。1つは、IPv6アドレス形式のセグメントリスト（Segment List）であり、マルチプロトコル・ラベル・スイッチング（multi－protocol label switching、MPLS）ネットワークにおけるラベルスタック情報と同様である。順番に並べられた複数のセグメント識別子（Segment ID、SID）を含むSegment Listは、SR内の明示的経路を示す。もう1つは、セグメントleft（Segment Left、SL）である。SLは現在のセグメント識別子を示すポインタである。
SRv6ネットワークでは、IPv6パケット内のDAフィールドの値は絶えず変化する。DAフィールドの値は、SLとSegment Listの両方によって決定される。ポインタSLが処理対象のセグメント、例えばSegment List［2］を指し示す場合、Segment List［2］のIPv6アドレスはDAフィールドにコピーされる必要がある。
転送プレーンにおいて、ノードがSRをサポートし、ノードのセグメント識別子がIPv6パケットの宛先アドレス内にある場合には、パケットを受信した後に、ノードはSLを1減少させ、ポインタを新しいセグメントにオフセットし、SLが1減少された後のSLに対応するセグメント識別子（すなわち、IPv6アドレス形式で）をDAフィールドにコピーし、次いでパケットを次のノードに転送することができる。通常、SLフィールドが0に減少すると、ノードはSRHパケットヘッダをポップアップし、次いでパケットに対して次の処理を実行することができる。ノードがSRをサポートしていない場合には、ノードはIPv6パケット内のSRH情報を処理する必要がない。代わりに、ノードは、IPv6宛先アドレスフィールドに基づいてIPv6ルーティングテーブルを検索し、通常、IPv6パケットを転送する。
SRポリシー（SR Policy）は、SRのためのトラフィック・エンジニアリング・メカニズムである。通常、SR Policyは、ヘッドエンド（Headend）、色識別子（Color）、宛先識別子（Endpoint）、および転送経路を示すセグメント識別子リストを含む。Headendは、SR Policyを実行するヘッドエンドを識別する。Colorは、SR Policyのサービス能力を要約するために、SRを低レイテンシおよび高帯域幅などのサービス属性と関連付けるために使用される。Endpointは、SR Policyの宛先アドレスを識別する。通常、（headend、color、endpoint）を用いて1つのSR Policyが決定される。同じheadendについて、（color、endpoint）を使用して1つのPolicyが代わりに決定されてもよい。SR policyは、負荷分散やマルチパスバックアップといった機能を実施するために、1つまたは複数のセグメント識別子リストを含んでもよい。パケットを転送するとき、ヘッドエンドは、SR policyに従って、パケットに対応するセグメント識別子リストを決定して、パケットを転送するための転送経路を決定し、セグメント識別子リストをパケットにカプセル化して、指示経路を表示または分散することができる。
ルートプレフィックスは、IPアドレスおよびサブネットマスクを含む。IPv6ネットワークでは、サブネットマスクの長さは、128ビットまたは128ビット未満であってもよい。一例では、ルートプレフィックスはA1：：1／32またはA1：：1／128と書かれてもよく、A1：：1はIPアドレスであり、32または128はサブネットマスクの長さを表す。
サブネットプレフィックスは、IPアドレスおよびサブネットマスクを含み、サブネットを表す。IPv6ネットワークでは、サブネットマスクの長さは128ビット未満である。一例では、サブネットプレフィックスは、A1：：1／32またはA1：：1／64と書かれてもよく、A1：：1はIPアドレスであり、32または64はサブネットマスクの長さを表す。
ユーザがクラウドサーバにアクセスする方式は、通常、ユーザの端末または企業の支店が位置されるメトロポリタン・エリア・ネットワークと、クラウドサービスが位置されるバックボーンネットワークとの間にエンドツーエンド接続トンネルを確立し、その結果、ユーザがトンネルに基づいてクラウドサーバにアクセスする。しかしながら、このようにしてトンネルを確立するために、大量のトンネルまたはトラフィック・エンジニアリング・トンネルが構成される必要が、通常ある。
例えば、図1は、本出願の一実施形態によるネットワークアーキテクチャの概略図である。図1に示されるように、図1の左側のネットワークはメトロポリタン・エリア・ネットワークであり、図1の右側のネットワークは基幹ネットワークである。企業ユーザのサービスおよびデータは、バックボーンネットワークに接続されたクラウドに配備される。クラウドにアクセスするとき、企業ユーザは、プロバイダエッジ（provider edge、PE）デバイス、すなわち、左側のメトロポリタン・エリア・ネットワークのPE 1またはPE 2から、右側のクラウドPE 1またはクラウドPE 2まで、クラウド上のデータまたはサービスにアクセスする必要がある。クラウドPEは、デバイスがクラウドにアクセスするPEデバイスであることを示す。また、PE 1またはPE 2からクラウドPE 1またはクラウドPE 2への経路は、図1のネットワークデバイスAおよびネットワークデバイスBなどの中間ネットワークデバイスをさらに含む。企業ユーザがクラウドにアクセスするためのネットワーク品質要件を有する場合、例えば、いくつかのサービスの要件が低レイテンシであり、いくつかのサービスの要件が高帯域幅である場合、メトロポリタン・エリア・ネットワーク内のPEとクラウドPEとの間の経路は、ネットワーク品質要件に基づいて計画される必要がある。
現在、これらのサービスはネットワーク上の伝送品質要件を有するため、PEとクラウドPEとの間の経路は、サービス要件およびPEとクラウドPEとの間のネットワークトポロジに基づいて、通常、計画され、エンドツーエンドのトラフィックエンジニアリングが構成されている。ネットワークの規模が大きい場合、またはネットワークが複数の異なるサービス要件を有する場合、大量のエンドツーエンド接続が生成され、トラフィックエンジニアリング構成の数が多い。
これを考慮して、本出願の一実施形態はデータ処理方法を提供する。ネットワークデバイスは、宛先識別子がサブネットプレフィックスであるトラフィック・エンジニアリング・トンネルを受信し、その結果、パケットを取得した後に、ネットワークデバイスが、パケットに関連するアドレスとサブネットプレフィックスとの間の最長一致に基づいて、パケットと一致するトラフィック・エンジニアリング・トンネルを決定することができる。トラフィック・エンジニアリング・トンネルの宛先識別子はサブネットプレフィックスを含むので、トラフィック・エンジニアリング・トンネルは、異なるアドレスを有する複数のパケットを照合することができ、その結果、ネットワーク内のトラフィック・エンジニアリング・トンネルの数が低減され得、構成または管理の複雑さが回避され得る。
図2は、本出願の一実施形態によるデータ処理方法200の概略フローチャートである。図2に示されるように、データ処理方法200は以下のステップを含む。
ステップ201：第1のネットワークデバイスがサブネットプレフィックスを取得し、サブネットプレフィックスはトラフィック・エンジニアリング・トンネルの宛先識別子である。
第1のネットワークデバイスは、トラフィック・エンジニアリング・トンネルの関連する構成を受信することによってサブネットプレフィックスを取得してもよく、別の方式でサブネットプレフィックスを取得してもよい。
第1のネットワークデバイスは、例えば、ルータ、スイッチ、またはゲートウェイなどの物理デバイスであってもよく、またはルート発行およびパケット転送をサポートする仮想デバイスであってもよい。この実施形態では、第1のネットワークデバイスおよび第2のネットワークデバイスの具体的な種類は限定されない。例えば、データ処理方法200が図1に示すシナリオに適用される場合、第1のネットワークデバイスは、例えば、図1に示すメトロポリタン・エリア・ネットワークに位置されるPEデバイス、または図1に示すバックボーンネットワークに位置されるネットワークデバイスAであってもよい。
可能な例では、第1のネットワークデバイスによって取得されたトラフィック・エンジニアリング・トンネルの構成は、第2のネットワークデバイスによって第1のネットワークデバイスへ配信されてもよい。第2のネットワークデバイスは、例えば、コントローラまたは別の経路計算デバイスであってもよく、または第1のネットワークデバイス内に事前構成されてもよい。トラフィック・エンジニアリング・トンネルは、SR PolicyまたはSR TEトンネルを含んでもよい。トラフィック・エンジニアリング・トンネルの宛先識別子は、サブネットプレフィックスを含み、サブネットプレフィックスは、IPアドレスおよびサブネットマスクの2つのフィールドを含んでもよい。例えば、サブネットプレフィックスはA1：：1／64であってもよい。トラフィック・エンジニアリング・トンネルの宛先識別子は、特定のネットワークデバイスに対応してもよい。例えば、宛先識別子はネットワークデバイスのアドレスであり、アドレスはサブネットに対応し、サブネットはネットワークセグメントとも呼ばれてもよい。あるいは、トラフィック・エンジニアリング・トンネルの宛先識別子は、ネットワークドメインに対応してもよく、具体的には、ネットワークドメイン内の複数のネットワークデバイスに対応してもよい。例えば、宛先識別子はアグリゲーション・ネットワーク・セグメントであり、アグリゲーション・ネットワーク・セグメントはネットワークドメイン内の複数のネットワークデバイスのアドレスの範囲を含む。
ステップ202：第1のネットワークデバイスが第1のサブネットプレフィックスに基づいてデータ処理を実行する。
サブネットプレフィックスおよびトラフィック・エンジニアリング・トンネルの構成を取得した後に、第1のネットワークデバイスは、第1のサブネットプレフィックスに基づいてデータ処理を実行してもよい。
第1のネットワークデバイスが第1のサブネットプレフィックスに基づいてデータ処理を実行することは、以下の2つのケースを含むが、これらに限定されない。
ケースA：第1のネットワークデバイスは、第1のサブネットプレフィックスに基づいてパケットを送信する。この場合、以下のステップを含む。
1．第1のネットワークデバイスが第1のパケットを取得する。
第1のネットワークデバイスは、メトロポリタン・エリア・ネットワーク内のPEデバイスまたはSRネットワーク内の任意のデバイスであってもよく、ネットワークデバイスは、SRネットワーク内の第1のパケットを転送するヘッドエンドであってもよい。第1のネットワークデバイスは、第1のネットワークデバイスに接続されたホストデバイスまたはクラウドデバイスによって送信された第1のパケットを受信するか、または第1のネットワークデバイスの隣接デバイスから第1のパケットを受信することができる。第1のパケットは、別のネットワークデバイスを宛先とするサービストラフィックであってもよい。
2．第1のネットワークデバイスは、第1のパケットに関連する第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、トラフィック・エンジニアリング・トンネルを介して第1のパケットを送信する。
第1のアドレスは、第1のパケットの宛先アドレスに基づいて取得され、以下のケースが存在する。
1．第1のアドレスは第1のパケットの宛先アドレスである。
2．第1のアドレスは、第1のパケットの宛先アドレスに基づいて第1のネットワークデバイスによって決定されたネクストホップ転送アドレスである。ネクストホップ転送アドレスは、第1のパケットに対応するルート内のネクストホップアドレスであってもよく、またはネクストホップ転送アドレスは、第1のパケットに対応するルート内のセグメント識別子であってもよい。
以下の2つのケースを参照して、以下では、説明が提供される。
ケース1：第1のパケットの宛先アドレスがパブリック・ネットワーク・アドレスである場合には、第1のパケットを取得した後で、第1のネットワークデバイスは、第1のパケットの宛先アドレスとサブネットプレフィックスとの間の最長一致に基づいて、第1のパケットがトラフィック・エンジニアリング・トンネルと一致すると決定することができ、その結果、第1のネットワークデバイスが、トラフィック・エンジニアリング・トンネルによって指示されるトンネルに基づいて第1のパケットを送信することができる。
ケース2：第1のパケットの宛先アドレスがプライベート・ネットワーク・アドレスである場合には、第1のパケットを取得した後で、第1のネットワークデバイスは、第1のパケットに関連し、かつ第1のネットワークデバイスによって取得された経路指定情報に基づいて、第1のパケットを転送するための対応するネクストホップ転送アドレスはネクストホップアドレスまたはセグメント識別子であるとまず決定することができ、セグメント識別子はVPN SIDであってもよい。この場合、第1のネットワークデバイスは、ネクストホップ転送アドレスとサブネットプレフィックスとの間の最長一致に基づいて、トラフィック・エンジニアリング・トンネルを介して第1のパケットを送信することを決定することができる。
ケースB：第1のネットワークデバイスは第1のサブネットプレフィックスに基づいて第1のルーティングパケットを発行し、第1のルーティングパケットは第2のサブネットプレフィックスを含み、第2のサブネットプレフィックスの範囲は第1のサブネットプレフィックスの範囲を含む。
一例では、トラフィック・エンジニアリング・トンネルを受信した後で、第1のネットワークデバイスは、第1のルーティングパケットを外部に発行することができる。言い換えれば、第1のネットワークデバイスは、トラフィック・エンジニアリング・トンネルを取得することに応答して、第1のルーティングパケットを発行する。
別の例では、トラフィック・エンジニアリング・トンネルおよび別のトラフィック・エンジニアリング・トンネルを受信した後で、第1のネットワークデバイスは、第1のルーティングパケットを外部に発行することができる。
第2のサブネットプレフィックスの範囲が第1のサブネットプレフィックスの範囲を含むという説明は、以下の2つの可能な場合を含むが、これらに限定されない。
1．第2のサブネットプレフィックスは、第1のサブネットプレフィックスと同じである。具体的には、トラフィック・エンジニアリング・トンネルを取得した後で、第1のネットワークデバイスは、第1のサブネットプレフィックスをルートプレフィックスとして発行することができる。
2．第2のサブネットプレフィックスの範囲は、第1のサブネットプレフィックスの範囲よりも大きい。通常、第2のサブネットプレフィックスのサブネットマスク長が第1のサブネットプレフィックスのサブネットマスク長よりも短く、第2のサブネットプレフィックスおよび第1のサブネットプレフィックスのIPアドレス部分の上位部分が同じである場合、第2のサブネットプレフィックスの範囲は第1のサブネットプレフィックスの範囲よりも大きいと考えられる。一例では、第2のサブネットプレフィックスが例えばA1：1：：／32であり、第1のサブネットプレフィックスが例えばA1：1：1：：1／64であり、サブネットマスクの長さ：32が64未満であり、第2のサブネットプレフィックスおよび第1のサブネットプレフィックスのIPアドレスの上位部分、例えばA1：1部分が同じである場合には、第2のサブネットプレフィックスの範囲は第1のサブネットプレフィックスの範囲よりも大きいと考えられる。同様に、特定のIPアドレスの上位部分とサブネットプレフィックスのIPアドレスとの間に同じ部分がある場合、サブネットプレフィックスの範囲はIPアドレスを含むとみなされてもよい。例えば、IPアドレスがA1：1：1：1：：1であり、サブネットプレフィックスがA1：1：：1／32またはA1：1：1：1：：2／64である場合、2つのサブネットプレフィックスの範囲は、IPアドレスA1：1：1：：1を含むとみなされてもよい。
複数のトラフィック・エンジニアリング・トンネルを取得した後で、第1のネットワークデバイスは、第2のサブネットプレフィックスを取得するために、複数のトラフィック・エンジニアリング・トンネルのターゲット識別子にサブネットプレフィックスを集約し、第1のネットワークデバイスが位置されるIGPドメインで第2のサブネットプレフィックスをルーティング形式で発行することができる。
あるいは、1つのトラフィック・エンジニアリング・トンネルを取得した後で、第1のネットワークデバイスは、第1のネットワークデバイスによって取得されたいくつかの構成を参照して第2のサブネットプレフィックスを取得し、次いで、第1のネットワークデバイスが位置されるIGPドメインで第2のサブネットプレフィックスを発行してもよい。
任意選択で、第1のネットワークデバイスによって発行されたルートは、経路識別子をさらに含み、経路識別子は、第1のネットワークデバイスへの転送経路を決定するための別のネットワークデバイスを示すことができる。経路識別子は、第1のネットワークデバイスのセグメント識別子またはネットワークスライス識別子を含む。第1のネットワークデバイスは、セグメント識別子またはネットワークスライス識別子を事前に取得することができる。第1のネットワークデバイスは、トラフィック・エンジニアリング・トンネルまたは第2のサブネットプレフィックスに基づいてセグメント識別子を代わりに取得し、第1のルーティングパケットを使用してセグメント識別子を発行することができる。ネットワークスライス識別子は、例えば、フレキシブルアルゴリズム識別子（FlexAlgo ID）またはネットワークスライスを識別することができる別の識別子であってもよい。
第1のルートは、SIDとネットワークスライス識別子との間のマッピング関係をさらに含むことができ、その結果、経路識別子を受信するネットワークデバイスは、マッピング関係に基づいて対応するネットワークスライス識別子またはSIDを決定することができる。
経路識別子は、別のネットワークデバイスに、第1のネットワークデバイスへの転送経路を決定するように指示することができる。また、経路識別子は、トラフィック・エンジニアリング・トンネルに対応する。具体的には、経路識別子とトラフィック・エンジニアリング・トンネルによって指示される経路とに基づいて決定される転送経路は、同じサービス要件を満たし、例えば、両方とも低レイテンシサービス要件を満たし、または両方とも高帯域幅サービス要件を満たす。
前述の説明では、第1のネットワークデバイスが第1のサブネットプレフィックスに基づいてデータ処理を実行することは、ケースAもしくはケースBを含んでもよく、またはケースAとケースBの両方を含んでもよい。ケースAおよびケースBの実行順序は、本出願では特に限定されない。
これに対応して、第2のネットワークデバイスは第1のネットワークデバイスにトラフィック・エンジニアリング・トンネルを送信し、トラフィック・エンジニアリング・トンネルの宛先識別子はサブネットプレフィックスを含み、トラフィック・エンジニアリング・トンネルは、第1のネットワークデバイスがサブネットプレフィックスに基づいてデータ処理を行うことを可能にするために使用される。第2のネットワークデバイスは、例えば、コントローラまたは別の経路計算デバイスであってもよい。
理解を容易にするために、以下では、例を使用して特定のシナリオを参照して、この実施形態で提供されるデータ処理方法200を説明する。
図1に示されるシナリオが一例として使用される。方法200の第1のネットワークデバイスは図1のPE 1であってもよく、方法200の第3のネットワークデバイスは図1のクラウドPE 1であってもよい。第1のネットワークデバイスは、コントローラによって配信されたトラフィック・エンジニアリング・トンネルを受信することができ、トラフィック・エンジニアリング・トンネルの宛先識別子はサブネットプレフィックスであり、トラフィック・エンジニアリング・トンネルによって示される経路はネットワークデバイスAへの経路を含む。サブネットプレフィックスは、アグリゲーション・ネットワーク・セグメントであってもよく、アグリゲーション・ネットワーク・セグメントの範囲は、バックボーンネットワーク内のクラウドPEのアドレスの範囲を含む。言い換えれば、バックボーンネットワーク内のクラウドPEの一部または全部のアドレスは、アグリゲーション・ネットワーク・セグメントの範囲内にある。例えば、サブネットプレフィックスはA1：：0／64であってもよい。PE 1がクラウドPE 1を宛先とするパケットを受信したとき、言い換えれば、パケットの宛先アドレスがクラウドPE 1のアドレスであるとき、PE 1は、パケットの宛先アドレスとサブネットプレフィックスとの間の最長一致に基づいて、パケットがトラフィック・エンジニアリング・トンネルと一致すると決定し、トラフィック・エンジニアリング・トンネルによって示される経路に基づいてパケットをネットワークデバイスAに転送する。最後に、ネットワークデバイスAは、パケットをクラウドPE 1に転送するように構成される。トラフィック・エンジニアリング・トンネルの宛先識別子はサブネットプレフィックスであるため、バックボーンネットワーク内の複数またはすべてのクラウドPEを宛先とするパケットの宛先アドレスのそれぞれとサブネットプレフィックスとの間には最長一致があり得る。言い換えれば、PE 1は、トラフィック・エンジニアリング・トンネルによって示された経路に基づいて、バックボーンネットワーク内の任意のクラウドPEを宛先とするパケットをネットワークデバイスAに転送することができ、最終的に、ネットワークデバイスAは、対応するクラウドPEにパケットを転送するように構成される。このようにして、ネットワーク内のトラフィック・エンジニアリング・トンネルの数が効果的に低減され得、構成または管理の複雑さが回避され得る。
第1のアドレスがパケットの宛先アドレスである例は、上記の説明に使用されている。実際の適用時には、第1のアドレスは、代替として、セグメント識別子またはネクストホップアドレスなどの、パケットに基づいてPE 1によって決定されたネクストホップ転送アドレスであってもよい。例えば、クラウドPE 1がPEへのルートを発行してもよい。ルートは、ルートプレフィックスおよびセグメント識別子（Segment Identifier、SID）を含む。このようにして、クラウドPE 1を宛先とする第1のパケットを受信した後に、PE 1は、第1のパケットの宛先アドレスとルートのルートプレフィックスとの間の最長一致に基づいて、セグメント識別子に基づいてパケットが転送される必要があると決定することができ、セグメント識別子は決定されたネクストホップ転送アドレスであり、次いで、セグメント識別子とトラフィック・エンジニアリング・トンネルのサブネットプレフィックスとの間の最長一致に基づいて、パケットがトラフィック・エンジニアリング・トンネルと一致すると決定し、その結果、PE 1がトラフィック・エンジニアリング・トンネルに基づいてパケットを転送することができる。一例では、PE 1が第1のパケットを更新することができる。第1のパケットはSRHを含み、SRHは、トラフィック・エンジニアリング・トンネルのセグメント識別子リストおよびクラウドPE 1によって発行されたセグメント識別子を含む。
方法200は、第1のネットワークデバイスが第2のルートをさらに取得し、第2のルートがルートプレフィックスおよび第1のアドレスを含み、第1のアドレスがネクストホップアドレスまたはセグメント識別子SIDを含むことをさらに含んでもよい。第1のネットワークデバイスは、第2のルートで搬送される第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、ルートプレフィックスとトラフィック・エンジニアリング・トンネルとの間の対応関係を取得し、例えば、ルートプレフィックスとトラフィック・エンジニアリング・トンネルの識別子との間の対応関係を取得する。このようにして、第1のパケットの宛先アドレスとサブネットプレフィックスとの間に最長一致があると決定した場合、第1のネットワークデバイスは、第1のパケットを転送するために使用されるトラフィック・エンジニアリング・トンネルを取得するために、テーブル検索を介して、ルーティングテーブル内のサブネットプレフィックスに対応するルートプレフィックスを決定し、トラフィック・エンジニアリング・トンネルによって示されるトンネルに基づいて第1のパケットを最終的に転送することができる。
以下では、例示的な適用シナリオを参照して、本出願で提供されるシナリオベースの方法の実施形態を説明する。図3は、本出願の一実施形態によるデータ処理方法300の概略フローチャートである。図3に示されるように、データ処理方法300は以下のステップを含む。
ステップ301：第1のネットワークデバイスが、第2のネットワークデバイスによって発行された第1のルートを取得し、第1のルートは第1のルートプレフィックスを含む。
第1のネットワークデバイスおよび第2のネットワークデバイスはそれぞれ、例えば、ルータ、スイッチ、またはゲートウェイなどの物理デバイスであってもよく、またはルート発行およびパケット転送をサポートする仮想デバイスであってもよい。この実施形態では、第1のネットワークデバイスおよび第2のネットワークデバイスの具体的な種類は限定されない。例えば、データ処理方法300が図1に示すシナリオに適用される場合、第1のネットワークデバイスは、例えば、図1に示されるバックボーンネットワーク内に位置されるクラウドPEデバイスであってもよく、第2のネットワークデバイスは、例えば、図1に示されるメトロポリタン・エリア・ネットワーク内に位置されるPEデバイスであってもよい。
第1のネットワークデバイスと第2のネットワークデバイスとの間にネットワーク接続が確立され、第1のネットワークデバイスと第2のネットワークデバイスとの間に1つまたは複数のネットワークデバイスが含まれる。第1のネットワークデバイスと第2のネットワークデバイスとの間で伝送されるパケットは、第1のネットワークデバイスと第2のネットワークデバイスとの間の1つまたは複数のネットワークデバイスを通過する必要がある。
一例では、第1のネットワークデバイスおよび第2のネットワークデバイスは、異なるネットワークドメイン、例えば、異なるIGPドメインに位置されてもよい。パケットは、第1のネットワークデバイスが位置されるネットワークドメインと第2のネットワークデバイスが位置されるネットワークドメインとで異なる方式で送信されてもよい。例えば、第1のネットワークデバイスは、フレキシブルアルゴリズムベースのIGP（FlexAlgo）ネットワークまたはSRネットワークに位置されてもよく、第1のネットワークデバイスは、ネットワークスライス識別子に基づいて経路計算を実行し、パケットに対応する出口を決定して、パケットを送信してもよい。第2のネットワークデバイスはSRネットワーク内に位置されてもよい。ネットワークにおいて、転送トンネルは、SR Policyまたはセグメント・ルーティング・トラフィック・エンジニアリング（segment routing traffic engineering、SR TEトンネル）を設定することによって指示されてもよい。第2のネットワークデバイスは、セグメント識別子リストの指示に基づいてパケットを送信することができる。
例示的なシナリオでは、第1のネットワークデバイスは、例えば、バックボーンネットワーク内のアクセスクラウドのプロバイダエッジPEデバイスであってもよく、バックボーンネットワークは、FlexAlgoネットワークまたはSRネットワークであってもよい。第2のネットワークデバイスは、例えば、メトロポリタン・エリア・ネットワークにおけるセグメントルーティングに基づくPEデバイスであってもよい。メトロポリタン・エリア・ネットワークは、トラフィックエンジニアリングで構成されたSRネットワークであってもよく、トラフィックエンジニアリングは、SR PolicyまたはSR TEトンネルを含む。
第1のネットワークデバイスは、複数の方式で第1のルートを取得することができる。
可能な実施態様では、第2のネットワークデバイスは、ルートリフレクタを使用して第1のネットワークデバイスに第1のルートを発行することができる。具体的には、第1のネットワークデバイスは、ルートリフレクタによって送信されたルーティング情報を受信することによって第1のルートを取得する。
別の可能な実施態様では、第2のネットワークデバイスは、第1のネットワークデバイスと第2のネットワークデバイスとの間のデバイスを使用して、第1のネットワークデバイスへの第1のルートを、代替として発行してもよい。具体的には、第1のネットワークデバイスは、第1のネットワークデバイスと第2のネットワークデバイスとの間でデバイスによって送信されたルーティング情報を受信することによって第1のルートを取得する。第1のネットワークデバイスが第1のルートを取得する方式は、本明細書では特に限定されない。
第1のルートは、第1のルートプレフィックスを含む。第1のルートプレフィックスは、第2のネットワークデバイスのプライベート・ネットワーク・アドレスであってもよい。例えば、第1のルートプレフィックスは2．2．2．2／24であってもよい。
ステップ302：中間ネットワークデバイスが、第2のサブネットプレフィックスおよび経路識別子を取得し、第2のサブネットプレフィックスは第1のトラフィック・エンジニアリング・トンネルの宛先識別子であり、第1のトラフィック・エンジニアリング・トンネルは経路識別子に対応する。
中間ネットワークデバイスは、第1のネットワークデバイスと第2のネットワークデバイスとの間に位置される。中間ネットワークデバイスおよび第1のネットワークデバイスは同じIGPドメインに属してもよく、中間ネットワークデバイスはIGPドメインの境界ネットワークデバイスであってもよい。中間ネットワークデバイスは、例えば、ルータ、スイッチ、またはゲートウェイなどの物理デバイスであってもよく、またはルート発行およびパケット転送をサポートする仮想デバイスであってもよい。中間ネットワークデバイスの特定のタイプは、この実施形態では限定されない。例えば、データ処理方法300が図1に示されシナリオに適用される場合、中間ネットワークデバイスは、例えば、図1に示されバックボーンネットワーク内に位置され、メトロポリタン・エリア・ネットワークに接続されたデバイスであってもよく、中間ネットワークデバイスは、例えば、図1に示されバックボーンネットワーク内に位置されるネットワークデバイスAであってもよい。
中間ネットワークデバイスは、トラフィック・エンジニアリング・トンネルの構成を取得することによって、または別の方式で、第2のサブネットプレフィックスを取得してもよい。これは本出願では特に限定されない。
中間ネットワークデバイスによって取得された第1のトラフィック・エンジニアリング・トンネルは、コントローラまたは別のデバイスによって中間ネットワークデバイスに送信されてもよいし、中間ネットワークデバイス内で事前構成されてもよい。第1のトラフィック・エンジニアリング・トンネルは、第2のサブネットプレフィックスと、第2のサブネットプレフィックスに対応する転送経路と、を含む。第2のサブネットプレフィックスは、第2のネットワークデバイスのサブネットプレフィックスであってもよく、例えば、第2のネットワークデバイスのlocatorアドレスであってもよい。この場合、第2のサブネットプレフィックスに対応する転送経路は、中間ネットワークデバイスから第2のネットワークデバイスへの転送経路である。
例えば、コントローラは、中間ネットワークデバイスにSR Policyを送信することができ、SR PolicyのEndpointは、第2のネットワークデバイスのlocatorアドレスまたはloopbackアドレスを集約することによって取得されたアドレスである。SR PolicyのHeadendは中間ネットワークデバイスのアドレスであり、Endpoitは第2のネットワークデバイス（すなわち、第2のサブネットプレフィックス）のlocatorアドレスであり、SR Policyに含まれるセグメント識別子リストは中間ネットワークデバイスから第2のネットワークデバイスへの転送経路を示す。
SR TEトンネル内の中間ネットワークデバイスによって取得された経路識別子は、中間ネットワークデバイスへの転送経路を決定するために、転送経路が通過するネットワーク内のネットワークデバイスによって使用され得る。さらに、経路識別子は、第1のトラフィック・エンジニアリング・トンネルに対応する。第1のトラフィック・エンジニアリング・トンネルに含まれる経路識別子および転送経路に基づいて決定される転送経路は、同じサービス要件を満たし、例えば、両方とも低レイテンシサービス要件を満たし、または両方とも高帯域幅サービス要件を満たす。
可能な例では、経路識別子は、中間ネットワークデバイスに含まれるネットワークスライス識別子または第2のSIDを含む。
経路識別子がネットワークスライス識別子である場合、中間ネットワークデバイスは、複数の方式で経路識別子を決定することができる。
方式1：第1のトラフィック・エンジニアリング・トンネルがSR Policyである場合、中間ネットワークデバイスは、色識別子（color）と経路識別子との間の対応関係に基づいて、対応する経路識別子を決定することができる。
例えば、colorとトラフィック・エンジニアリング・トンネルの中間ネットワークデバイス内のネットワークスライス識別子（例えば、FlexAlgo ID）との間に対応関係があってもよい。中間ネットワークデバイスは、colorとネットワークスライス識別子との間の対応関係に基づいて、SR Policyが経路識別子に対応すると決定することができる。経路識別子は、例えば、ネットワークスライス識別子であってもよい。例えば、SR Policyのcolorが123である場合、中間ネットワークデバイスは、colorとFlexAlgo IDとの間の対応関係に基づいて、SR PolicyがFlexAlgo 128に対応すると決定することができる。
方式2：第1のトラフィック・エンジニアリング・トンネルがSR Policyである場合、中間ネットワークデバイスは、サブネットプレフィックスと経路識別子との間の対応関係に基づいて、対応する経路識別子を決定することができる。
例えば、第2のネットワークデバイスがSR Policyネットワーク内に位置される場合、第1のトラフィック・エンジニアリング・トンネルはSR Policyであってもよい。SR Policyネットワークの計画プロセスでは、ネットワークデバイスに対応するサブネットプレフィックスが、ネットワークデバイスに対応するネットワークスライス識別子に基づいて割り当てられる。例えば、サブネットプレフィックスは、低レイテンシのサービス要件に対応するネットワークスライス識別子に基づいて割り当てられる。したがって、サブネットプレフィックスとネットワークスライス識別子との間の対応関係は、中間ネットワークデバイスにおいて事前構成されてもよい。このようにして、第2のサブネットプレフィックスおよび対応関係に基づいて、中間ネットワークデバイスは、SR Policyが経路識別子に対応すると決定することができる。例えば、SR PolicyのサブネットプレフィックスがA2：：0／64である場合、中間ネットワークデバイスは、サブネットプレフィックスとFlexAlgo IDとの間の対応関係に基づいて、SR PolicyがFlexAlgo 128に対応すると決定することができる。
方式3：第1のトラフィック・エンジニアリング・トンネルがSR TEトンネルである場合、中間ネットワークデバイスは、SR TEトンネルと経路識別子との間の対応関係に基づいて、対応する経路識別子を決定することができる。
例えば、第2のネットワークデバイスがSR TEトンネルネットワーク内に位置されるとき、第1のトラフィック・エンジニアリング・トンネルはSR TEトンネルであってもよい。SR TEトンネルとネットワークスライス識別子との間の対応関係は、中間ネットワークデバイスにおいて事前構成されてもよい。このようにして、中間ネットワークデバイスは、対応関係に基づいて、SR TEトンネルが経路識別子に対応すると決定することができる。
加えて、経路識別子が中間ネットワークデバイスに含まれる第2のSIDである場合、上記の3つの方式のいずれか1つで、第1のトラフィック・エンジニアリング・トンネルに対応するネットワークスライス識別子を決定した後に、中間ネットワークデバイスは、ネットワークスライス識別子に対応する第2のSIDを生成することができる。第2のSIDは、例えば、中間ネットワークデバイスのEND SIDであってもよい。すなわち、END SIDおよびネットワークスライス識別子は、ネットワーク品質を表すことができる。宛先識別子および中間ネットワークデバイスが同じIGPドメインにあるネットワークデバイスは、END SIDに基づいてパケットを中間ネットワークデバイスに転送することができる。
ステップ303：第1のトラフィック・エンジニアリング・トンネルおよび経路識別子を取得したことに応答して、中間ネットワークデバイスが、中間ネットワークデバイスが位置されるIGPドメインでルート告知パケットを発行することができ、ルート告知パケットは第1のサブネットプレフィックスおよび経路識別子を含み、第1のサブネットプレフィックスの範囲は第2のサブネットプレフィックスの範囲を含む。
一例では、中間ネットワークデバイスによって発行されたルート告知パケット内の第1のサブネットプレフィックスは、第1のトラフィック・エンジニアリング・トンネル内にあって、かつ中間ネットワークデバイスによって受信される、第2のサブネットプレフィックスと同じであってもよい。具体的には、中間ネットワークデバイスは、取得されたトラフィック・エンジニアリング・トンネルに基づいて、対応するルート告知パケットを発行する。別の例では、第1のサブネットプレフィックスは、代替的に、第2のサブネットプレフィックスと異なっていてもよい。この場合、第1のサブネットプレフィックスの範囲は、第2のサブネットプレフィックスの範囲を含む。具体的には、中間ネットワークデバイスは、取得された複数のトラフィック・エンジニアリング・トンネルに含まれる複数のサブネットプレフィックスに基づいて、新しいサブネットプレフィックス（すなわち、第2のサブネットプレフィックス）を生成し、対応するルート告知パケットを発行する。
中間ネットワークデバイスは、対応関係に基づいて、第1のサブネットプレフィックスが経路識別子に対応すると決定することができる。
一例では、対応関係は、第2のサブネットプレフィックスと経路識別子との間の対応関係を含む。中間ネットワークデバイスは、サブネットプレフィックスと経路識別子との間の対応関係を用いて静的に構成されてもよく、またはコントローラは、サブネットプレフィックスと経路識別子との間の対応関係を中間ネットワークデバイスに配信し、中間ネットワークデバイスは、対応関係に基づいて、第2のサブネットプレフィックスと経路識別子との間の対応関係を取得することを決定してもよい。
別の例では、第1のトラフィック・エンジニアリング・トンネルはセグメント・ルーティング・ポリシーSR Policyであってもよく、SR Policyは色識別子を含む。中間ネットワークデバイスは、色識別子と経路識別子とを含む対応関係に基づいて、第1のサブネットプレフィックスが経路識別子に対応すると決定することができる。中間ネットワークデバイスは、色識別子と経路識別子との間の対応関係で静的に構成されてもよく、またはコントローラは、色識別子と経路識別子との間の対応関係を中間ネットワークデバイスに配信する。したがって、中間ネットワークデバイスは、SR Policyに含まれる色識別子および対応関係に基づいて、第1のサブネットプレフィックスが経路識別子に対応すると決定することができる。
例えば、ルート告知パケットを発行する前に、中間ネットワークデバイスは、第2のトラフィック・エンジニアリング・トンネルを取得し、第2のトラフィック・エンジニアリング・トンネルは第3のサブネットプレフィックスを含む。中間ネットワークデバイスは、第2のトラフィック・エンジニアリング・トンネルが経路識別子に対応すると決定する。中間ネットワークデバイスは、第2のサブネットプレフィックスおよび第3のサブネットプレフィックスに基づいて第1のサブネットプレフィックスを決定し、第1のサブネットプレフィックスの範囲は、第2のサブネットプレフィックスの範囲および第3のサブネットプレフィックスの範囲を含む。
言い換えれば、中間ネットワークデバイスが複数のトラフィック・エンジニアリング・トンネルを取得するときに、複数のトラフィック・エンジニアリング・トンネルが同じ経路識別子に対応する場合には、中間ネットワークデバイスは、複数のトラフィック・エンジニアリング・トンネル内のサブネットプレフィックスを1つのサブネットプレフィックスに集約し、集約されたサブネットプレフィックスを発行されたルート告知パケットに含めることができる。このようにして、同じ経路識別子を有する複数のトラフィック・エンジニアリング・トンネルについて、中間ネットワークデバイスは、告知パケットのオーバーヘッドを低減するために、IGPドメインでのみ1つのルート告知パケットを発行することができる。加えて、複数のサブネットプレフィックスは、より広い範囲のサブネットプレフィックスに集約され、その結果、第1のネットワークデバイスのルート管理がさらに削減され得、トンネルの数がそれに応じて低減され得る。
別の例では、第1のトラフィック・エンジニアリング・トンネルが、第1のネットワークデバイスが位置されるネットワークドメイン内の境界デバイスによって中間ネットワークデバイスへ送信される場合、境界デバイスは、同じ経路識別子を有する複数のトラフィック・エンジニアリング・トンネルを代替として受信し、複数のトラフィック・エンジニアリング・トンネルに基づいて第1のトラフィック・エンジニアリング・トンネルを生成してもよい。言い換えれば、境界デバイスは、境界デバイスによって受信された複数のトラフィック・エンジニアリング・トンネル内のサブネットプレフィックスを1つのサブネットプレフィックスに集約し、第1のトラフィック・エンジニアリング・トンネル内で搬送された集約サブネットプレフィックスを中間ネットワークデバイスに送信することができる。
一例では、経路識別子が中間ネットワークデバイスに含まれる第2のSIDである場合、第2のルートは、SIDとネットワークスライス識別子との間のマッピング関係をさらに含む。このようにして、ルート告知パケットを受信したネットワークデバイスは、マッピング関係に基づいて対応するマッピング関係表を生成することができ、その結果、SIDを含むパケットを受信した場合、ネットワークデバイスは、SIDおよびマッピング関係表に基づいて対応するネットワークスライス識別子を決定することができる。
ステップ304：第1のネットワークデバイスが中間ネットワークデバイスによって発行された第2のルートを取得し、第2のルートは第1のサブネットプレフィックスおよび経路識別子を含む。
中間ネットワークデバイスがIGPドメインでルート告知パケットを発行した後に、第1のネットワークデバイスは、第1のサブネットプレフィックスおよび経路識別子を含む第2のルートを受信することができ、第2のルートは、例えば、IGPルートである。例えば、第1のネットワークデバイスと中間ネットワークデバイスとの間に別のネットワークデバイスがある場合、第2の経路は、ルート告知パケットに基づいて第1のネットワークデバイスの隣接デバイスによって第1のネットワークデバイスに送信されてもよい。
一例では、第1のサブネットプレフィックスの範囲は、第1のルートプレフィックスの範囲を含む。具体的には、第1のネットワークデバイスは、第1のサブネットプレフィックスに一致するために、第1のルート内の第1のルートプレフィックスに基づいて最長一致演算を実行する。このようにして、第1のネットワークデバイスは、第1のルートプレフィックスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のルートと第2のルートとの間の関連付け関係を確立することができる。
別の例では、第1のネットワークデバイスによって受信された第1のルートは第1のアドレスをさらに含み、第1のアドレスと第1のサブネットプレフィックスとの間には最長一致がある。言い換えれば、第1のネットワークデバイスは、第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のルートと第2のルートとの間の関連付け関係を確立することができる。
任意選択で、第1のアドレスは、第2のネットワークデバイスのネクストホップアドレスまたは第1のSIDを含んでもよい。第1のSIDは、ネットワーク内の第2のネットワークデバイスの位置または第2のネットワークデバイスによって提供されるネットワークサービスを示すことができる。例えば、第1のSIDは、仮想プライベート・ネットワーク・セグメント識別子VPN SIDまたは第2のネットワークデバイスの位置を示すことができる別のSIDであってもよい。例えば、第1のSIDは、第2のネットワークデバイスのlocatorネットワーク・セグメントに割り当てられたVPN SIDであってもよい。
この実施形態では、ステップ301とステップ304との間に順序はないことに留意されたい。ステップ301がステップ304の前に実行されてもよく、またはステップ304がステップ301の前に実行されてもよく、またはステップ301とステップ304とが同時に実行されてもよい。これは、この実施形態では特に限定されない。
ステップ305：第1のネットワークデバイスが第1のパケットを受信する。
この実施形態では、第1のパケットは、例えば、第1のネットワークデバイスによって受信され、かつ第2のネットワークデバイスを宛先とされる、サービスパケットであってもよい。
ステップ306：第1のネットワークデバイスが第2のパケットを取得するために第1のパケットを更新する。
一例では、第1のサブネットプレフィックスの範囲が第1のルートプレフィックスの範囲を含む場合、第1のネットワークデバイスは、第1のパケットの宛先アドレスと第1のルートプレフィックスとの間の最長一致および第1のルートプレフィックスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のパケットが第2の経路内の経路識別子に基づいて送信され得ると決定してもよい。第1のネットワークデバイスは、第2のパケットを取得するために、経路識別子を第1のパケットに更新することができる。経路識別子は、例えば、ネットワークスライス識別子または中間ネットワークデバイスに含まれる第2のSID、例えば、END SIDを含んでもよい。
別の例では、第1のルートが第1のアドレスをさらに含み、第1のアドレスと第1のサブネットプレフィックスとの間に最長一致がある場合、第1のネットワークデバイスは、第1のパケットの宛先アドレスと第1のルートプレフィックスとの間の最長一致に基づいて、第1のパケットが第2のルートの経路識別子に基づいて送信され得ると決定してもよい。第1のネットワークデバイスは、第2のパケットを取得するために、経路識別子を第1のパケットに更新することができる。加えて、第1のアドレスが第1のSIDであるとき、第1のネットワークデバイスは、第2のパケットを取得するために第1のSIDを第1のパケットにさらに更新することができる。すなわち、更新された第2のパケットは、第1のSIDおよび経路識別子を含む。
経路識別子がネットワークスライス識別子（例えば、FlexAlgo ID）である場合には、経路識別子は、第2のパケットのホップバイホップ（hop by hop）オプションヘッダで搬送され得ることを理解されたい。
一例では、第1のルートを受信した後に、第1のネットワークデバイスは、対応するルーティングテーブルまたは転送テーブルを生成することができる。テーブルは、第1のルートプレフィックスおよび第1のSIDを含む。このようにして、第1のパケットを取得した後で、第1のネットワークデバイスは、第2のパケットを取得するために、第1のパケットに対応する第1のSIDを決定するために、テーブル探索によって、第1のパケットの宛先アドレスと第1のルートプレフィックスとの間に最長一致があると決定し、第1のパケットに第1のSIDをカプセル化することができる。
別の例では、第1のネットワークデバイスは、第2のパケットを取得するために、異なるテーブルから、第1のルートプレフィックスに対応する第1のSIDを取得することができる。
ステップ307：第1のネットワークデバイスが出口を介して第2のパケットを送信し、出口は経路識別子に基づいて第1のネットワークデバイスによって決定される。
本実施形態では、出口を介して第2のパケットを送信する前に、第1のネットワークデバイスは、第2のパケット内の第1のアドレスに基づいて、第2のパケットを送信するための出口を決定することができる。
第1のネットワークデバイスは、複数の方式で出口を決定することができる。
一例では、第1のネットワークデバイスは、第1のアドレスと第1のサブネットプレフィックスとの間の最長一致に基づいて、第1のアドレスと経路識別子との間の対応関係を生成することができる。したがって、第1のネットワークデバイスは、第2のパケット内の第1のアドレスおよび対応関係に基づいて経路識別子を決定することができる。経路識別子がネットワークスライス識別子である場合、第1のネットワークデバイスは、ネットワークスライス識別子に基づいて、第2のパケットを送信するための出口を取得することができる。経路識別子が中間ネットワークデバイスに含まれる第2のSIDである場合、中間ネットワークデバイスによって発行された第2のルートは、第2のSIDとネットワークスライス識別子との間のマッピング関係をさらに含むことができる。第1のネットワークデバイスは、第2のSIDと第2のルートとの間のマッピング関係に基づいて対応するネットワークスライス識別子を決定し、次いで、取得されたネットワークスライス識別子に基づいて対応する出口を決定することができる。
一例では、第1のネットワークデバイスは、ネットワークスライス識別子に基づいて事前に経路計算を実行して、ネットワークスライス識別子に対応する出口を決定し、ネットワークスライス識別子と出口の識別子との間の対応関係を記憶することができる。この場合、第1のネットワークデバイスは、第1のサブネットプレフィックスとネットワークスライス識別子との間の対応関係およびネットワークスライス識別子と出口識別子との間の対応関係に基づいて出口の識別子を取得し、出口を決定することができる。
別の例では、第1のネットワークデバイスがネットワークスライス識別子に対応する出口を取得し、第1のSIDと第1のサブネットプレフィックスとの間に最長一致がある場合、第1のネットワークデバイスは、第1のSIDと出口の識別子との間の対応関係を生成する。このようにして、第1のネットワークデバイスは、第2のパケット内の第1のSIDおよび対応関係に基づいて第2のパケットの出口を決定することができる。
ステップ308：中間ネットワークデバイスが第2のパケットを受信する。
第1のネットワークデバイスと中間ネットワークデバイスとの間に別のネットワークデバイスがない場合、第1のネットワークデバイスは、出口を介して中間ネットワークデバイスに第2のパケットを送信することができる。
第1のネットワークデバイスと中間ネットワークデバイスとの間に別のネットワークデバイスがある場合、第1のネットワークデバイスが位置されるIGPドメイン内のネットワークデバイスも中間ネットワークデバイスによって送信されたルート告知パケットを受信するので、同様に、第1のネットワークデバイスが出口を介して第2のパケットを送信した後に、第1のネットワークデバイスと中間ネットワークデバイスとの間のネットワークデバイスが、中間ネットワークデバイスが第2のパケットを受信することを最終的に保証するために、第2のパケット内の経路識別子に基づいて第2のパケットを転送することができる。
ステップ309：中間ネットワークデバイスが、第3のパケットを取得するために第2のパケットを更新し、第3のパケットはセグメント識別子リストを含む。
第2のパケットを受信した後に、中間ネットワークデバイスは、第2のパケットに基づいて対応するトラフィック・エンジニアリング・トンネルを決定することができ、その結果、中間ネットワークデバイスが、決定されたトラフィック・エンジニアリング・トンネルに基づいて第2のパケットを転送することができる。
中間ネットワークデバイスは、第2のパケットの宛先アドレスに基づいて最長一致動作を実行し、第2のパケットの宛先アドレスとトラフィック・エンジニアリング・トンネルに含まれる第2のサブネットプレフィックスとの間の最長一致に基づいて、トラフィック・エンジニアリング・トンネルに基づいて第2のパケットを転送することを決定することができる。
一例では、第2のパケットの宛先アドレスは、第1のSIDであってもよい。具体的には、中間ネットワークデバイスは、第1のSIDに基づいて最長一致動作を実行し、第1のSIDとトラフィック・エンジニアリング・トンネルに含まれる第2のサブネットプレフィックスとの間の最長一致に基づいて、トラフィック・エンジニアリング・トンネルに基づいて第2のパケットを転送することを決定することができる。
別の例では、第2のパケットの宛先アドレスは第1のSIDでなくてもよく、すなわち、第2のパケットの宛先アドレスは第1のパケットの宛先アドレスと同じであり、第1のネットワークデバイスは第1のパケットの宛先アドレスを更新しない。
方式2では、第2のパケットの宛先アドレスが第1のSIDではない2つのケースがあり得ることを理解されたい。
ケース1：第2のルート内の第1のサブネットプレフィックスの範囲は、第1のルート内の第1のルートプレフィックスの範囲を含む。言い換えれば、トラフィック・エンジニアリング・トンネル内の第2のサブネットプレフィックスの範囲は、第1のルートプレフィックスの範囲を含み、第2のサブネットプレフィックスは、複数のルートプレフィックスを集約することによって得られるアグリゲーション・ネットワーク・セグメントであってもよい。
ケース2：第1のルートは第1のアドレスをさらに含み、第1のアドレスはネクストホップアドレスであり、第1のアドレスと第1のサブネットプレフィックスとの間に最長一致がある。言い換えれば、トラフィック・エンジニアリング・トンネル内の第2のサブネットプレフィックスの範囲は、ネクストホップアドレスの範囲を含み、第2のサブネットプレフィックスは、複数のネクストホップアドレスを集約することによって取得されたアグリゲーション・ネットワーク・セグメントであってもよい。
加えて、上述されたように、第1のサブネットプレフィックスと第2のサブネットプレフィックスとは同じであっても異なっていてもよい。
一例では、第1のサブネットプレフィックスと第2のサブネットプレフィックスとが同じである場合、中間ネットワークデバイスは、最長一致原理に従って、最も高い一致度を有する第2のサブネットプレフィックスが見つけられるまで、第2のパケットまたは第1のSIDの宛先アドレスに対応するサブネットプレフィックスを求めて、1つまたは複数の取得されたトラフィック・エンジニアリング・トンネルに対応するサブネットプレフィックスを探索することができる。
別の例では、第1のサブネットプレフィックスと第2のサブネットプレフィックスとが異なる場合、第1のサブネットプレフィックスは、複数のトラフィック・エンジニアリング・トンネルに含まれるサブネットプレフィックスを集約することによって取得されてもよい。同様に、中間ネットワークデバイスは、最長一致原理に従って、最も高い一致度を有する第2のサブネットプレフィックスが見つけられるまで、第2のパケットまたは第1のSIDの宛先アドレスに対応するサブネットプレフィックスを求めて1つまたは複数の取得されたトラフィック・エンジニアリング・トンネルに対応するサブネットプレフィックスを探索することができる。
ルートを探索する場合、複数の照合結果が通常取得され得、複数の照合結果から最長ネットワークプレフィックスを有するルートが選択されることが理解されよう。これは最長一致原理と呼ばれてもよい。より長いネットワークプレフィックスは、より小さいアドレスブロックおよびより具体的なルートを示す。
第2のパケットの宛先アドレスと第1のサブネットプレフィックスとの間に最長一致があると決定された場合、第1のサブネットプレフィックスは第1のトラフィック・エンジニアリング・トンネルに含まれるため、中間ネットワークデバイスは、第1のトラフィック・エンジニアリング・トンネルに含まれる転送経路を決定することができる。転送経路は、例えば、セグメント識別子リストであってもよい。このようにして、中間ネットワークデバイスは、セグメント識別子リストを含む第3のパケットを取得するために、セグメント識別子リストを第2のパケットに更新することができる。第3のパケット内のセグメント識別子リストは、第3のパケットを転送するために第2のネットワークデバイスと中間ネットワークデバイスとの間のネットワークデバイスを指示し、その結果、第3のパケットが第2のネットワークデバイスへ転送される。
可能な例では、第1のトラフィック・エンジニアリング・トンネルがSR Policyである場合、SR Policyは、負荷共有を実施するために、複数の候補経路（candidate path）を含むことができ、複数の候補経路は異なる重みを有する。中間ネットワークデバイスは、SR Policy内の複数の候補経路の重みに基づいて経路を選択し、経路に対応するセグメント識別子リストを取得することができる。
ステップ310：中間ネットワークデバイスが第3のパケットを送信する。
中間ネットワークデバイスは、第3のパケットの宛先アドレスに基づいて第3のパケットを送信することができ、第3のパケットの宛先アドレスは、第3のパケットに含まれるセグメント識別子リスト内の第1のSIDであってもよい。中間ネットワークデバイスはセグメント識別子リストを含むので、第3のパケットは、第1のトラフィック・エンジニアリング・トンネルによって指示される経路に基づいて第2のネットワークデバイスへ転送され得る。この実施形態では、第1のネットワークデバイスは、第2のネットワークデバイスによって発行された第1のルートおよび中間ネットワークデバイスによって発行された第2のルートを別々に取得し、第1のルート内のルートプレフィックスまたは第1のアドレスと第2のルート内のサブネットプレフィックスとの間の一致に基づいて第1のルートを第2のルートに関連付けるので、その結果、第1のネットワークデバイスが、第2のルート内の経路識別子に基づいて出口を決定し、第2のネットワークデバイスを宛先とするパケットを中間ネットワークデバイスに転送することができ、中間ネットワークデバイスが、第2のパケットを第2のネットワークデバイスに転送するように構成される。このようにして、ネットワーク内のトンネルまたはトラフィック・エンジニアリング・トンネルの数が低減され得、構成または管理の複雑さが回避され得る。
理解を容易にするために、以下で、具体例を参照して、本出願の実施形態で提供されるデータ処理方法を詳細に説明する。
図4は、本出願の一実施形態によるデータ処理方法400の概略フローチャートである。図4に示されるように、図4のネットワークアーキテクチャは、図1に示すネットワークアーキテクチャと同様である。描画を容易にするために、ネットワークデバイス1とネットワークデバイス3との間のネットワークデバイスは示されておらず、ネットワークデバイス2とネットワークデバイス3との間のネットワークデバイスも示されていない。ネットワークデバイス1が位置されるバックボーンネットワークは、FlexAlgoネットワークまたはSRネットワークであってもよく、ネットワークデバイス2が位置されるメトロポリタン・エリア・ネットワークは、トラフィックエンジニアリングで構成されたSRネットワークであってもよい。トラフィックエンジニアリングは、SR PolicyまたはSR TEトンネルを含む。説明を容易にするために、以下では、バックボーンネットワークがFlexAlgoネットワークをサポートし、メトロポリタン・エリア・ネットワークがSR Policyネットワークで構成される例を使用して、データ処理方法400を説明する。
図4に示されるように、データ処理方法400は以下のステップを含む。
ステップ401：ネットワークデバイス2が、ルートリフレクタを使用してネットワークデバイス1にルート1を発行する。
ケース1：ルート1はルートプレフィックス1を含み、ルートプレフィックス1は、ルート1が、宛先アドレスとルートプレフィックス1とが最長一致するパケットのルーティング情報であることを示す。例えば、ルートプレフィックス1は、例えば、A1：：1／84であってもよい。
任意選択で、ルート1は、以下の2つの場合に示されるように、以下の情報をさらに含むことができる。
ケース2：ルート1は、ネクストホップアドレスをさらに含み、ルート1は、宛先アドレスがルートプレフィックス1に対応するパケットが、ネクストホップアドレスによって示されるデバイスまたはサービスを使用して送信され得ることを示す。ネクストホップアドレスは、例えば、ネットワークデバイス2のloopbackアドレスであってもよい。例えば、ネクストホップアドレスは、例えば、B1：：1であってもよい。
ケース3：ルート1は、ルートプレフィックス1およびSIDを含み、ルート1は、宛先アドレスとルートプレフィックス1とが最長一致するパケットが、SIDによって示されるデバイスまたはサービスを使用して送信され得ることを示す。SIDは、ネットワークデバイス1に対応するlocatorネットワーク・セグメントに割り当てられたVPN SIDであってもよい。例えば、VPN SIDはC1：：1であってもよい。
ルートリフレクタを使用してネットワークデバイス1にルートを発行することに加えて、ネットワークデバイス2は、別の方式でネットワークデバイス1にルート1を発行してもよく、例えば、ネットワークデバイス3を使用してネットワークデバイス1にルートを発行してもよいことが理解されよう。ここでは詳細は繰り返されない。
ステップ402：コントローラがネットワークデバイス3にSR Policyを送信する。
この実施形態では、コントローラは、対応するSR Policyを取得するために、サービス要求に基づいてネットワークデバイス3からネットワークデバイス2への転送経路を計算し、計算によって取得されたSR Policyをネットワークデバイス3に配信することができる。例えば、コントローラは、SR Policyを取得するために、低レイテンシ要件に基づいてネットワークデバイス3からネットワークデバイス2への転送経路を計算する。SR PolicyのHeadendは、ネットワークデバイス3のアドレスであり、Endpointはサブネットプレフィックスである。SR Policyは、ネットワークデバイス3からネットワークデバイス2への転送経路を示すセグメント識別子リストをさらに含む。
例えば、ルート1がルートプレフィックス1を含むケース1では、SR PolicyのEndpointの範囲は、ルートプレフィックス1の範囲を含んでもよい。例えば、EndpointはA1：：0／64であってもよい。
ルート1がネクストホップアドレスをさらに含むケース2では、SR PolicyのEndpointの範囲は、ネクストホップアドレスの範囲を含んでもよい。例えば、EndpointはB1：：0／64であってもよい。
ルート1がSIDをさらに含むケース3では、SR PolicyのEndpointの範囲がSIDの範囲を含んでもよい。例えば、EndpointがC1：：0／64であってもよい。
SR Policyはcolorをさらに含み、colorはSR Policyに対応するサービス要件に関連付けられる。例えば、color 123は、SR Policyに対応するサービス要件が低レイテンシ要件であることを識別することができる。
一例では、colorとネットワークスライス識別子との間の対応関係は、ネットワークデバイス3に予め設定される。具体的には、ネットワークデバイス3は、SR Policy内のcolorおよび対応関係に基づいて、SR Policyに対応するネットワークスライス識別子を決定することができる。例えば、SR Policyのcolorは、例えば123であってもよい。この場合、ネットワークデバイス3は、対応関係に基づいて、対応するネットワークスライス識別子がFlexAlgo 128であると決定することができる。ネットワークスライス識別子に基づいて経路計算を実行することによって取得された経路はまた、SR Policyに対応するサービス要件を満たし、具体的には、低レイテンシ要件を満たす。
別の例では、colorとネットワークスライス識別子との間の対応関係は、ネットワークデバイス3に予め設定される。SR Policy内のcolorおよび対応関係に基づいて、SR Policyに対応するネットワークスライス識別子を決定した後に、ネットワークデバイス3は、対応するSIDをネットワークスライス識別子にさらに割り当てることができる。SIDは、例えば、END SIDであってもよい。加えて、ネットワークデバイス3は、ネットワークスライス識別子とSIDとの間のマッピング関係を生成することができる。例えば、ネットワークスライス識別子とSIDとの間のマッピング関係を示すマッピング関係表が表1に示され得る。
ステップ403：ネットワークデバイス3がルート告知パケットを発行し、その結果、ネットワークデバイス1はルート2を受信する。
SR Policyを取得することに応答して、中間ネットワークデバイスは、ルート告知パケットを生成し、中間ネットワークデバイスが位置されるIGPドメインでルート告知パケットを発行することができる。
実施態様では、ルート告知パケット内のルートプレフィックス2はSR PolicyのEndpointであってもよく、例えば、A1：：0／64、B1：：0／64、またはC1：：0／64であってもよい。ルート告知パケットは、SR Policyに対応する経路識別子、例えば、ネットワークスライス識別子（例えば、FlexAlgo 128）、またはネットワークスライス識別子に基づいてネットワークデバイス3によって割り当てられたSIDをさらに搬送することができる。ネットワークスライス識別子は、ネットワークスライス識別子の指示に基づいてルートプレフィックス2の経路計算を実行し、対応する出口を決定し、パケットをネットワークデバイス3に転送するための経路に沿ったネットワークデバイスを示す。
一例では、経路識別子がネットワークスライス識別子に基づいてネットワークデバイス3によって割り当てられたSIDである場合、ルート告知パケットは、ネットワークスライス識別子とSIDとの間のマッピング関係をさらに含むことができる。ルート告知パケットを受信したネットワークデバイスは、マッピング関係に基づいて対応するマッピング関係表を生成することができ、その結果、SIDを含むパケットを受信した場合、ネットワークデバイスは、SIDおよびマッピング関係表に基づいて対応するネットワークスライス識別子を決定することができる。
別の実施態様では、ネットワークデバイス3が、ネットワークデバイス2が位置されるネットワークドメインを宛先とする複数のSR Policyを受信し、これらのSR Policyが同じcolorを有する場合、ネットワークデバイス3は、アグリゲーション・ネットワーク・セグメントを取得するためにこれらのSR PolicyのEndpointを集約することができ、アグリゲーション・ネットワーク・セグメントの範囲は複数のSR PolicyのEndpointの範囲を含む。例えば、アグリゲーション・ネットワーク・セグメントはA1：：0／48であってもよく、ネットワークデバイス2に対応するSR PolicyのEndpointはA1：：0／64である。明らかに、A1：：0／48の範囲は、A1：：0／64の範囲を含む。
ネットワークデバイス3がIGPドメインでルート告知パケットを発行した後に、ネットワークデバイス1は対応するルート2を受信することができ、ルート2はルートプレフィックス2および経路識別子を含む。ルートプレフィックス2は、SR PolicyのEndpointであってもよいし、複数のSR Policyに基づいて取得されたアグリゲーション・ネットワーク・セグメントであってもよい。
ステップ404：ネットワークデバイス1がパケット1を受信する。
パケット1は、ネットワークデバイス2に向かうサービストラフィックである。具体的には、パケット1の宛先アドレスとネットワークデバイス2によって発行された宛先ルートのプレフィックスアドレスとの間には最長一致がある。
ステップ405：ネットワークデバイス1が、パケット2を取得するためにパケット1を更新し、パケット2は経路識別子を搬送する。
ルート1がルートプレフィックス1を含むケース1では、ネットワークデバイス1は、パケット1の宛先アドレスに基づいて最長一致演算を実行して、パケット1の宛先アドレスとルートプレフィックス2との間に最長一致があると決定することができる。この場合、ネットワークデバイス1は、ルート1の経路識別子をパケット1に更新する。
ルート1がネクストホップアドレスを含むケース2では、ネットワークデバイス1は、パケット1の宛先アドレスに基づいて、パケット1を転送するためのネクストホップアドレスとルートプレフィックス2との間に最長一致があると決定することができる。この場合、ネットワークデバイス1は、ルート1の経路識別子をパケット1に更新する。
経路1がSIDを含むケース3では、ネットワークデバイス1は、パケット1を転送するためのネクストホップアドレスがSIDであると決定するために、パケット1の宛先アドレスに基づいて最長一致動作を実行することができ、SIDとルートプレフィックス2との間に最長一致がある。この場合、ネットワークデバイス1は、ルート1内の経路識別子およびSIDをパケット1に更新する。
一例では、ルート1およびルート2を受信した後に、ネットワークデバイス1は、ルート1内のネクストホップアドレスまたはSIDとルート2内のルートプレフィックス2との間の最長一致に基づいて、ネクストホップアドレスまたはSIDとルート2との間の関連付け関係を確立することができ、その結果、パケット1を転送するためのネクストホップアドレスがネクストホップアドレスまたはSIDであると決定した場合、ネットワークデバイス1は、関連付け関係に基づいて対応するルート2を決定して、最長一致演算を再度実行することを回避することができる。
ネットワークデバイス1は、2つの方式でパケット1を更新することができる。
方式1：経路識別子がネットワークスライス識別子である場合、ネットワークデバイス1は、パケット2を取得するために、ネットワークスライス識別子をパケット1のホップバイホップヘッダにカプセル化することができる。
方式2：経路識別子がSIDであるとき、ネットワークデバイス1は、パケット2を取得するために、パケット1のセグメントルーティングヘッダ（Segment Routing Header、SRH）拡張ヘッダにSIDをカプセル化することができる。
ステップ406：ネットワークデバイス1が出口を介してパケット2を送信する。出口は、パケット2に対応する経路識別子に基づいて経路計算を行うことによってネットワークデバイス1によって取得され、パケット2に対応する経路識別子は、ルート2で搬送された経路識別子である。
一例では、ルート2を受信した後に、ネットワークデバイス1は、対応する出口を取得するために、ルート2内の経路識別子に基づいて経路計算を実行することができる。このようにして、経路識別子を含むパケット2を生成した後に、ネットワークデバイス1は、パケット2内の経路識別子に対応する出口に基づいて、パケット2を送信するために使用される出口を決定することができる。
ネットワークデバイス1が出口を取得するために経路識別子に基づいて経路計算を実行する2つの方式があり得る。
方式1：経路識別子はSIDである。ネットワークデバイス1によって受信されたルート2は、SID、およびSIDとネットワークスライス識別子との間のマッピング関係を含む。ネットワークデバイス1は、SIDおよびマッピング関係に基づいて、SIDに対応するネットワークスライス識別子を決定し、次いで、ネットワークスライス識別子に基づいて経路計算を実行して、SIDに対応する出口を取得することができる。
方式2：経路識別子はネットワークスライス識別子である。ネットワークデバイス1によって受信されたルート2は、ネットワークスライス識別子を含む。ネットワークデバイス1は、ネットワークスライス識別子に対応する出口を取得するために、ネットワークスライス識別子に基づいて経路計算を実行することができる。
ステップ407：ネットワークデバイス3が、パケット3を取得するためにパケット2を更新する。
ネットワークデバイス1が位置されるIGPドメイン内のネットワークデバイスも、ネットワークデバイス3によって送信されたルート告知パケットを受信するので、同様に、ネットワークデバイス1が出口を介してパケット2を送信した後に、ネットワークデバイス1とネットワークデバイス3との間のネットワークデバイスはまた、パケット2の経路識別子に基づいて、パケット2を転送するための出口を決定することができ、その結果、ネットワークデバイス3がパケット2を受信することができる。
例えば、パケット2内の経路識別子がネットワークスライス識別子である場合、ネットワークデバイス1とネットワークデバイス3との間のネットワークデバイスは、パケット2を転送するための出口を取得するために、パケット2のホップバイホップヘッダ内のネットワークスライス識別子に基づいて経路計算を実行することができる。パケット2内の経路識別子がSIDである場合、ネットワークデバイス1とネットワークデバイス3との間のネットワークデバイスは、パケット2のSRH拡張ヘッダ内の最外層にあるSIDを取得し、SIDおよびSIDとネットワークスライス識別子との間のマッピング関係に基づいて、SIDに対応するネットワークスライス識別子を決定し、次いで、ネットワークスライス識別子に基づいて経路計算を実行して、パケット2を転送するための出口を取得することができる。
パケット2を受信した後に、ネットワークデバイス3は、パケット2の宛先アドレスに基づいて最長一致動作を実行することができ、パケット2の宛先アドレスはSIDであってもなくてもよい。パケット2の宛先アドレスがSIDを搬送する場合には、ネットワークデバイス3は、SIDに基づいて最長一致演算を実行し、SIDとトラフィック・エンジニアリング・トンネルに含まれるEndpointとの間の最長一致に基づいて、トラフィック・エンジニアリング・トンネルに基づいてパケット2を転送するために、例えば、SID（C1：：1）とトラフィック・エンジニアリング・トンネル内のEndpoint（C1：：0／64）との間の最長一致を決定することができる。
パケット2に対応するトラフィック・エンジニアリング・トンネルを決定した後で、ネットワークデバイス3は、パケット3を取得するために、トラフィック・エンジニアリング・トンネル内のセグメント識別子リストをパケット2に更新することができる。
ステップ408：ネットワークデバイス3がパケット3を送信する。
更新によってパケット3を取得した後に、ネットワークデバイス3は、パケット3内のセグメント識別子リストに基づいてパケット3を転送することができる。加えて、ネットワークデバイス3とネットワークデバイス2との間のネットワークデバイスはまた、パケット3内のセグメント識別子リストに基づいてパケット3を転送することもでき、その結果、パケット3は最終的にネットワークデバイス2に転送される。
具体的には、図5aは、本出願の一実施形態によるパケット転送の概略図である。図5aに示されるように、図5aで説明されたパケット転送プロセスは、図4に対応する実施形態に基づいている。ネットワークデバイスAは、ネットワークデバイス1とネットワークデバイス2との間にさらに含まれ、ネットワークデバイス3とネットワークデバイス2との間にネットワークデバイスBおよびネットワークデバイスCがさらに含まれる。
ネットワークデバイス1によって送信されるパケット2は、VPN SID（C1：：1）およびEND SID（B1：1：1：1：1）を含む。ネットワークデバイス1は、END SIDに基づいてパケット2の出口を決定し、パケット2をネットワークデバイスAに送信する。同様に、ネットワークデバイスAは、パケット2内のEND SID、およびSIDとネットワークスライス識別子との間のマッピング関係に基づいて出口を決定し、パケット2をネットワークデバイス3に送信することができる。
パケット2を受信した後に、ネットワークデバイス3は、パケット2内のVPN SIDに基づいて、SR Policyと、SR Policyに対応するセグメント識別子リスト｛4：：4、3：：3、2：：2、1：：1｝と、を決定することができる。ネットワークデバイス3、ネットワークデバイスB、ネットワークデバイスC、およびネットワークデバイスAに対応するセグメント識別子は、それぞれ4：：4、3：：3、2：：2、および1：：1である。したがって、ネットワークデバイス3は、セグメント識別子リストを含むパケット3を取得するために、取得されたセグメント識別子リストをパケット2にカプセル化する。このようにして、ネットワークデバイス2、ネットワークデバイスB、およびネットワークデバイスCは、セグメント識別子リストの指示に基づいてパケット3をネットワークデバイス2に転送することができる。
図5bは、本出願の一実施形態による別のパケット転送の概略図である。図5bに示されるように、図5bで説明されたパケット転送プロセスも、図4に対応する実施形態に基づく。ネットワークデバイス1によって送信されるパケット2において、パケット2は、VPN SID（C1：：1）およびネットワークスライス識別子（FlexAlgo 128）を含む。ネットワークデバイス1は、ネットワークスライス識別子に基づいてパケット2の出口を決定し、パケット2をネットワークデバイスAに送信する。同様に、ネットワークデバイスAは、パケット2内のネットワークスライス識別子に基づいて出口を決定し、パケット2をネットワークデバイス3に送信することができる。
上記では、FlexAlgoネットワークからSRネットワークにパケットを転送するプロセスについて説明している。以下では、SRネットワークからFlexAlgoネットワークにパケットを転送するプロセスについて説明する。前述のいくつかの実施形態で説明されたFlexAlgoネットワークまたは本明細書で説明されたFlexAlgoネットワークに関係なく、SRも実行されてもよく、ネットワークと前述のSRネットワークは主に異なるIGPドメインであることを理解されたい。
図6は、本出願の一実施形態によるデータ処理方法600の概略フローチャートである。図6に示されるように、データ処理方法600は以下のステップを含む。
ステップ601：第1のネットワークデバイスがサブネットプレフィックスおよびセグメント識別子リストを取得し、サブネットプレフィックスはトラフィック・エンジニアリング・トンネルの宛先識別子であり、トラフィック・エンジニアリング・トンネルはセグメント識別子リストを含む。
第1のネットワークデバイスは、例えば、ルータ、スイッチ、またはゲートウェイなどの物理デバイスであってもよく、またはルート発行およびパケット転送をサポートする仮想デバイスであってもよい。例えば、データ処理方法600が図1に示すシナリオに適用される場合、第1のネットワークデバイスは、例えば、図1に示されるメトロポリタン・エリア・ネットワークに位置されるPEデバイスであってもよく、第1のネットワークデバイスが位置されるメトロポリタン・エリア・ネットワークは、トラフィックエンジニアリングで構成されたSRネットワークであってもよく、トラフィックエンジニアリングは、SR PolicyまたはSR TEトンネルを含む。
第1のネットワークデバイスによって取得されたトラフィック・エンジニアリング・トンネルは、コントローラまたは別のデバイスによって中間ネットワークデバイスに送信されてもよいし、あるいは中間ネットワークデバイス内で事前構成されてもよい。トラフィック・エンジニアリング・トンネルは、サブネットプレフィックスおよびセグメント識別子リストを含む。サブネットプレフィックスは、第2のネットワークデバイスのアドレス、例えば、第2のネットワークデバイスのloopbackアドレスであってもよい。セグメント識別子リストは、第1のネットワークデバイスから中間ネットワークデバイスへの転送経路を示し、中間ネットワークデバイスは、第1のネットワークデバイスと第2のネットワークデバイスとの間に位置される。セグメント識別子リストは、1つまたは複数のセグメント識別子を含んでもよい。
ステップ602：第1のネットワークデバイスが第2のネットワークデバイスに関連する第1のルートを取得し、第1のルートはルートプレフィックスおよび第1のアドレスを含み、第1のアドレスとサブネットプレフィックスとの間には最長一致がある。
第2のネットワークデバイスは、例えば、ルータ、スイッチ、またはゲートウェイなどの物理デバイスであってもよく、またはルート発行およびパケット転送をサポートする仮想デバイスであってもよい。例えば、データ処理方法600が図1に示されるシナリオに適用される場合、第2のネットワークデバイスは、例えば、図1に示されるバックボーンネットワーク内に位置するクラウドPEデバイスであってもよく、第2のネットワークデバイスが位置されるバックボーンネットワークは、FlexAlgoネットワークまたはSRネットワークであってもよい。
この実施形態では、第1のネットワークデバイスと第2のネットワークデバイスとの間にネットワーク接続が確立され、第1のネットワークデバイスと第2のネットワークデバイスとの間に1つまたは複数のネットワークデバイスが含まれる。第1のネットワークデバイスと第2のネットワークデバイスとの間で伝送されるパケットは、第1のネットワークデバイスと第2のネットワークデバイスとの間の1つまたは複数のネットワークデバイスを通過する必要がある。
バックボーンネットワーク内の第2のネットワークデバイスは、第2のネットワークデバイスと第1のネットワークデバイスとの間のルートリフレクタまたは別のネットワークデバイスを使用して、第1のネットワークデバイスに第1のルートを発行することができる。
一例では、第1のネットワークデバイスによって取得された第1のルートは、第2のネットワークデバイスによって発行されたルートであってもよく、または第1のルートは、第1のネットワークデバイスが第2のネットワークデバイスによって発行されたルートを受信した後に生成されたルートであってもよい。
第1のルート内のルートプレフィックスは、第2のネットワークデバイスのアドレス情報を示し、ルートプレフィックスは、例えば、D1：：1であってもよい。
一例では、第1のルート内の第1のアドレスは、ネットワークデバイスのネクストホップアドレスまたは第2のネットワークデバイスのSIDを含んでもよく、ネクストホップアドレスは、例えば、第2のネットワークデバイスのloopbackアドレスであってもよい。第2のネットワークデバイスのSIDは、ネットワーク内の第2のネットワークデバイスの位置または第2のネットワークデバイスによって提供されるネットワークサービス、例えば、第2のネットワークデバイスの位置を示すことができるVPN SIDまたは別のSIDを示すことができる。
可能な例では、第1のルートおよびトラフィック・エンジニアリング・トンネルを受信した後に、第1のネットワークデバイスは、ルート反復を実行することができ、言い換えれば、第1のルートに対応するトラフィック・エンジニアリング・トンネルを照合することができる。
例えば、第1のネットワークデバイスは、第1のルート内の第1のアドレスに基づいて、トラフィック・エンジニアリング・トンネル内にあり、第1のアドレスと一致するサブネットプレフィックスを決定することができる。第1のルートの第1のアドレスとトラフィック・エンジニアリング・トンネルのサブネットプレフィックスとの間に最長一致があると決定した場合、第1のネットワークデバイスは、第1のルート内のルートプレフィックスとトラフィック・エンジニアリング・トンネル内のセグメント識別子リストとの間の対応関係を生成することができる。
トラフィック・エンジニアリング・トンネルがSR Policyである場合、サブネットプレフィックスはSR PolicyのEndpointであってもよく、SR Policyはcolorをさらに含む。colorはサービス要件に関連付けられ、SR Policyが低レイテンシまたは高帯域幅などのサービス要件に基づく計算によって取得されることを示すことができる。第1のルートは経路識別子をさらに含み、経路識別子は、例えばcolorであってもよい。第2のネットワークデバイスのSIDが構成されるとき、第2のネットワークデバイスに対応する経路識別子は、第2のネットワークデバイスに対応するサービス要求に基づいて決定されてもよく、経路識別子に対応するSIDは、第2のネットワークデバイスのために構成され、すなわち、SIDと経路識別子との間の対応関係が確立され、その結果、SIDのために別のネットワークデバイスによって計算されたすべての経路が経路識別子の要求を満たすことが理解されよう。
この場合、第1のルートの第1のアドレスがSR Policyのサブネットプレフィックスと一致するかどうかを決定することに加えて、第1のネットワークデバイスは、第1のルート内の経路識別子がSR Policyに含まれるcolorと一致するかどうかをさらに決定することができる。経路識別子がSR Policyに含まれるcolorと一致すると決定した場合、第1のネットワークデバイスは、第1のルート内のルートプレフィックスとSR Policy内のセグメント識別子リストとの間の対応関係を生成するために、第1のルートがSR Policyに対応すると決定する。
例えば、経路識別子がcolorである場合、第1のネットワークデバイスは、第1のルート内のcolorがSR Policyに含まれるcolorと同じであるかどうかを比較することによって、2つが一致するかどうかを決定することができる。
加えて、第1のネットワークデバイスは、経路識別子とサブネットプレフィックスとの間の対応関係を用いて代替として静的に構成されてもよい。具体的には、第1のネットワークデバイスは、対応関係およびトラフィック・エンジニアリング・トンネル内のサブネットプレフィックスに基づいて、対応する経路識別子を決定することができる。経路識別子は、例えば、アルゴリズム識別子であってもよい。このようにして、トラフィック・エンジニアリング・トンネルに基づいてパケットを送信するときに、第1のネットワークデバイスは、トラフィック・エンジニアリング・トンネルに対応するアルゴリズム識別子をパケットに含めることができる。
本実施形態では、トラフィック・エンジニアリング・トンネル内のサブネットプレフィックスは、第2のネットワークデバイスが位置されるネットワークドメインのアグリゲーション・ネットワーク・セグメントであってもよい。言い換えれば、第2のネットワークデバイスが位置されるネットワークドメイン内のすべてのネットワークデバイスのアドレスは、サブネットプレフィックスの範囲内にある。言い換えれば、第2のネットワークデバイスが位置されるネットワークドメイン内の任意のネットワークデバイスについて、ネットワークデバイスによって発行されたルート内のネクストホップアドレスはサブネットプレフィックスと一致することができ、トラフィック・エンジニアリング・トンネルは、複数のネットワークデバイスによって発行されたルートと一致することができる。例えば、トラフィック・エンジニアリング・トンネル内のサブネットプレフィックスはD1：：0／64であってもよく、第2のネットワークデバイスによって発行された第1のルート内のネクストホップアドレスはD1：：10であり、第2のネットワークデバイスが位置されるネットワークドメイン内の別のネットワークデバイスによって発行された第2のルート内のネクストホップアドレスはD1：：20であり、D1：：10およびD1：：20はD1：：0／64の範囲内にある。
可能な例では、トラフィック・エンジニアリング・トンネルがSR Policyである場合、SR Policyに含まれるcolorは、エリアおよびサービス要件に基づいて割り当てられてもよく、SR PolicyのEndpointは0：：0である。例えば、第1のネットワークデバイスによって受信されたSR Policyに含まれるcolorが123として構成される場合、値が123であるcolorは、第2のネットワークデバイスが位置されるネットワークドメインにおいてサービス要件が低レイテンシであるすべてのネットワークデバイスに割り当てられてもよい。このようにして、これらのネットワークデバイスによって発行されたルートで搬送されるネクストホップアドレスはSR PolicyのEndpointと確実に一致することができ、それらのルートで搬送されるcolorもSR Policyに含まれるcolorと一致することができる。このようにして、これらのネットワークデバイスによって発行されたルートはSR Policyと一致することができる。
ステップ603：第1のネットワークデバイスが第1のパケットを受信し、第1のパケットの宛先アドレスとルートプレフィックスとの間に最長一致がある。
この実施形態では、第1のパケットは、例えば、第1のネットワークデバイスによって受信され、第2のネットワークデバイスを宛先とされるサービストラフィックであってもよい。具体的には、第1のパケットの宛先アドレスは、第2のネットワークデバイスの宛先アドレスである。したがって、第1のパケットの宛先アドレスと第2のネットワークデバイスによって発行された第1のルート内のルートプレフィックスとの間には最長一致がある。
ステップ604：第1のネットワークデバイスが第2のパケットを取得するために第1のパケットを更新する。
一例では、第1のパケットの宛先アドレスとルートプレフィックスとの間の最長一致に基づいて、第1のネットワークデバイスは、前述の対応関係に基づいて、第1のパケットに対応するセグメント識別子リストおよびSIDを決定し、第2のパケットを取得するために、セグメント識別子リストおよびSIDを第1のパケットに追加することができる。
ステップ605：第1のネットワークデバイスが第2のパケットを送信する。
セグメント識別子リストが第1のネットワークデバイスから中間ネットワークデバイスへの経路を指示するので、第1のネットワークデバイス、および第1のネットワークデバイスと中間ネットワークデバイスとの間のネットワークデバイスの両方が、第2のパケットを中間ネットワークデバイスへ転送するために、第2のパケット内のセグメント識別子リストに基づいて第2のパケットを送信することができる。
ステップ606：中間ネットワークデバイスが、第3のパケットを取得するために第2のパケットを更新する。
第2のパケットを受信した後で、中間ネットワークデバイスは、第2のパケット内のセグメント識別子リストに基づいて、中間ネットワークデバイスがセグメント識別子リストに示す最後のネットワークデバイスであることを識別することができる。この場合、中間ネットワークデバイスは、第3のパケットを取得するために第2のパケット内のセグメント識別子リストのカプセル化を解除することができ、第3のパケットは前述のセグメント識別子をさらに含む。
ステップ607：中間ネットワークデバイスが、第3のパケットを第2のネットワークデバイスへ転送する。
この実施形態では、第2のネットワークデバイスおよび中間ネットワークデバイスは、同じIGPドメインに位置されてもよく、第2のネットワークデバイスは、IGPドメインで、SIDを運ぶルートを事前に発行してもよい。さらに、IGPドメイン内の各ネットワークデバイスは、SIDとネットワークスライス識別子との間の対応関係で構成される。このようにして、IGPドメイン内のネットワークデバイスは、SIDに対応するネットワークスライス識別子に基づいて経路計算を実行し、対応する出口を取得することができる。具体的には、IGPドメインのネットワークデバイスが出口を決定する方式は、ステップ307の方式と同様である。ここでは詳細は繰り返されない。
言い換えれば、中間ネットワークデバイス、および第2のネットワークデバイスと中間ネットワークデバイスとの間のネットワークデバイスの両方が、SIDに基づいて対応する出口を決定し、第3のパケットを送信し、最後に第3のパケットを第2のネットワークデバイスに転送することができる。
理解を容易にするために、以下で、具体例を参照して、本出願の実施形態で提供されるデータ処理方法を詳細に説明する。
図7は、本出願の一実施形態によるデータ処理方法700の概略フローチャートである。図7に示されるように、図7のネットワークアーキテクチャは、図1に示されるネットワークアーキテクチャと同様である。描画を容易にするために、ネットワークデバイス1とネットワークデバイス3との間のネットワークデバイスは示されておらず、ネットワークデバイス2とネットワークデバイス3との間のネットワークデバイスも示されていない。ネットワークデバイス1が位置されるメトロポリタン・エリア・ネットワークは、トラフィックエンジニアリングで構成されたSRネットワークであってもよく、トラフィックエンジニアリングはSR PolicyまたはSR TEトンネルを含む。ネットワークデバイス2が位置されるバックボーンネットワークは、FlexAlgoネットワークまたはSRネットワークであってもよい。説明を容易にするために、以下では、バックボーンネットワークがFlexAlgoネットワークをサポートし、メトロポリタン・エリア・ネットワークがSR Policyネットワークで構成される例が使用されて、データ処理方法700を説明する。
ステップ701：コントローラがネットワークデバイス1にSR Policyを送信する。
この実施形態では、コントローラは、SR Policyを取得するために、ネットワークデバイス1のサービス要件に基づいてネットワークデバイス1からネットワークデバイス3への1つまたは複数の経路を計算することができる。SR PolicyのHeadendは、ネットワークデバイス1のアドレスであってもよく、Endpointは、ネットワークデバイス2が位置されるネットワークドメインのアグリゲーション・ネットワーク・セグメントであってもよい。アグリゲーション・ネットワーク・セグメントの範囲は、ネットワークデバイス2のアドレスの範囲を含む。例えば、ネットワークデバイス2のアドレスはD1：：10であってもよく、SR PolicyのEndpointはD1：：0／64であってもよい。SR Policyのcolorは、ネットワークデバイス1のサービス要件に対応する。例えば、ネットワークデバイス1のサービス要件が低レイテンシである場合、colorの値は低レイテンシを示す123であってもよい。SR Policyはセグメント識別子リストをさらに含み、SR Policyに対応する経路はセグメント識別子リストを用いて表されてもよい。
ステップ702：ネットワークデバイス2が、ルートリフレクタを使用してネットワークデバイス1にルート2を送信する。
ルート2は、ルートプレフィックスおよび第1のアドレスを含み、第1のアドレスは、ネクストホップアドレスまたはSIDを含んでもよい。ネットワークデバイス2がルートリフレクタを使用してルート2を送信し、ルートリフレクタはルート内のネクストホップアドレスを変更しない。したがって、ルート2内のネクストホップアドレスは、ネットワークデバイス2のネクストホップアドレスであり、例えば、D1：：10であってもよい。ルート2のSIDはVPN SIDであってもよく、SR FlexAlgoネットワーク内の第2のネットワークデバイスの位置情報を示す。例えば、SIDはD1：：1であってもよい。
ルート2を取得した後に、ネットワークデバイス1は、ルート反復を実行する、言い換えれば、ルート2をSR Policyに関連付ける。具体的には、ネットワークデバイス1は、ルート2内の第1のアドレスに基づいて最長マスク一致方式でSR PolicyのEndpointを一致する。ルート2のネクストホップアドレスがSR PolicyのEndpointと正常に一致する場合、ネットワークデバイス1は、ルート2をSR Policyに関連付けることができる。
加えて、ルート2はcolorをさらに搬送することができる。この場合、ルート反復を実行するとき、ネットワークデバイス1は、ルート2のネクストホップアドレスに加えて、ルート2のcolorをさらに一致させる必要がある。言い換えれば、ネットワークデバイス1が、ルート2のネクストホップアドレスがSR PolicyのEndpointと正常に一致し、ルート2のcolorもSR Policyのcolorと正常に一致すると決定した場合、ネットワークデバイス1がルート2をSR Policyに関連付けることができる。
ステップ703：ネットワークデバイス1がパケット4を受信する。
パケット4は、ネットワークデバイス2を宛先とするパケットであってもよい。具体的には、パケット4の宛先アドレスはネットワークデバイス2の宛先アドレスであり、ネットワークデバイス1は、パケット4の宛先アドレスとルート2のルートプレフィックスとの間の一致に基づいて、パケット4がルート2と一致し得ると決定することができる。
ステップ704：ネットワークデバイス1が、パケット5を取得するためにパケット4を更新する。
ルート2を受信した後に、ネットワークデバイス1がルート2をSR Policyに関連付ける。したがって、パケット4がルート2と一致すると決定した場合、ネットワークデバイス1は、ルート2およびSR Policyに基づいてパケット4を更新することができる。具体的には、ネットワークデバイス1は、パケット5を取得するために、ルート2のSIDおよびSR Policyに含まれるセグメント識別子リストをパケット4にカプセル化することができる。
ステップ705：ネットワークデバイス1が、パケット5内のセグメント識別子リストに基づいてパケット5を送信する。
パケット5を取得した後に、ネットワークデバイス1は、パケット5内のセグメント識別子リストによって示される経路に基づいてパケット5を送信することができる。パケット5内のセグメント識別子リストはネットワークデバイス1からネットワークデバイス3への経路を指示するので、SR Policyネットワークでは、ネットワークデバイス1とネットワークデバイス3との間のネットワークデバイスが、パケット5内のセグメント識別子リストに基づいてパケット5をネットワークデバイス3に転送することができる。
ステップ706：ネットワークデバイス3が、パケット6を取得するためにパケット5を更新する。
パケット5内のセグメント識別子リストによって示された経路に基づいて、ネットワークデバイス3が経路内の最後のネットワークデバイスであると決定した場合には、ネットワークデバイスは、セグメント識別子を含むパケット6を取得するために、パケット5内のセグメント識別子リストのカプセル化を解除する。
ステップ707：ネットワークデバイス3が、パケット6内のSIDに基づいてパケット6を送信する。
この実施形態では、ネットワークデバイス3およびネットワークデバイス2は、同じIGPドメインに位置されてもよく、ネットワークデバイス2は、IGPドメインで、SIDを運ぶルートを事前に発行してもよい。さらに、IGPドメイン内の各ネットワークデバイスは、SIDとネットワークスライス識別子との間の対応関係で構成される。このようにして、IGPドメイン内のネットワークデバイスは、SIDに対応するネットワークスライス識別子に基づいて経路計算を実行し、対応する出口を取得することができる。具体的には、IGPドメインのネットワークデバイスが出口を決定する方式は、ステップ207の方式と同様である。ここでは詳細は繰り返されない。
このようにして、パケット5を受信した後に、ネットワークデバイス3は、パケット5内のSIDを検出し、SIDに基づいて、パケット5を送信するための出口を決定し、出口を介してパケット5を送信することができる。あるいは、ネットワークデバイス3とネットワークデバイス2との間のネットワークデバイスが、パケット5内のSIDに基づいて対応する出口を決定し、パケット5を転送して、最終的にパケット5をネットワークデバイス2に転送してもよい。
具体的には、図8は、本出願の一実施形態による別のパケット転送の概略図である。図8に示されるように、図8で説明されたパケット転送プロセスは、図7に対応する実施形態に基づいている。ネットワークデバイス1とネットワークデバイス3との間にネットワークデバイスAおよびネットワークデバイスBがさらに含まれ、ネットワークデバイス3とネットワークデバイス2との間にネットワークデバイスCがさらに含まれる。
ネットワークデバイス1がパケット5を送信するとき、パケット5は、SR Policyに対応するセグメント識別子リスト｛1：：1、2：：2、3：：3、4：：4｝およびVPN SID（D1：：1）を含む。ネットワークデバイス1、ネットワークデバイスA、ネットワークデバイスB、およびネットワークデバイス3に対応するセグメント識別子は、それぞれ1：：1、2：：2、3：：3、および4：：4である。したがって、ネットワークデバイス1、ネットワークデバイスA、およびネットワークデバイスBが、セグメント識別子リストに基づいてパケット5を順次送信することができ、その結果、ネットワークデバイス3がパケット5を受信することができる。
パケット5を受信した後に、ネットワークデバイス3は、セグメント識別子リストの指示に基づいて、ネットワークデバイス3がセグメント識別子リストに示す最後のネットワークデバイスであると決定することができる。加えて、ネットワークデバイスは、パケット5内のVPN SIDに基づいて、パケット4に対応する出口を決定し、出口に基づいてパケット5を送信することができる。同様に、ネットワークデバイス3によって送信されたパケット5を受信した後に、ネットワークデバイスAは、パケット5をネットワークデバイス2に転送するために、パケット5内のVPN SIDに基づいてパケット5を送信することもできる。
本出願の実施形態における方法200、方法300、方法400、方法600、および方法700が上述されている。以下では、本出願の実施形態におけるネットワークデバイスについて説明する。以下に説明されるネットワークデバイスは、方法200、方法300、方法400、方法600、および方法700における第1のネットワークデバイス、第2のネットワークデバイス、または中間ネットワークデバイスの任意の機能を有する。
図9は、本出願の一実施形態によるネットワークデバイス900の構造の概略図である。図9に示されるように、ネットワークデバイス900は、ステップ301、303、307、310、410、402、403、406、408、602、605、607、701、702、705または707を実行するように構成された送信ユニット901と、ステップ302、304、305、308、404、601、603または703を実行するように構成された処理ユニット902と、ステップ306、309、405、407、604、606、704または706を実行するように構成された受信ユニット903と、を含む。
ネットワークデバイス900は、前述の方法の実施形態における第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスに対応することができる。ネットワークデバイス900内のユニットならびに前述の他の動作および／または機能は、方法の実施形態において第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスによって実施されるステップおよび方法を実施するために別々に使用される。具体的な詳細については、方法200、方法300、方法400、方法600、および方法700を参照されたい。簡潔にするため、ここでは詳細は再度説明されない。
ネットワークデバイス900がパケットを処理するとき、前述の機能モジュールの分割は、説明のための例として使用されているにすぎない。実際の適用時には、前述の機能は、要件に従って実装するために異なる機能モジュールに割り当てられてもよい。すなわち、ネットワークデバイス900の内部構造は、上述された機能の全部または一部を実施するために、異なる機能モジュールに分割される。加えて、前述の実施形態で提供されるネットワークデバイス900は、図1または図7に対応する実施形態の方法と同じ概念に属する。その具体的な実施プロセスについては、前述の方法200、方法300、方法400、方法600、および方法700を参照されたい。ここでは詳細は繰り返されない。
本出願において提供される方法の実施形態および仮想装置の実施形態に対応して、本出願の一実施形態は、ネットワークデバイスをさらに提供する。次に、ネットワークデバイスのハードウェア構成について説明する。
以下に説明されるネットワークデバイス1000またはネットワークデバイス1100は、前述の方法の実施形態における第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスに対応し、ネットワークデバイス1000またはネットワークデバイス1100におけるハードウェア、モジュール、および前述の他の動作および／または機能は、方法の実施形態において第1のネットワークデバイスまたは第2のネットワークデバイスによって実施されるステップおよび方法を実施するために別々に使用される。ネットワークデバイス1000またはネットワークデバイス1100がパケットをどのように処理するかの詳細な手順および具体的な詳細については、前述の方法の実施形態を参照されたい。簡潔にするため、ここでは詳細は再度説明されない。前述の方法200、方法300、方法400、方法600、および方法700のステップは、ネットワークデバイス1000またはネットワークデバイス1100のプロセッサ内のハードウェアの集積論理回路を使用することによって、またはソフトウェアの形態の命令を使用することによって完了される。本出願の実施形態を参照して開示された方法におけるステップは、ハードウェアプロセッサによって直接実行および完了されてもよく、またはプロセッサ内のハードウェアとソフトウェアモジュールとの組み合わせを使用して実行および完了されてもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどの当技術の成熟した記憶媒体に位置されてもよい。記憶媒体は、メモリ内に配置され、プロセッサは、メモリ内の情報を読み出し、プロセッサのハードウェアと共に前述の方法におけるステップを完了する。繰り返しを避けるため、ここでは詳細は再度説明されない。
ネットワークデバイス1000またはネットワークデバイス1100は、前述の仮想装置の実施形態におけるネットワークデバイス900に対応し、ネットワークデバイス900内の各機能モジュールは、ネットワークデバイス1000またはネットワークデバイス1100のソフトウェアを使用して実装される。言い換えれば、ネットワークデバイス900に含まれる機能モジュールは、ネットワークデバイス1000のプロセッサまたはネットワークデバイス1100がメモリに格納されたプログラムコードを読み取った後に生成される。
図10は、本出願の一実施形態によるネットワークデバイス1000の構造の概略図である。ネットワークデバイス1000は、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスとして構成されてもよい。ネットワークデバイス1000は、一般的なバスアーキテクチャを使用して実装されてもよい。
ネットワークデバイス1000は、少なくとも1つのプロセッサ1001と、通信バス1002と、メモリ1003と、少なくとも1つの通信インターフェース1004と、を含む。
プロセッサ1001は、汎用CPU、NP、マイクロプロセッサであってもよいし、本出願の解決策を実施するように構成された1つまたは複数の集積回路、例えば、特定用途向け集積回路（application－specific integrated circuit、ASIC）、プログラマブル論理デバイス（programmable logic device、PLD）、またはそれらの組み合わせであってもよい。PLDは、複雑なプログラマブルロジックデバイス（complex programmable logic device、CPLD）、フィールドプログラマブルロジックゲートアレイ（field－programmable gate array、FPGA）、ジェネリックアレイロジック（generic array logic、GAL）、またはそれらの任意の組み合わせであってもよい。
通信バス1002は、前述の構成要素間で情報を送信するように構成される。通信バス1002は、アドレスバス、データバス、制御バスなどに分類されてもよい。表現を容易にするため、図ではバスを表すためにただ1つの太線が使用されているが、これは、ただ1つのバスしかないことを、またはただ1つの種類のバスしかないことを、意味しない。
例えば、メモリ1003は、読取り専用メモリ（read－only memory、ROM）または静的情報および命令を記憶することができる別のタイプの静的記憶デバイスであってもよいし、あるいはランダムアクセスメモリ（random access memory、RAM）または情報および命令を記憶することができる別のタイプの動的記憶デバイスであってもよいし、あるいは電気的消去可能プログラマブル読取り専用メモリ（electrically erasable programmable read－only Memory、EEPROM）、コンパクトディスク読取り専用メモリ（compact disc read－only memory、CD－ROM）または他のコンパクトディスクストレージ、光ディスクストレージ（圧縮光ディスク、レーザディスク、光ディスク、デジタル多用途光ディスク、ブルーレイ光ディスクなどを含む）、磁気ディスク記憶媒体または別の磁気記憶デバイスであってもよいし、あるいは命令またはデータ構造の形態で予想されるプログラムコードを担持もしくは記憶するように構成され得、かつコンピュータによってアクセスされ得る、任意の他の媒体であってもよい。メモリはこれに限定されない。メモリ1003は独立して存在してもよく、通信バス1002を使用してプロセッサ1001に接続される。メモリ1003はプロセッサ1001と、あるいは統合されてもよい。
通信インターフェース1004は、任意のトランシーバタイプの装置を用いて、他のデバイスまたは通信ネットワークと通信を行うように構成される。通信インターフェース1004は、有線通信インターフェースを含み、無線通信インターフェースをさらに含んでもよい。有線通信インターフェースは、例えば、イーサネットインターフェースであってもよい。イーサネットインターフェースは、光インターフェース、電気インターフェース、またはこれらの組み合わせであってもよい。無線通信インターフェースは、無線ローカル・エリア・ネットワーク（wireless local area networks、WLAN）インターフェース、セルラネットワーク通信インターフェース、またはそれらの組み合わせなどであってもよい。
具体的な実装では、一実施形態では、プロセッサ1001は、図10に示されるCPU 0およびCPU 1などの1つまたは複数のCPUを含むことができる。
具体的な実装では、一実施形態では、ネットワークデバイス1000は、図10に示されるプロセッサ1001およびプロセッサ1005などの複数のプロセッサを含むことができる。プロセッサのそれぞれは、シングルコアプロセッサ（single－CPU）であってもよく、またはマルチコアプロセッサ（multi－CPU）であってもよい。本明細書におけるプロセッサは、データ（コンピュータプログラム命令など）を処理するように構成された1つまたは複数のデバイス、回路、および／または処理コアを指してもよい。
いくつかの実施形態では、メモリ1003は、本出願の解決策を実行するためのプログラムコード1010を格納するように構成され、プロセッサ1001は、メモリ1003に格納されたプログラムコード1010を実行することができる。すなわち、ネットワークデバイス1000は、メモリ1003内のプロセッサ1001およびプログラムコード1010を使用することによって、方法の実施形態で提供される方法200、方法300、方法500、または方法600を実施することができる。
本出願のこの実施形態におけるネットワークデバイス1000は、前述の方法の実施形態における第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスに対応することができる。加えて、ネットワークデバイス1000内のプロセッサ1001、通信インターフェース1004などは、第1のネットワークデバイス、中間ネットワークデバイス、もしくは第2のネットワークデバイスの機能、および／または前述の方法の実施形態において第1のネットワークデバイス、中間ネットワークデバイス、もしくは第2のネットワークデバイスによって実施されるステップおよび方法を実施してもよい。簡潔にするために、ここでは詳細が説明されない。
ネットワークデバイス900内の送信ユニット901および受信ユニット903はそれぞれ、ネットワークデバイス1000内の通信インターフェース1004に相当する。ネットワークデバイス900内の処理ユニット902は、ネットワークデバイス1000内のプロセッサ1001と同等であってもよい。
図11は、本出願の一実施形態によるネットワークデバイス1100の構造の概略図である。ネットワークデバイス1100は、方法200、方法300、方法500、または方法600において、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスとして構成されてもよい。ネットワークデバイス1100は、主制御基板1111およびインターフェース基板1130を含む。
主制御基板1111は、主処理ユニット（main processing unit、MPU）またはルート処理カード（route processor card）とも呼ばれる。主制御基板1111は、ルート計算、デバイス管理、デバイスメンテナンス、およびプロトコル処理の機能を含む、ネットワークデバイス1100内の構成要素を制御および管理するように構成される。主制御基板1111は、中央処理装置1111およびメモリ1112を含む。
インターフェース基板1130は、ライン処理ユニット（line processing unit、LPU）、ラインカード（line card）、またはサービス基板とも呼ばれる。インターフェース基板1130は、様々なサービスインターフェースを提供し、データパケットを転送するように構成される。サービスインターフェースは、イーサネットインターフェース、POS（Packet over SONET／SDH）インターフェースなどを含むが、これらに限定されない。イーサネットインターフェースは、例えば、フレキシブル・イーサネット・サービス・インターフェース（Flexible Ethernet Clients、FlexE Clients）である。インターフェース基板1130は、中央処理装置1131と、ネットワークプロセッサ1132と、転送エントリメモリ1134と、物理インターフェースカード（physical interface card、PIC）1133と、を含む。
インターフェース基板1130上の中央処理装置1131は、インターフェース基板1130を制御および管理し、主制御基板1111上の中央処理装置1111と通信するように構成される。
ネットワークプロセッサ1132は、パケット転送処理を実施するように構成される。ネットワークプロセッサ1132の形態は、転送チップであってもよい。具体的には、ネットワークプロセッサ1132は、転送エントリメモリ1134に記憶された転送テーブルに基づいて、受信したパケットを転送するように構成される。パケットの宛先アドレスがネットワークデバイス1100のアドレスである場合には、ネットワークプロセッサは、処理のためにパケットをCPU（例えば、中央処理装置1111）に送信する。パケットの宛先アドレスがネットワークデバイス1100のアドレスでない場合には、ネットワークプロセッサは、宛先アドレスに基づいて、宛先アドレスに対応するネクストホップおよびアウトバウンドインターフェースを求めて転送テーブルを探索し、宛先アドレスに対応するアウトバウンドインターフェースにパケットを転送する。アップリンクパケットの処理は、パケット着信インターフェースの処理および転送テーブル検索を含む。ダウンリンクパケットの処理は、転送テーブル検索などを含む。
物理インターフェースカード1133は、物理層相互接続機能を実現するように構成される。元のトラフィックは、物理インターフェースカードからインターフェース基板1130に入り、処理されたパケットは、物理インターフェースカード1133から送信される。物理インターフェースカード1133は、サブカードとも呼ばれ、インターフェース基板1130にインストールされてもよく、光電子信号をパケットに変換し、パケットの有効性チェックを実行し、次いでパケットを処理のためにネットワークプロセッサ1132に転送するように構成される。いくつかの実施形態では、中央処理装置はまた、ネットワークプロセッサ1132の機能を実行してもよく、例えば、汎用CPUに基づいてソフトウェア転送を実施してもよい。したがって、物理インターフェースカード1133には、ネットワークプロセッサ1132は不要である。
任意選択で、ネットワークデバイス1100は複数のインターフェース基板を含む。例えば、ネットワークデバイス1100は、インターフェース基板1140をさらに含む。インターフェース基板1140は、中央処理装置1141と、ネットワークプロセッサ1142と、転送エントリメモリ1144と、物理インターフェースカード1143と、を含む。
任意選択で、ネットワークデバイス1100は、スイッチング基板1120をさらに含む。スイッチング基板1120は、スイッチ・ファブリック・ユニット（switch fabric unit、SFU）と呼ばれることもある。ネットワークデバイスが複数のインターフェース基板1130を有する場合、スイッチング基板1120は、インターフェース基板間のデータ交換を完了するように構成される。例えば、インターフェース基板1130とインターフェース基板1140とは、スイッチング基板1120を用いて通信を行ってもよい。
主制御基板1111は、インターフェース基板1130に結合されている。例えば、主制御基板1111、インターフェース基板1130およびインターフェース基板1140、ならびにスイッチング基板1120は、インターワーキングのためのシステムバスを使用してシステムバックボードに接続される。可能な実施態様では、主制御基板1111とインターフェース基板1130との間にプロセス間通信プロトコル（inter－process communication、IPC）チャネルが確立され、主制御基板1111とインターフェース基板1130とはIPCチャネルを介して互いに通信する。
論理的には、ネットワークデバイス1100は、制御プレーンおよび転送プレーンを含む。制御プレーンは、主制御基板1111および中央処理装置1131を含む。転送プレーンは、転送エントリメモリ1134、物理インターフェースカード1133、およびネットワークプロセッサ1132などの転送を実行する構成要素を含む。制御プレーンは、ルーティング、転送テーブルの生成、シグナリングおよびプロトコルパケットの処理、ならびにデバイス状況の構成および維持などの機能を実行する。制御プレーンは、生成された転送テーブルを転送プレーンに配信する。転送プレーンにおいて、ネットワークプロセッサ1132は、物理インターフェースカード1133によって受信されたパケットを転送するために、制御プレーンによって配信された転送テーブルを検索する。制御プレーンによって配信される転送テーブルは、転送エントリメモリ1134に記憶されてもよい。いくつかの実施形態では、制御プレーンと転送プレーンとは完全に分離されてもよく、同じデバイス上にはない。
ネットワークデバイス1100が第1のネットワークデバイスとして構成されている場合には、ネットワークプロセッサ1132が第1のパケットを生成し、物理インターフェースカード1133から第1のパケットを送信することができ、その結果、第1のパケットが第2のネットワークデバイスに送信される。
ネットワークデバイス1100が第2のネットワークデバイスとして構成されている場合には、物理インターフェースカード1133は第1のパケットを受信し、第1のパケットをネットワークプロセッサ1132へ送信する。ネットワークプロセッサ1132は、第1のパケットから、第1のネットワークデバイスのiFIT能力のサポート状況を取得する。
ネットワークデバイス900内の送信ユニット901および受信ユニット903はそれぞれ、ネットワークデバイス1100内の物理インターフェースカード1133と同等であってもよい。ネットワークデバイス900内の処理ユニット902は、ネットワークプロセッサ1132または中央処理装置1111と同等であってもよい。
インターフェース基板1140上で実行される動作は、本出願のこの実施形態においてインターフェース基板1130上で実行される動作と一致する。簡潔にするため、詳細は説明されない。本実施形態におけるネットワークデバイス1100は、前述の方法の実施形態における第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスに対応することができる。ネットワークデバイス1100内の主制御基板1111、インターフェース基板1130、および／またはインターフェース基板1140は、第1のネットワークデバイス、中間ネットワークデバイス、もしくは第2のネットワークデバイスの機能、および／または前述の方法の実施形態において第1のネットワークデバイス、中間ネットワークデバイス、もしくは第2のネットワークデバイスによって実施されるステップを実施してもよい。簡潔にするため、ここでは詳細は再度説明されない。
1つまたは複数の主制御基板が存在してもよいことに留意されたい。複数の主制御基板が存在する場合、主制御基板は、一次主制御基板および二次主制御基板を含んでもよい。1つまたは複数のインターフェース基板があってもよく、より強力なデータ処理能力を有するネットワークデバイスは、より多くのインターフェース基板を提供する。インターフェース基板上には1つまたは複数の物理インターフェースカードがあってもよい。スイッチング基板はなくてもよく、1つまたは複数のスイッチング基板があってもよい。複数のスイッチング基板が存在するとき、負荷分散および冗長バックアップが一緒に実施されてもよい。集中転送アーキテクチャでは、ネットワークデバイスはスイッチング基板を必要としない場合があり、インターフェース基板はシステム全体のサービスデータを処理する機能を提供する。分散転送アーキテクチャでは、ネットワークデバイスは少なくとも1つのスイッチング基板を有することができ、大容量データ交換および処理能力を提供するために、複数のインターフェース基板間のデータ交換はスイッチング基板を使用して実施される。したがって、分散アーキテクチャにおけるネットワークデバイスのデータアクセスおよび処理能力は、集中アーキテクチャにおけるデバイスのデータアクセスおよび処理能力よりも優れている。任意選択で、ネットワークデバイスは、代替として、カードが1つしかない形態であってもよい。具体的には、スイッチング基板はなく、インターフェース基板および主制御基板の機能がカード上に統合される。この場合、インターフェース基板上の中央処理装置および主制御基板上の中央処理装置は、2つの中央処理装置を組み合わせた機能を実行するために、カード上の1つの中央処理装置に組み合わされてもよい。この形態のデバイス（例えば、ローエンドスイッチまたはルータなどのネットワークデバイス）は、弱いデータ交換および処理能力を有する。使用される特定のアーキテクチャは、特定のネットワーキング展開シナリオに依存する。これはここでは限定されない。
いくつかの可能な実施形態では、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、仮想化デバイスとして実装されてもよい。
例えば、仮想化されたデバイスは、パケット送信機能を有するプログラムが実行される仮想マシン（英語：Virtual Machine、VM）であってよく、仮想マシンはハードウェアデバイス（例えば、物理サーバ）上に展開される。仮想マシンは、ソフトウェアによってシミュレートされた完全なコンピュータシステムであり、完全なハードウェアシステム機能を有し、完全に隔離された環境で動作する。仮想マシンは、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスとして構成されてもよい。例えば、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、ネットワーク機能仮想化（Network Functions Virtualization、NFV）技術と組み合わせた汎用物理サーバに基づいて実装されてもよい。第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、仮想ホスト、仮想ルータ、または仮想スイッチである。本出願を読んだ後に、NFV技術を参照して、当業者は、汎用物理サーバ上で、第1のネットワークデバイス、中間ネットワークデバイス、または前述の機能を有する第2のネットワークデバイスを仮想化することができる。ここでは詳細は繰り返されない。
例えば、仮想化デバイスはコンテナであってもよく、コンテナは、分離された仮想化環境を提供するように構成されたエンティティである。例えば、コンテナはdockerコンテナであってもよい。コンテナは、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスとして構成されてもよい。例えば、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、対応するイメージを使用して作成されてもよい。例えば、proxy－container（プロキシサービスを提供するコンテナ）のイメージを使用することによって、proxy－containerに対して2つのコンテナインスタンス、すなわち、コンテナ・インスタンスproxy－container1およびコンテナ・インスタンスproxy－container2が作成され得る。コンテナ・インスタンスproxy－container1は、第1のネットワークデバイスまたは第1のコンピューティングデバイスとして提供される。コンテナ・インスタンスproxy－container2は、第2のネットワークデバイスまたは第2のコンピューティングデバイスとして提供される。コンテナ技術が実装に使用される場合、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、物理マシンのカーネルを使用して実行することができ、複数の第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、物理マシンのオペレーティングシステムを共有することができる。異なる第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、コンテナ技術を使用することによって互いに分離されてもよい。コンテナ化された第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、仮想化環境で実行することができ、例えば、仮想マシンで実行することができる。あるいは、コンテナ化された第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、物理マシン内で直接動作してもよい。
例えば、仮想化デバイスはPodであってもよい。Podは、コンテナ化されたアプリケーションを展開し、管理し、編成するためのKubernetesの基本ユニットである（Kubernetesは、グーグルのオープンソースコンテナ編成エンジンであり、英語では簡単にK8と呼ばれる）。Podは、1つまたは複数のコンテナを含んでもよい。同じPod内のすべてのコンテナは、同じホスト上に通常、展開される。したがって、同じPod内のすべてのコンテナは、ホストを介して互いに通信することができ、ホストのストレージリソースおよびネットワークリソースを共有することができる。Podは、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスとして構成されてもよい。例えば、具体的には、サービスとしてのコンテナ（英語正式名：container as a service、略してCaaS、コンテナベースのPaaSサービス）は、Podを作成するように指示され得、Podは、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスとして提供される。
もちろん、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、代替的に、本明細書に1つずつ列挙されていない別の仮想化デバイスであってもよい。
いくつかの可能な実施形態では、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスは、汎用プロセッサによって代替的に実装されてもよい。例えば、汎用プロセッサはチップの形態であってもよい。具体的には、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスを実装する汎用プロセッサは、処理回路と、処理回路に内部的に接続され、処理回路と通信する入力インターフェースおよび出力インターフェースとを含む。処理回路は、入力インターフェースを使用することによって、前述の方法の実施形態におけるパケット生成ステップを実行するように構成される。処理回路は、入力インターフェースを使用することによって、前述の方法の実施形態における受信ステップを実行するように構成される。処理回路は、出力インターフェースを使用することによって、前述の方法の実施形態における送信ステップを実行するように構成される。任意選択で、汎用プロセッサは記憶媒体をさらに含んでもよい。処理回路は、記憶媒体を使用することによって前述の方法の実施形態における記憶ステップを実行するように構成される。記憶媒体は、処理回路によって実行される命令を記憶することができる。処理回路は、前述の方法の実施形態を実行するために、記憶媒体に記憶された命令を実行するように構成される。
図12を参照されたい。本出願の一実施形態は、ネットワークシステム1200を提供する。ネットワークシステム1200は、第1のネットワークデバイス1201と、中間ネットワークデバイス1202と、第2のネットワークデバイス1203と、を含む。任意選択で、第1のネットワークデバイス1201は、ネットワークデバイス900、ネットワークデバイス1000、またはネットワークデバイス1100であり、中間ネットワークデバイス1202は、ネットワークデバイス900、ネットワークデバイス1000、またはネットワークデバイス1100であり、第2のネットワークデバイス1203は、ネットワークデバイス900、ネットワークデバイス1000、またはネットワークデバイス1100である。
図13を参照されたい。本出願の一実施形態は、ネットワークシステム1300を提供する。ネットワークシステム1300は、第1のネットワークデバイス1301と、第1の中間ネットワークデバイス1302と、第2の中間ネットワークデバイス1303と、第2のネットワークデバイス1304と、を含む。第1のネットワークデバイス1301、第1の中間ネットワークデバイス1302、第2の中間ネットワークデバイス1303、および第2のネットワークデバイス1304はそれぞれ、例えばルータ、スイッチ、もしくはゲートウェイなどの物理デバイスであってもよく、またはルート発行およびパケット転送をサポートする仮想デバイスであってもよい。この実施形態では、第1のネットワークデバイスおよび第2のネットワークデバイスの具体的な種類は限定されない。
例えば、ネットワークシステム1300が図1に示されるシナリオに適用される場合、第1のネットワークデバイス1301は、例えば、図1に示されるメトロポリタン・エリア・ネットワークに位置されるPEデバイスであってもよく、第1の中間ネットワークデバイス1302は、例えば、図1に示されるネットワークデバイスAであってもよく、第2の中間ネットワークデバイス1303は、例えば、図1に示されるネットワークデバイスAであってもよく、第2のネットワークデバイス1304は、例えば、図1に示されるバックボーンネットワークに位置されるクラウドPE 1デバイスであってもよい。
任意選択で、第2の中間ネットワークデバイス1303および第2のネットワークデバイス1304は同じIGPドメインに属し、第1のネットワークデバイス1301および第1の中間ネットワークデバイス1302は同じIGPドメインに属し、第1のネットワークデバイス1301および第2のネットワークデバイス1304は異なるIGPドメインに属する。
第1の中間ネットワークデバイス1302は第1のトラフィック・エンジニアリング・トンネルおよび第2のトラフィック・エンジニアリング・トンネルを取得し、第1のトラフィック・エンジニアリング・トンネルは第1のサブネットプレフィックスを含み、第2のトラフィック・エンジニアリング・トンネルは第2のサブネットプレフィックスを含む。第1のトラフィック・エンジニアリング・トンネルおよび第2のトラフィック・エンジニアリング・トンネルは、コントローラまたは別の経路計算デバイスによって第1の中間ネットワークデバイス1302に送信されてもよい。
第1の中間ネットワークデバイス1302は第2の中間ネットワークデバイス1303へ第1のルート告知パケットを発行し、第1のルート告知パケットは第3のサブネットプレフィックスを含み、第1の中間ネットワークデバイス1302は第1のサブネットプレフィックスと第2のサブネットプレフィックスとを集約することによって第3のサブネットプレフィックスを取得する。第1のトラフィック・エンジニアリング・トンネルおよび第2のトラフィック・エンジニアリング・トンネルを取得した後で、第1の中間ネットワークデバイス1302は、第1のサブネットプレフィックスおよび第2のサブネットプレフィックスを集約して、アグリゲーション・ネットワーク・セグメント、すなわち、第3のサブネットプレフィックスを取得し、アグリゲーション・ネットワーク・セグメントを第2の中間ネットワークデバイス1303に告知することができる。
一例では、第2の中間ネットワークデバイス1303は、第3のサブネットプレフィックスに対応する経路計算要件に基づいて、第1のネットワークスライス識別子を取得することができる。第1のネットワークスライス識別子は、第3のサブネットプレフィックスに対応する経路計算要件を満たす経路を計算するために使用されてもよく、第1のネットワークスライス識別子は、例えば、FlexAlgo IDであってもよい。加えて、第2の中間ネットワークデバイス1303は、対応する第1のSIDを第1のネットワークスライス識別子に割り当ててもよい。第1のSIDは、例えば、END SIDであってもよい。第2の中間ネットワークデバイス1303が、第3のサブネットプレフィックスを第1のSIDと関連付け、第2のルート告知パケットを発行することができ、その結果、第2のネットワークデバイス1304が第2のルート告知パケットを受信することができる。第2のルート告知パケットは、第3のサブネットプレフィックス、第1のSID、および第1のネットワークスライス識別子を含み、第1のSIDは第1のネットワークスライス識別子に対応する。別の例では、第2の中間ネットワークデバイス1303は、第3のサブネットプレフィックスを少なくとも1つのネットワークスライスに導入することができ、少なくとも1つのネットワークスライスは、第1のネットワークスライスおよび第2のネットワークスライスを含む。第2の中間ネットワークデバイス1303は第3のルート告知パケットを発行し、第3のルート告知パケットは第3のサブネットプレフィックスおよび第2のネットワークスライスの識別子を含む。第2のネットワークデバイス1304は、第3のルート告知パケットを取得し、第2のネットワークスライスの識別子に基づいて第3のサブネットプレフィックスの対応する出口を決定することができる。言い換えると、第2のネットワークデバイス1304について、第2のネットワークデバイス1304は第2の中間ネットワークデバイス1303によって発行された異なるルート告知パケットを受信することができ、異なるルート告知パケットは同じサブネットプレフィックスおよび異なるネットワークスライス識別子を含む。第2のネットワークデバイス1304は、対応する出口を決定するために、取得されたパケットの転送要件に基づいて異なるネットワークスライス識別子を選択することができ、その結果、パケットの転送経路が要件、例えば低レイテンシ要件または高帯域幅要件を満たすことができる。
ネットワークデバイスは、トラフィック・エンジニアリング・トンネルによって指定された宛先識別子のみではなく任意のルートを1つまたは複数のネットワークスライスに導入し、IGPプロトコルに従ってルートを発行することができる。発行されたルートは、1つまたは複数のネットワークスライスの識別子を搬送してもよく、またはルートは、1つまたは複数のネットワークスライスと経路識別子との間の対応関係のリストを搬送してもよい。導入されたルートは、ネットワークスライス範囲外のネットワークデバイスのルートであってもよい。このようにして、ネットワークスライスは、導入されたルートに対応するルートプレフィックスを使用してトラバースされ得る。あるいは、導入されたルートは、IGPドメイン内のネットワークデバイスのインターフェースアドレスであってもよい。このようにして、インターフェースアドレスにアクセスするためのトラフィックもまた、ネットワークスライスに基づいてドメイン内で転送され得る。
第2の中間ネットワークデバイス1303は第2のネットワークデバイス1304によって送信された第1のパケットを受信し、第1のパケットの宛先アドレスと第3のサブネットプレフィックスとの間には最長一致がある。
一例では、第1のパケットは第1のSIDをさらに含んでもよく、第2の中間ネットワークデバイス1303は第1のパケット内の第1のSIDに基づいて対応する第3のサブネットプレフィックスを決定してもよい。
別の例では、第1のパケットのホップバイホップヘッダは、第2のネットワークスライスの識別子を搬送する。第2のネットワークスライスの識別子は第1のパケットのホップバイホップヘッダで搬送されるので、その結果、第2のネットワークデバイス1304と第2の中間ネットワークデバイス1303との間のネットワークデバイスは、第1のパケットを転送するために第2のネットワークスライスの識別子に基づいて対応する出口を選択することができる。すなわち、第1のパケットは第2のネットワークスライスで送信され得る。
第2の中間ネットワークデバイス1303は第1のパケットに基づいて第2のパケットを取得し、第2のパケットを第1の中間ネットワークデバイス1302に送信する。任意選択で、第1のパケットが第1のSIDを含んでもよく、第2の中間ネットワークデバイスが、第1のSIDに対応する第1のネットワークスライス識別子に基づいて対応する出口を決定してもよい。あるいは、第1のパケットのホップバイホップヘッダが第2のネットワークスライスの識別子を搬送し、第2の中間ネットワークデバイス1303が第2のネットワークスライスの識別子に基づいて対応する出口を決定してもよい。
本出願の一実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品が第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイス上で動作すると、第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスが、前述の方法の実施形態における方法200、方法300、方法400、方法600、および方法700を実行することを可能にされる。
前述の製品形態のネットワークデバイスは、前述の方法の実施形態における第1のネットワークデバイス、中間ネットワークデバイス、または第2のネットワークデバイスの任意の機能を別々に有する。ここでは詳細は繰り返されない。
当業者は、本明細書に開示した実施形態を参照して説明された方法ステップおよびユニットが、電子ハードウェア、コンピュータソフトウェア、またはそれらの組み合わせによって実施され得ることを認識することができる。ハードウェアとソフトウェアとの間の互換性を明確に説明するために、上記では、機能に基づいて各実施形態のステップおよび構成を概して説明した。機能がハードウェアによって実行されるのかソフトウェアによって実行されるのかは技術的解決策の具体的な用途および設計制約条件に依存する。当業者であれば、具体的な用途ごとに様々な方法を用いて、説明されている機能を実装することができるが、その実装が本出願の範囲を超えるとみなされるべきではない。
簡便で、簡単な説明のために、前述のシステム、装置およびユニットの詳細な動作プロセスについては、前述の方法の実施形態の対応するプロセスを参照されたく、ここでは詳細は再び説明されないことが、当業者によって明確に理解されよう。
本出願で提供されるいくつかの実施形態では、開示されたシステム、装置、および方法は、別の方式で実装されてもよいことを理解されたい。例えば、説明されている装置の実施形態は単なる例である。例えば、ユニットに分割することは、単なる論理的機能分割であって、実際の実装時には他の分割であってもよい。例えば、複数のユニットまたは構成要素が、別のシステムと組み合わせられるか、またはこれと一体化されてもよく、あるいはいくつかの特徴は、無視されるかまたは実行されなくてもよい。さらに、表示または説明された相互結合または直接結合または通信接続は、いくつかのインターフェースを使用して実装されてもよい。装置またはユニット間の間接的な結合または通信接続は、電子的、機械的、または他の形態で実装されてもよい。
別々の構成要素として記載されたユニットは、物理的に別々であってもなくてもよく、ユニットとして表示された構成要素は、物理的ユニットであってもなくてもよく、言い換えれば、1つの位置に配置されてもよいし、または複数のネットワークユニット上に分散されてもよい。ユニットの一部または全部は、実施形態における解決策の目的を達成するための実際の要件に基づいて選択されてもよい。
これに加えて、本出願の実施形態の機能ユニットが1つの処理ユニットに統合されてもよいし、ユニットのそれぞれが物理的に単独で存在してもよいし、2つ以上のユニットが1つのユニットに統合される。統合ユニットは、ハードウェアの形態で実装されてもよく、またはソフトウェア機能ユニットの形態で実装されてもよい。
統合ユニットが、ソフトウェア機能ユニットの形態で実施され、独立した製品として販売または使用される場合、統合ユニットは、コンピュータ可読記憶媒体に格納されてもよい。そのような理解に基づき、本出願の技術的解決策が本質的に、または従来技術に寄与する部分が、または技術的解決策の全部もしくは一部が、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体に記憶され、本出願の実施形態における方法のステップの全部または一部を実行するようにコンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワークデバイスなどであってもよい）に命令するためのいくつかの命令を含む。前述の記憶媒体は、例えば、USBフラッシュドライブ、リムーバブルハードディスク、読取り専用メモリ、ランダムアクセスメモリ、磁気ディスク、または光ディスクなどの、プログラムコードを格納することができる任意の媒体を含む。
200 データ処理方法
300 データ処理方法
400 データ処理方法
600 データ処理方法
700 データ処理方法
900 ネットワークデバイス
901 送信ユニット
902 処理ユニット
903 受信ユニット
1000 ネットワークデバイス
1001 プロセッサ
1002 通信バス
1003 メモリ
1004 通信インターフェース
1005 プロセッサ
1010 プログラムコード
1100 ネットワークデバイス
1111 主制御基板、中央処理装置
1112 メモリ
1120 スイッチング基板
1130 インターフェース基板
1131 中央処理装置
1132 ネットワークプロセッサ
1133 物理インターフェースカード
1134 転送エントリメモリ
1140 インターフェース基板
1141 中央処理装置
1142 ネットワークプロセッサ
1143 物理インターフェースカード
1144 転送エントリメモリ
1200 ネットワークシステム
1201 第1のネットワークデバイス
1202 中間ネットワークデバイス
1203 第2のネットワークデバイス
1300 ネットワークシステム
1301 第1のネットワークデバイス
1302 第1の中間ネットワークデバイス
1303 第2の中間ネットワークデバイス
1304 第2のネットワークデバイス

Claims (8)

  1. データ処理方法であって、
    第1のネットワークデバイスにより、第1のサブネットプレフィックスを取得するステップであって、前記第1のサブネットプレフィックスがトラフィック・エンジニアリング・トンネルの宛先識別子である、ステップと、
    前記第1のネットワークデバイスにより、前記第1のサブネットプレフィックスに基づいてデータ処理を実行するステップと
    を含み、
    前記第1のネットワークデバイスにより、前記第1のサブネットプレフィックスに基づいてデータ処理を実行する前記ステップが、
    前記第1のネットワークデバイスにより、第1のパケットを取得するステップと、
    第1のアドレスと前記第1のサブネットプレフィックスとの間に最長一致がある場合に、前記第1のネットワークデバイスにより、前記トラフィック・エンジニアリング・トンネルを介して前記第1のパケットを送信するステップであって、前記第1のアドレスが前記第1のパケットの宛先アドレスに基づいて取得される、ステップと
    を含む、データ処理方法。
  2. 前記第1のアドレスは、前記第1のパケットの前記宛先アドレス、または前記宛先アドレスに基づいて前記第1のネットワークデバイスによって決定されたネクストホップ転送アドレスを含む、請求項1に記載の方法。
  3. 前記第1のネットワークデバイスにより、前記第1のサブネットプレフィックスに基づいてデータ処理を実行する前記ステップが、
    前記第1のネットワークデバイスにより、前記第1のサブネットプレフィックスに基づいて第1のルーティングパケットを告知するステップであって、前記第1のルーティングパケットが第2のサブネットプレフィックスを含み、前記第2のサブネットプレフィックスの範囲が前記第1のサブネットプレフィックスの範囲を含む、ステップ
    を含む、請求項1または2に記載の方法。
  4. 前記第1のルーティングパケットが、内部ゲートウェイプロトコル、IGP、パケットを含む、請求項3に記載の方法。
  5. 前記トラフィック・エンジニアリング・トンネルが、セグメント・ルーティング・ポリシー、SR、Policyトンネルまたはセグメント・ルーティング・トラフィック・エンジニアリング、SR TE、トンネルを含む、請求項1または2に記載の方法。
  6. プロセッサおよび通信インターフェースを含むネットワークデバイスであって、前記プロセッサが命令を実行するように構成され、その結果、前記ネットワークデバイスが請求項1から5のいずれか一項に記載の方法を実行する、ネットワークデバイス。
  7. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体がソフトウェアプログラムを記憶し、前記ソフトウェアプログラムが1つまたは複数のプロセッサによって読み取られ実行されて、請求項1から5のいずれか一項に記載の方法を実施する、コンピュータ可読記憶媒体。
  8. プログラムであって、前記プログラムが通信デバイスによって実行されると、前記通信デバイスが、請求項1から5のいずれか一項に記載の通信方法を実行することが可能になる、プログラム。
JP2023503020A 2020-07-17 2021-07-19 ネットワーク内のトラフィック・エンジニアリング・トンネルの数を削減するためのデータ処理方法、装置、媒体、およびコンピュータプログラム Active JP7536993B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
CN202010692883.2 2020-07-17
CN202010692883 2020-07-17
CN202011248687.2 2020-11-10
CN202011248687 2020-11-10
CN202011256894.2A CN114024900A (zh) 2020-07-17 2020-11-11 一种数据处理方法及相关设备
CN202011256894.2 2020-11-11
PCT/CN2021/107168 WO2022012690A1 (zh) 2020-07-17 2021-07-19 一种路由通告方法及相关设备

Publications (2)

Publication Number Publication Date
JP2023534050A JP2023534050A (ja) 2023-08-07
JP7536993B2 true JP7536993B2 (ja) 2024-08-20

Family

ID=79554484

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023503020A Active JP7536993B2 (ja) 2020-07-17 2021-07-19 ネットワーク内のトラフィック・エンジニアリング・トンネルの数を削減するためのデータ処理方法、装置、媒体、およびコンピュータプログラム

Country Status (5)

Country Link
US (1) US20230155938A1 (ja)
EP (1) EP4175252A4 (ja)
JP (1) JP7536993B2 (ja)
KR (1) KR20230035673A (ja)
WO (1) WO2022012690A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022012689A1 (zh) * 2020-07-17 2022-01-20 华为技术有限公司 一种路由通告方法及相关设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004266822A (ja) 2003-02-10 2004-09-24 Matsushita Electric Works Ltd トンネル自動設定装置及びトンネル自動設定方法
CN108259341A (zh) 2017-12-06 2018-07-06 新华三技术有限公司 一种前缀标签分配方法和sdn控制器
WO2020063500A1 (zh) 2018-09-29 2020-04-02 华为技术有限公司 获取SRv6隧道信息的方法、设备和系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102025613B (zh) * 2010-11-11 2012-12-12 福建星网锐捷网络有限公司 隧道建立方法、装置及网络设备
CN107770063A (zh) * 2016-08-17 2018-03-06 中兴通讯股份有限公司 报文转发方法及装置
US10469367B2 (en) * 2017-10-04 2019-11-05 Cisco Technology, Inc. Segment routing network processing of packets including operations signaling and processing of packets in manners providing processing and/or memory efficiencies
CN110661711B (zh) * 2018-06-29 2021-01-29 华为技术有限公司 生成标签转发表的方法、报文发送方法、装置及设备
CN113411243B (zh) * 2018-10-23 2024-03-19 华为技术有限公司 数据传输方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004266822A (ja) 2003-02-10 2004-09-24 Matsushita Electric Works Ltd トンネル自動設定装置及びトンネル自動設定方法
CN108259341A (zh) 2017-12-06 2018-07-06 新华三技术有限公司 一种前缀标签分配方法和sdn控制器
WO2020063500A1 (zh) 2018-09-29 2020-04-02 华为技术有限公司 获取SRv6隧道信息的方法、设备和系统

Also Published As

Publication number Publication date
EP4175252A1 (en) 2023-05-03
WO2022012690A1 (zh) 2022-01-20
US20230155938A1 (en) 2023-05-18
KR20230035673A (ko) 2023-03-14
JP2023534050A (ja) 2023-08-07
EP4175252A4 (en) 2023-11-22

Similar Documents

Publication Publication Date Title
US11283707B2 (en) Segment routing with fast reroute for container networking
CN109921990B (zh) 多线程路由处理
JP7547606B2 (ja) ルート告知方法および関連デバイス
US20130010797A1 (en) Custom routing decisions
US20220263751A1 (en) Packet Processing Method, Apparatus, and System
CN112468398B (zh) 一种vpn的处理方法和pe设备以及系统
WO2022166465A1 (zh) 一种报文处理方法及相关装置
CN114024900A (zh) 一种数据处理方法及相关设备
US20230327986A1 (en) Route Advertisement Method, Apparatus, and System
WO2023274083A1 (zh) 路由发布和转发报文的方法、装置、设备和存储介质
WO2022048418A1 (zh) 一种转发报文的方法、设备和系统
WO2022007702A1 (zh) 一种报文处理方法及网络设备
US20230155938A1 (en) Route Advertisement Method and Related Device
JP7278349B2 (ja) 経路処理方法およびネットワーク装置
WO2022088685A1 (zh) 一种语义名称获取方法、装置、设备及存储介质
WO2024007762A1 (zh) 一种路由发布方法、通信方法及装置
JP2024500907A (ja) ルート伝送方法および装置

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230224

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230224

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240311

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240611

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240708

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240807

R150 Certificate of patent or registration of utility model

Ref document number: 7536993

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150