« Return to Thread: a proposal for slice stitching
Re: [cfwg] a proposal for slice stitching
by Robert P Ricci
::
Rate this Message:
Thus spake Jeff Chase on Sat, Feb 06, 2010 at 04:57:36PM -0500:
> ORCA uses what we might call the "coordinator" approach similar to what
> you describe. But rather than defining a separate stitching manager
> service to function as the coordinator, the Slice Manager (SM)
> representing the slice acts as the coordinator. The SM is a piece of
> software representing "the researcher" in your description.
>
> This arrangement does not preclude various peering AMs from coordinating
> directly, as in the "peer to peer" approaches ProtoGENI and OMF are
> pursuing. But we wanted to avoid requiring neighboring AMs to
> pre-coordinate bindings to talk to each other.
I probably didn't make this clear enough, but one of our main goals in
the design I outlined was to make the negotiation between neighboring
AMs invisible to the user, so that different implementations are
possible. From the user perspective, they just need to create a sliver
on every aggregate that needs to be involved in the slice, and those
aggregates will take care of stitching where it's requested. The
peer-to-peer approach with pre-established relationships happens to be
the one we're pursuing right now. I'd be happy to have other methods
supported as well (though of course every AM that is going to
participate in a particular stitching needs to support a common method.)
For example, AMs could agree on a trusted third party that they're going
to use for negotiating labels (and this third party need not be the
researcher or the SM.)
> And we wanted to allow
> for scenarios involving "logical" stitches where there is no physical
> adjacency, like nodes attaching to a storage server in some other domain.
I'll answer these questions for the ProtoGENI design, more comments on
ORCA's below.
> The authorization questions for stitching should also be on the table.
> They are a bit subtle.
Agreed.
> In your proposal, does the stitch manager service run with any special
> privilege? Do the AMs trust it? Does the CH trust it?
No to all three. The main case where trust must be established is
between AMs that are physically neighboring. I think this is reasonable,
as plugging in a wire or sharing spectrum requires inherently requires
some degree of trust.
> Presumably the "researcher" ( or its SM or experiment control tools)
> must trust it. What is the basis of this trust?
In our design, the process of talking to all of the AMs involved falls
'by default' to the researcher. Therefore, they don't *have* to place
their trust in some stitching or slice management service. In practice,
we think it's *likely* that most users will want to use such a service.
The thing the researcher does have to trust is that the aggregates that
they ask to set up a stitched slice do so correctly (the user can
verify this to some extent, however.) When the AMs set up stitched links,
they are acting on their own authority, rather than the user's, though
they do have a signed ticked to prove that someone really did request
the stitching, and who.
> In general, each stitch involves agreement on a common label, e.g., a
> VLAN tag from one AM that is to be spliced into a VLAN from another AM
> at some adjacency point. One side of the stitch produces the label, and
> the other side consumes it. How does the consuming AM know that the
> coordinator reports the label correctly? I think this the nub of the
> authorization question for stitching.
We sidestep this question by having aggregates communicate directly -
they don't have to trust a third party coordinator (unless they want
to.) Of course, the two (or more) sides must authenticate each other.
This works well when the aggregates are physically adjacent and have
pre-established trust, as noted above. For the case of 'logical'
connections (we support some now in the form of IP tunnels), in our
design, the public keys of all AMs are available from the CH. (So
everyone must trust the CH to give out valid public keys, which is a
pretty core assumption in our design.)
> In ORCA, the producing AM signs the label, and the coordinator presents
> the signed label to the consuming AM. The public keys of the AMs are
> endorsed by some mutually trusted third party, such as a CH (or a
> certifying authority for a federation). In ORCA, tickets issued by a
> broker/CH can serve as the endorsement, since they contain the public
> key of the AM named in the ticket, and are signed by the broker. (I
> gloss over the multi-broker case.) This allows the SM to coordinate
> stitching without any special privilege.
So, if I understand this right, this requires the coordinator to be the
intermediary for label information? One of our earlier designs had this
property too, but we decided to move away from it for two reasons:
1) Ordering: in some cases, link setup must be done in a specific order
- eg. for many types of tunnels, one end must be set up to listen
before the other can connect. If labels pass through a third party,
this seems to require the third party to have some knowledge about
the ordering required for every stitchable link type. The more
aggregates a single link passes through, the worse this problem
gets. I'd rather 'hide' all that knowledge in the AMs which have to
know it anyway.
2) Negotiation: if there is actual negotiation required for labels rather
than just a 'label exchange', having a third party act as
intermediary makes things a lot more complicated. The exception to
this statement would be if the two (or more) aggregates are
unwilling to trust each other, but *are* willing to trust the third
party. This seems like an unlikely scenario for GENI, and even if
it happens, our design does support it.
How does ORCA deal with these issues?
I like the fact that the SM has no special privileges in your design -
would it be fair to say that it's more a service than a 'core' part of
the control framework?
> The ORCA protocol does not require any AM to know anything about what
> the slice looks like in other domains, except for the labels imported at
> the stitching points. Only the SM/coordinator knows the entire
> structure of the slice. This is important because we want to avoid
> assuming that slices are static entities, or that there is some central
> controlling authority for the entire "testbed".
In our current implementation, we do pass the researcher's entire
request RSpec around to every AM, and each AM simply ignores the parts
that aren't relevant to it. We could, I think, give each AM only the
relevant bits (components it controls + stitched links) - the main reason
we're not doing it now just is simplicity on the client side (it doesn't
have to worry about carving up the RSpec by AM.)
Your point about not wanting a single controlling entity is a good one,
and that's why I'm glad to see that the OMF and ORCA (as well as
ProtoGENI) designs don't have a trusted stitcher - in the limit, such a
stitcher has to have a global view of the physical substrate and be
globally trusted, which doesn't scale well.
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
> ORCA uses what we might call the "coordinator" approach similar to what
> you describe. But rather than defining a separate stitching manager
> service to function as the coordinator, the Slice Manager (SM)
> representing the slice acts as the coordinator. The SM is a piece of
> software representing "the researcher" in your description.
>
> This arrangement does not preclude various peering AMs from coordinating
> directly, as in the "peer to peer" approaches ProtoGENI and OMF are
> pursuing. But we wanted to avoid requiring neighboring AMs to
> pre-coordinate bindings to talk to each other.
I probably didn't make this clear enough, but one of our main goals in
the design I outlined was to make the negotiation between neighboring
AMs invisible to the user, so that different implementations are
possible. From the user perspective, they just need to create a sliver
on every aggregate that needs to be involved in the slice, and those
aggregates will take care of stitching where it's requested. The
peer-to-peer approach with pre-established relationships happens to be
the one we're pursuing right now. I'd be happy to have other methods
supported as well (though of course every AM that is going to
participate in a particular stitching needs to support a common method.)
For example, AMs could agree on a trusted third party that they're going
to use for negotiating labels (and this third party need not be the
researcher or the SM.)
> And we wanted to allow
> for scenarios involving "logical" stitches where there is no physical
> adjacency, like nodes attaching to a storage server in some other domain.
I'll answer these questions for the ProtoGENI design, more comments on
ORCA's below.
> The authorization questions for stitching should also be on the table.
> They are a bit subtle.
Agreed.
> In your proposal, does the stitch manager service run with any special
> privilege? Do the AMs trust it? Does the CH trust it?
No to all three. The main case where trust must be established is
between AMs that are physically neighboring. I think this is reasonable,
as plugging in a wire or sharing spectrum requires inherently requires
some degree of trust.
> Presumably the "researcher" ( or its SM or experiment control tools)
> must trust it. What is the basis of this trust?
In our design, the process of talking to all of the AMs involved falls
'by default' to the researcher. Therefore, they don't *have* to place
their trust in some stitching or slice management service. In practice,
we think it's *likely* that most users will want to use such a service.
The thing the researcher does have to trust is that the aggregates that
they ask to set up a stitched slice do so correctly (the user can
verify this to some extent, however.) When the AMs set up stitched links,
they are acting on their own authority, rather than the user's, though
they do have a signed ticked to prove that someone really did request
the stitching, and who.
> In general, each stitch involves agreement on a common label, e.g., a
> VLAN tag from one AM that is to be spliced into a VLAN from another AM
> at some adjacency point. One side of the stitch produces the label, and
> the other side consumes it. How does the consuming AM know that the
> coordinator reports the label correctly? I think this the nub of the
> authorization question for stitching.
We sidestep this question by having aggregates communicate directly -
they don't have to trust a third party coordinator (unless they want
to.) Of course, the two (or more) sides must authenticate each other.
This works well when the aggregates are physically adjacent and have
pre-established trust, as noted above. For the case of 'logical'
connections (we support some now in the form of IP tunnels), in our
design, the public keys of all AMs are available from the CH. (So
everyone must trust the CH to give out valid public keys, which is a
pretty core assumption in our design.)
> In ORCA, the producing AM signs the label, and the coordinator presents
> the signed label to the consuming AM. The public keys of the AMs are
> endorsed by some mutually trusted third party, such as a CH (or a
> certifying authority for a federation). In ORCA, tickets issued by a
> broker/CH can serve as the endorsement, since they contain the public
> key of the AM named in the ticket, and are signed by the broker. (I
> gloss over the multi-broker case.) This allows the SM to coordinate
> stitching without any special privilege.
So, if I understand this right, this requires the coordinator to be the
intermediary for label information? One of our earlier designs had this
property too, but we decided to move away from it for two reasons:
1) Ordering: in some cases, link setup must be done in a specific order
- eg. for many types of tunnels, one end must be set up to listen
before the other can connect. If labels pass through a third party,
this seems to require the third party to have some knowledge about
the ordering required for every stitchable link type. The more
aggregates a single link passes through, the worse this problem
gets. I'd rather 'hide' all that knowledge in the AMs which have to
know it anyway.
2) Negotiation: if there is actual negotiation required for labels rather
than just a 'label exchange', having a third party act as
intermediary makes things a lot more complicated. The exception to
this statement would be if the two (or more) aggregates are
unwilling to trust each other, but *are* willing to trust the third
party. This seems like an unlikely scenario for GENI, and even if
it happens, our design does support it.
How does ORCA deal with these issues?
I like the fact that the SM has no special privileges in your design -
would it be fair to say that it's more a service than a 'core' part of
the control framework?
> The ORCA protocol does not require any AM to know anything about what
> the slice looks like in other domains, except for the labels imported at
> the stitching points. Only the SM/coordinator knows the entire
> structure of the slice. This is important because we want to avoid
> assuming that slices are static entities, or that there is some central
> controlling authority for the entire "testbed".
In our current implementation, we do pass the researcher's entire
request RSpec around to every AM, and each AM simply ignores the parts
that aren't relevant to it. We could, I think, give each AM only the
relevant bits (components it controls + stitched links) - the main reason
we're not doing it now just is simplicity on the client side (it doesn't
have to worry about carving up the RSpec by AM.)
Your point about not wanting a single controlling entity is a good one,
and that's why I'm glad to see that the OMF and ORCA (as well as
ProtoGENI) designs don't have a trusted stitcher - in the limit, such a
stitcher has to have a global view of the physical substrate and be
globally trusted, which doesn't scale well.
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
« Return to Thread: a proposal for slice stitching
| Free embeddable forum powered by Nabble | Forum Help |
