NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Oct-97
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.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 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. |
Internet-Drafts:
· Providing integrated services over low-bitrate links
· Interoperation of Controlled-Load and Guaranteed-Service with ATM
· SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over IEEE 802-style networks
· The Multi-Class Extension to Multi-Link PPP
· A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies
· Integrated Services over IEEE 802.1D/802.1p Networks
· PPP in a real-time oriented HDLC-like framing
· Network Element Service Specification for Low Speed Networks
· RSVP over ATM Implementation Requirements
· A Framework for Integrated Services and RSVP over ATM
· Integrated Service Mappings on IEEE 802 Networks
No Request For Comments
Minutes of the Integrated Services Over Specific Link Layers (ISSLL) WG
Reported by John Wroclawski and Eric Crawley.
The ISSLL WG met for one session from 1930-2200 on Monday, December 8th, 1997. Eric Crawley started the meeting with an overview of the agenda. Slides are available in:
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/administrivia.pdf
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/administrivia.ppt
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/administrivia.ps
Eric went over the list of documents that are currently out for working group last call. In the ISATM subgroup, this includes:
draft-ietf-issll-atm-framework-01.txt
draft-ietf-issll-atm-mapping-04.txt
draft-ietf-issll-atm-imp-guide-02.txt
draft-ietf-issll-atm-imp-req-01.txt
The last call expires on December 22, 1997. There were no comments on the documents during the meeting.
There are two documents from the ISSLOW subgroup out for working group last call. They are:
draft-ietf-issll-isslow-02.txt
draft-ietf-issll-isslow-mcml-02.txt
The last call for these documents also expires on December 22, 1997 and there were no comments.
Dave Oran talked briefly about the ISSLOW RTF and service mapping drafts. The RTF draft got several comments on the last version that were mostly requiring more explanation. Carsten expects to prepare a new version in the next couple of weeks, and believes that this new version will be ready for last call.
A new draft from Stuart Cheshire on Constant Overhead Byte Stuffing (COBS) was brought to the group's attention. This draft deals with packet expansion under byte stuffing, but does many of the same things as RTF. So, there was a request for people to look at both COBS and RTF to decide whether there is sufficient overlap to hold or change the RTF draft.
There was further discussion of the COBS draft, Carsten Bormann pointed out that it is a new form of byte stuffing that is not compatible with existing hardware while RTF is compatible with existing hardware but requires new low-level software and addresses bit-synchronous applications. Carsten also said that COBS is also more targeted at high-speed byte-sync framings. There was discussion about the number of methods available (MCML, RTF, and COBS) being hard to compare and confusing. There was also concern expressed about the ISSLL framework draft that is in last call suggesting that only two framing methods exist, since it is likely that new methods will continue to come out and the framework talks about the "classes" of solution that fit all three methods. This was taken as a last-call comment requiring a very minor edit to the framework document.
Dave Oran then discussed the status of the ISSLOW Service Mapping document. The author was not able to attend and had time constraints for the near future so work that is necessary is in jepardy. Perhaps a new author is needed and a solicitation for volunteers was made.
Next, David Putzolu presented on MCML and RTF Heuristics. (draft-putzolu-heuristic-00.txt) David's slides can be found in:
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/mcml_rtf_heur.ps
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/mcml_rtf_heur.pdf
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/mcml_rtf_heur.ppt
The problem David was looking at was with applications that can use MCML/RTF but aren't RSVP-aware. His implementation idea was to use some heuristics to separate the traffic into classes, mostly based on CRTP. His initial class assigments included:
Class 0 - RTP audio (packets less than 300 bytes)
Class 1 - RTP Video (packets greater than 300 bytes)
Class 3 - Any packet not in classes 0 & 1 that is < 300 bytes
Class 4 - All other streams (mostly TCP)
He then talked about some possible link scheduling algorithms, periodic, priority, deficit round robin, etc. It was observed that David had started writing a form of the ISSLOW service mapping documents. A suggestion was made to consider the problem in two parts - heuristic mapping of packets onto IntServ services, and, separately, mapping of IntServ services onto PPP.
Andrew Smith next gave an update on the IS802 Framework and Service mapping documents. (draft-ietf-issll-is802-framework-03.txt), draft-ietf-issll-is802-svc-mapping-01.txt) Several sections were moved from the Service Mapping document to the Framework document. In the Service Mapping document, the mappings were modified to include the "background" class as user_priority 1 (yes, that means that the user_priorities are not monotonically increasing). There was some discussion that there was no "drop prioirty" mapping available but 802.1p switches do not do any "dropping" using drop priority mechanisms so further IEEE standardization would be needed. Also, the document changed the merge ordering for TCLASS values to 1,2,0,3,4,5,6,7 to match the latest IEEE 802.1p document. (yes, this is not monotonicaly increasing anymore). There was a comment on policing vs. shaping on the hosts. It was determined that hosts should shape and never police since they would be throwing away their own data. There was some discussion on the Framework document's use of "Classes of Switches". These and other comments will be discussed on the mailing list before making a decision about whether to revise the documents again or send them forward as is.
John Wroclawski gave an introduction to the IS802 SBM update presentation, asking for folks to carefully review the document and provide comments now that the design team believed their work to be complete. The chairs plan to allow two weeks for wider review of this document, and then working-group last-call it on December 22.
Raj Yavatkar presented an update on the SBM draft. (draft-ietf-issll-is802-bm-05.txt soon to be renamed draft-ietf-issll-is802-sbm-05.txt) Raj's slides can be found in:
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/is802_sbm.ps
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/is802_sbm.pdf
The comments received/raised on version 04 of the draft included:
· Should the 802.1p user_priority be in the SBM PATH?
· How is interoperability with non-SBM nodes or clients handled?
· How is interoperabiltiy with SBM transparent nodes handled?
· Should we use only raw IP mode for RSVP, (e.g. no UDP encaps)?
· Should we Include L2/L3 addresses in the DSBM messages?
The changes in version 05 that addresses these include:
· The SBM_INFO object was added to the I_AM_DSBM message
· The I_AM_DSBM and DSBM_WILLING messages contain both L2/L3 addresses.
· The correct multicast addresses (according to IANA) are now listed
· The semantics of user_priority were moved to the service mapping document
· The terminology was made consistent between the IS802 drafts.
The authors believe the document is ready for last call and asked for any comments. Raj made some minor clarifications in response to questions from the floor, but areas where the document required more work were identified.
This concluded the old business of the meeting. The group turned to new business.
M. Smirnov, speaking for L. Salgarelli and himself, gave an informational presentation on Multicast Integrated Services over ATM based on the draft: (draft-salgarelli-issll-mis-00.{txt, ps})
The slides can be found in:
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/issll_mis.ps
ftp://mercury.lcs.mit.edu/pub/issll/IETF/washington_9712/issll_mis.pdf
Technical solutions for IP/ATM multicast and QoS so far were classified as:
· Multicast without QoS [ION]
· QoS w/o multicast [ISSLL]
Both schemes have scalability issues. The authors target was to support integrated receiver heterogeneity. The basic idea is to use a Multicast Integration Server (MIS) integrating layer-2 multicast address resolution and QoS management with layer-3 QoS management; Joining operation of layer 2 and layer 3 with strict functional separation, (e.g., no changes to protocol semantics in both layers). An IntServ Server is co-located with Layer2 QoS aware Multicast ARP server for a single point of interworking. The details of the protocol interactions are in the draft. In summary, the authors claim that the MIS Architecture is open, integrates L2 and L3 processing, provides remote capacity admission control, provides ATM shortcuts and supports multicast flows. No changes are required to RSVP semantics but the Multicast Address Resolution protocol needs to be made aware of QoS and Shortcuts. "Quantized" heterogeneity is supported. There are two implementations in progress at this time. In the future, the authors wish to expand MIS to work in very large clouds, Interwork to MPLS, provide policy enforcement, and handle security issues.