Global Lambda Integrated Facility

Subject Re: Network Control Architecture
From Leon Gommans <lgommans@xxxxxxxxxxxxxx>
Date Thu, 19 Apr 2007 15:08:02 +0200

Hi all,

I few more cents to the discussion. When were discussing Bandwidth Brokers for diffserv architectures about 10 years ago, we had similar discussions. Groups of points in the discussions seems to form dimensions into the problem. To me its seems that we have
the following elements

- Architecture: Centralized (with single or multiple brokers) vs a distributed (with
or without federative elements).
- Control message communication: Signalled (east-west and northboud) vs provisioned (southbound)
- Time: ad-hoc vs future and undetermined and pre-determined time periods.

With the above elements in mind, on can construct all kinds of control sequences. However when constructing them, most control sequences so far describe how a control plane interacts with a forwarding plane and typically forget about the role of the user in the process. The user is assumed to send a request and one or more brokers will handle the request
somehow. However please don't forget that the user (process) may also
play an important role in the process, in particular in scenario's which involves the future. The user precisely knows when it wants to use the connection, but may not know it at the time it sends a request for some future connection. This is like
the phone system, a user may subscribe to a service, but does not know when
and for how long it wants to use the connection. The user may also request, based on the subscription for example a scheduled teleconference. It will receive a conference access code number to avoid that this number is mis-used. These kind of considerations lead us to writing RFC2904 - which describes authorization sequences, which always considers the user as part of the sequence. If one operates a network that has public access, one must at some point enforce access to the network. One must be able to distinguish between subscribers and non-subscribers. As a consequence the signal to access the network may not come from the user signalling it to a broker, but from the equipment where user tries to gain access. This is like a user dailing a modem into an ISP or using cable/DSL modem to gain access to the Internet. It needs to first obtain a username/password from the provider
to be recognized as a subscriber.

All I am saying is that one needs to stay open minded about how the network will ultimately be used and accessed. In our group we are working on a router that is capable to act as a gateway between an optical network an a public/campus network. We may want to signal the optical network and only provide this network with an identifier of some service has been pre-arranged with the part that controls the network. This pre-arrangement may be work in a provisioning fashion (using web-services) whereas the usage may work in a signalled fashion, eg using some
protocol like RSVP-TE, PPPoE with EAP or some mode of IPSEC like AH.

Maybe we should work on some of the possible sequence and recognize a number situations that
may use different solutions or only parts of certain solutions.

Kind regards .. Leon.

Gigi Karmous-Edwards schreef:
Hi Jeroen,

For your first point about components in the DNRM, we only put in functional components in the diagram. I agree the implementation from one DNRM to another may be completely different but provide similar functionality.

I agree the number of interfaces seem large, but each is suited for a particular resource and with the exception of the DNRM, they should mainly behave as translators between a broker request (based on standard interface) and the resource scheduler ( which contains the majority of logic). We should try to develop a very generic set of calls that can be used for each interface and then only a few calls specific to the type of resource.

Regarding a central broker, we assumed each "Grid administrative domain", or "resource domain" if we want to use that term will have a corresponding Resource Broker (RB), (which could be made redundant to avoid single point of failure). However, I disagree that RBs should make requests to each other due to the transaction problem. I do not think the RBs will obtain resource information about resources outside of their domain. If resources are requested which are outside of an RB's domain, then the RB will make a query to the distribute GLIF "distributed " resources to locate the other xRM necessary to resolved the request. I think this is where your work on NDL comes into play. How does each domain publish the information about resources and the corresponding URI for the xRMs.

I think each xRM should contain its own policy for usage and that is not the responsibility of the RB.

Thanks for the information about the new NML working group in OGF!



Gigi Karmous-Edwards
Principal Scientist
Advanced Technology Group
+1 919-248 -4121

Jeroen van der Ham wrote:


This framework seems an interesting startingpoint to work toward a
common architecture. I think the important point we need to agree on is
what kind of components need to be present in the architecture. For
example, the second slide lists all the important components for a DNRM,
but it will depend on the implementation how they are tied together. We
really should focus on the interfaces presented to the outside.

The amount of different interfaces listed in the first slide seems
staggering. I am certain that the architecture as listed there does not
scale. The resource broker has to know about all different kinds of
interfaces, and it is also impossible for one domain to maintain
information about all the different resources in other domains. Combine
that with policy restrictions and the equation becomes even more complex.

The way forward really seems to be using a central broker[1] for the
domain, with a standardised interface to other brokers. I agree that we
should aim to do this first for network resources, and then we can see
how this can be extended for other resources.

I completely agree that the interfaces should be generic and not Grid
specific. The reason why we're using the OGF as standardization body is
because they are already doing related things in the Network
Measurements WG[2].

I would like to invite everyone to the first session of the Network
Markup Language WG at OGF 20, May 9th in Manchester.


[1]: "Central broker" in the sense that applications will know how to
approach the domain. This does not necessarily imply that it should be
one single services or single point of failure.
[2]: Note that the charter of the Network Markup Language WG only
contains the word "Grid" once, in the term "Open Grid Forum".