ONLINE EXCLUSIVE: Bits-N-Bytes: Running Code at IETF

The first IETF Bits-N-Bytes took place in the summer of 2012. The Bits-N-Bytes concept, however, has deep roots in the technical and operational communities. In fact, events similar to Bits-N-Bytes were a part of the North American Network Operator’s Group meetings as early as 2009.

The success of Bits-N-Bytes first is attributed to the support of the IETF, but the participants and sponsors are the true heart and soul of this event. Participants and sponsors spend countless hours in preparation during the months leading up to the IETF meeting—and even more time onsite during the event—to ensure that the demonstrations and exhibits of IETF-developed technology are both interesting and relevant. Illustrating IETF technology in real-world scenarios is an invaluable offering to the IETF community.

Another tremendous benefit of the Bits-N-Bytes events is the one-of-a-kind opportunity for live collaboration in the development of prototypes and proofs of concept. There is no other place where the men and women who specify Internet protocols can collaborate hands-on with protocol implementers and those who deploy the overarching technologies.

In just a few short years, the event’s exhibits, demonstrations, and underlying protocols have greatly varied. In the earliest days, IPv6-enabled broadband and home-networking-technology demonstrations showed how state-of-the-art broadband-connected homes could leverage IPv6. The same technology in more recent meetings has demonstrated how it can act as a foundation for a host of future innovations. Similarly, a multitude of IPv6 transition technologies have been showcased, including NAT64 and DNS64. Demonstrating these technologies to such a diverse community has both shown the community their potential to impact user experiences and conveyed what options are viable as IPv4 nears worldwide depletion and IPv6 adoption matures.

Software Defined Networking (SDN) and Voice over IPv6 are also making their appearances—similarly illustrating a future in which IPv6 acts as a foundation for all Internet-enabled services. As networks become more complicated, SDN support and innovation become more critical to the effective management of networks and the successful deployment of advanced consumer products and services. Voice over IPv6 and the ability to support communications among devices using dissimilar versions of the Internet protocol enables communications beyond traditional interpretations. Further, advancements in core Internet protocol networking, specifically those built around IPv6, offer a glimmer of what the future of networking will resemble.

Following is a brief description of some of the exhibits from the past two years of Bits-N-Bytes.

Cable, IPv6, and the Broadband Home

The earliest Bits-N-Bytes exhibited production implementations of IPv6 for cable broadband networks. At the core of cable broadband is DOCSIS®. DOCSIS 3.0-capable cable modem termination systems (CMTS) and cable modems (CMs) were used to demonstrate production-grade implementations of dual-stack-enabled and IPv6-only cable broadband. Demonstrations focused largely on native IPv6 implementations in lieu of various tunneling or encapsulations approaches. While these approaches are valuable first steps toward IPv6 deployment, most adopters agree that native IPv6 needs to be deployed to properly enable IPv6 support for next-generation services.

An often overlooked element of any broadband deployment is the back office. Back-office elements, such as provisioning, are key enablers for most of the new technologies offered to today’s broadband customers. IPv6-enabled home networking is no different. Back-office systems implement support for IETF-developed protocols, including DHCPv6 (RFC 3315) and DHCPv6 prefix delegation (RFC 3633), as well as the core IPv6 protocols (RFC 4861, RFC 4862) found in CMTSs and CMs. Cable eRouters also leverage many of the open standards developed within the IETF, including DHCPv6 and DHCPv6 prefix delegation. The cable community, among others, has leveraged IETF-developed IPv6 specifications to catapult adoption to new highs—cable eRouters are enablers for next-generation home networking, including work in the IETF’s HOMENET working group. Support for prefix delegation and other planned specifications will enable cable-broadband technology to further fuel home networking innovation.

IPv6 Transition Technologies

There is no escaping the fact that IPv4 will fully deplete. Those of us working feverishly to deploy IPv6 recognize that technologies need to be deployed now to enable Internet operation during the transition to IPv6. As this transition progresses, technologies needed for support of the same are being developed and deployed. One interesting example is the combination of NAT64 and DNS64.

