--- 1/draft-ietf-mpls-lsp-ping-relay-reply-03.txt 2014-07-30 08:14:30.354294081 -0700 +++ 2/draft-ietf-mpls-lsp-ping-relay-reply-04.txt 2014-07-30 08:14:30.386294862 -0700 @@ -1,53 +1,53 @@ Network Working Group J. Luo, Ed. Internet-Draft ZTE Updates: 4379 (if approved) L. Jin, Ed. Intended status: Standards Track -Expires: October 4, 2014 T. Nadeau, Ed. +Expires: January 31, 2015 T. Nadeau, Ed. Lucidvision G. Swallow, Ed. Cisco - April 2, 2014 + July 30, 2014 Relayed Echo Reply mechanism for LSP Ping - draft-ietf-mpls-lsp-ping-relay-reply-03 + draft-ietf-mpls-lsp-ping-relay-reply-04 Abstract In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and 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 resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label Switching Router (LSR) to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. -Status of this Memo +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 October 4, 2014. + This Internet-Draft will expire on January 31, 2015. Copyright Notice Copyright (c) 2014 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 @@ -64,47 +64,48 @@ modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 - 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . . 6 - 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 6 - 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 8 - 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 + 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5 + 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 + 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 7 + 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 9 - 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . . 9 + 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 9 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10 + 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 10 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 + 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 13 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 11.2. Informative References . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document describes the extensions to the Label Switched Path (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply mechanism which could be used to detect data plane failures for the inter autonomous system (AS) and inter-area LSPs. The extensions are to update the [RFC4379]. Without these extensions, the ping functionality provided by [RFC4379] would fail in many deployed inter-AS scenarios, since the replying LSR in one AS may not have the @@ -178,20 +179,24 @@ Figure 2: Seamless MPLS Architecture This document describes extensions to the LSP Ping mechanism to facilitate a response from the replying LSR, by defining a simple mechanism that uses a relay node (e.g, ASBR) to relay the message back to the initiator. Every designated or learned relay node must have an IP route to the next relay node or to the initiator. Using a recursive approach, relay node could relay the message to the next relay node until the initiator is reached. + The LSP Ping relay mechanism in this document is defined for unicast + case. How to apply the LSP Ping relay mechanism in multicast case is + out of the scope. + 3. Extensions [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines two message types, Echo Request and Echo Reply message. This document defines a new message, Relayed Echo 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. A new TLV named Relay Node Address Stack TLV is defined in this @@ -201,22 +206,22 @@ In addition, a new Return Code is defined to notify the initiator that the packet length is exceeded unexpected by the Relay Node Address Stack TLV. It should be noted that this document focuses only on detecting the LSP which is set up using a uniform IP address family type. That is, all hops between the source and destination node use the same address family type for their LSP ping control planes. This does not preclude nodes that support both IPv6 and IPv4 addresses simultaneously, but the entire path must be addressable using only - one address family type. Supporting for mixed IPv4-only and IPv6- - only is beyond the scope of this document. + one address family type. Supporting for mixed IPv4-only and + IPv6-only is beyond the scope of this document. 3.1. Relayed Echo Reply message The Relayed Echo 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. New Message Type: Value Meaning ----- ------- @@ -274,22 +279,31 @@ Type# Address Type Address Length ---- ------------ ------------ 0 Unspecified 0 1 IPv4 4 2 IPv6 16 Reserved: This field is reserved and MUST be set to zero. K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in Relay Node Address Stack during TLV compress process described in - section 4.2. The K bit may be set by ASBRs whose address would be - kept in the stack if necessary. + section 4.2. The entry with Unspecified Address Type SHOULD NOT set + K bit. + + Having the K bit set on the relay node address entry causes that + entry to be preserved in the Relay Node Address Stack TLV for the + entire traceroute operation. A responder node MAY set the K bit to + ensure its relay node address entry remains as one of the relay nodes + in the Relay Node Address Stack TLV. Some nodes could be configured + to always set the K bit, or the module handling MPLS echo requests + could discover its K bit use through topology awareness. How a node + determines to set the K bit is outside the scope of this document. Relayed Address: this field specifies the node address, either IPv4 or IPv6. 3.3. New Return Code A new Return Code is used by the replying LSR to notify the initiator that the packet length is exceeded unexpected by the Relay Node Address Stack TLV. @@ -321,23 +335,25 @@ 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 message, the receiver MUST check the addresses of the stack in sequence from top to bottom (the first address in the stack will be the first one to be checked), 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 MUST be deleted, and the address entry of the replying LSR MUST be added at the bottom of - the stack. Those address entries with K bit set to 1 MUST be kept in - the stack. The updated Relay Node Address Stack TLV MUST be carried - in the response message. + the stack. The address entry added by the replying LSR MUST be same + as the source IP address of Relay Echo Reply (section 4.3) or Echo + Reply message (section 4.5) being sent. Those address entries with K + bit set to 1 MUST be kept in the stack. The updated Relay Node + Address Stack TLV MUST be carried in the response message. If the replying LSR is configured to hide its routable address information, the address entry added in the stack SHOULD be a blank entry with Address Type set to unspecified. The blank address entry in the receiving Echo Request SHOULD be treated as an unroutable address entry. If the packet length was exceeded unexpectedly by the Relay Node Address Stack TLV, the TLV SHOULD be returned back unchanged in the Echo Reply message. And the new return code in section 3.3 SHOULD be @@ -353,77 +369,93 @@ An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore it according to section 3 of [RFC4379]. 4.3. Originating an Relayed Echo Reply When the replying LSR receives an Echo Request with the first IP address in the Relay Node Address Stack TLV is IP unroutable, the replying LSR SHOULD send a Relayed Echo Reply message to the first routable intermediate node. The processing of Relayed Echo 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 + 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. The destination IP address of the Relayed Echo Reply is set to the first routable IP address from the Relay Node Address Stack TLV, and both the source and destination UDP port is set to 3503. 4.4. Relaying an Relayed Echo Reply Upon receiving an Relayed Echo Reply message with its own 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 from top to down, and find the first routable node address. If the first routable address is the top one of the address list, e.g, the initiator address, the relay node SHOULD send an Echo Reply message to the initiator containing the same payload with the Relayed Echo Reply message received. See section 4.5 for detail. If the first routable address is not the top one of the address list, e.g, another intermediate relay node, the relay node SHOULD send an Relayed Echo Reply message to this relay node with the payload - unchanged. + unchanged. The TTL of the Relayed Echo Reply SHOULD be copied from + the received Relay Echo Reply and decremented by 1. Note, the replying LSR SHOULD send a Relayed Echo Reply message to - the first relay node found in Relay Node Address Stack TLV that is - routable by the router. The routable address MUST be located before - the source IP address of the received Relayed Echo Reply which must - be also in the stack, otherwise the Relayed Echo Reply should not be - sent, so as to avoid potential loop. + the first relay node found in Relay Node Address Stack TLV that is IP + routable. The routable address MUST be located before the source IP + address of the received Relayed Echo Reply which must be also in the + stack, otherwise the Relayed Echo Reply SHOULD not be sent, so as to + avoid potential loop. 4.5. Sending an Echo Reply The Echo Reply is sent in two cases: 1. When the replying LSR receives an Echo Request with the first IP address in the Relay Node Address Stack TLV IP routable, the replying LSR would send an Echo Reply to the initiator. In addition to the procedure of the Echo Reply described in Section 4.5 of [RFC4379], the Relay Node Address Stack TLV would be carried in the Echo Reply. 2. When the intermediate relay node receives a Relayed Echo Reply with the first IP address in the Relay Node Address Stack TLV IP routable, the intermediate relay node would send the Echo Reply to the initiator with the UDP payload unchanged other than the Message Type field (change from type of Relayed Echo Reply to Echo Reply). The destination IP address of the Echo Reply is set to the first IP address in the stack, 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. + TLV. The source UDP port should be 3503. The TTL of the Echo Reply + SHOULD be copied from the received Relay Echo Reply and decremented + by 1. 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. +4.7. Impact to Traceroute + + Source IP address in Echo Reply and Relay Echo Reply are to be of the + address of the node sending those packets, not the original + responding node. Then the traceroute address output module will + print the source IP address as below: + + if (Relay Node Address Stack TLV exists) { + Print the last address in the stack; + } else { + Print the source IP address of Echo Reply message; + } + 5. LSP Ping Relayed Echo Reply Example Considering the inter-AS scenario in Figure 4 below. +-------+ +-------+ +------+ +------+ +------+ +------+ | | | | | | | | | | | | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | | | | | | | | | | | | +-------+ +-------+ +------+ +------+ +------+ +------+ <---------------AS1-------------><---------------AS2------------> @@ -564,49 +596,53 @@ ----- ------- TBD Response Packet length was exceeded unexpected by the Relay Node Address Stack TLV unexpected The value should be assigned from the "Standards Action" range (0-191), and using the lowest free value within this range. 9. Acknowledgement The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel - Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin and - Gregory Mirsky for their valuable comments and suggestions. + Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory + Mirsky, and Nobo Akiya for their valuable comments and suggestions. 10. Contributors Ryan Zheng JSPTPD 371, Zhongshan South Road Nanjing, 210006, China Email: ryan.zhi.zheng@gmail.com 11. References 11.1. Normative References + [I-D.ietf-mpls-proxy-lsp-ping] + Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo + Request", draft-ietf-mpls-proxy-lsp-ping-02 (work in + progress), July 2014. + [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. 11.2. Informative References [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, - M., and D. Steinberg, "Seamless MPLS Architecture", - draft-ietf-mpls-seamless-mpls-06 (work in progress), - February 2014. + M., and D. Steinberg, "Seamless MPLS Architecture", draft- + ietf-mpls-seamless-mpls-07 (work in progress), June 2014. Authors' Addresses Jian Luo (editor) ZTE 50, Ruanjian Avenue Nanjing, 210012, China Email: luo.jian@zte.com.cn