|
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
--------------------------------------------
Gigi Karmous-Edwards
Principal Scientist
Advanced Technology Group
http://www.mcnc.org
MCNC RTP, NC, USA
+1 919-248 -4121
gigi@xxxxxxxx
--------------------------------------------
Jeroen van der Ham wrote:
Hello,
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.
Regards,
Jeroen.
[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".
