Multiplex communications – Data flow congestion prevention or control – Flow control of data transmission through a network
Reexamination Certificate
1999-12-27
2004-12-07
Duong, Frank (Department: 2666)
Multiplex communications
Data flow congestion prevention or control
Flow control of data transmission through a network
C370S248000, C370S252000
Reexamination Certificate
active
06829221
ABSTRACT:
BACKGROUND TO THE INVENTION
The invention relates, in general, to a system and method for dynamically managing the transport of internet protocol-based traffic between user terminals and external ‘gateways’, and is particularly, but not exclusively, applicable in the context of a satellite system having a multiplicity of user beams accessible from several gateways of an internet-type terrestrial domain.
SUMMARY OF THE PRIOR ART
In modern telecommunication systems, information (such as coded speech and data) may be transferred using a variety of techniques across a plethora of system architectures, including satellite links, internet domains and broadband networks. With demand for constantly increasing levels of service, communication technologies are embracing integration of systems to provide enhanced architectures that synergistically benefit from efficient use of transport mechanisms during successive environments. However, the interworking of differing communication technologies often leads to implementation problems, particularly associated with the inability of different systems to realy, in a contiguous and seamless fashion, control information in a usable form. There are clearly mechanisms that allow for direct translation, or the re-packaging of information, but with integration of certain communication architectures and protocols in there embryonic stages the issues of providing full interworking are yet to be fully appreciated or addressed.
In multimedia broadband satellite systems, there is a necessity to transport traffic between user terminals and external gateways. There gateways are essentially router-based interfaces to either an internet service provider (ISP) via the internet or a private network (such as a local area network, LAN) supporting, for example, internet protocol (IP) traffic. As regards interfacing between external terrestrial networks and a satellite network running IP-based protocols (both over the ground and in satellite sagments thereof), such interfacing requires the exchange of interior and exterior routing information. Traditionally, large scale networks, like the Internet or other private carrier network, have to date used specifically developed routing protocols, such as the border gateway protocol (BGP4) discussed in the outline article “A Border Gateway Protocol (BGP)” by K Lougheed et al, June 1989 (available at http://sunsite.org.uk/rfc/rfc1105.txt). Indeed, BGP provides an interworking capability between the internet and a satellite gateway.
As will be appreciated, each gateway therefore provides an ingress/egress point for a satellite link, thus providing the interface to terrestrial networks, whereas each terminal connects user (e.g. computer) equipment to the satellite link in a dial-on-demand fashion (i.e. connectivity when requested). Gateways may be interconnected. As regards a typical geo-stationary satellite, terminally circular geographic coverage area (or ‘footprint’) in which designated service are provided.
Recent progress in swithching capabilities of satellite systems has enabled mappings between user beams (UBs) to gateways to follow a one-to-many basis (as well as the original one-to-one basis). In other words, connections to multiple gateways from the same user beam and multiple user beams from one gateway are now readily supportable, although there is usually some form of default set-up where a particular user beam is always associated with a particular gateway. The mapping of such user beam to gateway connection information (known as the “connectivity matrix”) is held by a network controller that operationally managers connections through the system. However, the satellite payload does not utilise any information concerning bandwidth availability or congested data routes and so it is not possible to determine the optimum (or “least cast” through the satellite network in terms of the route set-up overhead) data route. Furthermore, connectivity requirements within a satellite system are often in a state of flux (changing from hour to hour), as a consequence of changing service demands, fault conditions and system operator decisions.
Decision between separate ISPs (or network providers) to use policy-based routing to enforce routing decisions based on the use or avoidance of selected inter-autonomous system (ASs) as transit networks, is known as a “peering agreement”. Moreover, in order to achieve a situation where ingress bound IP packets can have an optimum route it is necessary to have peering agreements with internet service providers (ISPs). Such agreements are provided by BGP policy-based routing techniques (discussed in more detail below). The use of policy-based routing is understood to help avoid congestion within a satellite network as the policy-based routing distributes points of ingress of IP packets across a large number of gateways, rather than just restricting access to a single or small number of gateways.
In modern satellite networks, difficulties are often experienced as a result of ‘internet bottlenecks’ caused, for example, by: i) congested routers providing access between multiple inter-autonomous systems; ii) the set-up of links that attempt to avoid long haul terrestrial routes. Consequently, there is a need to identify and utilise data paths that bypass such difficulties, but which are preferably optimised in terms of shortest route length. The latter criterion is important when one considers that if an IP data packet has a longer route to traverse, then there is both an increased chance of the IP packet being lost and second, that an unacceptably long delay may be introduced into the path. Of course, in view of the distances travelled by signals in a satellite system, some delay is unavoidable (but excessive delays render services, such as voice calls unacceptably fractured and hence incoherent). It will be understood that, in this particular context, route length may be determined by the number of hops or routes that process the packet, as well as absolute traversed distance.
In a multimedia broadband satellite system, it is known to have an element of on-board processing within a satellite payload. Such satellite systems generally have dynamically changing connectivity. This information is vital in determining both how network topology is represented at any one moment in time and also the correct “link state” for the connection. However, upon transgressing a boundary between the satellite system and the terrestrial network, dynamically changing traffic loading within the satellite system is not effectively relayed into the terrestrial network using BGP, with the border gateway (routing) protocol only providing policy management routing without any indication of optimised route selection.
BGP is an inter-autonomous system routing protocol that requires considerable manual intervention in order that its policy-based routing decisions work correctly. Often, manual changes are required to rectify incorrect policy decisions. Thus, BGP is reliant upon manual updates to maintain its correct function and, clearly, it is not dynamically interactive to other network changes. Even thought some vendor platforms have sufficient intelligence to handle some forms of automatic distribution of configuration information, BGP is still an exception to the rule and is, in fact, reliant on manual configuration to notify and update the distribution of internal routes (within an IP-based network) in order to advise external systems elements. Manual configuration is inefficient in terms of both time and expense). In operation, BGP essentially only propagates a gateway address through the interconnected network that indicates one of a number of paths to a satellite user beam. BGP is, in fact, unable to differentiate between different routes/paths and so in unable to advise, select or otherwise route a packet of data (or the like) through a link having, say, the largest bandwidth, shortest distance, link quality, the level of congestion at a gateway, efficiency, etc. In other words, BGP advertises user beam availab
Cable Julian Frank
Rosenberg Catherine
Winckles Adrian M
Barnes & Thornburg LLP
Duong Frank
Jagannathan Melanie
Nortel Networks Limited
LandOfFree
Border gateway protocol manager and method of managing the... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Border gateway protocol manager and method of managing the..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Border gateway protocol manager and method of managing the... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3323612