{
  "number": 7746,
  "title": "Label Switched Path (LSP) Self-Ping",
  "authors": [
    "R. Bonica",
    "I. Minei",
    "M. Conn",
    "D. Pacella",
    "L. Tomotaki"
  ],
  "published": "2016-01",
  "status": "Proposed Standard",
  "stream": "IETF",
  "area": "rtg",
  "working_group": "mpls",
  "pages": 12,
  "formats": [
    "TXT",
    "HTML"
  ],
  "abstract": "When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.\n\nThis document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.\n\nLSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.\n\nLSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.",
  "draft": "draft-ietf-mpls-self-ping-06",
  "doi": "10.17487/RFC7746",
  "urls": {
    "html": "https://rfc.dk/rfc7746/",
    "text": "https://rfc.dk/rfc7746.txt",
    "rfc_editor": "https://www.rfc-editor.org/rfc/rfc7746",
    "datatracker": "https://datatracker.ietf.org/doc/rfc7746/"
  },
  "text_modified": "2016-01-29T02:00:44Z"
}