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

Versions: 00

Routing Working Group                                          R. Shakir
Internet-Draft                                                        BT
Intended status: Standards Track                              D. Vernals
Expires: January 16, 2014                                       Vodafone
                                                              A. Capello
                                                          Telecom Italia
                                                           July 15, 2013


    Performance Engineered LSPs using the Segment Routing Data-Plane
          draft-shakir-rtgwg-sr-performance-engineered-lsps-00

Abstract

   A number of applications and services running over IP/MPLS networks
   have strict requirements relating to their routing, or the
   performance of the path supporting their traffic flow, for instance,
   in terms of characteristics such as latency, loss, or bandwidth
   availability.  Segment routing provides a means by which the data-
   plane of an IP/MPLS network can be programmed to support such
   "performance engineered" paths.  This document describes an
   architecture for the use of such performance engineered label
   switched paths, and the control-plane functionality required to allow
   both distributed and centralised computation of acceptable forwarding
   paths.

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 January 16, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Shakir, et al.          Expires January 16, 2014                [Page 1]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   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 provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  6
   3.  Data-plane Path Selection  . . . . . . . . . . . . . . . . . .  7
     3.1.  SID Selection for Non-Revertive Services . . . . . . . . .  7
     3.2.  SID Selection for Revertive Services . . . . . . . . . . .  8
       3.2.1.  Procedure for Link Protection of Adj-SIDs  . . . . . .  8
       3.2.2.  Procedure for Node Protection of Adj-SIDs  . . . . . .  9
       3.2.3.  Example of Revertive Adj-SID Protection  . . . . . . . 10
     3.3.  Path Re-Optimisation and Re-Routing  . . . . . . . . . . . 11
   4.  Distributed Path Computation via Constrained Shortest-Path
       Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Path Selection based on Static IGP Path Attributes . . . . 13
     4.2.  Path Selection based on Performance-Related IGP Path
           Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.2.1.  Requirements for IGP Attributes Pertaining to
               Adjacency Performance  . . . . . . . . . . . . . . . . 14
   5.  Centralised Path Computation using PCE . . . . . . . . . . . . 16
     5.1.  Use of Path Computation Element to Provide Inter-Area
           SR LSPs  . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  Providing Co-routed or Multi-Layer Aware LSPs using PCE  . 17
       5.2.1.  Co-Routed LSPs . . . . . . . . . . . . . . . . . . . . 17
       5.2.2.  Resource Reservation and Admission Control through
               a Stateful PCE . . . . . . . . . . . . . . . . . . . . 18
       5.2.3.  Multi-Layer Calculation through a Common PCE . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24










Shakir, et al.          Expires January 16, 2014                [Page 2]


Internet-Draft       sr-performance-engineered-lsps            July 2013


1.  Motivation

   For numerous applications running over IP/MPLS networks, there is a
   requirement to provide paths that have guaranteed network
   performance.  These resources guarantees may be in terms of
   sufficient bandwidth being available for a traffic flow, but also can
   be in terms of other characteristics (such as latency, packet delay
   variation, and packet loss).  In addition to such characteristics of
   the underlying network, requirements related to path routing can
   exist to ensure that a path offers characteristics such as affinity
   to particular infrastructure, or disjointness to another service.
   For instance:

   o  Where two services provided by an IP/MPLS network make up part of
      an active/backup or live/live service pair for a transported
      application it is required that the paths are wholly disjoint
      (shared risk, link, and node) to ensure that they do not fail
      simultaneously.

   o  If the service a network provides supports an application that
      requires a particular end-to-end latency budget, then the service
      must be constrained to a path, or paths, meeting this budget and
      the path made unavailable if these characteristics cannot be met.

   o  Where a service provided by the IP/MPLS network makes up part of
      another network's topology (e.g., an ATM PWE3 service provided
      within an IP/MPLS network may form a part of a wider client ATN
      network), then an affinity to particular links within the network
      (such as particular sub-sea cable systems) may be required.  Where
      such a path is not available, it can be preferable to utilise
      protection within the client network rather than re-route the IP/
      MPLS service.

   o  Where services, such as paths for real-time voice and video
      trunking delivered over IP/MPLS services are routed according to
      paths with guaranteed resource availability (such as available
      bandwidth).

   o  Where the service requires that both directions of the network
      path are co-routed, such as where an IP/MPLS network path is used
      to carry IEEE 1588 synchronisation traffic.  In this case, two
      uni-directional LSPs must be routed in a co-ordinated manner,
      which may diverge from the shortest-path within the network.

   These requirements can be generalised into a need to support
   arbitrary constrained paths within an IP/MPLS network - with the
   constraints being both in terms of the path selected in the network
   (and its underlying characteristics) and the treatment of packets



Shakir, et al.          Expires January 16, 2014                [Page 3]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   forwarding onto this path during network events (such as during link
   failures, or re-convergence).

   It is important to note that these routing requirements are
   inherently related to a particular service (e.g., customer service A
   must be disjoint to customer service B, or a customer service must
   only be available if paths with an end-to-end latency of less than
   200 milliseconds are available between node X and node Y) - and apply
   to all traffic (as may be the case within a pair of PWE3 services) or
   a subset of traffic within the service (as may be the case with
   particular treatment of voice traffic within an L3VPN service).  This
   results in the number of such routed paths in the network being
   dependent upon the number of services supported by the network (order
   of tens or hundreds of thousands), rather than to the number of edge
   devices within a network (typically of the order of hundreds, or
   thousands).

   It is possible to utilise Segment Routing (SR) as described in
   [I-D.filsfils-rtgwg-segment-routing] to provide a means to support
   services with constrained path requirements via label-switched paths
   (LSPs) in an IP/MPLS network without requiring devices within the
   core of the network to maintain per-LSP state.  Since in the limits
   described above, this number of LSPs is proportional to the number of
   services on the network utilising a stateless mechanism (such as SR)
   to provide such forwarding paths equates to avoiding per-service
   state on transit devices.  The forwarding paths utilised to support
   such services are referred to as performance engineered LSPs within
   this document.

   For example, considering the topology shown in Figure 1, if the
   ingress label edge router (LER) requires forwarding of traffic on a
   path to the egress LER which does not exceed 40 milliseconds, it must
   ensure that traffic traverses the iLER-A, A-B, and B-eLER links.


                   lbl 1100        lbl 1200     lbl 1700
                  ---(10ms)--- A ---(5ms)--- B --(20ms)---
                 /             |                          \
             [iLER]        (30ms) lbl 1400               [eLER]
                 \             |                          /
                  ---(50ms)--- X ----------(10ms) --------
                     lbl 1500      lbl 1600


                                 Figure 1

   With segment routing, iLER can apply a label stack of {1200,1700} and
   next-hop of A to influence A to forward packets to B, and B to



Shakir, et al.          Expires January 16, 2014                [Page 4]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   forward to eLER, regardless of the shortest path selection due to the
   IGP metrics within the network topology.

















































Shakir, et al.          Expires January 16, 2014                [Page 5]


Internet-Draft       sr-performance-engineered-lsps            July 2013


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














































Shakir, et al.          Expires January 16, 2014                [Page 6]


Internet-Draft       sr-performance-engineered-lsps            July 2013


3.  Data-plane Path Selection

   When considering services that are to be carried via performance
   engineered paths within a network, constraints are introduced
   relating to protection during failures of the explicit path selected
   through the network.  Particularly, where a path is provided with
   particular link affinity, or as part of an active/active service pair
   where both primary and backup LSPs are routed within certain
   performance constraints, it is not desirable to perform dynamic re-
   routing or fast re-route protection for the traffic within the
   service, as a path violating the performance constraints may be
   introduced, where the alternate route made available continues to be
   compliant with the original routing criteria.  In order to allow an
   operator to route services not requiring reversion from the primary
   path, an implementation MUST allow the advertisement of segment
   identifiers which are explicitly excluded from fast re-route, and
   reversion away from the primary path.

   Where services are specified as being suitable for reversion, some
   consideration is required as to the means by which they are re-
   routed.  For instance, where with some IP FRR mechanisms the
   protection path may follow the shortest-path tree from the point of
   local repair (PLR) to the packet destination (effectively making the
   LSP tail-end the merge point - MP), such re-routing behaviour is not
   desirable for all performance engineered paths.  In such cases, it is
   more preferable to provide means by which (during protection events)
   traffic is routed back on to the original LSP path, as soon as
   possible, essentially minimising the divergence away from the path
   calculated to meet service constraints.  An implementation SHOULD
   provide means by which an operator can influence MP selection to
   support such requirements.

3.1.  SID Selection for Non-Revertive Services

   Following the calculation of a route meeting a particular set of
   constraints, the ingress service edge device should select the data
   path through determining the relevant SIDs to be pushed to the
   packet.  During the translation of a route to a set of SIDs the
   ingress device MUST consider the service requirements in order to
   ensure that protection within the network does not result in path
   constraints being violated where this is unacceptable.  Where a
   service is specified to be non-revertive, the iLER MUST utilise only
   segment identifiers which are explicitly identified to be non-
   revertive.  Since protection requirements vary on per-service basis,
   the control of reversion to other paths during failures SHOULD be
   specified on a per-LSP basis on the ingress router.

   It should be noted that where strict path constraints are required,



Shakir, et al.          Expires January 16, 2014                [Page 7]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   this results in the number of SIDs applied to a packet being
   proportion to the number of links traversed through the topology
   (through disallowing use of Node-SIDs), which may have implications
   for certain hardware implementations.

   A network operator MAY create forwarding adjacencies consisting of
   multiple SIDs utilising the Explicit Route Object encoding of the
   Adjacency-SID specified in
   [I-D.previdi-isis-segment-routing-extensions] for IS-IS and
   [I-D.psenak-ospf-segment-routing-extensions] for OSPF, such that the
   total SID-stack to be imposed is minimised.  Where such forwarding
   adjacency LSPs (FA-LSPs), or other paths consisting of multiple
   segments are re-advertised, the path characteristics of the
   underlying links MUST be included, such that other constraints used
   for calculation (such as shared risk link groups) can be considered
   by the calculating iLER.  In order that the routing of non-segment
   routed traffic and devices not supporting SR is not influenced by the
   advertisement of such adjacencies:

   o  It MUST be possible for an operator to specify policies as to
      whether such forwarding-adjacencies are utilised for non-Segment
      Routed traffic within the IP/MPLS network.

   o  The advertisement of FA-LSPs for the use of performance engineered
      LSPs SHOULD NOT negatively impact the scaling and performance of
      devices running vanilla SPF calculations of the network topology
      (in order to avoid introducing additional computational overhead
      to legacy devices within the IGP domain within which such LSPs are
      to be introduced).

3.2.  SID Selection for Revertive Services

3.2.1.  Procedure for Link Protection of Adj-SIDs

   By default, Adj-SID values refer to an particular individual or set
   of physical or logical adjacencies between two devices.  It is
   therefore linked specifically to a specific path between two nodes ,
   and hence (by default) does not have a viable alternate route.  Where
   a revertive Adj-SID is advertised, specified through the 'B' flag of
   the Adj-SID advertisement described in
   [I-D.previdi-isis-segment-routing-extensions] and
   [I-D.psenak-ospf-segment-routing-extensions] the advertising LSR MUST
   calculate a backup path for this adjacency.

   By default an LSR SHOULD calculate a link-protecting tunnel to the
   node to which the adjacency is received on - this can be achieved
   through mechanisms such as Loop-Free Alternates [RFC5286].  During
   failure of a path advertised with a revertive Adj-SID, the LSR



Shakir, et al.          Expires January 16, 2014                [Page 8]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   detecting the adjacency failure should act as the point of local
   repair (PLR) and SHOULD pop the adjacency segment (as per the default
   Adj-SID action).  In order to reach the merge point (MP), it is
   possible for the PLR to utilise either:

   o  A set of SIDs relating to the loop free alternate path to reach
      the MP - in this case, it should be noted that such a set of SIDs
      may relate to multiple node and/or adjacency SIDs, where a Remote
      or Directed LFA is required to reach the MP.

   o  The adjacency segments relating to the calculated path between the
      PLR and the MP.  Utilising Adj-SIDs requires the PLR to perform no
      calculation of the path between its neighbours and the MP,
      however, may result in a less survivable service, in cases where
      simultaneous failures result in the backup SR-LSP specified by the
      set of Adj-SIDs becoming unavailable.

   In cases where particular policies should be enforced for the
   protection path for an Adj-SID, an implementation SHOULD utilise a
   set of Adj-SIDs that indicate the links to be traversed between the
   PLR and the MP, based on characteristics of these adjacencies (e.g.,
   the maximum total link bandwidth path).  Where such Adj-SID based
   backup path selection is utilised, the path selected SHOULD be
   influenced by operator policy in a similar manner as the LFA
   selection considered in [I-D.ietf-rtgwg-lfa-manageability].

   It should be noted that since the selection of the protecting set of
   SIDs is calculated on a per-Adj-SID basis, no particular backup path
   selection can be performed by a transit LSR on a per-service basis.
   Therefore, where revertive SIDs are utilised an operator SHOULD
   recognise that during protection events, no path characteristics, or
   resource constraints can be met whilst re-routing results in the
   service diverging from the specified explicit path.

3.2.2.  Procedure for Node Protection of Adj-SIDs

   An LSR MAY provide node-protection for an Adj-SID if such a node-
   protecting path exists within the network topology.

   In the case where such a path is available, the LSR acting as the PLR
   must be capable of programming its forwarding plane based on the
   tuple of the top two labels of the SID stack.  Where this can be
   achieved, a backup action to push the corresponding set of SIDs to
   reach the next-next-hop node (indicated by the advertising entity of
   the second entry in the label stack) during the failure of the
   primary Adj-SID.  The PLR must therefore program an action to pop the
   first two labels of the ingress packet, and subsequently push the
   SIDs relating to this path.



Shakir, et al.          Expires January 16, 2014                [Page 9]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   Again, it is possible for a node to utilise either a set of Node or
   Adjacency SIDs to reach the next-next-hop node (MP).  Where Node-SIDs
   are utilised, means to determine a loop-free path MUST be used to
   determine the set of Node-SIDs required.  Where Adj-SIDs are utilised
   for such functionality, no such calculation is required.  Where
   certain policies are to be enforced for the protecting path, an
   implementation SHOULD allow the use of Adj-SIDs to determine the path
   utilised, and the selection of these SIDs SHOULD be influenced by
   operator policy.

3.2.3.  Example of Revertive Adj-SID Protection


                                    10000
                             --(80)- [E] ---100----------
                            /           \__90___          \
                           /                    \          \
        X --- [A] --10-- [B] -------- 20 -------- [C] -30- [D] --- Y
             9000       9001                      9003     9004

                                 Figure 2

   In Figure 2 a source X sends traffic utilising Adj-SIDs to a
   destination Y utilising through pushing the relevant Adj-SIDs to
   traverse A-B, B-C, C-D.  A therefore receives a packet with
   {10,20,30} segments applied.  B's FIB is programmed with a pop()
   operation for Adj-SID 20, along with a next-hop of the B-C link.

   To provide a link-protecting backup, if E has been calculated as a
   link-protecting LFA for segment 20, then B programs a backup action
   of push(9003) for the ingress label of 20, with an egress interface
   of the B-E link.  When E receives this labelled packet, it swaps
   label 9003 for label 9003 (as per standard behaviour for a Node-SID)
   , and forwards directly to C, who receives the packet with the label
   30 exposed, and hence acts as the MP.

   Clearly, an alternative is that B programs a backup action to push
   label 90 to this stack (with a next-hop of E) to ensure that the
   adjacency between E-C is utilised, rather than E's IGP shortest-path
   to C.

   To provide node protection for the Adj-SID, then additional
   complexity is introduced.  If B receives a packet destined for the
   Adj-SID indicating link B-C, B can examine the following label within
   the stack (in this case, label 30) which is advertised by D within
   the topology.  Since there is a node-protecting LFA via E to D, B may
   therefore pop() the subsequent Adj-SID and push the Node-SID of D
   (9004), whilst forwarding the packet via the B-E link.



Shakir, et al.          Expires January 16, 2014               [Page 10]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   Alternatively, it is possible for B to utilise an explicitly derived
   path to reach D (namely, the Adj-SID of the E-D link, with a next-hop
   of E), to reach the MP.  In this case, no calculation as to the
   routing behaviour of E is required to determine this protection path
   (trading computational complexity for increasing the length of the
   protection SID stack).  Through this behaviour, a packet can be
   forwarded during the complete failure of C. It should be noted that
   this requires two look-ups on the PLR rather than the single look-up
   required in the link protecting case.

3.3.  Path Re-Optimisation and Re-Routing

   Where performance-engineered SR paths are selected by a head-end, the
   calculation of the path is based on the information that is available
   to the computing entity (be it centralised or distributed) at the
   time of calculation.  In order to ensure that such paths are re-
   routed onto more optimal paths where available, an ingress LER MUST
   perform periodic re-optimisation whereby the path selected for a
   service is recalculated.  The period between such re-optimisations
   SHOULD be configurable by a network operator.

   Unlike other network technologies which can be utilised to specify
   explicit paths within an IP/MPLS network, the mid-point network
   elements are unaware of the LSPs that traverse them.  There is
   therefore a requirement for an SR head-end to determine when specific
   segments are no longer valid to be utilised for a service to be
   routed.  In order to ensure that traffic is forwarded onto paths that
   remain valid, a head-end device MUST trigger re-calculation of
   explicit paths within the network when it receives an IGP update
   relating to the segment utilised within a particular service
   topology.  In order to provide means to tolerate short-lived failures
   (particularly where such services are revertive), it SHOULD be
   possible to delay such recalculation on a per-service basis.  Such
   triggered re-optimisation MUST be performed for IGP updates that
   withdraw segments from the topology and MAY be triggered based on
   updates to other attributes within the network.  Where updates are
   triggered on information that may rapidly change within the IGP
   (e.g., information relating to bandwidth reservation or utilisation)
   an iLER device SHOULD provide means to limit the period between re-
   optimisations, or provide thresholds over which re-optimisation is
   triggered.

   In addition to re-optimisation based on failures, an iLER SHOULD
   provide means by which per-service OAM measuring performance or
   liveliness characteristics of a particular path can trigger a path to
   be withdrawn from use, and/or re-optimisation of the SID selection
   for the path.  Such per-service OAM is critical within multi-area
   environments where it cannot be guaranteed that a head-end device



Shakir, et al.          Expires January 16, 2014               [Page 11]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   will have all routing information propagated to it - in such
   deployments, an implementation MUST support per-service OAM.  In all
   environments, per-service OAM can be utilised to ensure that a
   service can be withdrawn more quickly than IGP-updates relating to
   segment failures can be propagated, or a head-end is able to react to
   "grey" failure events, where data-plane traffic forwarding has
   failed, but no IGP update is generated.












































Shakir, et al.          Expires January 16, 2014               [Page 12]


Internet-Draft       sr-performance-engineered-lsps            July 2013


4.  Distributed Path Computation via Constrained Shortest-Path
    Algorithms

4.1.  Path Selection based on Static IGP Path Attributes

   To determine the relevant set of segment identifiers to be utilised
   for a service, existing constrained shortest-path (CSPF) functions
   such as those used for other route selection mechanisms can be
   utilised.  This can provide route selection based on IGP traffic
   engineering metrics (such as those specified for OSPF in RFC3630, or
   IS-IS in RFC5305), or GMPLS IGP extensions such as shared risk link
   groups (SRLGs) carried in attributes such as those that are described
   for OSPF in RFC5307 and IS-IS in RFC4203.  An implementation
   providing distributed CSPF to provide performance-engineered SR paths
   SHOULD support path selection through consideration of such traffic
   engineering IGP attributes.

   Where adjacency segments are created for use as forwarding adjacency
   LSPs, or as a means to provide compression of SID stacks, an
   implementation MUST include the relevant IGP traffic engineering
   attributes indicating the characteristics of the underlying Adj-SIDs
   within IGP attributes relating to such segments.

4.2.  Path Selection based on Performance-Related IGP Path Attributes

   In addition to considering such static attributes of links within the
   IGP topology, distributed path computation can be triggered based on
   performance monitoring information propagated into IGP attributes
   such as those described in [I-D.giacalone-ospf-te-express-path] and
   [I-D.ietf-isis-te-metric-extensions].  Consideration of such
   attributes allows paths to be calculated based on the underlying loss
   and delay characteristics of a network path.  Through monitoring
   updates to these attributes advertised through IGP update messages,
   re-routes based on changes in the performance characteristics of a
   path can be achieved.  An iLER supporting performance engineered LSPs
   utilising the SR dataplane SHOULD allow consideration of these
   attributes when performing ERO calculation, and SHOULD provide means
   to trigger re-routes based on changes in their values.

   In many implementations of MPLS Traffic Engineering, a mechanism
   referred to as "auto-bandwidth" is implemented.  In this case, the
   traffic forwarded via a particular label switched path signalled by
   RSVP-TE is monitored, and the utilisation observed over a set period
   of time utilised as the bandwidth requested when a service is
   periodically re-optimised.  Whilst a SR-based implementation cannot
   provide control-plane resource reservation based on this approach,
   through monitoring these attributes, three forms of bandwidth-aware
   routing can be achieved:



Shakir, et al.          Expires January 16, 2014               [Page 13]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   o  Least-Fill - When selecting an particular path for a service to be
      routed by, where the service has affinity to an individual link
      within an ECMP, a typical means to ensure balancing of traffic
      between the different candidate links is to route the service via
      the link within the ECMP that is least utilised.  During the
      computation of a Segment ERO, an ingress LSR SHOULD provide means
      by which such services can select the least utilised link from an
      set of ECMP candidate links through consideration of the Available
      Bandwidth sub-TLV within such IGP extensions.

   o  Reaction to bandwidth utilisation within the network to re-route
      services based on load of links.  In this case, through monitoring
      a set of particular (potentially high-bandwidth) services against
      the bandwidth utilisation of the links that they follow, it is
      possible to re-optimise the routing of services such that traffic
      is re-routed away from links experiencing congestion in a reactive
      manner.

   o  Reaction to the bandwidth consumed per-service - for instance, in
      cases where traffic is routed via a network with mixed maximum
      link bandwidths (e.g., some paths may have a maximum of 2.5Gbps
      where others have a maximum of 10Gbps) it is advantageous for a
      head-end device to split traffic flows into multiple sub-elements,
      with some diverging from the SPT.  In this case, no knowledge of
      the utilisation of the network is required, however, the maximum
      available bandwidth of adjacencies within the SPT combined with
      explicit routed LSPs can be utilised to achieve traffic balance
      across the network.

   Through utilising the uni-directional residual and available
   bandwidth TLVs described in the aforementioned performance
   attributes, the current utilisation (or available bandwidth remaining
   on a link) can be considered within a path calculation.  An SR
   implementation providing performance engineered LSPs SHOULD provide
   means by which residual or available bandwidth can utilised as a
   means to calculate an ERO, and trigger subsequent re-routing.  Where
   re-routes are triggered based on available bandwidth an iLER MUST
   provide means by which the time between re-optimisations can be
   limited, and SHOULD provide means by which such recalculations can be
   jittered, such that periodic re-optimisation is not performed
   simultaneously for all LSPs on a particular iLER.

4.2.1.  Requirements for IGP Attributes Pertaining to Adjacency
        Performance

   The use of extended IGP attributes to determine underlying path
   characteristics for the selection of performance engineered paths
   requires some considerations to ensure that the routing information



Shakir, et al.          Expires January 16, 2014               [Page 14]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   utilised is sufficient and timely - and to balance this accuracy
   against resource utilisation of the systems within the IGP.

   Where dynamically measured performance statistics are advertised into
   the IGP - such as latency measurement, or bandwidth utilisation -
   there is a requirement to ensure that a head-end performing re-
   routing of an LSP calculates performance in a manner which balances:

   o  Accuracy of the resource consideration at the time of routing -
      ensuring that the current performance of the adjacency meets the
      path selection criteria.  This requirement may lead to frequent
      updates of performance information into the IGP - hence, in order
      to minimise the impact to the overall network system, a receiving
      implementation in such a network SHOULD provide means by which
      such updates do not result in a recalculation of (the complete, or
      a subset of) the network's topology.  In some networks, especially
      those with legacy systems, it is not possible to make such changes
      to all elements within the IGP, and therefore an advertising
      implementation MUST provide means by which the flooding of
      bandwidth information can be limited to cases where particular
      (operator specified) thresholds in performance are exceeded.

   o  Consideration of the medium-term performance of the network link -
      for instance, where residual bandwidth-based path selection is to
      be performed, it is of advantage to consider both the
      instantaneous bandwidth utilisation, along with the measured
      average over a previous time period such that the longer-term
      performance guarantees can be considered during route selection.
      Whilst such criteria does not provide strict admission control for
      services, it provides means by which further accuracy can be added
      to calculations based on instantaneous measures.  To this end, an
      advertising implementation SHOULD provide a moving average
      performance measure when advertising real-time performance
      information within the IGP, where such attributes are not
      available.

   In some cases, it may be advantageous for distributed path selection
   to consider per-forwarding class performance - in these cases an
   advertising implementation MAY provide performance measures on a per-
   configured forwarding class basis for a particular adjacency.











Shakir, et al.          Expires January 16, 2014               [Page 15]


Internet-Draft       sr-performance-engineered-lsps            July 2013


5.  Centralised Path Computation using PCE

   In addition to the utilisation of distributed computation, existing
   PCE mechanisms can be provided to provide centralised path
   computation for performance engineered services.  Such PCE-based
   computation have utility both for providing inter-area or multi-layer
   aware information, alongside providing globally aware service
   functions.

   It is envisaged that the interface between the PCE and head-end LSR
   utilises interfaces which may:

   o  Exploit the Path Computation Element Protocol described in
      RFC5440.

   o  Utilise other real-time protocols providing interaction between
      forwarding elements and centralised routing entities such as those
      described in [I-D.amante-i2rs-topology-use-cases].

   Where an implementation provides support for performance engineered
   LSPs it SHOULD provide means by which a remote path calculation
   entity can be utilised to provide both explicit route object
   consisting of IP addresses that can be translated into SIDs by the
   iLER and SHOULD support receiving a set of SID values directly from
   the PCE.

