[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-mpls-return-path-specified-lsp-ping

Network working group                                         M. Chen
Internet Draft                                                 X. Guo
Category: Standards Track                                      W. Cao
Created: July 2, 2009                     Huawei Technologies Co.,Ltd
Expires: January 2010                                           N. So
                                                              Verizon
                                                            F. Jounay
                                                       France Telecom
                                                            S. Delord
                                                              Telstra

                      Return Path Specified LSP Ping

           draft-chen-mpls-return-path-specified-lsp-ping-00.txt


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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 15, 2009.

Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info).





Chen, et al.           Expires January 2, 2010                [Page 1]

Internet-Draft     Return Path Specified LSP Ping            July 2009


   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.

Abstract

   This document defines extensions to LSP Ping [RFC 4379] to enable
   the return path(s) of an echo reply message, so that it can be
   specified when sending an echo request message to perform LSP
   failure detection, and the echo reply message is extended to detect
   the return path(s). This capability could improve the reliability of
   echo reply and allows failure detection of a Bidirectional LSP or
   two unidirectional LSPs being performed by one message, resulting in
   operational saving.

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 RFC-2119 [RFC2119].

Table of Contents


   1. Introduction.................................................3
   2. Problem statements and solution overview.....................3
   3. Extensions...................................................4
      3.1. Reply Via Specified Path mode...........................5
      3.2. The return codes........................................5
      3.3. Reply Path (RP) TLV.....................................5
      3.4. Bidirectional sub-TLV...................................6
      3.5. Any Candidate sub-TLV...................................7
   4. Theory of Operation..........................................7
      4.1. Sending an Echo Request.................................8
      4.2. Receiving an Echo Request...............................8
      4.3. Sending an Echo Reply...................................9
      4.4. Receiving an Echo Reply.................................9
   5. Security Considerations.....................................10
   6. IANA Considerations.........................................10
      6.1. Reply mode and return codes............................10
      6.2. RP TLV.................................................11
      6.3. Sub-TLVs for RP TLV....................................11
   7. Acknowledgments.............................................12
   8. References..................................................12
      8.1. Normative References...................................12
      8.2. Informative References.................................13
   Authors' Addresses.............................................14



Chen, et al.           Expires January 2, 2010                [Page 2]

Internet-Draft     Return Path Specified LSP Ping            July 2009



1. Introduction

   This document defines the extensions to LSP Ping that can be used to
   specify the return path(s) of the echo reply message in a LSP Ping
   echo request message. Several new reply mode requirements are added
   and a new Type-Length-Value (TLV) is defined.

   With the extensions described in this document, the operators can
   detect a Co-routed Bidirectional LSP and Associated Bidirectional
   LSP with a single operational action, resulting in operational
   savings.  It can also detect two unidirectional LSPs without any
   inherency or binding relationship (one for each direction) in one
   operational action as well, reduces the opportunity for error, and
   improves the reliability of the echo reply message.

   In this document, Bidirectional LSP includes Co-routed Bidirectional
   LSP defined in [RFC 3471] [RFC 3473] and Associated Bidirectional
   LSP that is constructed from a pair of unidirectional LSPs (one for
   each direction), and are associated with one another at the LSP's
   ingress/egress points. In the rest of this document, if there is no
   extra explanation, when say Bidirectional LSP, it includes both Co-
   routed Bidirectional LSP and Associated Bidirectional LSP.

2. Problem statements and solution overview

   Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping
   is defined in [RFC 4379].  It can be used to detect data plan
   failures in MPLS LSPs. More specifically, it is designed for
   unidirectional LSPs.

   Co-routed Bidirectional LSP is defined in [RFC 3471] [RFC 3473], but
   with the existing LSP Ping mechanisms defined in [RFC 4379], the
   operators have to perform LSP detection on each of the two ends of a
   specific Bidirectional LSP respectively.  It not only doubles the
   workload of the operators, but may also bring additional
   difficulties when checking the backward direction of the LSP under
   the following conditions

     1. The LSR that the operator logged on to perform the checking
     operations may not have out-of-band connectivity to the remote LSR
     of the LSP.  That can result in failing to check the return
     direction of the Bidirectional LSP.

     2. The tested LSP is an inter-domain/inter-AS LSP, the operator of
     one domain/AS may have no right to log on to the remote LSR reside



