Subject: GSMP WG topic additions

From: "Paul Jardetzky" <[email-masked]>
Date: Thu, 11 Nov 1999 13:08:44 -0800

GSMP Working Group:

We would like to add a few points for discussion tomorrow.

1) It may be desirable to separate the GSMP protocol spec from 
the suggested encapsulation formats. The proposal is to move the
encapsulation formats to an applicability document.

2) An easy way to make error codes applicable to different
service/port types is to have the notion of a primary error
code and an extended error code. We'd like to discuss the
options on how to accomplish this with the current message
format.

3) The GSMP MIB could have a way to set the transport 
protocol parameters for GSMP messages. For example, the
management entity might set the port number to which the
GSMP slave binds. This would allow multiple GSMP slaves
to exist on the same switch. This allows the ability to
implement a GSMP slave per partition.

4) We might want to consider an event to alert the 
controller when the resources on a port change. This may
be useful for partitioned switches.

5) In the port management PDUs, section 5.1, connections are
deleted only when the port is brought back to the "up" state.
Since in partitioned switches the only way to stop the flow
of cells between input and output port is to not have a 
connection, we propose that connections get deleted also when 
a port is brought down.

Thanks,
- Paul

-----------------------------------------------------------
Paul Jardetzky
CPlane Inc.                   Phone: +1 (650) 938-8066 x111
5150 El Camino Real           Fax  : +1 (650) 938-8068
Suite B-31                   Mobile: +1 (650) 619-3227
Los Altos, CA 94022

---

From: Joachim Buerkle <[email-masked]>
Date: Fri, 12 Nov 1999 00:20:24 -0500

Thanks Paul,
I see the following in the same way.

> be useful for partitioned switches.

I fully support this, since I am writing in the moment a
draft to extend the event types:

"                      Further Events for GSMP
                 <draft-buerkle-gsmp-events-00.txt>

Overview
   This draft proposes the definition of further Event Types for
   VPCs/VCCs. Till now GSMP supports only Events which
   are Port related.
   Furthermore this draft proposes the definition of an event for
   the case of "graceful blocking" of a Port through the operator.
"

This is by the way also a reason why we need the 'ack' of events.

I hope we have tomorrow time to talk about these issues.

> connection, we propose that connections get deleted also when

This is related with the issue of "graceful blocking" and
the for VB5 necessary Events after a "lock" and "unlock"
of a connection by the operator.

c.u. tomorrow
Best Regards
Joachim

By the way: What the hell is "graceful blocking"?

"
   'Graceful blocking' is a conditional shutdown of a physical or
virtual
   switch port. The condition for the shutdown is that the applications
   have released all their connections at this port.

   The sequence of operation of 'graceful blocking' is as follows. The
   Operator initiates at the management interface of a switch the
'graceful
   blocking' command for a physical or a virtual port. In the case of a
   physical port the switch must send an event via GSMP to all virtual
   switch controller which have a partition at this physical port.

   In the case of a virtual port the switch must send the event via GSMP

   only to the Switch controller of this partition where the virtual
port
   is a part of.

   The switch controller(s) knows with this event also that the switch
will
   not accept any further connection (add branch messages) at this port.

   The switch controller(s) will also not accept any further connection
at
   this port and will wait after they got this event till all on-demand-

   connections (connections initiated by signaling) are deleted or
released.
   If all on-demand-connections are deleted or released the switch
controller
   deletes or releases also all the permanent connections (resources) at

   this port in his partition. Afterwards the controller(s) sends a
   acknowledgement to the switch and the switch will ‘lock’ the port if
he
   got from all informed switch controllers an acknowledgement.

   Note: If the switch controller is loosing the synchronization with
the
         switch after the switch sent a graceful blocking event, this
         state must be resynchronized if the switch controller as again
         a connection to the switch.

   Note: Graceful blocking can be seen a the GSMP interface as an
extended
         case of the failure case in which a port is not longer
available
         because of a failure.

   Note: GSMP must support acknowledgements for events also in this
case.

   The Graceful blocking message is:

      Message Type = xx   (tbd. by the GSMP WG)
"