Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing
Reexamination Certificate
1999-06-15
2003-08-05
Maung, Zarni (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
C709S230000, C709S217000, C455S039000
Reexamination Certificate
active
06604146
ABSTRACT:
BACKGROUND OF INVENTION
Mesh satellite networks can be used to interconnect sites with traffic destined for several locations. These networks offer single-satellite-hop connectivity in contrast to hub/spoke type networks where all traffic is first sent to a hub and then re-distributed to the destination. Time Division Multiple Access (TDMA), Single Channel Per Carrier (SCPC)-Demand Assigned Multiple Access (DAMA), and Code Division Multiple Access (CDMA) schemes are commonly used for mesh networks. Packet switched services such as X.25, Frame-relay, or ATM have been offered in mesh networks using Virtual Circuits (VCs) between sites which need to exchange information. These Layer-2 protocols have been used to carry IP, IPX, SNA and other higher layer protocol traffic. Partial or full mesh connectivity using VC-based Layer-2 protocols requires multiple virtual circuits and significant resources are required for setup and management of these virtual circuits. This can be avoided if IP services were offered in a native fashion in the mesh satellite network. IP packets will be routed to the appropriate destination using information available in IP packet header (typically the 32 bit destination address). For interoperability with the terrestrial IP infrastructure, standard IP routing protocols will need to be supported by the satellite network. These routing protocols basically consist of messages exchanged between routers which provide connectivity information (i.e. the next hop information for incoming IP packets) and help determine the state of the interconnecting links.
The most straightforward technique for enabling IP services in a mesh satellite network would be to incorporate routing capabilities into each terminal. A packet-switched satellite terminal typically has one or more terrestrial interfaces (such as X.25, frame-relay, ATM, or ethernet) and a single physical satellite interface. The satellite interface can be used to communicate with one, many, or all of the terminals in the network depending on the beam connectivity and available bandwidth on the satellite. Since routing messages are typically exchanged between a router and all of its adjacent neighbors, the terminal/router would need to periodically communicate with all of the terminal/routers in the mesh thereby using up precious bandwidth. Modifications to RIP-
2
and OSPF, the most commonly used Interior Gateway Protocols have been suggested to minimize routing traffic for on-demand networks (e.g., J. Moy, “Extending OSPF to support demand circuits”, RFC 1793, April 1995), but these modifications are not widely implemented. In addition, supporting routing protocols such as Open Shortest Path First (OSPF) and Boundary Gateway Protocol (BGP) can take up significant CPU and memory resources. In many cases, large routing tables need to be maintained which would consume several megabytes of memory. Further, significant effort may be required to port and test routing protocol software.
A “route server” has been proposed for Multiprotocol over ATM (MPOA) transport in terrestrial ATM networks, as described in Multiprotocol over ATM (MPOA) v1.0 ATM Forum Specification af-mpoa-0087.000, July 1997, available at http://www.atmforum.com/atmforum/specs/approved.html, but has never been proposed for use in connection with satellite networks. In terrestrial ATM networks, there is no pressing need to minimize bandwidth usage between terminals (edge devices in MPOA terminology) and the route server, and the specific techniques disclosed in this reference would not be practical in connection with a meshed satellite network.
SUMMARY OF INVENTION
It is, therefore, an object of the present invention to provide a bandwidth-efficient technique for routing IP traffic over meshed satellite networks.
This and other objects are achieved according to the present invention by a system architecture wherein routing protocols run in a centralized route server (implemented on a standard UNIX workstation). In this architecture, the satellite network is part of a router fabric, with terminals appearing as ports attached to the router core (the route-server). External routers will establish routing sessions only with route-server and not with other terminals. Routing packets originated by an external router attached to a terminal will be conveyed transparently to the route-server. Forwarding (Next-hop) information will be provided by the route-server to all terminals. This information will be used to create a forwarding table in each terminal. The destination of an IP packet will be looked up in the forwarding table, and the IP packet will be sent to the destination if a connection with spare bandwidth exists to the destination terminal. If no connection exists, then the packets will be queued up until the connection is created and bandwidth is allocated, or sent over a fixed broadcast contention-based channel until the dedicated connection is established.
Implementing the route-server on a workstation provides enough CPU and memory resources to run common routing protocols and store large routing tables. The route-server can be easily upgraded with more memory and extra processing power in many cases. Many implementations of routing protocols exist for UNIX, so the porting and testing time is no longer an issue.
The invention minimizes the CPU and memory resources required at the end terminals to support IP routing protocols, and reduces the satellite bandwidth required to support full mesh IP routing packets. By supporting native IP services, the effort required to configure and manage partial or full mesh networks is minimized.
REFERENCES:
patent: 5490252 (1996-02-01), Macera et al.
patent: 5541911 (1996-07-01), Nilakantan et al.
patent: 5740164 (1998-04-01), Liron
patent: 5757784 (1998-05-01), Liebowitz et al.
patent: 5812545 (1998-09-01), Liebowitz et al.
patent: 5841765 (1998-11-01), Fielding et al.
patent: 5848143 (1998-12-01), Andrews et al.
patent: 6038594 (2000-03-01), Puente et al.
patent: 6085247 (2000-07-01), Parsons, Jr. et al.
patent: 6115750 (2000-09-01), Dillon et al.
patent: 6161141 (2000-12-01), Dillon
patent: 6205473 (2001-03-01), Thomasson et al.
patent: 6262982 (2001-07-01), Donahue et al.
patent: 6275496 (2001-08-01), Burns et al.
patent: 6289389 (2001-09-01), Kikinis
patent: 6310893 (2001-10-01), Yuan et al.
patent: 6317603 (2001-11-01), Allison
patent: 6404769 (2002-06-01), Kapoor
patent: WO 97/25787 (1997-07-01), None
patent: WO 98/16046 (1998-04-01), None
Rao Ashok K.
Rempe Steven P.
Shyamsundar Gokhale D.
Maung Zarni
Viasat, Inc.
LandOfFree
Efficient internet service implementation for mesh satellite... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Efficient internet service implementation for mesh satellite..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Efficient internet service implementation for mesh satellite... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3127953