2.7.6 Integrated Services over Specific Link Layers (issll)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 01-Mar-99


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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

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:

May 96


Guaranteed Service over token ring [Needs investigation, Dates TBD]

Jun 96


Submit Internet-Draft of Controlled Load Service over ISSLOW.

Jun 96


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

Jun 96


Submit Internet-Draft of describing expectations and procedure for adding a technology to the ISSLL work items list.

Jun 96


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

Jun 96


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)

Jun 96


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

Aug 96


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

Dec 96


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

Dec 96


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

Dec 96


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

Feb 97


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

Feb 97


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

Feb 97


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

Feb 97


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

Feb 97


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

Feb 97


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

Apr 97


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

Apr 97


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

Jul 97


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

Jul 97


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

Jul 97


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

Dec 97


Submit Internet-Draft on Updated Overview of Integrated Services over ATM 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 Working Group
44th IETF in Minneapolis, MN

Co-chairs: Eric Crawley & John Wroclawski
Minutes recorded by: Eric Crawley

The ISSLL WG met for one session on Wednesday, 3/17/99 from 1300-1500, with approximately 150 attendees.

* ISSLOW Service Mapping draft

Bruce Davie presented the updates to the ISSLOW service mapping drafts (draft-ietf-issll-isslow-svc-mapping-06.txt). This is a significant revision in response to comments received on the previous draft. The document was reworked from its original form to be more like the other service mapping documents. There were changes to clarify the behavior for guaranteed service and there is a new section on the "acceptable delay" for Intserv flows. A new section was added on example mappings that is much looser than the example mappings used in the IS802 service mapping document. it is believed that all outstanding WG comments have now been addressed, and the document will be sent out for working group last call just after the meeting. Any comments should be sent to the authors ASAP.

* SBM configuration and policy

Andrew Smith next presented some preliminary work on Subnet Bandwidth Manager (SBM) configuration, for the purpose of introducing the material and asking whether further work on this document should be an ISSLL WG item. The draft discusses a set of manageable objects for RSVP and SBM. As background, Andrew presented a view of the policy model for RAP and RSVP. The decision to admit a flow is divided into two pieces, the portion that determines if the resources are available (Admission Control) and the portion that checks to see if the flow is administratively allowed (Policy). RAP uses the COPS protocol to out-source the decisions on policy. The PDP (Policy Decision Point) needs to be split between the SBM and the policy manager.

Andrew discussed a set of groups of objects that could be managed; RSVP protocol config, SBM protocol config, RSVP Local Policy Module configuration, and SBM Local Policy Module configuration. The draft is more concerned with identifying the objects and information needed, rather than the method of transporting the data to the devices involved.

88. What parameters - level of specificity - should match current defined services/SBM or be more expandable? (see specific issue discussion below)
89. Representation (MIBs, etc.)
90. Fuzzy about the LPM portions (ISSLL may end up owning it because no one else can).

Discussion of specific vs expandable:

SBM policy as presented is based on the number or lower-layer "classes" in use (3 delay-ranked classes for IntServ flows based on the mapping drafts). There was some discussion about the use of 3 classes since these were really "examples" in the service mapping document. It was agreed that an array of classes might be a better representation.

Conclusion of the discussion was that some parts of this are clearly in the scope of ISSLL and should be addressed if WG sees need - which a number of people did. Other parts are less clearly in scope, and may require coordination with other WGs's. No clear allocation of tasks was agreed on. The current working proposal is that we create the parameter list in ISSLL and also do an "SBM MIB" in ISSLL. Some of the RSVP/SBM policy related items configuration and the decision whether to out-source configuration to a policy server probably needs to be a RAP WG item.

*Intserv with Diffserv clouds

John Wroclawski introduced a new discussion on Intserv using Diffserv clouds. He outlined the problem on the table: Diffserv WG to date has focused on building blocs and intra-domain models while Intserv has focused on e2e QoS for applications. It is technically possible and useful to use Diffserv clouds as part of the Intserv end-to-end QoS story. This allows us to keep and benefit from desirable Diffserv properties.

John noted that this is an intentionally narrow problem statement. Particularly, various other e2e QoS approaches have been proposed and are being developed. Also, various people have proposed larger & more general frameworks for QoS that encompass both Intserv and other specific approaches. The goal of the work being discussed here is to utilize the capabilities and technologies that exist today to produce more scalable more deployable e2e QoS services in the short term, without precluding other possible directions in the future.

