14.2. Traffic Engineering Perspective and its Relation to Network Robustness

In order to provide prioritization to different services under an attack or an overload condition, a key requirement is allocation of resources. For our discussion here, we will use bandwidth as the resource. While theoretically any network can be overprovisioned to the point where such resources are unlimited, from a practical perspective, this is not so. There are two important issues to consider: (1) the cost of overprovisioning can be prohibitive and (2) a sudden surge in traffic due to a number of events (legitimate or otherwise) can overwhelm a network to the point where it becomes nonfunctional or poorly functional. The first issue can be addressed somewhat by providing some level of overprovisioning, allowable within the capital and operational expenditure budget. However, the second issue brings out the importance of the point that not all events can be predicated, and thus, a network requires some form of protection. Combining both of them, we can say that protection or prioritization might not be necessary all the time, but the network must have the capability to have that, if and when necessary.

An important question then is how do we protect resources such as bandwidth in a shared environment. While there are a number of approaches in a shared virtualized environment, we take the approach of hiding resources, for example, by not announcing all available information in routing updates in a link-state routing environment. Before we delve into this aspect on how to do it, we first take a traffic engineering perspective with regard to hiding information in a dynamic routing environment.

To illustrate the hidden information idea in the context of a link-state advertisement, we consider a generic link i - j in a network. If C_i,j is the total bandwidth of this link, and the currently used bandwidth is u_i,j, then the free bandwidth is a_i,j = C_i,j - u_i,j. Thus, the obvious thing to do is to advertise a_i,j in the link-state advertisement. This information is flooded through the network and is used by (source) routers when doing routing computation in determining, say, the least-loaded route (e.g., the route with the most available bandwidth, also known as the widest path) to a destination router; this is then used for setting up a new request or a service class.

Suppose that we want to provide a built-in protection mechanism. That is, we want to reserve some bandwidth, say s_i,j, on link i - j for SC services. The link-state advertisement is SC capable when the available bandwidth advertised is w_i,j = C_i,j - u_i,j - s_i,j. In effect, we would like normal services to use the quantity w_i,j in determining route computation. At the same time, we want to let SC services know that there is really s_i,j amount of bandwidth also available on link i-j for their use in route computation and for traffic flow; this bandwidth is, however, not available to normal services. Note that the SC traffic has access to both the available bandwidth for normal traffic and the bandwidth set aside for SC traffic. To accomplish this, in the link-state advertisement, we actually want to advertise w_i,j as well as s_i,j; while the normal service sees w_i,j, the s_i,j amount is “hidden” to them. On the other hand, the SC service sees s_i,j, but based only on a properly specified authorization. Furthermore, if some routers are untrusted, we do not want them to “see” this hidden bandwidth. This mechanism provides a way to accomplish service priority to critical services in computing and selecting routes that uses the hidden bandwidth. This can be critical during an attack or an overload. Given the assumption that some routers (or users) may be untrusted, we propose to transmit the hidden bandwidth information in an encrypted mode. In this way, only the trusted routers can decipher this information. Note that while we focus here on available bandwidth information to be hidden, other resources that are critical to SC services could also be encrypted and disseminated through a link-state update.

The basic paradigm works on a semi-reservation-based mode. We use semi in two different ways. If in the above mechanism, s_i,j is set to zero, then there is no special reservation for SC services. Secondly, updating w_i,j with a new value does not mean that a hard reservation is needed; a soft reservation mechanism suffices. The network state maintenance at the routers can be threshold based with regard to access control. For example, access control may be activated if the link utilization is above a certain value and/or if notified by an intrusion detection system (IDS).

