Networking Working Group                             Matthew.
Internet Engineering Task Force (IETF)                     M. Meyer, Ed.
Internet-Draft
Request for Comments: 5712                               British Telecom
Intended status:
Category: Standards Track                               JP. Vasseur, Ed.
Expires: January 30, 2010
ISSN: 2070-1721                                      Cisco Systems, Inc
                                                           July 29, 2009 Inc.
                                                            January 2010

                MPLS Traffic Engineering Soft Preemption
                 draft-ietf-mpls-soft-preemption-18.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 January 30, 2010.

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).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies Multiprotocol Label Switching (MPLS) Traffic
   Engineering Soft Preemption, a suite of protocol modifications
   extending the concept of preemption with the goal of reducing/ reducing or
   eliminating traffic disruption of preempted Traffic Engineering Label
   Switched Paths (TE LSPs).  Initially  Initially, MPLS RSVP-TE was defined
   supporting with
   support for only immediate TE LSP displacement upon preemption.  The
   utilization of a reroute request notification helps more gracefully
   mitigate the re-route reroute process of preempted TE LSP.  For the brief
   period soft preemption is activated, reservations (though not
   necessarily traffic levels) are in effect under-provisioned until the
   TE LSP(s) can be re-routed. rerouted.  For this reason, the feature is
   primarily
   primarily, but not exclusively exclusively, interesting in MPLS enabled MPLS-enabled IP
   networks with Differentiated Services and Traffic Engineering
   capabilities.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and "OPTIONAL" has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5712.

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
   the Trust Legal Provisions and are to be interpreted provided without warranty as
   described in RFC 2119 [RFC2119]. the Simplified BSD License.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4 ....................................................3
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4 .....................................................3
      2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . .  4 .................................3
      2.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . .  5 ...............................................4
      2.3. Requirements Language ......................................4
   3. Motivations  . . . . . . . . . . . . . . . . . . . . . . . . .  5 .....................................................4
   4. RSVP Extensions  . . . . . . . . . . . . . . . . . . . . . . .  6 .................................................5
      4.1. SESSION-ATTRIBUTE Flags  . . . . . . . . . . . . . . . . .  6 ....................................5
      4.2. Path Error - "Reroute request Request Soft Preemption"
           Error Value  . . . . . . . . . . . . . . . . . . . . . . . . . .  6 ................................................5
   5. Mode of Operation  . . . . . . . . . . . . . . . . . . . . . .  6 ...............................................6
   6. Elements Of Procedures . . . . . . . . . . . . . . . . . . . .  8 ..........................................7
      6.1. On a Soft Preempting LSR . . . . . . . . . . . . . . . . .  8 ...................................7
      6.2. On Head-end LSR of a Soft Preempted TE LSP . . . . . . . . 10 .................9
   7. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 10 ...............................................10
   8. Management . . . . . . . . . . . . . . . . . . . . . . . . . . 11 .....................................................10
   9. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11 ............................................11
      9.1. New Session Attribute Object Flag  . . . . . . . . . . . . 12 .........................11
      9.2. New error sub-code value . . . . . . . . . . . . . . . . . 12 Error Sub-Code Value ..................................11
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 12 .......................................11
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 ..............................................12
   12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Contributors ..................................................12
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ....................................................12
      13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 .....................................12
      13.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 ...................................13

