I2RS Traffic Steering Use Case
draft-chen-i2rs-ts-use-case-00

Abstract

I2RS intends to be a standard, programmatic interface to the routing system that guides traffic in the network. A well designed Traffic Steering (TS) solution can fully use the network bandwidth, reduce the network congestion and satisfy the performance (e.g., delay, loss) requirement of applications. Most of the existing TS solutions need human intervention and are lack of dynamic feedback and self-adjust ability. This document describes use cases that leverage the I2RS interface to perform traffic steering dynamically and automatically.

Requirements Language

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 RFC 2119 [RFC2119].

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 August 17, 2014.

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 (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. Domain Exit Traffic Steering
• 3. End-to-end Traffic Steering
• 3.1. MPLS-TE
• 3.2. Segment Routing
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

Interface to Routing System (I2RS) architecture [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 to affect the packet forwarding and other behaviours.

Well designed Traffic Steering (RS) 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) [RFC3209] are useful tools for traffic steering deployed in the field. Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] is another tool that is being defined SPRING WG, it leverages the source routing paradigm for packet forwarding and reduces the per-flow state on the transit nodes, hence to provide a scalable traffic engineering solution.

Most of the existing TS solutions need human intervention and lack of dynamic feedback and self-adjust ability. This document describes use cases that leverage the I2RS interface to perform traffic steering dynamically and automatically.

2. Domain Exit Traffic Steering

Domain exit traffic steering is normally achieved by deploying policies at the domain exit gateway and policy routing is often used in practice. A typical scenario is the Data Center(DC) and Metro network exit traffic steering. At the DC or Metro gateways, by enforcing relevant policies, traffic can be steered through specific links, redirecting the traffic to other DC/Metro gateways and performing load balancing among the exit links.

            +---+   +---+   +---+
            | A |   | B |   | C |     Core Network
            +/--+   +-/-+   +-\-+
            / \      /\      / \
  ........./...\..../..\..../...\..................
          /   +-\-+/    \+-/-+   \
              | 1 |------| 2 |        DC Network
              +-|-+      +-|-+
                |          |
       Figure 1: DC Exit Traffic Steering

Figure 1 shows a typical DC exit network design. Router 1 and Router 2 are the DC gateways, Router A, B and C are the Access gateways of the Core network. Normally, the DC gateways will be multi-homed, connected to several access gateways. It is desired to spread the DC exit traffic over links equably if each link has the same capacity, or to spread the traffic in proportion according to the capacity of each link. This requires that router 1 and router 2 know the load of each link could dynamically adjust the traffic placement policies accordingly. Normally, each DC gateway only knows the traffic load of its own links, and the policies at the DC gateways will not be changed unless the operators reconfigure them.

I2RS introduces the concept of a feedback loop, the I2RS client can learn the dynamic state of routing system and then generate and install new RIB items or policies to the routing system. This feedback loop can perfectly matches the above DC/Metro exit traffic steering model. By collecting the exit links and load of each link, an I2RS client can dynamically adjust the policies to smooth spread the traffic as desired. Achieving this requires I2RS to have the ability to:

• collect the topology (especially the exit links) and the traffic load of each link;
• read the local rib of each DC/Metro gateway and the policies deployed on each gateway;
• add or delete or modify the relevant rib items and polices hence to steer the traffic as expected.

3. End-to-end Traffic Steering

3.1. MPLS-TE

MPLS-TE is one solution that can support end-to-end traffic steering. It is achieved by establishing an end-to-end Label Switched Path (LSP) before placing the traffic onto the LSP. When adjusting the traffic placement, it can move some traffic from one LSP to another LSP; or it establishes a new LSP and steers some traffic onto the new LSP.

The LSP computation and optimization can be performed by Path Computation Element (PCE) [RFC4655] which is responsible for path computation. The Path Computation Element Communication Protocol (PCEP) [RFC5440] is 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 [I-D.ietf-pce-stateful-pce] and then establish the path.

PCE and I2RS architectures contain similar functionalities. In the end-to-end traffic steering scenario, these similar architectures provide necessary complementary functions. Since the PCE is mainly for path computation, traffic placement and steering is out of the scope of PCE, and I2RS can be used in these aspects.

In order to support traffic placement and steering, the I2RS (I2RS client-agent exchange) is required to support:

• The ability to collect the LSP information either from the PCE or directly from network devices;
• 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;
• The ability to read the rib information and relevant policies of each network node;
• The ability to add/delete/modify rib items and relevant policies hence to adjust traffic placement and steer as desired.

3.2. Segment Routing

Segment Routing (SR) is another way to support end-to-end traffic steering. The essential portion of Segment Routing is source routing. By directly encoding the path and forwarding instruction information into the packet header, it can steer packets through an explicit route without per-flow states maintained in the transit nodes. This provides a scalable way to perform Traffic Engineering (TE).

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 [I-D.psenak-ospf-segment-routing-extensions] [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.

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.

To support segment routing, the I2RS (client-agent exchange) is required to support the following abilities:

• collect the topology and segment information needed to help the I2RS client to compute the end-to-end path;
• collect the network traffic matrix needed to help the I2RS client to compute the optimized path;
• read rib (especially the segment routing rib) information;
• add/delete/modify the segment rib, this finally determines how the traffic is forwarded.

4. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

5. Security Considerations

This document does not introduce new security issues.

6. Acknowledgements

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses