26.07.2013 Views

WiMax Operator's Manual

WiMax Operator's Manual

WiMax Operator's Manual

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

166 CHAPTER 7 ■ SERVICE DEPLOYMENTS OVER PUBLIC WIRELESS MANS<br />

Major Networking Standards for Supporting IP QoS<br />

To a considerable extent, the standards for achieving QoS with IP transmissions are complementary<br />

in the sense that none represents a complete solution. Frequently two or more<br />

protocols are used together.<br />

IP over ATM<br />

The 802.16 standard fully supports ATM, which itself offers excellent support for QoS on quite<br />

a number of applications. ATM is also supported almost universally by long-distance service<br />

providers, and unlike the case with MPLS, QoS functionality will be fully enabled end to end<br />

across the network when transmissions are directed through ATM core switches. ATM is, however,<br />

less efficient and less flexible than MPLS, and ATM services have not been competitively<br />

priced in the past. I consider ATM to be a legacy technology that is not ideally suited to the new<br />

service provider striving to compete on the basis of value with entrenched incumbents.<br />

Commonly Employed Ancillary IP Protocols for QoS<br />

From the middle 1990s onward, when the ascendancy of IP was becoming obvious, certain IP<br />

advocates sought to redress its equally obvious shortcomings in respect to determinacy by creating<br />

supplementary protocols. The fact that so many of these have been created would seem<br />

to argue the individual inadequacy of any one of them, and in fact they are frequently used in<br />

multiples. The protocols I will consider include RSVP, IntServ, DiffServ, IP Precedence, RTP,<br />

RTSP, and MPLS, among others.<br />

Most such protocols perform one of three functions. First, they request a certain allocation<br />

of bandwidth from the network deemed necessary for the execution of the application they<br />

are intended to support, and then they attempt to establish separate streams for individual<br />

applications where certain minimum network performance requirements will at all times be<br />

upheld. Thus, real-time video may go into one stream, toll-quality voice into another, and so<br />

on. Second, they append extra information to the packet in the form of an additional header or<br />

label. This assigns the packet to the correct stream and also requests special treatment by any<br />

network element the packet subsequently encounters; in effect it is a service classification<br />

label. Finally, they invoke specific mechanisms at the router for dealing with congestion and<br />

delay where different instructions for emptying queues, dropping packets, and retaining packets<br />

within queues over time are applied to different streams.<br />

It should be understood that the protocols themselves form only one aspect of a unified<br />

approach to QoS and that the use of the protocols as Band-Aids on an underengineered network<br />

is not going to produce satisfactory results. The protocols enable bandwidth to be used<br />

efficiently in supporting various services but they do not create bandwidth where it does not<br />

exist. In a sense compression can do that, but that is another issue for another section.<br />

RSVP<br />

Resource Reservation Protocol (RSVP) is a protocol for requesting bandwidth from routers<br />

along the path that a transmission will take. It does not guarantee that adequate resources will<br />

be provided, however, because one or more of the routers may themselves either lack adequate<br />

resources or may not have the protocol enabled. RSVP itself is not a routing protocol, and it<br />

makes no determination regarding the path that packet will take. Instead, it is a flow-based

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!