2.7.3 Integrated Services over Specific Link Layers (issll)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98

Chair(s):

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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>

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.

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the Integrated Services Over Specific Link Layers (issll) Working Group

Minutes recorded by Eric Crawley. Editing by Eric and John Wroclawski.

Eric Crawley started off the meeting with a quick recap of the status of the current documents. The ISATM document set is ready to go to the IESG, after some minor editorial revision at the request of the Area Director. Documents to be sent to the IESG are:

draft-ietf-issll-atm-framework-03.txt (Informational)
draft-ietf-issll-atm-imp-guide-04.txt (Best Current Practice)
draft-ietf-issll-atm-imp-req-03.txt (Proposed Standard)
draft-ietf-issll-atm-mapping-06.txt (Proposed Standard)

For the IS802 document set, the SBM draft (draft-ietf-issll-is802-sbm-06.txt) has passed last call and will be sent to the IESG shortly as a Proposed Standard. The IS802 Framework (draft-ietf-issll-is802-framework-04.txt) has been revised and is ready for a mini working group last call. It has been last called in the past but reworked since. It is expected to go forward as an Informational RFC. The IS802 Service Mapping document was a topic of discussion later in the meeting.

Carsten Borman gave an update on the ISSLOW documents:

· The ISSLOW Framework document (draft-ietf-issll-isslow-03.txt) is ready to go forward to the IESG as an Informational RFC.
· -The RTF document (draft-ietf-issll-isslow-rtf-02.txt) is ready for WG last call.
· The MCML document received some comments from the PPPext WG that does not affect the protocol but affects the negotiation. Also, the PPPext WG requested that prefix elision be put into a separate draft. Carsten is going to rework the MCML document based on this feedback and discuss the matter on the PPPEXT mailing list. PPPEXT agrees to complete the discussion by April 20th.
· The ISSLOW Service Mapping document will be discussed later in the meeting.

After the conclusion of WG last calls and discussion with PPPEXT about MCML, the framework, RTF, and MCML documents will be sent to the IESG as a group, shortly after April 20. The service mapping document will likely not be ready at that time.

Andrew Smith next discussed the IS802 Service Mapping draft. This draft discusses the mapping of Guaranteed Service and Controlled Load Service to 802.1p. Previous versions of this document mapped the IntServ G and CL services onto different priority classes, but substantial technical concerns have been raised with this approach. Andrew presented a revised approach that maps 802 priorities only onto delay classes. The type of service provided (G or CL) is dependent on the admission control algorithm used and the ability of the switch to provide the G service parameters (C and D).

The proposed classes look like:

0 - Best Effort
1 - reserved (less than best effort)
2 - reserved
3 - reserved
4 - Admission Controlled Long Delay
5 - Delay 100ms
6 - Delay 10ms
7 - Reserved (network control)

There was a good bit of discussion around this proposal and many of the issues will be addressed in the next round of the draft. An early question was where controlled load fits in this scheme? Different CL flows can be mapped into one of these delay bounded categories. Admission control will map the flow into one of these classes based on the TSpec. There was a question about the delay values chosen and whether they make any sense for voice traffic. Discussion concluded that the values are somewhat arbitrary and are really a function of the local requirements. The 10 and 100ms values are examples. Andrew will clarify this issue in the document. There was a question about the possibility of using one of the reserved values for something like DiffServ drop preference. Since there is no drop-preference in the 802.1p spec, it was hard to chose something at this time but some values are reserved for future use and when 802.1 comes up with a suitable behavior. The consensus was that this proposal was worthwhile and should be moved forward.

Steve Jackowski gave an update on the ISSLOW Service Mapping document. The last version of the document elicited no comments from the WG. There were recent comments from co-chairs that will be reflected in the next version of the draft. Steve went through the list of changes requested by the chairs. Several changes were editorial in nature. It was requested that the mapping for multiple levels use something similar to the IS802 mappings. There was a suggestion that perhaps this sort of mapping be moved to a common document but this was put off until it was shown that the sections were actually common enough.

John Wroclawski asked for a show of hands of people who had been implementing ISSLOW and there were some responses but not many had implemented to the current specification. There was further discussion about the minimum number of priorities needed to get reasonable application performance using ISSLOW. Obviously, this depends on your application requirements but some had done work with as few as two priorities.

The final discussion in this area centered around the topic of "fudging TSpecs" to indicate compression gain in admission control. This is a difficult topic that no one had good answers to at the moment. The group decided to delay addressing this topic to a later draft. With this exception, Steve will incorporate the points raised in the meeting into a new version of the draft.

Slides used at the meeting are available at the ISSLL ftp site:

Eric's overview and administration slides:
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/issll-admin.ps
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/issll-admin.pdf
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/issll-admin.ppt

Andrew Smith's IS802 status and service mapping slides:
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/is802.ps
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/is802.pdf

Steve Jackowski's ISSLL service mapping slides:
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/isslow-mapping.ps
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/isslow-mapping.pdf
ftp://mercury.lcs.mit.edu/pub/issll/IETF/LA_9803/isslow-mapping.doc

[Editor's Note: The slides listed above are also available in this working group's slides section of these proceedings.]

Slides

ISSLL Agenda
ISSLOW Service Mapping : Proposed Changes (PDF file)
ISSLL Working Group IS802 Status (PDF file)
Instantaneous Packet Delay Variation (PDF file)

Attendees List

go to list