CURRENT_MEETING_REPORT_ Reported by Andy Nicholson/Cray Research, Inc. CBNR BOF Minutes These are the Minutes from the ``Conditioning of By-Request Network Resources'' Birds of a Feather session which met at the St. Louis IETF. Due to the small size and informality of the meeting, no formal minutes were taken. This record is believed to be reasonably accurate and proper credit given to the originators of the ideas and concepts presented. My apologizes for any errors or omissions. The meeting began with a short exposition from Andy Nicholson about the purpose of the meeting and some description of work done at Cray Research Inc., for the support of Circuit Switched T3 networks. While working with circuit-switched T3 networks, developers at Cray Research Inc., determined that there would be advantages to defining a standard way to control certain classes of network resources through the internet. In the case of a circuit-switched T3 line, the line should be switched on only when there are active transport connections which can fully utilize the service. Due to the high cost of the resource, underutilization would be particularly undesirable. The developers believe that this capability might have other applications in the internet and that an effort should be made to define a standard protocol. It was noted that this work involved a host on the internet sending internet messages to another host which communicated with a T3 switch, and could turn the switch on and off. Dan Friedman offered the suggestion that a more refined architectural model could be used and that hosts would often be less concerned with accessing a particular network connection than with making a particular class of service available. He suggested that messages should be formatted to request an abstract service, rather than control a specific service provider directly. Jeff Young and Andy Nicholson were both uncomfortable with this idea, as existing products do not exist to use this capability, and Cray Research was already working to provide a resource-specific allocation capability for interested customers. They felt that it was necessary to support direct access to specific resources. Numerous discussions followed, during which Dan also noted that routing policy would be involved in decisions whether to allocate network resource. A four-layer architectural model emerged from these discussions: 1 o Policy Layer Handles policy questions like ``Will I allocate a resource to satisfy this request from this requester?'' o Resource Layer Makes decisions regarding which of many possible resources to allocate to satisfy a particular request. o Action Layer Handles the mechanics of allocating a particular instance of a type of resource. o Hardware Layer Actual network resources to be allocated and deallocated. In an actual system, each layer would be represented by some processing occurring on a host somewhere in the internet, except for the hardware layer which might not be capable of internet connectivity (i.e., a T3 circuit switch accessible only by a dialup line). When a resource is desired, a message would be sent to the ``Policy Manager'' (the entity residing at the policy layer), which would determine the disposition of the request. In a real system, the Policy and Resource managers might be null, and simply pass requests on the layer below. This will allow the implementation of a system where a host makes direct requests for specific network resources (i.e., a specific T3 switch to connect two particular hosts). It was also agreed that routing policy is being explored by another group, so we would not work on policy layer issues. Furthermore, we did not see an immediate need to work on resource layer issues. We agreed that since there is an immediate need to define an interface to the action layer, we would work on that. The interface between the action layer and the hardware layer is hardware-dependent, and will need to be implemented on a case-by-case basis. In the model, action layer direct messages would be sent to the policy layer, but neither the policy nor resource layers are yet defined and exist as null entities. Some of the information that the action manager would require appeared obvious and was: o Request type - what to do. o Resource identifier - what to do it to. o Status - probably a return value. o endpoints - parties using the allocated resource. 2 Jeff Young postulated that there might be some vendor-specific information associated with the allocation of a specific resource. Jeff felt that this information might best be stored with the entity requesting the service and that the vendor specific information be passed in the request message from the requester. Not all were thrilled with this idea and it was suggested that this information should be maintained by the action manager and that the resource identifier should be sufficient to find any vendor-specific information that might be required to allocate the resource. It was also suggested that there might be accounting information in the request messages, but it was noted that this might not always be necessary. It was also suggested that only the policy and/or resource managers would be interested in this information and that it should not be propagated to the action manager. The vendor-specific data and accounting information issues got alot of discussion, and it was suggested that we could define a message option format, much like tcp or ip options. In addition, we could pre-define at least two option types, vendor-specific data and accounting information. This idea was not universally popular either. If we meet at the next IETF (as the Chair hopes), these issues will require further discussion. In the closing minutes of the meeting (it should be noted that we met on two consecutive nights), we came up with some additional details. We would put the address of the intended manager into the request messages. If the manager receiving a message is not the intended recipient, then that manager will forward the message (as in the case of a policy manager receiving action manager messages). We also considered the possibility of a hierarchical message format, wherein the core message is an action manager message, and resource and policy information are added to the core message format, depending on the granularity of the requester's request. This was not decided at this meeting. Dan Freidman and Andy Nicholson agreed to do some work on an RFC to document the protocol the group is working on. If the interested parties are able, we will meet at the next IETF meeting. Attendees David Borman dab@cray.com Daniel Friedman danfriedman@bbn.com 3 Joseph Golio golio@cray.com Andy Nicholson droid@cray.com Jeff Young jsy@cray.com 4