One document matched: draft-chen-i2rs-ts-use-case-00.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.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-00" 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>Hickory Hill Consulting</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  month="February" year="2014"/>

    <abstract>
      <t>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.</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 to affect the packet forwarding and
      other behaviours.</t>

      <t>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) <xref target="RFC3209"/> are
      useful tools for traffic steering deployed in the field. Segment Routing
      (SR) <xref target="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.
      </t>

      <t>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.</t>
    </section>

    <section title="Domain Exit Traffic Steering">
      <t>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. </t>

      <t><figure>
          <artwork><![CDATA[            +---+   +---+   +---+
            | A |   | B |   | C |     Core Network
            +/--+   +-/-+   +-\-+
            / \      /\      / \
  ........./...\..../..\..../...\..................
          /   +-\-+/    \+-/-+   \
              | 1 |------| 2 |        DC Network
              +-|-+      +-|-+
                |          |
       Figure 1: DC Exit Traffic Steering
]]></artwork>
    </figure></t>
	<t> 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. </t>

      <t>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:</t>

      <t><list style="symbols">
          <t>collect the topology (especially the exit links)
          and the traffic load of each link; </t>

          <t>read the local rib of each DC/Metro gateway and
          the policies deployed on each gateway;</t>

          <t>add or delete or modify the relevant rib items and
          polices hence to steer the traffic as expected. </t>
        </list></t>
    </section>

    <section title="End-to-end Traffic Steering ">
      <section title="MPLS-TE">
        <t>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. </t>

        <t>The LSP computation and optimization can be performed by Path
        Computation Element (PCE) <xref target="RFC4655"/> which 
        is responsible for path computation. The Path Computation Element
		Communication Protocol (PCEP) <xref target="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 <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 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.</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>The ability to collect the LSP information either from the PCE
            or directly from network devices;</t>

            <t>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>The ability to read the rib information and relevant policies
            of each network node;</t>

            <t>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) 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).</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>collect the topology and segment information
            needed to help the I2RS client to compute the end-to-end
            path;</t>

            <t>collect the network traffic matrix needed
            to help the I2RS client to compute the optimized path; </t>

            <t>read rib (especially the segment routing rib)
            information;</t>

            <t>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;
    </references>
  </back>
</rfc>