Connecting the WAN

We have so far concentrated on scenarios with local-area connectivity. You might wonder whether it is possible to run multicast across a public WAN? Yes, it is. The manner in which you do so depends greatly on the services offered by your local providers.

If the provider has an mVPN service, you can connect your core devices across it. Figure 9-16 shows two deployment models. The top one connects a native PIM network over a wide-area mVPN service. The bottom one runs an enterprise mVPN network over a service provider mVPN service. In the second scenario, the mVPN service connects enterprise mVPN P devices that run native PIM. The service provider network does not have visibility of the enterprise MDTs, MTI, and other mVPN components .

Figure 9-16. mVPN Service

It is more likelyat least at the time of this writingthat multicast traffic will need to be tunneled across the WAN. Figure 9-17 shows this simpler scenario. The WAN edge routers have a LAN-facing MTI interface for MDT connectivity, a WAN- facing (regular) GRE interface, and run VRF-aware PIM. In mVPN terms, the CE-PE interface is a GRE tunnel that connects each site. This scenario allows for virtualized core networks to connect to nonvirtualized sites that run native PIM.

Figure 9-17. Single-Domain-per-Branch Site

If the remote site is also virtualized, mVPN runs on all sites, as shown in Figure 9-18. The WAN edge routers use a different GRE tunnel for each virtual network. The remote site in Figure 9-18 uses hop-by-hop tunnels, or simply VLANs, to carry multicast traffic.

Figure 9-18. Multiple-Domains-per-Branch Site

The final scenario, in Figure 9-19, shows each site as a different mVPN domain, where the CE of one domain is the PE of another. The tunnels are regular GRE and transport native multicast traffic across the WAN.

Figure 9-19. Multiple-Domains-per-Branch Site

Note

In all cases, remember that RPF requires a unicast route to the multicast source (or RP). Routers in each site must have appropriate unicast routing information in every VRF; otherwise , multicast packets will be dropped.

Summary

This chapter discussed three main topics: basic multicast, managing multicast source and receivers across VRFs, and transport architectures.

A virtualized enterprise network is fully capable of carrying multicast traffic. The simplest case has source and recipients in the same VRF, in which case the design decision is whether to use p2p transport or mVPN.

The mVPN extranet solution addresses the case where source and receiver are not in the same VRF.

Standards work continues in this area. The references sections in Appendices C and D include texts for the interested reader to follow new developments.

Chapter 10. Quality of Service in a Virtualized Environment

The protocols used to virtualize campus networks have two effects on quality of service (QoS). First, they bring with them from their service provider origins several new mechanisms that might be useful in an enterprise environment. Second, they give rise to the basic question of how to implement QoS guarantees over a Virtual Network (VN).

This chapter attempts to cover both effects and starts by demystifying certain technologies, such as differentiated services-aware traffic engineering (DS-TE), before looking at which mechanisms can be applied (and how) in Virtualized Network.

QoS Models and Mechanisms: A Review

QoS is a continuation of network policy. Policy information is set at certain points, carried in protocol headers, and enforced throughout the network. The result should provide a predefined level of service for different types of traffic.

Note

You can also use QoS can to protect the network against certain types of security attacks, but that is beyond the scope of this discussion.

Many of the protocols used to virtualize network transport have fields dedicated to QoS, as summarized in the following list:

802.1q 3 User Priority bits in the Tag Control Information field, used to set the class of service (CoS) value, commonly referred to as 802.1p bits
IP 3-bit Type of Service (ToS) value or a 6-bit differentiated services code point (DSCP) value
MPLS 3-bit Experimental [EXP] field on non-ATM links
L2TPv3 No dedicated field
GRE No dedicated field
IPsec No dedicated field

On the device itself, the mechanisms used to effect policy should be familiar to readers of this book. In the interest of having standard definitions, the following list summarizes them:

Classification Selection of traffic for QoS processing. Selection criteria can be packet source interface, destination address, Layer 4 port information, or existing policy settings.
Marking Setting policy bits in a protocol header, such as IP DSCP or 802.1p.
Policing Limiting the bandwidth available to a category of ( classified ) traffic. Reasonable policers have multiple traffic limits: accepted aggregate rate, accepted bursts, and excess burst. How each category of traffic is treated depends on network policy. Policing discards or re-marks out of contract traffic. Shaping, on the other hand, queues out of contract traffic.
Queuing/scheduling Assigning traffic to ingress or egress queues based on classification. The number of queues on a device can vary wildly from 1 or 2 per port to several thousands on Service edge routers. Examples of queuing schemes include weighted fair queuing (WFQ), weighted round robin (WRR), and so on.
Congestion avoidance A set of schemes that discards data during congestion, thus reserving bandwidth for high-priority traffic at the expense of lower-priority traffic. Examples include early packet discard (EPD), weighted random early detection (WRED), or weighted tail drop (WTD).
Resource reservation The process of requesting and allocating link bandwidth for a category of traffic.
Link optimization Packet interleaving mechanisms that allow priority packets to meet latency or delay requirements.

