New IP/IXI service
- Date: Thu, 13 Aug 92 14:06:14 +0200
- Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
- Organisation: Nikhef-H (National Institute for Nuclear and High-Energy Physics)
- Phone: +31 20 5925102, +31 20 6924218 (home)
- Telefax: +31 20 5925155
- Telex: 10262 hef nl
From: Rob Blokzijl (Chairman RIPE)
To: Tomaz Kalin (Secretary general of RARE)
Re.: IP service offered by EMPB
Date: 13 August 1992
Enc.: - announcement IXI service
- assessment IP/IXI service
Cc: - RARE COA
- ripe-org
Dear Tomaz,
we have read with great interest the announcement you published recently
regarding the appearance of a new IP service in Europe. I think
congratulations are due to the people who have worked hard for the last 20
months to reach this milestone.
As chairman of RIPE, the European IP coordinating committee, I can assure
you that we will cooperate in any way that is proper to ensure that the
new service is integrated in the European Internet in the best way
possible.
However, in order to be able to do that some actions have to be taken. The
first thing to do is to make the IP implementation plan of the new service
available. As you might know from recent discussions, triggered by your
announcement, great concern has been raised by European IP experts about
possible negative interference of the proposed service with the existing
services. One should keep in mind that the EMPB will not be an isolated
service: it has to fit in with the large existing European Internet.
The lack of available technical documents describing the new service is
certainly no great help. I append a summary report that goes into these
concerns to this message.
Secondly, I strongly urge you to see to it that the new service provider
takes full part in the coordination work done by RIPE. Without doing so,
the new service runs a serious risk of being a failure even before it
starts. This would result in a fragmentation of the European Internet.
Last, but not least, I remind you that the next RIPE meeting will take
place at the end of September. This is a unique opportunity to sort out
all technical details of interworking with the EMPB.
Let us all work together to ensure that the IP/EMPB service will be a
valuable addition to European IP networking.
Greetings,
Rob Blokzijl
----------------------------------------------------------------------------
Dear CoA members.
In view of recent developments in relation to the IXI Production Service
contract, the REC wishes to provide you with the following information:
SIGNATURE OF THE "FRAMEWORK" IXI PRODUCTION SERVICE CONTRACT
=============================================================
1. Background
The contract for the IXI-PS which has been negotiated by the CPMU is
structured as a common framework or "umbrella" contract between a
single entity and the service provider plus a set of bilateral contracts
between the service provider and the customer networks. The framework
contract specifies all aspects (technical and financial) of the service to
be provided; the bilateral contracts allow individual customer networks to
specify the set of services they choose to use.
In the liaison meeting between REC and CPB on 29 June 1992, it was
suggested that RARE was the organization which was in the best position
to sign the Framework contract for the IXI production service on behalf of
the European networking community.
2. The Framework Contract.
The need for the Framework contract arises from the fact that the OU has
not yet been established as a legal entity. The clear intention is that the
OU should take responsibility for the IXI-PS as soon as possible but, until
it is formally established, some way has to be found of keeping up the
momentum in the evolution of pan-European service provision. Since the
cost of basic (64 kbps X.25) IXI-PS is considerably less than that of the
IXI Pilot, there is also a large financial advantage in moving to the
IXI-PS
as soon as possible and in taking the necessary steps in parallel with the
creation of the OU.
The Framework contract provides a mechanism for proceeding
immediately. It commits the service provider to the specified terms as
long as enough customer networks agree to participate; there is no
commitment on the part of the customer networks before they subscribe
to the offered service by signing one of the set of bilateral contracts;
the
commitment of the other signatory of the Framework contract is limited
to making the terms of the contract known to potential customer
networks and recommending that they subscribe. The contracts can be
assigned to the OU as soon as it has been set up and this is the intention.
Within the framework of CIPEC, RARE has already signed contracts
necessary to set up services resulting from the COSINE project but, until
now, none of the contracts has covered a period which extends beyond the
lifeltime of COSINE. In contrast, the duration of the IXI-PS contract, as
proposed, is till the end of September 1995, i.e. well beyond the duration
of the CIPEC. There are nevertheless a number of good reasons for RARE to
sign the Framework contract as well.
This significant new departure, in combination with the general
importance of the IXI-PS, makes it necessary to present to the CoA, at
least in rough outline, the substance of the Framework contract and the
possible consequences to RARE of signing it.
3. The arguments in favor of RARE signing the Framework contract
The arguments are:
* The service offered by PTT Telecom to the users with the
proposed European multiprotocol backbone network is considered an
excellent offer at very competitive prices (which have already been
disclosed to CoA members on various occasions) in comparison with those
being paid for present services.
* RARE, on behalf of the community, keeps control of the way in which
the service is set up.
* No other organization is in a position to act in this way in the
interests of the national networks.
* If RARE decided not to sign the contract, the drive behind the OU and
harmonisation and integration of services in Europe would be lost and
further delay would be introduced in the long awaited enhancement of pan-
European backbone services.
In addition:
* RARE does not accept any binding commitments on behalf of the OU
* according to the contract elaborated by CPMU and the future service
provider (PTT Telecom):
- RARE takes on no financial commitment
- there is no automatic acceptance of the IXI-PS by
the Operational Unit; however, RARE and the customer participants offer
to assign the contract to the OU within six months after its formation
- RARE does not have to organise bilateral contracts between
the service provider and national networks at any time; RARE members are
not committed to signing any service contract. The risk for establishment
of service contracts rests with the provider
* The only financially binding commitments will be established by
the bilateral contracts for service provision between the PTT Telecom and
the national networks, for the services requested by them
REC members have examined the "umbrella" contract and, in view of the
above, support the signature of the contract.
Therefore, I would like to inform you that RARE Officers have now signed
the IXI - Production Service Framework contract on behalf of RARE. All
CoA members will be sent a copy of the Framework contract (and its
technical Annexes; a total of about 2 cm of paper) by ordinary mail as soon
as PTT Telecom return the copy with their signature.
Best regards
Tomaz Kalin
Below is a description provided by Dai Davies of the proposed services and
the contractual terms which have been agreed:
SUMMARY OF PROPOSALS FOR IXI PRODUCTION SERVICE
===============================================
Commercial Overview
The evaluation of the IXI Invitation to Tender has now been finalised and
the elements of a supply contract have been completed for the provision of
a Multi-protocol backbone service offering both X25 and TCP/IP accesses.
The evaluation was made on the basis of price/performance and overall
technical and operational credibility. This document summarises the key
elements of the proposal.
Service Availability
64 Kbits/sec X25 October 1992
2Mbits/sec X25 October 1992
TCP/IP October 1992
The availability of higher speed network connections is dependant upon
implementing a enhanced transmission backbone. The dates above
represent the availability of interfaces. The availability of service at
speeds higher than 64Kbits/sec could be 3-6 months from contract
signature depending on location and the time to implement 2 Mbit/sec
trunk circuits. It is proposed to pilot the TCP/IP service in the initial
phase. Availability of TCP/IP interfaces would be subject to an agreed
roll-
out program.
Access Point Pricing
The service is priced to a point of presence in each country; local access
lines would be charged separately. There is an initial connection fee of
1.5
times the monthly price of an access port. The access port prices are
subject to a confidentiality clause in the contract and are not
communicated in this summary since they have been provided on a
confidential basis to national network representatives. The relationship
between access prices and access port speed is provided below for
information.
Access speed Factor
9.6 Kbits/sec .5
64 Kbits/sec 1
128Kbit/sec 1.8
256Kbits/sec 3.5
512Kbits/sec 6
1Mbits/sec 8
2Mbit/sec 11.4
Prices are also available for other access port speeds.
Contractual Guarantees
The contract provides for contractual guarantees in respect to access port
availability, where an access port availability of 99.5 % is guaranteed;
monthly service availability where an availability of 99.7 % is guaranteed
and annual service availability where an overall service availability of
99.8 % is guaranteed. There is a compensation schedule specified if the
performance falls below these levels Total throughput performance. for
the backbone network is also specified and the supplier is contracted to
provide additional backbone capacity if the throughput performance falls
below agreed levels on the basis of a specified performance model.
Compensation arrangements envisage a transition period at the start of
network operation and an averaging period, the details of which are
specified in the contract . A clause requiring attached networks to provide
sufficient access capacity to carry their traffic is also defined
.
Network Performance
The guaranteed access performance to which the supplier is prepared to
commit contractually is as follows. Failure to meet agreed performance
will lead to penalties and can ultimately be regarded as a breach of
contract.
Access Capacity Throughput
at service start / April 1993
64 Kbits/sec 90% 90%
(128 Octet Pkts)
64 Kbit/sec 95% 95%
(1024 Octet Pkts)
2Mbits/sec 16% 21%
(128 Octet Pkts)
2Mbit/sec 64% 85%
(512 Octet Pkts)
2Mbit/sec 95% 95%
(1024 Octet Pkts)
The figures quoted are for duplex (ie both way operation) and should be the
same for X25 or IP traffic.
The solution does not envisage encapsulating IP-IP traffic in X25 packets
in the backbone subnetwork, but a proprietary datagram protocol, utilised
to carry backbone traffic
Embedded IP to native IP traffic is expected to be slightly less efficient.
The proposal meets the delay requirements stated in the invitation to
tender.
Overview of Technical specifications
The elements of specifications relating to X25 are as defined in the
Initial
invitation to tender documents. The IP service specification is based on
the backbone defined as a single autonomous system with access being by
either G703, V36 or X21 at speeds up to 2 Mbits/sec and LAN 8802.3 for
IP. The link levels supported include HDLC and PPP. The routing protocol
will initially be EGP and subsequently BGP. The usage of the same
backbone network allows for the provision of a single network operations
organisation. this will provide 24 hr 7day coverage .
Timescales
Annexes covering performance monitoring and operational procedures as
well as addressing are provided as part of the contract The end user
prices will be dependant on obtaining commitment to 75 access ports at
64 Kbits/sec or access port equivalents in the first twelve months (A
2Mbit/sec access port has an equivalent value of 11.4).
Piloting in the Production Service
The production service will become available in the third and fourth
quarters of this year. It will be offering a multiprotocl backbone capable
of supporting native X25, IP embedded in X25 and native IP as well as the
ability to interwork between the different modes of connecting IP traffic.
Whilst it will be possible to build on the X25 experience of the current
IXI
service there is a number of new areas where operational experience
needs to be gained in order to guarantee appropriate quality of service.
This is particularly true of the integration of X25 and IP on the same
backbone and the management of IP traffic.
In order to gain practical operational experience of IP it is proposed that
a
limited number of participants take part in an initial piloting of the IP
elements of the multi- protocol backbone.
The purpose of the pilot is threefold namely:-
1) To provide experience in integrating the currently separate IP
infrastructure in a common backbone
2)To enable the supplier to demonstrate the capability and
performance of the new systems
3)To provide a practical test bed for the higher performance
interfaces which will be made available in the new production service.
Commercial Implications
The pilot will have an agreed and limited set of participants and a set of
objectives defined in quality of service terms at the start. It should be
defined in two phases and have an overall duration of 9 months. The first
phase should last 4 months and should end in a review between the
supplier, the project manager and the participants who would agree
progress against the initial benchmarks. The progress to the second phase
would be dependant on achieving the initial benchmarks.
Subject to satisfactory progress in phase 1 the second phase would be
open to a broader set of participants. The aim would be, within 9 months
to have a fully functioning mutiprotocol backbone which would then be
available to all potential participants.
It is assumed that the pilot would have a successful outcome. In the event
of the supplier not being able to achieve the benchmarks the supply
contract will contain provisions to resolve the issues implied by the
failure to deliver. Ultimately, if the performance is regarded as
unacceptably poor this can be regarded as a material breach of the supply
contract.
(End of document)
-----------------------------------------------------------------------------
To: ecco@localhost
From: Bernhard Stockman boss@localhost
Subject: SOME CONCERNS WITH THE IXI PRODUCTION SERVICE
Date: Fri, 07 Aug 92 00:37:19 +0200
Sender: boss@localhost
SOME CONCERNS WITH THE IXI PRODUCTION SERVICE
Stockholm, August 7 1992
This is may personal thinking after having read the announcement of
the RARE signing of the framework contract for the IXI Production
Service with emphasis on the IP part of the described service.
Bernhard Stockman
1. Background
The RARE Executive Committee (REC) recently signed a framework
contract with the nominated provider of the IXI Production Service,
the follow-up of the COSINE IXI Pilot Service. This contract is not
economically binding but states the conditions for provision of the
service in terms of availability, speeds, costs etc. The actual
signing of an economically binding IXI Production Service has to be
done separately by each country interested in this service as there is
today no pan-European legal entity that would sign such a contract on
behalf of all nations involved.
Initially a 2 Mbps X.25 service was proposed under the name TRIXI
later renamed to EMPP (The European 2 Mbps Multiprotocol Pilot). The
EMPP has now been renamed to EMPS (European MultiProtocol Service).
The intention seems to be that the EMPS shall be the pilot phase of
the IXI Production Service. (One can of course question the need for a
pilot in something named a "production" service).
During the the first year(s) of specification work to define the
requirements in the call for tender of the IXI Production Service, the
Internet Protocol (IP) was never included. Recently IP was added as a
necessary requirement.
The following evaluations of the biddings to the IXI Production
Service and nomination of a winner was performed behind closed doors.
Especially there was no consultation of RIPE, the European IP
coordination activity. Through its meetings and information exchange
activities, RIPE has created a wealth of technical expertise and
experience in building large scale international IP networks. This
European pool of knowledge and experience was completely ignored.
This in spite of IP now was an integral part of the requested service.
Some European IP experts was finally invited in June this year, i.e.
when the service provider already had been chosen. Not to get
informed on the details of the IP service implementation as this was
still confidential but to help in specifying the pilot of the IP part
of the EMPS. This specification had to be finalised within a short
time after the IP experts were consulted, being part of the contract
to be signed. Consequently there was no time for reflections and
discussions.
2. Choice of Technology
The implementation of the IP part of the service will be based on X.25
switches with some kind of IP router built-in. It is today unknown
which kind of technology has been chosen to implement the IP service.
It may be the case that the switch vendor tries to make a "quick and
dirty" implementation of the IP service using some PC clone equipped
with "gated", a public domain software. It should be emphasised that
the IP routing technology and routing models supported has a big
impact on the total European Internet and its possibility of efficient
and stable connectivity to the global Internet.
3. Performance of the IXI Production Service
As one intention with TRIXI, EMPP, EMPS and now the IXI Production
Service is to build a 2 Mbps pan-European backbone, the performance at
this bandwidth is of course interesting. At 2 Mbps the IP performance
is initially 16 percent i.e around 300 Kbps and later to be improved
to 21 percent of the 2 Mbps full capacity in 1993. This at an average
packet size of 128 bytes.
A performance table of the IXI Production Service (Note: 2 Mbps is not
actually delivered by the PTT's but 1984 Kbps, 64 Kbps is used for
signaling internal to the PTT network).
From the Contract | Deduced
|
nom. packet start '93 | start '93 full start '93
kbit/s size % % | kbit/s kbit/s pkt/s pkt/s pkt/s
|
64 128 90 90 | 58 58 62 56 56
64 1024 95 95 | 61 61 8 7 7
|
1984 128 16 21 | 317 417 1938 310 407
1984 512 64 85 | 1270 1686 484 310 412
1984 1024 95 95 | 1885 1885 242 230 230
This is very rough not counting link level overhead etc. The "full
pkt/s"-column above shows the needed packet forwarding rate for a full
utilization of the available bandwidth.
The IXI Production Service will thus deliver a packet forwarding rate
of around 300 packets per second today with a promised upgrade to
around 400 packets per second 1993. This must be very cheap to have a
chance on the market. (Using today off-the-shelf IP routing
technology it is possible to achieve a forwarding rate of 20000 -
30000 packets per second between any two interfaces).
It should be requested that the IXI Production Service provider shows
a growth path consistent with expected performance needs. The quoted
performance figures for the IXI Production service so far indicate a
packet switching capacity per customer connection to be in the order
of 300 pkt/s initially. This seems quite low for current needs
already.
See the appendix for a calculation of average packet sizes in an
Internet network.
4. Interoperability
Questions like interoperability with the 1000's of networks in the
global Internet is not mentioned. Urgent subjects in the Internet
like the need for sourced based routing, the need for support of the
CIDR/supernetting according to current recommendations to cope with
the growth of the routing tables, etc. is never described.
The router implementation is stated to support EGP starting in October
this year and BGP later. What BGP version to be supported is not
mentioned. Support for BGP-III will be needed today to meet the
requirements for dynamic and fast converging policy based routing.
Support for BGP-4/IDRP and by that the supernetting in the very near
future will be essential judging from the estimated growth rate of the
today Internets to cope with these problems. Which kind of internal
routing protocol that will be used and if this interacts sufficiently
well with the exterior routing protocols is never mentioned.
There exist no officially available interoperability tests of the
chosen technology for the IP part of the IXI Production Service.
Compare with other vendors who take pride in bringing their products
to the Interop's to show their equipment can interoperate in the
Internet environment. Nothing like that seems to have happened here
but the choice of technology has been kept secret.
It should thus be requested by the IXI Production Service provider
that the technology used is revealed and independently tested. There
are independent tests conducted regularly and widely published both on
the networks and in the trade press.
It should be requested that the IXI Production Service provider has
coordinated routing with the rest of the European and Global Internet.
Evidence of this would be a statement by the RIPE routing WG to the
effect that it is expected to work.
It should be requested that the IXI Production Service provider shows
in depth understanding of ROAD issues and is likely to provide routing
technologies to support CIDR and "real" policy based routing. i.m.h.o.
this means source based routing and BGP-III initially and BGP-IV soon.
It could here also be noted that the IXI Production Service provider
have obviously assumed that there will be no transit across a region
to somewhere else in the world, not connected to them directly. This
is in reality probably an unvalid assumption.
5. Support for Common Network Management Interface.
In the Internet environment a protocol for common network management
has been specified, named SNMP. This protocol is today widely deployed
and supported of 100's of vendors equipment. The IXI Production
Service does not mention support of SNMP.
6. Cost Efficiency of the IXI Production Service
It would be very informative to see the actual prices of the offered
service but they are confidential and by that makes an open debate of
the cost-efficiency of the proposed service impossible. The prices has
been disclosed to RARE CoA members which thus will have the
possibility of doing necessary cost-efficiency calculations.
The IXI Production Service prices are based on the assumption that at
least 75 64 Kbps access point equivalents will be contracted where a
64 Kbps access point counts as 1 and a 2 Mbps access points counts as
11.4. If it turns out that there is not enough 64 Kbps equivalents
sold, the price offer will not be valid. Networks in Europe have
already signaled that they will not sign the IXI Production Service
before proven that it can deliver at least the same IP service
efficiency and performance as compared to the EBONE.
7. Pilot Results Questionable.
The contract states a 9 month pilot of the IP service. This pilot may
give a correct indication if done in a realistic way. However, only
those who actually subscribe and pay for the service will be eligible
to participate in the pilot, at least during the first 4 months.
Organizations that might be reluctant to spend money on an unproven
service, not signing the service contract, will not be allowed to
participate. This makes any positive results of the pilot highly
questionable because pilot participants will not be interested to
reveal that they have subscribed to and paid for a bad service.
8. Near Future Networking Requirements
Today we see pilots of 34 Mbps WAN in various parts of Europe.
Applications like multimedia mail, audio and video multicast are being
tested on the production backbones. There will certainly be a need for
upgrade of production services to these capacities in the near future
to cope with the current development. Such pilot services should be
done in close collaboration with deployed production backbones for
easy migration to production status when ready and needed. Any
production service contracted now needs to have demonstrated growth
path to this performance bracket. Otherwise the European R&D community
will again loose years and resources in a change of technology.
9. Conclusions
Due to the current growth of the Internet it will probably be
impossible to specify the service well enough to ensure it is useful
to the community if the supplier provides just the specified service.
It must be shown that they are willing and capable to adjust to
changing needs. The EBONE Routing Specification has already changed
several times during the lifetime of EBONE due to unforeseen growth
rates and new technologies becoming available. A pure service
contract is not the right structure for such a project.
The administrative community must understand that the technical
community is working hard to simplify the European Internet structure
to the point where it remains manageable given the expected growth
rates. This will only work if there is very close cooperation among
all service providers at the technical level and the specifications
remain flexible enough to make the necessary changes to keep it
working. Any service provider who does not cooperate closely with all
the others on the technical level and is not flexible to react to
changing technical requirements is not only a nuisance but a danger to
the whole community. Thus the administrative structures must allow
for such cooperation and flexibility. If they do not, they must be
considered harmful to the community.
What the provider of the IXI Production Service has proposed as an
alternative to the current EBONE IP service is an inferior technology
in terms of efficiency and absolute performance with no guarantee of
interoperability with the rest of the Internet.
All too often we are using very much non-optimal technical solutions
because of an administrative model that is very in-flexible in its
realization of the rapid growth/change of of the technology needed. IP
and it's needs are changing extremely fast right now, perhaps more
than ever before. People in the Internet community are working hard
to get new and dynamic solutions available. Europe must and has to
stay at the leading edge of this. If we don't we are in danger of
loosing the collaboration already built.
Coordination of IP networking in Europe have so far been managed
pretty well. RIPE has helped enormously in this regard as has the
advent of EBONE and the way it is being driven at the operational,
technical and management level. Due to complex policy requirements in
European networking EBONE has today one of the worlds most advanced
implementations of policy based routing. This could not have been
achieved without close cooperation among the leading European experts
in this field.
My personal hope is that EBONE will continue and evolve and that the
Operational Unit will, when established, function as a financial
clearing house for the EBONE IP service and the IXI X.25 Production
Service. The best implementations of both technologies for the best of
the the European R&D community. This could truly be called a balanced
approach.
APPENDIX
Calculations of Average Packet Sizes in Internet Networks
As we are using NNStat to gather all IP byte and packet counts in
NORDUnet it is easy to make a calculation of the average packet sizes.
(fi = Finland, dk = Denmark, no = Norway and se = Sweden)
europe-fi 55174477 packets, 11626545862 bytes -> avg pkt size 210.72
europe-dk 125112209 packets, 18838107299 bytes -> avg pkt size 150.57
europe-no 127259773 packets, 18835753323 bytes -> avg pkt size 148.01
europe-se 950619 packets, 61044589 bytes -> avg pkt size 64.21
A total average packet size for traffic between Europe and the
NORDUnet in May 1992 = 143.38. As Finland has large FTP archives
heavily used all over the world their packet size may not be
representative for most national IP backbones which probably are
closer to Sweden, Denmark or Norway in average packet size. 128 byte
packets would perhaps be close to an overall average of packet size in
IP networks.
An average packet size of 128 octets with an initial efficiency of 16
percent on 2 Mbps gives 328 Kbps. Using off-the-shelf IP router
technology it is possible to utilize up to 90 percent of the total
available capacity. This means that a network with a 512 Kbps
international connection would decrease its usable capacity with
around 130 Kbps, from 460 Kbps to 330 Kbps by purchasing a 2 Mbps IP
connection from the IXI Production Service.
It should be noted that packet size distributions are not usually
smooth but bi- to tri-modal. Applications like telnet and xwindows
generate small packets while ftp generates bigger packets. All kind of
acknowledgements are very small packets. This means that some
application will be hit more severely by a low packet forwarding rate.
For analysis of average packet sizes in the Internet see papers by
Hans Werner Braun and John Crowcroft.