Finally, despite the hidden bandwidth protection mechanism, it is possible that an attacker may still want to consume resources by generating excessive dummy traffic. In the earlier scenario, we assume that an attacker may not use the hidden bandwidth in route computation since it cannot decipher this information. This, however, does not stop the attacker from still trying to inject traffic into the “hidden” parts of the network. To avoid this attack traffic from spreading, we need an access control mechanism at the entry point to check if this traffic should be allowed and a reservation mechanism that protects resources dedicated to SC services. Thus, a dynamic access control mechanism to check such requests is needed. The second possible scenario is that the attacker somehow manages to access the SC traffic class (at some source router) and starts injecting excessive traffic to a certain destination (resulting in, for example, a distributed denial-of-service (DoS) attack). In this case, through active monitoring, it is desirable to substantially limit the injection of this traffic at different entry points rather than letting it reach its destination. This allows us to contain the attack (closer to the source) rather than let it spread throughout the network for an extended period of time. Either of these scenarios would require some adaptive feedback mechanisms between different entry-point routers and possible destinations (choke points) in a network and a new level of trust generation among routers.

It may be noted that a feature similar to SC service bandwidth protection, called trunk reservation (TR), is currently used in dynamic call routing telephone networks [3]. The TR concept [4–6] is essentially equivalent to the protection we have described here. Note that TR in such settings is typically used to avoid bistability in a network [5] rather than the type of protection we are considering. Also, note that TR has been discussed in the context of quality-of-service (QoS) routing in the Internet [7].

14.2.1. An Illustrative Example

We consider an example to address some of the issues related to adaptiveness, routing, and the SC service protection. Consider a three-node network. We will assume a flow-based reservation for the purpose of this illustration; note that this is not a requirement in general in semi-reservation-based mode. A new flow request requires a fixed bandwidth rate for the time duration of the flow. Note that in general, a flow does not mean a call or a microflow in our framework; it may be a request that is the result of a virtual tunnel that needs to be set up with certain guarantees for a certain time duration, which in turn serves as a bearer of microflows. However, for the purpose of this simple illustration, a flow may be thought of as a microflow or a call.

We assume dynamic flow-based routing (a flow request for a traffic node pair can either use the direct path or use the alternate two-link path). The traffic between two traffic pairs (i.e., between nodes 1 and 2 denoted by pair {1:2}, and between nodes 1 and 3 denoted by pair {1:3}) is assumed to be stationary (and has the traffic volume). On the other hand, the third pair (i.e., between nodes 2 and 3 denoted by {2:3}) has overloaded traffic caused by an attack, which is represented by a dynamic traffic stream using a time-dependent arrival rate that follows a sinusoidal behavior. Now assume that all of the traffic for both pairs {1:2} and {1:3} are for SC services, while the dynamic traffic behavior for pair {2:3} is for the normal service that contains traffic due to the attack. It may be noted that this is a special case of the framework discussed in Section 14.2. Specifically, in this case, we have reservations for normal and SC services with the following condition: s_2,3 = 0, while s_1,2 > 0, s_1,3 > 0.

We have performed a simulation of this scenario using the MuSDyR simulator [8]. In Figure 14.1, we plot the flow-blocking probability for the normal service and SC service over time. As can be seen from Figure 14.1(a) (where the SC service protection amount is low), it is clear that as the dynamic traffic for the normal service peaks, it also drastically affects the SC services by increasing the denial rate even though the traffic for the SC service did not have increase in traffic during this period (since a stationary traffic pattern was used). On the other hand, in Figure 14.1(b) (by adjusting the SC service protection parameter values appropriately), we can show that the SC service is receiving essentially the same service guarantee during the entire time while the attack traffic is dynamically increasing during this period, and in fact, the attack traffic is facing heavy blocking as is desirable during this time. On the other hand, when the attack traffic dies away (the right part on each plot), having a low level of protection for SC services can be acceptable.

It is important to note that the protection amount for the SC service needs to be adjusted although the traffic itself may remain at the same level in a dynamic traffic environment. The second observation is that the reservation parameter values need to be adaptive based on the traffic changes in a network. In other words, a semi-reservation-based mode can be the operational mode.