Internet DRAFT - draft-chen-idr-rr-based-traffic-steering-usecase
draft-chen-idr-rr-based-traffic-steering-usecase
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]
