Technical Reference Guide iDX 3.3 RevG 0117

Contents The Technical Reference Guide contains the following major sections: • iDirect System Overview • DVB-S2 in iDirect Networks • Modulation Modes and FEC Rates • iDirect Spread Spe

Technical Reference Guide

iDirect Satellite Routers

iDX Release 3.3

January 05, 2017

Technical Reference Guide for iDX Release 3.3

Copyright © 2017, VT iDirect Inc All rights reserved Reproduction in whole or in part without permission is prohibited Information contained herein is subject to change without notice The specifications and information regarding the products in this document are subject to change without notice All statements, information and recommendations in this document are believed to be accurate, but are presented without warranty of any kind, express, or implied Users must take full responsibility for their application of any products Trademarks, brand names and products mentioned in this document are the property of their respective owners All such references are used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product's rightful owner.

VT iDirect ® is a global leader in IP-based satellite communications providing technology and solutions that enable our partners worldwide to optimize their networks, differentiate their services and profitably expand their businesses Our product portfolio, branded under the name iDirect, sets standards in performance and efficiency to deliver voice, video and data connectivity anywhere in the world VT iDirect is the world’s largest TDMA enterprise VSAT manufacturer and is the leader in key industries including mobility, military/government and cellular

backhaul.

Company Web site: http://www.idirect.net ~ Main Phone: 703.648.8000

TAC Contact Information: Phone: 703.648.8151 ~ Email: tac@idirect.net ~ Web site: http://tac.idirect.net

iDirect Government™, created in 2007, is a wholly owned subsidiary of iDirect and was formed to better serve the

U.S government and defense communities

Company Web site: http://www.idirectgov.com ~ Main Phone: 703.648.8118

TAC Contact Information: Phone: 703.648.8111 ~ Email: tac@idirectgov.com ~ Web site: http://tac.idirectgov.com

Document Name: T0000598_REF_TRG_iDX 3.3_RevG_01052017.pdf

Document Part Number: T0000598

Revision History

Revision History

The following table shows all revisions for this document To determine if this is the latest revision, check the TAC Web site at http://tac.idirect.net

A 07/31/2014 First release of document for iDX 3.3

B 02/10/2015 Added Group Delay and Downstream Performance topic to the DVB-S2

Roll-off section

C 02/11/2015 Added L2oS for iDX 3.3.1

D, E 09/21/2015 For iDX Release 3.3.3.1, added the following:

• Added - X7 Multicast Fast Path on a Second Downstream Carrier

F 05/31/2016 For iDX 3.3.6, added the following:

• Added - CE Tag Transparency on page 224

• Added - CE Tag Transparency Example on page 258

• Added a note on telnet access and using default passwords -

Security Best Practices on page 119

G 01/05/2017 Added a Multichannel Line Card restriction under Multichannel Line

Cards on page 27

Revision History

Contents

List of Figures .xvi

About .xxi

Purpose xxi

Audience xxi

Contents xxi

Document Conventions xxii

Getting Help xxiii

Document Set xxiv

Chapter 1 iDirect System Overview 1

System Overview 1

IP Network Architecture 3

Chapter 2 DVB-S2 in iDirect Networks 7

DVB-S2 Key Concepts 7

DVB-S2 in iDirect 9

DVB-S2 Downstream 9

ACM Operation 10

Quality of Service in DVB-S2 ACM Networks 12

Remote Nominal MODCOD 12

Remote Maximum MODCOD 12

Fixed Bandwidth Operation 13

Enhanced Information Rate 13

Scaling Factors for Fixed Bandwidth Allocation 15

Bandwidth Allocation Fairness 16

DVB-S2 Configuration 16

DVB-S2 Performance Monitoring 17

Chapter 3 Modulation Modes and FEC Rates 19

iDirect Modulation Modes And FEC Rates 19

DVB-S2 Modulation Modes and FEC Rates 19

2D 16-State Inbound Coding for DVB-S2 Networks 19

TDMA Waveform Enhancements 20

Chapter 4 iDirect Spread Spectrum Networks 23

Overview of Spread Spectrum 23

Spread Spectrum Hardware Components 24

Supported Forward Error Correction (FEC) Rates 25

TDMA Upstream Specifications 25

SCPC Upstream Specifications 25

Chapter 5 Multichannel Line Cards 27

Multichannel Line Card Model Types 27

Multichannel Line Card Receive Modes 27

Multichannel Line Card Restrictions and Limits 28

Chapter 6 SCPC Return Channels 31

Hardware Support and License Requirements 31

Single Channel vs Multichannel SCPC Return 32

SCPC Return Feature on Remotes 32

VNO for SCPC Return 33

Chapter 7 Adaptive TDMA 35

Theory of Operation 35

Short Term Adaptivity and Real-Time Resource Management 36

Medium Term Adaptivity 37

Long Term Adaptivity 38

C/N0 and C/N 38

Fade Margin and Measurement Interval Calculations 40

C/N Dynamic Range for Individual Carriers 42

C/N0 Dynamic Range for Inroute Group 42

Power Control 43

Considerations of TDMA Frame-Filling Efficiency 43

Frame Filling 44

Adaptive TDMA Configuration and Constraints 44

Remote Configuration 46

Reference Carrier Parameters 46

Remote Carrier Constraint Parameters 47

47

Chapter 8 Multicast Fast Path 49

Overview 49

Multicast Fast Path Streams 49

Multicast Fast Path Encryption 50

Multicast Fast Path Encryption Key Management 51

Enabling Multicast Fast Path Encryption 52

Multicast Fast Path Encryption Monitoring 52

X7 Multicast Fast Path on a Second Downstream Carrier 53

Enabling X7 Multicast Fast Path from a Second Downstream 53

Setting Up Multicast Fast Path Encryption Using a GKD Server 55

Configuring GKD for Encrypted Multicast Fast Path in Secondary Networks 55

Protocol Processor Configuration 56

Network Configuration 57

X7 Remote Configuration 58

Creating a GKD Options File for MCFPE for X7 Remotes with a Second Downstream Carrier 59 Supported List of Configurations 61

Chapter 9 QoS Implementation Principles 65

Quality of Service (QoS) 65

QoS Measures 65

iDirect QoS Profiles 66

Classification and Scheduling of Packets 68

Service Levels 68

Packet Scheduling 69

