Minutes of the ISSLL Working Group 44th IETF in Minneapolis, MN Co-chairs: Eric Crawley & John Wroclawski Minutes recorded by: Eric Crawley The ISSLL WG met for one session on Wednesday, 3/17/99 from 1300-1500, with approximately 150 attendees. * ISSLOW Service Mapping draft Bruce Davie presented the updates to the ISSLOW service mapping drafts (draft-ietf-issll-isslow-svc-mapping-06.txt). This is a significant revision in response to comments received on the previous draft. The document was reworked from its original form to be more like the other service mapping documents. There were changes to clarify the behavior for guaranteed service and there is a new section on the "acceptable delay" for Intserv flows. A new section was added on example mappings that is much looser than the example mappings used in the IS802 service mapping document. it is believed that all outstanding WG comments have now been addressed, and the document will be sent out for working group last call just after the meeting. Any comments should be sent to the authors ASAP. * SBM configuration and policy Andrew Smith next presented some preliminary work on Subnet Bandwidth Manager (SBM) configuration, for the purpose of introducing the material and asking whether further work on this document should be an ISSLL WG item. The draft discusses a set of manageable objects for RSVP and SBM. As background, Andrew presented a view of the policy model for RAP and RSVP. The decision to admit a flow is divided into two pieces, the portion that determines if the resources are available (Admission Control) and the portion that checks to see if the flow is administratively allowed (Policy). RAP uses the COPS protocol to out-source the decisions on policy. The PDP (Policy Decision Point) needs to be split between the SBM and the policy manager. Andrew discussed a set of groups of objects that could be managed; RSVP protocol config, SBM protocol config, RSVP Local Policy Module configuration, and SBM Local Policy Module configuration. The draft is more concerned with identifying the objects and information needed, rather than the method of transporting the data to the devices involved. Issues: - What parameters - level of specificity - should match current defined services/SBM or be more expandable? (see specific issue discussion below) - Representation (MIBs, etc.) - Fuzzy about the LPM portions (ISSLL may end up owning it because no one else can). Discussion of specific vs expandable: SBM policy as presented is based on the number or lower-layer "classes" in use (3 delay-ranked classes for IntServ flows based on the mapping drafts). There was some discussion about the use of 3 classes since these were really "examples" in the service mapping document. It was agreed that an array of classes might be a better representation. Conclusion of the discussion was that some parts of this are clearly in the scope of ISSLL and should be addressed if WG sees need - which a number of people did. Other parts are less clearly in scope, and may require coordination with other WGs's. No clear allocation of tasks was agreed on. The current working proposal is that we create the parameter list in ISSLL and also do an "SBM MIB" in ISSLL. Some of the RSVP/SBM policy related items configuration and the decision whether to out-source configuration to a policy server probably needs to be a RAP WG item. *Intserv with Diffserv clouds John Wroclawski introduced a new discussion on Intserv using Diffserv clouds. He outlined the problem on the table: Diffserv WG to date has focused on building blocs and intra-domain models while Intserv has focused on e2e QoS for applications. It is technically possible and useful to use Diffserv clouds as part of the Intserv end-to-end QoS story. This allows us to keep and benefit from desirable Diffserv properties. John noted that this is an intentionally narrow problem statement. Particularly, various other e2e QoS approaches have been proposed and are being developed. Also, various people have proposed larger & more general frameworks for QoS that encompass both Intserv and other specific approaches. The goal of the work being discussed here is to utilize the capabilities and technologies that exist today to produce more scalable more deployable e2e QoS services in the short term, without precluding other possible directions in the future. John proposed the following documents for Intserv over Diffserv: - A Framework Document - A Service Mapping Document (implementing Intserv services using diffserv PHB's, edge behaviors, and bandwidth allocation rules) - BW Management approach documents (static provisioning, hierarchical aggregate RSVP, passthrough RSVP) This document set is very similar to the approach taken in the ISSLL WG for IEEE 802 and ATM networks - because the goal of incorporating a diffserv cloud as a network element within the Intserv e2e story is very similar to incorporating an 802 or ATM cloud. So the approach should be familar and workable for ISSLL WG participants. Next, Yoram Bernet discussed presented on draft-ietf-issll-diffserv-rsvp-00.txt. This draft is based on draft-ietf-diffserv-rsvp-02.txt and is the product of changes made both by Bob Braden and Yoram. The goal of this draft is to work towards an Internet in which hosts or their proxies initiate reservations for specific services from the network. It is assumed that the diffserv network provides aggregate traffic handling (though it may process either per-flow or aggregate reservation messages). This enables: 1) Per-flow end-to-end QoS vs. the aggregate edge-to-edge QoS typically associated with diffserv only networks. 2) Scaleability 3) Admission control The focus of this work is on quantitative applications of the sort handled by Intserv today. Some of the work is also applicable to qualitative applications, but that discussion is deferred. There are two high level models of the combined RSVP/intserv/diffserv network. In both models, devices at the edge of the network (typically hosts) use RSVP to signal certain per-flow requirements. On the path between the sending and receiving host(s) there are one or more diffserv networks. In one model, devices external to the diffserv network act as admission control agents for the diffserv network by rejecting or admitting RSVP resource requests. In another model, some number of devices within the diffserv network process some form of RSVP signaling to aid in the task of providing admission control. The first model (no RSVP awareness within the diffserv network) is typically associated with static SLAs and static provisioning within the diffserv network. The second model enables dynamic provisioning within the diffserv network. This may take one of the following forms: 1) Processing per-flow RSVP signaling within the diffserv network. 2) Using aggregate RSVP within the diffserv network (tunnels, RSVP aggregation, possibly MPLS). 3) Providing RSVP interfaces at the edges of the diffserv network and using some form of Oracle or bandwidth broker (tm Van Jacobson) internally. The draft still needs minor work, as follows: 1) Clean up terminology - use consisitent terms for: a) RSVP session admission b) MF classification c) aggregate classification 2) Possibly, pull in the DCLASS spec. Yoram also pointed out other related work within the ISSLL WG: 1) Mapping of Intserv services to diffserv and the corresponding admission control considerations. 2) Multicast. 3) Detailed drafts on diffserv provisioning mechansism including aggregate RSVP, tunneling and possibly MPLS. 4) Define edge device functionality to the point of enabling interoperability. John W. noted that with regard to service mappings (implementation of Intserv services by Diffserv clouds), that the WG can propose new PHBs, if necessary. However, it will be simpler, and may be technically acceptable, to use AF and/or EF, together with appropriate edge behaviors and bandwidth allocation rules, to implement reasonable fascimiles of CL service. G is a little trickier but may be possible as well. John further noted that if new PHB's are proposed the Diffserv WG would be responsible for standardizing them in the IETF, if that was to happen. Beyond the framework document mentioned above several relevant I-D's have appeared in the recent or more distant past. The ones listed here have dealt with some aspect of using RSVP to manage aggregate bandwidth usage, as might be appropriate when packets are forwarded using DS codepoints. - draft-baker-rsvp-aggregation-00.txt - draft-ietf-rsvp-tunnel-02.txt - draft-guerin-aggreg-rsvp-00.txt (timed out, but still at ftp.ietf.org) - draft-berson-rsvp-aggregation-00.txt (timed out, but still at ftp.ietf.org) Some work is presently underway to combine mechanisms from these drafts into a more broadly based RSVP-aggregation document. Hui Zhang gave an informational presentation on his work on Per Hop Behaviors based on Dynamic Packet State. Hui first gave an example to illustrate that in order to achieve worst-case guarantees in current diffserv network, the network utilization by the premium service traffic has to be extremely low. In an environment when this is not acceptable, alternative solutions are needed. He presented a technique called Dynamic Packet State (DPS) that can support a variety of services including guaranteed service (with mathematically proven worst case bounds), distributed admission service, weighted fair share service, penalty box in a diffserv environment. The key advantage of DPS is that even in a network where core routers do not maintain per flow state, the services provided with DPS can achieve similar flexibility, resource utilization, and assurance levels compared to those that can be provided with per flow mechanisms. With DPS, each packet carries in its header, in addition to the PHB codepoint, some PHB-specific state. The state is initialized by the ingress node. Interior nodes process each incoming packet based on the state carried in the packet's header, updating both its internal state and the state in the packet's header before forwarding it to the next hop. Hui also discussed issues of state encoding and several possible places (IP option, MPLS label) to put the the state. Several papers describing the algorithm details can be found at http://www.cs.cmu.edu/~istoica/DPS.