ESP – Product Engineering – Platform and Software Products

Global supply of publicly routable IP (Internet Protocol) addresses is going down and according to an estimate most of the remaining IPv4 addresses are expected to be allocated by the end of 2011. IPv4 addresses are 32-bit and can only provide around 4 billion (2^32) addresses. Less than 10% of these addresses are left and with the growing number of users and devices (e.g. smart phones) connecting to internet, it will become increasingly difficult to get new IPv4 addresses. With most of the current day businesses depending on internet to conduct their daily transactions, it is imperative that for business continuity, they should migrate to IPv6. Some of the leading web content providers are already offering services on IPv6 (e.g. www.ipv6.google.com, www.ipv6.netflix.com). IPv6 addresses are 128-bit and can provide virtually unlimited number of addresses (2^128). IPv6 protocol is specified by Internet Engineering Task Force (IETF) and is documented in RFC 2460.

  

In the coming years many of the ISPs (Internet Service Providers) will start provisioning only IPv6 addresses and businesses which do not migrate to IPv6 may loose the customers who cannot access their services over the net. Key to successful IPv6 transition is interoperability with the existing installed base of IPv4 nodes, as most of the installed IPv4 infrastructure will continue to co-exist with IPv6 in the coming years. Top priority would be to migrate the external facing servers (servers on the internet) to IPv6. Internally (intranet) organizations could still operate IPv4 networks.

 

The first step towards migrating to IPv6 would be to upgrade the existing IPv4 infrastructure on hosts, routers, switches etc. to IPv6. When the IPv6 infrastructure is being deployed, existing IPv4 infrastructure can be used to carry IPv6 traffic. IPv6 transition mechanisms like 6to4, Teredo tunneling and ISATAP provide a way to transfer the IPv6 packets over IPv4 networks. The nodes which are upgraded to IPv6 should be dual-stack enabled, i.e. those nodes should support both IPv4 and IPv6 protocols. Such nodes are configured with both IPv4 and IPv6 addresses. Most of the current operating systems like Windows XP/Vista/7, Linux and MacOS support IPv6. But IPv6 is disabled by default and may have to be enabled to operate in dual-stack mode. Mobile operating systems like iPhone OS 4.0, Android (2.0 onwards) and Symbian OS (v7.0 onwards) also support IPv6.

 

Apart from migrating the infrastructure to IPv6, applications will have to be modified to handle both IPv4 and IPv6 communication. Assuming that the underlying infrastructure has been migrated to dual-stack mode, applications could be in one of the 4 states:

• IPv4 application in a dual-stack mode: In this case the node supports both IPv4 and IPv6 protocols, but the application can only manage IPv4 communications. Application has to be migrated to IPv6 to handle both IPv4 and IPv6.
• IPv4-only application and IPv6-only application in dual-stack mode: In this case there are 2 versions of the same application, one which supports only IPv4 and other which supports only IPv6. For e.g. www.google.com is IPv4-only version of application and www.ipv6.google.com is IPv6-only version of the application. The problem with this approach is that two versions of the same source code have to be maintained for same application. Also users of these applications might have difficulty in choosing the right version of the application.  
IPv6-only version of the application should be able to communicate with IPv4 nodes also, by using IPv4-mapped-IPv6 addresses (some dual-stack implementations might have disabled support for IPv4-mapped-IPv6 addresses, due to security concerns). IPv6 addresses of type "::FFFF.w.x.y.z" represent the IPv4 address "w.x.y.z". 
• Application supporting both IPv4 and IPv6 in dual-stack mode: This is the ideal case. In this case the application can handle both IPv4 and IPv6. Single source code is maintained for handling both IPv4 and IPv6 communication. While communicating with remote nodes, typical version-independent applications prefer IPv6 communication by default. If IPv6 communication fails, then IPv4 is tried.  
• Application supporting both IPv4 and IPv6 in an IPv4-only node: In this case application has been ported to handle both IPv4 and IPv6, but IPv6 protocol has been disabled in the node. Hence the application can only send and receive IPv4 packets. This scenario should also be handled in the application.

 Following are some of the considerations while porting the applications to IPv6:

• Handle differences in IPv4 and IPv6 address formats and sizes: IPv4 addresses are 32-bit and are represented as four decimal numbers separated by dots. E.g. "10.66.96.187". IPv6 addresses are 128-bit and are represented as 8 fields of up to 4 hexadecimal digits, separated by colon. E.g. 3ffe:ffff:101::230:6eff:fe04:d9ff. The string buffers used to hold the addresses should be changed to be big enough to accommodate IPv6 addresses. Also differences in the formats (dot vs colon, decimal vs hexdecimal) should be handled while storing the addresses.
• Use of protocol independent data structures and APIs: Use generic data structures which can store any address family. For e.g. protocol independent structure "sockaddr_storage" should be used instead of "stockaddr_in". 
Protocol-independent versions of the APIs should be used for communication. Following table lists some of the old and corresponding new APIs which should be used: 

Old APIs	New (Protocol Independent) APIs
gethostbyaddr() getservbyport()	getnameinfo()
gethostbyname() getservbyname()	getaddrinfo()  freeaddrinfo()

 

 

 

 

 

 

  

• Address resolution: getaddrinfo() returns a list of all the configured IP addresses for a host and the application should try out each of these returned IP addresses till the communication with the remote host succeeds. 
• With migration to IPv6, remote hosts could be configured with multiple IP addresses.  Hence programmers should not hardcode the IP addresses of remote hosts in the code. Because it may be possible to reach the destination using different IP addresses.
• DNS changes: "AAAA" DNS resource records are used for identifying the IPv6 addresses ("A" for IPv4). If you have migrated your application to IPv6, then you should advertise both "AAAA" (for IPv6 address) and "A" (for IPv4 address) records with DNS. This enables both IPv4 and IPv6 clients to connect to your host.

 

For detailed guidelines on migrating applications to IPv6, refer RFC 4038. Other resources which provide materials for helping you to migrate to IPv6 are:

• http://www.ipv6.com/
• http://www.ipv6forum.org/
• http://www.getipv6.info/index.php/Main_Page
 

Posted by Manjunath Ballur at 6:44 PM | Permalink | Comments (0) | TrackBacks (0)

Despite initial sceptism, open source software has become a rage over the years. Beyond individuals, even companies today are no longer shying away from openly embracing open source software to meet their software development needs. Interestingly, more than a decade after Richard Stallman had written about the possibility of 'open-sourcing' hardware based on the same philosophy of open source software, that concept seems to be finally taking on.

As per a news item here, a group of open source hardware enthusiasts have been working on the draft version of a definition of open source hardware which they plan to finalise at a summit, scheduled for September in New York.

Open Source was meant to be 'free' and everyone is quite used to simply downloading necessary open source software from the internet and using it as per the corresponding license conditions. However, open source hardware might not be completely 'free' in the same sense as in open source software.  In open source hardware, when you buy the hardware, you will be entitled to the complete collection of documents (schematics, drawings, PCB layout etc) that form the basis for the development of the device, thus enabling you to modify and innovate further. Open source hardware can also consist of units which allow reprogramming or modification to install customized firmware for specific needs.

Bug Labs is a modular, open source hardware company that aims at making it easier for people and companies to create their own electronics products. Bug Labs allows its open source hardware components to be integrated together and programmed to build custom devices performing specific functionality. A portable computing device with a processor, memory is the base of the hardware stack around which other components can be fitted to as per the expected requirement. For example, you could add sensors, camera, GPS modules etc. to enhance the base stack to transform as a test device for the required functionality. This provides a facility to quickly develop prototypes for target products.

For example , a company could use these components to build a test device to be used by car insurance companies to monitor a driver's driving style to judge whether an incentive should be pronounced during the next renewal. 

Today, the hardware market is dominated by a few major companies which produce mass-market products at large scales. With open source hardware, the expectation is that in the next few years, there will be a number of niche products available from many other companies, who can innovate on shared hardware design.

Posted by Suraj Nair at 10:21 AM | Permalink | Comments (0) | TrackBacks (0)

The iCMG Architecture World 2010 Summit was held on the 27th and 28th of July, 2010 at the IISc Campus in Bangalore, India. That was a unique opportunity to hear the legendary John Zachman speak at the summit on his thoughts about enterprise architecture.  The topic for Zachman's keynote address on 27th July, 2010 was Managing Complexity and Change - in which he stressed on how the description of architecture was important towards creating systems which were large, complex and flexible to change in future years. The famous Zachman Framework serves as a reference schema towards architecting complex software systems for any domain - though it was primarily conceived keeping Enterprise Software Architecture in mind.

A software system which is complex, expected to change and be customizable, needs an architecture. After all, the hard truth is that any software system that is built today, is going to be legacy sometime in the future. But, it is the consideration and detail in the architecture of the system that is going to define it's ability to easily transform and adapt to newer technologies in future in quicker time.