Priority Queues 70

Class-Based Weighted Fair Queues 70

Best Effort Queues 70

Application Throughput 71

Minimum Information Rate 71

Committed Information Rate (CIR) 72

Maximum Information Rate 72

Free Slot Allocation 73

Compressed Real-Time Protocol 73

Sticky CIR 73

Application Jitter 73

TDMA Slot Feathering 74

Packet Segmentation 74

Application Latency 74

Maximum Channel Efficiency vs Minimum Latency 75

Group QoS 75

Group QoS Structure 76

Bandwidth Pool 76

Bandwidth Group 76

Service Group 77

Application 77

Service Profiles 78

Remote Profiles 78

Group QoS Scenarios 79

Physical Segregation Scenario 79

CIR Per Application Scenario 80

Tiered Service Scenario 81

Third Level of Segregation by VLAN Scenario 82

The Shared Remote Scenario 83

Remote Service Group Scenario 85

DVB-S2 ACM Scenario 1: Scaled Aggregate CIRs Below Partition’s CIR 87

DVB-S2 ACM Scenario 2: Scaled Aggregate CIRs Exceeds Partition’s CIR 89

Bandwidth Allocation Fairness Relative to CIR 90

Bandwidth Allocation Fairness Relative to MODCOD 91

Chapter 10 TDMA Initial Transmit Power 93

All Remotes Need To Transmit Bursts in the Same C/N Range 94

What Happens When Initial Tx Power Is Set Incorrectly? 94

When Initial Transmit Power is Too High 94

When Initial Transmit Power is Too Low 95

Chapter 11 Uplink Control Process 97

TDMA Uplink Control 97

Acquisition 97

Network Operation 99

UCP Correction Processing 99

UCP Symbol Timing 99

UCP Frequency Tracking 100

UCP Power Control and Fade Detection 100

SCPC Return Uplink Control 103

UCP Power Adjustment for SCPC Upstream Carriers 104

Viewing UCP Statistics in iMonitor 104

Chapter 12 Remote Idle and Dormant States 107

Overview 107

Feature Description 108

Chapter 13 Verifying Error Thresholds Using IP Packets 113

Introduction 113

TDMA Upstream Threshold Testing 113

Upstream Example 1 114

Upstream Example 2 114

DVB-S2 Downstream Threshold Testing 115

Downstream Example 115

Chapter 14 Global NMS Architecture 117

How the Global NMS Works 117

Sample Global NMS Network 118

Chapter 15 Security Best Practices 119

Hub and NMS Server Security 119

Network Isolation and External Access 119

Server Password Security 119

Secure Server Connections 120

Encryption of Backup Files Before Archiving 120

Clearing Data from Decommissioned Servers 120

NMS Client Security 120

User Passwords and Permissions 120

Client Access 121

Remote Access 121

Console Password Security 121

Clearing Data from Decommissioned Remotes and Line Cards 122

DNS Queries on Satellite (SAT0) Interface of Remote 122

Chapter 16 Global Protocol Processor Architecture 123

Remote Distribution 123

De-coupling of NMS and Data Path Components 123

Chapter 17 Distributed NMS Server 125

Distributed NMS Server Architecture 125

iBuilder and iMonitor 126

Chapter 18 Transmission Security (TRANSEC) 127

What is TRANSEC? 127

iDirect TRANSEC 128

TRANSEC Key types 129

DVB-S2 Downstream TRANSEC 129

Upstream TRANSEC 131

Disguising Remote Acquisition 132

Generating the TDMA Initialization Vector 133

Upstream TRANSEC Segment 134

ACQ Burst Obfuscation 134

TRANSEC Dynamic Key Management 136

TRANSEC Remote Admission Protocol 139

ACC Key Management 139

ACC Key Roll 140

Manual ACC Key Update 140

Automatic Beam Selection and TRANSEC 140

Chapter 19 Remote Sleep Mode 143

Feature Description 143

Awakening Methods 144

Operator-Commanded Awakening 144

Activity Related Awakening 144

Enabling Remote Sleep Mode 144

Power Consumption 145

Chapter 20 Remote Acquisition 147

Acquisition Process 147

Acquisition Algorithm 149

Superburst Acquisition 150

Advantages of Superburst 150

Considerations When Using Superburst 151

Acquisition Carrier Selection 151

Transmit Power Adjustment for Non-reference Carriers 151

Ability to Acquire When No Traffic Carrier Is Available 152

Chapter 21 Automatic Beam Selection 153

Automatic Beam Selection Overview 153

Theory of Operation 154

Overview 154

iDirect Beam Map File and Map Server 154

Beam Selection 155

Conveyance Beam Map File 156

Regulatory Considerations 156

Beam Characteristics: Visibility and Usability 157

Selecting a Beam without a Map 158

Controlling the Antenna 159

IP Mobility 159

Initial Transmit Power 160

Calculation of Initial Transmit Power 160

Setting the Initial Transmit Power Offset 161

Determining the Initial Transmit Power Offset for Other Beams 162

Receive-Only Mode for ABS Remotes 163

Multiple Map Servers per Network 163

Operational Scenarios 164

Creating the Network 164

Adding a Remote 164

Normal Operations 165

Mapless Operations 166

Blockages and Beam Outages 166

Error Recovery 167

Chapter 22 Hub Geographic Redundancy 169

Feature Description 169

Configuring Wait Time Interval for an Out-of-Network Remote 170

Chapter 23 Carrier Occupied Bandwidth171

Overview 171

Considerations When Determining Guard Band 172

DVB-S2 Roll-Off Factors 173

Group Delay and Downstream Performance 174

Improving Throughput by Reducing Guard Band 175

DVB-S2 Guard Band Constraints 175

Adjacent Channel Interference 176

Chapter 24 Alternate Downstream Carrier 179

Background 179

Feature Description 179

Chapter 25 Transmit Key Line 181

Introduction 181

Feature Description 181

Chapter 26 NMS Database Replication 183

Benefits of NMS Database Replication 183

Feature Description 184

NMS Database Replication Architecture 184

Replicating iDirect NMS Databases 185

NMS Database Replication on a Distributed NMS 187

Setting Up NMS Database Replication 189

Examples 190

Enable Replication to a Single Backup Server 190

Add Two Additional Backup NMS Servers as MySQL Slaves 191

