[ieee milcom 2006 - washington, dc, usa (2006.10.23-2006.10.25)] milcom 2006 - global broadcast...

Global Broadcast Service (GBS) Integration with IPv6A Pilot Implementation

Bruce BennettDefense Information Systems Agency

Falls Church, Virginia

Deanna Jing ZhangKathir RamaswamiBooz Allen HamiltonHerndon, Virginia

ABSTRACT

The Office of the Assistant Secretary of Defense forNetworks and Information Integration (OASD-NII)established a mandate in 2003 that all DoD networks beIPv6 capable by the year 2008. In support of thismandate, the OASD-NII authorized the formation ofIPv6Pilots in Operational Networks to demonstrate thefunctional capabilities ofIPv6 and help build expertise fora DoD-wide transition. The Pilots mustfulfill defined JointStaff operational criteria and three Milestone Objectives(MO) for a complete IPv6 transition.

The Global Broadcast Service (GBS) is a satellitecommunications program which provides a worldwide,high bandwidth, one-way transmission of classified andunclassified video and files to warfighters. In support ofthe OASD-NII mandate and the DoD's Network-centricvisions, the GBS Joint Program Office (GBS-JPO) and theDefense Information Systems Agency (DISA) have beenjointly investigating the transition of GBS to IPv6. GBS-JPO and DISA jointly submitted a nomination packageand have obtained approval for participation in the DoDIPv6 Pilot.

GBS-JPO and DISA have established a simulated satellitetestbed on which all tests will be performed. The testingwill establish the feasibility of conducting live SATCOMdemonstrations to fulfill MO] and M02. M02 willadditionally utilize the DATMS-U and the DefenseResearch Engineering Network (DREN) for cross domaintesting. This paper will discuss the different phases of theGBS Pilot, the IPv4/IPv6 transition technologies involved,the interoperability with High Assurance Internet ProtocolEncryptors (HAIPEs), and the simulcasting of IPv4 andIPv6. The results of the GBS IPv6 pilot will serve toprovide a reference architecture and requirementspecifications for the IPv6 transition of the GBS networkinfrastructure.

INTRODUCTION

GBS is a satellite communications program modeled on

the highly successful commercial Digital Video Broadcast- Satellite (DVB-S) platform. It provides a worldwide,high bandwidth, one-way transmission of classified andunclassified video, imagery, and other files to support jointmilitary forces in garrison, in transit, and in theater. GBSbroadcasts over government owned Ka-Band UHF Follow-On satellites F8, F9, FIO, and a combination ofcommercially leased Ku-Band geosynchronous satellites.Video and files destined for broadcast to GBS end-usersare initially collected, organized, queued, and transmittedto satellite uplink facilities via GBS Satellite BroadcastManagers (SBM). The three GBS Satellite uplinks are

located in Norfolk (VA), Wahiawa (HI), and Sigonella(Italy). Information sources are directly connected to eachSatellite Broadcast Manager through high-speed terrestrialnetworks. This allows for rapid and flexible datadissemination from the sources to fixed, transportable,shipboard, sub-surface, and field-capable GBS ReceiveSuites (RS) as necessary. The GBS RS receive thebroadcast content, process it, and disseminate it over

backend local area networks and tactical communicationsnetworks.

Over the past several years, the GBS architecture hastransitioned from Asynchronous Transfer Mode (ATM)technology to an Internet Protocol (IP) technology toenhance a multitude of features. Data transport becamemore efficient in conjunction with encapsulation using theDVB-S standard. Transitioning to an IP-based systemenabled compatibility between GBS network componentsand Commercial Off The Shelf (COTS) marketplace,allowing the architecture to become more modular andeconomically viable. This modularity extended to theReceive Suite components as well, which helped shrinkthe form factor, ease system installation, and decreaseoperation complexity. IP proved to be fundamental forinteroperability across the DoD's Global Information Grid

1 of 7

