Method and apparatus for exchanging routing information and establishing connectivity across multiple network areas
Abstract
The method ensures that the multicast packet follows the same loop-free path that is followed by the unicast packet in the packet communication network. The communication network includes at least one first area, the first area being interconnected to the second area through at least one area border node (ABN). Each ABN has a first level port connected to each first area and a second level port connected to a second area. Each multicast packet forwarded contains a header with a route ID that identifies the route in the multicast tree. Data packets are received on the ABN. In response to receiving the multicast packet on the second level port of the area border node, the root ID of the multicast packet is checked and if the multicast packet is forwarded across at least one of the first level ports. If it should, a different route ID is replaced in the packet before the packet is forwarded across the first level port.

Term
Projected expiry 6 October 2030.
- Priority
- Filed
- Published
- Today
- Projected expiry
20 claims: 5 independent, 15 dependent
- 1マルチキャストパケットが、パケット通信ネットワークにおいて、ユニキャストパケットによってフォローされるパスと同じループフリーなパスをフォローすることを確保する方法であって、前記パケット通信ネットワークは、第1レベルで定義される少なくとも1つの第1エリアを含み、各第1エリアは、第1リンクセットによって相互接続される第1複数ノードを含み、各第1エリアは、少なくとも1つのエリアボーダーノードを通して、第2レベルによって定義される第2エリアに相互接続され、前記第2エリアは、第2リンクセットによって相互接続される第2複数ノードを含み、各エリアボーダーノードは、少なくとも1つの第1エリアに接続される少なくとも1つの第1レベルポートと前記第2エリアに接続される第2レベルポートとを有し、前記ループフリーなパスを超えてフォワードされる各マルチキャストパケットは、マルチキャストツリーのルートを特定するルートIDを有するヘッダーを含む方法であって:エリアボーダーノードで少なくとも1つのデータパケットを受信するステップ;及び、 エリアボーダーノードの第2レベルポートでマルチキャストパケットを受信することに応答して: 前記マルチキャストパケットのルートIDを検査するステップ;前記マルチキャストパケットが、エリアボーダーノードの第1レベルポートの少なくとも1つの上にフォワードされるべきかを決定するステップ;及び、 前記マルチキャストパケットが、第1レベルポートの少なくとも1つで、フォワードオーバーされるべきかの決定に応答して、前記パケットを少なくとも1つの第1レベルポートを越えてフォワードする前に、異なるルートIDを前記パケットの中に置換するステップ、 を含む、方法。
- 2前記パケット通信ネットワークはイーサーネットネットワークである、請求項1記載の方法。
- 3少なくとも1つの第1エリアは、1つ以上のエリアボーダーノードによってサービスされ、少なくとも1つの第1エリアをサブセットのグループに分割するステップを更に含み、前記サブセットのグループは、前記第1エリアをサービスするエリアボーダーノードの総数に等しいサブセットの総数を含み、各サブセットは、所定のエリアボーダーノードに関連する、請求項1記載の方法。
- 4各サブセットは、関連するエリアボーダーノードへの最短パスを有するノードを含む、前記請求項3記載の方法。
- 5前記少なくとも1つの第1エリアをサブセットのグループに分割するステップは、 各エリアボーダーノードが、第2エリアを表す疑似ノードへのリンクのためのアドバタイズメントを作り出すステップであって、前記アドバタイズメントは、関連する第1エリアの最大の論理直径の半分よりも大きい関連するメトリックを含む、ステップ;及び、 前記アドバタイズメントを関連する第1データに伝送するステップ、 を含む、前記請求項3記載の方法。
- 6各サブセットに固有の識別子を割り当てるステップを更に含む、前記請求項5記載の方法。
- 7サブセットの固有の識別子は、前記アドバタイズメントにルートIDとして含まれる、前記請求項6記載の方法。
- 8前記少なくとも1つの受信されたデータパケットは、第1レベルポートで受信したマルチキャストパケットであり、前記少なくとも1つの受信されたデータパケットは、ルートIDを含み、 前記ルートIDが、受信エリアボーダーノードに関連するサブセットの範囲内で、ノードを特定することを決定するステップ、 前記ルートIDを、前記受信エリアボーダーノードに関連する前記サブセットの固有の識別子に置き換えるステップ、及び、 前記少なくとも1つのデータパケットを、前記第2レベルポートを通してフォワードするステップ、 を含む、前記請求項7記載の方法。
- 9前記マルチキャストパケットが少なくとも1つの第1レベルポートを越えてフォワードされるべきであるとの決定に応答して、 前記ルートIDが、第1エリア内で、受信エリアボーダーノードによって供される他のサブセットを特定しているとの決定に応答して、少なくとも1つの受信データパケットをドロップするステップ、並びに、 前記ルートIDが、第1エリア内で、受信エリアボーダーノードによって供される他のサブセットを特定していないとの決定に応答して、 前記ルートIDを異なるルートIDに置き換えるステップ、及び、 少なくとも1つのデータパケットを、受信エリアボーダーノードに関連するサブセットを通じてフォワードするステップ、 をさらに含む、前記請求項3記載の方法。
- 10前記少なくとも1つの受信データパケットは、単一の目的地アドレスを含むユニキャストパケットであって、前記目的地アドレスは、受信エリアボーダーノードのサブセットに関連しない第1エリア内で、ノードを特定し、 第1レベルポート上で少なくとも1つのデータパケットを受信することに応答して、前記少なくとも1つのデータパケットを、異なる第1レベルポートを通してフォワードするステップ、及び、 第1レベルポート上で少なくとも1つのデータパケットを受信することに応答して、前記少なくとも1つのデータパケットを、第2レベルポートを通して他のエリアボーダーノードへフォワードするステップ、 を含む、前記請求項3記載の方法。
- 11パケット通信ネットワークで使用するためのエリアボーダーノードであって、前記パケット通信ネットワークは、第1レベルで定義される少なくとも1つの第1エリアを含み、各第1エリアは、第1リンクセットによって相互接続される第1複数ノードを含み、各第1エリアは、少なくとも1つのエリアボーダーノードを通して、第2レベルで定義される第2エリアに相互接続され、 前記エリアボーダーノードは、 各第1エリアに接続される少なくとも1つの第1レベルポートであって、当該少なくとも1つの第1レベルポートは、データパケットを対応する第1エリアから受信し、データパケットをその対応する第1エリアに送信するように動作可能であり、 前記第2エリアに接続される第2レベルポートであって、当該第2レベルポートは、データパケットを前記第2エリアから受信し、データパケットをその第2エリアに送信するように動作可能であり、 前記少なくとも1つの第1レベルポートと第2レベルポートとに電気的に接続される少なくとも1つのプロセッサであって、第2レベルポートでマルチキャストパケットを受信することに応答して、当該マルチキャストパケットは、マルチキャストツリーのルートを特定するルートIDを有するヘッダーを含む、プロセッサ、 前記プロセッサは、 前記マルチキャストパケットのルートIDを検査し、 前記マルチキャストパケットが、エリアボーダーノードの少なくとも1つの第1レベルポート上にフォワードされるべきかを決定し、及び、 前記マルチキャストパケットが、少なくとも1つの第1レベルポートでフォワードされるべきとの決定に応答して、前記少なくとも1つの第1レベルポートを越えて前記パケットのフォワードを始める前に、異なるルートIDを前記パケットの中に置き換えるように動作可能である、 エリアボーダーノード。
- 12少なくとも1つのプロセッサに電気的に接続される少なくとも1つのメモリであって、前記少なくとも1つのメモリは、 前記少なくとも1つの第1レベルポートに関連する第1フォワーディング情報ベース(FIB)、及び、 前記少なくとも1つの第2レベルポートに関連する第2フォワーディング情報ベース(FIB)を含み、 前記少なくとも1つのプロセッサは、 少なくとも1つの第1レベルポートで受信したデータパケットを、前記第1FIBに従ってフォワードし、及び、 前記第2レベルポートで受信したデータパケットを、前記第2FIBに従ってフォワードするように動作可能である、 前記請求項11記載のエリアボーダーノード。
- 13少なくとも1つの第1エリアは、1つ以上のエリアボーダーノードによってサービスされ、前記プロセッサは、前記第2エリアを表す疑似ノードへのリンクのため、その関連する第1エリアにアドバタイズメントを、前記少なくとも1つの第1レベルポートを通して送信することにより、前記少なくとも1つの第1エリアをサブセットのグループに分割するように動作可能であり、前記サブセットグループは、前記少なくとも1つの第1エリアにサービスするエリアボーダーノードの総数に等しいサブセットの総数を含み、各サブセットは所定のエリアボーダーノードに関連し、前記エリアボーダーノードに関連する前記サブセットは、前記関連するエリアボーダーノードへの最短パスを有するノードだけを含み、前記アドバタイズメントは、前記関連する第1エリアの最大直径の半分よりも大きい関連するメトリックを含む、前記請求項11記載のエリアボーダーノード。
- 14固有の識別子が各サブセットに割り当てられ、前記サブセットに固有の識別子は、ルートIDとして前記アドバタイズメントに含まれる、前記請求項13記載のエリアボーダーノード。
- 15マルチキャストパケットを第1レベルポートで受信することに応答して、前記マルチキャストパケットは、マルチキャストツリーのルートを特定するルートIDを有するヘッダーを含み、 前記少なくとも1つのプロセッサは、 前記ルートIDが、受信エリアボーダーノードに関連するサブセットの範囲内で、ノードを特定することを決定し、 前記ルートIDを、前記受信エリアボーダーノードに関連するサブセットに固有の識別子に置き換え、及び、 前記少なくとも1つのデータパケットを前記第2レベルポートを通してフォワードするように更に動作可能である、 前記請求項14記載のエリアボーダーノード。
- 16前記マルチキャストパケットが、少なくとも1つの第1レベルポートを越えてフォワードされるべきかを決定することに応答して、前記プロセッサは、 前記ルートIDが、エリアボーダーノードによって供される第1エリアにおいて、他のサブセットを特定することを決定することに応答し、前記少なくとも1つの受信データパケットをドロップし、 前記ルートIDが、エリアボーダーノードによって供される第1エリアにおいて、他のサブセットを特定していないことを決定することに応答し、 前記ルートIDを、第2レベル疑似ノードに置き換え、そして、 前記少なくとも1つのデータパケットを、前記エリアボーダーノードに関連するサブセットを通してフォワードするよう更に動作可能である、 前記請求項13記載のエリアボーダーノード。
- 17単一の目的地アドレスを含むユニキャストパケットを受信することに応答して、前記目的地アドレスは、エリアボーダーノードのサブセットに関連しない第1エリアにおいて、ノードを特定し、前記プロセッサは、 前記少なくとも1つのデータパケットを或る第1レベルポートで受信することに応答して、前記少なくとも1つのデータパケットを、異なる第1レベルポートを通してフォワードし、そして、 前記少なくとも1つのデータパケットを前記第2レベルポートで受信することに応答して、前記少なくとも1つのデータパケットを、前記第2レベルポートを通して、別のエリアボーダーノードへフォワードするように更に動作可能である、 前記請求項13記載のエリアボーダーノード。
- 18パケット通信システムであって:少なくとも1つの第1エリアであり、各第1エリアは、リンクステートプロトコル制御のイーサーネットネットワークとして構成され、各第1エリアは、第1リンクセットにより相互接続される第1複数ノードを含む、第1エリア;及び、 リンクステートプロトコル制御のイーサーネットネットワークとして構成される第2エリアであり、当該第2エリアは、第2リンクセットにより相互接続される第2複数ノードを含み、当該第2エリアは、各第1エリアに相互接続される、第2エリア;を含み、 前記第2エリアを各第1エリアに相互接続する少なくとも1つのエリアボーダーノードであって、前記少なくとも1つのエリアボーダーノードは、2つ以上の独立したエリアに供されるように動作可能であり、各エリアボーダーノードは: 前記第2エリアに接続される第2レベルポートであって、当該第2レベルポートは、前記第2エリアからデータパケットを受信し、前記第2エリアへデータパケットを伝送するよう動作可能であり;各第1エリアに動作可能に接続される少なくとも1つの第1レベルポートであって、当該少なくとも1つの第1レベルポートは、対応する第1エリアからデータパケットを受信し、対応する第1エリアへデータパケットを伝送するよう動作可能であり、 ことを含み、 前記第2レベルポートと前記少なくとも1つの第1レベルポートとに電気的に接続される少なくとも1つのプロセッサと、 マルチキャストパケットを第2レベルポートで受信したことに応答して、前記マルチキャストパケットは、マルチキャストツリーのルートを特定するルートIDを有するヘッダーを含み、 前記少なくとも1つのプロセッサは: 前記マルチキャストパケットのルートIDを検査し;前記マルチキャストパケットが、前記エリアボーダーノードの少なくとも1つの第1レベルポート上にフォワードされるべきかを決定し;そして、 前記マルチキャストパケットが、前記少なくとも1つの第1レベルポートで、フォワードされるべきかを決定することに応答して、異なるルートIDを前記パケットの中に置き換えるように動作可能である、プロセッサ、 を含む、パケット通信システム。
- 19少なくとも1つの第1エリアは、1つ以上のエリアボーダーノードによってサービスされ、前記少なくとも1つの第1エリアは、サブセットのグループに区分され、前記サブセットのグループは、対応する第1エリアにサービスするエリアボーダーノードの総数と等しい総数のサブセットを含み、各サブセットは、所定のエリアボーダーノードに関連しており、前記サブセットは、関連するエリアボーダーノードへの最短パスを有するノードのみを含む、前記請求項18記載のパケット通信システム。
- 20前記エリアボーダーノードは、前記少なくとも1つの第1レベルポートを通じて、その関連する第1エリアへ伝送されるアドバタイズメントにおいて、前記第2エリアを表す疑似ノードへのリンクが存在することを示し、前記アドバタイズメントは、関連する第1エリアの最大直径の半分よりも大きい関連するメトリックを有する、前記請求項19記載のパケット通信システム。
Independent claims20
98 paragraphs, as filed
The present invention relates to an Ethernet network, and more particularly to a method and apparatus for exchanging routing information and constructing a connection over a multiple network area.
In an Ethernet network architecture, networked devices compete for their ability to use a shared communication path at a given time. Where multiple bridges or nodes are used to interconnect network segments, there are often multiple potential paths to the same destination. The advantage of this architecture is to provide a path redundancy between bridges, the form of additional links in formula, is to allow the capacity is added to the network. However, to avoid loop formation, spanning tree has been commonly used to limit the way traffic is sent over the network. Most, if not all, traffic is spanning tree because the route is learned by sending a frame and waiting for a response, and both the request and the response will follow the spanning tree. You will follow the partial links. This often led to overuse of links on the spanning tree, leading to non-use of links that were not part of the spanning tree.
To eliminate some limitations inherent in Ethernet networks, the Ethernet network control link-state protocol is "Provider Link State." It is disclosed in US Patent Application No. 11/537775, filed October 2, 2006, entitled "Bridging," the content of which is incorporated herein by reference. As detailed in the application, Ethernet network-controlled link-state protocols exchange "hello" messages, learn adjacencies of other nodes on the network, and "link-state advertisements". Send a message to allow each node on the network to build a linked database. The link-state packet contains the metric associated with the advertised link. By convention, this metric is interpreted as distance. A link-state database may then be used to calculate the shortest path through the network. Each node forms a forwarding information base (FIB), which is used by the node to determine the forwarding so that the frame is forwarded over the shortest path to the calculated destination. I do. Since the shortest path to a given destination is always used, network traffic is sent across many links, with a single spanning tree or even multiple spanning trees carrying traffic over the network. Will follow a path that is more suitable for a large number of nodes than it is used to.
When the customer's traffic enters the provider, the destination MAC address (C-MAC DA) of the customer's frame is decomposed into the provider's MAC address (B-MAC DA), so that the provider is the provider's MAC address. Space may be used to forward traffic over the provider's network. In addition, the network element of the provider's network is a virtual LAN It is configured to forward traffic based on ID (VID), so that different frames specified at the same destination address but with different VIDs are forwarded across the network across different paths. To. During operation, Ethernet network-controlled link-state protocols may associate a VID region with the shortest path forwarding, and unicast and multicast traffic is forwarded from that range using VIDs for traffic engineering. (TE) paths may be created across the network, on paths other than the shortest path, and forwarded using a second VID region. The use of traffic engineering (TE) paths with the Ethernet network control link state protocol is described in "Engineered Paths In A Link State Protocol Controlled Ethernet. It is described in detail in US Patent Application No. 11 / 732,381, filed April 3, 2007, entitled "Network," the content of which is incorporated herein by reference. Link-state routing protocols include Open Shortest Path First (OSPF) and Intermediate Systems Two Intermediate Systems (IS-IS). These link-state networks only scale up to the point where the reconvergence time becomes unacceptable due to the computational complexity required by the link-state control plane, which is proportional to the network size. And increase exponentially. To get the points in the past, the link-state protocol divides the network into areas. Both IS-IS and OSPF are confined to a two level hierarchy. That is, it is a single backbone area (IS-IS level 2) with a subtending level 1 (L1) stub area.
In provider link state bridging (PLSB), the PLSB applies the IS-IS protocol to the bridge of the provider's Ethernet network, and the bridge that interconnects two or more areas is called an area border bridge (ABB). .. For reliability, it is desirable to have multiple ABBs between any L1 region and a single level 2 (L2) region. The operation of IS-IS in IP networks is already known. However, there are significant differences between Internet Protocol (IP) and PLSB, the difference being that proven methods of directing IP traffic between areas are not always applicable to PLSB. For example, IP is subnet-based, so testing whether to forward a packet to an area-border router is simple.
IP is connectionless, forwarding packets to the nearest Area Border Router (ABR), and the nearest ABB-equivalent IP network will always work. IP does not require path symmetry, packets can leave the area by one ABB, and the opposite packet arrives by another ABB. On the other hand, due to Ethernet multicast and operational design causes, in PLSB the path between two endpoints must be the same in both directions. Also, IP IS-IS and OSPF protocols do not support multicast routing, but the multicast tree is an essential part of PLSB. For Ethernet, multicast packets should follow the same route that unicast packets are transmitted to the same destination (essential for PLSB design).
Currently, the IS-IS protocol allows links to be in both the L1 and L2 areas, but PLSB treats incoming packets as coming from L1 or L2 when deciding on the next hop. Do not supply ABB instructions to determine what should be done. Also, there is no provision to handle scenarios where a single ABB is served in multiple independent L1 areas.
Therefore, what is needed is a system and method for forwarding packets loop-free in a multi-area PLSB network, where the L1 area can be served by multiple ABBs. Often, a single ABB may serve multiple areas.
The present invention advantageously provides methods, devices, and systems that ensure that multicast packets follow the same loop-free paths that unicasts follow within a packet-communication network. In general, a single forwarding information base (FIB) is inadequate for packet-switched networks where any level of area (L1) is provided by multiple area border bridges (ABB). The present invention provides the use of different FIBs, depending on whether the packet arrives on the L1 or L2 port.
According to the first aspect of the present invention, there is provided a method of ensuring that a multicast packet follows the same loop-free path as a unicast packet follows in a packet communication network. The packet communication network includes at least one first area defined at the first level. Each first area contains a first set of nodes interconnected by a first set of links. Each first area is interconnected with a second area defined at the second level through at least one area border node. The second area contains a second set of nodes interconnected by a second set of links. Each area border node contains at least one first level port connected to each first area and a second level port connected to the second area. Each multicast packet forwarded across a loop-free path contains a header with a root-id that identifies the route of the multicast tree. At least one data packet is received at the area border node. The multicast route ID is checked in response to receiving the multicast packet on the second level port of the area border node. If the multicast packet should be forwarded on at least one of the area border node's second level ports, then the packet with a different route ID before forwarding the packet across at least one first level port. Is replaced by.
According to another aspect of the invention, area border nodes are provided for use in packet communication networks. The packet communication network includes at least one first area defined at the first level. Each first area contains a first plurality of nodes interconnected by a first set of links. Each first area is interconnected with a second area defined at the second level. The second area contains a second set of nodes interconnected by a second set of links. The area border node includes at least one first level port corresponding to each first area, a second level port corresponding to the second area, and at least one processor. The first level port can operate to receive data packets from the corresponding first area and send them to that first area. The second level port can operate to receive data packets from the second area and send them to the second area. At least one processor is electrically connected to each first level port and second level port. In response to receiving a multicast packet on a second port that contains a header with a route ID that identifies the route of the multicast tree, at least one processor checks the route ID of the multicast packet and the multicast packet is It can act to determine if it should be sent to at least one of the first level ports of the area border node. If the multicast packet should be sent across at least one of the first level ports, the processor puts a different route ID in the packet before starting to send the packet across the first level port. Replace with.
According to yet another aspect of the invention, a packet communication system includes a second area, at least one first area, and at least one area border node. At least one of the first areas is interconnected with the second area. The second area and each first area are configured as a link-state protocol for Ethernet network control and contain multiple nodes interconnected by a set of links. At least one area border node can operate to interconnect each first area to a second area and serve two or more independent first areas. Each area border node contains a second level port, at least one first level port, and at least one processor. The second port can operate to receive data packets from the second area and send data packets to the second area. Each first level port can operate to receive data packets from the corresponding first area and send the data packets to the corresponding first area. In response to receiving a multicast packet on a second-level port that contains a header with a route ID that identifies the route of the multicast tree, the processor checks the multicast route ID and the multicast packet is on the area border node. It can act on at least one of the first level ports to determine if it should be sent. If a multicast packet should be sent across at least one of the first level ports, the processor puts a different route ID in the packet before starting to send the packet across the first level port. replace.
Some aspects of the invention are pointed out in detail in the appended claims. The present invention is illustrated by the following specific examples of the drawings, in which similar reference numbers point to similar elements. The following drawings disclose various embodiments of the invention, but they are for illustration purposes only and are not intended to limit the scope of the invention. For clarity, not all components are referenced in all figures.<figref num="1">Figure 1 shows a functional block diagram of an example Ethernet network with link-state protocol control.</figref><figref num="2" /><figref num="3">2 and 3 show a set of examples of interconnected link-state protocol controlled Ethernet networks according to an embodiment of the invention, the functional block diagram thereof.</figref><figref num="4">Figure 4 is an exploded view of a functional block diagram of an ABB, performing both area division of the network and hierarchical routing. This figure shows a process in which a community of interest identifier information is used to leak between network areas according to an embodiment of the invention, with paths traversing between link-state protocol controlled Ethernet network areas.</figref><figref num="5">FIG. 5 is a functional block diagram of a network element according to an embodiment of the present invention, wherein the network element acts as an area boundary bridge (ABB) between two link-state protocol controlled Ethernet network areas. Used at boundaries.</figref><figref num="6">FIG. 6 is a functional block diagram of network elements according to an embodiment of the present invention, configured to employ recursion that allows network subdivision.</figref><figref num="7">FIG. 7 is a functional block diagram of a two-level provider link state bridging (PLSB) network according to the principles of the present invention, with ABB in a multihomed configuration.</figref>
The provider backbone bridge of IEEE standard 802.1ah-2008 is "MAC in" By defining a new Ethernet header informally known as "MAC", it provides complete separation of customer and provider Ethernet addressing and provides a large number of customer service instances in the provider network, such as transparent LAN services. Allow to provide an instance. Using a link-state protocol with 802.1ah to control a provider's Ethernet backbone network provides that Ethernet network by providing more efficient network capacity with loop-free shortest path forwarding. Allows expansion from LAN space to MAN and WAN. By using the Spanning Tree Protocol (STP) algorithm combined with transparent bridging, a mesh network is formed in a link-state protocol-controlled Ethernet network rather than leveraging the network view learned on each node. Bridges can exchange link-state advertisements to give each node a synchronized view of the network topology. This is achieved through a well-understood mechanism of link-state routing systems. Bridges in the network have a synchronized view of the network topology, have the required knowledge of unicast and multicast connections, and can calculate the shortest path connections between any bridge pair in the network. , And the forwarding information base (FIB) can be generated individually according to the calculated view of the network.
When all nodes have calculated the role of the synchronized network view and generated their FIB, the network will have a loop-free unicast tree from a set of peer bridges to any given bridge. Deaf (the set of peer bridges requires communication with the bridge for whatever reason). It includes a congruent, loop-free one-to-many (point-to-multipoint; p2mp) from a given bridge to the same set or subset of peer bridges per service instance provided by the bridge. As a result, the path between a given bridge pair is unconstrained and can transit the root bridge of the spanning tree, and as a result, better utilize the connection width of the mesh. In essence, each bridge is the root of one or more spanning trees, which define a unicast connection to that bridge and a multicast connection from that bridge.
Link-state protocol controlled Ethernet networks provide the equivalent of Ethernet bridge connections, but this is achieved through the configuration of network element FIBs rather than by flooding and learning. It is, for example, provider backbone bridging, or IEEE (Institute of Electrical and Electronics) entitled MAC in MAC. Engineers) Could be used by new standards such as the 802.1ah draft, configured to forward minor changes to B-MAC (backbone MAC) and BEB adaptive capabilities to map client delivery behavior to multicast. Will be done. The client Ethernet can then take advantage of the connections provided by the link-state protocol controlled Ethernet network without modification. To provide transparent LAN services to the C-MAC (customer MAC) layer, or other network layers that use transparent LAN services, the MAC settings are a set of (slightly modified) 802.1ah provider backbones. Used to build the shortest path loop-free connection (for both unicast and multicast) between bridges.
Similar reference numbers for the drawings represent similar elements, and FIG. 1 is an example of a portion of a link-state protocol controlled Ethernet network 10 showing its functional block diagram. As shown in FIG. 1, the network 10 in this example includes a plurality of bridge nodes 12, which are interconnected by a link 14. Bridge node 12 exchanges "hello" messages to learn the proximity of other nodes and exchanges link-state advertisements, with each node calculating the shortest path between an entry and exit through the network. Allows you to build a link-state database used for. Additional details relating to the example Link State Protocol Control Ethernet Network are described in US Patent Application No. 11 / 537,775, filed October 2, 2006, entitled "Provider Link State Bridging". Its contents are incorporated by reference in this application.
Two examples of link-state routing protocols include Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS), but other link-state routing protocols are used as well. May be good. For example, IS-IS is described in ISO10589 and IETF RFC1195, the contents of which are incorporated herein by reference. Although various protocols currently exist, the invention is not limited to implementation based on the latest version of the standard, and the invention may be adapted to function in future versions of the standard as it evolves. .. Similarly, the invention is not limited to implementations that operate in the context of one of a given protocol, other protocols may also be used to exchange routing information.
In addition to installing the shortest path unicast forwarding state, the node may install a forwarding state for the multicast tree on the network. An example of how to implement multicast in a link-state protocol-controlled Ethernet network is "Multicast Implementation in a Link State." It is described in detail in US Patent Application No. 11 / 702,263, filed February 5, 2007, entitled Protocol, the content of which is incorporated herein by reference. As stated in the application, link-state advertisement advertises the membership of the multicast group and raises the forwarding state of the multicast group installed on the network. Specifically, each tree route for a given multicast group may be assigned a unique identifier, such as a route ID, which identifier is the destination MAC address (DA) for forwarding multicast frames on the network. May be used as. Nodes on the network are on the shortest path from the multicast route to one of the destination nodes where they happen to advertise "receive interest" over the link state within the multicast group. If so, install the forwarding state for the root / group tree. In Figure 1, a multicast tree with a route at node F is shown, where the destination nodes (A, B, C, E and H) receive received interest in one or more multicast groups with members at F. If you have. For example, node D is the shortest distance between node F and node A, so it installs itself in the tree (installs the forwarding state of that tree).
Multicast interest may be based on a community of interest identifiers, such as I-SID. A node on the network is in the forwarding state of the multicast group if it is at the shortest distance between the source and the destination and both have advertised the interest of the community of interest identifiers associated with the multicast group. To install. However, the forwarding state is based on the multicast destination address (DA) and the virtual LAN ID (VID) associated with that multicast. During operation, when an internal node receives a frame, it performs a reference in the forwarding information base (FIB) based on the DA and the VID associated with that frame, thus forwarding the frame. As described above, embodiments of the present invention will be described using the I-SID as a community of interest identifiers, but the invention is not limited to this embodiment and communities of other types of interest identifiers are used. You may.
Traffic engineering may be used to create paths that do not necessarily follow only the shortest path on a link-state protocol controlled Ethernet. By identifying the forwarding state of traffic engineering using different VIDs, the forwarding state of the traffic engineering path may be distinguished from the forwarding state installed in connection with the implementation of the shortest path routing protocol. A method for creating traffic engineering paths through a link-state protocol controlled Ethernet network is a US patent application filed on April 3, 2007, entitled "Engineered Paths In A Link State Protocol Controlled Ethernet Network", No. 11/732381. It is described in detail in the issue, the contents of which are incorporated by reference in this application.
When a frame arrives at a network element, for example, if the customer's network element I sends the frame to the customer's network element J, the frame will be received by the provider's network element F. Network element F will determine which nodes on the provider's network know which can reach the customer MAC address (C-MAC) of destination node J. If F already knew that provider network element E could reach customer network element J, network element F would add a MAC header and perform MAC-in-MAC encapsulation of the customer frame. Its outer header will contain the destination MAC address of network element E as it will generate frames that are forwarded over the network.
Similarly, where the frame is a multicast frame, the provider network element F will determine the provider multicast DA that should be used to send the frame over the provider network. Ingress network element F will send frames across the provider network using the shortest path forwarding or using the traffic engineering controlled paths available through the network. The entry node performs C-MAC B-MAC decomposition and uses the new MAC header to perform client frame encapsulation. The resulting encapsulated frame is addressed using the B-MAC addressing space. MAC-in-MAC encapsulation is well known and therefore no detailed description of the processes involved in this type of encapsulation will be provided.
Where entry node F does not know which provider node can reach customer node J, the entry node simply uses the multicast tree associated with the interest community (or I-SID) to send packets. Will flood to all other backbone edge bridges (BEBs) in the interest community. Subsequent messages from any J allow F to know which provider DA to use for the outer MAC header. Optionally, the distributed HASH table may be used to store the C-MAC and B-MAC correlations so that the entry node sends the query to one or more nodes. Realize the distributed HASH table rather than delivering the address decomposition request. One way to achieve a distributed HASH table is "Distributed Storage of Routing Information in a Link State Protocol Controlled Ethernet". It is described in detail in US Patent Application No. 11 / 714,508, filed March 6, 2007, entitled "Network," the content of which is incorporated by reference in this application.
As a network grows in size and contains a large number of nodes, it is desirable to divide the network into two or more smaller areas. This allows the control plane and associated network database to be split into two or more instances, detailed routing updates are contained within that small network area, and changes within one area are close. Do not confuse the area. This is advantageous because it reduces the number of link-state advertisements, reduces the size of the link-state database, and increases the overall concentration rate of the network of topographical changes. However, dividing a network into two or more areas is disadvantageous because it requires coordination to build connections across the networks.
Once the network exceeds a certain size, fragmentation is not enough to solve the scalability problem and the amount of state in the core of the network (L2 network) needs to be reduced in order for the network to continue to grow. There may be. This can be achieved by hierarchically recurring the network (MACinMACinMAC) on both the control plane and the data plane, and in a preferred embodiment between the B-MAC layer and the further recursed MAC layer. Achieved by reusing the MAC known by 802.1ah to build the bond.
Loops within an Ethernet forwarding path can be catastrophic, especially if the forwarding path is a multicast path, which can lead to infinite packet replication. Therefore, constraining the interconnection of areas and making them hierarchical is advantageous over allowing mesh interconnection of areas because the problem of ensuring loop-free is simplified. The routing system has such a concept and is an example of the Level 1 / Level 2 (L1 / L2) concept within IS-IS, where the L1 area is only connected to one L2 area. FIG. 2 shows an example of the communication network 11, in which the Ethernet network area 20 of the multiple link state protocol control is interconnected via the area boundary bridge (ABB) 30. Specifically, in FIG. 2, network 11 includes a first set of Ethernet network areas L1A, L1B and L1C with link-state protocol control. The first set of link-state protocol controlled Ethernet networks may be, for example, urban networks, but the invention is not limited to this particular example. Networks L1A, L1B and L1C are interconnected by other link-state protocol controlled Ethernet networks L2. The L2 network area may be, for example, a provider backbone network configured to interconnect with the L1 network. The present invention is not limited to the particular example shown in FIG. 2, and the network of FIG. 2 is merely intended to provide an exemplary environment in which the invention is practiced. In IS-IS, the official interface between L1 and L2 is defined as existing on the connection, not in the node. As used herein, ABB is defined as a bridge having an interface to at least one L1 link and at least one L2 link.
Customers connect to the network via the backbone edge bridge (BEB) 32. Within the network, connections are established via the backbone core bridge (BCB) 34. As shown in FIG. 2, customer 40 connecting to network L1A via BEB-A wants to be able to communicate with customer 42 connecting to network L1-B via BEB-B, and further, BEB- Suppose you want to be able to communicate with a customer 44 who connects to network L1-B via C. To enable this type of communication, it is necessary to build a route between A and B via network areas L1-A, L2 and L1-B, as well as network area L1-A. It will be necessary to build a route between A and C via, L2 and L1-B.
According to one embodiment of the present invention, the communication network 11 includes a single L2 area. ABB may be served in multiple independent L1 areas, but each port on ABB is dedicated to a single area. However, if a direct physical link exists between two ABBs served in the same area and it is desirable to use that link for both L1 and L2 traffic, then the two logical ports are multiplexed. Used in the method. Each L1 area is a stub area. That is, there is no ABB between the two L1 areas and it is not connected to the L2 area. L1 intra-area traffic should not use L2 links to facilitate loop-free path calculations. The L2 node does not use the L1 link as a transit to another L2 node, even if the L2 area is divided separately. However, the L2 node can use the provider backbone transit (PBT) path through the L1 area. That is, in this case, the L2 traffic traverses the L1 area with an additional layer of Ethernet encapsulation and an outermost layer VID that is different from the VID of the L1 traffic. Traffic coming from different areas always arrives at well-defined physical or logical ports, so ABB can easily maintain and use different forwarding information bases (FIBs), one in each area. Is served. Therefore, when a packet arrives on the L2 port, ABB refers to its L2 FIB to determine how the packet should be forwarded.
Multi-area solutions have many constraints to consider. Unlike telephone numbers (for example), Ethernet MAC addresses cannot be summarized so that some abbreviations represent a group (for example, the 613 area code specifies all telephone numbers in Ottawa, Canada). Area code). In addition, the network area should provide symmetric forwarding so that traffic can follow the same path in both directions through the network.
In the example of FIG. 2, areas L1-A, L2 and L1-B are all link-state protocol controlled Ethernet network areas, each implementing its own link-state routing protocol instance. Therefore, routing information is generally contained within various network areas, and only a limited or summarized amount of routing information is exchanged between areas. However, as detailed here, ABB allows a community of interest identifiers, such as I-SID, and some relevant BEB information to leak between areas, resulting in BEB. Related routes common to and I-SIDs may be built through one or more areas. More specifically, I-SID interests may leak across network boundaries, so route segments for I-SIDs may be built within each network area, and the route segments are aggregated. Form a multi-area route. Since the I-SID is leaked without interference by the network management system, routes between areas may be automatically constructed by the control planes of multiple network areas.
According to one embodiment of the invention, ABB at the border between two networks advertises with each network area so that other networks can be reached. Thus, for example, in FIG. 2, ABB-a and ABB-b are located in the boundaries between network areas L1-A and L2, respectively. Therefore, each of these ABBs will advertise the ability to reach network area L2 within network area L1-A and the ability to reach network area L1-A within network area L2. .. According to one embodiment of the invention, ABB advertises network area L2 as a "pseudo node" (also known as virtual BEB) of network area L1, so that BCB is the closest BEB and ABB. By installing the forwarding state of the shortest path to and from the virtual BEB advertised by, it automatically determines which ABB should handle traffic for a given set of closest BEBs. In this way, the L1 network self-selects ABB and represents a set of BEBs within the adjacent L2 network area. If all ABBs advertise network area L2 as the same virtual BEB, the shortest path from BEB in network area L1 is automatically installed via the ABB closest to that virtual BEB and is therefore specific. The shortest path from the set of BEBs closest to ABB will be installed.
By determining which BEB in L1 is closer to each ABB than the other ABB, the ABB serving a given L1 self-diagnoses to represent a particular BEB in L2. So, for example, in FIG. 2, ABB-a is closest to BEB-A. Therefore, the route from A, it is required to go out from network area L1-A, and the route from A is, for example, BCB-A. It is installed via a backbone core bridge (BCB) like ́ and passes through ABB-a. Similarly, routes from BEB-D will be installed via ABB-d. There are many ways to do this, but the simplest (the one that doesn't require any special rules for BEB and BCB in L1) is as a single pseudonode connected to ABB with an equivalent cost link ( That is, L2 is represented in L1 by virtual BEB) and ABB. As mentioned above, traffic between L1 areas should not use L2 links. The cost of a "link" to a pseudonode representing L2 must be large enough that the shortest distance path between any node pair in the L1 area does not include a virtual BEB. According to one embodiment of the invention, this is ensured by setting the cost metric, or distance, for the "link" to be greater than half the diameter of the L1 area. The diameter of the L1 area is the maximum distance between two nodes in the L1 area.
There are certain rules about how ABB leaks information between areas. The ABB closest to the BEB in L1 advertises the I-SID and the BED MAC address associated with that area. This does not require deductive knowledge of what I-SIDs are multi-area interests. ABB will only leak BEB and I-SID information collected from other L1 areas from L2 into L1. There, one or more BEBs in L1 have already dictated interest in the I-SID. Therefore, the node in L2 will have a complete map of I-SID and BEB in the control plane. Nodes in L1 will have maps of their BEB and I-SIDs of local area interest only, and those maps of purely multi-area.
As understood in L2 above, the proper data plane connection is determined to be built between ABBs per community of interest identifiers, i.e. per I-SID, and to represent the associated BED in L1. Let's go. Similarly, in L1, the ABB representing BEB in the other L1 will have the appropriate connections constructed to include the local BED that is part of the community of the same interest identified by the community of interest identifiers.
The BEB on the L1 network area can interest the community of interest identifiers, such as the I-SID, via link-state advertising or by using other messages in the L1 network area. Will advertise. In this example, the interest identifier community is the I-SID. Communities of other interest identifiers may be used as well.
ABB receives a message indicating that one or more BEBs on the L1 network area are interested in the I-SID. ABB will leak I-SIDs learned on the L1 network area to the L2 network area. Its I-SID is advertised by the nearest BEB. By simply advertising the I-SID advertised by the closest set of BEBs, the L2 network can learn which ABB should be used to forward traffic on the route to the BEBs. ABB will hear I-SIDs advertised by other ABBs on the L2 network area. Where one or more ABBs belonging to different L1s on the L2 network area advertise the interest of the same I-SID, the I-SID is of multi-area interest. For one or more L1, I-SID detection ensures that the L2 network does not install forwarding state between two ABBs on the same L1 network. If a single L1 has one or more ABBs, the internal topology of that L1 may cause one or more ABBs to advertise the I-SID into L2, but this is because different L1s As long as the I-SID is advertised, it must be ignored in L2. In this example, ABB that advertised the I-SID in the L2 network would also advertise back to the L1 network area to which the I-SID belongs. Then, connectivity in the L1 network area is built from BEB to ABB in the L1 network area. If multiple ABBs advertise their I-SID back to L1, the connection between ABBs for that I-SID will not be built in L1. In the example of Figure 2, connectivity between ABB-b and ABB-c is not built in L1-B. In the example shown in Figure 2, BEB-A advertises the interest of I-SID-x within network area L1-A, and BEB-B and BEB-C are in network area L1-B. , I-SID-x will be assumed to have advertised the interest.
All of ABB-a, ABB-b and ABB-c will advertise interests to all I-SIDs to L2. Those I-SIDs are advertised by the BEB represented by the I-SID.
Therefore, in this example, ABB-a advertises MAC-BEB-A / I-SID-x, ABB-b advertises MAC-BEB-B / I-SID-x, and ABB-c advertises. Will advertise MAC-BEB-C / I-SID-x.
All of ABB-a, ABB-b and ABB-c receive advertisements from other ABBs and determine that the I-SID is advertised from both L1-A and L1-B. It will determine that the I-SID is of multi-area interest.
Therefore, ABB-a advertises MAC-BEB-B / I-SID-x and MAC-BEB-C / I-SID-x into the network area L1-A, while ABB-b and ABB-c , MAC-BEB-A / I-SID-x will be advertised in network area L1-B.
Advertisements to these L1 areas are made to appear as if they were derived from L2 pseudonodes advertised from ABB to the L1 area, as described below.
By having each ABB advertise all the I-SIDs learned from the adjacent L1 network area to the L2 network area, the ABB on L2 will see which I-SID spreads between the L1 network areas and of its route. You may selectively decide if you need to advertise the MAC / I-SID information to the L1 network area just for the sake of it.
ABB will leak all interest I-SIDs from L1 to L2 into the set of BEBs in L1. ABB in L2 will advertise all L1 I-SIDs among themselves, but if the same I-SID has already been advertised by L1, only the I-SIDs from L2 will be L1. Will advertise to. Therefore, the end result is that within L1, all BEBs interested in a particular I-SID will have the connectivity established by the routing system. Only if the I-SID exists in another area, ABB will advertise the interest of that I-SID to L1 (in which case the connection from the area will be established via ABB. Deaf). Within the L2 network area, BCB installs connections between ABBs in different L1 areas that advertise interests with the same I-SID. As a result, a connection within the L2 network may be established. If any L1 has one or more ABBs that advertise the I-SID to L2, then the connection for the I-SID between those ABBs will not be built in L2.
ABB advertises all I-SIDs and associated BEB information from L1 to L2. The I-SID information advertised from the L1 network area to the L2 network area will be in the form of ABB MAC addresses, I-SIDs, and BEB MAC addresses for that I-SID. When ABB receives an I-SID advertisement from another ABB in L2 and receives an advertisement from a local L1 indicating interest to the same SID, the I-SID and BEB information received from L2. Will be advertised to L1.
The I-SID will be advertised within network L2. Similar to how a single area solution works, BCBs within the area L2 range install the forwarding state and advertise interest to the same I-SID, the shortest path between ABBs belonging to different L1 areas. Will be able to be made. Therefore, for example, it is assumed that ABB-a, ABB-b, and ABB-c all advertise the interest of I-SID = x. BCB-1 recognizes that it is on the shortest path between two ABBs that advertise a common I-SID interest, installs a forwarding state, and the frame is forwarded from ABB-a to ABB-b. Will be possible (and vice versa). Similarly, BCB-2 will install a forwarding state and allow frames to be forwarded from ABB-a to ABB-c (and vice versa).
ABB-b and ABB-c leak I-SID from network area L2 to network area L1-B, which seems to be advertised from the virtual BEB behind ABB-b and c. is there. BCBs within network L1-B are on the shortest path between the BEBs they advertised the interest in the I-SID and the virtual BEBs (which ABB advertised as interested in the I-SID). If so, you'll install the forwarding state. When there are two or more ABBs that leak the I-SID from the network area L2 to a certain L1, the ABB makes the advertisement appear to come from the virtual BEB. In one embodiment, ABB is configured so that advertisements to the L1 area always appear to be advertised by the virtual BEB. In other embodiments, when there are multiple ABBs connected to the L1 area, the ABBs are only configured to use the virtual BEB to leak the I-SID to a given L1. In some other embodiments, some ABBs determine that only one I-SID is required to advertise to the L1 area (eg ABB-a in Figure 2), and thus the I-SID. Advertise your interest as if it came from itself.
In this regard, by letting ABB self-diagnose which BEB is represented by connecting to the route leaving L1-B, parallel paths can be created between ABB-b and BEB-B, and Note that it was created between ABB-c and BEB-C. However, reaching different BEBs using multiple ABBs will not cause forwarding collisions. What is actually being created is a spanning tree to the virtual BEB that represents L2, which inevitably becomes the route between BEB and ABB and is only installed from BEB to the nearest ABB. Where there is an equivalent cost path between a given BEB and two or more ABBs, the routing system uses the normal intra-area ty-breaking mechanism to determine which ABB is the BEB in the adjacent area. Decide whether to represent.
The I-SID is generally associated with a multicast connection. Specifically, a predetermined multicast is constructed on the network by having the BEB interested in the multicast advertise the interest of the I-SID associated with the multicast. Therefore, the forwarding state is installed for multicast, as described in detail in US Patent Application No. 11 / 702,263 above. Other interest identifier communities may be used in place of the I-SID, and the present invention is not limited to the practice of using the I-SID as a community of interest identifiers. As mentioned above, it is desirable to leak knowledge of BEB between areas, but in a mechanism that minimizes how changes within one area confuse other areas. One way to do this is to simply associate the BEBs with the ABBs in the peer area, as if they were placed together. As a result, knowledge of peer area topologies (in the form of actual metrics) does not need to be shared between areas. It was simply simplified to associate BEB with the closest ABB. One result of this is that the multicast tree for a given I-SID routed in ABB will be the same for all BEBs behind that ABB. This means that the general destination multicast address is used for the multicast flow of a given I-SID transiting ABB, which increases scalability.
Since ABB may represent multiple multicasts routed to the nearest set of BEBs in L2, the multicasts may be summarized when leaking routing information to the adjacent area L2. For example, ABB-a may summarize the multicast routing information mMAC (BED, I-SID) by advertising the mMAC (ABB, I-SID) instead. Specifically, ABB may replace its DA with the DA of the BED for a given I-SID. This may be repeated at the boundary between L2 and L1. It is shown below.
-From L1 to L2, the multicast tree in L2 that is routed to a given ABB is common to all BEBs in L1 that are closest to that ABB.
-From L2 to a specific L1, the multicast tree in L1 that is routed to a given ABB is common to all ABBs in L2 that are routed to any other L1. Note that this tree will only extend into L1 to the BEB closest to the given ABB.
The ABB on a given area boundary, whether L1 or L2, is not a leaf of a multicast tree that routes to another ABB on that area boundary.
From the point of view of the path structure in the L1-A network, BCB-A ́ will determine to be on the shortest path from BEB-A to L2 (via ABB-a). BCB-A ́ will also determine that BEB-A and ABB-a have a common I-SID. Therefore, BCB-A ́ generates and installs a multicast group address for BED-A / I-SID = x. It will install unicast addresses for remote BEBs that advertise interest to I-SID-x (BEB-B and BEB-C in this example) and unicast for local BEB-A. It will install the cast address, and will generate and install the multicast address for ABB-a / I-SID = x. In the L2 network, BCB-1 states that it is on the shortest path between ABB-a and ABB-b in L2, both sharing one I-SID (I-SID = x). Will decide. BCB-1 generates and installs multicast addresses for ABB-a / I-SID = x and ABB-b / I-SID = x, and Uni for BEB-A and BEB-B. Install the cast address.
Within a given L1 network, such as L1-B, multiple ABBs may advertise interest or knowledge of a given I-SID. To allow the BCB to install the forwarding state within the network (L1-B network), ABB will advertise the I-SID along with the virtual BEB that represents the L2 network. This only allows the BCB to install a forwarding state for routes that span areas, through the nearest ABB and to the BEB of interest. This also avoids multiple paths being installed between a given BEB and one or more ABBs. This is because the only shortest path from that BEB to the virtual BEB that represents L2 is installed, and that shortest path will automatically go to that BEB through the nearest ABB. If more than one ABB may advertise interests with the same I-SID, BCB will not install forwarding state between ABBs on a common network boundary (eg L1A-L2). It may be configured as follows.
Within L2, a given ABB has many BEBs behind it and appears within its L2 network area. To simplify the shortest path calculation for BCB within the L2 network area, BCB will base its routing calculations on ABB rather than BEB as indicated by ABB. In this example, each BCB in L2 may determine if it is on the shortest path between the two ABBs, and if so, whether the ABBs have a common I-SID. You may decide. If both of these conditions are present, BCB may install a forwarding state for the multicast MAC address mMAC (ABB, I-SID = x) and the unicast MAC address uMAC (BEB). Those BEBs are involved in a set of I-SIDs that are common to the two ABBs.
By having ABB self-diagnose, unicast forwarding may be constructed across multiple domains without requiring an explicit path to be set. Rather, the routing system implements a unicast path, and the forwarding state is set for that unicast path, even where it is required to span multiple network areas. Make it possible.
Since each network area has its own control plane, topological changes can often be isolated within a given network area range. However, when a topology change occurs and somehow changes which ABB is closest to which BEB, the topology change will also affect adjacent networks. Specifically, it is assumed that a failure occurs on network L1-A, which changes the shortest path to L2 for BEB-A to pass through ABB-d. In this example, the L1-A routing system would cause the new shortest path to build from BEB-A to ABB-d and let ABB-d advertise BEB-A / I-SID = x to L2. This will cause new shortest paths to be built within L2 between ABB-a and ABB-d, and between ABB-c and ABB-d. However, as a result, network changes do not affect other L1 areas, so that local failures are included without cascading routing changes throughout the entire area of the network. In addition, some failures within network L1-A may affect the routing system within L2, but many failures within network L1-A affect the choice of ABB for BEB. Will not give. Therefore, the failure is localized within the range L1-A and the routing within the range L2 is unaffected by the failure.
Once the result of L2 is modeled as a virtual BEB within L1, multiple copies of the multicast packet may enter from L2 to L1. However, the overall behavior is that of a spanning tree routed by a virtual BEB in L2, so each BEB in L1 still only receives one copy of a given multicast packet, and only one copy. Is.
Although details have been given in connection with the specific network example shown in FIG. 2, the present invention is not limited to this method, and the techniques described herein are in many different network configurations. , May be used to build a path across multiple areas. Therefore, the present invention is not limited to embodiments in networks with interconnected network areas as shown in FIG. 2, but rather has one or more Ethernet network areas with two or more link-state protocol controls. It may be adopted in connection with any network interconnected with ABB. Similarly, the I-SID may be used as an example of a community of interest identifiers, which may be used to determine which community of interest spans between areas, but the invention is not limited to this method. , A community of other interest identifiers may be used as well.
Where a given BEB has two or more paths and that path branches at the same cost as two or more ABBs, it is necessary to use different VIDs to distinguish traffic to different ABBs. May become. Other methods of resolving conflicts between ABBs may be used as well, and the invention is not limited to examples using different VIDs to identify traffic destined for different ABBs.
ABB and BCB in L2 have additional requirements, i.e. ABB on a given area boundary cannot be a leaf of a multicast tree from ABB on the same area boundary. This avoids forming a loop in the area boundary.
When traffic is forwarded from one network area to another (for example, from one L1 area to an L2 area), the MAC addressing space in that area is used to cause forwarding across the second area. As such, the traffic may be encapsulated. For example, when customer 16 receives a frame addressed by BEB-A to customer 18 on BEB-B, the frame first receives the destination address DA = C-, which is the address of customer 18. Will have a MAC. BEB-A will use the provider Ethernet header to determine which BEB can reach the customer MAC address and encapsulate the customer frame. For example, using the provider MAC address space rather than the customer MAC address space, BEB-A performs MAC-in-MAC encapsulation so that the frame is forwarded across the L1-A network. May be good. BEB-A has several methods for determining which BEBs on the network can reach Customer 18, but the present invention is limited to specific methods that disseminate this information. It's not something.
After the frame travels across network area L1-A, it will arrive at ABB-a, where it will travel over network area L2. In this regard, it will be understood that the path has been established, as detailed above. According to one embodiment of the invention, since ABB-a transmits across the L2 network, frames may be further encapsulated, which performs MAC-in-MAC-in-MAC encapsulation. This is done by using the L2MAC address space to forward frames within the range of the L2 network. Specifically, ABB-a may determine which other ABB on L2 can forward the frame to its destination (B-MAC address) and of the destination ABB on the L2 network. It will determine the MAC address (A-MAC address) and add an L2MAC header to further encapsulate the frame for transmission over the L2 network. This allows L1 addresses to be summarized on L2 in ABB by encapsulation, and within L2 the BCB only needs to install routes based on the L2MAC (A-MAC) address space.
The C-MAC / B-MAC learned in the L1 network space may be generated in the usual way. Similarly, L1-MAC / L2-MAC (B-MAC address A-MAC address) learning was distributed, for example, by flooding L1-MAC / L2-MAC related requests and waiting for a response. It may be generated by a normal learning process, such as by using a hash table.
Figure 3 provides a visual illustration of what is happening with respect to the encapsulation process. Specifically, the L1-A metrics remain local to the network area L1-A. L2 simply filters the inter-L1 area route by I-SID. This allows uMAC / mMAC compatibility in L1, L2 and MAC-in-MAC-in-MAC. Multicast MAC addresses from L1-A are mapped to the tree in L2 via the I-SID. ABB-a needs to know that the path to BEB-E is via ABB-e. This relationship may be learned by flooding the request and waiting for a response. However, flooding on the network area is capped by the ABB boundary node, and its B-MAC / A-MAC related requests are not flooded to other network areas. Once the B-MAC / A-MAC relationship is learned by the entry ABB, ABB may use that address to encapsulate the frame for transmission over the L2 network. Optionally, the self-designated L2 multicast MAC address may be used where a given I-SID is advertised by one or more destination ABBs on the L2 network.
Figure 4 illustrates an interlayer that learns and binds the functions between layers as the routing system recurses. As mentioned above, the L2 network can grow too large, allowing the network to recurse further and distribute the L2 network within the second level L1 / L2 / L1 network, as shown in Figure 6. It is desirable to do. Figure 4 shows the process by which a frame is encapsulated because the frame is transmitted from L1 over recursive L2 (where the unencapsulated layer is referred to as "layer X" and is the encapsulated layer. Is referred to as "Layer X + 1"), and also the process of decapsulating frames after receipt from recursive network area L2 to transmit across network area L1 within a given layer. Shown.
Figure 4 is a decomposition of ABB's functional block diagram, which provides both area division of the network and hierarchical routing. It also communicates with each segment of the peer in the current layer. It is also a peer at the recursive level, layer X + 1.
The L1 FIB for layer X is generated via routing exchanges with peer devices at L1 (including those that communicate across L2), as well as the L1 FIB for layer X + 1. , Generated through a routing exchange with a peer device at layer X + 1 (encapsulation layer).
As shown in Figure 4, when a frame is received from L1 on layer X, ABB will layer X destination MAC through a search (lookup) of the mapping FIB from X to X + 1. You will find out if it can be decomposed into an X + 1 MAC, or whether the frame is a broadcast or multicast frame. In these cases, the BEB's layer X + 1 MAC is used as the source, and the multicast MAC address of the I-SID used as the destination by the BEB within layer X + 1 is used, encapsulated, and then. Forwarded according to layer X + 1 FIB. If the layer X destination MAC address can be decomposed into layer X + 1 MAC addresses, then the packet is the destination obtained from the BEB MAC address as the source and the X to X + 1 mapping FIB. Encapsulated with the Layer X + 1 MAC address of and forwarded according to the Layer X + 1 FIB.
When a packet is received from layer X + 1, the source MAC is associated with the layer X source MAC and its binding is inserted into the X to X + 1 mapping FIB. The packet is decapsulated and forwarded according to the information in the "Layer X" FIB. It is the learning of X to X + 1 joins through creative reuse of the 802.1ah MAC learning process, which addresses the need to explicitly communicate with interlayer joins in layer X + 1 routing systems. prevent.
Note that the network can use this technique to recurse any number of times. Also, what is referenced in this example can be subdivided without recursion or a mixture of recursion, and subdivision at each layer of recursion can be adopted to extend the network. pay attention to. This is shown in Figure 6. For example, as shown in Figure 6, an L2 network is formed as a layer X + 1 L1 / L2 / L1 network, which is interconnected by a single L2 (X + 1) network area. X + 1) Has a network. Similarly, the L2 (X + 1) network area may be formed as L1 / L2 / L1 of a set of (X + 2) network areas. The process described with respect to FIG. 4 may be used to perform the boundary between the L1 (X) and L1 / L2 / L1 (X + 1) layers, L1 (X + 1) and L1 / L2. It may be used to perform a boundary between the / L1 (X + 2) layer or another boundary between the network area and the recursive L1 / L2 / L1 (X + n) layer.
From a routing perspective, ABB's Layer X network-side UNI interface will store Layer X I-SID information received via the Layer X network link-state routing protocol within the Layer X FIB. Similarly, the NNI interface on the Layer X + 1 network side of ABB stores Layer X + 1 I-SID information received via the Layer X + 1 network link-state routing protocol within Layer X + 1 FIB. right. However, according to one embodiment of the invention, the I-SID information leaks between layer X and layer X + 1, and the layer X + 1 network is common to different areas of the layer X network. The SID allows you to selectively install routes through the Layer X + 1 network.
From a control plane perspective, control plane information is summarized / integrated across the Layer X + 1 network, processed on the control plane, and reduces the amount of information that should be installed in the Layer X + 1 forwarding table. .. This is advantageous in terms of scalability, as the BCB on the Layer X + 1 network only needs to store the forwarding information for the Layer X + 1 MAC address.
Both Layer X and Layer X + 1 transforms communicate the peer device's I-SID membership, allowing other ABBs to know which I-SID should be leaked. The I-SID information is used to build multicast connections within the Layer X + 1 network area and learn interconnect layers. Where Layer X networks use Mac-in-Mac encapsulation and Layer X + 1 networks use Mac-in-Mac-in-Mac encapsulation, the I-SID information is ABB, Mac-in. -Mac / Mac-in-Mac-in-Used to allow learning Mac joins, so that ABB can encapsulate traffic based on each I-SID.
Where another ABB is used to interconnect L1 / L2 networks, that other ABB is fed with a large metric and provides the shortest path for any BED on the L1 network area. May not be chosen. However, that other ABB may leak I-SID information into the L1 network area and vice versa, allowing network elements to have information about ABB and the first failure on ABB. Allows for faster convergence in the case of events.
If ABB fails, all traffic on the I-SID needs to be rebuilt. I-SID traffic will need to be associated with a different ABB and will cause BCBs within the range of the L1 network to install a new forwarding state. One way to do this is to install a new forwarding state with a different VID, resulting in the installation of two sets of connections. The first set of passes is for the first ABB and the second set of passes is for the second ABB. The forwarding state may be installed according to the failure decision, or it may be pre-computed and installed before the failure occurs. Installing a backup forwarding state with a different VID allows that forwarding state to be installed earlier in time, and as a result, if there is an ABB failure, traffic will be used with a different VID. By tagging, traffic is automatically switched over to another path.
FIG. 5 shows an example of a network element used to realize one embodiment of the present invention. As shown in FIG. 5, the network element includes a data plane 50 and a control plane 60. The data plane 50 is typically configured to perform functions related to data received across input / output cards (I / O cards) 52 that are configured to interface with links on the network. It includes a data card 54 and a switch configuration 56 configured to switch data between the data card and the I / O card. The control plane includes a processor 62, which contains control logic configured to implement the L1 link-state routing process 64 and the L2 link-state routing process 66. Other processes may be implemented in the control logic as well.
The data and instructions associated with the L1 link-state routing process 64 and the L2 link-state routing process 66 may be stored in memory 70 as L1 routing software 72 and L2 routing software 74. One or more databases or tables are also maintained by ABB30, allowing ABB to store information related to routes installed on the L1 and L2 networks. For example, ABB30 includes L1FIB80, L2FIB82, L1 link-state database 84, L2 link-state database 86, and L1 / L2FIB88, which contains a community (eg, I-SID) relationship of interest identifiers between transfer information in two networks. You may have. ABB includes the storage of other software, processes, and information, enabling ABB to perform the above-mentioned functions and other functions commonly implemented in network elements on communication networks.
The functions described above may be implemented as a set of program instructions, which are stored in computer-readable memory and executed on one or more processors on the computer platform associated with the network elements. However, to those skilled in the art, all the logic described here is for individual components, eg integrated circuits such as application specific integrated circuits (ASICs), eg programmable logic devices such as field programmable gate arrays (FPGAs). It will be clear that this can be achieved using the programmable logic used with, or other devices, including microprocessors, state machines, or any combination thereof. Programmable logic can be temporarily or permanently anchored to tangible media, such as read-only memory chips, computer memory, disks, or other storage media. The programmable logic can also be fixed to the computer data signal implemented in the carrier, allowing the programmable logic to be transmitted across interfaces such as computer buses and communication networks. All such embodiments are intended to be within the scope of the present invention.
How both the source and interest multicast groups are encoded in the data plane provided by the above basic techniques for building the shortest path tree is entitled "Provider Link State Bridging", October 2006. It is possible to envision various variants of US Patent Application No. 11 / 537,775 filed on March 2, but with minor modifications to the data plane transfer function performed by ABB.
In one variant, the multicast group address for a given interest group is common to the entire group of BEBs that support the group of interests, and the given source BEB or ABB (multicast) is encoded in a VLAN field. .. In this example, multicast MAC address summarization is not possible, but VLAN information summarization is possible between areas. This is useful because such technologies do not save VLANs, and therefore multi-area solutions dramatically increase network scalability. The summarization can be performed by a generic VLAN transition at the ABB entry, which allows ABB to override the VLAN of the multicast packet with the VLAN value assigned to ABB as the multicast source. The present invention is not limited by the particular way in which a VLAN value is assigned to ABB as a multicast source.
In this variant, the shortest path tree from a given BEB would have only one VLAN wrapper per tree. Therefore, the shortest path tree from BEB A will see (for example) all packets from BEB A tagged with VLAN1, all packets from BEB B tagged with VLAN2, and so on. A Reverse Path Forwarding Check (RFPC) will then be performed on the VLAN instead of the source MAC address. Packets that need to transit between areas flow through ABB onto the shortest path tree in the adjacent area. Packets flowing on the shortest path tree from ABB are simply re-tagged with the VID assigned to ABB as the multicast source, so that ABB is due to the set of multicast sources that transit the area through ABB. "Choke point" point) . So, if 4000 odd VLAN tags are available, each "area" or "level" will eventually have 4000 nodes (BEB, BCB and ABB total), but ABB summaries (and ABB). VID alternative) allows each area to have its own VID space, and the network can grow in size in multiples of 4000 nodes per area.
In another variant, the multicast group address is common as described above, but the source is only encoded with the source MAC address, and the VLAN used is common to all BEDs. Is. In this example, ABB would not be able to summarize any multicast addressing and the packet would pass unchanged.
Referring to FIG. 7, an exemplary PLSB communication network 100 is shown, in which an ABB may be "home" in multiple L1 areas. In other words, an ABB may be served in multiple independent L1 areas. The PLSB communication network 100 is represented together with the L2 area 110 that extends geographically so as to surround several L1 areas 116. In one example, the L1 area may be a metropolitan area network and the L2 area may be a national backbone network. .. The single L2 area 110 includes five ABBs, namely ABB-1 112a, ABB-2 112b, ABB-3 112c, ABB-4 112d, and ABB-5 112e (collectively referred to as ABB 112), and , Includes three other BBs, namely BB-1 114a, BB-2 114b, and BB-3 114c (collectively referred to as BB 114). The PLSB communication network 100 also includes three L1 stub areas, namely L1-A 116a, L1-B 116b, and L1-C 116c (collectively referred to as L1 area 116). L1-A 116a is provided for two ABBs, namely ABB-1 112a and ABB-2 112b. L1-C is provided to three ABBs, namely ABB-3 112c, ABB-4 112d and ABB-5 112e. Note that the L2 area 110 is represented in FIG. 7 as one pseudonode L2PN in each of the L1 areas 116.
When L1 area 116 is served by one or more ABB 112s, the nodes within L1 area 116 are divided into independent "subset" nodes, one for each ABB, where all of one division is made. A node is "closer" to a given ABB in the L1 area than any other ABB. As is common in the field of routing protocols, "close" here means that the sum of the link metrics for the shortest path between a node and a given ABB is the shortest path to any other ABB. Tie brakes where there is a tie, that is, where the sum of the link metrics is the same between the node and two or more ABBs, which means less or the same. A tie breaking mechanism determines that a given ABB is "close". In communication system 100, L1-B 116b is provided for two ABBs, but L1-B 116b is divided into two subsets, as indicated by the separation break 118a. Subset L1-B1 120a is provided to ABB-1 112a and subset L1-B2 120b is ABB-2. Dedicated to 112b. Similarly, L1-C 116c is served in three ABBs, but is divided into three subsets, as indicated by the separation breaks 118b and 118c. Subset L1-C1 122a is served to ABB-3 112c, subset L1-C2 122b is served to ABB-4 112d, and subset L1-C3 122c is served to ABB-5 112e.
It should be noted that ABB-2 112b is provided in two independent L1 areas, namely L1-A 116a and L1-B 116b. When an ABB112 is served in a single L1 area 116, it typically refers to a single L1 FIB to forward data packets as described above. However, for ABB served in multiple L1 areas, there should be multiple L1 FIBs, and one L1 FIB for packets arrives at all ports.
A link to the pseudo node L2PN110 representing the L2 area is advertised to the L1 area 116 by each ABB112. The cost metric for advertisements is usually the same for all ABBs. However, in this example, the metric is larger than half the maximum diameter of L1 area 116, and L2PN110 does not appear on the shortest path in any area. This large metric effectively divides L1 area 116 into independent subset nodes that are "closest" to each ABB112. The I-SID for the total set of "port MAC" and "external" MAC is also advertised with L2PN. For each subtending L1 area subset, each ABB112 advertises a "port MAC" and ISID for each subset at level 2. The different IDs of a subset are contained in the subset's link-state packets. It can be seen that L2PN110 is the root node for the whole tree and therefore its nickname can be used as the root ID for any multicast traffic entering the L1 area.
The L2 pseudonode 110 performs many functions, including the following three: First, the use of large metrics ensures that traffic within the L1 area does not transit to level 2. Second, computing the "closest" subset node of L1 for ABB is simplified to the node on the shortest path to L2PN. Finally, all external port MACs are associated with a single node.
Due to the unicast message, traffic arriving on the L2 port is forwarded according to the L2FIB, and traffic on the L1 port is forwarded according to the L1FIB. These FIBs differ when the destination is in the L1 area but not in the "closest" subset of ABB. In this case, the L2FIB forwards the packet towards the other ABB over the L2 port, but the L1FIB commands the packet to be forwarded over the other L1 port.
The L2 multicast tree with source ABB-2 112b is shown in Figure 7 with a thick thick line 124. Because of the multicast packet, the "closest" subset in L1 116 needs to ensure that the reception of a single copy packet arrives on the L2 port with multiple ABBs of the same L1 because of that packet. is there. In the illustrated L2 multicast tree, multicast packets originating through ABB-2 112d serve three ABBs for L1 area C 116c, namely ABB-3 112c, ABB-4 112d, and ABB-5. Will be duplicated on 112e. Trees rooted in ABB112 are not confined to the "closest" subset, so a root ID for a tree that only covers the "closest" subset cannot be an ABB nickname. However, its root ID can be a nickname for L2PN. As mentioned above, advertising L2PN inevitably produces a "closest" subset and a multicast forwarding tree. It should be noted that the "closest" subset for each B-VID does not necessarily contain the same set of nodes. That is, a different ABB112 may be used for the equal-cost multi-path routing (ECMP) path to L2PN110.
Therefore, in one embodiment of the invention, when a multicast packet arrives at ABB112 on a level 2 port, the route ID of the incoming packet is checked. If the route ID is from another "closest" subset of the same L1 area, the packet will be dropped. Otherwise, its root ID replaces the root ID of L2PN and is forwarded across the L1 tree that covers the "closest" subset of ABB.
To provide symmetry, multicast from the L1 node exits to L2 110 only on the ABB 112 served in the "closest" subset. This means that the L2 multicast tree must have the same structure as the L2 multicast tree rooted at ABB112. However, the route ID cannot have an ABB nickname to prevent multicast traffic from re-entering L1 area 116 from another ABB 122. Therefore, referring again to the communication network 100 illustrated in FIG. 7, ABB-1 112a replicates the packet from ABB-2 112b into L1-B 116b if the packet came from L1-A 116a. It should, but if it came from L1-B 116b, it shouldn't.
The root IDs in L2 for all trees routed to ABB112 serving the same L1 area 116 should not be the same. This is because the trees from each ABB are not independent. The route ID should be clear and easily tested for area identity so that ABB112 discards packets originating from its area rather than forwarding it. Therefore, because of a multicast packet from level 1, if the packet's route ID belongs to the "closest" subset of ABB, it will be swapped to the only "closest" subset route ID and forwarded to all Level 2 ports. To. All its Level 2 ports are part of the "closest" subset multicast tree of the packet's ISID.
A common combination of hardware and software becomes a special computer system, which has one or more processing elements, a computer program stored on storage media, and the computer program is loaded and executed. It controls the computer system and the computer system performs the method described here. The present invention may be incorporated into a computer program product, which includes all features that enable the implementation of the methods described herein and, when loaded within a computing system, these methods. To execute. Storage media refers to any volatile or non-volatile storage device.
A computer program or application in this context means any representation, code, or notation in any language of an instruction set intended to cause a system with information processing capabilities to perform a particular function. The execution may be direct, after one of the following, or after both. a) Conversion to other languages, codes or notations; b) Reproduction of different material forms.
In addition, it should be noted that all of the accompanying drawings are not to scale unless the above statements are inconsistent. Significantly, the invention can be practiced in other particular embodiments without departing from its spiritual or essential qualities, and thus references are described above to indicate the scope of the invention. Rather than writing, it should be made for the following claims.
It should be understood that the embodiments shown in the drawings and described herein may be modified and modified in various ways within the spirit and scope of the invention. Therefore, all matters contained in the above specification and accompanying drawings are intended to be exemplary and not in a limiting sense. The present invention is only limited as defined in the following claims and their equivalents.
8 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US11991074B2 | Cited by | United States of America | Applicant |
| JP2022087146A | Cited by | Japan | Search report |
| WO2008076201A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| WO2009088856A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| US7008A | Cites | United States of America | Search report |
| US9020A | Cites | United States of America | Search report |
44 members in 9 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 12575190 | United States of America | – | |
| 57519009 | United States of America | A | |
| 57519009 | United States of America | A | |
| 2010001587 | Canada | W | |
| 2010001587 | Canada | W | |
| 2009575190 | – | – | – |
| 2010001587 | – | – | – |
| US20090575190 | – | – | – |
| WO2010CA01587 | – | – | – |
Members44
| Document | Office | Kind | |
|---|---|---|---|
| US2008144644A1 | United States of America | A1 | |
| CA2671671A1 | Canada | A1 | |
| WO2008076201A1 | World Intellectual Property Organization (WIPO) | A1 | |
| EP2092692A1 | European Patent Office (EPO) | A1 | |
| KR20090099556A | Republic of Korea | A | |
| US2010020797A1 | United States of America | A1 | |
| CN101663859A | China | A | |
| CA2764632A1 | Canada | A1 | |
| US2010316056A1 | United States of America | A1 | |
| WO2010144418A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CA2776895A1 | Canada | A1 | |
| WO2011041895A1 | World Intellectual Property Organization (WIPO) | A1 | |
| EP2441214A1 | European Patent Office (EPO) | A1 | |
| CN102484604A | China | A | |
| KR20120060810A | Republic of Korea | A | |
| EP2092692A4 | European Patent Office (EPO) | A4 | |
| US8223668B2 | United States of America | B2 | |
| EP2486703A1 | European Patent Office (EPO) | A1 | |
| CN102648605A | China | A | |
| KR20120097377A | Republic of Korea | A | |
| US2012233350A1 | United States of America | A1 | |
| US8270319B2 | United States of America | B2 | |
| US2012263075A1 | United States of America | A1 | |
| JP2012529855A | Japan | A | |
| US2012300774A1 | United States of America | A1 | |
| JP2013507797AThis record | Japan | A | |
| CN101663859B | China | B | |
| RU2011153500A | Russian Federation | A | |
| RU2012116597A | Russian Federation | A | |
| EP2685669A1 | European Patent Office (EPO) | A1 | |
| RU2507698C2 | Russian Federation | C2 | |
| EP2092692B1 | European Patent Office (EPO) | B1 | |
| EP2486703A4 | European Patent Office (EPO) | A4 | |
| KR101421511B1 | Republic of Korea | B1 | |
| US2014226527A1 | United States of America | A1 | |
| US2014301244A1 | United States of America | A1 | |
| US8879424B2 | United States of America | B2 | |
| EP2441214A4 | European Patent Office (EPO) | A4 | |
| RU2544766C2 | Russian Federation | C2 | |
| US9001829B2 | United States of America | B2 | |
| RU2013144245A | Russian Federation | A | |
| RU2013144973A | Russian Federation | A | |
| BR112012007996A2 | Brazil | A2 | |
| BR112012000198A2 | Brazil | A2 |
6 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 2013507797
- Publication, DOCDB
- 2013507797
- Publication, EPODOC
- JP2013507797
- Application
- 2012532428
- Application, DOCDB
- 2012532428
- Application, EPODOC
- JP20120532428
Titles2
- Japanese
- ルーティング情報を交換し、複数のネットワーク領域を横断して接続を構築する方法及び装置
- English
- Methods and devices for exchanging routing information and building connections across multiple network areas
Classification
- CPC, 9
- H04L12/462
- H04L12/46
- H04L12/4641
- H04L45/02
- H04L45/026
- H04L45/04
- H04L45/16
- H04L45/18
- H04L45/66
- IPC, 4
- H04L12 701
- H04L45 02
- H04L45 16
- H04L45 18
Designated states4
- Regional, 4
- Zimbabwe
- Turkmenistan
- Türkiye
- Togo