Network Working Group S. Kini Internet Draft A. Liu Intended status: Standards Track Ericsson Expires: August 2010 February 22, 2010 A fast LSP-alert Mechanism draft-kini-mpls-fast-lsp-alert-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 This Internet-Draft will expire on August 22, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kini & Liu Expires August 22, 2010 [Page 1] Internet-Draft A fast LSP-alert Mechanism February 2010 Abstract There are applications (e.g. fault-management, OAM) that need to alert LSRs along an LSP path. TTL expiry and GAL are currently defined mechanisms. An invocation of such a mechanism alerts a single LSR. When multiple LSRs along the LSP need to be alerted, multiple messages may have to be generated. Also, messages may have to be processed and forwarded hop-by-hop by the control plane. In fault recovery scenarios where multiple LSRs need to be alerted this increases the recovery time and hence the traffic loss. This document defines a simple and fast mechanism that allows all the LSRs along a LSP to be alerted with a single message. Table of Contents 1. Introduction ..................................................2 2. Conventions used in this document .............................3 3. Packet Format .................................................3 4. Packet processing .............................................3 4.1. Origination ..............................................3 4.2. Receiving and Forwarding .................................4 4.3. Example ..................................................5 5. Addressing in ACH TLVs and G-Ach Message ......................5 6. Applicability to LSP types ....................................6 7. Security Considerations .......................................6 8. IANA Considerations ...........................................6 9. References ....................................................6 9.1. Normative References .....................................6 9.2. Informative References ...................................6 10. Acknowledgments ..............................................7 1. Introduction [RFC5586] defines a Generic Associated Channel (G-Ach) that can be used for Operations, Administration, and Maintenance (OAM) functions. The label encoding/processing rules defined in [RFC3032] along with the G-Ach defined in [RFC5586] can be used to deliver an alert message to a LSR along the LSP. Certain applications require a message to be delivered to multiple LSRs along the LSP. In such a case multiple messages have to be generated (one per LSR). Alternatively, the message could be received and forwarded hop-by-hop by an LSR. If this forwarding is based on an address formatted in the ACH TLVs or the G-Ach message, then the forwarding may have to be done in the slow path (control plane). In fault recovery scenarios this increases Kini & Liu Expires August 22, 2010 [Page 2] Internet-Draft A fast LSP-alert Mechanism February 2010 the time required to do the protection switch and consequently increases traffic loss. This document defines a simple and fast mechanism to alert multiple LSRs along a LSP. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Packet Format This document uses a reserved bit of the ACH defined in [RFC5586]. This bit is henceforth referred to as the `Fast LSP Alert bit' or FLA-bit for short. The 16th bit is defined as the FLA-bit and the resultant ACH is shown below 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved |X| Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X = FLA-bit Figure 1 ACH with FLA-bit 4. Packet processing This section describes the rules for origination, receiving and forwarding the packet with FLA-bit set. It is also illustrated via an example in Section 4.3. below. 4.1. Origination When a LSR has a message that has to be delivered (using G-Ach) to multiple LSRs along the LSP, it generates a packet by setting the FLA-bit in the ACH. In the outer Label (i.e., LSP label) the TTL is set to 1 and S-bit is 0. The GAL should have TTL set to the number of LSRs along the LSP that need to be alerted. If the number of LSRs is not known apriori, then the TTL must be set to 255. The GAL's S-bit must be set to 1. Kini & Liu Expires August 22, 2010 [Page 3] Internet-Draft A fast LSP-alert Mechanism February 2010 4.2. Receiving and Forwarding When a LSR receives a packet with LSP label's TTL=1 it is identified as an alert packet. Since S=0, the next label in the label stack (in this case the GAL) is processed. If the GAL's TTL is 0, the packet is dropped. Else, the packet is treated as an alert packet for the local LSR. In addition, if the FLA-bit is set, the GAL's TTL is decremented by 1. If the LSR is not a terminating LSR of the LSP and the decremented GAL TTL is > 0, a copy of the packet is forwarded to the next LSR along the LSP. The forwarding should follow the same rules as for any data packet of that LSP. The notable difference is that the LSP label's TTL is set to 1 and the GAL TTL is lesser by 1 (compared to the GAL's TTL in the incoming packet). If the LSR is the termination point for the LSP then the packet is not forwarded. Kini & Liu Expires August 22, 2010 [Page 4] Internet-Draft A fast LSP-alert Mechanism February 2010 4.3. Example L1-----------------L2-------------------L3-------------------L4 ----> ----> ----> +-----------+ +-----------+ +-----------+ |LSP1 Label1| |LSP1 Label2| |LSP1 Label3| |S=0 TTL=1 | |S=0 TTL=1 | |S=0 TTL=1 | |-----------| |-----------| |-----------| |GAL | |GAL | |GAL | |S=1 TTL=255| |S=1 TTL=254| |S=1 TTL=253| |-----------| |-----------| |-----------| |ACH | |ACH | |ACH | |FLA-bit=1 | |FLA-bit=1 | |FLA-bit=1 | |-----------| |-----------| |-----------| | ACH TLV | | ACH TLV | | ACH TLV | |Header/TLVs| |Header/TLVs| |Header/TLVs| |if present | |if present | |if present | |-----------| |-----------| |-----------| | G-Ach | | G-Ach | | G-Ach | | Message | | Message | | Message | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ Figure 2 Fast LSP-alert packet traversal L1-4 are LSRs and an LSP (LSP1) is routed along L1->L2->L3->L4. L1 needs to send a message (on G-Ach) that has to be delivered to LSRs (L2, L3, L4) along the LSP. It generates the message in the G-Ach with FLA-bit set. In this example the GAL TTL is set to 255. The packet as it traverses the LSP is shown in Figure 2. Each of the LSRs along the LSP delivers the packet locally as an alert packet and also sends a copy of the packet (with the GAL TTL decremented) along the LSP. 5. Addressing in ACH TLVs and G-Ach Message The mechanism described in this document is independent of any addressing scheme of the ACH TLVs or the G-Ach message. Since the same message is delivered as an alert packet to multiple LSRs, any address that indicates where this message must be processed, must be chosen such that it is accepted by each of those LSRs for local processing. This document borrows on the Kini & Liu Expires August 22, 2010 [Page 5] Internet-Draft A fast LSP-alert Mechanism February 2010 requirements in [RFC4379] and places the following requirements on addressing: 1. The likelihood that this alert message is delivered to a user of the service should be kept to an absolute minimum. 2. The alert message must not be forwarded further based on the address in the ACH TLVs or the G-Ach message. For `Channel Type' IPv4, an address from the 127/8 range should be used. For `Channel Type' IPv6 an address from the same range embedded in as IPv4-mapped IPv6 address should be used. For additional `Channel Types', addresses that satisfy the above stated requirements should be used. 6. Applicability to LSP types The mechanism described in this document is applicable to point- to-point as well as point-to-multipoint TE tunnels. Applicability to other types of LSPs is for further study. 7. Security Considerations The security considerations in [RFC5586] are applicable. An additional consideration is loops. That is prevented using the GAL TTL. 8. IANA Considerations IANA should allocate a reserved bit in the ACH as the FLA-bit. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC 5586, June 2009. 9.2. Informative References [RFC4379] Kompella, K., et al, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Kini & Liu Expires August 22, 2010 [Page 6] Internet-Draft A fast LSP-alert Mechanism February 2010 [RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, January 2001. 10. Acknowledgments The authors would like to thank Marc Rapoport for his comments. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Sriganesh Kini Ericsson 300 Holger Way, San Jose, CA 95134 Email: sriganesh.kini@ericsson.com Autumn Liu Ericsson 300 Holger Way, San Jose, CA 95134 Email: autumn.liu@ericsson.com Kini & Liu Expires August 22, 2010 [Page 7]