Editor's note: These minutes have note been edited. Below are the minutes for the ISSLL working group meeting in Montreal. These minutes and all the presentations should show up on the ISSLL server on Monday. See ftp://mercury.lcs.mit.edu/pub/issll/IETF/9606/ Minutes for the ISSLL WG meetings, June 24 & 25 at the Montreal IETF Co-chairs: Eric Crawley & John Wroclawski Reported by: Greg Troxel (with many thanks from the chairs) and Eric Crawley Session #1: June 24, 1996 0930-1130 Eric provided a quick status update on the group. The group was officially chartered by the IESG. Coordinators are in place for ATM, Token Ring, Ethernet, and Low BW links. Other areas of interest include: Frame Relay, SMDS, and Cable Modems Carsten Bormann gave an overview of the issues related to ISSLOW (Integrated Services over Slow/Low BW links). This included the relevant work in other WGs and the ITU. The problems for low speed links are their speed and blockage from larger frames. Carsten discussed the current work on header compression for PPP/IP/UDP/RTP as well as some options for suspending/fragmenting larger best-effort frames. There was also discussion of applications providing compression and QoS hints. Fred Burg and Barry O'Mahony followed up with some details on the modem technologies involved and the recent ITU standards for multimedia modems. Carsten came back to discuss some of the issues further. It is pretty clear that some of the current compression standards (e.g. V.42) introduce delays that will be significant to real time traffic. A scheme for using PPP Multilink for suspension and resumption of best effort frames was also discussed (Multilink can be used on a single PPP link). Carsten summarized by noting that we need to enlist the help of the AVT, PPPEXT, and RSVP working groups. People interested in ISSLOW activities met with Carsten and others after the WG meeting. Wayne Pace presented a draft on Integrated Services over Token Ring networks. This was mostly a high level overview that may apply to other IEEE 802-style networks. The architecture was based on an IBM implementation that utilized Q.933 signalling to start the LAN resource reservation process. An allocator approves or rejects requests from hosts. The allocator can be centralized or distributed depending on the network architecture/needs but there are some issues to be resolved. They are wanting to expand this mechanism to use RSVP to trigger the LAN resource requests. Token Ring networks also have source routing and priority mechanisms that may be useful to ISSLL. There was some discussion of the overlap of the allocator with the "gatekeeper" function in H.323. The H.323 gatekeeper has hooks to access other resource management facilities. Session #2: Tuesday, June 25, 1996 0900-1130 John Wroclawski kicked the session off with a request that presenters keep things short and provide introductory material only so discussions can happen on the mailing list. Questions should be held until the end of presentations, if possible. Raj Yavatkar presented a draft on a Subnet BW Manager (SBM). This is somewhat similar to the allocator presented for Token Ring networks but uses more RSVP functionality and mechanisms to request resources. There are still issues with electing the "Designated Subnet BW Manager" DSBM and centralizing vs. distributing the SBM function. There was some discussion about the issues for shared network segments and getting other hosts to "play along". Peter Kim presented a draft on the "Link Layer Resource Management Protocol" (LLRMP). This scheme is distributed and independent of the higher level protocol and link technology but was designed for demand- priority networks. It uses soft state with sender initiation and can be deployed gradually. The folks interested in subnet BW managers gathered together later in the day to discussion the issues in more detail. The chairs took an action item to appoint a coordinator for the subnet BW manager area. It is clear that a subnet BW manager is a common element to many shared media networks. Marty Borden presented a draft on ATM Service Mappings. The problems of VC Management and Service Mappings cannot be completely separated. The draft ignored LANE encapsulation for now because of no QoS mechanisms in LANE. The main concentration is on the mappings of the service classes. There are lots of parameters available and some of them are a bit confusing as to how they map. It was noted that some service categories may be used for a variety of services. There will need to be a range of options for service mappings because not all service categories will be available from vendors and service providers. Steve Berson presented a draft on the operation of RSVP over ATM including some of the VC management issues. Mapping the data flows for an RSVP session depends on the level of heterogenaity in the receivers. Homogeneous flows can use one VC while flows with limited heterogenaity (reserved and best effort) can be mapped to 2 VCs. There are some hybrid models that can also be implemented. The next issue is how to map the control flows. If the same VC is used, the CLP bit may be used to keep from dropping control messages. Multiple VCs may be useful for hosts. Lou Berger presented another draft on RSVP over ATM that he believed was complementary to Steve Berson's draft. The draft targets UNI 3.x networks and provides a framework without dictating the actual data and control management. The framework has data VCs established by the source with no reuse of the reverse path and receivers accept all incoming VCs. Control VCs use the best effort path and VCs. Lou discussed some possible changes to the RSVP specification but not to the protocol to adapt some of the APIs suggested in the spec to support the end point identification needed in the framework. There was discussion of other possible areas of change for RSVP over ATM including NHRP QoS, MARS/MCS QoS signalling, variageted VCs, and LANE QoS and multicast extensions. It was also noted that VC timeout mechanisms as they are specified in RFC1577 could be a problem for QoS flows. Phillipe Oechslin presented a draft on Application REQuested IP over ATM (AREQUIPA). AREQUIPA requires the ATM end point address in order to establish direct application VCs, bypassing most of the IP over ATM mechanisms. AREQUIPA is viewed as an interim solution for application QoS until RSVP over ATM is deployed. Muneyoshi Suzuki briefly presented on ST-II+ over ATM. The purpose is to use ATM as one subnet technology in an end-to-end ST-II+ connection. He quickly discussed the use of the existing VCs for control plane management while setting up VCs for data flows in response to ST-II+ connection setup. -------------------------------------- Minutes of side meetings: Three side meetings were held for folks interested link level BW management, ISSLOW, and ATM. These minutes are/will be available on the ISSLL server. Link Level BW Managment: ftp://mercury.lcs.mit.edu/pub/issll/IETF/montreal_9606/llbw-mgr- minutes.text ISSLOW: Minutes not available yet ISATM: Minutes not available yet