Zachman feels that there is a gross misunderstanding as regards architecture in the IT industry. The urge to implement and witness things working, has often resulted in architecture being ignored. However, architecture is important because one cannot create or build what one cannot describe. According to Zachman, the Roman Coliseum is not architecture, but an end-result of architecture (an implementation of the architecture)."In the end result, the implementation, you can see an instantiation of the Architect's Architecture".  The end product of an architecture is amenable to change only if there is a description of it's architecture which has been kept updated with it's implementation.

A common theme noticed across working on various projects for customers across geographies, is the relative absence of any documentation concerning the architecture of the product. A majority of projects in the software services industry are maintenance or enhancement requests to existing products. In the offshoring model, all that is often handed over to project teams offshore is -  a working instance of the product, the source code and user manuals. With stringent deadlines and high expectations of quick turnaround, changes in the product have to be made by wading through a maze of complex code - some of which is needed, some of which is redundant. Besides, one never knows how changes made in the absence of a 'big picture', could affect other quality attributes. As Zachman mentioned, "without Architecture, you are not going to be able to create an object of any complexity and you won't be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost)" - a statement proved true repeatedly in a number of discomforting projects.

According to Zachman, architecture "constitutes the set of descriptive representations relevant for describing an object such that you can create it and change it with minimum time, disruption and cost". Zachman has been inspired from learnings in complex industrial projects, to draw up the famous Zachman's framework. The framework provides a schema to help describe information in detail relevant to all stakeholders involved in the creation of the product.

The universal set of descriptions ("Abstractions") include an understanding of the product characteristics with respect to the following - What, How, Where, Who, When and Why. The complexity of having to understand the complete system can be reduced by the ability to abstract out one characteristic at a time, and developing a formal, explicit description of that characteristic (keeping all the other characteristics constant). (The OSI Layer is a good illustration where each layer can be described independently and changed without affecting any of the other layers) Now, each of the universal set of descriptions mentioned above, needs to be created uniquely for different audiences (visionaries, executive leaders, architects, designers, developers, users) which Zachman called "Perspectives". Hence, what constitutes Enterprise Architecture (or for that matter any software architecture) is the total set of intersections of the Abstractions and the Perspectives. A primitive model is considered to be each intersection of an abstraction and a perspective and needs to be described completely and independently in the architecture description. 

Any implementation must be built  in a disciplined manner using a composite of primitives (identified in the architecture description). Building systems from the whole (without consideration towards componentization using primitives) typically results in systems that are big, monolithic and inflexible to changes without major trade-offs. It is indeed true that because of a lack of architectural thought, a number of legacy systems have maze-like, tightly coupled and complicated implementations.

According to Zachman, almost all industrial products (cars, aeroplanes, machinery etc) are architected while software systems just seem to happen somehow. One of the reasons is probably because, most legacy software products developed were originally proofs of concept (POC) with layers and layers of software added over the years - some of of which may inturn, negatively impact certain quality attributes of the system. The lack of interest in leaders (CIOs etc) to initially invest in detailed architecture descriptions of the systems that they own - cause situations where, overtime, the costs of maintaining systems outweigh the revenue generated from them. Zachman noted that "When the energy needed to support the system is more than the energy in the system, the system dies". This is something that should be prevented by describing the architecture and keeping it updated to match changes in the system. Openness to bearing this short term cost will help reduce maintenance costs in the long term.

In legacy software systems (other than banking systems), the cost of software failure was probably not as serious as the cost of mechanical failure (like in aeroplanes or cars for example, where failure could cause impairment or loss of human life). Today, almost all industrial products are controlled by software. To develop a secure and efficient system, there is a need to have detailed software architecture descriptions in place to satisfy all stakeholders involved. With immense competition across industries, failure is not an option today because of huge financial obligations and hence, there is the willingness to do whatever it takes using prescribed methodologies.

It is more relevant than never today, that there should be a lot of focus on developing the architecture of software systems. With cloud computing and SOA, the building and running of systems is moving out into the cloud. Notice, as more and more implementations move to the cloud as services, it is the architecture that remains. It is probably these services that Zachman had identified as primitive models that are reusable (developed and maintained in inventories) and flexible to change.

The Zachman Framework is like a schema (Zachman likens the idea to be similar to the periodic table in chemistry) which can be used as per the understanding of the practioner. Though this seems to have been formally introduced to bring in a structure towards engineering 'lean and mean' enterprise architecture solutions, it is generic enough to be referenced equally efficiently in architecting complex software systems in other software domains too.

Posted by Suraj Nair at 10:11 AM | Permalink | Comments (0) | TrackBacks (0)