Fast LIveness Protocol (FLIP)
draft-sandiick-flip-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Ian Duncan , Hal J. Sandick , Bradley Cain , Brian Haberman , Dr. Matt Squire | ||
| Last updated | 2000-03-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Networks and network applications must be robust and reliable. For many applications and services, such as packetized voice, correcting a failure must be almost instantaneous. The first step in correcting a failure is, of course, detecting that it occurred. IP routing protocols and signaling protocols as well as many application layer protocols incorporate their own keepalive mechanisms to detect failures. Typically, these protocols detect failures on the order of seconds or tens of seconds. While there are some physical and link layer technologies that inherently supply link outage detection, not all link layers do this. In order to provide for fast failure detection over any type of lower layer, an IP layer fast keepalive protocol can be used. This draft describes such a protocol for quickly detecting when a network layer interface of a peer has failed.
Authors
Ian Duncan
Hal J. Sandick
Bradley Cain
Brian Haberman
Dr. Matt Squire
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)