NAT64 is implemented over an IPv6 access network and allows a service provider to reclaim precious IPv4 address space and lay the foundation for an all-IPv6 infrastructure. IPv6 packets originating from clients are translated into IPv4 packets by the CGN device implementing NAT64. Source addresses and ports are dynamically translated between IPv6 and IPv4, thereby creating a stateful binding in the CGN device between the IPv6 and IPv4 transport addresses. All facets of the packet header including IP header, TCP/UDP header, and ICMP parameters are translated, providing a seamless, transparent connectivity construct from IPv6 client to IPv4 server.

A necessary counterpart to NAT64 translation is DNS64 functionality. The IPv6 client initiates communication with a host using its fully qualified domain name (FQDN). This creates an AAAA resource request (RR) that is specific to IPv6 and not directly compatible with IPv4-only DNS. The DNS64 implementation translates the AAAA request to an A request, enabling the DNS server to respond with an IPv4 address. DNS64 then creates a synthetic AAAA record by appending the 32-bit IPv4 address to the configured NAT64 prefix and relays it to the requesting client. The client now has an IPv6 destination address towards the NAT64 CGN device that corresponds with the desired FQDN.

NAT64/DNS64 is an excellent foundation for IPv6 transition in that it enables providers to incrementally deploy IPv6. As more IPv6 content becomes available, DNS64 can bypass the NAT64 component by providing the requesting node with the AAAA record for a particular FQDN, thus providing a simple and controlled migration from translated to native IPv6 services.

Traffic Steering Using RR+ and PCE+

MPLS and IP networking are two types of widely deployed network technologies. Routing Reflect Plus (RR+) technology can be introduced to realize traffic steering in a traditional IP network; Path Computation Element Plus (PCE+) can be introduced to realize traffic steering in a MPLS network.

In an IP network, setting and adjusting the IGP metrics is the most practical method to control traffic and optimize network performance. Typically, both the Interior Gateway Protocol (IGP) and Border Gateway Protocol (BGP) are deployed to forward traffic from one domain to another. The IGP is responsible for the internal routing and connectivity; the BGP is responsible for interdomain routing. Interdomain traffic is forwarded based on the BGP routes—when the traffic enters a specific domain, the BGP routes depend on the IGP routes to reach the next BGP hop router. Traffic follows the IGP routes to reach Autonomous System Border Routers (ASBRs) and then is forwarded to next domain. In this way, IGP topology, link metric, and related policies determine traffic paths within a domain.

The following problems can arise when setting and adjusting IGP metrics

• Routing considers only the destination, not the source, and cannot steer traffic per user traffic flow and is based on its own IGP metric and local information.
• Routing design and adjustment is based on an estimated/projected traffic model with multiple nodes involved, resulting in a complex and error-prone configuration.
• IGP metric adjustment is the primary method, but setting or changing the IGP metric is sensitive and changes can have a significant impact on the entire network.

In the draft of draft-chen-idr-rr-based-traffic-steering-usecase, a method called RR+ using enhanced Route Reflect (RR) is introduced to steer traffic in IP networks. It uses a centralized computation for routes, and uses BGP to control the router’s RIB. RR+ enhances the RR with computation based on IGP and eBGP metric, computation based on source and destination, and computation considering both the link’s and the service’s bandwidth requirements.

In MPLS networks, although the traffic engineering technology already exists, it too has some problems:

• Independent calculation on each node (no global view of topology)
• Bandwidth allocation based on peak flow (waste of resources)
• No integration of fragmented resources (waste of resources)
• Decentralized policy control (no synergies)

In the draft of draft-zhao-pce-central-controller-user-cases, a new method is introduced that uses enhanced a Path Computation Element called PCE+ as SDN controller. One of the main functionalities of PCE+ is to steer the traffic in MPLS networks. It uses expanded Path Computation Element Protocol (PCEP) to control Label Switched Path (LSP) setup, while the signaling protocol is eliminated from the routers.

PCE+ simplifies the network operation and reduces capital and operational expenditures by using the following enhanced mechanisms:

• Adjusting the existing LSPs when a new high-privileged LSP must be provisioned but the bandwidth resource is not enough
• Integrating the fragmented resources to maximize network utilization
• Allocating bandwidth based on real-time traffic to improve link utilization and reduce transport cost
• Automatically adjusting the traffic according to traffic privilege when congestion occurs

