{"draft":"draft-ietf-ccamp-crankback-06","doc_id":"RFC4920","title":"Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE","authors":["A. Farrel, Ed.","A. Satyanarayana","A. Iwata","N. Fujita","G. Ash"],"format":["ASCII","HTML"],"page_count":"38","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Common Control and Measurement Plane","abstract":"In a distributed, constraint-based routing environment, the\r\ninformation used to compute a path may be out of date.  This means\r\nthat Multiprotocol Label Switching (MPLS) and Generalized MPLS\r\n(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup\r\nrequests may be blocked by links or nodes without sufficient\r\nresources.  Crankback is a scheme whereby setup failure information is\r\nreturned from the point of failure to allow new setup attempts to be\r\nmade avoiding the blocked resources.  Crankback can also be applied to\r\nLSP recovery to indicate the location of the failed link or node.\r\n\r\nThis document specifies crankback signaling extensions for use in MPLS\r\nsignaling using RSVP-TE as defined in \"RSVP-TE: Extensions to RSVP for\r\nLSP Tunnels\", RFC 3209, and GMPLS signaling as defined in \"Generalized\r\nMulti-Protocol Label Switching (GMPLS) Signaling Functional\r\nDescription\", RFC 3473.  These extensions mean that the LSP setup\r\nrequest can be retried on an alternate path that detours around\r\nblocked links or nodes.  This offers significant improvements\r\nin the successful setup and recovery ratios for LSPs, especially in\r\nsituations where a large number of setup requests are triggered at the\r\nsame time.  [STANDARDS-TRACK]","pub_date":"July 2007","keywords":["[--------|p]","multiprotocol label switching","generalized multiprotocol label switching","traffic engineered","te","lsp","label switched path"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC4920","errata_url":"https:\/\/www.rfc-editor.org\/errata\/rfc4920"}