2.7.3 Integrated Services over Specific Link Layers (issll)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.


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

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: 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 documents 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.


No Request For Comments

Current Meeting Report

Minutes of the ISSLL Working Group Meeting

[Note: In general, the URLs given in these minutes for slides reference versions in Adobe Acrobat (PDF) format. For most of these, the material is also available in Postscript and/or Microsoft PowerPoint format (with .ps or .ppt substituted for the .pdf in the URL.]

Reported by Jim Binder, Eric Crawley, and John Wroclawski

First Session: Monday August 11, 1997 0930-1130

Eric Crawley started the meeting with a quick review of the agenda. Some agenda items, notably the discussion of the ATM Service Mapping draft were moved to the second session due to participant schedules.

John Wroclawski gave the status of the ISATM documents. The framework, implementation requirements, and implementation guidelines documents will be reviewed in detail later in the meeting. These documents and the service mapping document are all expected to be ready for WG last call shortly. They are:

· draft-ietf-issll-atm-framework-00.txt
· draft-ietf-issll-atm-imp-req-00.txt
· draft-ietf-issll-atm-imp-guide-01.txt
· draft-ietf-issll-atm-mapping-03.txt

John also talked about new work areas for ISATM. Two of these will be discussed in more detail later; these include the use of multicast servers (MARS/MCS) and support for the use of shortcuts with NHRP. A third item that has been asked about is work to reconcile ISATM with updates and changes in the ITU-T standardization of ATM.

Dave Oran gave a quick status of the ISSLOW documents. See <ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isslow_stuff.pdf> for more details of Dave's presentation. Some slides were also used from Carsen's previous ISSLL presentations available in <ftp://mercury.lcs.mit.eu/pub/issll/IETF/memphis_9703/isslow4.pdf>

Three ISSLOW documents are ready or nearly ready for WG last call. They are:

· The framework document, draft-ietf-issll-isslow-02.txt
· The MultiClass MultiLink draft, draft-ietf-issll-isslow-mcml-02.txt
· The RealTime Framing draft, draft-ietf-issll-isslow-rtf-01.txt

Of these, the first two are thought to be done and will be WG last-called shortly after the IETF. The realtime framing draft is being presented to the PPPExt group for their input and consensus.

The service mapping draft, draft-ietf-issll-isslow-svcmap-00.txt, is further away from last call and in need of comments from the WG.

Andrew Smith gave an update on the IS802 work. The framework document, having passed WG last call, was rejected by the IESG for a number of minor reasons. However, there has been discussion of moving some information in the service mapping draft into the framework draft. This will be discussed with the draft authors and the chairs. The service mapping and Subnet Bandwidth Manager (SBM) drafts were to be discussed later in the meeting.

Andrew also discussed the status of the IEEE 802.1p work, which is nearing completion. Products are expected shortly that implement the developing standard.

The meeting then moved to presentations and discussion of specific works in progress.

I. IS802

Raj Yavatkar talked about the new SBM draft (draft-ietf-issll-is802-sbm-04.txt). Slides are in

Major changes include:

· Message processing rules and election processing moved into one place
· Clarification on the use of reserved multicast address
· Addition of a Traffic Class object as per the IEEE 802.1p draft (and service mapping draft)
· Added MAC level information to SBM-specific objects
· Added an implementation guidelines section

Raj went over the multicast address issues as well as the new traffic class object. The merging of TCLASS objects uses the *lowest* priority value of the ones received. This is different from RSVP merging but Raj explained that this works better in IEEE 802.1p networks.

There was a question about where to set the user_priority and why put it in the PATH message. The user_priority is set by SBMs but putting it in the PATH message allows SBMs to give "hints" on the user_priority to downstream SBMs. The designers offered to think about the need for putting the user_priority in the PATH message a bit more.

In response to a question, it was noted that all L2 addresses are encoded using the IEEE 802 canonical encoding.

Open issues:

· Non-SBM nodes: reserve resources in different partitions or requests are resolved dynamically through a common BW allocator.
· SBM transparent nodes: all messages work but the efficiency is lower because there is no separation of the physical segments
· Some non-DSBM clients: Either require everyone to use SBM or a common allocator.

There was a question on a DSBM with different sized segments. The DSBM must know the segment sizes it is working with.

Further open issues:

· Only using raw IP mode for RSVP, no UDP encapsulation. Is this a problem?
· I_AM_DSBM messages contain both L2 and L3 addresses.
· Raj made a request for any further open issues that folks had. None were raised.

Next, Andrew presented the IS802 Service Mapping draft (draft-ietf-issll-is802-svc-map-00.txt). See ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/is802-svc-mapping.pdf> for the slides. Andrew went over the goals and assumptions for the IS802 service mappings and the changes to the document. There was a good deal of background material presented on the IEEE 802 networks and their characteristics as well as architectural information on implementing IntServ in 802 environments.

There was a question about the applicability of the service mapping draft to other 802 networks, such as 802.14 and MCNS for cable modems. This is likely to be an entirely different area within ISSLL.


Carsten Bormann went into more detail on the RTF draft (draft-ietf-issll-isslow-rtf-00.txt). He marked up some previous slides from Memphis <ftp://mercury.lcs.mit.edu/pub/issll/IETF/memphis_9703/isslow4.pdf>.
He briefly reiterated the requirements and the two complementary approaches (fragmentation and suspension) being developed. Fragmentation is easiest to implement while suspension yields the lowest latency. The challenge is to define a scheme that allows both to interoperate. Even with header compression, the headers are still big. The RTF frames increase the sequence number size through a borrowing of bits. They also steal bits for added classes. There is a 25% expansion, max, from stuffing for the FSE byte.

The author of the ISSLOW service mapping draft (draft-ietf-issll-isslow-svcmap-00.txt), Steve Jackowski, was not able to be at the meeting so no update was presented. However, Carsten and Dave Oran brought up a few issues with the document that will be discussed with the author.


Eric Crawley presented the status of the ISATM framework doc (draft-ietf-issll-atm-framework-00.txt). Slides are available in <ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isatm_framework.pdf> Eric explained purpose of the document and the sorting of the issues into "solved" and "unsolved" problems. Indicate clearly what things are not addressed in this round of work. The current document is the merger of two previous documents, draft-crawley-rsvp-over-atm-00.txt from February 1996 and draft-ietf-issll-atm-support-02.txt from March 1997.

Eric noted that more editing was needed to update some obsolete text and remove some redundant bits. There are also a few comments that have been received and need to be incorporated. A new version is expected soon and should be ready for WG last call.

Second Session: Wednesday, August 13th, 1997 0900-1130

Lou Berger presented his drafts on ATM Implementation Guidelines & Requirements (draft-ietf-issll-atm-imp-guide-00.txt and draft-ietf-issll-atm-imp-req-00.txt). His slides can be found in <ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isatm_guide_req.pdf>

Lou indicated that his drafts were drawn from draft-ietf-issll-atm-support-02.txt and that there is one major open issue: Can RSVP control messages be sent on the data VCs? The current text allows for control messages to be sent on both data VCs and their own VCs.

After some discussion, a consensus emerged that RSVP control messages MUST NOT be sent over a QoS data VC, so that implementations could "switch" the QoS VC without having to look for control messages in the data flow. RSVP control messages can be sent over a best effort VC or their own control VC. The documents will be changed to reflect this view.

A discussion of error detection and recovery ensued. The room agreed that it is important that the RSVP data and control VCs have some form of "fate sharing" for detecting errors, to avoid useless dangling VC's. There was no agreement on the need for a single specific mechanism to support this, it was seen as a need that could be met in a number of ways.

Roch Guerin presented on the ATM Service Mapping draft (draft-ietf-issll-atm-mapping-02.txt) for Mark Garrett, who was unable to attend the meeting. Roch's slides can be found in <ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isatm_mapping.pdf>. Mark had made some last updates before WG last call. Sections 2.5 and 2.6 have been revised and there are new sections on path characterization and handling non-conformant traffic. WG participants are requested to check the expanded mapping tables and the unit conversions.

Additionally, for the handling of excess traffic, there is now consistency between Sections 2.2 and 3.2. We want to ensure preferred behavior (no-reordering) vs. tolerable behavior (reordering).

Mark requests comments promptly, and plans to have a revised version of the document available in September.

This concluded the discussion of current drafts. The remaining presentations were on upcoming work items for the WG.

Roch Guerin initiated a discussion on support for shortcuts for RSVP flows over ATM. The slides for this presentation can be found in <ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/shortcut.tar>. I-D draft-guerin-issll-rsvp-shortcut-00.txt further discusses the proposal.

Note: The tar file in the URL above expands to a set of html and GIF files that form a web-based presentation. There is no other version of this material presently available.

The purpose of the draft was to identify issues for shortcuts for ATM flows, define requirements and guidelines for interoperability (internally and externally). Design issues: maintain consistent shortcuts for RSVP data and control messages. There is a need to consider several scenarios. There are several error conditions that must be considered; best effort shortcut failure, shortcut QoS VC fails, shortcut QoS setup failure during renegotiations. There was a consensus to continue this work.

Steve Berson then gave a short presentation on the issues for QoS ATM MultiCast Servers (MCS) with MARS. His slides can be found in <ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/mcs.pdf>.

The Problem: MARS does not indicate whether a Multicast Server or mesh approach is in use, but MCS does not provide QoS support.

Three possible solutions:

· Declare that Thou shalt do VC mesh in ISATM networks.
· Change MARS to indicate whether mesh or MCS is being used.
· Put QoS into the MCS.

There was some consensus that the group should do more work on this issue.

Richard Woundy gave an overview of the issues for IntServ over Cable Modems (ISCABLE) [Sorry; formatting problem. Slides available soon; availability announcement will be sent to the issll mailing list]

Rich gave a quick overview of cable modems and MCNS. There are some upstream traffic variations:

· Requests can be piggybacked to data
· CMTS generates allocation MAPs with "unicast" request intervals (useful for Controlled Load?)
· CMTS generates allocation MAPs with "unsolicited" data grants but there are min/max packet size issues, and bursts

There will need to be split efforts for MCNS/POCIS and IEEE 802.14

· Different MAC protocols; cells vs. frames
· Share information for frame-based services
· Define dynamic SID messages format, RSVP interaction
· Enable controlled load and guaranteed services

There are interesting issues for policing. Rich asked for volunteers to work on this effort.

The general meeting broke up at this point. The ISSLOW subgroup, under the direction of Dave Oran, used the remaining time to discuss some issues particular to their work.

Dave Oran gave a PPPExt status update:

Steve Casner presented the compression draft (again). A new draft is in process to address issues. There will be a reduction in the number of options. Dave made a request for comments on the ISSLOW drafts from the PPPext participants.

Fred Burg gave a presentation on the overhead for processing of MCML & RTF formats. Fred's presentation can be found in: <ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/pre-emption-concl.pdf>.

Fred looked at RTF and MCML for type 1 and type 2 in terms of available bandwidth after voice processing (28K modem speed, no prefix ellision, 1 vox stream, 1 data stream, 1 link in bundle, packetization rule per 4/97 draft revision of RFC1890.) They looked at the BW left for data in 1 second after voice has gotten its share with no delay. Partial results indicate that RTF is better at keeping delay low than MCML/S2 by 7-25%. Compressed RTP is necessary.

Next there was a discussion of the service mappings document. Dave Oran commented that the author, Steve Jackowski has received some comments and is planning to put them in a revised draft. There was some discussion of the effect of varying rates in V.34. There was more discussion on how to incorporate the influence of header compression gain. The problem is that the compressor is not part of the application so it has to give "advice" to the flowspecs (actually, TSpec) to indicate the compressibility of the header data.

Next Steps for ISSLOW were discussed. Dave would like to wrap up by the next meeting. The Framework document will go to WG last call. The MCML document will wait for comments from PPPext and go to last call in September. The RTF document will do the same with longer a timeout; last call in October. The Service Mapping document will get a new draft by September and address open issues. It should be discussed in December with a last call afterwards.


None Received

Attendees List

go to list

Previous PageNext Page