Enable Replication to a Redundant NMS Server 191

Stop Replication to a Backup NMS Server 192

Monitoring NMS Database Replication 192

Events And Warnings 193

Viewing Replication Conditions in iMonitor 193

Recovering from Replication Failures 194

Chapter 27 Feature and Chassis Licensing 197

iDirect Licensing Requirements 197

Chapter 28 Hub Line Card Failover 199

Basic Failover Concepts 199

Warm Standby versus Cold Standby Line Card Failover 199

Failover Sequence of Events 200

Chapter 29 NMS, PP and GKD Server Port Assignments 203

NMS Server Ports 203

PP Controller Ports 205

GKD Server Ports 205

Protocol Processor Ports 205

Port Assignments for NMS/Upstream Router Traffic Flow 206

Chapter 30 VRRP and Remote LAN Port Monitoring 207

Virtual Router Redundancy Protocol (VRRP) 207

VRRP Overview 207

Configuring VRRP on iDirect Remotes 210

VRRP Route Tracking 213

Remote LAN Port Monitoring 216

Monitoring VRRP Status and Remote LAN Status 217

Remote Console Commands 218

Chapter 31 Layer 2 over Satellite 221

L2oS Overview 221

L2oS Benefits 222

L2oS Reference Model 223

CE Tag Transparency 224

Satellite Virtual Network and Service Delimiting Tags 225

TCP Acceleration 227

SVNs Scalability 227

L2oS Service Modes 228

Virtual Private LAN Service 229

Virtual Private Wire Service 229

Virtual Private Wire Service-Evolved Packet Core 229

Layer 2/Layer 3 Hybrid Mode 230

Advanced Header Compression 230

MAC Address Learning 232

MAC Addresses Scalability 233

Deleting MAC Addresses from the Forward Information Base Table 233

Forwarding Rules 234

Bi-directional Forwarding Detection 235

L2oS Configuration 236

Layer 2/Layer 3 Hybrid Mode Configuration 236

L2oS Hub Parameters 237

Remote L2oS SDT and SVN Parameters 239

Configuring Advanced Header Compression 241

Assigning VLAN IDs to X7 LAN Ports 242

Configuring Rules for Classifying Layer 2 Traffic 245

Monitoring L2oS Networks 246

Changing MTU at Protocol Processor in L2oS Network 246

L2oS Examples including Layer 2 and Layer 3 Hybrid Mode 248

Layer 2/Layer 3 Hybrid Mode with VLAN Tagging at Hub 256

Layer 2/ Layer 3 Hybrid Mode in Q-in-Q Tagging at Hub 257

CE Tag Transparency Example 258

List of Figures

List of Figures

Figure 1-1 Sample iDirect Network 2

Figure 1-2 iDirect IP Architecture – Multiple VLANs per Remote 4

Figure 1-3 iDirect IP Architecture – VLAN Spanning Remotes 4

Figure 1-4 iDirect IP Architecture – Classic IP Configuration 5

Figure 2-1 Physical Layer Frames 9

Figure 2-2 Feedback Loop from Remote to Protocol Processor 11

Figure 2-3 Feedback Loop with Back-Off from Line Card to Protocol Processor 11

Figure 2-4 Total Bandwidth vs Information Rate in Fixed Bandwidth Operation 13

Figure 2-5 EIR: Total Bandwidth vs Information Rate as MODCOD Varies 14

Figure 3-1 TDMA Burst Format with Distributed Pilots 21

Figure 4-1 Spread Spectrum Network Diagram 23

Figure 7-1 Control Elements of iDirect’s ATDMA System 36

Figure 7-2 Fade Slope Distribution at Various Fade Levels (ITU-R Rec P.1623-1) 40

Figure 8-1 Enabling Multicast Fast Path Encryption 52

Figure 8-2 Protocol Processor GKD Tab 57

Figure 8-3 Network Information Tab 58

Figure 8-4 Protocol Processor Options File with GKD Node Definitions 59

Figure 9-1 Group QoS Structure 76

Figure 9-2 Physical Segregation Scenario 79

Figure 9-3 CIR Per Application Scenario 80

Figure 9-4 Tiered Service Scenario 81

Figure 9-5 Third Level VLAN Scenario 83

Figure 9-6 Shared Remote Scenario 84

Figure 9-7 Remote Service Group Scenario 86

Figure 9-8 Scaled Aggregate CIRs Below Partition’s CIR 88

Figure 9-9 Scaled Aggregate CIRs Exceed Partition’s CIR 89

Figure 9-10 Bandwidth Allocation Fairness Relative to CIR 90

Figure 9-11 Bandwidth Allocation Fairness Relative to Nominal MODCOD 91

Figure 10-1 Optimal C/N Detection Range 94

Figure 10-2 Skewed C/N Detection Range: Initial Transmit Power Too High 95

Figure 10-3 Skewed Detection Range: Initial Transmit Power Too Low 95

Figure 11-1 TDMA Frame Format 97

Figure 11-2 iBuilder: Maximum Speed and Guard Interval for Inroute Group 100

Figure 11-3 Uplink Power Control During Remote Fade 102

Figure 11-4 iMonitor UCP Statistics 104

Figure 11-5 Remote Upstream Acquisition Statistics 106

Figure 12-1 Active, Idle and Dormant State Change Diagram 108

Figure 12-2 Configuring Active, Idle and Dormant States 108

List of Figures

Figure 12-3 Upstream Service Level with Trigger State Change Selected 110

Figure 14-1 Global NMS Database Relationships 117

Figure 14-2 Sample Global NMS Network Diagram 118

Figure 16-1 Protocol Processor Architecture 124

Figure 17-1 Sample Distributed NMS Configuration 125

Figure 18-1 TRANSEC Functional Diagram 128

Figure 18-2 DVB-S2 TRANSEC Frame Structure 130

Figure 18-3 Disguising Which Key is Used for a Burst 132

Figure 18-4 Code Field 132

Figure 18-5 Generating the Upstream Initialization Vector 133

Figure 18-6 Upstream ACQ Burst Obfuscation 135

Figure 18-7 Key Distribution Protocol 136

Figure 18-8 Key Roll Data Structure 137

Figure 18-9 Host Keying Protocol 138

Figure 21-1 iMonitor Probe: Remote Power Section 161

Figure 21-2 Remote VSAT Tab: Entering the Initial Transmit Power Offset 161

