Draft Minutes of Meeting of BT SuperJANET URI MMN technical sub-committee on Management of Policies. Meeting at IC DOC, Jan 6th, 1995, 11-1.30. Attendees James Cowan Jon Crowcroft Morris Sloman Nat Pryce Emil Lupu Damien Marriott ... Agenda Policy Notation Implementation What to Manage Mbone ATM T&D of Next Meet Policy Notation We discussed the IC notation, and related notations. Crowcroft presented the ideas from a) Clark's notation for constraining routes (RFC 1102). It was agreed this was really an Access Control specification system b) The traffic classes and policies in the Internet Integrated Services working group (RFC 1633). These include some interesting ideas of service class, specification, implmenation, negotiation, and replacement strategies. c) The ATM (specifically, the ATM Forum Traffic Management working group) ideas on traffic classes: There is a traffic class hierarchy: CBR (Constant - equivalent to existing synchronous services) VBR (Variable, leaky bucket) VBR+ (Mix of VBR and ABR) ABR (Available- Fair share - typically Hierarchical Round Robin) UBR (Unspecified) A policy might be a permitted mix of these classes. A more subtle policy might involve time of day, or relative mixes, or indeed functions that permit borrowing of bandwidth between underutilised classes. A mechanism might be a hierarchical round robin with priorities, with a particular instance being a time of day, a number of hierarchies and a number of priorities, with a particular population of virtual calls through a given switch, or given administrative domain. Action 1: UCL - ask UKERNA for statement of existing real world policies on SuperJANET. Refine document on policies so it can be converted to IC's notation. We need to derive at least 2 levels - one is a statement of the policies, another is the abstract service specification. [another mightr be how to combine service specs and policies across multiple domains, or whether this is ever a meaningful thing to do.... This latter is for future study). Implementation There was some discussion about scripting languages [see attached message for why]. We will (IC and UCL) investigate availability of General Magoc's Telescript specification, but otherwise, we will use Tcl and its dferivatives. UCL intend adding Tcl interpreters to management agents. IC already have Tcl in Remus and some form of integration with ANSAware. However, we must look at Tcl access to C++ objects (e.g. via Orbix repository) to get full power required. We Looked at The 2 level split of implemenation work, as attached below again. This seems the right division of layer We will produce a workplan that shows what can be done over the next year and a half. Expectation is that we can demonstrate at least the notation in use this year, but realistic application to existing systems is a very much larger piece of work. For example, investageing adding Tcl interpreters into Orbix is 3-6 months work. Damien and James to collaborate here to see how the work with policy notation and TCL scripts that carry out actions inter-relates. What to Manage UCL will look at the Fore MIB to see whether we can manage the traffic classes directly. This may be feasible, since in priciple one can set the policing parameters to the different classes (this is certainly the case in the Netcomm/GDC DV2 type siwtches, even idf they don't act properly on it). IC will look at manageing traffic sources on ATM equipped workstations. For example, we can manage the cell peak burst length parameter as well as writing applications that use the fore API and can be managed. Mbone & ATM Kevin Twidle (sp?) joined us to discuss IC Mbone access and ATM setup. UCL and IC will do some diagnostics on normal Mbone access from IC to see if we can improve that. IC have their ASX200 (and will be getting a Phillips 4*4 experiemnatl switch) and should be fiber connected via their center to superJANET in the next few weeks. We will look into Abone access from then. ACTION 2. Jon Crowcroft will contact Bob Day, John Dyer and the JIPS Nosc to ascertain whether we can use the existing IP net nukber for our IP over ATM connectivity or should get another IP address. T&D of Next Meet We'll try to have a meeting with BT around 20th or so. (aprt from the existing mgmt meet 28th of mar at IC and tech meet 1st mar at UCL) ACTION 3. UCL & IC: set up accounts for each other to use systems ACTION 4. All: set up local mail distribution lists to fan out mmn main list from ucl. Jon Crowcroft ---------------------------------------------------- We are interested in using Corba, we do not want to give up our work in Internet management and more generally we prefer a slant towards tcp/ip). Initially we are interested in building interpreters in Corba servers and Snmp agents. We probably want to use a version of Tcl because Tcl is widely used in Snmp management but only in managers and not agents. We are also interested in seeing how you get Corba/TCL and Snmp/TCL agents to interoperate - we discussed some of the issues in the document on the MIB interpreter. The approach we have adopted has a slant of just getting an(y) interpreted language working within agents that currently deal with behaviour statically. It seems to me (and Ian mentioned this as well) that there is a problem of managing the downloaded interpreted code and a higher level tier that manages these policy statements is what is needed. It may be worth thinking about an approach where we concentrate on getting say TCL working at the lower levels and you concentrate on the management of these lower level agents that execute interpreted code. A key question (in terms of effort) is deciding what to manage. As mentioned in one of the documents that I sent you, there are three levels where one can apply policies - within the network (eg managing the fore switch or Ian Wakeman's class based queuing system), in the end system managing the protocol stack and ultimately managing applications. The last is probably the most interesting - distributed applications where you do not in advance what the bandwidth requirements (e.g. information retrieval systems) raise very interesting problems. All this could soak up loads of effort (eg cbq is not currently manageable, protocol stacks are not manageable and most applications are not manageable). Any plan to tackle these areas will certainly be long term! James Cowan