CURRENT_MEETING_REPORT_
AGENDA
``A WORLDWIDE INTERNET - What's missing ? - What do we need to do ?''
o Introduction
o Background information (European network situation, current status
of X.25 Research Network, future plans, etc.)
o Network situation in some oversea countries (Argentina, Australia,
Brazil, Indonesia, Israel, Japan, etc.)
o Status report on BBN-VAN-GATEWAY (butterfly replacement, EGP, etc.)
(Chet Birger, BBN) - Discussion
o Discussion on submitted RFC-Drafts:
1. Internet Cluster Addressing Scheme
2. PDN Cluster and Hierarchical VAN-Gateway Algorithms
3. Assignment / Reservation of Internet Network Numbers to
National X.25 Public Data Networks (DNICs)
o Hierarchical Scheme for the Assignment of PDN-Cluster Addresses,
Draft RFC (Roki)
o X.121 address resolution protocol, Draft RFC (Roki); detailed
technical discussion
o Access control and reverse charging on international X.25
connections, draft proposal; detailed technical discussion
o VAN-BoX (Specification of required protocols using formal
description techniques)
o Coordination of international PDN Routing performance tests with
partners in: Germany, Sweden, United Kingdom, Austria, Italy,
Norway (Zone 2), USA (Zone 3), Japan (Zone 4), Australia, Indonesia
(Zone 5)
o Detailed technical discussion and definition of a test plan
o Discussion on documents to be published by members of the PDN
Routing WG
o Assignment of action items
o Miscellaneous (mailing lists, etc.)
MINUTES
Report of the Open PDN Routing WG Meeting, IETF, November 2, 1989
Network Situation in Europe and Some Overseas Countries (reported by
Roki):
o German X.25 Research Network:
According to the plans, a German X.25 Research Network (X.25 WIN)
will be installed and operated by the German PTT, starting January
1990. A large number of German universities and research
institutes will be connected to this X.25 Research Network at fixed
costs. A gateway to the German DATEX-P network will allow
interoperation with the worldwide system of X.25 Public Data
Networks (PDN).
Due to the charging policy for the X.25 Research Network (fixed
costs), most universities, having local TCP/IP networks, are
especially interested in exchanging TCP/IP datagrams with each
other through this X.25 research network.
The PDN Routing and VAN gateway algorithms, which have already been
published or are currently specified, are expected to improve the
interoperability between these local TCP/IP network and to reduce
the amount of network management significally.
o International X.25 Interconnect (IXI):
The Commission of the European Communities (CEC) and the Dutch PTT
on behalf of all European PTTs have signed an agreement for an
international X.25 infrastructure in Brussels, in September 1989.
o NORDUNET:
This large network interconnects hosts in the Scandinavian
countries (Denmark, Finland, Iceland, Norway and Sweden). A
satellite connection from the NORDUNET (Sweden) to the US TCP/IP
Internet exists. The supported networks are: EARN,
NSFnet/Internet, SPAN/HEPNET, OSI Pilot Services, EUnet, etc. The
supported protocols are: TCP/IP, DECnet, ISO IP, X.25, RSCS, etc.
The Swedish Institute of Computer Science (SICS) will participate
in international PDN tests performed by the PDN Routing WG.
o TCP/IP Networks in Oversea Countries:
Several TCP/IP networks exist already in Australia, Japan,
Argentinia, Brazil, etc.
With the support of DLR/FernUni a TCP/IP network is currently
installed in Indonesia at LAPAN (Air and Space Research
Establishment) and other national agencies (BPPT, etc.). Satellite
communications will be provided by VSAT using X.25 protocols. It
is intended to integrate these networks in international PDN tests.
Status Report on BBN-VAN-GATEWAY (Zbigniew Opalka, BBN):
The LSI-11/23 has been replaced by a butterfly gateway, which runs EGP
for network reachability information exchange (with CNUCE, Italy, etc.).
The BBN-VAN-GATEWAY will participate in international PDN tests
(contact: Zbigniew Opalka and Chet Birger).
X.121 Address Resolution Protocol, Draft RFC (Roki), technical
discussion:
The proposal for an X.121 address resolution protocol (developed at the
FernUni), which is currently being written up as an Internet Draft, has
been discussed in detail.
For a dynamic routing of Internet datagrams through X.25 Public Data
Networks (PDN) an X.121 Address Resolution Protocol (X.121 ARP) is
required to determine the mapping between the 32-bit Internet address of
a PDN-host/ VAN-gateway and its X.121 address on the X.25 network. This
X.121 address resolution can be performed by:
o a table lookup on the local host/gateway
o a fast X.121 address resolution using the user data field in X.25
calls
o an X.121 address resolution retrieved from a remote X.25
host/gateway
o by information exchange with an X.121 address resolution server
X.121 Address Resolution by Table Lookup:
The mapping between the Internet address and the corresponding X.121
address is contained in a data file ("XARP.PDN"). X.121 address
resolution is simply performed by a local table lookup. A standard for
the format of this file ("XARP.PDN") will be specified, so that it can
be distributed to other PDN-hosts and VAN-gateways (by FTP) for X.121
address resolution. Whenever a PDN-cluster address is assigned to some
PDN-host or VAN-gateway, the corresponding X.121 address will be updated
in the (original) XARP.PDN file.
The following format has been discussed for the XARP.PDN file:
<IP-ADDRESS>:<X.121-ADDRESS>[;<FACILITIES>[;<ACCESS
CONTROL>]][:<COMMENT>]
It has been agreed, that the fields <FACILITIES>, <ACCESS CONTROL> and
<COMMENT> (e.g., containing the host/gateway name) should be optional.
Packet Identifier in X.25 Call Setup Packets:
According to RFC-877, IP datagrams are identified by a value of CC (hex)
in the first octet of the user data field in an X.25 call setup request
packet.
A (new) interpretation of the bits of the first octet in the user data
field has been discussed:
1 1 0 0 x x x x
| | | |
| | | +---- 0: NO Reverse Charging
| | | 1: Reverse Charging requested
| | +------ 0: NO ARP
| | 1: ARP
| +-------- 0: Extended User Data Field (20 octets)
| 1: Regular User Data Field (packet identifier only)
+---------- 0: NO IP datagrams
1: IP datagrams will be transmitted
According to the new interpretation of the bits of the first octet of
the user data field, the following packet identifiers would be used for:
Type hexadec. binary Comment
Fast X.121 Address Resolution (FXARP) C2 11000010 ARP
X.121 Address Resolution (XARP) C6 11000110 regular, ARP
Piggy-Backed Fast X.121 ARP (PFXARB) CA (CB) 11001010 IP, ARP
IP Datagram (RFC 877) (IP) CC (CD) 11001100 IP, regular
(X.121 Address Res. using UDP (IP) CC (CD) 11001100 IP, regular)
NOTE: A possible conflict with already defined values of the first octet
of the user data field (C0-CF) for other applications has been
mentioned. In this case the following alternative has been discussed:
The first octet of the user data field would always contain CC (hex),
according to RFC 877. Then, the bits of the second octet would indicate
the packet type as follows (similar to the specification above):
0 0 x x x x x x
| | | | | | | |
| | | | | | | +---- 0: NO Reverse Charging
| | | | | | | 1: Reverse Charging requested
| | | | | | +------ 0: NO ARP
| | | | | | 1: ARP
| | | | | +-------- 0: Extended User Data Field (20 octets)
| | | | | 1: Regular User Data Field (packet identifier only)
| | | | +---------- 0: NO IP datagrams
| | | | 1: IP datagrams will be transmitted
| | | +------------ 0: Request
| | | 1: Reply
| | +-------------- 0: NOT unsolicited (request or reply)
| | 1: Unsolicited
| +--------<reserved>: for future use
+----------<reserved>: for future use
Fast X.121 Address Resolution Using the User Data Field in X.25 Calls:
A fast X.121 address resolution can already be performed during the call
setup time by specifying the X.121 address resolution request/reply
information in the user data field of the X.25 call setup request/accept
packets, in the following format:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Packet Identifier | 0 0 x x| (Pointer) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Max. X.121 length = 8 | Length of IP address=4|
+-----------------------+-----------------------+
| IP address of sender |
+-----------------------+-----------------------+
| IP address of target |
+-----------------------+-----------------------+
|Len. X.121 | X.121 address of target | in X.121 ARP reply or
| (encoded in quartets, padded with 0's) | unsolicited X.121 ARP
+-----------------------------------------------+
Note: that the X.121 address of the sender is contained in the X.25
packet header (calling DTE address).
Example:
194 22 4 14 188 1 255 1 189 42 128 1 227 17 6 23 0 2 80 0
Fast Reply
X.121 IP X121 IP address IP address X.121 address (311061700025)
ARP Ptr 6 Len. of sender of target of target
X.121 Address Resolution Protocol for X.25 Hosts/Gateways:
The following X.121 Address Resolution Protocol (similar to the Ethernet
Address Resolution Protocol (RFC-826)) for Internet hosts and gateways,
which are directly connected to an X.25 Public Data Network, has been
discussed:
The first (second) octet of the user data field in an X.25 call setup
request packet contains C6 (06). When the X.25 connection is
established, then, the following X.121 address resolution request/reply,
is transmitted in the data field of subsequent X.25 packets:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Hardware Address Space (PDN) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Protocol Address Space (DoD_Internet) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Max. X.121 length = 8 | Length of IP address=4|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Opcode |
+-----------------------------------------------+
|Len. X.121 | X.121 address of sender |
| (encoded in quartets, padded with 0's) |
+-----------------------------------------------+
| IP address of sender |
+-----------------------------------------------+
|Len. X.121 | X.121 address of target |
| (encoded in quartets, padded with 0's) |
+-----------------------------------------------+
| IP address of target |
+-----------------------------------------------+
X.121 Address Resolution using UDP:
In case, that the X.121 address resolution cannot be obtained from a
host or gateway directly connected to the X.25 network, the X.121
address resolution request/reply messages are sent to an X.121 address
resolution server in IP datagrams using UDP. The data field contains the
X.121 address resolution request/reply as specified above.
Access Control and Reverse Charging on International X.25 Calls:
An "X.25 Call Setup and Charging Determination Protocol" has been
developed at the FernUni and is currently being specified as an Internet
draft. This protocol will allow reverse charging on international X.25
calls, which is of special importance for a worldwide interoperability
of TCP/IP networks.
Also, the specification of an access control scheme has been discussed,
but most people suggested that access control should be done by higher
layers.
Implementation of the Proposed Algorithms in a VAN-BoX (or on a
Workstation):
The IETF-PDN Routing working group has already developed and specified
most of the required PDN addressing schemes and gateway algorithms to
allow a dynamic routing of TCP/IP datagrams through the worldwide system
of X.25 Public Data Networks (PDN). The required algorithms and
protocols include:
o PDN-cluster addressing scheme: published ICCC'88 and RFC Draft
o Hierarchical VAN-gateway algorithms: published in ITG/GI'89 and
RFC Draft Assign. and Res. of PDN-cluster net no.: Internet
Draft to be published as RFC
o Assign. and Res. of PDN-cluster addr.: being finished as an
Internet draft
o X.121 Address Resolution Protocol: being finished as an Internet
draft
o X.25 Call Setup and Charging Determ: being written up as an
Internet draft
o Modified EGP2 or EGP3 between VANs: currently in progress to be
defined
o Delayed TCP/IP header compression: will be considered (new
objective)
By putting all these pieces together, it is intended to implement these
algorithms, with support of the gateway companies (BBN, Proteon, SUN,
3COM, ACC, cisco) and eventually the University of Salzburg and the
University of Tokyo, in a small "VAN-BoX" (and on a workstation) with an
Ethernet and an X.25 interface. By placing this "VAN-BoX" between a
local TCP/IP network and an X.25 public data network, the implemented
gateway algorithms will automagically exchange network reachability
information to provide worldwide INTERNET interoperability between local
TCP/IP networks through X.25 Public Data Networks.
Coordination of International PDN Routing Performance Tests:
The developed PDN addressing schemes and VAN-gateway algorithms will be
tested with participating sites in the following countries:
Zone 2 (Europe):
Germany: Fern University of Hagen (all VAN-gateway levels)
GMD, St. Augustin (DFN-Gateway)
University of Dortmund (UUCP-Gateway)
University of Karlsruhe (BELWUE)
University of Stuttgart (BELWUE)
Austria: University of Salzburg
Finland: University of Helsinki (NORDUNET)
Italy: CNUCE, Pisa *
Norway: NTARE, Oslo, (NORDUNET) *
Sweden: SICS, Stockholm (NORDUNET)
UK: Portsmouth Polytechnic
University College London (INTERNET Gateway) *
Zone 3 (North America):
USA: ACC *
BBN, Cambridge, MA
CISCO, Menlo Park, CA *
PROTEON *
SRI, Menlo Park, CA *
SUN, Mountain View, CA *
3COM *
Zone 4 (Asia):
Japan: University of Tokyo
Zone 5 (Pacific):
Australia: CSIRO
Indonesia: LAPAN
Zone 6 (Africa): Egypt ?
Zone 7 (South America): Argentina ?, Brazil ?
(* ... intended, but not yet agreed) (? ... these countries will be
contacted for participation, to have at least one representative site
for each zone).
First tests have already been started within Germany. International
PDN-tests are expected to start in January '90 between BBN and sites in
Europe, Australia, Japan and Indonesia.
PDN-cluster addresses, according to the developed hierarchical scheme,
will be assigned to all participating sites, in Jan '90. An appropriate
application form has been prepared recently. SRI-NIC will be informed
about the assigned PDN-cluster addresses. The XARP.PDN file containing
the mapping between the Internet PDN-cluster address and the
corresponding X.121 address will be updated after each assignment.
Assignment of action items:
Stahl: Check assignment and specification of INTERNET/PDN-cluster
network numbers for national public data networks in the North America
cluster for correctness (O3, Jan '90)
Roki: Finish Internet Draft "Addressing Scheme for the Assignment of
INTERNET/PDN-Cluster Addresses to VAN-Gateways and PDN-Hosts" for
submission to the IETF Chair and Reviewers (O4, Jan '90).
Roki: Check the coding of the first octet of the user data field in
X.25 call setup request packets (related to o6, fast X.121 address
resolution protocol, Jan '90).
Roki: Finish Internet Draft "X.121 Address Resolution Protocol", for
submission to the IETF Chair and Reviewers (O6, Jan '89).
Roki: Continue Internet Draft "X.25 Call Setup and Charging
Determination Protocol" (O7, expected to be completed by Feb '90)
Roki: Perform international PDN-tests according to the developed PDN-
cluster addressing scheme and hierarchical VAN-gateway algorithms
between USA (BBN) and sites in Europe (Fern University of Hagen,
University of Dortmund, University of Salzburg, Portsmouth Polytech
(UK), SICS (Sweden), etc.), Australia, Japan and Indonesia, starting
January '90 (O11).
Comments, suggestions and contributions to the work being done in the
PDN Routing working group are highly appreciated.
ATTENDEES
Berggreen, Art Opalka, Zbigniew
Carvalho, Charles Rokitansky, Carl-Herbert
Cook, John Stahl, Mary
Malkin, Gary Youssef, Mary N.