One document matched: draft-geib-spring-te-discussion-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category='info' docName='draft-geib-spring-te-discussion-00.txt' ipr='trust200902'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="SR TE approaches">Requirements and approaches to combine Traffic Engineering and Segment Routing</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ruediger Geib" initials="R." role="editor"
surname="Geib">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Heinrich Hertz Str. 3-7</street>
<!-- Reorder these if your country does things differently -->
<code>64295</code>
<city>Darmstadt</city>
<region></region>
<country>Germany</country>
</postal>
<phone>+49 6151 5812747</phone>
<email>Ruediger.Geib@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Martin Horneffer" initials="M."
surname="Horneffer">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Dahlweg 100</street>
<!-- Reorder these if your country does things differently -->
<code>48153</code>
<city>Muenster</city>
<region></region>
<country>Germany</country>
</postal>
<phone>+49 251 788773788</phone>
<email>Martin.Horneffer@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stefan Schnitter" initials="S."
surname="Schnitter">
<organization>Detecon</organization>
<address>
<postal>
<street>Oberkasseler Str. 2</street>
<!-- Reorder these if your country does things differently -->
<code>53227</code>
<city>Bonn</city>
<region></region>
<country>Germany</country>
</postal>
<phone>+49 221 91612968</phone>
<email>Stefan.Schnitter@detecon.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Martin Franzke" initials="M."
surname="Franzke">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Deutsche-Telekom-Allee 7</street>
<!-- Reorder these if your country does things differently -->
<code>64295</code>
<city>Darmstadt</city>
<region></region>
<country>Germany</country>
</postal>
<phone>+49 6151 5833097</phone>
<email>Martin.Franzke@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>spring</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Segment based Routing, Traffic Engineering, TE, SR, traffic matrix</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>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 <xref target="tr_mat">actions </xref>. With the
Introduction of the <xref target="ID.sr-req">segment routing</xref><xref target="ID.sr-arch">, </xref>, these mechanisms should continue to work.
The present document describes requirements and solution options of
some approaches combining Segment Routing and Traffic Engineering.</t>
<t>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.</t>
<t>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).</t>
<t>The solution pursued should integrate smoothly with routing
(i.e. not require serious configuration effort). Further,
the core MPLS network must remain BGP free.</t>
<t>For the sake of simplicity, we assume a global label space where
a single global label identifies a single Node Segment in the
following.</t>
</section>
<section title="Traffic Engineering requirements">
<section title="Use Cases">
<t>Out of many possible use cases for segment routing the following
three are currently considered most relevant</t>
<t><list style="symbols">
<t>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)</t>
<t>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.</t>
<t>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).</t>
</list></t>
</section>
<section title="Traffic Matrix Requirements">
<t>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):</t>
<t><list style="symbols">
<t>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 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.</t>
<t>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.</t>
</list></t>
</section>
<section title="LDP based Traffic Matrix Measurement">
<t>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:</t>
<t><list style="symbols">
<t>Number of bytes transferred per (X-to-Y) label swap operation per outgoing
interface and tracing of traffic path to sink.</t>
<t>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.</t>
<t>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.</t>
<t>Measurement of ECMP split level based on label swap statistic per multiple
outgoing interfaces.</t>
</list></t>
</section>
</section>
<section title="Solution approaches">
<section title="Approach 1: Double Label operation">
<t>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.</t>
<t>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:</t>
<figure anchor="figure_1">
<preamble></preamble>
<artwork>
+------+
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| | |
+---+---+----+---+ +---+---+----+---+
</artwork>
<postamble>Double label operation</postamble>
</figure>
<t>Consider a typical LSR such as R101 in figure 1:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>Consider an LSR at the end of a traffic engineering segment such as R102:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.)</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Approach 2: A Top Label always identifying the destination">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>This approach is optimistically a research topic. It has decent
properties though, thats why considering it might be worthwhile.</t>
</section>
</section>
<section title="Standardized QoS counters">
<t>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 <xref target="RFC1213">Ethernet interfaces</xref>. 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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>A security discussion should be added in a later version.
</t>
</section>
<section title="Acknowledgement">
<t>Fabian Perko provided reviews of this draft.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include='reference.RFC.1213'?>
<!-- the following is the minimum to make xml2rfc happy -->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
<reference anchor="ID.sr-arch">
<front>
<title>Segment Routing Architecture
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2014"/>
</front>
<seriesInfo name="IETF, " value="https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing/"/>
</reference>
<reference anchor="ID.sr-req">
<front>
<title>SPRING Problem Statement and Requirements
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2014"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/"/>
</reference>
<reference anchor="tr_mat">
<front>
<title>Traffic matrices for MPLS networks with LDP traffic statistics</title>
<author initials="S." surname="Schnitter">
<organization>Detecon</organization>
</author>
<author initials="M." surname="Horneffer">
<organization>Deutsche Telekom</organization>
</author>
<date year="2004" />
</front>
</reference>
</references>
<!-- Change Log
v00 2014-10-13 RG draft to be published
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 01:35:10 |