Hi Bill,
> So it defaults to repeating the packet to all ports where a router > would have chosen to drop the packet. > > That's the difference between an identifier and a locator? An > identifier defaults to flood while a locator defaults to drop? Actually, the router would have forwarded the packet whether or not the destination is present (up until the L2 mapping fails, at which point its stuck). Again, the IP address that the router uses contains location. You can see this with other addressing schemes: 170 W. Tasman Dr. San Jose, CA USA This contains location information, regardless of the individual (identifier) that you're trying to reach, and: +1 408 853 XXXX A phone number includes political and geographic information and specifies a particular CO in the PSTN, regardless of the least significant bits. >> Function 2 is filtering based on an identifier. > > Is it now? Last I heard it, different process subscribe to different > multicast MACs and can even subscribe to different unicast MACs (e.g. > a host OS with guest virtual servers). There's a decision about which > process to repeat the packet to. Just like a router, it defaults to > not repeating the packet if the destination MAC matches none of the > known destinations. Virtualization changes nothing except that the logical entities are physically co-located. Multicast MAC 'addresses' are also just filtering entities: the network knows nothing about the location of the listeners and simply floods the packet in the hope that something cares. As you know, this is even known as MAC address filtering in the hardware. I'll be the first grant you that an L3 multicast address isn't so much about topology as a group of listeners and thus is itself not a true 'locator'. We fudge it with a lot of software. ;-) >> Function 3 is simply including a source identifier. It's only real purpose >> is to support the learning function for function 1. > > Actually, I was talking about the destination MAC that gets tacked on > from the ARP table, not the implicit source announcement (much like a > route announcement) that lets the switch know which port to repeat > subsequent packets to. Ah sorry, I misinterpreted. Even then, that's not a true forwarding function, so much as an identifier translation function. The host that generates the ARP has some notion of (L3) location based on the IP address, but learns nothing of the L2 location of the next hop even as a part of ARP. > But hey, you say poTAYto, I say poTAHto and we all dance a little jig. ToMAYto. ;-) Happy Friday, Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
