Minutes of the Integrated Services over Specific Link Layers (ISSLL) working group from the 40th IETF in Washington, DC. Minutes recorded 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 & 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.