System and a method for routing traffic in an MPLS network

Abstract

A system and a method are provided for use in an MPLS network, wherein the system comprises at least one routing element configured to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances, wherein each of the multi instances is associated with a unique database, and wherein the at least one routing element comprises a managing entity configured to: manage a plurality of traffic engineering software agents each associated with a respective database, and allocate available resources to respective instances; update at least one of the plurality of databases; and for traffic that is about to be conveyed via a specific instance, determine a neighboring instance through which said traffic will be conveyed, based on information comprised in the database associated with the specific instance through which said traffic will be conveyed.

Claims

1. A system for use in an MPLS network, said system comprising: a) a routing element that shares one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances; b) a plurality of routing protocol instances each of which is associated with a database from among a plurality of databases; c) a managing entity that manages plurality of traffic engineering software agents, and dynamically selects a database from among the plurality of databases, to be associated with a traffic engineering software agent from among said plurality of the traffic engineering software agents, wherein said traffic engineering software agent conveys traffic along a path being currently used for conveying traffic, and wherein said selection of a database is made based on an ad hoc selection of a database from among the plurality of databases; d) wherein said managing entity updates databases associated with respective routing protocol instances and based on that update, allocates available resources to routing protocol instances via which traffic is being conveyed; and e) wherein said managing entity conveys traffic via a specific routing protocol instance, wherein said specific routing protocol instance is associated with the one or more databases currently selected from among the plurality of databases.

2. The system of claim 1, wherein for traffic that is being conveyed via a specific routing protocol instance, said managing entity is further configured to determine a neighboring routing protocol instance through which said traffic will be conveyed, based on information comprised in the database associated with the specific routing protocol instance through which said traffic is being conveyed.

3. A method for use in an MPLS network by a managing entity comprises in a routing element, wherein said routing element is configured to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances, and wherein each of the routing protocol instances is dynamically associated with a database selected from among a plurality of databases, said method comprising the steps of: managing a plurality of traffic engineering software agents, and to dynamically select a database from among the plurality of databases, to be associated with a traffic engineering software agent from among said plurality of the traffic engineering software agents, wherein said traffic engineering software agent is used for conveying traffic along a path being currently used for conveying traffic, and wherein said selection of a database is made based on an ad hoc selection of a database from among the plurality of databases, updating databases associated with respective routing protocol instances and based on that update, to allocate available resources to routing protocol instances via which traffic is being conveyed; and conveying traffic via a specific routing protocol instance, wherein said specific routing protocol instance is associated with the one or more databases currently selected from among the plurality of databases.

4. The method of claim 3, wherein for traffic being conveyed via a specific routing protocol instance, the method comprises determining a neighboring routing protocol instance through which said traffic is being conveyed, based on information comprised in the database associated with the specific routing protocol instance through which said traffic is being conveyed.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate several embodiments of the disclosure and, together with the description, serve to explain the principles of the embodiments disclosed herein.

(2) FIG. 1. illustrates a schematic overview of multi-instance TE network topology, construed in accordance with an embodiment of the present invention; and

(3) FIG. 2. illustrates a schematic overview of MI-RTR Routing and Forwarding table structure, construed in accordance with another embodiment of the present invention.

DESCRIPTION OF EXEMPLARY EMBODIMENTS

(4) Some of the specific details and values in the following detailed description refer to certain examples of the disclosure. However, this description is provided only by way of example and is not intended to limit the scope of the invention in any way. As will be appreciated by those skilled in the art, the claimed method and device may be implemented by using other methods that are known in the art per se. In addition, the described embodiments comprise different steps, not all of which are required in all embodiments of the invention.

(5) Let us consider the following example illustrated in FIG. 1, in which a communication system is construed in accordance with an embodiment of the present disclosure and operative in an MPLS network. The communication system which is depicted in this figure, comprises a plurality of routers associated with multiple instances (i.e. multi instances capable routers) MI-RTR.sub.1 to MI-RTR.sub.4 and a plurality of single instances routers (SI-RTR), each associated with a single instance.

(6) The prior art solutions previously adopted by the industry, relied on selecting one of the instances from among the multi instances available, to operate as a fixed instance through which traffic will be conveyed while using a single database associated with that instance.

(7) The present invention provides another solution that relies on a completely different underlying principle. According to an embodiment of the present invention, each of the multi instances is associated with its own database, and the selection is made based on an ad hoc determination as to which of the databases from among the plurality of databases will be used when determining a path along which traffic will be conveyed. Another challenge associated with this solution that needs to be overcome, is, how to manage this plurality of databases, and to allocate resources there-between. To do that, each database associated with one of the multi instances, is provided with a traffic engineering software agent. A managing entity comprised in the router is configured to update each of the databases, for example updates about changes that occurred to their adjacent neighbors, and to determine which of the neighbors will be used for traffic conveying.

