Editor's note: These minutes have not been edited. Minutes of the ISSLL working group meeting at the 37th IETF meeting in San Jose, CA. Reported by Eric Crawley, John Wroclawski, Don Hoffman, Sue Thomson, Mark Garrett, Steve Jackowski, and Dave Oran. Many of the slides used at this meeting are available at the ISSLL FTP site. URL's for these slides are given at the end of these minutes. The ISSLL WG held two meetings at the 37th IETF. The first of these was a general session. The second was broken out into separate sessions for the IS802, ISATM, and ISSLOW area groups. General Session: Thursday, December 12, 1996 1300-1500 John Wroclawski briefly discussed some updates to the working group charter, in response to some changes in the structures of the areas. In particular, the Ethernet and Token Ring groups are being combined into a single IS802 area and a single coordinator must be chosen. Sue Thomson provided a status of the ISATM area. There are three drafts currently under consideration; mapping of IntServ to ATM, VC management and the support of RSVP, and use of MCS for IntServ. - The mapping document has been updated to include translation of the ADspec and the use of R in Guaranteed service as well as updated guidelines for TSpec mappings. The remaining issues are; the mapping of controlled load service, default values for ATM parameters unspecified at the IP layer, and strategies for dealing with non-conforming traffic. - The VC Management Draft has been updated to include implementation guidelines and provides a union of two previous drafts. There is an introduction of implementation guidelines for the range of VC management policies. The remaining issues are; completion of the implementation guidelines and the use of RSVP with shortcuts. - The MARS MCS draft includes a recommendation to run RSVP on the MCS which will be discussed in the breakout session. The "To Do List" for ISATM includes: Aggregation MCS NHRP Leaf Initiated Join ----- Carsten Bormann gave a summary of ISSLOW work at and since the Interim Meeting held in September. There are three components required to support int-services over slow speed links: - A Realtime encapsulation, which provides the needed low latency for time-sensitive traffic. - A header compression architecture, which compresses the non-data portion of the packet as effectively as possible, and - Mappings IP flows on to encapsulation/compression to provide the desired QoS services. Of these, the first is the current work topic of this group, the second is being addressed in the IETF AVT group, and the third is the next work topic of this group. Carsten gave a brief summary of the header compression work in AVT. Two complementary proposals being combined and put forward for PS. There is a lot of demand for this PS from commercial internet telephony and conferencing vendors. Carsten next summarized the two approaches being considered for a realtime encapsulation, fragmentation (of packets), and suspension (of a high-latency packet's transmission when you want to send a low-latency one). Fragmentation is simpler, but in some cases suspension works better. ISSLOW Agenda: Need to decide on the encapsulation at this meeting and near future: - Support fragmentation with minimum changes to PPPmultilink. (need to get PPP multilink to last call in that WG) - Fragmenters vs. Suspenders question: find way for both to interoperate? - hash out suspender's solution in time for Memphis - Start work on service mapping, compressed TSpec, link delay characterization. ----- The meeting then turned to a discussion of the newly merged IS802 area's current work. Raj Yavatkar gave a quick report on the results of the September interim meeting. At that meeting, a discussion of the basic requirements and goals for IS802, and a discussion of the overall framework for a solution both reached a reasonable consensus. Some results of that discussion have been incorporated into new drafts which will be discussed at the breakout meeting. The September discussion of SBM and LLRMP, the two proposals for a signalling protocol currently before the group, raised many issues. Lack of convergence on those questions led the group to a more detailed consideration of service mappings as a way of clarifying the design of the signalling protocol. Eric Crawley spoke about the framework and requirements documents. A new organization is planned for the documents, as a result both of the merger of the different IEEE 802 technology groups and to better match the group's thinking. The new documents are: The Framework document. This doc gives an overview of the problem and solution. It contains: - Usage scenarios - Description of the components or building blocks used to provide the overall function. - Requirements and goals for the developed solution. This document will be based on contributions from a number of the current internet drafts. Service mapping document. This document starts from a matrix of (intserv) services and the scenarios above. It describes what can be done in each case, restrictions on what is practical, and a specification for the service mapping. Signalling document. The signalling document describes the protocol used to manage resources in the 802 network. It will - specify the signalling protocol - describe how it is used in each scenario above (will be -quite- different in the different scenarios, thus the challenge) The group is working towards the goal of a single signalling protocol, but has not yet reached that point. The two current drafts providing input to this process are the SBM proposal from Don Hoffman and co-authors and the LLRMP proposal from Peter Kim. Anoop Ghanwani described the current view of the framework document, based on his draft. The document first describes a number of scenarios in which the IS802 technology must work, including full and half duplex paths, shared and switched media, priority or no priority, and so on. The reality and effect of hybrid topologies is described. Existing or proposed 802 traffic management mechanisms, such as Token Ring's native priority and 802.1p, are described. The document then defines the components of the overall solution, which include admission control, signalling, flow classification, policing and shaping, and service mappings. Anoop, and the document, then turn to requirements. See the presentation slides for much more detail on this topic. The group has identified both requirements, which are mandatory, and goals, which are desirable but not mandatory. Requirements: - resource reservation and management. The requirements are driven by needs of RSVP - admission control - scheduling - policing. definitely at edge devices, could be at edges and switches. Needed both to ensure conformity with the service spec for the QoS flows, and to protect other flows. - fault tolerance. - soft state approach. - either centralized or distributed implementation. - specify MIBS. Goals: - independence from higher level protocols - receiver heterogeneity - RSVP-like scalability - path selection Anoop concluded with a brief description of how the framework was being developed from the existing drafts. With the reorganization of the documents, pieces of a number of drafts will go into the framework, including those by Ghanwani, Hoffman, Seaman/Smith/Crawley, Pace, and others. Don Hoffman talked about mapping intserv services and RSVP into diverse 802 environments. The work has several starting points, including a top-down summary of intserv traffic control requirements (draft-hoffman-issll-l2tcreq-00.txt), a description of the proposed new 802.1 traffic control mechanisms (draft-ietf-issll-802-xxx), and the WG member's knowledge of other 802 traffic control mechanisms, particularly those in token ring. Don described several difficulties in mapping the pure intserv model onto 802 LAN's. His overall conclusion was that some degree of approximation will be required in certain scenarios, and that an important question was how much approximation should be tolerated. Specific points mentioned included: - goal of avoiding application awareness of L2 approximation - particular problems with some legacy environments (but some approximation may be required in new 802.1 technologies as well). - sources of difficulty - LAN scenarios lacking priority - lack of per-flow policing in L2 switches (BIG problem) - heterogeneity of L2 fabric - lack of tagging scheme for non-conformant traffic Don described a couple of specific "test cases" where a particular aspect of the Intserv/RSVP model caused a problem. - Shared-style reservations with many senders in absence of peripheral hard policing (a hand-drawn slide showed that the implicit merge point inside switch creates the possibility of degrading service for other flows in presence of an overloaded flow) - Receiver Heterogeneity. This occurs when different RSVP receivers ask for different delay bounds, and/or some receivers don't have reservations at all (the common case]). The problem is that the aggregated, rather than per-flow mechanism makes it impossible for a flow to be "reserved" at some point in the net and best-effort at other part of the net. Granularity of control does not match granularity of admission control. [editor's note: This is somewhat unclear, and the slide was hand-drawn and not in the archive.] The presentation turned to what services could be provided by each LAN type: (GS = Guaranteed, CL = Controlled Load) o Legacy (802.3, most Token Ring) - GS probably impossible - CL not perfect, but probably useful implementations o Next generation 802.1p - GS causes great disagreement - CL quite likely to be done or approximated well. [editors note: I do not recall if the presentation differentiated between shared and switched "legacy" services in this assessment, other discussions in the WG have done so.] Andrew Smith gave a brief presentation on the development of traffic priority mechanisms in 802 networks. The new model is that the customer of the MAC service can specify a user_priority and an access_priority. Different technologies may do different things with these numbers. Ethernet has no support "on the wire", but can use access_priority locally. 802.5 has 8 levels of user_priority and 8 levels of access_priority. The new 802.1D (802.1p) defines 8 traffic classes over any 802 network. The specs (loosely) define the behavior of switches and bridges with respect to these traffic classes. However, there are no rules given for how end-stations assign traffic to a class, so in the absence of further agreement or admission control, no predictable behavior can be obtained. The rules for 802.1p switches are very vague. An 802.1p switch - may implement one or more queues per output port. - perform locally defined mapping of traffic class onto output queue. - the default queue servicing mode is "strict priority". - switch does not necessarily use MAC destination address or port when mapping to queues. This suggests that just being an 802.1p switch is not enough to promise much of anything; switches will have to be selected based on detailed vendor specs in order to be useful for many ISSLL situations. --------- Eric Crawley gave a presentation about providing IP Integrated Services in an ATM LANE environment. Since LANE is ATM emulating an 802 LAN, this turns out to be a combination of work done in the IS802 and ISATM subgroups. Eric gave some motivation. LANEv2 is now coming to completion in the ATM forum. Two goals of that work - better support for multicasting and support for QoS control - are directly relevant to IP Integrated Services, and make LANE much more interesting. Another goal of LANE - keeping the basic spirit of emulating 802 LAN's, so as to minimally change the higher-level protocol requirements - has made LANE perhaps most popular use of ATM now. Eric re-summarized 802.1P as used in LANE. 802.1p adds traffic classes and multicast management. A question arose: Eric said the minimal number of queues (priorities) in 802.1p is two; Andrew Smith had previously said one in his talk. Eric proposed a mapping (see slide) of traffic onto priorities which gave GS the highest, CL next, best-effort next, and less-than-best-effort the lowest. Questions: Q: what is "less than best effort". A: might be used for non-conformant overflow of CL, GS. Q: is 802 relaxing ordering requirements inherent in 802.1d? Keith: you can misorder to hearts content between priorities. Some details of LANEv2 implementation and use by ISSLL were presented. LANEv2 maps 8 traffic classes to 8 different VC's between LANE clients. One needs to figure out call setup parameters for these VC's. They can then be stored in the LANE configuration server so that clients will know how to set up VC's. The ISATM subgroup is defining mappings between ATM VC setup parameters and intserv service classes. The problem is that these are currently only per-flow. A LANEv2 VC will have multiple flows mapped to same emulated priority. It is necessary to compute setup parameters for the aggregated traffic flow. Observation: this is one simple way of aggregating traffic onto a VC. (Picture showing mapping of flows onto VC's at LANE emulation clients. Traversing ATM net, and comes out as two different flows of traffic.) Eric's last slide summarized the questions which must be answered to make this practical. 1) Need to define a good mapping of intserv services to 802.1p classes. 2) What to do about multiple priorities for G service? 3) Dynamic assignment of service-to-priority mapping (LANE clients learn mapping at call setup time, not at build time. This gives greater flexibility to the LANE server to manage its resources). - configure mappings so end-stations don't require static mapping bw manager -tells- you the priority to use - new requirements on is802 admission control/signalling 4) Algorithm for sizing VC's for aggregate traffic flows. With the conclusion of this presentation, the general session ended at 15:30. ----- ISSLL Intserv/ATM subgroup minutes for IETF meeting, December 1996. Susan Thomson, ISATM Coordinator The IS-ATM group met on Friday, December 13th, 0900-1130. The following two drafts were discussed: - RSVP over ATM (draft-ietf-issll-atm-support-02.{ps, txt}) - Mapping IntServ to ATM (draft-ietf-issll-atm-mapping-01.txt) Steve Berson and Lou Berger led discussions of the first draft. Steve summarized the heterogeneous, limited heterogeneous, homogeneous and modified homogeneous styles of mapping flows into VCs. He discussed support for dynamic behavior, change in QoS, change in the list of receivers, etc. These schemes may be compared using metrics such as the number of VCs, whether packets are duplicated and the amount of ATM signalling traffic. A point was identified that there are many types of possible failures (e.g. a sender cannot duplicate a packet), where some default behavior policy needs to be articulated in the draft. There is an issue regarding the behavior during transients, where VCs are set up or torn down in the middle of an active session which they support. During the transient packets may be duplicated or dropped, or a more complex set of VCs may be invoked to avoid this. The recommendation was to allow duplication during the transient. There was some discussion of non-rsvp routers, and the use of the Logical Interface Handle (LIH). In Lou Berger's discussion, the question was raised regarding whether implementation "SHOULD" or "MUST" implement a one VC per flow option (an implementation with aggregation is never disallowed). A straw vote was taken, and the consensus seemed to be for "SHOULD", although a significant plurality preferred "MUST". The concept of a default implementation, where functions are identified as either optional or mandatory, was introduced. An issue regarding non-aggregated VC management policies was not resolved and will be discussed further on the mailing list. A discussion of multicast end point identification left the draft unchanged. When using a MARS multicast server (MCS), the sender must be configured to set the int-serv break bit, since MCS doesn't support QoS. This is problematic, since the sender doesn't generally know about the MCS. The agreement was that the network administrator should set a consistent configuration: i.e. to set the break bit when an MCS is used. Mark Garrett led a discussion of the service mapping draft. The new additions to the draft (since the October interim meeting) are a section on AdSpec, and what the ingress router advertises for C and D in Guaranteed Service. The traffic description mapping section now contains explicit bounds on values for PCR, SCR and MBS, in terms of the IP rate and bucket parameters, and the line rate. There have been some concerns from the ITU about explicit values of loss and delay in the mapping draft, and the fact that they do not agree with corresponding values in recommendation I.356. The resolution of this issue will be to remove the numerical values in the tables. This makes sense in any case, since we cannot really recommend any single value for a parameter that would be independent of the situation (propagation delay, link technology, etc). Note that we still retain a recommendation of QoS class numbers consistent with the UNI 3 and UNI 4 specs. We note that this is now inconsistent with the new I.356, which provides new definitions (with actual numerical values). The draft now mentions the existence of the new I.356, and the interpretation of conformance is left up to the implementor. Bandwidth reservations on VCs in the reverse direction are zero for QoS VCs, and non-zero (conforming with rfc 1755) for best effort VCs. These points attained dissent-less consensus. Consensus was also obtained around the requirement that implementations should anticipate the ATM UPC (Usage Parameter Control, a.k.a policing function) and mark all the cells in certain packets in such a way that the ATM network never marks any cells because of non-conformance. This avoids the case where the ATM network marks some cells of a packet and not others, which is understood to have bad performance properties. A discussion about statistical multiplexing in the Controlled-Load service (CLS) led to an opinion, expressed by Drew Perkins, and shared by the group. Mark expressed a concern that a router could have design permitting statistical multiplexing in CLS, and the switches in the ATM cloud could also do stat muxing in a VBR service. However, there may be some variability in the "degree" of statistical multiplexing, which essentially means the aggressiveness of the admission control algorithm. Since there is no way to communicate this as a parameter, the two may differ in their behavior. The group thought this is not a problem, and each technology could implement statistical multiplexing independently, within the bounds of the standard service definitions. The missing section on excess traffic is still missing. It, and the rest of the remaining issues for the draft, are expected to be completed by April. Thanks to Stephen Shew for contributing some notes. ----- Minutes from the IS802 Breakout session Reported by Don Hoffman and Eric Crawley The IS802 break-out session was held on 12/13 from 9:00am till noon. Wayne Pace was acting Chair for the meeting, with minutes provided by him and Don Hoffman. The meeting started with prepared discussions on each of the outstanding IDs for this group. [Ed.: In this discussion, GS == Guaranteed Service, CL == Controlled-Load service, and BE == best-effort service] Anoop Ghanwani presented an update on the framework document, co-authored with Wayne Pace and Vijay Srinivasan. At this point there appears to be general agreement on this document after we have completed the merge with other outstanding documents discussed in the overall ISSLL minutes. Specifically, we will include portions from the Hoffman/Yavatkar, and Smith/Seaman/Crawley drafts. The following additional points were made during the framework discussion: The diagrams for the Centralized model do not show the case for multiple receivers and implicit L2 merge points. The consensus was to edit the document to reflect these cases. We agreed to keep the L3/L2 distinction in the framework, even if actual mechanisms take a more integrated approach. We need to make explicit that link-by-link resource allocation in the centralized model may require some form of L2 topology discovery mechanism. Don Hoffman presented a discussion on IntServ/RSVP scenarios for 802-style networks discussed in the draft co-authored with Raj Yavatkar. Parts of this draft will be merged in to the Framework document described above. Two specific issues were discussed: The case of multiple senders, and shared reservation styles where the total possible TSpec for all senders exceeds the merged receiver TSpecs. In cases where there is an implicit L2 merge point, and no per-flow L2 policing (as in the current 802.1 proposal discussed below), this scenario may result in service degradation on other conformant flows in the same traffic class. The consensus appeared to be that this case can be handled by sufficiently conservative admission control, at least in the case of CL service. The case of receiver heterogeneity where one receiver is using BE, and the others are using CL or GS. If all packets are classified to a L2 traffic class at the ingress point of the L2 network, this may result in high priority traffic going down BE branches where no admission control has been done (or it has been done and failed). Several mechanisms for handling this were discussed at the meeting, none providing completely satisfactory resolution. Andrew Smith then presented a discussion of how some traffic control mechanisms being proposed in 802.1 could be used to support IntServ/RSVP services. This discussion was based on a draft co-authored with Mick Seaman and Eric Crawley. The basic approach is to define a small number of priority bits to identify traffic class. These bits are set at the ingress point to the L2 network. In the proposal, all traffic from a particular IntServ traffic class would be mapped to specific L2 priority bits based on still to be specified mapping mechanisms. No L2 per-flow labeling would be provided. There was some discussion about whether these bits could be changed at the interior of the L2 network, with no clear resolution. It appears that such functions might be possible with further future discussion with IEEE 802.1 folks. The question was asked as to how per-flow handling could be provided by L2 switches. The answer was that such a switch would need to look ahead in to the L3 headers to identify IntServ flows. There was discussion about mechanisms for mapping L3 flows to L2, and as to whether it could be made dynamic. If so, Andrew is proposing that it happen in the network rather than at the L3 ingress host. The exact mechanism for doing this is currently unspecified. There was discussion as to whether the 802.1D mechanisms described here would be compatible with the 802.5 use of priority. It was agreed that this needs to be examined in more detail (by the 802.1 folks), but since the semantics of the FC bits in 802.5 were not defined, some sort of post hoc compatibility could be maintained. Finally, we agreed that the specification of the handling of priorities and other L2 mechanisms in Layer 2 devices is the responsibility of IEEE 802 committees, not of IS802. This will avoid any possible questions about the scope of the IS802 responsibilities. Don Hoffman presented a brief summary of the SBM signaling approach co-authored by Raj Yavatkar and Yoram Bernet. The basic changes were: Addition of two new RSVP objects to facilitate L2 processing. Now process PATH messages in SBM. Minor changes to discovery protocol. The results of the Intel, Microsoft, Sun interoperability testing were discussed. Versions of the SBM and SBM client support will be made available to the research community in the January time-frame. Peter Kim presented a summary of the LLRMP signaling approach. Basic changes since the last version were: Addition of pseudo-code detailing exact operation of LLRMP entities. Support for certain RSVP heterogeneity semantics by allowing switch to snoop RSVP RESV messages. We next went on to a general discussion of where to go next. As part of this, Peter Kim summarized some discussions he has been having with Raj Yavatkar on TuTu design (the basic concept of TuTu, is discussed in the Framework document). Their discussion indicates that it is in principle possible to define a TuTu architecture that handles both sender and receiver signaling and that support various different L2 mechanism. We also agreed that the system diagrams in Andrew Smiths's slides of the TuTu mechanism were a good representation and would be incorporated in to the framework document. We agreed during the meeting that an interim meeting before the next IETF would be required. Eric Crawley would be reporting back on proposed meeting times and venues. [Ed.: This meeting is now scheduled for February 26, 1997 at MIT] ----- Minutes from the ISSLOW Breakout session Reported by Steve Jackowski and Dave Oran Any/all errors inserted by John Wroclawski Meeting Agenda - Complete PPP multi-class multi-link draft (the "Fragment" approach) - Continue discussion of two Suspend/Resume approaches (one from this group, one from QoSPPP -Further work items. Fragmentations and Suspend/Resume discussions Carsten Bormann opened the meeting by asking if there were any questions regarding the current draft (draft-issll-isslow-mcml-00). He clarified the following: Number of traffic classes available: 4 plus 1 (uses 2 bits) in the 12 bit header 16 plus 1 (uses 4 bits) for the 24-bit header more than 9 classes has not been perceived as requirement Options, and interaction with short/long header selection: 18 - 2 specifies short header - 12 bits You must be able to identify multiple classes in both short and long header First negotiate short/long, then class within that agreement (i.e., there is a new option for the number of classes) Prefix Elision Binds a particular class to a higher level protocol traffic stream Used to reduce header overhead Can be used to identify particular connections/flows Carsten then followed with a presentation of issues surrounding the Fragmentation versus Suspend/Resume approaches to achieving delay bounds in the ISSLOW environment. He divided systems into two groups: Type 1 and Type 2. Type 1 systems are those which have bit by bit control over driver input and output. Type 2 systems have byte by byte control, but cannot effect bit oriented control in real time. Examples of Type 2 systems include most routers and any host systems where serial drivers are controlled by the OS. The point of this discussion was to demonstrate that the QoSPPP proposal, which is clearly the most efficient of the proposed suspend/resume solutions, requires hardware changes on many systems and cannot be implemented on existing Type 2 systems. Since QoSPPP proposes implementing suspend/resume (no fragmentation) at the Physical layer, the question was raised as to whether it made sense to implement a Suspend/Resume scheme at a higher layer. The conclusion was that if the modem FIFO is smaller than the smallest fragment sent, Suspend/Resume would have no benefit. It was also noted that the typical FIFO on a modem is 10-15 milliseconds, so that for the transmissions we're focusing on: e.g. IP Telephony, Suspend/Resume could have benefit. Fred Burg, who represented the QoSPPP group, presented numbers that indicated that in comparing the current draft to QoSPPP, the current draft's header overhead and Suspend/Resume approach resulted in roughly 5Kbps of overhead (on a 28.8 link). Steve Jackowski presented numbers demonstrating that with proper scheduling of fragments, the overhead associated with the current draft was in the 1-2Kbps range (on a 28.8 link). Fred Burg then responded that if the overhead were less than 5%, it wasn't worth pursuing the discussions, but that the fragment scheduling, while better, was still borderline. At this point, Carsten Bormann surprised the group by summarizing the two proposals and suggesting a third approach: Draft approach: suspend with CRC and add suspend byte at end of frame - no hardware change QoSPPP approach: suspend with no CRC - hardware change Carsten's New Approach Replace the CRC and the suspend byte in the draft approach with an escape character. Combine the inserted realtime frame with the one currently being sent. The receiver must scan the received frame to find the embedded realtime frame. The only exposure the group could identify was a potential problem with exceeding the MRU when combining frames. This could be resolved through proper negotiation. The group also agreed that this was a promising approach which would likely satisfy the overhead limits acceptable to the group. Carsten committed to updating the draft to include this option and to establish the performance impact of this approach. A number of additional work items were discussed, with the aims of gauging interest and prioritizing the list, as well as technical discussion. The items considered included: - Service mappings - Compressed Tspec format(s) - Link Characterization - reliability of link and delay of the link ( guaranteed needs delay) ( may be covered by PPP link monitoring? ) - Header Compression MIB V4 and V6 - Must examine L2TP impact, particularly in delay bounds. Action Items - Submit current draft to PPPEXT and CRTP in early January - Carsten - Provide Suspend Resume document to group by end of December - Carsten - SVC mappings (upon receipt of latest draft from Carsten) - Steve - Compressed Tspec - Dave - Header compression MIB - Stan? - Link Characterization - TBD - Check into conference bridge for possible interim meeting - end of January - Decide by 1/15 if there is a conference call ----- Slides used at this meeting: GENERAL SESSION General Overview Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/ISSLL_General.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/ISSLL_General.ppt ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/ISSLL_General.ps Anoop's overview of the IS802 Framework: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/is802-framework-overv iew.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/is802-framework-overv iew.ps Eric's IntServ/LANE Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/IntServ_over_LANE.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/IntServ_over_LANE.ppt ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/IntServ_over_LANE.ps IS802 (Some of these slides were used in the General Session as well) Don Hoffman's IS802 Scenario Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/802-scenarios_1up.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/802-scenarios_1up.ps ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/802-scenarios_3up.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/802-scenarios_3up.ps Andrew Smith's Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/draft-issll-802.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/draft-issll-802.ppt ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/draft-issll-802.ps Anoop's Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/is802-framework.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/is802-framework.ps Peter Kim's Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/llrmp_update.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/llrmp_update.ps ISATM Mark Garrett's Slides ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/garrett-atm.ps ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/garrett-atm.pdf Lou Berger's Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/Berger_berson_ATM.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/Berger_berson_ATM.ps Steve Berson's Slides: ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/Berson_berger_ATM.pdf ftp://mercury.lcs.mit.edu/pub/issll/IETF/san_jose_9612/Berson_berger_ATM.ps The WG chairs apologize that we do not have electronic copies of the slides used at the ISSLOW breakout session.