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.