The basic service, a shared, switching infrastructure, that an IXP will usually offer to its members will probably be evident by inference from other parts of the 'Starting an IXP' section of the Euro-IX web site, however there are a number of further services that an IXP can offer.
As existing IXPs have grown they have been in a position to provide a number of services, other than a basic shared switching infrastructure, to their members. In some case these services have been requested by the members, in other cases an IXP itself has initiated a new service. One issue for an IXP to consider when contemplating a new service is how it fits in with the IXP's model. Most existing IXPs do not compete with the business activities of their membership (this may be explicitly stated in an IXP's operational terms and conditions, or an implicit understanding). Most European IXPs have a 'neutral' model; the inevitable conflicts of interest and difficulties in recruiting new members that would occur should the IXP compete with its members have generally led them to avoid this situation.
This page discusses the basic services, and a number of further services that an IXP can offer. No attempt is made here to determine what services (other than the provision of the shared switching infrastructure itself) should be offered, this is a matter for each IXP. Nor is the list of services intended to be definitive, the list represents the principal services offered by existing IXPs Shared switching infrastructure.
This service is the core of all IXPs. Technical and other details have been discussed previously, and whilst it is relatively simple to provide the infrastructure, consideration should be given to how it will be supported. A start up IXP will rarely be able to provide 24x7 technical support for the infrastructure. There may be other limitations in the service that can be offered, such as site access for members, switch availability during maintenance and guaranteed connection timescales for new members, to name just a few. The reasons for theses limitations are usually well understood by the members, however it is good practice to publicise the extent of, and limitations to, the service provided. This is best done via the IXPs web site and mailing lists, and it is reasonable to consider the provision of a web site and at least one technical or operational mailing list essential to the function of the IXP.
It is almost inconceivable that an active IXP would not have a web site, but the content of that web site is not always given a great deal of consideration. At the very least it should outline the model and principals of the IXP, the cost and conditions of joining, and contact details for the IXP operator. Obviously a web site can be a vehicle for vast amounts of information, and the maintenance overhead of a very large site can be high, so in a start up situation it is probably advisable to keep the content to a minimum, but to ensure it is current. There are, however, some services that can be provided via a web site that an IXP may wish to consider in addition to the minimum above. These are the provision of statistics and a 'peering matrix'. Many IXPs provide publicly available statistics on the traffic through the IXP, and whilst this is not strictly speaking a service to the members, it performs a useful function to advertise the importance of an IXP in the Internet infrastructure. A peering matrix, sometimes obtained automatically from questioning the routing databases, indicates who is peering with whom amongst the IXP members. This can be particularly useful for new members when considering whom they may wish to, or be able to, peer with.
As mentioned above, it is extremely useful to have at least one mailing list for the IXP operators and members' operational personnel to discuss technical matters concerning the IXP. Many IXPs run multiple mailing lists, to discuss various aspects of the IXP. Whatever mailing list structure an IXP decides to operate it is important that the persons using the lists understand their use. Typically, the people on the lists will not appreciate off-topic postings or abuse of the lists.
Many European IXPs have expanded to provide access to their switched infrastructure on multiple sites in a given Metropolitan area. Whilst it is unlikely that a start up IXP will need, or be able, to do this, the growth of the market place and the expansion of co-location facilities would suggest that a new IXP would be advised to keep up to date with potential new sites.
In parallel with providing multiple site access, a number of IXPs have extended their service to provide access at Gigabit speeds. Again, it is unlikely that a start up IXP will need to be able to provide this at day one, but consideration should be given to the upgrade path for equipment and other implications of providing this service as and when traffic levels demand it.
As mentioned elsewhere, some IXPs provide their members with access to a router connected to the switched infrastructure that all members' networks peer with. This router listens to all route announcements but makes no route announcements of its own. It is often a useful fault finding tool for a member to be able to 'view' the IXP via this router, particularly when they do not have visibility of the exchange via their own connected router. The number of potentially available routes at the IXP can also be ascertained from such a device. This information can be useful when marketing the IXP to encourage new members to join.
The question of whether an IXP will allow member routers to be co-located in the IXP has been discussed previously, but where this service is offered consideration should be given to the practical aspects. Space, power, cooling and other environmental conditions must be taken into account. Physical access to the IXP must be provided for installation, upgrade and maintenance. 'Out of Band' comms access may be required, involving telco circuits and terminating equipment. It may be the case that an IXP must offer this service due to its location - it may not be possible for members to have their own local co-lo space if the IXP is not situated in a public co-location facility. Also, the IXP may wish to encourage members, who do not wish to take their own space, this becomes more common when members are being solicited from regions remote from the IXP. Whatever the circumstances a start up IXP is recommended to consider the implications carefully.
Some of the longer established IXPs are offering facilities for members to use IPv6 and multicast. Currently, most IXPs offering either or both of these facilities are doing so on a test or trial basis, and they are provided on infrastructures independent of each other and the main IXP. As these technologies are adopted by more ISPs, (in particular IPv6) the implications will need to be considered by all IXPs, and whilst an IXP starting up today may not need to concern itself with this immediately it would be appropriate to take the potential short term developments into account.
The concentration of ISP connections at an IXP can make it a very convenient place for one ISP to have a direct physical connection to another where their router equipment is co-located and with whom they exchange significant traffic. Some IXPs prohibit this, whilst some encourage it, so there are clearly two schools of thought. Prohibiting the practice will avoid any issues of responsibility for the IXP, stop any ISPs potentially taking advantage of the IXPs facilities to reduce their co-lo costs, and possibly encourage ISPs to peer 'publicly'. Encouraging the practice will increase management and responsibility overhead for the IXP but reduce the traffic through the shared switching infrastructure. (It should perhaps be noted that it might not be in the interest of a start up IXP to reduce the traffic through its own infrastructure.) At least one IXP also offers this service for members who do not have router equipment co-located within the IXP, but within the same co-lo facility.
Some IXPs offer a route server facility. This is typically a device that interrogates routing registries, builds a database of the entries in the registries for the member networks, and provides a routing table based on this information. An IXP member's router may then build its routing table with just one peering session with the route server rather than taking many routing tables from all its peers. The principal aim is to reduce the processing power required in the member router connected to the IXP, however inconsistencies in the routing registries tend to make this unreliable.
Some IXPs provide services unrelated to the exchange of Internet traffic. It is understandable that an organisation such as an IXP, involving many ISPs might well become a forum for debate about industry issues, but whether the IXP should actively involve itself is a contentious issue. Some ISPs will not want their membership fees spent on anything other than the switching infrastructure and its direct support, they will wish to take care of trade association issues via alternative means. Trade association activity tends to be country specific, ISPs from countries other than that in which the IXP is sited will not necessarily benefit from trade association activities. Also, where the membership is made up of ISPs of greatly differing sizes their requirements from a trade association are likely to be quite different, and in some cases requirements may even be diametrically opposed. For these, and possibly other, reasons, the majority of IXPs actively avoid becoming involved in these activities. This being said, an IXP, particularly in a start up phase where it's members are of a similar size and a relatively small number, could be a focus for the ISP industry, and a useful representative of its constituent members. Probably the most important requirement for an IXP considering such activities is that there is a very high level of consensus amongst the membership, and that the activities are reviewed regularly to reflect the change in members' requirements as the IXP grows.