Title of Invention: System and method for secure communication of routing messages Abstract: A system and method distributes encryption and/or authentication capabilities among route processors in a manner that allows route processors in a set of route processors to back each other up in case one or more of the route processors in the set fail. Detailed Description: Part general_description_paragraphs: Part RELATED APPLICATIONS: This application claims the benefit of U.S. provisional patent application No. 60/420,016 entitled, “Method and Apparatus for Secure Communication of Routing Messages” filed by Van Jacobson, Kedar Poduri, Satish Kanna, Cengiz Alaettinoglu on Oct. 21, 2002, and is a continuation-in-part of U.S. patent application Ser. No. 10/206,715 entitled “System and Method for Communicating Routing Information” filed on Jul. 26, 2002 by Van Jacobson, Kedar Poduri, Satish Kanna, and Cengiz Alaettinoglu, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/308,174, entitled, “METHOD AND APPARATUS FOR ALLOCATING (I)BGP MESSAGES TO ONE OF SEVERAL PROCESSORS” filed on Jul. 26, 2001 by Van Jacobson, Kedar Poduri, and Cengiz Alaettinoglu, U.S. Provisional Patent Application Ser. No. 60/308,156, entitled, “METHOD AND APPARATUS FOR PROCESSING (I)BGP MESSAGES” filed on Jul. 26, 2001 by Van Jacobson, Kedar Poduri, and Cengiz Alaettinoglu, and U.S. Provisional Patent Application Ser. No. 60/308,333, entitled, “METHOD AND APPARATUS FOR REDUNDANT ROUTE PROCESSING” filed on Jul. 26, 2001 by Van Jacobson, Kedar Poduri, and Cengiz Alaettinoglu, all having the same assignee as the present application and each is incorporated herein by reference in its entirety. Part FIELD OF THE INVENTION: The present invention is related to communication systems and more specifically to communication systems for processing network management information. Part BACKGROUND OF THE INVENTION: Conventional networks such as the Internet may be made up of several autonomous systems, which are networks under the administrative control of a single entity, such as a conventional Internet Service Provider, or ISP. Each autonomous system (“AS”) communicates topology and routing information with every other AS to which it is in communication directly, that is, without passing through another AS. The conventional (E)BGP protocol (known as the Border Gateway Protocol) may be used to communicate such information. A border router at the edge one AS uses a different connection with each border router in the other AS to which it is connected to exchange (E)BGP information with the other border routers to which it is in communication. Additional connections are employed to accurately communicate this (E)BGP information to the other border routers in the AS. Because the computer processing the (E)BGP information may have a finite amount of resources, and each connection takes a certain amount of these resources, as the number of routers in other autonomous systems connected to a border router grows, and as the number of routers in the same AS as the router to which the router must be connected also grows, (E)BGP information is communicated through separate connections to each of these other devices, processor capacity can become a constraint. It can be desirable to use processor capacity for other purposes. For example, because the communications between routers in different autonomous systems is unauthenticated and unencrypted, it subjects each autonomous system to attack by malicious parties. It would be desirable to encrypt and/or authenticate the (E)BGP information arriving from outside of an AS, but in many cases, there may be no processor capacity available to perform these functions. Even if there is, as the network grows, the processors in the route processors may be needed for the additional connections required, making parties reluctant to commit capacity to authorization and encryption that may be needed in the future to support additional connections. An additional problem can occur if encryption is employed. If a route processor fails, another route processor cannot take over the duties of that route processor because the second route processor will not have the encryption state needed to continue the session. Instead, another session must be started, further reducing the capacity of the route processor. What is needed is a system and method that can accurately disseminate (E)BGP information between and within an AS that can encrypt and/or authenticate (E)BGP information and have sufficient capacity available for connections to communicate (E)BGP and other routing information even as a network grows, and can allow for redundancy among route processors. Part SUMMARY OF INVENTION: A system and method employs a flooding technique, in which a route processor communicates only with adjacent route processors and a number of border routers from which routing information is received, to communicate BGP information, which is secured using conventional security and authentication techniques. The flooding technique does not require a separate connection between every route processor, dramatically reducing the resources required to communicate (E)BGP and other routing information, even as the network grows. If encryption such as IPSec is used, the encryption state is flooded with the other messages to allow the system to recover from failures by having another route processor continue the IPSec session using the flooded encryption state. Part DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT: The present invention may be implemented as computer software on a conventional computer system. Referring now to FIG. 1, a conventional computer system 150 for practicing the present invention is shown. Processor 160 retrieves and executes software instructions stored in storage 162 such as memory, which may be Random Access Memory (RAM) and may control other components to perform the present invention. Storage 162 may be used to store program instructions or data or both. Storage 164, such as a computer disk drive or other nonvolatile storage, may provide storage of data or program instructions. In one embodiment, storage 164 provides longer term storage of instructions and data, with storage 162 providing storage for data or instructions that may only be required for a shorter time than that of storage 164. Input device 166 such as a computer keyboard or mouse or both allows user input to the system 150. Output 168, such as a display or printer, allows the system to provide information such as instructions, data or other information to the user of the system 150. Storage input device 170 such as a conventional floppy disk drive or CD-ROM drive accepts via input 172 computer program products 174 such as a conventional floppy disk or CD-ROM or other nonvolatile storage media that may be used to transport computer instructions or data to the system 150. Computer program product 174 has encoded thereon computer readable program code devices 176, such as magnetic charges in the case of a floppy disk or optical encodings in the case of a CD-ROM which are encoded as program instructions, data or both to configure the computer system 150 to operate as described below. In one embodiment, each computer system 150 is a conventional SUN MICROSYSTEMS ULTRA 10 workstation running the Solaris operating system commercially available from SUN MICROSYSTEMS of Mountain View, Calif., a PENTIUM-compatible personal computer system such as are available from DELL COMPUTER CORPORATION of Round Rock, Tex. running a version of the WINDOWS operating system (such as 95, 98, Me, XP, NT or 2000) commercially available from MICROSOFT CORPORATION of Redmond Wash. or a MACINTOSH computer system running the MACOS or OPENSTEP operating system commercially available from APPLE COMPUTER CORPORATION of Cupertino, Calif. and the NETSCAPE browser commercially available from NETSCAPE COMMUNICATIONS CORPORATION of Mountain View, Calif. although other systems may be used. Referring now to FIG. 2, a system for processing routing messages is shown according to one embodiment of the present invention. In one embodiment, all communication into or out of system 200 is made via input/output 208 of communication interface 210 which is coupled to a network such as the Internet or a local area network or both. Communication interface 210 is a conventional communication interface that supports TCP/IP, SCTP, UDP or other conventional communication protocols. In one embodiment, when system 200 initializes, system 200 contacts or is contacted by, various devices in the autonomous system (not shown) in order to initiate a series of BGP conversations using conventional BGP protocols, such as (E)BGP or (I)BGP. Although the devices are described as routers herein, in other embodiments, the devices may include routers, route reflectors or other devices. The various devices that system 200 communicates with or accepts communications from are identified by a system administrator providing to system administration manager 212 the IP addresses of those devices with which system 200 is to establish a BGP peering relationship, for example, via (I)BGP. Communication with system administration manager 212 may be performed via communication interface 210, for example, by connecting to the IP address of system 200 using a port that corresponds to system administration manager 212. Communication interface 210 provides such communications to system administration manager 212 and receives and forwards replies from system administration manager 212 to the intended recipient via input/output 208. System administration manager 212 provides a user interface via HTML and accepts commands including a command to add one or more IP addresses of such devices. System administration manager 212 stores the IP addresses in system administration storage 214. BGP processor 230 includes a conventional BGP processor, such as a process running the conventional GateD BGP processor commercially available from NextHop Technologies, Inc., of Mountain View, Calif. and exchanges conventional (I)BGP communications between itself and the routers having IP addresses in system administration storage 214 and may receive other communications such as (E)BGP messages. In one embodiment, the communications include topology information such as conventional (I)BGP peering messages. BGP processor 230 may either initiate or receive and respond to such messages for routers that have an IP address in system administration storage 214 as described above. BGP processor 230 establishes, or responds to requests for, (I)BGP sessions with each such device, and begins to exchange sync information. In one embodiment, BGP processor 230 provides outgoing (I)BGP peering messages to message director 232 for transmission. Message director 232 receives such (I)BGP peering messages from BGP processor 230 and routes them based on whether or not the destination IP address is a current peer. Messages to peers are provided via a flooding arrangement described in more detail below, and messages to non-peers are provided via a conventional TCP/IP connection with the non peer, in a manner similar to that used to send conventional (I)BGP messages by conventional routers. Message director 232 extracts the destination IP address from the header of each message, and searches for this address in current peer DB storage 224. If message director 232 does not find this IP address in current peer DB storage 224 (which would be the case if current peer DB storage 224 were empty or if the two devices had never exchanged peering messages), the message is treated as though it is intended for a non-peer: message director 232 transmits this message to TCP manager 220 and communications manager 210 to the non-peer. TCP manager 220 establishes a conventional TCP/IP connection with the non-peer if one is not already established and sends the sync message via the connection between TCP manager 220 and the non-peer. Had message director 232 found this IP address in current peer DB storage 226 then message director 232 would have forwarded the message to flood manager 222 as described below. In this case, no TCP/IP connection to the device would have been established or used. According to the (I)BGP specification, after providing a sync message, BGP processor 230 will receive a sync message from the other border router via TCP manager 220 and communications interface 210. This message will be provided via conventional TCP/IP techniques. Each sync message follows another message that includes an initial set of routes, and consists of paths, prefixes, and masks that describe to which IP addresses the other router or device has access, and cost information. The cost information may include the number of AS hops it takes to get to the IP address from the other border router. BGP processor 230 receives the sync message and the prior message from TCP manager 220, stores (I)BGP messages in BGP storage 240 and calculates routes in a conventional manner of a router or a route reflector. If the system 200 is part of a device acting as a route reflector, route information may be provided to non-border routers as described below. When the sync messages have been exchanged between (I)BGP processor and the other router, current peer manager 226 will send to the router from which the sync message was received a BST_PEER_SYNC message via TCP manager 220 and communications interface 210. In one embodiment, the determination of whether sync messages have been exchanged is made by BGP processor 230, which signals current peer manager 226. In another embodiment, current peer manager 226 monitors all communications to and from BGP processor 230 and watches for the exchange of sync messages. If the other router has the capabilities described below to accept and provide BGP messages such as (I)BGP messages via a flooding mechanism, that router will respond to the BST_PEER_SYNC message. If not, the other router will ignore the BST_PEER_SYNC message as it would another message that it does not understand. If the other border router replies with a (I)BGPS_PEER_SYNC of its own; if current peer manager 226 monitors such communications, it will receive the BST_PEER_SYNC message, and if not, BGP processor 230 will receive the message and signal current peer manager 226. In response to either type of event, current peer manager 226 marks the other border router as a BST peer by adding its IP address to a table in current peer DB storage 224 and signals BGP processor 230 to close the TCP/IP connection to the other border router it specifies in the signal. Current peer DB storage 224 is a table of IP addresses of peer (I)BGPS routers. In one embodiment current peer DB storage 224 is an in-memory table. In one embodiment current peer DB storage 224 is a conventional database such as MySQL or DB2. When BGP processor 230 receives this signal from current peer manager 226, it signals TCP manager 220 to close the TCP/IP connection with the other border router specified by current peer manager 226 and, if a TCP/IP connection is not already open between BGP processor 230 and header manager 228, BGP processor 230 opens a connection to header manager 228. The procedure described herein will be repeated for the other routers in the list of routers in system administration storage 214. When current peer manager 226 enters the IP address of the other border router into current peer database storage 224, the other border router has established itself as a peer with system 200, and otherwise, the border router may remain as a non-peer. If sync messages are exchanged at a future time, for example, after communications are interrupted and reestablished, the process of identifying whether the other router is a peer, and if so, establishing it as a peer, will take place. At any time after sync messages are exchanged, BGP processor 230 may desire to send (I)BGP maintenance messages to the other border routers. BGP processor 230 originates this message in accordance with the conventional (I)BGP protocol, and sends one such message for each TCP/IP connection it has open. As described above, in one embodiment, those routers that are not listed as current peers have their own TCP/IP connections. (I)BGP messages sent over these connections by BGP processor 230 are forwarded via the TCP/IP connection with that peer. Messages sent via the TCP/IP connection to header manager 228 have their TCP/IP headers removed by header manager 228 and the remainder of the message is sent to flood manager 222. In the above description, BGP processor 230 may be a conventional route processor such as would be found in a route reflector, but modified as described herein. For example, as described above, BGP processor 230 may signal current peer manager 226 when both sync messages have been received, may close the TCP/IP connection when signaled by current peer manager as described above, and may send update messages for each TCP/IP connection as described above, instead of sending one message per other router with which it has exchanged sync messages as described above. However, if it is not possible or undesirable to modify BGP processor 230 as described herein, instead of setting up a TCP/IP connection between BGP processor 230 and header manager 228 and setting up a TCP/IP connection with non-peer routers, one TCP/IP connection may be arranged for each other router in the list of routers in system administration storage 214. All such TCP/IP connections are passed through message director 232 in the manner of a buffer. Current peer manager 226 monitors the connections as described above, and after a router is added to the list of current peers as described above, current peer manager 226 signals TCP manager 220 to terminate the TCP/IP connection, and signals message director 232, which simulates the appearance to BGP processor 230 that the TCP/IP connection remains open. TCP/IP connections with non peers actually remain open, though they continue to pass through message director 232. When a TCP/IP message arrives from BGP processor 230, message director 232 compares the destination IP address in the message (or uses the connection over which the message is being sent to identify the destination IP address and compares this IP address) with the list of current peers in current peer database storage 224. If the destination address is not on the list of current peers, message director 232 passes the message via TCP manager 220 and communication interface 210 to the other router using the TCP/IP connection with the router corresponding to that destination address. If the destination address is on the list of current peers, message director 232 passes the message to header manager 228. Header manager 228 removes the TCP/IP header from messages it receives and provides the message to message manager 250. Message manager 250 compares the contents of the message to the contents of other messages received from flood manager 222 it has recently stored. If the contents of the message do not match the contents of such a message recently stored in message storage 252 (which may be conventional memory or disk storage, and may include a database, such as any of those described herein) message manager 250 stores the message in message storage 252 and provides the message to flood manager 222 and flood manager 222 adds a common header to the message and provides the message to its neighbor routers as described above. If the contents of the message match the contents of a message stored in message storage 252, message manager 250 does not provide the message to flood manager 222, and so the message is not provided by flood manager 222. This procedure can prevent messages having identical contents that are intended for different routers from being flooded more than once in response to those messages and may be used in the embodiment in which BGP processor 230 uses one connection per device with which it communicates. In one embodiment, flood manager 222 adds a header to messages it provides as described herein using a specific format, although other formats may be used by the present invention. Part of this reformatting may include building a header or otherwise encapsulating the message to correspond to the requirements of the transport protocol used, such as SCTP. It is noted that although SCTP is used as a transport for flooding messages in one embodiment, other embodiments may use other protocols, such as UDP. If UDP is used, the rate of outgoing messages may be limited by communication interface 210. In one embodiment, flood manager 222 builds and appends to each message it sends a common header, shown in FIG. 3. Referring momentarily to FIGS. 2 and 3, the common header 300 contains an eight bit type field 310, followed by an eight bit set of flags 312, which is followed by a sixteen bit length field 314 specifying the length of the entire message, including the header. Following the length field 314, a thirty two bit source identifier 316, which unless otherwise specified is the IP address of the device that originally sent the message, is provided. In one embodiment, the type field 310 specifies the type of the message, with a type of 0 specifying the message contains data, 1 specifying the message contains a repair request, 2 specifying the message contains database status, 3 specifying the message reporting one or more peers are down, and 4 specifying the message contains database synchronization information, each of which will now be described. Referring again to FIG. 2, flood manager 222 adds a common header described below to all content it receives and sends them via conventional flooding techniques so that they may be received by all routers capable of receiving the flood messages. Conventional flood techniques may include transmitting the message to all of the “neighbor routers” of the system 210. As used herein, a “neighbor router” is a router to which communication interface 210 is directly connected. An other router is directly connected to communication interface 210 if communication to that router need not pass through any other router to reach the neighbor router. Referring momentarily to FIG. 4, showing a network of routers A–H, routers G, H and B are the only neighbor routers of router A. Referring again to FIG. 2, in one embodiment, input/output 208 contains more than one physical input/outputs, each connected to a neighbor router. If desired, communication interface 210 is made up of several conventional physical communication interfaces, each meeting some or all of the criteria for communication interface 210 described above. In one embodiment, when header manager 228 removes a header as described above, the result is the “content” of a data message. Flood manager 222 builds a common header with a type equal to zero and adds a thirty two bit sequence number following the common header and appends the data following the sequence number to build a data message. In one embodiment, the data comprises the content of one or more conventional (I)BGP messages and may be received from BGP processor 230 or otherwise as described herein. The sequence number is a number that is incremented by the number of bytes in the message for each message that has a source identifier corresponding to system 200. Flood manager 222 maintains a counter of each such message it sends, adds the number of bytes in the message to the counter and includes the value of the counter as the sequence number. In one embodiment, to flood a message, flood manager 222 builds one message for each neighbor device with each such message being otherwise identical except for the address of the neighbor device and provides the messages to communication interface 210. Communication interface 210 handles congestion control and avoidance, and adds protocol specific headers, corresponding to the protocol used, e.g. SCTP. The addresses to use for each of the neighbor devices may be configured via system administration manager 212 and stored in system administration storage 214 or may be discovered by communication interface 210 and stored in system administration storage 214. Flood manager 222 uses these addresses in system administration storage 214 to generate the messages. Each other router to which messages are flooded contains some or all of the elements of system 200. Any of those other routers, having received a data message from system 200, or system 200, having received a data message from any of its neighbor routers, process data messages as will now be described. Communications interface 210 passes all flood messages received from other devices to flood manager 222. Flood manager 222 receives the message and examines it. If the message has the same source identifier as system 200, such source identifier being stored by a system administrator in system administration storage 214 using system administration manager 212 in a manner similar to that described above, flood manager 222 ignores the message. Otherwise, flood manager 222 provides the message to message manager 250. Message manager 250 compares the source identifier and sequence number of the message with other messages stored in message storage 252 having the same source identifier as the message it receives. If the message matches a message stored in message storage, message manager 250 so indicates to flood manager 222, which discards the message. In one embodiment, if a special flag is set in the common header of the message, even if the message is stored in message storage 252, message manager 250 will treat the message as not matching a message stored in message storage 252 as described below. If the message does not match a message stored in message storage 252, message manager 250 stores the message in message storage 252 and indicates to flood manager 222 that the message was not previously stored in message storage 252. In this case, flood manager 222 floods the message by providing via communication interface 210 the message to other neighbor routers other than the neighbor router from which the message was received as described above, provides it to header manager 228, which removes the common header and sequence number, reformats the message as a TCP/IP message and provides it to BGP processor 230 via the TCP/IP connection it has with BGP processor 230 or provides it to message director 232 which provides it via the simulated connection corresponding to the source identifier of the message it has with BGP processor 230. BGP processor 230 processes the message in a conventional manner, such as that which would be performed by a conventional route reflector. In one embodiment, these forwarding functions are performed as a background task. In one embodiment, message manager 250 stores the last “n” messages it has received; in such embodiment “n” is 200 or any other number higher or lower than 200. In the embodiment in which n is 200, when message manager 250 receives its 201st message, message manager 250 overwrites the oldest message in message storage 252. In one embodiment message manager 250 examines message storage 252 whenever a new message is received, and deletes from message storage 252 any old messages having the same source identifier and advertising a different route to the same destination as in the new message. This way, message storage 252 is made more efficient in that prior messages advertising out of date routes do not remain in message storage, thereby preventing older, but still up to date messages from being pushed out of message storage 252. As message manager 250 receives data messages from other sources, it stores them in message storage 252 as described above. As it stores them, it compares the sequence number of the message less the number of bytes in the message with the highest sequence number of any prior message it received from the same source. If there is a gap in the sequence numbers, a message is missing. In this case, message manager 250 sends to repair request generator 254 the range of missing sequence numbers and the source identifier of the device from which the messages corresponding to the gap should have been received. Repair request generator 254 builds the contents of a repair request message, to which flood manager 222 can add the common header to build a message to be sent to all of its neighbors. The contents of a repair request message includes a thirty two bit source identifier of the device from which the missing messages should have been sourced, followed by a sixteen bit number of gaps the sender is trying to fill (which could be more than one if, for example, only intermittent messages from a source are received before the gaps are filled), followed by sixteen bits of unused zeros or ones, followed by, for each gap, a thirty two bit starting sequence number of the gap and a thirty two bit ending sequence number of the gap until all of the gaps are so specified. Repair request generator 254 internally stores the contents of the message and also provides it to flood manager 222, which builds a common header as described above, appends the contents to it, and floods the message to its neighbors. Because the message is received from repair request generator, flood manager 222 uses a type of “1” in the common header. Before performing the actions described above, repair request generator 254 checks its internal storage prior to building the message contents. If another set of contents previously generated for the same source identifier is internally stored by repair request generator 254, it increments the number of gaps stored in the request, appends the beginning and ending sequence number of the gap it receives from message manager 250 to the set of contents in order to build a new content for a new message, which it uses to replace the old content of that message. If the new gap would be contiguous to the last gap in the content, instead of incrementing the number of gaps and adding the beginning and ending sequence numbers of the gap, repair request generator 254 replaces the ending sequence number of the gap with the one it receives. Repair request generator 254 sends the new content to flood manager 222, which builds a common header, appends the content to it and sends the common header and content as a message to its neighbors. In one embodiment, a repair request period is established by a system administrator using system administration manager 212 and stored in system administration storage 214 in a manner similar to other information stored there as described above. Repair request generator 254 sends only one content to flood manager 222 to be sent to neighbors during any repair request period. Any others are queued until a following request period using conventional techniques. If no response is received to a repair request message, repair request generator 254 may resend the identical contents to flood manager 222 to be sent out as another repair request message to its neighbor. When a repair request is received, flood manager 222, in response to identifying the type of message as “1”, routes the contents of the message and the source identifier of the sender of the repair response message to repair response manager 256. Repair response manager 256 checks message storage 252 for messages with sequence numbers from the source specified in the repair response message. If the repair request cannot be fulfilled from the messages in message storage 252, repair response manager 256 internally stores the request and sends the highest sequence number of the repair request and the source identifier of the device from which the messages are being requested in the repair request message to message manager 250. Message manager 250 then identifies the highest sequence number stored in message storage 252 from the source it receives, and compares it to the highest sequence number it receives from repair response manager 256. If the sequence numbers are different, message manager 250 adds one to the highest sequence number for that source stored in message storage 252, and provides that sequence number, the source identifier of the device from which the missing messages should have been received, and the highest sequence number received from repair response manager 256 to repair request generator 254, which incorporates the missing sequence numbers into a content of a new or existing repair request message as described above and sends it to flood manager 222 as described above. When a repair response message, generated as described below, is received by flood manager 222, it provides it to message manager 250 in response to the type identifier in the message having a value of 0. Each repair response message contains the source identifier of the originator of the messages corresponding to the messages contained in the repair response message, as well as the message requested, exactly as it was originally sent. If the message is already in message storage 252, message manager 250 discards the message. Otherwise, message manager 250 adds the messages in the repair response message to message storage 250, as if the messages had arrived in a data message from the source corresponding to the messages. The originator of the messages in a repair response message is the source identifier of the device that originally sent the messages via its own flood manager 222. Periodically repair request generator 254 checks to see whether any or all of the messages corresponding to the repair request are stored in message storage 252. If all of the messages corresponding to the repair request are stored in message storage 252, repair request generator 254 discards the repair request. If some, but not all of the gaps have been filled, repair request generator 254 builds a new content for a repair request that omits the gaps or portions of the gaps that have been filled and alters the number of gaps accordingly. Repair response manager 256 periodically verifies whether it can fulfill the request it internally stored using the messages in message storage 252 and if so, for each message requested, builds its own repair response message (which is identical to the original message), provides the repair response message to flood manager 222 and maintains a list of the sequence identifiers of the repair response messages it has provided that correspond to the request. The repair response message includes the message source identifier of originator of the message, which may be different from the sender of the repair response message, the sequence number of the original message, and the message itself. The type of the message is 0, making the message appear as though it is being flooded from the originator of the message. Flood manager 222 does not add the common header to the content of the repair response message in response to it being received from repair response manager 256. Flood manager 222 floods the repair response message to the neighbors of system 200. Subsequent repair response messages may be received from other neighbor devices. In one embodiment, the contents of a repair response message are checked against the messages in message storage 252 prior to their storage by message manager 250 as described above. In such embodiment, if the messages in a repair response message are already in message storage 252, message manager 250 ignores the repair response message and takes no further action. In one embodiment, repair request generator 254 timestamps all repair requests when it initially generates them, and if some or all of the gaps are removed from the request as described above, it updates the timestamp. Periodically, the timestamps are compared against the current time. If the difference between the timestamp and the current time is greater than a threshold (which may be provided by a system administrator using system administration manager 212 and stored in system administration storage 214) repair request generator 254 removes the request it stores and signals current peer manager 226 with the source identifier of the device. Current peer manager 226 removes the source identifier from the list of current peers in current peer database storage 224 and either sends, or signals BGP processor 230 to send (for example, by informing BGP processor 230 that synchronization has been lost), another sync request, and the process of establishing the other device as a current peer follows as described above. In one embodiment, status messages are periodically sent by system 200 to its neighbors. Database status generator 260 periodically checks the messages in database storage 252 and builds the contents of a database status message. The contents includes the number of source identifiers from which messages are stored in message storage 252 and for each such source identifier, the source identifier and the highest sequence number of the messages stored in message storage 252 for that source identifier. Database status generator 260 provides the contents of the message to flood manager 222, which adds a common header to the message, including a type value of 2 in response to receipt of the content from database status generator 260. When flood manager 222 receives such a message, flood manager passes the message to message manager 250 and passes the source identifier to peer down manager 262 in response to the type value of 2. Message manager 250 then compares the highest sequence numbers for each source identifier with the highest sequence numbers for the corresponding sources of messages stored in message storage 252. If the highest sequence number for a source identifier stored in message storage 252 is lower than the corresponding sequence number in the database status message, message manager 252 treats the difference as a gap and attempts to have it filled as described above. Peer down manager 262 maintains in current peer database storage 224 the date and time of the most recent status message received from each of the current peers. Each time it is signaled by flood manager 222, peer down manager 262 updates the date and time in the entry in current peer database storage 224 corresponding to the source identifier received from flood manager 222. Periodically, peer down manager 262 compares the current date and time to each of the dates and times in the entries in current peer database storage 224. If the difference exceeds a threshold, peer down manager 262 treats the peer as down. If communication interface 210 receives an indication that a neighbor is down (e.g. an SCTP indication that the connection has been dropped), it will signal peer down manager 262 with the identifier of the neighbor. In this case, peer down manager 262 will also treat the peer as down. To treat a peer as down, peer down manager 262 either signals message director 232 to terminate the TCP/IP connection between message director 232 and BGP processor 230, or removes the peer from current peer database storage 224. Peer down manager 262 also purges the entries in message storage 252 for that peer and signals BGP processor 230 to terminate the peer and establish synchronization (which will cause the peer status to be reattempted as well) with the peer as described above. In addition, peer down manager 262 adds the identifier to the contents of a peer down message and increments a number of source identifiers in the contents of the message, internally stores it, and provides it to flood manager 222 for flooding to neighbor devices. In one embodiment, the content of a peer down message contains a 32 bit number of source identifiers of peers that are being identified as down, followed by the identifiers of each peer identified as down. When a peer is established as described above, current peer manager 226 provides the identifier of the peer to peer down manager 262, which removes the peer from the content it stores and decrements the number of source identifiers in the content it stores. If the number of source identifiers is greater than zero, peer down manager periodically provides the contents of the message to flood manager 222. The period may be set via a system administrator using system administration manager 212, which stores the period in system administration storage 214 as described above. Flood manager 222 appends the common header to the content, with a type of 3 in response to the contents being received from peer down manager 262, and floods the peer down message to all of the neighbor devices not identified in the peer down message. The flood managers 222 in the neighbor devices will flood the peer down message to all of their neighbors (other than the neighbor from which the message was received), and suppress duplicates subsequently received, all as described above. In one embodiment, when a peer is down, the peer is not removed from the list of peers in current peer database storage 224 as described above. Instead, it is marked as removed by peer down manager 262. Instead of resending the a sync message, an interest message is sent to the downed peer. An interest message indicates that one device is interested in receiving the information that would normally be included as a sync message. The sync message may be intercepted by message director 232 and the message is provided to interest manager 270. Interest manager 270 may then provide an indication that it is interested in receiving synchronization from the device by providing as a content the sync message to flood manager 222. Flood manager 222 appends the common header to the message with a type of 5 and floods the message to its neighbors. Messages received by flood managers 222 in the neighbor devices compare the destination identifier of the device to their own identifier (which may be stored in system administration storage 214 via system administration manager 212 as described above) and if the identifiers do not match, that flood manager 222 will provide the message to message manager 250 to determine if the message has been previously received. If so, the message is suppressed, and if not, message manager 250 adds it to message storage 252 and signals flood manager 222, which floods the message to its neighbors other than the neighbor from which the message was received. If the destination identifier matches the device's own identifier, the device is the device for which the interest message was intended, so flood manager 222 passes the message to interest response manager 272. Interest response manager 272 waits a configurable period of time and selects each message that it receives, and provides the content to message director 232, which provides the contents of the message (e.g. the sync message) to BGP processor 230 on a simulated TCP/IP connection with the device, as if it were received as described above or via the single TCP/IP connection to BGP processor 230 used for flood messages. Message director 232 receives the sync messages provided by BGP processor 230 in response to these sync messages and provides them to interest response manager 272, which sends the first one as the content of a data message to flood manager 222, which appends the common header (with a type of 5 in one embodiment) and floods it as described above. Subsequent responses made by BGP processor 230 to the messages it collected while waiting and provides as described above are suppressed by interest response manager 272. When a flood manager 222 in another device receives such a data message from communication interface 210, it provides it to message manager 228, which checks to see if the source identifier is marked in current peer database storage as being down. If so, instead of providing the message to message director as described above, it provides it to interest manager 270, which provides it to message director 232, which provides it to BGP processor 230 over the TCP/IP connection for the device or to the TCP/IP connection between BGP processor 230 and header manager 228. Interest manager 270 then unmarks the peer as down in current peer database storage 224. A system containing elements similar to system 200 may be used to process (E)BGP messages in a fault-tolerant manner that provides load balancing across multiple route processors in one embodiment. Referring now to FIG. 5, a network of border routers, a pool selector and nodes of pools of route processors is shown according to one embodiment of the present invention. Border routers 510A–E are conventional border routers running the conventional (E)BGP protocol. Border routers 510A–E may be in one AS or many autonomous systems, each such AS being different from an AS in which pool selector 512 and nodes 520–538 operate. Border routers 510A–E communicate with pool selector 512, which simulates to each such border router 510A–E the operation of another border router. Such operation includes responding to sync messages and the like. In one embodiment, nodes 520–538 perform conventional route processing functions in addition to the functions described herein. Route processing functions include assembling route processing information from all available sources and identifying at least a portion of a least cost path over which communications can be forwarded, or identifying any portion of the information useful in doing so. Each node 520–538 is assigned to one of several pools of nodes. In FIG. 5, nodes 520–526 are assigned to one pool and nodes 530–538 are assigned to a different pool. The number of nodes 520–538 and pools and nodes 520–538 per pool may be any number, not just the specific number shown, and each pool may have a different number of nodes 520–236 from the other pools. The number of pool selectors 512 may also be greater than one, with border routers assigned to one or more pool selectors 512. If a border router 510A–E is assigned to more than one pool selector 512, the router may anycast the BGP information to each such pool selector 512. FIG. 6 shows a pool selector 512 according to one embodiment of the present invention. Referring now to FIGS. 5 and 6, nodes 520–538 establish contact with BGP handler 630 in the same manner that the other devices established contact with BGP processor 230 as described above. Peer status is automatically established by current peer manager 226 when communication interface 610 reports a valid connection (e.g. via SCTP), and the peer status is stored in current peer database storage 224 as described above. Border routers 510A–E communicate with pool selector 512 using the conventional (E)BGP protocol. A system administrator configures the IP addresses of the border routers 510A–E with which pool selector 512 is to communicate using system administration manager 612 as described above, and system administration manager 612 stores these addresses in system administration storage 614. System administration manager 612 and system administration storage 614 operate in a similar manner to system administration manager 212 and system administration storage 214. Each border router 510A–E communicates sync messages between itself and BGP handler 630 via individual TCP/IP connections between input/output 608 of communication interface 610, which are similar to input/output 208 and communication interface 210 described above. Subsequent communications are made between each border router 510A–E and BGP handler 630 via this same TCP/IP connection. Unlike BGP processor 230, when sync is established with border routers 510A–E, no attempt is made to establish the border routers 510A–E as current peers nor are the individual TCP/IP sessions to the route processors 510A–E dropped. BGP handler 630 also makes no attempt to process routes received in any message from border routers 510A–E. BGP handler 630 provides copies of all messages it receives from border routers 510A–E as the content of a data message to pool assignment manager 680. In one embodiment, the TCP/IP header received with the content is left as part of the message content, and so header manager 228 is not used, although it can be used in other embodiments to reformat the TCP/IP header into the content of the message. Pool assignment manager 680 optionally provides the content to encryption manager 682, which encrypts the content and provides it back to pool assignment manager 680. Pool assignment manager 680 selects one of the pools to which subsequent communications from the border router 510A–E from which the message was received will also be assigned. The assignment may be made in response to pool assignments received with the IP addresses of the border routers 510A–E stored in configuration storage 614 as described above, or may be performed by balancing the number of assignments with an equal number assigned to each pool, a number assigned to each pool in proportion with the number of nodes 520–538 in the pool, or using any other conventional allocation technique. Pool assignment manager 680 internally maintains a table of assignments of border routers 510A–E to pools so that subsequent messages may be assigned to the same pool, although other embodiments dynamically allocate route processors to pools and stores the allocation in the table. Pool assignment manager 680 provides the content or encrypted content and an identifier of the pool to which it assigned the message to flood manager 622. Flood manager 622 operates in a manner similarly to flood manager 222 except as noted herein. One difference in operation is that flood manager 622 provides data messages it receives with a unique type identifier that identifies the data message as a message that should be flooded by flood managers 722 described below only within the pool, and not to interfaces coupled to routers outside of the pool corresponding to the interface on which the message is received. In addition, flood manager 622 itself floods the message not to all of its neighbor routers, but only to neighbor routers assigned to the pool in system administration storage 614 corresponding to the identifier it receives with the content. If communications with a border router 510A–E are interrupted (either because messages have not been received from the border router for a certain period of time or communication interface 610 reports to BGP handler 630 that the connection is lost), BGP handler 630 reports the TP address of
{'bibliographic_information': "{'country': 'US', 'doc-number': '10317582', 'kind': 'B1', 'date': '20021212', 'extension': '778', 'invention_title': 'System and method for secure communication of routing messages'}", 'source_file': './grant/2006/ipg061010.xml', 'source_data': 'USPTO-Grant'}