Advocacy for IPv6 Deployment—Example

We include below some excerpt from the European Economic and Social Committee and the Committee of the Regions [39] to emphasize the issues related to IPv6. Clearly, issues about IPv6 impact not only Europe but the entire world.

The European Economic and Social Committee and the Committee of the Regions has issued an “Action Plan for the deployment of IPv6 in Europe.” It is the objective of this Action Plan to support the widespread introduction of the next version of the IP (IPv6) for the following reasons:

  • Timely implementation of IPv6 is required as the pool of IP addresses provided by the current protocol version 4 is being depleted.
  • IPv6 with its huge address space provides a platform for innovation in IP based services and applications.

Preparing for the Growth in Internet Usage and for Future Innovation. One common element of the Internet architecture is the IP that in
essence gives any device or good connecting to the Internet a number, an address, so that it can communicate with other devices and/or goods. This address should generally be unique, to ensure global connectivity. The current version, IPv4, already provides for more than 4 billion such addresses. Even this, however, will not be enough to keep pace with the continuing growth of the Internet. Being aware of this long-term problem the Internet community developed an upgraded protocol, IPv6, which has been gradually deployed since the late 1990s.

In a previous Communication on IPv6, the European Commission made the case for the early adoption of this protocol in Europe. This Communication has been successful in establishing IPv6 Task Forces, enabling IPv6 on research networks, supporting standards, and setting-up training actions. Following the Communication, more than 30 European R&D projects related to IPv6 were financed. Europe has now a large pool of experts with experience in IPv6 deployment. Yet, despite the progress made, adoption of the new protocol has remained slow while the issue of future IP address scarcity is becoming more urgent.

Increasing Scarcity of IPv4 Addresses: A Difficulty for Users, an Obstacle to Innovation. Initially all Internet addresses are effectively held
by the IANA and then large blocks of addresses are allocated to the five RIRs that in turn allocate them in smaller blocks to those who need them, including ISPs. The allocation, from IANA to RIR to ISP, is carried out on the basis of demonstrated need: there is no preallocation.

The address space of IPv4 has been used up to a considerable extent. At the end of January 2008 about 16% was left in the IANA pool, that is, approximately 700 million IPv4 addresses. There are widely quoted and regularly updated estimates that forecast the exhaustion of the unallocated IANA pool somewhere between 2010 and 2011. New end users will still be able to get addresses from their ISP for some time after these dates, but with increasing difficulty.

Even when IPv4 addresses can no longer be allocated by IANA or the RIRs, the Internet will not stop working: the addresses already assigned can and most probably will be used for a significant time to come. Yet the growth and also the capacity for innovation in IP-based networks would be hindered without an appropriate solution. How to deal with this transition is currently the subject of discussion in the Internet community in general, and within and amongst the RIR communities in particular.

All RIRs have recently issued public statements and have urged the adoption of IPv6.

IPv4 is only a Short-Term Solution Leading to More Complexity. Concerns about the future scarcity of IP addresses are not a recent phenomenon. In the early days of the Internet, before the establishment of the RIRs and before the take-off of the World Wide Web, addresses were assigned rather generously. There was a danger of running out of addresses very quickly. Therefore, changes in allocation policy and in technology were introduced that allowed allocation to be more aligned to actual need.

One key IPv4 technology has been NAT. NATs connect a private (home or corporate) network that uses private addresses to the public Internet where public IP addresses are required. Private addresses come from a particular part of the address space reserved for that purpose. The NAT device acts as a form of gateway between the private network and the public Internet by translating the private addresses into public addresses. This method therefore reduces consumption of IPv4 addresses. However, the usage of NATs has two main drawbacks, namely:

  • It hinders direct device-to-device communication: intermediate systems are required to allow devices or goods with private addresses to communicate across the public Internet.
  • It adds a layer of complexity in that there are effectively two distinct classes of computers: those with a public address and those with a private address. This often increases costs for the design and maintenance of networks, as well as for the development of applications.

Some other measures could extend the availability of IPv4 addresses. A market to trade IPv4 addresses might emerge that would offer incentives to organizations to sell addresses they are not using. However IP addresses are not strictly property. They need to be globally acceptable to be globally routable, which a seller cannot always guarantee. In addition, they could become a highly priced resource. So far, RIRs have been skeptical about the emergence of such a secondary market. Another option consists of trying to actively reclaim those already-allocated address blocks that are underutilized. However, there is no apparent mechanism for enforcing the return of such addresses. The possible cost of it has to be balanced against the additional lifetime this would bring to the IANA pool. Though such measures may provide some interim respite, sooner or later the demand for IP addresses will be too large to be satisfied by the global IPv4 space. Efforts to stay with IPv4 too long risk increasing unnecessary complexity and fragmentation of the global Internet. A timely introduction of IPv6 is thus the better strategy.

IPv6: The Best Way Forward. IPv6 provides a straightforward and long-term solution to the address space problem. The number of addresses defined by the IPv6 protocol is huge. IPv6 allows every citizen, every network operator (including those moving to all IP “Next Generation Networks”), and every organization in the world to have as many IP addresses as they need to connect every conceivable device or good directly to the global Internet. IPv6 was also designed to facilitate features that were felt to be missing in IPv4. Those features included quality of service, autoconfiguration, security, and mobility. In the meantime, however, most of those features have been engineered in and around the original IPv4 protocol. It is the large address space that makes IPv6 attractive for future applications as this will simplify their design when compared to IPv4. The benefits of IPv6 are, therefore, most obviously apparent whenever a large number of devices or goods need to be easily networked, and made potentially visible and directly reachable over the Internet. A study funded by the Commission demonstrated this potential for a number of market sectors such as home networks, building management, mobile communication, defense and security sector, and car industry.

Prompt and efficient adoption of IPv6 offers Europe potential for innovation and leadership in advancing the Internet. Other regions, in particular the Asian region, have already taken a strong interest in IPv6. For instance, the Japanese consumer electronics industry increasingly develops IP enabled products and exclusively for IPv6. The European industry should therefore be ready to meet future demand for IPv6-based services, applications, and devices and so secure a competitive advantage in world markets.

To conclude, the key advantage of IPv6 over IPv4 is the huge, more easily managed address space. This solves the future problem of address availability now and for a long time to come. It provides a basis for innovation—developing and deploying services and applications that may be too complicated or too costly in an IPv4 environment. It also empowers users, allowing them to have their own
network connected to the Internet.

What Needs to be Done? IPv6 is not directly interoperable with IPv4. IPv6 and IPv4 devices can only communicate with each other using
application-specific gateways. They do not provide a general future-proof solution for transparent interoperability. However, IPv6 can be enabled in parallel with IPv4 on the same device and on the same physical network. There will be a transition phase (expected to last for 10, 20, or even more years) when IPv4 and IPv6 will coexist on the same machines (technically often referred to as “dual stack”) and be transmitted over the same network links. In addition, other standards and technologies (technically referred to as “tunneling”) allow IPv6 packets to be transmitted using IPv4 addressing and routing mechanisms and ultimately vice versa. This provides the technical basis for the step-by-step introduction of IPv6. Because of the universal character of the IP, deployment of IPv6 requires the attention of many actors worldwide. The relevant stakeholders in this process are as follows:

  • Internet organizations (such as ICANN, RIRs, and IETF) that need to manage common IPv6 resources and services (allocate IPv6 addresses, operate DNS servers, etc.), and continue to develop needed standards and specifications. As of May 2008, the regional distribution of allocated IPv6 addresses is concentrated on Europe (R´eseaux Internet Protocol Europ´eens or RIPE: 49%), with Asia and North America growing fast (Asia–Pacific Network Information Centre, APNIC: 24%; ARIN: 20%). Less than half of those
    addresses are currently being announced on the public Internet (i.e., visible in the default-free routing table). In the DNS the root and top-level name servers are increasingly becoming IPv6 enabled. For instance, the gradual introduction of IPv6 connectivity to. eu name servers started in 2008.
  • ISPs that need over time to offer IPv6 connectivity and IPv6 based services to customers: There is evidence that less than half of the ISPs offer some kind of IPv6 interconnectivity. Only a few ISPs have a standard offer for IPv6 customer access service (mainly for business users) and provide IPv6 addresses. The percentage of “Autonomous Systems” (typically ISPs and large end users) that operate IPv6 is estimated at 2.5%. Accordingly, IPv6 traffic seems to be relatively low. Typically the IPv6/v4 ratio is less than
    0.1% at Internet Exchange Points (of which about one in five supports IPv6). However, this omits direct ISP to ISP traffic and IPv6 that is “tunneled” and so appears at first glance to be still IPv4. Recent measurements suggest that this kind of traffic IPv6 that is “tunneled” is growing.
  • Infrastructure vendors (such as network equipment, operating systems, network application software) that need to integrate IPv6 capability into their products: Many equipment and software vendors have upgraded their products to include IPv6. However, there are still issues with certain functions and performance, and vendor support equivalent to IPv4. The installed equipment base of consumers, such as small routers and home modems to access the Internet, still by and large do not yet support IPv6.
  • Content and service providers (such as websites, instant messaging, email, file sharing, voice over IP) that need to be reachable by enabling IPv6 on their servers: Worldwide there are only very few IPv6 websites. Almost none of the global top sites offer an IPv6 version. The de facto nonexistence of IPv6 reachable content and services on the Internet is a major obstacle in the take-up of the new protocol.
  • Business and consumer application vendors (such as business software, smart cards, peer-to-peer software, transport systems, sensor networks) that need to ensure that their solutions are IPv6 compatible and increasingly need to develop products and offer services that take advantage of IPv6 features. Today, there are few, if any, current applications that are exclusively built on IPv6. One expectation has been that proliferation of IP as the dominant network protocol would drive IPv6 into new areas such as logistics and traffic management, mobile communication, and environment monitoring that has not taken place to any significant degree yet.
  • End users (consumers, companies, academia, and public administrations) that need to purchase IPv6 capable products and services and to enable IPv6 on their own networks or home Internet access: Many home end users, without being aware of it, operate IPv6 capable equipment and yet, as a result of missing applications, without necessarily making use of it. Companies and public administrations are cautious to make changes to a functioning network without a clear need. Therefore not much user deployment in private networks is visible. Among the early adopters have been universities and research institutions. All EU national research and education networks also operate on IPv6. The European G´eant network is IPv6 enabled, whereby approximately 1% of its traffic is native IPv6.

