[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            M. Chen
Internet-Draft                                                 S. Zhuang
Intended status: Informational                       Huawei Technologies
Expires: January 12, 2014                                         Y. Zhu
                                                                 S. Wang
                                                   China Telecom Co.,Ltd
                                                           July 11, 2013


          Use Cases of Route Reflection based Traffic Steering
          draft-chen-idr-rr-based-traffic-steering-usecase-00

Abstract

   Route Reflection based Traffic Steering (RRTS) is an idea that
   leverages the BGP route reflection mechanism to realize traffic
   steering in the network, therefore the operators can conduct their
   traffic to transmit/receive through specific nodes, domains and/or
   planes as demand.  This document introduces the requirements and use
   cases of RRTS.

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 January 12, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Chen, et al.            Expires January 12, 2014                [Page 1]


Internet-Draft          RR based Traffic Steering              July 2013


   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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use Cases and Requirements  . . . . . . . . . . . . . . . . .   4
     2.1.  Multihoming Scenario  . . . . . . . . . . . . . . . . . .   4
     2.2.  Multiple Planes Scenario  . . . . . . . . . . . . . . . .   6
     2.3.  Multiple Entries/Exits Scenario . . . . . . . . . . . . .   7
     2.4.  Requirement Summary . . . . . . . . . . . . . . . . . . .   8
   3.  Route Refelection based Traffic Steering  . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Problem Statement

   In an IP network, typically, both the Interior Gateway Protocol (IGP)
   and Border Gateway Protocol (BGP) are simultaneously deployed to
   forward traffic from one domain to other domains.  The IGP is
   responsible for the internal routing and connectivity, the BGP is
   responsible for inter-domain routing.  For the inter-domain traffic,
   it is forwarded based on the BGP routes.  But when the traffic enters
   a specific domain, since the BGP routes depend the IGP routes to
   reach to the BGP nexthop router, the traffic actually follows the IGP
   routes to reach to the Autonomous System Border Routers (ASBRs) and
   then is forwarded to next domain.  So, the IGP topology, link metric
   and related policies determine the traffic path within the domain.
   Setting and adjusting the IGP metrics is the major practice method to
   conduct the traffic.  In order to fully use the network bandwidth,
   reduce the congestion on links and/or nodes, the operators have to
   carefully design and adjust the IGP metrics.  Design IGP metrics for
   a greenfield network is relatively easy.  But for a product network,
   with the increasing of network size, density and traffic volume, it's
   hard or even impossible to adjust the IGP metrics to smoothly conduct
   the traffic as needed.  Setting or changing IGP metric just likes a
   teeterboard, it often happens that changing the metric of one link to



Chen, et al.            Expires January 12, 2014                [Page 2]


Internet-Draft          RR based Traffic Steering              July 2013


   solve one problem, and there will be another problem occurs.  And
   even worse, bad metric design may result in route oscillation.

          ........................................
          .         +-----+        +-----+       . /--\
          .         |  A  |--------|  B  |--------|MAN2|
          .         |     |\       |     |       . \--/
          .         +-----+  \     +-----+       .
          .        /    \      \   /   \         .
          .      /       \       \/     \        .
          . +-----+       \      / \     \       .
    /--\  . |  E  |        \    /    \    \      .
   |MAN1|---|     |\        \  /       \  +-----+.   /--\
    \--/  . +-----+  \    +------+       \|  C  |---|MAN3|
          .            \  |  D   |--------|     |.   \--/
          .              \|      |        +-----+.
          .               +------+               .
          .           IP Core Network            .
          ........................................
               Figure 1: Paradoxical Metric


   Figure 1 shows a paradoxical metric scenario.  Where router A, B, C,
   D and E belong to the IP core network, Router A, B, C and D connect
   each other with full mesh links, and each link have the same metric;
   router E multihoming connects to router A and D. The Metropolitan
   Area Network 1 (MAN1) connects to the IP core network through router
   E, MAN2 connects to the IP core network through router B, and MAN3
   connects to the IP core network through router C.  The requirement
   would like this: the traffic between MAN1 and MAN2 is required to
   follow the path: E-A-B; and the traffic between MAN1 and MAN3 is
   required to follow the path: E-D-C. To satisfy the former
   requirement, it requires that the metric of link E-A must be less
   than the metric of link E-D. But to satisfy the later requirement, it
   will require that the metric of link E-A must be larger than the
   metric of link E-D. It's impossible to satisfy the paradoxical metric
   requirements simultaneously.

   In addition, the existing BGP route decision is mainly based on the
   destination address, it does not consider the source address.  From
   the source node point of view, the selected best route may not be the
   best route for the source node, especially in the network where Route
   Reflection is largely deployed.  There are some proposed mechanisms
   (e.g., add-path[I-D.ietf-idr-add-paths], optimal route reflection
   [I-D.ietf-idr-bgp-optimal-route-reflection] ) that may solve or
   mitigate the issues.  But they also bring some new challenges, they
   will require more memory to save huge extra routes, to keep more
   states and make the implementation more complicated.  The most



Chen, et al.            Expires January 12, 2014                [Page 3]


Internet-Draft          RR based Traffic Steering              July 2013


   important one is that these solutions require to upgrade not just
   only one or two deployed devices, they may require to upgrade the
   whole or most the network devices.  This makes it difficult to be
   deployed in a product network.

   Route Reflection based Traffic Steering (RRTS) is an idea that
   leverages the BGP route reflection mechanism to realize traffic
   steering in the network, therefore the operators can conduct their
   traffic to transmit/receive through specific nodes, domains and/or
   planes as demand.  The essential of RRTS is that the concept of
   traffic engineering is introduced into BGP network.

   This document introduces some use cases and requirements of the RRTS.

2.  Use Cases and Requirements

2.1.  Multihoming Scenario

   Figure 2 is a multihoming scenario, where the MANs are connected by
   an IP core network.  The routers in the core network run both IGP
   (ISIS or OSPF) and BGP, the IGP is used to achieve the internal
   routing and connectivity.  There will be full mesh I-BGP sessions
   among the core routers or I-BGP sessions between the routers and the
   Route Reflector (RR).  There will be E-BGP sessions between the core
   routers of the IP core network and the edge routers of the MANs.  The
   BGP is used to distribute the Internet and the MAN routes.

   For each MAN, it multihoming connects to the IP core network through
   two or more core routers.  Traffic between the MANs are typically
   forwarded through the IP core network.  At the same time, there are
   some MANs that may have direct connected links between them.




















Chen, et al.            Expires January 12, 2014                [Page 4]


Internet-Draft          RR based Traffic Steering              July 2013


                         ----------
                     ///-          -\\\
                  /// IP Core Network  \\\        +-----+
                 /                        \ ------|MAN3 |
   +-----+     | +---+              +---+  |   \  +-----+
   |MAN1 |----|  | A |--------------| B |   |   \  / |
   +-----+ /  |  +---+              +---+    |   \/  |
         \/   |     \                 |      |   /\  |
         /\   |      \                |      |  /  \ |
   +-----+ \   |      \               |     |  /   +-----+
   |MAN2 | ---- |  +----+          +----+  | ------|MAN4 |
   +-----+       \ | C  |----------| D  | /        +-----+
                  \+----+          +----+/
                     \\\-          -///
                         ----------
                Figure 2: Multihoming Scenarios


   For such a network, there will be requirements like this:

      If there are direct links between MANs, the traffic should be
      forwarded through the direct connected links; and if the direct
      connected links are used up, then some traffic should be forwarded
      though the IP core network;

      For two specific MANs (e.g., MAN1 and MAN3), the traffic between
      them should be forwarded though the required path, for example,
      MAN1-A-B-MAN3; the working and backup path should be disjoint as
      soon as possible.

      For two specific MANs (e.g., MAN2 and MAN4), part of the traffic
      is required to be forwarded through one path (e.g.,
      MAN2-C-D-MAN4), and other traffic is required to be forwarded
      through other path (e.g., MAN2-A-B-MAN4);

      There may be more other requirements with the increasing of the
      network size, density, and more services transmitted over the
      network, more access networks connect to the network.

   As discussed in the previous section, the current metric-based
   traffic conducting mechanism cannot (at least does not easily)
   satisfy the above requirements.









Chen, et al.            Expires January 12, 2014                [Page 5]


Internet-Draft          RR based Traffic Steering              July 2013


2.2.  Multiple Planes Scenario

   With the increasing of network traffic, the bandwidth, device ports
   of the existing devices/network are not enough to support new
   accessed traffic and services.  So, some operators choose to set up
   new parallel planes to enlarge the network capacity.

   Figure 3 is a multiple planes scenario, there are two planes in the
   IP core network.  C11, C12, C13 and C14 belong to plane 1; C21, C22,
   C23 and C24 belong to plane 2.  Plane 2 is the new built plane that
   normally has more bandwidth and is fine designed.  So, the operators
   will move the high-cost services to the new plane, and keep the other
   services on the old plane, and try to fully use the network resource
   of the two planes and keep the traffic balanced according to the
   capacity of two planes.

                +-----+  +-----+   +-----+
                |MAN1 |  |MAN2 |...|MANn |   MANs
                +-----+  +-----+   +-----+
                    /\    /    \    /\
           ......../..\../......\../..\.............
           .           \/        \/                .
           .          C11----------C21             .
           .          | \         | \              .
           .          |  \        |  \             .
           .          |   C12----------C22         .
           .  Plane1  |    |      |    | Plane2    .
           .          C13--|-----C23   |           .
           .            \  |        \  |           .
           .             \ |         \ |           .
           .  IP Core    C14----------C24          .
           .  Network      /\        /\            .
           ............\../..\....../..\../.........
                        \/    \    /    \/
                    +-----+  +-----+   +-----+
                    |MAN11|  |MAN12|...|MAN1n|   MANs
                    +-----+  +-----+   +-----+
               Figure 3: Multiple Planes Scenarios


   For the multiple planes network, here are some typical requirements:

      For any two specific MANs (e.g., MAN1 and MAN11), some service
      (e.g., Internet Data Center (IDC), Virtual Private Network (VPN),
      Private Line etc. services ) traffic is required to be forwarded
      through the new plane (plane 2), and the other traffic will still
      be forwarded though the old plane (plane 1);




Chen, et al.            Expires January 12, 2014                [Page 6]


Internet-Draft          RR based Traffic Steering              July 2013


      Traffic between some MANs is required to be forwarded though plane
      1, and traffic between other MANs is required to be forwarded
      though plane 2; for example, traffic between MAN1 and MAN11 is
      required to be forwarded through plane 1, traffic between MAN3 and
      MAN33 is required to be forwarded through plane 2.

      For any two specific MANs (e.g., MAN2 and MAN22), it should be
      able to balance the traffic between the two MANs through the two
      planes based on the capacity/load of the two planes;

      According to different users, it should be able to choose
      different planes;

      According different SLA and QoS requirements, it should be able
      choose proper forwarding plane based on the SLA and QoS
      requirements and the fact of the planes;

      It should able to choose forwarding plane based on the different
      access locations;

2.3.  Multiple Entries/Exits Scenario

   Figure 4 shows the multiple entries/exits scenario.  For network 1,
   it has three entries/exits that respectively connect to transit
   network A, B and C. And between network 1 and each transit network,
   there is one or more links.  Different link has different cost/price,
   bandwidth, delay/loss attributes.

                          /---\
                         |  A  |---
                        / \---/
           -----       /
        ///     \\\   /
       |           | /    /---\
      |  Network 1  |----|  B  |---
      |             |     \---/
       |           | \
        \\\     ///   \
           -----       \  /---\
                        \|  C  |---
                          \---/

       Figure 4: Multiple Entry/Exit (MEE)


   For this multiple extry/exit scenario, it has the following
   requirements:




Chen, et al.            Expires January 12, 2014                [Page 7]


Internet-Draft          RR based Traffic Steering              July 2013


      Choose the proper extry/exit based on link price and/or service
      type;

      Dynamically adjust the extry/exit based on link load and/or link
      price;

2.4.  Requirement Summary

   According to the above use cases, the requirements can be summarized
   as follows:

      Be able to specify the forwarding path/plane based source and
      destination addresses;

      Be able to specify the forwarding path/plane based on service
      type;

      Be able to specify the forwarding path/plane based on users;

      Be able to specify the forwarding path/plane based on SLA and QoS
      requirements;

      Be able to change/adjust the forwarding path/plane of some traffic
      based on the network load and usable capacity;

      Be able to choose/adjust network entry/exit based on link price/
      service type/link load;

   Looking through these requirements, they are actually the
   requirements of traffic engineering.  In tradition IP network,
   traffic forwarding is a per-hop IP lookup and forwarding behavior.
   There is few mechanism defined for pure IP based traffic engineering.
   IP source routing is a way that can direct the traffic to transmit
   along specified path, but it is not widely implemented and deployed.
   That means, there is requirement to introduce the traffic engineering
   to pure IP network, but it is lack of readily available solutions.

3.  Route Refelection based Traffic Steering

   For a product network, an acceptable solution should be able to
   smoothly and incrementally upgrade the network and should not affect
   the on-going services.  Route Reflection is widely deployed in the
   field, a Route Reflector (RR) has the ability to "install"/distribute
   a route to its client with the nexthop that can be either the RR
   itself or any other different BGP speakers.  Given this, for an IP
   network, if all routers run BGP and are connected by a centralized
   RR, and the RR has the topology, network capacity, network resource
   etc. information of the whole network.  Then the RR can compute the



Chen, et al.            Expires January 12, 2014                [Page 8]


Internet-Draft          RR based Traffic Steering              July 2013


   routes for every router and install/distribute the routes to
   corresponding routers.

                          ----
                         /    \
                        |  RR  |
                         \    /
                         /-+-\
                        /  |  \
                       /   |   \
                      / +--+-+  \
               +--+-+/| | B  |   +--+-+
    Source 1---| A  | | +----+   | C  |--- Destination 1
            \ /+----+ |          +----+\ /
             *    +---+----+-------+    *
            / \+--+-+      |     +-+--+/ \
    Source 2---| D  |   +--+-+   | F  |--- Destination 2
               +----+   | E  |   +----+
                        +----+
    Figure 5: Route Reflection based Traffic Steering (RRTS)



   Figure 5 is a reference architecture of the Route Reflection based
   Traffic Steering (RRTS).  The RR and its route reflection clients
   form a RRTS domain.  The RR is a centralized controller that is
   responsible for the BGP route decision of the whole domain.  All
   other routers in the domain are as route reflection clients of the
   RR, each router will establish an I-BGP session to the RR, and there
   is no direct BGP sessions among these routers.

   This looks no different from the current Route Reflector (RR) based
   architecture.  For each client, it will still run as current, when
   received BGP routes from outside, it will transparently distribute
   the routes to the RR.  For each route, the RR will make the decision
   for each relevant router and then install/distribute the route to
   each related router.

   For example, for a path from Source 1 (S1) to Destination 1 (D1), if
   the computed path is: S1-A-B-C-D1, then the RR will distribute a
   route (D1) to C with the nexthop set to D1; a route (D1) to B with
   the nexthop set to C, and a route (D1) to A with the nexthop set to
   B, and finally the route (D1) will be distributed to S1 by A.

   RRTS will not require the clients to make any changes.  All the
   changes are made on the RR, the RR can apply any route or traffic
   engineering algorithms.




Chen, et al.            Expires January 12, 2014                [Page 9]


Internet-Draft          RR based Traffic Steering              July 2013


4.  IANA Considerations

   This document makes no request of IANA.

5.  Acknowledgements

   The authors would like to thank Bai Tao, Fengqing Yu for their
   contribution to this document.

6.  References

6.1.  Normative References

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

6.2.  Informative References

   [I-D.ietf-idr-add-paths]
              Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
              add-paths-08 (work in progress), December 2012.

   [I-D.ietf-idr-bgp-optimal-route-reflection]
              Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S.
              Litkowski, "BGP Optimal Route Reflection (BGP-ORR)",
              draft-ietf-idr-bgp-optimal-route-reflection-05 (work in
              progress), June 2013.

Authors' Addresses

   Mach(Guoyi) Chen
   Huawei Technologies

   Email: mach.chen@huawei.com


   Shunwan Zhuang
   Huawei Technologies

   Email: zhuangshunwan@huawei.com










Chen, et al.            Expires January 12, 2014               [Page 10]


Internet-Draft          RR based Traffic Steering              July 2013


   Yongqing Zhu
   China Telecom Co.,Ltd
   109 West Zhongshan Ave,Tianhe District
   Guangzhou  510630
   China

   Email: zhuyq@gsta.com


   Subin Wang
   China Telecom Co.,Ltd
   109 West Zhongshan Ave,Tianhe District
   Guangzhou  510630
   China

   Email: wangsb@gsta.com



































Chen, et al.            Expires January 12, 2014               [Page 11]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/