NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99
Chair(s):
John Wroclawski <jtw@lcs.mit.edu>
Eric Crawley <esc@argon.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
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:
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 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 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 Overview of Integrated Services over ATM UNI 3.X to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft on Controlled Load Service over ATM UNI 3.x to IESG for publication as an RFC. |
Done |
|
Submit Internet-Draft of Updates of the documents relate to the ATM Forum 4.0 Specification(s) |
Done |
|
Submit Internet-Draft of Updated Overview of Integrated Services over ATM to include Short Cuts and VC Aggregation |
Done |
|
Submit Internet-Draft on 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 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. |
Sep 99 |
|
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 of MIB for Subnet Bandwidth Manage to IESG for publication as a RFC. |
Nov 99 |
|
Submit Internet-Draft defining the intserv |
Nov 99 |
|
Submit Internet-Draft of intserv-diffserv integration framework document to IESG for publication as a RFC. |
Nov 99 |
|
Submit Internet-Draft describing use of RSVP for managing aggregate |
Nov 99 |
|
Submit Internet-Draft on Controlled Load Service over token ring networks to IESG for publication as an RFC. |
Nov 99 |
|
Submit Internet-Draft on Integrated Services over token ring networks to IESG for publication as an RFC. |
Mar 00 |
|
Submit Internet-Draft on service mapping to IESG for publication as a RFC. |
Internet-Drafts:
· A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies
· Integrated Service Mappings on IEEE 802 Networks
· A Framework For Integrated Services Operation Over Diffserv Networks
· Definitions of Managed Parameters for SBM network nodes
· Format of the RSVP DCLASS Object
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 | |
Minutes of the ISSLL Working Group from the 46th IETF meeting in Washington, DC. November 11, 1999 1530-1730.
Minutes recorded by Eric Crawley.
The agenda for this meeting is available as http://ana.lcs.mit.edu/ISSLL/meetings/11.99/agenda.pdf
These minutes are also available as http://ana.lcs.mit.edu/ISSLL/meetings/11.99/minutes.txt
John Wroclawski went over the status of the current drafts:
- draft-ietf-issll-is802-sbm-09.txt is going to the IESG. Latest version was in response to comments from AD and other editorial comments. This version will be submitted with the other IS802 documents to the IESG immediately.
- draft-ietf-issll-is802-sbm-mib-01.txt has received no comments on the mailing list. The author was not available for an update but it is likely that we will send this to the IESG soon.
The majority of the activity in the WG is centered around the IntServ over DiffServ area.
- draft-ietf-issll-diffserv-rsvp-03.txt framework document is getting a few last comments before going to the IESG.
- draft-ietf-issll-dclass-01.txt DCLASS document is complete and will be going to the IESG shortly
- draft-ietf-issll-nullservice-00.txt, Null Service specification has some comments that are being incorporated and is in WG last call. The last call will end 11/25/99 [ed. this has slipped. now will end sometime in December]
Bruce Davie gave an update on the RSVP Aggregation draft (draft-ietf-issll-rsvp-aggr-00.txt):
SLIDES: http://ana.lcs.mit.edu/ISSLL/meetings/11.99/bsd-rsvp-aggr.pdf
A small number of changes have been made, including the renaming of the draft. Bruce proposed a clarification be made regarding aggregate reservations; they can be used to manage BW in a Diffserv cloud independent of e2e RSVP reservations, much like a tunnel. He proposed to add text to cover this case. This draft can then be put forward for WG last call. Any questions and issues can be raised on the mailing list.
Next, John Wroclawski discussed DCLASS Marking Negotiation.
SLIDES: http://ana.lcs.mit.edu/ISSLL/meetings/11.99/jtw-dclass-neg.pdf
The problem is: What happens when the host doesn't know what a DCLASS object is and can't mark the traffic? This is another instance of DCLASS marking negotiation for aggregates. There are a few options available we can:
- Ignore the issue
- Describe it and handle it locally by domain-specific configuration
- Develop a simple yes/no protocol to send responses upstream.
This protocol can be implemented as RSVP objects, made into a separate protocol or something else.
The following discussion noted that this is a similar problem to that of the TCLASS object used by the IS802 SBM. There was a question about where, in terms of documents, such a specification would belong. John felt that it should be a separate document. There was concern that all the negotiation would come down to a least common DCLASS, which is true. There was more discussion about the use of RSVP for this function and it was pointed out that this approach requires some form of acknowledgement which is not very strongly supported in RSVP but the responses are only needed when using RSVP. The general consensus was that this problem needed to be documented but not solved immediately. If it is determined that the problem needs to be solved, it will be done in separate documents and will not impede the current set of documents. The problem may be a lot harder than we think right now.
The remainder of the meeting was spent on an excellent discussion of IntServ/DiffServ service mapping. John Wroclawski introduced the problem.
SLIDES: http://ana.lcs.mit.edu/ISSLL/meetings/11.99/jtw-svc-map.pdf
The purpose of IntServ/DiffServ service mapping is to make a DiffServ cloud act like an IntServ "network element". This means the DiffServ cloud must:
- Implement a scheduling service (G,CL)
- Perform admission control
- Export some information (delay info for G)
- provide a control interface (E2E RSVP, SNMP, etc.)
For a Diffserv cloud we must:
- Select appropriate PHBs
- Select edge behavior (metering, policing, remarking)
- Select admission control algorithm(s)
- Collect and export required information (CL and G terms)
These topics must be documented in draft-ietf-issll-isdif-svc-map-xx, which does not yet exist. It must also answer the top level questions of: Which Services? How Accurately? and What Approach?
The discussion next turned to mapping specific IntServ services. John Wroclawski started off with Controlled Load (CL). CL requires an assurance that BW is available and that a flow's expected queuing delay is related to its own burst size. A CL node must carry over-TSpec traffic when capacity permits and CL traffic should not disrupt adaptive best-effort traffic. In DiffServ, this means we must:
- Use AF PHBs
- Use different AF classes to handle traffic with different delay expectations (burst sizes)
- Police flows at the cloud edge where in spec traffic is marked AFx1 and out of spec traffic is marked AFx2
- Set AF Class BW to carry expected traffic
- Set AF class dropping parameters to limit delay
See John's presentation (http://ana.lcs.mit.edu/ISSLL/meetings/11.99/jtw-svc-map.pdf) for an example picture using multiple queues and weight or priority across AF classes . In such a mapping, admission control is a must. There are three current methods for admission control; Parameter Based, Measurement based, and Experience based.
The Open Questions/Issues are:
- Do we require/recommend a specific number of delay classes?
- Do we require/recommend a particular output scheduling behavior?
- What should be said about admission control?
- What should be said about alternate mappings?
In the discussion that followed, Questions about the aggregate and the delays experienced by the aggregate of the bursts were raised. This can be handled by multiple AF classes and the aggregate usually wins statistically. Another question was raised about burst sizes and how they are specified. This is really a problem for the IntServ models as they exist. The application programmers have to figure this out or it is available via policy servers.
Further questions and discussion about the use of DiffServ PHBs, which are specifically *not* services to construct IntServ *services*. Yes, DiffServ PHBs do not define services but using a DiffServ network as an IntServ node, we are able to develop services. There was a concern that by combining multiple burst sizes together would either run out of AF classes or not get the service desired. This is a case where the classes have to be provisioned properly and admission control is used to control the resources. There was a concern that if we specify the behavior and end up specifying more of AF than is already specified. John Wroclawski pointed out that we would only be talking about weighting between AF classes and not inter-PHB behavior. There was a comment that we have gone from a very specific micro-flow monitored network to one that can scale by aggregating but we lose some of the detail so a bit of over-provisioning is needed. However, this allows a statistical multiplexing gain that is good for aggregates. There was a question about just recommending AF when one could also use EF. John pointed out that that EF will throw away over-spec traffic while AF can't so we *must* used AF for Controlled Load. A concern was voiced about ordering the AF classes but it is likely that we can only recommend the order.
John Wroclawski next gave an introduction to Guaranteed Service mapping. The key difference between G and CL is that there is a mathematical guarantee of worst case. This means that the nodes must Generate and export "error terms". There are some tradeoffs that must be considered such because the mathematical guarantee and error terms impose difficult implementation requirements. Handling these over TSPec traffic well is "very hard". John presented the following strawman:
- Shape all G traffic at ingress to CBR
- Use EF to carry G traffic
- optionally reshape G traffic at exit
- overall delay bound is sum of delays
Anna Charny gave a presentation on a mathematical Model for Guaranteed traffic in a DiffServ network.
Slides: http://ana.lcs.mit.edu/ISSLL/meetings/11.99/charny-g-aggr.pdf
The assumptions in the model are:
- Backbone implements priority FIFO for EF
- Ingress node performs per "flow" shaping
- All devices in the backbone are output-bufferened (standard in intserv and diffserv)
The basic formula is: delay = ingress shaping delay + backbone delay + egress shaping delay
For more details see Anna's slides. She has worked out a proof for the formula but it was done recently and hasn't been completely checked yet. Anna's model showed that delay is very sensitive to priority traffic utilization and also sensitive to the accuracy of shaping at all ingress points as well as the smallest flow rate acorss the cloud. This formula applies to arbitrary topologies too. For more examples, please see Anna's slides.
Anna noted that delay is inversly proportional to the smallest rate you shape at. She showed some startling numbers about the maximum delay. There was lots of discussion on what these numbers and models mean. The interesting and counter-intuitive result is that aggregation actually reduces the delay!
Observations:
- There is a reasonable area in parameter space that gives reasonable delay bounds meaning that G service can be provided .
- The ability to provide G service requires cooperation of all edge and core equipment, not just along the path.
- High utilization of delay-sensitive traffic is not feasible
- Appropriate aggregation (on edge-to-edge basis) *decreases* delay bounds!
None received.