How much and which efforts are required to adopt IPv6 differ amongst actors and depend on each individual case. Therefore, it is practically impossible to reliably estimate the aggregated costs to introduce IPv6 globally. Experience and learning from projects have shown that costs can be kept under control when deployment is gradual and planned ahead. It is recommended that IPv6 be introduced step-by-step, possibly in connection with hardware and software upgrades, organizational changes, and training measures (at first glance unrelated to IPv6). This requires a general awareness within the organization in order to not miss those synergies. The costs will be significantly higher when IPv6 is introduced as a separate project and under time constraints.

Introduction of IPv6 will take place alongside the existing IPv4 networks. Standards and technology allow for a steady incremental adoption of IPv6 by the various stakeholders that will help to keep costs under control. Users can use IPv6 applications and generate IPv6 traffic without waiting for their ISP to offer IPv6 connectivity. ISPs can increase their IPv6 capability and offer this in line with perceived demand.

IPv6 Overview

While the basic function of the IP is to move information across networks, IPv6 has more capabilities built into its foundation than IPv4. A key capability is the significant increase in address space. For example, all devices could have a public IP address so that they can be uniquely tracked.7 Today, inventory management of dispersed assets in a very large dispersed organization such as the United States Department of Defense (DoD) Department cannot be achieved with IP mechanisms; during the inventory cycle someone has to manually verify the location
of each desktop computer. With IPv6 one can use the network to verify that such equipment is there; even non-IT equipment in the field can also be tracked, by having an IP address permanently assigned to it. IPv6 also has extensive automatic configuration (autoconfiguration) mechanisms and reduces the IT burden, making configuration essentially plug-and-play (autoconfiguration implies that a Dynamic Host Configuration Protocol or DHCP server is not needed and/or does not have to be configured. Owing to the fact that IPv4 manual configuration is already a challenge in itself, one can understand that manually manipulating IPv6 addresses that are four times longer can be much more problematic. Corporations and government agencies will be able to achieve a number of improvements with IPv6 such as, but not limited to the following

  • expanded addressing capabilities;
  • serverless autoconfiguration (what some call “plug-n-play”) and reconfiguration;
  • streamlined header format and flow identification;
  • end-to-end security, with built-in, strong IP-layer encryption and authentication (embedded security support with mandatory IPsec implementation);
  • in IPv6, creating a VPN is easier and more standard than in IPv4, because of the Authentication Header (AH) and Encapsulating Security Protocol (ESP) Extension Headers and the performance penalty is lower for the VPN implemented in IPv6 compared to those built in IPv4 [25];
  • enhanced support for multicast and QoS (more refined support for flow control and QoS for the near real-time delivery of data);
  • more efficient and robust mobility mechanisms (enhanced support for Mobile IP and mobile computing devices);
  • extensibility: improved support for feature options/extensions;
  • IPv6 makes it easy for nodes to have multiple IPv6 addresses on the same network interface. This can create the opportunity for users to establish overlay or Communities of Interest (COI) networks on top of other physical IPv6 networks. Department, groups, or other users and resources can belong to one or more COIs, where each can have its own specific security policy [26];
  • merging two IPv4 networks with overlapping addresses (say, if two organizations merge) is complex; it will be much easier to merge networks with IPv6;
  • IPv6 network architectures can easily adapt to an end-to-end security model where the end hosts have the responsibility of providing the security services necessary to protect any data traffic between them; this results in greater flexibility for creating policy-based trust domains that are based on varying parameters including node address and application [27].

IPv6 basic capabilities include the following:

  • addressing,
  • anycast,
  • flow labels,
  • ICMPv6,
  • Neighbor Discovery (ND).

Table A5.1 shows the core protocols that comprise IPv6.

Key IPv6 ProtocolsIP was designed in the 1970s for the purpose of connecting computers that were in separate geographic locations. Computers in a campus were connected by means of local networks, but these local networks were separated into essentially stand-alone islands. “Internet,” as a name to designate the protocol and more recently the worldwide information network, simply means “internetwork”; that is, a connection between multiple networks. In the beginning, the protocol initially had only military use in mind, but computers from universities and enterprises were quickly added. The Internet as a worldwide information network is the result of the practical application of the IP protocol; that is, the result of the interconnection of a large set of information networks [19]. Starting in the early 1990s, developers realized that the communication needs of the twenty-first century required a protocol with some new features and capabilities, while at the
same time retaining the useful features of the existing protocol.

While link-level communication does not generally require a node identifier (address) since the device is intrinsically identified with the link-level address, communication over a group of links (a network) does require unique node identifiers (addresses). The IP address is an identifier that is applied to each device connected to an IP network. In this setup, different elements taking part in the network (servers, routers, desktop computers, etc.) communicate among each other using their IP address as an entity identifier. In version 4 of the IP protocol, addresses consist of four octets. For ease of human conversation, IP protocol addresses are represented as separated by periods, for example: 166.74.110.83, where the decimal numbers are a short hand (and correspond to) the binary code described by the byte in question (an 8 bit number takes a value in the 0–255 range). Since the IPv4 address has 32 bits there are nominally 232 different IP addresses (approximately 4 billion nodes, if all combinations are used). The Domain Name System (DNS) also helped the human conversation in the context of IPv4; DNS is going to be even more critical in IPv6 and will have substantial impact on security administrators that use IP addresses to define security policies (e.g., Firewalls).

IPv4 has proven, by means of its long life, to be a flexible and powerful networking mechanism. However, IPv4 is starting to exhibit limitations, not only with respect to the need for an increase of the IP address space, driven, for example, by new populations of users in countries such as China and India, and by new technologies with “always connected devices” (DSL, cable, networked Primary Deployment Area or PDAs, 2.5G/3G mobile telephones, etc.), but also in reference to a potential global rollout of VoIP. IPv6 creates a new IP address
format, so that the number of IP addresses will not get exhausted for several decades or longer even though an entirely new crop of devices are expected to connect to Internet.

IPv6 also adds improvements in areas such as routing and network autoconfiguration. Specifically, new devices that connect to Internet will be “plug-and-play” devices. With IPv6 one is not required to configure dynamic unpublished local IP addresses, the gateway address, the subnetwork mask or any other parameters. The equipment, when plugged into the network, automatically obtains all requisite
configuration data [19].

The advantages of IPv6 can be summarized as follows:

  • Scalability: IPv6 has 128 bit addresses versus 32 bit IPv4 addresses. With IPv4 the theoretical number of available IP addresses is 232 ∼ 1010. IPv6 offers a 2128 space. Hence, the number of available unique node addressees are 2128 ∼ 1039.
  • Security: IPv6 includes security features in its specifications such as payload encryption and authentication of the source of the communication.
  • Real-Time Applications: To provide better support for real-time traffic (e.g., VoIP), IPv6 includes “labeled flows” in its specifications. By means of this mechanism, routers can recognize the end-to-end flow to which transmitted packets belong. This is similar to the service offered by MPLS, but it is intrinsic with the IP mechanism rather than an add-on. Also, it preceded this MPLS feature by a number of years.
  • “Plug-And-Play”: IPv6 includes a “plug-and-play” mechanism that facilitates the connection of equipment to the network. The requisite configuration is automatic.
  • Mobility: IPv6 includes more efficient and enhanced mobility mechanisms, which are important for mobile networks.
  • Optimized Protocol: IPv6 embodies IPv4 best practices but removes unused or obsolete IPv4 characteristics. This results in a better-optimized Internet protocol.
  • Addressing and Routing: IPv6 improves the addressing and routing hierarchy.
  • Extensibility: IPv6 has been designed to be extensible and offers support for new options and extensions.

With IPv4, the 32-bit address can be represented as AdrClass|netID|hostID. The network portion can contain either a network ID or a network ID and a subnet. Every network and every host or device has a unique address, by definition. Basic NATing is a method by which IP addresses (specifically IPv4 addresses) are transparently mapped from one group to another. Specifically, private “unregistered”
addresses are mapped to a small set (as small as 1) of public registered addresses; this impacts the general addressability, accessibility, and “individuality” of the device. Network Address Port Translation (NAPT), also referred to as Port Address Translation (PAT), is a method by which many network addresses and their TCP/UDP ports are translated into a single network address and its TCP/UDP ports. Together, these two methods, referred to as traditional Network Address Translation (NAT), provide a mechanism to connect a realm with private
addresses to an external realm with globally unique registered addresses [29]. NAT is a short-term solution for the anticipated Internet growth requirements for this decade and a better solution is needed for address exhaustion. There is a clear recognition that NAT techniques make the Internet, the applications, and even the devices more complex (especially when conducting business-to-business transactions) and this means a cost overhead [19]. Overlapping encryptions domains has been a substantial issue for organizations to deal with when creating gateway-togateway VPNs. The expectation is that IPv6 can make IP devices less expensive, more powerful, and even consume less power; the power issue is not only important for environmental reasons, but also improves operability (e.g., longer battery
life in portable devices, such as mobile phones).

IPv4 addresses can be from an officially assigned public range or from an internal intranet private (but not globally unique) block. Internal intranet addresses may be in the ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, as suggested in RFC 1918. In the case of an internal intranet private address, a NAT function is employed to map the internal addresses to an external public address when the
private-to-public network boundary is crossed. This, however, imposes a number of limitations, particularly since the number of registered public addresses available to a company is almost invariably much smaller (as small as 1) than the number of internal devices requiring an address.

As noted, IPv4 theoretically allows up to 232 addresses, based on a four-octet address space. Public, globally unique addresses are assigned by the Internet Assigned Numbers Authority (IANA). IP addresses are addresses of network nodes at layer 3; each device on a network (whether the Internet or an intranet) must have a unique address. In IPv4, it is a 32-bit (4-byte) binary address used to identify the device. It is represented by the nomenclature a.b.c.d, each of a, b, c, and d being from 1 to 255 (0 has a special meaning). Examples are
167.168.169.170, 232.233.229.209, and 200.100.200.100.

The problem is that during the 1980s many public, registered addresses were allocated to firms and organizations without any consistent control. As a result, some organizations have more addresses than they actually need, giving rise to the present dearth of available “registerable” Layer 3 addresses. Furthermore, not all IP addresses can be used due to the fragmentation described above.

One approach to the issue would be a renumbering and a reallocation of the IPv4 addressing space. However, this is not as simple as it appears since it requires significant worldwide coordination efforts and it would not solve the medium-term need for a much larger address space for evolving end-user/ consumer applications. Moreover, it would still be limited for the human population and the quantity of devices that will be connected to the Internet in the medium-term future [19]. At this juncture, and as a temporary and pragmatic approach to alleviate the dearth of addresses, NAT mechanisms are employed by organizations and even home users. This mechanism consists of using only a small set of public IPv4 addresses for an entire network to access to Internet. The myriad of internal devices are assigned IP addresses from a specifically designated range of Class A or Class C address that are locally unique but are duplicatively used and reused within various organizations. In some cases (e.g., residential Internet access use via DSL or cable), the legal IP address is only
provided to a user on a time-lease basis, rather than permanently.

A number of protocols cannot travel through a NAT device and hence the use of NAT implies that many applications (e.g., VoIP) cannot be used effectively in all instances.9 As a consequence, these applications can only be used in intranets. Examples include the following [19]:

  • Multimedia applications such as videoconferencing, VoIP, or VOD/IPTV do not work smoothly through NAT devices. Multimedia applications make use of RTP and Real-Time Control Protocol (RTCP). These in turn use UDP with dynamic allocation of ports and NAT does not directly support this environment.
  • IPsec is used extensively for data authentication, integrity, and confidentiality. However, when NAT is used, IPsec operation is impacted, since NAT changes the address in the IP header.
  • Multicast, although possible in theory, requires complex configuration in a NAT environment and hence, in practice, is not utilized as often as could be the case.

The need for obligatory use of NAT disappears with IPv6 (but it can still be used if someone wanted to).

The format of IPv6 addressing is described in RFC 2373. As noted, an IPv6 address consists of 128 bits, rather than 32 bits as with IPv4 addresses. The number of bits correlates to the address space, as follows:

NAT disappears with IPv6The relatively large size of the IPv6 address is designed to be subdivided into hierarchical routing domains that reflect the topology of the modern-day Internet. The use of 128 bits provides multiple levels of hierarchy and flexibility in designing hierarchical addressing and routing. The IPv4-based Internet currently lacks this flexibility [30].

The IPv6 address is represented as 8 groups of 16 bits each, separated by the “:” character. Each 16 bit group is represented by 4 hexadecimal digits, that is, each digit has a value between 0 and F (0,1, 2, . . . A, B, C, D, E, F with A = 1010, B = 1110, etc., to F = 1510). What follows is an example of a hypothetical IPv6 address

3223 : 0BA0:01E0:D001 : 0000 : 0000 : D0F0 : 0010

If one or more four-digit groups is 0000, the zeros may be omitted and replaced with two colons (::). For example,

3223 : 0BA0 ::

is the abbreviated form of the following address:

3223 : 0BA0 : 0000 : 0000 : 0000 : 0000 : 0000 : 0000

Similarly, only one 0 is written, removing 0’s in the left side, and four 0’s in the middle of the address. For example, the address

3223 : BA0 : 0 : 0 : 0 : 0 :: 1234

is the abbreviated form of the following address

3223 : 0BA0 : 0000 : 0000 : 0000 : 0000 : 0000 : 1234

There is also a method to designate groups of IP addresses or subnetworks that is based on specifying the number of bits that designate the subnetwork, beginning from left to right, using remaining bits to designate single devices inside the network. For example, the notation

3223 : 0BA0:01A0 :: /48

indicates that the part of the IP address used to represent the subnetwork has 48 bits. Since each hexadecimal digit has 4 bits, this points out that the part used to represent the subnetwork is formed by 12 digits, that is “3223:0BA0:01A0.” The remaining digits of the IP address would be used to represent nodes inside the network.

There are a number of special IPv6 addresses, as follows:

  • Autoreturn or Loopback Virtual Address: This address is specified in IPv4 as the 127.0.0.1 address. In IPv6, this address is represented as ::1.
  • Unspecified Address (::): This address is not allocated to any node since it is used to indicate the absence of an address.
  • IPv6 over IPv4 Dynamic/Automatic Tunnel Addresses: These addresses are designated as IPv4-compatible IPv6 addresses and allow the sending of IPv6 traffic over IPv4 networks in a transparent manner. For example, they are represented as ::156.55.23.5.
  • IPv4 over IPv6 Addresses Automatic Representation: These addresses allow for IPv4-only-nodes to still work in IPv6 networks. They are designated as IPv4-mapped IPv6 addresses and are represented as ::FFFF: (e.g., ::FFFF:156.55.43.3).

Like IPv4, IPv6 is a connectionless, unreliable datagram protocol used primarily for addressing and routing packets between hosts. Connectionless means that a session is not established before exchanging data. Unreliable means that delivery is not guaranteed. IPv6 always makes a best-effort attempt to deliver a packet. An IPv6 packet might be lost, delivered out of sequence, duplicated, or delayed. IPv6 per se does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets is done by a higher-layer protocol, such as TCP [30]. From a packet forwarding perspective, IPv6 operates just like IPv4.

An IPv6 packet, also known as an IPv6 datagram, consists of an IPv6 header and an IPv6 payload, as shown in Fig. A5.1. The IPv6 header consists of two parts, the IPv6 base header, and optional extension headers (Fig. A5.2). Functionally, the optional extension headers and upper-layer protocols, for example

IPv6 packet.IPv6 extension headers. IPv6 extension headers are optional headers that may follow the basic IPv6 header. An IPv6 PDU may include zero, one or multiple headers. When multiple extension headers are used, they form a chained list of headers identified by the “next header” field of the previous header.

TCP, are considered part of the IPv6 payload. Table A5.2 shows the fields in the IPv6 base header. IPv4 headers and IPv6 headers are not directly interoperable: hosts and/or routers must use an implementation of both IPv4 and IPv6 in order to recognize and process both header formats (Fig. A5.3). This gives rise to a number of complexities in the migration process between the IPv4 and the IPv6 environments. The IP header in IPv6 has been streamlined and defined to be of a fixed length (40 bytes). In IPv6, header fields from the IPv4 header have been removed, renamed, or moved to the new optional IPv6 Extension Headers. The header length field is no longer needed since the IPv6 header is now a fixed length entity. The IPv4 Type of Service is equivalent to the IPv6 Traffic Class field. The Total Length field has been replaced with the Payload Length field. Since IPv6 only allows for fragmentation to be performed by the IPv6 source
and destination nodes, and not individual routers, the IPv4 segment control fields (Identification, Flags, and Fragment Offset fields) have been moved to similar fields within the Fragment Extension Header. The functionality provided by the Time to Live (TTL10) field has been replaced with the Hop Limit field. The Protocol field has been replaced with the Next Header Type field. The Header Checksum field was removed; that has the main advantage of not having each relay spend time processing the checksum. The Options field is no longer part of

IPv6 Base HeaderComparison of IPv4 and IPv6 headersthe header as it was in IPv4. Options are specified in the optional IPv6 Extension Headers. The removal of the Options field from the header enables more efficient routing; only the information that is needed by a router needs to be processed [31].

One area requiring consideration, however, is the length of the IPv6 PDU: the 40-octet header can be a problem for real-time IP applications such as VoIP and IPTV. Header compression becomes critical [32].11 Also, there will be some bandwidth inefficiency in general, that could be an issue in limited-bandwidth environments or applications (e.g., sensor networks.)

“Autoconfiguration” is a new characteristic of the IPv6 protocol that facilitates network management and system setup tasks by users. This characteristic is often called “plug-and-play” or “connect-and-work.” Autoconfiguration facilitates initialization of user devices: after connecting a device to an IPv6 network, one or several IPv6 globally unique addresses are automatically allocated. DHCP allows systems to obtain an IPv4 address and other required information (e.g., default router or DNS server). A similar protocol, DHCPv6, has been published for IPv6. DHCP and DHCPv6 are known as stateful protocols because they maintain tables on (specialized) servers. However, IPv6 also has a new stateless autoconfiguration protocol that has no equivalent in IPv4. The stateless autoconfiguration protocol does not require a server component because there is no state to maintain (a DHCP server may typically run in a router or firewall). Every IPv6 system (other than routers) is able to build its own unicast global address. Stateless Address Autoconfiguration (SLAAC) provides an alternative between a purely manual configuration and stateful autoconfiguration [33].

“Stateless” autoconfiguration is also described as “serverless.” The acronym SLAAC is also used for serverless address autoconfiguration. SLAAC is defined in RFC 2462. With SLAAC, the presence of configuration servers to supply profile information is not required. The host generates its own address using a combination of the information that it possesses (in its interface or network card) and the information that is periodically supplied by the routers. Routers determine the prefix that identifies networks associated to the link under discussion. The “interface identifier” identifies an interface within a subnetwork and is often, and by default, generated from the Media Access Control (MAC) address of the network card. The IPv6 address is built combining the 64 bits of the interface identifier with the prefixes that routers determine as belonging to the subnetwork. If there is no router, the interface identifier is self-sufficient to allow the PC to generate a “link-local” address. The “link-local” address is sufficient to allow the communication between several nodes connected to the same link (the same local network).

IPv6 addresses are “leased” to an interface for a fixed established time (including an infinite time.) When this “lifetime” expires, the link between the interface and the address is invalidated and the address can be reallocated to other interfaces. For the suitable management of addresses expiration time, an address goes through two states (stages) while is affiliated to an interface [19]:

  1. At first, an address is in a “preferred” state, so its use in any communication is not restricted.
  2. After that, an address becomes “deprecated,” indicating that its affiliation with the current interface will (soon) be invalidated.

When it is in a “deprecated” state, the use of the address is discouraged, although it is not forbidden. However, when possible, any new communication (for example, the opening of a new TCP connection) must use a “preferred” address. A “deprecated” address should only be used by applications that have  already used it before and in cases where it is difficult to change this address to another address without causing a service interruption.

To ensure that allocated addresses (granted either by manual mechanisms or by autoconfiguration) are unique in a specific link, the link duplicated addresses detection algorithm is used. The address to which the duplicated address detection algorithm is being applied to is designated (until the end of this algorithmic session) as an “attempt address.” In this case, it does not matter that such an address has been allocated to an interface and received packets are discarded.

Next, we describe how an IPv6 address is formed. The lowest 64 bits of the address identify a specific interface and these bits are designated as “interface identifier.” The highest 64 bits of the address identify the “path” or the “prefix” of the network or router in one of the links to which such interface is connected. The IPv6 address is formed by combining the prefix with the interface identifier.

It is possible for a host or device to have IPv6 and IPv4 addresses simultaneously? Most of the systems that currently support IPv6 allow the simultaneous use of both protocols. In this way, it is possible to support communication with IPv4-only-networks as well as IPv6-only-networks and the use of the applications developed for both protocols [19].

Is it possible to transmit IPv6 traffic over IPv4 networks via tunneling methods. This approach consists of “wrapping” the IPv6 traffic as IPv4 payload data: IPv6 traffic is sent “encapsulated” into IPv4 traffic and at the receiving end, this traffic is parsed as IPv6 traffic. Transition mechanisms are methods used for the coexistence of IPv4 and/or IPv6 devices and networks. For example, an “IPv6-in- IPv4 tunnel” is a transition mechanism that allows IPv6 devices to communicate through an IPv4 network. The mechanism consists of creating the IPv6 packets in a normal way and encapsulating them in an IPv4 packet. The reverse process is undertaken in the destination machine that de-encapsulates the IPv6 packet.

There is a significant difference between the procedures to allocate IPv4 addresses, that focus on the parsimonious use of addresses (since addresses are a scare resource and should be managed with caution), and the procedures to allocate IPv6 addresses, that focus on flexibility. ISPs deploying IPv6 systems follow the RIRs policies relating to how to assign IPv6 addressing space among their clients. RIRs are recommending ISPs and operators allocate to each IPv6 client a/48 subnetwork; this allows clients to manage their own subnetworks without using NAT. (The implication is that the obligatory need for NAT disappears in IPv6).

In order to allow its maximum scalability, the IPv6 protocol uses an approach based on a basic header, with minimum information. This differentiates it from IPv4 where different options are included in addition to the basic header. IPv6 uses a header “concatenation” mechanism to support supplementary capabilities. The advantages of this approach include the following:

  • The size of the basic header is always the same, and is well known. The basic header has been simplified compared with IPv4, since only 8 fields are used instead of 12. The basic IPv6 header has a fixed size; hence, its processing by nodes and routers is more straightforward. Also, the header’s structure aligns to 64 bits, so that new and future processors (64 bits minimum) can process it in a more efficient way.
  • Routers placed between a source point and a destination point (that is, the route that a specific packet has to pass through), do not need to process or understand any “following headers.” In other words, in general, interior (core) points of the network (routers) only have to process the basic header while in IPv4, all headers must be processed. This flow mechanism is similar to the operation in MPLS, yet precedes it by several years.
  • There is no limit to the number of options that the headers can support (the IPv6 basic header is 40 octets in length, while IPv4 one varies from 20 to 60 octets, depending on the options used).

In IPv6, interior/core routers do not perform packets fragmentation, but the fragmentation is performed end-to-end. That is, source and destination nodes perform, by means of the IPv6 stack, the fragmentation of a packet and the reassembly, respectively. The fragmentation process consists of dividing the source packet into smaller packets or fragments [19].

The IPv6 specification defines a number of extension headers [31] (Table A5.3) [34]):

  • Routing Header: Similar to the source routing options in IPv4, the header is used to mandate a specific routing.
  • Authentication Header: AH is a security header that provides authentication and integrity.
  • Encapsulating Security Payload (ESP) Header: ESP is a security header that provides authentication and encryption.
  • Fragmentation Header: This is similar to the fragmentation options in IPv4. Destination Options Header: A header that contains a set of options to be processed only by the final destination node. Mobile IPv6 is an example of an environment that uses such a header
  • Hop-by-Hop Options Header: A set of options needed by routers to perform certain management or debugging functions..

