NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 01-Dec-00
Chair(s):
John Wroclawski <jtw@lcs.mit.edu>
Eric Crawley <esc@argon.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@east.isi.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:
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. |
Internet-Drafts:
Request For Comments:
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 |
ISSLL WG - Minutes from meeting at 49th IETF - San Diego, CA, 12/13/00
*) Summary of happenings since last meeting
John Wroclawski presented a status report for ISSLL work in progress:
Three internet-drafts completed and published as RFC's
- RFC 2996: Format of the RSVP DCLASS Object
- RFC 2997: Specification of the Null Service Type
- RFC 2998: A Framework for Integrated Services Operation over Diffserv Networks
draft-ietf-issll-rsvp-aggr-02.txt submitted to IESG for publication as RFC, ran into some concerns. Will discuss later in the meeting.
New document draft-ietf-issll-rsvp-cap-01.txt taken on as WG work, will discuss next.
*) draft-ietf-issll-rsvp-cap-01.txt
Hamid Syed presented this draft. The work defines a mechanism for allowing upstream and downstream elements (hosts, routers, etc) to negotiate about which one is responsible for what functions (marking, policing) when an RSVP-controlled flow enters a diffserv network. The work is intended to augment the use of the RSVP DCLASS object previously defined by the group.
Discussion:
- Examples are between router and upstream host - is this the only intended use?
-- No, intended to be a negotiation framework between upstream and downstream boxes in general. For example, between egress router of one diffserv cloud and ingress of another. Another case - multiple markings, where different DSCP is used in different parts of the path - here negotiation might be between egress and ingress routers of two DS clouds, and simultaneously between ingress router of first DS cloud and host.
- Name the RSVP object to reflect this (original proposal was HCAP).
-- Yes. (now CAP object)
- Why is this object really useful?
-- Discussion of this question concluded that the object was useful in a number of scenarios, but that the examples given in the current draft were somewhat limiting. Draft examples focus on whether a DCLASS object should be used at all, but real questions are more complex - who marks, who filters, who polices, etc. Conclusion: need more work here, first to work out wider range of scenarios and then to present them in an informational fashion.
- What path forward for the document?
-- Discussion reached a concensus to split the draft into two documents, a very short standards-track document that specifies the CAP object and any related mechanism, and a longer informational document that describes a range of scenarios and uses of the object and mechanism.
*) draft-ietf-issll-rsvp-aggr-02.txt
Allison Mankin (Transport AD) reported briefly on concerns raised by the IESG with this draft. Basically, the draft specifies that the IP protocol field of packets be changed in flight, to allow hiding of RSVP messages within a diffserv cloud, so that they will be ignored. This is viewed as a bad precedent, and a possible security problem. The security section of the document does not discuss the issue in any detail.
Discussion:
- Isn't this dealt with by RSVP integrity object?
-- No, it's the IP header protocol field, not covered.
- Why not just use a mechanism similar to the RSVP tunnel draft?
-- (from draft author) This mechanism auto-configures to routing configuration better. Tunnel draft solves a somewhat different problem.
- Is there a protocol fix?
-- (from author) No obvious fix. Can reconsider.
- Will the IESG buy a strong security statement with no other changes?
-- (From Allison) Not clear, but can try.
Conclusion:
Authors of document will discuss possible technical changes. Will allow one month for this. If no promising changes are emerging, will draft a strong security statement discussing this issue, add to the current draft, and resubmit.
*) Disucssion of Diffserv "Service Mapping" draft.
This document is a listed work item on the WG charter, and two revisions have been drafted, but work has stalled recently. The purpose of the discussion was to determine if there was interest in restarting the work.
Conclusions:
- Significant interest.
- Knowledge lies mostly with a small number of people (Anna Charny, Jim Roberts of France Telecom are high on the list). Need to get them involved if possible.
- Document should reflect reality of use of current intserv services (G, CL) rather than exactly implementing the formal definitions from the RFC's.
- May be appropriate to aim for BCP rather than informational. Not standards-track.
Conclusion: Chairs will contact key people, outline a way to restart work on this.
Meeting concludes.