On Mon, Jan 27, 2003 at 11:34:04AM -0800, Guy Harris wrote:
| On Sun, Jan 26, 2003 at 07:19:23PM +0100, Hannes Gredler wrote:
| > pls find attached a [mini] patch that registers the MPLS
| > dissector within the C-HDLC dissector;
|
| Checked in.
|
| BTW, is "MPLS multicast" not used over broadcast networks such as
| Ethernet (e.g., is it designed to handle multicasting over
| point-to-point links)? It's registered with PPP and Cisco HDLC, but not
| registered as an Ethertype.
i guess thats an IETF thing - i.e. reserve things that later no one needs ;-)
seriously the intention was to ease processing for hardware based routers
in the input parsing stage and feed multicast marked packets to the appropriate
lookup engines and [if needed] replication stages.
the problem is that M-MPLS really never got materialized in a product, in lack
of a signaling protocol that signals multipoint distribution trees;
| Also, it would be possible to have the Cisco HDLC dissector get a handle
| for the "ethertype" dissector table, and first try the Cisco HDLC
| dissector table and, if no dissector is found, try the "ethertype"
| table; that would obviate the need for protocols that don't have special
| Cisco HDLC types to register themselves with "chdlc".
|
| However, that doesn't help with the "chdlc_vals[]" value_string table;
| I'm not sure what the right fix would be there, but it'd be nice to have
| "chdlc_vals[]" inherit stuff from "etype_vals[]" and then put its own
| items on top of it. (Are there any protocols that are different from
| each other but that share an Ethertype/CHDLC type value?)
there are the exceptions that i do know of:
0x8035 [SLARP link layer keepalives and more] -> collides with REV-ARP
0xfefe [ethertypecasted LLC header for OSI] -> unassigned ethertype
0x2000 [CDP] -> ???
so given the fact that it is a _proprietary_ protocol and the vendor may change
it anytime IMO we should not map it to a _standards_ based table [that we might
tweak b/c of that]
/hannes