As noted, IPsec provides network-level security where the application data is encapsulated within the IPv6 packet. IPsec utilizes the AH and/or ESP header to provide security (the AH and ESP header may be used separately or in combination). IPsec, with ESP, offers integrity and data origin authentication, confidentiality, and optional (at the discretion of the receiver) antireplay features (using confidentiality without integrity is discouraged by the RFCs); ESP furthermore provides limited traffic flow confidentiality. Both the AH and ESP header may be employed as follows [31] (Fig. A5.4):

IPv6 Extension Headers

  • Tunnel Mode: The protocol is applied to the entire IP packet. This method is needed to ensure security over the entire packet, where a new IPv6 header and an AH or ESP header are wrapped around the original IP packet.
  • Transport Mode: The protocol is just applied to the transport layer (i.e., TCP, UDP, ICMP) in the form of an IPv6 header, AH or ESP header, followed by the transport protocol data (header, data).

IPsec modes and types.

Migration to IPv6 environments is expected to be fairly complex. Initially, internetworking between the two environments will be critical. Existing IPv4- endpoints and/or nodes will need to run dual-stack nodes or convert to IPv6 systems. Fortunately, the new protocol supports an IPv4-compatible IPv6 address that is an IPv6 address employing embedded IPv4 addresses. Tunneling, that we already described in passing, will play a major role in the beginning. There are a number of requirements that are typically applicable to an organization wishing to introduce an IPv6 service [35]:

  • the existing IPv4 service should not be adversely disrupted (e.g., as it might be by router loading of encapsulating IPv6 in IPv4 for tunnels);
  • the IPv6 service should perform as well as the IPv4 service (e.g., at the IPv4 line rate, and with similar network characteristics);
  • the service must be manageable and be able to be monitored (thus tools should be available for IPv6 as they are for IPv4);
  • the security of the network should not be compromised, due to the additional protocol itself or a weakness of any transition mechanism used;
  • an IPv6 address allocation plan must be drawn up.