Chen, et al.           Expires January 2, 2010                [Page 3]

Internet-Draft     Return Path Specified LSP Ping            July 2009


     in another domain/AS. That can also result in failing to check the
     return direction of the Bidirectional LSP.

     3. The return path of the echo reply message is randomly
     determined by the egress of the LSP.  However, there can be more
     than one LSPs connecting the two LSRs.  When a LSP Ping echo
     request for detecting one Bidirectional LSP reached remote LSR,
     the remote LSR may choose another LSP as the return path.  This
     can result in mis-information and mis-diagnostics.

   For Associated Bidirectional LSPs and even unidirectional LSPs, they
   have the similar issues listed above.

   This document defines the extensions to LSP Ping that can be used to
   specify the return path(s) of the echo reply message in a LSP echo
   request message.  A new TLV is defined to carry the specific return
   path(s) information required by the initiator.  Several new reply
   mode requirements are added.  For example, this document specifies
   that the echo reply should return along the back direction LSP of
   the tested Bidirectional LSP, or the specific return path(s) as
   defined in the echo request message.

   The detail extensions and procedures are defined in the following
   sections.

3. Extensions

   LSP Ping defined in [RFC 4379] is carried out by sending echo
   request message.  It carries the Forwarding Equivalence Class (FEC)
   information of the tested LSP for indicating which MPLS path is
   being verified, along the same data path as other normal data
   packets belonging to the FEC.

   The only determinant of the echo reply message return path is the
   four reply modes defined in Section 3 of [RFC 4379].  But it is not
   enough for the egress LSR of the tested LSP to determine how to
   choose the return path(s) of the echo reply message.

   This document defines a new reply mode, Reply Via Specified Path
   mode. This new mode can be used to direct the egress of the tested
   LSP to send back the echo reply message along the path specified in
   the echo request message.

   This document also adds a new TLV, Reply Path TLV.  The Reply Path
   TLV consists one or more sub-TLVs that can be used to carry the




Chen, et al.           Expires January 2, 2010                [Page 4]

Internet-Draft     Return Path Specified LSP Ping            July 2009


   specified return path information of an echo reply message.  The
   detail definitions listed below.

3.1. Reply Via Specified Path mode

   The recommended value of the Reply via specified path mode is 5
   (SHOULD be confirmed by the IANA).

         Value    Meaning
         -----    -------
             5     Reply via specified path

   The Reply via specified path mode is used to notify the remote LSR
   received the LSP Ping echo request message to send back the echo
   reply message along the specified path(s) carried in the Reply Path
   TLV.

3.2. The return codes

   This document defines two new return codes that can be used to
   inform the sender the results of the testing.

         Value    Meaning
         -----    -------
            14    Success to match the specified path
            15    The specified reply path not existence

   Return code 15 is used when egress fails to match the specified
   reply path which is designated by ingress node. For example ingress
   node expects to detect the reply path of the bidirectional LSP, but
   the path being tested isn't bidirectional indeed, and also the
   condition that the specified path does not exist on egress.  Return
   code 14 will be used when egress matches the specified reply path
   successfully. The detailed usage of the return codes is described in
   Section 4.

3.3. Reply Path (RP) TLV

   The Reply Path (RP) TLV is included in an echo request message. It
   carries the specified return path(s) that the echo reply message
   required to follow. The format of RP TLV is as follows:






Chen, et al.           Expires January 2, 2010                [Page 5]

Internet-Draft     Return Path Specified LSP Ping            July 2009


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   RP (reply path) TLV Type    |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Reply Path(s)                           |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RP TLV Type field is 2 octets in length, and the type value is TBD
   (which is needed to be assigned by IANA).

   Length field is 2 octets in length.  It defines the length in octets
   of the Reply Path(s) field.

   Reply Path(s) field is variable in length.  It has several nested
   sub-TLVs that describe the specified path(s) the echo reply message
   is required to follow.  Each of the FEC sub-TLVs defined in [RFC
   4379] is applicable to be a sub-TLV for inclusion in the RP TLV for
   expressing a specific return path.

   In addition, two more new sub-TLVs are defined, Bidirectional sub-
   TLV and Any Candidate sub-TLV.

3.4. Bidirectional sub-TLV

   The Bidirectional sub-TLV is used when the return path is required
   to follow the back direction of the tested Bidirectional LSP.  The
   format of Bidirectional sub-TLV is as follows:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Bidirectional sub-TLV Type   |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Bidirectional sub-TLV Type field is 2 octets in length, and the
   type value is 17 (which is needed to be confirmed by IANA).

   Length field is 2 octets in length, the value of length field MUST
   be 0, it means that there is no any value fields follows.




Chen, et al.           Expires January 2, 2010                [Page 6]

Internet-Draft     Return Path Specified LSP Ping            July 2009


3.5. Any Candidate sub-TLV

   The Any Candidate sub-TLV is used when the return path is required
   to exclude the path(s) that are identified by any other reply path
   sub-TLVs carried in the echo request message. This is very useful
   when one/several previous LSP Ping(s) failed. By carrying an Any
   Candidate sub-TLV and the previous failed reply path sub-TLVs, a new
   LSP Ping echo request could be used to help the egress to select
   another candidate path when sending echo reply message.  The format
   of Any Candidate sub-TLV is as follows:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Any Candidate sub-TLV Type   |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Any Candidate sub-TLV Type field is 2 octets in length, and the
   type value is 18 (which is needed to be confirmed by IANA).

   Length field is 2 octets in length, the value of length field MUST
   be 0, it means that there is no any value fields follows.

4. Theory of Operation

   The procedures defined in this document only apply to "ping" mode,
   how to deal with "traceroute" mode is out of the scope of this
   document.

   In RFC 4379, the echo reply is used to report the LSP checking
   result to the LSP Ping initiator.  This document defines a new reply
   mode and a new TLV (RP TLV) to enable that the return path of the
   echo reply message could specified by the LSP Ping initiator, and
   the function of echo reply is extended to detect the return path by
   carrying specified path FEC TLV. It enables LSP Ping to detect both
   directions of a path in one operation.

   When the echo reply message is intended to test the return MPLS LSP
   path as specified, the destination IP address of the echo reply
   message is never used in a forwarding decision. For the purpose of
   detection the specified return MPLS LSP path, the echo reply message
   also needs to avoid IP forward at the condition of the LSP being
   tested broken. So the destination IP address of the echo reply
   message that is transmitted along the specified return path MUST be
   set numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104
   for Ipv6, and the IP TTL MUST be set 1.  If the echo reply message


Chen, et al.           Expires January 2, 2010                [Page 7]

Internet-Draft     Return Path Specified LSP Ping            July 2009


   is not intended for testing the specified return path, the same as
   defined in [RFC 4379], the destination IP address is copied from the
   source IP address of the echo request.

4.1. Sending an Echo Request

   When sending an echo request, in addition to the rules and
   processing defined in Section 4.3 of [RFC 4379], the reply mode of
   the echo request MUST be set to "Reply via specified path", and a RP
   TLV MUST be carried in the echo request message correspondingly. The
   RP TLV includes one or several reply path sub-TLV(s) to identify the
   return path(s) that is used to notify the egress which path(s) to
   send along.

   For Bidirectional LSP, since the ingress and egress of a
   Bidirectional LSP are aware of the relationship between the forward
   and backward direction LSPs, only a Bidirectional sub-TLV SHOULD be
   carried within the RP TLV. If the operator wants the echo reply to
   be sent along a different path other than the reverse LSP of the
   Bidirectional LSP, another FEC sub-TLV SHOULD be carried in the RP
   TLV instead.

   In some cases, operators may want to detect two unidirectional LSPs
   (one for each direction) as a pair. There may not be any binding
   relationship between the two LSPs. Using the mechanism defined in
   this document, operators can run LSP Ping one time from one end to
   complete the failure detection on both unidirectional LSPs. In such
   condition, when sending the echo request message, one specific FEC
   sub-TLV MUST be carried in the RP TLV to notify the egress which
   path to send along and detect.

4.2. Receiving an Echo Request

   Those processing relevant to "ping" mode defined in Section 4.4 of
   [RFC 4379] apply in this document. In addition, when an echo request
   received, if the egress does not know the reply mode defined in this
   document, an echo reply with return code set to "Malformed echo
   request" and the Subcode set to zero SHOULD be send back to the
   ingress. If the egress knows the reply mode, according to the RP TLV,
   it SHOULD find and select a matched return path, if there is no such
   a path, an echo reply with return code set to "The specified reply
   path not existence" and the Subcode to zero SHOULD be sent back to
   the ingress. If there is a match, an echo reply with return code set
   to "Success to match the specified path" and Subcode to zero SHOULD
   be sent back to the ingress.




Chen, et al.           Expires January 2, 2010                [Page 8]

Internet-Draft     Return Path Specified LSP Ping            July 2009


   When received an echo request with reply mode set to "Reply via
   specified path", if there is no Any Candidate sub-TLV included in
   the RP TLV, means that the echo reply is required to send along the
   specified path and to detect the return path as well. Otherwise,
   means that the echo reply is not required to detect the return path.

4.3. Sending an Echo Reply

   As described in [RFC 4379], the echo reply message is a UDP packet,
   and it MUST only be sent response to an MPLS echo request. The
   source IP address is a routable IP address of the replier, the
   source UDP port is the well-know UDP port for LSP ping.

   When the echo reply is intended to test the return path, the
   destination IP address of the echo reply message MUST be never used
   in a forwarding decision. For the purpose of detection the specified
   return MPLS LSP path, the echo reply message also needs to avoid IP
   forward at the condition of the LSP being tested broken. So the
   destination IP address of the echo reply message that is transmitted
   along the specified return path MUST be set numbers from the range
   127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for Ipv6, and the IP TTL
   MUST be set 1.  If the echo reply is required to test the return
   path, the echo reply MUST have an FEC stack TLV about the return
   path, which is used for the ingress to perform FEC validation. The
   FEC stack TLV of the forward path MUST NOT be copied to the echo
   reply.

   If the echo reply message is not intended for testing the specified
   return path, the same as defined in [RFC 4379], the destination IP
   address and UDP port are copied from the source IP address and
   source UDP port of the echo request.

   When sending the echo reply, the RP TLV carried in the received echo
   request MAY be copied to the echo reply to give the Ingress enough
   information about the back direction tested path to verify the
   consistent of the data plane against control plane.

4.4. Receiving an Echo Reply

   The rules and process defined in Section 4.6 of [RFC 4379] apply
   here. And when an echo reply received, if the reply mode is "Reply
   via specified path" and an FEC stack TLV exists, it means that the
   echo reply has both Ping result reporting and reverse path checking
   functions. The ingress MUST do FEC validation as an egress does when
   received an echo request, the FEC validation process (relevant to
   "ping" mode) defined in Section 4.4.1 of [RFC 4379] apply here.



Chen, et al.           Expires January 2, 2010                [Page 9]

Internet-Draft     Return Path Specified LSP Ping            July 2009


   When received an echo reply with return code set to "Malformed echo
   request received" and the Subcode set to zero. It's possible that
   the egress may not know the "Reply via specified path" reply mode,
   the operator may choose to re-perform another LSP Ping by using one
   of the four reply modes defined [RFC 4379].

   When the LSP Ping initiator failed to receive the echo reply message,
   the operator MAY initiate another LSP Ping by resending a new echo
   request carrying a RP TLV that includes an Any Candidate sub-TLV and
   the previous sent reply path sub-TLV(s) (Bidirectional sub-TLV or
   FEC sub-TLVs) to notify the egress LSR to send echo reply message
   along any other workable path (no matter what MPLS LSP or IP path)
   excluding the path(s) identified by those Bidirectional sub-TLV
   or/and FEC sub-TLVs. Hence it could improve the reliability of the
   echo reply message. In such mode, the echo reply SHOULD NOT be used
   to detect the return path.

5. Security Considerations

   Security considerations discussed in [RFC 4379] applies to this
   document.

