ipv6nd-02.txt & autoconfig

[Albert Manfredi <[e-mail]>]

[e-mail] wrote:

> The SEL field is for _internal_ routing of an incoming call
> once the physical ATM interface has been located (routed to) using
> the top 19 bytes. i.e. the top 19 bytes denote the physical host,
> and SEL can be used internally to the physical hosts (end systems)
>  - aka logical ATM interfaces. This not a new idea.

I guess my point is that the SEL should be viewed as an ATM-only neat-o
feature. It should not be used to map to different IP addresses.

For example, using the AEREQUIPA model, the SEL would only be used if
the two end systems are both ATM. After all, you've already 19 bytes of
ATM address to play with, compared with the 16 bytes of IPv6. What's the
big deal? 

> >>The point was only that I think the ATM NSAPA should stand on its own
> >>merits too. If we force ESI to be unique, MAC-like, then the UNI 3.0
> >>format for DCC and ICD address formats starts looking cramped. That
> >>would make those formats less useful on their own, e.g. for cut-through.
> 
> I'm sorry, but in the context of IPv6 over ATM your comments seem
> orthogonal (And if I recall, you were given a thread on this issue
> a few months ago. Like it or not, the ESI is not required to be anything
> but flat by the UNI standards. It doesn't have to be a MAC address,
> but under UNI 3.0 or 3.1 it is required to be unique, nothing more).
> Apologies if I'm missing an obvious tangent here.

You missed nothing. It is orthogonal. It was a parenthetical comment. The
general point was that I would agree completely with those who want ESI
to be flat and unique, usable exactly like a MAC address in those lesser
networks. I'm simply raising a flag wrt DCC and ICD formats.

> E.164 numbers in native format are potentially just as 'ATM' as NSAP format
> addresses are, at least in the public arena (you know, the telcos whose
> methods you like to champion on the odd occasion :)

Only amongst the IP-chauvinist crowd! I would propose, for instance, that
whenever ATM hosts do IP over ATM, or whenever ATM hosts want to reap the
benefits of autoconfiguration in native ATM comms, they simply must use
NSAPA encapsulation. Again, in an effort to introduce some stability.

AUTOCONFIGURATION

You made a point about use of well-known VPI/VCI for autoconfiguration:
what about situations in which multiple LLGs exist on one ATM net?

This is a generic problem, and I think the same solution could be used
with this proposal as is used in others: partial knowledge (in this case,
optional).

A new host boots up. If this host doesn't care what LLG it joins, it
simply waits for the first VPI=0 VCI=x autoconfiguration message. The
IPv6 (and ATM) routable prefix sent down is used by this host to
manufacture its complete address. This autoconfig message might also
indicate where all further transactions with that server will occur.
(If the server goes down, the hosts can go back to VCI=x to discover the
backup server.)

A new host boots up. This guy cares what LLG it joins. It listens on
VCI=x until the server transmitting the proper IPv6 (and ATM?) routable
prefix sends its autoconfig message. Then the new host responds as
indicated, and proceeds as above (i.e. all further transactions
conducted over a different channel).

How these pt-mpt VCs from each of the servers are set up to begin with
is (in typical I-D vernacular) beyond the scope of this proposal. But
it is entirely conceivable that two adjacent ATM switches, on separate
nets, have different pt-mpt VCs set up on their respective VPI=0, VCI=x.

Bert
[e-mail]