Technology for a Realistic End User Access Network Testbed

Telenor has describes how the QoS parameters of applications provided in TORRENT are mapped to Generic Network Services classified by their network performance parameters. The Generic services are mapped to technology specific Network Service, e.g. ATM, IP, and IP DiffServ. The purpose was to investigate how QoS can be achieved in the framework of TORRENT, considering the full range of possibilities (applications, network services, etc) currently available, not been limited to describing what actually can be implemented in the TORRENT field trials. In TORRENT, the end users specify their preferences for applications and price/performance in a user profile, different quality levels will be offered for each application. In the TORRENT system the applications map to appropriate Network Services based on knowledge about service-to-resource mapping, users preferences, trend analyses and Network Provider data to provide appropriate, as specified in the Service Level Agreement (SLAs) for its customers. Our contribution describes the QoS-mappings, considering the SLA, willingness to pay, application profiles. Some detailed regarding QoS signalling and various cost models are also included. The QoS model description serves as the basis of a paper to be submitted to QofIS'04. This paper describes a systematic approach for specifying and mapping QoS parameters of a wide range of applications to multi-vendor and multi-technology network services, including 4G mobile systems and bandwidth brokers. TORRENT is used as a case in this paper to demonstrate the use of this systematic resource to service mapping method. More information on the Torrent project can be found at: http://www.torrent-innovations.org

In the Phase II system trials, the LAPs were based in Stuttgart (IND) and Basel (MCLab). Dedicated accesses to different types of networks were provided by tesion, enabling the LAP to select and access the most suitable network depending on the requested QoS. Since tesion is a full-service provider, there was a choice between voice (switch), data and Internet services. LAP features and interconnectivity were tested with the use of the MPLS and SDH core networks. The following interconnections were realised: - IP over MPLS; - IP tunnelled or via VPN; - SDH. The Phase II system trials included: - Ease of use/control/maintenance; - Reliability; - Ease of installation; - Acceptable service selection time; - Emergency access to basic service if power fails; - Fast & easy provision of new service to customers; - Diagnosis; - Support of different user profiles. System orientated tests will include: - Negotiation speed; - Appropriate communication between RG & LAP; - Throughput; - Transfer delay, delay variation; - Necessary intelligent functions in RG; - Necessary intelligent functions in LAP; - Application response times; - Suitable management platform specifications. More information on the Torrent project can be found at: http://www.torrent-innovations.org

FIPA is one of the main standards available within the software agent domain today. FIPA agents, which are part of the software agent domain are based on the concept of the distributed intelligent agent domain and requires secure and fair negotiation between agents. The TORRENT QoS negotiation agent system is based on the concepts of FIPA and requires secure and fair negotiation between agents. In order to achieve this, we need to, for example, ensure the availability of agent system services for authorized users and avoid the insertion of malevolent agent into the system. However, the main focus within the FIPA domain has not been on security issues but on development and testing. Since FIPA agents operate in an open environment they are vulnerable to security attacks and one should consider security issues, such as the problem of authentication of agents, securing communication, and preventing unauthorised activity from hackers or malevolent agents. This work focus on security issues in FIPA agent systems by giving overviews of software agent technologies and IT security before discussing and highlighting security issues in FIPA agent systems in general and the TORRENT agent system in particular. A threat analysis including an assessment of these threats was carried out as part of the TORRENT project. In this paper we present a subset of the results from this analysis and a security framework that meets some of these security challenges. More information on the Torrent project can be found at: http://www.torrent-innovations.org

The functional architecture provides a viewpoint of the TORRENT platform that is relevant to implementers and users of that platform. There are several layers: - Physical: This layer describes the hardware of the Local Access Point and the Residential Gateway, the interfaces and the physical links between them. - Linux-OS: This contains, apart from the operating system, driver extensions and Netfilter-based packet-handling extensions. - Support: This includes the applications programming interface (from Flextel), the Human-Computer Interface and Packet-Handling Functionality. It also includes the Agent Platform (FIPA-OS). - Decision: This agent-based layer can be subdivided in to 2 further layers. - Reactive: Session/Call Control, Policy Enforcement. - Proactive: Negotiation, Strategy, Policy Creation. More information on the Torrent project can be found at: http://www.torrent-innovations.org

