Skip to main content

Definition of Time-to-Live TLV for LSP-Ping Mechanisms

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7394.
Authors George Swallow , Sam Aldrin , Sami Boutros , Shaleen Saxena , Siva Sivabalan , Vishwas Manral
Last updated 2011-10-28 (Latest revision 2011-06-29)
Replaces draft-boutros-mpls-lsp-ping-ttl-tlv
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                              Siva Sivabalan (Ed.) 
Internet Draft                                       Sami Boutros (Ed.) 
Intended status: Standards Track                         George Swallow  
Expires: September 2011                                  Shaleen Saxena               
                                                     Cisco Systems, Inc. 
                                                         Vishwas Manral 
                                                        IPInfusion, Inc. 
                                                             Sam Aldrin 
                                              Huawei Technologies, Inc. 
                                                        October 28, 2011 

          Definition of Time-to-Live TLV for LSP-Ping Mechanisms 


   LSP-Ping is a widely deployed Operation, Administration, and 
   Maintenance (OAM) mechanism in MPLS networks. However, in the present 
   form, this mechanism is inadequate to verify connectivity of a 
   segment of a Multi-Segment PseudoWire (MS-PW) from any node on the 
   path of the MS-PW. This document defines a TLV to address this 

Requirements Language 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
   this document are to be interpreted as described in RFC 2119 [3]. 

Status of this Memo 

   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-

   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." 


Boutros                  Expires May 28, 2012                  [Page 1] 