6. IANA Considerations

   IANA is requested to make the following allocations from registries
   under its control.

6.1. Reply mode and return codes

   IANA is requested to assign a new reply mode and two new return
   codes as follows:

   Reply mode:

      Value    Meaning
      -----    -------
          5    Reply via specified path

   Return codes:









Chen, et al.           Expires January 2, 2010               [Page 10]

Internet-Draft     Return Path Specified LSP Ping            July 2009


      Value    Meaning
      -----    -------
         14   Success to match the specified path
         15   The specified reply path not existence

6.2. RP TLV

   IANA is requested to assign a new TLV type (TBD) from the range of
   0-16383. We suggest that the value 20 be assigned for the new RP TLV
   type.

       Type    Value Field
      -----    -----------
         20    Reply Path

6.3. Sub-TLVs for RP TLV

   This document defines two new sub-TLV Types (described in Section
   3.4 and 3.5) of RP TLV, and those FEC sub-TLVs defined in [RFC 4379]
   are applicable for inclusion in RP TVL.

   IANA is requested to assign sub-TLVs as follows. The following
   numbers are suggested:
























Chen, et al.           Expires January 2, 2010               [Page 11]

Internet-Draft     Return Path Specified LSP Ping            July 2009


      Sub-type        Value Field                  Reference
      --------        -----------                  ---------
               1          LDP IPv4 prefix                   RFC 4379
               2          LDP IPv6 prefix                   RFC 4379
               3          RSVP IPv4 LSP                     RFC 4379
               4          RSVP IPv6 LSP                     RFC 4379
               5          Not Assigned                      RFC 4379
               6          VPN IPv4 prefix                   RFC 4379
               7          VPN IPv6 prefix                   RFC 4379
               8          L2 VPN endpoint                   RFC 4379
               9          "FEC 128" Pseudowire (Deprecated) RFC 4379
              10          "FEC 128" Pseudowire              RFC 4379
              11          "FEC 129" Pseudowire              RFC 4379
              12          BGP labeled IPv4 prefix           RFC 4379
              13          BGP labeled IPv6 prefix           RFC 4379
              14          Generic IPv4 prefix               RFC 4379
              15          Generic IPv6 prefix               RFC 4379
              16          Nil FEC                           RFC 4379
              17          Bidirectional                     this document
              18          Any Candidate                     this document

7. Acknowledgments

   The authors would like to thank Adrian Farrel and Ehud Doron for
   their review and comments to this document.

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.

   [RFC 4379] K. Kompella., et al., "Detecting Multi-Protocol Label
             Switched (MPLS) Data Plane Failures", RFC 4379, February
             2006.







Chen, et al.           Expires January 2, 2010               [Page 12]

Internet-Draft     Return Path Specified LSP Ping            July 2009


8.2. Informative References

   [RFC 3471] L. Berger, "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Functional Description", RFC 3471,
             January 2003.

   [RFC 3473] L. Berger, "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling", RFC 3473, January 2003.








































Chen, et al.           Expires January 2, 2010               [Page 13]

Internet-Draft     Return Path Specified LSP Ping            July 2009


Authors' Addresses

   Mach(Guoyi) Chen
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Hai-Dian District, Beijing 100085
   P.R. China

   EMail: mach@huawei.com


   Xinchun Guo
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Hai-Dian District, Beijing 100085
   P.R. China

   EMail: guoxinchun@huawei.com


   Wei Cao
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Hai-Dian District, Beijing 100085
   P.R. China

   EMail: caoweigne@chinamobile.com


   So Ning
   Verizon
   2400 N. Glem Ave.,
   Richerson, TX  75082

   Phone: +1 972-729-7905
   EMail: ning.so@verizonbusiness.com


   Frederic Jounay
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   FRANCE

   EMail: frederic.jounay@orange-ftgroup.com




Chen, et al.           Expires January 2, 2010               [Page 14]

Internet-Draft     Return Path Specified LSP Ping            July 2009



   Simon Delord
   Telstra
   242 Exhibition St
   Melbourne VIC 3000
   Australia

   EMail: simon.a.delord@team.telstra.com








































Chen, et al.           Expires January 2, 2010               [Page 15]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/