The Service and Resource Management (SRM) Software is at the centre of the TORRENT project. It is novel in that it integrates the residential services including telephony, radio, television, Internet access and the monitoring of residential systems such as central heating. The SRM software achieves this by using novel agent technology to facilitate scalability, flexibility and a potentially vast range of customer-provider negotiation scenarios. The SRM system is being designed to meet user requirements such as availability, ease of use, flexible pricing structures, and security, ease of installation and easy-to-use fault diagnosis and management. It also meets the users expectations for the full range of telecommunications services, be they traditional or yet to come on to the market. The architecture of the SRM software emphasises accounting in conjunction with session and call management. The SRM system uses databases that contain customer profiles, preferences and service level agreements (SLAs). Further databases hold accounting (call and session) records for use by the accounts and billing manager. Modules supporting virtual files in the Linux filesytem are used to provide effective communication paths between the agent-system and both the kernel and Netfilter. This solves potential problems with (e.g.) concurrency, locking and latency. More information on the Torrent project can be found at: http://www.torrent-innovations.org

APi software was developed to enable the agents to perform the TORRENT functionality, that is, to handle connections and to manage the Flextel platforms. Flextel provided the API for the LAP management (LAMA). It required the development of a library and of some demons running on the Processors in the Flextel Platform. This API software has the following functionalities: - LAP hardware management (Alarm Handling, Configuration, Hot Plug/Unplug); - Network connection statistic and alarm counters handling; - General purpose primitives to support specific agent needs. The primitives allow the Flextel platform to improve its management and configuration capability as: - Reliability; - Ease of installation; - Emergency recovery when power fails; - Diagnosis. This library and the related demons have been commercialised in the release 6.0 of the Flextel. More information on the Torrent project can be found at: http://www.torrent-innovations.org

In the Torrent system proxies are used to help with the routing and the route pinning of packet flows of different types of service, and also to extract dynamic information about related data flows/connections from initial signalling flows/connections. While a proxy operates in the user space, there is an alternative mechanism of using protocol helpers in kernel space based on the netfilter framework and the connection-tracking framework. While a proxy usually has to be addressed explicitly and terminates signalling relations for security reasons, a connection tracking protocol helper operates transparently and does not interfere with the signalling relation. The protocol helper has to extract the same dynamic information as a proxy, and therefore requires capabilities for parsing (signalling) packets of the protocol it should help. For the SIP protocol the viability of a connection tracking protocol helper has been investigated. The SIP protocol offers numerous options in the signalling, a number of protocol extensions, and also several application scenarios. It was possible to make a helper work for a specific client in a back-to-back setup for a control and a media connection with great difficulty. Due to this experience, a protocol helper can be considered to be a solution for simple protocols like HTTP or FTP, using only one or two related traffic streams. It cannot be considered to be a valid alternative for complex protocols with numerous related traffic streams. This holds especially true if additionally network address translation or complex call scenarios, as for instance in SIP, also need to be considered. More information on the Torrent project can be found at: http://www.torrent-innovations.org

- GLUE FUNCTIONALITY: A variety of code was required to enable the inter-operability of various components of the TORRENT architecture. It is intended to submit this code to appropriate interest groups. -- Kernel -extensions -- Added missing %s and %c functionality to the kernel sscanf function (simplified coding of our /proc modules) -- Provided a user-space mechanism to read the netfilter mark on the next packet in a socket's input queue (permits user-space code to be netfilter-mark aware) -- Apache mod-proxy extensions -- Features to bind outgoing IP-addresses -- Features based on the netfilter-mark on request packets -- Features applying netfilter-marks to outgoing packets -- Iproute2 IPv6 extensions (surprisingly many IPv4features are not available in IPv6) -- Source-base routing (limited functionality, meeting TORRENT's needs) -- Netfilter-mark based routing and queuing - COMMUNICATION BETWEEN KERNEL AND USER-SPACE CODE The /proc virtual file system provides a safe and efficient mechanism for communicating between kernel-space code and user-space code. Typically these /proc files are coded as kernel modules. TORRENT uses several files in the /proc file system. These not only provide communication paths between TORRENT components, but also permit issues such as concurrency, locking and latency to be handled. The majority of the data in these virtual files is described in the TORRENT data model. - AUTOMATIC CONFIGURATION OF THE TORRENT SYSTEM The configuration of a TORRENT system is quite complex, and potentially error-prone, so an automatic configuration system was developed. This takes a declarative definition of the required configuration, and generates a set of script-files, which are then used to establish the appropriate configuration. More information on the Torrent project can be found at: http://www.torrent-innovations.org