(GIG) by being able to integrate sensors, weapons, andplatforms with their respective user communities. GBScurrently implements Internet Protocol version 4 (IPv4) inits entire end-to-end architecture. However, IPv4 is notcapable of supporting the DoD's next generation net-centric operations or their warfare policies. These policiesenvision robust, secure, interconnected and interoperablenetworks that can be geographically dispersed yetsynchronized in function. Next-generation IPv6 networkswill provide warfighters, policy-makers, and intelligenceusers the ability to share knowledge across domains in atruly collaborative capacity to increase efficiency andutilize all available resources in achieving objectives.

IPV6 OPERATIONAL IMPACTS

Deploying IPv6 within the GBS network will providesignificant operational benefits to disadvantagedwarfighters, especially when coupled with other innovativetechnologies such as next generation wireless networksand two way SATCOM. By providing the infrastructurefor future IPv6 advanced applications, GBS can greatlyenhance services to end users. A description of the keyadvantages of IPv6 for GBS is outlined below.

Wireless GBS extensions. IPv6 is the key to tacticalwireless extensions and mobile networking (end-to-endIP). Integrating IPv6 native mobile routing capability withnext generation wireless transport technologies such asDVB-T/H/WiMAX will enable GBS to provide missioncritical information to the tactical edge. Figure 1 depictsan illustration of the integration between IPv6 wirelessnetwork and the GBS SATCOM network. This integrationis fundamental to the GIG vision of disseminatinginformation to the warfighter and is critical in takingadvantage of the capabilities of the DVB standards.

Advanced Multicast. The advanced multicast features ofIPv6 can enhance the distribution of video content. IPv6multicast has been key to the development of IPTV. As aservice provider, GBS has been the primary multicastnetwork for the DISN, distributing information to forwarddeployed warfighters worldwide. Because GBS today isthe only DoD system that is actively utilizing IP multicaston a large scale basis, GBS must be at the forefront oftransitioning to an IPv6 capable infrastructure in order tosupport advanced future multicast applications. In theevent that GBS adopts and employs the new Digital VideoBroadcast - Return Channel over Satellite (DVB-RCS)technology, IPv6 multicast will provide end users withnew video services, such as video-on-demand and videoteleconferencing.

