Network Working Group N. Bahadur, Ed. Internet-Draft K. Kompella, Ed. Intended status: Standards Track Juniper Networks, Inc. Expires: January 2, 2008 July 1, 2007 Mechanism for performing LSP-Ping over MPLS tunnels draft-nitinb-lsp-ping-over-mpls-tunnel-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes methods for performing lsp-ping traceroute over mpls tunnels. The techniques outlined in RFC 4379 fail to perform correct traceroute validation and path discovery for a LSP that goes over other mpls tunnels. This document describes new procedures that can be used in conjunction with the standard procedures described in RFC 4379 to trace such LSPs. Bahadur & Kompella Expires January 2, 2008 [Page 1] Internet-Draft LSP-Ping over MPLS tunnel July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Modification to Downstream map TLV . . . . . . . . . . . . 4 3.3. Downstream FEC Stack TLV . . . . . . . . . . . . . . . . . 4 4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 6 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 6 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 6 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 6 4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 7 4.2.1. Handling of FEC Stack TLV . . . . . . . . . . . . . . 7 4.2.1.1. No Downstream FEC Stack TLV . . . . . . . . . . . 7 4.2.1.2. Downstream FEC Stack TLV . . . . . . . . . . . . . 7 4.2.2. Modifications to handling to EGRESS_OK responses. . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Bahadur & Kompella Expires January 2, 2008 [Page 2] Internet-Draft LSP-Ping over MPLS tunnel July 2007 1. Introduction This documents describes methods for performing lsp-ping traceroute over mpls tunnels. The techniques outlined in [1] outline a traceroute mechanism that includes FEC validation and ECMP path discovery. Those mechanisms fail in case the FEC being traced traverses one or more mpls tunnels. This document uses the existing definitions of [1] to define a mechanism using which a traceroute request can correctly traverse mpls tunnels with proper FEC and label validations. 1.1. 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 [2]. 2. Motivation A LSP-Ping traceroute may cross multiple mpls tunnels en-route the destination. Let us consider a simple case. A B C D E o -------- o -------- o --------- o --------- o LDP RSVP RSVP LDP LDP LDP Figure 1: LDP over RSVP tunnel When a traceroute is initiated from router A, router B returns downstream mapping information for node C in the echo-response. The next echo request reaches router C with a LDP FEC. Node C is a pure RSVP node and does not run LDP. So it will return back an error of NO_MAPPING (4). It is not prudent for C to ignore FEC validation and determine next-hop information based on incoming label stack in the echo request. It SHOULD do the FEC validation to catch any misrouted echo-requests. When A receives an error from C, it will be unable to proceed with the trace and this can give the incorrect impression of a fault in the network. The above problem can be extended for a generic case of tunnel over tunnel or multiple tunnels (e.g. B-C can be a separate RSVP tunnel and C-D can be a separate RSVP tunnel). The problem of FEC validation can be solved if the transit routers (router B in the above example) provide some hint or information to the ingress regarding the start of a new tunnel. Bahadur & Kompella Expires January 2, 2008 [Page 3] Internet-Draft LSP-Ping over MPLS tunnel July 2007 3. Packet format 3.1. Introduction The problem of providing more information in a lsping echo response can be solved in multiple ways. 1. A new flag has been added to the DSMAP TLV which indicates there is more data associated with the TLV. A new TLV (Downstream FEC Stack TLV) has been added which can be co-related uniquely to a DSMAP TLV in the echo response. There can be only 1 such TLV associated with a DSMAP TLV. 3.2. Modification to Downstream map TLV The modification described in section is based on Section 3.1, approach 1. The downstream mapping TLV (TLV 2) defined in [1] has been enhanced to include a new flag in the DS Flags field. The new field definition is as below. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Rsvd(MBZ)|F|I|N| +-+-+-+-+-+-+-+-+ Flag Name and Meaning ---- ---------------- F This flags should NOT be set in an echo request. If set in an echo request, it should be ignored. In an echo response, when this flag is set, it indicates that a Downstream FEC Stack TLV associated with this Downstream TLV is present in the echo response. Figure 2: DS Flags 3.3. Downstream FEC Stack TLV A new TLV is introduced. The TLV type is pending IANA allocation. A router SHOULD include the the downstream FEC stack TLV when the downstream node in the echo response will go over a tunnel (i.e. a new FEC). The F flag in the DS-Flags fields (Figure 2) in the corresponding downstream map TLV MUST also be set. The contents of this TLV very similar to the contents of the Target FEC Stack TLV. The format is as below. Bahadur & Kompella Expires January 2, 2008 [Page 4] Internet-Draft LSP-Ping over MPLS tunnel July 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type |Reserved (MBZ) | FEC stack length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Interface Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (FEC Stack) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Downstream FEC Stack TLV Address Type The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the Downstream IP Address and Downstream Interface fields. It's usage is same as that in the Downstream Map TLV. It MUST be the same as that specified in the Downstream Map TLV with which this TLV is associated. FEC Stack Length Length in bytes of the FEC stack. Downstream IP Address It MUST be the same as that specified in the Downstream Map TLV with which this TLV is associated. Downstream Interface Address It MUST be the same as that specified in the Downstream Map TLV with which this TLV is associated. FEC Stack The FEC Stack is a list of sub-TLVs (like the Target FEC Stack). The number of elements is determined by looking at the sub-TLV length fields. Bahadur & Kompella Expires January 2, 2008 [Page 5] Internet-Draft LSP-Ping over MPLS tunnel July 2007 4. Performing lsp-ping traceroute on tunnels This section describes the procedures to be followed by an ingress node and transit nodes when performing lsp-ping traceroute over mpls tunnels. 4.1. Transit node procedure 4.1.1. Addition of a new tunnel A transit node (Figure 1) knows when that the FEC being traced is going to enter a tunnel at that node. Thus, it knows about the new outer FEC. All transit nodes that are the origination point of a new tunnel SHOULD include a Downstream FEC stack TLV (Section 3.3) in the echo-response. The transit node should construct by FEC stack by copying the contents of target FEC stack ([1], Section 3.2) received in the echo request and appending the FEC of the new tunnel to that. The downstream mapping TLV (in the echo response) that corresponds to the Downstream FEC stack TLV should have the F bit (Figure 2) set in the DS Flags. If the transit node wishes to hide the nature of the tunnel from the ingress of the echo-request, then it MAY not want to send details about the new tunnel FEC to the ingress. In such a case, the transit node SHOULD use the NIL FEC. So the echo response would contain a Downstream FEC stack TLV containing the FEC stack received in the echo request, appended with a NIL FEC. The value of the label in the NIL FEC MUST be set to zero. One Downstream FEC Stack TLV SHOULD be included for each new tunnel originating from the transit node. 4.1.2. Transition between tunnels Consider the case in Figure 1, and B--C and C--D are 2 separate RSVP tunnels. In such a case, based on the data in the echo request packet, node C may or may not know that the lsp being traced is at the end of tunnel B--C and at the start of tunnel C--D. If node B was performing tunnel hiding (i.e. it sent a NIL FEC for the B--C tunnel in it's echo response), then node C should NOT add a new NIL FEC in the echo response. Addition of a NIL FEC would cause the ingress to treat C--D as a tunnel over B--C, instead of peer tunnels. However, in the case where the number downstream labels from C--D increases (over the number of labels in the incoming request) due to VPNs or some other reason, then node C MUST include a NIL FEC to account for the extra label. Note that if FEC hiding (via use of NIL FECs) is in use, then all Bahadur & Kompella Expires January 2, 2008 [Page 6] Internet-Draft LSP-Ping over MPLS tunnel July 2007 subsequent tunnels over the existing path MUST use a stack of NIL FECs. This is to avoid intermixing of NIL FECs and non-NIL FECs. The above applies only if the outermost FEC is the NIL FEC. i.e. if a FEC stack contains: LDP-FEC, NIL-FEC, RSVP-FEC, then the transit node can insert either a NIL FEC or a non-NIL FEC to represent a new tunnel. 4.2. Ingress node procedure It is the responsibility of an ingress node to understand tunnel within tunnel semantics when performing a lsp traceroute. This section describes the ingress node procedure based on the kind of response an ingress node receives from a transit node. 4.2.1. Handling of FEC Stack TLV 4.2.1.1. No Downstream FEC Stack TLV This would be the default behavior as described in [1]. The ingress node MUST perform echo response processing as per the procedures in [1]. 4.2.1.2. Downstream FEC Stack TLV If a Downstream FEC stack TLV (Section 3.3) is received in the echo response, the ingress node SHOULD process it and perform some validation. Each TLV must be validated as follows: found = FALSE for_each_downstream_map_tlv if address_type, ip_addr and interface_addr in the downstream_map_tlv match those in the downstream_fec_stack_tlv found = TRUE if found == FALSE ignore this downstream fec stack tlv Downstream FEC stack TLV validation procedure The ingress node SHOULD compare the FEC stack with the FEC stack that it believes it is tracing. The ingress node knows this from the FEC stack it sent in the echo request to the node that just responded. If the FEC stack contained in the FEC data section of the TLV is the same as the Target FEC stack sent in the echo request, then nothing Bahadur & Kompella Expires January 2, 2008 [Page 7] Internet-Draft LSP-Ping over MPLS tunnel July 2007 needs to be done. An echo request contains new FEC(s) if the FEC stack in the echo response contains the Target FEC stack ( of the echo request ) followed by more FEC(s). In such a case, the ingress node SHOULD save the new FEC(s) and associate them with the path being traced. The next echo request along the same path should include these FECs. A non-NIL FEC guarantees that the next echo request along the same path will have the DSMAP validated for IP address and Interface address mismatch. An echo response might contain a FEC stack that contains fewer FECs than those sent in the echo request. If any of the missing FEC is a non-NIL FEC, then the packet should be discarded and treated as an error. If the missing FECs are all NIL FECs, then this is an implicit sign that the tunnel associated with the NIL FEC has ended. The ingress node should pop it's Target FEC stack with the same number of NIL FECs, as missing in the echo response. Note that an echo response containing a FEC stack exactly the same as that sent in the echo request does not necessarily mean that the LSP has not started traversing a new tunnel. If the bottom-most FEC in the stack is a NIL FEC, then it could be that the LSP associated with the NIL FEC terminated at a transit node and at the same time a new LSP started at the same transit node. The NIL FEC would now be associated with the new LSP (and the ingress has no way of knowing this). Thus, it is not possible to build an accurate hierarchical LSP topology if a traceroute contains NIL FECs. 4.2.2. Modifications to handling to EGRESS_OK responses. The procedures above allow the addition of new FECs to the original FEC being traced. Consequently, the EGRESS_OK response from a downstream node may not necessarily be for the FEC being traced. It could be for one of the new FECs that was added. On receipt of an EGRESS_OK response, the ingress should check if the Target FEC sent to the node that just responded was the base FEC that was being traced. If it was not, then it should pop the bottom-most entry in the Target FEC stack and resend the request with the same TTL (as previously sent). The process of popping a FEC is to be repeated until either the ingress receives a non-EGRESS_OK response or until all the additional FECs added to the FEC stack have already been popped. Using EGRESS_OK responses, an ingress can build a map of the hierarchical LSP structure traversed by a given FEC. Bahadur & Kompella Expires January 2, 2008 [Page 8] Internet-Draft LSP-Ping over MPLS tunnel July 2007 5. Security Considerations There are no new security considerations added by this document. The security considerations discussed in [1] are applicable to this document. 6. IANA Considerations This document introduces a Downstream FEC Stack TLV in [1]. This has to be assigned from the TLV type registry maintained by IANA. 7. Acknowledgements The authors would like to thank Yakov Rekhter for his suggestions on the draft. 8. Normative References [1] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Nitin Bahadur (editor) Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US Phone: +1 408 745 2000 Email: nitinb@juniper.net URI: http://www.juniper.net Bahadur & Kompella Expires January 2, 2008 [Page 9] Internet-Draft LSP-Ping over MPLS tunnel July 2007 Kireeti Kompella (editor) Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US Phone: +1 408 745 2000 Email: kireeti@juniper.net URI: www.juniper.net Bahadur & Kompella Expires January 2, 2008 [Page 10] Internet-Draft LSP-Ping over MPLS tunnel July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bahadur & Kompella Expires January 2, 2008 [Page 11]