The prototype has been realized on the Flextel platform integrating a DSLAM CO Fujitsu Central office card. This Card is a development toolkit sold with hardware schemas allowing designing and producing a proprietary DSLAM hardware using Fujitsu chip. The activity included the following tasks: - To acquire knowledge on DSLAM and Fujitsu DSLAM CO card; - To develop new protocol over the internal Flextel High speed bus (IPB) to allow a high performance CLIP frame pass through; - To develop a new driver to allow the AAL5 frame management on the Flextel Processor Modules; - To experience a new access connectivity in the Flextel platform. This activity allows to test and verify the Flextel platform playing a new role as gateway between Access and Core Networks. As result Flextel produced a prototype that should became a product (Flextel DSLAM blade) in a time windows estimated in 8mm. More information on the Torrent project can be found at: http://www.torrent-innovations.org

In the Phase II trials, the Torrent equipment was based in Stuttgart (UST/IKR) and Basel (MCLab). Both test-beds were interconnected via Tesions backbone networks based on IPv6 over SDH, over MPLS, and over tunnelled MPLS. This offered three quasi-independent different networks to the Torrent system in order to show the policy routing of mircoflows according to user preferences. The connection of the trial sites to the Tesions backbone networks was realised over leased lines offering E1 connectivity to the LAP. The LAP itself hosted E1 cards. Setting up the trial site included basic setup and the configuration of the system, installation and testing of software (on UST as well as MCLab premises), and the support of partners for conducting test. In this process the establishment of connectivity over the E1 lines was not straightforward and required debugging. The Phase II system trials then were conducted as predefined. These included a number of higher layer tests as opposed to the Phase I test, mainly concentrating on lower layers. More information on the Torrent project can be found at: http://www.torrent-innovations.org

Flextel, providing the hardware LAP platform and the Cards for Access and Core Network connectivity, has been deeply involved in the test bed activity in term of support in the configuration phase and experienced in the integration of different kind of Connection cards in the Flextel platform. It allows to experience new configurations and to test the Flextel Platform in some not traditional network scenarios. It is a great add value for Flextel that can use the results of test bed as input for its market presentation and for the description of real scenarios where the platform can be used. In addition, test beds have been a good ring where to experience and to verify the use of IPV6 in the Flextel platform both, in a pure IPV6 scenario and in a mixed scenario where IPV4, IPV6 and tunnelling functionality have been tested. These tests arose over the IPB (internal Flextel high speed bus) and versus external devices as other Flextel platform and third party products. More information on the Torrent project can be found at: http://www.torrent-innovations.org

The LAP has connections to Residential Devices (via their Residential Gateways) and to several networks. In general, packets enter the LAP, pass through the firewall, are handled by the proxy, pass out through the firewall, and finally leave the LAP. Packets belonging to services barred by the user-preferences of their originating Residential Device are rejected before they get to the proxy. Outbound and inbound packets pass through the firewall and proxy, and go into an outbound and inbound queue respectively. To look at the interactions between the SRM components, consider the first outbound packet of a service, and the first inbound response packet. Assume that the packet is from a RD behind RG1, whose user preferences require this service to use network1 with priority 3. It is then possible to identify 14 detailed stages (see diagram) as shown in deliverable D3.4. The diagram in D3.4 hows an initial IPv4 proof-of-concept implementation. The IPv4 + IPv6 implementation used for the final demonstration used netfilter connection marking for client <--> proxy microflows. Applying the connection marking via netfilter protocol helper routines gives a system with enhanced scalability that also ensures that the change of user-preferences does not impact existing microflows for that user. Some code was also needed to overcome limitations in iproute2 code for IPv6 Future developments would also use connection marking for proxy <--> server microflows between proxy and server. These can be applied by netfilter protocol handler routines, that communicate with the proxy via a virtual file in the /proc routine library. More information on the Torrent project can be found at: http://www.torrent-innovations.org