g :. g 11(4! .l4 [e] IUk.. . iUYJ I.. g .'ju . [.i mu ..'.'L.j

Figure 1. Illustration of GBS IPv6 Mobile TacticalNetwork

Quality of Service (QoS). Integrating the advanced QoScapabilities of IPv6 within the GBS network will enablepriority and preemption for GBS video and filedissemination services. Similar to the Type of Servicefield within IPv4 headers today, the IPv6 traffic class fieldmay be used to set specific precedence or differentiatedservice code. The addition of the 20 bit flow label to theIPv6 header can enable per-flow processing fordifferentiation at the IP layer. Since the flow label iswithin the first octet of the IPv6 header, routers will notneed to open the inner packet to identify the flow.

DOD IPv6 PILOT BACKGROUND

The three Milestone Objectives for the IPv6 Pilot willdemonstrate the operational capabilities of GBS insuccessive stages. Milestone Objective 1 (MO 1) onlypermits testing within a single enclave environment, andthus this transition phase will be conducted entirely withinthe GBS Norfolk Satellite Broadcast Management facility.Within MO1, IPv6 data will be generated and transmittedthrough a satellite transponder string, whose satellitefootprint covers the Norfolk SBM. This data will bereceived with a GBS Receive Suite co-located at theNorfolk SBM. The Pilot Information Assurance (IA)guidance for MO1 states that the MO1 testing must beperformed under a single administrative IA authority. TheGBS Designated Approval Authority (DAA) is under theArmy Strategic Command (ARSTRAT). To ensure thatIPv6 traffic remains completely isolated in a single GBSenclave at the Norfolk SBM, strict access controls will beimplemented on all router interfaces. Permission tocomplete MO1 testing was granted by the DoD IPv6Transition Office (DITO) on September 30th, 2005.

2 of 7

Milestone Objective 2 (MO2) permits IPv6 testingbetween enclaves, but only under a single DoD domain.The same architecture will be maintained for M02 as willbe for MOI, with the additional integration of theDATMS-U and Defense Research Engineering Network(DREN) connection at the receive suite. The broadcastcontent will be received and multicasted over the DREN tovarious IPv6 peer sites. The peer site will be responsiblefor determining the successful reception of the IPv6broadcast and verifying complete cross-enclave testingcapability. The target date for M02 is September 30th,2006.

Milestone Objective 3 (MO3) is the culmination of all theinvestigations into the IPv6 protocol, both from a policyand technical standpoint. MO3 will allow IPv6 traffic toachieve full parity with IPv4, to traverse any operationalDoD network, and to interface with non-DoD networks.The target date for MO3 is March, 2008.

GBS IPV6 PILOT TECHNICAL OBJECTIVES

The GBS IPv6 Pilot will provide a phased transitionapproach for GBS networks by completing MOI andMO2. In MOI, the GBS IPv6 Pilot will broadcast GBSservices within a single GBS enclave, while in MO2 theseservices will be broadcasted across multiple enclaves tovarious end users. For broadcast testing within bothmilestone objectives, this Pilot will demonstrate video andfile dissemination services using native IPv6 traffic acrossnetwork devices, as well as various IPv6 transitionmechanisms. The GBS IPv6 Pilot will also demonstratethe efficiency of providing imagery, video, and filesthrough simulcasting in IPv6/IPv4 over the GBS satellitenetwork.

GBS transports both classified and Sensitive ButUnclassified (SBU) content, so both IPv6 capable Type Iand Type II encryption must be investigated to ensuresecure communication across the GBS SATCOM network.GBS relies on the use of High Assurance Internet ProtocolEncryption (HAIPE) for the transmission of classifiedinformation. Since next generation IPv6 capable HAIPEs(version 3.0) will not be widely deployed until 2009, GBSmust employ the use of transition mechanisms toovercome this limitation. To continue to support GBSservices, IPv6 manual tunnels will be used to multicaststreaming video, while Network Address Translation -Protocol Translation (NAT-PT) will be implemented todeliver imagery and data files. The interoperability ofthese transition mechanisms with current generationHAIPEs will be demonstrated to verify seamlessintegration of IPv6 into the current GBS network.

SIMULATED OPERATIONAL TESTING

In order to meet the technical objectives outlined in theprevious section, simulated operational testing will becompleted to demonstrate the performance and capabilitiesof implementing dual stacks, manual tunneling, and NAT-PT in a controlled environment. Performance testing willbe conducted to verify the integrity of deploying IPv6within the GBS architecture and validate the impact ofIPv6 on the simulated operational network. Figure 2illustrates the testing architecture of the simulatedoperational setup. The test architecture is composed of aDVB-S transport equipment string that encapsulates andmodulates incoming IP packets onto an RF carrier. Inorder to accurately simulate a SATCOM system, the testsetup will include a Satellite Link Emulator (SLE) andCarrier-to-Noise Generator (CNG). For the Pilot, both aningress and an egress router will be augmented to thecurrent GBS architecture to serve three functions: transportnative IPv6 and IPv4 traffic, tunnel IPv6 traffic via manualtunneling, and implement NAT-PT of IPv6 packets.

The testing of GBS services includes the simulation ofboth the store and forward service and the videodissemination service over the testbed. The store andforward service is composed of Immediate File Delivery(IFD) traffic using the Kencast content delivery engine.Testing of streaming IPv6 multicast video will bedelivered using the Video LAN Codec (VLC).Measurement of performance will be conducted using Ixiaand Spirent traffic generators and analyzers. Performancemetrics that are crucial to video and file disseminationservices will be measured, including latency, jitter, frameloss, and maximum throughput.

Figure 2. Simulated Operational Testing Architecture

In order to test the feasibility of integrating IPv6 transitionmechanisms with current generation HAIPEs, two HAIPEencryptors will be included in this setup. Since manualtunneling of IPv6 packets utilizes protocol 41, testing willbe completed to ensure that the use of protocol 41 does notinhibit HAIPE functionality. The effects of translating aheader from IPv6 to IPv4 on the operation of the HAIPEmust also be investigated, since critical information withinthe header can potentially be lost during this protocol

3 of 7

translation. For the testing of the manual tunneling andNAT-PT, two encryptors will be inserted between theingress and egress routers so that the IPv6 packet will betransparent to the HAIPE.

IPV6 BROADCAST TESTING FOR MOI

During MOI testing, the GBS IPv6 Pilot will demonstrateIPv6 broadcasting over the GBS Galaxy XR satellitetransponder using dual stacks, manual tunneling, andNAT-PT. Since the Galaxy XR is a government-leasedcommercial satellite transponder, the broadcast testing willbe completed using the Ku-band instead of the militaryKa-band. This will not affect the IPv6 network since IPv6is agnostic of the SATCOM transport band. MOIrequirements state that the Pilot must remain in a singleenclave and under a single IA authority. In order to satisfythis requirement, the broadcast demonstrations will besourced from the GBS Norfolk SBM and received usingthe local GBS SBM Receive Suite. Figure 3 illustrates theDVB-S broadcast architecture for transporting IPv6 trafficover the Galaxy XR transponder. The broadcastdemonstration will include GBS services, such as filedelivery and video dissemination with the sameconfiguration as described in the previous section.Performance testing will be completed to assess the impactof deploying IPv6 in the operational GBS environment.The performance metrics that will be captured include,packet loss, jitter, average latency, and maximumthroughput.

Galaxy XR

that IPv6 traffic does not cross any mission-criticalsystems. In addition to the access-lists, a strict IA impactanalysis was completed on the IPv6 broadcast architectureto ensure MO1 testing does not compromise the security ofthe GBS operational network, or impact operationalservices. Based on the results of this analysis and the finaltest architecture, an IA Information Package wascompleted and submitted to the GBS CA and ARSTRATDAA for the Pilot MO1 broadcast testing.

IPv6 BROADCAST TESTING FOR M02

The GBS IPv6 Pilot broadcast demonstration for M02 willinclude GBS one-way services, such as file delivery andvideo dissemination. To demonstrate cross-enclavecommunication, multicast video streams and unicastimagery packets will be disseminated from the DISABTAF facility to the GBS Norfolk SBM using an existingDATMS-U PVC connection. Figure 3 illustrates theDVB-S broadcast test architecture for the M02 cross-enclave demonstrations. At the Norfolk SBM, this IPv6video/file content will be broadcasted over one of theGalaxy XR transponders. A Next Generation ReceiveTerminal (NGRT) Receive Suite will be set up at the DISASkyline facility to receive the content from this IPv6broadcast. Once the content is received at the DISASkyline facility, the data will be routed over the DREN viathe ATDnet to IPv6 peer sites. Some potential DREN peersites are the Army CERDEC, SPAWAR, NRL, or JITC.

In addition to the GBS services, performance testing willbe completed to assess the impact of deploying IPv6within the GBS system to tactical end-user networks. Theperformance metrics that will be captured for M02broadcast demonstrations include frame loss, jitter,average latency, and maximum throughput. Theperformance testing will be measured from the DISABTAF source (across the DATMS-U circuit and theGalaxy XR transponder) to the Receive Suite co-located atthe DISA BTAF facility. Performance measurementsacross the DREN will not be measured since this testingwill require two synchronized test chassis.

Figure 3. GBS Broadcast Architecturefor MO]

In order to meet the IA requirements for MO1, the GBSpilot must ensure that IPv6 packets do not leave the GBSenclave. IPv6 access lists will be installed on both theingress and egress routers within the broadcastarchitecture. As part of the IA requirements, it is critical

4 of 7

[Pv6 Traffic

lPv4 Traffic

k

IPFs Peer Site IPct Peer Site

Figure 4.- GBS Cross Enclave Broadcast Architecture

The main goal of M02 IA requirements is to implement arisk avoidance strategy so that no new risks are introducedto DOD networks outside the participating pilots. In orderto meet this requirement, the GBS IPv6 Pilot architecturewill include IPv6 capable firewalls and Intrusion DetectionSystems (IDS) to ensure network protection. The GBSIPv6 Pilot is required to obtain IA accreditation from theARSTRAT DAA and DISN DAA for M02. The GBSPilot architecture will conform to the six notionalarchitectures for IPv6 testing stipulated in the M02 IAguidance.

1. Enclave Perimeter Device Generic RoutingEncapsulation (GRE) Tunneling

2. Enclave Perimeter Device Virtual Private Network(VPN) Tunnel

3. Enclave Interior Device GRE Tunnel4. Enclave Interior Device VPN Tunnel5. Single Enclave Perimeter Device Dual-Stack6. Dual Enclave Perimeter Devices Dual-Stack

These notional architectures will be used for M02 testingover the DATMS-U circuit between the DISA BTAF andthe GBS Norfolk SBM. The first four architectures will beused at the beginning of M02. To reach M03, GBS IPv6Pilot architecture must meet the final two notionalarchitectures.

Similar to MO1, the broadcast demonstration for M02 willhave three modes of operation for IP traffic transmissionover the GBS SATCOM network: dual stacks, manualtunneling, and NAT-PT. In the dual stack test mode,IPv6 and IPv4 packets will be forwarded over the DRENthrough the receive suite's egress edge router. In the IPv6

manual tunneling mode, IPv6 traffic will be encapsulatedin IPv4 prior to transmission over the GBS DVB-Sbroadcast equipment. When the tunneled packets arrive atthe receive suite, the egress router will de-encapsulate thetunnel and forward the IPv6 packets across the DREN toIPv6 peer sites. In the NAT-PT test mode, the IPv6 packetswill be translated to IPv4 at the ingress router and thentransmitted over the GBS broadcast equipment. At theReceive Suite, the translated packets will remain IPv4,where the egress router will forward this data to IPv6 peersites over the DREN. In addition, the six notionalarchitectures described above will be demonstrated inconjunction with these three modes of operation to ensureIA compliance for the M02 broadcast testing. For the firstfour notional architectures, either GRE or VPN tunnelswill be used to secure the traffic over the DATM-Unetwork. Two VPN/GRE routers, inserted between theingress and egress routers, will be used to create thesetunnels. Once the DISN DAA reviews the results of thetesting over the first four notional architecture and certifiesthe security compliance, the testing over the last twonotional architectures will be completed, where native anddual stacked traffic can traverse the DATMS network.

TEST FINDINGS

The GBS IPv6 Pilot simulated operational testing wascompleted to measure the performance and capability ofthe GBS DVB-S system to transport native IPv6 and dualstack traffic. The performance of delivering IPv4 unicasttraffic over the Pilot testbed was obtained to serve as acomparison baseline. The Spirent Smartbits trafficgenerator was used to generate IPv4 and IPv6 unicasttraffic at various frame sizes and data rates as depicted inTable 1. The represented dual stack traffic is composed of95%0 IPv4 traffic and 5% IPv6 traffic, which is theprojected ratio of IPv4 to IPv6 traffic during initialdeployment of IPv6 over the GBS networks. Figure 5 and6 depict sample frame loss data for IPv4 unicast baseline,IPv6 unicast, and dual stack unicast traffic over thesimulated operational testbed for 512 and 1400 ByteFrame sizes, respectively.

Test Data Rate2.0 Mbps3.0 Mbps6.0 Mbps

-H-Frame Size (B)

512,1024,1280,1400512,1024,1280,1400512,1024,1280,1400

Table 1. Simulated Operational Testing CharacterizationTest Scenarios

5 of 7

I~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~IL

GalaxyXR

IPA Traffic

0- lPv4 TrafficGRENPN

ME Tunnel

Frame Loss for 512 Byte Frames process and forward IPv6 traffic, which can be attributedto the streamline design of the IPv6 header as compared toIPv4.

Average Latency for 512 Byte Frames

0.0005

0.00045

0.0004

0.00035

-- 0.0003U)