1.  Introduction

   In an a Multiprotocol Label Switching (MPLS) Resource Reservation
   Protocol Traffic Engineering (RSVP-TE) (see [RFC3209]) enabled IP
   network, hard preemption is the default behavior.  Hard preemption
   provides no mechanism to allow preempted Traffic Engineering Label
   Switched Paths (TE LSPs) to be handled in a make-before-break
   fashion: the hard preemption scheme instead utilizes a very intrusive
   method that can cause traffic disruption for a potentially large
   amount of TE LSPs.  Without an alternative, network operators either
   accept this limitation, or remove functionality by using only one
   preemption priority or using invalid bandwidth reservation values.
   Understandably desirable features like ingress (Label Edge Router)
   LER automated (Traffic Engineering (TE) TE reservation adjustments
   that are automated by the ingress Label Edge Router (LER) are less
   palatable when preemption is intrusive and maintaining high levels of
   network stability levels are is a concern.

   This document defines the use of additional signaling and maintenance
   mechanisms to alert the ingress LER of the preemption that is pending
   and allow for temporary control plane control-plane under-provisioning while the
   preempted tunnel is re-routed rerouted in a non disruptive non-disruptive fashion (make-
   before-break) by the ingress LER.  During the period that the tunnel
   is being re-routed, rerouted, link capacity is under-provisioned on the midpoint
   where preemption initiated and potentially one or more links upstream
   along the path where other soft preemptions may have occurred.

2.  Terminology

   This document follows the nomenclature of the MPLS Architecture
   defined in [RFC3031].

2.1.  Acronyms and Abbreviations

   CSPF: Constrained Shortest Path First.

   DS: Differentiated Services.

   LER: Label Edge Router.

   LSR: Label Switching Router.

   LSP: Label Switched Path.

   MPLS: MultiProtocol Label Switching.

   RSVP: Resource ReSerVation Protocol.

   TE LSP: Traffic Engineering Label Switched Path.

2.2.  Nomenclature

   Point of Preemption - the midpoint or ingress LSR which due to RSVP
   provisioning levels is forced to either hard preempt or under-
   provision and signal soft preemption.

   Hard Preemption - The (typically default) preemption process in which
   higher numeric priority TE LSPs are intrusively displaced at the
   point of preemption by lower numeric priority TE LSPs.  In hard
   preemption
   preemption, the TE LSP is torn down before reestablishment.

2.3.  Requirements Language

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

3.  Motivations

   Initially Multiprotocol Label Switching (MPLS)

   Initially, MPLS RSVP-TE [RFC3209] was defined supporting with support for only
   one method of TE LSP preemption preemption, which immediately tears down TE
   LSPs, disregarding the preempted in-transit traffic.  This simple but
   abrupt process nearly guarantees preempted traffic will be discarded,
   if only briefly, until the RSVP Path Error message reaches and is
   processed by the ingress LER and a new data path can be established.
   The Error Code and Error Values carried within the RSVP Path Error
   message to report a preemption action are documented in [I-D.ietf-mpls-3209-patherr]. [RFC5711].
   Note that such preemption is also referred to as a fatal error in
   [I-D.ietf-mpls-3209-patherr].
   [RFC5711].  In cases of actual resource contention this might be helpful, however
   helpful; however, preemption may be triggered by mere reservation contention
   contention, and reservations may not reflect data plane data-plane contention up
   to the moment.  The result is that when conditions that promote
   preemption exist and hard preemption is the default behavior,
   inferior priority preempted traffic may be needlessly discarded when
   sufficient bandwidth exists for both the preempted Traffic
   Engineering Labeled Switched Path (TE LSP) TE LSP and the
   preempting TE LSP(s).

   Hard preemption may be a requirement to protect numerically lower
   preemption priority traffic in a non Diff-Serv enabled non-Diffserv-enabled architecture,
   but in a Diff-Serv enabled architecture, Diffserv-enabled-architecture, one need not rely exclusively
   upon preemption to enforce a preference for the most valued traffic
   since the marking and queuing disciplines should already be aligned
   for those purposes.  Moreover, even in non Diff-
   Serv aware non-Diffserv-aware networks,
   depending on the TE LSP sizing rules (imagine all LSPs are sized at
   double their observed traffic level), reservation contention may not
   accurately reflect the potential for
   data plane data-plane congestion.

4.  RSVP Extensions

4.1.  SESSION-ATTRIBUTE Flags

   To explicitly signal the desire for a TE LSP to benefit from the soft
   preemption mechanism (and so thus not to be hard preempted if the soft
   preemption mechanism is available), the following flag of the
   SESSION-ATTRIBUTE object (for both the C-Type 1 and 7) is defined:

   Soft Preemption Desired bit

   Bit Flag  Name Flag
     0x40    Soft Preemption Desired

4.2.  Path Error - "Reroute request Request Soft Preemption" Error Value

   [I-D.ietf-mpls-gmpls-lsp-reroute]

   [RFC5710] specifies defines a new reroute-
   specific reroute-specific error code that
   allows a mid-point midpoint to report a TE LSP reroute request (Error-code=34 (Error Code=34 -
   Reroute).  This document specifies a new error Error Value sub-code value for the
   case of Soft Preemption (to be
   confirmed by IANA upon publication of this document). soft preemption.

   Error-value               Meaning                    Reference
     1            Reroute Request Soft Preemption     This document

   Upon (soft) preemption, the preemting preempting node MUST issue a PathErr
   message with the error code=34 Error Code=34 ("Reroute") and a value=1 ("Reroute
   request soft preemption"), to be confirmed by IANA.
   Request Soft Preemption").

5.  Mode of Operation

   Let's consider the following example:

    R0--1G--R1---155----R2
             | \         |
             |   \      155
             |    \      |
            155   1G     R3
             |       \   |
             |        \ 155
             |          \|
             R4----1G----R5

             LSP1:        LSP2:

             R0-->R1      R1<--R2
                   \      |
                   V      V
                   R5     R4

              Figure 1: Example of Soft Preemption Operation

   In the network depicted above in figure Figure 1, consider the following
   conditions:

   o  Reservable BW on R0-R1, R1-R5 R1-R5, and R4-R5 is 1Gb/sec. 1 Gbit/s.

   o  Reservable BW on R1-R2, R1-R4, R2-R3, and R3-R5 is 155 Mb/sec. Mbit/s.

   o  Bandwidths and costs are identical in both directions.

   o  Each circuit has an IGP metric of 10 10, and the IGP metric is used
      by CSPF.

   o  Two TE tunnels are defined: -

      *  LSP1: 155 Mb, Mbit/s, setup/hold priority 0 tunnel, path R0-R1-R5. -

      *  LSP2: 155 Mb, Mbit/s, setup/hold priority 7 tunnel, path R2-R1-R4.

      Both TE LSPs are signaled with the soft
      preemption desired "Soft Preemption Desired" bit
      of their SESSION-ATTRIBUTE object set.

   o  Circuit R1-R5 fails fails.

   o  Soft Preemption is functional.

   When the circuit R1-R5 fails, R1 detects the failure and sends an
   updated IGP LSA/LSP and Path Error message to all the head-end LSRs
   having
   that have a TE LSP traversing the failed link (R0 in the example
   above).  Either form of notification may arrive at the head-end LSRs
   first.  Upon receiving the link failure notification, R0 triggers a
   TE LSP
   re-route reroute of LSP1, and re-signals LSP1 along shortest path
   available satisfying the TE LSP constraints: R0-R1-R4-R5 path.  The
   Resv messages for LSP1 travel in the upstream direction (from the
   destination to the head-end LSR - -- R5 to R0 in this example).  LSP2
   is soft preempted at R1 as it has a numerically lower priority value value,
   and both bandwidth reservations cannot be satisfied on the R1-R4
   link.

   Instead of sending a path tear PathTear message for LSP2 upon preemption as
   with hard preemption (which would result in an immediate traffic
   disruption for LSP2), R1s R1's local bandwidth accounting for LSP2 is zeroed
   zeroed, and a PathErr message with error code "Reroute" and a value
   "Reroute
   request soft preemption" Request Soft Preemption" for LSP2 is issued.

   Upon reception of the PathErr message for LSP2, R2 may update the
   working copy of the TE-DB before running calculating a new path for the new
   LSP.  In the case that Diff-Serv Diffserv [RFC3270] and TE [RFC3209] are
   deployed, receiving a preemption pending "preemption pending" notification may imply to
   a head-end LSR that the available bandwidth for the affected priority
   level and numerically greater priority levels has been exhausted for
   the indicated node interface.  R2 may choose to reduce or zero the
   available bandwidth for the implied priority range until more
   accurate information is available (i.e. (i.e., a new IGP TE update is
   received).  It follows that R2 re-computes a new path and performs a
   non traffic disruptive
   non-traffic-disruptive rerouting of the new TE LSP T2 by means of the
   make-before-break procedure.  The old path is then torn down.

6.  Elements Of Procedures

6.1.  On a Soft Preempting LSR

   When a new TE LSP is signaled which that requires to preempt a set of TE LSP(s) to be
   preempted because not all TE LSPs can be accommodated on a specific
   interface, a node triggers a preemption action which that consists of
   selecting the set of TE LSPs that must be preempted so as to free up
   some bandwidth in order to satisfy the newly signaled numerically
   lower preemption TE LSP.

   With hard preemption, when a TE LSP is preempted, the preempting node
   sends an RSVP PathErr message notifiying that serves as notification of a fatal
   action as documented in [I-D.ietf-mpls-3209-patherr]. [RFC5711].  Upon receiving the RSVP PathErr
   message, the head-end LSR sends an RSVP Path Tear PathTear message, which that would
   result in an immediate traffic disruption for the preempted TE
   LSP). LSP.

   By contrast, the mode of operation with soft preemption is as
   follows: the preempting node's local bandwidth accounting for the
   preempted TE LSP is zeroed and a PathErr with error code "Reroute" "Reroute",
   and a error value "Reroute request soft preemption" Request Soft Preemption" for that TE LSP
   is issued upstream toward the head-end LSR.

   If more than one soft preempted TE LSP has the same head-end LSR,
   these soft preemption PathErr notification messages may be bundled
   together.

   The preempting node MUST immediately send a PathErr with error code
   "Reroute" and a error value "Reroute request soft preemption" Request Soft Preemption" for
   each soft preempted TE LSP.  The node MAY use the occurrence of soft
   preemption to trigger an immediate IGP update or influence the
   scheduling of an IGP update.

   To guard against a situation where bandwidth under-provisioning will
   last forever, a local timer (named the "Soft preemption timer") MUST
   be started on the preemption node, node upon soft preemption.  If this
   timer expires, the preempting node SHOULD send an RSVP PathTear and
   either a ResvTear message or a PathErr with the 'Path_State_Removed'
   flag set.

   Should a refresh event for a soft preempted TE LSP arrive before the
   soft preemption timer expires, the soft preempting node MUST continue
   to refresh the TE LSP.

   When the MESSAGE-ID extensions defined in [RFC2961] are available and
   enabled, PathErr messages with the error code "Reroute" and an error
   value "Reroute request soft preemption" Request Soft Preemption" SHOULD be sent in reliable
   mode.

   The preempting node MAY preempt TE LSPs which that have a numerically
   higher Holding priority than the Setup priority of the newly admitted
   LSP.  Within the same priority, first it SHOULD attempt to pre-empt preempt
   LSPs with the "Soft Preemption Desired" bit of the SESSION ATTRIBUTE
   object cleared, i.e., the TE LSP LSPs that are considered as Hard Preemptable, first.
   Preemptable.

   Selection of the preempted TE LSP at a preempting mid-point: midpoint: when a
   numerically lower priority TE LSP is signaled that requires the
   preemption of a set of numerically higher priority LSPs, the node
   where preemption is to occur has to make a decision on the set of TE
   LSP(s),
   LSP(s) that are candidates for preemption.  This decision is a local
   decision and various algorithms can be used, depending on the
   objective (e.g, see [RFC4829]).  As already mentioned, soft
   preemption causes a temporary link under provisioning under-provisioning condition while
   the soft preempted TE LSPs are rerouted by their respective head-end
   LSRs.  In order to reduce this under provisioning under-provisioning exposure, a soft-preempting soft
   preempting LSR MAY check first if there exists soft preemptable TE
   LSP bandwidth that is flagged by another node but still available for soft-preemption
   soft preemption locally.  If sufficient overlap bandwidth exists exists, the
   LSR MAY attempt to soft preempt the same TE LSP.  This would help reducing
   reduce the temporarily elevated under-provisioning ratio on the links
   where soft preemption occurs and reduce the number of preempted TE
   LSPs.  Optionally, a midpoint LSR upstream or downstream from a soft
   preempting node MAY choose to flag the TE LSPs in soft preempted
   state.  In the event a local preemption is needed, the relevant priority level LSPs from that are
   in the cache and of the relevant priority level are soft preempted
   first, followed by the normal soft and hard preemption selection
   process for the given priority.

   Under specific circumstances such as unacceptable link congestion, a
   node MAY decide to hard preempt a TE LSP (by sending a fatal Path
   Error message, a PathTear PathTear, and either a ResvTear or a Path Error
   message with the 'Path_State_Removed' flag set) even if its head-end
   LSR explicitly requested 'soft preemption' ('Soft soft preemption (by setting the "Soft
   Preemption desired' Desired" flag of the corresponding SESSION-ATTRIBUTE object set).
   object).  Note that such a decision MAY also be taken made for TE LSPs
   under soft preemption state.

6.2.  On Head-end LSR of a Soft Preempted TE LSP

   Upon reception of a PathErr message with error code "Reroute" and an
   error value "Reroute request soft preemption", the head-end LSR MAY
   first update the working copy of the TE-DB before computing a new
   path (e.g (e.g., by running CSPF) for the new LSP.  In the case that Diff-
   Serv
   Diffserv [RFC3270] and MPLS Traffic Engineering [RFC3209] are
   deployed, receiving preemption pending "preemption pending" may imply to a head-end LSR
   that the available bandwidth for the affected priority level and
   numerically greater priority levels has been exhausted for the
   indicated node interface.  A head-end LSR MAY choose to reduce or
   zero the available bandwidth for the implied priority range until
   more accurate information is available (i.e., a new IGP TE update is
   received).

   Once a new path has been computed, the soft preempted TE LSP is
   rerouted using the non traffic disruptive non-traffic-disruptive make-before-break
   procedure.  The amount of time the head-end node avoids using the
   node interface identified by the IP address contained in the PathErr
   is based on a local decision at the head-end node.

   As a result of soft preemption, no traffic will be needlessly black black-
   holed due to mere reservation contention.  If loss is to occur, it
   will be due only to an actual traffic congestion scenario and
   according to the operators Diff-Serv operator's Diffserv (if Diff-Serv Diffserv is deployed) and
   queuing scheme.

7.  Interoperability

   Backward compatibility should be assured as long as the
   implementation followed the recommendations set forth in [RFC3209].

   As mentioned previously, to guard against a situation where bandwidth
   under-provisioning will last forever, a local timer (soft preemption
   timer) MUST be started on the preemption node, node upon soft preemption.
   When this timer expires, the soft preempted TE LSP SHOULD be hard
   preempted by sending a fatal Path Error message, a PathTear message message,
   and either a ResvTear message or a PathErr message with the
   'Path_State_Removed' flag set.  This timer SHOULD be configurable configurable,
   and a default value of 30 seconds is RECOMMENDED.

   It is RECOMMENDED that configuring the default preemption timer to 0
   will cause the implementation to use hard-preemption.

   Soft Preemption preemption as defined in this document is designed for use in
   MPLS RSVP-TE enabled IP Networks networks and may not functionally translate
   to some GMPLS technologies.  As with backward compatibility, if a
   device does not recognize a flag, it should pass the subobject
   transparently.

8.  Management

   Both the point of preemption and the ingress LER SHOULD provide some
   form of accounting internally and to the network operator interface
   with regard to which TE LSPs and how much capacity is under-
   provisioned due to soft preemption.  Displays of under-provisioning
   are recommended for the following midpoint, ingress ingress, and egress
   views:

   o  Sum of current bandwidth per preemption priority per local
      interface

   o  Sum of current bandwidth total per local interface

   o  Sum of current bandwidth total per local router (ingress, egress,
      midpoint)

   o  List of current LSPs and bandwidth in PPend (preemption pending)
      status
   o  List of current sum bandwidth and session count in PPend status
      per observed ERO Explicit Route Object (ERO) hops (ingress, (ingress and egress
      views only).

   o  Cumulative PPend events per observed ERO hops. hop.

9.  IANA Considerations

   IANA will not need to create a new registry.

9.1.  New Session Attribute Object Flag

   A new flag of the Session Attribute object is defined (to be
   confirmed Object has been registered by IANA)
   IANA.

   Soft Preemption Desired bit

   Bit Flag       Name Flag                           Reference
     0x40    Soft Preemption Desired             This document

9.2.  New error sub-code value

   [I-D.ietf-mpls-gmpls-lsp-reroute] Error Sub-Code Value

   [RFC5710] defines a new reroute-specific error code that allows a mid-point
   midpoint to report a TE LSP reroute request.  This document specifies
   a new error sub-code value for the case of Soft Preemption (to be confirmed by IANA upon publication of
   this document). Preemption.

   Error-value               Meaning                    Reference
     1            Reroute Request Soft Preemption     This document

10.  Security Considerations

   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RFC3209]
   remain relevant.  Further details about MPLS security considerations
   can be found in [SEC_FMWK].

   As noted in Section 6.1, soft preemption may result in temporary link
   under provisioning condition while the soft preempted TE LSPs are
   rerouted by their respective head-end LSRs.  Although this is a less
   serious condition than false hard preemption, and despite the
   mitigation procedures described in Section 6.1, network operators
   should be aware of the risk to their network in the case that the
   soft preemption processes are subverted, and should apply the
   relevant MPLS control plane security techniques to protect against
   attacks.

11.  Acknowledgements

   The authors would like to thank Carol Iturralde, Dave Cooper, Loa
   Andersson, Arthi Ayyangar, Ina Minei, George Swallow, Adrian Farrel Farrel,
   and Mustapha Aissaoui for their valuable comments.

12.  Authors' Addresses

   The content of this document was contributed by the editors and the
   co-authors listed below:  Contributors

   Denver Maddux
   Limelight Networks
   USA
     email:
   EMail: denver@nitrous.net

   Curtis Villamizar
   AVICI
     curtis@faster-light.net
   EMail:curtis@faster-light.net

   Amir Birjandi
   Juniper Networks
   2251 corporate park dr ste
     herndon, Corporate Park Dr., Ste. 100
   Herndon, VA 20171
   USA
   EMail: abirjandi@juniper.net

13.  References

13.1.  Normative References

   [I-D.ietf-mpls-3209-patherr]
              Vasseur, J., Swallow, G., and I. Minei, "Node behavior
              upon originating and receiving Resource ReserVation
              Protocol  (RSVP) Path Error message",
              draft-ietf-mpls-3209-patherr-04 (work in progress),
              February 2009.

   [I-D.ietf-mpls-gmpls-lsp-reroute]
              Berger, L., Papadimitriou, D., and J. Vasseur, "PathErr
              Message Triggered MPLS and GMPLS LSP Reroute",
              draft-ietf-mpls-gmpls-lsp-reroute-04 (work in progress),
              January 2009.

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

   [RFC3031]   Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
               Label Switching Architecture", RFC 3031, January 2001.

   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.

   [RFC5710]   Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr
               Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710,
               January 2010.

   [RFC5711]   Vasseur, JP., Swallow, G., and I. Minei, "Node Behavior
               upon Originating and Receiving Resource Reservation
               Protocol (RSVP) Path Error Messages", RFC 5711, January
               2010.

13.2.  Informative References

   [RFC2961]   Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
               and S. Molendini, "RSVP Refresh Overhead Reduction
               Extensions", RFC 2961, April 2001.

   [RFC3270]   Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
               P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
               Protocol Label Switching (MPLS) Support of Differentiated
               Services", RFC 3270, May 2002.

   [RFC4829]   de Oliveira, J., Vasseur, JP., Chen, L., and C. Scoglio,
               "Label Switched Path (LSP) Preemption Policies for MPLS
               Traffic Engineering", RFC 4829, April 2007.

   [SEC_FMWK]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
               Networks", Work in Progress, October 2009.

Authors' Addresses

   Matthew R. Meyer (editor)
   British Telecom

   EMail: matthew.meyer@bt.com

   Email:

   JP Vasseur (editor)
   Cisco Systems, Inc Inc.
   11, Rue Camille Desmoulins
   Issy Les Moulineaux,   92782
   France

   Email:

   EMail: jpv@cisco.com