Cell Relay Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: ILMI address registration question
albert.e.manfredi@boeing.com wrote: > > In article <37691B54.67115CD9@lucent.com>, > "ronald h. davis" <ronaldd@lucent.com> wrote: > > Paul Koning wrote: > > > > > > I know the terminology. It's not clear that it was intentional > > > here. Even if it was, it's a mistake. If the use of the IEEE > > > identifier were required, it would ensure unique ESIDs (if the > > > globally administered values are used) yet allow the use of > > > locally administered values as well (with the "local" bit set). > > > So the text as written creates ambiguity and removes a guarantee > > > without offering any benefit whatsoever in exchange. > > > > > > > i don't know that you need/want to require that the esi be equal to > > a mac address when using e.164 format aesa's. similarly, when using > > private numbering plan (pnp) format there may also be no need/want > > to have a "required" esi value since it is, in that case, a "private" > > numbering plan. > > I was sort of agreeing with you on this, Ronald, except that the price > you would pay for doing what Paul suggests is pretty trivial. > > Basically, Paul is saying that if you want to code up those ESI bits > according to some sort of numbering plan of your own, vs. a flat MAC > address, just set the G/L bit to "locally administered." Now you can > set the rest of the 48 bits any way you please. > > You do pay a price: 1 bit's worth of information. So Paul was > exaggerating a tad when he said "no benefit whatever," but the price is > not so high. That was my point. Note that I use the term "IEEE identifier" intentionally. The 48-bit value we're talking about is often loosely referred to as "MAC address". That usage is actually incorrect when talking about the ESID. I agree that there is no reason for having the ESID equal a MAC address. It probably would be on boxes that implement LANE, but that's not necessary since the address resolution in LANE establishes the mapping from LAN style MAC address to AESA. What I was talking about is the 48 bit ESID, which is an IDENTIFIER, not an address. It should be an identifier administered according to the IEEE 802 adminstration rules. That doesn't make them MAC addresses; it just means they follow the 802 format (I/G and U/L bits zero at the start, OUI in the first 24 bits, per-organization unique non-reused value in the last 24 bits, or U/L bit set to 1 and next 46 bits administered by the customer or network operator's organization). The reason for doing this is to give you an effective way of ensuring the uniqueness of the ESID. (It actually gives you a stronger guarantee than needed if you use the universally administered format, but that's harmless.) Saying that the ESID can be but doesn't have to be administered by the IEEE 802 rules is pure and simple foolishness serving no purpose, and as far as I'm concerned it is a bug in the spec (most likely an unintended one). paul
|
|