[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02                                                      
MPLS Working Group                                          L. Dunbar
Internet Draft                                                 Huawei
Intended status: Standard Track                                 N. So
Expires: February 2011                                        Verizon
                                                  P. Niger, Y. Le Goff
                                                        France Telecom
                                                      August 13, 2010


              Detecting MPLS Path Impairment using MPLS-Ping


             draft-dunbar-so-mpls-detect-impair-mplsping-02.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 February 13, 2009.

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
   (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



Dunbar                Expires February 13, 2011               [Page 1]


Internet-Draft    Path Condition Marking using BFD         August 2010


   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Abstract

   The MPLS-Ping is for detecting data path failure. This draft suggests
   an extension to MPLS-Ping so that transit LSR can indicate the
   downstream link impairment condition to the source LSR.

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

Table of Contents


   1. Motivation..........................................2
   2. MPLS-Ping extension for path condition impairment indication..3
      2.1. Downstream Link Condition sub-TLV...................4
      2.2. Link Condition Request in Echo Request...............5
      2.3. Receiving Echo Request with a Path Condition Request flag set
      ..................................................6
   3. Receiving Path Condition Impairment Notification...........6
   4. Manageability Considerations...........................7
   5. Security Considerations...............................7
   6. IANA Considerations...................................7
   7. Acknowledgments......................................7
   8. References..........................................7
      8.1. Normative References..............................7
   Authors' Addresses......................................8
   Intellectual Property Statement...........................8
   Disclaimer of Validity...................................9



1. Motivation

   MPLS-Ping [MPLS-Ping] can be used to detect faults along the LSP
   path. One of the faults detected by MPLS-Ping is downstream link
   failure, i.e. link connectivity being down. In some network
   environment, source node also needs to know the condition of the link
   on which the LSPs are carried even though the link connectivity is
   up.  That way the source LSR can perform needed functions, such as
   enforcing admission control, re-signal and/or re-compute the LSP



Dunbar, So            Expires February 13, 2011               [Page 2]


Internet-Draft    Path Condition Marking using BFD         August 2010


   path, or generate more stringent performance monitoring at shorter
   interval, and etc.

   A common example for the link condition change is the bandwidth
   fluctuation in Mobile Backhaul network, where Microwave transport is
   widely deployed. Most Microwave transport nodes adjust its bandwidth
   based on the weather. Even though there is RSVP-TE for individual
   links to advertise its available bandwidth in the routing domain,
   end-to-end bandwidth change may not be possible in some Mobile
   Backhaul environment, because there may be multiple routing domains
   from base stations to MSO. If Source Nodes, i.e. LTE's eNodeB or
   MSO's RNC, are aware of the bandwidth change, they can adjust
   services accordingly, request other base stations to accept new
   calls, or trigger a new Performance Monitoring scheme to track the
   condition more closely.

   In another application, source LSRs may want to be aware of the
   congestion along the LSP path, so that proper actions can be taken.
   MPLS-ECN (RFC 5129) specifies a mechanism for transit nodes to mark
   EXP bits when congestion happens. However, many deployed MPLS
   networks already use EXP bits to mark packet priorities, making MPLS-
   ECN (RFC 5129) mechanism un-usable for the purpose of LSP change
   indication.

   In a third application, source LSRs may want to be aware of
   significant performance degradation on the downstream links along the
   LSP path.  The performance degradation can be increased latency
   and/or increased delay variation.  Those performance degradations may
   be induced by the physical layer protection scheme, such as link
   switching from active side of the ring to protect side of the ring,
   or it may be induced by transmission media degradation.

   In a forth application, source LSRs may want to be aware of transport
   media change on the downstream links along the LSP path.  For
   example, the link can be a fiber protected by microwave, and the
   source router may be carrying an application that cannot use
   microwave due to security concerns.

   This draft suggests adding a new sub-TLV to the MPLS Ping Echo Reply
   for the transit LSR to indicate the downstream link condition changes
   to source routers.

2. MPLS-Ping extension for path condition impairment indication

   [MPLS-Ping] specified that replying router for MPLS Ping should
   include one Downstream Mapping for each interface, over which this
   FEC could be forwarded, in the Echo Reply.  [MPLS-Ping-Enhanced] has


Dunbar, So            Expires February 13, 2011               [Page 3]


Internet-Draft    Path Condition Marking using BFD         August 2010


   introduced 3 types of sub-TLV to the Downstream Detailed Mapping,
   Multipath data, Label stack, and FEC Stack change.

   This draft suggests adding a new sub-TLV "Downstream Link Condition"
   to indicate the condition of the downstream link of the corresponding
   interface. The "Downstream Path Condition" could be bandwidth being
   reduced, the interface being congested, etc.

     Sub-Type   Value Field
   --------       --------
     TBD      Multipath data (specified by [MPLS-Ping-Enhanced])
     TBD      Label stack (specified by [MPLS-Ping-Enhanced])
     TBD      FEC Stack change (specified by [MPLS-Ping-Enhanced])
      TBD        Downstream Link Condition (new)


2.1. Downstream Link Condition sub-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          | Length        |ImpairmentType | SeverityLevel |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The Impairment Type field can take one of the following values:

     Value   Meaning
   --------    --------
     1     port towards downstream LSR is congested
     2     Bandwidth of the link towards downstream LSR is reduced
     3     performance of the link towards downstream LSR is reduced
     4        transport media of the link towards downstream LSR has
               been changed


   The Severity Level field is a value indicating the severity of the
   impairment. Network operator can set the Severity Level for
   anticipated conditions and configure the proper actions at the source
   node upon receiving the Echo Reply. For example, Severity Level 0 can
   represent full bandwidth, 1 represents the next bandwidth level, and
   6 represents the least bandwidth. For microwave transport link within
   MPLS based Mobile Backhaul network, the Adaptive Modulation usually
   has several levels of adjusted bandwidth, which can be used as the
   basis for setting the Severity Level.



Dunbar, So            Expires February 13, 2011               [Page 4]


Internet-Draft    Path Condition Marking using BFD         August 2010


2.2. Link Condition Request in Echo Request

   If a source LSR of a LSP cannot do anything when the LSP path is
   impaired, then there is no point for the transit LSR to send any link
   condition in the Echo Reply to the sender. Therefore, it is necessary
   for the sender to indicate if it desires to receive the Downstream
   Link Condition status in the Echo Reply. This draft suggests using
   one reserved bit of DS flags in the Echo Request for the source node
   to indicate if it desires to receive the impairment condition of the
   downstream link on a transit LSR.

     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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               MTU             | Address Type  |    DS Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Downstream IP Address (4 or 16 octets)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Downstream Interface Address (4 or 16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Multipath Type| Depth Limit   |        Multipath Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                     (Multipath Information)                   .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Downstream Label                |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Downstream Label                |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   DS Flags

     RFC4379 already defines I bit and N bit out of the octet DS Flags.
     This draft suggests adding a new bit C for source LSR to indicate
     if it desires to have the link impairment condition to be reported
     by transit LSR in the Echo Reply.

     The DS flags field is a bit vector with the following format:
          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+


Dunbar, So            Expires February 13, 2011               [Page 5]


Internet-Draft    Path Condition Marking using BFD         August 2010

         |Rsvd(MBZ)|C|I|N|
         +-+-+-+-+-+-+-+-+


     I and N flags are already specified by RFC 4379. The C flag is
     defined as follow:

      Flag  Name and Meaning
       -----   ----------------
       C     Source LSR desires to know the downstream link condition

     When this flag is set (C = 1), it indicates that the replying
     router SHOULD include the downstream link condition sub-TLV in the
     echo reply message. When this flag is not set (C=0), it indicates
     that the source LSR doesn't need downstream path condition
     information, so replying router SHOULD NOT include the downstream
     link condition sub-TLV in the echo reply.

2.3. Receiving Echo Request with a Path Condition Request flag set

     If the DS flags' C is set, the receiving LSRs HAVE TO construct the
     Downstream Link Condition sub-TLV and insert it into the Echo
     Reply.

3. Receiving Path Condition Impairment Notification

   Though it is out of the scope of this draft on what Source LSR will
   do upon receiving the Path Condition in the Echo Reply, here are some
   examples of possible actions Source LSR could do:

       trigger more stringent performance monitoring in shorter
        interval to measure the quality of the path

       re-adjust load balancing among the multiple paths from Source
        LSR to the Destination LSR

       Re-signal LSP to alternative path

       activate the secondary/protection path

       adjust admission rate (in the case of LTE eNodeB)

       Notify adjacent client device via E-LMI, IEEE802.3ah, or simple
        flow control.





Dunbar, So            Expires February 13, 2011               [Page 6]


Internet-Draft    Path Condition Marking using BFD         August 2010


4. Manageability Considerations

   This document does not add additional manageability considerations.

5. Security Considerations

   This document has no additional requirement for a change to the
   security models of MPLS-Ping and MPLS-Ping-Enhanced.

6. IANA Considerations

   A future revision of this document will present requests to IANA for
   codepoint allocation.



7. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.



8. References

                              8.1. Normative References

   [ECN]   B. Davie, et. al., "Explicit Congestion Marking in MPLS",
             RFC 5129, Jan. 2008.

   [MPLS-PING] K. Kompella, et. al., "Detecting MPLS Data Plane
             Failures", RFC 4379, February 2006.

   [BFD-MPLS] Aggarwal, R., "draft-ietf-bfd-mpls-07.txt", work in
             progress.

   [LSP-Ping-Enhanced] N. Bahadur, et. al.,"Mechanism for performing
             LSP-Ping over MPLS tunnels", "draft-ietf-mpls-lsp-ping-
             enhanced-dsmap-04", work in progress.










Dunbar, So            Expires February 13, 2011               [Page 7]


Internet-Draft    Path Condition Marking using BFD         August 2010


Authors' Addresses

   Linda Dunbar (Ed.)
   Huawei Technologies
   1700 Alma Drive, Suite 500
   Plano, TX 75075, USA
   Phone: (972) 543 5849
   Email: ldunbar@huawei.com


   Ning So (Ed.)
   Enterprise Data Network and Traffic Planning
   2400 N. Glenville Dr.
   Richardson, TX 75082, USA
   Phone: (972) 729 7905
   Email: ning.so@verizonbusiness.com

   Philippe Niger
      France Telecom
      2, avenue Pierre-Marzin
      22307 Lannion Cedex
      FRANCE
      Email: philippe.niger@orange-ftgroup.com

   Yannick Le Goff
      France Telecom
      2, avenue Pierre-Marzin
      22307 Lannion Cedex
      FRANCE
      Email: yannick1.legoff@orange-ftgroup.com


Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or



Dunbar, So            Expires February 13, 2011               [Page 8]


Internet-Draft    Path Condition Marking using BFD         August 2010


   users of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
























Dunbar, So            Expires February 13, 2011               [Page 9]