{"draft":"draft-ietf-mpls-self-ping-06","doc_id":"RFC7746","title":"Label Switched Path (LSP) Self-Ping","authors":["R. Bonica","I. Minei","M. Conn","D. Pacella","L. Tomotaki"],"format":["ASCII","HTML"],"page_count":"12","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Multiprotocol Label Switching","abstract":"When certain RSVP-TE optimizations are implemented, ingress Label\r\nSwitching Router (LSRs) can receive RSVP RESV messages before\r\nforwarding state has been installed on all downstream nodes.\r\nAccording to the RSVP-TE specification, the ingress LSR can forward\r\ntraffic through a Label Switched Path (LSP) as soon as it receives a\r\nRESV message.  However, if the ingress LSR forwards traffic through\r\nthe LSP before forwarding state has been installed on all downstream\r\nnodes, traffic can be lost.\r\n\r\nThis document describes LSP Self-ping.  When an ingress LSR receives\r\nan RESV message, it can invoke LSP Self-ping procedures to ensure\r\nthat forwarding state has been installed on all downstream nodes.\r\n\r\nLSP Self-ping is a new protocol.  It is not an extension of LSP Ping.\r\nAlthough LSP Ping and LSP Self-ping are named similarly, each is\r\ndesigned for a unique purpose.  Each protocol listens on its own UDP\r\nport and executes its own procedures.\r\n\r\nLSP Self-ping is an extremely lightweight mechanism.  It does not\r\nconsume control-plane resources on transit or egress LSRs.","pub_date":"January 2016","keywords":[],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC7746","errata_url":null}