Subject: managing output label ranges

From: "tom worster" <[email-masked]>
Date: Thu, 2 Mar 2000 14:38:00 -0500

at the editing session in new orleans it was requested that gsmp
manage output label ranges. this involves introducing fields or
message into the port management messages to report and change
output label ranges on each port on each partition, checking that
the output labels in connection management messages are within
the specified range and issuing error responses if they are not.

it may not be necessary to include output label management in the
port management messages if we specify in the protocol spec that 
a port's output label range always matches its input label range.
however, this would lead to a loss of generality over the current
protocol spec which could be a problem in mpls applications.

the desire to include this feature stems from a desire to prevent
controllers from establishing connections outside of their 
partitions' allocated resources.

my opinion on the proposal is as follows. the legality of a 
given value of a label at an output port is a matter for the
network layer (i'm using the term network layer rather loosely). 
gsmp is supposed to be ignorant of network layer issues as far as 
possible and we have a basic assumption in the design of gsmp 
that controllers know what they are doing. there are very many 
ways that an errant controller can cause trouble and establishing 
connections to output ports that are illegal at the network layer 
is just one way. we have not in the past attempted to "police" 
the controller's behaviour by installing state in the switch that 
prevents control plane errors at the network layer. i therefore
argue against the proposal on the grounds that it is neither
necessary nor easy to do.

an interesting related issue is that gsmp lets the controller
manipulate label ranges. this reasonable as far as gsmp is 
concerned but allows controller behaviour that is very illegal 
in the msf switch control architecture. 

any other opinions?

c u
tom

---

From: Jaroslaw Sydir <[email-masked]>
Date: Thu, 02 Mar 2000 13:49:36 -0800

Tom,

Last year, the Partition Id field was added to GSMP messages, in order
to allow a GSMP controller to control a partition of a switch, rather
then just the complete switch. Just to make sure that we are in sync,
our definition of a partion is an arbitrary subset of switch resources,
which are either reserved exclusively for the controller that owns the
partition or are shared with other partitions according to some policy.
The simplest model is to partition resources for the exclusive use of
individual controllers, allowing them to operate on their partition,
oblivious to the fact that they are controlling only a subset of the
switch resources and that other subets of the switch resources are being
controlled by other controllers. 

When switch partitions are created on switches throughout a network,
they form a partition of the network (a virtual network). In order for
this to work, the resources assigned to adjacent switch partitions
(within the same network partition) must match. That is the outgoing
bandwidth at one end of a virtual link (a partition of a link) must
match the incoming bandwidth of the adjacent switch partition. Similarly
the outgoing labels used by a partition must match the incoming labels
of the adjacent partition. When such network partitions are set up
properly they can be used to host different services over the same
network (e.g., MPLS and native ATM) or to host individual VPNs.

In order for this model to work, the switches must guarantee that
errant/malicious controllers cannot affect the operations of other
partitions. Within a virtual network (network partition) the peer
controllers are free to make whatever errors they like, and I agree with
you that it is not the job of the GSMP slave to try to protect them from
themselves. However it is critial that a partitionable switch police the
actions of controllers to make certain that they do not interfere with
each other and GSMP, as the protocol used to control a partition must
carry the messages that enable this.

In a partitioned network, the ability to use an outgoing label outside
the range of incoming labels assigned to the adjacent partition, gives
an errant or malicious controller the ability to send traffic into an
unrelated network partition. This is clearly not desirable.

To illustrate, here is an example. Switch 1 is connected to switch 2 via
link 1. Assume that link 1 plugs into Port 0 on both switches.
Partition A on Switch 1 is part of the same virtual network as
Partition A on switch 2. Assuming that we assign only incoming label
space, 
partition A on switch 1 will have some label range (which I've omitted
in the diagram)
and Partition A on switch 2 will have an incoming label range, which
I've 
assigned to be VPI 0 VCI 1-10. Similarly there is a second pair of
partitions (B),
which are part of a different virtual network. The resources specified
in the example
are port resources on the ports which are connected by link 1 (ports 0),
so the two 
partitions share resources on the link. Now, if things are to work
correctly the 
controller for Partition A on switch 1 creates a connection accross
switch 1 from some incoming port, vpi, vci to say port 0 vpi 0 vci 1.
This will cause cells to be routed to Partition A on switch 2 which is
within the same virtual network. 

On the other hand, if the controller of Partition A on switch 1 sends a
request to 
create a connection from some incoming port, vpi,vci to port 0 vpi 0 vci
15, the
cells flowing to that connection will flow into Partition B on switch 2
and thus
into a different virtual network. There will be no way to prevent the
controller of
partition A from messing with Partition B.

      -------------------                           
---------------------
     |  Switch 1         |                          |   Switch
2          |   
     | ----------------  | Port 0            Port 0 | 
-----------------  |   
     ||Partition A     | |         Link 1           | | Partition A    
| |   
     || BW: 5 Mbs      | |--------------------------| | BW: 5 Mbs      
| |   
     ||                | |                          | | Incoming       
| |   
     ||                | |                          | | Labels:        
| |   
     ||                | |                          | | vpi 0 vci 1- 10
| |   
     | ----------------  |==========================| 
-----------------  |   
     |                   |                         
|                     |   
     | ----------------  |                          | 
-----------------| |   
     ||Partition B     | |                          | | Partition B    
| |   
     || BW: 10 Mbs     | |                          | | BW: 10 Mbs     
| |   
     ||                | |--------------------------  | Incoming       
| |   
     ||                | |                          | | Labels:        
| | 
     ||                | |                          | | vpi 0 vci 11-20
| |  
     | ----------------  |                          | 
-----------------  |   
     |                   |                         
|                     |   
     |                   |                         
|                     |   
     |                   |                         
|                     |   
      -------------------                           
---------------------

So to summarize my lengthy note, we believe that it is a fundamental
responsiblity of a partitionable switch to disallow a controller of a
partition from interferring with the operation of any other partition.
Furthermore, we believe that the resources of a partition should
explicitly include outgoing labels and that the GSMP connection
management requests be policed to disallow connections from using labels
outside this range. We therefore restate our proposal that the Port
information message response include both incoming and outgoing label
ranges and the the GSMP slave police the use of both incoming and
outgoing labels.

Regards,
Jerry Sydir

---

From: "Simon Crosby" <[email-masked]>
Date: Fri, 3 Mar 2000 08:57:54 -0800

Good reply.

S

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jaroslaw Sydir
> Sent: Thursday, March 02, 2000 1:50 PM
> To: [email-masked]
> Subject: Re: managing output label ranges
> 
> 
> Tom,
> 
>      ||                | |                          | | 
> Incoming       
>      ||                | |                          | | 
> Labels:        
>      ||                | |                          | | 
> Labels: