2.7.5 Integrated Services over Specific Link Layers (issll)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 24-Jun-99


John Wroclawski <jtw@lcs.mit.edu>
Eric Crawley <esc@argon.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:issll@mercury.lcs.mit.edu
To Subscribe: issll-request@mercury.lcs.mit.edu
Archive: ftp://mercury.lcs.mit.edu/pub/issll/mail/

Description of Working Group:

The ISSLL Working Group defines specifications and techniques needed to implement Internet Integrated Services capabilities within specific network technologies.

The Internet Integrated Services design, developed within the IETF by working groups such as INTSERV and RSVP, specifies extensions to the IP architecture which allow applications to request and receive a specific level of service from the internetwork, as alternatives to the current IP best-effort service class. The work of these groups has resulted in technology-independent protocols and specifications. Focused engineering work to define the mapping of these universal specifications onto specific subnetwork technologies is now required.

At minimum, the following points must be addressed for each candidate technology:

- Service mappings. Service mappings define the way that the link layer technology is used to provide a particular IntServ traffic management service, such as controlled-load or guaranteed-delay.

- Setup protocol mappings. Setup protocol mappings define how an internet- level setup protocol such as RSVP is implemented or mapped onto the link layer technology.

- Adaptation protocols. Adaptation protocols are used to augment the native capabilities of the link-layer technology, when this is necessary to support required Integrated Services functions.

- Statements of non-applicability. Statements of non-applicability describe which Integrated Service capabilities are not supported by the link layer technology under consideration.

The ISSLL WG will carry out this work for all technologies with perceived market demand and of sufficient interest to its members. To ensure timely progress on each work item the WG will employ an administrative structure based on technology coordinators, as described below. The WG expects to coordinate its activities across technologies whenever technical commonality between layer two media is apparent. The WG chairs hold primary responsibility for this coordinating role.

WG Outputs:

The WG is expected to produce standards-track RFC's, informational RFC's and "best-current-practices" guidelines, as required. The need for standards-track RFC's is limited both because the work of the group is focused on the engineering of existing protocols to existing link layer technologies, and because in certain cases information and guidelines will better serve the needs of a rapidly evolving technology.

Operational Structure:

Due to the scope of the task and the need for parallel progress on multiple work items, the WG effort is organized as follows:

A technical coordinator will be identified and selected for each media technology adopted as a work item by the group. This person will be responsible for coordinating the technical efforts of the group with respect to that media, working with and motivating the document editors, and evangelizing the group's work within the community and relevant external organizations such as the IEEE and ATM Forum.

Since many link layer media continue to evolve, and since that evolution may be influenced by the work of the ISSLL WG, it is expected that each technology work item will be divided into short term tasks, medium term tasks, and ongoing monitoring, as follows:

- Short term tasks focus on using the existing technology as best as possible with no changes whatsoever. This work will accept whatever limits are imposed the link-level and IP-level technology, with the goal of creating the best solution possible within a 6-9 month timeframe.

- Medium term tasks focus on planned changes to the technology that are currently being standardized and may not yet be widely available Ideally this work would conclude just as the changes become available in the market. In general a 1-1.5 year timeframe is appropriate for these tasks.

- Monitoring focuses on tracking and advising on changes being made by others to a link layer technology, to allow it to better support the Integrated Services models and protocols. Generally, these efforts would be conducted as informal activities, rather than work items within the WG structure. The exception would be when formal cooperation between the WG and an external effort was required.

In addition to the normal responsibilities of IETF working group chairs, the ISSLL chairs hold primary responsibility for selection of coordinators, identifying areas of technical commonality and building cross-technology efforts within the group.

Relationship to Other Working Groups:

The ISSLL WG maintains a close working relationship with the INTSERV and RSVP WG's. Particularly, ISSLL may wish to feed back information about the effectiveness or limitations of RSVP and INTSERV work in the context of a specific technology to these groups for review. ISSLL is also expected to interact with other WG's as needed to aid in the use of particular media (e.g. IPATM, PPPEXT).

Coordinators for initially important technologies:

ATM Sue Thomson, set@bellcore.com Low-Speed Serial Carsten Bormann, cabo@informatik.uni-bremen.de Ethernet Token Ring Wayne Pace, pacew@raleigh.ibm.com Frame Relay Cable Modems

Goals and Milestones:



Submit Internet-Draft of The Operation of RSVP over ATM UNI 3.X



Submit Internet-Draft of Integrated Services over token ring networks (switched and shared with sections on source route bridging, token priority, filtering, etc).



Submit Internet-Draft of Controlled Load Service over ATM UNI 3.x (includes parameter mapping, VC management, and references VC usage guidelines from Overview)