00.00025

M 0.0002

0.00015

0.00005

370

350

>, 330

asas

a)< 290

U 1 2 3 4 b 6 7

Data Rates (Mbps)

Figure 5. Frame Loss Across the GBS IPv6 SimulatedOperational Testbedfor 512 Byte Frames.

3 4

Data Rate (Mbps)Frame Loss for 1400 Byte Frames

0.0001

0.00009

0.00008

0.00007

-- 0.00006

-i 0.00005

p 0.00004

0.00003

0.00002

0.00001

D R

Data Rate (Mbps)

Figure 6. Frame Loss Across the GBS IPv6 SimulatedOperational Testbedfor 1400 byte Frames.

The collected frame loss data demonstrates minimal lossfor IPv4 unicast traffic, native IPv6 unicast traffic, anddual stack traffic. The frame loss for all three traffic typeswas below .0005%, which is well within the acceptablelimit of data loss across a satellite system. CPUprocessing on the network devices within the GBS IPv6Pilot architecture was minimal, indicating that operating ineither native IPv6 or dual stack mode will not impact theperformance of GBS operational networks.

Sample average latency data over the GBS IPv6 Pilottestbed is illustrated in Figure 7 and Figure 8. The lowestaverage latency was observed over the GBS Pilot testbedfor IPv6 unicast traffic, while the highest average latencywas observed for IPv4 unicast traffic. For dual stacktraffic, the IPv6 packets arrive significantly in advance ofthe IPv4 packets. This illustrates the efficiency of therouters and network devices within the Pilot network to

