Internet DRAFT - draft-geib-spring-te-discussion
draft-geib-spring-te-discussion
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]
