One document matched: draft-chen-i2rs-ts-use-case-00.txt

Network Working Group                                            M. Chen
Internet-Draft                              Huawei Technologies Co., Ltd
Intended status: Informational                                  S. Hares
Expires: August 18, 2014                         Hickory Hill Consulting
                                                       February 14, 2014


                     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 18, 2014.







Chen & Hares             Expires August 18, 2014                [Page 1]

Internet-Draft              I2RS TS Use Case               February 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
   2.  Domain Exit Traffic Steering  . . . . . . . . . . . . . . . .   3
   3.  End-to-end Traffic Steering . . . . . . . . . . . . . . . . .   4
     3.1.  MPLS-TE . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Segment Routing . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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.



Chen & Hares             Expires August 18, 2014                [Page 2]

Internet-Draft              I2RS TS Use Case               February 2014


   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:





Chen & Hares             Expires August 18, 2014                [Page 3]

Internet-Draft              I2RS TS Use Case               February 2014


   o  collect the topology (especially the exit links) and the traffic
      load of each link;

   o  read the local rib of each DC/Metro gateway and the policies
      deployed on each gateway;

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

   o  The ability to collect the LSP information either from the PCE or
      directly from network devices;

   o  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;

   o  The ability to read the rib information and relevant policies of
      each network node;




Chen & Hares             Expires August 18, 2014                [Page 4]

Internet-Draft              I2RS TS Use Case               February 2014


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

   o  collect the topology and segment information needed to help the
      I2RS client to compute the end-to-end path;

   o  collect the network traffic matrix needed to help the I2RS client
      to compute the optimized path;

   o  read rib (especially the segment routing rib) information;

   o  add/delete/modify the segment rib, this finally determines how the
      traffic is forwarded.







Chen & Hares             Expires August 18, 2014                [Page 5]

Internet-Draft              I2RS TS Use Case               February 2014


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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [I-D.filsfils-rtgwg-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
              "Segment Routing Architecture", draft-filsfils-rtgwg-
              segment-routing-01 (work in progress), October 2013.

   [I-D.ietf-i2rs-architecture]
              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-01 (work in
              progress), February 2014.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-07 (work in progress), October 2013.

   [I-D.previdi-isis-segment-routing-extensions]
              Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and
              S. Litkowski, "IS-IS Extensions for Segment Routing",
              draft-previdi-isis-segment-routing-extensions-04 (work in
              progress), October 2013.






Chen & Hares             Expires August 18, 2014                [Page 6]

Internet-Draft              I2RS TS Use Case               February 2014


   [I-D.psenak-ospf-segment-routing-extensions]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., and W. Henderickx, "OSPF Extensions for
              Segment Routing", draft-psenak-ospf-segment-routing-
              extensions-03 (work in progress), October 2013.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440, March
              2009.

Authors' Addresses

   Mach(Guoyi) Chen
   Huawei Technologies Co., Ltd
   Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
   Beijing  100095
   China

   Email: mach.chen@huawei.com


   Susan Hares
   Hickory Hill Consulting
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com
















Chen & Hares             Expires August 18, 2014                [Page 7]