Figure 21-3 Absolute vs Generated G/T Contours for Two Beams 162

Figure 23-1 Spectral Mask Illustrating 20% and 5% Roll-Off Factors 173

Figure 23-2 Adjacent Carrier Interference Example 176

Figure 26-1 NMS Database Replication Architecture 184

Figure 26-2 NMS Database Replication from a Single Primary NMS Server 186

Figure 26-3 NMS Database Replication on a Distributed NMS 188

Figure 26-4 Enabling NMS Database Replication to a Backup Server 191

Figure 26-5 Replication Conditions Viewed in iMonitor 194

Figure 26-6 Replication Error Resulting in Active Condition in iMonitor 194

Figure 28-1 Line Card Failover Sequence of Events 201

Figure 30-1 Example of a Virtual Router 209

Figure 30-2 Example VRRP Configuration in iBuilder 212

Figure 30-3 Changing the Frequency of Router Priority Messages 215

Figure 30-4 Changing a Remote’s Router Priority Message Timeout 215

Figure 30-5 Example of LAN Port Monitoring Configuration for Multiple Ports in iBuilder 217

Figure 30-6 Example LAN Port Monitoring Configuration for Single Port in iBuilder 217

Figure 30-7 VRRP and Remote LAN Status Events in iMonitor 218

Figure 31-1 Transparent Layer 2 Emulation 222

Figure 31-2 L2oS Reference Model 223

Figure 31-3 L2oS Reference Model Applied to iDirect 224

Figure 31-4 SDT Mode = VLAN 226

Figure 31-5 SDT Mode = Q-in-Q (Double Tagged) 226

Figure 31-6 SDT Mode = Access (Remote Side Only) 227

Figure 31-7 L2oS Forwarding Rules 234

List of Figures

Figure 31-8 Enabling L2oS 237

Figure 31-9 iBuilder Protocol Processor L2oS Tab 238

Figure 31-10 iBuilder Remote L2oS Tab 239

Figure 31-11 L2oS Advanced Header Compression 241

Figure 31-12 X7 Switch Configuration 243

Figure 31-13 Assigning a Layer 2 VLAN ID to an X7 Port 244

Figure 31-14 Classifiers for Layer 2 Traffic 245

Figure 31-15 Configuring IPv6 Packet Classifier in iBuilder 246

Figure 31-16 VPWS Service with Remote Single End Points 248

Figure 31-17 VPWS Service with IPv6 Traffic 249

Figure 31-18 VPWS Service with Multiple Remote VLANs 250

Figure 31-19 VPWS Service with Multiple VLANs 251

Figure 31-20 VPLS Service with Remote-to-Remote Routing 252

Figure 31-21 VPWS Service with Remote-to-Remote Routing by Upstream Router 253

Figure 31-22 Hub-Side Q-in-Q and Remote VLAN 254

Figure 31-23 BGP Peering 255

Figure 31-24 MPLS with VRF Lite Over the Air 256

Figure 31-25 Layer 2/Layer 3 Hybrid Mode with VLAN Tagging at Hub 256

Figure 31-26 Layer 2/Layer 3 Hybrid Mode with Q-in-Q Tagging at Hub 257

Figure 31-27 CE Tag Transparency 258

List of Tables

List of Tables

Table 2-1 DVB-S2 Modulation and Coding Schemes 8

Table 2-2 ACM MODCOD Scaling Factors 15

Table 4-1 Spread Spectrum: TDMA Upstream Specifications 25

Table 4-2 Spread Spectrum: SCPC Upstream Specifications 25

Table 5-1 Multichannel Receive Line Card Parameters (XLC-M and eM0DM) 29

Table 6-1 Single Channel vs Multichannel SCPC 32

Table 7-1 Fade Slope Values Used For Calculations 41

Table 7-2 Example of M1 Margin and Measurement Spacing Settings 41

Table 7-3 Sample Adaptive Inroute Group Configuration 45

Table 8-1 Supported MCFPE Configurations 61

Table 19-1 Power Consumption: Normal Operations vs Remote Sleep Mode 145

Table 23-1 Increasing Information Rate by Reducing Guard Band 175

Table 23-2 DVB-S2 Guard Band Constraints 175

Table 29-1 NMS Server Ports 203

Table 29-2 pp_controller Ports 205

Table 29-3 GKD Server Ports 205

Table 29-4 samnc Ports 205

Table 29-5 Protocol Processor Port Ranges 206

Table 29-6 Port Designations for NMS/Upstream Router Traffic 206

Table 30-1 PP Routing Table Operations: LAN Port Monitoring and VRRP 216

Table 31-1 SDT Support Matrix 227

Table 31-2 Maximum Number of Layer 3 SVNs Per Network (Relative to Network Size) 228

Table 31-3 IPv4 Header Compression 231

Table 31-4 IPv4 Header Compression with IP Extensions 231

Table 31-5 IPv6 Header Compression 232

Table 31-6 IPv6 Header Compression with IP Extensions 232

Table 31-7 BFD Options Trade-offs 236

Table 31-8 Header Compression Examples 242

List of Tables

About

Purpose

The Technical Reference Guide provides detailed technical information on iDirect technology

and major features as implemented in iDX Release 3.3

Audience

The Technical Reference Guide is intended for iDirect Network Operators, network architects,

and anyone upgrading to iDX Release 3.3

Contents

The Technical Reference Guide contains the following major sections:

• iDirect System Overview

• DVB-S2 in iDirect Networks

• Modulation Modes and FEC Rates

• iDirect Spread Spectrum Networks

• Multichannel Line Cards

• SCPC Return Channels

• Adaptive TDMA

• Multicast Fast Path

• QoS Implementation Principles

• TDMA Initial Transmit Power

• Uplink Control Process

• Remote Idle and Dormant States

• Verifying Error Thresholds Using IP Packets

• Global NMS Architecture

• Security Best Practices

• Global Protocol Processor Architecture

• Distributed NMS Server

• Transmission Security (TRANSEC)

• Remote Sleep Mode

• Automatic Beam Selection

• Hub Geographic Redundancy

• Carrier Occupied Bandwidth

• Alternate Downstream Carrier

• Transmit Key Line

• NMS Database Replication

• Feature and Chassis Licensing

• Hub Line Card Failover