John proposed the following documents for Intserv over Diffserv:
91. A Framework Document
92. A Service Mapping Document (implementing Intserv services using diffserv PHB's, edge behaviors, and bandwidth allocation rules)
93. BW Management approach documents (static provisioning, hierarchical aggregate RSVP, passthrough RSVP)

This document set is very similar to the approach taken in the ISSLL WG for IEEE 802 and ATM networks - because the goal of incorporating a diffserv cloud as a network element within the Intserv e2e story is very similar to incorporating an 802 or ATM cloud. So the approach should be familar and workable for ISSLL WG participants.

Next, Yoram Bernet discussed presented on draft-ietf-issll-diffserv-rsvp-00.txt.

This draft is based on draft-ietf-diffserv-rsvp-02.txt and is the product of changes made both by Bob Braden and Yoram.

The goal of this draft is to work towards an Internet in which hosts or their proxies initiate reservations for specific services from the network. It is assumed that the diffserv network provides aggregate traffic handling (though it may process either per-flow or aggregate reservation messages).

This enables:

1) Per-flow end-to-end QoS vs. the aggregate edge-to-edge QoS typically associated with diffserv only networks.
2) Scaleability
3) Admission control

The focus of this work is on quantitative applications of the sort handled by Intserv today. Some of the work is also applicable to qualitative applications, but that discussion is deferred.

There are two high level models of the combined RSVP/intserv/diffserv network. In both models, devices at the edge of the network (typically hosts) use RSVP to signal certain per-flow requirements. On the path between the sending and receiving host(s) there are one or more diffserv networks. In one model, devices external to the diffserv network act as admission control agents for the diffserv network by rejecting or admitting RSVP resource requests. In another model, some number of devices within the diffserv network process some form of RSVP signaling to aid in the task of providing admission control.

The first model (no RSVP awareness within the diffserv network) is typically associated with static SLAs and static provisioning within the diffserv network. The second model enables dynamic provisioning within the diffserv network. This may take one of the following forms:

1) Processing per-flow RSVP signaling within the diffserv network.
2) Using aggregate RSVP within the diffserv network (tunnels, RSVP aggregation, possibly MPLS).
3) Providing RSVP interfaces at the edges of the diffserv network and using some form of Oracle or bandwidth broker (tm Van Jacobson) internally.

The draft still needs minor work, as follows:

1) Clean up terminology - use consisitent terms for:
a) RSVP session admission
b) MF classification
c) aggregate classification

2) Possibly, pull in the DCLASS spec.

Yoram also pointed out other related work within the ISSLL WG:

1) Mapping of Intserv services to diffserv and the corresponding admission control considerations.
2) Multicast.
3) Detailed drafts on diffserv provisioning mechansism including aggregate RSVP, tunneling and possibly MPLS.
4) Define edge device functionality to the point of enabling interoperability.

John W. noted that with regard to service mappings (implementation of Intserv services by Diffserv clouds), that the WG can propose new PHBs, if necessary. However, it will be simpler, and may be technically acceptable, to use AF and/or EF, together with appropriate edge behaviors and bandwidth allocation rules, to implement reasonable fascimiles of CL service. G is a little trickier but may be possible as well. John further noted that if new PHB's are proposed the Diffserv WG would be responsible for standardizing them in the IETF, if that was to happen.

Beyond the framework document mentioned above several relevant I-D's have appeared in the recent or more distant past. The ones listed here have dealt with some aspect of using RSVP to manage aggregate bandwidth usage, as might be appropriate when packets are forwarded using DS codepoints.
94. draft-baker-rsvp-aggregation-00.txt
95. draft-ietf-rsvp-tunnel-02.txt
96. draft-guerin-aggreg-rsvp-00.txt (timed out, but still at ftp.ietf.org)
97. draft-berson-rsvp-aggregation-00.txt (timed out, but still at ftp.ietf.org)

Some work is presently underway to combine mechanisms from these drafts into a more broadly based RSVP-aggregation document.

Hui Zhang gave an informational presentation on his work on Per Hop Behaviors based on Dynamic Packet State.

Hui first gave an example to illustrate that in order to achieve worst-case guarantees in current diffserv network, the network utilization by the premium service traffic has to be extremely low.

In an environment when this is not acceptable, alternative solutions are needed. He presented a technique called Dynamic Packet State (DPS) that can support a variety of services including guaranteed service (with mathematically proven worst case bounds), distributed admission service, weighted fair share service, penalty box in a diffserv environment. The key advantage of DPS is that even in a network where core routers do not maintain per flow state, the services provided with DPS can achieve similar flexibility, resource utilization, and assurance levels compared to those that can be provided with per flow mechanisms. With DPS, each packet carries in its header, in addition to the PHB codepoint, some PHB-specific state. The state is initialized by the ingress node. Interior nodes process each incoming packet based on the state carried in the packet's header, updating both its internal state and the state in the packet's header before forwarding it to the next hop. Hui also discussed issues of state encoding and several possible places (IP option, MPLS label) to put the the state.

Several papers describing the algorithm details can be found at http://www.cs.cmu.edu/~istoica/DPS.


None received.