Network Working Group R. Zheng, Ed. Internet-Draft L. Jin, Ed. Intended status: Standards Track ZTE Expires: December 18, 2012 T. Nadeau, Ed. Juniper G. Swallow, Ed. Cisco June 16, 2012 Echo Relay Reply mechanism for LSP Ping draft-zjns-mpls-lsp-ping-relay-reply-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 December 18, 2012. Copyright Notice Copyright (c) 2012 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 Zheng, et al. Expires December 18, 2012 [Page 1] Internet-Draft MPLS LSP Ping relay reply June 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Echo Relay Reply message . . . . . . . . . . . . . . . . . 4 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 5 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 6 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 6 4.3. Sending an Echo Relay Reply . . . . . . . . . . . . . . . 7 4.4. Receiving an Echo Relay Reply . . . . . . . . . . . . . . 8 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 8 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 9 6.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Zheng, et al. Expires December 18, 2012 [Page 2] Internet-Draft MPLS LSP Ping relay reply June 2012 1. Introduction This draft describes LSP Ping Echo Relay Reply mechanism that can be used to detect data plane failures in MPLS LSPs that span across multiple domains. A new message referred to as "Echo Relay Reply message" and a new TLV referred to as "Relay Node Address Stack TLV" are defined in this draft. 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. Motivation 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 inter-AS scenarios, it is common of the providers to NOT distribute the IP addresses of any of the nodes other than the ASBR. If initiating a traceroute procedure on the ingress node PE1 of an LSP from PE1 to PE2, P nodes in the other AS like P2 would be unable to respond to the echo request message for the lack of IP reachable route to PE1. +-------+ +-------+ +------+ +------+ +------+ +------+ | | | | | | | | | | | | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | | | | | | | | | | | | +-------+ +-------+ +------+ +------+ +------+ +------+ <---------------AS1-------------><---------------AS2------------> Zheng, et al. Expires December 18, 2012 [Page 3] Internet-Draft MPLS LSP Ping relay reply June 2012 For the inter-area situation in Seamless MPLS architecture [ietf- mpls-seamless], P nodes in core network would not have IP reachable route to ANs. When tracing an LSP from AN to remote AN, the LSR1/ LSR2 node could not make a response to the echo request either, like P2 node in the inter-AS scenario. +-------+ +-------+ +------+ +------+ | | | | | | | | +--+ 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 response from the replying LSR to be relayed back to the initiator. The replying LSR would send the response to a relay node indicated by the Relay Node Address Stack TLV, and the response would be relayed to the next relay node, till to the initiator. 3. Extensions RFC4379 describes the basic MPLS LSP Ping mechanism, which defines two message types. This draft defines a new message, Echo Relay Reply message. This new message is used to replace Echo Reply message which is sent from the replying LSR to a relay node or from a relay node to another relay node. In addition, a new TLV named Relay Node Address Stack TLV is defined in this draft, to carry the IP addresses of the possible relay nodes for the replying LSR. 3.1. Echo Relay Reply message The echo relay reply message is a UDP packet, and the UDP payload has the same format with echo request/reply message. A new message type is requested from IANA. Zheng, et al. Expires December 18, 2012 [Page 4] Internet-Draft MPLS LSP Ping relay reply June 2012 New Message Type: Value Meaning ----- ------- TBD MPLS echo relay reply 3.2. Relay Node Address Stack The Relay Node Address Stack TLV MUST be carried in the echo request, echo reply and echo relay 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Source Port | Number of Relayed Addresses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Stack of Relayed Addresses ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Relay Node Address Stack TLV - Type: to be assigned by IANA. - Length: The Length of the Value field in octets. - Initiator Source Port: The port that the initiator sends the echo request message, and also the port that expected to receive the echo reply message. - Number of Relayed Addresses: An integer indicating the number of relayed addresses in the stack. - Stack of Relayed Addresses: A list of relay node addresses. The format of each relay node address is as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Address Length| Reserved |K| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Relayed Address (0, 4, or 16 octects) ~ Zheng, et al. Expires December 18, 2012 [Page 5] Internet-Draft MPLS LSP Ping relay reply June 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type# Address Type Address Length ---- ------------ ------------ 0 Unspecified 0 1 IPv4 4 2 IPv6 16 Reserved: This field is reserved for future use and MUST be set to zero. K bit: If the K bit is set to 1, then this sub-TLV SHOULD be kept in Relay Node Address Stack, SHOULD not be deleted in compress process of section 4.2. The K bit may be set by ASBRs which address would be kept in the stack if necessary. If the K bit is set to 0, then this sub-TLV SHOULD be processed normally according to section 4.2. Relayed Address: This field specifies the node address, either IPv4 or IPv6. 4. Procedures 4.1. Sending an Echo Request The procedures described in Section 4.3 of RFC4379 apply here. In addition, An Relay Node Address Stack TLV MUST be carried in the echo request message. When the echo request is first sent by initiator, a Relay Node Address Stack TLV with the initiator address in the stack and its source port MUST be included. For the subsequent echo request messages, the initiator would copy the Relay Node Address Stack TLV from the received echo reply message. 4.2. Receiving an Echo Request In addition to the processes in Section 4.4 of RFC4379, the procedures of the Relay Node Address Stack TLV are defined here. Upon receiving a Relay Node Address Stack TLV of the echo request Zheng, et al. Expires December 18, 2012 [Page 6] Internet-Draft MPLS LSP Ping relay reply June 2012 message, the receiver would check the addresses of the stack in sequence from top to bottom, to find out the first public routable IP address. Those address entries behind of the first routable IP address in the address list with K bit set to 0 would be deleted, and the address entry of the replying LSR would be added at the bottom of the stack. Those address entries with K bit set to 1 would be kept in the stack. The updated Relay Node Address Stack TLV would be carried in the response message. If the replying LSR wishes to hide its routable address information, the address entry added in the stack would be a blank entry with Address Type set to Unspecified. The blank address entry in the receiving echo request would be treated as an unroutable address entry. If the first routable IP address is the first address in the stack, the replying LSR would respond an echo reply message to the initiator. If the first routable IP address is of an intermediate node, other than the first address in the stack, the replying LSR would send an echo relay reply instead of an echo reply in response. 4.3. Sending an Echo Relay Reply The echo relay reply is sent in two cases: 1. When the replying LSR received an echo request with the initiator IP address in the Relay Node Address Stack TLV is IP unroutable, the replying LSR would send an echo relay reply message to the first routable intermediate node. The encapsulation processing of echo relay reply is the same with the procedure of the echo reply described in Section 4.5 of RFC4379, except the destination IP address and the destination UDP port of the message part. The destination IP address of the echo relay reply is set to the first routable IP address from the Relay Node Address Stack TLV, and the destination UDP port is set to 3503. 2. When the intermediate relay node received an echo relay reply with the initiator IP address in the Relay Node Address Stack TLV is IP unroutable, the intermediate relay node would send the echo relay reply to the next relay node with the content of the UDP packet unchanged. The destination IP address of the echo relay reply is set to the first routable IP address from the Relay Node Address Stack TLV. Both the source and destination UDP port should be 3503. Zheng, et al. Expires December 18, 2012 [Page 7] Internet-Draft MPLS LSP Ping relay reply June 2012 4.4. Receiving an Echo Relay Reply Upon receiving an echo relay reply message with its address as the destination address in the IP header, the relay node should check the address items in Relay Node Address Stack TLV in sequence and find the first routable node address. If the first routable address is the top one of the address list, i.e., the initiator address, the relay node should send an echo reply message to the initiator containing the same payload with the echo relay reply message received. If the first routable address is not the top one of the address list, i.e., another intermediate relay node, the relay node should send an echo relay reply message to this relay node with the payload unchanged. 4.5. Sending an Echo Reply The echo relay reply is sent in two cases: 1. When the replying LSR received an echo request with the initiator IP address in the Relay Node Address Stack TLV is IP routable, the replying LSR would send an echo reply to the initiator. The processing of echo relay reply is the same with the procedure of the echo reply described in Section 4.5 of RFC4379. 2. When the intermediate relay node LSR received an echo relay reply with the initiator IP address in the Relay Node Address Stack TLV is IP routable, the intermediate relay node would send the echo reply to the initiator with the payload no changes other than the Message Type field. The destination IP address of the echo reply is set to the initiator IP address, and the destination UDP port would be copied from the Initiator Source Port field of the Relay Node Address Stack TLV. The source UDP port should be 3503. 4.6. Receiving an Echo Reply In addition to the processes in Section 4.6 of RFC4379, the initiator would copy the Relay Node Address Stack TLV received in the echo reply to the next echo request. 5. Security Considerations In addition to the Security Consideration from [RFC4379], to avoid potential Denial-of-service attack, it is RECOMMENED that implementations regulate the LSP Ping traffic going to the control Zheng, et al. Expires December 18, 2012 [Page 8] Internet-Draft MPLS LSP Ping relay reply June 2012 plane. A rate limiter SHOULD be applied to UDP port 3503 of the intermediate node. The node which acts as a relay node SHOULD validate the relay reply against a set of valid source addresses. An implementation SHOULD provide such filtering capabilities. If an operator wants to obscure their nodes, then a blank entry may be used in the address stack. 6. IANA Considerations IANA is requested to assign one new Message Type and one new TLV 6.1. New Message Type New Message Type: Value Meaning ----- ------- TBD MPLS echo relay reply 6.2. New TLV New TLV: Routable Relay Node Address TLV Type Meaning ---- -------- TBD Relay Node Address Stack TLV 7. Acknowledgement The authors would like to thank Carlos Pignataro, Xinwen Jiao and Manuel Paul for their valuable comments and discussions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. Zheng, et al. Expires December 18, 2012 [Page 9] Internet-Draft MPLS LSP Ping relay reply June 2012 [RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011. [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011. 8.2. Informative References [ietf-mpls-seamless] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M. and D. Steinberg, "Seamless MPLS Architecture", draft-ietf-mpls-seamless-mpls-00 , May 2011. Authors' Addresses Ryan Zheng (editor) ZTE 50, Ruanjian Avenue Nanjing, 210012, China Email: zheng.zhi@zte.com.cn Lizhong Jin (editor) ZTE 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Thomas Nadeau (editor) Juniper Email: tnadeau@juniper.net Zheng, et al. Expires December 18, 2012 [Page 10] Internet-Draft MPLS LSP Ping relay reply June 2012 George Swallow (editor) Cisco 300 Beaver Brook Road Boxborough , MASSACHUSETTS 01719, USA Email: swallow@cisco.com Zheng, et al. Expires December 18, 2012 [Page 11]