The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] denser ar$pro space.
Grenville Armitage writes: +-------- |My initial reaction was that the above table only encompasses |NPLIDs that identify a protocol, rather than NLPIDs that really |mean "there are more protocol bytes to follow". +-------- Ok. So we could add text to say so. But... +--------- |But I think you've inadvertently hit on an 'almost standard' way |of including SNAP based protocol IDs. People may remember a few weeks |ago I said that the existing MARS message format could carry SNAP |fields as a TLV, with ar$pro = 0x400 being interpreted as the flag |saying "go look in the TLV list". Of course, 0x400 was a rather arbitrary |value. +-------- Grenville: This works well for the data plane (as I said in my original note). However I do not think it is acceptable for the control plane. Recall that the sequence number is protocol-specific. Now I need to look at the ar$pro and if it is 0x80 go look for a TLV and _then_ do sequence number processing ? I think not. Let us just burn the extra bytes and get it over with. It is only the control plane after all. I like the way the data plane works out but I don't think that saving the bytes in the control plane justifies the increase in complexity. Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680 |
|