Well-known interworking mechanisms include the following [36]12:

  • Dual IP-Layer (or Dual Stack): A technique for providing complete support for both IPs—IPv4 and IPv6—in hosts and routers.
  • Configured Tunneling of IPv6 over IPv4: Point-to-point tunnels made by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
  • Automatic Tunneling of IPv6 over IPv4: A mechanism for using IPv4- compatible addresses to automatically tunnel IPv6 packets over IPv4 networks.

Tunneling techniques include the following [36]12:

  • IPv6-over-IPv4 Tunneling: The technique of encapsulating IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.
  • Configured Tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined by configuration information on the encapsulating node. The tunnels can be either unidirectional or bidirectional. Bidirectional configured tunnels behave as virtual point-to-point links.
  • Automatic Tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined from the IPv4 address embedded in the IPv4- compatible destination address of the IPv6 packet being tunneled.
  • IPv4 Multicast Tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined using ND. Unlike configured tunneling, this does not require any address configuration and unlike automatic tunneling it does not require the use of IPv4-compatible addresses. However, the mechanism assumes that the IPv4 infrastructure supports IPv4 multicast.

Applications (and the lower-layer protocol stack) need to be properly equipped. There are four cases [37].

Case 1: IPv4-only applications in a dual-stack node. IPv6 protocol is introduced in a node, but applications are not yet ported to support IPv6. The protocol stack is as follows:

IPv6 protocol is introduced in a node

Case 2: IPv4-only applications and IPv6-only applications in a dual-stack node. Applications are ported for IPv6-only. Therefore there are two similar applications, one for each protocol version (e.g., ping and ping6). The protocol stack is as follows:

IPv4-only applications and IPv6-only applications

Case 3: Applications supporting both IPv4 and IPv6 in a dual-stack node. Applications are ported for both IPv4 and IPv6 support. Therefore, the existing IPv4 applications can be removed. The protocol stack is as follows:

Applications supporting both IPv4 and IPv6

Case 4: Applications supporting both IPv4 and IPv6 in an IPv4-only node. Applications are ported for both IPv4 and IPv6 support, but the same applications may also have to work when IPv6 is not being used (e.g., disabled from the OS). The protocol stack is as follows:

IPv4 and IPv6

The first two cases are not interesting in the longer term; only a few applications are inherently IPv4- or IPv6-specific and should work with both protocols without having to care about which one is being used.

Figure A5.5 depicts some basic scenarios of carrier-based IPv6 support. Cases (a) and (b) represent traditional environments where the carrier link supports either a clear channel that is used to connect, say, two IPv4 routers, or is IPaware. (In each case, the “cloud” on the left could also be the IPv4 Internet or the IPv6 Internet.)

Support of IPv6 in carrier networks.In Case (c), the carrier link is used to connect as a transparent link two IPv6 routers; the carrier link is not (does not need to be) aware that it is transferring IPv6 PDUs. In Case (d), the carrier system is IPv4-aware, so the use of that environment to support IPv6 requires IPv6 to operate in a tunneled-mode over the non-IPv6 cloud, which is a capability of IPv6.

In Case (e), the carrier infrastructure needs to provide a gateway function between the IPv4 and the IPv6 world (this could entail repacking the IP PDUs from the v4 format to the v6 format). Case (f) is the ideal long-term scenario where the “world has converted to IPv6” and “so did the carrier network.”

In Case (g), the carrier IP-aware network provides a conversion function to support both IPv4 (as a baseline) and IPv6 (as a “new technology”) handoffs. Possibly a dual-stack mechanism is utilized. In Case (h), the carrier IPv6-aware network provides a support function for IPv6 (as a baseline) and also a conversion function to support legacy IPv4 islands.

Even network/security administrators that operate in a pure IPv4 environment need to be aware of IPv6-related security issues. In a standard IPv4 environment where IPv6 is not explicitly supported, any form of IPv6-based tunneling traffic must be considered abnormal, malicious traffic. For example, unconstrained 6to4-based traffic should be blocked (6to4 is a transitional mechanism intended for individual independent nodes to connect IPv6 over the greater Internet). Most commercial-grade IPv4 firewalls block IP protocol 41, the 6to4, and tunnel protocol, unless it has been explicitly enabled [38].

In 2008, the Cooperative Association for Internet Data Analysis (CAIDA) and the American Registry for Internet Numbers (ARIN) surveyed over 200 respondents from USG agencies, commercial organizations (including ISPs and end users), educational institutions, associations, and other profit and nonprofit entities to determine the state of affairs in the United States with reference to IPv6 plans. Between 50% and 75% of the organizations surveyed indicated that they plan to deploy IPv6 by 2010 or sooner. According to some observers IPv6 is still an emerging technology, maturing and growing as practical experience is gained; others take a more aggressive view, as seen in the next section.

 

 

IPv6 Concepts

While it is likely that initially 3DTV will be delivered by traditional transport mechanisms, including DVB over DTH systems, recently some research efforts have been focused on delivery (streaming) of 3DTV using IP. IP can be used for IPTV systems or over an IP shared infrastructure, whether a private network (here shared with other applications) or over the Internet (here shared with a multitude of other users and applications) (some studies have also been undertaken of late on the capabilities of DVB-H to broadcast stereo-video streams.) However, it seems that the focus so far has been on IPv4; the industry is encouraged to assess the capabilities of IPv6. While this topic is partially tangential to a core 3DTV discussion, the abundant literature on proposals for packet-based delivery of future 3DTV (including but not limited to Refs [4–13]) makes the issue relevant. IPv6, when used with header compression, is expected to be a very useful technology to support IPTV in the future in general and 3DTV in particular. For a general discussion of IPTV and DVB-H, the reader may refer to Ref. [14] among other references.

