NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
John Wroclawski <jtw@lcs.mit.edu>
Eric Crawley <esc@argon.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Allison Mankin <mankin@east.isi.edu>
General Discussion:issll@mercury.lcs.mit.edu
To Subscribe: issll-request@mercury.lcs.mit.edu
Archive: ftp://mercury.lcs.mit.edu/pub/issll/mail/
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
Done |
|
Submit Internet-Draft of Controlled Load Service over ATM UNI 3.x (includes parameter mapping, VC management, and references VC usage guidelines from Overview) |
Done |
|
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) |
Done |
|
Submit Internet-Draft of The Operation of RSVP over ATM UNI 3.X |
Done |
|
Submit Internet-Draft of Integrated Services over token ring networks (switched and shared with sections on source route bridging, token priority, filtering, etc). |
Done |
|
Submit Internet-Draft of Controlled Load Service over ISSLOW. |
Done |
|
Submit Internet-Draft of Realtime Header-compression and packet framing protocol. [Requires close coordination with PPPEXT and AVT.] |
Done |
|
Submit Internet-Draft of Guaranteed Service over ATM UNI 3.X (includes parameter mapping, VC management, and references VC usage guidelines from Overview) |
Done |
|
Submit Internet-Draft of Controlled Load Service over token ring networks (switched and shared). |
Done |
|
Submit Internet-Draft on The Operation of RSVP over ATM UNI 3.X |
Done |
|
Submit Internet-Draft on Controlled Load Service over ATM UNI 3.x to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft on Overview of Integrated Services over ATM UNI 3.X to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft of Updated Overview of Integrated Services over ATM to include Short Cuts and VC Aggregation |
Done |
|
Submit Internet-Draft of Updates of the documents relate to the ATM Forum 4.0 Specification(s) |
Done |
|
Submit Internet-Draft on Guaranteed Service over ATM UNI 3.X to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft on ATM Forum 4.0 Specification(s) |
Done |
|
Submit Internet-Draft on dcouments relate to the ATM Forum 4.0 Specification(s) |
Done |
|
Submit Internet-Draft on Updated Overview of Integrated Services over ATM to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft on Controlled Load Service over ISSLOW to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft on Realtime Header-compression and packet framing protocol to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft on DCLASS object to IESG for publication as a proposed standard |
Oct 99 |
|
Publish Internet-Draft on service mapping - support of intserv services using diffserv aggregate scheduling mechanisms. |
Nov 99 |
|
Submit Internet-Draft describing use of RSVP for managing aggregate resources in diffserv clouds for publication as an RFC. |
Done |
|
Submit Internet-Draft of intserv-diffserv integration framework document to IESG for publication as a RFC. |
Done |
|
Submit Internet-Draft of MIB for Subnet Bandwidth Manage to IESG for publication as a RFC. |
Mar 00 |
|
Submit Internet-Draft on service mapping of intserv services onto diffserv clouds to IESG for publication as a RFC. |
Done |
|
Submit SBM protocol draft to IESG for standards track. |
Done |
|
Submit int-serv mappings onto IEEE 802 networks draft to IESG for standards track. |
Done |
|
Submit Framework for int-serv in switched and shared IEEE 802 LAN technologies for informational publication. |
RFC |
Status |
Title |
RFC2380 |
PS |
RSVP over ATM Implementation Requirements |
RFC2379 |
RSVP over ATM Implementation Guidelines | |
RFC2381 |
PS |
Interoperation of Controlled-Load Service and Guaranteed Service with ATM |
RFC2382 |
A Framework for Integrated Services and RSVP over ATM | |
RFC2687 |
PS |
PPP in a real-time oriented HDLC-like framing |
RFC2686 |
PS |
The Multi-Class Extension to Multi-Link PPP |
RFC2688 |
PS |
Integrated Services Mappings for Low Speed Networks |
RFC2689 |
Providing integrated services over low-bitrate links | |
RFC2814 |
PS |
SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks |
RFC2816 |
A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies | |
RFC2815 |
PS |
Integrated Service Mappings on IEEE 802 Networks |
RFC2996 |
PS |
Format of the RSVP DCLASS Object |
RFC2997 |
PS |
Specification of the Null Service Type |
RFC2998 |
A Framework For Integrated Services Operation Over Diffserv Networks |
Minutes of the ISSLL WG Meeting
50th IETF - Minneapolis, MN.
Tuesday, March 20, 2001 13:00-14:00
ISSLL held a one-hour meeting at the 50th IETF. Issues related to several Intserv/Diffserv documents were discussed.
* draft-ietf-issll-rsvp-aggr-03.txt
The chair gave a short summary of the status of this draft. It was submitted to the IESG for publication as a RFC months ago. At the December, 2000 WG meeting the cognizant AD (Allison Mankin) gave a short presentation explaining the concerns, which focused around the draft's requirement that the IP next-protocol field be altered as the packet traveled through routers. She suggesting that the concerns could be resolved either through technical revision or through a more detailed security concerns section.
After some discussion at the 49th IETF meeting and consideration among the authors, a new security section was drafted and a revised version of the document was submitted before the deadline for this meeting. No further comments on the revised version have been received on the mailing list.
At the time of the WG meeting, the IESG was still reviewing this revised version.
[Ed. after the meeting, the IESG approved publication of the draft, subject only to some clarification of the IANA considerations section. That clarification led to a -04 version draft being submitted. This version will now go to the RFC editor.]
* draft-ietf-issll-rsvp-cap-02.txt
This draft defines the RSVP CAP object. The -02 version of this draft, incorporating previous comments, was submitted in February. A key change was removing most of the explanatory material into a separate document, draft-hamid-issll-rsvp-cap-dsmark-00.txt, leaving this one as a standalone spec.
Comments from the mailing list and the chairs identified several small issues with this document. These points include:
1) Sections of the previous document that specified bit assignments were incorrectly removed to the explanatory document. Bit assignments should be part of the standard, not the explanation
2) The document presently implies that each capability will only require one bit. There is no reason that this need be true, and the limitation is not needed.
3) Message processing rule descriptions need to be either completely generic or specified per-capability, rather than in a general section.
The author of the draft was unable to attend the meeting. In his absense, the chairs proposed revising the document to address these issues by a) editing the present definition of the CAP object itself to include only generic (not per-capability) information and to not limit the definition of a particular capability, and b) adding new sections for each defined capability, giving bit assignments and message processing rules for that capability. The intent is that new revisions of the document would be issued if and when new capabilities are defined.
A brief discussion did not reveal any objections to this approach from meeting attendees. The chairs will draft a note to the mailing list and forward comments to the draft author.
* draft-ietf-issll-ds-map-01.txt
[Ed. The chairs note that one of them is also an author of the current version of this draft.]
This is the "service mapping" draft, which gives advice about using diffserv technologies to cause a DS cloud to effectively emulate an intserv "network element" and thus play a part in an intserv end-to-end QoS path.
The current version of the document was written some time ago and has not been modified in any significant way in some time. However, in the view of the authors, it is missing some important sections and thus is still work in progress. At this meeting, the chairs raised the question of whether to continue work on the document, and if so, what path forward would be most useful:
Specifically, the chair raised three questions as a starting point for discussion.
1: Is the document, either as it stands or as it might stand, useful?
2: Present practice is to implement and use the defined intserv services, particularly Guaranteed, in ways that do not completely match the RFC definitions. Should the document focus on mapping diffserv to the defined services, or to some approximation of these services that is emerging from current practice? If so, should we attempt to write down these approximations, either in this document or in a separate one?
3: One specific technical area that is not addressed in the current document is statistical approximations of G-like services. (CL is already defined in this way). Should the document specifically attempt to capture the current state of knowledge in this area, even though that knowledge is evolving fast?
A vigorous discussion ensued. The results of this discussion can be summarised as:
1) There was substantial concensus in the meeting that the document is useful and should be completed. Some speakers expressed the opinion that the document is useful as it stands now, and should be published as is even if no further technical work is done.
2) There was substantial concensus in the meeting that the document should focus on implementing the intserv services as they are actually being used, rather than strictly following the RFC definition.
3) There was substantial concensus that it would be useful to crisply document the assumptions and approximations made by current implementations of the intserv services, as a starting point for doing the above. The question of whether this should be a separate document or a section of the mapping draft was left open.
4) Some speakers suggested that the intserv service definitions themselves were subject to misunderstandings that led to problems. A document or section of the current draft discussing these issues was suggested.
5) There was an extended discussion of whether it would be useful to define one or more new IntServ services with definitions that captured what people perceive as the current requirements for VoIP. The meeting was more or less evenly split on this topic, with several speakers arguing for a new service at the Intserv level and several others arguing that appropriate selection, implementation and approximation of the existing services in different environments is a simpler and adequate approach. A complicating factor in this discussion was point 4, above, which raised the possibility that some concerns about the current specs were based on interpretation of the spec document rather than technical unsuitability.
Based on this discussion, and followup discussions with the document authors and people that expressed interest in the meeting, the chairs will draft a proposal for revising this I-D and forward it to the mailing list for discussion as soon as practical.
None received.