QoS mechanisms detailed are deployed in support of a particular model or architecture. The initial Internet model was, of course, point-to-point (p2p) best effort. Other models include integrated services (IntServ), which uses the Resource Reservation Protocol (RSVP) to reserve bandwidth for flows of application traffic, and DiffServ. We review DiffServ in the next sections.

Differentiated Services

The DiffServ model is an architecture that allows scalable differentiation between data flows. With DiffServ, the majority of the labor- intensive QoS processing, such as classification, marking, and policing, is done at the network edge.

Traffic admitted to the network core is marked with a numeric value, a DSCP, which indicates to which class the packet belongs. The core devices process on a per-class (not per-flow) basis, and so they need to examine only the bits that carry the DSCP information (6 bits in the IP header) to know how to handle any particular packet.

DiffServ does not require state information or signaling of resource requirements, either on a flow or aggregate basis. Instead, each device is configured with certain administratively determined limits on the amount of resource per class. DiffServ is defined in RFC 2474 ( Definition of the Differentiated Services Field [DS Field] in the IPv4 and IPv6 Headers ) and RFC 2475 ( An Architecture for Differentiated Services ).

DiffServ introduces an important concept, namely per-hop behavior (PHB). PHB is the observable behavior of a device as it processes traffic. An end-to-end QoS service can be provided as long as the PHB is consistent across the network.

RFC 2474 defines two PHBs:

Default Simple best-effort class, with a DSCP value of 000000. Packets with no defined DSCP are mapped to the default class for best-effort service.
Class selector Provides for backward compatibility with 3-bit IP Precedence classes. Basically, it defines a DCSP of XXX 000, where XXX represent the IP Precedence bits.

The two most significant PHBs that use DiffServ are Assured Forwarding (AF) and Expedited Forwarding (EF), which are both defined in separate RFC documents.

RFC 2597 defines AF, and RFC 2598 defines EF:

AF The AF PHB defines four different classes. Within each class, there are three drop probabilities: low, medium, and high. Classes are written as AF ny , where n is the class and y is the drop probability within the class. Lower values of y denote higher priority; so, for example, the AF11 has a lower drop probability (so a better service) than AF13. RFC 2597 leaves it up to network administrators to define which AF classes they want to use for different traffic types and to configure the routers to allocate resources appropriately. Similarly, RFC 2597 makes no recommendations as to how the PHBs should be implemented, leaving the choice up to vendors .
EF Offers a leased-line ToS, with strict guarantees for latency, jitter, packet delivery, and so forth. Voice over IP (VoIP) applications use the EF PHB.

It is important to apply the correct DSCP value to a packet. In a switched environment, there are typically two QoS domains (Layer 2 and Layer 3), and policy classifications must be correctly copied between each.

In a typical campus network, the access switch classifies traffic based on either the incoming interface or ToS settings (the latter is common when a PC is connected to a switch through an IP phone) and marks this information in the 802.1p bits on the VLAN trunks that connect to the distribution layer. On the distribution switch, these ToS settings are copied to IP DSCP bits.

Cisco provides guidelines for which Layer 2 and 3 values to use in an enterprise network. Table 10-1 gives the complete 11 DSCP values and corresponding PHB names , if defined.

Table 10-1. Guidelines for 802.1p, IP Precedence, DSCP, and PHB Values in Enterprise Networks

Application	Layer 3 Classification			Layer 2
	IP Precedence	PHB	DSCP
IP routing	6	CS6	48	6
Voice	5	EF	46	5
Interactive video	4	AF41	34	4
Streaming video	4	CS4	32	4
Locally defined mission-critical data	3		25	3
Call signaling	3	AF31/CS3	26/24	3
Transactional data	2	AF21	18	2
Network management	2	CS2	16	2
Bulk data	1	AF11	10	1
Scavenger	1	CS1	8	1
Best effort
Information in Table 10-1 is taken from QoS SRND, available at http://www.cisco.com/go/srnd

The first settings column of the table lists the settings (limited to 7 classes) for IP Precedence rather than DSCP. Similarly, the last settings column shows the Layer 2 equivalence for each class.

The baseline QoS model is extremely granular, and it is often necessary to group different categories together (for example, in case you need to send data over a wide-area virtual private network (VPN) connection that supports only a limited number of classes, typically between three and five). This number is essentially determined by cost considerations in the wide-area provider's network.

However, the VPN protocols themselves can impose technical limitations. Of these, Multiprotocol Label Switching (MPLS) is the most interesting, not only because it is possibly unfamiliar, but also because it offers some valuable services not yet found with other the VPN transport protocols. The next section provides an introduction to MPLS QoS, but the interested reader is encouraged to consult some of the more specialized texts listed in the references at the end of the book.