Submit Internet-Draft of Overview of Integrated Services over ATM UNI 3.X (VC management, issues, models, and other service and setup protocol independent pieces)



Submit Internet-Draft of Controlled Load Service over ISSLOW.



Submit Internet-Draft of Realtime Header-compression and packet framing protocol. [Requires close coordination with PPPEXT and AVT.]



Submit Internet-Draft of Guaranteed Service over ATM UNI 3.X (includes parameter mapping, VC management, and references VC usage guidelines from Overview)



Submit Internet-Draft of Controlled Load Service over token ring networks (switched and shared).



Submit Internet-Draft on The Operation of RSVP over ATM UNI 3.X



Submit Internet-Draft on Overview of Integrated Services over ATM UNI 3.X to IESG for publication as an RFC.



Submit Internet-Draft on Controlled Load Service over ATM UNI 3.x to IESG for publication as an RFC.



Submit Internet-Draft of Updates of the documents relate to the ATM Forum 4.0 Specification(s)



Submit Internet-Draft of Updated Overview of Integrated Services over ATM to include Short Cuts and VC Aggregation



Submit Internet-Draft on ATM Forum 4.0 Specification(s)



Submit Internet-Draft on Guaranteed Service over ATM UNI 3.X to IESG for publication as an RFC.



Submit Internet-Draft on dcouments relate to the ATM Forum 4.0 Specification(s)



Submit Internet-Draft on Updated Overview of Integrated Services over ATM to IESG for publication as an RFC.

Jun 99


Submit Internet-Draft on Integrated Services over token ring networks to IESG for publication as an RFC.

Jun 99


Submit Internet-Draft on Controlled Load Service over ISSLOW to IESG for publication as an RFC.

Jun 99


Submit Internet-Draft on Controlled Load Service over token ring networks to IESG for publication as an RFC.

Jun 99


Submit Internet-Draft on Realtime Header-compression and packet framing protocol to IESG for publication as an RFC.


Request For Comments:







RSVP over ATM Implementation Guidelines



Interoperation of Controlled-Load Service and Guaranteed Service with ATM



A Framework for Integrated Services and RSVP over ATM



RSVP over ATM Implementation Requirements

Current Meeting Report

Minutes of the ISSLL WG Meeting - 45th IETF - Oslo, NO, July 15, 1999 1:00-3:00

The WG held one two-hour meeting at the 45th IETF. The first part of the meeting was dedicated to a review of old business status, and discussion of one open IS802 issue, the Subnet Bandwidth Manager MIB. The remainder of the meeting was devoted to discussion of Intserv/Diffserv mapping issues (ISDIFF). The final agenda for this meeting is available as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/agenda.pdf

Old business status:

The chair reported that WG work on the IS802 and ISSLOW primary documents has been completed, and the documents forwarded to the AD and the IESG for comments and IETF last-call.

Subnet Bandwidth Manager MIB:

Andrew Smith presented work in progress on the SBM MIB, draft-ietf-issll-is802-sbm-mib-00.txt. The presentation is available as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Smith_SBM_MIB.pdf
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/smith/index.htm

The major change since the previous version (which was draft-smith-...) is the removal of those MIB variables that were concerned with policy issues. The MIB is now closely focused on the SBM protocol and mechanics.

Andrew's presentation identified several open issues, which are documented on the last slide of the presentation. In addition to these open issues, there is still some uncertainty about the relation of this MIB to other MIBS, including the general INTSERV MIG and the evolving DIFFSERV MIB. Andrew is raising these issues in other WG's as well. Discussion requested on the list.

Yoram Bernet noted the absence of a MIB variable to determine whether an SBM was eligible to participate in the DSBM election. Keith McCloghrie suggested that the "supported but disabled" indicator served this purpose. After some discussion, the meeting concluded that this was inadequate, and two indicators were needed - SBM disabled and SBM enabled but not eligible to be DSBM.

Discussion turned to open issue 3 on Andrew's list: should the MIB allow the creation of new SBM instances? The current MIB only allows configuration of existing SBM instances. After some discussion the meeting agreed on this approach, and the issue is considered closed.

Intserv/Diffserv/RSVP Overview:

John Wroclawski presented a brief review of the ISDIFF topic, to set the stage for the remainder of the meeting. The presentation summarized how a diffserv cloud might be used within the end-to-end intserv model, and how each of the work items to be discussed in the meeting fit into that picture. Slides are avalable as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Wroclawski_isdiff_intro.pdf
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/wroc1/index.htm

Qualitative (Null) Service:

Yoram Bernet presented draft-moore-qualservice-00.txt, a proposal for a new Intserv service that is intended to allow for policy-driven QoS in an intserv or signalled diffserv environment. Slides are available as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Bernet_qualservice.pdf
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/bernet/index.htm

An intserv service request, together with related identity and policy information, can be viewed as a way to say "here's who I am, here's what I want to do, and here's what I need from my end-to-end network path". In the case of Guaranteed service, "here's what I need" is the mathematical delay bound information and strict bandwidth reservation. In the case of Controlled-Load, "here's what i need" is the provision of an unloaded path. In the case of the new service, "here's what i need" is null. The purpose of the service is thus to say only "here's who I am and here's what I want to do". This allows a third-party or policy component to decide what is needed end-to-end, or alternatively to allow each element of the end-to-end path to provide whatever service that element has agreed to provide to the requesting customer.

Discussion after the presentation turned to the question of whether the service should support the ability for the user to provide some information about the desired end-to-end service, such as a delay "hint". In the current draft, this is not supported. A vigorous discussion revealed that the meeting was split into two camps. One group argued that it would be useful for the service to support these non-binding hints, with (numerical) delay as the specific example. The other group argued that non-binding quantitative hints were not particularly useful to applications, that honoring such hints would require more information from the application (in the TSPEC) than was desirable for this service, and that the choice of which hints to support would complicate the process of defining the service too much.

This question was not resolved in the meeting. The draft authors will issue a new version addressing some minor points shortly. Discussion of the open question will be taken to the mailing list.

Intserv/Diffserv Framework Document:

Bruce Davie presented the ISDIFF Framework document, draft-ietf-issll-diffserv-rsvp-02.txt. This document describes the overall framework for use of diffserv clouds as intserv network elements. The presentation is available as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Davie_isdiff_fwork.pdf
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/davie/index.htm

This document has been through several revisions, and is now believed by the authors to be substantially complete. Changes from the previous version include expansion of the sections on service mapping and microflow "isolation" in an aggregate scheduling situation like diffserv, decoupling of the diffserv cloud behavior from any assumptions about end-to-end use of RSVP as a signaling protocol, clarification of issues related to which network component does DSCP marking in different situations, and cleanup of several definitions. The significant missing piece is an adequate discussion of multicast considerations.

Kathie Nichols raised some questions about terminology, and asked whether the model supported concatenating several administratively separate diffserv clouds into a single diffserv region. Bruce said that the intent of the framework was to support this, and agreed with Kathie's suggestions for clarifying this.

Yoram Bernet raised the issue of how configuration of network elements would be done in the framework. This includes not only things like static bandwidth allocation policies, but also more mechanical things like which network element is responsible for DS marking. It was suggested that this configuration was expressed by MIBs and PIB's. The chair asked whether developing the needed MIBS/PIBS should be a WG issue. Fred Baker said that the WG was responsible for all of this work. Keith McCloghrie suggested that the WG might not be responsible for developing a PIB, and pointed out that the RAP working group was doing COPS protocol object definition for controlling things developed in other WG's. Fred said that the IETF now had a policy for all this, but that it was not fully in effect because the work area was relatively new. After some further discussion, the chair tabled the issue. Advice from the AD will be obtained when the question becomes immediate.

DCLASS object: (now draft-ietf-issll-dclass-00.txt)

Yoram Bernet gave a brief presentation on the DCLASS object (no slides). The purpose of the DCLASS object is to carry information from a diffserv cloud to an upstream network element (host, upstream router, etc) that is responsible for setting the DSCP field in the packets it is sending to the cloud. The standard example of how this might be used is to carry DSCP marking information to a host that has made a service request via RSVP, but there are other ways the object might be used as well.

Yoram noted that the major change since the last version of the spec was to allow for a list of DSCP's in the object, rather than a single DSCP. A question was asked about ordering of DSCP's in the DCLASS object, and how it related to the service being provided. A discussion about how diffserv capabilities might be used for different purposes ensued.

The chair suggested that this discussion was important but not directly related to the DCLASS object, and that the object definition spec should be treated as a very low-level, syntactic thing - "here is how DSCP's are represented in an RSVP object". Then, different uses the DCLASS object can impose whatever meaning they need on top of this representation, and define that meaning in the appropriate documents. The WG agreed to this path. A new version of the I-D will be issued with all higher-level semantics removed from the definition. This version will become a WG document (the previous version was draft-bernet...).

Walter Weiss asked whether it would be appropriate to use the PHB identifier format presented by Scott Brim in the Diffserv meeting here, rather than the DSCP. Bruce Davie and others responded that that was a completely different thing, and the purpose of this object was to represent and carry code points, not PHB names. Further discussion was pushed to the mailing list by the chair.

