QoS cooperation reaches new heights at IETF meeting

There's been plenty of infighting over the years among quality-of-service (QoS) standards developers, but QoS advocates attending this week's Internet Engineering Task Force (IETF) meeting were practically the picture of cooperation. The emphasis was not on picking winners from a cluster of initiatives such as Diff-Serv and RSVP, but on making the various technologies work together.

There's been plenty of infighting over the years among quality-of-service (QoS) standards developers, but QoS advocates attending last week's Internet Engineering Task Force (IETF) meeting were practically the picture of cooperation.

Working groups -- including those for Differentiated Services (Diff-Serv), Multi-protocol Label Switching (MPLS), Resource Reservation Protocol (RSVP) and the RSVP Admission Policy -- pushed a handful of initiatives toward the standards stage. But rather than approaching each QoS separately, IETF members looked for ways to make the technologies work together.

For example, the RSVP working group members listened to a member of the MPLS working group explain how MPLS could use RSVP as its signaling protocol.

Separately, a new policy framework working group was formed to guide the development of policy management schemes, which need to take different QoS technologies into account.

Many of the 42nd IETF meeting's 2,000 attendees say it's becoming increasingly important to sort out differences among various QoS schemes in order to help ISPs meet customer demand for more reliable Internet traffic delivery.

"This cooperation is a response by the IETF to customers," says John Strassner, co-chair of the policy framework working group. "ISPs need to offer differentiated services because customers want to use high-powered applications with more functionality," adds Strassner, who is also the chief architect of Cisco's Internet Business Unit.

Equipment and software vendors, in turn, are receiving pressure from ISPs to standardize their wares so that ISPs can offer guarantees on traffic performance and delivery across each others' networks, Strassner says.

Understanding how different QoS approaches can co-exist across corporate, carrier and ISP networks is important in moving ahead with QoS standards efforts, says Kathleen Nichols, senior principal engineer at Bay Networks in Santa Clara, California.

RSVP handles bandwidth reservations. Common Open Policy Service, a draft in progress by the RSVP Admission Policy working group, can be used to check with a policy server to ensure a user has the right to request that bandwidth.

Diff-Serv uses bits within a packet header to denote the level of service a packet is to receive, while MPLS specifies the best route for traffic through a network based on a label marking source, destination and other factors. Diff-Serv backers say RSVP can be used at the edge of a network, while Diff-Serv is implemented at the core.

Until now, the various working groups dealing with QoS have largely kept to themselves, resulting in some standards delays, Nichols says.

For example, Microsoft until recently had opposed the Diff-Serv draft out of concern that Diff-Serv development would impede RSVP -- a technology Microsoft supports in products such as Windows NT and 98. But after recently meeting with Cisco and Bay about Diff-Serv, Microsoft changed its perspective.

"Diff-Serv's great," says Yoram Bernet, development lead of advanced technology at Microsoft. "It provides a way to extend QoS to places people feared RSVP won't be able to scale."

Microsoft included an implementation of Diff-Serv in NT 5.0 Beta 2.

Some attendees thought RSVP would be passed over at this IETF meeting because of its inability to scale well. "It's just not the best approach in a heterogeneous world," says Lixia Zhang, co-author of the RSVP specification. But she adds that a combination of RSVP and Diff-Serv has potential.

"RSVP's gained a new life," Nichols says.

While the MPLS and RSVP Admission Policy working groups are looking to the IETF's December meeting in Orlando, Florida, to get their standards approved, the Diff-Serv working group was able to push through its basic architecture standard.

Next on the Diff-Serv group's plate is standardising what the bits in the Diff-Serv header will mean.

The newly formed policy framework working group hopes to have its standard implemented next third quarter.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments