2.7.3 Integrated Services (intserv)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Nov-97


John Wroclawski <jtw@lcs.mit.edu>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:int-serv@isi.edu
To Subscribe: int-serv-request@isi.edu
Archive: ftp://ftp.isi.edu/int-serv/int-serv.mail

Description of Working Group:

Recent experiments demonstrate the capability of packet switching protocols to support Integrated Services --- the transport of audio, video, real-time, and classical data traffic within a single network infrastructure. These experiments suggest that expanding the Internet service model would better meet the needs of these diverse applications. The purpose of this working group is to specify this enhanced service model and then to define and standardize certain interfaces and requirements necessary to implement the new service model.

The working group will focus on defining a minimal set of global requirements which transition the Internet into a robust integrated-service communications infrastructure. Enhancements to individual protocols (e.g., adding additional routing information to routing protocols, or choosing IP queuing disciplines for routers) will be left to other working groups, except in those rare cases where detailed definitions of behavior are critical to the success of the enhanced architecture.

Extending the Internet service model raises a series of questions. The working group will focus on the three problems listed below:

(1) Clearly defining the services to be provided. The first task faced by this working group is to define and document the enhanced Internet service model.

(2) Defining the application service, router scheduling and (general) subnet interfaces. The working group must define at least three high-level interfaces: that expressing the application's end-to-end requirements, that defining what information is made available to individual routers within the network, and the additional expectations (if any) the enhanced service model has for subnet technologies. The working group will define these abstract interfaces, and will coordinate with and advise IP over "subnet" working groups (such as IP over ATM) in this.

(3) Developing router validation requirements which can ensure that the proper service is provided. We assume that the Internet will continue to contain a heterogeneous set of routers, running different routing protocols and using different forwarding algorithms. The working group will seek to define a minimal set of additional router requirements which ensure that the Internet can support the new service model. Rather than presenting specific scheduling and admission control algorithms which must be supported, these requirements will likely take the form of behavioral tests which measure the capabilities of routers in the integrated services environment. This approach is used because no single algorithm seems likely to be appropriate in all circumstances at this time. The working group will coordinate with the Benchmarking Working Group (BMWG).

We expect to generate three RFCs as a product of performing these tasks.

An important aspect of this working group's charter is in coordination with the development of IP Next Generation. The working group will be reviewed in November 1995 to determine if it should be re-chartered as is or modified to reflect IPng developments, in particular, but also operational and commercial developments. The IESG deems the great significance of this working group to merit this unusual review.

In addition, because many of the integrated services concepts are new, the working group may produce Informational RFCs explaining specific algorithms that may be appropriate in certain circumstances, and may host some educational meetings to assist both IETF members and members of the larger Internet community to understand the proposed enhancements to IP.

The working group proposes to hold regular meetings beyond those held at the IETF meetings.

APPENDIX - Integrated Services Working Group Management Plan

The general chair is Craig Partridge (BBN). The co-chairs are Dave Clark (MIT), Scott Shenker (XEROX), and John Wroclawski (MIT).

The dual reasons for this management structure are:

(1) The working group will have do considerably more outreach into the larger networking community than the typical IETF working group. For instance, one of the important tasks is to convince the larger public that IP is suitable for integrated services. So we need management manpower to do outreach.

(2) The working group has a lot of work to do and swiftly. Even though we plan to spin off working groups as fast as we can, a lot of key architectural decisions will need to be made in one place (e.g., by this working group) if the final architecture is to be sound. So we need management manpower just to keep the working group moving.

So Craig has primary responsibility for keeping the working group moving, and Dave, Scott, and John have primary responsibility for outreach to different communities (and titles sufficient to show they can speak for the working group).

Goals and Milestones:



Seattle IETF: First full meeting of working group. Discuss proposed service model. Discuss strategy for addressing other issues.

Nov 94


Submit Informational RFC on service model. Discuss initial draft documents describing router requirements and strategies for behavioral testing. Hold coordination meeting with RSVP Working Group (and perhaps others as well) to discuss Application (end-to-end) PI.



Continue discussion of router requirements. Develop experimental verification of behavioral testing approach. Continue discussion of API and subnet models.

Nov 95


Submit API. Working group charter will be revised after a working group review managed by the area director, then submitted via the normal chartering process for approval.

Nov 95


Submit router requirements document for publication as an RFC.

Jun 96


Submit subnet document for publication as an RFC.


Request For Comments:







Integrated Services Management Information Base using SMIv2



Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2



General Characterization Parameters for Integrated Service Network Elements



Network Element Service Specification Template



The Use of RSVP with IETF Integrated Services



Specification of the Controlled-Load Network Element Service



Specification of Guaranteed Quality of Service

Current Meeting Report

Minutes of the Integrated Services (intserv) WG

Meeting notes by Rob Cheng and Allison Mankin, thanks! Edited by John W.

John Wroclawski began the meeting with a brief presentation of the agenda and proposed goals.

Goals of the Meeting:

1) Understand what problem or problems each proposal is trying to solve.

2) Understand areas of commonality and disagreement in the proposals
3) Work towards agreement on a plan for moving forward


Presentations from:

Dave Clark (for himself, Kathie Nichols, Lixia Zhang, and Van Jacobson)
Paul Ferguson
Juha Heinanen
Jean-Yves Le Boudec
Zheng Wang
Kilkki Kalevi
Steven Blake


Speakers were asked to describe what they thought should be done now, what might be done later, and what was not necessary, as well as describing their own proposals.

I. Presentation by Dave Clark: "A Combined Approach to Differential Service in the Internet"

Slides from Dave's presentation are available at:


Notes from Dave's talk:

Goal of talk is to describe a framework that can help distinguish between _mechanisms_ in the routers and the range of _application_services_ that can be built from them. Specifically, describe a combination of the two schemes ("Van's" and "Dave's"). Bottom line: they can be used together.

Proposal for action: Identify and agree on some _mechanism_ (routers and hosts)


What is inside the box (router/host) is called a _mechanism_; the mechanism has a specific (hop-by-hop) _behavior_. The user of the network (could be an end-user or a subsidiary network) obtains an (end-to-end) _service_, which can be obtained by using the mechanisms following certain _rules_. Mechanisms can operate, and rules can apply, at several places within the network:

1) router: mechanism controls scheduling during congestion.
2) boundaries between networks: mechanism verifies usage patterns, tags, shapes, logs, enforces rules.
3) end nodes: generate/sink traffic, mark traffic according to profile.

Two points:

1) The (hop-by-hop) _behavior_ of the mechanism is NOT the same as the (end-to-end)_service_ given to the user.
2) User-visible services are NOT the ONLY objective (e.g., network mgmt.)

Idea/concept: Profile meters at the edge, inside a network cloud no checking.

Specifics - some examples of using mechanisms according to rules to obtain a service:

Router Profile Meter Resulting Service

Q w/ higher Token buffer w/ constant Emulate fixed capacity circuit
Priority (Van) rate output (not same as the mechanism

Q w/ RIO Tags packets In/Out Allocated capacity profiles
Dropper (Dave) based on Profile

Same Host tagging of Application-controlled
hierarchical video drop preference

Same Classification based Favoring of selected traffic during
on addresses overloag (not e-2-e, but local
intra-ISP management)

(Note the last three service examples result from different use of the same mechanism.)

Conclusion for mechanisms:

Point: Need to more tightly specify a per-hop mechanism, in order to build a _range_ of services from it. Might be able to be less specific if the mechanism is only to be used to provide one service, but that is not (Dave's) goal.

(Ed: A later discussion spent some time on the distinction between mechanism and behavior; and whether it was possible to sufficiently tightly specify a behavior in a mechanism-independent way.)

Multiple roles of traffic meters:

Two views of how to use bits in packet headers:

1) bits describe some end-to-end goal (e.g. "lower delay")
2) bits _select_ or _control_ per-hop mechanism(s) used as building blocks. (Dave's proposal)

Advantages of 2)

Disadvantages of 2)

"Aggregate and Forward" instead of "Segregate and Bill" model.


II. Presentation by Paul Ferguson: "Simple Differential Services: IP ToS and Precedence, Delay Indication, and Drop Preference"

Slides from Paul's presentation are available at:


Notes from Paul's Talk:

How drop preference might be used:

How delay might be used:

What problems should we be trying to solve?

Work on NOW:

Work on LATER:

Out of Scope:

Questions Paul would like to raise for discussion:

III. Presentation by Juha Heinanen: "Use of the IPv4 ToS Octet to Support Differential Services"

Slides from Juha's presentation are available at:


Notes from Juha's Talk:

Problem: ISP Requirements

What should be standardized?
What _Types of Service_ are to be supported?
How many levels of drop preference are needed to indicate packet importance within a Type of Service?


Possible Extensions:

IV. Presentation by Jean-Yves Le Boudec: "Scalable Reservation Protocol"

Slides from Jean-Yves' presentation are available at:


Notes from Jean-Yves' talk:

Objective: _Scaleable_ Reservations (no per-flow state info. in routers).

SRP offers "sticky network" service, best effort -> reservations may fail.

Four key technical features:

1) Routers keep track of _total resources reserved_ only.
2) Routers learn about reservations "on the fly"
3) *End systems cooperate*
4) No out-of-band signaling

Protocol uses packets of 3 types (2 bits needed in header):


How does it work?

V. Presentation by Zheng Wang: "Scaleable Service Allocation for the Internet"

Slides from Zheng's presentation are available at:


Problems with current Internet:

Problems with per-session reservations:

Diff-serv "in between" best effort and per-session reservations (BE: no isolation, DS: aggregated resource management, Per-session reservation: per flow isolation)

What are we trying to achieve?

Important Questions:

Problems with single profile-based tagging: edge control

VI. Zheng's Proposal: User-Share Based Differential Service

You can buy

You get (contract)

System considers two things:

Application/user can select policy, packet preference within share.


VII. Presentation by Kilkki Kalevi: "Why Should we Reserve Three Bits for Drop Preference"

Slides from Killki's presentation are available at:


Notes from Killki's talk:

Goals of Diffserv work:

Why 3-bits for drop preference?

3 DP bits

3 bits: granularity, flexibility, dynamics, scalability avoids need for signaling/reservations.

VIII. Presentation by Steven Blake: "Packet Marking"

Slides from Steven's presentation are available at:


Notes from Steven's talk:

Model is services implemented by components:

Intserv and Diffserv differ in service allocation policy:

(Sees this as an artifact of lack of customer signaling, not necessarily need for aggregation of state.)

Service assurance

Level of assurance possible is dependent on stat-mux gain that allocator is trying to achieve

Static, domain-wide services must be conservatively allocated (for high assurance) because of lack of knowledge.

Dynamic or destination specific services can be allocated more aggressively


Hypothesis 1 - wide range of allocation time/space scales will be needed, offered)

Hypothesis 2 - packing efficiency can be improved if resources are explicitly provisioned for each time-pace allocation (I think this means that if you use whatever detailed information is available you can pack better).

Conclusion - router differentiation model should evolve to a variant of class-based queuing.

This was the last presentation. The meeting moved to discussion. As a discussion starter, John Wroclawski presented a strawman proposal for a work plan and timeline for moving forward:

++ Now

Start work from the model of bits in the packet header selecting a queuing mechanism (or "action" or "behavior") taken at a router and a parameter or argument to the action.

Begin writing a framework document:

++ ~Late February 1998

Framework document nearing completion. Hold an interim meeting to discuss the framework document, and to begin work in two technical areas:

1) Begin considering details of bit allocation for diffserv within the TOS byte.

Need to consider:

2) Begin selection and description of a small number of initial standard router actions

++ April 1998 IETF

Present and discuss work in progress in the two areas above.

++ August 1998 IETF

Present and discuss documents resulting from work in the two areas above. Goal is that initial versions of these documents be nearing publication.

++ ~August/September 1998

Review status of longer-range diffserv research and implementation outside the IETF, and consider whether IETF WG should do something more based on that research.

Examples of topics that might be appropriate to take on at this time include:

++ December, 1998 IETF

Present initial work on any new topics taken on by the WG as a result of the August work review.

A general discussion then began.

(ed: I tried to mark the start of a thread with a Q and the followon comments with A's although the discussion wasn't strictly question-and-answer...)

Q. (Mark Garrett): What's the service model: are concrete mechanism mapped to the concrete applications they are to support?

Q. (Jim Boyle): Are you talking about standardizing queuing algorithms?

A. (Dave Clark): There's a spectrum. Intserv specified hop-by-hop router behaviors that provided a single end-to-end service, kept spec as loose as possible. Here I'm suggesting specifying a set of building blocks that can be used for new purposes over time - may need tighter spec.