The initial testing of system hardware interoperability included: - Ease of use/control/maintenance; - Reliability; - Ease of installation; - Emergency access to basic service if power fails; - Diagnosis; - Appropriate communication between RG & LAP; - Suitable management platform. More information on the Torrent project can be found at: http://www.torrent-innovations.org

Packet Handling is done in the Linux Kernel (v2.4) using the Netfilter framework, an abstract and generalized framework, which is not only protocol independent, but also modular and extensible. When IPv6 was incorporated into the TORRENT, one of the aims was to realize as much as possible of the packet handling functionality for IPv4 and IPv6 in the same way. As the available functionality of the Netfilter/iptables framework for IPv4 and IPv6 was and still is very different, it was decided to enhance the available IPv6 functionality to better fit the projects requirements. In a first step the connection tracking functionality was ported to IPv6. The actual flow information is exported to the user space as in IPv4 by means of the process file system of Linux. Connection tracking on IPv6 then was enhanced with a patch available on IPv4 to add byte (and later packet) counts of flows to the connection-tracking table, and additionally with the ctnetlink functionality to send the flow states together with the counters to the user space. A logging daemon in the user space also was ported to IPv6 for logging the respective information. As a last step to allow for stateful firewalling in IPv6, the state match was ported as well. The functionality being useful to TORRENT are the means to examine and modify packets to influence routing and queueing of packets, stateful filtering of packets to realize a firewall functionality, and the possibility to indicate packet flows and associated traffic volumes to the user space, all of that in IPv6. More information on the Torrent project can be found at: http://www.torrent-innovations.org

In TORRENT, Intracom has developed a residential gateway (RG) that comprises HW and SW modules, with target to provide connectivity and advanced applications support for a magnitude of terminals and devices. Intracom considers the RG being a system where by interchanging plug & play interfaces, the services provided by the gateway itself can still be on and transparent to the user. The RG has extended processing capabilities focused on the SW part of it. In some way, it resembles a general-purpose computer, while being also a portable and popular SW platform. Such one had been a Java one, which enables the write once, execute everywhere concept. Intracom co-operates to other vendors so that, existing devices (e.g. PC, STB) upgraded with modules similar to TORRENT, finally lead to the RG concept. There had been 4 RG prototypes available for testing and demonstration during all TORRENT trials, with multiple interfaces for the in-home networks; ISDN and ADSL connections to the access network. More information on the Torrent project can be found at: http://www.torrent-innovations.org

Authentication Issues in Multi-Service Residential Access Networks. In Proceedings of the 6th IFIP/IEEE International Conference on Management of Multimedia Networks and Services, Belfast, Northern Ireland, Ireland, September 7-10, 2003. The TORRENT system allows residential customers to choose amongst a variety of service offerings, over a range of Core Networks and subject to user requirements such as QoS, mobility, cost and availability. These issues place requirements on authentication for network access, with a need for mutual authentication of the RG and the LAP. This paper examines the authentication issues for the TORRENT system and presents a public key based authentication protocol for mutually authenticating the RG and LAP. More information on the Torrent project can be found at: http://www.torrent-innovations.org

Telenor has carried out the field trial in the House of the Future lab/demo environment. The focus was on qualitative user-related tests considering ease of install/use/maintain, reliability and new service provisioning. Personnel not having in depth technical knowledge, simulating an ordinary user carried out several of the tests. If TORRENT RG is to be offered in a home market, a user-friendlier interface must be provided. The RG uses the Webmin tool for configuration, that has nice graphics and is capable of performing all the configurations needed, but the tool is too complex for ordinary users in a mass market. The existing physical box is also too big, thus it should be migrated to a more pleasant format before market deployment. Also, documentation that can be understood by customers has to be provided, regarding mainly the RG management system. Firewall functionality was available, but by default set to allow all traffic. A lot of configuration possibilities were available, but complex to set. Basic pre-configurations should be enabled by default. Security matter being of extreme importance should be kept simple in order to allow common users to administrate the basic firewall features. The RG system ran 14 days without any problems, and recovered from a power failure, proving its reliability. More information on the Torrent project can be found at: http://www.torrent-innovations.org

The fine grained policy based routing on a per-user and per-flow basis being part of the TORRENT approach is itself a unique functionality, which, as far as the project is aware, is not offered anywhere else. The realization of this functionality has introduced a number of issues, which were not originally foreseen. Examples are: necessary enhancements to the Linux kernel (Linux being the basis for Torrent equipment), the necessity to use proxies and to also extend them, and, as a matter of principle, the different time scales on which certain parts of the Torrent system have to operate (e.g. agent platform vs. packet handling). Queues are used on a per-service and a per-user basis, which results, overall, in a large number of queues, devices the queues are associated with in the system, and an increased processing load, all of which potentially may prove to become limiting factors in the future. More information on the Torrent project can be found at: http://www.torrent-innovations.org

- User Preferences Data Base: The User preferences schema is still under active development. In the current schema, described below, the routing decisions are fixed by the database. For each entry in the table the combination rd + ip + port + mode must be unique. In future schema some freedom will be allowed for a context-dependent choice. - Field Semantics: -- rd IP-address of a residential device; -- ip Proxys IP-address; the null-string if the service is not proxied; -- port Proxys port number; the null-string if the service is not proxied; -- nw 1, 2, or 3 => network number; 0 => this service is barred; -- prty Priority; -- mode service-type id; -- what Human-readable description of service type. In a commercial TORRENT system the range of user preferences offered and their degree of customisability - would be a business decision, based on a market analysis of the planned customer-base. The following set of utility functions provides a simple interface, but provides a demonstration of the SRMs capabilities in traffic management: Gold, Silver, Bronze, Gsb, Blue and Green. The gold, silver and bronze utility functions can be used to show: Admission control, Bandwidth tradeoffs made with and without congestion, Per-microflow rate limiting and Per-service-role rate limiting. The gsb utility function can be used to show selection of the best-available choice from a range of options. The blue and green utility functions can be used to show how the selection process can respond to changes in tariff structure and QoS. Accounting Database: It was initially intended that the Accounting DB would hold IPDRs (Internet Protocol Detail Records), which could still be the right choice for an operational TORRENT system. However, it was then realised that the effect of individual test cases would be much more obvious if CDRs (Call Detail Records) were held instead. - Field Semantics: -- id Sequence number -- value Call definition record - Implementation: With the requirement of a multi-user, fully functional, open-source, relational database to run on Linux, PostgreSQL was a natural choice. As it many ways it is the Linux database (although it also runs on several other platforms). MyDB was briefly considered - as some partners had used it on other projects - but was quickly rejected because it did not support transactions. Besides its many standard features, Postgresql also supports some useful non-standard features. These include triggers, that are functions embedded in the database, called before/after specific entries/tables in the database are read/updated. Triggers can be used to help enforce consistency (i.e. referential integrity) in the database. More information on the Torrent project can be found at: http://www.torrent-innovations.org

In preparation of Deliverable D3.3 it was realised that certain features would be desirable in a commercial system. One of these features is network layer encryption is order to protect media streams from unauthorised reception. WIT-TSSG investigated the IPsec protocol for this purpose as it is now considered the standard for network layer encryption. More information on the Torrent project can be found at: http://www.torrent-innovations.org

The PTIN field trial has shown, through a period of three months, the Torrent behaviour as aggregator of three different access networks: ADSL, CATV and ISDN. Torrent Local Access Point (LAP) concentrates traffic coming from different access networks giving different treatments according to the user preferences. This allows having a single network edge point able of traffic prioritisation according to the user requirements capable of selecting the better core network, with advantages in terms of end-to-end QoS. In association it was shown the use of IPv6 over all the networks segments, meaning domestic, access and core networks where Torrent LAP smart routing was tested through connections to Euro6IX servers. The edge aggregation was demonstrated with success for ADSL and CATV access networks with both IPv4 and IPv6 showing a versatile solution in a migration from IPv4 to IPv6 scenario. More information on the Torrent project can be found at: http://www.torrent-innovations.org