(8) Multiprotocol Label Switching (MPLS) traffic engineering software enables an MPLS backbone to replicate and expand upon the traffic engineering capabilities of Layer 2 networks. Traffic engineering is essential for service provider's and Internet service provider's backbones that support a high transmission capacity in networks that are very resilient. MPLS traffic engineering provides an integrated approach to traffic engineering. With MPLS, traffic engineering capabilities are integrated within Layer 3, which optimizes the routing of IP traffic, given the constraints imposed by the backbone capacity and topology.

(9) The routers' IS-IS level capabilities can be configured globally and/or on a per-interface basis. The interface level parameters may specify the interface's routing level as well as the neighbor capabilities and parameters defining the adjacencies that are established. Typically, when an IS-IS instance is enabled, the router may operate either as a level 1 and/or as a level 2 router with associated databases. The routers run separate shortest path first (SPF) calculations for the level 1 area routing and for the level 2 multi-area routing, in order to create an IS-IS routing table for the IS-IS instance.

(10) As may be seen from this FIG. 1, both MI-RTR.sub.3 and MI-RTR.sub.4 are associated (e.g. participate in a broadcast circuit) each with instances B and C. There is a plurality of RSVP-TE tunnels that extend between MI-RTR.sub.3 and MI-RTR.sub.4, where each of these tunnels is associated with a different IS-IS instance.

(11) Resource Reservation Protocol-Traffic Engineering (RSVP-TE) is an extension of the Resource Reservation Protocol (RSVP) for traffic engineering. It supports the reservation of resources across an IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature of the packet streams they want to receive (e.g. bandwidth, jitter, maximum burst, and the like).

(12) RSVP-TE as described in RFC 3209 and RFC 5151 generally allows the establishment of MPLS label switched paths (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops.

(13) In the present example, RSVP-TE protocol is used to establish a tunnel between two end-points (MI-RTR) in the communication network, based on Constrained Shortest Path First (CSPF) information derived from a single IS-IS TE instance.

(14) During operation, the operator of the communication network is able to establish a tunnel which is associated explicitly with a given IS-IS instance, selected from among a plurality of instances supported by the respective MI-RTR.

(15) When establishing a tunnel, the relevant MI-RTR may use the same set of virtual loopback interfaces that are used as RSVP signaling source which serve as the destinations for all local IS-IS instances configured on the respective devices.

(16) An MI-RTR may be configured with multiple instances to support installation of relevant IS-IS routes to a single Route Information Base (RIB) table. In order to distinguish between the different paths of IS-IS reaching the same destination, each IS-IS instance is preferably provided with a user configured admin-distance preference.

(17) Using the RIB table, an associated processor performs a route selection based on the admin-distance value (a lower value means a higher priority) and the selected route is then introduced to the Forwarding Information Base (FIB) table.

(18) If an MI-RTR is associated with multiple RSVP-TE tunnels targeted to a destination router, where each of the RSVP-TE tunnels is associated with a different IS-IS instance, the RIB table is preferably used by the processor to select one of the RSVP-TE tunnels by implementing admin-distance algorithm.

(19) In case of an MI-RTR acting as a head-end router (i.e. an ingress point to an RSVP-TE tunnel) is used to establish the RSVP-TE tunnels in a dedicate MPLS table, the MI-RTR is used for resolution of recursive protocol next-hop routes such BGP, which in turn may require MPLS reachability to the destination (i.e. BGP Labelled-unicast address-family).

(20) Moreover, when two adjacent MI-RTRs belong to one or more multiple IS-IS-TE instances, a special handling is required for allocating bandwidth on the shared resource interface. An RSVP tunnel may require a certain allocation of bandwidth at an interface for a given IS-IS-TE instance. Yet, the bandwidth allocation may have to be changed for the very same interface, when another instance associated with that router is about to be used. An MI-RTR may be configured with multiple logical interfaces (sub-interfaces), each for a different IS-IS-TE instance, and using a shared resource calculation in an RSVP in order to enable affecting changes while switching from one instance to another.

(21) The question of RSVP-TE tunnel prioritization across multiple instances may be determined by applying the first-come-first-served mechanism, where an RSVP preemption mechanism (soft or hard) is used to establish RSVP-TE tunnels based on the IS-IS TED information available.

(22) FIG. 2 illustrates an example of a schematic overview of MI-RTR Routing and Forwarding table, construed in accordance with another embodiment of the present invention. As may be seen in this example, the table comprises details of an MI-RTR system, where IS-IS is associated with multiple Traffic-engineering databases, and the RSVP is updated with information in the IS-IS TED per instance. The IS-IS Information is preferably included in an IPv4/IPv6 routing table, and the RSVP-TE information (Tunnel resolution) is comprised in an MPLS-NH table.

(23) Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.