he Internet was simply designed for packet delivery. However recent developments such as commercialization and the diversity of application requirements make it obvious that a more concrete definition of the type of service delivered to the user is needed. This description of the service delivered by the network is called the service model and documents the commitments the network makes to the clients that request service. It describes a set of end-toend services and it is up to the network to ensure that the services offered at each link along a path combine meaningfully to support the end-to-end service.Traditionally, in the Internet all packets are treated the same without any discrimination or explicit delivery guarantees. This is known as the best effort service model; all the network promises is to exert its best effort to deliver the packets injected into it without committing to any quantitative performance (quality of service, QoS) bounds. 1 Users do not request permission before transmitting, and therefore perceived performance is determined not only by the network itself, but also from other users' offered load, resulting in a complete lack of isolation and protection. The best effort service model has no formal specification; rather, it is specified operationally; packet delivery should be an expectation rather than an exception. The traditional applications and protocols were flexible, adaptive, and robust enough to operate under a wide range of network conditions without requiring any particularly welldefined service. The Problem of CongestionCongestion is the state of sustained network overload where the demand for network resources is close to or exceeds capacity. Network resources, namely link bandwidth and buffer space in the routers, are both finite and in many cases still expensive. The Internet has suffered from the problem of congestion which is inherent in best effort datagram networks due to uncoordinated resource sharing. It is possible for several IP packets to arrive at the router simultaneously, needing to be forwarded on the same output link. Clearly, not all of them can be forwarded simultaneously; there must be a service order. In the interim buffer space must be provided as temporary storage for the packets still awaiting transmission.Sources that transmit simultaneously can create a demand for network resources (arrival rate) higher than the network can handle at a certain link. The buffer space in the routers offers a first level of protection against an increase in traffic arrival rate. However, if the situation persists, the buffer space is exhausted and the router has to start dropping packets. Traditionally Internet routers have used the first come first served (FCFS) service order, typically implemented by a first in first out (FIFO) queue, and drop from the tail at buffer overflow as their queue management strategy.The problem of congestion cannot be solved by introducing "infinite" buffer space inside the network; the queues would then grow without bound, and the end-to-e...

No abstract

No abstract

Sensors utilize a large number of heterogeneous technologies for a varied set of application environments. The sheer number of devices involved requires that this Internet be the Future Internet, with a core network based on IPv6 and a higher scalability in order to be able to address all the devices, sensors and things located around us. This capability to connect through IPv6 devices, sensors and things is what is defining the so-called Internet of Things (IoT). IPv6 provides addressing space to reach this ubiquitous set of sensors, but legacy technologies, such as X10, European Installation Bus (EIB), Controller Area Network (CAN) and radio frequency ID (RFID) from the industrial, home automation and logistic application areas, do not support the IPv6 protocol. For that reason, a technique must be devised to map the sensor and identification technologies to IPv6, thus allowing homogeneous access via IPv6 features in the context of the IoT. This paper proposes a mapping between the native addressing of each technology and an IPv6 address following a set of rules that are discussed and proposed in this work. Specifically, the paper presents a technology-dependent IPv6 addressing proxy, which maps each device to the different subnetworks built under the IPv6 prefix addresses provided by the internet service provider for each home, building or user. The IPv6 addressing proxy offers a common addressing environment based on IPv6 for all the devices, regardless of the device technology. Thereby, this offers a scalable and homogeneous solution to interact with devices that do not support IPv6 addressing. The IPv6 addressing proxy has been implemented in a multi-protocol card and evaluated successfully its performance, scalability and interoperability through a protocol built over IPv6.

Emerging Internet of Things (IoT)/Machine-to-Machine (M2M) systems require a transparent access to information and services through a seamless integration into the Future Internet. This integration exploits infrastructure and services found on the Internet by the IoT. On the one hand, the so-called Web of Things aims for direct Web connectivity by pushing its technology down to devices and smart things. On the other hand, the current and Future Internet offer stable, scalable, extensive, and tested protocols for node and service discovery, mobility, security, and auto-configuration, which are also required for the IoT. In order to integrate the IoT into the Internet, this work adapts, extends, and bridges using IPv6 the existing IoT building blocks (such as solutions from IEEE 802.15.4, BT-LE, RFID) while maintaining backwards compatibility with legacy networked embedded systems from building and industrial automation. Specifically, this work presents an extended Internet stack with a set of adaptation layers from non-IP towards the IPv6-based network layer in order to enable homogeneous access for applications and services.