|
On a
personal note, one GOOD reason to use NSAPs is that if you use the Network
Entity Title format, for instance, not only you're able to
imediateley identify the ethernet MAC address of the Network Element you're
trying to reach, you have a much larger Address space than in IP (v4, which is
what everyone will have for many years to come), it's intrinsicaly more secure
since not every "jack" has an Osi stack implementation to hack your network, and
last but not least... it's what ITU recommends (try saying to an operator that
your NE ONLY talks IP).
But IP
is gaining, and we, vendors using/supporting OSI, are taking notice of
that, and are already installing OSI2IP and IP2OSI layers... for the Control
Plane flavor of the month...
About
the "names" transalation suggestion... my guess is that you got to be joking
:-).
Best
regards,
Jorge
Pinto
Siemens IC R&D ON
Hi all, it's great to see a draft
and this much support for a UNI model which seems necessary when offering
support out to the edge of "connection oriented services".
This is very similar to the
original OIF UNI work, until a huge issue arose over supported address types.
The initial thrust was for only
IP address types (v4 and v6).
However this didn't fly with a bunch of folks with installed networks
using NSAPs.
However it was never really clear, to me, that NSAPs were needed, i.e., the optical control plane was to
be IP based and any other "addresses" could be viewed as "names" and
translated when and if necessary.
Note that all previous SONET/SDH standards specified OSI stacks on the
"in band" data communications channels (if you were wondering how we got into
this mess).
This is an area that could use a
bit of thinking since from the ITU-T perspective
other (non IP) address are desirable.
And it would be nice to harmonize the work at the various standards
bodies.
Greg
B.
Greg Bernstein,
Grotto-Networking
|