Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695) (02/26/89)
Is there any dynamic way of learning the address resolution for IP over X.25? I would appreciate it if anyone could give me pointers for papers or information. Yuko Murayama Dept of Computer Science UCL
barns@GATEWAY.MITRE.ORG (Bill Barns) (02/27/89)
The prior discussion on IP and X.25 left me with the impression that
there is not any scheme now in use anywhere, for *dynamically* learning
an X.121 address corresponding to an IP address given that the source
and destination are both connected to some particular X.25 network. If
such a scheme does exist, I would be interested in learning about it.
Keith Mitchell suggested a scheme involving passing IP addresses in
the Call User Data field of the call request. I think he had a
rather different purpose in mind - for the originator to declare
its own IP address. However, I can imagine a variation of this which
uses an address server whose X.121 address is preconfigured in other
systems. You would connect to such a server and include the IP address
you want to resolve in the CUD, probably with some protocol identifier
prefix which signals that you are requesting this address resolution
service. There are probably three ways that could be used to pass back
the answer:
1) accept the call, send back the X.121 address as data, then clear.
2) perform the whole operation as a 'fast select' and use a clear with
data to send back the X.121 address.
3) use the new 1988 Call Deflection facility to route the call through
automatically to the right destination, and return a called line
address modification notification facility to the source for its
future reference. This allows the same VC to be used for address
resolution and for actually communicating. [According to the best
locally available rumor, Call Deflection seems to be like call
redirection, except that it works on a per-call basis.]
It can be argued that if servers are to be built, they should use ES-IS
protocol instead of an ad hoc approach like those above. This does not
entirely eliminate the need for preconfiguration of at least one
address, since the ES and IS can only communicate on an X.25 network
when one of them has called the other one, which it cannot do without
first having the appropriate X.121 address.
Bill Barns / MITRE-Washington / barns@gateway.mitre.org