Figure 7. Average Latency Across the GBS IPv6Simulated Operational Testbedfor 512 Byte Frames.

Average Latency for 1400 Byte Frames

370

_ 4 IPv350 _ =

IPv6U, 330 ~~~~~~~~~~~~~~~DualStack

E330

Cu 310

> 290

270

2500 1 2 3 4 5 6 7

Data Rate (Mbps)

Figure 8. Average Latency Across the GBS IPv6Simulated Operational Testbedfor 1400 Byte Frames.

The performance of native IPv6 traffic and dual stacktraffic over the GBS IPv6 Pilot architecture has proven tobe more efficient than the current IPv4 architecture. Basedon this initial data, deploying IPv6 and dual stack withinthe GBS architecture will not impact the performance ofthe network. In fact, deploying IPv6 within the GBSnetwork will enhance the delivery of video and files byreducing the latency across the network. Additional IPv4,IPv6, and dual stack multicast testing will be completedover the GBS Pilot simulated operational testbed todemonstrate the benefits of deploying IPv6 multicasting.

6 of 7

270

250

CONCLUSION

The next generation internet protocol, IPv6, will enable theGBS to create enhanced services for forward deployedwarfighters. With the enhanced IPv6 mobile routingcapabilities, and the advancement of wireless transport andtwo-way SATCOM technologies, GBS will be able todeliver critical information to the tactical edge. To ensurethe seamless integration of IPv6 into the GBS network,GBS has been nominated as a pilot IPv6 network. Duringthe Pilot, GBS will meet Milestone Objective 1 andMilestone Objective 2 requirements. The Pilot will allowGBS to demonstrate the satellite broadcasting of GBSservices using dual stack, manual tunneling, and NAT-PT.At the end of this IPv6 Pilot, GBS will have demonstratedIPv6 capability across its SATCOM network. Completionof the IA requirements for the Pilot will serve as guidancefor the GBS operational network to transition to IPv6.

ACKNOWLEDGEMENTS

The authors would like to extend their thanks to RoseThomas, LtCol Patrick Rizzuto, and CDR Bruce Dickeyfor their support in the development of this paper. Theauthors also extend their appreciation to Chris Ellis, FelixYao, Brian Myers, and Minh Nguyen for their support andassistance.

REFERENCES

[1] Loshin, Pete. "IPv6 Theory, Protocol, and Practice."Morgan Kaufmann Publishers. 2nd Ed. 2004.

[2] Department of Defense Memorandum, "DOD InternetProtocol Version 6 (IPv6) Pilot Nominations." August 16,2005.

[3] Department of Defense IPv6 Transition Office, "DITOInformation Assurance Guidance for Milestone Objective1", Version 1.0, January, 2006.

[4] Department of Defense IPv6 Transition Office, "DITOInformation Assurance Guidance for Milestone Objective2", Version 1.0, March 3ISt 2006.

7 of 7