IPv6 was defined in the mid-1990s in IETF Request for Comments (RFC) 2460 “Internet Protocol, Version 6 (IPv6) Specification” and a host of other more recent RFCs, is an “improved, streamlined, successor version” of IPv4.4 Because of market pull from the Office of Management and Budget’s mandate that 24 major federal agencies in the US Government (USG) be IPv6-ready by June 30, 2008, and because of market pull from European and Asian institutions, IPv6 is expected to see gradual deployment from this point forward and in the coming decade. With IPv6 already gaining momentum globally, with major interest and activity in Europe and Asia and also some traction in the United States; the expectation is that in the next few years a (slow) transition to this new protocol will occur worldwide. An IP-based infrastructure has now become the ubiquitous underlying architecture for commercial-, institutional-, and USG/Other (non-US)
Government (OG) communications and services functions. IPv6 is expected to be the next step in the industry’s evolution in the past 50 years from analog, to digital, to packet, to broadband. As an example of IPv6 deployment underway, Europe has set the objective to widely implement IPv6 by 2010; the goal is that at least 25% of users should be able to connect to the IPv6 Internet and to access their most important content and service providers without noticing a major difference when compared to IPv4.

IPv6 offers the potential of achieving increased scalability, reachability, endto- end interworking, QoS, and commercial-grade robustness for data communication, mobile connectivity, and for VoIP/triple-play networks. The current version of the IP, IPv4, has been in use successfully for almost 30 years and poses some challenges in supporting emerging demands for address space cardinality, high-density mobility, multimedia, and strong security. This is particularly true in developing domestic and defense department applications utilizing peer-to-peer networking. IPv6 is an improved version of IP that is designed to coexist with IPv4 while providing better internetworking capabilities than IPv4 [14–17].

When the current version of IPv4 was conceived in the mid-1970s and defined soon thereafter (1981), it provided just over 4 billion addresses; that is not enough to provide each person on the planet with one address without even considering the myriad of other devices and device modules needing addressability (such as but not limited to over 3 billion cellphones). Additionally, 74% of IPv4 have been assigned to North American organizations. The goal of developers is to be able to assign IP addresses to a new class of Internet-capable devices: mobile phones, car navigation systems, home appliances, industrial equipment, and other devices (such as sensors and Body-Area-Network medical devices). All of these devices can then be linked together, constantly communicating, even in wireless mode. Projections show that the current generation of the Internet will “run out of space” in the near future (2010/2011) if IPv6 is not adopted around the world. IPv6 is an essential technology for ambient intelligence and will be a key driver for a multitude of new, innovative mobile/wireless applications and services [18].

IPv6 was initially developed in the early 1990s because of the anticipated need for more end system addresses based on anticipated Internet growth, encompassing mobile phone deployment, smart home appliances, and billions of new users in developing countries (e.g., in China and India). New technologies and applications such as VoIP, “always-on access” (e.g., DSL and cable), Ethernet-tothe- home, converged networks, and evolving ubiquitous computing applications will continue to drive this need even more in the next few years [19].

IPv6 features, in comparison with IPv4, include the following [20]:

  • Expanded Addressing Capabilities: IPv6 increases the IP address size from 32 bits to 128 bits to support more levels in the addressing hierarchy, a much greater number of addressable nodes, and simpler autoconfiguration of addresses. The scalability of multicast routing is improved by adding a “scope” field to multicast addresses. A new type of address called an “anycast address” is also defined to be used to send a packet to any one of a group of nodes.
  • Header Format Simplification: Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header.
  • Authentication and Privacy Capabilities: In IPv6, security is built-in as part of the protocol suite: extensions to support authentication, data integrity (encryption), and (optional) data confidentiality are specified for IPv6. The security features of IPv6 are described in the Security Architecture for the Internet Protocol RFC 2401 [21], along with RFC 2402 [22] and RFC2406 [23]; Internet Protocol Security (IPsec) defined in these RFCs is required (mandatory). IPsec is a set of protocols and related mechanisms that supports confidentiality and integrity. (IPsec was originally developed as part of the IPv6 specification, but due to the need for security in the IPv4 environment, it has also been adapted for IPv4).
  • Flow Labeling Capability: A new feature is added to enable the labeling of packets belonging to particular traffic “flows” for which the sender requests special handling, such as non-default quality of service or “real-time” service. Services such as VoIP and IP-based entertainment video delivery (IPTV) is becoming broadly deployed and flow labeling, especially in the network core, can be very beneficial.
  • Improved Support for Extensions and Options: Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.

End systems (such as PCs, servers), network elements (customer-owned and/or carrier-owned) and (perhaps) applications need to be IPv6-aware to communicate in the IPv6 environment. IPv6 has been enabled on many computing platforms. At this juncture, many operating systems come with IPv6 enabled by default;  IPv6-ready Operating Systems (OS) include but are not limited to Mac OS X,
OpenBSD, NetBSD, FreeBSD, Linux, Windows Vista, Windows XP (Service Pack 2), Windows 2003 Server, and Windows 2008 Server. Java began supporting IPv6 with J2SE 1.4 (in 2002) on Solaris and Linux. Support for IPv6 on Windows was added with J2SE 1.5. Other languages, such as C and C++ also support IPv6. At this time the number of applications with native IPv6 support is significant given that most important networking applications provide native IPv6 support. Hardware vendors including Apple Computer, Cisco Systems,
HP, Hitachi, IBM, and Microsoft, support IPv6. One should note that IPv6 was designed with security in mind, but at the current time its implementation and deployment are (much) less mature than is the case for IPv4. When IPv4 was developed in the early 1980s, security was not a consideration; now a number of mechanisms have been added to address security considerations to IP. When IPv6 was developed in the early-to-mid 1990s, security was a consideration; hence, a number of mechanisms have been built-in into the protocol from the get-go to furnish security capabilities to IP.

A presentation delivered during an open session at the July 2007 ICANN Public Meeting in San Juan, Puerto Rico made note of the accelerated depletion rate of IPv4 addresses and the growing difficulties the Regional Internet Registries (RIRs) are experiencing in allocating contiguous address blocks of sufficient size to service providers. Furthermore, the fragmentation in the IPv4 address space
is taxing and stressing the global routing fabric and the near-term expectation is that the RIRs will impose more restrictive IPv4 allocation policies and promote a rapid adoption of IPv6 addresses [24]. The IPv4 address space is expected to run out by 2012.

 

Multicast Operation

As noted above, the backbone may consist of (i) a pure IP network or (ii) a mixed satellite transmission link to a metropolitan headend that, in turn, uses a metropolitan (or regional) telco IP network. Applications such as video are very sensitive to end-to-end delay, jitter, and (uncorrectable) packet loss; QoS considerations are critical. These networks tend to have fewer hops and pruning may be somewhat trivially implemented by a making use of a simplified network topology.

At the logical level, there are three types of communication between systems in a(n IP) network:

  • Unicast: Here, one system communicates directly to another system.
  • Broadcast: Here, one system communicates to all systems.
  • Multicast: Here, one system communicates to a select group of other systems.

In traditional IP networks, a packet is typically sent by a source to a single destination (unicast); alternatively, the packet can be sent to all devices on the network (broadcast). There are business- and multimedia (entertainment) applications that require a multicast transmission mechanism to enable bandwidthefficient communication between groups of devices where information is transmitted to a single multicast address and received by any device that wishes to obtain such information. In traditional IP networks, it is not possible to generate a single transmission of data when this data is destined for a (large) group of remote devices. There are classes of applications that require  distribution of information to a defined (but possibly dynamic) set of users. IP Multicast, an extension to IP, is required to properly address these communications needs. As the term implies, IP Multicast has been developed to support efficient communication between a source and multiple remote destinations.

Multicast applications include, among others, datacasting—for example, for distribution of real-time financial data—entertainment digital television over an IP network (commercial-grade IPTV), Internet radio, multipoint video conferencing, distance-learning, streaming media applications, and corporate communications. Other applications include distributed interactive simulation, cloud/grid computing, and distributed video gaming (where most receivers are also senders). IP Multicast protocols and underlying technologies enable efficient distribution of data, voice, and video streams to a large population of users, ranging from hundreds to thousands to millions of users. IP Multicast technology enjoys intrinsic scalability, which is critical for these types of applications.

As an example in the IPTV arena, with the current trend toward the delivery of HDTV signals, each requiring the 12 Mbps range, and the consumers’ desire for a large number of channels (200–300 being typical), there has to be an efficient mechanism of delivering a signal of 1–2 Gbps1 aggregate to a large number of remote users. If a source had to deliver 1 Gbps of signal to, say, 1 million receivers by  transmitting all of this bandwidth across the core network, it would require a petabit per second network fabric; this is currently not possible. On the other hand, if the source could send the 1 Gbps of traffic to (say) 50 remote distribution points (for example, headends), each of which then makes use of a local distribution network to reach 20,000 subscribers, the core network only needs to support 50 Gbps, which is possible with proper design. For such reasons, IP Multicast is seen as a bandwidth-conserving technology that optimizes traffic management by simultaneously delivering a stream of information to a large population of recipients, including corporate enterprise users and residential customers. IPTV uses IP-based basic transport (where IP packets contain MPEG-4 TSs) and IP Multicast for service control and content acquisition (group membership). See Fig. 5.1 for a pictorial example.

One important design principle of IP Multicast is to allow receiver-initiated attachment (joins) to information streams, thus supporting a distributed informatics model. A second important principle is the ability to support optimal pruning such that the distribution of the content is streamlined by pushing replication as close to the receiver as possible. These principles enable bandwidth-efficient use of underlying network infrastructure.

The issue of security in multicast environments is addressed via Conditional Access Systems (CAS) that provide per-program encryption (typically, but not always, symmetric encryption; also known as inner encryption) or aggregate IP-level encryption (again typically, but not always, symmetric encryption; also known as outer encryption).

