Harvey,
Regarding your remark on RSVP:
In pure RSVP I tend to agree with your first observation. Reservations
are hard to do in multi-domain cases using RSVP. But this is not the
point
of using RSVP in the case I am trying to point out.
RSVP, (or some signalling protocol using EAP if you do it in-band) or
other
any other suitable signalling protocol (SIP) for this matter, could
also be used for access
control purposes to point at a specific reservation of an explicit path.
For example RSVP is able to also support a policy data object as
described
in RFC2750. This policy data object could contain some form of
"token". The token in this case would be a secured index into a
pre-provisioned
service instance waiting to be accessed. Brokers could have negotiated
this service using WS mechanisms in the way we are discussing now and
the steps you are refering to below. Agents can still do the work
needed to
make sure the path is correctly in place when the time comes the path is
reserved.
As a result of the negotiation, however, each domain would agree on a
key
that allows the creation of a token.
Each domain would use this key to verify the validity of the token
when it receives a RSVP signal (PATH) at the ingress of its network.
The sender would create the token using some kind of secure HMAC
mechanism using the index and maybe some other service parameters
as digest. The token could remain the same along the way for each
domain or could be regenerated at the egress of a network dependant
on the fact if the agreed key is the same or different for each
domain. This approach does not reserve the path,
but just ensures nobody else is using a particular reservation.
This is important if a path can be publically accessed.
This approach is therefore a hybrid approach (mixing WS
style provisioning for the reservation with signalling style for
access control and usage) which will enable quick network access
without the need to go back an authority.
The token model is very successfull as authorization model in other
cases, so I am wondering why it cannot be used in networks.
The approach has at least the following advantages:
1. As the reservation processes can be slow and would involve an
arbitrary
amount parties each taking their own amount of time, separating
the reservation process from the actual access and usage of a path
would be
an advantage. A token would enable instant access without the need to
go up.
2. Once the reservation is received by the user process, the
reservation can
be used very flexibly. Maybe a metascheduler could assign a particular
reservation at the last minute to a particular process that can best use
the particular connection. The meta scheduler can hand the key to
the most optimal process at that moment.
3. Scheduling resources may not be enough as it provided no access
control in cases where it is needed. You need to be able to somehow
seperate the sheep from the goats (subscribers v.s. non subscribers)
when they need
to be. Non token approaches tend to use call-outs (e.g. RADIUS) that may
take their time as well.
Anyway, I demonstrated the token approach at SC|06 using the DRAGON
GMPLS code and as a result we will start testing this approach more as
part of the Phosphorus project in collaboration with Internet2 and
the DRAGON
project.
Kind regards .. Leon.
Harvey Newman schreef:
This is a limited view that will run into the same problems as are
well-known
from RSVP. One will never get to reserve a multi-domain path this way.
Operational steps in a services-oriented architecture:
(reservations are stateful, time-dependent, and responsive to
capability to use the allocated resource):
(1) AAA, with priority schemes and policy expressed by each VO.
(2) Inter-VO allocations according to quotas; coupled to tracking of
what has been used during a specified time period
(3) Service to verify end-system capability and load as being
consistent with the request
(4) Agents to build the path and verify its state (up, down,
which segment(s) are down or impaired) also agents to
verify end-system capability (hardware, system and kernel
config., network interface and settings); verification
of end-to-end capability with an active probe (viz.
FDT); build or tear down circuits in parallel in a
time < the TCP timeout.
(5) Tracking of capability (if relevant, as in large scale data
transfer)
(6) Adjustment of channel capability if allowed, according to
performance end-to-end. For example with LCAS
[allocation of a non-adjustable channel takes longer,
and becomes an economic question.]
(7) Adjustments driven by (a) entry of higher priority
allocation-requests; these could affect many or even
all channels or (b) re-routing of certain flows if better
paths become available (c) optimization of workflow according
to deadline scheduling for certain flows
Except for the higher-level "strategic" parts above (policy and
quotas; which need to come from the VOs), many of the technical pieces
above exist, and will be hard to match.
Harvey
Steve Thorpe wrote:
Hello Bert, everyone,
The point Bert made "...if the pre-reservation of resources is not
an atomic action..." is very important.
My belief is the pre-reservation of resources, or Phase 1 of a
2-phase commit protocol, *must* be atomic. That is, there must be
a guarantee that at most one requestor will ever be granted a
pre-reservation of a given resource. Then, the requestor should
come back with a subsequent "Yes, commit the pre-reservation", or
"No, I release the pre-reservation". In the case where the
requestor does not come back within a certain amount of time, then
the pre-reservation could expire and some other requestor could
then begin the 2-phase commit process on the given resource.
There may be situations where a resource broker can not get the
desired resource reservation(s) booked. But, I don't see
deadlocking here - where both resources can *never* be booked.
Unless of course, a resource broker books them once and is allowed
on to them forever.
The atomicity of the pre-reservation (phase 1) stage of the 2-phase
commit process is a very critical part for this to work.
Steve
PS I have also added Jon MacLaren to this thread, as I'm not sure
he's on the GLIF email list(s).
Bert Andree wrote:
Hi Gigi,
What exactly dou you mean with one RB per request.
Suppose there are two independant RB's,RB-A and RB-B and two
resources, RS-1 and RS-2.
Suppose that there is a request to RB-A to book both resources and
a request to RB-B to do the same. Now, if the pre-reservation of
resources is not an atomic action, two different strategies may
introduce specific problems.
Stategy 1: an availibility request does not reserve the resource:
RB-A asks for RS-1 (available)
RB-B asks for RS-2 (available)
RB-A asks for RS-2 (available)
RB-B asks for RS-1 (available)
RB-A confirms RS-1 (success)
RB-B confirms RS-2 (success)
RB-A confirms RS-2 (fail)
RB-B confirms RS-1 (fail)
The obvious solution would be to free all resources and try again.
In complex systems there is a fair chance that both resources can
never be booked (deadlock).
Stategy 2: an availibility request reserves the resource:
RB-A asks for RS-1 (available)
RB-B asks for RS-2 (available)
RB-A asks for RS-2 (not available)
RB-B asks for RS-1 (not available)
RB-A and RB-B free all resources and try again. In complex systems
there is a fair chance that both resources can never be booked
(deadlock).
The only way to prevent is, is to have some queing of requests and
even then "individual starvation", e.g. RB-A can never book any
resources is possible in complex systems.
Best regards,
Bert
Gigi Karmous-Edwards wrote:
Hi Admela,
I agree, there are two phases, 1) check availability from xRM,
and 2) If all xRMs give an ack. then go th second phase of
commit, 2') if one or more xRM gives a nack, then do not proceed
to the phase two commit. In the architecture sent out, the
responsibility of coordinating and administering the two phases
is in ONE RB per request. Each xRM will rely on the RB to tell
them whether to proceed to a commit or not. If they get a commit
from an RB, it then becomes the xRM's responsibility to make the
reservation and allocation in the actual resources. I think if
for example RB-A talks to an xRM in domain "B", then it may be
the responsibility of the xRM-B to tell its own RB-B of its
interaction with RB-A. Is this in line with your thoughts?
Gigi
