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.