You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

New IP/IXI service

  • To:
  • From: (Rob Blokzijl)
  • Date: Thu, 13 Aug 92 14:06:14 +0200
  • Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
  • Cc:
  • 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

   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.


   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: 


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
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;
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: 


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
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
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

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

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

Overview of Technical specifications

The elements of specifications relating to X25 are as defined in the
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 . 


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
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
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

(End of document)


To: ecco@localhost
From: Bernhard Stockman boss@localhost
Date: Fri, 07 Aug 92 00:37:19 +0200
Sender: boss@localhost


                     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

 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

    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


    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.

  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>