Figures 1 and 2 show the topologies used for the Bits-N-Bytes demonstration. The demonstration illustrated how PCE+ integrated the fragmented resources to provide maximum network utilization.

In figure 1, there is a service with 100M bandwidth; the LSP carrying the service uses the path PE1->PE2. In figure 2, the bandwidth must be increased to 150M, but the link of PE1-PE2 cannot carry the service because its bandwidth is limited to 100M. Without the service being aware of the change, the PCE+ controller can set up a new LSP with an additional 50M of bandwidth to carry the traffic.

Traffic steering is a mandatory requirement in Data Center Interconnect (DCI) and IP CORE. RR+ and PCE+ satisfy that requirement by leveraging traditional protocols—they’re practical solutions for traditional networks seeking to migrate to an advanced SDN network.

OpenV6: A Unified IPv4/IPv6 Transition Solution Based on Open API and Unified Forwarding Plane

The transition from IPv4 to IPv6 is expected to be slow and complicated. In most cases, transition cannot be completed in one step—operators need to choose the proper transition technology for different stages and transition from one technology to the next as adoption evolves. Some operators will need to deploy two or more transition technologies in their networks.

OpenV6 is an open platform for the development and deployment of IPv6 transition technologies. A prototype of OpenV6 was demonstrated at the IETF 88 Bits-N-Bites event. During the demonstration, independent address pools and IPv6 addresses and prefixes were configured for each transition technology while Internet access via both IPv4 and IPv6 was available to visitors. Visitors could accesshttp://ipv6-test.com/ via their tablets or mobile phones, which displayed their IPv4 and IPv6 addresses. Flexible switching among different transition technologies was also demonstrated.

OpenV6 employs the concept of control and forwarding separation, incorporating a unified forwarding plane and open API for any transition application, including third-party implementation (figure 3).

The unified data plane can support the IP-in-IP (including IPv4-in-IPv6, IPv6-in-IPv4, etc.) tunnels and NAT functions required by most transition technology. This prototype aims to support most of the common features required to support an IPv6 transition. By combining these features, most of the existing transition technologies can be supported, as can future transition technologies. The forwarding plane can be flow-based (like OpenFlow or OpenvSwitch) or it can be provided by a commercial router with ASIC or another acceleration component with a set of common programming API.

IPv6 transition and third-party applications can send instructions to the data plane via a common northbound API. The demonstrated prototype currently supports transition technologies such as Dual-Stack, DS-Lite, MAP, LW4over6, NAT64, and NAT44.

Its architecture allows for the parallel running of multiple transition applications and easy switching from one application either to another or to a transition technology with different configurations.

To support new types of transition technologies, one must only develop new software applications—there is no need to modify the data plane.

OpenV6 includes a management interface, which enables administrators to configure transition applications (e.g., tunnel endpoint, NAT address pool, etc.) and to stop or start transition applications. The standardization of the configuration interface is ongoing.

OpenV6 architecture also supports centralized management of IP address pools, rather than independent address pools for each transition technology or network device. This can reduce the difficulty of IP address planning and management and enable a more efficient use of IP addresses.

Voice over IPv6: CSCF Control IMS Voice over IPv6 solution

From an architecture perspective, IMS is flat. Unlike TDM-based terminals, every IMS terminal must have IP connectivity to function properly. To increase performance or improve flexibility, carriers may allocate different IP addresses for different services. eDVAs most likely have different IP addresses for VoIP and Internet. Also consider the headache of NAT traversal—public IP addresses are almost always preferred over the use of private address space. But as IPv4 address resources are running out, we must evolve voice-network architecture to be IPv6 capable in an incremental manner.

There are several factors to consider before choosing how to do this:

1. Gradually increasing the number of IPv6 terminals to avoid heavy costs at the onset. It is important to implement a Voice-over-IPv6-capable network to support a large number of IPv4 terminals with a small number of IPv6 terminals at the initial stage.
2. An IP-conversion strategy for both on-net and off-net calls. Most voice calls are still on-net to off-net. As IP networks become more common, the ratio of on-net to on-net calls will increase.
3. Investment protection. Eventually, IPv4 terminals will all be replaced or upgraded to support IPv6 terminals, and IPv4/IPv6 conversion will no longer be necessary. We must consider how to reuse our old equipment.