RSVP Aggregation:

Fred Baker presented draft-baker-rsvp-aggregation-01.txt, a document describing in detail the use of RSVP to manage bandwidth on an aggregated basis in a DS cloud. Slides of this presentation are available as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Baker_RSVP_aggreg.pdf
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/baker/index.htm

Fred's presentation discussed different things that can be aggregated (packet classification state, scheduling state, reservation/bandwidth allocation/admission control state) and why it is useful to separate them, presented several motications for this aggregation, and described the mechanisms used to do this with RSVP.

This work has advanced significantly since the previous version of the document was published. The most significant change is that the multicast story has converged. The current draft adopts a mechanism that aggregates classification and scheduling state, but not reservation state. This is because there appears to be no simple way to manage aggregate reservation state for multicast data flows with potentially different topologies except by allowing significant over-reservation of resources, which is unacceptable. Another significant change is the work by the authors and others to bring this draft into as much alignment as possible with the RSVP tunnel draft, which addresses a similiar problem. Several changes have been made, and all remaining differences are now seen to be because of differences in the underlying problems.

Fred reported that with this revision the authors believe that the spec is solid and complete, and ready for broad review. At least one prototype implementation is underway. This work will be published as draft-ietf-issll-rsvp-aggregation in its next version.

Remaining ISDIFF Documents:

John Wroclawski gave a brief presentation about the remaining documents needed to complete the ISDIFF work. Slides are available as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Wroclawski_isdiff_docs.pdf
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/wroc2/index.htm

The documents that are presently seen to be missing are:
- a "service mapping" document, which discusses how to select PHB's and edge actions that cause a DS cloud to effectively act as an intserv network element.
- a standards-track RSVP-use document, which describes any specific interoperability issues that are needed to support use of RSVP to glue DS and other clouds together in this way. A specific issue that was discovered just before the meeting was the need for a DSCP marking negotiation protocol, to determine which network element (DS cloud edge or some upstream device) is responsible for marking packets.

Neither of these documents is beyond a very early stage. The service mapping document in particular will draw from several previously published drafts, but more work is needed. People interested in working on these topics should send email to the list or to John directly.

This completed the discussion of the working group's ISDIFF work items.

Work in Progress:

Nitsan Elfassy gave a presentation of draft-sgai-rsvp-plus-00.txt. This is work in progress by the draft authors and others, presented for the information of the WG. Slides of this presentation are available as:
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Elfassy_RSVP_plus.pdf
- http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/elfassy/index.htm

RSVP-plus is an attempt to place many of the various ways that RSVP and policy engines interact under a single umbrella, and to add some additional capabilities to the RSVP protocol, also controlled by a policy engine. Nitsan noted that some of the issues previously discussed in the meeting, such as the choice of when to use an aggregate reservation versus when to establish a separate per-flow reservation through a cloud, were things that might be controlled by a policy engine, and thus overlapped with RSVP-plus.

One part of Nitsan's presentation reviewed the various actions that might require policy input in the current RSVP/Diffserv/Intserv picture, and discussed why this control was useful.

The larger part of Nitsan's presentation argued that the RSVP model should be modified to remove the end-to-end signaling assumption inherent in the current protocol. Instead, policy engines would be able to decide, in any given case, whether RSVP messages should flow end-to-end or through some smaller portion of the network data path.

This part of the presentation was controversial. An initial question (Raj Yavatkar?) was whether this proposal was to "optimize" RSVP by eliminating the end-to-end message flow in cases where the - appearance- of end-to-end semantics could be preserved, or whether the proposers were suggesting extending the range of semantics of the protocol. Nitsan replied that the proposers were suggesting extending the semantics. Keith McCloghrie suggested an example where a host might not know whether the network policy for a particular service was to give e2e QoS assurance or something else, and thus would want to use the same signaling protocol in either case. Another point raised that the model presented in the talk was essentially sender-oriented, and that the proposal seemed not to consider the receiver-oriented model of current RSVP.

At this point the meeting was 15 minutes past the scheduled close. The chair reiterated that this level of change to the RSVP protocol itself would fall either to the RSVP WG or a newly chartered WG, and suggested that the discussion continue after the meeting. The meeting was officially adjourned at 3:15, though a corner discussion of Nitsan's presentation continued for some time.


Aggregated RSVP
Intserv/Diffserv Intserv/Diffserv Framework
RSVP+: Policy based variations on standard RSVP processing
Qualitative Service
Remaining Documents