CA2429634A1 - System, device, and method for limiting tunnel traffic in an information communication network - Google Patents
System, device, and method for limiting tunnel traffic in an information communication network Download PDFInfo
- Publication number
- CA2429634A1 CA2429634A1 CA002429634A CA2429634A CA2429634A1 CA 2429634 A1 CA2429634 A1 CA 2429634A1 CA 002429634 A CA002429634 A CA 002429634A CA 2429634 A CA2429634 A CA 2429634A CA 2429634 A1 CA2429634 A1 CA 2429634A1
- Authority
- CA
- Canada
- Prior art keywords
- tunnel
- end device
- tail
- destination
- serviced
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
Abstract
There is disclosed an apparatus and method for limiting tunnel traffic in a network. Traffic engineering tunnels are used to direct traffic along a predefined path, which may differ from the path that internet protocol (IP) routing would determine. Interior gateway rotocol ((IGP) cut through will allow the forwarding of all destinations downstream of a tunnel through the tunnel, without the operator needing to specify a forwarding equivalence class (FEC). But congestion in the tunnel and network instability may result from this approach. A solution to these problems is disclosed which limits the traffic in the tunnel to only that with destination addresses of the tunnel's egress router or nodes directly supported thereby. Other solutions are disclosed which allow tunnel traffic to nodes having destination addresses other than those being directly supported by the tunnel's egress router. All of these solutions are achieved in both pre-determined forwarding entry and dynamic packet-by packet embodiments.
Description
SYSTEM, DEVICE, AND METHOD FOR LIMITING TUNNEL TRAFFIC
IN AN INFORMATION COMMUNICATION NETWORK
FIELD OF THE INVENTION
The present invention relates generally to information communication networks and, more particularly, relates to limiting tunnel traffic in such 1o networks.
BACKGROUND OF THE INVENTION
Computer networks are having more and more of an impact on human interaction with the passage of time. For one example, the Internet, which is currently used by only about 5% of worldwide human population, is being recognized as a boon to mankind. Accordingly, the Internet, is rapidly 2o growing in usage on a global basis, is bringing a vast array of useful information to those members of our global village who are Internet users, and is fostering communication between diverse cultures located around the globe by way of the email system. As is widely known, the Internet has its foundation in globally-deployed computer networks. For other examples, one could cite rapidly growing non-Internet local area network (LAN) usages of computer networks in industry, academia, government, and elsewhere.
Accordingly, information (traffic) on all of these networks is building at an accelerating pace which is creating an urgent need for finding additional solutions to network traffic congestion and traffic-induced network-instability 3o problems.
One such solution involves the use of what is known in the art as "tunnels". These are computer software/protocol network-constructs which typically employ "labels" as in the multi protocol label system (MPLS). For example, these labels can override destination addresses in the headers of network information or data packets received at a router. This router may be the input router to a particular tunnel, where the labels allow forwarding such network information or messages or binary-styled data packets from the input roister via the tunnel to its exit located on its tail-end roister or network device. These tunnels can provide rapid movement of traffic from entrance to exit devices, thus reducing the handling of this traffic at every network device or node therebetween and speeding-up the process of communication. In other words, traffic engineering tunnels are used to direct traffic along a predefined path, which may differ from the path that IP routing (Internet Protocol routing) would have otherwise determined. This one network feature, tunneling, can thus be a step in the right direction with regard to 1o solving or managing the increasing network traffic problem.
However, tunnels have certain limitations. One of the problems with tunneling is that it can cause network instability as it is being incorporated into a network. For example, consider a tunnel being created between an ingress or head-end roister and an egress or tail-end roister in a network having a number of other roisters, switches, and other network nodes with links connecting all devices. Traffic that is upstream of the tunnel's ingress roister and destined for roisters downstream of the tunnel's egress roister will be directed towards the ingress roister to try to get a "quick ride through the tunnel". This creates an instability in the network since traffic across the 2o network, which otherwise would or should have been generally uniformly distributed, is being subjected to a perturbation caused by a single tunnel being introduced into the network and attracting traffic to its head-end. In other words, normally when an MPLS Traffic Engineering (TE) tunnel is created, it causes an aggregation of traffic to the tunnel's tail-end roister, since the newly created tunnel appears to be the best path to all destinations beyond the tail-end roister. In many cases this is not desirable. When initially configuring MPLS TE tunnels, there is a problem with network stability; but, once tunnels are configured everywhere the problem is reduced. An approach to a solution to this instability problem is to try to (1) introduce a 3o plurality of tunnels in a generally uniformly-distributed manner throughout the network and (2) introduce them all generally at the same time. If successful, under these circumstances, the above-noted instabilities can be reduced and might be avoided. However, this approach is not without frustration because it can be a challenging problem to uniformly introduce a plurality of tunnels into and across a complex network at approximately the same time.
Another problem with tunneling and related to the scenario just described is a traffic congestion problem within the tunnel itself. This problem is created when all or most of traffic upstream of the tunnel's head-end router that is destined for network devices or other nodes downstream of the tunnel's tail-end router would like to use the tunnel to get there. Under to these circumstances, traffic-handling capacity of the tunnel can quickly be exceeded and congestion and delay, including loss of information, can result.
This problem occurs frequently when using current protocols such as, for example, a currently-popular network protocol known as "Interior Gateway Protocol (IGP) cut through". IGP cut through is used within local area 15 networks (LANs) or within autonomous systems (ASs) [to be contrasted with wide area networks (WANs) which connect one or more LANs or ASs via gateways]. IGP cut through is described in an IETF (Internet Engineering Task Force) draft entitled "Calculating IGP Routes Over Traffic Engineering Tunnels", is available on line at "draft-hsmit-mpls-igp-spf-OO.txt", was 2o authored by Messrs. Henk Smit and Naiming Shen and published in June, 1999, and is incorporated by reference herein in its entirety. The main advantage of IGP cut through is that packets with destination addresses downstream of the egress router of a tunnel will automatically use the tunnel without a human operator needing to specify those destinations as part of a 25 forwarding equivalency class (FEC). Thus, all destinations downstream of the tunnel's exit become part of an implied FEC (IFEC). But, using IGP cut through causes the human operator to lose his/her ability to direct traffic through the tunnel which can result in a problem of severe tunnel traffic congestion.
3o These problems of network instability and tunnel congestion are addressed by the welcome arrival of the present invention which not only offers a solution to these problems but does so while also allowing continued usage of the popular IGP cut through protocol.
SUMMARY OF THE INVENTION
Embodiments of the present invention include methodology, apparatus and/or computer program product for limiting traffic volume in a tunnel in an information communication network. Such traffic volume to limiting initially involves establishing a tunnel between a head-end router and a tail-end router in the network and then determining which network devices are directly-connected to the tail-end router. Then such traffic volume limiting involves routing certain information destined for such directly-connected network devices from head-end router to tail-end router through 15 the tunnel. Accordingly, other information not destined for directly-connected network devices is not routed through the tunnel thereby limiting traffic volume in the tunnel.
In another aspect of the present invention the tunnel is a traffic engineered MPLS tunnel and routing of that certain information includes 2o affixing a label to that certain information identifying the tail-end router as its destination, thereby allowing any transit routers in the tunnel to switch-forward that certain information based solely on the destination on the label.
This reduces the processing load on those transit routers, freeing-up such transit routers for other tasks as may be needed and speeding-up transit time 25 for that certain information through the tunnel. The tail-end router removes the label and forwards that certain information based on destination addresses contained in that certain information to hosts and subnets directly connected from and supported by the tail-end router.
In yet another aspect of the present invention the head-end router 3o includes a link state database allowing such router to determine the network devices to which its tail-end router is directly and indirectly connected. The information destined for other than such directly-connected hosts and subnets is routed by routes other than through the tunnel.
IN AN INFORMATION COMMUNICATION NETWORK
FIELD OF THE INVENTION
The present invention relates generally to information communication networks and, more particularly, relates to limiting tunnel traffic in such 1o networks.
BACKGROUND OF THE INVENTION
Computer networks are having more and more of an impact on human interaction with the passage of time. For one example, the Internet, which is currently used by only about 5% of worldwide human population, is being recognized as a boon to mankind. Accordingly, the Internet, is rapidly 2o growing in usage on a global basis, is bringing a vast array of useful information to those members of our global village who are Internet users, and is fostering communication between diverse cultures located around the globe by way of the email system. As is widely known, the Internet has its foundation in globally-deployed computer networks. For other examples, one could cite rapidly growing non-Internet local area network (LAN) usages of computer networks in industry, academia, government, and elsewhere.
Accordingly, information (traffic) on all of these networks is building at an accelerating pace which is creating an urgent need for finding additional solutions to network traffic congestion and traffic-induced network-instability 3o problems.
One such solution involves the use of what is known in the art as "tunnels". These are computer software/protocol network-constructs which typically employ "labels" as in the multi protocol label system (MPLS). For example, these labels can override destination addresses in the headers of network information or data packets received at a router. This router may be the input router to a particular tunnel, where the labels allow forwarding such network information or messages or binary-styled data packets from the input roister via the tunnel to its exit located on its tail-end roister or network device. These tunnels can provide rapid movement of traffic from entrance to exit devices, thus reducing the handling of this traffic at every network device or node therebetween and speeding-up the process of communication. In other words, traffic engineering tunnels are used to direct traffic along a predefined path, which may differ from the path that IP routing (Internet Protocol routing) would have otherwise determined. This one network feature, tunneling, can thus be a step in the right direction with regard to 1o solving or managing the increasing network traffic problem.
However, tunnels have certain limitations. One of the problems with tunneling is that it can cause network instability as it is being incorporated into a network. For example, consider a tunnel being created between an ingress or head-end roister and an egress or tail-end roister in a network having a number of other roisters, switches, and other network nodes with links connecting all devices. Traffic that is upstream of the tunnel's ingress roister and destined for roisters downstream of the tunnel's egress roister will be directed towards the ingress roister to try to get a "quick ride through the tunnel". This creates an instability in the network since traffic across the 2o network, which otherwise would or should have been generally uniformly distributed, is being subjected to a perturbation caused by a single tunnel being introduced into the network and attracting traffic to its head-end. In other words, normally when an MPLS Traffic Engineering (TE) tunnel is created, it causes an aggregation of traffic to the tunnel's tail-end roister, since the newly created tunnel appears to be the best path to all destinations beyond the tail-end roister. In many cases this is not desirable. When initially configuring MPLS TE tunnels, there is a problem with network stability; but, once tunnels are configured everywhere the problem is reduced. An approach to a solution to this instability problem is to try to (1) introduce a 3o plurality of tunnels in a generally uniformly-distributed manner throughout the network and (2) introduce them all generally at the same time. If successful, under these circumstances, the above-noted instabilities can be reduced and might be avoided. However, this approach is not without frustration because it can be a challenging problem to uniformly introduce a plurality of tunnels into and across a complex network at approximately the same time.
Another problem with tunneling and related to the scenario just described is a traffic congestion problem within the tunnel itself. This problem is created when all or most of traffic upstream of the tunnel's head-end router that is destined for network devices or other nodes downstream of the tunnel's tail-end router would like to use the tunnel to get there. Under to these circumstances, traffic-handling capacity of the tunnel can quickly be exceeded and congestion and delay, including loss of information, can result.
This problem occurs frequently when using current protocols such as, for example, a currently-popular network protocol known as "Interior Gateway Protocol (IGP) cut through". IGP cut through is used within local area 15 networks (LANs) or within autonomous systems (ASs) [to be contrasted with wide area networks (WANs) which connect one or more LANs or ASs via gateways]. IGP cut through is described in an IETF (Internet Engineering Task Force) draft entitled "Calculating IGP Routes Over Traffic Engineering Tunnels", is available on line at "draft-hsmit-mpls-igp-spf-OO.txt", was 2o authored by Messrs. Henk Smit and Naiming Shen and published in June, 1999, and is incorporated by reference herein in its entirety. The main advantage of IGP cut through is that packets with destination addresses downstream of the egress router of a tunnel will automatically use the tunnel without a human operator needing to specify those destinations as part of a 25 forwarding equivalency class (FEC). Thus, all destinations downstream of the tunnel's exit become part of an implied FEC (IFEC). But, using IGP cut through causes the human operator to lose his/her ability to direct traffic through the tunnel which can result in a problem of severe tunnel traffic congestion.
3o These problems of network instability and tunnel congestion are addressed by the welcome arrival of the present invention which not only offers a solution to these problems but does so while also allowing continued usage of the popular IGP cut through protocol.
SUMMARY OF THE INVENTION
Embodiments of the present invention include methodology, apparatus and/or computer program product for limiting traffic volume in a tunnel in an information communication network. Such traffic volume to limiting initially involves establishing a tunnel between a head-end router and a tail-end router in the network and then determining which network devices are directly-connected to the tail-end router. Then such traffic volume limiting involves routing certain information destined for such directly-connected network devices from head-end router to tail-end router through 15 the tunnel. Accordingly, other information not destined for directly-connected network devices is not routed through the tunnel thereby limiting traffic volume in the tunnel.
In another aspect of the present invention the tunnel is a traffic engineered MPLS tunnel and routing of that certain information includes 2o affixing a label to that certain information identifying the tail-end router as its destination, thereby allowing any transit routers in the tunnel to switch-forward that certain information based solely on the destination on the label.
This reduces the processing load on those transit routers, freeing-up such transit routers for other tasks as may be needed and speeding-up transit time 25 for that certain information through the tunnel. The tail-end router removes the label and forwards that certain information based on destination addresses contained in that certain information to hosts and subnets directly connected from and supported by the tail-end router.
In yet another aspect of the present invention the head-end router 3o includes a link state database allowing such router to determine the network devices to which its tail-end router is directly and indirectly connected. The information destined for other than such directly-connected hosts and subnets is routed by routes other than through the tunnel.
Alternative embodiments of the present invention include limiting traffic in the tunnel by defining subsets of traffic received by the head-end router and forwarding over or through the tunnel at least one of those subsets. In particular implementations, subsets forwarded over the tunnel are destined for the tail-end router or for nodes or devices directly served (one hop in certain protocols) by the tail-end router.
Further alternative embodiments include limiting traffic in a multiplicity of tunnels extending from the head-end router by defining a like multiplicity of subsets of traffic received by the head-end router and to forwarding each one of those subsets over a different one of the tunnels.
In particular implementations, subsets forwarded over the tunnels are destined for respective tail-end routers or for nodes or devices directly served (one hop in certain protocols) by those tail-end routers.
In a system aspect of the present invention for controlling traffic in a 15 network, determination logic is operatively coupled within the network employing an appropriate protocol to determine a first subset of network devices which are no more than a selected number of hops (N hops) away from the tail-end router. The head-end router forwards over the tunnel a second subset of traffic destined for the tail-end router and/or the first subset 20 of network devices or any one or more of these devices. In a further feature, control logic measures level or volume of traffic in the tunnel and adjusts the level or volume by changing the number (N) of hops in, and therefore the number of network devices in, the first subset.
In another system aspect of the present invention for limiting traffic in 25 an information communication network, a subset of additional network devices directly supported by or within N-hops from the tail-end router is determined. Then by using the Dijkstra algorithm or by other ways the shortest path from the head-end router to each node or device in the subset is determined. Thereafter, any tunnels connected from the head-end router to 3o any of these nodes or devices having a metric less than its corresponding shortest path is determined. And, entries in the head-end router's router or forwarding table are filled with any tunnel or tunnels shorter than any of their corresponding shortest paths, but only with those having the minimum metric. In a further feature, absent any tunnel or tunnels shorter than any of their corresponding shortest paths, entries in the table are filled with any tunnel or tunnels equal to their corresponding shortest paths. In yet a further feature, absent any of the above-mentioned tunnels, entries in the table are filled with neighbor nodes forming routes) having the minimum metric or shortest path.
It is therefore advantageous and beneficial to employ the present invention in computer networks in which turulels are utilized, to avoid 1o destabilization and congestion problems associated with those tunnels that otherwise do not limit their respective traffic levels or volumes, whereby overall speed and efficiency of communication in the network is enhanced.
The foregoing and other objects and advantages of the invention will be appreciated more fully from the following further description thereof with 2o reference to the accompanying drawings wherein:
Fig. 1 is a schematic diagram of an information communication network illustrating both multiple routes between a tunnel's head-end and tail-end roofers and a plurality of network devices directly and indirectly supported by the tail-end router, and in which embodiments of the present 25 invention can be used to advantage;
Fig. 2A is a schematic diagram of information or data packets received by tunnel head-end router A101 of Fig. 1;
Fig. ~B is a prior art illustration of a head-end or ingress router's map table or routing table or forwarding entry table in which destination 3o addresses of incoming packets of information and/or data are mapped to particular outgoing interfaces or ports on such router;
Fig. 2C is an illustration of a head-end or ingress-router's map table or routing table or forwarding entry table filled with table entries in conformance with an embodiment of the present invention in which destination addresses of certain subsets of traffic or incoming packets of information and/or data are mapped to particular outgoing interfaces or ports on such router;
Fig. 3 is a flowchart illustrating the prior art approach to usage of tunnels in information communication networks;
Fig. 4 is a flowchart illustrating an algorithm utilized by an embodiment of the present invention;
Fig. 5 is a flowchart illustrating an algorithm utilized in the process of 1o filling the table entries in accordance with another embodiment of the present invention; and, Fig. 6 is a flowchart illustrating an algorithm associated with a system for controlling level or volume of tunnel traffic in accordance with principles of the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
Referring to Fig.1, there is depicted an information communication 2o network including multiple routers A, B, C, D, E, and F as well as subnets and 108 connected by various links. More specifically, ingress or head-end router A101 is shown with an input 125 which receives traffic or information or generic packet 123 (more detail about these packets is discussed in connection with Fig. 2A). Router A101 may have many output ports but shows only two output ports or interfaces 1 and 2 connected by link110 to router B102 and link 109 to router C104 respectively. Link 109 is depicted as a tunnel and link 110 is depicted as other than a tunnel and could be a link based on OSPF (Open Shortest Path First) or some other protocol. Router 8102 is connected via link 110 to tail-end or egress router E. Router C104 is 3o connected via tunnel 109 to router D105 which, in turn, is connected via tunnel 109 also to tail-end router E103. Thus, there are two pathways shown between ingress and egress routers in this Fig., one being a tunnel and the other not being a tunnel. Finally, Router E103 indirectly connects to subnet 108 through roister F106 via links 112 and 113 (two hop counts in certain protocols), but roister E103 directly connects to subnet 107 via link 111 (one hop count in certain protocols). Each subnet is an autonomous networle and would typically contain roisters, switches, host computers and other network nodes, each such item having its own address within its autonomous network.
As is understood by those familiar with this art, a tunnel involves technology that enables a first network to send its data by way of another network's connections, typically by encapsulating a first network's protocol to within packets carried by the second network. For example, one can employ MPLS which is an integration of Layer 2 and Layer 3 technologies and uses labels which override the destination addresses of the packets. Thus, a hard-coded communication pathway is created based on these labels having a particular destination and such pathway is Balled a "label-switched path 15 (LSP) tunnel". Any roisters internal to such tunnel may be directly accessed lay other roisters in the network to perform routing functions independent of their otherwise dedicated usage as transit roisters within the tunnel.
Also, as understood by those familiar with this art, there are various protocols that have been adopted for exchanging routing information within a 2o LAN and between multiple LANs within the same AS. These are known as interior gateway protocols (IGPs). OSPF and RIP are example IGPs that can be used to exchange routing information within an autonomous system (AS) or LAN such as within subnet 107 or within subnet 108. OSPF establishes links throughout the network by having roisters broadcast individual link 25 metric information to all other roisters. This is contrasted with RIP that establishes links throughout the network by having roisters advertise their data to only neighboring roisters which, in turn, pass on the information only to successive neighboring roisters. The former class is called link state routing protocols and the latter class is called distance-vector protocols. The tunnel of 3o Fig. 1 can be constructed as an LSP tunnel and the other links shown can be constructed in accordance with an IGP.
_g_ Fig. 2A shows certain characteristics of a number of packets 114,117, 121, and 122. In actuality, each packet, including the packets 114, 117,121, 122, and 123 (shown in Fig.1), includes a destination address field indicating the final destination of the packet, a source address field ("FROM") indicating the source of the packet, and a data payload. Each packet typically passes through a number of roisters along the way from the source to the destination.
Specifically, each roister determines a "next hop" roister for each packet, and forwards the packet to the "next hop" roister. For convenience, Fig. 2A shows a "TO" field representing the "next hop" roister for each packet. It should be 1o noted that the "TO" field is not an actual field within the packets. For packets 114,117,121, and 122, the "FROM" field and the "PAYLOAD" field are left blank, since these fields are not germane to comprehension of the described embodiments of the present invention. In packet 114, the "T0'° field shows roister A101 and the destination address field shows "Internal Subnet 107."
z5 Tllis packet information is interpreted as follows: the packet came from some unknown upstream network node and was sent to Roister A101 as the "next hop" roister. Roister A101 forwards or routes the packet toward a particular node internal to subnet 107 for which a specific address is provided in this packet's header and depicted herein as "Internal Subnet 107". The payload 2o field contains whatever data (binary 1's and 0's) is intended for that particular node destination. Packet 117 contains similar information in its fields, but its destination address is different from that of packet 114 - packet 117 is destined for a particular node internal to or within autonomous subnet 108.
Such particular node's address is intended to be represented by "Internal 25 Subnet 108" in this illustration. Packets 121 and 122 differ from packets and 117 primarily in their respective destination addresses, where packets 121 and 122 are destined for tunnel tail-end roister E103 and roister F106 respectively, rather than nodes within the subnets 107 and 108. Further detailed discussion of these packets will be presented hereinbelow.
3o Referring next to both Figs. 2B and 2C, Fig. 2B shows a prior art map table for purposes of comparison with Fig. 2C, which reflects a map table in conformance with principles of the present invention. These tables pictorially represent functional essence of operation of certain computer hardware, firmware and/or software in router A101 of Fig. 1 and are thus tables of binary numbers or binary values. However, such values are not shown but are represented by their functional equivalents in English language and decimal numbers to enhance comprehension of the various embodiments of the present invention. A table representation similar to these, but with different information, can be associated with each router of the network of Fig. 1. These tables show columns entitled "Packet number" and "Forwarding Entry'°. Packet number is not necessarily an item maintained in 1o these mapping or router tables, and is shown here as a convenient identifier for discussion purposes. On the other hand, Forwarding Entry including its sub-columns entitled "Destination Address" (DA), "Outgoing Interface" and "Label Added?" are included in the router tables for substantive operational purposes. "The first column and first row or tuple entry in the tables is 15 packet 114 and is similar to the generic packet 123 depicted in Fig. 1.
Corresponding to packet 114 is a destination address binary value corresponding to a particular node within subnet 107, an outgoing interface binary value corresponding to interface or port #2 of router A101, and a binary value corresponding to answer "yes" to the question of whether or not 2o a label is added to this packet. Similar binary values are associated with the table entries for the other packets shown.
With specific regard to prior art Fig. ~B, packets 114 through 1~2 are shown having destination addresses of either subnet 107, subnet 108, router E103 or router F106. (As noted earlier, a designation of "subnet 107" for 25 destination address means a particular node within subnet 107 and is illustrated in this manner for purposes of convenience, since the internals of subnet 107 are not shown in order to enhance clarity of presentation. Thus the repetitive destination address designation of "subnet 107" also for packet numbers 115,116, and 118 may mean either the same node as - or different 3o nodes from - the particular node within subnet 107 to which packet 114 is destined.) As can be seen, in Fig. 2A, all packets exit router A101 via outgoing interface or port #2 and all have a label added. All of these packets are said to belong to the same forwarding equivalence class (FEC), since they all exit the router by way of the same port with the same label. In typical router construction, there are multiple printed circuit boards or "cards" associated with the multiplicity of outgoing interfaces or ports in the router, and a card may have more than one port associated with it. Further discussion of router construction detail at this level, however, is not essential to full comprehension of the presented embodiments of the present invention.
Next, with specific regard to Fig. 2C, a map table in accordance with principles reflected in embodiments of the present invention is shown. A
1o principal difference between this table and the one of Fig. 2B is the indication that nodes having destination addresses within subnet 108, such as those associated with packets 117,119, and 120, all do not have labels added, and all are routed out outgoing interface #1 instead of interface #2. Thus, rather than have all incoming packets that are destined for addresses downstream of router E103 go out interface #2 (to the tunnel entrance), now, in accordance with principles of the present invention, only certain incoming packets (a subset of the incoming packets) that are destined for addresses downstream of router E103 go out interface #2.
In operation, referring to Figs. 1, 2A, 2B, and 2C collectively, traffic or 2o packets, such as packet 114, are serially received by head-end router A101 at input 125. Packet 114 would ordinarily contain header information which would show (in the °'FROM" field of the header) where it came from (either a local device within this particular LAN or AS or from a different or remote LAN or AS via a network "gateway"). The header also shows where the packet is heading to (in the "DESTINATION ADDRESS" field of the header), which, in this case, is a node within internal subnet 107. Upon receipt of this packet, router A101 examines the packet's destination address, and compares the packet's destination address against destination address entries in the table of Fig. 2C. (For purposes of enhancing clarity of presentation, a limited 3o number of only nine entries are presented in the tables of Fig.2B and Fig.
2C, those entries all being related to tail-end routers and downstream routers E103 and F106 respectively, and depicted subnets 107/108. It should be understood, however, that the network can be much larger than that shown, with a vast number of subnets and/or network devices and host computers, and with a corresponding vast number of destination addresses). A match is found between the arriving packet's destination address and a destination address entry in the table, i.e. a node within subnet 107. Thus, the first row or tuple of the table of Fig. 2C represents a matched association between the binary-numbered destination address contained in packet 114 entered in the first column, and the binary numbered address of a particular node within subnet 107 stored in the first row, second column headed "Destination 1o Address." The hardware, firmware, and/or software of router A101 represented by this table thus responds by affixing the computer binary equivalent of a label to this particular packet and forwarding it to outgoing interface "2" as reflected in the first row or tuple of the table. Outgoing interface or port ~ is the entrance to tunnel 109 by which packet 114 travels to router C104. Roister 0104 receives the packet and does not examine its destination address like roister A101 did, but relatively quickly (as compared with the prior address examination procedure) notes its label and forwards it along the tunnel based on the label information. Roister D105 receives the labeled packet and performs the same procedure as roister C104 and quickly 2o forwards it to tail-end roister E103. Roister E103 removes the label and forwards the packet to a particular node within subnet 107 over link 111 based on its original destination address. Other packets similarly destined, namely packets 115,116 and 118, are handled in an identical fashion, and their entries in Fig. 2C also represent matched associations between each of their destination addresses in their respective headers and a matching binary number address of a particular node internal to subnet 107 stored in the Fig.
2C table of roister A101 (which may or may not be the same address to which the destination of packet 114 was matched). Thus, packets destined for various nodes internal to subnet 107 being directly connected from tunnel 3o egress roister E103 are sent by way of the tunnel.
In contrast, consider the operation of this network upon a different packet, packet 117, which has a different destination address. In Figs. 1, 2A
and 2C, generic packet 123 can also represent packet 117 being received by router A101, but in this case showing a different destination address of "Internal Subnet 108" in its destination address field. Thus router A101, as with aforementioned packets 114,115,116, and 118, again proceeds with the relatively lengthy procedure of examining this new packet's destination address and comparing it against destination address entries in its table. As before, a match is found between the destination address of packet 117 and, in this case, a particular node within subnet 108, as reflected in the fourth row or tuple of the table in Fig. 2C, counting from the top down. Thus, this fourth 1o tuple represents a matched association between the destination address (binary numbered) contained in packet 117 shown in the first column and the address (binary number) of such particular node within subnet 108 stored in the table of router A101 shown in the second column headed "Destination Address." Hardware, firmware, and/or software represented by the table responds, in this case, by aiot affixing the computer binary equivalent of a label to this particular packet, but by merely forwarding it to a different outgoing interface, port "1" based on its destination address as shown in this fourth tuple. Outgoing interface or port 1 is the entrance to link 110 by which packet 117 travels to router B102. Router 8102 receives the packet and in this 2o case (without a label) must reexamine the packet's destination address like router A101 did. Thereafter, router B101 forwards the packet along to router E103 based on the destination address. Router E103 again reexamines the address and forwards the packet to router F106 over link 112. Router F106 examines the packet's destination address and forwards the packet over link 113 to some node having such destination address internal to subnet 108.
Packets 119 and 120 are handled in like fashion since they are also destined to internal subnet 108. Thus, packets destined for nodes, routers, hosts, etc.
within subnet 108, which is indirectly connected from tunnel egress router E, are sent by routes other than through the tunnel. Packet numbers 121 and 122 3o reflect packets destined for roofers upstream from the subnets; one of these routers is the tail-end router and the other is directly supported thereby, whereby packets so destined are labeled and proceed via the tunnel.
If the tables of Figs. 2B and 2C did not have label columns they could have been called generic routing tables. The added label column converts each table to what is known as a traffic engineered (TE) tunnel table, since addition of labels contribute to creation of the tunnel. Another way of describing implementation of this embodiment of the present invention is that each roister maintains a table of traffic-engineered tunnels that originate on that roister. After shortest path first (SPF) calculations have been completed by each roister and routes submitted to its routing table, interior gateway protocol (IGP) examines the TE tunnel table and finds all the tail-end roisters 1o for tunnels originating on this calculating roofer. This is done for each roister.
For each tail-end roister found, the link state database is examined to find all subnets directly attached to that tail-end roister. For each of these directly attached subnets, a route is submitted to its head-end router's TE tunnel table with the tunnel as "next hop". The labels that are ultimately affixed to those 15 incoming packets which are properly destined take this next hop information into account.
For further explanation with regard to implementation of the table of Fig 2C, reflecting an exemplary embodiment of the present invention, refer to Fig. 5 which is a flowchart illustrating metrics involved. Metrics can be 2o viewed as effective "distances" or "loads" between nodes, such effective distances taking into account other factors such as traffic congestion, transmission speed of the physical media (e.g. copper vs glass fiber), etc.
All of this information is available to each of the roisters in the network which can broadcast such information to all other roisters in the network under certain 25 protocols. In block 501, head-end roister A101 of Fig. 1 determines the shortest path to subnet 107 using the "Dijkstra" algorithm (see almost any text on computer networks, such as "Computer Networks" by Andrew S.
Tanenbaum published by Prentice Hall). The algorithmic process then moves to decision block 502 which determines if any tunnels exist that directly se~we 3o subnet 107 (i.e. that have their respective tail-ends on separate roisters such as E103 that directly sex~re subnet 107) that provide metrics from roister A101 to the subnet that are less than the shortest path determined in block 501. If "yes", the algorithmic process moves to block 503 reflecting that all such tunnels) having the rninirnurn metric are the forwarding entries that fill the table of Fig. 2C. Thus other existing tunnels, if any, directly serving subnet 107 but having metrics greater than the minimum tunnel metric determined are not entered into the table. On the other hand, if the answer to decision block 502 was "no", where no tunnels in that category exist, then the process moves to a second decision block 504 where the same question is posed with regard to directly serving subnet 107 but only for tunnels having metrics that are egual to the shortest path determined. If the answer to this second 1o question is "yes", then in block 505 the table in Fig. 2C is filled with forwarding entries to subnet 107 comprising tunnels) and neighbor nodes (if any) forming routes) having the minimum metric (in this case equal to the Dijkstra-determined shortest path metric). Finally, if the answer to this second question is "no", then in block 506 the routing or mapping table of Fig.
15 2C is filled with forwarding entries to subnet 107 comprised of only neighbor nodes (non-tunnel nodes) forming routes) having the minimum Dijkstra-determined metric. (By contrast, the prior art approach would be reflected in decision blocks that are similar as far as the metrics comparison is concerned, but are quite different in that they would ignore the "directly-serve"
concept.
2o Thus, the prior art decision blocks would form routes including tunnels that would accept traffic destined for all nodes downstream from the tail-end roister.) It is understood that, in this embodiment of the present invention, this process of filling a routing table of a particular head-end roister with forwarding entries is one that is performed in advance of any packets arriving 25 at the input to such roister. In other words, in this embodiment of the present invention, this is a static, pre-determined process, established in advance of packet-arrival to handle packets arriving thereafter.
As an alternative embodiment of the present invention, consider a dynamic approach to implementation of the present invention. But first, refer 3o to the flowchart of Fig. 3; while reflecting a dynamic approach this Fig. 3 does not reflect embodiments of the present invention. The algorithm starts with a tunnel being established in block 301. The algorithmic process moves to block 302 where a packet with a header is received by the ingress roister. The algorithmic process moves to decision block 303, which dynamically determines if the packet's destination address corresponds to that of the tunnel's egress roister or any node downstreaw froyn sucla egress shouter. If the answer is "yes", then the algorithmic process goes to block 304 where the ingress roister directs such packets) to its output port, which is linked to the tunnel's entrance. From there the algorithmic process moves to block 306 where the packets) is received at the destination via the tunnel. Thus all traffic to the egress roister and downstream therefrom is jammed into the 1o turuzel. On the other hand, if the answer is "no", then the process moves from decision block 303 to block 305 where the ingress roister directs the packet to another output port having the destination address of the packet(s).
From there the process moves to block 307 where the packet is received at the destination, but not via the tunnel.
By contrast, consider the algorithmic process of the flowchart of Fig. 4, which does reflect a dynamically-responsive embodiment of the present invention. A tunnel is established in block 401 between ingress and egress roisters. A packet with header is received by the ingress roister in block 402.
The algorithmic process moves to decision block 403, which dynamically 2o determines if the header reflects a destination address corresponding to the egress roister or of subnet(s) or hosts) dis~ectly supported by the egress shouter, thus limiting the traffic through the tunnel to this subset of downstream addresses.
If the answer is "yes" then the algorithmic process moves to block 404 where the ingress roister directs such packets) to its output port that is connected to the tunnel entrance. The process moves from there to block 406 where the packets) is received at the destination via the tunnel. On the other hand, if the answer is "no", then the algorithmic process moves from block 403 to block 405 where the ingress roister directs the packets) to another output port (not connected to the tunnel) and having the destination address of the 3o packet(s). From block 405 the process moves to block 407 where the packet is received at its destination (not via the tunnel). In this case traffic through the tunnel is limited providing the operational network benefits earlier described.
As noted, this approach dynamically solves the problem on a packet-by-packet basis, where decision block 403 is a dylzamic operation in real time, as compared with the earlier-described embodiment of pre-determining all addresses of all downstream nodes and entering that information in a table in advance of packet-arrival.
For another alternative embodiment in the category of dynamic control of tunnel traffic in a network, consider Fig. 6. In block 601, within a network, establish a head-end roister (e.g. A101 in Fig. 1) connecting to a tail-end roister (e.g. E103 in Fig. 1) by way of both a turuzel and multiple non-tunnel routes;
o there are additional network devices connected to the tail-end roister. The algorithmic process moves to block 6N where a particular portion of the network traffic (portion of the packets routed and transmitted throughout the network) is forwarded to and received by the head-end roister. The algorithmic process moves next to decision block 603 wherein a determination i5 is made: is such particular portion of received network traffic destined for the tail-end roister or for nodes no more than N hops (N is an integer greater than or equal to a value of one) away from the tail-end roister? If the answer is "yes", then in block 604 such particular traffic portion is conducted to a particular output port on the head-end roister so that it is routed over or 2o through the tunnel. Then, the algorithmic process moves to decision block 605 wherein it is determined if the level of traffic in the tunnel is acceptable, i.e., is the traffic too light where more traffic could be easily handled, or, on the other hand, is there congestion or instability or other adverse condition detected in the tunnel? If the answer is "no", that the traffic level is not 25 acceptable, then the process moves to control block 606, which either increases or decreases the number "N" to adjust the subset of downstream network nodes that are included in the group having addresses to which tunnel traffic will be forwarded. This group of addresses is thus either increased or decreased by adjusting the number N upwards or downwards 3o respectively, with a lower limit to its value being N =1 and by feeding-back its adjusted value into decision block 603 where the operation of block 603 is repeated, but now with respect to this adjusted value of N. (In other words, this is a dynamic feedback operation where the subset of addresses of nodes located downstream from the tail-end roister of a tunnel to which tunnel traffic is being routed or forwarded is adjusted up or down to maintain an optimum level of traffic within the tunnel.) Assuming that this adjusted value of N results in another "yes" answer from block 603, then the concomitant adjusted traffic level is routed over the tunnel in block 604. On this iteration, if level of traffic in the tunnel is now acceptable (contrasted with the prior "no" answer) according to block 605, the algoritl-tmic process moves via its "yes" output and stops.
1o On the other hand, returning to decision block 603, if the traffic portion received by the head-end roister was riot destined for the tail-end roister or was not within N hops of the tail-end roister, then the algorithmic process moves to block 607 wherein such traffic portion is conducted to head-end roister output ports connected to multiple routes excluding the tunnel, and 15 again the algorithmic process stops. In this manner traffic in the tunnel is clearly controlled under two conditions: (1) As noted in embodiments earlier described, if traffic is destined for downstream nodes that are outside of the subset of nodes established for servicing by the tunnel (e.g. not within the class of nodes that are directly supported by the tunnel's egress roister 2o representing under certain protocols a "one-hop" condition or a value of N
=
1) then such destined traffic is conducted to head-end roister output ports that route such traffic outside the tunnel; and (2) If the first condition is met, where the traffic is destined for downstream nodes that are inside such subset, then such traffic in the tunnel is dynamically adjusted to maintain an 2s optimum traffic level or volume for that tunnel, optimum being determined within the context of traffic distribution throughout the entire network.
It should be noted that the term "roister" is used herein to describe a communication device that may be used in a communication system, and should not be construed to limit the present invention to any particular 3o communication device type. Thus, a communication device may include, without limitation, a bridge, roister, bridge-roister (brouter), switch, node, or other communication device.
-1 g-It should also be noted that the term "packet" is used herein to describe a communication message that may be used by a communication device (e.g., created, transmitted, received, stored, or processed by the communication device) or conveyed by a communication medium, and should not be construed to limit the present invention to any particular communication message type, communication message format, or communication protocol.
Thus, a communication message may include, without limitation, a frame, packet, datagram, user datagram, cell, or other type of communication message.
to It should also be noted that the logic flow diagrams are used herein to demonstrate various aspects of the invention, and should not be construed to limit the present invention to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e.g., programs, modules, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the invention. Often times, logic elements may be added, modified, omitted, performed in a different order, or implemented using different logic constructs (e.g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing 2o from the true scope of the invention.
The present invention may be embodied in many different forms, including, but in no way limited to, computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer), programmable logic for use with a programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or other PLI~), discrete components, integrated circuitry (e.g., an Application Specific Integrated Circuit (ASIC)), or any other means including any combination thereof. In a typical embodiment of the present invention, predominantly all of the head-end device logic is implemented as a set of 3o computer program instructions that is converted into a computer executable form, stored as such in a computer readable medium, and executed by a microprocessor within the head-end device under the control of an operating system.
Computer program logic implementing all or part of the functionality previously described herein may be embodied in various forms, including, but in no way limited to, a source code form, a computer executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator). Source code may include a series of computer program instructions implemented in any of various programming languages (e.g., an object code, an assembly language, or a high-level language such as Fortran, 1o C, C++, JAVA, or HTML) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form.
The computer program may be fixed in any form (e.g., source code form, computer executable form, or an intermediate form) either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory 2o device (e.g., a CD-ROM), or other memory device. The computer program may be fixed in any form in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking technologies, and internetworking technologies.
The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).
3o Hardware logic (including programmable logic for use with a programmable logic device) implementing all or part of the functionality previously described herein may be designed using traditional manual methods, or may be designed, captured, simulated, or documented electronically using various tools, such as Computer Aided Design (CAD), a hardware description language (e.g., VHDL or AHDL), or a PLD
programming language (e.g., PALASM, ABEL, or CUPL).
Programmable logic may be fixed either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM), or other memory device. The programmable logic may be fixed o in a signal that is transmittable to a computer using any of various communication teclulologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking technologies, and internetworking technologies. The programmable logic may be distributed as a removable storage medium with ~5 accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).
Although various exemplary embodiments of the invention have been 2o disclosed and described, it should be apparent to those skilled in the art that various changes and modifications can be made that will achieve some of the advantages of the invention without departing from the true scope of the invention. The present embodiments are thus to be considered as illustrative and not restrictive. , These and other such modifications are intended to be 25 covered by the appended claims.
Further alternative embodiments include limiting traffic in a multiplicity of tunnels extending from the head-end router by defining a like multiplicity of subsets of traffic received by the head-end router and to forwarding each one of those subsets over a different one of the tunnels.
In particular implementations, subsets forwarded over the tunnels are destined for respective tail-end routers or for nodes or devices directly served (one hop in certain protocols) by those tail-end routers.
In a system aspect of the present invention for controlling traffic in a 15 network, determination logic is operatively coupled within the network employing an appropriate protocol to determine a first subset of network devices which are no more than a selected number of hops (N hops) away from the tail-end router. The head-end router forwards over the tunnel a second subset of traffic destined for the tail-end router and/or the first subset 20 of network devices or any one or more of these devices. In a further feature, control logic measures level or volume of traffic in the tunnel and adjusts the level or volume by changing the number (N) of hops in, and therefore the number of network devices in, the first subset.
In another system aspect of the present invention for limiting traffic in 25 an information communication network, a subset of additional network devices directly supported by or within N-hops from the tail-end router is determined. Then by using the Dijkstra algorithm or by other ways the shortest path from the head-end router to each node or device in the subset is determined. Thereafter, any tunnels connected from the head-end router to 3o any of these nodes or devices having a metric less than its corresponding shortest path is determined. And, entries in the head-end router's router or forwarding table are filled with any tunnel or tunnels shorter than any of their corresponding shortest paths, but only with those having the minimum metric. In a further feature, absent any tunnel or tunnels shorter than any of their corresponding shortest paths, entries in the table are filled with any tunnel or tunnels equal to their corresponding shortest paths. In yet a further feature, absent any of the above-mentioned tunnels, entries in the table are filled with neighbor nodes forming routes) having the minimum metric or shortest path.
It is therefore advantageous and beneficial to employ the present invention in computer networks in which turulels are utilized, to avoid 1o destabilization and congestion problems associated with those tunnels that otherwise do not limit their respective traffic levels or volumes, whereby overall speed and efficiency of communication in the network is enhanced.
The foregoing and other objects and advantages of the invention will be appreciated more fully from the following further description thereof with 2o reference to the accompanying drawings wherein:
Fig. 1 is a schematic diagram of an information communication network illustrating both multiple routes between a tunnel's head-end and tail-end roofers and a plurality of network devices directly and indirectly supported by the tail-end router, and in which embodiments of the present 25 invention can be used to advantage;
Fig. 2A is a schematic diagram of information or data packets received by tunnel head-end router A101 of Fig. 1;
Fig. ~B is a prior art illustration of a head-end or ingress router's map table or routing table or forwarding entry table in which destination 3o addresses of incoming packets of information and/or data are mapped to particular outgoing interfaces or ports on such router;
Fig. 2C is an illustration of a head-end or ingress-router's map table or routing table or forwarding entry table filled with table entries in conformance with an embodiment of the present invention in which destination addresses of certain subsets of traffic or incoming packets of information and/or data are mapped to particular outgoing interfaces or ports on such router;
Fig. 3 is a flowchart illustrating the prior art approach to usage of tunnels in information communication networks;
Fig. 4 is a flowchart illustrating an algorithm utilized by an embodiment of the present invention;
Fig. 5 is a flowchart illustrating an algorithm utilized in the process of 1o filling the table entries in accordance with another embodiment of the present invention; and, Fig. 6 is a flowchart illustrating an algorithm associated with a system for controlling level or volume of tunnel traffic in accordance with principles of the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
Referring to Fig.1, there is depicted an information communication 2o network including multiple routers A, B, C, D, E, and F as well as subnets and 108 connected by various links. More specifically, ingress or head-end router A101 is shown with an input 125 which receives traffic or information or generic packet 123 (more detail about these packets is discussed in connection with Fig. 2A). Router A101 may have many output ports but shows only two output ports or interfaces 1 and 2 connected by link110 to router B102 and link 109 to router C104 respectively. Link 109 is depicted as a tunnel and link 110 is depicted as other than a tunnel and could be a link based on OSPF (Open Shortest Path First) or some other protocol. Router 8102 is connected via link 110 to tail-end or egress router E. Router C104 is 3o connected via tunnel 109 to router D105 which, in turn, is connected via tunnel 109 also to tail-end router E103. Thus, there are two pathways shown between ingress and egress routers in this Fig., one being a tunnel and the other not being a tunnel. Finally, Router E103 indirectly connects to subnet 108 through roister F106 via links 112 and 113 (two hop counts in certain protocols), but roister E103 directly connects to subnet 107 via link 111 (one hop count in certain protocols). Each subnet is an autonomous networle and would typically contain roisters, switches, host computers and other network nodes, each such item having its own address within its autonomous network.
As is understood by those familiar with this art, a tunnel involves technology that enables a first network to send its data by way of another network's connections, typically by encapsulating a first network's protocol to within packets carried by the second network. For example, one can employ MPLS which is an integration of Layer 2 and Layer 3 technologies and uses labels which override the destination addresses of the packets. Thus, a hard-coded communication pathway is created based on these labels having a particular destination and such pathway is Balled a "label-switched path 15 (LSP) tunnel". Any roisters internal to such tunnel may be directly accessed lay other roisters in the network to perform routing functions independent of their otherwise dedicated usage as transit roisters within the tunnel.
Also, as understood by those familiar with this art, there are various protocols that have been adopted for exchanging routing information within a 2o LAN and between multiple LANs within the same AS. These are known as interior gateway protocols (IGPs). OSPF and RIP are example IGPs that can be used to exchange routing information within an autonomous system (AS) or LAN such as within subnet 107 or within subnet 108. OSPF establishes links throughout the network by having roisters broadcast individual link 25 metric information to all other roisters. This is contrasted with RIP that establishes links throughout the network by having roisters advertise their data to only neighboring roisters which, in turn, pass on the information only to successive neighboring roisters. The former class is called link state routing protocols and the latter class is called distance-vector protocols. The tunnel of 3o Fig. 1 can be constructed as an LSP tunnel and the other links shown can be constructed in accordance with an IGP.
_g_ Fig. 2A shows certain characteristics of a number of packets 114,117, 121, and 122. In actuality, each packet, including the packets 114, 117,121, 122, and 123 (shown in Fig.1), includes a destination address field indicating the final destination of the packet, a source address field ("FROM") indicating the source of the packet, and a data payload. Each packet typically passes through a number of roisters along the way from the source to the destination.
Specifically, each roister determines a "next hop" roister for each packet, and forwards the packet to the "next hop" roister. For convenience, Fig. 2A shows a "TO" field representing the "next hop" roister for each packet. It should be 1o noted that the "TO" field is not an actual field within the packets. For packets 114,117,121, and 122, the "FROM" field and the "PAYLOAD" field are left blank, since these fields are not germane to comprehension of the described embodiments of the present invention. In packet 114, the "T0'° field shows roister A101 and the destination address field shows "Internal Subnet 107."
z5 Tllis packet information is interpreted as follows: the packet came from some unknown upstream network node and was sent to Roister A101 as the "next hop" roister. Roister A101 forwards or routes the packet toward a particular node internal to subnet 107 for which a specific address is provided in this packet's header and depicted herein as "Internal Subnet 107". The payload 2o field contains whatever data (binary 1's and 0's) is intended for that particular node destination. Packet 117 contains similar information in its fields, but its destination address is different from that of packet 114 - packet 117 is destined for a particular node internal to or within autonomous subnet 108.
Such particular node's address is intended to be represented by "Internal 25 Subnet 108" in this illustration. Packets 121 and 122 differ from packets and 117 primarily in their respective destination addresses, where packets 121 and 122 are destined for tunnel tail-end roister E103 and roister F106 respectively, rather than nodes within the subnets 107 and 108. Further detailed discussion of these packets will be presented hereinbelow.
3o Referring next to both Figs. 2B and 2C, Fig. 2B shows a prior art map table for purposes of comparison with Fig. 2C, which reflects a map table in conformance with principles of the present invention. These tables pictorially represent functional essence of operation of certain computer hardware, firmware and/or software in router A101 of Fig. 1 and are thus tables of binary numbers or binary values. However, such values are not shown but are represented by their functional equivalents in English language and decimal numbers to enhance comprehension of the various embodiments of the present invention. A table representation similar to these, but with different information, can be associated with each router of the network of Fig. 1. These tables show columns entitled "Packet number" and "Forwarding Entry'°. Packet number is not necessarily an item maintained in 1o these mapping or router tables, and is shown here as a convenient identifier for discussion purposes. On the other hand, Forwarding Entry including its sub-columns entitled "Destination Address" (DA), "Outgoing Interface" and "Label Added?" are included in the router tables for substantive operational purposes. "The first column and first row or tuple entry in the tables is 15 packet 114 and is similar to the generic packet 123 depicted in Fig. 1.
Corresponding to packet 114 is a destination address binary value corresponding to a particular node within subnet 107, an outgoing interface binary value corresponding to interface or port #2 of router A101, and a binary value corresponding to answer "yes" to the question of whether or not 2o a label is added to this packet. Similar binary values are associated with the table entries for the other packets shown.
With specific regard to prior art Fig. ~B, packets 114 through 1~2 are shown having destination addresses of either subnet 107, subnet 108, router E103 or router F106. (As noted earlier, a designation of "subnet 107" for 25 destination address means a particular node within subnet 107 and is illustrated in this manner for purposes of convenience, since the internals of subnet 107 are not shown in order to enhance clarity of presentation. Thus the repetitive destination address designation of "subnet 107" also for packet numbers 115,116, and 118 may mean either the same node as - or different 3o nodes from - the particular node within subnet 107 to which packet 114 is destined.) As can be seen, in Fig. 2A, all packets exit router A101 via outgoing interface or port #2 and all have a label added. All of these packets are said to belong to the same forwarding equivalence class (FEC), since they all exit the router by way of the same port with the same label. In typical router construction, there are multiple printed circuit boards or "cards" associated with the multiplicity of outgoing interfaces or ports in the router, and a card may have more than one port associated with it. Further discussion of router construction detail at this level, however, is not essential to full comprehension of the presented embodiments of the present invention.
Next, with specific regard to Fig. 2C, a map table in accordance with principles reflected in embodiments of the present invention is shown. A
1o principal difference between this table and the one of Fig. 2B is the indication that nodes having destination addresses within subnet 108, such as those associated with packets 117,119, and 120, all do not have labels added, and all are routed out outgoing interface #1 instead of interface #2. Thus, rather than have all incoming packets that are destined for addresses downstream of router E103 go out interface #2 (to the tunnel entrance), now, in accordance with principles of the present invention, only certain incoming packets (a subset of the incoming packets) that are destined for addresses downstream of router E103 go out interface #2.
In operation, referring to Figs. 1, 2A, 2B, and 2C collectively, traffic or 2o packets, such as packet 114, are serially received by head-end router A101 at input 125. Packet 114 would ordinarily contain header information which would show (in the °'FROM" field of the header) where it came from (either a local device within this particular LAN or AS or from a different or remote LAN or AS via a network "gateway"). The header also shows where the packet is heading to (in the "DESTINATION ADDRESS" field of the header), which, in this case, is a node within internal subnet 107. Upon receipt of this packet, router A101 examines the packet's destination address, and compares the packet's destination address against destination address entries in the table of Fig. 2C. (For purposes of enhancing clarity of presentation, a limited 3o number of only nine entries are presented in the tables of Fig.2B and Fig.
2C, those entries all being related to tail-end routers and downstream routers E103 and F106 respectively, and depicted subnets 107/108. It should be understood, however, that the network can be much larger than that shown, with a vast number of subnets and/or network devices and host computers, and with a corresponding vast number of destination addresses). A match is found between the arriving packet's destination address and a destination address entry in the table, i.e. a node within subnet 107. Thus, the first row or tuple of the table of Fig. 2C represents a matched association between the binary-numbered destination address contained in packet 114 entered in the first column, and the binary numbered address of a particular node within subnet 107 stored in the first row, second column headed "Destination 1o Address." The hardware, firmware, and/or software of router A101 represented by this table thus responds by affixing the computer binary equivalent of a label to this particular packet and forwarding it to outgoing interface "2" as reflected in the first row or tuple of the table. Outgoing interface or port ~ is the entrance to tunnel 109 by which packet 114 travels to router C104. Roister 0104 receives the packet and does not examine its destination address like roister A101 did, but relatively quickly (as compared with the prior address examination procedure) notes its label and forwards it along the tunnel based on the label information. Roister D105 receives the labeled packet and performs the same procedure as roister C104 and quickly 2o forwards it to tail-end roister E103. Roister E103 removes the label and forwards the packet to a particular node within subnet 107 over link 111 based on its original destination address. Other packets similarly destined, namely packets 115,116 and 118, are handled in an identical fashion, and their entries in Fig. 2C also represent matched associations between each of their destination addresses in their respective headers and a matching binary number address of a particular node internal to subnet 107 stored in the Fig.
2C table of roister A101 (which may or may not be the same address to which the destination of packet 114 was matched). Thus, packets destined for various nodes internal to subnet 107 being directly connected from tunnel 3o egress roister E103 are sent by way of the tunnel.
In contrast, consider the operation of this network upon a different packet, packet 117, which has a different destination address. In Figs. 1, 2A
and 2C, generic packet 123 can also represent packet 117 being received by router A101, but in this case showing a different destination address of "Internal Subnet 108" in its destination address field. Thus router A101, as with aforementioned packets 114,115,116, and 118, again proceeds with the relatively lengthy procedure of examining this new packet's destination address and comparing it against destination address entries in its table. As before, a match is found between the destination address of packet 117 and, in this case, a particular node within subnet 108, as reflected in the fourth row or tuple of the table in Fig. 2C, counting from the top down. Thus, this fourth 1o tuple represents a matched association between the destination address (binary numbered) contained in packet 117 shown in the first column and the address (binary number) of such particular node within subnet 108 stored in the table of router A101 shown in the second column headed "Destination Address." Hardware, firmware, and/or software represented by the table responds, in this case, by aiot affixing the computer binary equivalent of a label to this particular packet, but by merely forwarding it to a different outgoing interface, port "1" based on its destination address as shown in this fourth tuple. Outgoing interface or port 1 is the entrance to link 110 by which packet 117 travels to router B102. Router 8102 receives the packet and in this 2o case (without a label) must reexamine the packet's destination address like router A101 did. Thereafter, router B101 forwards the packet along to router E103 based on the destination address. Router E103 again reexamines the address and forwards the packet to router F106 over link 112. Router F106 examines the packet's destination address and forwards the packet over link 113 to some node having such destination address internal to subnet 108.
Packets 119 and 120 are handled in like fashion since they are also destined to internal subnet 108. Thus, packets destined for nodes, routers, hosts, etc.
within subnet 108, which is indirectly connected from tunnel egress router E, are sent by routes other than through the tunnel. Packet numbers 121 and 122 3o reflect packets destined for roofers upstream from the subnets; one of these routers is the tail-end router and the other is directly supported thereby, whereby packets so destined are labeled and proceed via the tunnel.
If the tables of Figs. 2B and 2C did not have label columns they could have been called generic routing tables. The added label column converts each table to what is known as a traffic engineered (TE) tunnel table, since addition of labels contribute to creation of the tunnel. Another way of describing implementation of this embodiment of the present invention is that each roister maintains a table of traffic-engineered tunnels that originate on that roister. After shortest path first (SPF) calculations have been completed by each roister and routes submitted to its routing table, interior gateway protocol (IGP) examines the TE tunnel table and finds all the tail-end roisters 1o for tunnels originating on this calculating roofer. This is done for each roister.
For each tail-end roister found, the link state database is examined to find all subnets directly attached to that tail-end roister. For each of these directly attached subnets, a route is submitted to its head-end router's TE tunnel table with the tunnel as "next hop". The labels that are ultimately affixed to those 15 incoming packets which are properly destined take this next hop information into account.
For further explanation with regard to implementation of the table of Fig 2C, reflecting an exemplary embodiment of the present invention, refer to Fig. 5 which is a flowchart illustrating metrics involved. Metrics can be 2o viewed as effective "distances" or "loads" between nodes, such effective distances taking into account other factors such as traffic congestion, transmission speed of the physical media (e.g. copper vs glass fiber), etc.
All of this information is available to each of the roisters in the network which can broadcast such information to all other roisters in the network under certain 25 protocols. In block 501, head-end roister A101 of Fig. 1 determines the shortest path to subnet 107 using the "Dijkstra" algorithm (see almost any text on computer networks, such as "Computer Networks" by Andrew S.
Tanenbaum published by Prentice Hall). The algorithmic process then moves to decision block 502 which determines if any tunnels exist that directly se~we 3o subnet 107 (i.e. that have their respective tail-ends on separate roisters such as E103 that directly sex~re subnet 107) that provide metrics from roister A101 to the subnet that are less than the shortest path determined in block 501. If "yes", the algorithmic process moves to block 503 reflecting that all such tunnels) having the rninirnurn metric are the forwarding entries that fill the table of Fig. 2C. Thus other existing tunnels, if any, directly serving subnet 107 but having metrics greater than the minimum tunnel metric determined are not entered into the table. On the other hand, if the answer to decision block 502 was "no", where no tunnels in that category exist, then the process moves to a second decision block 504 where the same question is posed with regard to directly serving subnet 107 but only for tunnels having metrics that are egual to the shortest path determined. If the answer to this second 1o question is "yes", then in block 505 the table in Fig. 2C is filled with forwarding entries to subnet 107 comprising tunnels) and neighbor nodes (if any) forming routes) having the minimum metric (in this case equal to the Dijkstra-determined shortest path metric). Finally, if the answer to this second question is "no", then in block 506 the routing or mapping table of Fig.
15 2C is filled with forwarding entries to subnet 107 comprised of only neighbor nodes (non-tunnel nodes) forming routes) having the minimum Dijkstra-determined metric. (By contrast, the prior art approach would be reflected in decision blocks that are similar as far as the metrics comparison is concerned, but are quite different in that they would ignore the "directly-serve"
concept.
2o Thus, the prior art decision blocks would form routes including tunnels that would accept traffic destined for all nodes downstream from the tail-end roister.) It is understood that, in this embodiment of the present invention, this process of filling a routing table of a particular head-end roister with forwarding entries is one that is performed in advance of any packets arriving 25 at the input to such roister. In other words, in this embodiment of the present invention, this is a static, pre-determined process, established in advance of packet-arrival to handle packets arriving thereafter.
As an alternative embodiment of the present invention, consider a dynamic approach to implementation of the present invention. But first, refer 3o to the flowchart of Fig. 3; while reflecting a dynamic approach this Fig. 3 does not reflect embodiments of the present invention. The algorithm starts with a tunnel being established in block 301. The algorithmic process moves to block 302 where a packet with a header is received by the ingress roister. The algorithmic process moves to decision block 303, which dynamically determines if the packet's destination address corresponds to that of the tunnel's egress roister or any node downstreaw froyn sucla egress shouter. If the answer is "yes", then the algorithmic process goes to block 304 where the ingress roister directs such packets) to its output port, which is linked to the tunnel's entrance. From there the algorithmic process moves to block 306 where the packets) is received at the destination via the tunnel. Thus all traffic to the egress roister and downstream therefrom is jammed into the 1o turuzel. On the other hand, if the answer is "no", then the process moves from decision block 303 to block 305 where the ingress roister directs the packet to another output port having the destination address of the packet(s).
From there the process moves to block 307 where the packet is received at the destination, but not via the tunnel.
By contrast, consider the algorithmic process of the flowchart of Fig. 4, which does reflect a dynamically-responsive embodiment of the present invention. A tunnel is established in block 401 between ingress and egress roisters. A packet with header is received by the ingress roister in block 402.
The algorithmic process moves to decision block 403, which dynamically 2o determines if the header reflects a destination address corresponding to the egress roister or of subnet(s) or hosts) dis~ectly supported by the egress shouter, thus limiting the traffic through the tunnel to this subset of downstream addresses.
If the answer is "yes" then the algorithmic process moves to block 404 where the ingress roister directs such packets) to its output port that is connected to the tunnel entrance. The process moves from there to block 406 where the packets) is received at the destination via the tunnel. On the other hand, if the answer is "no", then the algorithmic process moves from block 403 to block 405 where the ingress roister directs the packets) to another output port (not connected to the tunnel) and having the destination address of the 3o packet(s). From block 405 the process moves to block 407 where the packet is received at its destination (not via the tunnel). In this case traffic through the tunnel is limited providing the operational network benefits earlier described.
As noted, this approach dynamically solves the problem on a packet-by-packet basis, where decision block 403 is a dylzamic operation in real time, as compared with the earlier-described embodiment of pre-determining all addresses of all downstream nodes and entering that information in a table in advance of packet-arrival.
For another alternative embodiment in the category of dynamic control of tunnel traffic in a network, consider Fig. 6. In block 601, within a network, establish a head-end roister (e.g. A101 in Fig. 1) connecting to a tail-end roister (e.g. E103 in Fig. 1) by way of both a turuzel and multiple non-tunnel routes;
o there are additional network devices connected to the tail-end roister. The algorithmic process moves to block 6N where a particular portion of the network traffic (portion of the packets routed and transmitted throughout the network) is forwarded to and received by the head-end roister. The algorithmic process moves next to decision block 603 wherein a determination i5 is made: is such particular portion of received network traffic destined for the tail-end roister or for nodes no more than N hops (N is an integer greater than or equal to a value of one) away from the tail-end roister? If the answer is "yes", then in block 604 such particular traffic portion is conducted to a particular output port on the head-end roister so that it is routed over or 2o through the tunnel. Then, the algorithmic process moves to decision block 605 wherein it is determined if the level of traffic in the tunnel is acceptable, i.e., is the traffic too light where more traffic could be easily handled, or, on the other hand, is there congestion or instability or other adverse condition detected in the tunnel? If the answer is "no", that the traffic level is not 25 acceptable, then the process moves to control block 606, which either increases or decreases the number "N" to adjust the subset of downstream network nodes that are included in the group having addresses to which tunnel traffic will be forwarded. This group of addresses is thus either increased or decreased by adjusting the number N upwards or downwards 3o respectively, with a lower limit to its value being N =1 and by feeding-back its adjusted value into decision block 603 where the operation of block 603 is repeated, but now with respect to this adjusted value of N. (In other words, this is a dynamic feedback operation where the subset of addresses of nodes located downstream from the tail-end roister of a tunnel to which tunnel traffic is being routed or forwarded is adjusted up or down to maintain an optimum level of traffic within the tunnel.) Assuming that this adjusted value of N results in another "yes" answer from block 603, then the concomitant adjusted traffic level is routed over the tunnel in block 604. On this iteration, if level of traffic in the tunnel is now acceptable (contrasted with the prior "no" answer) according to block 605, the algoritl-tmic process moves via its "yes" output and stops.
1o On the other hand, returning to decision block 603, if the traffic portion received by the head-end roister was riot destined for the tail-end roister or was not within N hops of the tail-end roister, then the algorithmic process moves to block 607 wherein such traffic portion is conducted to head-end roister output ports connected to multiple routes excluding the tunnel, and 15 again the algorithmic process stops. In this manner traffic in the tunnel is clearly controlled under two conditions: (1) As noted in embodiments earlier described, if traffic is destined for downstream nodes that are outside of the subset of nodes established for servicing by the tunnel (e.g. not within the class of nodes that are directly supported by the tunnel's egress roister 2o representing under certain protocols a "one-hop" condition or a value of N
=
1) then such destined traffic is conducted to head-end roister output ports that route such traffic outside the tunnel; and (2) If the first condition is met, where the traffic is destined for downstream nodes that are inside such subset, then such traffic in the tunnel is dynamically adjusted to maintain an 2s optimum traffic level or volume for that tunnel, optimum being determined within the context of traffic distribution throughout the entire network.
It should be noted that the term "roister" is used herein to describe a communication device that may be used in a communication system, and should not be construed to limit the present invention to any particular 3o communication device type. Thus, a communication device may include, without limitation, a bridge, roister, bridge-roister (brouter), switch, node, or other communication device.
-1 g-It should also be noted that the term "packet" is used herein to describe a communication message that may be used by a communication device (e.g., created, transmitted, received, stored, or processed by the communication device) or conveyed by a communication medium, and should not be construed to limit the present invention to any particular communication message type, communication message format, or communication protocol.
Thus, a communication message may include, without limitation, a frame, packet, datagram, user datagram, cell, or other type of communication message.
to It should also be noted that the logic flow diagrams are used herein to demonstrate various aspects of the invention, and should not be construed to limit the present invention to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e.g., programs, modules, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the invention. Often times, logic elements may be added, modified, omitted, performed in a different order, or implemented using different logic constructs (e.g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing 2o from the true scope of the invention.
The present invention may be embodied in many different forms, including, but in no way limited to, computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer), programmable logic for use with a programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or other PLI~), discrete components, integrated circuitry (e.g., an Application Specific Integrated Circuit (ASIC)), or any other means including any combination thereof. In a typical embodiment of the present invention, predominantly all of the head-end device logic is implemented as a set of 3o computer program instructions that is converted into a computer executable form, stored as such in a computer readable medium, and executed by a microprocessor within the head-end device under the control of an operating system.
Computer program logic implementing all or part of the functionality previously described herein may be embodied in various forms, including, but in no way limited to, a source code form, a computer executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator). Source code may include a series of computer program instructions implemented in any of various programming languages (e.g., an object code, an assembly language, or a high-level language such as Fortran, 1o C, C++, JAVA, or HTML) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form.
The computer program may be fixed in any form (e.g., source code form, computer executable form, or an intermediate form) either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory 2o device (e.g., a CD-ROM), or other memory device. The computer program may be fixed in any form in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking technologies, and internetworking technologies.
The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).
3o Hardware logic (including programmable logic for use with a programmable logic device) implementing all or part of the functionality previously described herein may be designed using traditional manual methods, or may be designed, captured, simulated, or documented electronically using various tools, such as Computer Aided Design (CAD), a hardware description language (e.g., VHDL or AHDL), or a PLD
programming language (e.g., PALASM, ABEL, or CUPL).
Programmable logic may be fixed either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM), or other memory device. The programmable logic may be fixed o in a signal that is transmittable to a computer using any of various communication teclulologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking technologies, and internetworking technologies. The programmable logic may be distributed as a removable storage medium with ~5 accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).
Although various exemplary embodiments of the invention have been 2o disclosed and described, it should be apparent to those skilled in the art that various changes and modifications can be made that will achieve some of the advantages of the invention without departing from the true scope of the invention. The present embodiments are thus to be considered as illustrative and not restrictive. , These and other such modifications are intended to be 25 covered by the appended claims.
Claims (76)
1. In an information communication network comprising a head-end device in communication with a tail-end device via a number of routes for routing information to various destinations, a method for limiting traffic volume in a tunnel by said head-end device, the method comprising:
establishing said tunnel to said tail-end device as one of said number of routes;
determining a number of said destinations that are serviced by said tail-end device to obtain serviced destinations; and routing information destined for said serviced destinations to said tail-end device through said tunnel.
establishing said tunnel to said tail-end device as one of said number of routes;
determining a number of said destinations that are serviced by said tail-end device to obtain serviced destinations; and routing information destined for said serviced destinations to said tail-end device through said tunnel.
2. The method of claim 1, wherein said serviced destinations comprise directly-connected hosts/subnets of said tail-end device.
3. The method of claim 1, wherein said serviced destinations comprise destinations within a predetermined number of roister hops of said tail-end device.
4. The method of claim 3, further comprising monitoring tunnel utilization, wherein said determining further comprises dynamically increasing said predetermined number of roister hops if said tunnel is under-utilized and decreasing said predetermined number of roister hops if said tunnel is over-utilized.
5. The method of claim 1, wherein said serviced destinations comprise said tail-end device.
6. The method of claim 1, wherein said serviced destinations comprise a destination for which said tunnel is a better route to said destination than a predetermined shortest path route to said destination.
7. The method of claim 6, wherein said determining comprises:
calculating said shortest path route to said destination;
determining a shortest path route metric associate with said shortest path route;
determining a tunnel metric associated with said tunnel; and determining from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
calculating said shortest path route to said destination;
determining a shortest path route metric associate with said shortest path route;
determining a tunnel metric associated with said tunnel; and determining from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
8. The method of claim 1, wherein said head-end device comprises a link state database, and wherein said determining comprises examining said link state database to determine which of said destinations are serviced by said tail-end device.
9. The method of claim 1, wherein said tunnel comprises a label switched path from said head-end device to said tail-end device, and wherein said routing comprises affixing to said information a predetermined label associated with said label switched path for label switching of said information from said head-end device to said tail-end device by a number of intermediate devices.
10. The method of claim 1, wherein said head-end device comprises a forwarding table indicating one of said number of routes for each of said number of destinations, and wherein said determining further comprises indicating said tunnel for each of said serviced destinations in said forwarding table.
11. The method of claim 10, wherein said routing comprises determining from said forwarding table that said information is associated with said tunnel.
12. The method of claim 1, further comprising routing information destined for other than said serviced destinations over one of said number of routes other than said tunnel.
13. An apparatus for limiting traffic volume in a tunnel between said apparatus and a tail-end device, said apparatus having a number of routes to said tail-end for routing information to various destinations, the apparatus comprising:
tunnel establishment logic operably coupled to establish said tunnel to said tail-end device as one of said number of routes;
determination logic operably coupled to determine a number of said destinations that are serviced by said tail-end device to obtain serviced destinations; and routing logic operably coupled to route information destined for said serviced destinations from said head-end device to said tail-end device through said tunnel.
tunnel establishment logic operably coupled to establish said tunnel to said tail-end device as one of said number of routes;
determination logic operably coupled to determine a number of said destinations that are serviced by said tail-end device to obtain serviced destinations; and routing logic operably coupled to route information destined for said serviced destinations from said head-end device to said tail-end device through said tunnel.
14. The apparatus of claim 13, wherein said serviced destinations comprise directly-connected hosts/subnets of said tail-end device.
15. The apparatus of claim 13, wherein said serviced destinations comprise destinations within a predetermined number of router hops of said tail-end device.
16. The apparatus of claim 15, further comprising monitoring logic operably coupled to monitor tunnel utilization, wherein said determination logic is operably coupled to dynamically increase said predetermined number of router hops if said tunnel is under-utilized and decrease said predetermined number of router hops if said tunnel is over-utilized.
17. The apparatus of claim 13, wherein said serviced destinations comprise said tail-end device.
18. The apparatus of claim 13, wherein said serviced destinations comprise a destination for which said tunnel is a better route to said destination than a predetermined shortest path route to said destination.
19. The apparatus of claim 18, wherein said determination logic is operably coupled to calculate said shortest path route to said destination, determine a shortest path route metric associate with said shortest path route, determine a tunnel metric associated with said tunnel, and determine from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
20. The apparatus of claim 13, further comprising a link state database, wherein said determination logic is operably coupled to examine said link state database to determine which of said destinations are serviced by said tail-end device.
21. The apparatus of claim 13, wherein said tunnel comprises a label switched path to said tail-end device, and wherein said routing logic is operably coupled to affix to said information a predetermined label associated with said label switched path for label switching of said information from said head-end device to said tail-end device by a number of intermediate devices.
22. The apparatus of claim 13, further comprising a forwarding table indicating one of said number of routes for each of said number of destinations, wherein said determination logic is operably coupled to indicate said tunnel for each of said serviced destinations in said forwarding table.
23. The apparatus of claim 22, wherein said routing logic is operably coupled to determine from said forwarding table that said information is associated with said tunnel.
24. The apparatus of claim 13, wherein said routing logic is operably coupled to route information destined for other than said serviced destinations over one of said number of routes other than said tunnel.
25. A computer program for controlling a head-end device to limit traffic volume in a tunnel between said head-end device and a tail-end device, said head-end device having a number of routes to said tail-end for routing information to various destinations, the computer program comprising:
tunnel establishment logic programmed to establish said tunnel to said tail-end device as one of said number of routes;
determination logic programmed to determine a number of said destinations that are serviced by said tail-end device to obtain serviced destinations; and routing logic programmed to route information destined for said serviced destinations from said head-end device to said tail-end device through said tunnel.
tunnel establishment logic programmed to establish said tunnel to said tail-end device as one of said number of routes;
determination logic programmed to determine a number of said destinations that are serviced by said tail-end device to obtain serviced destinations; and routing logic programmed to route information destined for said serviced destinations from said head-end device to said tail-end device through said tunnel.
26. The computer program of claim 25, wherein said serviced destinations comprise directly-connected hosts/subnets of said tail-end device.
27. The computer program of claim 25, wherein said serviced destinations comprise destinations within a predetermined number of router hops of said tail-end device.
28. The computer program of claim 27, further comprising monitoring logic programmed to monitor tunnel utilization, wherein said determination logic is further programmed to dynamically increase said predetermined number of router hops if said tunnel is under-utilized and decrease said predetermined number of router hops if said tunnel is over-utilized.
29. The computer program of claim 25, wherein said serviced destinations comprise said tail-end device.
30. The computer program of claim 25, wherein said serviced destinations comprise a destination for which said tunnel is a better route to said destination than a predetermined shortest path route to said destination.
31. The computer program of claim 30, wherein said determination logic is programmed to calculate said shortest path route to said destination, determine a shortest path route metric associate with said shortest path route, determine a tunnel metric associated with said tunnel, and determine from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
32. The computer program of claim 25, wherein said determination logic is programmed to examine a link state database to determine which of said destinations are serviced by said tail-end device.
33. The computer program of claim 25, wherein said tunnel comprises a label switched path from said head-end device to said tail-end device, and wherein said routing logic is programmed to affix to said information a predetermined label associated with said label switched path for label switching of said information from said head-end device to said tail-end device by a number of intermediate devices.
34. The computer program of claim 25, wherein said head-end device comprises a forwarding table indicating one of said number of routes for each of said number of destinations, and wherein said determination logic is programmed to indicate said tunnel for each of said serviced destinations in said forwarding table.
35. The computer program of claim 34, wherein said routing logic is programmed to determine from said forwarding table that said information is associated with said tunnel.
36. The computer program of claim 25, wherein said routing logic is programmed to route information destined for other than said serviced destinations over one of said number of routes other than said tunnel.
37. The computer program of claim 25 embodied in a computer readable medium.
38. The computer program of claim 25 embodied as a data signal.
39. In an information communication network comprising a head-end device in communication with a tail-end device via a number of routes for routing information to various destinations, a method for limiting traffic volume in a tunnel, the method comprising:
establishing said tunnel between said head-end device and said tail-end device as one of said number of routes receiving information for a destination by said head-end device;
determining whether said destination is serviced by said tail-end device; and routing said information by said head-end device to said tail-end device over said tunnel, if and only if said destination is serviced by said tail end device.
establishing said tunnel between said head-end device and said tail-end device as one of said number of routes receiving information for a destination by said head-end device;
determining whether said destination is serviced by said tail-end device; and routing said information by said head-end device to said tail-end device over said tunnel, if and only if said destination is serviced by said tail end device.
40. The method of claim 39, wherein determining whether said destination is serviced by said tail-end device comprises determining whether said destination is a directly-connected host/subnet of said tail-end device.
41. The method of claim 39, wherein determining whether said destination is serviced by said tail-end device comprises determining whether said destination is within a predetermined number of roofer hops of said tail-end device.
42. The method of claim 41, further comprising monitoring tunnel utilization, wherein said determining further comprises dynamically increasing said predetermined number of roister hops if said tunnel is under-utilized and decreasing said predetermined number of roister hops if said tunnel is over-utilized.
43. The method of claim 39, wherein determining whether said destination is serviced by said tail-end device comprises determining whether said destination is said tail-end device.
44. The method of claim 39, wherein determining whether said destination is serviced by said tail-end device comprises:
calculating a shortest path route to said destination;
determining a shortest path route metric associate with said shortest path route;
determining a tunnel metric associated with said tunnel; and determining from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
calculating a shortest path route to said destination;
determining a shortest path route metric associate with said shortest path route;
determining a tunnel metric associated with said tunnel; and determining from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
45. The method of claim 39, wherein said head-end device comprises a link state database, and wherein said determining comprises examining said link state database to determine whether said destination is serviced by said tail-end device.
46. The method of claim 39, wherein said tunnel comprises a label switched path from said head-end device to said tail-end device, and wherein said routing comprises affixing to said information a predetermined label associated with said label switched path for label switching of said information from said head-end device to said tail-end device by a number of intermediate devices.
47. The method of claim 46, wherein said routing further comprises said tail-end device removing said label from said information and forwarding said information to said destinations based upon destination address information in said information.
48. The method of claim 39, further comprising routing said information by said head-end device to said tail-end device over one of said routes other than said tunnel, if and only if said destination is not serviced by said tail-end device.
49. An apparatus for limiting traffic volume in a tunnel between said apparatus and a tail-end device, said apparatus having a number of routes to said tail-end for routing information to various destinations, the apparatus comprising:
tunnel establishment logic operably coupled to establish said tunnel to said tail-end device as one of said number of routes;
receiving logic operably coupled to receive information for a destination;
determination logic operably coupled to determine whether said destination is serviced by said tail-end device; and routing logic operably coupled to route said information to said tail-end device through said tunnel if and only if said destination is serviced by said tail-end device.
tunnel establishment logic operably coupled to establish said tunnel to said tail-end device as one of said number of routes;
receiving logic operably coupled to receive information for a destination;
determination logic operably coupled to determine whether said destination is serviced by said tail-end device; and routing logic operably coupled to route said information to said tail-end device through said tunnel if and only if said destination is serviced by said tail-end device.
50. The apparatus of claim 49, wherein said determination logic is operably coupled to determine whether said destination is a directly-connected host/subnet of said tail-end device.
51. The apparatus of claim 49, wherein said determination logic is operably coupled to determine whether said destination is within a predetermined number of router hops of said tail-end device.
52. The apparatus of claim 51, further comprising monitoring logic operably coupled to monitor tunnel utilization, wherein said determination logic is operably coupled to dynamically increase said predetermined number of router hops if said tunnel is under-utilized and decrease said predetermined number of router hops if said tunnel is over-utilized.
53. The apparatus of claim 49, wherein said determination logic is operably coupled to determine whether said destination is said tail-end device.
54. The apparatus of claim 49, wherein said determination logic is operably coupled to calculate a shortest path route to said destination, determine a shortest path route metric associated with said shortest path route, determine a tunnel metric associated with said tunnel, and determine from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
55. The apparatus of claim 49, further comprising a link state database, wherein said determination logic is operably coupled to examine said link state database to determine whether said destination is serviced by said tail-end device.
56. The apparatus of claim 49, wherein said tunnel comprises a label switched path to said tail-end device, and wherein said routing logic is operably coupled to affix to said information a predetermined label associated with said label switched path for label switching of said information from said head-end device to said tail-end device by a number of intermediate devices.
57. The apparatus of claim 49, wherein said routing logic is operably coupled to route said information to said tail-end device over one of said routes other than said tunnel, if and only if said destination is not serviced by said tail-end device.
58. A computer program for controlling a head-end device to limit traffic volume in a tunnel between said head-end device and a tail-end device, said head-end device having a number of routes to said tail-end for routing information to various destinations, the computer program comprising:
tunnel establishment logic programmed to establish said tunnel to said tail-end device as one of said number of routes;
receiving logic programmed to receive information for a destination;
determination logic programmed to determine whether said destination is serviced by said tail-end device; and routing logic programmed to route said information to said tail-end device through said tunnel if and only if said destination is serviced by said tail-end device.
tunnel establishment logic programmed to establish said tunnel to said tail-end device as one of said number of routes;
receiving logic programmed to receive information for a destination;
determination logic programmed to determine whether said destination is serviced by said tail-end device; and routing logic programmed to route said information to said tail-end device through said tunnel if and only if said destination is serviced by said tail-end device.
59. The computer program of claim 58, wherein said determination logic is programmed to determine whether said destination is a directly-connected host/subnet of said tail-end device.
60. The computer program of claim 58, wherein said determination logic is programmed to determine whether said destination is within a predetermined number of roister hops of said tail-end device.
61. The computer program of claim 60, further comprising monitoring logic programmed to monitor tunnel utilization, wherein said determination logic is programmed to dynamically increase said predetermined number of router hops if said tunnel is under-utilized and decrease said predetermined number of roister hops if said tunnel is over-utilized.
62. The computer program of claim 59, wherein said determination logic is programmed to determine whether said destination is said tail-end device.
63. The computer program of claim 59, wherein said determination logic is programmed to calculate said shortest path route to said destination, determine a shortest path route metric associate with said shortest path route, determine a tunnel metric associated with said tunnel, and determine from said shortest path route metric and said tunnel metric that said tunnel is a better route to said destination than said shortest path route.
64. The computer program of claim 59, wherein said determination logic is programmed to examine a link state database to determine whether said destination is serviced by said tail-end device.
65. The computer program of claim 59, wherein said tunnel comprises a label switched path from said head-end device to said tail-end device, and wherein said routing logic is programmed to affix to said information a predetermined label associated with said label switched path for label switching of said information from said head-end device to said tail-end device by a number of intermediate devices.
66. The computer program of claim 59, wherein said routing logic is programmed to route said information to said tail-end device over one of said routes other than said tunnel, if and only if said destination is not serviced by said tail-end device.
67. The computer program of claim 59 embodied in a computer readable medium.
68. The computer program of claim 59 embodied as a data signal.
69. A communication system comprising a head-end device in communication with a tail-end device via a number of routes including a tunnel for routing information to various destinations, wherein said head-end device is operably coupled to determine a number of said destinations that are serviced by said tail-end device and route information to said serviced destinations over said tunnel.
70. The communication system of claim 69, wherein said serviced destinations comprise directly-connected hosts/subnets of said tail-end device.
71. The communication system of claim 69, wherein said serviced destinations comprise destinations within a predetermined number of router hops of said tail-end device.
72. The communication system of claim 69, wherein said serviced destinations comprise said tail-end device.
73. The communication system of claim 69, wherein said serviced destinations comprise a destination for which said tunnel is a better route to said destination than a predetermined shortest path route to said destination.
74. The communication system of claim 69, wherein said tunnel comprises a label switched path from said head-end device to said tail-end device.
75. The communication system of claim 74, wherein said head-end device is operably coupled to affix to said information a predetermined label associated with said label switched path for label switching of said information from said head-end device to said tail-end device by a number of intermediate devices, and wherein said tail-end device is operably coupled to remove said label from said information and forward said information to said destinations based upon destination address information in said information.
76. The communication system of claim 69, wherein said head-end device is operably coupled to route information destined for other than said serviced destinations over one of said number of routes other than said tunnel.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/721,488 US7123587B1 (en) | 2000-11-22 | 2000-11-22 | System, device and method for limiting tunnel traffic in an information communication network |
| US09/721,488 | 2000-11-22 | ||
| PCT/US2001/051323 WO2002043323A2 (en) | 2000-11-22 | 2001-11-19 | Device and method for limiting tunnel traffic in a communication network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2429634A1 true CA2429634A1 (en) | 2002-05-30 |
Family
ID=24898193
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002429634A Abandoned CA2429634A1 (en) | 2000-11-22 | 2001-11-19 | System, device, and method for limiting tunnel traffic in an information communication network |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7123587B1 (en) |
| EP (1) | EP1358738A2 (en) |
| AU (1) | AU2002232956A1 (en) |
| CA (1) | CA2429634A1 (en) |
| WO (1) | WO2002043323A2 (en) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7593373B2 (en) * | 2001-12-12 | 2009-09-22 | At&T Intelectual Property Ii, Lp | Snoop-and-shortcut routing method for better mobility support on networks |
| GB0215505D0 (en) * | 2002-07-04 | 2002-08-14 | Univ Cambridge Tech | Packet routing |
| CN1961541B (en) * | 2004-04-16 | 2011-07-20 | 杜比实验室特许公司 | Devices and methods for routing a unit of data in a network |
| US7656805B2 (en) * | 2004-05-26 | 2010-02-02 | Sun Microsystems, Inc. | Optimal communication path routing in a system employing interconnected integrated circuit technology |
| US7855953B2 (en) * | 2005-10-20 | 2010-12-21 | Cisco Technology, Inc. | Method and apparatus for managing forwarding of data in an autonomous system |
| US20070091794A1 (en) * | 2005-10-20 | 2007-04-26 | Clarence Filsfils | Method of constructing a backup path in an autonomous system |
| US7852772B2 (en) * | 2005-10-20 | 2010-12-14 | Cisco Technology, Inc. | Method of implementing a backup path in an autonomous system |
| US7864669B2 (en) * | 2005-10-20 | 2011-01-04 | Cisco Technology, Inc. | Method of constructing a backup path in an autonomous system |
| US8644137B2 (en) * | 2006-02-13 | 2014-02-04 | Cisco Technology, Inc. | Method and system for providing safe dynamic link redundancy in a data network |
| US7493383B1 (en) * | 2006-12-29 | 2009-02-17 | F5 Networks, Inc. | TCP-over-TCP using multiple TCP streams |
| US8284780B2 (en) | 2008-01-14 | 2012-10-09 | At&T Intellectual Property I, L.P. | Adaptive edge-implemented traffic policy in a data processing network |
| US7843918B2 (en) * | 2008-01-25 | 2010-11-30 | Cisco Technology, Inc. | Selectively forwarding traffic through tunnels in a computer network |
| CN101534240B (en) * | 2008-03-14 | 2012-04-25 | 华为技术有限公司 | Method, system and device for sending mapping information |
| US8463880B2 (en) * | 2008-03-24 | 2013-06-11 | Hewlett-Packard Development Company, L.P. | Method and system for removing a tunnel between portal points |
| US8064362B2 (en) * | 2008-08-21 | 2011-11-22 | Cisco Technology, Inc. | Wide area network optimization proxy routing protocol |
| US9401855B2 (en) * | 2008-10-31 | 2016-07-26 | At&T Intellectual Property I, L.P. | Methods and apparatus to deliver media content across foreign networks |
| US9584414B2 (en) * | 2009-12-23 | 2017-02-28 | Pismo Labs Technology Limited | Throughput optimization for bonded variable bandwidth connections |
| US8612743B2 (en) * | 2011-07-26 | 2013-12-17 | The Boeing Company | Wireless network security |
| US9119077B2 (en) | 2011-07-26 | 2015-08-25 | The Boeing Company | Wireless network security |
| US9300564B2 (en) * | 2012-06-15 | 2016-03-29 | Cisco Technology, Inc. | Ordered flooding requests for path computation elements |
| US8929379B2 (en) * | 2012-06-21 | 2015-01-06 | Breakingpoint Systems, Inc. | High-speed CLD-based internal packet routing |
| US8811401B2 (en) | 2012-06-21 | 2014-08-19 | Breakingpoint Systems, Inc. | Binding of network flows to process threads |
| WO2018011889A1 (en) * | 2016-07-12 | 2018-01-18 | 三菱電機株式会社 | Communication device and communication system |
| CN109639600B (en) * | 2019-01-25 | 2022-07-01 | 新华三技术有限公司 | Tunnel speed limiting method and device |
| CN114513435A (en) * | 2022-01-14 | 2022-05-17 | 深信服科技股份有限公司 | Method for detecting VPN tunnel, electronic device and storage medium |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9100389D0 (en) * | 1991-01-09 | 1991-02-20 | Digital Equipment Corp | Method and apparatus for transparently bridging traffic across wide area networks |
| US5987259A (en) * | 1997-06-30 | 1999-11-16 | Sun Microsystems, Inc. | Functional unit switching for the allocation of registers |
| US6496491B2 (en) * | 1998-05-08 | 2002-12-17 | Lucent Technologies Inc. | Mobile point-to-point protocol |
| US6519254B1 (en) * | 1999-02-26 | 2003-02-11 | Lucent Technologies Inc. | RSVP-based tunnel protocol providing integrated services |
| US6751190B1 (en) * | 1999-05-18 | 2004-06-15 | Cisco Technology, Inc. | Multihop nested tunnel restoration |
| US6665273B1 (en) * | 2000-01-11 | 2003-12-16 | Cisco Technology, Inc. | Dynamically adjusting multiprotocol label switching (MPLS) traffic engineering tunnel bandwidth |
-
2000
- 2000-11-22 US US09/721,488 patent/US7123587B1/en not_active Expired - Lifetime
-
2001
- 2001-11-19 WO PCT/US2001/051323 patent/WO2002043323A2/en not_active Application Discontinuation
- 2001-11-19 CA CA002429634A patent/CA2429634A1/en not_active Abandoned
- 2001-11-19 AU AU2002232956A patent/AU2002232956A1/en not_active Abandoned
- 2001-11-19 EP EP01992474A patent/EP1358738A2/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| AU2002232956A1 (en) | 2002-06-03 |
| WO2002043323A3 (en) | 2003-08-21 |
| US7123587B1 (en) | 2006-10-17 |
| WO2002043323A2 (en) | 2002-05-30 |
| WO2002043323A9 (en) | 2003-04-24 |
| EP1358738A2 (en) | 2003-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7123587B1 (en) | System, device and method for limiting tunnel traffic in an information communication network | |
| US11424987B2 (en) | Segment routing: PCE driven dynamic setup of forwarding adjacencies and explicit path | |
| EP2904747B1 (en) | Mpls segment-routing | |
| US8171162B2 (en) | Methods and apparatus for using both LDP and RSVP in a communications system | |
| EP1741247B1 (en) | Router configured for outputting update messages specifying a detected attribute change of a connected active path according to a prescribed routing protocol | |
| EP2974176B1 (en) | Segment routing: pce driven dynamic setup of forwarding adjacencies and explicit path | |
| US7082140B1 (en) | System, device and method for supporting a label switched path across a non-MPLS compliant segment | |
| US7149217B2 (en) | Load-sharing technique for distributing multi-protocol label switching protocol encapsulated flows across multiple physical links | |
| EP3869751B1 (en) | Flexible algorithm aware border gateway protocol (bgp) prefix segment routing identifiers (sids) | |
| JP4104554B2 (en) | Packet container transfer in connection-oriented protocols | |
| US20130266018A1 (en) | Communication system and communication method | |
| US11616726B2 (en) | End-to-end flow monitoring in a computer network | |
| US20170041239A1 (en) | Backward congestion notification in layer-3 networks | |
| EP3754914A1 (en) | Class-based traffic engineering in an ip network | |
| US7233593B2 (en) | System, device, and method for routing information in a communication network using policy extrapolation | |
| CN114128240A (en) | Compressed data transmission in a network implementing an interior gateway protocol | |
| US7680113B2 (en) | Inter-FE MPLS LSP mesh network for switching and resiliency in SoftRouter architecture | |
| EP3941006B1 (en) | System and method for carrying and optimizing internet traffic over a source-selected path routing network | |
| EP3621251B1 (en) | Packet processing | |
| US20220255838A1 (en) | A Method and a Device for Routing Traffic Along an IGP Shortcut Path | |
| CN114666268A (en) | Packet reordering in a packet-switched network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |