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.

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

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.

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

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):

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:

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

	
		  
+----------------+    +----------------+
|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:

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

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

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.

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.

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

Martin Franzke Deutsche Telekom Deutsche-Telekom-Allee 7 Darmstadt, 64295 Germany Phone: +49 6151 5833097 EMail: Martin.Franzke@telekom.de