Minutes of the ISSLL WG Meeting - 45th IETF - Oslo, NO, July 15, 1999 1:00-3:00 The WG held one two-hour meeting at the 45th IETF. The first part of the meeting was dedicated to a review of old business status, and discussion of one open IS802 issue, the Subnet Bandwidth Manager MIB. The remainder of the meeting was devoted to discussion of Intserv/Diffserv mapping issues (ISDIFF). The final agenda for this meeting is available as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/agenda.pdf Old business status: The chair reported that WG work on the IS802 and ISSLOW primary documents has been completed, and the documents forwarded to the AD and the IESG for comments and IETF last-call. Subnet Bandwidth Manager MIB: Andrew Smith presented work in progress on the SBM MIB, draft-ietf-issll-is802-sbm-mib-00.txt. The presentation is available as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Smith_SBM_MIB.pdf http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/smith/index.htm The major change since the previous version (which was draft-smith-...) is the removal of those MIB variables that were concerned with policy issues. The MIB is now closely focused on the SBM protocol and mechanics. Andrew's presentation identified several open issues, which are documented on the last slide of the presentation. In addition to these open issues, there is still some uncertainty about the relation of this MIB to other MIBS, including the general INTSERV MIG and the evolving DIFFSERV MIB. Andrew is raising these issues in other WG's as well. Discussion requested on the list. Yoram Bernet noted the absence of a MIB variable to determine whether an SBM was eligible to participate in the DSBM election. Keith McCloghrie suggested that the "supported but disabled" indicator served this purpose. After some discussion, the meeting concluded that this was inadequate, and two indicators were needed - SBM disabled and SBM enabled but not eligible to be DSBM. Discussion turned to open issue 3 on Andrew's list: should the MIB allow the creation of new SBM instances? The current MIB only allows configuration of existing SBM instances. After some discussion the meeting agreed on this approach, and the issue is considered closed. Intserv/Diffserv/RSVP Overview: John Wroclawski presented a brief review of the ISDIFF topic, to set the stage for the remainder of the meeting. The presentation summarized how a diffserv cloud might be used within the end-to-end intserv model, and how each of the work items to be discussed in the meeting fit into that picture. Slides are avalable as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Wroclawski_isdiff_intro.pdf http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/wroc1/index.htm Qualitative (Null) Service: Yoram Bernet presented draft-moore-qualservice-00.txt, a proposal for a new Intserv service that is intended to allow for policy-driven QoS in an intserv or signalled diffserv environment. Slides are available as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Bernet_qualservice.pdf http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/bernet/index.htm An intserv service request, together with related identity and policy information, can be viewed as a way to say "here's who I am, here's what I want to do, and here's what I need from my end-to-end network path". In the case of Guaranteed service, "here's what I need" is the mathematical delay bound information and strict bandwidth reservation. In the case of Controlled-Load, "here's what i need" is the provision of an unloaded path. In the case of the new service, "here's what i need" is null. The purpose of the service is thus to say only "here's who I am and here's what I want to do". This allows a third-party or policy component to decide what is needed end-to-end, or alternatively to allow each element of the end-to-end path to provide whatever service that element has agreed to provide to the requesting customer. Discussion after the presentation turned to the question of whether the service should support the ability for the user to provide some information about the desired end-to-end service, such as a delay "hint". In the current draft, this is not supported. A vigorous discussion revealed that the meeting was split into two camps. One group argued that it would be useful for the service to support these non-binding hints, with (numerical) delay as the specific example. The other group argued that non-binding quantitative hints were not particularly useful to applications, that honoring such hints would require more information from the application (in the TSPEC) than was desirable for this service, and that the choice of which hints to support would complicate the process of defining the service too much. This question was not resolved in the meeting. The draft authors will issue a new version addressing some minor points shortly. Discussion of the open question will be taken to the mailing list. Intserv/Diffserv Framework Document: Bruce Davie presented the ISDIFF Framework document, draft-ietf-issll-diffserv-rsvp-02.txt. This document describes the overall framework for use of diffserv clouds as intserv network elements. The presentation is available as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Davie_isdiff_fwork.pdf http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/davie/index.htm This document has been through several revisions, and is now believed by the authors to be substantially complete. Changes from the previous version include expansion of the sections on service mapping and microflow "isolation" in an aggregate scheduling situation like diffserv, decoupling of the diffserv cloud behavior from any assumptions about end-to-end use of RSVP as a signaling protocol, clarification of issues related to which network component does DSCP marking in different situations, and cleanup of several definitions. The significant missing piece is an adequate discussion of multicast considerations. Kathie Nichols raised some questions about terminology, and asked whether the model supported concatenating several administratively separate diffserv clouds into a single diffserv region. Bruce said that the intent of the framework was to support this, and agreed with Kathie's suggestions for clarifying this. Yoram Bernet raised the issue of how configuration of network elements would be done in the framework. This includes not only things like static bandwidth allocation policies, but also more mechanical things like which network element is responsible for DS marking. It was suggested that this configuration was expressed by MIBs and PIB's. The chair asked whether developing the needed MIBS/PIBS should be a WG issue. Fred Baker said that the WG was responsible for all of this work. Keith McCloghrie suggested that the WG might not be responsible for developing a PIB, and pointed out that the RAP working group was doing COPS protocol object definition for controlling things developed in other WG's. Fred said that the IETF now had a policy for all this, but that it was not fully in effect because the work area was relatively new. After some further discussion, the chair tabled the issue. Advice from the AD will be obtained when the question becomes immediate. DCLASS object: (now draft-ietf-issll-dclass-00.txt) Yoram Bernet gave a brief presentation on the DCLASS object (no slides). The purpose of the DCLASS object is to carry information from a diffserv cloud to an upstream network element (host, upstream router, etc) that is responsible for setting the DSCP field in the packets it is sending to the cloud. The standard example of how this might be used is to carry DSCP marking information to a host that has made a service request via RSVP, but there are other ways the object might be used as well. Yoram noted that the major change since the last version of the spec was to allow for a list of DSCP's in the object, rather than a single DSCP. A question was asked about ordering of DSCP's in the DCLASS object, and how it related to the service being provided. A discussion about how diffserv capabilities might be used for different purposes ensued. The chair suggested that this discussion was important but not directly related to the DCLASS object, and that the object definition spec should be treated as a very low-level, syntactic thing - "here is how DSCP's are represented in an RSVP object". Then, different uses the DCLASS object can impose whatever meaning they need on top of this representation, and define that meaning in the appropriate documents. The WG agreed to this path. A new version of the I-D will be issued with all higher-level semantics removed from the definition. This version will become a WG document (the previous version was draft-bernet...). Walter Weiss asked whether it would be appropriate to use the PHB identifier format presented by Scott Brim in the Diffserv meeting here, rather than the DSCP. Bruce Davie and others responded that that was a completely different thing, and the purpose of this object was to represent and carry code points, not PHB names. Further discussion was pushed to the mailing list by the chair. RSVP Aggregation: Fred Baker presented draft-baker-rsvp-aggregation-01.txt, a document describing in detail the use of RSVP to manage bandwidth on an aggregated basis in a DS cloud. Slides of this presentation are available as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Baker_RSVP_aggreg.pdf http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/baker/index.htm Fred's presentation discussed different things that can be aggregated (packet classification state, scheduling state, reservation/bandwidth allocation/admission control state) and why it is useful to separate them, presented several motications for this aggregation, and described the mechanisms used to do this with RSVP. This work has advanced significantly since the previous version of the document was published. The most significant change is that the multicast story has converged. The current draft adopts a mechanism that aggregates classification and scheduling state, but not reservation state. This is because there appears to be no simple way to manage aggregate reservation state for multicast data flows with potentially different topologies except by allowing significant over-reservation of resources, which is unacceptable. Another significant change is the work by the authors and others to bring this draft into as much alignment as possible with the RSVP tunnel draft, which addresses a similiar problem. Several changes have been made, and all remaining differences are now seen to be because of differences in the underlying problems. Fred reported that with this revision the authors believe that the spec is solid and complete, and ready for broad review. At least one prototype implementation is underway. This work will be published as draft-ietf-issll-rsvp-aggregation in its next version. Remaining ISDIFF Documents: John Wroclawski gave a brief presentation about the remaining documents needed to complete the ISDIFF work. Slides are available as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Wroclawski_isdiff_docs.pdf http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/wroc2/index.htm The documents that are presently seen to be missing are: a "service mapping" document, which discusses how to select PHB's and edge actions that cause a DS cloud to effectively act as an intserv network element. a standards-track RSVP-use document, which describes any specific interoperability issues that are needed to support use of RSVP to glue DS and other clouds together in this way. A specific issue that was discovered just before the meeting was the need for a DSCP marking negotiation protocol, to determine which network element (DS cloud edge or some upstream device) is responsible for marking packets. Neither of these documents is beyond a very early stage. The service mapping document in particular will draw from several previously published drafts, but more work is needed. People interested in working on these topics should send email to the list or to John directly. This completed the discussion of the working group's ISDIFF work items. Work in Progress: Nitsan Elfassy gave a presentation of draft-sgai-rsvp-plus-00.txt. This is work in progress by the draft authors and others, presented for the information of the WG. Slides of this presentation are available as: http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/Elfassy_RSVP_plus.pdf http://mercury.lcs.mit.edu/ISSLL/meetings/7.99/elfassy/index.htm RSVP-plus is an attempt to place many of the various ways that RSVP and policy engines interact under a single umbrella, and to add some additional capabilities to the RSVP protocol, also controlled by a policy engine. Nitsan noted that some of the issues previously discussed in the meeting, such as the choice of when to use an aggregate reservation versus when to establish a separate per-flow reservation through a cloud, were things that might be controlled by a policy engine, and thus overlapped with RSVP-plus. One part of Nitsan's presentation reviewed the various actions that might require policy input in the current RSVP/Diffserv/Intserv picture, and discussed why this control was useful. The larger part of Nitsan's presentation argued that the RSVP model should be modified to remove the end-to-end signaling assumption inherent in the current protocol. Instead, policy engines would be able to decide, in any given case, whether RSVP messages should flow end-to-end or through some smaller portion of the network data path. This part of the presentation was controversial. An initial question (Raj Yavatkar?) was whether this proposal was to "optimize" RSVP by eliminating the end-to-end message flow in cases where the - appearance- of end-to-end semantics could be preserved, or whether the proposers were suggesting extending the range of semantics of the protocol. Nitsan replied that the proposers were suggesting extending the semantics. Keith McCloghrie suggested an example where a host might not know whether the network policy for a particular service was to give e2e QoS assurance or something else, and thus would want to use the same signaling protocol in either case. Another point raised that the model presented in the talk was essentially sender-oriented, and that the proposal seemed not to consider the receiver-oriented model of current RSVP. At this point the meeting was 15 minutes past the scheduled close. The chair reiterated that this level of change to the RSVP protocol itself would fall either to the RSVP WG or a newly chartered WG, and suggested that the discussion continue after the meeting. The meeting was officially adjourned at 3:15, though a corner discussion of Nitsan's presentation continued for some time.