Upload
michael-ferguson
View
212
Download
0
Embed Size (px)
Citation preview
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 1
Interworking Between Public Data Interworking Between Public Data Networks and the Internet Networks and the Internet
A numbering perspectiveA numbering perspectiveITU “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: [email protected]
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 2
SummarySummary 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 3
Some IssuesSome Issues Key requirement:
– 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
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– 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 4
Some Issues (cont)Some Issues (cont) Can PDN terminals be identified by mnemonic
address such as [email protected] 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 5
Numbering of Public Data NetworksNumbering 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 6
Call Set-up for Frame Relay & ATMCall 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: – X.121 or E.164 number or NSAP address
For ATM the called terminal may be identified by: – 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 7
Use of NSAP to identify called terminal 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 8
General Interworking ScenarioGeneral Interworking Scenario
Public Data Network(X.25, FR, ATM)
INTERNETIWF
Point of attachment to public data networkdefined by X.121 or E.164 number
Terminal identified by IP address
Term A
Term B
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 9
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
Notes onNotes on General Interworking ScenarioGeneral Interworking Scenario
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 10
Interworking via an Interworking via an Internet Service ProviderInternet Service Provider
Public Data Network( X.25, FR or ATM)
INTERNET
Terminal B identified only by IP address
Internet Service Provider
FR or ATM Connection
FR, ATM or leased lineConnection to
Internet Backbone
Term A
Term B
EdgeRouter
Edge Router
Edge Router
Point of attachment to public data networkdefined by X.121 or E.164 number
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 11
Notes on Interworking via an Notes on Interworking via an Internet Service Provider (#1)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 12
Notes on Interworking via an Notes on Interworking via an Internet Service Provider (#2)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 13
What’s required for efficient routing What’s required for efficient routing from the IP network to a terminal on from the IP network to a terminal on
the PDN?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 14
INTERNET
Interworking Gateway Routers
Network DNIC3134
Network DNIC2288
Network DNIC5052
Network DNIC3139
IPv6Network Layer
X.121= 3134 908 949 5369
X.121=3134 908080136
X.121=22889089495369
X.121= 2288 914 308 3270
X.121=505292536308
X.121= 505291556144
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.
PDN - X.25 or Frame Relay
IPv6Network Layer
Example showing interworking via gateway routers Example showing interworking via gateway routers if the IP terminal could signal an X.121 Addressif the IP terminal could signal an X.121 Address
X.121= 313991556144
Edge or Border Routers
X.121=3134 908087788
IP Terminals
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 15
Is there a requirement for service Is there a requirement for service Interworking ?Interworking ?
PDN / IP Service Interworking
PDN IPIWFPDNDTE
IPTerminal
The IP Terminal has noknowledge that it istalking to a PDN DTE.
PDU on PDNencapsulation
PDU on IPencapsulation
The PDN Terminal has noknowledge that it istalking to a IP Terminal
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 16
Typical Scenario Typical Scenario for Service Interworkingfor Service Interworking
Video
IPFR / ATM
IWFCentralHost
VideoConferenceServer IP
terminal
LANR
LANR
Private Network
FR /ATMterminal
FR /ATMterminal
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 17
Service Interworking via a Gateway Service Interworking via a Gateway
Public Data Network( X.25, FR or ATM)
INTERNET
Terminal B identified only by IP addressService Interworking
Gateway
FR or ATM Connection
FR, ATM or leased lineConnection to
Internet Backbone
Term A
Term BEdge Router
Edge Router
Point of attachment to public data networkdefined by X.121 or E.164 number
Protocol translation&
encapsulation
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 18
FR or ATM / IP InterworkingFR or ATM / IP InterworkingProtocol StacksProtocol Stacks
Physical
IP
IP Terminal
Application
InterworkingGateway
FR or ATM
Data PDUVoice PDURFC Encap
Payload
IP
Physical Physical
? Implemtdepend
FRor ATMUNI
FR/ATM DTE
FR or ATM
Data PDUVoice PDURFC Encap
Application
Physical
? Implemtdepend
ITU “IP & Telecoms” Interworking Workshop, Jan 2000 19
ConclusionsConclusions 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 [email protected]
» 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 20
Conclusions (cont)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