In the Phase II system trials, the LAPs were based in Stuttgart (IND) and Basel (MCLab). Dedicated accesses to different types of networks were provided by tesion, enabling the LAP to select and access the most suitable network depending on the requested QoS. Since tesion is a full-service provider, there was a choice between voice (switch), data and Internet services. LAP features and interconnectivity were tested with the use of the MPLS and SDH core networks. In order to support the trials WIT-TSSG had deployed IPv6 internally for testing purposes. WIT-TSSG also established an IPv6 tunnel to HEAnet in order to act as a configurable Internet site for tests as well as hosting the source code repository for the project. WIT-TSSG now uses the services developed on the TORRENT project as part of the core infrastructure, and the entire facility is used as a testbed. More information on the Torrent project can be found at: http://www.torrent-innovations.org

Intelligent agent technology is used for an important part of the SRM software. Agent technology reduces the need for centralised control, and conceptually, also scales well with the size and capabilities of a telecommunications network. Negotiation is a strong feature of agent technology, making this technology especially attractive for TORRENT. Agent technology is also ideally suited to the plug-and-play approach in the standardized interface environment that TORRENT advocates for future home networks. Intelligent agents have been used successfully in mobile and ATM. This gives us confidence that this technology will provide TORRENT with the flexibility needed to accommodate a vast range of services, present and future, and a customer base that can fluctuate, both in terms of numbers and preferences. The functionality of the agent-based system is shown in the shaded area of the figure in D3.4. An agent representing the user negotiates with one or more network provider agents in order to initiate and control a session. A session may consist of one or more calls, where a call can be regarded as a single instance of service provision. The policy maker agent performs negotiations in accordance with customer preferences, network offerings, the customers ability to pay and any constraints placed on a customer. Such constraints may include the ability to pay for a service, authorised use of a service, network (e.g. bandwidth) constraints and general regulatory policy regarding network usage. Service negotiation may use mechanisms such as English, Dutch and Vickery auctions. Partner dominance in negotiations may also be relevant. The agent system is being hosted on a FIPA-compliant agent platform. The agent system has to seamlessly interact with a variety of other components, in particular: - The variously repositories. Here the issue is synchronisation with other users of the repository, as many users may be reviewing and/or updating their user preferences at any time. - The monitoring features of Netfilter (with our extensions). Here the issues are: - Reliably catching transient messages from the kernel. - Filtering them to reduce the load. - Passing them to the agent system, when it is ready to handle them. - The packet-handling features of Netfilter. Here the issue is expanding the high-level commands from the agent system into low-level instructions to Netfilter (and potentially other kernel functions, such as the /proc file system). In addition, any response or error messages from these components need to be handled. These issues are handled by the three daemons shown in the figure in D3.4, which can be identified by their blue shadows. These daemons are coded in C (fast and low memory footprint), and given an appropriate scheduling priority. More information on the Torrent project can be found at: http://www.torrent-innovations.org

For Versatel (previously tesion), TORRENT initiated the early deployment of IPv6 over MPLS, to fulfil the requirements for the IPv6 connectivity for the Stuttgart-Basel field trial. Versatel (tesion) is now among the first operators in Germany to have IPv6 implemented in their IP backbone. The configuration of IPv6 over MPLS was well tested as preparation for the TORRENT test-bed. This experience was used in a later stage for the integration of IPv6 in the total backbone. IPv6 is now commercially available for customers. More information on the Torrent project can be found at: http://www.torrent-innovations.org

MCLab applied MP3 Streaming over IPv6 that was used to measure whether or not QoS was being supported adequately. The MPEG Layer III (MP3) streaming is the preferred choice for most online radio stations. As shown at http://www.icecast6.remcom.org the MP3 streaming server, can also easily act as a relay for several IPv4 based streaming radio stations. Icecast delivers audio in a live situation, or audio on-demand for archived broadcasts. The administration can be conducted over Telnet or web interface. Many audio players can listen to Icecast streams, as it's been built to remain compatible with Nullsoft Shoutcast. Popular clients such as XMMS or Winamp can also stream audio to an icecast server, using specific plugins. The setup in MCLab is as shown in D4.5B. More information on the Torrent project can be found at: http://www.torrent-innovations.org

In the initial investigations of the project, it became apparent that a dual stack Proxy would be required: - WIT-TSSG did the initial investigations into the Proxy technologies available. - Did initial tests to prove that the proxyforward feature of Apache could be utilised for the benefit of Torrent, the result of this work was made available to partners. More information on the Torrent project can be found at: http://www.torrent-innovations.org

Deliverables

Share this page

Download