5.1.  Use of Path Computation Element to Provide Inter-Area SR LSPs

   In a multi-area network deployment, where there is restricted
   information propagated into stub areas, an iLER within the stub area
   does not have full visibility of the Adj-SIDs required to build a
   particular network path.  Such a LER is therefore unable to determine
   (based on distributed computation) which SIDs should be utilised for
   a path to a remote node.  Whilst one solution to providing such
   visibility is to implement a single-area IGP, or propagate all
   topology information to all areas, non-engineering constraints can
   prevent such implementations.  Through utilising a PCE which has
   information relating to the SIDs within the network, any iLER may be
   provided with the relevant SIDs create a particular path through the
   network.

   In such a deployment, the PCE element MUST have a live view of the
   IGP topology for all areas.  This allows knowledge of the SIDs that
   are to be utilised to the head-end.  It is envisaged that such
   information be provided to the PCE through interfaces such as BGP-LS
   as described in [I-D.ietf-idr-ls-distribution], with extensions to
   encode Segment Routing IGP attributes within the information
   propagated.



Shakir, et al.          Expires January 16, 2014               [Page 16]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   Since it is not only during signalling that visibility into the IGP
   topology is required, a PCE supporting such SR LSPs MUST offer
   functionality to inform the ingress LER supporting the SR LSP of a
   change to the underlying path of the LSP.  For non-revertive LSPs, an
   iLER SHOULD offer a mechanism by which a secondary (backup) path can
   be requested for a service, which can be switched to based on local
   failure detection mechanisms (such as in-band OAM) to allow fast
   restoration of a service independent on interaction with the PCE at
   the time of failure.

5.2.  Providing Co-routed or Multi-Layer Aware LSPs using PCE

5.2.1.  Co-Routed LSPs

   For a number of use-cases, there is a requirement for a path (be it a
   complete service, or a subset of traffic within a service) to be
   routed according to the route of another service within the network.
   For example:

   o  Where there is a requirement diversity between a pair of services
      within a network - particularly where there services are
      instantiated on different iLER devices.  In such cases, global
      visibility is required in order to jointly route two the services
      in a manner such that they are diverse (SRLG, link, and node) to
      one another (in addition to meeting any other performance
      constraints required of them).

   o  Where two services form a bi-directional service within an IP/MPLS
      network.  In this case, some services (e.g., those supporting BFD
      for end-to-end monitoring) may have a requirement for a return
      path from the eLER to the iLER which requires similar performance
      characteristics to the path from the iLER to eLER.  Other services
      have tighter coupling requirements, such that the forwarding path
      used from iLER to eLER is symmetrical (i.e., utilises the exact
      same links) to the return path.

   In both cases, there is a requirement for association between a set
   of LSPs, which span multiple head-end LERs.  An implementation
   supporting such co-routing requirements MUST support the use of a
   stateful PCE, such as that described in [I-D.ietf-pce-stateful-pce]
   to provide calculated paths for such services.

   In cases where an LSR initiates an path computation request, it MUST
   be possible to communicate associated paths, and relationship between
   the calculated path and the associated paths (in terms of co-routing
   or disjointness) to the PCE device.  Both PCE and LSRs SHOULD provide
   means by which the associated paths can be specified in terms of an
   arbitrary service identifier (e.g., the service provider's "circuit



Shakir, et al.          Expires January 16, 2014               [Page 17]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   identifier").

   Since associated LSPs may also have performance requirements, it MUST
   be possible for an LSR to communicate performance constraints along
   with associations.  Where a bi-directional service is specified, path
   computation SHOULD support the communication of common, or differing,
   performance requirements for each LSP within the path.

   Such PCE functions MUST provide means by which the protection
   requirements for a particular service can be specified - both in
   terms of the expected reversion behaviour for the instantiated SR-
   LSPs and requirements for any supporting paths (e.g., path
   protection).

5.2.2.  Resource Reservation and Admission Control through a Stateful
        PCE

   Implementing explicit path routing via the segment routing data-
   plane, rather than alternatives such as RSVP-TE, results in the
   inability of transit LSR devices to provide admission control (since
   it is unaware of the existing flows and their resource reservations).
   For some premium applications - such as carrying broadcast traffic -
   the reservation of bandwidth (and its guarantee via the relevant
   data-plane queueing configuration) continues to be a requirement.

   A stateful PCE can be utilised to perform admission control into one
   or more forwarding classes - allowing reservation to be achieved for
   these services.  Where reservations are required, an iLER MUST
   provide means by which a bandwidth reservation in (one or more)
   classes can be requested of the PCE.  LERs supporting such requests
   MUST provide means by which the resources requested for a particular
   SR-LSP can be statically configured by an operator, and SHOULD
   provide means by which dynamic observation of traffic forwarded via
   an LSP can be used in the subsequent requests (in order to achieve
   PCE-controlled auto-bandwidth functionality).

5.2.3.  Multi-Layer Calculation through a Common PCE

   A further case in which such PCE-based computation can be utilised is
   to provide correlation between layers of network infrastructure.  For
   instance, where a common network model is available to a PCE across
   an optical and IP/MPLS network infrastructure, SRLG diverse paths can
   be provided without the requirement to encode this information (or
   communicate it) between the layers of the network.  Through utilising
   a PCE able to support such multi-layer optimisations SRLG-disjoint
   paths can be computed and provided to iLERs for use as performance
   engineered paths.




Shakir, et al.          Expires January 16, 2014               [Page 18]


Internet-Draft       sr-performance-engineered-lsps            July 2013


   Implementations providing PCE-based calculation with multi-layer
   awareness SHOULD provide means by which an arbitrary SRLG identifier
   can be provided to the PCE to allow path calculation.
















































Shakir, et al.          Expires January 16, 2014               [Page 19]


Internet-Draft       sr-performance-engineered-lsps            July 2013


6.  Security Considerations

   TBC
















































Shakir, et al.          Expires January 16, 2014               [Page 20]


Internet-Draft       sr-performance-engineered-lsps            July 2013


7.  Acknowledgements

   The authors would like to thank Clarence Filsfils, Pierre Francois,
   Hannes Gredler, and Siva Sivabalan for their feedback and suggestions
   pertaining to this document.














































Shakir, et al.          Expires January 16, 2014               [Page 21]


Internet-Draft       sr-performance-engineered-lsps            July 2013


8.  Normative References

   [I-D.amante-i2rs-topology-use-cases]
              Amante, S., Medved, J., Previdi, S., and T. Nadeau,
              "Topology API Use Cases",
              draft-amante-i2rs-topology-use-cases-00 (work in
              progress), February 2013.

   [I-D.filsfils-rtgwg-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
              "Segment Routing Architecture",
              draft-filsfils-rtgwg-segment-routing-00 (work in
              progress), June 2013.

   [I-D.giacalone-ospf-te-express-path]
              Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Express Path",
              draft-giacalone-ospf-te-express-path-02 (work in
              progress), September 2011.

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
              Ray, "North-Bound Distribution of Link-State and TE
              Information using BGP", draft-ietf-idr-ls-distribution-03
              (work in progress), May 2013.

   [I-D.ietf-isis-te-metric-extensions]
              Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
              A., and C. Filsfils, "IS-IS Traffic Engineering (TE)
              Metric Extensions",
              draft-ietf-isis-te-metric-extensions-00 (work in
              progress), June 2013.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE",
              draft-ietf-pce-stateful-pce-05 (work in progress),
              July 2013.

   [I-D.ietf-rtgwg-lfa-manageability]
              Litkowski, S., Decraene, B., Filsfils, C., and K. Raza,
              "Operational management of Loop Free Alternates",
              draft-ietf-rtgwg-lfa-manageability-00 (work in progress),
              May 2013.

   [I-D.previdi-isis-segment-routing-extensions]



Shakir, et al.          Expires January 16, 2014               [Page 22]


Internet-Draft       sr-performance-engineered-lsps            July 2013


              Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and
              S. Litkowski, "IS-IS Extensions for Segment Routing",
              draft-previdi-isis-segment-routing-extensions-02 (work in
              progress), July 2013.

   [I-D.psenak-ospf-segment-routing-extensions]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H., and R.
              Shakir, "OSPF Extensions for Segment Routing",
              draft-psenak-ospf-segment-routing-extensions-02 (work in
              progress), July 2013.

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

   [RFC5286]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
              Reroute: Loop-Free Alternates", RFC 5286, September 2008.



































Shakir, et al.          Expires January 16, 2014               [Page 23]


Internet-Draft       sr-performance-engineered-lsps            July 2013


Authors' Addresses

   Rob Shakir
   BT
   pp. C3L, BT Centre
   81, Newgate Street
   London  EC1A 7AJ
   UK

   Email: rob.shakir@bt.com
   URI:   http://www.bt.com/


   Danny Vernals
   Vodafone
   Melbourne Street
   Leeds  LS2 7PS
   UK

   Email: danny.vernals@vodafone.com
   URI:   http://www.vodafone.com/


   Alessandro Capello
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148
   Italy

   Email: alessandro.capello@telecomitalia.it
   URI:   http://www.telecomitalia.com/




















Shakir, et al.          Expires January 16, 2014               [Page 24]


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