4.4 Flows

4.4 Flows

Flows (also known as traffic flows or data flows) are sets of network traffic (application, protocol, and control information) that have common attributes, such as source/destination address, type of information, directionality, or other end-to-end information. Figure 4.1 illustrates this concept.

Figure 4.1: Flow attributes apply end-to-end and throughout network.

Information within a flow is transmitted during a single session of an application. Flows are end-to-end, between source and destination applications/devices/users. Since they can be identified by their end-to-end information, they can be directly linked to an application, device, or network or can be associated with an end user. We can also examine flows on a link-by-link or network-by-network basis. This is useful when we want to combine flow requirements at the network or network-element levels. Common flow characteristics are shown in Figure 4.2.

Flow Characteristics
Performance Requirements	Capacity (e.g., Bandwidth)
	Delay (e.g., Latency)
	Reliability (e.g., Availability)
	Quality of Service Levels
Importance/Priority Levels	Business/Enterprise/Provider
	Political
Other	Directionality
	Common Sets of Users, Applications, Devices
	Scheduling (e.g., Time-of-Day)
	Protocols Used
	Addresses/Ports
	Security/Privacy Requirements

Figure 4.2: Common flow characteristics.

Flow analysis is an integral part of the overall analysis process. Flows are where performance requirements, services, and service metrics are combined with location information to show where performance and service are needed in the network. Flow analysis provides an end-to-end perspective on requirements and shows where requirements combine and interact. It also provides some insight into the degrees of hierarchy and interconnectivity needed in the architecture and design. In addition, as we will see in the design process, this analysis also provides information that can be useful in choosing interconnection strategies, such as switching, routing, or hybrid mechanisms.

Most flows are bidirectional and can be represented as either a double-sided arrow with one or two sets of performance requirements or as two separate flows, each with its own set of requirements. A single-sided arrow with one set of performance requirements represents a unidirectional flow. Figure 4.3 shows these cases.

Figure 4.3: Flows are represented as unidirectional or bidirectional arrows with performance requirements.

Flows provide a different perspective on traffic movement in networks: They have logical and physical components, and they allow traffic to be coupled with users, applications, or devices. Flows are becoming increasingly important in the analysis, architecture, and design processes.

We will examine two types of flows: individual and composite. We will see that the aggregation of requirements and flows in the network as a result of hierarchy will lead to composite flows and that this can happen in the access network and in the backbone.

4.4.1 Individual and Composite Flows

An individual flow is the flow for a single session of an application. An individual flow is the basic unit of traffic flows in this book; either they are considered individually or they are combined into a composite flow. When an individual flow has guaranteed requirements, those requirements are usually left with the individual flow and are not consolidated with other requirements or flows into a composite flow (Figure 4.4).

Figure 4.4: Individual flow for a single application with guaranteed requirements.

This is done so that the flow's guaranteed requirements can be treated separately from the rest of the flows. Individual flows are derived directly from the requirements specification or are estimated from our best knowledge about the application, users, and devices, as well as their locations.

A composite flow is a combination of requirements from multiple applications or of individual flows that share a common link, path, or network. Most flows in a network are composites (Figure 4.5).

Figure 4.5: Example composite flows.

More examples of flows are presented in Figure 4.6. The first example is an individual flow, consisting of a one-way delay requirement for a single session of an application (note that this flow is unidirectional). The second example is also of an individual flow, but in this case the capacity requirements are given in each direction. Since they are different, they are listed independently. The convention of upstream and downstream is used here to provide directionality based on the source and destination of the flow, where upstream indicates the direction toward the source and downstream is the direction to the destination. Upstream is often toward the core of the network, and downstream is often toward the edge of the network, particularly in service-provider networks. Another way to show a bidirectional flow is with two arrows, one upstream and the other downstream, each with its own performance requirement.

Figure 4.6: Flow examples.

The third example is a composite flow, listing requirements from three applications at the same source. The last example uses a performance profile to describe the flow's performance requirements. A profile is often used when many flows have the same requirement. In this case, developing a profile makes it easier to apply the same requirements to multiple flows. Then a pointer to the profile is sufficient to describe the requirements instead of having them written out each time. This is especially useful when the requirements are long or when they are consistent across many flows. The flow in this example could be either an individual or a composite flow, depending on the contents of the profile.

Performance requirements for individual flows and composite flows are determined through development of a flow specification for the network, which is discussed at the end of this chapter.

4.4.2 Critical Flows

Some flows can be considered more important than others; that is, they are higher in performance or have strict requirements (e.g., mission-critical, rate-critical, real-time, interactive, high performance), whereas some flows may serve more important users, their applications, and devices. Such flows are called critical flows. In this chapter, we will examine how to determine when flows are critical. When prioritizing which flows get attention in the network architecture and design, critical flows usually come first. This is usually the case, but individual flows with guaranteed requirements might also be considered first in the architecture and design. Prioritizing flows will be discussed at the end of this chapter.

Flows are described in this fashion to make it easier to understand and combine requirements. Composite flows combine the requirements of individual flows, whereas individual flows can show guaranteed requirements that must be considered throughout the end-to-end path of the flow. All of these flows are important in the architecture and design of the network. The descriptions of the types of flows that we develop in the flow specification will help us define the architecture and choose the technologies and services that best fit the customer's needs.

Throughout this chapter, we will analyze flow requirements to determine where they apply and when they contribute to composite flows and, if so, how to combine their performance requirements accordingly. Some networks will have flows that indicate single-tier performance, others will have flows that indicate multitier performance, and still others will have flows that have predictable (stochastic) and/or guaranteed performance. Often, the few flows that require high, predictable, and/or guaranteed performance will be the ones that drive the architecture and design from a service (capacity, delay, and RMA) perspective, and all flows will drive the architecture and design from a capacity perspective. The architecture and design processes accommodate both of these perspectives.