Carriers have been upgrading their network infrastructure in the past few years to enhance their capability to provide QoS-managed services, such as IPTV. Specifically, legacy remote access platforms, implemented largely to support basic DSL service roll-outs—for example, supporting ATM aggregation and DSL termination—are being replaced by new broadband network gateway access technologies optimized around IP, Ethernet, and VDSL2 (Very High Bitrate

Bandwidth advantage of IP Multicast.

Digital Subscriber Line 2). These services and capabilities are delivered with multiservice routers on the network edge. Viewer-initiated program selection is achieved using the IGMP, specifically with the Join Group Request message. (IGMP v2 messages include Create Group Request, Create Group Reply, Join Group Request, Join Group Reply, Leave Group (LG) Request, LG Reply, Confirm Group Request, and Confirm Group Reply.) Multicast communication is based on the construct of a group of receivers (hosts) that have an interest in receiving a particular stream of information, be it voice, video, or data. There are no physical or geographical constraints, or boundaries to belong to a group, as long as the hosts have (broadband) network connectivity. The connectivity of the receivers can be heterogeneous in nature, in terms of bandwidth and connecting infrastructure (for example, receivers connected over the Internet), or homogeneous (for example, IPTV or DVB-H users). Hosts that are desirous of receiving data intended for a particular group join the group using a group management protocol: hosts/receivers must become explicit members of the group to receive the data stream, but such membership may be ephemeral and/or dynamic. Groups of IP hosts that have joined the group and wish to receive traffic sent to this specific group are identified by multicast addresses.

Multicast routing protocols belong to one of two categories: Dense-Mode (DM) protocols and Sparse-Mode (SM) protocols.

  • DM protocols are designed on the assumption that the majority of routers in the network will need to distribute multicast traffic for each multicast group. DM protocols build distribution trees by initially flooding the entire network and then pruning out the (presumably small number of) paths without active receivers. The DM protocols are used in LAN environments, where bandwidth
    considerations are less important, but can also be used in WANs in special cases (for example, where the backbone is a one-hop broadcast medium such as a satellite beam with wide geographic illumination, such as in some IPTV applications).
  • SM protocols are designed on the assumption that only few routers in the network will need to distribute multicast traffic for each multicast group. SM protocols start out with an empty distribution tree and add drop-off branches only upon explicit requests from receivers to join the distribution. SM protocols are generally used in WAN environments, where bandwidth considerations are important.

For IP Multicast there are several multicast routing protocols that can be employed to acquire real-time topological and membership information for active groups. Routing protocols that may be utilized include the Protocol-Independent Multicast (PIM), the Distance Vector Multicast Routing Protocol (DVMRP), the MOSPF (Multicast Open Shortest Path First), and Core-Based Trees (CBT). Multicast
routing protocols build distribution trees by examining routing a forwarding table that contains unicast reachability information. PIM and CBT use the unicast forwarding table of the router. Other protocols use their specific unicast reachability routing tables; for example, DVMRP uses its distance vector routing protocol to determine how to create source-based distribution trees, while MOSPF utilizes its link state table to create source-based distribution trees. MOSPF, DVMRP, and PIM-DM are dense-mode routing protocols, while CBT and PIM-SM are sparse-mode routing protocols. PIM is currently the most-widely used protocol.

As noted, IGMP (versions 1, 2, and 3) is the protocol used by Internet Protocol Version 4 (IPv4) hosts to communicate multicast group membership states to multicast routers. IGMP is used to dynamically register individual hosts/receivers on a particular local subnet (for example, LAN) to a multicast group. IGMP

IGMP v2 message format.

version 1 defined the basic mechanism. It supports a Membership Query (MQ) message and a Membership Report (MR) message. Most implementations at press time employed IGMP version 2; it adds LG messages. Version 3 adds source awareness, allowing the inclusion or exclusion of sources. IGMP allows group membership lists to be dynamically maintained. The host (user) sends an IGMP “report,” or join, to the router to be included in the group. Periodically, the router sends a “query” to learn which hosts (users) are still part of a group. If a host wishes to continue its group membership, it responds to the query with a “report.” If the host does not send a “report,” the router prunes the group list to delete this host; this eliminates unnecessary network transmissions. With IGMP v2, a host may send an LG message to alert the router that it is no longer participating in a multicast group; this allows the router to prune the group list to delete this host before the next query is scheduled, thereby minimizing the time period during which unneeded transmissions are forwarded to the network.

The IGMP messages for IGMP version 2 are shown in Fig. 5.2. The message comprises an eight octet structure. During transmission, IGMP messages are encapsulated in IP datagrams; to indicate that an IGMP packet is being carried, the IP header contains a protocol number of 2. An IP datagram includes a Protocol Type field, that for IGMP is equal to 2 (IGMP is one of many protocols that can be specified in this field). An IGMP v2 PDU consists of a 20-byte IP header and 8 bytes of IGMP.

Some of the areas that require consideration and technical support to develop and deploy IPTV systems include the following, among many others:

  • content aggregation;
  • content encoding (e.g., AVC/H.264/MPEG-4 Part 10, MPEG-2, SD, HD, Serial Digital Interface (SDI), Asynchronous Serial Interface (ASI), Layer 1 switching/routing);
  • audio management;
  • digital right management/CA: encryption (DVB-CSA, AES or Advanced Encryption StandardAdvanced Encryption Standard); key management schemes (basically, CAS); transport rights;
  • encapsulation (MPEG-2 transport stream distribution);
  • backbone distribution such as satellite or terrestrial (DVB-S2, QPSK, 8-PSK, FEC, turbo coding for satellite—SONET (Synchronous Optical Network)/SDH/OTN (Synchronous Digital Hierarchy/Optical Transport Network) for terrestrial);
  • metro-level distribution;
  • last-mile distribution (LAN/WAN/optics, GbE (Gigabit Ethernet), DSL/FTTH);
  • multicast protocol mechanisms (IP multicast);
  • QoS backbone distribution;
  • QoS, metro-level distribution;
  • QoS, last-mile distribution;
  • QoS, channel surfing;
  • Set-Top Box (STB)/middleware;
  • QoE;
  • Electronic Program Guide (EPG);
  • blackouts;
  • service provisioning/billing, service management;
  • advanced video services (e.g., PDR and VOD);
  • management and confidence monitoring;
  • triple play/quadruple play.

IPTV Concepts

As described in Ref. [1], IPTV deals with approaches, technologies, and protocols to deliver commercial-grade SD and HD entertainment-quality real-time linear and on-demand video content over IP-based networks, while meeting all prerequisite QoS, QoE, Conditional Access (CA) (security), blackout management (for sporting events), Emergency Alert System (EAS), closed captions, parental controls, Nielsen rating collection, secondary audio channel, picture-in-picture, and guide data requirements of the content providers and/or regulatory entities. Typically, IPTV makes use of MPEG-4 encoding to deliver 200–300 SD channels and 20–30 HD channels; viewers need to be able to switch channels within 2 s or less; also, the need exists to support multi-set-top boxes/multiprogramming (say 2–4) within a single domicile. IPTV is not to be confused with the simple delivery of video over an IP network (including video streaming) that has been possible for over two decades; IPTV supports all business, billing, provisioning, and content protection requirements that are associated with commercial video distribution. IP-based service needs to be comparable to that received over cable TV or Direct Broadcast Satellite. In addition to TV sets, the content may also be delivered to a personal computer. MPEG-4, which operates at 2.5 Mbps for SD video and 8–11 Mbps for HD video, is critical to telco-based video delivery over a copper-based plant because of the bandwidth limitations of that plant, particularly when multiple simultaneous streams need to be delivered to a domicile; MPEG-2 would typically require a higher bitrate for the same perceived video quality. IP Multicast is typically employed to support IPTV. There has been significant deployment of commercial-grade IPTV services around the world in the recent past, as seen in Table 5.1.

Partial List of IPTV Providers in the United States and Europe

One can anticipate several phases in the deployment of IPTV, as follows:

  • Phase 1: IPTV introduced by the telcos for commercial delivery of entertainment-grade video over their IP/MPLS (Multiprotocol Label Switching) networks (2007–2012).
  • Phase 2: IPTV introduced by the cable TV companies for commercial delivery of entertainment-grade video over their cable infrastructure (speculative, 2012+).
  • Phase 3: IPTV to morph to Internet TV for commercial delivery of any video content but of entertainment-grade quality over the Internet/broadband Internet access connections (2012+).

 

3DTV/3DV IPTV Transmission Approaches

IPTV services enable advanced content viewing and navigation by consumers; the technology is rapidly emerging and becoming commercially available. IPTV is being championed by the telecom industry in particular, given the significant IP-based infrastructure these carriers already own. IPTV may be an ideal technology to support 3DTV because of the efficient network pruning supported by IP Multicast. Developers are encouraged to explore the use of IPv6 to support evolving 3DTV needs. 3DTV is a forward-looking service and hence, it should make use of a forward-looking IP transport technology, specifically IPv6.

IP Multicast is also employed for control. While IP Multicast has been around for a number of years, it is now finding fertile commercial applications in the IPTV and DVB-H arenas. Applications such as datacasting (e.g., stock market or other financial data) tend to make use of large multihop networks; pruning is often employed and nodal store-and-forward approaches are completely acceptable. Applications such as video are very sensitive to end-to-end delay, jitter, and (uncorrectable) packet loss; QoS considerations are critical. These networks tend
to have fewer hops and pruning may be somewhat trivially implemented by making use of a simplified network topology.

IPTV services enable traditional carriers to deliver SD (Standard Definition) and HD video to their customers in support of their Triple/Quadruple Play strategies. With the significant erosion in revenues from traditional voice services on wireline-originated calls (both, in terms of depressed pricing and a shift to VoIP over broadband Internet services delivered over cable TV infrastructure), and with the transition of many customers from wireline to wireless services, the traditional telephone carriers find themselves in need of generating new revenues by seeking to deliver video services to their customers. Traditional phone carriers find themselves challenged in the voice arena (by VoIP and other providers); their Internet services are also challenged in the broadband Internet access arena (by cable TV companies); and, their video services are nascent and challenged by a lack of deployed technology.

MPEG-4 and/or Other Data Support

For satellite transmission and to remain consistent with already existing MPEG-2 technology6, MPEG-4 TSs (or other data) are further  encapsulated in Multiprotocol Encapsulation (MPE – RFC 3016) and then segmented again and placed into TS streams via a device called IP Encapsulator (IPE; Fig. A4.5). MPE is used to transmit datagrams that exceed the length of the DVB “cell,” just as Asynchronous Transfer Mode Adaptation Layer 5 (AAL5) is used for a

Pictorial view of encapsulation.