• NMS, PP and GKD Server Port Assignments

• VRRP and Remote LAN Port Monitoring

• Layer 2 over Satellite

Document Conventions

This section illustrates and describes the conventions used throughout this document

Command Used when the user is required to

enter a command at a command line prompt or in a console.

Enter the command:

Used when specifying names of commands, menus, folders, tabs, dialogs, list boxes, and options.

1 To add a remote to an inroute group, right-click

the Inroute Group and select Add Remote.

The Remote dialog box has a number of selectable tabs across the top The Information

user-tab is visible when the dialog box opens.

Hyperlink Used to show all hyperlinked text

within a document or external links such as web page URLs.

For instructions on adding a line card to the network tree, seeAdding a Line Card on page 108.

NOTE: A Note is a statement or other notification that adds, emphasizes, or

clarifies essential information of special importance or interest

Getting Help

The iDirect Technical Assistance Center (TAC) and the iDirect Government Technical

Assistance Center (TAC) are available to provide assistance 24 hours a day, 365 days a year Software user guides, installation procedures, FAQs, and other documents that support iDirect and iDirect Government products are available on the respective TAC Web site:

• Access the iDirect TAC Web site at http://tac.idirect.net

• Access the iDirect Government TAC Web site at http://tac.idirectgov.com

The iDirect TAC may be contacted by telephone or email:

• iDirect: techpubs@idirect.net

• iDirect Government: techpubs@idirectgov.com

For sales or product purchasing information contact iDirect Corporate Sales at the following telephone number or e-mail address:

• Telephone: 703.648.8000

• E-mail: sales@idirect.net

CAUTION: A Caution highlights an essential operating or maintenance procedure,

practice, condition, or statement which, if not strictly observed, could result in damage to, or destruction of, equipment or a condition that adversely affects system operation

WARNING: A Warning highlights an essential operating or maintenance

procedure, practice, condition or statement which, if not strictly observed, could result in injury or death or long term health hazards

Document Set

The following iDirect documents are available at http://tac.idirect.net and contain

information relevant to installing and using iDirect satellite network software and equipment

• Release Notes

• Software Installation Guide or Network Upgrade Procedure Guide

• iBuilder User Guide

• iMonitor User Guide

• Installation and Commissioning Guide for Remote Satellite Routers

• Features and Chassis Licensing Guide

• Software Installation Checklist/Software Upgrade Survey

• Link Budget Analysis Guide

System Overview

1 iDirect System Overview

This chapter presents a high-level overview of iDirect Networks It provides a sample iDirect network and describes the network architectures supported by iDirect

System Overview

An iDirect network is a satellite network with a Star topology in which a Time Division Multiplexed (TDM) broadcast downstream channel from a central hub location is shared by a number of remote sites Each remote transmits to the hub either on a shared Deterministic-TDMA (D-TDMA) upstream channel with dynamic timeplan slot assignments or on a dedicated SCPC return channel

iDirect supports both traditional OSI Layer 3 TCP/IP networks and Layer 2 over Satellite (L2oS) networks that transport Ethernet frames over the satellite link The L2oS feature, which was added in iDX Release 3.3.1, is described in Layer 2 over Satellite on page 221

The iDirect Hub equipment consists of one or more iDirect Hub Chassis with Universal Line Cards, one or more Protocol Processors (PP), a Network Management System (NMS) and the appropriate RF equipment Each remote site consists of an iDirect broadband satellite router and the appropriate external VSAT equipment

TDMA upstream carriers are configured in groups called Inroute Groups Multiple Inroute Groups can be associated with one downstream carrier Any remote configured to transmit to the hub on a TDMA upstream carrier is part of an Inroute Group The specific TDMA upstream carrier on which the remote transmits at any given time is determined dynamically during operation A remote that transmits on a dedicated SCPC return channel is not associated with

an Inroute Group Instead, the dedicated SCPC upstream carrier is directly assigned to the remote and to the hub line card that receives the carrier

Prior to iDX Release 3.2, all TDMA upstream carriers in an Inroute Group were required to have the same symbol rate, modulation and error coding With the introduction of Adaptive TDMA in iDX Release 3.2, the symbol rate and MODCOD of the carriers in an Inroute Group may vary from carrier to carrier Remotes in an Inroute Group move from carrier to carrier in real time based on network conditions Furthermore, with Adaptive TDMA, the individual carrier MODCODs can adjust over time to optimize network performance for changing network conditions Adaptive TDMA allows for significantly less fade margin in the network design and optimal use of upstream bandwidth during operation

Figure 1-1 on page 2 shows an example of an iDirect network The network consists of one downstream carrier; two Inroute Groups providing the TDMA return channels for a total of

1200 remotes; and three remotes transmitting dedicated SCPC return channels to the hub

System Overview

Figure 1-1 Sample iDirect Network

iDirect software has flexible controls for configuring Quality of Service (QoS) and other traffic-engineered solutions based on end-user requirements and operator service plans Network configuration, control, and monitoring functions are provided by the integrated NMS.The iDirect software provides numerous features, including:

• Packet-based and network-based QoS, including Layer 2 and Layer 3 packet

classification

• TCP acceleration (IPv4)

• AES link encryption

• Multicast support

• End-to-end VLAN tagging

Layer 3 TCP/IP networks also support a long list of IP features, including DNS, DHCP, RIPv2, IGMP, GRE tunneling, and cRTP Layer 2 Ethernet-based networks provide Layer 3 protocol transparency and simplified operation for applications such as Virtual Private Networks

NOTE: iDX 3.3.1 or later is required to configure Layer 2 over Satellite.

IP Network Architecture

For a complete list of available features in all iDirect releases, see the iDirect Software

Feature Matrix available on the TAC Web site.

IP Network Architecture

The examples in this section apply to traditional iDirect TCP/IP networks which transport IPV4 traffic over the satellite link Layer 2 networks, which transport Ethernet frames over satellite, are discussed in Layer 2 over Satellite on page 221 Since Layer 3 protocols are transparent to a Layer 2 network, a Layer 2 network can support Layer 3 protocols (such as IPv6 and BGP) that are not supported in an iDirect TCP/IP network

An iDirect network interfaces to the external world over Ethernet ports on the Remote Satellite Routers and the Protocol Processor servers at the hub The examples in Figure 1-2 on page 4, Figure 1-3 on page 4, and Figure 1-4 on page 5 illustrate the IP level configurations available to a Network Operator for Layer 3 networks

