Interworking Between Public Data
Networks and the Internet
A numbering perspective
ITU “IP and Telecoms Interworking” Workshop
25-27January 2000
Submitted by Peter Hicks
Rapporteur ITU-T SG 7 Q3: Data Network Numbering
Tel: + 613 9253 6308, Fax: + 613 9253 6777
email: p.hicks@trl.telstra.com.au
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 1
Summary



This presentation examines numbering and
addressing issues associated with the interworking of
Public Data Networks and the Internet.
Interworking largely depends on being able to signal
the “called” terminal’s number or address
This presentation does not attempt to solve all the
technical or implementation problems but highlights
the key issues that will either allow or prevent
interworking to occur in the future.
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 2
Some Issues

Key requirement:
–

PDN Protocols (X.25, Frame Relay, ATM) are
connection oriented
–

PVC or SVC is established between the originating
terminal and the destination terminal before protocol data
units (user data) are transferred.
IP connectionless
–

Seamless interworking between terminals (DTEs) on
Public Data Networks (X.25, FR or ATM) & terminals (also
known as hosts) on IP routed networks or the Internet
no call set up phase exists
Is single-stage “dialling” possible or is two stage
“call setup” required?
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 3
Some Issues (cont)


Can PDN terminals be identified by mnemonic
address such as j.blogs@acme.com.au
How will PDN terminals be identified
–
–
–
–



X.121 or E.164 number only
X.121 or E.164 number plus an IP address
IP address only
is dual numbering/addressing required?
What functionality is required in the gateway
between PDNs and the Internet
Where is the gateway located
What QoS does the “end-to-end” connection
achieve (This is not a numbering issue)
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 4
Numbering of Public Data Networks


Frame Relay networks numbered under either X.121 or
E.164 - identifies DTE point of attachment.
ATM networks numbered under E.164
- also can use NSAP formats for ATM end system addresses


The leading digits of an X.121 and an E.164 number
identify the country where the network is located
Network Identification
–
–
–
within an X.121 number, the Data Network Identification Code
(DNIC) uniquely identifies a specific network
E.164 numbers generally do not have a network ID code built
in to the number; (flat number structure)
for networks numbered under E.164, a network ID code as per
Rec X.125 may be carried in a specific field of the signalling
protocol (not currently used for call set up)
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 5
Call Set-up for Frame Relay & ATM



Call Setup message identifies the called terminal
Called terminal’s point of attachment carried in the
called party information element (as per X.36, X.76 or
Q.2931 signalling)
For Frame Relay the called terminal identified by:
–

For ATM the called terminal may be identified by:
–
–

X.121 or E.164 number or NSAP address
E.164 number or NSAP address
only certain NSAP formats supported (embedded E.164,
ICD, DCC)
X.25 allows the called terminal to be identified by an
“alternative address” which can be an IP address, a
mnemonic address or an NSAP
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 6
Use of NSAP to identify called terminal

NSAP Formats (see Rec X.213 Annex A) include:
–
–
–
–
–


embedded X.121 number
embedded E.164 number
ICD (International Code Designator) Format
DCC (Data Country Code) Format
embedded IP address
Hence capability exists to signal an IP address
However use of NSAPs to identify the called terminal
requires additional intelligence in the switch to which
the calling terminal is connected
–
–
address resolution entity required
requires a “large” data base
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 7
General Interworking Scenario
Point of attachment to public data network
defined by X.121 or E.164 number
Term A
Public Data Network
(X.25, FR, ATM)
IWF
INTERNET
Term B
Terminal identified by IP address
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 8
Notes on
General Interworking Scenario