similar function in an ATM context. MPE allows one to encapsulate IP packets into MPEG-2 TSs (“packets,” or “cells”; Fig. A4.6). IPEs handle statistical multiplexing and facilitate coexistence. IPE receives IP packets from an Ethernet connection and encapsulates packets using MPE, and then maps these streams into an MPEG-2 TS. Once the device has encapsulated the data, the IPE forwards the data packets to a satellite link. Generic data (IP) for transmission over the MPEG-2 transport multiplex (or IP packets containing MPEG-4 video) is passed to an encapsulator that typically receives PDUs (Ethernet frames, IP datagrams, or other network layer packets); the encapsulator formats each PDU into a series of TS packets (usually after adding an encapsulation header) that are sent over a TS logical channel. The MPE packet has the format shown in Fig. A4.7. Figure A4.8 shows the encapsulation process.

Note: IPEs are usually not employed if the output of the layer 2 switch is connected to a router for transmission over a terrestrial network; in this case, the headend is responsible for proper downstream enveloping and distribution of the traffic to the ultimate consumer. In other pure, IP-based video environments, where DVB-S or DVB-S2 are not used (e.g., a greenfield IP network that is designed to just handle video), the TSs are included in IP packets that are then transmitted as needed (Fig. A4.9). Specifically, with the current generation of equipment, the encoder will typically generate IP packets; these have a source IP address and a single or multicast IP address. The advantage of having video in IP format is that it can be carried over a regular (pure) Local Area Network (LAN) or carrier Wide Area Network (WAN).

IPE protocol stack.

MPE packet.

Encapsulation process.

Consider Fig. A4.9 again. It clearly depicts video (and audio) information being organized into PESs that are then segmented into TSs. Examining the protocol stack of Fig. A4.9 one should note that in a traditional MPEG-2 environment of DTV, either over-the-air transmission or cable TV transmission, the TSs are handled directly by an MPEG-2-ready infrastructure formally known as an MPEG-2 Transport Multiplex (see left-hand side stack). As explained, MPEG-2 Transport Multiplex offers a number of parallel channels that are known as TS logical channels. Each TS logical channel is uniquely identified by the PID value that is carried in the header of each MPEG-2 TS packet. TS logical channels are independently numbered on each MPEG-2 TS multiplex (MUX). As just noted, the service provided by an MPEG-2 transport multiplex offers a number of parallel channels that correspond to logical links (forming the MPEG TS) [24, 28]. The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks, say in cable TV–based Internet access.

Simplified protocol hierarchy.

There may be an interest in also carrying actual IP datagrams over this MPEG-2 transport multiplex infrastructure (this may be generic IP data or IP packets emerging from MPEG-4 encoders that contain 7 MPEG-4 frames.) To handle this requirement, packet data for transmission over an MPEG-2 transport multiplex is passed to an IPE. This receives PDUs, such as Ethernet frames or IP packets, and formats each into a Subnetwork Data Unit (SNDU), by adding an encapsulation header and trailer. The SNDUs are subsequently fragmented into a series of TS packets. To receive IP packets over an MPEG-2 TS Multiplex, a receiver needs to identify the specific TS multiplex (physical link) and also the TS logical channel (the PID value of a logical link). It is common for a number of MPEG-2 TS logical channels to carry SNDUs; therefore, a receiver must filter (accept) IP packets sent with a number of PID values, and must independently reassemble each SNDU [29]. Some applications require transmission of MPEG-4 streams over a preexisting MPEG-2 infrastructure, for example, in a cable TV application. This is also done via the IPE; here the IP packets generated by the MPEG-4 encoder are considered (treated) as if they were data, as just described above in this paragraph (Fig. A4.10).

The encapsulator receives PDUs (e.g., IP packets or Ethernet frames) and formats these into SNDUs. An encapsulation (or convergence) protocol transports each SNDU over the MPEG-2 TS service and provides the appropriate mechanisms to deliver the encapsulated PDU to the receiver IP interface. In forming an SNDU, the encapsulation protocol typically adds header fields that carry protocol control information, such as the length of SNDU, receiver address, multiplexing information, payload type, and sequence numbers. The SNDU payload is typically followed by a trailer that carries an Integrity Check (e.g., Cyclic Redundancy Check, CRC). When required, an SNDU may be fragmented across a number of TS packets (Figs A4.11 and A4.12) [29].

Encapsulator function.

Encapsulation of a subnetwork IPv4 or IPv6 PDU to form an MPEG-2 payload unit.

Encapsulation of a PDU (e.g., IP packet) into a series of MPEG-2 TS packets. Each TS packet carries a header with a common packet ID (PID) value denoting the MPEG-2 TS logical channel.

In summary, the standard DVB way of carrying IP datagrams in an MPEG-2 TS is to use MPE; with MPE each IP datagram is encapsulated into one MPE section. A stream of MPE sections are then put into an ES, that is, a stream of MPEG-2 TS packets with a particular PID. Each MPE section has a 12-B header, a 4-B CRC (CRC-32) tail, and a payload length, which is identical to the length of the IP datagram that is carried by the MPE section [30].

 

Packetized Elementary Stream (PES) Packets and Transport Stream (TS) Unit(s)

International Standard ISO/IEC 13818-1 was prepared3 by JTC ISO/IEC JTC 1, Information technology, Subcommittee SC 29, “Coding of audio, picture, multimedia and hypermedia information,” in collaboration with ITU-T. The identical text is published as ITU-T Rec. H.222.0. ISO/IEC 13818 consists of the following parts, under the general title “Information  technology—Generic coding of moving pictures and associated audio information”:

  • Part 1: Systems
  • Part 2: Video
  • Part 3: Audio
  • Part 4: Conformance testing
  • Part 5: Software simulation
  • Part 6: Extensions for DSM-CC
  • Part 7: Advanced Audio Coding (AAC)
  • Part 9: Extension for real time interface for systems decoders
  • Part 10: Conformance extensions for Digital Storage Media Command and Control (DSM-CC)

The MPEG-2 and/or -4 standard defines three layers: systems, video, and audio [24–26]. The systems layer supports synchronization and interleaving of multiple compressed streams, buffer initialization and management, and time identification. For video and audio, the information is organized into access units, each representing a fundamental unit of encoding; for example, in video, an access unit will usually be a complete encoded video frame. The audio and the video layers define the syntax and semantics of the corresponding  Elementary Streams (ESs). An ES is the output of an MPEG encoder and typically contains compressed digital video, compressed digital audio, digital data, and digital control data. The information corresponds to an access unit (a fundamental unit of encoding), such as a video frame. The compression is achieved using the DCT. Each ES is in turn an input to an MPEG-2 processor that accumulates the data into a stream of PES packets. A PES typically contains an integral number of ESs. Figure A4.1 shows both the multiplex structure and the Protocol Data Unit (PDU) format. A PES packet may be a fixed- or variable-sized block, with up to 65,536 octets per block and includes a 6-byte protocol header.

Combining of Packetized Elementary Streams (PES) into a TS.

PES and TS multiplexing.

As seen in the figure, and more directly in Fig. A4.2, PESs are then mapped to Transport Stream (TS) unit(s). Each MPEG-2 TS packet carries 184 octets of payload data prefixed by a 4-octet (32 bit) header (the resulting 188-byte packet size was originally chosen for compatibility with Asynchronous Transfer Mode (ATM systems). These packets are the basic unit of data in a TS. They consist of a sync byte (0 × 47), followed by flags and a 13-bit Packet Identifier (PID5). This is followed by other (some optional) transport fields; the rest of the packet consists of the payload. Figure A4.3 connects the PES and TS concepts together.

A sequence of PESs leads to a sequence of uniform TS packets.

The PID is a 13-bit field that is used to uniquely identify the stream to which the packet belongs (e.g., PES packets corresponding to an ES) generated by the multiplexer. Each MPEG-2 TS channel is uniquely identified by the PID value carried in the header of fixed length MPEG-2 TS packets. The PID allows the receiver to identify the stream to which each received packet belongs; effectively, it allows the receiver to accept or reject PES packets at a high level without burdening the receiver with extensive processing. Often one sends only one PES (or a part of a single PES) in a TS packet (in some cases, however, a given PES packet may span several TS packets so that the majority of TS packets contain continuation data in their payloads). Each PID contains specific video, audio or data information. Programs are groups of one or more PID streams that are related to each other. For example, a TS used in IPTV could contain five programs, to represent five video channels. Assume that each channel consists of one video stream, one or two audio streams, and metadata. A receiver wishing to
tune to a particular “channel” has to decode the payload of the PIDs associated with its program. It can discard the contents of all other PIDs. The number of TS logical channels is limited to 8192, some of which are reserved; unreserved TS logical channels may be use to carry audio, video, IP datagrams, or other data. Examples of systems using MPEG-2 include the DVB and Advanced Television Systems Committee (ATSC) Standards for Digital Television.

Note 1: Ultimately an IPTV stream consists of packets of fixed size. MPEG (specifically MPEG-4) packets are aggregated into an IP packet then and the IP packet is transmitted using IP Multicast methods. MPEG TS are then typically encapsulated in the UDP and then in IP. In turn, and (only) for interworking with existing MPEG-2 systems already deployed (e.g., satellite systems and associated ground equipment supporting DTH), this IP packet needs further encapsulation, as discussed later. Note that traditional MPEG-2 approaches make use of the PID to identify content, whereas in IPTV applications, the IP Multicast address is used to identify the content; also, the latest IPTV systems make use of MPEG-4-coded PESs.

Note 2: The MPEG-2 standard defines two ways for multiplexing different elementary stream types: (i) Program Stream (PS) and (ii) Transport Stream (TS).

  • An MPEG-2 PS is principally intended for storage and retrieval from storage media. It supports grouping of video, audio, and data ESs that have a common time base. Each PS consists of only one content (TV) program. The PS is used in error-free environments; for example, DVDs use the MPEG-2 PS. A PS is a group of tightly coupled PES packets referenced to the same time base.
  • An MPEG-2 TS combines multiple PESs (that may or may not have common time base) into a single stream and multiplexes these PESs into one stream, along with information for synchronizing between them. At the same time the TS segments the PES into the smaller fixed-size TS packets. An entire video frame may be mapped in one PES packet. PES headers distinguish PES packets of various streams and also contain time stamp information. PESs are generated by the packetization process; the payload consists of the data bytes taken sequentially from the original ES. A TS may correspond to a single TV program; this type of TS is normally called a Single Program Transport Stream (SPTS). In most cases, one or more SPTS streams are combined to form a Multiple Program Transport Stream (MPTS). This larger aggregate also contains the control information (Program Specific Information or PSI) [27].

 

DVB-H

There is interest in the industry in delivering 3DTV services to mobile phones. It is perceived that simple lenticular screens can work well in this context and that the bandwidth (even though always at a premium in mobile applications) would not be too onerous overall; even assuming a model with two independent streams being delivered, it would double the bandwidth to 2 × 384 kbps or 2 × 512 kbps and the use of spatial compression (which should not be such a “big” compromise here) would be handled at the traditional data rate, 384 kbps or 512 kbps.

DVB-H, as noted in Table 4.2, is a DVB specification that deals with approaches and technologies to deliver commercial-grade medium-quality real-time linear and on-demand video content to handheld, battery-powered devices such as mobile telephones and PDAs (Personal Digital Assistants). IP Multicast is typically employed to support DVB-H.

DVB-H2 addresses the requirements for reliable, high-speed, high–data rate reception for a number of mobile applications including real-time video to handheld devices. DVB-H systems typically make use of IP Multicast. DVB-H is generating significant interest in the broadcast and telecommunications worlds, and DVB-H services are expected to start at this time. The DVB-H standards have been standardized through ETSI.

ETSI EN 302 304 “Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)” is an extension of the DVB-T standard. Additional features have been added to support handheld and mobile reception. Lower
power consumption for mobile terminals and secured reception in the mobility environments are key features of the standard. It is meant for IP-based wireless services. DVB-H can share the DVB-T MUX with MPEG-2/MPEG-4 services,
so it can be part of the IPTV infrastructure described in the previous chapter, except that lower bitrates are used for transmission (typically in the 384-kbps range). DVB-H was published as ETSI Standard in 2004 as an umbrella standard
defining how to combine the existing (now updated) ETSI standards to form the DVB-H system (Fig. 4.11).

