Subject: Proposed dynamic partitioning architecture

From: "Anderson, Todd A" <[email-masked]>
Date: Thu, 4 Jan 2001 17:21:43 -0800

If we wish to allow for partitions to be dynamically scaled at
run-time there are a couple of issues to be addressed.  First, 
who initiates the repartitioning on the switch?  Second, how is 
the controller notified of the increase or decrease in resources.
Below is a picture that illustrates my proposal for the answers
to these questions.  As always, comments are highly appreciated.

           |
           | 3        
           |
   ------------------             -------------------
   |     Switch     |       3     |                 |
   |    Partition   |-------------|   Controller    |
   |     Manager    |             |                 |
   ------------------             -------------------
                 \  \              /  /
                  \  \            /  /
                 4 \  \ 1      2 /  / 5
                    \  \        /  /      
                    -----------------
                    |               |
                    |    Switch     |
                    |               |
                    -----------------

1.  Switch Partition Manager (SPM) partitions the switch and assigns 
    partition IDs.
2.  Controller connects to the partition and queries the partition to 
    determine its capabilities.
3.  Either the controller reports a lack of resources to the SPM, an 
    external entity informs the SPM that a partition's resources should 
    be changed, or the SPM asynchronously decides that the partition's 
     resources must be changed.
4.  The SPM repartitions the switch.
5.  The switch notifies the controller that the available resources 
    have changed.

With respect to GSMP, I think this proposal has the benefit that the 
controller continues to not be involved in the original partitioning 
of the switch, nor is it directly involved in the repartitioning.  The 
controller may be indirectly involved in the partitioning in that it 
may somehow report low resource availability on the switch to the SPM 
but this is not a requirement.

The only change that this architecture forces upon GSMP is that the
switch needs to be able to inform the controller of a change in
resources.  Are there any suggestions as to how to do this?  The strawman
is to break the connection and restart the adjacency protocol.  Is the
efficiency of a new GSMP message to inform the controller of a resource
change worth it?

Regards,

Todd A. Anderson
Intel Architecture Labs

---

From: "tom worster" <[email-masked]>
Date: Thu, 4 Jan 2001 22:34:56 -0500

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anderson, Todd A
> the controller notified of the increase or decrease in resources.

before i get into that, may i first ask about the
dynamic partitioning requirements? specifically: is
it required that a partition maintain the connection 
state that is unaffected by the change in available
resources to the partition through the repartitioning 
action?

c u
fsb

---

From: "Avri Doria" <[email-masked]>
Date: Thu, 04 Jan 2001 23:20:20 -0500

Hi,

Obvioulsy we have not written any requirements for this yet,
but my assumption is that repartioning is not dynamic if it
requires that existing state be lost or that adjacency needs
to be reestablished.

My inclination would be that resources could be added to a 
partition without difficulty, but that they could only be
removed if they were not in use.  To remove assigned resources
that were in use should be prohibited.

Regards,

a.

-- 

Avri Doria
+1 401 663 5024

---

From: "tom worster" <[email-masked]>
Date: Mon, 8 Jan 2001 09:42:06 -0500

>
> As always, comments are highly appreciated.

i think all of what you suggest can reasonably be done.

my concern is how the overall system deals with an spm
that is trying to take resources (ports, labels, bw)
away from a controller that has them in use for
established connections. we need to decide how the
switch will react to such a conflict when it is
presented with one.

on the one hand, if i understand the concept of
“dynamic partitioning” correctly, the spm is always a
higher authority than any controller. on the other, a
partition is subservient to its controller and has no
business withdrawing resources in use. so it seems to
me that a switch should refuse such a conflicting
request from an spm on the grounds that the spm must
resolve the conflict with the respective controller
before withdrawing the switch resources. the means of
such resolution being outside of gsmp.

however, in this proposal there is a burden on the
switch since it is required to be able to detect the
conflict: a thoroughly non-trivial task. this is bad
because it's an expensive error check for a condition
that should never happen.

what are the alternatives? if the spm really is
superior to all controllers and we assume its sanity
(as we always do with controllers in the gsmp model)
then we could suppose that the spm has good reason to
take the action of removing resources in use by a
controller, e.g. the controller is not co-operating
for whatever reason. so the switch removes the
impacted connection state and repartitions.

i'm not at all sure that the second model is any
worse that the first.

coming back to the first model: if an spm is unable
to cajole a controller into releasing switch resources,
what is it do? this question is not really a gsmp
question, although the answer may have impact on gsmp,
but it highlights how we need more discussion on the
architectural requirements of "dynamic partitioning."

> resources.  Are there any suggestions as to how to do this?

i'd prefer an explicit notification.

> The strawman

the circumstances under which a switch pulls the plug
on its controller ought to be a bit more severe than
this. after all, the switch is just executing a gsmp
command like any other -- this should be routine.

c u
fsb