Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing
Reexamination Certificate
1998-06-29
2002-07-09
Geckil, Mehmet B. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
C370S401000
Reexamination Certificate
active
06418476
ABSTRACT:
COPYRIGHT NOTICE
Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is related to data communications. In particular, the present invention is related to a method for synchronizing Network Address Translator (NAT) tables, or databases, using the Open Shortest Path First (OSPF) Opaque Link State Advertisement (LSA) option protocol.
2. Description of the Related Art
The Transport Control Protocol/Internet Protocol (TCP/IP) suite of protocols is used in many of today's internetworks (internets). A TCP/IP-based internet provides a data packet switching system for communication between nodes (e.g., end-user workstations, servers, network devices, etc.) connected to an internet. With reference to
FIG. 1
, in accordance with the well known International Standards Organization (ISO) Open Systems Interconnection (OSI)seven-layer conceptual model for data networking, Network layer devices known as routers or switches select a path and forward, i.e., route, IP datagrams between nodes, or hosts, connected to the internet. For example, internet
100
comprises multiple networks, including Local Area Networks (LANs)
110
,
120
and
170
, and Wide Area Network (WAN)
180
, interconnected by routers
130
,
140
,
150
and
160
. The routers route IP datagrams, for example, between nodes
111
,
112
,
121
,
122
, and
171
via the multiple networks in the internet.
In traditional destination address based routing, a source node, e.g., node
111
, transmitting an IP datagram to a destination node, e.g., node
121
, specifies as a destination IP address the IP address of the destination node in the IP datagram. The IP datagram is encapsulated in a physical frame, or packet, and sent to the router attached to the same network (LAN
110
) as the source node, e.g., router
130
or router
140
. The router receiving the frame, in turn, extracts the IP datagram, and determines the destination IP address. The router selects the next hop router enroute to the destination node, e.g., router
160
, and again encapsulates the datagram in a physical frame for transmission to the next hop router. This process continues until the IP datagram reaches the network to which the destination node is connected, i.e., LAN
120
, wherein the datagram is delivered to the destination node
121
.
Routing tables on each router store information about what networks are reachable, either directly or via adjacent routers. When a router receives an IP datagram, it compares the network portion of the IP destination address in the datagram, referred to herein as the address prefix, with the network reachability information stored in its routing table. If a match is found, the router sends the datagram over the appropriate, directly attached network to the next hop router through which the destination network is reachable, or directly to the node, if the destination network is directly attached to the router.
In the event of topological changes to network
100
, network reachability information may be maintained up to date, automatically, through the use of an interior gateway protocol (IGP), such as the well known Open Shortest Path First (OSPF) Version 2 TCP/IP internet routing protocol, the specification of which is set forth in the Internet Standard Request For Comments (RFC) 1583, March, 1994. In addition to exchanging network reachability information between routers, the OSPF protocol routes IP datagrams over one of possibly multiple routes based on the destination IP address and IP Type of Service specified in the IP header of the datagrams. Further details of the well known OSPF version 2 routing protocol may be found in RFC 1583.
Growth of the Internet, as well as private internets, has placed demands not only on bandwidth requirements, but also the internet routing protocols and the available IP address space. Traditional destination address based routing using OSPF version 2 generally allows traffic to be routed based only on destination IP address and IP type of service. New approaches to routing and IP address allocation have been sought to improve routing functionality, scalability and control as changes in internet traffic patterns and volume emerge.
A particular problem for the Internet, and for which a number of proposals providing short-term and long-term solutions have been developed, is running out of unique IP addresses. One short term proposal is set forth in the Informational Request For Comments (RFC) 1631, May, 1994, entitled “The IP Network Address Translator (NAT).” The proposal is based on reuse of existing IP addresses by placing NAT software, and NAT tables or databases, at each router between routing domains. The NAT table at each participating router comprises pairs of local, reusable IP addresses for use in data packets transmitted within local routing domains, and assigned, globally unique IP addresses for use in data packets transmitted outside local routing domains, that is, over the Internet.
Briefly, network address translation functions as follows. With reference to
FIG. 1
, domains A, B, C and D represent separate routing domains. Routing domains A and B are stub, or leaf, domains, that only handle traffic originating from or destined to hosts in the routing domain, whereas routing domains C and D route traffic originating from or destined to hosts in the same or other routing domains. Most of the traffic in leaf routing domains is local, that is, at any given time, generally a small percentage of traffic originating from or destined to hosts in a leaf routing domain is transmitted outside the routing domain. Therefore, the local IP addresses assigned to hosts in one leaf routing domain may be reused by hosts in another leaf routing domain, without IP address conflict. A local IP address assigned to a host in a leaf routing domain needs only be translated to a globally unique IP address when the host communicates with a host outside the leaf routing domain. Thus, only a subset of the local IP addresses used in a leaf routing domain are translated to the globally unique IP addresses required when transmitting outside the leaf domain, thereby averting IP address depletion in the Internet.
Routers that provide ingress to or egress from a leaf routing domain are known as border routers. Network Address Translator (NAT) software, including NAT tables, is installed at these routers to provide the network address translator functionality. For example, routers
130
,
140
and
150
are border routers for leaf routing domains that may utilize reusable local IP addresses.
According to the proposed NAT solution, host
111
can use a local IP address as the destination IP address when transmitting an IP datagram to host
112
. However, host
111
must use a globally unique IP address as the destination IP address when sending an IP datagram to a host outside leaf routing domain A, e.g., host
121
in leaf routing domain B, via either of routers
130
and
140
, say router
130
. Router
130
checks its routing table, locates the route for the destination network specified by the globally unique destination IP address, and forwards the IP datagram to the next hop router via WAN
180
, but not before replacing the local IP address of host
111
in the source IP address field of the datagram with a globally unique IP address. Ultimately, router
150
receives the IP datagram, and using its NAT software and associated data structures, translates the globally unique destination IP address with the local IP address assigned to host
121
in routing domain B before forwarding the datagram to host
121
.
On the return path, the same process occurs: Host
121
, for example, transmits to router
150
an IP datagram destined for host
111
in routing domain A, speci
Blakely , Sokoloff, Taylor & Zafman LLP
Geckil Mehmet B.
Nortel Networks Limited
LandOfFree
Method for synchronizing network address translator (NAT)... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for synchronizing network address translator (NAT)..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for synchronizing network address translator (NAT)... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2918133