DVB-H is based on DVB-T, a standard for digital transmission of terrestrial over-the-air TV signals. When DVB-T was first published in 1997, it was not designed to target mobile receivers. However, DVB-T mobile services have been launched in a number of countries. Indeed, with the advent of diversity antenna receivers, services that target fixed reception can now largely be received on the move as well. DVB-T is deployed in more than 50 countries. Yet, a new standard was sought, namely, DVB-H.

Despite the success of mobile DVB-T reception, the major concern with any handheld device is that of battery life. The current and projected power consumption of DVB-T front-ends is too high to support handheld receivers that are
expected to last from one to several days on a single charge. The other major requirements for DVB-H were an ability to receive 15 Mbps in an 8-MHz channel and in a wide area Single Frequency Network (SFN) at high speed. These requirements were drawn up after much debate and with an eye on emerging convergence devices providing video services and other broadcast data services to 2.5G and 3G handheld devices. Furthermore, all this should be possible while

DVB-H Framework.

Block-level view of a DVB-H network.

maintaining maximum compatibility with existing DVB-T networks and systems. Figure 4.12 depicts a block-level view of a DVB-H network.

In order to meet these requirements, the newly developed DVB-H specification includes the capabilities discussed next.

  • Time-Slicing: Rather than continuous data transmission as in DVB-T, DVBH employs a mechanism where bursts of data are received at a time—a so-called IP datacast carousel. This means that the receiver is inactive for much of the time, and can thus, by means of clever control signaling, be “switched off.” The result is a power saving of about 90% and more in some cases.
  • “4-K Mode”: With the addition of a 4-K mode with 3409 active carriers, DVB-H benefits from the compromise between the high-speed small-area SFN capability of 2-K DVB-T and the lower speed but larger area SFN of 8-K DVB-T. In addition, with the aid of enhanced in-depth interleavers in the 2-K and 4-K modes, DVB-H has even better immunity to ignition interference.
  • Multiprotocol Encapsulation–Forward Error Correction (MPE-FEC): The addition of an optional, multiplexer level, FEC scheme means that DVB-H transmissions can be even more robust. This is advantageous when considering
    the hostile environments and poor (but fashionable) antenna designs typical of handheld receivers.

Like DVB-T, DVB-H can be used in 6-, 7-, and 8-MHz channel environments. However, a 5-MHz option is also specified for use in non-broadcast environments. A key initial requirement, and a significant feature of DVB-H, is that it can coexist
with DVB-T in the same multiplex. Thus, an operator can choose to have two DVB-T services and one DVB-H service in the same overall DVB-T multiplex.

Broadcasting is an efficient way of reaching many users with a single (configurable) service. DVB-H combines broadcasting with a set of measures to ensure that the target receivers can operate from a battery and on the move, and is thus an ideal companion to 3G telecommunications, offering symmetrical and asymmetrical bidirectional multimedia services.

DVB-H trials have been conducted in recent years in Germany, Finland, and the United States. Such trials help frequency planning and improve understanding of the complex issue of interoperability with telecommunications networks and
services. However, to date at least in the United States, there has been limited interest (and success) in the use of DVB-H to deliver video to hand-held devices. Providers have tended to use proprietary protocols.

Proponents have suggested the use of DVB-H for delivery of 3DTV to mobile devices. Some make the claim that wireless 3DTV may be introduced at an early point because of the tendency of wireless operators to feature new applications
earlier than traditional carriers. While this may be true in some parts of the world—perhaps mostly driven by the regulatory environment favoring wireless in some countries, by the inertia of the wireline operators, and by the relative
ease with which “towers are put up”—we remain of the opinion that the spectrum limitations and the limited QoE of a cellular 3D interaction do not make cellular 3D such a financially compelling business case for the wireless operators to
induce them to introduce the service “over night.”

 

DVB

DVB is a consortium of over 300 companies in the fields of broadcasting and manufacturing that work cooperatively to establish common international standards for digital broadcasting. DVB-generated standards have become the leading
international standards, commonly referred to as “DVB,” and the accepted choice for technologies that enable an efficient, cost-effective, high-quality, and interoperable digital broadcasting. The DVB standards for digital television have been adopted in the United Kingdom, across mainland Europe, in the Middle East, South America, and in Australasia. DBV standards are used for DTH satellite transmission 22 (and also for terrestrial and cable transmission).

The DVB standards are published by a Joint Technical Committee (JTC) of European Telecommunications Standards Institute (ETSI), European Committee for Electrotechnical Standardization (Comit´e Europ´een de Normalisation Electrotechnique—CENELEC), and European Broadcasting Union (EBU). DVB produces specifications that are subsequently standardized in one of the European statutory standardization bodies. They cover the following DTV-related areas:

  • conditional access,
  • content protection copy management,
  • interactivity,
  • interfacing,
  • IP,
  • measurement,
  • middleware,
  • multiplexing,
  • source coding,
  • subtitling,
  • transmission.

Standards have emerged in the past 10 years for defining the physical layer and data link layer of a distribution system, as follows:

  • satellite video distribution (DVB-S and DVB-S2),
  • cable video distribution (DVB-C),
  • terrestrial television video distribution (DVB-T),
  • terrestrial television for handheld mobile devices (DVB-H).

Distribution systems differ mainly in the modulation schemes used (because of specific technical constraints):

  • DVB-S (SHF) employs QPSK (Quadrature Phase-Shift Keying).
  • DVB-S2 employs QPSK, 8PSK (Phase-Shift Keying), 16APSK (Asymmetric Phase-Shift Keying) or 32APSK; 8PSK is the most common at this time (it supports a 30-megasymbols pre-satellite transponder and provides a usable rate in the 75 Mbps range, or about 25 SD-equivalent MPEG-4 video channels).
  • DVB-C (VHF/UHF) employs QAM (Quadrature Amplitude Moderation): 64-QAM or 256-QAM.
  • DVB-T (VHF/UHF) employs 16-QAM or 64-QAM (or QPSK) along with COFDM (Coded Orthogonal Frequency Division Multiplexing).
  • DVB-H: refer to the next section.

Because these systems have been widely deployed, especially in Europe, they may well play a role in the near-term 3DTV services. IPTV also makes use of a number of these standards, particularly when making use of satellite links (an architecture that has emerged is to use satellite links to provide signals to various geographically distributed headends, which then distribute these signals terrestrially to a small region using the telco IP network—these headends act as rendezvous point in the IP Multicast infrastructure). Hence, in the reasonable assumption that IPTV will play a role in 3DTV, these specifications will also be considered for 3DTV in that context.

As implied above, transmission is a key area of activity for DVB. See Table 4.2 for some of the key transmission specifications.

In particular, EN 300 421 V1.1.2 (1997–2008) describes the modulation and channel coding system for satellite digital multiprogram television (TV)/HDTV services to be used for primary and secondary distribution in Fixed Satellite Service (FSS) and Broadcast Satellite Service (BSS) bands. This specification is also known as DVB-S. The system is intended to provide DTH services for consumer IRD, as well as cable television headend stations with a likelihood
of remodulation. The system is defined as the functional block of equipment performing the adaptation of the baseband TV signals, from the output of the MPEG-2 transport multiplexer (ISO/IEC DIS 13818-1) to the satellite channel characteristics. The following processes are applied to the data stream:

  • transport multiplex adaptation and randomization for energy dispersal;
  • outer coding (i.e., Reed–Solomon);
  • convolutional interleaving;
  • inner coding (i.e., punctured convolutional code);
  • baseband shaping for modulation;
  • modulation.

DVB-S/DVB-S2 as well as the other transmission systems could be used to deliver 3DTV. As seen in Fig. 4.9, MPEG information is packed into PESs (Packetized Elementary Streams), which are then mapped to TSs that are then handled by the DVB adaptation. The system is directly compatible with MPEG- 2 coded TV signals. The modem transmission frame is synchronous with the MPEG-2 multiplex transport packets. Appropriate adaptation to the signal formats (e.g., MVC ISO/IEC 14496-10:2008 Amendment 1 and ITU-T Recommendation H.264, the extension of AVC) will have to be made, but this kind of adaptation has recently been defined in the context of IPTV to carry MPEG-4 streams over an MPEG-2 infrastructure (Fig. 4.10).

Key DVB Transmission Specifications

Key DVB Transmission Specifications

For Digital Rights Management (DRM), the DVB Project–developed Digital Video Broadcast Conditional Access (DVB-CA) defines a Digital Video Broadcast Common Scrambling Algorithm (DVB-CSA) and a Digital Video Broadcast Common Interface (DVB-CI) for accessing scrambled content:

  • DVB system providers develop their proprietary conditional access systems within these specifications;
  • DVB transports include metadata called service information (DVB-SI i.e., Digital Video Broadcast Service Information) that links the various Elementary Streams (ESs) into coherent programs and provides human-readable descriptions for electronic program guides.

Functional block diagram of DVB-S.

Mapping of MPEG-2/MPEG-4 to DVB/DVB-S2 systems.