Patent Abstract:
The invention provides a method and system for sending and receiving end-to-end bidirectional keep-alive messages using virtual circuits. Nodes coupled to a network, such as a frame relay network, periodically exchange link-layer “keep-alive” messages which indicate information regarding configuration and status of the virtual circuit, as well as information regarding congestion at sending nodes. Nodes respond to received keep-alive messages, or to timed-out failure to receive keep-alive messages, with follow-on actions, such as attempting to reconnect when a virtual circuit fails. Keep-alive messages may be propagated across multiple networks of either similar or different architecture. Keep-alive messages include sent and received sequence numbers, thus providing receiving nodes with a technique for determining if any keep-alive messages have been lost. Keep-alive messages can also include information regarding configuration of the virtual circuit, status of the virtual circuit (including counts of recent keep-alive message failure or success), and congestion at the sending node.

Full Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates to end-to-end bidirectional keep-alive techniques using virtual circuits. 
     2. Description of Related Art 
     In frame relay networks and some other networking techniques, communication between nodes uses virtual circuits, either permanent virtual circuits (PVCs) or switched virtual circuits (SVCs) 
     One problem which has arisen in the art is determining whether particular virtual circuits are still operational, or have failed due to one or more communication links in the virtual circuit having failed. Frame relay networks usually include a local management interface (LMI), a management technique for local communication links between nodes and the network. However, information provided by the LMI is limited to the communication links directly between routers and the frame relay network, and does not generally allow nodes to determine if a virtual circuit with a remote node has failed at an intermediate communication link in the frame relay network. Moreover, information provided by the LMI is sometimes unreliable with regard to status of remote links to the frame relay network. 
     Another problem which has arisen in the art is that of determining congestion for virtual circuits for which communication is primarily unidirectional. For example, multicast video sessions includes a great deal of data which is originated at a single source and transmitted to essentially passive receivers. In frame relay networks, header information in frames provides information regarding congestion within the frame relay network. However, passive receivers generate frames at most infrequently, and thus have little or no opportunity to cause information regarding congestion to be transmitted back to the source in a multicast video session. 
     Known methods exist, at higher-level protocol layers, for responding to broken or congested network communication, including virtual circuits. However, these known methods operate at higher-level protocol layers, such as an application (level 3) protocol layer in the OSI protocol layer model, and thus can take substantially more time and more resources to respond to a broken virtual circuit than may be desirable, particularly for band-width-intensive applications such as multicast video. 
     Known methods exist for management of aggregates of virtual circuits. For example, one such method is described in Annex D of specification document T1.617, in Annex A of the specification document ITU Q.933, and in the LMI frame relay specification document. However, this method is operative only for aggregates of virtual circuits, and is not effective for determining if an individual virtual circuit is broken, congested, or otherwise requires remedial action at an intermediate point in the frame relay network. 
     Accordingly, it would be advantageous to provide techniques for determining whether particular virtual circuits are end-to-end operational, as well as techniques for determining information regarding congestion at nodes which generate infrequent frames. These advantages are achieved by a method and system according to the present invention in which a virtual circuit protocol provides for end-to-end bidirectional keep-alive messages using virtual circuits. 
     SUMMARY OF THE INVENTION 
     The invention provides a method and system for sending and receiving end-to-end bidirectional keep-alive messages using virtual circuits. Nodes coupled to a network, such as a frame relay network, periodically exchange data link-layer “keep-alive” messages which indicate information regarding configuration and status of the virtual circuit, as well as information regarding congestion at sending nodes. Nodes respond to received keep-alive messages, or to timed-out failure to receive keep-alive messages, with follow-on actions, such as attempting to reconnect when a virtual circuit fails. Keep-alive messages can be propagated across multiple networks of either similar or different architecture. 
     In a preferred embodiment, keep-alive messages include sent and received sequence numbers, thus providing receiving nodes with a technique for determining if any keep-alive messages have been lost. Keep-alive messages can also include information regarding configuration of the virtual circuit and congestion at the sending node. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 shows a block diagram of a system including end-to-end keep-alive messages. 
     FIG. 2 shows a flowchart of a protocol for using end-to-end keep-alive messages. 
     FIG. 3 shows a block diagram of an end-to-end keep-alive message in a frame relay network. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT 
     In the following description, a preferred embodiment of the invention is described with regard to preferred process steps, data structures, and protocols. Those skilled in the art would recognize, after perusal of this application, that embodiments of the invention may be implemented using a computer at each site operating under program control, and that modification of a set of computers to implement the process steps, data structures, and protocols described herein would not require undue invention. 
     System Including End-to-end Keep-alive Messages 
     FIG. 1 shows a block diagram of a system including end-to-end keep-alive messages. 
     A first node  110  is coupled using a first local communication link  111  to a first local router  112  in a frame relay network  120 . Similarly, a second node  130  is coupled using a second local communication link  131  to a second local router  132  in the frame relay network  120 . Communication between the first node  110  and the second node  130  is conducted using a virtual circuit  140 , including the first local communication link  111 , the second local communication link  131 , and a communication path  141  in the frame relay network  120 . 
     The first local communication link  111  is controlled using a first local management interface (LMI)  161  between the first node  110  and the first local router  112 . Similarly, the second local communication link  131  is controlled using a second local management interface (LMI)  163  between the second node  130  and the second local router  132 . Communication occurs in the frame relay network  120  using a set of communication links (not shown) between the first local router  112  and the second local router  132 ; note that the first local router  112  and the second local router  1132  may happen to be the same device, or may be coupled by a large number of separate devices and separate communication links. 
     When the virtual circuit  140  is established in the frame relay network  120  between the first node  110  and the second node  130 , it is assigned an associated unique data link connection identifier (DLCI). Frames which are transmitted using the frame relay network  120  include a header; the header includes the DLCI, thus identifying frames being transmitted using the associated virtual circuit  140 . 
     The first node  110  includes a keep-alive send side  113 , disposed for sending keep-alive messages  150  to the second node  130 ; the second node  130  includes a corresponding keep-alive receive side  134 , disposed for receiving keep-alive messages  150  from the first node  110 . Similarly, the second node  130  includes a keep-alive send side  133 , disposed for sending keep-alive messages  150  to the first node  110 ; the first node  110  includes a corresponding keep-alive receive side  114 , disposed for receiving keep-alive messages  150  from the second node  130 . 
     Protocol for Using End-to-end Keep-alive Messages 
     FIG. 2 shows a flowchart of a protocol for using end-to-end keep-alive messages. 
     A method  200  for using end-to-end keep-alive messages includes a sequence of steps to be executed by the first node  110  in cooperation with the second node  130 . 
     At a flow point  210 , the first node  110  and the second node  130  have each been coupled to the frame relay network  120 . 
     At a step  211 , the first node  110  and the second node  130  are configured for the end-to-end keep-alive technique. As part of this step, the first node  110  and the second node  130  are configured to assign values to a set of timeout intervals. A first timeout interval determines a duration to be waited by the keep-alive send side  113  or the keep-alive send side  133  before sending a keep-alive REQUEST message  231 . A second timeout interval determines a duration to be waited by the keep-alive send side  113  or the keep-alive send side  133  before triggering a timeout for the keep-alive REPLY message  232 . 
     In a preferred embodiment, the first timeout interval and the second timeout interval have the same duration. 
     In a preferred embodiment, the first timeout interval and the second timeout interval are preselected by an operator at the first node  110  when the first node  110  is coupled to the frame relay network  120 . Similarly, the first timeout interval and the second timeout interval are preselected by an operator at the second node  130  when the second node  130  is coupled to the frame relay network  120 . In a preferred embodiment, the first timeout interval is about 10 seconds, and the second timeout interval is about 15 seconds. 
     At a flow point  220 , the first node  110  and the second node  130  have been coupled using a virtual circuit  140 , and the keep-alive send side  113  or the keep-alive send side  133  are disposed for activity. 
     At a step  221 , the keep-alive send side  113  at the first node  110  sets its REQUEST timer to the first timeout interval. Similarly, the keep-alive send side  133  at the second node  130  sets its own REQUEST timer to the first timeout interval. 
     At a step  222 , a timeout occurs for the first timeout interval at the keep-alive send side  113  at the first node  110 . The keep-alive send side  113  generates a keep-alive REQUEST message  231  and transmits the keep-alive REQUEST message  231  to the keep-alive receive side  134  at the second node  130 . Similarly, a timeout occurs for the first timeout interval at the keep-alive send side  133  at the second node  130 . The keep-alive send side  133  at the second node  130  generates its own keep-alive REQUEST message  231  and transmits its keep-alive REQUEST message  231  to the keep-alive receive side  114  at the first node  110 . In each case, the keep-alive REQUEST message  231  includes a keep-alive send sequence-number (SSN). In each case, the keep-alive REQUEST message  231  is transmitted on the same virtual circuit  140  identified by the associated DLCI. 
     At a step  223 , the keep-alive send side  113  at the first node  110  sets its REPLY timer to the second timeout interval. Similarly, the keep-alive send side  133  at the second node  130  sets its own REPLY timer to the second timeout interval. 
     At a flow point  240 , the first node  110  and the second node  130  have been coupled using a virtual circuit  140 , and the keep-alive receive side  114  or the keep-alive receive side  134  are disposed for activity. 
     At a step  241 , the keep-alive receive side  134  at the second node  130  receives the keep-alive REQUEST message  231  from the keep-alive send side  113  at the first node  110 . Similarly, the keep-alive receive side  114  at the first node  110  receives its keep-alive REQUEST message  231  from the keep-alive send side  133  at the second node  130 . 
     At a step  242 , the keep-alive receive side  134  at the second node  130  generates a keep-alive REPLY message  232  and transmits the keep-alive REPLY message  232  to the keep-alive send side  113  at the first node  110 . Similarly, the keep-alive receive side  114  at the first node  110  generates its own keep-alive REPLY message  232  and transmits its keep-alive REPLY message  232  to the keep-alive send side  133  at the second node  130 . In each case, the keep-alive REPLY message  232  includes a keep-alive receive sequence-number (RSN). In each case, the keep-alive REPLY message  232  is transmitted on the virtual circuit  140  identified by the selected DLCI used by the keep-alive REQUEST message  231 . 
     In a preferred embodiment, the keep-alive send sequence-number (SSN) and the keep-alive receive sequence-number (RSN) are both sent with both the keep-alive REQUEST message  231  and the keep-alive REPLY message  232 . 
     After the step  223 , if the keep-alive send side  113  at the first node  110  receives the keep-alive REPLY message  232  within the second timeout interval, it proceeds with the step  224 . Otherwise, a timeout occurs for the second timeout interval at the keep-alive send side  113  at the first node  110 , and it proceeds with the step  225 . Similarly, if the keep-alive send side  133  at the second node  130  receives its keep-alive REPLY message  232  within the second timeout interval, it proceeds with the step  224 . Otherwise, a timeout occurs for the second timeout interval at the keep-alive send side  133  at the second node  130 , and it proceeds with the step  225 . 
     At the step  224 , the keep-alive send side  113  at the first node  110  receives the keep-alive REPLY message  232 , and the keep-alive send side  113  at the first node  110  proceeds with the step  226 . Similarly, the keep-alive send side  133  at the second node  130  receives its keep-alive REPLY message  232 , and the keep-alive send side  133  at the second node  130  proceeds with the step  226 . 
     At the step  225 , a timeout occurs for the second timeout interval at the keep-alive send side  113  at the first node  110 , and the keep-alive send side  113  at the first node  110  proceeds with the step  226 . Similarly, a timeout occurs for the second timeout interval at the keep-alive send side  133  at the second node  130 , and the keep-alive send side  133  at the second node  130  proceeds with the step  226 . 
     At the step  226 , the keep-alive send side  113  at the first node  110  determines whether the keep-alive REQUEST message  231  and keep-alive REPLY message  232  exchange was a SUCCESS or a FAILURE, and sets a current “keep-alive send event” accordingly. Similarly, the keep-alive send side  133  at the second node  130  determines whether the keep-alive REQUEST message  231  and keep-alive REPLY message  232  exchange was a SUCCESS or a FAILURE, and sets its current “keep-alive send event” accordingly. 
     The exchange was a SUCCESS if the keep-alive send side  113  at the first node  110  executed the step  224  and the SSN and RSN matched expectations, and a FAILURE if the keep-alive send side  113  at the first node  110  executed the step  225  or if the SSN or RSN failed to match expectations. To match expectations, the SSN in the keep-alive REQUEST message  231  must match the SSN returned by the keep-alive REPLY message  232 , and the RSN in the keep-alive REPLY message  232  must be one greater than the RSN in the keep-alive REQUEST message  231 . If the exchange was a FAILURE, the RSN is set to match the RSN returned by the keep-alive REPLY message  232 . 
     At the step  243 , the keep-alive receive side  134  at the second node  130  sets a current “keep-alive receive event” responsive to the keep-alive REQUEST message  231 , and whether the SSN and RSN matched expectations. Similarly, the keep-alive receive side  114  at the first node  110  sets its current “keep-alive receive event” responsive to its own keep-alive REQUEST message  231 , and whether the SSN and RSN matched expectations. To match expectations, the RSN in the keep-alive REQUEST message  231  must match the RSN returned by the most recent keep-alive REPLY message  232 , and the SSN in the keep-alive REQUEST message  231  must be one greater than the SSN returned by the most recent keep-alive REPLY message  232 . If the exchange was a FAILURE, the SSN is set to match the SSN received in the keep-alive REQUEST message  231 . 
     At a flow point  250 , not part of normal operation of the method  200  but available for extraordinary processing, an operator (not shown) is prepared to enter a command to set the history sequence for the keep-alive send side  113  or the keep-alive receive side  114  (or the keep-alive send side  133  or the keep-alive receive side  134 ). In a preferred embodiment, the operator may comprise a person using a console at the first node  110  or the second node  130 , or may comprise an application program operating at the first node  110  or the second node  130  or coupled to the first node  110  or the second node  130  using the network  120  or another communication path. 
     At the step  226 , the keep-alive send side  113  at the first node  110  sets a history sequence of keep-alive send events, responsive to a command from the operator. Similarly, the keep-alive send side  133  at the second node  130  sets its history sequence of keep-alive send events responsive to the command from the operator. If history sequences of keep-alive send events have never been set, they default to hexadecimal “FFFFFFFF”, representing a sequence of 32 “SUCCESS” keep-alive send events. 
     After the step  226 , the keep-alive send side  113  at the first node  110  continues at the flow point  220 . Similarly, after the step  226 , the keep-alive send side  133  at the second node  130  also continues at the flow point  220 . 
     At the step  243 , the keep-alive receive side  134  at the second node  130  sets a history sequence of keep-alive receive events, responsive to the command from the operator. Similarly, the keep-alive receive side  114  at the first node  110  sets its history sequence of keep-alive receive events responsive to the command from the operator. If history sequences of keep-alive receive events have never been set, they default to hexadecimal “FFFFFFFF”, representing a sequence of 32 “SUCCESS” keep-alive receive events. 
     After the step  243 , the keep-alive receive side  134  at the second node  130  continues at the flow point  240 . Similarly, after the step  243 , the keep-alive receive side  114  at the first node  130  also continues at the flow point  240 . 
     At a flow point  260 , the first node  110  or the second node  130  are disposed for determining a status of the virtual circuit  140 . 
     At a step  261 , the first node  110  determines the status of the virtual circuit responsive to the history sequence for the keep-alive send side  113 , responsive to the history sequence for the keep-alive receive side  114 , and responsive to a status for the LMI interface for the first local communication link  111 . Similarly, the second node  130  determines the status of the virtual circuit responsive to the history sequence for the keep-alive send side  133 , responsive to the history sequence for the keep-alive receive side  134 , and responsive to a status for the LMI interface for the second local communication link  131 . 
     The keep-alive send history sequence is constructed responsive to a prior keep-alive send history sequence (as possibly recorded at the step  226 ) and a current keep-alive send event (as determined at the step  224  or the step  225 ). The prior keep-alive send history sequence is shifted left one bit, and the current keep-alive send event is appended at the least significant bit. This operation would be described in the “C” computer language as shown in equation 262. 
     
       
         new_history=(old_history&lt;&lt;1)|current_event  (262) 
       
     
     Similarly, the keep-alive receive history sequence is constructed responsive to a prior keep-alive receive history sequence (as possibly recorded at the step  243 ) and a current keep-alive receive status (as determined at the step  242 ). The prior keep-alive receive history sequence is shifted left one bit, and the current keep-alive receive status is appended at the least significant bit. 
     The keep-alive send side  113  at the first node  110  maintains 32 bits of send history sequence information, and the keep-alive receive side  114  at the first node  110  maintains 32 bits of receive history sequence information. Similarly, the keep-alive send side  133  at the second node  130  maintains 32 bits of send history sequence information, and the keep-alive receive side  134  at the second node  130  maintains 32 bits of receive history sequence information. 
     The keep-alive send side  113  at the first node  110  uses the send history sequence information to determine a send status for the virtual circuit  140 ; it determines that the virtual circuit  140  is “up” if there have been fewer than ES errors in the past MS messages; values for ES and MS are configurable parameters which can be set by commands from the operator. In a preferred embodiment, ES is about 2 and MS is about 3. Similarly, the keep-alive send side  133  at the second node  130  uses its send history sequence information to determine its send status for the virtual circuit 140. 
     The keep-alive receive side  134  at the second node  130  uses the receive history sequence information to determine a receive status for the virtual circuit  140 ; it determines that the virtual circuit  140  is “up” if there have been fewer than ER errors in the past MR messages; values for ER and MR are configurable parameters which can be set by commands from the operator. In a preferred embodiment, ER is about 2 and MR is about 3. Similarly, the keep-alive receive side  114  at the first node  110  uses its receive history sequence information to determine its receive status for the virtual circuit  140 . 
     In a preferred embodiment, the first node  110  and the second node  130  determine the status of the virtual circuit as shown in table 2-1. 
     
       
         
               
               
               
               
             
           
               
                 TABLE 2-1 
               
               
                   
               
               
                 receive status 
                 send status 
                 LMI status 
                 overall status 
               
               
                   
               
             
             
               
                 up 
                 up 
                 up 
                 up 
               
               
                 down 
                 any 
                 any 
                 down 
               
               
                 any 
                 down 
                 any 
                 down 
               
               
                 any 
                 any 
                 down 
                 down 
               
               
                   
               
             
          
         
       
     
     At a step  262 , the status as determined in the step  261  is reported to a level  3  protocol layer. The first node  110  or the second node  130  can act on the status as specified by the level  3  protocol layer; alternatively, the first node  110  or the second node  130  can use the status as determined in the step  261  within the frame relay protocol layer. For example, in a preferred embodiment, the first node  110  or the second node  130  can switch the virtual circuit  140  to a new virtual circuit  140  responsive to status showing that the virtual circuit  140  is inoperative. 
     At a flow point  270 , the method  200  is complete, and the first node  110  and the second node  130  can proceed with other processing. 
     Content of End-to-end Keep-alive messages 
     FIG. 3 shows a block diagram of an end-to-end keep-alive message in a frame relay network. 
     An end-to-end keep-alive message comprises a format  300  having a sequence of eight-bit bytes; in the figure, bits in these bytes are labeled from a least significant bit  1  to a most significant bit  8 . In a preferred embodiment, the keep-alive REQUEST message  231  and the keep-alive REPLY message  232  have the same format. 
     The format  300  begins with four bytes of frame-relay header information. A first byte  301  and a second byte  302  collectively comprise a two-byte frame-relay header having a ten-bit DLCI and six bits of control information. Frame-relay headers are known in the art of frame-relay network processing. A third byte  303  and a fourth byte  304  collectively comprise a two-byte type field value reserved for end-to-end keep-alive messages, which is hexadecimal “8037”, thus indicating that the frame-relay message is an end-to-end keep-alive message. The hexadecimal value “8037” is arbitrarily selected and can be any value so long as it is used consistently and does not interfere with values selected for other types of frame-relay messages. 
     The format  300  continues with three bytes of keep-alive report-type information. A fifth byte  305  comprises a keep-alive report type identifier, which is hexadecimal “01”. A sixth byte  306  comprises a keep-alive report type length field, which is hexadecimal “01”, to indicate a one-byte report type value. A seventh byte  307  comprises a keep-alive report type value, which distinguishes between a keep-alive REQUEST message  231  and a keep-alive REPLY message  232 . In a preferred embodiment, the value hexadecimal “01” indicates a keep-alive REQUEST message  231  and the value hexadecimal “02” indicates a keep-alive REPLY message  232 . 
     The format  300  continues with four bytes of keep-alive sequence-number information. An eighth byte  308  comprises a keep-alive sequence-number identifier, which is hexadecimal “03”. A ninth byte  309  comprises a keep-alive sequence-number length field, which is hexadecimal “02”, to indicate a two-byte sequence-number value. A tenth byte  310  comprises the value for the keep-alive send sequence-number (SSN) and an eleventh byte  311  comprises the value for the keep-alive receive sequence-number (RSN). Both the keep-alive send sequence-number (SSN) and the keep-alive receive sequence-number (RSN) are represented as modulo- 255  unsigned integers. 
     Keep-alive messages can also include information regarding configuration of the virtual circuit and congestion at the sending node. For example, certain applications, such as compression or voice transmission, might require consistent configuration at both the sending and receiving ends of the virtual circuit  140 . 
     ALTERNATIVE EMBODIMENTS 
     Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those skilled in the art after perusal of this application.

Technology Classification (CPC): 7