US20120290721A1 - Systems and methods for ip session keepalive using bfd protocols - Google Patents
Systems and methods for ip session keepalive using bfd protocols Download PDFInfo
- Publication number
- US20120290721A1 US20120290721A1 US13/556,927 US201213556927A US2012290721A1 US 20120290721 A1 US20120290721 A1 US 20120290721A1 US 201213556927 A US201213556927 A US 201213556927A US 2012290721 A1 US2012290721 A1 US 2012290721A1
- Authority
- US
- United States
- Prior art keywords
- session
- packets
- bfd
- iped
- active
- 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.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
Abstract
A network device may include logic to establish an IP session, establish a BFD session within the established IP session, transmit BFD packets within the established BFD session, and determine that the established IP session is active based upon reception of the BFD packets. In another embodiment, the logic may also determine that an IP session is active using an inactivity timer that may also trigger transmission of BFD packets.
Description
- Implementations consistent with the systems and methods described herein relate generally to computer and data communications and, more particularly, to techniques for detecting failures in computer and data communications.
- Network service providers, such as Internet service providers (ISPs), typically allocate network resources upon creation of an IP session. For various reasons, an IP session may fail. Current methods of detecting failed connections in IP sessions do not provide timely detection and notification of IP session failures.
- One aspect is directed to method that comprises establishing an IP session, establishing a BFD session within the established IP session, receiving BFD packets within the established BFD session, and determining that the established IP session is active based upon receiving the BFD packets. The method may further include establishing a BFD session between an IP edge device and a remote IP device, wherein either the IP edge device or the remote IP device may determine that the IP session is active. The method may further include transmitting and receiving BFD packets using one of a BFD asynchronous mode or BFD demand mode.
- Another aspect is directed to a network device that comprises logic configured to: establish an IP session, establish a BFD session within the established IP session, receive BFD packets, and determine whether the IP session is active, based on a number of received BFD packets. The network device may be one of an IP edge device or a remote IP device. In another aspect, data received by the network device from the remote IP device determines whether the IP session is active. In another aspect, if data is not received by the network device within a predetermined time period set by an inactivity timer, the expiration of the inactivity timer may trigger transmission of BFD packets by the network device.
- The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments and, together with the description, explain the system and methods. In the drawings,
-
FIG. 1 is a diagram of an exemplary system in which systems and methods may be implemented; -
FIG. 2 is an exemplary diagram of the IP edge device ofFIG. 1 ; -
FIG. 3 illustrates an exemplary functional diagram of the IP edge device ofFIG. 2 ; -
FIG. 4 illustrates exemplary processing performed by the IP edge device ofFIG. 2 ; -
FIG. 5 illustrates another exemplary processing performed by the IP edge device ofFIG. 2 ; and -
FIG. 6 illustrates another exemplary processing performed by the IP edge device ofFIG. 2 . - The following detailed description of implementations consistent with systems and methods described herein refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the implementations. Instead, the scope of the systems and methods described herein is defined by the appended claims and their equivalents.
-
FIG. 1 is a diagram of anexemplary system 100 in which systems and methods described herein may be implemented. As illustrated,system 100 may include anaccess network 110, subscriber devices 120-1 to 120-N,router gateway 130,network 140,servers IP edge device 170. It will be appreciated that the number of devices illustrated inFIG. 1 is provided for simplicity. In practice, a typical system may include more or fewer devices than illustrated inFIG. 1 . Moreover,system 100 may include other devices (not shown) that aid in the reception, processing, and/or transmission of data. - Access Network 110 may include any network capable of transferring a data unit. “Data unit,” as used herein, may refer to any type of machine-readable data having substantially any format that may be adapted for use in one or more networks, such as
access network 110. A data unit may include packet data and/or non-packet data. Implementations ofaccess network 110 may include a network that connects anetwork 140 to arouter gateway 130.Access network 110 may be constructed as a Layer 2 network (data link layer) in the Open Systems Interconnection (OSI) reference model. Access Network 110 may be a hardwired network using wired conductors and/or optical fibers and/or may be a wireless network using free-space optical and/or radio frequency (RF) transmission paths. Implementations of networks and/or devices operating on networks described herein are not limited to any particular data type, and/or protocol. - Subscriber devices 120-1 through 120-N (collectively referred to as subscriber devices 120) may include any device capable of transmitting and/or receiving data from
access network 110. For example,subscriber devices 120 may include a personal computer, a laptop computer, a personal digital assistant (PDA), a television, a telephone device, a video game console a web-enabled cellular telephone, or another computation or communication device.Subscriber devices 120 may connect torouter gateway 130 via any type of connection, such as wired, wireless, and/or optical connections. -
Router gateway 130 may include a device capable of receiving data fromsubscriber devices 120 and routing the data to/throughaccess network 110.Router gateway 130 may also receive data fromaccess network 110 and route the data to theappropriate subscriber device 120. In one implementation,router gateway 130 may be a public interface to accessnetwork 110. In another implementation,router gateway 130 may include a digital subscriber line access multiplexer (DSLAM).Router gateway 130 may operate in cooperation withservers subscriber devices 120, for example. -
Network 140 may include any network capable of transferring a data unit as described above. Implementations ofnetwork 140 may include local area networks (LANs), public switched telephone network (PSTN), metropolitan area networks (MANs) and/or wide area networks (WANs), such as the Internet, that may operate using substantially any network protocol, such as Internet protocol (IP), asynchronous transfer mode (ATM), and/or synchronous optical network (SONET).Network 140 may include network devices, such as routers, switches, firewalls, and/or servers (not shown).Network 140 may be a hardwired network using wired conductors and/or optical fibers and/or may be a wireless network using free-space optical and/or radio frequency (RF) transmission paths. Implementations of networks and/or devices operating on networks described herein are not limited to any particular data type, and/or protocol. -
Server 150 may include one or more processors or microprocessors enabled by software programs to perform functions, such as data storage and transmission, codex conversion, and interfacing withserver 160 andIP edge device 170, for example.Server 150 may also include a data storage memory such as a random access memory (RAM) or another dynamic storage device that stores information such as subscriber device information for establishing IP and BFD sessions, as described in detail below. -
Server 150 may also include a communication interface that may include any transceiver-like mechanism that enablesserver 150 to communicate with other devices and/or systems. For example,server 150 may include a modem or an Ethernet interface to a LAN. In addition,server 150 may include other mechanisms for communicating data via a network, such as a wireless network. For example,server 150 may include one or more radio frequency (RF) transmitters and receivers for transmitting and receiving (RF) signals. -
Server 150 may include a computer device that stores and/or runs applications to validate, establish and monitor IP and BFD protocol sessions.Server 150 may also be configured as a RADIUS server to provide and/or aid in providing media content to subscribers associated withsubscriber devices 120. For example, media content may be transmitted in an established static IP session in a DSL connection. Media content may include, for example, video-on-demand, live or pre-recorded television or radio broadcasts, streaming music, on-line gaming, or other voice and/or video content. In fact, media content may include any content that is stored or dynamically generated in real-time on one or multiple network devices. -
Server 160 may include one or more processors or microprocessors enabled by software programs to perform functions, such as data storage and transmission, codex conversion, and interfacing withserver 150 andIP edge device 170, for example.Server 160 may also include a data storage memory such as a random access memory (RAM) or another dynamic storage device that stores information.Server 160 may also include a communication interface that may include any transceiver-like mechanism that enablesserver 160 to communicate with other devices and/or systems. For example,server 160 may include a modem or an Ethernet interface to a LAN. In addition,server 160 may be configured as a DHCP server that stores and/or runs applications to provide network resources tosubscriber devices 120. - IP Edge Device (IPED) 170 may include hardware or software logic to store information related to routing of data between
servers subscriber devices 120, viarouter gateway 130 andaccess network 110. In one implementation,IPED 170 may establish and monitor IP and BFD protocol sessions, between for example,subscriber devices 120 and/orrouter gateway 130 andserver 160. In another implementation,IPED 170 may be configured as a broadband network gateway or a BRAS server, for example. -
IPED 170 may include computer devices that retrieve subscriber profile information fromserver 150, for example. Subscriber profile information may include a subscriber IP address and information necessary to validate and establish IP sessions and to establish and create BFD protocol sessions.IPED 170 may be implemented in hardware, software, or a combination of hardware and software. Anexemplary IPED 170 is described below with reference toFIGS. 2-3 . -
FIG. 2 illustrates an exemplary architecture for implementingIPED 170 ofFIG. 1 . It will be appreciated thatsubscriber devices 120,router gateway 130,servers system 100 may be similarly configured. As illustrated inFIG. 2 ,IPED 170 may include abus 210 that may include one or more interconnects that permit communication among aprocessor 220, amemory 230, a read only memory (ROM) 240, astorage device 250, aninput device 260, anoutput device 270, and acommunication interface 280. -
Processor 220 may include any type of processor, microprocessor, or processing logic that may interpret and execute instructions.Memory 230 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution byprocessor 220.Memory 230 may also be used to store temporary variables or other intermediate information during execution of instructions byprocessor 220.ROM 240 may include a ROM device and/or another type of static storage device that may store static information and instructions forprocessor 220.Storage device 250 may include a magnetic disk and/or optical disk and its corresponding drive for storing information and/or instructions. -
Input device 260 may include any mechanism or combination of mechanisms that permit an operator to input information toservers Output device 270 may include any mechanism or combination of mechanisms that outputs information to the operator, including a display, a printer, etc. -
Communication interface 280 may include any transceiver-like mechanism that enablesIPED 170 to communicate with other devices and/or systems, such assubscriber devices 120,router gateway 130, andservers communication interface 280 may include one or more interfaces, such as a first interface coupled tosubscriber device 120 and/or a second interface coupled to accessnetwork 110, and/or a third interface coupled tonetwork 140. -
IPED 170 may perform certain functions in response toprocessor 220 executing software instructions contained in a computer-readable medium, such asmemory 230. A computer-readable medium may be defined as one or more memory devices and/or carrier waves. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions to implement features consistent with principles of the embodiments. Thus, implementations consistent with principles of the embodiments are not limited to any specific combination of hardware circuitry and software. -
FIG. 3 illustrates an exemplary functional diagram ofIPED 170 ofFIG. 2 . The functional diagram ofFIG. 3 may includenetwork interface logic 310, IPsession management logic 320, and Bidirectional Forwarding Detection (BFD)session management logic 330. The implementation ofFIG. 3 is exemplary, andIPED 170 may include more or fewer functional components without departing from the spirit of the embodiments. In other embodiments,router gateway 130 may contain similar components. In one embodiment,IPED 170 may be configured to function as a DHCP server or as a DHCP Relay/Proxy. -
Network interface logic 310 may include hardware or software to route data betweensubscriber devices 120 andservers network interface logic 310 may establish a network interface betweensubscriber devices 120 andnetwork 110 upon receiving a connection request fromsubscriber devices 120. In one implementation,network interface logic 310 may configure a virtual router associated with an established network interface.Network interface logic 310 may assign network addresses to the respective network interfaces. In one implementation, the network interface may include routes for data transmissions to/fromsubscriber devices 120 and routes to/fromservers Network interface logic 310 may be implemented incommunication interface 280 or elsewhere inIPED 170. - IP
session management logic 320 may include hardware or software forIPED 170 to process instructions or data related to establishing and maintaining an IP session. For example, IPsession management logic 320 may be implemented inprocessor 220 and may make IP session information available to another device, software module, or component operating inIPED 170, such as BFDsession management logic 330. IPsession management logic 320 may include IP session information that identifies one or more network parameters and policies related tosubscriber device 120. In one implementation, IPsession management logic 320 may include IP session information downloaded fromserver 150, vianetwork interface logic 310, for example. An IP session may be established betweenIPED 170 and a remote IP device, such asrouter gateway 130 orsubscriber device 120, for example. - BFD
session management logic 330 may include hardware or software to process instructions or data related to establishing and maintaining Bidirectional Forwarding Detection (BFD) protocol sessions. In one implementation, BFDsession management logic 330 may notifynetwork interface logic 310 and/orservers session management logic 330 may receive BFD session parameters and policies fromserver 150, vianetwork interface logic 310. In another implementation, BFDsession management logic 330 may automatically create a BFD session in response to the creation of an IP session. BFDsession management logic 330 may store parameters relating to establishing and maintaining a BFD session such as a BFD session enable flag, a BFD mode (asynchronous or demand), a frequency or time period between BFD packet transmissions, a number of BFD packet polls unanswered indicating an IP session or connection failure and an alarms enable flag. -
FIG. 4 illustrates anexemplary process 400 to implement IP session monitoring using BFD protocol mechanisms. In one implementation,exemplary process 400 may be performed byIPED 170 and/orrouter gateway 130. Processing may begin, for example, by establishing an IP session (act 410). For example, an IP session may be established betweenrouter gateway 130 andIPED 170, in response toIPED 170 receiving an IP packet fromsubscriber devices 120, viarouter gateway 130. The established IP session may be a dynamically created IP session or a static IP session, for example. In response to receiving an IP packet, for example,IPED 170 may accessserver 150 for validation data and session parameters in order to establish an IP session. Once the IP session has been established, a BFD session may be established within the IP session (act 420). For example,IPED 170 may access BFD session parameters inserver 150 and/or these BFD session parameters may be transmitted toIPED 170 when the IP session may have been validated and established. BFD parameters may include for example, the BFD mode of operation (asynchronous or demand), whether the BFD session is enabled, a frequency of BFD packet transmissions, a number of dropped BFD packet polls allowed and enablement of alarms. - In BFD asynchronous mode for example,
IPED 170 may begin to transmit BFD Control packets using BFD protocols (act 430). For example, BFD Control packets may be transmitted fromIPED 170 torouter gateway 130 every 30 seconds.Router gateway 130 may also begin to transmit BFD Control packets to IPED 170 within the established BFD session (act 430). The frequency of BFD Control packets may be determined from the BFD session parameters contained inserver 150 and/orIPED 170. In one embodiment, theIPED 170 androuter gateway 130 may have different frequencies of transmitting BFD Control packets to one another. In another embodiment, the frequency of transmitting BFD Control packets may be manually adjusted, for example. - In accordance with the established BFD session parameters for example,
IPED 170 may determine that an IP session is active based on receiving BFD Control packets (act 440). For example,IPED 170 may receive a BFD Control packet every 30 seconds fromrouter gateway 130. If theIPED 170 does not receive BFD Control packets fromrouter gateway 130 for 90 seconds, (3 polling periods) for example,IPED 170 may determine a failed connection and/or IP session (act 440). In response to this determination (act 440), the IP session may be terminated byIPED 170.IPED 170 may also determine that an IP session is inactive if a predetermined number of BFD Control packets are not received. For example, 3 failed receptions of BFD Control packets may determine that an IP session is inactive. - In another implementation,
router gateway 130 may determine that the IP session is active upon receiving BFD Control packets from IPED 170 (act 440). For example, in the established IP and BFD sessions (acts 410 and 420),IPED 170 may transmit BFD Control packets to router gateway 130 (act 430).Router gateway 130 may determine that the IP session is active based on receiving BFD Control packets from IPED 170 (act 440).Router gateway 130 may also determine that an IP session is inactive based upon not having received a predetermined number of BFD Control packets fromIPED 170, or may determine that an IP session is inactive when a BFD Control packet has not been received for a predetermined period of time, for example. - In the above embodiments, once an IP session is determined to be inactive, appropriate action may be taken, such as notifying an administrator or automatically attempting to renew the IP session.
-
FIG. 5 illustrates anexemplary process 500 to implement IP session monitoring using another BFD protocol mechanism. In one implementation,exemplary process 500 may be performed byIPED 170. Processing may begin by establishing an IP session (act 510). For example, an IP session may be established betweenrouter gateway 130 andIPED 170, in response toIPED 170 receiving an IP packet fromsubscriber devices 120, viarouter gateway 130. The established IP session may be a dynamically created IP session or a static IP session, for example. In response to receiving an IP packet,IPED 170 may accessserver 150 for validation data and session parameters in order to establish the IP session. Once the IP session has been established, a BFD session may be established within the IP session (act 520). For example,IPED 170 may access BFD session parameters inserver 150 and/or these BFD session parameters may be transmitted toIPED 170 when the IP session was validated and established. BFD parameters may include for example, the BFD mode of operation, whether the session is enabled, a frequency of BFD packet transmission, a number of dropped BFD packet polls allowed and enablement of alarms. - BFD demand mode may be used. In demand mode,
IPED 170 may transmit BFD Echo packets using BFD protocols (act 530). For example, BFD “Echo packets” may be transmitted fromIPED 170 to router gateway 130 (act 530). Echo packets are packets that are automatically transmitted back toIPED 170 fromrouter gateway 130, without requiring control and negotiation of transmission parameters fromrouter gateway 130. The BFD Echo packet originally transmitted fromIPED 170 may then be automatically transmitted fromrouter gateway 130 back toIPED 170.IPED 170 may then determine that the IP session is active upon reception of the BFD Echo packet from router gateway 130 (act 540). - In another embodiment,
router gateway 130 may be configured to transmit BFD Echo packets toIPED 170. For example, once the IP and BFD sessions are established (acts 510 and 520),router gateway 130 may transmit BFD Echo packets to IPED (act 530). The BFD Echo packet originally transmitted fromrouter gateway 130 may then be automatically transmitted fromIPED 170 back torouter gateway 130.Router gateway 130 may then determine that the IP session is active upon reception of the BFD Echo packet from IPED 170 (act 540). -
FIG. 6 illustrates anexemplary process 600 to implement IP session monitoring using BFD protocols and an inactivity timer mechanism. In one implementation,exemplary process 600 may be performed byIPED 170, or a remote IP device, such asrouter gateway 130. Processing may begin by establishing an IP session (act 610). For example, an IP session may be established betweenrouter gateway 130 andIPED 170, in response toIPED 170 receiving an IP packet fromsubscriber devices 120, viarouter gateway 130. The established IP session may be a dynamically created IP session or a static IP session, for example. In response to receiving an IP packet,IPED 170 may accessserver 150 for validation data and session parameters in order to establish the IP session. Once the IP session has been established, a BFD session may be established within the IP session (act 620). For example,IPED 170 may access BFD session parameters inserver 150 and/or these BFD session parameters may be transmitted toIPED 170 when the IP session was validated and established. BFD parameters may include for example, the BFD mode of operation, whether the BFD session is enabled, a frequency of BFD packet transmission, an inactivity timer period, a number of dropped BFD packet polls allowed and enablement of alarms. - In
exemplary process 600, an inactivity timer may be enabled inIPED 170 upon establishing the IP and BFD sessions (acts 610 and 620). An inactivity timer enabled inIPED 170 may set a predetermined period of time that may generate an alert when no data has been received fromrouter gateway 130 for the predetermined period of time, for example. The time period may be manually configured or may be set by stored parameters upon establishment of the IP and BFD sessions. If, for example,IPED 170 receives data fromsubscriber device 120 and/orrouter gateway 130, the inactivity timer on IPED may be reset for the predetermined period of time, for example, 30 seconds. As long asIPED 170 receives data fromsubscriber device 120 and/orrouter gateway 130 within the predetermined period of time, the inactivity timer may not expire. If for example, no data has been received fromsubscriber device 120 and/orrouter gateway 130 within the predetermined period of time, the inactivity timer onIPED 170 may expire. In demand mode, the expiration of the inactivity timer may instigate BFD packets to be transmitted fromIPED 170 to router gateway 130 (act 630). - In demand mode,
IPED 170 may transmit BFD packets as Echo packets or Control packets using BFD protocols (act 630). As described above, BFD “Echo packets” may be transmitted fromIPED 170 torouter gateway 130 and may be automatically transmitted back toIPED 170 fromrouter gateway 130, without requiring control and negotiation of transmission parameters fromrouter gateway 130. A BFD Echo packet may be transmitted fromIPED 170 may then be automatically transmitted fromrouter gateway 130 back to IPED 170 (act 630), for example.IPED 170 may then determine that the IP session is active based upon reception of the BFD Echo packet from router gateway 130 (act 640). In this embodiment,IPED 170 may also determine that an IP session is active based on receiving data fromsubscriber device 120 and/or router gateway 130 (act 640), without transmitting BFD Echo packets (act 630). If for example, the inactivity timer expires, and BFD Echo packets are not received back byIPED 170, the IP session may be determined to be inactive (act 640). - Also using demand mode in another exemplary embodiment,
IPED 170 may transmit BFD Control packets using BFD protocols (act 630). A BFD Control packet may be transmitted fromIPED 170 in response to the expiration of an inactivity timer, for example. The BFD Control packet transmitted fromIPED 170 may then be received byrouter gateway 130, for example. Upon receiving BFD Control packets fromIPED 170,router gateway 130 may determine that the IP session is active (act 640). If for example, the inactivity timer expires, and BFD Control packets are transmitted fromIPED 170 and the BFD Control packets are not received byrouter gateway 130, the IP session may be determined to be inactive (act 640). As described above for example, as long asIPED 170 receives data fromrouter gateway 130 within the predetermined time period of the inactivity timer, the IP session may be determined to be active (act 640), without sending BFD Control packets to router gateway 130 (act 630). - In all of the exemplary embodiments described above relating to process 600, once an IP session is determined to be inactive, appropriate action may be taken, such as notifying an administrator or automatically attempting to renew the IP session.
- The foregoing description of exemplary embodiments provides illustration and description, but is not intended to be exhaustive or to limit embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the embodiments. For example, while a series of acts has been described with regard to
FIGS. 4-6 , the order of the acts may be modified in other implementations. Further, non-dependent acts may be performed in parallel. - For example, implementations consistent with principles of the embodiments can be implemented using devices and configurations other than those illustrated in the figures and described in the specification without departing from the spirit of the embodiments. Devices and/or components may be added and/or removed from the implementations of
FIGS. 1-3 depending on specific deployments and/or applications. Further, disclosed implementations may not be limited to any specific combination of hardware. - No element, act, or instruction used in the description of the embodiments should be construed as critical or essential, unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on,” as used herein is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
- The scope of the systems and methods described herein is defined by the claims and their equivalents.
Claims (21)
1-24. (canceled)
25. A method comprising:
detecting, by a first device, an expiration of a timer;
transmitting, by the first device and based on the expiration of the timer, one or more first packets to a second device in a session established between the first device and the second device;
determining, by the first device, if one or more second packets are received from the second device;
determining, by the first device and when the one or more second packets are not received from the second device, that the session is not active; and
transmitting, by the first device, data based on determining that the session is not active.
26. The method of claim 25 , where, when transmitting the data, the method further includes:
transmitting a notification to an administrator that notifies the administrator that the session is not active.
27. The method of claim 25 , where, when transmitting the data, the method further includes:
transmitting one or more additional packets to the second device to renew the session.
28. The method of claim 25 , further comprising:
determining, by the first device and when the one or more second packets are received from the second device, that the session is active.
29. The method of claim 25 , further comprising:
determining, by the first device and when one or more additional packets are received from a third device, that the session is active.
30. The method of claim 25 , where the timer is associated with a polling period, the method further comprising:
automatically transmitting the one or more first packets upon the expiration of the polling period.
31. The method of claim 25 , where the one or more first packets are Bidirectional Forwarding Detection (BFD) packets and the one or more second packets are BFD Echo packets.
32. A non-transitory computer-readable storage medium comprising:
one or more instructions which, when executed by at least one processor, cause the at least one processor to:
detect an expiration of a timer;
transmit, based on the expiration of the timer, one or more first packets to a second device in a session established between the first device and the second device;
determine if one or more second packets are received from the second device;
determine, when the one or more second packets are not received from the second device, that the session is not active; and
transmit data based on determining that the session is not active.
33. The non-transitory computer-readable medium of claim 32 , where the one or more instructions to transmit the data include:
one or more instructions to transmit a notification to an administrator that notifies the administrator that the session is not active.
34. The non-transitory computer-readable medium of claim 32 , where the one or more instructions to transmit the data include:
one or more instructions to transmit one or more additional packets to the second device to renew the session.
35. The non-transitory computer-readable medium of claim 32 , further comprising:
one or more instructions to determine, when the one or more second packets are received from the second device, that the session is active.
36. The non-transitory computer-readable medium of claim 32 , further comprising:
one or more instructions to determine, when one or more additional packets are received from a third device, that the session is active.
37. The non-transitory computer-readable medium of claim 32 , where the timer is associated with a polling period, the one or more instructions further comprising:
one or more instructions to automatically transmit the one or more first packets upon the expiration of the polling period.
38. The non-transitory computer-readable medium of claim 32 , where the one or more first packets are Bidirectional Forwarding Detection (BFD) packets and the one or more second packets are BFD Echo packets.
39. A device comprising:
one or more memory devices to store a plurality of instructions; and
one or more processors to execute the plurality of instructions, to:
detect an expiration of a timer;
transmit, based on the expiration of the timer, one or more first packets to a second device in a session established between the first device and the second device;
determine if one or more second packets are received from the second device;
determine, when the one or more second packets are not received from the second device, that the session is not active; and
transmit, based on determining that the session is not active, one or more additional packets to the second device to renew the session.
40. The device of claim 39 , where the one or more processors are to:
determine, when the one or more second packets are received from the second device, that the session is active.
41. The device of claim 39 , where the one or more processors are to:
determine, when one or more packets are received from a third device, that the session is active.
42. The device of claim 39 , where the timer is associated with a polling period, and the one or more processors are to:
automatically transmit the one or more first packets upon the expiration of the polling period.
43. The device of claim 39 , where the one or more first packets are Bidirectional Forwarding Detection (BFD) packets and the one or more second packets are BFD Echo packets.
44. The device of claim 39 , where the session is an Internet Protocol (IP) session.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/556,927 US20120290721A1 (en) | 2006-09-29 | 2012-07-24 | Systems and methods for ip session keepalive using bfd protocols |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/537,095 US7860981B1 (en) | 2006-09-29 | 2006-09-29 | Systems and methods for IP session keepalive using BFD protocols |
US12/951,986 US8255543B2 (en) | 2006-09-29 | 2010-11-22 | Systems and methods for IP session keepalive using BFD protocols |
US13/556,927 US20120290721A1 (en) | 2006-09-29 | 2012-07-24 | Systems and methods for ip session keepalive using bfd protocols |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/951,986 Continuation US8255543B2 (en) | 2006-09-29 | 2010-11-22 | Systems and methods for IP session keepalive using BFD protocols |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120290721A1 true US20120290721A1 (en) | 2012-11-15 |
Family
ID=43357448
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/537,095 Active 2028-05-25 US7860981B1 (en) | 2006-09-29 | 2006-09-29 | Systems and methods for IP session keepalive using BFD protocols |
US12/951,986 Active US8255543B2 (en) | 2006-09-29 | 2010-11-22 | Systems and methods for IP session keepalive using BFD protocols |
US13/556,927 Abandoned US20120290721A1 (en) | 2006-09-29 | 2012-07-24 | Systems and methods for ip session keepalive using bfd protocols |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/537,095 Active 2028-05-25 US7860981B1 (en) | 2006-09-29 | 2006-09-29 | Systems and methods for IP session keepalive using BFD protocols |
US12/951,986 Active US8255543B2 (en) | 2006-09-29 | 2010-11-22 | Systems and methods for IP session keepalive using BFD protocols |
Country Status (1)
Country | Link |
---|---|
US (3) | US7860981B1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8688888B1 (en) | 2012-12-31 | 2014-04-01 | Giga-Byte Technology Co., Ltd. | Computer peripheral device and operating method thereof |
CN106330586A (en) * | 2015-06-29 | 2017-01-11 | 中兴通讯股份有限公司 | Method and device for improving service detection reliability in switch network link |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7860981B1 (en) * | 2006-09-29 | 2010-12-28 | Juniper Networks, Inc. | Systems and methods for IP session keepalive using BFD protocols |
CN101437021B (en) * | 2007-11-16 | 2013-08-07 | 华为技术有限公司 | Method, system and apparatus for processing access prompt information |
US8078721B2 (en) * | 2008-02-15 | 2011-12-13 | Cisco Technology, Inc. | Dynamic host configuration protocol (DHCP) initialization responsive to a loss of network layer connectivity |
CN101729303B (en) * | 2008-10-25 | 2012-12-12 | 华为技术有限公司 | Method and device for measuring network performance parameter |
US20100138501A1 (en) * | 2008-12-03 | 2010-06-03 | Microsoft Corporation | End-to-end validation in a push environment |
CN101783773B (en) * | 2009-01-21 | 2013-01-09 | 华为技术有限公司 | IP session survival monitoring method, as well as system, home gateway and network device |
CN103067220B (en) * | 2012-12-19 | 2016-02-10 | 中兴通讯股份有限公司 | Two-way link forwarding detection (BFD) method and device under parameter update status |
US9258234B1 (en) | 2012-12-28 | 2016-02-09 | Juniper Networks, Inc. | Dynamically adjusting liveliness detection intervals for periodic network communications |
US8953460B1 (en) * | 2012-12-31 | 2015-02-10 | Juniper Networks, Inc. | Network liveliness detection using session-external communications |
US9185170B1 (en) * | 2012-12-31 | 2015-11-10 | Juniper Networks, Inc. | Connectivity protocol delegation |
US9769017B1 (en) | 2014-09-26 | 2017-09-19 | Juniper Networks, Inc. | Impending control plane disruption indication using forwarding plane liveliness detection protocols |
CN105591768B (en) * | 2014-10-21 | 2019-11-29 | 中兴通讯股份有限公司 | Fault detection method and device |
KR102435334B1 (en) * | 2015-05-07 | 2022-08-23 | 삼성전자 주식회사 | Adaptive Bidirectional Forwarding Detection protocol and equipment for maximizing service availability in network system |
CN106301840B (en) * | 2015-05-27 | 2020-09-15 | 中兴通讯股份有限公司 | Method and device for sending Bidirectional Forwarding Detection (BFD) message |
US10530869B2 (en) * | 2015-10-08 | 2020-01-07 | Arista Networks, Inc. | Bidirectional forwarding detection accelerator |
US10374936B2 (en) | 2015-12-30 | 2019-08-06 | Juniper Networks, Inc. | Reducing false alarms when using network keep-alive messages |
US10397085B1 (en) | 2016-06-30 | 2019-08-27 | Juniper Networks, Inc. | Offloading heartbeat responses message processing to a kernel of a network device |
US10476774B2 (en) * | 2016-08-31 | 2019-11-12 | Juniper Networks, Inc. | Selective transmission of bidirectional forwarding detection (BFD) messages for verifying multicast connectivity |
US10447586B2 (en) * | 2017-06-01 | 2019-10-15 | Zte Corporation | Defect detection in IP/MPLS network tunnels |
US11750441B1 (en) | 2018-09-07 | 2023-09-05 | Juniper Networks, Inc. | Propagating node failure errors to TCP sockets |
CN109743746A (en) * | 2018-12-07 | 2019-05-10 | 盛科网络(苏州)有限公司 | A kind of two-way converting detection BFD parameter consultation method, device and chip |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7561527B1 (en) * | 2003-05-02 | 2009-07-14 | David Katz | Bidirectional forwarding detection |
US7499395B2 (en) * | 2005-03-18 | 2009-03-03 | Cisco Technology, Inc. | BFD rate-limiting and automatic session activation |
DE102005025419A1 (en) * | 2005-06-02 | 2006-12-07 | Siemens Ag | Method for the efficient handling of disruptions in the packet-based transmission of traffic |
US7773611B2 (en) * | 2005-06-15 | 2010-08-10 | Cisco Technology, Inc. | Method and apparatus for packet loss detection |
EP1921809A4 (en) * | 2005-08-05 | 2008-10-01 | Huawei Tech Co Ltd | A method for achieving fault detection of ip forwarding plane |
US8441919B2 (en) * | 2006-01-18 | 2013-05-14 | Cisco Technology, Inc. | Dynamic protection against failure of a head-end node of one or more TE-LSPs |
US7765306B2 (en) * | 2006-01-30 | 2010-07-27 | Cisco Technology, Inc. | Technique for enabling bidirectional forwarding detection between edge devices in a computer network |
US8082340B2 (en) * | 2006-01-30 | 2011-12-20 | Cisco Technology, Inc. | Technique for distinguishing between link and node failure using bidirectional forwarding detection (BFD) |
US8543718B2 (en) * | 2006-03-02 | 2013-09-24 | Cisco Technology, Inc. | Technique for efficiently and dynamically maintaining bidirectional forwarding detection on a bundle of links |
US8208372B2 (en) * | 2006-06-02 | 2012-06-26 | Cisco Technology, Inc. | Technique for fast activation of a secondary head-end node TE-LSP upon failure of a primary head-end node TE-LSP |
US7498818B2 (en) * | 2006-08-25 | 2009-03-03 | Schweitzer Engineering Laboratories, Inc. | Apparatus and method for detecting a brush liftoff in a synchronous generator rotor circuit |
US7860981B1 (en) * | 2006-09-29 | 2010-12-28 | Juniper Networks, Inc. | Systems and methods for IP session keepalive using BFD protocols |
-
2006
- 2006-09-29 US US11/537,095 patent/US7860981B1/en active Active
-
2010
- 2010-11-22 US US12/951,986 patent/US8255543B2/en active Active
-
2012
- 2012-07-24 US US13/556,927 patent/US20120290721A1/en not_active Abandoned
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8688888B1 (en) | 2012-12-31 | 2014-04-01 | Giga-Byte Technology Co., Ltd. | Computer peripheral device and operating method thereof |
CN106330586A (en) * | 2015-06-29 | 2017-01-11 | 中兴通讯股份有限公司 | Method and device for improving service detection reliability in switch network link |
Also Published As
Publication number | Publication date |
---|---|
US20110066735A1 (en) | 2011-03-17 |
US8255543B2 (en) | 2012-08-28 |
US7860981B1 (en) | 2010-12-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7860981B1 (en) | Systems and methods for IP session keepalive using BFD protocols | |
US11146470B2 (en) | Apparatus and methods for monitoring and diagnosing a wireless network | |
US9344462B2 (en) | Switching between connectivity types to maintain connectivity | |
US10771396B2 (en) | Communications network failure detection and remediation | |
US7898939B2 (en) | Scalable and robust mechanism for remote IP device monitoring with changing IP address assignment | |
US9258183B2 (en) | Method, device, and system for realizing disaster tolerance backup | |
US9363313B2 (en) | Reducing virtual IP-address (VIP) failure detection time | |
KR101591102B1 (en) | Method for router of virtual router redundancy protocol and communication system therefor | |
US20050091304A1 (en) | Telecommunications device and method | |
US20050086385A1 (en) | Passive connection backup | |
WO2022134616A1 (en) | Wireless network delay processing method and system and access server | |
JP5604389B2 (en) | Communication system, router device, and router switching method | |
US8462952B2 (en) | Synchronizing management signaling in a network | |
JP2005204189A (en) | Access user management system and device | |
KR101459170B1 (en) | Mechanisms for failure detection and mitigation in a gateway device | |
US9813763B2 (en) | Application for in-field discovery, diagnosis and repair of a set-top device | |
WO2014090194A1 (en) | Dialing method of terminal device, and access device | |
Cisco | System Software Caveats 9.21 | |
Cisco | 9.21(1) Caveats/9.21(2) Modifications | |
Cisco | 9.21(1) Caveats/9.21(2) Modifications | |
CN106375224B (en) | Router and method for network connection by using same | |
US20230344747A1 (en) | Method and apparatus for detecting state of bgp session, and network device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |