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]