The iDirect system allows a mix of networks that use traditional IP routing and VLAN based configurations This provides support for customers with conflicting IP address ranges It also allows multiple independent customers at individual remote sites by configuring multiple VLANs on the same remote

Figure 1-2 iDirect IP Architecture – Multiple VLANs per Remote

IP Network Architecture

Figure 1-3 iDirect IP Architecture – VLAN Spanning Remotes

IP Network Architecture

Figure 1-4 iDirect IP Architecture – Classic IP Configuration

IP Network Architecture

• Improved inner coding: Low-Density Parity Coding

• Greater variety of modulations: QPSK, 8PSK, 16APSK

• Dynamic variation of the encoding on broadcast channel: Adaptive Coding and

ModulationThese improvements lead to greater efficiencies and flexibility in the use of available bandwidth iDirect supports DVB-S2 in both TRANSEC and non-TRANSEC networks

MODCOD refers to the combinations of Modulation Types and Error Coding schemes supported

by the DVB-S2 standard The higher the modulation the greater the number of bits per symbol (or bits per Hz) The modulation types specified by the standard are:

The DVB-S2 standard does not support every combination of modulation and coding DVB-S2 specifies the MODCODs shown in Table 2-1 on page 8 In general, the lower the MODCOD, the more robust the error correction, and the lower the efficiency in bits per Hz The higher the MODCOD, the less robust the error correction, and the greater the efficiency in bits per Hz

DVB-S2 Key Concepts

DVB-S2 defines three methods of applying modulation and coding to a data stream:

• ACM (Adaptive Coding and Modulation) specifies that every BBFRAME can be transmitted

on a different MODCOD Remotes receiving an ACM carrier cannot anticipate the MODCOD of the next BBFRAME A DVB-S2 demodulator such as those used by iDirect remotes must be designed to handle dynamic MODCOD variation

• CCM (Constant Coding and Modulation) specifies that every BBFRAME is transmitted at

the same MODCOD using long frames Long BBFRAMEs are not used in iDirect Instead, a constant MODCOD can be achieved by setting the Maximum and Minimum MODCODs of

the outbound carrier to the same value (See the iBuilder User Guide for details on

configuring DVB-S2 carriers.)

Table 2-1 DVB-S2 Modulation and Coding Schemes

DVB-S2 in iDirect

• VCM (Variable Coding and Modulation) specifies that MODCODs are assigned according to

service type As in ACM mode, the resulting downstream contains BBFRAMEs transmitted

at different MODCODs Although iDirect does not support VCM, it does allow configuration of specific MODCODs for multicast streams

DVB-S2 in iDirect

Beginning with iDX Release 3.2, iDirect only supports DVB-S2 downstream carriers Networks with iNFINITI downstream carriers are only supported in earlier releases All iDirect hardware

supported in this release can operate in a DVB-S2 network The iBuilder User Guide lists all

available line card and remote model types

iDirect DVB-S2 networks support ACM on the downstream carrier with all modulations up to 16APSK An iDirect DVB-S2 network always uses short DVB-S2 BBFRAMES iDirect also allows the Network Operator to configure multiple multicast streams and specify the multicast MODCOD of each stream

DVB-S2 Downstream

A DVB-S2 downstream can only be configured as ACM An ACM downstream is not constrained

to operate at a fixed modulation and coding Instead, the modulation and coding of the downstream varies within a configurable range of MODCODs In iDirect, CCM is configured by limiting the MODCOD range to a single MODCOD

An iDirect DVB-S2 downstream contains a continuous stream of Physical Layer Frames

(PLFRAMEs) The PLHEADER indicates the type of modulation and error correction coding used

on the subsequent data It also indicates the data format and frame length Refer to

Figure 2-1

Figure 2-1 Physical Layer Frames

The PLHEADER always uses /2 BPSK modulation Like most DVB-S2 systems, iDirect injects pilot symbols within the data stream The overhead of the DVB-S2 downstream varies

between 2.65% and 3.85%

The symbol rate remains fixed on the DVB-S2 downstream Variation in throughput is realized through DVB-S2 support, and the variation of MODCODs in ACM Mode The maximum possible throughput of the DVB-S2 carrier (calculated at 45 Msym/s and highest MODCOD 16APSK 8/9)

is approximately 155 Mbps Multiple protocol processors may be required to support high traffic to multiple remotes

PLHEADER: signals MODCOD and frame length (always S/2 BPSK)

Pilot symbols:

unmodulated carrier

Data symbols: QPSK, 8PSK, 16APSK, or 32APSK

DVB-S2 in iDirect

iDirect uses DVB-S2 “Generic Streams” with a proprietary variation of the LEGS (Lightweight Encapsulation for Generic Streams) protocol for encapsulation of downstream data between the DVB-S2 line cards and remotes LEGS maximizes the efficiency of data packing into BBFRAMES on the downstream For example, if a time plan only takes up 80% of a BBFRAME, the LEGS protocol allows the line card to include a portion of another packet that is ready for transmission in the same frame This results in maximum use of the downstream bandwidth

ACM Operation

Adaptive Coding and Modulation (ACM) allows remotes operating in better signal conditions to receive data on higher MODCODs by varying the MODCOD of data targeted to each remote to match its current receive capabilities

Not all data is sent to each remote at its most efficient MODCOD Important system

information (such as time plan messages), as well as broadcast traffic, is transmitted at the minimum MODCOD configured for the outbound carrier This allows all remotes in the

network, even those operating at the worst MODCOD, to receive this information reliably.The protocol processor determines the maximum MODCOD for all data sent to the DVB-S2 line card for transmission over the outbound carrier However, the line card does not necessarily respect these MODCOD assignments In the interest of downstream efficiency, some data scheduled for a high MODCOD may be transmitted at a lower one as an alternative to inserting padding bytes into a BBFRAME When assembling a BBFRAME for transmission, the line card first packs all available data for the chosen MODCOD into the frame If there is space left in the BBFRAME, and no data left for transmission at that MODCOD, the line card attempts to pack the remainder of the frame with data for higher MODCODs This takes advantage of the fact that a remote can demodulate any MODCOD in the range between the carrier’s minimum MODCOD and the remote current maximum MODCOD

