Large Flow Use Cases for I2RS PBR and QoS
draft-krishnan-i2rs-large-flow-use-case-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Ramki Krishnan , Anoop Ghanwani , Sriganesh Kini , Dave McDysan , Diego R. Lopez | ||
| Last updated | 2014-01-20 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-krishnan-i2rs-large-flow-use-case-01
I2RS Working Group R. Krishnan
Internet Draft Brocade Communications
Category: Informational A. Ghanwani
Expires: April 2014 Dell
S. Kini
Ericsson
D. Mcdysan
Verizon
Diego Lopez
Telefonica
January 20, 2014
Large Flow Use Cases for I2RS PBR and QoS
draft-krishnan-i2rs-large-flow-use-case-01
Abstract
This draft discusses two use cases to help identify the requirements
for policy-based routing in I2RS. Both of the use cases involve
identification of certain flows and then using I2RS to program
special handling for those flows.
The first use case deals with improving bandwidth efficiency.
Demands on networking bandwidth are growing exponentially due to
applications such as large file transfers and those with rich media.
Link Aggregation Group (LAG) and Equal Cost Multipath (ECMP) are
extensively deployed in networks to scale the bandwidth. However,
the flow-based load balancing techniques used today make inefficient
use of the bandwidth in the presence of long-lived large flows. We
discuss how I2RS can be used for achieving better load balancing.
The second use case is for recognizing and mitigating Layer 3-4
based DDoS attacks. Behavioral security threats such as Distributed
Denial of Service (DDoS) attacks are an ongoing problem in today's
networks. DDoS attacks can be Layer 3-4 based or Layer 7 based. We
discuss how such attacks can be recognized and how I2RS can be used
for mitigating their effects.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Krishnan Expires April 2014 [Page 1]
Internet-Draft I2RS Large Flow September 2013
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April, 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.
Conventions used in this document
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 [RFC 2119].
Table of Contents
1. Introduction...................................................4
1.1. Large Flow Load Balancing.................................4
1.2. DDoS attack mitigation....................................5
1.3. Large Flow Identification.................................5
1.4. Acronyms..................................................6
1.5. Terminology...............................................6
2. Large Flow Recognition, Signaling, and Rebalancing..........7
2.1. Network-based Recognition of Large Flows..................7
Krishnan Expires April 2014 [Page 2]
Internet-Draft I2RS Large Flow September 2013
2.2. Off-network based notification of Large Flows.............7
2.3. Flow Rebalancing..........................................7
2.3.1. Local Rebalancing....................................7
2.3.2. Global Rebalancing...................................8
3. DDoS Detection and Mitigation..................................9
4. Summary.......................................................10
5. Operational Considerations....................................10
6. IANA Considerations...........................................10
7. Security Considerations.......................................10
8. Acknowledgements..............................................11
9. References....................................................11
9.1. Normative References.....................................11
9.2. Informative References...................................11
Authors' Addresses...............................................11
Krishnan Expires April 2014 [Page 3]
Internet-Draft I2RS Large Flow September 2013
1. Introduction
This draft describes use cases that address two problems caused by
large flows. The use case consists of mitigating the problem by
applying policy-based routing (PBR) on the routing elements using
its I2RS. The first large flow problem is that of inefficient
bandwidth usage due to hash-based load balancing in networks and the
second is that of DDoS attacks.
1.1. Large Flow Load Balancing
Networks extensively deploy LAG and ECMP for bandwidth scaling.
Network traffic can be predominantly categorized into two traffic
types: long-lived large flows and other flows (which include long-
lived small flows, short-lived small/large flows) [OPSAWG-large-
flow]. Stateless hash-based techniques [ITCOM, RFC 2991, RFC 2992,
and RFC 6790] are often used to distribute flows over the components
in a LAG/ECMP irrespective of whether the flows are long-lived large
flows or other types. In a traffic distribution consisting of long-
lived large flows, the traffic load may not be evenly distributed
over the components of the LAG or ECMP.
This draft describes long-lived large flow load balancing techniques
for achieving the best network bandwidth utilization with LAG/ECMP
and the corresponding I2RS requirements. Some of these techniques
have been described in detail in [OPSAWG-large-flow]. We describe
methods that can be used locally within a single router, as well as
methods that can be applied across multiple network elements, where
the network is under the control of single administrative entity.
We refer to the former as local load balancing and the latter as
global load balancing. A combination of local/global load balancing
helps in achieving the best network bandwidth utilization and
latency for a given network topology.
At a high-level, the technique involves recognizing large flows and
rebalancing them to achieve optimal load balancing. Large flows may
be recognized within a router, or using the aid of an external
entity such as an IPFIX [RFC 7011] collector or a sFlow [sFlow-v5]
collector. Once a large flow has been recognized, it must be
signaled to an application that makes the rebalancing decision.
Finally, the rebalancing decision is communicated to the routers to
program the forwarding plane. In subsequent sections, we describe
the requirements with recognition and rebalancing as they pertain to
I2RS.
Krishnan Expires April 2014 [Page 4]
Internet-Draft I2RS Large Flow September 2013
1.2. DDoS attack mitigation
Layer 3-4 based DDoS attacks are an ongoing problem in today's
networks. Example of Layer 3-4 based DDoS attacks are [FDDOS]:
. SYN Flood Attack: Fake TCP connections are setup which result
in table overflows in stateful devices.
. UDP Flood Attack: Servers are flooded with UDP packets that
result in consumption of bandwidth and CPU. These can be used
to target specific services by attacking, e.g., DNS servers and
VOIP servers.
. Christmas Tree Flood Attack: TCP packets from non-existent
connections with flags other than the SYN flag sent to servers
result in consumption of more CPU than normal packets because
of the effort required to discard them.
Typically, the above attacks are not from a single host or source IP
address; multiple hosts with different source IP addresses working
in tandem cause these attacks - hence the term Distributed DoS or
DDoS.
The DDoS use case involves recognizing large flows and performing
various types QoS actions on the recognized flows based on
configured policies. Large flows may be recognized within a router,
or using the aid of an external entity such as an IPFIX [RFC 7011]
collector or a sFlow [sFlow-v5] collector. In subsequent sections,
we describe the requirements with respect to recognition and QoS
actions as they pertain to I2RS.
1.3. Large Flow Identification
From the standpoint of a router, large flows are typically
identified using one or more fields from the packet header from the
following list:
. Layer 2: source MAC address, destination MAC address, VLAN ID.
. IP/TCP/UDP header: IP Protocol, IP source address, IP
destination address, flow label (IPv6 only), TCP/UDP source
port, TCP/UDP destination port, TCP Flags.
. MPLS Labels.
For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc., flow
identification is possible based on inner and/or outer headers. The
Krishnan Expires April 2014 [Page 5]
Internet-Draft I2RS Large Flow September 2013
above list is not exhaustive. This definition of a flow is
consistent with [RFC 7011].
In the remainder of this document, consistent with [OPSAWG-large-
flow], we use the term "large flow" to refer to "long-lived large
flows," and we use the term "small flow" to refer to any of the
three other types of flows identified above.
1.4. Acronyms
COTS: Commercial Off-the-shelf
DoS: Denial of Service
DDoS: Distributed Denial of Service
ECMP: Equal Cost Multi-path
GRE: Generic Routing Encapsulation
LAG: Link Aggregation Group
LSR: Label Switch Router
MPLS: Multiprotocol Label Switching
NVGRE: Network Virtualization using Generic Routing Encapsulation
PBR: Policy Based Routing
QoS: Quality of Service
STT: Stateless Transport Tunneling
TCAM: Ternary Content Addressable Memory
VXLAN: Virtual Extensible LAN
1.5. Terminology
Large flow(s): long-lived large flow(s)
Small flow(s): long-lived small flow(s) and short-lived small/large
flow(s)
Krishnan Expires April 2014 [Page 6]
Internet-Draft I2RS Large Flow September 2013
2. Large Flow Recognition, Signaling, and Rebalancing
2.1. Network-based Recognition of Large Flows
The first step is recognizing large flows. There are two ways for
recognizing large flows as described in [OPSAWG-large-flow].
The first method is automatic hardware-based recognition in which
the large flows are identified in hardware. Once a large flow is
recognized, it needs to be communicated to an application that is
capable of making rebalancing decisions. This communication is out
of scope for I2RS and can be handled using protocols such as IPFIX
[RFC 7011].
The next method is where sFlow or IPFIX packet sampling [PSAMP] can
be used to convey packet samples to an external entity such as sFlow
or IPFIX collector. The external entity recognizes large flows and
this entity signals the large flows to another application that is
capable of making rebalancing decisions. Once again, this
communication is out of scope of the I2RS. An example of software
which can be used to recognize large flows in real-time is inMon
sFlow-RT [sFlow-RT]; sFlow-RT is a component of the external sFlow
collector entity.
2.2. Off-network based notification of Large Flows
Instead of having the network recognize large flows, the large flow
can be notified by an application that has awareness of large flows,
e.g. a backup operation, and may perhaps indicate other parameters
such as the latency desired. Such flows would once again need to be
notified to the application capable of routing or rebalancing
decisions. This communication is also outside the scope of I2RS.
2.3. Flow Rebalancing
2.3.1. Local Rebalancing
In the case of local rebalancing, the utilization of the component
links that are part of the LAG or ECMP are monitored and the flows
are redistributed among the member links to ensure optimal load
balancing across all of the component links. Typically, this
involves redirecting large flows to specific ECMP or LAG components,
and potentially adjusting the weights used to distribute small flows
across these components, using mechanisms specified in [OPSAWG-
large-flow].
Krishnan Expires April 2014 [Page 7]
Internet-Draft I2RS Large Flow September 2013
This approach works regardless of whether the underlying network is
IP or MPLS.
At the RIB level, the nexthop information is typically resolved over
an IP interface. However, the IP interface can be realized over a
L2 LAG. For this use case the nexthop of a PBR route should be
resolvable to the granularity of a component of a L2 LAG.
To achieve this, there are two requirements for I2RS:
. For redirecting large flows to a specific component, a PBR
entry is required for the flow with its nexthop that identifies
the specific LAG or ECMP component.
. For adjusting the weights used to distribute traffic across
components of the LAG or ECMP, a mechanism is needed that
identifies ECMP entries and is able to associate weights that
can be programmed for each of the components. To do this in a
scalable fashion, it would be useful to have the notion of an
ECMP nexthop that is used by multiple routes.
2.3.2. Global Rebalancing
2.3.2.1. IP Networks
For IP networks, this involves programming a globally optimal path
for the large flow. The globally optimal path is programmed in the
IP network using hop-by-hop PBR rules.
For IP networks, this involves creating a globally optimal path
[HEDERA-dynamic-flow-scheduling] using a network management entity
which hosts an I2RS client. The globally optimal path is programmed
in the IP network using hop-by-hop PBR rules. The weights of the
ECMP table for different nexthops should be adjusted to factor the
long-lived large flows - this is explained below with an example.
As an example, consider a 4 way ECMP at node n1 with IP nexthops
n11, n12, n13, n14 using links l1, l2, l3, l4 each of capacity 10
Gbps. Say, a long-lived large flow of average bandwidth 2 Gbps is
admitted to one of the links l3. The ECMP nexthop table needs to be
adjusted to approximately account for the long-lived large flow so
that the other flows do not overload link l3 which is already used
by the large flow. The ECMP nexthop table will be programmed as
w1*n11, w2*n12, w3*n13, w4*n14 where w1=w2=w4=1 and w3=0.8; this
needs to be done for all the routes using the same set of nexthops.
Krishnan Expires April 2014 [Page 8]
Internet-Draft I2RS Large Flow September 2013
Now, if there are other set of nexthops from node n1 using link l3,
they should also be adjusted. Say, there is another set of IP ECMP
nexthops n13, n14, n15, n16 using links l3, l4, l5, l6. The ECMP
nexthop table will be programmed as w1*n13, w2*n14, w3*n15, w4*n16
where w2=w3=w4=1 and w1=0.8; this needs to be done for all the
routes using the same set of nexthops. In practice, there could be
multiple large flows on a single link and the ECMP nexthop table
must be adjusted to factor all of these flows.
As mentioned in Section 2.3.1. , it would be useful to have a way of
addressing an ECMP group, so that all routes sharing an ECMP group
are addressed together.
2.3.2.2. MPLS Networks
There are several ways to address global load rebalancing in MPLS
networks. For example:
. Have multiple LSPs between ingress and egress routers. In
this case, having a PBR entry at the edge LSR that forwards the
large flow to specific LSP known to have the necessary
bandwidth is needed.
. Program a new LSP for a given large flow.
Here the requirements for I2RS would be providing the ability to
program PBR entries at the edge LSR, and the programming new LSPs in
the network.
3. DDoS Detection and Mitigation
Layer 3-4 based DDoS attacks can be mapped to large flows in the
network. Consider the following example of a TCP SYN attack. A TCP
SYN packet from a single source IP address can be mapped to a Layer
4 flow based on the following: IP source/destination addresses,
TCP/UDP source/destination ports, IP protocol, TCP SYN Flag. For the
purpose of DDoS it is not useful to observe the above Layer 4 flow
in the network. Say, we observed a large flow based on IP
destination addresses, TCP/UDP destination port, IP protocol, and
TCP SYN flag in the network. In the case of a DDoS attack such a
flow would cause a significant event in the network in terms of
exceeding a pre-defined bandwidth threshold over an observation
interval.
Once the large flows causing the DDoS attacks are recognized in the
network, various types of Quality of Service (QoS) actions such as
rate-limiting, re-marking, or discarding can be performed on the
Krishnan Expires April 2014 [Page 9]
Internet-Draft I2RS Large Flow September 2013
flows based on configured policies. Besides the QoS actions, we need
the capability to redirect the large flow to a DDoS scrubber
appliance for further examination (typically layer 7) of the traffic
- this can be accomplished through nexthop redirection (the nexthop
may be directly connected to the router or indirectly through a
tunnel). The QoS action is independent of the nexthop redirection
action. It should be possible to program either of these actions
independently of the other. This would help in preventing resource
exhaustion (CPU, memory etc.) on devices such as servers and unfair
access to network resources in a multitenant network.
4. Summary
We have described the problems of large flow load balancing and DDoS
mitigation using I2RS. In both cases, the problem translates to
that of detection large flows that meet certain criteria. The
detection can be done without I2RS using tools such as IPFIX and
sFlow.
Once a large flow has been detected, I2RS must be used to modify the
forwarding tables in the router.
. In the case of large flow load balancing, this may involve
redirecting the large flow to a particular member with the LAG
or ECMP group and readjusting the weights of the other members
to account for the large flow.
. In the case of DDoS mitigation, the action involves rate
limiting, remarking or potentially discarding the large flow in
question.
5. Operational Considerations
Operational considerations would be similar to those specified in
[OPSAWG-large-flow].
6. IANA Considerations
None.
7. Security Considerations
This draft specifies a use case for I2RS and does not introduce any
new security requirements beyond those already under consideration
for I2RS.
Krishnan Expires April 2014 [Page 10]
Internet-Draft I2RS Large Flow September 2013
8. Acknowledgements
9. References
9.1. Normative References
9.2. Informative References
[OPSAWG-large-flow] Krishnan, R. et al., "Mechanisms for Optimal
LAG/ECMP Component Link Utilization in Networks," February 2014.
[HEDERA-dynamic-flow-scheduling] Al-Fares, M. et al., "Hedera:
Dynamic Flow Scheduling for Data Center Networks", December 2009
[sFlow-v5] Phaal, P. and M. Lavine, "sFlow version 5," July 2004.
[RFC 7011] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of Flow Information,",
September 2013
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels,", March 1997
[sFlow-RT] http://www.inmon.com/products/sFlow-RT.php
[PSAMP] Claise, B., "Packet Sampling (PSAMP) Protocol
Specifications", March 2009
[FDDOS] David Holmes, "The DDoS Threat Spectrum", F5 White paper
2012
Authors' Addresses
Ram Krishnan
Brocade Communications
[email protected]
Anoop Ghanwani
Dell
[email protected]
Sriganesh Kini
Ericsson
[email protected]
Dave Mcdysan
Verizon
Krishnan Expires April 2014 [Page 11]
Internet-Draft I2RS Large Flow September 2013
[email protected]
Diego Lopez
Telefonica
[email protected]
Krishnan Expires April 2014 [Page 12]