spring R. Geib, Ed. Internet-Draft M. Horneffer Intended status: Informational Deutsche Telekom Expires: April 20, 2015 S. Schnitter Detecon M. Franzke Deutsche Telekom October 17, 2014 Requirements and approaches to combine Traffic Engineering and Segment Routing draft-geib-spring-te-discussion-00.txt Abstract MPLS Traffic engineering heavily relies on the correct simulation of traffic under normal and failure conditions. Currently traffic simulations rely on RSVP TE or on SPF routing with ECMP. SR introduces basically a new overlay on top of the L3 topology, the SR topology. The SR-topology is demand dependant. This document discusses issues, requirements and some solution approaches to combine Segment Routing and Traffic Engineering. 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 April 20, 2015. Copyright Notice Copyright (c) 2014 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 Geib, et al. Expires April 20, 2015 [Page 1] Internet-Draft SR TE approaches October 2014 (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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Traffic Engineering requirements . . . . . . . . . . . . . . 3 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Traffic Matrix Requirements . . . . . . . . . . . . . . . 3 2.3. LDP based Traffic Matrix Measurement . . . . . . . . . . 4 3. Solution approaches . . . . . . . . . . . . . . . . . . . . . 4 3.1. Approach 1: Double Label operation . . . . . . . . . . . 4 3.2. Approach 2: A Top Label always identifying the destination . . . . . . . . . . . . . . . . . . . . . . . 7 4. Standardized QoS counters . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Traffic engineering heavily relies on the correct simulation of traffic under normal and failure conditions. Correct simulation means that the simulated network utilization of the traffic matrix is the same as the measured load. Currently traffic simulations rely on RSVP TE or on SPF routing with ECMP. SR introduces basically a new overlay on top of the L3 topology, the SR topology. The SR-topology is demand dependant. Edges of the SR-topology are not used for all demands. As basic input for traffic engineering use cases operators need to measure end-to-end traffic matrices and it is common that they use MPLS based traffic statistics for this, e.g. LDP statistics of the label swap actions [tr_mat]. With the Introduction of the segment routing [ID.sr-req], [ID.sr-arch], these mechanisms should continue to work. The present document describes requirements and solution options of some approaches combining Segment Routing and Traffic Engineering. Geib, et al. Expires April 20, 2015 [Page 2] Internet-Draft SR TE approaches October 2014 To start a discussion how to combine Segment Routing and Traffic Engineering in MPLS networks, this document is focused on the simplest case of a two label Segment stack. In general two different Label values are assumed for the typical SR based traffic engineering scenario: One label identifies the end-to- end traffic matrix or destination and one label identifies the intermediate traffic engineering segment or a path deviating from SPF routing (or ECMP path selection). The solution pursued should integrate smoothly with routing (i.e. not require serious configuration effort). Further, the core MPLS network must remain BGP free. For the sake of simplicity, we assume a global label space where a single global label identifies a single Node Segment in the following. 2. Traffic Engineering requirements 2.1. Use Cases Out of many possible use cases for segment routing the following three are currently considered most relevant o A and B plane selection: Use anycast segments on ingress A or B-plane routers that can be used for traffic that requires strict A or B plane routing (like Sigtran traffic) o Link group selection: Use anycast segments on routers defining a certain set of links that shall be used for certain part of the traffic, e.g. to force voice/delay sensitive traffic via a geographically shorter route from Europe to Asia. o Intermediate node selection: Enforce the use of a particular route for traffic for traffic engineering reasons that cannot be modeled with IGP based traffic engineering (in normal or failure case, potentially only on demand in specific failure situations). 2.2. Traffic Matrix Requirements With segment routing the need for IP traffic matrices becomes more complex. With SR, two type of IP traffic matrices are needed in order to carry out the traffic engineering tasks that operators have introduced (without SR they are the same): o End-to-End traffic matrix: Traffic matrix of end-to-end demands in the IP-MPLS network. The end-to-end traffic matrix contains the Geib, et al. Expires April 20, 2015 [Page 3] Internet-Draft SR TE approaches October 2014 traffic levels (e.g. 5 min or 15 min average traffic level) between the entry and final exit routers. End-to-end traffic matrices are needed for network planning and global traffic engineering optimizations. o Segment traffic matrix: Traffic matrix of segmented demands using the configured segments. The segment traffic matrix is needed for correct traffic simulations (normal and failure cases) based on the IP topology and configured segments as well as for incremental traffic engineering optimizations. 2.3. LDP based Traffic Matrix Measurement LDP statistics in current router implementations provide a useful tool for both path and traffic discovery in MPLS networks today. The following mechanisms of LDP statistics are used in operator networks today: o Number of bytes transferred per (X-to-Y) label swap operation per outgoing interface and tracing of traffic path to sink. o Detection of the sink (end of path) within the topology under consideration if the outgoing interface points to a router not included in the topology. o Detection of source traffic (in contrast to transit traffic) through algorithmic operation: Add traffic to the entry (N,S) of the traffic matrix. (if N is the current router under consideration and S the identified sink of the traffic in this forwarding equivalence class (FEC) ) and subtract the traffic from the entry (N+1,S), if N+1 is the next router on the path towards S. o Measurement of ECMP split level based on label swap statistic per multiple outgoing interfaces. 3. Solution approaches 3.1. Approach 1: Double Label operation As we have discussed we need two different values for the typical traffic engineering scenario: One for the end-to-end traffic matrix and one for the intermediate traffic engineering segment. In this proposed solution we suggest to achieve this by replacing the typical swap MPLS operations by a double-pop-double-push operation, which could also be considered a pop-swap-push operation. Also the pop operation normally executed at the end of the traffic engineering Geib, et al. Expires April 20, 2015 [Page 4] Internet-Draft SR TE approaches October 2014 segment would be replaced by a pop-swap operation. An example operation is illustrated by figure 1, where the following signs and symbols are used: +------+ Router with Id R101: | R101 | +------+ MPLS byte counter: MPLS label stack, +----------------+ different frame |R101 Counter | characters denote | In|Out|Byte| If| different flows: +---+---+----+---+ ##### %%%%% |105|pop|4321|3/1| #103# %103% +---+---+----+---+ #106# %105% |106|106|1234|3/1| # IP# % IP% +---+---+----+---+ ##### %%%%% +----------------+ +----------------+ +----------------+ |R107 Counter | |R103 Counter | |R105 Counter | | In|Out|Byte| If| | In|Out|Byte| If| | In|Out|Byte| If| +---+---+----+---+ +---+---+----+---+ +---+---+----+---+ |103|103| 0|7/1| |105|pop|4321|3/1| |106|pop|4321|5/1| |105|105| | | +---+---+----+---+ +---+---+----+---+ +---+---+----+---+ |106|106|1234|3/1| | | | | | |103|103|1234|7/1| +---+---+----+---+ +---+---+----+---+ |106|106| | | +---+---+----+---+ ##### #103# %%%%% #106# ##### %105% ##### # IP# #106# % IP% #106# ##### # IP# %%%%% # IP# %%%%% +------+ ##### +------+ ##### % IP% ##### | R107 |__ __| R103 |__ %%%%% # IP# +------+ \__ 7/1 2/1__/ +------+ \__3/1 ##### \__+------+__/ \__+------+ 5/1 +------+ __| R102 |__ __| R105 |--------| R106 | +------+ __/ +------+ \__ +------+ __/ +------+ +------+ | R101 |__/ 1/1 2/2 \__| R104 |__/ 4/1 +------+ +------+ %%%%% %103% %105% % IP% %%%%% Geib, et al. Expires April 20, 2015 [Page 5] Internet-Draft SR TE approaches October 2014 +----------------+ +----------------+ |R101 Counter | |R102 Counter | | In|Out|Byte| If| | In|Out|Byte| If| +---+---+----+---+ +---+---+----+---+ |103|103|4321|1/1| |103|pop|4321|2/1| |105|105| | | |105|105| | | +---+---+----+---+ +---+---+----+---+ |103|103| 0|1/1| |103|pop|1234|2/1| |106|106| | | |106|106| | | +---+---+----+---+ +---+---+----+---+ Double label operation Figure 1 Consider a typical LSR such as R101 in figure 1: o The transport label of 103 would just be swapped against 103. The associated traffic counter would only count traffic of the aggregated traffic engineering segment. o We suggest that instead the lookup of label 103 would lead to the command to do another lookup of the following label. In this case, that could be 105 or 106. In both cases the resulting action would be to push two labels - 105 (or 106 respectively) and 103. An equivalent implementation would be to swap 105 against 105 and push 103 again. An entry to count bytes for this operation shall be contained in the MPLS forwarding table. o A plain label of 105 as top label, i.e. the final destination without an additional traffic engineering segment, does need a separate entry in the MPLS forwarding table, and consequently a separate counter. Consider an LSR at the end of a traffic engineering segment such as R102: o Normally label 103 would just be popped and the remainder of the packet would be forwarded. Only the aggregated traffic of the traffic engineering segment would be counted. o We suggest that instead the lookup of label 103 would lead to the command to do another lookup of the following label. The resulting action for both label 105 and 106 would be to swap this one against the same number just before forwarding the packet. (Or pop the second label and push it again.) Geib, et al. Expires April 20, 2015 [Page 6] Internet-Draft SR TE approaches October 2014 The result would be to have two different counters for all the traffic of segment 103 - one for each final destination. The traffic of traffic engineering segment 103 itself can be derived by adding both counters. This can be generalized to any number of final destination and any number of traffic engineering segments. The number of entries in the MPLS forwarding table and counters would be equivalent to the number of final destinations multiplied by the number of segment routing segments. We strongly recommend to limit the amount of additional paths (or labels respectively) for traffic engineering purposes to one. Otherwise even more labels would have to be inspected and the number of entries in the MPLS forwarding tables would explode. This limitation seems quite reasonable for all scenarios and use-cases we have seen so far. Also we recommend to limit the use of the relevant type of traffic engineering tunnels. It should be the responsibility of the network operator to know about the scalability of their LSR devices with respect to the possible size of the forwarding table, and to limit the configured traffic engineering segments accordingly. It must be possible for the operator to indicate to the routers which segments are eligible as traffic engineering segments that are treated in the way described above. 3.2. Approach 2: A Top Label always identifying the destination This may be a new routing paradigm rather than a Segment Routing TE solution approach. The idea is inspired by ECMP: While the top label identifies the destination of a packet, the specific path the packet takes depends on information below the top label. In todays environments, ECMP is a hash based random method working within Equal Cost SPF routes. The idea is, to generalize this method. The top label identifies the destination. The address information below the top label determines the path deterministically. This could be a particular SPF path, if the route is SPF based. This could be a non SPF path in other cases. Capturing the traffic matrix is simple in this case. If the top label always identifies the destination, the label stack below may be deeper. The second label may be called path selector or key label. A specific value of this second label may indicate that the packet should execute a specific SPF path or a non SPF path. If the key label is missing, standard SPF routing including ECMP should be executed. ECMP may be applicable within a route set deviating from standard SPF, if the key label is present. Geib, et al. Expires April 20, 2015 [Page 7] Internet-Draft SR TE approaches October 2014 This approach is optimistically a research topic. It has decent properties though, thats why considering it might be worthwhile. 4. Standardized QoS counters QoS aware MPLS traffic engineering requires to capture QoS differentiating traffic matrices. This draft does not suggest a specific granularity above the basic one of a single load counter per MPLS Ordered Aggregate on a physical interface. So far, only the MIB II interface counter captures a largely standardized packet size on Ethernet interfaces [RFC1213]. In analogy, the total number of octets received on the interface which are classified for a particular QoS class, including framing characters, should be captured. The interpretation of framing characters should be non ambiguous (it should e.g. be clear whether CRC bytes are part of the Layer 2 frame or not). To support QoS aware traffic engineering (and other purposes like billing at IP interfaces, configuration of policers and schedulers), the packet length captured by a QoS aware counter per MPLS Ordered Aggregate must be standardized. Counters with proprietary QoS packet length definitions may be dealt with if the captured packet size is known and the number of packets per QoS class is captured in parallel. This requires additional counters and additional operational overhead however. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations A security discussion should be added in a later version. 7. Acknowledgement Fabian Perko provided reviews of this draft. 8. References 8.1. Normative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. Geib, et al. Expires April 20, 2015 [Page 8] Internet-Draft SR TE approaches October 2014 8.2. Informative References [ID.sr-arch] IETF, "Segment Routing Architecture", IETF, https://datatracker.ietf.org/doc/draft-filsfils-spring- segment-routing/, 2014. [ID.sr-req] IETF, "SPRING Problem Statement and Requirements", IETF, http://datatracker.ietf.org/doc/ draft-ietf-spring-problem-statement/, 2014. [tr_mat] Schnitter, S. and M. Horneffer, "Traffic matrices for MPLS networks with LDP traffic statistics", 2004. Authors' Addresses Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de Martin Horneffer Deutsche Telekom Dahlweg 100 Muenster 48153 Germany Phone: +49 251 788773788 Email: Martin.Horneffer@telekom.de Stefan Schnitter Detecon Oberkasseler Str. 2 Bonn 53227 Germany Phone: +49 221 91612968 Email: Stefan.Schnitter@detecon.com Geib, et al. Expires April 20, 2015 [Page 9] Internet-Draft SR TE approaches October 2014 Martin Franzke Deutsche Telekom Deutsche-Telekom-Allee 7 Darmstadt 64295 Germany Phone: +49 6151 5833097 Email: Martin.Franzke@telekom.de Geib, et al. Expires April 20, 2015 [Page 10]