The maximum MODCOD of a remote is based on the latest Signal-to-Noise Ratio (SNR)

reported by the remote to the protocol processor The SNR thresholds per MODCOD are determined during hardware qualification for each remote model type The Spectral

Efficiency of iDirect remotes at the threshold SNR for each MODCOD is documented in the

iDirect Link Budget Analysis Guide.

The hub adjusts the MODCODs of the transmissions to the remotes by means of the feedback loop shown in Figure 2-2 on page 11 Each remote continually measures its downstream SNR and reports the current value to the protocol processor When the protocol processor assigns data to an individual remote, it uses the last reported SNR value to determine the highest MODCOD on which that remote can receive data without exceeding a specified BER The protocol processor includes this information when sending outbound data to the line card The line card then adjusts the MODCOD of the BBFRAMES to the targeted remotes accordingly

NOTE: The line card may adjust the MODCOD of the BBFRAMEs downward for

downstream packing efficiency

DVB-S2 in iDirect

Figure 2-2 and Figure 2-3 show the operation of the SNR feedback loop and the behavior of the line card and remote during fast fade conditions Figure 2-2 shows the basic SNR reporting loop described above

Figure 2-2 Feedback Loop from Remote to Protocol Processor

Figure 2-3page 11 shows the back-off mechanism that exists between the line card and

protocol processor to prevent data loss The protocol processor decreases the maximum data sent to the line card for transmission based on a measure of the number of remaining

untransmitted bytes on the line card These bytes are scaled according to the MODCOD on which they are to be transmitted, since bytes destined to be transmitted at lower MODCODs will take longer to transmit than bytes destined to be transmitted on a higher MODCODs

Figure 2-3 Feedback Loop with Back-Off from Line Card to Protocol Processor

Remote

Rx Line card

SNR measured and reported to PP

New MODCOD Incoming user

data

internal queue SNR compared to

SNR threshold:

new MODCOD selected

Downstream throughput (varies based on MODCOD assigned )

Remote

Rx Line Card

SNR measured and reported to PP

New MODCOD Incoming user

data

Tx ine card queue too full? Allocate less user data

internal queue SNR compared to

SNR threshold:

New MODCOD selected

Tx line card reports internal queue fullness

to PP

Reduction in downstream data

Downstream throughput (varies based on MODCOD assigned)

DVB-S2 in iDirect

Quality of Service in DVB-S2 ACM Networks

iDirect QoS for DVB-S2 downstream carriers is basically identical to QoS for fixed MODCOD downstream carriers (See QoS Implementation Principles on page 65.) However, with DVB-S2

in ACM Mode, the same amount of user data (in bits per second) occupies more or less downstream bandwidth, depending on the MODCOD at which it is transmitted This is true because user data transmitted at a higher MODCOD requires less bandwidth than it does at a lower MODCOD

When configuring QoS in iBuilder, a Network Operator can define a Maximum Information Rate (MIR) and/or a Committed Information Rate (CIR) at various levels of the QoS tree (See the

iBuilder User Guide for definitions of CIR and MIR.) For an ACM outbound, the amount of

bandwidth granted for a configured CIR or MIR is affected by both the MODCOD that the remote is currently receiving and a number of parameters configurable in iBuilder The remainder of this section discusses the various parameters and options that affect DVB-S2 bandwidth allocation and how they affect the system performance

Remote Nominal MODCOD

The Network Operator can configure a Nominal MODCOD for DVB-S2 remotes operating in ACM mode The Nominal MODCOD is the Reference Operating Point (ROP) for the remote By default, a remote Nominal MODCOD is equal to the DVB-S2 carrier’s Maximum MODCOD The Nominal MODCOD is typically determined by the link budget but may be adjusted after the remote is operational

In a fixed network environment, the Nominal MODCOD is typically chosen to be the Clear Sky MODCOD of the remote In a mobile network where the Clear Sky MODCOD depends on the position of the remote terminal, the Nominal MODCOD may be any point in the beam coverage

at which the service provider chooses to guarantee the CIR

The CIR and MIR granted to the remote are limited by the remote Nominal MODCOD The remote is allowed to operate at MODCODs higher than the Nominal MODCOD (as long as it does not exceed the configured Remote Maximum MODCOD described below), but is not granted additional higher CIR or MIR when operating above the Nominal MODCOD

Remote Maximum MODCOD

The Network Operator can also configure a Maximum MODCOD for DVB-S2 remotes operating

in ACM mode By default, a remote Maximum MODCOD is equal to the DVB-S2 carrier’s Maximum MODCOD iBuilder allows the operator to limit the Maximum MODCOD for a remote

to a value lower than the DVB-S2 carrier’s Maximum MODCOD and higher than or equal to the remote Nominal MODCOD This is important if the network link budget supports higher MODCODs but some remote LNBs do not have the phase stability required for the higher MODCODs For example, a DRO LNB cannot support 16APSK due to phase instability at higher MODCODs

Note that a remote Maximum MODCOD is not the same as a remote Nominal MODCOD The remote is allowed to operate above its Nominal MODCOD as long as it does not exceed the remote Maximum MODCOD A remote is never allowed to operate above its Maximum

MODCOD

DVB-S2 in iDirect

Fixed Bandwidth Operation

During a rain fade, the CIR or MIR granted to a remote are scaled down based on the remote Nominal MODCOD This provides a graceful degradation of CIR and MIR during the fade while consuming the same satellite bandwidth as at the Nominal MODCOD

Figure 2-4 shows the system behavior when operating in Fixed Bandwidth Mode The remote

Nominal MODCOD is labeled Nominal @ ClearSky in the figure In the example, the remote

has been configured with 256 kbps of CIR and a Nominal MODCOD of 8PSK 3/5 If the remote operates at a higher MODCOD, it is not granted a higher CIR When the remote enters a rain fade, the allocated bandwidth remains fixed at the Nominal MODCOD bandwidth The degradation in throughput is gradual because the remote continues to use the same amount of satellite bandwidth that was allocated for its Nominal MODCOD

Figure 2-4 Total Bandwidth vs Information Rate in Fixed Bandwidth Operation

Enhanced Information Rate

As noted above, the occupied bandwidth for CIR or MIR varies per MODCOD If, when

allocating downstream bandwidth for a remote, the system always attempted to meet these rates regardless of MODCOD, then a remote in a deep rain fade may be granted a

