The target of 4 to 6 Transformation Project is a research field and business process related to the network infrastructures migration from IPv4 to IPv6. Currently only about 8.6% of the IPv4 address space is free therefore that process could be considered inevitable. The migration to the new protocol could be pretty expensive for the network operators and extremely disruptive for the end customers. The Project aims to deliver an open framework capable of handling the migration process. The framework consists of three major components – Business Transformation Logic (BTL), Network Inventory and Service Transformation. Each of the components extends the Fulfillment, Assurance and Billing (FAB) Model and could be easily integrated with the current OSS systems.
Keywords: IPv4, IPv6, FAB model, Service and Network Transformation, OSS, Business Transformation Logic, Network Concepts and Objectives
4to6TRANS Project Concepts and Objectives
The 4to6TRANS project aims to deliver scientific and technical quality in the area of Future Internet to all kinds of network players throughout Europe. The project target is the process of transforming IPv4 to an IPv6 based networks. Currently IPv6 is matured enough and is already widely supported by the network industry vendors and software manufacturers ,. Most of the Operation Systems, Browsers, Email Clients, Web and DNS Servers already support IPv6. The share of free IPv4 address space is getting smaller and it is expected the network providers to migrate their current services and subscribers to the new protocol . Nevertheless, still a real migration to the new protocol does not occur. It will be costly and extremely disruptive, which is the major factor impeding its real start.
Another reason is that in the current OSS, there are no tools, software, commercial and open platform able to handle similar migration. Facing that problem, the project authors propose 4to6trans framework to be created, having the power and ability to model the current services, to speak with the network devices and to follow certain business logic during the transformation process. The framework architecture consists of several Application Programmable Interfaces build on technologies beyond the current state of art. A similar network migration task being extremely complex, the, Project authors promote the idea of an open framework instead of closed platform. That is the only way to handle/have control on the variety and complexity of the current IP networks.
The framework is supposed to give the possibility to the Network Operators to perform the transition in controlled and automated fashion. The final project output will be of great help to a big number of Internet Service Providers, Cable, Telecoms and Mobile operators to optimize the transition process and to reduce the loss of service periods in their networks. From the other perspective the end users (most of the population of European Union) won’t experience a significant loss of service during that service transition periods.
Fig. 1 presents a typical IPv4 Internet Service Provider network with some common network nodes and services . We have an MPLS backbone and several service clouds build around it. The project focuses on service transformation of ISP residential clients, but also on Inter ISP BGP peering and corporate data services. The framework will be robust and flexible enough to handle easily the communication with great diversity of network devices as routers, switches, radius/diameter servers, Policy Control Points, xDSL modems, WiMax base stations and IPTV platforms.
As a final result the framework will be able to transform the described IPv4 based services and platform to IPv6 one, if the last is supported on that platform. In case the protocol is not supported, a transition methodology will be proposed and configured on the devices of the network operator. The final result is fully or partially migrated IPv6 based network (fig.2.).
For the purpose a number of open application programmable interfaces (API), able to model the transformation process, are to be specified and created.
The first stage is the specification of the framework’s API. The API’s can be split in three major groups:
- Business Transformation Logic (BTL)
- Network Inventory
- Service Transformation
The output of that phase is:
- Detailed framework architecture specification
- Network Inventory APIs software specification
- BTL APIs software specification
- Service Transformation APIs software specification
The second phase is APIs creation. The APIs are to be realized in the state of the art technologies like PL/SQL, J2EE, JFC SWING, ORACLE and XSL. The output of that phase is:
- Network Inventory APIs source code
- BTL APIs software source code
- Service Transformation APIs source code
The third part of the project is on testing and integrating the framework with real network devices. One of the project objectives is to test the API’s against different network vendors.
Several service provider architectures will be simulated with most of the common ISP services. The services planned to be tested are Internet BGP Peering, DSL Internet access, MPLS L2 VPNs and MPLS L3 VPNs.
The goals achieved in the last phase are:
- Perform Inter vendor Network Discovery
- Perform Inter vendor Device/Service Upload
- Model certain service business logic through workflow creation
- Transform IPv4 services and subscribers to an IPv6 following certain business logic.
The output is:
- Network Discovery documentation
- Network Upload documentation
- Prove of Concept Tests documentation