Readers might be wondering why is he writing about components now, well I am interested in the meta models. Such models can be useful when designing a naming and addressing system, the meta-data associated to each component will help to find a specific component.
This article suggests a component model in order to deal with mobile adaptation.
Applications are more often monolithic (one code block), which means hard to update and maintain when an event or change of context occurs.
Their model allows logical mobility defined as the migration of a partial or complete application or process from one host to another.
Component based development divide the system into interacting components with well defined interfaces. Traditional approaches do not support code migration and execution at runtime. They apply this mobility to components.
The SATIN component model allows to send and receive components dynamically at runtime. Instead of relying on the invocation of remote services, SATIN components are remotely cloned and instantiated locally.
This solution provides autonomy when networks are disconnected. Applications can introspect which components are available locally for a task, and dynamically change the system configuration by adding or removing components.
Component metadata is essential in order to best describe component's properties which are a set of its attributes (ID, version, dependencies with other components, hardware etc). The SATIN component system use attributes similar to the Debian packaging system. This allows applications running on heterogeneous hardware/framework to decide whether on not to deploy a component.
The central component of a SATIN system is the container component which acts as a registry, holds a reference to each component installed on the system. A registrar component is used for loading, removing components, managing dependencies etc.
They consider four aspects of Logical Mobility: components, classes, Instances and data types which is a bit stream. A Logical Mobility Entity (LME) is an abstract generalization of a class, instance or data types. Logical Mobility Unit (LMU) is an encapsulation of LMEs. LMU provides operations that permit inspection of the content, a handler class to deploy and manipulate it contents. Properties (set of attributes) of LMU are used to express dependencies, target environment etc. These LMUs and its contents are serialized/deserialized for transfer and deployment between physical hosts. LMU is always deployed in a reflective component which is able to adapt on runtime by receiving LMU from other hosts.
When a change in the context/environment appears (user/component triggered), the system asks the deployer for a component satisfying a set of attributes. The local deployer contacts a remote deployer and asks for a component. The container packs an LMU and sends it back to the host.
Component discovery and advertising is general. It can uses Jini, UPnP, etc.
In their implementation they used IP Multicast advertising group and a simple centralized publish/subscribe protocol.
So far my knowledge on mobile adaptively component systems is limited, comments on this topic will be added further.
However classic issues deserves to be explored such as:
How much time is needed to transfer a component in a mobile system?
Can we and how to guarantee such time in a dynamic and mobile system. Mobile nodes appears and disappears, the transfer of LMU will be interrupted due to node departure (this is MANET similar issues).
How to advertise for services and new nodes with a minimum overhead, message exchange between nodes?
How to manage resources allocated for every component in a limited resource environment/platforms?
Link to the article
Showing posts with label Mobile. Show all posts
Showing posts with label Mobile. Show all posts
Friday, April 17, 2009
Wednesday, April 15, 2009
Review: An IPv6-Based Identification Scheme
This article presents an IPv6 identification scheme to identify physical objects with
RFID tags. The identification is needed in different fields such as locating objects,
health care monitoring, military operations etc.
Their scheme is based on IPv6 unicast address:
010.Registry_ID[5].Provider_ID[16].0.8].Subscriber_ID[24].0[8].Subnet_ID[16].Interface[48].
(note that the "‘."’ is used as a concatenation operator and X[n] where n indicates the
number of bits used to code the field X).
Register_ID is allocated to organizations responsible for assigning network addresses.
Provider_ID is allocated to Internet service provider. 0[8] future extension.
To identify objects they propose to use the unassigned IPv6 namespace that has the
binary prefix "‘001"’ with two formats:
General ID:
0010.Agency_ID[5].Domain_name[48].0[7].Object_Class[16].Serial_Number[48].
Agency_ID is analogous to registry ID, the agency is responsible for allocating the
identifier. Domain name for company or organization. 0[7] future use. Object class to
identify object types. Serial number ID of an object type.
Pseudo Random ID:
0011.Agency_ID[5].Random_Number[119]
This scheme provides more privacy, it does not reveals the ID of the company and other information. They clearly distinguish between and IPv6 address to locate an object and IPv6 ID
to identify and object. The prefix translation is what they propose to translate between an IPv6 ID (prefix 001) and an IPv6 address prefix (010) which means that the IPv6 ID may be used to
obtain an IPv6 address. Since physical objects are mobile, they propose the following
two methods to track objects:
Name System: (Same ID, multiple addresses)
They propose to use canonical name written in a reverse order in which they are constructed.
They reverse it so it can be used as a URL DNS like. By doing this, they can integrate their scheme in existing systems like DNS.
Serial_number.object-class.company.organization.obj.
DNS query will start at "obj"’ level than it will go from right to left.
When objects moves, we need only to update DNS records which maps a name into an address. When objects moves to a different domain, the new owner of objects should update the DNS record. Since DNS is not suited for updates, a localization service provided by the proxy should handle the update.
Address forward scheme:
They use the home agent approach (see Mobile IP paragraph).
They assume that routers are configured to distinguish identifiers from addresses.
We can search for an object by its ID because routers will translate the IPv6 ID into an IPv6 address by modifying the 3 bits prefix. The ID will remain the same and so the address. Objects of the same owner are assigned to a dedicated proxy. The proxy’s address will have same domain prefix. When a router receives an object ID, it translates it and forwards it to the correspondent proxy according to the domain name. When an object moves, its ID and so its address remains the same. The object updates his home proxy with the new location where it moved recently. It also informs the new proxy about its ID. Routers will forward the packets to the proxy according to the domain name. This proxy will have the same role as a home agent in an IP mobile. The proxy will forward requests to the new proxy where the object has moved.
The approach is very comprehensive specially the mapping between ID and address with the 3 bits prefix and the facility of integration in today’s system without major modifications and without a need to query directories like DNS.
However since objects are usually manufactured in thousands and millions (Gillette raisers) when a container moves from an owner to another. The traffic update will generate a massive overhead between owners.
We are faced to the same problems when dealing with mobile IP. We lost object’s trace during transition from one proxy to another.
Not all companies have the same productions capacities. Small companies manufacturers small number of items which means that small companies will not use the IDs assigned to it, while big companies will exhaust ID in a short time (comparing to small companies). Should small companies share the domain ? This means that proxies of small companies cannot use a routing mask when dealing with IDs and IP addresses.
Two companies can share same domain, these 2 companies will have same prefix and since it cannot apply a mask. A proxy will list all the IDs of owned objects. Proxies will be overloaded then and I/O time query will be slow due to the huge amount of data.
Mobile IP approach what if home proxy or company owner of the domain is closed for economic or other reasons. How to maintain the address forwarding?
Link to the article
RFID tags. The identification is needed in different fields such as locating objects,
health care monitoring, military operations etc.
Their scheme is based on IPv6 unicast address:
010.Registry_ID[5].Provider_ID[16].0.8].Subscriber_ID[24].0[8].Subnet_ID[16].Interface[48].
(note that the "‘."’ is used as a concatenation operator and X[n] where n indicates the
number of bits used to code the field X).
Register_ID is allocated to organizations responsible for assigning network addresses.
Provider_ID is allocated to Internet service provider. 0[8] future extension.
To identify objects they propose to use the unassigned IPv6 namespace that has the
binary prefix "‘001"’ with two formats:
General ID:
0010.Agency_ID[5].Domain_name[48].0[7].Object_Class[16].Serial_Number[48].
Agency_ID is analogous to registry ID, the agency is responsible for allocating the
identifier. Domain name for company or organization. 0[7] future use. Object class to
identify object types. Serial number ID of an object type.
Pseudo Random ID:
0011.Agency_ID[5].Random_Number[119]
This scheme provides more privacy, it does not reveals the ID of the company and other information. They clearly distinguish between and IPv6 address to locate an object and IPv6 ID
to identify and object. The prefix translation is what they propose to translate between an IPv6 ID (prefix 001) and an IPv6 address prefix (010) which means that the IPv6 ID may be used to
obtain an IPv6 address. Since physical objects are mobile, they propose the following
two methods to track objects:
Name System: (Same ID, multiple addresses)
They propose to use canonical name written in a reverse order in which they are constructed.
They reverse it so it can be used as a URL DNS like. By doing this, they can integrate their scheme in existing systems like DNS.
Serial_number.object-class.company.organization.obj.
DNS query will start at "obj"’ level than it will go from right to left.
When objects moves, we need only to update DNS records which maps a name into an address. When objects moves to a different domain, the new owner of objects should update the DNS record. Since DNS is not suited for updates, a localization service provided by the proxy should handle the update.
Address forward scheme:
They use the home agent approach (see Mobile IP paragraph).
They assume that routers are configured to distinguish identifiers from addresses.
We can search for an object by its ID because routers will translate the IPv6 ID into an IPv6 address by modifying the 3 bits prefix. The ID will remain the same and so the address. Objects of the same owner are assigned to a dedicated proxy. The proxy’s address will have same domain prefix. When a router receives an object ID, it translates it and forwards it to the correspondent proxy according to the domain name. When an object moves, its ID and so its address remains the same. The object updates his home proxy with the new location where it moved recently. It also informs the new proxy about its ID. Routers will forward the packets to the proxy according to the domain name. This proxy will have the same role as a home agent in an IP mobile. The proxy will forward requests to the new proxy where the object has moved.
The approach is very comprehensive specially the mapping between ID and address with the 3 bits prefix and the facility of integration in today’s system without major modifications and without a need to query directories like DNS.
However since objects are usually manufactured in thousands and millions (Gillette raisers) when a container moves from an owner to another. The traffic update will generate a massive overhead between owners.
We are faced to the same problems when dealing with mobile IP. We lost object’s trace during transition from one proxy to another.
Not all companies have the same productions capacities. Small companies manufacturers small number of items which means that small companies will not use the IDs assigned to it, while big companies will exhaust ID in a short time (comparing to small companies). Should small companies share the domain ? This means that proxies of small companies cannot use a routing mask when dealing with IDs and IP addresses.
Two companies can share same domain, these 2 companies will have same prefix and since it cannot apply a mask. A proxy will list all the IDs of owned objects. Proxies will be overloaded then and I/O time query will be slow due to the huge amount of data.
Mobile IP approach what if home proxy or company owner of the domain is closed for economic or other reasons. How to maintain the address forwarding?
Link to the article
Thursday, April 2, 2009
Review: Infrastructure for Pervasive Computing: Challenges
This paper enumerates the challenges faced today to design an infrastructure for pervasive computing.
Their conceptual model is based on four components: devices, users, software components and users interface.
In the following paragraph a summary of the challenges related to the naming and addressing issues of devices and software components.
Devices:
Software Components:
Service platforms allow the rapid creation and deployment of services, as well dynamic service discovery.
JINI based on Java and RMI. Services can be added and removed dynamically.
JINI proposes among others a look up service used by clients to locate services.
MOCA aims to satisfy requirements of mobile environments. It provides dynamic service discovery, limited forms of adaptation to changes due to mobility, support for device heterogeneity.
JINI and MOCA provides solution to small scale environments.
The NINJA service framework addresses large scale services. Service discovery is supported by hierarchical arrangement of service discovery services.
Link to the article
Their conceptual model is based on four components: devices, users, software components and users interface.
In the following paragraph a summary of the challenges related to the naming and addressing issues of devices and software components.
Devices:
- Heterogeneity is expected to increase in the future, devices will include sensors and everyday objects such as watches, shoes etc. Those devices will require to interact despite differences in resources (hardware and software capabilities). An infrastructure is needed to manage the integration of those devices in the system.
- Mobility is faced to problems related to maintaining connectivity while devices move between networks (See IP mobile section). Disconnected networks can be handled by replicated data.
Software Components:
- Mobility and distribution: since users are mobile they can access several devices simultaneously. Mechanisms should enable the mobility and distribution of software. The support for distribution need to be extended to address mobility, synchronization and coordination between software components. Platforms like CORBA offers only transparency of distributed communication.
- Context awareness: applications will rely more on context knowledge than information based on user's input.
- Adaptation: The infrastructure should be able to facilitate adaptation such as reconfiguring software components, binding, adding, removing components.
- Interoperability: applications will be required to respond to new tasks and situations. Applications would be dynamically assembled from existing and available components. Those components should acquire knowledge of each other's interfaces and behavior to interact with other unknown heterogeneous components.
- Component discovery has been addressed in many research areas. Resource discovery is supported by a type management repository which maintains descriptions of service interface types. Another solution is addressed by network directory protocols such as LDAP. As resource discovery tried to solve the problem differently, the main challenge would be to integrate the different approaches into a scalable resource discovery by mapping requests between resource discovery domains.
- Scalability: the increasing number of devices and softwares requires a powerful scalable software platform on which distributed components will be built on.
Service platforms allow the rapid creation and deployment of services, as well dynamic service discovery.
JINI based on Java and RMI. Services can be added and removed dynamically.
JINI proposes among others a look up service used by clients to locate services.
MOCA aims to satisfy requirements of mobile environments. It provides dynamic service discovery, limited forms of adaptation to changes due to mobility, support for device heterogeneity.
JINI and MOCA provides solution to small scale environments.
The NINJA service framework addresses large scale services. Service discovery is supported by hierarchical arrangement of service discovery services.
Link to the article
Wednesday, March 25, 2009
Mobile IP
Nowadays a device might belong to a home network which means that it maintains a permanent address known as its home address and a temporary internet address assigned to it when joining another network.
This permanent unique address is used to communicate with such hosts.
When a host with a permanent address is attached to another network, the data received at the home network should be forwarded to the visited network.
There are several methods to keep track of migrating hosts such as:
[Internet draft NETLMM problem]
"The on-line Migration":
With the huge development of Wireless networks, a host can migrate from one network to another in a short time while still connected to other hosts. This is called "on-line" migration.
When migrating several applications need to stop and reestablish the communication with distant hosts using the new assigned address. This causes service or application interruption.
This interruption of service is encountered because in the OSI layers, the IP address is used for both host identification and routing (data delivery).
In the transport layer (TCP, UDP) the IP address is used as an identifier along with other parameters in order to uniquely address a host or a communication session.
As for the network layer, the IP address is used as a way to locate a host and deliver data.
The following paragraphs describes some solutions for the host migration.
This permanent unique address is used to communicate with such hosts.
When a host with a permanent address is attached to another network, the data received at the home network should be forwarded to the visited network.
There are several methods to keep track of migrating hosts such as:
- A server that keep the binding between the permanent address and temporary address. However this method has several limitations, mainly it is impossible to provide an on-line migration, transport protocols need to know about the new address in order to reestablish communication. It increase network traffic to update the mapping and caches if existed.
- Broadcast solution: when a host wants to send data to a migrating host, it broadcasts a query packet in a network and the migrating host reply with its temporary address. This mechanism can only be applied to small networks.
[Internet draft NETLMM problem]
- Update latency: the update of the new temporary address is always necessary when a host migrate, though this update might take time if the migrating host did not notify about his mobility, network traffic, crashed routers,etc. During this time, the home network will forward received packets to an old temporary IP address until the new mapping occurs.
- Signaling overhead: when moving to another network, the migrating host notifies its home network and acquire a new address. The configuration and notification can be expensive depending on the method and the node resources (bandwidth, battery dependent etc).
- Location privacy: the change in temporary address exposes the migrating host topologically.
"The on-line Migration":
With the huge development of Wireless networks, a host can migrate from one network to another in a short time while still connected to other hosts. This is called "on-line" migration.
When migrating several applications need to stop and reestablish the communication with distant hosts using the new assigned address. This causes service or application interruption.
This interruption of service is encountered because in the OSI layers, the IP address is used for both host identification and routing (data delivery).
In the transport layer (TCP, UDP) the IP address is used as an identifier along with other parameters in order to uniquely address a host or a communication session.
As for the network layer, the IP address is used as a way to locate a host and deliver data.
The following paragraphs describes some solutions for the host migration.
Review: A network architecture providing host migration transparency
The Sony team proposes a network architecture in order to provide host mobility. Even though the article was written back in the 1991, we are still facing the same problem when dealing with host migration transparency.
They propose to separate the network layer to two sub-layers:
When a host migrates, only its PN-address changes. Thereby the path to deliver data and not its identity (VN-address).
If host A wants to communicate with another distant host B, A uses B-VN-address. Host A-PN layer will translate Host B-VN-address to B-PN-address.
The Sony team uses the propagating cache method in order to reduce the overhead of address conversion. In this method each host and gateway hold a cache for address conversion. it is actually an address mapping table between the host's PN-address and the VN-address. Every entry in the table hold a VN/PN address, a source address timestamp used to determine whether the entry is obsolete and an Idle time (a Time To Live).
When a host changes a physical network it sends an update message "control packet" to its native network. This packet includes its VN-address and the new PN-address. When the packet travels to its native network, gateways on the path updates their entry with the new PN-address.
When a host A sends a request to another distant host B without any knowledge of host B PN-address, A just sets the host B PN-address with host B VN-address. The packets will be redirected to its native network and then will be redirected to its actual PN because on the path to the native network an address mapping of VN-PN will be hold by gateways.
This approach is interesting and seems to reduce overhead traffic comparing to Central server and broadcast methods.
However since packets sent from host A to host B don't always take the same path. Some of the routers and gateways will be updated and others will still hold an old mapping information. This would definitely lead to obsolete cache entries and loss of packets due to routing error.
link to the article
They propose to separate the network layer to two sub-layers:
- The virtual network (VN) is a logical network that exists on the physical network. Each host in always connected to a VN just as it is connected to a PN. A host never migrates from its VN even if it migrates from its PN. A host has a VN address (permanent) and PN address (temporary).
- The physical network (PN): is the IP layer where the PN address indicates the location of the host in the PN which is used for routing.
When a host migrates, only its PN-address changes. Thereby the path to deliver data and not its identity (VN-address).
If host A wants to communicate with another distant host B, A uses B-VN-address. Host A-PN layer will translate Host B-VN-address to B-PN-address.
The Sony team uses the propagating cache method in order to reduce the overhead of address conversion. In this method each host and gateway hold a cache for address conversion. it is actually an address mapping table between the host's PN-address and the VN-address. Every entry in the table hold a VN/PN address, a source address timestamp used to determine whether the entry is obsolete and an Idle time (a Time To Live).
When a host changes a physical network it sends an update message "control packet" to its native network. This packet includes its VN-address and the new PN-address. When the packet travels to its native network, gateways on the path updates their entry with the new PN-address.
When a host A sends a request to another distant host B without any knowledge of host B PN-address, A just sets the host B PN-address with host B VN-address. The packets will be redirected to its native network and then will be redirected to its actual PN because on the path to the native network an address mapping of VN-PN will be hold by gateways.
This approach is interesting and seems to reduce overhead traffic comparing to Central server and broadcast methods.
However since packets sent from host A to host B don't always take the same path. Some of the routers and gateways will be updated and others will still hold an old mapping information. This would definitely lead to obsolete cache entries and loss of packets due to routing error.
link to the article
Subscribe to:
Posts (Atom)
Posts
