Skip to main content
European Commission logo print header

Multiple Organisation Interconnection for Collaborative Advanced Network Experiments

Deliverables

The UPB/CCSRST IP sub-island is realised as a complex test-bed for advanced e-Learning services and related communications, on IP based heterogeneous packet network offering deeper insight in know-how on configuration, installation and QoS controlling. One main result is the demonstration that this joint use of the DiffServ and IntServ technologies is a good solution for future Internet QoS - guarantee-capable network. The QoS oriented configuration must be performed and real-time aspects would be monitored. The set of services offered by the MOICANE network are: - e-Learning (Video Audio Conference -VAC, chat, whiteboard, FTP, Voice over IP-VoIP, VoD streaming). - VoIP as a stand-alone service. - Virtual Lab: On line laboratory Whiteboard, LabView and Virtual Electronics Lab, IP traffic measurements, VoD streaming, FTP, Whiteboard, Chat, Remote X on measuring devices, Video-audio conference.
In the CPR solution the BR placed at the boundary between the access network and the DiffServ network, is called X-DS BR, where X is a generic QoS architecture (i.e. IntServ, H.323, SIP, DiffServ). The X-DS BR plays a key role in the MOICANE scenario, or potentially in network service provider architecture, as it is responsible to understand the signalling coming from the access network, and to accept or refuse the signalling requests according to the resource availability on the DiffServ network and on the established policies. The DS BR router is placed at the boundaries of different domains within the DiffServ core network. In the MOICANE framework, it is used for interconnection between islands. In a real network might be use to connect islands under different administrative domain. The DS Core Router (DS CR) is the "simplest" element of the DS network architecture (from a Control Plane viewpoint) since no signalling functions are needed. This network element provides DS traffic forwarding capabilities and management / configuration capabilities by a specific communication with Bandwidth Brooker.
One of the main object of the MOICANE project is the study and the implementation of the two architectural models for IP-QoS, meaning the IS (IntServ) and DS (DiffServ) models. OTE is a telecom operator and is now deploying an MPLS network over Greece. DiffServ and MPLS are two separate standards, which purport to help solve the IP quality problem. DiffServ operates at Layer 3 only and does not deal with lower layers. On the other hand, MPLS specifies ways that Layer 3 traffic can be mapped to connection-oriented Layer 2 transports like ATM and Frame Relay. So the mapping of these two different protocols is extremely useful for the deployment of an IP QoS in MPLS networks.
The DiffServ Core and Border routers enable different levels of QoS on a TCP/IP network, so even in situations of network congestion is possible to deliver the contracted services. On this way it is possible to deliver Video Conference, Telephony or other services that need the delivery of network data with quality better than "Best Effort Service" of traditional TCP/IP. The Border routers identify the packets that belong to flows with contracted QoS and police the flows to assure that they only use the contracted resources. The Core routers give the contracted services to the previous identified packets. Currently one Core DiffServ Network is implemented. It delivers different levels of QoS. It was possible to deliver a videoconference over the network, by using this device, even in a situation of network congestion.
In an advisable network scenario the peripheral non-DiffServ access networks, mainly IntServ networks with the RSVP signalling protocol but the approach could be generalized (H.323, SIP, MPEG-4, etc.), are connected to a DiffServ core network (as for the access network, the approach could be generalised to an MPLS core network). In such a scenario the key elements are the Edge and Border Routers, which manage the interoperability between diverse domains. In our solution the functionality of both devices are unified within a single element called X-DiffServ Border Router (X-DS BR, where X is for a generic access network architecture, e.g. IntServ). Our solution focuses on the possibility of integrating diverse protocols used in the Access Network. In a general scenario, applications speaking different "languages" may coexist, and the access point of the Core Network, that is the X-DS Border Router, must understand all these languages. For this purpose, an extension (a new unified client-type) to COPS protocol was defined. This innovative mechanism is used to transport admission control messages despite of the signalling protocol (e.g. RSVP, SIP, H.323) and from the QoS protocol (e.g. DiffServ/MPLS). Therefore a single client could be supported by the Bandwidth Broker while the complexity is shifted on the border router where a appropriate Inter Working Unit (IWU) is used to map protocol specific messages into generalised client messages.
The proposed extension to the LBAP traffic characterisation, called 3D-LBAP, were taken as input in the design of DiffServ service architecture, which allows the user (be it an final user or an intermediate DS service provider) to specify its traffic descriptions and QoS needs in terms of 3D-LBAP parameters. These studies on 3D-LBAP characterisation will also allow the dimensioning of the QoS parameters of the IP network nodes in both the access and core sections of any networks.
Taking advantage of a well-known graphical programming platform, specialised in programmable cooperation of real instruments with virtual ones, ICCS develops an application utilising a family of electronic filters. End - users will be able to make remote use of this virtual electronic infrastructure. Additionally according to the goals of the project this user- device interaction will take place over a QoS - enabled network. The overall outcome is to test the potential of the MOICANE network to support this interaction of users with remote devices, ensuring an adequate quality of service in the delivery of the measurements and the transportation across the network of the remote commands.
The ADSL is a strong broadband candidate as an access technology in Internet, for real time flow transfer, including E-learning applications. The main access equipment is a DSLAM (Digital ADSL Access Multiplexer and in particular the ATM Subscriber Access Multiplexer (ASAM) has been used. If the DSLAM ADSL multiplexer is ATM used, then several stacks and configuration solutions exist with different performances w.r.t. QoS. (e.g. PPP/PPTP/ATM, Remote bridging, IPoATM, PVC) The purpose is to find the best solution to map the higher layer requirements to the lower layer data and control plane (at ADSL level) in order to obtain the best QoS guarantees for the given application. These concerns cover a major role in the operational, as well as performance, maintenance of an arbitrary QoS-enabled architecture (in the MOICANE pilot all the most widespread technologies have been actually deployed). Monitoring and testing of the data and control planes are performed, in a dedicated workpackage of the project regards both the access and core parts of the overall topology, so allowing the achievement of a complete background in the field.
The Bandwidth Broker is an important component in a Differentiated Service Network. It decides which flows of data can have QoS in the network and manages the resources of the routers to accomplish the best possible performance of the network. This way it is assured that the committed services will have the contracted QoS, despite the number of new flows that ask for services if the network does not have enough free resources. The Bandwidth Broker has the potential to solve some network flaws, by reconfiguring the network around the problems and dropping the QoS on less important flows to assure the others flows achieve the contracted services. Presently the Bandwidth Broker has three functions: - Initialises and configures the Differentiated Services on the routers. - Decides which flows the network can serve with the requested QoS. - Configures the Border routers so that only authorised flows have QoS and use no more than the requested resources.
ICCS develops several QoS-aware applications, in order to demonstrate the capabilities and on the other hand the constraints of the Diff-Serv core network deployed by the MOICANE consortium. These applications constitute a set of two services, e-Learning service and Virtual Lab service, services that aim at familiarising end-users with a new generation network and its innovative "philosophy of operation". End-users will interact with SLAs and experiment with the technical requirements that the proper operation of the applications demand. In parallel the applications deployed by ICCS will help in testing the performance and robustness of the overall MOICANE network. Killing applications like video-conferencing (based on the H.323 protocol) and a bandwidth and delay-constrained demanding Video on Demand (streaming MPEG-2 video) application will test the limits and capabilities of the MOICANE pilot.
The Bluetooth Access Point (AP) is a device that performs the interface between the radio interface based on the Bluetooth technology and the wired interface of the Access Network. Due to the unavailability of LINUX device drivers for Bluetooth NICs, the Bluetooth AP will be implemented in the MS Windows 2000 operating system. This prevents the implementation of IP mobility and QoS at the AP. The architecture of the Bluetooth AP comprises the following modules: - Radio Interface: This module comprises the set of device drivers that implement the layer-2 functionality of Bluetooth. The Bluetooth hardware is from Digianswer, which allows the access to lower layer functionality through the BlueTooth SoftWare Suite (BTSWS) API. On the other hand this module offers an NDIS interface to the TCP/IP module. - Ethernet Interface: This module implements the layer-2 functionality of the wired interface, through which the AP connects to the backbone routers of the wireless access network. It offers an NDIS interface to the TCP/IP module. TCP/IP: This module implements the TCP/IP protocol stack, including routing functions. - Bluetooth/H.323 Gateway: This module consists on the extension of an existent telephony Gateway to support the Bluetooth interface. It converts between Bluetooth SCO based streamed voice and H.323 packet based telephony at the Ethernet interface. The Bluetooth control plane is accessed through the BTSWS API, while the voice SCO stream is accessed with the standard audio interface of Windows, the Waveform Audio interface. The H.323 functionality is based on the Elemedia H.323 API, which supports the complete H.323 protocol stack (including the RAS and H.245 session establishment protocols in the control plane and RTP packetisation in the data plane) and is totally compliant with NetMeeting (it should be noted that NetMeeting is in fact built on top of the Elemedia H.323 API). - Although the Bluetooth AP runs the Bluetooth SCO/H.323 Gateway, it also supports ACL based Internet access, allowing the transmission of all kinds of IP traffic in simultaneous with H.323 telephony. As an example, a Bluetooth user is able to establish a telephony call with QoS guarantees at the radio interface while performing Web browsing.
The problem of translating QoS requirements from applications to IntServ and IntServ-DiffServ mapping is a crucial point in the emergence of new applications. The study of combined cutting-edge QoS technologies, over an Integrated Services (IntServ)-Differentiated Services (DiffServ) architecture, is applied to an IP based pilot network for advanced communication (e.g. e-Learning). The architecture consisting in control (signalling) plane and (data/user plane) is studied and designed for different access technologies and applications. The MOICANE network infrastructure contains several heterogeneous islands interconnected where the applications developed are running (example of a next generation Internet network able to provide QoS guarantees at the IP level). The UPB/CCSRST sub-island contains one Core Network DiffServ Domain. The CN/DSD is implemented by using Linux PC based routers.
The IEEE 802.11b Access Point (AP) is a device that performs the interface between the radio interface based on the IEEE 802.11b technology and the wired interface of the Access Network. The 802.11b AP runs on a Linux machine configured as a router. Its architecture comprises the following Software modules: - Radio Interface: This module implements the layer-2 functionality of the radio interface, through which the AP communicates directly with the terminals. - Ethernet Interface: This module implements the layer-2 functionality of the wired interface, through which the AP connects to the backbone routers of the wireless access network. - Traffic Control: This module implements the traffic control functionalities of the AP used by both IntServ and DiffServ: packet classification, marking and policing for upstream and downstream aggregated flows. - Routing: This module implements the IP routing functions of the AP. - IntServ Entity: This is the ISI implementation of IntServ, which includes RSVP signalling and correspondent configuration of the Traffic Control module. - IP Mobility Entity (TIMIP): This module implements the Terminal Independent Mobility for IP (TIMIP), exchanging TIMIP signalling with other APs and the ER. Handover is detected transparently to the terminals based on layer-2 notifications AssociationInd and DisassociationInd. The former is called when a terminal requests an association to the local radio interface, while the latter is called when the terminal requests a disassociation in order to move to a different radio interface. Both primitives receive the MAC address of the terminal as a parameter. The IP Mobility Entity interacts with the Routing module through the IP tool (IPT) of the LINUX kernel interface. - IP QoS Configuration Entity: This module is responsible for the configuration of the Traffic Control module and the IntServ module, in order to accomplish the integration of IntServ and DiffServ. It uses the TC tool commands to access the Traffic Control module.

Searching for OpenAIRE data...

There was an error trying to search data from OpenAIRE

No results available