next up previous
Next: Overview Up: Introduction Previous: Are future reservations needed?


Contribution

The first problem we address is that the generic nature of high-level primitives prevents applications from exploiting application-specific knowledge. As an example, consider Figure [*]. The nature of an application ${\cal A}$ may be such that at any time only one of the endpoints is active as source and every endpoint Ci+1 becomes the source exactly Ti(t) seconds after its neighbour Ci became active as source (i.e. the source moves in clockwise direction, assuming addition is mod 4). For application ${\cal A}$, the connections to be made are determined by the following algorithm: if the last connection from Ci was a multicast, then a connection is made across switch S from Ci to Ci+2, else a multicast connection is made from Ci to Ci+1 and Ci+3. For good performance, it would be useful for ${\cal A}$ to set up all connections to and from the central switch S so a change of source only requires changing the switch connection in S according to the algorithm. This is hard to do using high-level end-to-end primitives. While this example lies almost entirely within the control plane, a similar example for the management plane may consist of gathering and manipulating management information whenever some application-specific event occurs.

As a solution, we introduce a MCA which allows applications to load their own code into the network, i.e. to program the network. This, combined with the ability to reserve and allocate arbitrary collections of resources in the network, opens up the control and management architecture to incorporate application-specific behaviour. Although beyond the scope of this paper, we observe that advance reservations are also explicitly supported. The code is able to interact with the MCA at a very low level, enabling applications to have their own policies executed both in the reservation and allocation domain. Applications can even extend the MCA with new operations which are accessible to other applications as well.

This brings us to the second problem. The solution of loading application-specific code as described above allows applications to introduce application-specific policies, into the heart of the MCA controlling a certain MCA domain. Many applications, however, extend beyond the boundaries of a single control and management domain. We would like to support these applications in a similar way. The challenge here is twofold.

Firstly, different types of MCAs should be enabled to interoperate. Ideally, this should be possible without degrading the functionality of two communicating feature-rich MCAs A and B, only because an interconnecting MCA C (located between A and B) does not provide this rich functionality.

Secondly, clients should be allowed to take their policies across domain boundaries. This way clients can exploit their specific knowledge about the nature of their application throughout the network. We call these policies global. One problem here is that, although applications may be assumed to have knowledge about the local domain (e.g. about the topology), no such knowledge can be assumed for remote MCA domains.


next up previous
Next: Overview Up: Introduction Previous: Are future reservations needed?
Herbert Bos
2001-12-11