scispace - formally typeset
Search or ask a question

Showing papers on "Virtual routing and forwarding published in 2001"


Proceedings ArticleDOI
27 Aug 2001
TL;DR: This work presents a hash-based technique for IP traceback that generates audit trails for traffic within the network, and can trace the origin of a single IP packet delivered by the network in the recent past and is implementable in current or next-generation routing hardware.
Abstract: The design of the IP protocol makes it difficult to reliably identify the originator of an IP packet. Even in the absence of any deliberate attempt to disguise a packet's origin, wide-spread packet forwarding techniques such as NAT and encapsulation may obscure the packet's true source. Techniques have been developed to determine the source of large packet flows, but, to date, no system has been presented to track individual packets in an efficient, scalable fashion.We present a hash-based technique for IP traceback that generates audit trails for traffic within the network, and can trace the origin of a single IP packet delivered by the network in the recent past. We demonstrate that the system is effective, space-efficient (requiring approximately 0.5% of the link capacity per unit time in storage), and implementable in current or next-generation routing hardware. We present both analytic and simulation results showing the system's effectiveness.

797 citations


Proceedings ArticleDOI
22 Apr 2001
TL;DR: The developed scheme performs very well in terms of performance metrics such as the number of rejected demands and the performance objective is the accomodation of as many requests as possible without requiring any a priori knowledge regarding future arrivals.
Abstract: This paper develops an algorithm for integrated dynamic routing of bandwidth guaranteed paths in IP over WDM networks. By integrated routing, we mean routing taking into account the combined topology and resource usage information at the IP and optical layers. Typically, routing in IP over WDM networks has been separated into routing at the IP layer taking only IP layer information into account, and wavelength routing at the optical layer taking only optical network information into account. The motivation for integrated routing is the potential for better network usage, and this is a topic which has not been been studied extensively. We develop an integrated routing algorithm that determines (1) whether to route an arriving request over the existing topology or whether it is better to open new wavelength paths. Sometimes it is better to open new wavelength paths even if it feasible to route the current demand over the existing IP topology due to previously set-up wavelength paths. 2) For routing over the existing IP-level topology, compute "good" routes. (3) If new wavelength paths are to be set-up, determine the routers amongst which new wavelength paths are to be set-up and compute "good" routes for these new wavelength paths. The performance objective is the accomodation of as many requests as possible without requiring any a priori knowledge regarding future arrivals. The route computations account for the presence or absence of wavelength conversion capabilities at optical crossconnects. We show that the developed scheme performs very well in terms of performance metrics such as the number of rejected demands.

196 citations


Patent
Anand Rangarajan1, Sanjay Bakshi1
05 Jul 2001
TL;DR: In this article, a modularized routing system includes a control element and forwarding elements, all of which are connected via a private network, for example, an Ethernet, and the control element computes a routing table for each of the forwarding elements.
Abstract: A modularized routing system includes a control element and forwarding elements, all of which are connected via a private network, for example, an Ethernet. The control element computes a routing table for each of the forwarding elements. Based on information in the routing table, a forwarding element decrements a time-to-live counter in the packet header only if the forwarding element is the first one in the routing system encountered by the packet. Accordingly, the forwarding elements preserve the behavior of a single router while using substantially the same routing protocols as the single router.

168 citations


