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 [email protected]: 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 [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
