On Mon, Jul 06, 2009 at 06:32:53PM -0400, Sebastien Roy wrote: > > On Mon, 2009-07-06 at 15:16 -0700, Eric Cheng wrote: > > On Mon, Jul 06, 2009 at 05:49:00PM -0400, Sebastien Roy wrote: > > > By design, the SAP space for a given media is defined by the MAC-Type > > > plugin for that media. For example, the SAP corresponding to IPv4 for > > > DL_ETHER is ETHERTYPE_IP, but for other MAC-Types, it might not be. For > > > IP tunnels, for example, it's IPPROTO_ENCAP. I would hope that there > > > isn't any more Ethernet-specific stuff going into the common framework > > > to implement this, and that you're leveraging the plugin architecture. > > > Is this the case? > > > > > > > yes, certainly. we will use mac_header_info() to retrieve the sap just > > like mac_flow.c does today. > > mac_header_info() allows the caller to obtain the SAP value for a given > packet, but it doesn't tell you if that value corresponds to IPv4, IPv6, > or ARP. How will that actually be done? >
this issue mostly affects tunnels right? as far as I am aware, the sap for wifi/ib corresponds to the ethernet sap. and I think it's unlikely that any new media types other than tunnels would use a separate sap space. to simplify the implementation, I am inclined to not support link protection for media types not sharing the same sap space as ethernet. at plugin registration time, the plugin could indicate whether it supports this via a new flag. yes, I agree this is not ideal but I think it's better than adding special media-specific parsing logic in the main data paths. thanks eric
