I think collisions are only problematic when you cannot disambiguate them.
For example, packets coming from servers connected to different switch ports can be disambiguated based on ingress port, irrespective of their IP or Ethernet headers. Another example is NAT boxes - behind the NAT, everyone can be on a different 10.x network reusing the same IP addresses. Whether you think of certain header bits as "color" or "smell" or "IP address" or "forwarding hash" or "link-local virtual circuit identifier" is basically up to you in an OpenFlow switch, except that you can do longest-prefix matching on an IP address, and you may not be able to do so on other fields like TCP ports. Does Click send color-tagged packets out switch ports in a way that can be decoded at the other end of a link? If so, how are they encoded and decoded? On Nov 2, 2012, at 2:36 PM, Abhishek Chanda <[email protected]> wrote: > Hi all, > > Is there a way to insert custom metadata in a packet (other than the match > tuple) that can then be extracted in a switch? Specifically, I am looking for > something like Click's Paint element that allows marking packets with a > 'color'. Later, another network element can look at the color and use it to > decide forwarding behavior. > > Initially, I was thinking of using VLAN tags for this. But then, those tags > can collide with tags used in the underlying network and can create confusion. > > http://www.read.cs.ucla.edu/click/elements/paint > > Thanks > _______________________________________________ > openflow-discuss mailing list > [email protected] > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
_______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