An algorithm in C code-------------------------very loose specification (like controlled load). Somewhere in the middle here (like TCP congestion control algorithm development).

A. (Paul Ferguson):

I disagree with this standardization; keep it SIMPLE!

A. (Dave Clark): It's easy to say simple-sounding things, like "a drop-level corresponds to a particular queue threshold to start dropping", and find underconstrained specification results in wildly unworkable behaviors. "Simple" argument is important but should not go to the point of making Building Blocks useless. The hard question for me is - how much must we constrain semantics? -> get the right BEHAVIOR

Q (Christian Huitema): We should not assume that once we write a spec that people will do the right thing, and therefore it is going to go right out there. Need market forces to make it work! What is in interfaces that market forces can play on:

NOT the queues, interior of routers.... WG needs to find technical mechanisms that allow market forces to play.

A. (Jon Crowcroft) difference between intserv and diffserv is that diffserv is after we got smarter about pricing. Result of Brian's BOF. Other part of the diffserv origins is the aggregation problem, and we use the bits there again, though it's very different. Details might be wanted at edges [+ cloud borders] only.

A. (Ed Elleson): diffserv already in commercial nets (SNA) - priority and bw allocation to prevent starvation. Consider deployment of diffserv a migration problem, and include customer bw alloc, which Dave has done but some others not. Use mechanisms already in routers for both edges and cores, because networks won't have profile meters around them everywhere quickly. Review what we can do now and make a migration part of our thinking.

Q. (Matt Mathis) I question the use of the word "mechanism." Do you really mean "a specific implementation/algorithm" or "a detailed behavior spec"? I think we'd really like a hop-by-hop _behavior_ spec for routers and traffic meters, but we don't quite know how to do it: thus we will spec mechanisms.

A. [ Many nods of agreement]

A. (Jim Boyle) Hard to look at services directly, only examples.

Q. (Yoram Bernet, Microsoft): background points for emphasis - don't lose sight the value of RSVP as a signaling protocol from applications. Large numbers of hosts will be able to do this [RSVP is big in WinNT 5.0]. Hosts might also set diffserv bits based on feedback from RSVP.

Q. (Mike O'Dell): as a person building net services, not thinking about how to think about doing it, I have several points: nothing about what's inside the net makes sense. I want two things:

Don't tell me what to do, instead tell me what the user in some broad simple sense is looking for! Mental image is like a mime-type and a graded service within the type, 2 bits worth would be useful. Traffic types: probably need 16 bits. Use flow-id in IPv6 or reencapsulate in IPv4. Apps can easily say these categories.

A. (Allyn Romanow): grade of service _and_ type, why?

A. (Mike O'Dell) because they're orthogonal. E.g., highly important 6.9K voice versus don't care 6.9K voice.

A. (Dave Clark): I'm uncomfortable with the bits in header that specify application classes:

A. (Mike O'Dell): turning knobs to get your behavior...some of them will make your $ signs bigger, so that's OK. Sensitive to DDC's second concern, but it's a very limited subcase of the general problem. It doesn't go away if you don't type packets.

Q. (Wil Leland): multiple models in play here. Need some commonality enhancement.

Q. (Jack Houldsworth): ISO ECTS joint-authoring work on similar problems with ITU-T. Will send pointer to list, but it's an ID. Feel free to ignore its mcast contents.

Q. (Yoram Bernet): (to DDC) Don't assume end-systems are trusted. End-systems knowing/saying packet (application?) type is not what I had in mind either. I want something more abstract than a type tag.

Q. (Sally Floyd): Could talk about mechanism or whatever for some time. Propose to ratify John's schedule and milestones. We may have more common agreement than the last 1/2 hour might suggest.

At this point the meeting was past closing time. The IESG Area Director asked for a closing comment:

(Scott Bradner): We need help in deciding how this goes next. We have a number of mechanistic ways to proceed, from declaring it out of IETF bounds, to charting a new WG, to rechartering this one, to baying at the moon...Please catch Scott as the AD and give your opinions.


A combined approach to differential service in the Internet
Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop Preference
Use of the IPv4 ToS Octet to Support Differential Services
Packet Marking
Scalable Reservation Protocol
Why Should we Reserve Three Bits for Drop Preference
Scaleable Service Allocation for the Internet

Attendees List

go to list

Previous PageNext Page