What are the requirements for Anycast in a new architecture?
As I understand Anycast is about delivery to one out of multiple
destinations within a given scope.
Where is the center point of this scope ? Is it always the location of the
source ?
Can/should it be something to be provided/signalled (which makes sense if
alternatives to that case were allowed where the source is this center
point)?
Who determines the final Unicast destination ? the source? the ingress
router? Or also some router/server along the path?
May an enforced detour of the forwarding path wind up in
selecting a different Unicast destination - done by any transit router?
I'll appreciate learning the answers to these questions because I
think there are multiple ways to conceive and implement Anycast (not just the
traditional one). There are quite a few concepts developed for other services
which are likewise applicable to Anycast: MIP4 care of address server, HIP
rendez-vous server,...
Heiner
In einer eMail vom 21.04.2009 07:58:07 Westeuropäische Normalzeit schreibt
tony.li at tony.li:
Hi
Bill,
> I have this mental picture of the NFAs and DFAs (finite
automata) used
> to process regular grammars from the formal languages
class I took in
> college. All NFA's can be translated to DFAs but the
translation
> explosively grows the automata.
>
> Seems to
me like NFAs are decent metaphors for broadcast and multicast
> while
DFAs are metaphors for anycast and unicast. And I think its
> notable
that anycast groups with unicast (it's DFA-like) instead of
> grouping
with multicast.
Ok, I remember these. Still have the textbook
right here. ;-)
>> Except that we haven't figured out
how to aggregate anycast, which from a
>> routing perspective, makes
it completely unique.
>
> What do you mean? Anycast aggregates
the same way as unicast: whenever
> the endpoints physically group
together, they aggregate. At a
> practical level, that's rarely useful
for anycast... But then at a
> practical level aggregating unicast that
way (or failing to) is the
> source of our current
grief.
Well, the problem with aggregating anycast is that it ends
up with one
route per service. In a world of highly differentiated
services, the
sheer number of services could be explosive. And you
can only aggregate
them if they are numbered appropriately and are
topologically
correlated. How often is that going to happen with
anycast?
To be fair, we do get substantial aggregation up to the site
level with
unicast, it's above that level that things get
iffy.
>>> The same can't be said of multicast. Multicast
has different semantics
>>> even if there's only one host in the
group.
>> Say more please, I'm not following.
>
> With
anycast, the packet's next hop is always in exactly one
> direction,
precisely the same as with unicast. And knowledge about
> what that next
hop should be propagates precisely the same way.
>
> With
multicast, the packet is replicated in all currently valid
> directions
with complex subscription/desubscription overhead that has
> to be
maintained even if there's only one receiver in the group.
Having
watched the development of PIM, BGP, OSPF, ARP, HSRP, VRRP, and
IS-IS, I'm
having a hard time saying that the "complex
subscription/desubscription"
overhead for multicast is all that much
worse than what we do for
unicast.
As for the forwarding plane, the differences are NOT that
large. Ok,
yes, there is an order of magnitude more complexity in
doing the packet
replication, but it becomes quite clear that with one
receiver it does
devolve nicely into an effective unicast. No one
would implement
unicast that way, of course, but that's an efficiency
issue, not a
conceptual one.
Even if multicast's differentiation is
the replication in the data
plane, I'm not sure I see how that becomes
non-deterministic. I see no
references to an oracle. The right
things always seems to happen with
total determinism.
>>
Ok, but how would a map resolution change that? Is the key point here
that
>> whatever mapping function is used, the map result has a TTL
and needs to be
>> refreshed periodically? Or, the applications
need to be able to trigger a
>> refresh?
>
> You'd put
the map resolution outside the app developer's scope, either
> in the
network (as proposed by strategy A) or in the system-level host
>
software (as proposed by strategy B). Unprivileged applications simply
>
wouldn't be able to diddle with addresses at the routing layer.
>
> With a guaranteed maximum time that a given map remains valid and
no
> application-level access to the routing element, the protocol
and
> weigh in favor of renumbering for aggregation instead of rerouting
for
> multiple connections.
>
> But this is rather off on a
tangent from anycast and its rather
> identical nature to
unicast.
Seems like useful implementation strategies to me.
And it leads me
again to the conclusion that it's again not something
that's happening
within the routing
subsystem.
Tony
_______________________________________________
rrg
mailing
list
rrg at irtf.org
http://www.irtf.org/mailman/listinfo/rrg
|