One document matched: draft-chen-i2rs-ts-use-case-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY I-D.ietf-i2rs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ls-distribution.xml">
<!ENTITY I-D.keyupate-i2rs-bgp-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-keyupate-i2rs-bgp-usecases-01.xml">
<!ENTITY I-D.previdi-isis-segment-routing-extensions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.previdi-isis-segment-routing-extensions.xml">
<!ENTITY I-D.filsfils-rtgwg-segment-routing SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-rtgwg-segment-routing.xml">
<!ENTITY I-D.ietf-pce-stateful-pce SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-stateful-pce.xml">
<!ENTITY I-D.psenak-ospf-segment-routing-extensions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.psenak-ospf-segment-routing-extensions.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-chen-i2rs-ts-use-case-01" ipr="trust200902">
<front>
<title abbrev="I2RS TS Use Case">I2RS Traffic Steering Use Case</title>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian
District</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<date year="2014"/>
<abstract>
<t>Traffic steering (TS) mechanisms are designed to improve the overall utilization of network resources in terms of bandwidth and services, and to optimize traffic flow in terms of latency and jitter through the network. Most existing TS systems require human intervention to monitor and manage the assignment of specific paths to specific flows or traffic types, reducing the effectiveness of TS. I2RS, as a near real time programmatic interface to the routing system, provides the ability to manage TS systems in a more dynamic and iterative way. This document describes several TS use cases for I2RS.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Interface to Routing System (I2RS) architecture <xref
target="I-D.ietf-i2rs-architecture"/> defines a standard, programmatic
interface to routing system. Through the I2RS interface, an entity
external to the routing system can retrieve and program network
states of the routing system, hence affecting packet forwarding behaviours.</t>
<t>Well designed Traffic Steering (TS) can improve the usage of network
bandwidth resource, reduce the network congestion and satisfy the
requirements (e.g., loss and delay) of the applications. Policy Routing
(PR), MPLS Traffic Engineering (MPLS-TE) <xref target="RFC3209"/> are
useful tools for traffic steering deployed in the field. Segment Routing (SR) leverages the source routing paradigm for packet forwarding, reducing the per flow state in transit devices to provide a scalable TR solution <xref target="I-D.filsfils-rtgwg-segment-routing"/>. A BGP specific use case similar to the more general use cases considered here is described in section 3.4 of <xref target="I-D.keyupate-i2rs-bgp-usecases"/>.</t>
<t>Most of the existing TS solutions need human intervention because they
lack dynamic feedback which would facilitate programmatic adjustments to the policies impacting packet flows. This document
describes use cases that leverage the I2RS interface to perform traffic
steering dynamically and automatically.</t>
</section>
<section title="I2RS Requirements from the Traffic Steering Use Cases">
<t> This section contains the list of I2RS requirements found in this draft.
Each of these requirements has been given an an ID number of TS-REQ-nn for ease of reference. </t>
<t>The requirements from the Traffic Steering use cases described in this document are:
<list>
<t>TS-REQ01: The I2RS Client-Agent must be able to collect the topology (especially the exit links)
and the traffic load of each link; </t>
<t>TS-REQ02: The I2RS Client-Agent must be able to read the local rib of each DC/Metro gateway and
the policies deployed on each gateway;</t>
<t>TS-REQ03: The I2RS Client-Agent must be able to add or delete or modify the relevant rib items and
relevant polices to steer the traffic as expected; and adjust traffic placement. </t>
<t>TS-REQ-04: The I2RS Client-Agent must have the ability to collect the LSP information either from the PCE
or directly from network devices;</t>
<t>TS-REQ-05: The I2RS Client-Agent must have the ability to collect the traffic matrix of the network, this
is used to help the I2RS client to determine how to adjust the
traffic placement;</t>
<t>TS-REQ-06: The I2RS Client-Agent must have the ability to read the rib information and relevant policies
of each network node;</t>
<t>TS-REQ-07:collect the topology and segment information
needed to help the I2RS client to compute the end-to-end
path;</t>
<t>TS-REQ-08:read rib (especially the segment routing rib)
information;</t>
<t>TS-REQ-09: add/delete/modify the segment rib, this finally
determines how the traffic is forwarded.</t>
</list> </t>
<t> Note: In each of these sections, the requirements match the technical specificaiton, but
maybe listed of ascending numerical order.</t>
</section>
<section title="Domain Exit Traffic Steering">
<t>Data Center (DC) fabrics and metro area networks often have more than one exit point. By enforcing relevant policies, it is possible to share the outbound traffic load among these exit points, in turn preventing a single link from becoming overloaded, and thus improving the experience of customers using these facilities. The figure below illustrates a typical network design with multiple exits.</t>
<t><figure>
<artwork><![CDATA[
+---+ +---+ +---+
| A | | B | | C | Interconnect
+/--+ +-/-+ +-\-+
/ \ /\ / \
........./...\..../..\..../...\..................
/ +-\-+/ \+-/-+ \
| 1 |------| 2 | Edge
+-|-+ +-|-+
| |
Figure 1: DC Exit Traffic Steering
]]></artwork>
</figure></t>
<t>Router 1 and Router 2 represent the border leaf in a DC scenario, or the provider edge in a metro network. Routers A, B and C represent the fabric interconnect in a data center, or the network core in a metro network. Ideally, load would be shared between the outbound link at Router 1 and the outbound link at Router 2; equably if each link has the same capacity, or in proportion to the capacity of each link if they have different capacities. This requires that router 1 and router 2 know the load of each link so Routers A, B, and C, can dynamically steer traffic towards the correct exit point. Normally the load of each of these links is only available to Routers 1 and 2 locally; steering traffic to the correct exit requires manual monitoring and configuration on the part of the network operator.</t>
<t>I2RS introduces the concept of a feedback loop;
the I2RS client can dynamically learn the utilization of the links at
Routers 1 and 2, as well as the state of the routing tables at Routers
A, B, and C, the topology of the network, and other information.
Based on this information, the I2RS client can compute the changes necessary in the
network to evenly balance the load between the two exit points, and
inject the right information into the appropriate RIBs to make the necessary changes.</t>
<t> Achieving this requires the I2RS Client-Agent to have the following abilities:
<list style="symbols">
<t>TS-REQ01: be able to collect the topology (especially the exit links)
and the traffic load of each link; </t>
<t>TS-REQ02: be able to read the local rib of each DC/Metro gateway and
the policies deployed on each gateway;</t>
<t>TS-REQ03: be able add or delete or modify the relevant rib items and
polices to steer the traffic as expected. </t>
</list></t>
</section>
<section title="End-to-end Traffic Steering ">
<section title="MPLS-TE">
<t>In MPLS-TE, traffic is placed into a Label Switched Path (LSP), guding that traffic through a specific set of nodes and edges to traverse the network. Each LSP represents a (potentially) different path through the network, allowing different streams to take a different path to reach the same destination device. In placing LSPs, the network operator effectively steers traffic through the network.</t>
<t>LSP computation and optimization can be performed by Path
Computation Element (PCE) <xref target="RFC4655"/>, which uses the Path Computation Element
Communication Protocol (PCEP) <xref target="RFC5440"/> as a southbound interface.
Since the Path Computation Client (PCC) is embedded in the network devices,
it can actively request path computation or just receive the path
establishment direction from the stateful PCE <xref
target="I-D.ietf-pce-stateful-pce"> </xref> and then establish the
path. </t>
<t>PCE and I2RS architectures contain similar
functionalities. In the end-to-end traffic steering scenario,
these similar architectures provide complementary functions.
Since the PCE is mainly for path computation, traffic
placement and steering are out of the scope of PCE, and I2RS
can be used in these aspects.</t>
<t>In order to support traffic placement and steering, the I2RS
(I2RS client-agent exchange) is required to support:</t>
<t><list style="symbols">
<t>TS-REQ-04: The ability to collect the LSP information either from the PCE
or directly from network devices;</t>
<t>TS-REQ-05: The ability to collect the traffic matrix of the network, this
is used to help the I2RS client to determine how to adjust the
traffic placement;</t>
<t>TS-REQ-06: The ability to read the rib information and relevant policies
of each network node;</t>
<t>TS-REQ-03: The ability to add/delete/modify rib items and relevant
policies hence to adjust traffic placement and steer as desired.
</t>
</list></t>
</section>
<section title="Segment Routing">
<t>Segment Routing (SR) supports end-to-end traffic steering by directly encoding the path and forwarding instruction information
into the packet header, steering packets through an explicit route
without per-flow states maintained in the transit nodes. This
provides a scalable way to perform Traffic Engineering (TE).</t>
<t>In an SR capable network, there are two types of state. One is the
segment information that is supplied to the path computation entity
for path computation. It can be obtained either from the IGP based
Segment advertisement <xref
target="I-D.psenak-ospf-segment-routing-extensions"/> <xref
target="I-D.previdi-isis-segment-routing-extensions"/>, or through the
unified BGP interface [draft-chen-idr-segment-distribution]. The other
is the SR RIB information that is computed and installed by the path
computation entity.</t>
<t>The path computation entity can be either the control plane of the
ingress node of a path or an external controller (e.g., PCE or SDN
controller). Since this is an I2RS use case, this document mainly
talks about the latter (Controller based SR). The controller can be an
I2RS client or an application running on an I2RS client. In either
case, the I2RS interface should have two capabilities. One is to
collect the segment information, the other is able to read and write
the SR RIB state.</t>
<t>To support segment routing, the I2RS (client-agent exchange)
is required to support the following abilities:</t>
<t><list style="symbols">
<t>TS-REQ-07:collect the topology and segment information
needed to help the I2RS client to compute the end-to-end
path;</t>
<t>TS-REQ-05:collect the network traffic matrix needed
to help the I2RS client to compute the optimized path; </t>
<t>TS-REQ-08:read rib (especially the segment routing rib)
information;</t>
<t>TS-REQ-09: add/delete/modify the segment rib, this finally
determines how the traffic is forwarded.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce new security issues.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t/>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC3209;
&RFC4655;
&RFC5440;
&I-D.filsfils-rtgwg-segment-routing;
&I-D.psenak-ospf-segment-routing-extensions;
&I-D.previdi-isis-segment-routing-extensions;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-pce-stateful-pce;
&I-D.keyupate-i2rs-bgp-usecases;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:24 |