Internet DRAFT - draft-zj-mpls-lsp-ping-reply-relay

draft-zj-mpls-lsp-ping-reply-relay






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]