Network Working Group R. Zheng Internet-Draft L. Jin Intended status: Standards Track ZTE Expires: April 25, 2012 October 23, 2011 LSP Ping extensions for echo reply relay draft-zj-mpls-lsp-ping-reply-relay-00 Abstract [RFC4379] describes the LSP Ping mechanism to detect data plane failures. In some deployment scenario for the LSP traceroute, a replying LSR may not have the available route to the initiator, and the echo reply message sent to the initiator would be discarded. Thus, the basic idea of traceroute procedure to localize fault could not be achieved. This document describes extensions to LSP Ping mechanism to enable the replying LSR to have the capability to relay the echo reply by a set of routable intermediate nodes to the initiator. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 25, 2012. Copyright Notice Copyright (c) 2011 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 Zheng, et al. Expires April 25, 2012 [Page 1] Internet-Draft MPLS LSP Ping reply relay October 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . . 4 2. Routable Relay Node Address TLV . . . . . . . . . . . . . . . . 4 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. LSP Ping Example . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Zheng, et al. Expires April 25, 2012 [Page 2] Internet-Draft MPLS LSP Ping reply relay October 2011 1. Introduction LSP Ping is an efficient OAM mechanism to detect data plane failures and localize faults. The basic LSP Ping mechanism has been described in [RFC4379]. In traceroute mode of LSP Ping procedure, the echo request message is sent to the control plane of each transit LSR, and an echo reply massage with proper information are required to send to the initiator at each transit LSR. Then the LSP fault could be localized exactly, and an accurate LSP topology could also be built. The echo reply would normally be sent back to the initiator via an IPv4/IPv6 UDP packet. The basic requirement is that the replying LSR has reachable IP route to the initiator. However, in some network deployment, the requirement could not be met because of the route control policy. For example, considering the inter-area situation in Seamless MPLS architecture [ietf-mpls-seamless], LSR1/LSR2 nodes in core network would not have IP reachable route to ANs. If tracing an LSP from AN to remote AN, the LSR1/LSR2 node would be unable to respond to the echo request message for the lack of IP reachable route to AN. +-------+ +-------+ +------+ +------+ | | | | | | | | +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN / | | /| | | | | | +----+/ +-------+\/ +-------+ +------+ /+------+ | AN | /\ \/ +----+\ +-------+ \+-------+ +------+/\ +------+ \ | | | | | | \| | +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN | | | | | | | | +-------+ +-------+ +------+ +------+ static route ISIS L1 LDP ISIS L2 LDP <-Access-><--Aggregation Domain--><---------Core---------> This draft describes extensions to LSP Ping mechanism to enable the echo reply message to be relayed back to the initiator. The replying LSR would send the echo reply message to a routable relayed node indicated by the Routable Relay Node Address TLV, and the echo reply would be relayed to the next relay node, till to the initiator. Note: [I-D. ietf-mpls-interas-lspping-00] describes an echo reply relayed mechanism for inter-AS scenario, by using a dedicated ASBR stack list. Unfortunately, this mechanism could not be applied in Zheng, et al. Expires April 25, 2012 [Page 3] Internet-Draft MPLS LSP Ping reply relay October 2011 inter-area scenario. The current mechanism described in this draft is only for inter-area scenario. 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 [RFC2119]. 2. Routable Relay Node Address TLV The Routable Relay Node Address TLV MUST be carried in the echo request and echo reply messages if the echo reply relayed mechanism described in this draft is required. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node 1 IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node n IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Routable Relay Node Address TLV - Type: to be assigned by IANA. - Length: The Length of the Value field in octets. - Address Type The Address Type indicates the routable relay node address type. The routable relay node IP address length is determined based on the Address Type. Type Address Type Node Address length ---- -------------- ---------------------- 1 IPv4 4 2 IPv6 16 Zheng, et al. Expires April 25, 2012 [Page 4] Internet-Draft MPLS LSP Ping reply relay October 2011 - Node 1 IP Address: The IP Address of the first node that adds its address in this TLV. - Node n IP Address: The IP Address of the last node that adds its address in this TLV. 3. Procedures When tracing an LSP with outmost label TTL=1, a Routable Relay Node Address TLV with the first address item of the initiator address should be included in the echo request. Upon receiving an echo request message, the receiver checks the address list in the Routable Relay Node Address TLV from node 1 to n IP address. Until finds the first routable node address, sets this node address as the destination address of the echo reply message. The receiver deletes all the node IP address items behind of the first routable one in the address list, and adds its own address as the last address item in the Routable Relay Node Address TLV. The updated Routable Relay Node Address TLV should be carried in the echo reply message. Upon receiving an echo reply message with its address as the destination address in the IP header, the receiver should check the address items in Routable Relay Node Address TLV in sequence to find the next relay node address. If its own address is node n IP address, then the next relay node address is node (n-1) IP address. The receiver should then send the echo reply to the next relay node with the Routable Relay Node Address Stack TLV unchanged. The next relay node may be an intermediate node or the initiator. As relayed by intermediate nodes, the echo reply will finally be transmitted to the initiator. The initiator will copy the Routable Relay Node Address TLV from the echo reply into the next echo request message. Those nodes do not understand or support the Routable Relay Node Address TLV, SHOULD ignore and pass it unchanged. 4. LSP Ping Example Considering the inter-area scenario of Seamless MPLS architecture below, Zheng, et al. Expires April 25, 2012 [Page 5] Internet-Draft MPLS LSP Ping reply relay October 2011 +-------+ +-------+ +------+ +------+ | | | | | | | | #### AGN11 ##### AGN21 ##### ABR1 ##### LSR1 ###> to AGN # | | /| | | | | | +----+# +-------+\/ +-------+ +------+ /+------+ | AN | /\ \/ +----+\ +-------+ \+-------+ +------+/\ +------+ \ | | | | | | \| | +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN | | | | | | | | +-------+ +-------+ +------+ +------+ static route ISIS L1 LDP ISIS L2 LDP <-Access-><--Aggregation Domain--><---------Core---------> Supposing the active LSP from AN to remote AN goes through AGN11, AGN21, ABR1, LSR1 and the following nodes. When performing LSP traceroute on the LSP the first echo request sent by AN with outmost label TTL=1, contains the Routable Relay Node Address TLV with the only address of AN. After processed by AGN11, AGN11 address will be added in the Routable Relay Node Address list following AN1 address in the echo reply. AN1 copies the Routable Relay Node Address TLV into the next echo request when receiving the echo reply. Upon receiving the echo request, AGN21 checks the address list in the Routable Relay Node Address TLV in sequence, and finds out that AN1 address is routable. Then deletes AGN11 address, and adds its own address following AN1 address. As a result, there would be AN1 address followed by AGN21 address in the Routable Relay Node Address TLV of the echo reply sent by AGN21. For echo request with outmost label TTL=3, similarly with the procedures on AGN21, the Routable Relay Node Address TLV sent by ABR1 in the echo reply will include two address items with both AN1 and ABR1 address. Then AN1 sends echo request with outmost label TTL=4, containing the Routable Relay Node Address TLV copied from the received echo reply message. Upon receiving the echo request message, LSR1 checks the address list in the Routable Relay Node Address TLV in sequence, and finds out that AN1 address is IP route unreachable, and ABR1 address is the first routable one in the Routable Relay Node Address TLV. LSR1 adds its address as the last address item following ABR1 address in the Routable Relay Node Address TLV, sets ABR1 address as the Zheng, et al. Expires April 25, 2012 [Page 6] Internet-Draft MPLS LSP Ping reply relay October 2011 destination address of the echo reply, and sends the echo reply to ABR1. Upon receiving the echo request message from LSR1, ABR1 checks the address list in the Routable Relay Node Address TLV in sequence, and finds out that AN1 address is the one just before its address. Then ABR1 sends the echo reply to AN1 with the Routable Relay Node Address TLV unchanged. The echo reply from the replying node which has no reachable route to the initiator is finally transmitted to the initiator by multiple relay nodes. 5. Security Considerations TBD 6. IANA Considerations TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 7.2. Informative References [I-D.ietf-mpls-interas-lspping-00] Nadeau, T.and G. Swallow, "Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios", draft-ietf-mpls-interas-lspping-00(expired) , March 2007. [I-D.ietf-mpls-seamless-mpls-00] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M. and D. Steinberg, "Seamless MPLS Architecture", draft-ietf-mpls-seamless-mpls-00 , May 2011. Zheng, et al. Expires April 25, 2012 [Page 7] Internet-Draft MPLS LSP Ping reply relay October 2011 Authors and contributors' Addresses Ryan Zheng ZTE Corporation 50, Ruanjian Avenue Nanjing, 210012, China Email: zheng.zhi@zte.com.cn Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Manuel Paul Deutsche Telekom Goslarer Ufer 35 10589 Berlin, Germany Email: manuel.paul@telekom.de Zheng, et al. Expires April 25, 2012 [Page 8]