Journal ArticleDOI
TL;DR: This work studied `hop-by-hop destination based only' (HbHDBO) QoS routing that ignores the source and previous path history (as in current IP routing) and demonstrates that an exact QoS algorithm assures the avoidance of routing loops in this HbHD BO setting.

166 citations


Journal ArticleDOI
TL;DR: This paper examines strategies for implementing and operating IP routing effectively within satellite constellation networks, given known constraints on the constellation resulting from satellite mobility, global visibility, routing and addressing.
Abstract: This paper examines strategies for implementing and operating IP routing effectively within satellite constellation networks, given known constraints on the constellation resulting from satellite mobility, global visibility, routing and addressing.

164 citations


Proceedings ArticleDOI
11 Jun 2001
TL;DR: The integration improves the scalability of the mobile IP data forwarding process by leveraging on the features of MPLS which are fast switching, small state maintenance and high scalability.
Abstract: Multi-protocol label switching (MPLS) is a technology that combines the simplicity of IP routing with the high-speed switching of ATM. Mobile IP is a protocol that allows users to move around and yet maintain continuous IP network connectivity. We propose a scheme to integrate the mobile IP and MPLS protocols. The integration improves the scalability of the mobile IP data forwarding process by leveraging on the features of MPLS which are fast switching, small state maintenance and high scalability. In addition, we have removed the need for IP-in-IP tunneling from home agent (HA) to foreign agent (FA) under this scheme. This paper covers some issues regarding mobile IP scalability and also defines the signaling and control mechanisms required to integrate MPLS and mobile IP.

101 citations


01 Jan 2001
TL;DR: The artificial workload model uses both detailed knowledge and measured characteristics of the user application programs responsible for the traffic to drive simulation experiments of communication protocols and flow and congestion control experiments, for existing and future networks.
Abstract: We present an artificial workload model of wide-area internetwork traffic. The model can be used to drive simulation experiments of communication protocols and flow and congestion control experiments. The model is based on analysis of wide-area TCP/IP traffic collected from one industrial and two academic networks. The artificial workload model uses both detailed knowledge and measured characteristics of the user application programs responsible for the traffic. Observations drawn from our measurements contradict some commonly held beliefs regarding wide-area TCP/IP network traffic. The simulation techniques presented here will be useful in studying congestion control, routing algorithms, and other resource management schemes, for existing and future networks.

100 citations


Proceedings ArticleDOI
30 Sep 2001
TL;DR: Assigning a wavelength label as well as a label in a DPSK modulation format orthogonal to the data payload significantly increases the forwarding and routing capabilities of optical packet routers in IP-over-WDM networks.
Abstract: Assigning a wavelength label as well as a label in a DPSK modulation format orthogonal to the data payload significantly increases the forwarding and routing capabilities of optical packet routers in IP-over-WDM networks.

96 citations


Patent
26 Apr 2001
TL;DR: In this paper, a group of Secure Gateway Devices (1302-1312) is connected between their respective local area networks (1314-1324) and a public network (such as the internet) (1300).
Abstract: A group of Secure Gateway Devices (1302-1312) is connected between their respective local area networks (1314-1324), and a public network (such as the internet) (1300). The Secure Gateway Devices (1302-1312) create a cloud of virtual gateways that are all located at the same virtual IP address. On this network, standard routing protocols are used by network devices to pass their routing information, in real time, to each other. All communications between Secure Gateway Devices (1302-1312) are done via IP tunnels using tunneling protocols.

92 citations


Patent
12 Jun 2001
TL;DR: In this paper, the authors propose a method of sending IP packets from a host on a home network to hosts on remote networks by assigning a network ID to each network, assigning virtual IP addresses to the home network where each virtual IP address represents a host in one of the remote networks and each virtual address has the same network ID as the home one.
Abstract: On a plurality of IP networks where each network is remote from every other network and is connected to the internet by a VPN-router, a method of sending IP packets from a host on a home network to hosts on remote networks by assigning a network ID to each network, assigning IP addresses to hosts on each network, assigning virtual IP addresses to the home network where each virtual IP address represents a host on one of the remote networks and each virtual IP address has the same network ID as the home network, assigning virtual IP addresses to each remote network where the virtual IP addresses represent a host on the home network and each virtual IP address has the same network ID as the remote network to which it is assigned; creating, in each VPN-router, tables that cross reference each virtual IP address assigned to the VPN-router's network to the I network ID of the remote network of the host which the virtual IP address represents, and cross referencing the IP address of each host on the VPN-router's network to the virtual IP addresses representing those hosts on other networks; and sending a plurality of IP packets from one or more hosts on the home network to one or more hosts on remote networks by addressing the packets to virtual IP addresses assigned to the home network representing the destination hosts on the remote networks.

84 citations


Patent
28 Dec 2001
TL;DR: A system and method of sending and receiving voice calls over the Internet is described in this article, which includes a PSTN-derived intelligent call routing engine that receives call control messages from the Voice over IP (VoIP) network and routes calls via previously stored, customized routing procedures.
Abstract: A system and method of sending and receiving voice calls over the Internet is described. The system includes a PSTN-derived intelligent call routing engine that receives call control messages from the Voice over IP (VoIP) network and routes calls via previously stored, customized routing procedures. Special dialing plan, 800 numbers, minimized cost routing, time and day-based least cost routing, transferring, conferencing, and additional messaging capabilities are provided. The system operates on standard server computers with interface cards connected to the packetized networks via TCP/IP and, indirectly, to VoIP gateways to accessing PSTN networks and to virtual and/or private networks (PBXs).

Patent
Toshiro Yamauchi1
05 Sep 2001
TL;DR: An MPLS-VPN (MultiProtocol Label Switching-Virtual Private Network) service network of the present invention includes an interface identifying device as discussed by the authors, which includes a virtual router belonging to a preselected VPN and an MPLS label operating section for stacking or removing MPLS labels on or from an IP packet received from the virtual router.
Abstract: An MPLS-VPN (MultiProtocol Label Switching-Virtual Private Network) service network of the present invention includes an interface identifying device. The Interface identifying device includes a virtual router belonging to a preselected VPN and an MPLS label operating section for stacking or removing MPLS labels on or from an IP packet received from the virtual router. The label operating section is made up of a first-stage label operating section for stacking on an IP packet received from a customer an MPLS label for transferring the packet over the network and a second-stage MPLS label operating section for executing label operation for identifying a virtual interface. The network constructs a virtual interface at each virtual router for allowing a routing protocol to operate between user sites that belong to the same VPN.

Patent
02 Mar 2001
TL;DR: In this paper, the authors present a method and system for routing information lookup for packets using a routing protocol such as IP, which is performed in response to at least one set of selected routing information, using a lookup table which includes tags both for the routing information and for bitmask length.
Abstract: The invention provides a method and system for routing information lookup for packets using a routing protocol such as IP. Routing information which has been determined responsive to the packet header, which includes a destination address, a source address, and an input interface for the packet. Routing lookup is performed in response to at least one set of selected routing information, using a lookup table which includes tags both for the routing information and for a bitmask length (thus indicating the generality or scope of the routing information for the routing lookup). The lookup table is structured so that addresses having the most common bitmask length are addressed first, but that more specific addresses are still considered when they are present. It has been discovered that most internet addresses can be found by reference to 24-bit or 21-bit IP addresses, after which 16-bit, 12-bit, and finally 32-bit IP addresses are considered. Lookup flags indicate when a relatively uncommon but more specific 32-bit IP address match is available. A memory controller pipelines the lookup requests to a hash table memory, flushes superfluous requests when a lookup result is found, and handles cases relating to 32-bit IP address matches.

Journal ArticleDOI
J. Lawrence1
TL;DR: This article emphasizes MPLS point of presence design, routing design issues for MPLS, and provisioning of sufficient label space.
Abstract: Multiprotocol label switching adds to the capabilities of IP networks in several ways. Despite new capabilities, MPLS technology has much in common with ordinary IP networks. In turn, the design process for MPLS networks has much in common with the design of any IP network. This article examines MPLS and IP technology with particular emphasis on what is common between them. The common design steps of MPLS networks and other IP networks are outlined briefly, and those issues specific to MPLS networks are covered in more detail. This article emphasizes MPLS point of presence design, routing design issues for MPLS, and provisioning of sufficient label space.

Journal ArticleDOI
TL;DR: This work discusses the aspects of optical routing that differ from routing in irrational IP networks, highlighting the issue of wavelength continuity and the differences between lightpath computation and traditional IP route computation.
Abstract: An overview of current issues and challenges in lightpath routing for optical networks is given. An architecture is presented in which optical switches are deployed, usually in the core, to interconnect IP routers at the edges. Lightpath routing within this architecture follows the framework of generalized multiprotocol label switching. Our discussion pays particular attention to the aspects of optical routing that differ from routing in irrational IP networks. Such aspects include physical layer constraints, wavelength continuity, the decoupling of the control network topology from the data network topology, explicit routing with wavelength assignment, and diversity routing for fast protection. We also present an algorithmic framework for lightpath computation, highlighting the issue of wavelength continuity and the differences between lightpath computation and traditional IP route computation.

Patent
31 May 2001
TL;DR: In this article, a signaling gateway routing node is adapted to facilitate signaling communication between nodes in a signaling system 7 (SS7) network and nodes in an Internet protocol (IP) type network.
Abstract: Disclosed is a communications network element that is capable of routing signaling messages and also performing inter-network management functions in a converged telephony-data network environment. A signaling gateway routing node is adapted to facilitate signaling communication between nodes in a signaling system 7 network and nodes in an Internet protocol (IP) type network. In addition to basic message routing functionality, the signaling gateway routing node is adapted to notify nodes in the IP network when a node in the SS7 network becomes congested or unavailable. In certain cases, the signaling gateway selectively notifies only IP nodes that are concerned with the status of the troubled SS7 node, while in other cases, notification messages are broadcast to all relevant IP nodes. The signaling gateway also serves to filter redundant congestion status queries or polling type messages that are conveyed from IP nodes through to the distressed SS7 node.

Patent
20 Apr 2001
TL;DR: In this article, the authors propose a self-registering data communication module (sDCM) that is adapted to receive and process dynamic routing key registration messages from associated IP nodes.
Abstract: Disclosed is a communications network element that is capable of routing signaling messages and includes a dynamic routing key registration feature which allows Internet protocol (IP) nodes to automatically register/de-register and subsequently direct traffic towards or away from themselves without the need for manual operator intervention. A signaling gateway routing node includes a self-registering data communication module (sDCM) that is adapted to receive and process dynamic routing key registration messages from associated IP nodes. Such dynamic routing key registration messages may include information that is used to register a new routing key association with a TCP/IP connection, de-register an existing routing key association with the TCP/IP connection, or modify routing key information associated with the TCP/IP connection.

Journal ArticleDOI
TL;DR: TIMIP is a new architecture for IP mobility in wireless access networks based on principles similar to those in the CIP and HAWAII architectures proposed at IETF and is equally suited for micromobility scenarios.
Abstract: This article presents Terminal Independent Mobility for IP (TIMIP), which is a new architecture for IP mobility in wireless access networks. TIMIP is based on principles similar to those in the CIP and HAWAII architectures proposed at IETF and is equally suited for micromobility scenarios. With TIMIP, terminals with legacy IP stacks have the same degree of mobility as terminals with mobility-aware IP stacks. Nevertheless, it still uses MIP for macromobility scenarios. In order to support seamless handoff, TIMIP uses context-transfer mechanisms compatible with those currently in discussion at the IETF SeaMoby group.

01 Jan 2001
TL;DR: The key idea in the approach is to use multipaths to implement “near-optimal” routing, while keeping the scalability of data and control plane mechanisms similar to that in today's IP routing, which preserves the connection-less nature of the IP architecture.
Abstract: The success of the IP architecture is largely due to the simplicity, robustness and scalability that resulted from its the connection-less design methodology. As the Internet evolves, it must support new services such as QoS, and when extensions are made to the EP architecture to support such services, its basic connection-less model must be preserved to retain the scalability and robustness that made it so successful. In the past few years, with the Internet becoming the main communication infrastructure, IP networks are faced with two challenging problems that require immediate attention: traffic engineering and supporting guaranteed services. Providing efficient, robust and scalable solutions to these problems within the framework of the connection-less IP has become extremely important and urgent. The traffic engineering problem arose mainly because the single-path routing prevalent in IP networks proved very inefficient in the face of rapid growth of the Internet. To improve performance of current IP networks, several solutions based on the multi-protocol label-switching (MPLS) have been proposed by IETF. The main idea in these approaches is to setup alternate paths using label-switching, and distribute traffic over them. There are couple of serious concerns with these approach. First, most of the proposed solutions are not based on any theoretical results on optimal routing. Second, using connection-oriented technology like virtual circuits or MPLS violates its connection-less methodology of IP that contributed to the very success of the Internet. These approaches tend to replace the IP architecture, rather than evolve it. We propose a solution to the traffic engineering problem that addresses these concerns. The key idea in our approach is to use multipaths to implement “near-optimal” routing, while keeping the scalability of data and control plane mechanisms similar to that in today's IP routing. More importantly, the proposed approach preserves the connection-less nature of the IP architecture. Today, there is a growing need to support real-time applications that require delay and bandwidth guarantees. To address this, the IETF proposed the Intserv architecture and the associated RSVP. This architecture does not scale well to backbone networks that carry large numbers of flows because of the per-flow reservations and per-flow processing that is required in the routers. Several other architectures have also been proposed to support guaranteed services, but most of them are either inefficient in terms of bandwidth utilization, or use connection-oriented approaches such as virtual circuits and MPLS. The main concern with all these architecture, besides scalability, is that they introduce connection-oriented mechanisms in the IP architecture, thus compromising its robustness. We base our approach to this problem on multipaths, and provide a complete solution through a novel architecture, SMART, which adheres to connection-less nature of the IP architecture. We show how multipaths can help achieve scalability and performance of the network, without sacrificing the kind of service guarantees that can be offered to end users.

Journal ArticleDOI
01 Oct 2001
TL;DR: A middleware layer to extend IP routing to work with MOPEDs and a lightweight IP encapsulation protocol, Multipath Routing enCAPsulation (MRCAP), used to implement that middleware is introduced.
Abstract: We propose a networking model that treats a user's set of personal devices as a MObile grouPEd Device, a MOPED, which appears as a single entity to the rest of the Internet. All communication for a user is directed to this point of presence. As the user moves through different environments, the devices cooperate to provide the user with access to all available communication resources. We present the basic networking functionality necessary to enable the operation of MOPEDs and their integration into the Internet. We introduce a middleware layer to extend IP routing to work with MOPEDs and a lightweight IP encapsulation protocol, Multipath Routing enCAPsulation (MRCAP), used to implement that middleware.

Patent
Gregory S. Fisher1
16 Mar 2001
TL;DR: In this paper, a local network router dynamically generates a routing table from address resolution protocol (ARP) packets exchanged between the CPE and the external network for each IP data packet received from a CPE that is destined for another local CPE.
Abstract: A local network router learns to route IP traffic among customer premises equipment on a local network rather than permitting the IP traffic to be routed through a broadband cable network and selected internet service provider (ISP) to the internet. The local network router dynamically generates a routing table from address resolution protocol (ARP) packets exchanged between the CPE and the external network. For each IP data packet received from a CPE that is destined for another local CPE, the local network router replaces a default gateway with the destination CPE. Accordingly, network resources for routing traffic are significantly reduced.

Patent
30 Oct 2001
TL;DR: A forwarding engine of a router device may replace addresses of some IP packets by virtual ones such to mask the active routing daemon as mentioned in this paper, which is used in unicast regime when said forwarding engine forwards incoming IP packets from neighbor routers to said routing daemon.
Abstract: A forwarding engine of a router device may replace addresses of some IP packets by virtual ones such to mask the active routing daemon. This is used in unicast regime when said forwarding engine forwards incoming IP packets from neighbor routers to said routing daemon. It is also used in unicast as well as in multicast regime in the opposite case. A standby routing daemon may also be used on another processor by affecting same virtual addresses for its ports as the first active routing daemon. In a case of failure of the first active routing daemon, a controller will switch said standby routing daemon to be the new active daemon connected to the forwarding engine. A CompactPCI bus can be advantageously used. In that case, the forwarding engine is a peripheral board of the controller of that CompactPCI.

Book
01 Apr 2001
TL;DR: This chapter discusses external Gateway Protocol, BGP Configuration and Troubleshooting, and Router Management, which is used in the BGP-4 and Multicast Routing manuals.
Abstract: I. EXTERIOR GATEWAY PROTOCOLS. 1. Exterior Gateway Protocol. 2. Introduction to BGP-4. 3. BGP Configuration and Troubleshooting. II. ADVANCED IP ROUTING ISSUES. 4. Network Address Translation. 5. Introduction to Multicast Routing. 6. Configuration and Troubleshooting for Multicast Routing. 7. Large-Scale Multicast Routing. 8. IPv6. 9. Router Management. Appendix A: Field Details for the, 'show ip bgp neighbor' Output. Appendix B: A Regular Expression Tutorial. Appendix C: Answers to Review Questions. Appendix D: Answers to Configuration Exercises. Answers to Troubleshooting Exercises.

01 Jan 2001
TL;DR: It is shown, both theoretically and by simulations, that source invariant routing can be significantly worse than per-flow routing, and develops novel routing algorithms that are based on dynamic weights, and empirically study their performance in an Internet like environment.
Abstract: In the traditional IP scheme, both the packet forwarding and the routing protocols are source invariant, i.e., their decisions depend on the destination IP address and not on the source address. Recent protocols, such as MPLS, as well as traditional circuit based protocols like PNNI allow routing decisions to depend both on the source and destination addresses. In fact, much of the theoretical work on routing assumes per-flow forwarding and routing, i.e., the forwarding decision is based both on the source and destination addresses. The benefit of per-flow forwarding is well-accepted, so is the practical implications of its deployment. Nevertheless, no quantitative study has been carried on the performance differences between the two approaches. This work aims at investigating the toll in terms of performance degradation that is incurred by source invariant schemes, as opposed to the per-flow alternatives. We show, both theoretically and by simulations, that source invariant routing can be significantly worse than per-flow routing. Realizing that static shortest path algorithms are not optimal even among the source invariant routing algorithms, we develop novel routing algorithms that are based on dynamic weights, and empirically study their performance in an Internet like environment. Paper Available at: ftp://dimacs.rutgers.edu/pub/dimacs/TechnicalReports/TechReports/2001/2001-17.ps.gz

Patent
15 Feb 2001
TL;DR: In this article, an IP Packet Access Gateway (IP PAG) system manages an IP bearer path between communicating IP endpoints, which includes an IP PAG having a first IP bearer connection termination for terminating a first bearer connection with a first endpoint, and a second IP connection termination or terminating a second connection with another IP endpoint.
Abstract: An IP Packet Access Gateway (IP PAG) system manages an IP bearer path between communicating IP endpoints. The system includes an IP PAG having a first IP bearer connection termination for terminating a first bearer connection with a first IP endpoint, and a second IP connection termination or terminating a second bearer connection with a second IP endpoint. A call control entity is associated with the IP PAG and communicates call control instructions thereto. The call control instructions include instructions for logically concatenating the connections into an active IP bearer path extending between the first IP endpoint and the second IP endpoint. A bearer traffic IP packet handler in the IP PAG moves bearer traffic IP packet payloads over the active IP bearer path.

Proceedings ArticleDOI
03 Sep 2001
TL;DR: This paper proposes an easy-to-implement strategy to complete up*/down* forwarding tables for IBA switches that guarantees deadlock freedom, and is effective whatever the methodology applied to compute up*/ down* routing tables.
Abstract: InfiniBand is very likely to become the facto standard for communication between processing nodes and I/O devices as well as for interprocessor communication. The InifiniBand Architecture (IBA) defines a switch-based network with point-to-point links that support any topology defined by the user. Routing in IBA is distributed based on forwarding tables, and only considers the packet destination ID for routing within subnets. Up*/down* routing is the simplest and most popular routing algorithm for irregular topologies. Unfortunately, up*/down* routing cannot be used in IBA switches because it may leads to deadlock. In this paper we address this issue, proposing an easy-to-implement strategy to complete up*/down* forwarding tables for IBA switches that guarantees deadlock freedom, and is effective whatever the methodology applied to compute up*/down* routing tables. Preliminary evaluation results modeling an InfiniBand network at register transfer level show that the proposed strategy allows up*/down* routing algorithms to be implemented on InfiniBand networks with minimal performance degradation.

Proceedings ArticleDOI
13 Mar 2001
TL;DR: This paper presents an IP component matching system targeting automatic component searching and matching across the Internet based on Extensible Markup Language (XML) specification both for IP libraries and IP user queries.
Abstract: Intellectual Property (IP) reuse is one of the most promising techniques addressing the design complexity problem. IP reuse assumes that pre-designed components can be integrated into the design under development, thereby reducing design complexity and time. On the other hand, as the number of IP providers increases, the selection of the best IP block for a given design becomes more challenging and time-consuming. In this paper, we present an IP component matching system targeting automatic component searching and matching across the Internet. The system is based on Extensible Markup Language (XML) specification both for IP libraries (a repository of pre-designed IP components indexed by their corresponding specifications) and IP user queries (specifications with incomplete/uncertain attributes). An IP query is parsed into a document object model (DOM) and the DOM is transformed to an internal tree-structured model. Fuzzy logic scoring and aggregation algorithms are applied to the internal tree structure to provide a set of candidate approximate matches ranked by proximity between the query and IP specification.

Proceedings Article
03 Sep 2001
TL;DR: This paper proposes an easy-to-implement strategy to adapt the forwarding tables already computed following any routing algorithm that considers the destination ID and the input channel into the required IBA forwarding table format, and the resulting routing algorithm is deadlock-free on IBA.
Abstract: The InfiniBand Architecture (IBA) defines a switch-based network with point-to-point links that supports any topology defined by the usel; including irregular ones, in order toprovide flexibility and incremental expansion capability. Routing in IBA is distributed, based on forwarding tables, and only considers the packet destination ID for routing within subnets in order to drastically reduce forwarding table size. Unfortunately, the forwarding tables for most of the previously proposed routing algorithms for irregular topologies consider both the destination ID and the input channel. Therefore, these popular routing algorithms for irregular topologies may not be usable in InfiniBand networks because they do not conform to the IBA specijications. In this paper; we propose an easy-to-implement strategy to adapt the forwarding tables already computed following any routing algorithm that considers the destination ID and the input channel into the required IBA forwarding table format. The resulting routing algorithm is deadlock-free on IBA. Indeed, the originally computed paths are not modified at all. Hence, the proposed strategy does not degrade pegormanee with respect to the original routing scheme.

Journal ArticleDOI
TL;DR: It is demonstrated that both ALR forwarding policies can efficiently handle traffic load sharing among alternative routes, significantly reducing peak values of link load which is a central goal of ISL network dimensioning.
Abstract: The implementation of a satellite communication network consisting of intersatellite links provides a highly interconnected backbone in the space segment, increasing the network flexibility and reliability, while, on the other hand, introducing numerous issues related to network dimensioning, efficient resource management, adaptive routing, etc. In this paper we study two forwarding policies based on alternate link routing (ALR) and compare their performance with that of a simple forwarding policy employing shortest path routing (SPR) without options. All forwarding policies compared in this study are operating on routing tables calculated with the Dijkstra shortest path algorithm, capable of adapting to traffic load and propagation delay on the links through the appropriately selected link cost metric. Using an ISL network simulator, we demonstrate that both ALR forwarding policies can efficiently handle traffic load sharing among alternative routes, significantly reducing peak values of link load which is a central goal of ISL network dimensioning.

Proceedings ArticleDOI
01 Jan 2001
TL;DR: This paper proposes an easy-to-implement strategy to adapt the forwarding tables already computed following any routing algorithm that considers the destination ID and the input channel into the required IBA forwarding table format, and the resulting routing algorithm is deadlock-free on IBA.
Abstract: The InfiniBand Architecture (IBA) defines a switch-based network with point-to-point links that supports any topology defined by the user including irregular ones, in order to provide flexibility and incremental expansion capability. Routing in IBA is distributed, based on forwarding tables, and only considers the packet destination ID for routing within subnets in order to drastically reduce forwarding table size. Unfortunately, the forwarding tables for most of the previously proposed routing algorithms for irregular topologies consider both the destination ID and the input channel. Therefore, these popular routing algorithms for irregular topologies may not be usable in InfiniBand networks because they do nor conform to the IBA specifications. In this paper we propose an easy-to-implement strategy to adapt the forwarding tables already computed following any routing algorithm that considers the destination ID and the input channel into the required IBA forwarding table format. The resulting routing algorithm is deadlock-free on IBA. Indeed, the originally computed paths are not modified at all. Hence, the proposed strategy does not degrade performance with respect to the original routing scheme.