Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing
Reexamination Certificate
1999-05-27
2003-04-22
Dinh, Dung C. (Department: 2172)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
C709S238000, C370S401000
Reexamination Certificate
active
06553423
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to computer networks, and more particularly, to routing protocols in a computer network.
BACKGROUND OF THE INVENTION
A computer network is a geographically distributed collection of interconnected communication links for transporting data between nodes, such as computers. Many types of computer networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). The nodes typically communicate by exchanging discrete frames or packets of data according to pre-defined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules defining how the nodes interact with each other. The TCP/IP architecture is well-known and described in
Computer Networks,
3
rd Edition,
by Andrew S. Tanenbaum, published by Prentice-Hall (1996).
Computer networks may be further interconnected by an intermediate node, such as a router, to extend the effective “size” of each network. Since management of a large system of interconnected computer networks can prove burdensome, smaller groups of computer networks may be maintained as autonomous systems or routing domains. The networks within a routing domain are typically coupled together by conventional “intra-domain” routers. Yet is still may be desirable to increase the number of nodes capable of exchanging data; in this case, interdomain routers executing interdomain routing protocols are used to interconnect nodes of the various autonomous systems.
An example of an interdomain routing protocol is the Border Gateway Protocol (BGP-4) which performs routing between autonomous systems by exchanging routing and reachability information among neighboring interdomain routers of the systems. The BGP-4 routing protocol is well-known and described in detail in
Request For Comments
(
RFC
) 1771, by Y. Rekhter and T. Li (1995),
Internet Draft<draft
-
ietf
-
idr
-
bgp
4-08.
txt
>titled,
A Border Gateway Protocol
4 (
BGP
-4) by Y. Rekhter and T. Li (August 1998) and
Interconnections, Bridges and Routers,
by R. Perlman, published by Addison Wesley Publishing Company, at pages 323-329 (1992), all disclosures of which are hereby incorporated by reference.
The interdomain routers configured to execute the BGP-4 protocol, referred to herein as BGP routers, perform various routing functions including transmission of routing messages. Before transmitting such messages, however, the BGP neighbors cooperate to establish a logical “peer” connection (session) between the routers. BGP-4 generally operates over a reliable transport protocol, such as TCP, to establish a TCP connection. Specifically, a TCP process executing on each neighboring peer router establishes the TCP connection in accordance with a conventional “3-way handshake” arrangement involving the exchange of TCP packet or segment data structures. The TCP protocol and establishment of a TCP connection are described in
Computer Networks,
3
rd Edition,
particularly at pgs. 521-542.
FIG. 1
is a schematic block diagram of the format of a TCP segment
100
which includes a source port field
102
containing a 16-bit source port number and a destination port field
104
containing a 16-bit destination port number. The BGP-4 protocol preferably uses TCP port number
179
to establish a TCP connection; the source port number is used by a receiving peer router (i.e., a BGP receiver) to reply to a TCP segment issued by a sending peer router (i.e., a BGP sender). A sequence number field
106
contains a sequence number of a first data byte in the segment and an acknowledgment number field
108
contains a value indicating the next sequence number that the receiver expects to receive. Note that the value contained in field
108
is valid only when an acknowledgment control bit (ACK
110
) is asserted. In addition to the ACK bit
110
, the TCP segment
100
includes other control bits such as a finish bit (FIN
112
) denoting the end of data transmitted from the sender. Termination (closing) of the TCP connection is done implicitly by sending a TCP segment with an asserted FIN bit
112
.
Once the TCP connection is established, the neighboring peer routers exchange messages to open and confirm various parameters associated with the connection. For example, a first message exchanged by the routers is an OPEN message which opens a BGP communication session between the peers. The OPEN message is thereafter confirmed by a KEEPALIVE message issued by a BGP router to notify its neighboring peer router that it is “alive” and active. The OPEN message data structure is essentially a means for the routers to identify themselves at the beginning of the neighboring peer relationship. The formats and functions of the KEEPALIVE and OPEN messages, the latter including the optional parameter field, are described in
RFC
1771 and
Internet Draft <draft
-
ietf
-
idr
-
bgp
4-08.
txt>.
FIG. 2
is a schematic block diagram of the format of an OPEN message
200
which includes a fixed-size BGP header
210
prepended to various message fields. The OPEN message fields comprise a version field
212
containing a BGP version number, an autonomous system field
214
containing the autonomous system number of the sender, a BGP identifier field
216
containing a BGP identifier (e.g., an IP address) of the sender and an optional parameters field
300
containing a list of optional parameters (if any).
FIG. 3
is a schematic block diagram of the format of the optional parameters field
300
comprising a type subfield
302
, a length subfield
304
and a variable-length value subfield
306
. An example of an optional parameter is a capabilities parameter used to introduce new features that are supported by a BGP router.
In general, each interdomain (BGP) router has certain routing capabilities that may be related to its operation, including the types of messages it is able to process. Such capabilities are announced when the router establishes a peer relationship via a TCP connection with a neighboring BGP router. For example, a BGP sender may announce its ability to support address families such as IPv4 unicast and multicast messages through the use of the capabilities optional parameters in the OPEN message
200
. The BGP receiver of the OPEN message is thus informed that it is safe to exchange messages related to IPv4 unicast and IPv4 multicast address families with the sender.
However in order to enable a new capability, or revise or remove an announced capability, the established TCP connection between the neighboring peer routers must be reset (i.e., closed and reopened) thereby disrupting existing services and operations of the routers. For example after the OPEN and KEEPALIVE messages are exchanged between the peer routers, an initial data flow involves the transmission of an entire BGP routing table between the routers. Closing and reopening of the TCP connection results in a loss of connectivity between the routers which, in turn, may require the retransmission of the contents of the routing table.
Therefore, it is an object of the present invention to provide an improved method for routing protocols in which a non-disruptive update of routing capabilities can be performed.
SUMMARY OF THE INVENTION
The present invention comprises a technique for dynamically exchanging or updating routing capabilities between neighboring peer routers in a computer network without disruption to the operation of the routers. According to the invention, a new dynamic capability parameter is provided that enables a router to announce a new capability, or revise or remove a previously announced capability, to a neighboring router when a peer connection is established between the routers. Once announced, the dynamic capability parameter facilitates graceful capability changes between neighboring routers by allowing the routers to exchange a novel capability message. In the illustrative embodiment, the capability message includes, inter alia, a capability action code that has the
Cesari and McKenna LLP
Cisco Technology Inc.
Dinh Dung C.
Woo Isaac
LandOfFree
Method and apparatus for dynamic exchange of capabilities... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for dynamic exchange of capabilities..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for dynamic exchange of capabilities... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3035118