IETF Bits-N-Bytes demonstrations illustrated the following Voice over IPv6 solution benefits:

1. IPv4 to IPv6 conversion is done only when necessary, meaning conversion occurs only between two terminals with different IPv4/IPv6 types.
2. TrGW resources are fully shared by P-CSCF and I-BCF through H.248 interfaces, which benefits even when off-net traffic declines—TrGW resources are still fully used for IPv4/IPv6 conversion for on-net-on-net calls.
3. IBCF and TrGW are capable to evolve to I-SBC when IPv4/v6 conversion is not required anymore.

For on-net calls, PCSCF control TrGW performs IPv4/IPv6 conversion when necessary (e.g., two peer terminals have different IPv4/IPv6 types). For on-net with off-net calls, IBCF control TrGW performs IP conversion when necessary (e.g., when the peer network has different IPv4/IPv6 types of IMS terminals).

When P-CSCF at the terminated side identifies that the caller IP type is different than that of the destination, it adds the TrGW into the media path to enable IPv4/IPv6 conversion. P-CSCF SIP ALG function then changes the corresponding IPv6 header to IPv4 in INVITE messages. After all terminals and the network move to IPv6, I-BCF and TrGW repurpose to I-SBC.

The VoIPv6 demonstration showed basic IPv4 and IPv6 voice client interoperability, including:

IPv4 and IPv6 clients registration

• IPv4 client registration on IMS
• IPv6 client registration on IMS

Call flow

• IPv4 client call IPv6 client
• IPv6 client call IPv4 client

Announcement

• IPv4 voice call announcement
• Pv6 voice call announcement

Further, the following implementations illustrated innovative ways that the transition to IPv6-only voice can be simplified:

Mechanism of dynamic insert TrGW for IPv4/IPv6 conversion

• Unlike SBC static conversion, the Huawei IMS dynamically inserts TrGW when needed
• Less conversion, higher performance

SIP ALG separated from TrGW makes TrGW shared in the beginning phase of deployment, which reduces costs

• Choose the transport protocol for signaling path
• Based on the attribute of the address of next hope returned by DNS, choose the correct transport protocol

Smooth revolution to the final all IPv6 network

Summary

Over the past two years, the Bits-n-Bytes event has offered impressive displays of Internet-based technology—all developed under the umbrella of the IETF. At the convergence of thousands of meeting participants, this unique event helps key players understand how their collective and collaborative efforts define the Internet and further the innovation that enables open communications around the globe. And there is more to come as the Internet continues to evolve and change! You can support the IETF’s Bits-n-Bytes by bringing your ideas and innovation to the floor. We look forward to seeing you at the next event.

Acknowledgements

We would like to acknowledge David Fang, Robin Li, Yizhou Li, Qiong Sun, Tom Taylor, and Chongfeng Xie for their valuable contributions to Bits-N-Bytes and to this article.

Additional References

1. Sun Q., Liu W., Zhou C., Problem Statement for Openv6 Scheme, draft-sun-openv6-problem-statement-00, October 2013
2. Liu W., Zhou C., Sun Q., Openv6 Architecture for IPv6 Deployment, draft-liu-openv6-architecture-00, October 2013
3. Xie C., Sun Q., Zhou C., Address Management for IPv6 Transition, draft-sun-openv6-address-pool-management-00, October 2013
4. Zhou C., Sun Q., A YANG Data Model for Open IPv6 Transition, draft-zhou-netmod-openv6-transition-cfg-00, October 2013
5. Duran A., Droms R., Woodyatt J., Lee Y., Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion, RFC6333, August 2011
6. Troan O., Dec W., Li X., Bao C., Matsushima S., Murakami T., Taylor T., Mapping of Address and Port with Encapsulation (MAP), draft-ietf-softwire-map-08, August 2013
7. Cui Y., Sun Q., Boucadair M., Tsou T., Lee Y., Farrer I., Lightweight 4over6: An Extension to the DS-Lite Architecture, draft-ietf-softwire-lw4over6-03, November 2013
8. Bagnulo M., Matthews P., van Beijnum I., Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, RFC6146, April 2011
9. Srisuresh P., Egevang K., Traditional IP Network Address Translator (Traditional NAT), RFC3022, January 2011