Requirement is for Terminal A to be able to send data
to Terminal B and for Terminal B to be able to send
data to Terminal A at any time
initiated by either party
Terminal A identified by X.121 or E.164 number
Terminal B identified by an IP address
Does Terminal A need to have an IP Address?
What protocol stack does Terminal A use?
What functionality is required in the IWF
–
address resolution or protocol translation
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 9
Interworking via an
Internet Service Provider
Point of attachment to public data network
defined by X.121 or E.164 number
Term A
Public Data Network
( X.25, FR or ATM)
FR or ATM
Connection
Edge
Router
Internet
Service
Provider
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 10
Edge
Router
Edge
Router
FR, ATM or leased line
Connection to
Internet Backbone
INTERNET
Term B
Terminal B identified
only by IP address
Notes on Interworking via an
Internet Service Provider (#1)
Case A: Terminal A sending data to Terminal B
 Terminal A must subscribe to the service provided by an
Internet Service Provider
 Terminal A sets up SVC or PVC connection to Internet
Service Provider.
–
–
Edge router of the ISP identified by X.121 number
IP address is allocated to terminal A by the ISP
»


Can this address be “permanent” or use made of DHCP?
IP packets encapsulated as Frame Relay or ATM user
Data and sent to the Internet Service Provider
Internet Service Provider routes IP packets into the
Internet for forwarding to Terminal B
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 11
Notes on Interworking via an
Internet Service Provider (#2)
Case B: Terminal B sending data to Terminal A
 What happens if Terminal A’s connection to the Internet
Service Provider is “inactive”
 What is the IP address for Terminal A
 How does Terminal B know what Terminal A’s IP
address is - can use be made of Inverse ARP?
 How does the Internet “know” the location of terminal A
–
if Terminal B receives an IP packet from Terminal A, does
this imply that the reverse path and IP Address for Terminal A
is known
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 12
What’s required for efficient routing
from the IP network to a terminal on
the PDN?

How is the PDN terminal identified
–
–
–

Does the terminal have a dual address ie, X.121 or E.164
number plus an IP address
what mechanisms are there available for carrying an
X.121 or E.164 number within the address block of an IP
packet
what extensions in IP addressing are needed to “signal”
an X.121 or E.164 number
What additional functionality is required in gateway or
border routers that allows identification of the PDN
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 13
Example showing interworking via gateway routers
if the IP terminal could signal an X.121 Address
IPv6
Network Layer
IPv6
Network Layer
PDN - X.25 or Frame Relay
Interworking
Gateway
Routers
X.121= 3134 908 949 5369
Edge or Border Routers
X.121=3134 908080136
X.121=3134 908087788
X.121=22889089495369
Network DNIC
3134
Network DNIC
2288
X.121= 2288 914 308 3270
X.121=505292536308
X.121= 505291556144
Network DNIC
5052
I
N
T
E
R
N
E
T
IP Terminals
Network DNIC
3139
X.121= 313991556144
In order that IP data packets can be efficiently routed to end system terminals connected to public data networks, the
Gateway Routers connected to the various public data networks could advertise the DNIC to the border routers on the
Internet: e.g. DNIC = 2288, The gateway routers would then need to establish the necessary connections to the PDN
terminals based on the full X.121 number.
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 14
Is there a requirement for service
Interworking ?
PDN / IP Service Interworking
PDN
DTE
PDN
PDU on PDN
encapsulation
The PDN Terminal has no
knowledge that it is
talking to a IP Terminal
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 15
IWF
IP
IP
Terminal
PDU on IP
encapsulation
The IP Terminal has no
knowledge that it is
talking to a PDN DTE.
Typical Scenario
for Service Interworking
Video
Central
Host
IWF
FR / ATM
IP
R
Video
Conference
Server
LAN
IP
terminal
R
LAN
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 16
FR /ATM
terminal
Private
Network
FR /ATM
terminal
Service Interworking via a Gateway
Point of attachment to public data network
defined by X.121 or E.164 number
Term A
Public Data Network
( X.25, FR or ATM)
FR or ATM
Connection
Protocol translation
&
encapsulation
Edge
Router
Service Interworking
Gateway
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 17
Edge
Router
FR, ATM or leased line
Connection to
Internet Backbone
INTERNET
Term B
Terminal B identified
only by IP address
FR or ATM / IP Interworking
Protocol Stacks
Payload
Application
Data PDU
Voice PDU
RFC Encap
FR
or
ATM
Application
Data PDU
Voice PDU
RFC Encap
FR
or
ATM
IP
IP
?
Implemt
depend
?
Implemt
depend
Physical
Physical
Physical
Physical
FR/ATM DTE
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 18
FR
or ATM
UNI
Interworking
Gateway
IP Terminal
Conclusions

The necessary code points within the FR signalling protocols
enable a calling terminal on the PDN to identify an IP
terminal (by use of an NSAP) in the call setup message.
–
–
extensions required in ATM signalling (Rec Q.2931) to allow
NSAP (embedded IP format ) to be supported
features such as X.25 “alternative addressing” would enable
the called party to be identified by a mnemonic address such
j.blogs@acme.com.au
»
»

extensions required to FR and ATM signalling protocols
required to facilitate interworking as demonstrated in the use email
today
Two stage interworking from the PDN into the Internet is
achievable today
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 19
Conclusions (cont)

Interworking from the IP world to the PDN appears to be
constrained by the fact that an IP packet can not readily
carry an X.121 or E.164 number to identify the
destination terminal on the PDN

will require extensions in IP addressing or
functionality to “signal” an X.121 or E.164 number
–
–
No such functionality in IPv4
May be able to use IPV6 address extensions options to
carry an OSI NSAP which contained the embedded X.121
or E.164 number
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 20