IP QoS and the Enterprise
| Converged enterprise networks have a critical need for controllable IP QoS levels. The various voice, video, and data applications in common use must be assigned specific service levels. In this section we examine the solution that MPLS offers in the provision of IP QoS. A service can be defined [RFC2475] as a set of characteristics of packet transmission in one direction through a network. A VLAN is a type of service in that it gives members a single broadcast domain, possibly distributed across a large enterprise network. A network operator views a service as a kind of pipe through its underlying network. The end user simply pushes traffic into the pipe (in this case, a VLAN) and may in fact be unaware of the existence of any service. SLAs (in relation to network management) dictate parameters such as:
Traffic that does not conform to the SLA may be either tagged or dropped. Tagged traffic may be forwarded if resources permit, or it may be dropped at a subsequent point in the path through the network. Enterprise network operators require the ability to easily create and manage different services in order to fulfill SLAs. This is an important NMS requirement, particularly as many organizations adopt a customer “supplier relationship with their IT departments. It also applies to organizations that outsource IT functions. A number of approaches can be adopted in the provision of IP QoS (i.e., a domain that offers more than best-effort service):
IntServ provides an end-to-end QoS model using microflows between specified endpoints. The routers in the path must maintain state information. IntServ provides a coarse-grained approach to traffic management. The RSVP protocol implements the IntServ model. Incoming traffic is pushed into a given microflow based on its destination address. The need for state maintenance and path reservation is often raised as a scalability concern with the IntServ approach. DiffServ (as we saw in the previous chapter) adopts a divide-and-conquer approach. Traffic is marked (with a DSCP) prior to entering the QoS domain, and routers apply specific per-hop-behavior (PHB) based on the marked values. MPLS and IntServ can be used in conjunction to create LSPs. Also, MPLS can use DiffServ to provide more advanced QoS capabilities (often in conjunction with special-purpose network processors) by the use of:
DiffServ allows a useful separation between traffic conditioning and service provisioning functions from the forwarding behaviors implemented in the network. The end-user IP traffic is marked with a DSCP in the DS IP header field (as we saw in Chapter 3, Figure 3-5). The DSCP corresponds with a specific set of downstream traffic handling criteria. Scalability concerns dictate that there are a limited number of forwarding behaviors associated with the DSCPs. This reduces the amount of QoS- related decision-making needed in NEs. In fact, the six bits provide for 64 (2 6 ) different DSCP. Out of these, 32 are set by the standard (RFC 2474), 16 are reserved, and 16 are available for experimental use. Each one corresponds to a PHB ”expedited forwarding, assured forwarding, and so on. The standard PHBs consist of:
Figure 4-9 illustrates two enterprise sites called Headquarters (Chicago) and Branch Office A (Boston) joined by a 10Mbps leased line (SP Link). Figure 4-9. Multisite enterprise traffic management. The two sites group functionally related users (such as NMS developers) into a VLAN1 ”the latter forms a multisite broadcast domain. Multiservice switches (containing both ATM and IP/MPLS hardware) are located at each end of the intersite link, and all traffic passes through these NEs. The traffic emitted by the Boston office originates from:
The Chicago site acts as the termination point for both Internet and telephony traffic. The three traffic types (originating in Boston) must cross the intersite link to get to Chicago, and to achieve this we use three virtual circuits (or connections):
Creating these circuits requires us to instantiate rows in the MIB tables of the SNMP agent in Multiservice Switch1. We will see how this is done in Chapter 8, so for the moment, let's assume we use an NMS to magically create the circuits for us (after we specify the two endpoints and the required resources). Each of the virtual circuits has an associated bandwidth reservation, and the allocated value has been derived by IT. This allows for the link bandwidth to be carved up for use by the applications in both sites. If the bandwidth calculations are correct, then there is no need for overengineering. We note in passing that this is referred to as static traffic engineering (i.e., analyze traffic patterns, set the allocated bandwidth, and reconfigure later if required). Dynamic traffic engineering attempts to modify resources on the fly. Traffic from VLAN1 is forwarded from Boston to Chicago (and vice versa) across the Layer 2 LSP pair. One of the LSP pair handles traffic from Boston to Chicago while the other handles traffic in the opposite direction. VoIP traffic passes over the Layer 3 LSP pair. Finally, SMTP traffic passes over the SPVC. The only real-time traffic passing between the two sites is VoIP telephony, and we assume that all such traffic is marked to receive DiffServ EF forwarding. The DSCP in the IP header of these packets is then mapped into the EXP bits of the associated MPLS label (as in Figure 4-10). This ensures that when the VoIP packets are MPLS-encapsulated, they are pushed into the LSP where they receive the required PHB. Because the LSPs use the contents of the EXP field for scheduling priorities, they are referred to as E-LSPs. The E-LSPs in Figure 4-9 are dimensioned to carry 10 uncompressed voice channels of 64Kbps each. Figure 4-10. MPLS shim header structure. Once the virtual circuits have been created and are carrying traffic between the two sites, the NMS can examine the statistics MIB tables to verify correct operation. This consists of checking that packets are not being dropped excessively, bandwidth levels are adequate, and so on. MPLS Differentiated Services SupportChapter 3 discussed the IP header DS field. This can be mapped into the label associated with an MPLS LSP. Such an LSP is known as an E-LSP (as described in RFC 3270 and [DavieRehkter2000]) because its forwarding treatment is derived from the EXP (erimental) bits in the label. The MPLS label structure is illustrated in Figure 4-10. MPLS nodes use the label as the packet travels across an LSP. For an E-LSP, when the associated IP packet crosses the boundary of the MPLS cloud, the value of the DS field is mapped into the MPLS label EXP field. This field then dictates the PHB for the packet as it is forwarded through the MPLS cloud. The S bit dictates the position of this header in a hierarchy of LSPs. The topmost label in the stack is the one used for making forwarding decisions, and this is indicated by a value of zero in the S bit. Labels lower down the stack are used only when the ones above them have been popped. The TTL (Time to Live) field is used to ensure that the number of hops in the MPLS cloud has some meaningful value. Its value may be decremented at each hop, and once it reaches zero, the packet may be dropped. The standards also describe another option that uses the entire MPLS cloud as a single hop. Where the scheduling behavior is derived solely from the label value, the LSP is known as an L-LSP. This type of LSP can be used on links (such as ATM) that cannot encode the entire label structure. There will be one L-LSP for each supported PHB, and the drop precedence can be encoded in the link layer header (e.g., in the cell loss priority bit field for ATM). RFC 3260 contains more information on these topics. Attacks Against DiffServ NetworksDiffServ networks provide the means for advanced QoS features to be deployed at layer 3. This introduces a new level of vulnerability to external attacks because fraudulent use of such networks can have a potentially more destructive effect than is the case for best-effort service. We mention, in passing, that two types of attacks can be directed specifically at DiffServ networks:
If a network provides a limited set of PHBs, then denial of service can occur if a user fraudulently marks his or her traffic with a higher level of service than the one allocated. This may cause the network to consume more of its resources in handling the fraudulent traffic. This in turn can cause a denial of service to legitimate users by reducing the available bandwidth. The fraudulent marker is also guilty of theft of service in this case. More detail on the growing threat of network attacks can be found at [CERTWeb]. |
EAN: 2147483647
Pages: 150