MPLS Working Group S. Kini Internet-Draft A. Liu Intended Status: Standards Track Ericsson Expires: January 2011 July 12, 2010 A fast LSP-alert Mechanism draft-kini-mpls-fast-lsp-alert-01.txt Status of this Memo Distribution of this memo is unlimited. 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 January 13, 2011. 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. Kini & Liu Expires January 2011 [Page 1] Internet Draft A fast LSP-alert Mechanism July 12, 2006 Abstract There are applications (e.g. fault-management, OAM) that need to alert LSRs along an LSP. Currently defined alert mechanisms for labeled packets (e.g., TTL expiry, GAL, etc) alert a single LSR along the LSP with one alert message. To alert multiple LSRs along the LSP, multiple alert messages have to be generated. This results in increasing delays in generating the message as the number of LSRs increase. If the message is used to recover from faults, it results in increasing traffic loss. This document defines a simple and fast mechanism that can alert all the LSRs along a LSP. Kini & Liu Expires January 2011 [Page 2] Internet Draft A fast LSP-alert Mechanism July 12, 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Packet processing . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Origination . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Receiving and Forwarding . . . . . . . . . . . . . . 5 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Addressing in ACH TLVs and G-ACh Message . . . . . . . . . . . 7 5. Applicability to LSP types . . . . . . . . . . . . . . . . . . 7 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Kini & Liu Expires January 2011 [Page 3] Internet Draft A fast LSP-alert Mechanism July 12, 2006 1. Introduction MPLS defines mechanisms to alert a LSR to perform exception processing on a labeled packet. The trigger for the exception processing is based on TTL expiry and/or an alert label. OAM applications can use these mechanisms to perform application specific functions. A typical application is MPLS ping described in [RFC4379]. Some OAM applications require multiple LSRs along a LSP to be alerted. When the application is doing fault recovery it is important to deliver the alert message quickly to the LSR(s) that performs the recovery action so that traffic loss is minimized. If the message is generated as a labeled packet the currently defined alert mechanisms can alert only a single LSR along the LSP. When the application requires multiple LSRs along the LSP to be alerted, multiple messages (one per LSR) must be generated. This causes delays and consequently increased traffic loss. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Solution This solution is designed such that a single message originated by an LSR is delivered to multiple LSRs along the LSP. To do this, intermediate LSRs have to create a copy of the incoming packet for local processing and at the same time forward the packet to another LSR. The semantics of the packet processing, encoding and addressing to achieve this uses currently defined MPLS mechanisms as much as possible. A Generic Associated Channel (G-ACh) is defined in [RFC5586] and can be used to encode OAM messages for an LSP. The solution defined in this document uses the G-ACh to encode an alert message and defines additional mechanisms such that a single G-ACh message is delivered to multiple LSRs along the LSP. In order to quickly deliver a G-ACh message to multiple LSRs along the LSP, the forwarding semantics of a labeled packet on the LSP is used. This is combined with the existing MPLS alert mechanism that uses TTL expiry. To effect the combined semantics, the TTL in the GAL is used to preserve the TTL semantics of MPLS forwarding whereas the TTL (expiry) of the LSP label is used to deliver the packet locally. A bit in the ACH is used to indicate that the packet has to be locally delivered as well as forwarded along the LSP. This bit is Kini & Liu Expires January 2011 [Page 4] Internet Draft A fast LSP-alert Mechanism July 12, 2006 henceforth referred to as Fast-LSP-Alert bit or FLA-bit. The solution is designed to be simple so that it can be easily implemented in hardware. Implementations that are incapable of doing this in hardware should implement it in firmware. The details of the packet format are described in section 3.1. Packet processing procedures are described in section 3.2. 3.1. Packet Format The 16th bit in the ACH is suggested to be defined (by IANA) 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 3.2. Packet processing This section describes the rules for origination, receiving and forwarding a G-ACh message with FLA-bit set. It is also illustrated via an example in Section 3.3. 3.2.1. Origination When a LSR originates an alert message that has to be delivered to multiple LSRs along the LSP, it encodes it as a G-ACh message for the LSP (with GAL at the bottom of the stack) and sets the FLA-bit in the ACH. In the outer Label (i.e., LSP label) the TTL is set to 1. The GAL's TTL SHOULD be set to 255 if all LSRs along the LSP have to be alerted. If not all LSRs need to be alerted then the GAL's TTL MUST be set to the number of LSRs that need to be alerted. 3.2.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 a G-ACh message to be processed by the local LSR. All of these processing steps are currently defined in MPLS. Kini & Liu Expires January 2011 [Page 5] Internet Draft A fast LSP-alert Mechanism July 12, 2006 This document defines an additional step when processing the ACH. If the FLA-bit is set and the Incoming Label Map (ILM) entry indicates that the packet must be forwarded along the LSP, an additional copy of the packet MUST be made. For this copy of the packet the GAL's TTL is processed as would have been done on an incoming packet's LSP label TTL. Following a successful TTL processing, the labeled packet (with the LSP label stacked on top of the GAL) is operated in accordance with the ILM. An LSP label on the forwarded packet MUST continue to have TTL set to 1. Thus the difference in the TTL between the incoming and outgoing packet is that the outgoing packet would have the GAL's TTL decremented. 3.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 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's traversal along the LSP's G-ACh is shown in Figure 2. Each of the LSRs along the LSP delivers the packet locally as an alert message and also sends a copy of the packet (with the GAL TTL decremented) along the LSP. Kini & Liu Expires January 2011 [Page 6] Internet Draft A fast LSP-alert Mechanism July 12, 2006 4. 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 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 G-ACh Channel Type IPv4, an address from the 127/8 range should be used. For G-ACh 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. 5. Applicability to LSP types The mechanism described in this document is applicable to point-to- point as well as point-to-multipoint TE tunnels that have G-ACh (using GAL) enabled. Applicability to other types of LSPs is for further study. 6. Future Work If an LSR does not support FLA-bit then it would not make a copy of the packet to forward. To address this an LSR that supports the FLA- bit and has a neighbor that doesn't, can set the LSP label TTL such that it skips such LSRs. If the LSP is statically configured the outgoing TTL to be set such that non supporting LSRs are skipped, can be configured. If the LSP is signaled then the RRO object can be used to detect the number of LSRs to be skipped. Defining the objects and procedures to do this is for future study. 7. Security Considerations The security considerations in [RFC5586] are applicable. An additional consideration is loops. That is prevented using the GAL TTL. Kini & Liu Expires January 2011 [Page 7] Internet Draft A fast LSP-alert Mechanism July 12, 2006 8. IANA Considerations IANA should allocate a reserved bit in the ACH as the FLA-bit. 9. Conclusion This document defines a mechanism that by which messages can be quickly delivered to multiple LSRs along a LSP. It re-uses currently defined MPLS mechanisms and keeps the principles of MPLS forwarding intact. A reserved bit in the ACH is defined to enable forwarding a copy of the packet. This change is defined to be simple enough to enable implementation in hardware or firmware. 10. References 10.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. 10.2. Informative References [RFC4379] Kompella, K., et al, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, January 2001. 11. Acknowledgements The authors would like to thank Marc Rapoport for his comments. Kini & Liu Expires January 2011 [Page 8] Internet Draft A fast LSP-alert Mechanism July 12, 2006 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 January 2011 [Page 9]