disproportionate share of bandwidth at the expense of other remotes in the network On the other hand, if CIR and MIR settings were only honored at the remote Nominal MODCOD (Fixed Bandwidth Mode), then there would be no option to increase the bandwidth to satisfy the requested information rate when a remote dropped below its Nominal MODCOD

The “Enhanced Information Rate” (EIR) option allows configuration of the system to maintain CIR or MIR during rain fade for the physical remote (Remote Service Groups or Remote-Based Group QoS) or critical applications (Application-Based Group QoS) EIR only applies to networks that use DVB-S2 with Adaptive Coding and Modulation (ACM) EIR can be enabled for

a physical remote or at several levels of the Group QoS tree For details on configuring EIR,

see the iBuilder User Guide.

DVB-S2 in iDirect

EIR is only enabled in the range of MODCODs from the remote Nominal MODCOD down to the configured EIR Minimum MODCOD Within this range, the system always attempts to allocate requested bandwidth in accordance with the CIR and MIR settings, regardless of the current MODCOD at which the remote is operating Since higher MODCODs contain more information bits per second, as the remote MODCOD increases, so does the capacity of the outbound channel to carry additional information

As signal conditions worsen, and the MODCOD assigned to the remote drops, the system

attempts to maintain CIR and MIR only down to the configured EIR Minimum MODCOD If the

remote drops below this EIR Minimum MODCOD, it is allocated bandwidth based on the remote Nominal MODCOD with the rate scaled to the MODCOD actually assigned to the remote The net result is that the remote receives the CIR or MIR as long as the current MODCOD of the remote does not fall below the EIR Minimum MODCOD Below the EIR minimum MODCOD, the information rate achieved by the remote falls below the configured settings

The system behavior in EIR mode is shown in Figure 2-5 The remote Nominal MODCOD is labeled “Nominal” in the figure The system maintains the CIR and MIR down to the EIR Minimum MODCOD Notice in the figure that when the remote is operating below EIR Minimum MODCOD, it is granted the same amount of satellite bandwidth as at the remote Nominal MODCOD

Figure 2-5 EIR: Total Bandwidth vs Information Rate as MODCOD Varies

DVB-S2 in iDirect

Scaling Factors for Fixed Bandwidth Allocation

Table 2-2 shows the scaling factors that can be used to calculate the information rate at different MODCODs when the allocated bandwidth is held constant at the remote Nominal MODCOD This happens both in Fixed Bandwidth Mode or in EIR Mode when the remote MODCOD falls below the EIR Minimum MODCOD

The following formula can be used to determine the information rate at which data is sent when that data is scaled to the remote’s Nominal MODCOD:

IR a = IR n x S b / S a

where:

• IR a is the actual information rate at which the data is sent

• IR n is the nominal information rate (for example, the configured CIR)

• S b is the scaling factor for the remote’s Nominal MODCOD

Table 2-2 ACM MODCOD Scaling Factors MODCOD Scaling Factor Comments

16APSK 8/9 1.2382 Best MODCOD 16APSK 5/6 1.3415

16APSK 4/5 1.4206 16APSK 3/4 1.5096 16APSK 2/3 1.6661 8PSK 8/9 1.6456 8PSK 5/6 1.7830 8PSK 3/4 2.0063 8PSK 2/3 2.2143 8PSK 3/5 2.4705 QPSK 8/9 2.4605 QPSK 5/6 2.6659 QPSK 4/5 2.8230 QPSK 3/4 2.9998 QPSK 2/3 3.3109 QPSK 3/5 3.6939 QPSK 1/2 5.0596 QPSK 2/5 5.6572 QPSK 1/3 6.8752 QPSK 1/4 12.0749 Worst MODCOD

DVB-S2 in iDirect

• S a is the scaling factor for the MODCOD at which the data is sentFor example, assume that a remote is configured with a CIR of 1024 kbps and a Nominal MODCOD of 16ASPK 8/9 If EIR is not in effect, and data is being sent to the remote at MODCOD QPSK 8/9, then the resulting information rate is:

IR a = IR n x S b / S a

IR a = 1024 kbps x 1.2382 / 2.4605 = 515 kbps

For two scenarios showing how CIR and MIR are allocated for a DVB-S2 network in ACM mode, see page 87 and page 89

Bandwidth Allocation Fairness

There are three configurable options for bandwidth allocation fairness:

• Allocation Fairness Relative To CIR

• Allocation Fairness Relative to Nominal MODCOD

• Allocation Fairness Relative to Operating MODCOD

Enabling or disabling any of these options for a Group QoS node or for a physical remote affects how CIR and MIR bandwidth is apportioned during bandwidth contention Allocation Fairness Relative to MODCOD only affects bandwidth allocation on DVB-S2 ACM outbound carriers Allocation Fairness Relative to CIR affects bandwidth allocation in general

For a detailed explanation of these options, see the Quality of Service chapter in the iBuilder

User Guide For sample scenarios illustrating the use of these options, see Bandwidth

Allocation Fairness Relative to CIR on page 90 and Bandwidth Allocation Fairness Relative to MODCOD on page 91

DVB-S2 Configuration

Various iBuilder settings affect the operation of DVB-S2 networks For details on configuring

DVB-S2, see the iBuilder User Guide The following areas are affected:

• Downstream Carrier Definition: When adding an ACM DVB-S2 downstream carrier, the

Network Operator must specify a range of MODCODs over which the carrier will operate Error correction for the carrier is fixed to LDPC and BCH In addition, iBuilder does not allow selection of an information rate or transmission rate for a DVB-S2 carrier as an alternative to the symbol rate, since these rates vary dynamically with changing MODCODs

However, iBuilder provides a MODCOD Distribution Calculator that estimates the overall Information Rate for the carrier based on the distribution of the Nominal MODCODs of the remotes in the network Access this calculator by clicking the MODCOD Distribution button on the DVB-S2 Downstream Carrier dialog box A similar calculator allows estimation of CIR and MIR bandwidth requirements at various levels of the Group QoS tree

NOTE: When bandwidth is allocated for a remote, the CIR and MIR are scaled to

the remote’s Nominal MODCOD At higher levels of the Group QoS tree (Bandwidth Group, Service Group, etc.) CIR and MIR are scaled to the network’s best

MODCOD.)