IPv6 - New Oppurtunities for European Public Network Operators IPv6 and IPv4 - Quality of Service (QoS) bandwidth-on-demand - alternative trunking     Classical Internet has a vast potential and covers a wide range of applications. However, a serious drawback is that the Internet cannot guarantee the bandwidth required by real-time services, such as telephony or videophone. The EURESCOM Project P702 has set out to investigate the support of user initiated bandwidth-on-demand for the Internet, especially in connection with IPv6 (Internet Protocol version 6). The idea is to use (public) switched networks, such as PSTN, ISDN, ATM or Frame Relay, to explore opportunities for so-called Non-Broadcast Multiple Access Networks (NBMA), the Internet terminology for public switched networks, to transport specific IP flows with a specified QoS. The illustration on the cover shows how a user or application in the P702 context may choose between classical Internet and the fast P702 “guaranteed bandwidth” alternative. Project P702 combines the best of two worlds: the Store and Forward IP world and the Circuit Switched Telephony world.   The current world-wide Internet is based on the protocol IPv4 (Internet Protocol version 4). Although it has some limitations, Internet usage is increasing dramatically. Almost all known telecommunication services and applications are technically feasible over this network. Examples are: e-messaging, Web-site hosting, telephony, audio, video (still and moving pictures), retrieval and conference services. Despite its undoubted success and ubiquity, IPv4 reflects the limitations of a protocol of the early seventies. It is increasingly unable to cope with the migration towards services with real-time and multicast requirements. Problems also arise for delay and delay variation sensitive multimedia services, where there is a need for specific QoS or for differential service levels. IPv6 is being developed by the IETF to address many of these problems and to enable scaleable IP services to meet future growth demands. In essence, the protocol has been extended to meet new requirements, such as address space, flow labels, traffic class field and security features. It has also been simplified with old parameters, such as check-sum, type of service, flags and identification options being removed. Project P702 has investigated network scenarios and specified building blocks which combine the best of two worlds: the Store and Forward IP world and the Circuit Switched Telephony world. Two experiments were specified by P702. The first was internal to the Project, and experimented with IPv6 tunnelling and traffic-driven switching over to ISDN. The second is being carried out in co-operation with the Danish vendor Telebit Communications and the University of Lancaster in the UK.   The Project has developed a so-called Cut-through Reference Model that exploits the general characteristics and requirements of a dynamic bandwidth-on-demand service. The model shown below identifies the main elements of the architecture that are common in all scenarios (Figure 1). The main elements of the Cut-through Reference Model are: CLNS: Connection-less Network such as Public Internet or Private Intranets. Non-Broadcast Multiple Access Networks (NBMA): currently ISDN and ATM. Decision Point: the machine that has the hardware and software to route packets to different networks types (CLNS, NBMA). Cut-through Data: the point where all the relevant static or dynamic information is stored or calculated. Policy: the information about who is allowed to use what, when, with what characteristics, for how long and at what price. Flow Specification: the information about the specific characteristics of a cut-through, such as bandwidth and delay Autonomous System (AS): a collection of machines (router and hosts) that share one Decision Point and one set of associated Cut-through Data. Examples are: a PNO/ISP and the customer base. The decision is made by the user, but the Decision Point is in the network. The user must therefore signal his or her flow requirements to the Decision Point. The IETF RSVP is used for this purpose in conjunction with an IPv6 QoS routing table based on subscription information that enables the requested flow requirement to be mapped to the appropriate network type and bandwidth.   Figure 2 shows the EURESCOM P702 bandwidth-on-demand Demonstrator set-up. The hosts H1, H2 and H3 are all connected to Decision Points DP1, DP2 and DP3 respectively via Ethernet. The route through DP2 represents an IP Internet. The ATM switch represents an ATM network, while ISDN1 and ISDN2 are the connections to an ISDN network. Through the ISDN network, an IPv6-in-IPv4 tunnel is set up in order to forward IPv6 traffic over the IPv4 ISDN boxes. Users subscribe to this bandwidth-on-demand service and the subscription information is stored at the Decision Points as policy information. When starting an application, the user selects the QoS parameters for the flow transmitted by the application via a graphical interface. The application may also make this selection automatically. The selection is signalled to the Decision Point using an RSVP PATH message and then routed according to the next-hop information found in an IPv6 QoS routing table. A Flow ID based on source address and the IPv6 Flow Label is then used to register the flow in the reservation table, enabling subsequent data packets for which a Flow ID match is found to bypass a full router table look-up. The mapping of QoS parameters to the selection of bearer network at the Decision Points is subscription specific and under the control of the PNO. This is an implicit choice of the bearer network and the required network bandwidth. Users are notified of rejected requests for QoS. The signalling of flow requirements and subsequent reject or success results is signalled by RSVP. Accounting information is collected at the Decision Points and transmitted as account records to a Network Management Centre, where they are logged. In general, as much as possible is designed according to available or emerging IETF RFCs, ATM Forum specifications and ITU Recommendations. In particular, the signalling between the host and the Decision Point of user or application selections is done by means of IETF RSVP over IPv6, which is currently on the standards track. IPv6 for different media is also encapsulated according to IETF drafts or RFCs. The ATM SVC service is accessed according to ATM Forum UNI 3.1. The main item that goes beyond the framework of the above specifications is the concept of Decision Points, where the assignment of routes of IPv6 packets in a flow are based not only on Destination and Source IPv6 addresses, but also on a EURESCOM defined interpretation of other fields in the RSVP PATH message. This interpretation, together with policy information, is configured in the Decision Points by means of network management and forms the basis of deciding whether to assign a route for a flow via ISDN via ATM SVC networks or via normal IPv6 Internet.   The main advantage of IPv6 is its random integer “flow label” which is used as a hash key. In conjunction with the source address, a globally unique flow identifier is created that identifies traffic flows in case of collisions. This results in an efficient look-up process far superior to the traditional association of source address, destination address, as well as possible protocol identifier and port number. Further items of note are: The first operational National IPv6 network (UNI-C) is already two years old. The kernel of the IPv6 specification and address format is stable. IPv6 is less about address shortages and more about providing a scaleable addressing structure to enable the Internet's growth to continue. IPv6 provides: Extended address space allowing hierarchical prefix based routing (smaller routing tables) and overcoming future address shortages. A standardized header format and size making it easier to process packets in modern 64 bit hardware architectures. Header and payload compression. Standards track QoS and differential service features. Mandated security (authentication, integrity, confidentiality and key management). Mandated autoconfiguration in both stateful and stateless modes. Updated routing protocols (RIPv6, OSPFv6, BGP4+, IDRPv6). Multi-homing possibilities. Dual stack migration strategy ensuring interoperability with the installed base of IPv4 devices. Simplified mobility supporting mobile and nomadic scenarios.     EURESCOM P702 information Participants: BT TELECOM ITALIA S.p.a. FINNET Group Koninklijke PTT Nederland N.V. Telecom Eireann Telia AB Subcontractors: Telebit Communications A/S University of Lancaster Project Leader: Henk Groen, Unisource, Tel.: +31 70 3 71 13 37 Project Supervisor: Amardeo Sarma, EURESCOM For more information: EURESCOM GmbH Wieblinger Weg 19/4, D-69123 Heidelberg, Germany http://www.eurescom.de Tel: +49 62 21 9 89-0, Fax: +49 62 21 9 89-2 09