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