US7978612B2 - Two-hop relay for reducing distance vector routing information - Google Patents

Two-hop relay for reducing distance vector routing information Download PDF

Info

Publication number
US7978612B2
US7978612B2 US12/250,446 US25044608A US7978612B2 US 7978612 B2 US7978612 B2 US 7978612B2 US 25044608 A US25044608 A US 25044608A US 7978612 B2 US7978612 B2 US 7978612B2
Authority
US
United States
Prior art keywords
node
neighbor
message
relay
neighbors
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US12/250,446
Other versions
US20100091823A1 (en
Inventor
Alvaro Retana
Stanley Ratliff
Donnie Van Savage
Mihail L. Sichitiu
Russell White
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cisco Technology Inc filed Critical Cisco Technology Inc
Priority to US12/250,446 priority Critical patent/US7978612B2/en
Assigned to CISCO TECHNOLOGY, INC. reassignment CISCO TECHNOLOGY, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SAVAGE, DONNIE, RATLIFF, STANLEY, SICHITIU, MIHAIL, WHITE, RUSSELL, RETANA, ALVARO
Publication of US20100091823A1 publication Critical patent/US20100091823A1/en
Application granted granted Critical
Publication of US7978612B2 publication Critical patent/US7978612B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/64Distributing or queueing
    • H04Q3/66Traffic distributors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/033Topology update or discovery by updating distance vector protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • H04L45/123Evaluation of link metrics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13098Mobile subscriber
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13141Hunting for free outlet, circuit or channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196Connection circuit/link/trunk/junction, bridge, router, gateway
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13352Self-routing networks, real-time routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13353Routing table, map memory
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389LAN, internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/24Connectivity information management, e.g. connectivity discovery or connectivity update

Definitions

  • the present invention relates to distance vector routing in packet switching communication networks, such as in a wireless mobile ad hoc network (MANET).
  • MANET wireless mobile ad hoc network
  • Networks of general purpose computer systems and specialized devices connected by external communication links are well known and widely used in commerce.
  • the networks often include one or more network devices that facilitate the passage of information between the computer systems and devices.
  • a network node is a network device or computer or specialized device connected by the communication links.
  • An end node is a node that is configured to originate or terminate communications over the network.
  • An intermediate network node facilitates the passage of data between end nodes.
  • Communications between nodes are typically effected by exchanging discrete packets of data.
  • Information is exchanged within data packets according to one or more of many well known, new or still developing protocols.
  • a protocol consists of a set of rules defining how the nodes interact with each other based on information sent over the communication links.
  • Routers are intermediate network nodes that support the exchange of data packets across multiple heterogeneous subnetworks. Routing protocols are used by routers to pass information that affects the links chosen by each router to forward a data packet. Some routing protocols require routers to exchange information about all connections at each router. Distance vector routing protocols require a router to pass only summary information that indicates a destination in the network and a total cost (called a distance) of reaching that destination from the router.
  • communication bandwidth between routers can be scarce, while routing information is likely to change quickly, at least some of the time, as mobile nodes move into and out of direct communication with each other.
  • some communication is two way (each can send and receive to the other) and some is one way (e.g., the node with a weaker transmitter can only receive from the other node and not send to it). It is very uncommon to use a one-way link for routing.
  • routing protocols conserve bandwidth by passing routing information only when needed to forward a particular data stream of one or more packets of data. Such routing protocols may be perceived as slow to establish a connection. Proactive routing protocols use the time between data packets to pass routing information changes so that each router already has a path to each destination in the network. Such protocols may be perceived as faster to establish a connection, but may consume extra bandwidth for route maintenance, which slows the perceived duration of transmitting a data stream.
  • FIG. 1 illustrates an example network that incorporates a two-hop relay process for a distance vector routing protocol, according to an embodiment
  • FIG. 2 illustrates example data structures on a router, according to an embodiment
  • FIG. 3A illustrates an example distance vector routing protocol neighbor discovery message, according to an embodiment
  • FIG. 3B illustrates another example distance vector routing protocol neighbor discovery message, according to an embodiment
  • FIG. 3C illustrates an example distance vector routing protocol update message, according to an embodiment
  • FIG. 4A illustrates, at a high level, an example method for using relay neighbors in a two-hop relay process, according to an embodiment
  • FIG. 4B illustrates, at a high level, an example method for serving as a relay neighbor in a two-hop relay process, according to an embodiment
  • FIG. 5 illustrates a computer system upon which an embodiment of the invention may be implemented.
  • a method and apparatus are described for reducing routing information passed in a distance vector routing protocol by using a two-hop relay.
  • numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
  • EIGRP Enhanced Interior Gateway Routing Protocol
  • Cisco Systems, Inc. of San Jose, Calif.
  • embodiments of the invention are not limited to this context.
  • larger networks with wired or wireless communication links that are equally or less stable than those depicted herein, using the same or different distance vector routing protocols are involved in addition to or instead of the nodes, links and protocols described herein.
  • a method for using a two-hop relay includes receiving an update message for a distance vector routing protocol at a node in a communications network from a first neighbor node in direct communication with the node.
  • An update message is a message that indicates a destination in the communications network and a least total cost of reaching that destination from the neighbor that sent it.
  • the receiving node sends the update message to a different neighbor of the plurality of neighbors, even though the routing protocol is a distance vector routing protocol that normally does not forward update messages.
  • the node is a relay node for the first neighbor in the distance vector routing protocol. If so, then the update message is sent immediately to the different neighbor.
  • the relay node is a node preferred by the first neighbor to update a particular one or more nodes two hops from the first neighbor.
  • a method for serving as a two hop relay includes receiving, at a first node in a communications network, a first message for a distance vector routing protocol from each neighbor.
  • the first message from each neighbor includes neighbor data that indicates a set of one or more nodes that are in direct communication with the neighbor.
  • a relay set of fewer than all neighbors is determined based on the neighbor data received from every neighbor.
  • Each neighbor in the relay set is a neighbor preferred to update a particular one or more nodes two hops from the first node, and every node two hops from the first node is updated using only the relay set of neighbors.
  • a second message for the distance vector routing protocol is sent to all the neighbors. The second message includes relay data that indicates the relay set.
  • an apparatus, or logic encoded in one or more tangible media, or instructions encoded on one or more computer-readable media are configured to perform one or more steps of the above method.
  • the article “a” and “the” mean “one or more,” unless otherwise indicated; and “comprising” and “including” before one or more listed items means “including but not limited to” the one or more listed items.
  • FIG. 1 illustrates an example network 100 that incorporates a two-hop relay process for a distance vector routing protocol, according to an embodiment.
  • the network includes intermediate network nodes 120 , including node 120 a, node 120 b, node 120 c, node 120 d, node 120 e, node 120 f and node 120 g connected by communication links 130 .
  • each of links 130 represents two-way wireless communications using a single carrier frequency.
  • one or more links 130 are wireless links using one or more different carrier frequencies or are wired or optical cable links.
  • each node 120 learns of its neighbors by receiving routing protocol neighbor discovery messages, such as an EIGRP HELLO message, that indicates a node identifier for the node that sent the message.
  • a neighbor of a node is a node with which that node has a direct two-way communication.
  • the direct communication links 130 are two-way links.
  • each node 120 determines a cost associated with the link between the node and its neighbor. Any method known in the art may be used to determine a cost metric value for a link.
  • Each node then sends out a distance vector routing protocol update message that indicates a list of network addresses that can be reached from the node and the cost of reaching that address from the node sending the update message.
  • each node 120 only knows the addresses and costs of any local area networks (LANs, not shown) connected directly to the node and its own address (with a cost of zero).
  • Each node that receives an update message uses the information to update its routing information and sends an acknowledgement message.
  • the receiving node determines whether the new information changes the information it has previously sent out about the network addresses it can reach and the costs. If so, the receiving node adds the cost of the link between itself and the sending node to the cost of the addresses and sends a new update message with the changed information to its neighbors. The receiving node never forwards the update message from the sending node unchanged.
  • the revised update message is not sent back to the sending node, in an application of a so-called split horizon rule, to prevent extraneous looping of routing protocol packets back and forth between the two nodes.
  • the update may be unicast or multicast only to the other neighbors; rather than broadcast to all neighbors.
  • the address of a particular intended recipient is included in an internetwork layer protocol.
  • the group name for a set of nodes is included in the internetwork layer protocol.
  • the protocol update messages can be rather lengthy compared to the protocol neighbor discovery messages.
  • Some nodes are configured with filters to avoid forwarding data packets for some addresses, called filtered nodes.
  • Filter data indicates a filtered node in the communications network for which data packets are not forwarded by the node. In such nodes, a change to the reachability or cost of a filtered node address is not included in an update message sent by the node. For example, if abusive behavior is noted from a particular LAN (not shown) attached to node 120 g by a network administrator for a LAN connected to node 120 b, node 120 b may be configured with a filter to remove routing information for the abusive LAN.
  • node 120 b will not send an update message with the new cost in response to this update received from node 120 a.
  • the updates sent by node 120 b, node 120 c and node 120 d all indicate that node 120 g and its LANs are now reachable (unreachable) on the communications links 130 with node 120 b, node 120 c and node 120 d.
  • This information is redundant. Therefore the bandwidth consumed to transmit all three updates is largely wasted.
  • the only difference among the three updates might be any difference in costs of reaching node 120 g and its LANs among node 120 b, node 120 c and node 120 d.
  • node 120 g has left the network 100 , there is not even a cost difference among the updates from the three nodes: node 120 b, node 120 c and node 120 d ; and the bandwidth consume by two of the three messages is entirely wasted.
  • Applicants have developed techniques to provide node 120 e with the routing information it needs, without sending three updates, one each from node 120 b, node 120 c and node 120 d. This can have significant impact on the availability of scarce bandwidth, because the update messages are rather lengthy compared to the other routing protocol messages, like a neighbor discovery message.
  • the techniques of the illustrated embodiments save scarce bandwidth in any network that includes one or more nodes that are two hops or more away from a node that experiences a change in routing information (such as reachability data).
  • At least some nodes 120 include at least a portion of a two-hop relay process 150 .
  • node 120 a, node 120 b, node 120 c and node 120 d include two-hop relay process 150 , or a portion thereof.
  • every intermediate node in a network 100 , or a wireless portion thereof includes the two-hop relay process 150 .
  • a network includes more nodes, such as routers, more links, with the same or different costs and more or fewer end nodes and LANs.
  • FIG. 2 illustrates example data structures on a node 200 , such as a router, according to an embodiment.
  • Node 200 includes a routing process 210 , a routing table 220 , and routing protocol information in the form of protocol neighbor data 230 .
  • routing process 210 executes on a processor, such as a general purpose processor executing sequences of instructions that cause the processor to perform the routing process.
  • routing process 210 includes one or more methods 212 of the two-hop relay process 150 . These methods are described in more detail below with respect to FIG. 4A and FIG. 4B .
  • the routing process 210 stores and retrieves information in the routing table 220 based on information received in one or more distance vector routing protocol messages that are stored in a neighbor data structure 230 of a routing protocol information data structure.
  • the routing table 220 is a data structure that indicates for each destination that can be reached from the router 200 , an address, a link and zero or more attributes, as is well known in the art.
  • the routing protocol neighbor data structure 230 is a data structure that includes, for each neighbor, a list of reachable destinations and costs, as is well known in the art. According to the illustrated embodiments, the neighbor data also includes a neighbors' neighbors field 232 , a two-hop data field 240 , a relay data field 244 , and self relay field 260 .
  • the neighbor's neighbors field 232 holds data that indicates all the neighbors of a neighbor of node 200 , as listed in neighbor discovery messages, described below.
  • the neighbors' neighbors field 232 includes multiple entries for the same node, including multiple entries for the node 200 itself.
  • the neighbors of node 120 a are, in alphabetical order, node 120 b, node 120 c, 130 d and node 120 g.
  • field 232 includes the list of node 120 a, node 120 e, node 120 f, node 120 a, node 120 e, node 120 a, node 120 e, node 120 a.
  • the two-hop data field 240 is a pared down list of all the nodes that are two-hops from the node 200 , based on data in the neighbors' neighbors field 232 , but with redundant entries and all entries for the node 200 , itself, removed.
  • the two hop data field 240 includes the list of node 120 e and node 120 f, which are the only nodes in network 100 that are two hops from node 120 a, and a complete list.
  • the relay data field 244 holds data that indicates a subset of the neighbors of node 200 that are sufficient to forward updates to all nodes that are two hops away from node 200 and favored over other subsets that also reach all nodes two hops away from node 200 .
  • This subset is called the relay set of neighbors. Sometimes the subset includes all the neighbors of node 200 ; but advantages accrue, such as bandwidth savings, if fewer than all neighbors suffice to reach all two hop nodes.
  • Each relay node in the relay set is a node preferred by the node 200 to update a particular node two hops from the node 200 . The determination of the relay set is described in more detail in a later section.
  • the relay node is node 120 b. Node 120 b is able to forward all update messages from node 120 a to every node two hops away from node 120 a, e.g., node 120 e and node 120 f.
  • the self relay field 260 holds data that indicates any neighbors for which node 200 serves as the relay node to forward updates.
  • node 120 a is the relay node for node 120 b, node 120 c and node 120 d to forward updates to node 120 g, and is the relay node for node 120 g to forward updates to node 120 b, node 120 c and node 120 f, so all four neighbors of node 120 a are indicated in the self relay field 260 .
  • Data structures may be formed in any method known in the art, including using portions of volatile memory, or non-volatile storage on one or more nodes, in one or more files or in one or more databases accessed through a database server, or some combination.
  • data structures 220 , 230 are shown as integral blocks with contiguous fields, e.g. fields 232 , 240 , 244 , 260 in a particular order for purposes of illustration, in other embodiments one or more portions of fields and data structures 220 , 230 are stored in the same or different order as separate data structures on the same or different multiple nodes that perform the functions of node 200 .
  • relay data field 244 and self relay field 260 are simply one-bit flags added to a record for each neighbor in the distance vector routing protocol neighbor data structure 230 .
  • One value of the bit in the relay data flag indicates the neighbor is a relay node for the node 200 ; and the other value indicates it is not.
  • one value of the bit in the self relay flag indicates the node 200 is a relay node for that neighbor; and the other value indicates it is not.
  • the neighbors' neighbors field 232 is a set of linked lists, each list starting in a record for one neighbor of node 200 , to list the neighbors of that one neighbor.
  • FIG. 3A illustrates an example distance vector routing protocol neighbor discovery message, 310 according to an embodiment.
  • a neighbor discovery message is a message type used by a distance vector routing protocol to discover the nodes that have a direct communication, such as direct two-way radio communications, with a particular node. For example, in EIGRP, the neighbor discovery message is called a HELLO message.
  • the neighbor discovery message 310 usually includes a sending router identification (ID) field 312 and an attributes field 314 , both well known in the art.
  • the sending router ID field holds data, such as a router's loopback Internet Protocol (IP) address that uniquely indicates the node that sent the message, or a network interface card IP address that uniquely indicates a particular interface on the sending node through which the message was sent.
  • IP Internet Protocol
  • the attributes field 314 holds data that indicates other properties of the sending node that are used by the distance vector routing protocol.
  • the distance vector routing protocol is extended to allow the attributes field 314 of a neighbor discovery message 310 to include a neighbor data field 316 and a relay willingness field 318 .
  • the neighbor data field 316 indicates the router IDs for all the nodes that are neighbors of the sending node. This information is used to fill a portion of the neighbors' neighbors field 232 at the receiving node. Such information is not passed among nodes in any current distance vector routing protocol known to the inventors.
  • the neighbor data field 316 includes cost field 317 that indicates the cost of reaching each of the neighbors of the sending node from the sending node. In some embodiments, the cost field 317 is omitted. This cost data is considered in some embodiments to decide which neighbors of the receiving node are better situated to serve as a two-hop relay node, as explained in greater detail below. In some embodiments, this cost data is used to replace information that would be sent in an update message, that can be eliminated using the two-hop relay process 150 .
  • the relay willingness field 318 holds data that indicates the sending node's assessment of its willingness to serve as a two-hop relay node for update messages. Willingness data, such as in field 318 , indicates a relative capacity of the node to serve as a relay node. Any method of determining and indicating willingness may be used. In some embodiments, the relay willingness field holds a single octet (eight bits) that varies in value from 0 to 255. By default, a node's willingness is assumed to be a middle value 128 . A node that is more capable and willing, such as a node with better than average processing capacity or more powerful transmitters, with better than average two-way communications, or less than average load, might specify a larger value. A node of limited communications, transmitter power or processing capacity or heavily loaded might specify a lower value. In some embodiments the relay willingness field 318 is omitted and all nodes are assumed to have the same, default willingness.
  • the neighbor data field 316 or the relay willingness field 318 , or both are included in other types of messages for the distance vector protocol, such as an update message that is not forwarded.
  • FIG. 3B illustrates another example distance vector routing protocol neighbor discovery message 320 , according to an embodiment.
  • the neighbor discovery message usually includes a sending router identification (ID) field 312 and an attributes field 324 , both well known in the art.
  • ID sending router identification
  • attributes field 324 both well known in the art.
  • the distance vector routing protocol is extended to allow the attributes field 324 of a neighbor discovery message 320 to include a relay information field 326 .
  • the relay information field 326 holds data that indicates a relay set of one or more neighbors of the sending node (indicated in sending node ID field 312 ) that are to serve as two-hop relay nodes for forwarding update messages from the sending node.
  • a neighbor discovery message from node 120 a after node 120 a determines that node 120 b is the appropriate two-hop relay, includes in field 326 data that indicates a relay set that consists of node 120 b alone.
  • the relay information field 326 is included in other types of messages for the distance vector protocol, such as an update message that is not forwarded, or the neighbor discovery message 310 that includes neighbor data field 316 .
  • FIG. 3C illustrates an example distance vector routing protocol update message 330 , according to an embodiment.
  • a distance vector routing protocol update message indicates a destination in the communications network and a least total cost of reaching that destination from the node sending the message.
  • the distance vector routing protocol message usually includes an advertised address with cost field 332 and attributes field 334 .
  • the advertised address with cost field 332 holds data that indicates a set of addresses reachable from the sending node and the associated costs of reaching those addresses through the sending node.
  • the attributes field 334 holds data that indicates other properties of the sending node that are used by the distance vector routing protocol.
  • the distance vector routing protocol is extended to allow the attributes field 334 of an update message 330 to include an originating router field 336 and a sequence number (#) field 338 .
  • the originating router field 336 holds data that indicates a node that originated the update message 330 , such as a loopback IP address for the node.
  • the sequence # field 338 holds data that distinguishes among multiple update messages sent by the same sending node for acknowledgement purposes.
  • Update messages in existing distance vector routing protocols are not forwarded, and do not require both an origination router field 336 and a sequence # field 338 . Because the distance vector routing protocol is being extend to support two-hop relay processes, it is desirable for an update message to indicate the originating router to distinguish forwarded messages from a relay node and the update messages that originate at the relay node, as described in more detail below.
  • fields in distance vector routing protocol messages 310 , 320 and 330 are shown as contiguous blocks of data in a particular order in a single data packet for purposes of illustration, in other embodiments, one or more fields or portions thereof are arranged in a different order in one or more separate data packets.
  • FIG. 4A illustrates, at a high level, an example method 400 for using relay neighbors in a two-hop relay process, according to an embodiment.
  • steps in FIG. 4A and subsequent flow chart, FIG. 4B are show in a particular order for purposes of illustration, in various other embodiments, one or more steps are performed in a different order or overlapping in time, in series or in parallel, or one or more steps are omitted or added, or changed in some combination of ways.
  • step 410 distance vector neighbor discovery messages are received from all neighbors.
  • the neighbor discovery messages include data that indicates the sending node's neighbors, at least, e.g., in neighbor field 314 .
  • the discovery messages of the type indicated by message 310 are received with cost field 317 and relay willingness field 318 both included.
  • node 120 a receives messages 310 from all its neighbors: node 120 b, node 120 c, node 120 d and node 120 g.
  • the data received during step 410 indicates the values listed in Table 1.
  • other messages with this information such as special update type messages, are received.
  • the information listed in Table 1 is stored in neighbors' neighbors field 232 at node 120 a.
  • two-hop nodes are determined based on the received messages with neighbor data, such as the discovery messages 310 .
  • neighbor data such as the discovery messages 310 .
  • node 120 a determines based on the data in Table 1 that its two-hop nodes are node 120 e and node 120 f, underlined upon their first appearance in Table 1.
  • the two-hop data is stored in two-hop data field 240 .
  • a relay set of possibly fewer than all neighbors is determined.
  • the relay set is able to forward updates to all two-hop nodes from the node receiving the messages with neighbors data.
  • the relay set is determined based on the messages received from the neighbors.
  • the relay data set is stored locally in relay data field 244 .
  • step 422 it is determined in step 422 that neighbor 120 b should be in the relay set alone.
  • Node 120 b is able to forward to both two-hop nodes 120 e and 120 f, and no other node is needed to reach all of nodes that are two hops from node 120 a.
  • the determination made during step 422 includes consideration of the cost or the willingness or both. For example, if node 120 f leaves the network 100 , then there is only one two-hop node from node 120 a, i.e., node 120 e. Three neighbors (node 120 b, node 120 c, node 120 d ) are able to send updates to node 120 e.
  • the one chosen as the relay node is determined in step 422 based on the cost or willingness or both. For example, in some embodiments, cost is given more weight, and among neighbors with equal cost, willingness is used, and router ID number is then used to break remaining ties.
  • both node 120 b and node 120 c have lower cost (62) than node 120 d (83), so one of those two is chosen.
  • Node 120 c has higher willingness, so node 120 c is chosen as the only neighbor in the relay set. If cost is only used to break ties in willingness, then node 120 d, with the highest willingness is chosen as the only neighbor in the relay set.
  • both cost and willingness are used together.
  • the neighbor is chosen with a highest score given by subtracting a weighted cost from willingness.
  • the scores of the three neighbors, node 120 b, node 120 c and node 120 d are 66, 78 and 77, respectively.
  • Node 120 c with the highest score, 78 is chosen to be the only node in the relay set.
  • the relay set for the node is sent to all the neighbors.
  • a neighbor discovery message 320 is sent to all neighbors with the relay set indicated by data in the relay information field 326 .
  • the relay information field 326 holds data that indicates the relay set made up of node 120 b alone. If a relay set has already been sent to all neighbors and neither the neighbors nor the relay set has changed, then step 434 is omitted.
  • step 430 it is determined whether there is a change in nodes reached from the current node, as is usual for a distance vector routing protocol. If not, control passes to step 438 . In step 438 , it is determined whether there is a new neighbor discovery message received. If so, control passes back to step 410 and subsequent steps to adapt to any changes in neighbors based on the new neighbor discovery messages. If not, control passes through other steps, not shown, back to step 430 .
  • step 431 it is determined whether the change is based on an update from a neighbor for which the current node is not a relay. If so, then an update is not produced by the current node and control shifts to step 434 described below. Otherwise, control passes to step 432 in which the current node sends an update message based on the local changes. For example, since node 120 a is a relay node for all its neighbors, node 120 a always sends an update.
  • node 120 c is not a relay node for node 120 a
  • an update received at node 120 c from node 120 a is used to update the routing tables at node 120 c, but the change is not included in an update sent from node 120 c, e.g., to node 120 e.
  • an update message is sent to one or more neighbors.
  • the update message includes an identifier for the sending node (e.g., in field 346 of message 330 ) and a sequence #, such as a time stamp, that is unique among all update messages sent by the sending node (e.g., in field 348 ).
  • the update message due to changes at the local node is sent to all neighbors.
  • each neighbor that receives the update message sent in step 432 sends an acknowledgement message and uses the data to update their own routing tables.
  • the relay nodes for the sending node forward the change in information, as an unchanged update message for changes that originated in their neighbor or as a modified update for changes that originated elsewhere.
  • the nodes that are not relay nodes for the sending node do not send any updates, because such updates are rendered redundant by the information already sent in discovery messages and forwarded by the relay node(s), or information in updates sent by relay nodes.
  • node 120 b forwards the update message, unchanged, from node 120 a.
  • Node 120 b incorporates updates received through node 120 a from farther nodes, e.g., node 120 g, and sends a modified update message.
  • Nodes 120 c incoprorte changes received through node 120 a, but do not send updates, since they are not relay nodes for node 120 a.
  • the update message forwarded or generated by node 120 b is received by node 120 e and node 120 f, which use the information to update their routing tables.
  • the node e.g., node 120 a
  • step 434 the update message generated locally is retransmitted from node 120 a if an acknowledgement is not received from all its neighbors within a predetermined retransmission time. Also, the update message received from the neighbor for which the current node is not a relay node (e.g., received at node 120 c from node 120 a ) is transmitted from the node if an acknowledgement is not received from all its neighbors within a predetermined retransmission time. Control then passes back to step 438 and following steps to respond to new discovery messages and update messages.
  • FIG. 4B illustrates, at a high level, an example method 440 for serving as a relay neighbor in a two-hop relay process, according to an embodiment.
  • the neighbors and link costs to those neighbors are determined, e.g., based on neighbor discovery messages and acknowledgements, as is currently done in distance vector routing protocols. For example, node 120 b determines the neighbors and link costs listed in two columns of the first line of Table 1, above.
  • a discovery message is sent to all neighbors optionally indicating willingness to serve as relay and listing all neighbors and, optionally, costs.
  • the discovery messages of the type indicated by message 310 are sent with cost field 317 and relay willingness field 318 both included.
  • node 120 b sends message 310 to all its neighbors, including node 120 a, as listed in the first line of Table 1.
  • other messages with this information such as special update type messages, are sent.
  • a message is received from each neighbor indicating that neighbor's relay set.
  • a neighbor discovery message 320 is received from all three neighbors of node 120 b with the relay set indicated by data in the relay information field 326 .
  • a discovery message 320 is received from node 120 a in which the relay information field 326 holds data that indicates the relay set made up of node 120 b alone.
  • a discovery message 320 is received from node 120 f in which the relay information field 326 holds data that indicates the relay set made up of node 120 b alone.
  • node 120 e selects node 120 c as its relay node to update its two-hop node, node 120 a.
  • a discovery message 320 is received from node 120 e in which the relay information field 326 holds data that indicates the relay set made up of node 120 c alone.
  • the node receiving the relay sets determines neighbors, if any, for which the receiving node is a relay node.
  • the neighbors for which the receiving node serves as a relay node are stored in self relay field 260 .
  • the self relay field 260 holds data that indicates node 120 b is a relay node for two neighbors, node 120 a and node 120 f.
  • step 460 it is determined whether the node receives an update message from a neighbor, as is currently done in most distance vector routing protocols. If not, control passes back to step 450 and subsequent steps to receive any updates in neighbors and relay sets. If it is determined in step 460 that the node receives an update message from a neighbor, then control passes to step 462 . It is assumed for purposes of illustration that node 120 b receives an update message sent by node 120 a that indicates the IP addresses of the LAN just connected to node 120 a.
  • the update message includes an identifier for the sending node (e.g., in field 346 of message 330 ) and a sequence #, such as a time stamp, that is unique among all update messages sent by the sending node (e.g., in field 348 ).
  • step 462 the receiving node acknowledges the update message, e.g., by sending a short message that indicates the node identifier for the sending node.
  • the receiving node also uses the data to update its routing table, and stores the update message for retransmission if not acknowledged. Control then passes to step 470 .
  • step 470 it is determined whether the node that receives the update message is a relay node for the sending node. For example, in some embodiments, the node checks the contents of self relay field 260 to determine whether data indicating the sending node is included therein. If so, then control passes to step 470 . If not, then control passes to step 490 .
  • node 120 b that received the update message from 120 a determines that the sending node, node 120 a, is included in the self relay field 260 . Therefore node 120 b recognizes that it is a relay node for the update message from node 120 a and control passes to step 472 .
  • step 472 the update message is immediately forwarded to all neighbors of the relay node, regardless of split horizon or filtering rules.
  • the update message from node 120 a is sent unchanged to node 120 e and node 120 f, the neighbors of relay node 120 b for the sending node 120 a. This is done even if the update is for IP addresses that are listed in a filter for node 120 b.
  • node 120 e When node 120 e receives this update, it learns that node 120 a can reach the new LAN addresses. Node 120 b can determine whether the best route to node 120 a and the LAN addresses is through the relay node 120 b or another node, e.g., node 120 c or node 120 d. Node 120 e can make this determination because node 120 e already received costs to reach node 120 a through node 120 b and node 120 c and node 120 d in the discovery messages sent by each node when step 452 was executed at that node. For example, node 120 e received the discovery messages listed in the first three lines of Table 1.
  • node 120 e updates its routing table it knows that the new addresses reached at node 120 a, which sent the forwarded message, has the same cost (62) through node 120 b and node 120 c Node 120 e will chose one of these two nodes to forward data packets directed to the new LAN addresses.
  • step 470 it is determined in step 470 that the node receiving the update message is not the relay node for the sending node. Control passes to step 490 instead of step 472 .
  • the update message is not forwarded and updates to costs at nodes 120 c and 120 d are not used to generate new update messages from those nodes.
  • step 480 it is determined whether the update message indicates a filtered node is updated. For example, it is determined whether the new LAN addresses are listed as filtered addresses at node 120 b.
  • a node is configured with filter data indicting node addresses for which the node will not forward data packets. Any method may be used to receive this configuration data.
  • the data is included as a default value in software instructions, is received as manual input from a network administrator on the local or a remote node, is retrieved from a local file or database, or is sent from a different node on the network, either in response to a query or unsolicited, or the data is received using some combination of these methods.
  • control passes to step 490 . However, if it is determined that one or more route destinations updated in the update message are filtered node addresses, then control passes to step 482 .
  • a poison update message is sent to all neighbors for the filtered node addresses.
  • a poison update message indicates a prohibitive cost to reach the filtered node through the node that sends the update message.
  • node 120 b sends a poison update message that indicates a cost to reach a filtered node address is a value that indicates “infinite” cost. Control then passes to step 490 .
  • step 490 any node that received an update message, whether a relay node or not, retransmits the update message if an acknowledgement for the update message is not received within a retransmission time. Because the update did not originate with the node that does the retransmission, the acknowledgement is recognized using the originating node identifier and sequence #. Control then passes back to step 450 to detect changes in neighbors or new update messages.
  • Neither relay nodes nor other neighbors of node 120 a construct a new update message based on changes to their routing table. Such updates are redundant with the information already passed in the forwarded update and the discovery messages reporting neighbors and costs. Thus the bandwidth to send updates from node 120 c and node 120 d is conserved for other uses. The bandwidth consumed for passing distance vector routing protocol information is reduced.
  • Method 400 or method 440 or both constitute the two-hop relay process 150 depicted in FIG. 1 that is included on one or more nodes of a network.
  • FIG. 5 illustrates a computer system 500 upon which an embodiment of the invention may be implemented.
  • the preferred embodiment is implemented using one or more computer programs running on a network element such as a router device.
  • the computer system 500 is a router.
  • Computer system 500 includes a communication mechanism such as a bus 510 for passing information between other internal and external components of the computer system 500 .
  • Information is represented as physical signals of a measurable phenomenon, typically electric voltages, but including, in other embodiments, such phenomena as magnetic, electromagnetic, pressure, chemical, molecular atomic and quantum interactions. For example, north and south magnetic fields, or a zero and non-zero electric voltage, represent two states (0, 1) of a binary digit (bit). A sequence of binary digits constitutes digital data that is used to represent a number or code for a character.
  • a bus 510 includes many parallel conductors of information so that information is transferred quickly among devices coupled to the bus 510 .
  • One or more processors 502 for processing information are coupled with the bus 510 .
  • a processor 502 performs a set of operations on information.
  • the set of operations include bringing information in from the bus 510 and placing information on the bus 510 .
  • the set of operations also typically include comparing two or more units of information, shifting positions of units of information, and combining two or more units of information, such as by addition or multiplication.
  • a sequence of operations to be executed by the processor 502 constitute computer instructions.
  • Computer system 500 also includes a memory 504 coupled to bus 510 .
  • the memory 504 such as a random access memory (RAM) or other dynamic storage device, stores information including computer instructions. Dynamic memory allows information stored therein to be changed by the computer system 500 . RAM allows a unit of information stored at a location called a memory address to be stored and retrieved independently of information at neighboring addresses.
  • the memory 504 is also used by the processor 502 to store temporary values during execution of computer instructions.
  • the computer system 500 also includes a read only memory (ROM) 506 or other static storage device coupled to the bus 510 for storing static information, including instructions, that is not changed by the computer system 500 .
  • ROM read only memory
  • Also coupled to bus 510 is a non-volatile (persistent) storage device 508 , such as a magnetic disk or optical disk, for storing information, including instructions, that persists even when the computer system 500 is turned off or otherwise loses power.
  • Non-volatile media include, for example, optical or magnetic disks, such as storage device 508 .
  • Volatile media include, for example, dynamic memory 504 .
  • Transmission media include, for example, coaxial cables, copper wire, fiber optic cables, and carrier waves that travel through space without wires or cables, such as acoustic waves and electromagnetic waves, including radio, optical and infrared waves. Signals include man-made variations in amplitude, frequency, phase, polarization or other physical properties of carrier waves.
  • Computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, a magnetic tape or any other magnetic medium, a compact disk ROM (CD-ROM), a digital video disk (DVD) or any other optical medium, punch cards, paper tape, or any other physical medium with patterns of holes, a RAM, a programmable ROM (PROM), an erasable PROM (EPROM), a FLASH-EPROM, or any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.
  • a floppy disk a flexible disk, a hard disk, a magnetic tape or any other magnetic medium
  • CD-ROM compact disk ROM
  • DVD digital video disk
  • punch cards paper tape
  • EPROM erasable PROM
  • FLASH-EPROM FLASH-EPROM
  • Information is provided to the bus 510 for use by the processor from an external terminal 512 , such as a terminal with a keyboard containing alphanumeric keys operated by a human user, or a sensor.
  • an external terminal 512 such as a terminal with a keyboard containing alphanumeric keys operated by a human user, or a sensor.
  • a sensor detects conditions in its vicinity and transforms those detections into signals compatible with the signals used to represent information in computer system 500 .
  • terminal 512 coupled to bus 510 , used primarily for interacting with humans, include a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD) or a plasma screen, for presenting images, and a pointing device, such as a mouse or a trackball or cursor direction keys, for controlling a position of a small cursor image presented on the display and issuing commands associated with graphical elements presented on the display of terminal 512 .
  • a display device such as a cathode ray tube (CRT) or a liquid crystal display (LCD) or a plasma screen
  • a pointing device such as a mouse or a trackball or cursor direction keys
  • terminal 512 is omitted.
  • Computer system 500 also includes one or more instances of a communications interface 570 coupled to bus 510 .
  • Communication interface 570 provides a two-way communication coupling via transmission media to a variety of external devices that operate with their own processors, such as printers, scanners, external disks, and terminal 512 .
  • Firmware or software running in the computer system 500 provides a terminal interface or character-based command interface so that external commands can be given to the computer system.
  • communication interface 570 may be a parallel port or a serial port such as an RS-232 or RS-422 interface, or a universal serial bus (USB) port on a personal computer.
  • USB universal serial bus
  • communications interface 570 is an integrated services digital network (ISDN) card or a digital subscriber line (DSL) card or a telephone modem that provides an information communication connection to a corresponding type of telephone line.
  • ISDN integrated services digital network
  • DSL digital subscriber line
  • a communication interface 570 is a cable modem that converts signals on bus 510 into signals for a communication connection over a coaxial cable or into optical signals for a communication connection over a fiber optic cable.
  • communications interface 570 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN, such as Ethernet.
  • LAN local area network
  • Wireless links may also be implemented using carrier waves. For wireless links, the communications interface 570 sends and receives electrical, acoustic or electromagnetic signals, including infrared and optical signals, which carry information streams, such as digital data.
  • special purpose hardware such as an application specific integrated circuit (IC) 520
  • IC application specific integrated circuit
  • the special purpose hardware is configured to perform operations not performed by processor 502 quickly enough for special purposes.
  • application specific ICs include graphics accelerator cards for generating images for display, cryptographic boards for encrypting and decrypting messages sent over a network, speech recognition, and interfaces to special external devices, such as robotic arms and medical scanning equipment that repeatedly perform some complex sequence of operations that are more efficiently implemented in hardware.
  • Logic encoded in one or more tangible media includes one or both of computer instructions and special purpose hardware.
  • the computer system 500 includes switching system 530 as special purpose hardware for switching information for flow over a network.
  • Switching system 530 typically includes multiple communications interfaces, such as communications interface 570 , for coupling to multiple other devices.
  • each coupling is with a network link 532 that is connected to another device in or attached to a network, such as local network 580 in the illustrated embodiment, to which a variety of external devices with their own processors are connected.
  • an input interface or an output interface or both are linked to each of one or more external network elements.
  • three network links 532 a, 532 b, 532 c are included in network links 532 in the illustrated embodiment, in other embodiments, more or fewer links are connected to switching system 530 .
  • Network links 532 typically provides information communication via transmission media through one or more networks to other devices that use or process the information.
  • network link 532 b may provide a connection through local network 580 to a host computer 582 or to equipment 584 operated by an Internet Service Provider (ISP).
  • ISP equipment 584 in turn provides data communication services through the public, world-wide packet-switching communication network of networks now commonly referred to as the Internet 590 .
  • a computer called a server 592 connected to the Internet provides a service in response to information received over the Internet.
  • server 592 provides routing information for use with switching system 530 .
  • the switching system 530 includes logic and circuitry configured to perform switching functions associated with passing information among elements of network 580 , including passing information received along one network link, e.g. 532 a, as output on the same or different network link, e.g., 532 c.
  • the switching system 530 switches information traffic arriving on an input interface to an output interface according to pre-determined protocols and conventions that are well known.
  • switching system 530 includes its own processor and memory to perform some of the switching functions in software.
  • switching system 530 relies on processor 502 , memory 504 , ROM 506 , storage 508 , or some combination, to perform one or more switching functions in software.
  • switching system 530 in cooperation with processor 504 implementing a particular protocol, can determine a destination of a packet of data arriving on input interface on link 532 a and send it to the correct destination using output interface on link 532 c.
  • the destinations may include host 582 , server 592 , other terminal devices connected to local network 580 or Internet 590 , or other routing and switching devices in local network 580 or Internet 590 .
  • the invention is related to the use of computer system 500 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 500 in response to processor 502 executing one or more sequences of one or more instructions contained in memory 504 . Such instructions, also called software and program code, may be read into memory 504 from another computer-readable medium such as storage device 508 . Execution of the sequences of instructions contained in memory 504 causes processor 502 to perform the method steps described herein.
  • hardware such as application specific integrated circuit 520 and circuits in switching system 530 , may be used in place of or in combination with software to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware and software, unless otherwise explicitly stated.
  • the signals transmitted over network link 532 and other networks via transmission media through communications interfaces such as interface 570 carry information to and from computer system 500 .
  • Computer system 500 can send and receive information, including program code, through the networks 580 , 590 among others, through network links 532 and communications interfaces such as interface 570 .
  • a server 592 transmits program code for a particular application, requested by a message sent from computer 500 , through Internet 590 , ISP equipment 584 , local network 580 and network link 532 b through communications interface in switching system 530 .
  • the received code may be executed by processor 502 or switching system 530 as it is received, or may be stored in storage device 508 or other non-volatile storage for later execution, or both. In this manner, computer system 500 may obtain application program code in the form of signals on a carrier wave.
  • instructions and data may initially be carried on a magnetic disk of a remote computer such as host 582 .
  • the remote computer loads the instructions and data into its dynamic memory and sends the instructions and data over a telephone line using a modem.
  • a modem local to the computer system 500 receives the instructions and data on a telephone line and uses an infra-red transmitter to convert the instructions and data to a signal on an infra-red carrier wave serving as the network link 532 b.
  • An infrared detector serving as communications interface in switching system 530 receives the instructions and data carried in the infrared signal and places information representing the instructions and data onto bus 510 .
  • Bus 510 carries the information to memory 504 from which processor 502 retrieves and executes the instructions using some of the data sent with the instructions.
  • the instructions and data received in memory 504 may optionally be stored on storage device 508 , either before or after execution by the processor 502 or switching system 530 .

Abstract

In one embodiment, a method for using a two-hop relay includes receiving an update message for a distance vector routing protocol from a first neighbor. The update message is sent to a different neighbor. Often, it is first determined whether the receiving node is a relay node for the first neighbor in the protocol. The relay node is a node preferred to update a particular node two hops from the first neighbor. In another embodiment, a method for serving as the two-hop relay includes receiving from each neighbor a first message that includes neighbor data that indicates nodes that are in direct communication with the neighbor. A relay set of fewer than all neighbors is determined. Every node two hops from the first node is updated using only the relay set of neighbors. The relay set is sent in a second message for the protocol.

Description

BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to distance vector routing in packet switching communication networks, such as in a wireless mobile ad hoc network (MANET).
2. Background
Networks of general purpose computer systems and specialized devices connected by external communication links are well known and widely used in commerce. The networks often include one or more network devices that facilitate the passage of information between the computer systems and devices. A network node is a network device or computer or specialized device connected by the communication links. An end node is a node that is configured to originate or terminate communications over the network. An intermediate network node facilitates the passage of data between end nodes.
Communications between nodes are typically effected by exchanging discrete packets of data. Information is exchanged within data packets according to one or more of many well known, new or still developing protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other based on information sent over the communication links.
Routers are intermediate network nodes that support the exchange of data packets across multiple heterogeneous subnetworks. Routing protocols are used by routers to pass information that affects the links chosen by each router to forward a data packet. Some routing protocols require routers to exchange information about all connections at each router. Distance vector routing protocols require a router to pass only summary information that indicates a destination in the network and a total cost (called a distance) of reaching that destination from the router.
In emerging mobile networks, such as mobile ad hoc networks, communication bandwidth between routers can be scarce, while routing information is likely to change quickly, at least some of the time, as mobile nodes move into and out of direct communication with each other. Depending on the radio characteristics of the communicating nodes, some communication is two way (each can send and receive to the other) and some is one way (e.g., the node with a weaker transmitter can only receive from the other node and not send to it). It is very uncommon to use a one-way link for routing.
On demand routing protocols conserve bandwidth by passing routing information only when needed to forward a particular data stream of one or more packets of data. Such routing protocols may be perceived as slow to establish a connection. Proactive routing protocols use the time between data packets to pass routing information changes so that each router already has a path to each destination in the network. Such protocols may be perceived as faster to establish a connection, but may consume extra bandwidth for route maintenance, which slows the perceived duration of transmitting a data stream.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 illustrates an example network that incorporates a two-hop relay process for a distance vector routing protocol, according to an embodiment;
FIG. 2 illustrates example data structures on a router, according to an embodiment;
FIG. 3A illustrates an example distance vector routing protocol neighbor discovery message, according to an embodiment;
FIG. 3B illustrates another example distance vector routing protocol neighbor discovery message, according to an embodiment;
FIG. 3C illustrates an example distance vector routing protocol update message, according to an embodiment;
FIG. 4A illustrates, at a high level, an example method for using relay neighbors in a two-hop relay process, according to an embodiment;
FIG. 4B illustrates, at a high level, an example method for serving as a relay neighbor in a two-hop relay process, according to an embodiment; and
FIG. 5 illustrates a computer system upon which an embodiment of the invention may be implemented.
DESCRIPTION OF EXAMPLE EMBODIMENTS
A method and apparatus are described for reducing routing information passed in a distance vector routing protocol by using a two-hop relay. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Some embodiments are described below in the context of a small network of reasonably stable wireless two-way communication links using a particular distance vector protocol, such as the Enhanced Interior Gateway Routing Protocol (EIGRP) of Cisco Systems, Inc. of San Jose, Calif. However, embodiments of the invention are not limited to this context. In other embodiments, larger networks with wired or wireless communication links that are equally or less stable than those depicted herein, using the same or different distance vector routing protocols are involved in addition to or instead of the nodes, links and protocols described herein.
1.0 Overview
In one set of embodiments, a method for using a two-hop relay includes receiving an update message for a distance vector routing protocol at a node in a communications network from a first neighbor node in direct communication with the node. An update message is a message that indicates a destination in the communications network and a least total cost of reaching that destination from the neighbor that sent it. The receiving node sends the update message to a different neighbor of the plurality of neighbors, even though the routing protocol is a distance vector routing protocol that normally does not forward update messages.
In some of these embodiments, it is first determined whether the node is a relay node for the first neighbor in the distance vector routing protocol. If so, then the update message is sent immediately to the different neighbor. The relay node is a node preferred by the first neighbor to update a particular one or more nodes two hops from the first neighbor.
In another set of embodiments, a method for serving as a two hop relay includes receiving, at a first node in a communications network, a first message for a distance vector routing protocol from each neighbor. The first message from each neighbor includes neighbor data that indicates a set of one or more nodes that are in direct communication with the neighbor. A relay set of fewer than all neighbors is determined based on the neighbor data received from every neighbor. Each neighbor in the relay set is a neighbor preferred to update a particular one or more nodes two hops from the first node, and every node two hops from the first node is updated using only the relay set of neighbors. A second message for the distance vector routing protocol is sent to all the neighbors. The second message includes relay data that indicates the relay set.
In other embodiments, an apparatus, or logic encoded in one or more tangible media, or instructions encoded on one or more computer-readable media are configured to perform one or more steps of the above method.
As used herein, the article “a” and “the” mean “one or more,” unless otherwise indicated; and “comprising” and “including” before one or more listed items means “including but not limited to” the one or more listed items.
2.0 Networks
FIG. 1 illustrates an example network 100 that incorporates a two-hop relay process for a distance vector routing protocol, according to an embodiment. The network includes intermediate network nodes 120, including node 120 a, node 120 b, node 120 c, node 120 d, node 120 e, node 120 f and node 120 g connected by communication links 130. For purposes of illustration, each of links 130 represents two-way wireless communications using a single carrier frequency. In other embodiments, one or more links 130 are wireless links using one or more different carrier frequencies or are wired or optical cable links.
In a conventional distance vector routing protocol, each node 120 learns of its neighbors by receiving routing protocol neighbor discovery messages, such as an EIGRP HELLO message, that indicates a node identifier for the node that sent the message. As used herein, a neighbor of a node is a node with which that node has a direct two-way communication. In the illustrated embodiment, the direct communication links 130 are two-way links. Based on the HELLO and an acknowledgement message exchanged between each neighbor, each node 120 determines a cost associated with the link between the node and its neighbor. Any method known in the art may be used to determine a cost metric value for a link.
Each node then sends out a distance vector routing protocol update message that indicates a list of network addresses that can be reached from the node and the cost of reaching that address from the node sending the update message. At the start, each node 120 only knows the addresses and costs of any local area networks (LANs, not shown) connected directly to the node and its own address (with a cost of zero). Each node that receives an update message uses the information to update its routing information and sends an acknowledgement message. The receiving node then determines whether the new information changes the information it has previously sent out about the network addresses it can reach and the costs. If so, the receiving node adds the cost of the link between itself and the sending node to the cost of the addresses and sends a new update message with the changed information to its neighbors. The receiving node never forwards the update message from the sending node unchanged.
If possible, the revised update message is not sent back to the sending node, in an application of a so-called split horizon rule, to prevent extraneous looping of routing protocol packets back and forth between the two nodes. In wireless communications received by all neighbors, the update may be unicast or multicast only to the other neighbors; rather than broadcast to all neighbors. In a unicast, the address of a particular intended recipient is included in an internetwork layer protocol. In a multicast, the group name for a set of nodes is included in the internetwork layer protocol. The protocol update messages can be rather lengthy compared to the protocol neighbor discovery messages.
Some nodes are configured with filters to avoid forwarding data packets for some addresses, called filtered nodes. Filter data indicates a filtered node in the communications network for which data packets are not forwarded by the node. In such nodes, a change to the reachability or cost of a filtered node address is not included in an update message sent by the node. For example, if abusive behavior is noted from a particular LAN (not shown) attached to node 120 g by a network administrator for a LAN connected to node 120 b, node 120 b may be configured with a filter to remove routing information for the abusive LAN. If a cost on the link from node 120 g to node 120 a changes, prompting node 120 a to send an update message to all its neighbors, and only the abusive LAN is connected to node 120 g, then node 120 b will not send an update message with the new cost in response to this update received from node 120 a.
Eventually the routers in the network converge on a set of addresses reachable at itself and each neighbor, and the associated costs.
There are circumstances in which this update process is wasteful of bandwidth that may be scarce in a mobile network, such as a MANET. Consider an update sent by node 120 a to its neighbors, for example because node 120 g enters or leaves the network 100, or a new LAN is connected to node 120 a. The update message sent by node 120 a is received and acknowledged by all the neighbors of node 120 a, including node 120 b, node 120 c and node 120 d. This information is incorporated into the routing information at each of these nodes. Then updates are sent by node 120 b, node 120 c and node 120 d to node 120 e, while the update from node 120 b is also heard at node 120 f. The updates sent by node 120 b, node 120 c and node 120 d all indicate that node 120 g and its LANs are now reachable (unreachable) on the communications links 130 with node 120 b, node 120 c and node 120 d. This information is redundant. Therefore the bandwidth consumed to transmit all three updates is largely wasted. The only difference among the three updates might be any difference in costs of reaching node 120 g and its LANs among node 120 b, node 120 c and node 120 d. However, if the node 120 g has left the network 100, there is not even a cost difference among the updates from the three nodes: node 120 b, node 120 c and node 120 d; and the bandwidth consume by two of the three messages is entirely wasted.
Applicants have developed techniques to provide node 120 e with the routing information it needs, without sending three updates, one each from node 120 b, node 120 c and node 120 d. This can have significant impact on the availability of scarce bandwidth, because the update messages are rather lengthy compared to the other routing protocol messages, like a neighbor discovery message. In general, the techniques of the illustrated embodiments save scarce bandwidth in any network that includes one or more nodes that are two hops or more away from a node that experiences a change in routing information (such as reachability data).
According to the illustrated embodiment, at least some nodes 120 include at least a portion of a two-hop relay process 150. For example, node 120 a, node 120 b, node 120 c and node 120 d include two-hop relay process 150, or a portion thereof. In other embodiments, every intermediate node in a network 100, or a wireless portion thereof, includes the two-hop relay process 150.
While a certain number of nodes 120 and links 130 are depicted in network 100 for purposes of illustration, in other embodiments, a network includes more nodes, such as routers, more links, with the same or different costs and more or fewer end nodes and LANs.
3.0 Data Structures
FIG. 2 illustrates example data structures on a node 200, such as a router, according to an embodiment. Node 200 includes a routing process 210, a routing table 220, and routing protocol information in the form of protocol neighbor data 230.
The routing process 210 executes on a processor, such as a general purpose processor executing sequences of instructions that cause the processor to perform the routing process. According to illustrated embodiments of the invention, routing process 210 includes one or more methods 212 of the two-hop relay process 150. These methods are described in more detail below with respect to FIG. 4A and FIG. 4B. The routing process 210 stores and retrieves information in the routing table 220 based on information received in one or more distance vector routing protocol messages that are stored in a neighbor data structure 230 of a routing protocol information data structure.
The routing table 220 is a data structure that indicates for each destination that can be reached from the router 200, an address, a link and zero or more attributes, as is well known in the art.
The routing protocol neighbor data structure 230 is a data structure that includes, for each neighbor, a list of reachable destinations and costs, as is well known in the art. According to the illustrated embodiments, the neighbor data also includes a neighbors' neighbors field 232, a two-hop data field 240, a relay data field 244, and self relay field 260.
The neighbor's neighbors field 232 holds data that indicates all the neighbors of a neighbor of node 200, as listed in neighbor discovery messages, described below. In some embodiments, the neighbors' neighbors field 232 includes multiple entries for the same node, including multiple entries for the node 200 itself. For example, the neighbors of node 120 a are, in alphabetical order, node 120 b, node 120 c, 130 d and node 120 g. If all those nodes send their neighbors list to node 120 a and node 120 a stores those lists in neighbors' neighbors field 232, then field 232 includes the list of node 120 a, node 120 e, node 120 f, node 120 a, node 120 e, node 120 a, node 120 e, node 120 a.
The two-hop data field 240 is a pared down list of all the nodes that are two-hops from the node 200, based on data in the neighbors' neighbors field 232, but with redundant entries and all entries for the node 200, itself, removed. For example, at node 120 a, the two hop data field 240 includes the list of node 120 e and node 120 f, which are the only nodes in network 100 that are two hops from node 120 a, and a complete list.
The relay data field 244 holds data that indicates a subset of the neighbors of node 200 that are sufficient to forward updates to all nodes that are two hops away from node 200 and favored over other subsets that also reach all nodes two hops away from node 200. This subset is called the relay set of neighbors. Sometimes the subset includes all the neighbors of node 200; but advantages accrue, such as bandwidth savings, if fewer than all neighbors suffice to reach all two hop nodes. Each relay node in the relay set is a node preferred by the node 200 to update a particular node two hops from the node 200. The determination of the relay set is described in more detail in a later section. In one illustrated embodiment, the relay node is node 120 b. Node 120 b is able to forward all update messages from node 120 a to every node two hops away from node 120 a, e.g., node 120 e and node 120 f.
The self relay field 260 holds data that indicates any neighbors for which node 200 serves as the relay node to forward updates. For example, node 120 a is the relay node for node 120 b, node 120 c and node 120 d to forward updates to node 120 g, and is the relay node for node 120 g to forward updates to node 120 b, node 120 c and node 120 f, so all four neighbors of node 120 a are indicated in the self relay field 260.
Data structures may be formed in any method known in the art, including using portions of volatile memory, or non-volatile storage on one or more nodes, in one or more files or in one or more databases accessed through a database server, or some combination. Although data structures 220, 230 are shown as integral blocks with contiguous fields, e.g. fields 232, 240, 244, 260 in a particular order for purposes of illustration, in other embodiments one or more portions of fields and data structures 220, 230 are stored in the same or different order as separate data structures on the same or different multiple nodes that perform the functions of node 200. For example, in some embodiments, relay data field 244 and self relay field 260 are simply one-bit flags added to a record for each neighbor in the distance vector routing protocol neighbor data structure 230. One value of the bit in the relay data flag indicates the neighbor is a relay node for the node 200; and the other value indicates it is not. Similarly, one value of the bit in the self relay flag indicates the node 200 is a relay node for that neighbor; and the other value indicates it is not. As another example, in some embodiments, the neighbors' neighbors field 232 is a set of linked lists, each list starting in a record for one neighbor of node 200, to list the neighbors of that one neighbor.
FIG. 3A illustrates an example distance vector routing protocol neighbor discovery message, 310 according to an embodiment. A neighbor discovery message is a message type used by a distance vector routing protocol to discover the nodes that have a direct communication, such as direct two-way radio communications, with a particular node. For example, in EIGRP, the neighbor discovery message is called a HELLO message.
The neighbor discovery message 310 usually includes a sending router identification (ID) field 312 and an attributes field 314, both well known in the art. The sending router ID field holds data, such as a router's loopback Internet Protocol (IP) address that uniquely indicates the node that sent the message, or a network interface card IP address that uniquely indicates a particular interface on the sending node through which the message was sent. The attributes field 314 holds data that indicates other properties of the sending node that are used by the distance vector routing protocol.
According to the illustrated embodiment, the distance vector routing protocol is extended to allow the attributes field 314 of a neighbor discovery message 310 to include a neighbor data field 316 and a relay willingness field 318.
The neighbor data field 316 indicates the router IDs for all the nodes that are neighbors of the sending node. This information is used to fill a portion of the neighbors' neighbors field 232 at the receiving node. Such information is not passed among nodes in any current distance vector routing protocol known to the inventors.
In the illustrated embodiment, the neighbor data field 316 includes cost field 317 that indicates the cost of reaching each of the neighbors of the sending node from the sending node. In some embodiments, the cost field 317 is omitted. This cost data is considered in some embodiments to decide which neighbors of the receiving node are better situated to serve as a two-hop relay node, as explained in greater detail below. In some embodiments, this cost data is used to replace information that would be sent in an update message, that can be eliminated using the two-hop relay process 150.
The relay willingness field 318 holds data that indicates the sending node's assessment of its willingness to serve as a two-hop relay node for update messages. Willingness data, such as in field 318, indicates a relative capacity of the node to serve as a relay node. Any method of determining and indicating willingness may be used. In some embodiments, the relay willingness field holds a single octet (eight bits) that varies in value from 0 to 255. By default, a node's willingness is assumed to be a middle value 128. A node that is more capable and willing, such as a node with better than average processing capacity or more powerful transmitters, with better than average two-way communications, or less than average load, might specify a larger value. A node of limited communications, transmitter power or processing capacity or heavily loaded might specify a lower value. In some embodiments the relay willingness field 318 is omitted and all nodes are assumed to have the same, default willingness.
In other embodiments, the neighbor data field 316 or the relay willingness field 318, or both, are included in other types of messages for the distance vector protocol, such as an update message that is not forwarded.
FIG. 3B illustrates another example distance vector routing protocol neighbor discovery message 320, according to an embodiment. As described above, the neighbor discovery message usually includes a sending router identification (ID) field 312 and an attributes field 324, both well known in the art.
According to the illustrated embodiment, the distance vector routing protocol is extended to allow the attributes field 324 of a neighbor discovery message 320 to include a relay information field 326. The relay information field 326 holds data that indicates a relay set of one or more neighbors of the sending node (indicated in sending node ID field 312) that are to serve as two-hop relay nodes for forwarding update messages from the sending node. For example, a neighbor discovery message from node 120 a, after node 120 a determines that node 120 b is the appropriate two-hop relay, includes in field 326 data that indicates a relay set that consists of node 120 b alone.
In other embodiments, the relay information field 326 is included in other types of messages for the distance vector protocol, such as an update message that is not forwarded, or the neighbor discovery message 310 that includes neighbor data field 316.
FIG. 3C illustrates an example distance vector routing protocol update message 330, according to an embodiment. A distance vector routing protocol update message indicates a destination in the communications network and a least total cost of reaching that destination from the node sending the message.
The distance vector routing protocol message usually includes an advertised address with cost field 332 and attributes field 334. The advertised address with cost field 332 holds data that indicates a set of addresses reachable from the sending node and the associated costs of reaching those addresses through the sending node. The attributes field 334 holds data that indicates other properties of the sending node that are used by the distance vector routing protocol.
According to the illustrated embodiment, the distance vector routing protocol is extended to allow the attributes field 334 of an update message 330 to include an originating router field 336 and a sequence number (#) field 338. The originating router field 336 holds data that indicates a node that originated the update message 330, such as a loopback IP address for the node. The sequence # field 338 holds data that distinguishes among multiple update messages sent by the same sending node for acknowledgement purposes.
Update messages in existing distance vector routing protocols are not forwarded, and do not require both an origination router field 336 and a sequence # field 338. Because the distance vector routing protocol is being extend to support two-hop relay processes, it is desirable for an update message to indicate the originating router to distinguish forwarded messages from a relay node and the update messages that originate at the relay node, as described in more detail below.
Although fields in distance vector routing protocol messages 310, 320 and 330 are shown as contiguous blocks of data in a particular order in a single data packet for purposes of illustration, in other embodiments, one or more fields or portions thereof are arranged in a different order in one or more separate data packets.
4.0 Method
FIG. 4A illustrates, at a high level, an example method 400 for using relay neighbors in a two-hop relay process, according to an embodiment. Although steps in FIG. 4A and subsequent flow chart, FIG. 4B, are show in a particular order for purposes of illustration, in various other embodiments, one or more steps are performed in a different order or overlapping in time, in series or in parallel, or one or more steps are omitted or added, or changed in some combination of ways.
In step 410, distance vector neighbor discovery messages are received from all neighbors. The neighbor discovery messages include data that indicates the sending node's neighbors, at least, e.g., in neighbor field 314. In the illustrated embodiment, the discovery messages of the type indicated by message 310 are received with cost field 317 and relay willingness field 318 both included. For example, in network 100, node 120 a receives messages 310 from all its neighbors: node 120 b, node 120 c, node 120 d and node 120 g. For purposes of illustration, it is assumed that the data received during step 410 indicates the values listed in Table 1. In other embodiments, other messages with this information, such as special update type messages, are received. In the illustrated embodiment, the information listed in Table 1 is stored in neighbors' neighbors field 232 at node 120 a.
TABLE 1
Example neighbors, costs and willingness received in
discovery messages at node 120a.
Sending Relay
node Willingness Neighbors Costs
120b 128 120a, 120e, 120f 32, 30, 40
120c 140 120a, 120e 31, 31
120d 160 120a, 120e 33, 50
120g 128 120a 38
In step 420, two-hop nodes are determined based on the received messages with neighbor data, such as the discovery messages 310. For example, in network 100, node 120 a determines based on the data in Table 1 that its two-hop nodes are node 120 e and node 120 f, underlined upon their first appearance in Table 1. In the illustrated embodiment, the two-hop data is stored in two-hop data field 240.
In step 422, a relay set of possibly fewer than all neighbors is determined. The relay set is able to forward updates to all two-hop nodes from the node receiving the messages with neighbors data. The relay set is determined based on the messages received from the neighbors. In an illustrated embodiment, the relay data set is stored locally in relay data field 244.
For example, it is determined in step 422 that neighbor 120 b should be in the relay set alone. Node 120 b is able to forward to both two- hop nodes 120 e and 120 f, and no other node is needed to reach all of nodes that are two hops from node 120 a.
In some embodiments, the determination made during step 422 includes consideration of the cost or the willingness or both. For example, if node 120 f leaves the network 100, then there is only one two-hop node from node 120 a, i.e., node 120 e. Three neighbors (node 120 b, node 120 c, node 120 d) are able to send updates to node 120 e. The one chosen as the relay node is determined in step 422 based on the cost or willingness or both. For example, in some embodiments, cost is given more weight, and among neighbors with equal cost, willingness is used, and router ID number is then used to break remaining ties. In such an embodiment, both node 120 b and node 120 c have lower cost (62) than node 120 d (83), so one of those two is chosen. Node 120 c has higher willingness, so node 120 c is chosen as the only neighbor in the relay set. If cost is only used to break ties in willingness, then node 120 d, with the highest willingness is chosen as the only neighbor in the relay set.
In some embodiments, both cost and willingness are used together. For example, the neighbor is chosen with a highest score given by subtracting a weighted cost from willingness. For a weight of 1.0, and node 120 f absent, the scores of the three neighbors, node 120 b, node 120 c and node 120 d are 66, 78 and 77, respectively. Node 120 c with the highest score, 78, is chosen to be the only node in the relay set.
In step 424, the relay set for the node is sent to all the neighbors. For example, a neighbor discovery message 320 is sent to all neighbors with the relay set indicated by data in the relay information field 326. In the illustrated embodiment, using discovery message 320, the relay information field 326 holds data that indicates the relay set made up of node 120 b alone. If a relay set has already been sent to all neighbors and neither the neighbors nor the relay set has changed, then step 434 is omitted.
In step 430, it is determined whether there is a change in nodes reached from the current node, as is usual for a distance vector routing protocol. If not, control passes to step 438. In step 438, it is determined whether there is a new neighbor discovery message received. If so, control passes back to step 410 and subsequent steps to adapt to any changes in neighbors based on the new neighbor discovery messages. If not, control passes through other steps, not shown, back to step 430.
If it is determined in step 430 that there is a change in nodes or addresses reached from the current node, then control passes to step 431. For example, if another LAN with a new range of IP addresses is connected to node 120 a, then control passes to step 431.
In step 431, it is determined whether the change is based on an update from a neighbor for which the current node is not a relay. If so, then an update is not produced by the current node and control shifts to step 434 described below. Otherwise, control passes to step 432 in which the current node sends an update message based on the local changes. For example, since node 120 a is a relay node for all its neighbors, node 120 a always sends an update. However, if it is assumed for purposes of illustration that node 120 c is not a relay node for node 120 a, then an update received at node 120 c from node 120 a is used to update the routing tables at node 120 c, but the change is not included in an update sent from node 120 c, e.g., to node 120 e.
In step 432, an update message is sent to one or more neighbors. Unlike extant distance vector routing protocol update messages, the update message includes an identifier for the sending node (e.g., in field 346 of message 330) and a sequence #, such as a time stamp, that is unique among all update messages sent by the sending node (e.g., in field 348). In the illustrated embodiment, the update message due to changes at the local node is sent to all neighbors.
As explained in more detail below, each neighbor that receives the update message sent in step 432 sends an acknowledgement message and uses the data to update their own routing tables. However, rather than generating an update message to send to their neighbors, as is the case in extant distance vector routing protocols, only the relay nodes for the sending node forward the change in information, as an unchanged update message for changes that originated in their neighbor or as a modified update for changes that originated elsewhere. The nodes that are not relay nodes for the sending node do not send any updates, because such updates are rendered redundant by the information already sent in discovery messages and forwarded by the relay node(s), or information in updates sent by relay nodes. In the illustrated embodiment, node 120 b forwards the update message, unchanged, from node 120 a. Node 120 b incorporates updates received through node 120 a from farther nodes, e.g., node 120 g, and sends a modified update message. Nodes 120 c incoprorte changes received through node 120 a, but do not send updates, since they are not relay nodes for node 120 a. The update message forwarded or generated by node 120 b is received by node 120 e and node 120 f, which use the information to update their routing tables. In this embodiment, the node (e.g., node 120 a) reduces the number of directly connected neighbors which forward updates based on the sending node's knowledge of the two hop neighborhood.
In step 434, the update message generated locally is retransmitted from node 120 a if an acknowledgement is not received from all its neighbors within a predetermined retransmission time. Also, the update message received from the neighbor for which the current node is not a relay node (e.g., received at node 120 c from node 120 a) is transmitted from the node if an acknowledgement is not received from all its neighbors within a predetermined retransmission time. Control then passes back to step 438 and following steps to respond to new discovery messages and update messages.
FIG. 4B illustrates, at a high level, an example method 440 for serving as a relay neighbor in a two-hop relay process, according to an embodiment.
In step 450, the neighbors and link costs to those neighbors are determined, e.g., based on neighbor discovery messages and acknowledgements, as is currently done in distance vector routing protocols. For example, node 120 b determines the neighbors and link costs listed in two columns of the first line of Table 1, above.
In step 452, a discovery message is sent to all neighbors optionally indicating willingness to serve as relay and listing all neighbors and, optionally, costs. In the illustrated embodiment, the discovery messages of the type indicated by message 310 are sent with cost field 317 and relay willingness field 318 both included. For example, in network 100, node 120 b sends message 310 to all its neighbors, including node 120 a, as listed in the first line of Table 1. In other embodiments, other messages with this information, such as special update type messages, are sent.
In step 454, a message is received from each neighbor indicating that neighbor's relay set. For example, a neighbor discovery message 320 is received from all three neighbors of node 120 b with the relay set indicated by data in the relay information field 326. In the illustrated embodiment, a discovery message 320 is received from node 120 a in which the relay information field 326 holds data that indicates the relay set made up of node 120 b alone. Similarly, a discovery message 320 is received from node 120 f in which the relay information field 326 holds data that indicates the relay set made up of node 120 b alone. For purposes of illustration, it is assumed that node 120 e selects node 120 c as its relay node to update its two-hop node, node 120 a. Thus, a discovery message 320 is received from node 120 e in which the relay information field 326 holds data that indicates the relay set made up of node 120 c alone.
In step 458, the node receiving the relay sets determines neighbors, if any, for which the receiving node is a relay node. In the illustrated embodiment, the neighbors for which the receiving node serves as a relay node are stored in self relay field 260. Thus, at node 120 b, the self relay field 260 holds data that indicates node 120 b is a relay node for two neighbors, node 120 a and node 120 f.
In step 460, it is determined whether the node receives an update message from a neighbor, as is currently done in most distance vector routing protocols. If not, control passes back to step 450 and subsequent steps to receive any updates in neighbors and relay sets. If it is determined in step 460 that the node receives an update message from a neighbor, then control passes to step 462. It is assumed for purposes of illustration that node 120 b receives an update message sent by node 120 a that indicates the IP addresses of the LAN just connected to node 120 a. Unlike extant distance vector routing protocol update messages, the update message includes an identifier for the sending node (e.g., in field 346 of message 330) and a sequence #, such as a time stamp, that is unique among all update messages sent by the sending node (e.g., in field 348).
In step 462, the receiving node acknowledges the update message, e.g., by sending a short message that indicates the node identifier for the sending node. The receiving node also uses the data to update its routing table, and stores the update message for retransmission if not acknowledged. Control then passes to step 470.
In step 470, it is determined whether the node that receives the update message is a relay node for the sending node. For example, in some embodiments, the node checks the contents of self relay field 260 to determine whether data indicating the sending node is included therein. If so, then control passes to step 470. If not, then control passes to step 490.
In the illustrated embodiment, node 120 b that received the update message from 120 a determines that the sending node, node 120 a, is included in the self relay field 260. Therefore node 120 b recognizes that it is a relay node for the update message from node 120 a and control passes to step 472.
In step 472 the update message is immediately forwarded to all neighbors of the relay node, regardless of split horizon or filtering rules. In the illustrated embodiment, the update message from node 120 a is sent unchanged to node 120 e and node 120 f, the neighbors of relay node 120 b for the sending node 120 a. This is done even if the update is for IP addresses that are listed in a filter for node 120 b.
When node 120 e receives this update, it learns that node 120 a can reach the new LAN addresses. Node 120 b can determine whether the best route to node 120 a and the LAN addresses is through the relay node 120 b or another node, e.g., node 120 c or node 120 d. Node 120 e can make this determination because node 120 e already received costs to reach node 120 a through node 120 b and node 120 c and node 120 d in the discovery messages sent by each node when step 452 was executed at that node. For example, node 120 e received the discovery messages listed in the first three lines of Table 1. Thus when node 120 e updates its routing table it knows that the new addresses reached at node 120 a, which sent the forwarded message, has the same cost (62) through node 120 b and node 120 c Node 120 e will chose one of these two nodes to forward data packets directed to the new LAN addresses.
At node 120 c and node 120 d, which are not relay nodes for node 120 a, the routing tables are updated in step 462. However, it is determined in step 470 that the node receiving the update message is not the relay node for the sending node. Control passes to step 490 instead of step 472. The update message is not forwarded and updates to costs at nodes 120 c and 120 d are not used to generate new update messages from those nodes.
After step 472, in the illustrated embodiment, control passes to step 480. In step 480 it is determined whether the update message indicates a filtered node is updated. For example, it is determined whether the new LAN addresses are listed as filtered addresses at node 120 b.
A node is configured with filter data indicting node addresses for which the node will not forward data packets. Any method may be used to receive this configuration data. For example, in various embodiments, the data is included as a default value in software instructions, is received as manual input from a network administrator on the local or a remote node, is retrieved from a local file or database, or is sent from a different node on the network, either in response to a query or unsolicited, or the data is received using some combination of these methods.
If it is determined in step 480 that the route destinations updated in the update message are not filtered node addresses, control also passes to step 490. However, if it is determined that one or more route destinations updated in the update message are filtered node addresses, then control passes to step 482.
In step 482 a poison update message is sent to all neighbors for the filtered node addresses. A poison update message indicates a prohibitive cost to reach the filtered node through the node that sends the update message. For example, node 120 b sends a poison update message that indicates a cost to reach a filtered node address is a value that indicates “infinite” cost. Control then passes to step 490.
In step 490, any node that received an update message, whether a relay node or not, retransmits the update message if an acknowledgement for the update message is not received within a retransmission time. Because the update did not originate with the node that does the retransmission, the acknowledgement is recognized using the originating node identifier and sequence #. Control then passes back to step 450 to detect changes in neighbors or new update messages.
Neither relay nodes nor other neighbors of node 120 a construct a new update message based on changes to their routing table. Such updates are redundant with the information already passed in the forwarded update and the discovery messages reporting neighbors and costs. Thus the bandwidth to send updates from node 120 c and node 120 d is conserved for other uses. The bandwidth consumed for passing distance vector routing protocol information is reduced.
Method 400 or method 440 or both constitute the two-hop relay process 150 depicted in FIG. 1 that is included on one or more nodes of a network.
5.0 Implementation Mechanisms—Hardware Overview
FIG. 5 illustrates a computer system 500 upon which an embodiment of the invention may be implemented. The preferred embodiment is implemented using one or more computer programs running on a network element such as a router device. Thus, in this embodiment, the computer system 500 is a router.
Computer system 500 includes a communication mechanism such as a bus 510 for passing information between other internal and external components of the computer system 500. Information is represented as physical signals of a measurable phenomenon, typically electric voltages, but including, in other embodiments, such phenomena as magnetic, electromagnetic, pressure, chemical, molecular atomic and quantum interactions. For example, north and south magnetic fields, or a zero and non-zero electric voltage, represent two states (0, 1) of a binary digit (bit). A sequence of binary digits constitutes digital data that is used to represent a number or code for a character. A bus 510 includes many parallel conductors of information so that information is transferred quickly among devices coupled to the bus 510. One or more processors 502 for processing information are coupled with the bus 510. A processor 502 performs a set of operations on information. The set of operations include bringing information in from the bus 510 and placing information on the bus 510. The set of operations also typically include comparing two or more units of information, shifting positions of units of information, and combining two or more units of information, such as by addition or multiplication. A sequence of operations to be executed by the processor 502 constitute computer instructions.
Computer system 500 also includes a memory 504 coupled to bus 510. The memory 504, such as a random access memory (RAM) or other dynamic storage device, stores information including computer instructions. Dynamic memory allows information stored therein to be changed by the computer system 500. RAM allows a unit of information stored at a location called a memory address to be stored and retrieved independently of information at neighboring addresses. The memory 504 is also used by the processor 502 to store temporary values during execution of computer instructions. The computer system 500 also includes a read only memory (ROM) 506 or other static storage device coupled to the bus 510 for storing static information, including instructions, that is not changed by the computer system 500. Also coupled to bus 510 is a non-volatile (persistent) storage device 508, such as a magnetic disk or optical disk, for storing information, including instructions, that persists even when the computer system 500 is turned off or otherwise loses power.
The term computer-readable medium is used herein to refer to any medium that participates in providing information to processor 502, including instructions for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 508. Volatile media include, for example, dynamic memory 504. Transmission media include, for example, coaxial cables, copper wire, fiber optic cables, and carrier waves that travel through space without wires or cables, such as acoustic waves and electromagnetic waves, including radio, optical and infrared waves. Signals include man-made variations in amplitude, frequency, phase, polarization or other physical properties of carrier waves.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, a magnetic tape or any other magnetic medium, a compact disk ROM (CD-ROM), a digital video disk (DVD) or any other optical medium, punch cards, paper tape, or any other physical medium with patterns of holes, a RAM, a programmable ROM (PROM), an erasable PROM (EPROM), a FLASH-EPROM, or any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.
Information, including instructions, is provided to the bus 510 for use by the processor from an external terminal 512, such as a terminal with a keyboard containing alphanumeric keys operated by a human user, or a sensor. A sensor detects conditions in its vicinity and transforms those detections into signals compatible with the signals used to represent information in computer system 500. Other external components of terminal 512 coupled to bus 510, used primarily for interacting with humans, include a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD) or a plasma screen, for presenting images, and a pointing device, such as a mouse or a trackball or cursor direction keys, for controlling a position of a small cursor image presented on the display and issuing commands associated with graphical elements presented on the display of terminal 512. In some embodiments, terminal 512 is omitted.
Computer system 500 also includes one or more instances of a communications interface 570 coupled to bus 510. Communication interface 570 provides a two-way communication coupling via transmission media to a variety of external devices that operate with their own processors, such as printers, scanners, external disks, and terminal 512. Firmware or software running in the computer system 500 provides a terminal interface or character-based command interface so that external commands can be given to the computer system. For example, communication interface 570 may be a parallel port or a serial port such as an RS-232 or RS-422 interface, or a universal serial bus (USB) port on a personal computer. In some embodiments, communications interface 570 is an integrated services digital network (ISDN) card or a digital subscriber line (DSL) card or a telephone modem that provides an information communication connection to a corresponding type of telephone line. In some embodiments, a communication interface 570 is a cable modem that converts signals on bus 510 into signals for a communication connection over a coaxial cable or into optical signals for a communication connection over a fiber optic cable. As another example, communications interface 570 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN, such as Ethernet. Wireless links may also be implemented using carrier waves. For wireless links, the communications interface 570 sends and receives electrical, acoustic or electromagnetic signals, including infrared and optical signals, which carry information streams, such as digital data.
In the illustrated embodiment, special purpose hardware, such as an application specific integrated circuit (IC) 520, is coupled to bus 510. The special purpose hardware is configured to perform operations not performed by processor 502 quickly enough for special purposes. Examples of application specific ICs include graphics accelerator cards for generating images for display, cryptographic boards for encrypting and decrypting messages sent over a network, speech recognition, and interfaces to special external devices, such as robotic arms and medical scanning equipment that repeatedly perform some complex sequence of operations that are more efficiently implemented in hardware. Logic encoded in one or more tangible media includes one or both of computer instructions and special purpose hardware.
In the illustrated computer used as a router, the computer system 500 includes switching system 530 as special purpose hardware for switching information for flow over a network. Switching system 530 typically includes multiple communications interfaces, such as communications interface 570, for coupling to multiple other devices. In general, each coupling is with a network link 532 that is connected to another device in or attached to a network, such as local network 580 in the illustrated embodiment, to which a variety of external devices with their own processors are connected. In some embodiments, an input interface or an output interface or both are linked to each of one or more external network elements. Although three network links 532 a, 532 b, 532 c are included in network links 532 in the illustrated embodiment, in other embodiments, more or fewer links are connected to switching system 530. Network links 532 typically provides information communication via transmission media through one or more networks to other devices that use or process the information. For example, network link 532 b may provide a connection through local network 580 to a host computer 582 or to equipment 584 operated by an Internet Service Provider (ISP). ISP equipment 584 in turn provides data communication services through the public, world-wide packet-switching communication network of networks now commonly referred to as the Internet 590. A computer called a server 592 connected to the Internet provides a service in response to information received over the Internet. For example, server 592 provides routing information for use with switching system 530.
The switching system 530 includes logic and circuitry configured to perform switching functions associated with passing information among elements of network 580, including passing information received along one network link, e.g. 532 a, as output on the same or different network link, e.g., 532 c. The switching system 530 switches information traffic arriving on an input interface to an output interface according to pre-determined protocols and conventions that are well known. In some embodiments, switching system 530 includes its own processor and memory to perform some of the switching functions in software. In some embodiments, switching system 530 relies on processor 502, memory 504, ROM 506, storage 508, or some combination, to perform one or more switching functions in software. For example, switching system 530, in cooperation with processor 504 implementing a particular protocol, can determine a destination of a packet of data arriving on input interface on link 532 a and send it to the correct destination using output interface on link 532 c. The destinations may include host 582, server 592, other terminal devices connected to local network 580 or Internet 590, or other routing and switching devices in local network 580 or Internet 590.
The invention is related to the use of computer system 500 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 500 in response to processor 502 executing one or more sequences of one or more instructions contained in memory 504. Such instructions, also called software and program code, may be read into memory 504 from another computer-readable medium such as storage device 508. Execution of the sequences of instructions contained in memory 504 causes processor 502 to perform the method steps described herein. In alternative embodiments, hardware, such as application specific integrated circuit 520 and circuits in switching system 530, may be used in place of or in combination with software to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware and software, unless otherwise explicitly stated.
The signals transmitted over network link 532 and other networks via transmission media through communications interfaces such as interface 570, carry information to and from computer system 500. Computer system 500 can send and receive information, including program code, through the networks 580, 590 among others, through network links 532 and communications interfaces such as interface 570. In an example using the Internet 590, a server 592 transmits program code for a particular application, requested by a message sent from computer 500, through Internet 590, ISP equipment 584, local network 580 and network link 532 b through communications interface in switching system 530. The received code may be executed by processor 502 or switching system 530 as it is received, or may be stored in storage device 508 or other non-volatile storage for later execution, or both. In this manner, computer system 500 may obtain application program code in the form of signals on a carrier wave.
Various forms of computer readable media may be involved in carrying one or more sequence of instructions or data or both to processor 502 for execution. For example, instructions and data may initially be carried on a magnetic disk of a remote computer such as host 582. The remote computer loads the instructions and data into its dynamic memory and sends the instructions and data over a telephone line using a modem. A modem local to the computer system 500 receives the instructions and data on a telephone line and uses an infra-red transmitter to convert the instructions and data to a signal on an infra-red carrier wave serving as the network link 532 b. An infrared detector serving as communications interface in switching system 530 receives the instructions and data carried in the infrared signal and places information representing the instructions and data onto bus 510. Bus 510 carries the information to memory 504 from which processor 502 retrieves and executes the instructions using some of the data sent with the instructions. The instructions and data received in memory 504 may optionally be stored on storage device 508, either before or after execution by the processor 502 or switching system 530.
6.0 Extensions and Alternatives
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (22)

1. A method comprising:
receiving, at a node in a communications network, an update message for a distance vector routing protocol from a first neighbor of a plurality of neighbors, wherein the update message indicates a destination in the communications network and a least total cost of reaching that destination from the first neighbor, wherein the node is configured to filter at least one change in cost for a selected network address such that it is not forwarded;
sending, to a different neighbor of the plurality of neighbors, the update message, wherein if the change in cost for the selected network address is for a sole address provided in the update message, then the update message is not forwarded by the node;
sending the update message to the different neighbor of the plurality of neighbors if the node is a relay node for the first neighbor, wherein the relay node is a node preferred by the first neighbor to update a particular node a certain number of hops from the first neighbor;
determining whether the update message is for a filtered node address; and
sending to the different neighbor a poison update message that indicates a prohibitive cost to reach the filtered node address through the node.
2. The method as recited in claim 1, wherein sending the update message to the different neighbor further comprises sending the update message as a multicast to the plurality of neighbors.
3. The method as recited in claim 1, wherein determining whether the node is the relay node for the first neighbor further comprises:
receiving from the first neighbor a first message for the distance vector routing protocol, wherein the first message includes relay identification data that indicates the relay node; and,
determining that the node is the relay node if the relay identification data indicates the node.
4. The method as recited in claim 3 wherein the first message is a type of neighbor discovery message for the distance vector routing protocol.
5. The method as recited in claim 3 further comprising, sending a different second message for the distance vector routing protocol to the plurality of neighbors, wherein the different message includes neighbor data that indicates the plurality of neighbors.
6. The method as recited in claim 5 wherein the relay identification data is based on the neighbor data.
7. The method as recited in claim 5 wherein the neighbor data also indicates a corresponding plurality of costs to reach the plurality of neighbors and the relay identification data is also based on the plurality of costs.
8. The method as recited in claim 5 wherein:
the second message includes willingness data that indicates a relative capacity of the node to serve as a relay node; and,
the relay identification data is also based on the willingness data.
9. The method as recited in claim 5 wherein the second message is a type of neighbor discovery message for the distance vector routing protocol.
10. The method as recited in claim 1, further comprising:
if it is determined that the node is not the relay node for the first neighbor, then,
determining whether an acknowledgment message is received for the update message within a retransmission time; and
only sending the update message to the plurality of neighbors if it is determined that the acknowledgment message is not received within the retransmission time.
11. The method as recited in claim 1, further comprising, if it is determined that the node is not the relay node for the first neighbor, then, updating the local routing information based on the update message without sending an update message reflecting the updates to the local routing information.
12. A method comprising:
receiving, at a first node in a communications network, a first message for a distance vector routing protocol from each neighbor of a plurality of neighbors, wherein the first message from each neighbor of the plurality of neighbors includes a neighbor data that indicates a set of one or more nodes that are in direct communication with the neighbor;
determining a relay set of fewer than all neighbors of the plurality of neighbors based on the neighbor data received from every neighbor of the plurality of neighbors, wherein the first node is configured to filter at least one change in cost associated with reaching a destination for a selected network address such that it is not forwarded; and
sending to the plurality of neighbors a second message for the distance vector routing protocol, wherein the second message includes relay data that indicates the relay set, wherein every node two hops from the first node is updated using the relay set of neighbors;
determining whether a particular message is for a filtered node address; and
sending to a particular neighbor a poison update message that indicates a prohibitive cost to reach the filtered node address through the first node.
13. The method as recited in claim 12, wherein at least one of the first message or the second message is a type of neighbor discovery message for the distance vector routing protocol.
14. The method as recited in claim 12, wherein the neighbor data also indicates a cost of reaching each node in the set of one or more nodes from the neighbor and determining a relay set is also based on the plurality of costs.
15. The method as recited in claim 12, wherein:
the first message from each neighbor of the plurality of neighbors includes willingness data that indicates a relative capacity of the neighbor to serve as a relay node; and
determining the relay set further comprises determining the relay set based on the willingness data.
16. An apparatus comprising:
a network interface that is part of a node and that is configured for communicating a data packet with a packet-switched network;
logic encoded in one or more tangible media for execution and, when executed, operable to:
receive an update message for a distance vector routing protocol from a first neighbor of a plurality of neighbors, wherein the update message indicates a destination in a communications network and a least total cost of reaching that destination from the first neighbor, wherein the node is configured to filter at least one change in cost for a selected network address such that it is not forwarded as part of the update message;
send, to a different neighbor of the plurality of neighbors, the update message, wherein if the change in cost for the selected network address is for a sole address provided in the update message, then the update message is not forwarded by the node;
send the update message to the different neighbor of the plurality of neighbors if the node is a relay node for the first neighbor, wherein the relay node is a node preferred by the first neighbor to update a particular node two hops from the first neighbor;
determine whether the update message is for a filtered node address; and
send to the different neighbor a poison update message that indicates a prohibitive cost to reach the filtered node address.
17. The apparatus as recited in claim 16, wherein the logic operable to determine whether the apparatus is the relay node for the first neighbor is further operable to:
receive from the first neighbor a first message for the distance vector routing protocol, wherein the first message includes relay identification data that indicates the relay node; and,
determine that the apparatus is the relay node if the relay identification data indicates the apparatus.
18. The apparatus as recited in claim 17 wherein the first message is a type of neighbor discovery message for the distance vector routing protocol.
19. The apparatus as recited in claim 17 wherein the logic, when executed, is further operable to send a different second message for the distance vector routing protocol to the plurality of neighbors, wherein the different message includes neighbor data that indicates the plurality of neighbors.
20. The apparatus as recited in claim 19 wherein the relay identification data is based on the neighbor data.
21. The apparatus as recited in claim 19 wherein the second message is a type of neighbor discovery message for the distance vector routing protocol.
22. The apparatus as recited in claim 16, wherein, if it is determined that the apparatus is not the relay node for the first neighbor, the logic is further operable to then,
determine whether an acknowledgment message is received for the update message within a retransmission time; and
only send the update message to the plurality of neighbors if it is determined that the acknowledgment message is not received within the retransmission time.
US12/250,446 2008-10-13 2008-10-13 Two-hop relay for reducing distance vector routing information Active 2028-12-18 US7978612B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/250,446 US7978612B2 (en) 2008-10-13 2008-10-13 Two-hop relay for reducing distance vector routing information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12/250,446 US7978612B2 (en) 2008-10-13 2008-10-13 Two-hop relay for reducing distance vector routing information

Publications (2)

Publication Number Publication Date
US20100091823A1 US20100091823A1 (en) 2010-04-15
US7978612B2 true US7978612B2 (en) 2011-07-12

Family

ID=42098810

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/250,446 Active 2028-12-18 US7978612B2 (en) 2008-10-13 2008-10-13 Two-hop relay for reducing distance vector routing information

Country Status (1)

Country Link
US (1) US7978612B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100211718A1 (en) * 2009-02-17 2010-08-19 Paul Gratz Method and apparatus for congestion-aware routing in a computer interconnection network
CN105847278A (en) * 2016-05-03 2016-08-10 杭州寒舍科技有限公司 Distributed self-adaptive transmission routing protocol
US9756549B2 (en) 2014-03-14 2017-09-05 goTenna Inc. System and method for digital communication between computing devices
CN110139335A (en) * 2019-05-22 2019-08-16 南京大学 A kind of mobile Ad Hoc network method for routing based on node location information and active volume
US11811642B2 (en) 2018-07-27 2023-11-07 GoTenna, Inc. Vine™: zero-control routing using data packet inspection for wireless mesh networks

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7940668B2 (en) * 2008-03-21 2011-05-10 Cisco Technology, Inc. Method and apparatus to enable an IPe domain through EIGRP
US8199635B2 (en) * 2008-08-12 2012-06-12 General Atomics Method and system for network setup and maintenance and medium access control for a wireless sensor network
US8902805B2 (en) * 2008-10-24 2014-12-02 Qualcomm Incorporated Cell relay packet routing
JP5228951B2 (en) * 2009-01-30 2013-07-03 沖電気工業株式会社 Packet relay system and wireless node
ES2423989T3 (en) * 2009-03-30 2013-09-26 The Boeing Company AD HOC mobile network
ES2473515T3 (en) 2009-03-30 2014-07-07 The Boeing Company Mobile ad hoc network
US8503309B2 (en) * 2010-12-17 2013-08-06 Cisco Technology, Inc. Dynamic expelling of child nodes in directed acyclic graphs in a computer network
US10749711B2 (en) 2013-07-10 2020-08-18 Nicira, Inc. Network-link method useful for a last-mile connectivity in an edge-gateway multipath system
US10454714B2 (en) 2013-07-10 2019-10-22 Nicira, Inc. Method and system of overlay flow control
KR102184767B1 (en) * 2014-04-01 2020-12-01 삼성전자주식회사 Communication method and apparatus in network including plurality of device
US9124507B1 (en) * 2014-04-10 2015-09-01 Level 3 Communications, Llc Proxy of routing protocols to redundant controllers
US10498652B2 (en) 2015-04-13 2019-12-03 Nicira, Inc. Method and system of application-aware routing with crowdsourcing
US10135789B2 (en) 2015-04-13 2018-11-20 Nicira, Inc. Method and system of establishing a virtual private network in a cloud service for branch networking
US10425382B2 (en) 2015-04-13 2019-09-24 Nicira, Inc. Method and system of a cloud-based multipath routing protocol
US10069736B2 (en) * 2016-05-02 2018-09-04 Cisco Technology, Inc. Optimized in-network retransmission for information-centric networking protocols
US20200036624A1 (en) 2017-01-31 2020-01-30 The Mode Group High performance software-defined core network
US11706127B2 (en) 2017-01-31 2023-07-18 Vmware, Inc. High performance software-defined core network
US11252079B2 (en) 2017-01-31 2022-02-15 Vmware, Inc. High performance software-defined core network
US10992568B2 (en) 2017-01-31 2021-04-27 Vmware, Inc. High performance software-defined core network
US11121962B2 (en) 2017-01-31 2021-09-14 Vmware, Inc. High performance software-defined core network
US10992558B1 (en) 2017-11-06 2021-04-27 Vmware, Inc. Method and apparatus for distributed data network traffic optimization
US20180219765A1 (en) 2017-01-31 2018-08-02 Waltz Networks Method and Apparatus for Network Traffic Control Optimization
US10778528B2 (en) 2017-02-11 2020-09-15 Nicira, Inc. Method and system of connecting to a multipath hub in a cluster
US10523539B2 (en) 2017-06-22 2019-12-31 Nicira, Inc. Method and system of resiliency in cloud-delivered SD-WAN
US11089111B2 (en) 2017-10-02 2021-08-10 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US10999100B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external SAAS provider
US10959098B2 (en) 2017-10-02 2021-03-23 Vmware, Inc. Dynamically specifying multiple public cloud edge nodes to connect to an external multi-computer node
US11115480B2 (en) 2017-10-02 2021-09-07 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US10805114B2 (en) 2017-10-02 2020-10-13 Vmware, Inc. Processing data messages of a virtual network that are sent to and received from external service machines
US10999165B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Three tiers of SaaS providers for deploying compute and network infrastructure in the public cloud
US11223514B2 (en) 2017-11-09 2022-01-11 Nicira, Inc. Method and system of a dynamic high-availability mode based on current wide area network connectivity
CN110875938A (en) * 2018-08-31 2020-03-10 元一科技控股有限公司 Method and device for sending information in block chain
US11018995B2 (en) 2019-08-27 2021-05-25 Vmware, Inc. Alleviating congestion in a virtual network deployed over public clouds for an entity
US11611507B2 (en) 2019-10-28 2023-03-21 Vmware, Inc. Managing forwarding elements at edge nodes connected to a virtual network
US11394640B2 (en) 2019-12-12 2022-07-19 Vmware, Inc. Collecting and analyzing data regarding flows associated with DPI parameters
US11489783B2 (en) 2019-12-12 2022-11-01 Vmware, Inc. Performing deep packet inspection in a software defined wide area network
US20210234804A1 (en) 2020-01-24 2021-07-29 Vmware, Inc. Accurate traffic steering between links through sub-path path quality metrics
US11245641B2 (en) 2020-07-02 2022-02-08 Vmware, Inc. Methods and apparatus for application aware hub clustering techniques for a hyper scale SD-WAN
US11709710B2 (en) 2020-07-30 2023-07-25 Vmware, Inc. Memory allocator for I/O operations
US11575591B2 (en) 2020-11-17 2023-02-07 Vmware, Inc. Autonomous distributed forwarding plane traceability based anomaly detection in application traffic for hyper-scale SD-WAN
US11575600B2 (en) 2020-11-24 2023-02-07 Vmware, Inc. Tunnel-less SD-WAN
US11929903B2 (en) 2020-12-29 2024-03-12 VMware LLC Emulating packet flows to assess network links for SD-WAN
US11792127B2 (en) 2021-01-18 2023-10-17 Vmware, Inc. Network-aware load balancing
CN113115398B (en) * 2021-03-01 2022-11-11 北京遥测技术研究所 Aircraft cluster networking routing method based on software defined network
US11381499B1 (en) 2021-05-03 2022-07-05 Vmware, Inc. Routing meshes for facilitating routing through an SD-WAN
US11729065B2 (en) 2021-05-06 2023-08-15 Vmware, Inc. Methods for application defined virtual network service among multiple transport in SD-WAN
US11489720B1 (en) 2021-06-18 2022-11-01 Vmware, Inc. Method and apparatus to evaluate resource elements and public clouds for deploying tenant deployable elements based on harvested performance metrics
US11375005B1 (en) 2021-07-24 2022-06-28 Vmware, Inc. High availability solutions for a secure access service edge application
US11909815B2 (en) 2022-06-06 2024-02-20 VMware LLC Routing based on geolocation costs

Citations (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6032194A (en) * 1997-12-24 2000-02-29 Cisco Technology, Inc. Method and apparatus for rapidly reconfiguring computer networks
US6484209B1 (en) * 1997-10-31 2002-11-19 Nortel Networks Limited Efficient path based forwarding and multicast forwarding
US6578086B1 (en) * 1999-09-27 2003-06-10 Nortel Networks Limited Dynamically managing the topology of a data network
US20030107992A1 (en) * 2000-10-30 2003-06-12 The Regents Of The University Of California Loop-free multipath routing method using distance vectors
US20040213167A1 (en) * 1999-10-15 2004-10-28 Nokia Wireless Routers, Inc. System for communicating labeled routing trees to establish preferred paths and source routes with local identifiers in wireless computer networks
US20050073998A1 (en) * 2003-10-01 2005-04-07 Santera Systems, Inc. Methods, systems, and computer program products for voice over IP (VoIP) traffic engineering and path resilience using media gateway and associated next-hop routers
US20050135256A1 (en) 2003-12-23 2005-06-23 Ball David A. System and method for distributing route selection in an implementation of a routing protocol
US20050160179A1 (en) * 2004-01-21 2005-07-21 Cisco Technology, Inc. System and method for controlling the flooding of information in a network environment
US20060007865A1 (en) * 2004-07-12 2006-01-12 White Russell I Arrangement for preventing count-to-infinity in flooding distance vector routing protocols
US7042834B1 (en) 2000-07-28 2006-05-09 Cisco Technology, Inc. Method and system for routing communications among computer networks
US7123620B1 (en) 2000-04-25 2006-10-17 Cisco Technology, Inc. Apparatus and method for scalable and dynamic traffic engineering in a data communication network
US20060282511A1 (en) 2005-06-14 2006-12-14 Hitachi Global Storage Technologies Netherlands B.V. Method for limiting utilizing terminal of contents, and memory device and system for method
US20060291404A1 (en) * 2005-06-28 2006-12-28 Pascal Thubert Directed acyclic graph discovery and network prefix information distribution relative to a clusterhead in an ad hoc mobile network
US20070019647A1 (en) * 2005-07-11 2007-01-25 Cisco Technology, Inc. Unsynchronized adjacencies in OSPF
US7174371B2 (en) * 2002-07-08 2007-02-06 Packetfront Sweden Ab Dynamic port configuration of network equipment
US7203191B2 (en) 2000-10-10 2007-04-10 The Regents Of The University Of California Method for loop-free multipath routing using predecessor information
US20070115837A1 (en) * 2005-06-17 2007-05-24 David Elie-Dit-Cosaque Scalable Selective Alarm Suppression for Data Communication Network
US20070121521A1 (en) * 2005-11-30 2007-05-31 D Amico Thomas V Method and apparatus for broadcast in an AD HOC network with dynamic selection of relay nodes
US7230914B2 (en) 2002-11-22 2007-06-12 Nokia Inc. Method and system for synchronizing a standby route distributor in a distributed routing platform
US7260518B2 (en) 1996-05-28 2007-08-21 Cisco Technology, Inc. Network flow switching and flow data report
US20070237095A1 (en) 2006-04-05 2007-10-11 Cisco Technology, Inc. System and method for improving network performance and security by controlling topology information
US7302482B2 (en) 2000-11-01 2007-11-27 Cisco Technology, Inc. Traffic flow optimisation system
US20070291663A1 (en) * 2006-06-19 2007-12-20 Nokia Corporation Method and apparatus for scale-free topology generation in relay based wireless networks
US7319674B2 (en) 2003-07-24 2008-01-15 Cisco Technology, Inc. System and method for exchanging awareness information in a network environment
US7325069B1 (en) 2001-12-07 2008-01-29 Cisco Technology, Inc. Method of establishing bi-directional connectivity of a network element in a network
US20080031236A1 (en) 2006-08-01 2008-02-07 Cisco Technology, Inc. Techniques for one-way synchronization of routing information among intermediate nodes
US7333501B2 (en) 2005-01-14 2008-02-19 Cisco Technology, Inc. Techniques for determining network nodes to represent, multiple subnetworks for a routing protocol
US7450495B2 (en) 2004-03-15 2008-11-11 Iptivia, Inc. Method and system for path change root-cause identification in packet networks
US7466703B1 (en) 1998-05-01 2008-12-16 Alcatel-Lucent Usa Inc. Scalable high speed router apparatus
US7512106B2 (en) * 2006-08-01 2009-03-31 Cisco Technology, Inc. Techniques for distributing routing information using multicasts
US20090091465A1 (en) 2005-12-23 2009-04-09 Mark-Paul Buckingham Monitoring Apparatus and Method
US7525920B2 (en) * 2001-11-29 2009-04-28 Coactive Technologies, Inc. Method and system for path identification in packet networks
US20090147723A1 (en) * 2007-12-07 2009-06-11 Hong Kong Applied Science and Technology Research Institute Company Limited Method and Device for Data Routing and Bandwidth Reservation in Small Scale Distributed Networks
US20090238076A1 (en) * 2008-03-21 2009-09-24 Cisco Technology, Inc. METHOD AND APPARATUS TO ENABLE AN IPe DOMAIN THROUGH EIGRP
US7672253B2 (en) * 2007-08-06 2010-03-02 Cisco Technology, Inc. Border router with selective filtering of link state advertisements
US7693939B2 (en) * 2007-05-07 2010-04-06 Microsoft Corporation Context-based routing in multi-hop networks
US7693073B2 (en) 2006-10-13 2010-04-06 At&T Intellectual Property I, L.P. System and method for routing packet traffic
US7697505B2 (en) * 2006-02-03 2010-04-13 Cisco Technology, Inc. Techniques for decreasing queries to discover routes in an interior gateway protocol
US7808927B2 (en) * 2008-02-05 2010-10-05 Cisco Technology, Inc. Technique to automatically deaggregate an optimum set to prevent suboptimal routing or routing failures within a link state flooding domain
US20100309799A1 (en) * 2007-09-14 2010-12-09 Nec Europe Ltd. Method and system for optimizing network performances

Patent Citations (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7260518B2 (en) 1996-05-28 2007-08-21 Cisco Technology, Inc. Network flow switching and flow data report
US6484209B1 (en) * 1997-10-31 2002-11-19 Nortel Networks Limited Efficient path based forwarding and multicast forwarding
US6032194A (en) * 1997-12-24 2000-02-29 Cisco Technology, Inc. Method and apparatus for rapidly reconfiguring computer networks
US7466703B1 (en) 1998-05-01 2008-12-16 Alcatel-Lucent Usa Inc. Scalable high speed router apparatus
US6578086B1 (en) * 1999-09-27 2003-06-10 Nortel Networks Limited Dynamically managing the topology of a data network
US20040213167A1 (en) * 1999-10-15 2004-10-28 Nokia Wireless Routers, Inc. System for communicating labeled routing trees to establish preferred paths and source routes with local identifiers in wireless computer networks
US6836463B2 (en) * 1999-10-15 2004-12-28 Nokia Corporation System for communicating labeled routing trees to establish preferred paths and source routes with local identifiers in wireless computer networks
US7123620B1 (en) 2000-04-25 2006-10-17 Cisco Technology, Inc. Apparatus and method for scalable and dynamic traffic engineering in a data communication network
US7042834B1 (en) 2000-07-28 2006-05-09 Cisco Technology, Inc. Method and system for routing communications among computer networks
US7203191B2 (en) 2000-10-10 2007-04-10 The Regents Of The University Of California Method for loop-free multipath routing using predecessor information
US20030107992A1 (en) * 2000-10-30 2003-06-12 The Regents Of The University Of California Loop-free multipath routing method using distance vectors
US7302482B2 (en) 2000-11-01 2007-11-27 Cisco Technology, Inc. Traffic flow optimisation system
US7525920B2 (en) * 2001-11-29 2009-04-28 Coactive Technologies, Inc. Method and system for path identification in packet networks
US7325069B1 (en) 2001-12-07 2008-01-29 Cisco Technology, Inc. Method of establishing bi-directional connectivity of a network element in a network
US7174371B2 (en) * 2002-07-08 2007-02-06 Packetfront Sweden Ab Dynamic port configuration of network equipment
US7230914B2 (en) 2002-11-22 2007-06-12 Nokia Inc. Method and system for synchronizing a standby route distributor in a distributed routing platform
US7319674B2 (en) 2003-07-24 2008-01-15 Cisco Technology, Inc. System and method for exchanging awareness information in a network environment
US20050073998A1 (en) * 2003-10-01 2005-04-07 Santera Systems, Inc. Methods, systems, and computer program products for voice over IP (VoIP) traffic engineering and path resilience using media gateway and associated next-hop routers
US20050135256A1 (en) 2003-12-23 2005-06-23 Ball David A. System and method for distributing route selection in an implementation of a routing protocol
US7023808B2 (en) 2003-12-23 2006-04-04 Cisco Technology, Inc. System and method for distributing route selection in an implementation of a routing protocol
US20050160179A1 (en) * 2004-01-21 2005-07-21 Cisco Technology, Inc. System and method for controlling the flooding of information in a network environment
US7821956B2 (en) * 2004-01-21 2010-10-26 Cisco Technology, Inc. System and method for controlling the flooding of information in a network environment
US7298707B2 (en) * 2004-01-21 2007-11-20 Cisco Technology, Inc. System and method for controlling the flooding of information in a network environment
US20080043635A1 (en) * 2004-01-21 2008-02-21 Cisco Technology, Inc. System and Method for Controlling the Flooding of Information in a Network Environment
US7450495B2 (en) 2004-03-15 2008-11-11 Iptivia, Inc. Method and system for path change root-cause identification in packet networks
US20060007865A1 (en) * 2004-07-12 2006-01-12 White Russell I Arrangement for preventing count-to-infinity in flooding distance vector routing protocols
US7333501B2 (en) 2005-01-14 2008-02-19 Cisco Technology, Inc. Techniques for determining network nodes to represent, multiple subnetworks for a routing protocol
US20060282511A1 (en) 2005-06-14 2006-12-14 Hitachi Global Storage Technologies Netherlands B.V. Method for limiting utilizing terminal of contents, and memory device and system for method
US20070115837A1 (en) * 2005-06-17 2007-05-24 David Elie-Dit-Cosaque Scalable Selective Alarm Suppression for Data Communication Network
US20060291404A1 (en) * 2005-06-28 2006-12-28 Pascal Thubert Directed acyclic graph discovery and network prefix information distribution relative to a clusterhead in an ad hoc mobile network
US20070019647A1 (en) * 2005-07-11 2007-01-25 Cisco Technology, Inc. Unsynchronized adjacencies in OSPF
US20070121521A1 (en) * 2005-11-30 2007-05-31 D Amico Thomas V Method and apparatus for broadcast in an AD HOC network with dynamic selection of relay nodes
US20090091465A1 (en) 2005-12-23 2009-04-09 Mark-Paul Buckingham Monitoring Apparatus and Method
US7697505B2 (en) * 2006-02-03 2010-04-13 Cisco Technology, Inc. Techniques for decreasing queries to discover routes in an interior gateway protocol
US20070237095A1 (en) 2006-04-05 2007-10-11 Cisco Technology, Inc. System and method for improving network performance and security by controlling topology information
US20070291663A1 (en) * 2006-06-19 2007-12-20 Nokia Corporation Method and apparatus for scale-free topology generation in relay based wireless networks
US7512106B2 (en) * 2006-08-01 2009-03-31 Cisco Technology, Inc. Techniques for distributing routing information using multicasts
US20080031236A1 (en) 2006-08-01 2008-02-07 Cisco Technology, Inc. Techniques for one-way synchronization of routing information among intermediate nodes
US7693073B2 (en) 2006-10-13 2010-04-06 At&T Intellectual Property I, L.P. System and method for routing packet traffic
US7693939B2 (en) * 2007-05-07 2010-04-06 Microsoft Corporation Context-based routing in multi-hop networks
US7672253B2 (en) * 2007-08-06 2010-03-02 Cisco Technology, Inc. Border router with selective filtering of link state advertisements
US20100309799A1 (en) * 2007-09-14 2010-12-09 Nec Europe Ltd. Method and system for optimizing network performances
US20090147723A1 (en) * 2007-12-07 2009-06-11 Hong Kong Applied Science and Technology Research Institute Company Limited Method and Device for Data Routing and Bandwidth Reservation in Small Scale Distributed Networks
US7808927B2 (en) * 2008-02-05 2010-10-05 Cisco Technology, Inc. Technique to automatically deaggregate an optimum set to prevent suboptimal routing or routing failures within a link state flooding domain
US20090238076A1 (en) * 2008-03-21 2009-09-24 Cisco Technology, Inc. METHOD AND APPARATUS TO ENABLE AN IPe DOMAIN THROUGH EIGRP

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Chandra, M and Roy, A, Extensions to OSPF to Support Mobile Ad Hoc Networking , draft-chandra-ospf-manet-ext-05, Aug. 1, 2007, p. 32pp, Publisher: http://tools.ietf.org/html/, Published in: San Jose, California, US.
Perkins et al., Ad Hoc On-Demand Distance Vector (AODV) Routing, Jul. 2003, p. 14 (30 pages).

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100211718A1 (en) * 2009-02-17 2010-08-19 Paul Gratz Method and apparatus for congestion-aware routing in a computer interconnection network
US8285900B2 (en) * 2009-02-17 2012-10-09 The Board Of Regents Of The University Of Texas System Method and apparatus for congestion-aware routing in a computer interconnection network
US8694704B2 (en) 2009-02-17 2014-04-08 Board Of Regents, University Of Texas Systems Method and apparatus for congestion-aware routing in a computer interconnection network
US9571399B2 (en) 2009-02-17 2017-02-14 The Board Of Regents Of The University Of Texas System Method and apparatus for congestion-aware routing in a computer interconnection network
US9756549B2 (en) 2014-03-14 2017-09-05 goTenna Inc. System and method for digital communication between computing devices
US10015720B2 (en) 2014-03-14 2018-07-03 GoTenna, Inc. System and method for digital communication between computing devices
US10602424B2 (en) 2014-03-14 2020-03-24 goTenna Inc. System and method for digital communication between computing devices
CN105847278A (en) * 2016-05-03 2016-08-10 杭州寒舍科技有限公司 Distributed self-adaptive transmission routing protocol
CN105847278B (en) * 2016-05-03 2022-02-08 杭州盈飞驰科技有限公司 Distributed self-adaptive transmission method
US11811642B2 (en) 2018-07-27 2023-11-07 GoTenna, Inc. Vine™: zero-control routing using data packet inspection for wireless mesh networks
CN110139335A (en) * 2019-05-22 2019-08-16 南京大学 A kind of mobile Ad Hoc network method for routing based on node location information and active volume

Also Published As

Publication number Publication date
US20100091823A1 (en) 2010-04-15

Similar Documents

Publication Publication Date Title
US7978612B2 (en) Two-hop relay for reducing distance vector routing information
US7936732B2 (en) Selecting aggregation nodes in a network
US8699410B2 (en) Method and apparatus for automatic sub-division of areas that flood routing information
US7940776B2 (en) Fast re-routing in distance vector routing protocol networks
US7515551B2 (en) Techniques for reducing adjacencies in a link-state network routing protocol
US7756038B2 (en) Service advertisement framework (SAF) in a communications network
US7889655B2 (en) Techniques for detecting loop-free paths that cross routing information boundaries
US7697505B2 (en) Techniques for decreasing queries to discover routes in an interior gateway protocol
US7768995B2 (en) Techniques for one-way synchronization of routing information among intermediate nodes
US7796537B2 (en) Creating non-transit nodes in a link network
US8009591B2 (en) Automatic overlapping areas that flood routing information
US7899005B2 (en) Method and apparatus for passing routing information among mobile routers
JP5087553B2 (en) Method and system for adaptive wireless routing protocol in mesh networks
US7382731B1 (en) Method and apparatus for updating probabilistic network routing information
EP2652905B1 (en) Increased communication opportunities with low-contact nodes in a computer network
US9143431B2 (en) Hiding a service node in a network from a network routing topology
JP2004336716A (en) Path mtu discovery system and method for ad-hoc network
US11765078B2 (en) Techniques for loop-free dynamic on-demand and proactive routing in communications networks
US20080212585A1 (en) Preventing Loops during Recovery in Network Rings Using Cost Metric Routing Protocol
JP2010178310A (en) Route control system and route control apparatus
Mim et al. Study on Routing Protocols in Wireless Ad-HOC Networks

Legal Events

Date Code Title Description
AS Assignment

Owner name: CISCO TECHNOLOGY, INC.,CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RETANA, ALVARO;RATLIFF, STANLEY;SAVAGE, DONNIE;AND OTHERS;SIGNING DATES FROM 20080924 TO 20081008;REEL/FRAME:021675/0761

Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RETANA, ALVARO;RATLIFF, STANLEY;SAVAGE, DONNIE;AND OTHERS;SIGNING DATES FROM 20080924 TO 20081008;REEL/FRAME:021675/0761

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12