Internet-Draft  draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt       June 2011  

   The list of current Internet-Drafts can be accessed at 

   The list of Internet-Draft Shadow Directories can be accessed at 

   This Internet-Draft will expire on May 28, 2012. 

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 
  ( 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...................................................2 
   2. Terminology....................................................3 
   3. Time To Live TLV...............................................4 
   4. Operation......................................................4 
   5. Security Considerations........................................5 
   6. IANA Considerations............................................5 
   7. References.....................................................5 
      7.1. Normative References......................................5 
      7.2. Informative References.........Error! Bookmark not defined. 
   Author's Addresses................................................7 
1. Introduction 

      A MS-PW can span across multiple service provider networks. In 
   order to allow Service Providers (SP) to verify segments of such MS-
   PW from any node on the path of the MS-PW, any node along the path of 
   the MS-PW, should be able to originate an LSP-Ping echo request 
   packet to any another node along the path of the MS-PW and receive 
   the corresponding echo reply. If the originator of the echo request 
   is at the end of a MS-PW, the receiver of the request can send the 
Boutros                  Expires May 28, 2011                  [Page 2] 

Internet-Draft  draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt       June 2011  

   reply back to the sender without knowing the hop-count distance of 
   the originator. For example, the reply will be intercepted by the 
   originator regardless of the TTL value on the reply packet. But, if 
   the originator is not at the end of the MS-PW, the receiver of the 
   echo request MAY need to know how many hops away the originator of 
   the echo request is so that it can set the TTL value on the MPLS 
   header for the echo reply to be intercepted at the originator node. 

   In MPLS networks (also applicable to MPLS-TP), for bidirectional co-
   routed LSPs, if it is desired to verify connectivity from any 
   intermediate node (LSR) on the LSP to the any other LSR on the LSP 
   the receiver may need to know the TTL to send the Echo reply with, so 
   as the packet is intercepted by the originator node. 

   A new optional TTL TLV is being proposed in this document this TLV 
   will be added by the originator of the echo request to inform the 
   receiver how many hops away the originator is on the path of the MS-
   PW or Bidirectional LSP. 

   Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   document are to be interpreted as described in RFC-2119Error! 
   Reference source not found. 

2. Terminology 

   LSR: Label Switching Router 

   MPLS-OAM: MPLS Operations, Administration and Maintenance 

   MPLS-TP: MPLS Transport Profile 

   MS-PW: Multi-Segment PseudoWire 

   PW: PseudoWire 

   TLV: Type Length Value 

   TTL: Time To Live 


Boutros                  Expires May 28, 2011                  [Page 3] 

Internet-Draft  draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt       June 2011  

3. Time To Live TLV 

   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 = TBD                   |   Length = 8                  | 
   |   value       | 
                  Figure 1: Time To Live TLV format 

   The TTL TLV has the format shown in Figure 1. This TLV shall be 
   included in the echo request by the originator of request. The use of 
   this TLV is optional. If the value field is zero, the LSP Ping Echo 
   request packet will be dropped.  

   If a receiver does not understand the TTL TLV, it will simply ignore 
   the TLV (Type value of TLV is assumed to be in the range of optional 
   TLVs which SHOULD be ignored if an implementation does not support or 
   understand them). In the absence of TTL TLV or if TTL TLV is ignored 
   by a receiver, the determination of the TTL value used in the MPLS 
   label on the echo reply is beyond the scope of this document.  

   If a receiver understands the TTL TLV, and the TTL TLV is present in 
   the echo request, the receiver MUST use the TTL value specified in 
   TLV in the MPLS header of the echo reply. 

   In the traceroute mode TTL value in the TLV is successively set to 1, 
   2, and so on. 

4. Operation 

   In this section, we explain a use case for the TTL TLV with an MPLS 

                <------------------MS-PW ---------------------> 

                A          B          C           D           E 
                o -------- o -------- o --------- o --------- o 
                           ------Echo Request-----> 
                           <-----Echo Reply-------- 

                 Figure 2: Use-case with MS-PWs 
Boutros                  Expires May 28, 2011                  [Page 4] 

Internet-Draft  draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt       June 2011  

   Let us assume a MS-PW going through LSRs A, B, C, D, and E. 
   Furthermore, assume that an operator wants to perform a connectivity 
   check between B and D from B. Thus, an LSP-Ping request with the TTL 
   TLV is originated from B and sent towards D. The echo request packet 
   contains the FEC of the PW Segment between C and D. The value field 
   of the TTL TLV and the TTL field of the MPLS label are set to 2. The 
   echo request is intercepted at D because of TTL expiry. D detects the 
   TTL TLV in the request, and use the TTL value (i.e., 2) specified in 
   the TLV on the MPLS label of the echo reply. The echo reply will be 
   intercepted by B because of TTL expiry.  

   The same operation will apply in the case a co-routed bidirectional 
   LSP and we want to check connectivity from an intermediate LSR B to 
   another LSR D, from B.  

5. Security Considerations 

   This draft allows the setting of the TTL value in the MPLS Label of 
   an echo reply, so that it can be intercepted by an intermediate 
   device. This can cause a device to get a lot of LSP Ping packets 
   which get redirected to the CPU.  

   However the same is possible even without the changes mentioned in 
   this document. A device should rate limit the LSP ping packets 
   redirected to the CPU so that the CPU is not overwhelmed. 

6. IANA Considerations 

   IANA is requested to assign TLV type value to the following TLV from   
   the "Multiprotocol Label Switching Architecture (MPLS) Label Switched   
   Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-   

   Time To Live TLV (See Section 3). 


7. References 

7.1. Normative References 

     [1] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label 
           Switched (MPLS) Data Plane Failures", RFC 4379, February 

Boutros                  Expires May 28, 2011                  [Page 5] 

Internet-Draft  draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt       June 2011  

     [2] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity 
           Verification (VCCV): A Control Channel for Pseudowires ", RFC 
           5085, December 2007. 

     [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
           Levels", BCP 14, RFC 2119, March 1997. 

Boutros                  Expires May 28, 2011                  [Page 6] 

Internet-Draft  draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt       June 2011  

Author's Addresses 

   Siva Sivabalan 
   Cisco Systems, Inc. 
   2000 Innovation Drive 
   Kanata, Ontario, K2K 3E8 
   Sami Boutros 
   Cisco Systems, Inc. 
   3750 Cisco Way 
   San Jose, California 95134 
   George Swallow 
   Cisco Systems, Inc. 
   300 Beaver Brook Road  
   Boxborough , MASSACHUSETTS 01719  
   United States  
   Shaleen Saxena 
   Cisco Systems, Inc. 
   1414 Massachusetts Avenue 
   Boxborough , MASSACHUSETTS 01719  
   United States  
   Vishwas Manral 
   IPInfusion, Inc. 
   1188 E. Arques Ave., 
   Sunnyvale, CA 94085 
   United States  
   Sam Aldrin 
   Huawei Technologies, Inc. 
   1188 Central Express Way, 
   Santa Clara, CA 95051 
   United States  
Boutros                  Expires May 28, 2011                  [Page 7]