RSVP gets a callback. IETF to recast the QoS protocol
nwfusion.com
By Sandra Gittlen
Network World Fusion, 8/27/98
Chicago - Some attendees at this week's
Internet Engineering Task Force meeting
thought they had come to place a headstone on
RSVP's grave.
But instead, the Resource Reservation Protocol
received a reprieve with the help of some other
quality-of-service initiatives: Differentiated
Services (DiffServ) and Multiprotocol Label
Switching (MPLS).
"RSVP's getting a new life," said Kathie
Nichols, senior principal engineer at Bay
Networks.
QoS was a major topic of discussion at the
meeting, because users are becoming impatient
for 'Net traffic delivery and performance
guarantees.
RSVP has been cited as one way to QoS
nirvana. But the protocol was designed in 1990
for a single network architecture, rather than
today's complex world of multiple subdomains.
"It's just not the best approach in a
heterogeneous world," acknowledges RSVP's
co-author, Lixia Zhang.
However, talk of replacing RSVP had many
scared, including Microsoft. "Microsoft was
worried about losing its investment in RSVP,"
Nichols said. In fact, Microsoft had put support
for RSVP in Windows 98 and NT.
A group of vendors, including Bay, Cisco,
which supports MPLS, and Microsoft, recently
met on the issues, according to Nichols,
co-chair of the DiffServ working group. They
agreed that RSVP could be used within
domains and that DiffServ and MPLS could be
used to send traffic across domains. Basically,
she said, "whatever you want to do in the local
domain is fine."
DiffServ allows a user to mark packets with
priority to ensure better service. The level of
service is denoted by a bit in the header. For
instance, if that bit is 0, then there is no
guaranteed level of service.
"Microsoft's now excited about DiffServ,"
Nichols said.
"DiffServ's great," said 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 in Beta 2 of NT 5.0
an implementation of DiffServ.
A network can use RSVP at the edge routers
and then use DiffServ in the core to aggregate
traffic, he said. "Telephony needs a tight
assurance from the DiffServ network. It
couldn't use a five [level of service] when it
asked for a six," he said.
The basic DiffServ concept of having bits
denoted in the header was approved at the
IETF meeting. However, what those bits, or
code points, will mean has not yet been
standardized.
"We need to standardize the code points,"
Bernet said. "Calling the router vendor to agree
on a number turns into a Tower of Babel."
Is there a policy on this?
To put all of these pieces together - RSVP,
DiffServ and MPLS - the IETF created a
policy framework working group.
The group was chartered to work on creating
parameters for policy development. A policy
could be the implementation of a service-level
agreement between an ISP and a customer or it
could be a decision on how a certain
department's traffic is going to be handled
within the corporate network. The group will
create a policy framework and set of data
structures that facilitate the administration and
distribution of policies. Among the group's
tasks is to create a means for specifying what
actions are to be taken under what conditions.
"[Policies] will provide the translation from
business-speak to device-level speak," said Ed
Ellesson, senior engineer at IBM Networking
Software in Research Triangle Park, N.C. "The
policy will tell the device know what needs to
be done [with packets]."
Even though many vendors either have or are
developing their own policy plans, the success
of policy-based networking depends on
interoperability among various vendors'
devices, one meeting attendee said.
To RSVP or not?
The MPLS working group, in the meantime,
was suffering through its own infighting. The
group could not decide whether to go with
RSVP as its signaling protocol to establish
routes. But at this meeting that issue was
resolved.
"RSVP is going to do path setup for MPLS,"
said Scott Bradner, a consultant with Harvard
University's Information Systems.
The MPLS working group is hoping to have a
proposed standard ready by the IETF's next
meeting in Orlando. |
