Internet Draft Vadim Suraev Document: draft-suraev-mpls-globl-recov-enhm- KereniX 00.txt Expires: October 2001 April 2001 Global path recovery enhancement using Notify Reverse LSP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft proposes fault notification time improvement for CR-LSPs when using global recovery approach. This reduces the disadvantage of global recovery approach (slower) relative to local recovery approach while keeping global recovery more optimal from resource utilization, complexity and management point of view. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Terminology........................................................3 Introduction.......................................................3 Current fault notification.........................................4 RSVP-TE fault notification.........................................4 CR-LDP.............................................................4 Proposed enhancement...............................................4 LSR requirements for Notify Reverse LSP............................7 Notify Reverse LSP for unidirectional path protection setup........7 Notify Reverse LSP for bi-directional path protection setup........8 Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 1 April 2001 Notify Reverse LSP tear down.......................................8 Signaling extensions...............................................9 RSVP-TE extensions.................................................9 CR-LDP extensions.................................................10 Notify Reverse LSP Label Mapping Object processing................10 Notify Reverse LSP Label Release Object processing................10 Notify Reverse LSP Label Withdraw Object processing...............10 Unacceptable Notify Reverse LSP Label Mapping.....................10 Receiving Notify Reverse LSP ID Object without Notify Reverse LSP Label Mapping when Label does not exist for Notify Reverse LSP....11 Security Considerations...........................................11 References........................................................12 Author's Addresses................................................12 Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 2 April 2001 Terminology This draft mostly uses terms, defined in other drafts ([1], [4], [9]). However, some terms need to be defined/explained: FIN û Failure Interfacing Node. Means node, which cannot forward packets through required path due to path failure (may be outgoing link failure, next hop failure etc). PSL û Path Switch LSR. LSR, which can switch traffic from working path to backup path in protection purposes. Path û depend on context means path vector (ordered list of nodes) or LSP. LSP, LSP setup in context of RSVP-TE mean tunnel, tunnel setup. Introduction MPLS recovery framework discusses about various MPLS recovery principles. From topological point of view, path (LSP) recovery approaches can be classified as local recovery (switch over performed by interfacing with failed link/node node) and global recovery (switch over performed by Path Switch LSR (PSL [4])). PSL may be an Ingress router of LSP or any downstream LSR, able to switch traffic to recovery path. Note that there may be upstream and downstream PSLs since GMPLS allows bi-direction LSPs to be setup. So, each PSL may be responsible for protection switch in its own direction. The disadvantage of global recovery - it is slower because it requires FIS (fault indication signal) delivery from Failure Interfacing Node (FIN) to PSL. Notification time also depends on distance from FIN to PSL; notification time grows with distance from FIN to PSL (notification message is processed at each node on the way to PSL). Local protection is faster because it does not require FIS delivery û LSR, detecting fault switches traffic to pre-established backup path (LSP). Local recovery approach has also certain drawbacks: For entire path protection, it is required, each link/node along the path to be protected. For protection against node (or/and numbered link) failure, backup tunnels should be setup [8] around protected node. For protection against link failure (in case multiple unnumbered links), backup link should be either pre-defined (additional action (setting cross-connect and/or signaling) is required in case of failure before traffic may be sent. It may take 10s of milliseconds ([7])) or pre-signaled (traffic may be sent immediately in case of failure). So, backup path computation, signaling, and management may be significant to protect entire path. As mentioned above, global recovery is slower. Reducing fault notification time of PSL reduces this disadvantage. As notification time becomes shorter, global recovery becomes comparable to local recovery in terms of time and, therefore, loss. This draft proposes mechanism, improving notification time. Such improvement may attract to use only global recovery approach for less critical traffic while Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 3 April 2001 protecting most critical traffic using local recovery, probably in couple with global recovery. By reducing local recovery usage, path protection task may become less expensive in terms of resource utilization and management while keeping quality of protection near if local recovery technique is used. Current fault notification There is currently defined fault notification signaling for RSVP-TE and CR-LDP. RSVP-TE fault notification Generalized RSVP-TE signaling [9] introduces new message for RSVP û Notify message, which can be sent directly to node, which can switch traffic to backup path (Path Switch LSR - PSL), without router alert option (Ingress router can define, which LSR will serve as PSL. Ingress router can be itself PSL). Note that there may be upstream and downstream PSLs since GMPLS allows bi-directional LSPs. GMPLS also defines Notify Request message in purpose to propagate the IP address of node (Notify Node IP address), to which Notify message is to be sent. Notify Request may be included in Path (unidirectional and Forward part of bi-directional LSP) and in Resv (Backward part of bi-directional LSP). If Notify message is sent as native IP packet without router alert option, it is processed at each node (RSVP processing is not done, but IP header processing is performed) û IP header validation, lookup etc. Also, Notify message, which sent as native IP packet without route alert option, may take shortest path (distinct from reverse), which may be also failed due to node/link failure (if Notify message would travel in reverse to failed LSP direction, even if there are multiple link failures on the path LSP takes, Notify always would reach PSL (unless control channel between some pair of neighbors is also failed)). CR-LDP CR-LDP has LabelWithdraw message for failure notification of upstream LSRs. Each LDP message except Hello requires TCP connection existence (TCP connection is established between peers), which makes direct notification of PSL unavailable unless PSL is peer (directly connected or not). LabelWithdraw message is processed at each node (till it reaches Ingress): IP header, TCP & LDP processing is done. There is no mechanism for direct PSL notification about failure. Proposed enhancement This draft proposes the following enhancement for fast fault notification: LSP for Notification messages in reverse to protected LSP direction (Notify Reverse LSP) should be setup: a). In case of unidirectional LSP or in case of bi-directional LSP in forward direction - between Egress to PSL (Figures 1 & 3); Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 4 April 2001 b). In case of bi-directional LSP - in forward direction as in a) and in backward direction - between Ingress to PSL (Figures 2 & 4). Notify Reverse LSP can be defined as interface to destination PSL. To make Notify messages delivery more reliable (reduce Notify message drop), only control messages should be sent over Notify Reverse LSP, and each LSR should recognize (by label) the packets, related to Notify Reverse LSP and probably to apply an appropriated queuing behaviour. Notify Reverse LSP may be used for failure notification of multiple protected LSPs in case PSL -> Egress path is same (i.e. same nodes in same order). PSL must not setup more than one Notify Reverse LSP on the same path. LSP initiator defines PSL (node, capable to switch traffic to backup LSP) by insertion of Notify Request object with Notify Node IP address û IP address of PSL. Each node below PSL, when detects LSP failure (link failure etc), should sent Notify message to PSL using Notify Reverse LSP. For example (Figure 1), if B detects that link B->C is failed, B should send Notify (if requested by I) to PSL (in this case I) using Notify Reverse LSP. Another example (Figure 3): if C detects that link C->E is failed, C should send Notify message (if requested by I) to PSL (LSR A) using Notify Reverse LSP. Same behaviour should be expected in case of bi-directional LSPs (Figure 2,4): if B detects that link B->C became failed, B should send Notify (if requested by I) to PSL (I at Figure 2, A at Figure 4); if B detects, that link B->A became failed, B should send Notify (if requested by E) to PSL (E at Figure 2, C at Figure 4). ---- ---- ---- ---- ---- | I |<-----| A |<-----| B |<--- | C |<----| E | | |=====>| |=====>| |====>| |====>| | ----\ ---- ---- ---- ---- \ \Alternative (backup) Path \ <------ Notify Reverse LSP =====> Unidirectional LSP Figure 1. Notify Reverse LSP for unidirectional LSP, Ingress I is PSL. Alternative (backup) path \ \ \ ---- <------ ---- <-------- ---- <------ ---- <-----\---- | |:-:-:->| |:-:-:-:->| |-:-:-->| |-:-:->| | | I |<=:=:=:| A |<=:=:=:=:| B |<=:=:=:| C |<=:=:=| E | | |======>| |========>| |======>| |=====>| | ----\ ---- ---- ---- ---- Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 5 April 2001 \ \Alternative (backup) Path \ <------ Notify Reverse LSP for Forward direction of bi-directional LSP :-:-:-> Notify Reverse LSP for Backward direction of bi-directional LSP ======> Forward direction of bi-directional LSP <=:=:=:= Backward direction of bi-directional LSP Figure 2. Notify Reverse LSP for bi-directional LSP, Ingress I is PSL for Forward direction of bi-directional LSP, Egress E is PSL for Backward direction of bi-directional LSP. ---- ---- ---- ---- ---- | I | | A |<-----| B |<--- | C |<----| E | | |=====>| |=====>| |====>| |====>| | ---- ----\ ---- ---- ---- \ \Alternative (backup) Path \ <------ Notify Reverse LSP =====> Unidirectional LSP Figure 3. Notify Reverse LSP for unidirectional LSP, LSR A is PSL. \ \Alternative (backup) Path \ ---- ---- <-------- ---- <------\---- <----- ---- | |:-:-:->| |:-:-:-:->| |-:-:-->| | | | | I |<=:=:=:| A |<=:=:=:=:| B |<=:=:=:| C |<=:=:=| E | | |======>| |========>| |======>| |=====>| | ---- ----\ ---- ---- ---- \ \Alternative (backup) Path \ <------ Notify Reverse LSP for Forward direction of bi-directional LSP :-:-:-> Notify Reverse LSP for Backward direction of bi-directional LSP ======> Forward part of bi-directional LSP <=:=:=:= Backward part of bi-directional LSP Figure 4. Notify Reverse LSP for bi-directional LSP, Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 6 April 2001 LSR A is PSL for Forward direction of bi-directional LSP LSR C is PSL for Backward direction of bi-directional LSP. As it described in [9], when LSP (tunnel) is setup/modified, Ingress may insert Notify Request object into Path message (unidirectional LSP and Forward direction of bi-directional LSP). Egress may insert Notify request into Resv message (Backward direction of bi- directional LSP). Notify request object defines IP address of PSL, to which Notification should be sent. Note that Ingress may define itself as PSL (Egress may define itself as PSL for LSP in backward direction). So, PSL is responsible to setup Notify Reverse LSP. If PSL is not Ingress, LSR, one of IP addresses of which matches Notify Node Address, identifies itself as PSL. LSR requirements for Notify Reverse LSP In purpose to support fast fault notification using Notify Reverse LSP, LSR should: a). Have MPLS forwarding capability (perform label swapping, push and pop); b). To support signaling extensions; Any pair of LSRs on the protected path should have at least one bi- directional channel (over which Notify Reverse LSP may pass). The bi-directional channel existence is inherent requirement (MPLS signaling protocols already need it). Notify Reverse LSP for unidirectional path protection setup There may be two cases: a). Protected LSP is fully explicitly routed (complete route provided) and: b). Protected LSP is partially/loosely explicitly routed. For first case, before Path sent/forwarded, PSL should check before sending Path message if there is Notify Reverse LSP on this path (same nodes in same order between Egress to PSL, in backward direction). If there is no, Notify Reverse LSP is setup with protected LSP. The labels for Notify Reverse LSP are propagated by insertion of Notify Reverse LSP Label Mapping Object into Path message (see below) like if Label Request was pending (arrived before from Egress). Notify Reverse LSP identifier (Notify Reverse LSP ID) is also allocated by PSL and inserted into Path message. If there is already Notify Reverse LSP (in case it was setup once together with some other protected LSP), only Notify Reverse LSP identifier (Notify Reverse LSP ID) is propagated with Path message in purpose protected LSP will be associated with Notify Reverse LSP (each LSR then makes this association). For second case, before Path sent/forwarded, PSL requests to record actual LSP route by insertion of RRO into Path message. When Resv message arrives back to PSL, PSL does know LSPÆs actual route and then sends Path message again (performs pseudo-modification û Path Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 7 April 2001 message sent with same as in first time parameters (traffic, preemption etc), but with explicit route û returned actual LSP route) with insertion of Notify Reverse LSP Label Mapping Object and Notify Reverse LSP ID Object (in purpose Notify Reverse LSP setup, if Notify Reverse LSP does not exist on the path) or only Notify Reverse LSP ID Object (if Notify Reverse LSP already exists). PSL should track the mapping between protected LSPs (which traverse this PSL) and Notify Reverse LSP. PSL should keep also a list of hops (path) Notify Reverse LSP traverses in purpose to determine Notify Reverse LSP existence when required. Notify Reverse LSP ID is required for: a). Notify Reverse LSP association with protected LSP (labels for Notify Reverse LSP are propagated once); b). To check Notify Reverse LSP existence on certain path and if needed to setup there Notify Reverse LSP (to distinct between two Notify Reverse LSPs between PSL and Egress/Ingress, do not traverse exactly same path (nodes)); Notify Reverse LSP for bi-directional path protection setup Backward direction Notify Reverse LSP (from Ingress to PSL): Ingress should insert record route object when Path message sent. When Path message arrives to Egress, Egress will examine recorded route and determine if Notify Reverse LSP exists for this path. Setting up Notify Reverse LSP in Egress -> PSL direction does not differ from setting up Notify Reverse LSP in case of unidirectional LSP. Notify Reverse LSP tear down When node initiates/receives RTEAR/ResvErr message, it checks if node is PSL for LSP which torn down. If yes, node checks is there associated Notify Reverse LSP with LSP, for which RTEAR/ResvErr message is received. If LSP, for which RTEAR/ResvErr message is received, is last which is associated with Notify Reverse LSP, PSL must include the Notify Reverse LSP Label Withdraw (Notify Reverse LSP Label Release if PSL for backward direction of bi-directional LSP) with value of Notify Reverse LSP label into RTEAR/ResvErr message. When node initiates/receives PTEAR/PathErr message, it checks if node is PSL for LSP, for which PTEAR/PathErr message is received. If yes, node checks is there associated Notify Reverse LSP with LSP, for which PTEAR/PathErr message is received. If LSP, for which PTEAR/PathErr message is received, is last which is associated with Notify Reverse LSP, PSL must include the Notify Reverse LSP Label Release (Notify Reverse LSP Label Withdraw if PSL for backward direction of bi-directional LSP) with value of Notify Reverse LSP label into PTEAR/PathErr message. Note that node, detecting LSP (tunnel) failure, must send Notify message to Notify Node (using Notify Reverse LSP) before PathErr/ResvErr sending is initiated (label for Notify Reverse LSP is released). Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 8 April 2001 Signaling extensions Minor signaling extension to existing signaling protocols is required to support Notify reverse LSPs. RSVP-TE extensions Following Objects must be defined to support Notify reverse LSP signaling extensions: a). Notify Reverse LSP Label Mapping; Class = NotifyReverseLabel (TBD), C-Type = 1 (Mapping); 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notify Reverse Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ b). Notify Reverse LSP Label Release; Class = NotifyReverseLabel (TBD), C-Type = 2 (Release); 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notify Reverse Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c). Notify Reverse LSP Label Withdraw; Class = NotifyReverseLabel (TBD), C-Type = 3 (Withdraw); 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notify Reverse Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d). Notify Reverse LSP ID; Class = NotifyReverseLSPID (TBD), C-Type = 1 (LSP ID); 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notify Reverse LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e). Notify Reverse LSP ID Not Exists; Class = NotifyReverseLSPID (TBD), C-Type = 2 (LSP ID error); Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 9 April 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notify Reverse LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CR-LDP extensions Due to LDP messages, except Hello, require TCP connection, which may not exist between FIN and PSL, currently extensions to CR-LDP are not defined. Notify Reverse LSP Label Mapping Object processing If Path message received with Notify Reverse LSP Label Mapping Object, incoming (incoming - for Path. For Notify Reverse LSP is outgoing) interface and label should be stored as in case of normal label mapping received. If by protected LSP setup, interface through which label mapping (for Notify Reserve LSP) is received, becomes non-PSC capable (cross-connect established), it is assumed that Notify Reverse LSPÆs packets will be sent over some default control channel (between adjacent nodes). Node, which is propagating this Label Mapping, should provide Label uniqueness. If node is not Egress (for protected LSP), node should allocate outgoing Label and track an outgoing label and outgoing interface (outgoing - for Path. For Notify Reverse LSP is incoming) as in case of normal label mapping received with Resv. Outgoing interface (outgoing for Path) is outgoing interface of Path message in case interface does not become non-PSC by protected LSP setup. Otherwise default control channel should be assumed as incoming interface of Notify Reverse LSP. In case of Notify Reverse LSP Label Mapping Object exists in Resv message (Backward direction for bi-directional LSP), just see Resv instead of Path in procedure above. Notify Reverse LSP Label Release Object processing Label with value of Notify Reverse LSP Label Release Object must be released. See also Notify Reverse LSP tear down procedure. Notify Reverse LSP Label Withdraw Object processing Label with value of Notify Reverse LSP Label Withdraw Object must be released. See also Notify Reverse LSP tear down procedure. Unacceptable Notify Reverse LSP Label Mapping It is unlikely, but if due to some reason Notify Reverse LSP Label Mapping cannot be accepted by node, node must not propagate Notify Reverse LSP Label Mapping Object. When Resv received for this LSP, node must propagate Notify Reverse LSP Label Release Object with Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 10 April 2001 value of label received. In case of Notify Reverse LSP for backward direction of bi-directional LSP, Notify Reverse LSP Label Release Object must be included into Path message. Receiving Notify Reverse LSP ID Object without Notify Reverse LSP Label Mapping when Label does not exist for Notify Reverse LSP In case of due to some reason all protected by the Notify Reverse LSP LSPs were torn down and, therefore, Notify Reverse LSP is also torn down (probably, not by PSL), but PSL has not up-to-date information (that such Notify Reverse LSP exists), Receiving Notify Reverse LSP ID Object should not be propagated with Path message. When Resv received for this LSP, Notify Reverse LSP ID Not Exists Object should be inserted. On reception Resv with such object, PSL may repeat Notify Reverse LSP setup procedure as described above. Security Considerations No additional security risks are posed. Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 11 April 2001 References [1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [2] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [3] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", RFC 3036, January 2001. [4] Vishal Sharma, et al, "Framework for MPLS-based Recovery", draft-ietf-mpls-recovery-frmwrk-02.txt, work in progress. [5] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, Work in Progress, August 2000. [6] Jamoussi, B. et al "Constraint-Based LSP Setup using LDP", Internet Draft draft-ietf-mpls-cr-ldp-04.txt, Work in Progress, July 2000. [7] ôGeneralized Multi-Protocol Label Switching (GMPLS) Architectureö, Draft, draft-many-gmpls-architecture-00.txt, Work in Progress, February 2001. [8] Goguen, R. and Swallow, G., ôRSVP Label Allocation for Backup Tunnelsö, draft-swallow-rsvp-bypass-label-00.txt, work in progress, October 1999. [9] Berger, Ashwood-Smith, editors ôGeneralized MPLS Signaling û RSVP- TE Extensionsö, draft-ietf-mpls-generalized-rsvp-te-00.txt, work in progress, November 2000. [10] Chang et al. ôA Path Protection/Restoration Mechanism for MPLS Networksö, draft-chang-mpls-path-protection-02.txt, work in progress, November 2000. Author's Addresses Vadim Suraev KereniX 70 Pinsker St. POB 10053 Phone: 972-3-905-0830 Petach-Tikva, Israel Email: Vadim_suraev@kerenix.com Suraev Expires October 2001 Global path recovery enhancement using Notify Reverse LSP 12