Browse Prior Art Database

Methodology for Avoidance of Transmission of Routing Information on Transmission Control Protocol/Internet Protocol Network

IP.com Disclosure Number: IPCOM000118204D
Original Publication Date: 1996-Nov-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 113K

Publishing Venue

IBM

Related People

Tracey, K: AUTHOR [+3]

Abstract

Transmission Control Protocol/Internet Protocol (TCP/IP) networks require the ability to decide what the next hop should be for a packet bound for any given destination. This is currently achieved by maintaining a routing table on each machine. This table is a list of destinations and their associated routers. There must be some way of keeping these tables up to date on all the machines.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Methodology for Avoidance of Transmission of Routing Information
on Transmission Control Protocol/Internet Protocol Network

      Transmission Control Protocol/Internet Protocol (TCP/IP)
networks require the ability to decide what the next hop should be
for a packet bound for any given destination.  This is currently
achieved by maintaining a routing table on each machine.  This table
is a list of destinations and their associated routers.  There must
be some way of keeping these tables up to date on all the machines.

      If the network is large, with many routers attached to it, then
the routing tables also become quite large, and the mechanism for
keeping all the tables up to date can become resource-intensive,
either in terms  of computer cycles and network bandwidth, or in
terms of administrative  work, or both.

      The problem is not specific to running TCP/IP programs over an
Systems Network Architecture (SNA) network, nor is the solution
specific to an SNA network.  Since the problem and solution both
originated in the SNA environment, that is how it will be discussed
here, but the solution is general as will be pointed out again later
on.

      Many customers are now beginning to use multiple transport
protocols for computer communications.  Typically, we see large
customers with an installed SNA backbone which they would like to
maintain.  These customers are starting to use TCP/IP for
peer-to-peer communications and wish to route the TCP/IP traffic
across the SNA backbone.  IBM, as well as a number of competitors,
have products that perform this function.  One IBM product, the NWays
Multiprotocol Concentrator (MpC), aka 2217, uses the Sockets over SNA
MultiProtocol Transport Networking (MPTN) gateway function to perform
this routing.

      A problem with the configuration shown in the Figure is how the
MpC's exchange the routing information of the TCP/IP networks for
networks that contain hundreds of MpC's and where a node on any
TCP/IP network may request a connection to a node on _any_ other
TCP/IP network.  The routing information at each MpC needs to contain
enough routes so that the any-to-any connection can be established.
This requires that all MpC's be notified when a new TCP/IP route
becomes available, as well as when a new MpC establishes itself on
the SNA backbone.  An assumption is made that the TCP/IP protocols
operating within each separate TPC/IP network keep the MpC up to date
with respect to all TCP/IP routes within the isolated TCP/IP network.

      TCP/IP networks have a few solutions to this problem.  One is
to use broadcasting to send out the routing updates.  SNA does not
support broadcasting, and the obvious analog, to send individually to
each partner machine, can be very inefficient.  Even in a straight
TCP/IP network, if there are a large number of Local Area Networks
(LANs) attached to the Wide Area Network (WAN), the routing updates
can be resource i...