SDG_book

Services Delivery Gateway Solution

Today, mobile wireless service providers face a multitude of challenges in keeping pace with

the ever-increasing demands on their network infrastructure. Increased demand for bandwidth

is generated by multimedia, data-enabled handheld devices and streaming devices. Smart

phones have become an integral part of everyday life and the penetration rate of such devices

is reaching exponential proportions in an attempt to satisfy the unquenchable demands across

the globe. Certain applications such as video streaming are now commodities. As a result,

these simultaneous trends impact the infrastructure of existing mobile operators.

This handbook describes how mobile operators can now address the increasing demands

on their mobile packet core network infrastructure by deploying Juniper’s Services Delivery

Gateway which will enable them to offload services to maximize investment on existing

deployed mobile packet gateways, consolidate diversified/distributed services to simplify

current backend networks and prepare for v4/v6 transition and provide overall multimedia

optimization to delay/save RAN CapEx investment. Juniper’s Services Delivery Gateway is an

initiative that was proposed jointly by sales teams, MBU and the RSBU and is based on the

Juniper flagship MX Series platform and leverages the key services such as CGNAT, SLB, SFW

and others to enable mobile operators to effectively manage their traffic, optimize the usage of

their network resources and ensure quality of experience for their end subscribers.

“Tier 1 global mobile operators today are experiencing multiple challenges from several

directions. They are trying to grow their revenue by introducing new services while at the

same time dealing with the growing demands to decrease CapEx as they grow their network

infrastructure. “Success based investment” where they see a revenue return for their

investments is critical. The delivery of the Services Delivery Gateway solution to the market

is extremely timely and will enable Juniper to address these challenges that mobile operators

experience and alleviate some of the pain points in the network at the edge of the mobile

packet core. This handbook describes how mobile operators can reduce the impact of growing

bandwidth requirements on their mobile packet core network infrastructure by effectively

aggregating key services in one single node—Juniper’s Services Delivery Gateway. In addition

to describing Services Delivery Gateway as a consolidated service node, this handbook details

how Services Delivery Gateway is a key network component in the Mobile Video Optimization

solution offering from Juniper.”

− Scott Stevens

VP Technology and Worldwide Systems Engineering

Juniper Networks

7100142-002-EN Aug 2011

Se

rvices D

elive

ry Ga

tew

ay S

olu

tion

Services Delivery Gateway SolutionImplementing IP Services and Mobile Video Optimization at the Mobile Packet Core

© 2011 by Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. Junos-e is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.

Printed in the USA.

i

Contents

Chapter 1 – Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Handheld Devices Increase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Data Growth Increase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Depletion of IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Siloed Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Challenges Summary, Operators’ Needs, Services Delivery Gateway Value Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Roadmap/Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Services Delivery Gateway Framework Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Role of the Junos Software Development Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Junos SDK (RE and Services) Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Junos SDK Virtual Execution Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Proposed Services Delivery Gateway Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Implementing Services Delivery Gateway Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15In-house Junos Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Partnership for Value Added Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Multi-Media Optimization (MMO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Application Delivery Control (ADC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

DNS Partner for User Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Services Delivery Gateway, Phase 1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 3 – Policy and Charging Control Standards Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3GPP PCC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Services Delivery Gateway and 3GPP PCC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Traffic Detection Function in 3GPP TS 23 .203 .b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Insertion Point Story Line—Services Delivery Gateway as a Pre-TDF Network Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Chapter 4 – Architectural Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Services Delivery Gateway Connectivity Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

MC-LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

GRES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

RPM, Automation Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Generic Logical Flow Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

ii Services Delivery Gateway Solution

Chapter 5 – Traffic Direct Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Dynamic Subscriber Awareness Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Juniper Networks SBR, SRC and DSA Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Diameter Messages Exchanged by Juniper’s DSA and SAE . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Understanding Diameter AVPs for Dynamic Subscriber Awareness . . . . . . . . . . . . . . . . . . 41

Understanding DSA and SAE Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Traffic Direct Validated Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Traffic Direct Generic Call Flow Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Configuration Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Validation Test Bed Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Validated Traffic Direct Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

Static Bypass Scenario Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Static Bypass Scenario Code Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Dynamic Scenario (Subscriber and Application Aware) Call Flow . . . . . . . . . . . . . . . . . . . . 57

Dynamic Policy Scenario Code Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapter 6 – Consolidated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Identified Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Validation Test Bed Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Physical Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Logical Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Hardware Components and Software Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78UE DNS Call Flow (to DNS Service Complex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

DNS Complex Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Configuration Snippets and Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Non-HTTP Traffic Call Flow (to the Internet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Configuration Snippets and Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84HTTP Traffic Call Flow (to Multimedia Optimization Service Complex) . . . . . . . . . . . . . . .87

Configuration Snippets and Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

iii

Chapter 7 – Juniper Mobile Video Optimization Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

Optimizing the Mobile Network for Video Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Juniper Networks Mobile Video Optimization Solution Overview . . . . . . . . . . . . . . . . . . . 95

Solution Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Minimizing the Solution Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Mobile Video Optimization Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Juniper’s Mobile Video Optimization Service Complex Sub Components . . . . . . . . . . .102

White List and Sampling Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Media Flow Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

Functional Test Setup Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Main Corresponding Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Configuration Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134Traffic Management to Minimize CapEx/OpEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Improve Subscriber Quality of Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Future Proof Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Appendices

Appendix A: Juniper Networks Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136

MX 3D Universal Edge Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136EX Series Ethernet Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Junos Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Steel-Belted Radius Service Provider Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Session and Resource Control (SRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

Media Flow Controller (MFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

Appendix B: References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Web Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Juniper Marketing Collateral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Juniper Technical Collateral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Junos Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Appendix C: Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

iv Services Delivery Gateway Solution

Preface

This handbook serves as a reference guide for feasibility, insertion and implementation of validated services supported by the Services Delivery Gateway, Phase 1 based on Juniper Networks validated solution reference architecture.

The focus is on how Mobile Service Providers (MSPs) can deploy this solution by incorporating it into their existing infrastructure to consolidate incumbent distributed services while not only delaying their CapEx and OpEx investment but also by positioning themselves (subsequent phase of Service Delivery Gateway) to facilitate inevitable network transition towards IPV6.

This handbook provides guidelines and considerations, the solution technical details and various sample configurations, which are based on validation testing performed using Juniper Networks and partners’ platforms and software.

The reader, as a prerequisite, should have some level of knowledge regarding IP services, mobile networks, and video.

Chapter 1 – Introduction provides a high-level overview of the growing multitude of challenges facing mobile wireless operators thereby creating an opportunity for Juniper to insert into the mobile packet core without disrupting the core, and in turn, help open the doors for MobileNext product portfolio sales and opportunities.

Chapter 2 – Services Delivery Gateway Framework – Foundation for Next Generation Services describes the positioning of Juniper’s MX Series 3D Ethernet Services Router as a Service Delivery Gateway and introduces the concept of services on the MX.

Chapter 3 – Policy and Charging Control Standards Perspective explains how and where the Services Delivery Gateway fits into the existing 3GPP architecture and the evolving deployment models for which Services Delivery Gateway, today, is already well positioned to support future requirements and functions such as TDF (Traffic Detection Function).

Chapter 4 – Architectural Approach presents the high-level reference architecture, which is discussed in detail in the remainder of the book.

Chapter 5 – Traffic Direct Overview defines Juniper Networks Traffic Direct solution and how it works; provides call flows, and details its main scenarios (Subscriber Aware, Application Aware and Static Bypass). This chapter also provides snapshots of configurations/logs/sniffer captures and other pertinent technical information.

Chapter 6 – Consolidated Services explains a set of IPv4 Junos® services (CG-NATv4/ALGv4/LB (ECMP) /FW/HA) supported by and validated on the MX Series 3D Universal Edge Routers platform in Services Delivery Gateway, Phase 1. This chapter also provides snapshots of configurations/logs/sniffer captures and other technical details.

Chapter 7 – Juniper Mobile Video Optimization Solution provides an introduction to challenges surrounding mobile video, as well as a high level view of the key components and features involved in Juniper Mobile Video solution. This chapter provides details on key mechanisms, a couple of generic overall call flows and configuration principles used during the functional validation testing.

Appendix A – Juniper Networks Products describes the key Juniper Networks products used in testing and validation.

Appendix B – References lists all external references

Appendix C – Acronyms provides alphabetical list of acronyms used in this handbook.

Please send us your feedback or ideas that you would like to see covered in future revisions or in other validated solutions books at: [email protected].

Any references or hints alluded to in this book regarding information related to future possible features, or enhancements is subject to change at any time, without notice, except in the cases where definitive agreements for a potential transaction were made, Juniper Networks provides no assurances, and assumes no responsibility, that future products, features, or enhancements will be introduced into the market.

mailto:[email protected]

Chapter 1 – Introduction 1

Chapter 1

Introduction

This chapter provides a high-level overview of the growing multitude of challenges that mobile wireless operators face, thereby creating potential for Juniper Networks to insert into the mobile packet core without disrupting the core, and in turn, help open the doors for Juniper’s MobileNext product portfolio sales and opportunities.

2 Services Delivery Gateway Solution

Services Delivery Gateway is a next generation services solution framework put forward by Juniper Networks to address a set of converging, simultaneous challenges that mobile operators currently face. Juniper Networks embarked on an overall effort in 2010 to develop a product portfolio and series of partnerships to position itself as a significant player in the mobile packet core industry. As with any attempt to break through new territories, there are multiple ways to vector into this market space. The Services Delivery Gateway is one of the initiatives in that direction. The Services Delivery Gateway runs on the same platform as the Juniper Networks Mobile Broadband Gateways (MBGs). It is projected as a way to penetrate the mobile packet core leveraging pure IP play from Juniper Networks to possibly enable the insertion of Juniper’s MobileNext product line in the near future.

This chapter presents:

• Challenges facing Mobile wireless providers.

• Services Delivery Gateway business value proposition.

Mobile wireless service providers face challenges in addressing the ever increasing demand for bandwidth generated by multimedia, data-enabled handheld devices. Smart phones have become an integral part of present day generation’s way of life and the penetration rate of such devices is reaching exponential proportions in an attempt to satisfy the seemingly unquenchable demand from the masses across the globe. Essentially, smart phones are no longer restricted to a selected few but have become a commodity that is in common use today. Certain high-payload applications such as video streaming are now in common use, growing rapidly and perceived as commodities. All these trends which are simultaneously happening, impact existing mobile operators’ infrastructure. The following outlines four popular trends that significantly impact mobile wireless industry.


Handheld Devices Increase

As shown in Figure 1.1, current sales of handheld devices exceed PC/laptop sales, as indicated in “The New World Order” report from RBC Capital Markets.

Smartphone (premium device) Sales to End Users

Source: Gartner, Inc. report, Forecast:Mobile Devices Worldwide, 2008-2015, 1Q11 Update (March 2011)

600

2008 2009 2010 2011 2012 2013 2014

700

100

200

300

400

500

0

Global Data-centric Smartphone Shipmentsto Exceed PC Shipments by 2011

Source: RBC Capital Markets estimates

300

350

2005A 2006A 2007A 2008A 2009E 2010E 2011E

400

50

100

150

200

250

0

PC’sSmartphones

Sh

ipm

en

ts (

MM

)

2008: 251,898,870

2009: 284,938,440

2010: 268,721,350

2011: 366,214,680

2012: 454,895,000

2013: 555,393,710

2014: 670,322,860

Figure 1.1 Smartphone market

Data Growth Increase

The keynote from Kris Rinne, SVP, AT&T at 4G world “4932% wireless data growth over last 12 quarters” is a prime example of the impact of data traffic on the network. Mobile video traffic , using HTTP streaming, is forecast to consume as much as 60% of the mobile capacity in a 4G world. Video is a key driver of mobile network capacity investment. Profitably managing video is critical to mobile operators.

Figure 1.2 Data traffic HTTP streaming


Depletion of IPv4 Addresses

For quite sometime now the industry has been talking about the advent of IPv6. There are only 15% of IPv4 addresses remaining. It is projected, and already established for some geopgraphical areas, that no new IPv4 addresses will be available by the end of 2011. The increase of handheld devices for Human to Human (H2H) communciations, as described in Figure 1.1 is significant and plays a key role for IPv6 requirement. This need will be compounded by the rise of the machines, another market segment related to Machine to Machine (M2M) or Machine-Type Communciation (MTC), leading to the Internet of things (as opposed to humans). All this does not mean IPv4 networks and applications will stop working. It simply means that the end points, the infrastrucutres and applications must be IPv6-aware to first coexist with IPv4 and then to migrate and transition to IPv6. IPv6 is now a reality.

Figure 1.3 IPv4 address depletion (Source: ICANN)


Siloed Services

Because many services and functions are currently distributed in a complex manner and are difficult to manage across multiple network elements, existing siloed services are expensive to operate.

MPLSBACKBONE

SERVICECOMPLEX

ENTERPRISE

INTERNET

Video Opt, WAP,GW, Proxy, etc.

(s)Gi

(s)Gi

NAT

NAT

Firewalland IPS

Firewalland IPS

Router

PE Router + IPSecfor Business Customers

BorderGateway

Router

BorderGateway

Router

MobileGateway

VPN

Figure 1.4 Siloed existing services northbound of (s)Gi

Challenges Summary, Operators’ Needs, Services Delivery Gateway Value Proposition

In summary, mobile operators face the following challenges:

• Growth curve: Mobile packet gateway capacity offering to keep pace with the demand for subscriber density and data bandwidth.

This growth is clearly evidenced in the article, “AT&T CTO: Throw Moore’s Law out, rethink networks”. John Donavan, CTO of AT&T quotes, “The capacity we carried in 2008 will be a rounding error five years out,” he said. “Our 2-[gigabit-per-second] backbone lasted seven years. Our 10-gig lasted five. Our 40-gig will last three. You get to 100 gig, what’s that – 18 months? At 400 gig, I think routers melt. The finance [department] likes liquid assets, but I don’t think that’s what they have in mind.” This is exactly the predicament that major tier-1 mobile operators are currently facing,

• Subscriber growth: exponential growth for both H2H and M2M communications.

• IPV6 coexistence and transition: now a reality.

• Multimedia traffic: Most data traffic will be related to mobile video streaming.

Mobile operators seek the following:

• Offload services to maximize investment on existing deployed mobile packet gateways.

• Consolidate diversified/distributed services to simplify current backend neworks and prepare for IPv4/IPv6 transition.

• Provide overall multimedia optimization to delay/save RAN CapEx investment.

All the above key drivers, provide Juniper Networks an opportunity to propose and to insert the Services Delivery Gateway.

http://connectedplanetonline.com/service_delivery/news/moores-law-out-rethink-networks-1021/

http://connectedplanetonline.com/service_delivery/news/moores-law-out-rethink-networks-1021/


• To minimize cost, complexity, and easier growth by consolidating legacy service complexes into a single platform

• To provide Multimedia optimization complex, initialy mobile video, to decrease load in the RAN and to allow for CapEx deferals.

• To provide traffic steering capabilities to simplify and to minimize cost of APNs provisioning

• To consolidate and to chained services into one MX Series.

• To enable readiness towards IPv6 transition and migration.

• To provide a UE DNS service complex allowing cahce resolving function.

• To leverage common key enablers, such as Subscriber Profile, Identity & Policy, Network state information, Application detection (5 tuples, DPI...), Proxy (tcp, http), Parsing (http..)- to enable value added services from a single location.

Services Delivery Gateway’s framework provides the foundation for next generation services with the following value proposition:

• Insertion point into wireless mobile packet core.

• Leverages existing MX Series deployment.

• No Interoperability issues.

• Dramatically reduces the number of boxes/appliances in the network.

• Reduces footprint, latency, power, cooling, cabling, etc.

• Fewer failure points.

• Saves CapEx by consolidation of services function.

• Saves OpEx by using the same management system.

• Improve subscriber Quality of experience.

• Future proof solution .

• Service consolidation on the Services Delivery Gateway increases service resiliency and delivers up to 50% total cost of ownership savings.

Roadmap/Phases

Services Delivery Gateway has moved from a concept to a product solution offering. For further details on roadmaps, please contact directly the corresponding PLMs in the respective BUs or your sales representative.

For overall Juniper statement of product directions (SOPDs) please contact your sales contact.

Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services 7

Chapter 2

Services Delivery Gateway Framework and Foundation for Next Generation Services


This chapter describes the positioning of Juniper Networks MX Series 3D Universal Edge Routers as a Services Delivery Gateway, introduces the concept of services that can be offered by the MX Series 3D and highlights the subset of the currently available services that were validated as part of Services Delivery Gateway, Phase 1 effort. Essentially, this chapter describes in detail the following:

• Services Delivery Gateway framework and foundation for next generation services.

• How services are implemented.

• Currently available services.

• Validated services (a subset of the available services) in the initial phase of Services Delivery Gateway.

Services Delivery Gateway Framework Overview

The concept behind Services Delivery Gateway framework is to provide an overall services umbrella that runs on Juniper Networks MX960, leveraging the Multi Services-Dense Port Concentrator (MS-DPC), the Junos Software Development Kit (SDK) and external, third-party platforms and applications. Juniper’s goal is to run these services in either standalone mode or concurrently in the same chassis or blade. The idea is to leverage this concept as a possible insertion point to help penetrate the mobile packet core to position Juniper’s broader mobility product portfolio, and in particular position the Mobile Control Gateway (MCG) and Mobile Broadband Gateway (MBG) as part of the MobileNext initiative.

To achieve this goal, an overall cross-functional team (effort in Juniper Networks spanning multiple Business Units/Business Groups and also leveraging our ecosystem partnership) is already underway. Conceptually, the framework can be seen as a three-step process:

1. Services consolidation (chaining with next hop routing)

2. Chained services

2. Interactive chained services.

Services Delivery Gateway applies IP router based services on the path of the traffic that leaves the northbound interface from Gateway GPRS Support Node (GGSN)-(Gi) or Packet Data Network Gateway (PGW)-(SGi). Services Delivery Gateway processes IP flows. Although the primary target insertion point is geared towards mobile core -not only 3GPP but also 3GPP2 or WiMAX (802.16e/m)-, since Services Delivery Gateway treats IP flows, it does offer the possibility to become agnostic to access technologies either wireless or wireline, As a matter of fact, Services Delivery Gateway router based services are already deployed in some wireline networks jointly with Juniper Broadband Network Gateway (BNG). It should be noted though Juniper Mobile Video Optimization only apply to wireless networks (3GPP, 3GPP2, WiMAX).Figure 2.1 depicts the Services Delivery Gateway solution components.


EN

D T

O E

ND

MA

NA

GE

ME

NT

IP BACKHAUL

MX Series

BX7000

EX3200

END TO END SECURITY

MX Series

T Series

SRXSeries

SDG

RADIO ACCESS

2G/3G/LTE

WiMAX

WiFi

JUNOS PULSE JUNIPER MOBILE CORE

S-GWPDG

SGSN/MME

Identity and Policy

Management

P-GW/HA/GGSN

DATA CENTER/NGMSOCLOUD NETWORKING

JAS

Junos SpaceCarrier Grade NAT

Media FlowTra�c Direct

Firewall and IPS

DNS

Junos SDK Openwave So�wareRadware So�ware

Partners

Openwave(video op. phase 1)

Radware

PSG

MX SeriesMS-DPC

Customer Input

MX Series

Services Delivery Gateway

Figure 2.1 Services Delivery Gateway solution components

As previously stated, Services Delivery Gateway is a cross-functional team initiative and the different parties involved and their respective roles are as follows:

• Juniper’s Platform System Groups (PSG) provides the hardware hosting Services Delivery Gateway software functionalities. More information on the MX can be found at http://www-int.jnpr.net/ipg/products/mx-series/

• Juniper’s Junos Application Software (JAS) includes most of the BUs involved in the Services Delivery Gateway effort.

- RSBU for Junos services.

- CMBU for caching function.

- MBU for mobile video and subscriber management.

• Strategic alliances for developing ecosystem partnership

• Device and Network Services group (DNS) providing Junos SDK (software development kit) toolkit for open API to facilitate full partner integration to provide value added services.

http://www-int.jnpr.net/ipg/products/mx-series


The Juniper CTO team as well as sector marketing, and key team members from account teams funneling customer requirements also play a key role in the definition and refinement of the Services Delivery Gateway.

Role of the Junos Software Development Kit

Overall, Juniper Networks advocates an open architecture, open network and an open API. The following quote is from Pradeep Sindhu, Vice Chairman, Chief Technical Officer and Founder.

“Junos is the software foundation for our products. For us to continue to win in the marketplace, we need to improve the rate of feature development in Junos while simultaneously improving the quality with which these features are delivered. The only way to do this is to follow a strict development methodology where the internal structure of Junos is partitioned along carefully defined lines into a set of relatively independent components with clean, well-defined, and stable API’s. An internal version of the Junos SDK will be a key part of this development methodology, so product teams should make every effort to learn the SDK and attempt to use it whenever they can.

We have aspirations to provide Junos as a platform for others to write software on top. We need to start by becoming internal consumers of this platform first.”

Some Business Units already initiated the process towards building their product portfolio and leveraging the SDK. For further details concerning the SDK, refer to Junos SDK.

The Juniper family of SDKs includes the following products:

• Junos SDK (Routing Engine (RE), Services, Virtual Execution Environment (VEE))

• Junos Space SDK

• Junos Pulse SDK

In the first release, only the Junos SDK has been employed with Services Delivery Gateway. Services Delivery Gateway leverages some services implemented through Juniper’s Junos SDK. The following section describes the Junos SDK.

Junos SDK (RE and Services) Description

The traditional Junos SDK for router provides the RE SDK and Services SDK. Figure 2.2 illustrates the physical location of the RE and Services SDK.


Support on M, MX, T, SRX, JCS

Control Plane Apps Perform:

RE SDK

UI

Management

Signaling

Servers

Service Coordination

Support on MS PIC and MS DPC (M, MX, T)

Service Plane Apps Perform CustomizedPacket Processing and Monitoring

SERVICES SDK

Figure 2.2 Physical location of RE SDK and Services SDK

Figure 2.3 illustrates the overall Junos OS architecture. Note the separation among the control plane (Routing Engines), data plane (Packet Forwarding Engine), and service applications plane (MS-DPC).

Routing Engines−Control Plane

Packet Forwarding Engine−Data Plane

Service Modules−Services PlaneI/OModules

I/OModules

Tra�cTra�c

Service Applications

Built with the Services SDK

Applications User InterfaceExtensions

Built with the RE SDKBuilt with the RE SDK

Figure 2.3 Junos OS architecture with SDK


The control plane primarily manages and controls the behavior of the device including the other two planes. To do this, it is critical that it has a global view of the device hardware and software. It also manages the user interface.

Many Juniper Networks products have REs that are hot-swappable physical modules within the chassis. There is often a chassis option for a redundant RE backing up the master as well. A master RE must always be present as this is the primary location of the control plane software that controls the rest of the device. The RE SDK APIs are tools to build applications to extend the control plane software on the RE. Because an RE is always present in any device, RE SDK-based applications are always deployable without additional hardware or software.

The data plane spans many aspects of a device’s chassis and its modules. In Juniper Networks specific terms, it is collectively referred to and abstracted as the Packet Forwarding Engine (PFE), and comprises of ASIC-based hardware and Junos OS microcode to perform packet processing which is generally stateless. Aiming to perform at fast wire speeds and within its hardware resource limits, the PFE generally defers stateful packet processing to the services plane.

Today, Junos SDK applications do not run in the data plane, but they can certainly influence the packet processing in the data plane by using APIs from an application running in the control or services plane.

The services plane can be thought of as an extension to the data plane to perform stateful services and any services non-native to the PFE. By now you understand that applications built with the Junos SDK can run on either a Routing Engine (RE) or a services module.

Junos SDK Virtual Execution Environment

The Virtual Execution Environment (VEE) is a new module of the Junos SDK. The VEE enables simpler, faster, and cheaper integration of non-Junos third-party as well as Juniper internal applications with the Junos software. It supports application integration across multiple hardware integration models, for example blades in the router, a standalone appliance, or a cloud-based solution.


KVM/CentOS

Processing Complex

Juniper Router

Tethered Appliance or Blade Extension

WindowsLinux

VEE Agent VEE Agent

App App

Juniper Provided Environment

Junos SDK Information

VM Creation Information

Mirrored or Inline Data Tra�c

App Specific Information

VEE Broker

SDK VMMController

SDK VMMClient

MGD

RPD

.....

RE

PFE

Figure 2.4 Junos SDK VEE

Junos Space SDK, Junos SDK (RE, Services), as well as its new module VEE will play a key role on how the required third party applications are integrated (beyond integration by the wire). The former, traditional Junos SDK, requiring the partner application would have to be fully ported to the Junos operating system. The latter, VEE, allows partner applications to run in their native environment without requiring any porting while providing mechanisms (like Hypervisor) to integrate with the Junos platform.

As such, all services especially those leveraging third parties, may not be physically integrated for initial go-to-market purposes or thereafter, depending on the SDK flavor, if used, and business needs. Such services would be running on adjacent platforms, creating thus a specialized service complex that can be collocated with the Services Delivery Gateway. Services Delivery Gateway, Phase 1 includes two of those specialized service complexes:

• User Equipment (UE) DNS

• Juniper Mobile Video Optimization (JMVO).


Proposed Services Delivery Gateway Services

In addition to routing, a certain number of services have been identified, categorized and advertised as part of the Services Delivery Gateway solution framework, as illustrated in Figure 2.5.

All Functions Consolidate Into One Gateway

Save on Space, Power, Cooling, Network Management, Vendor Management

More Resilient and Less Expensive

Subscriber ManagementTrac Direct

PE Router/VPNLoad Balancing

Firewall/IDPCGN/NAT

Multimedia OptimizationIPSec/VPN

Top SDG Services Interactive Chaining

Tra

c D

irect

PE

Ro

ute

r

Fire

wa

ll

IPS

CG

N N

AT

AL

G

Laptop

Smart Phone

Feature Phone

MPLS BACKBONEMOBILE CORE(s)Gi

GGSNPGW

Services Delivery Gateway(based on the MX Series)

SERVICE COMPLEX

ENTERPRISE

INTERNET

VPN

UE DNS Complex

DNS Partner

Juniper Mobile Video Optimization Complex

Optimization Engine Cache

Figure 2.5 Services Delivery Gateway services overview

As previously mentioned, Services Delivery Gateway, Phase 1 focuses on the consolidated services aspect. Subsequent phases will review chained services and the interactive aspect of chained services. Currently, the interactive aspect of chained services is only a concept that has yet to materialize. A service may include different options (load balancing through ECMP or Juniper ADC) or can be a service umbrella itself (CG-NAT (NAT44, NAT64, DS-lite….etc.), Multi-Media Optimization (Web, Video, etc.). Subscriber management1 as a whole scalable service from Services Delivery Gateway is still being defined.

1Subscriber management service refers to the ability of Service Delivery Gateway to be subscriber aware in a scalable way and in line with standards. This service is still being defined and includes capabilities, such as Radius proxy or endpoint, Gx like/Sd reference point support for interaction with a PCRF entity. In case of MVO, subscriber-awareness decision in Services Delivery Gateway, Phase 1 is left for the MVO complex to handle. Note that Traffic Direct service is subscriber aware through DSA and is proprietary to Juniper JGx (diameter application Id 16777273) interface. This allows for scaling of up to 400k subscribers and requires a policy control network element that understands JGx. For more information on how Services Delivery Gateway fits into the current standard policy framework and how to preposition Service Delivery Gateway as a Traffic Detection Function (TDF), see Chapter 3.


Implementing Services Delivery Gateway Services

At a high level, services in Services Delivery Gateway can derive from two primary sources:

• In-house Junos services.

• Third party for value-added services VAS.

Figure 2.6 illustrates the current router-based services landscape.

MS-PIC/MS-DPC INLINE

Trio OnlyOFFLOADServices SDKUkernel

TodayHomeGrown

Services

SFWL2 +

TunnelCGN IPsec

OEM+

fromotherBUs

Mon.(TePM,

eRM)ADC SFW DPI

TrioandDPC

Long-lived

Sessions13.1

JFlowtoday

12.2More

Services

Figure 2.6 Router-based services landscape


In the initial phase, the router-based services landscape, as shown in Figure 2.6, can be categorized as follows:

• Using a service module (MS-DPC/MS-PIC)

- Micro-kernel enabled services (non subscriber aware services)

• Stateful Firewall

• Carrier Grade NAT + v4 to v6 transition methods

• L2 services + tunneling

• IPSec

• JFlow v9 + RPM time stamping

• Flow monitoring services (Tap and CALEA)

• SDK-enabled services (subscriber aware services)

- Partner developed services

• StreamScope eRM for Video Monitoring, MPEG analysis

• TePM for VoIP and Network monitoring

• ADC for intelligent load balancing

- Juniper developed services

• Deep Packet Inspection Technologies (Application Awareness (AppID + Application ACL, from SBU)

• IDP/IPS (from SBU)

• Web Redirect + HTTP rewrite + DNS.

• DSA, NAT44, ALGv4, SFW.

• RE (Routing Engine) enabled services

- Video optimization

• Inline, MX 3D-only (Trio)

- Some services can be performed in the forwarding plane without the need for a service module. These include:

• JFlow v10

- Inline services provide:

• A less expensive method of implementing services, as it does not require an MS-DPC.

• Services can be performed at line rate, but the types of services are limited to non-stateful applications.

NOTE: Offload is currently not supported.


In-house Junos Services

The RSBU on the JAS branch provides most of the in-house Junos services. The RSBU Junos services are categorized into two modes:

• Microkernel (non subscriber aware services)

- Allows services consolidation.

• SDK Services (subscriber aware services)

- Plug-in/shared mode: allows chained services.

- Exclusive mode: requires a complete service blade.

With the current implementation landscape, the two modes must run on separate Network Processing Units (NPUs). Services offered in plug-in mode, as shown in Figure 2.7 can be chained within the same NPU. Services (only a subset of the overall services suite) available in plug-in mode are currently IPv4-based and include DPI, DSA, NAT44, ALGv4, SFW, and IDP.

Plug-in Manager Process

JunosPackets In Packets Out

Service 1 Service 2 Service n-1 Service n

Figure 2.7 Services SDK Plug-in Mode allows service chaining

The services offered in the other two modes (Microkernel – non subscriber aware services, Service SDK exclusive – subscriber aware services) cannot be chained unless next-hop routing across the different blades within the chassis (inter-blade) or between NPUs within a service blade is implemented, as shown in Figure 2.8.


6

5

VRF 1 VRF 2

Next Hop

PFE – Trio-based

Service nService 2Service 1

1

7

2 4 6

3 5

Service is delivered and routed backto the PFE (output service I/F)

Secondary service is tied to the sameVRF (1) and routed across to the second service-card/NPU (output I/Fand input I/F share the same VRF (1))

Repeat the same process (using a di�erent VRF (2) on the PFE)

Packet from 3rd service is routed tothe outbound I/O

Packet from I/O routes on the PFEto the services PIC using next-hopservice-set (input service I/F)

1

7

2

3

4

Figure 2.8 Service consolidation –chaining with next hop routing

NOTE: Microkernel Carrier Grade Nat (CGN) and Stateful Firewall (SFW) can be consolidated/chained on the same NPU.

NOTE: Currently, Microkernel or Services SDK (exclusive mode) is recommended to meet scaling needs for tier one operators.

NOTE: Not all service chaining combinations work today, and some sequences are not meaningful. The following services can be chained across the backplane in a meaningful way: SFW + CGN, SFW + ADC/SLB, IPSec + ADC/DPI, JFlow with any service. Please note, upon failure the service chain will be broken.

The overall intention is to port all services through Services SDK. A few services, although available through Services SDK, still might need to be in the Exclusive mode, which is the case for the upcoming Application Delivery Control (ADC) load balancing feature that leverages the Radware functionality. Services Delivery Gateway services, leveraging service-SDK, require the MS-DPC service blade.

As explained previously in this chapter, RE SDK represents another type of SDK. In Chapter 7, Juniper Mobile Video Optimization Solution we explore how RE SDK is leveraged for JMVO.

Partnership for Value Added Services

Juniper will partner with best-in-class third party vendors for services required to address mobility vertical opportunities. These additional features can be initially integrated loosely as an external platform or can be integrated through SDK (RE, Services and VEE). Third parties may require plug in into Junos Space as well.

Multi-Media Optimization (MMO)

Juniper officially announced a partnership agreement with OpenWave Systems, Inc. during the Mobile World Congress 2011 in Barcelona, Spain to provide an optimization solution for the mobility market. The initial focus for this service umbrella pertains to the Juniper Mobile Video Optimization Solution (JMVO).


JMVO also offers cached content capability and leverages a Juniper in-house caching solution from the CMBU through the Media Flow Controller. JMVO leverages the RE SDK by enabling key new functionality developed by Openwave to run on the Services Delivery Gateway platform. It is envisioned that additional capabilities around analytics, add insertion and monetization will be considered in the near future.

Application Delivery Control (ADC)

Juniper is bringing to market a load balancing function for Application Delivery Control (ADC) on the MS-DPC service blade.

DNS Partner for User Equipment

At the time of publishing of this handbook, Juniper is considering partnering with DNS vendors to satisfy the requirement of UE DNS service. Bringing in a DNS vendor is expected to provide the option to leverage as an example, among other things, their own security framework for IDP and DNS protection. It does enable the operator to improve user experience by providing DNS cache resolver function.

Services Delivery Gateway, Phase 1 Services

Services Delivery Gateway Phase1 validation focuses on the following major topics:

• Step 1 of the framework and delves further into the consolidation of key, identified services (based on Microkernel – non subscriber aware services) as being currently driven by the requirements from a major tier 1 mobile wireless operator.

• The exploratory testing and validation effort that was executed for Traffic Direct service leveraged DSA that was implemented in plug-in mode and leverages Juniper’s Diameter interface.

• The functional testing and validation results that were executed for Juniper Mobile Video Optimization.

See Chapter 5, Traffic Direct and Chapter 6, Consolidated Services which summarize the validation efforts. In particular, Chapter 6 specifically addresses the following topics:

• CE routing instances.

• CG-NAT (IPv4).

• ALGv4 (SIP, DNS, FTP, RTSP, HTTP).

• Stateful Firewall (SFW) (IPv4, IPv6).

• Load Balancing (ECMP, RPM probes).

- To DNS service complex.

See Chapter 7, Juniper Mobile Video Optimization Solution for functional validation details.

Chapter 3 – Policy and Charging Control Standards Perspective 21

Chapter 3

Policy and Charging Control Standards Perspective

This chapter discusses the policy and control aspect of 3GPP architecture and provides a context as to how the Services Delivery Gateway fits into the Policy and Charging Control (PCC) framework. This chapter describes:

• 3GPP policy architecture.

• Current Services Delivery Gateway subscriber awareness capability leveraging Dynamic Subscriber Awareness (DSA) for traffic direct.

• Inserting and positioning Services Delivery Gateway as a pre-TDF.

One of the key goals of this chapter is to present a scenario where Services Delivery Gateway itself can become a full-fledged 3GPP network element known as the TDF. TDF is fast becoming an important functional entity in the 3GPP PCC reference architecture as the place for application detection and as a means to subject traffic to specific policies as decided by the PCRF.


3GPP PCC Architecture

Evolved Packet System (EPS) reference architectures (3GPP TS 23.401 for 3GPP access or 3GPP TS 23.402 for non-3GPP access) use the PCC framework, as defined in 3GPP TS 23.203.

Evolved Packet Core (EPC) Packet Data Network (PDN) gateway (PGW) hosts the Policy and Charging Enforcement Function (PCEF) and communicates, using the diameter protocol to the Policy and Charging Rule Function (PCRF) through a Gx reference point, as specified in TS 29.212.

Gateways, such as Bearer Binding and Event Reporting Function (BBERF) can also communicate with a PCRF through the GxX (Gxa, Gxb, and Gxc -if based on PMIPv6-) interfaces.

The PCRF can receive trigger events from the Application Function (AF) through Rx and access the Subscriber Profile Repository (SPR) through the Sp reference point. Figure 3.1 represents a non-roaming EPS architecture.

3GPP Access

GERAN

EVOLVEDPACKET CORE

2G / 3G

LTE

UTRAN

E-UTRAN

IPServices

UnTrustedNon-3GPPIP Access

TrustedNon-3GPPIP Access

S1-MME(S1-AP)

S3 (GTP-C)

S4 (GTP-C, GTP-U)

S12 (GTP-U)

Iu up (GTP-U)

Gn (GTPc, GTPu)

S13SBc

S2cUE

UE

Gn

SGs, Sv

S1-U(GTP-U)

S10(GTP-C)

S11(GTP-C)

S101S102

S103

X2

S9

S5 (PMIPv6.GRE)

S2a(PMIPv6, GREMIPv4 FACoA)

S2b(PMIPv6, GRE)

S5(GTP-C, GTP-U)

S2c (DSMIPv6) S2c

SWaSWh

SWm

SGi

S6b

Gxb

Rx

Gxa

Gxc

S6a

SWx (Diameter)

Gx

STa (Radius, Diameter)

SWu (IKEv2,MOBIKE, IPSec)

CBC MSC EIR

eNodeB

HSS

PCRF

ServingGateway

GGSN/PDNGateway

AAA

pre-R8SGSN

R8SGSN

ePDG

MME

Figure 3.1 EPS reference architecture non-roaming

Figure 3.1 shows how the mobile gateways interact with the PCRF. Interaction with PCRF can occur both in a roaming and non-roaming scenario. Based on the previously mentioned description regarding the location of Services Delivery Gateway (northbound of GGSN/PGW on (s)Gi), Services Delivery Gateway can interact with a PCRF similar to other mobile gateway interaction.


Services Delivery Gateway and 3GPP PCC Architecture

Although Juniper intends to offer subscriber management service through Services Delivery Gateway, the Services Delivery Gateway in its current state is not subscriber aware as per standards (see footnote 1 in Chapter 2) unless it terminates specific required protocols.

However, the Services Delivery Gateway with Traffic Direct service leveraging Dynamic Subscriber Awareness (DSA) provides a diameter interface that can communicate to a PCRF-like entity to provide dynamic policy rules capabilities. Testing has been done in 2010 with Juniper Networks in-house Session and Resource Control (SRC) component to provide some level of dynamic policy control capability (see Chapter 5). In this respect, the SRC can be seen as a lightweight pre-PCRF.

The DSA application is a Juniper Networks Diameter application registered with the IANA (http://www.iana.org) as Juniper JGx, with an ID of 16777273.

Figure 3.2 illustrates an example of Services Delivery Gateway deployment connected to an EPC core.

IP ServicesE-UTRAN

S1-MME(S1-AP)

S11(GTP-C)

S10(GTP-C)

S3(GTP-C)

Gn (GTP-C)Gn

(GTP-C, GTP-U)

S5/S8 (GTP-C, GTP-U)S1-U (GTP-U)

X1, X2, X3 SBRGa/Gz (GTP)

Iu up (GTP-U)

S4 (GTP-C, GTP-U)

S12 (GTP-U)

S13 S6a

Gi/SGi

Gx Rx

JGx

S9

Sp

SBc

X2

eNodeB

pre-R8SGSN

3GPPAAAOFCS

Partner

HSSEIRCBC DNS

MVOComplex

UE DNSComplex

R8SGSN

SGW

Juniper

GGSN/PGW

MMES2c

UE

LI

PCRF

SPR

AF

UTRAN

GERAN

Services DeliveryGateway

SRC

Figure 3.2 Example of Services Delivery Gateway deployment connected to EPC core

Figure 3.2 shows two policy control network elements (SRC and PCRF). If convergence towards PCRF is needed, it therefore might be a natural course of action to take in order for Services Delivery Gateway to interact with PCRF. However, although Juniper announced a partnership with key PCRF vendors, they do not support Juniper’s current diameter application (JGx), and similarly Juniper currently


does not support the standardized reference point Gx. Traffic Direct validation testing also identified the scaling limitations of DSA in its current capability/implementation.

Presently, these limitations influence where policy decisions occur for the initial JMVO solution. The interaction with the policy control entity directly from Services Delivery Gateway is not being considered and the decision to opt in or out and the per user optimization policy is left to the optimization complex that will perform the PCRF query or Master Integrated Network Directory (MIND) dip.

Traffic Detection Function in 3GPP TS 23 .203 .b

In terms of possible positioning with Services Delivery Gateway, another aspect to consider is the functional similarities between existing Traffic Direct services (see Chapter 5, Traffic Direct Overview) with the TDF functional block stated in 3GPP 23.203 R11. See Figure 3.3.

Gxx Gx

Rx

Gy

Gz

Sd

SpOnline Charging System (OCS)

Service Data FlowBased Credit Control

O�ineChargingSystem(OFCS)

GATEWAY

PCEF

BBERF TDF

Policy and Charging Rules Function(PCRF)

Subscription ProfileRepository

(SPR)AF

Figure 3.3 3GPP 23.303.b01 PCC logical architecture (non-roaming)


The following information is referenced from section 6.2.9 of the 3GPP TS 23.203 document concerning the TDF function.

Traffic Detection Function (TDF)

The TDF is a functional entity that performs application detection and reporting of detected application and its service data flow description to the PCRF.

For those cases where service data flow description is not possible to be provided by the TDF to the PCRF, the TDF performs:

• Gating

• Redirection

• Bandwidth limitation for the detected applications.

For those cases where service data flow description is provided by the TDF to the PCRF, the actions resulting of application detection may be performed by the PCEF as part of the charging and policy enforcement per service data flow and by the BBERF for bearer binding, as defined in this document or may be performed by the TDF.

The PCEF can be enhanced with the TDF capabilities as specified in Clause 6.2.2.1.

Editor’s Note: It is FFS how the interaction between TDF and usage monitoring control functionality is implemented.


Insertion Point Story Line—Services Delivery Gateway as a Pre-TDF Network Element

The function provided by Services Delivery Gateway with Traffic Direct is in-line with the description of TDF. Therefore, the concept of positioning Services Delivery Gateway as an insertion point into the mobile packet core becomes all the more valid and there is the option to position Services Delivery Gateway as an early TDF function or pre-TDF function, until full subscriber management service becomes a reality. Therefore, it is conceivable in the future to have the Services Delivery Gateway implement a Gx-like reference point to interwork with a PCRF and/or the Sd reference point.

As illustrated in Figure 3.4, 3GPP has defined the PCRF discovery and selection leveraging the concept of Diameter Routing Agent (DRA) in TS 23.203 (PCC framework) based on RFC 3588 diameter agent proxy and redirects a functional description, unless notified otherwise in 3GPP TS 29.213.

Diameter (PCRF) Realm

Non-3GPP GW

ePDG

AF

TDF (SDG)

SGW

PGW

PLMN

PCRF

Diameter (PCRF) Realm

DRA

PCRF

Gx, Gxa, Gxb, Gxc, Rx, Sd

DRA

Figure 3.4 PCRF selection and discovery using DRA

The following quote is from TS 23.203:

“In order to ensure that all Diameter sessions for Gx, S9, Gxa/Gxc and Rx for a certain IP-CAN session reach the same PCRF when multiple and separately addressable PCRFs have been deployed in a Diameter realm, an optional logical “Diameter Routing Agent (DRA)” function is enabled. This resolution mechanism is not required in networks that utilise a single PCRF per Diameter realm”

The DRA functionality should be transparent to the Diameter applications used on the Gx, Gxa/Gxc, S9 or Rx reference points.

Services Delivery Gateway, positioned as a pre-TDF, will enhance Juniper Networks Mobile Broadband Gateways product portfolio on the MX Series 3D Universal Edge Routers by supporting all major 3GPP gateways.

Chapter 4 – Architectural Approach 27

Chapter 4

Architectural Approach

This chapter discusses the overall architectural approach regarding Services Delivery Gateway from both a connectivity and services standpoint.


Services Delivery Gateway Connectivity Overview

Services Delivery Gateway applies IP router-based services on the path of the traffic that leaves the northbound interface from the Gateway GPRS Support Node (GGSN)-(Gi) or the Packet Data Network Gateway (PGW)-(SGi). Because Services Delivery Gateway processes IP flows and although the primary target insertion point shown (Figure 4.1) is geared towards 3GPP mobile packet core, Services Delivery Gateway also can be deployed in 3GPP2 or WiMAX (802.16e/m) packet core networks. Furthermore, because Services Delivery Gateway processes IP flows, Services Delivery Gateway can be applied to both wireline and wireless networks. Thus, it does offer the possibility for Services Delivery Gateway to become access agnostic whether wireless or wireline. Services Delivery Gateway router-based services already are deployed in some wireline networks. However, it should be noted that the JMVO solution only applies to wireless networks, for example 3GPP, 3GPP2 and WiMAX.

Services DeliveryGateway-active

Services DeliveryGateway-standby

(s)Gi

xn xa

xa (LAG)

xn (MC-LAG)

xn

xnxa

xn

CORETo InternetS5, S8, Gn, Gp

GGSN, PGW

Mobile Video Optimization Service Complex

Juniper Mobile Video Optimization Incumbent Solution

UE DNS Service Complex

DNS Partner / Incumbent

Figure 4.1 Services Delivery Gateway connectivity overview

Services Delivery Gateway services umbrella operates on the MX Series 3D Universal Edge Routers, leveraging the Multi Services-Dense Port Concentrator (MS-DPC), in-house Junos services, the Junos Software Development Kit (SDK) and external third party platforms and applications. Offered services can run in


standalone mode or can be consolidated (chaining with next hop routing), as long as the chained combination is meaningful, to concurrently run in the same chassis or blade.

Scaling is achieved by adding MS-DPC blades in the chassis. The combination of consolidated services also dictates the number of MS-DPC blades to be used. For further details, see Chapter 2, Services Delivery Gateway Framework and Foundation for Next Generation Services.

Needed services that are not directly hosted by the Services Delivery Gateway are co-located with the Services Delivery Gateway within the different service complexes to provide specific value-added services. As an example, such service complexes include the UE DNS service complex and Juniper’s Mobile Video Optimization service complex. Some of these service complex functions can be integrated by leveraging Junos SDK capabilities.

Service complexes and packet gateways (GGSN, PGW) attach to active/standby Services Delivery Gateway in VRRP groups leveraging MC-LAG. The Services Delivery Gateway pair connects to the core routers using LAG. Services Delivery Gateway can be deployed to act as a CE or a PE router, with BFD enabled.

Server Load Balancing (SLB) towards service complexes is performed using ECMP. RPM probes are configured to provide server status updates in the complex. An event script or an operational script can be leveraged to take appropriate action upon detection of a status change. Leveraging ADC from MS-DPC is another possible avenue.

High Availability

The architecture supports High Availability in Services Delivery Gateway by leveraging the following MX Series and Junos features and functions:

• Virtual Router Redundancy Protocol (VRRP) for Services Delivery Gateway in active/standby mode

• Link Aggregation Groups (LAG) and Multi-Chassis LAG (MC-LAG)

• Bidirectional Forwarding Detection (BFD)

• Graceful Routing Engine Switchover (GRES)

• Non-Stop routing (NSR)

• In-service Software Upgrades (ISSU)

• Real Time Performance Monitoring (RPM) and event scripts.

The following section presents a high-level description for each of the above-listed functionalities.


VRRP

Virtual Router Redundancy Protocol (VRRP) is a protocol, which operates on routers that connect to the same broadcast domain. VRRP configuration assigns these routers to a group. The grouping eliminates the possibility of a single point of failure and thus provides high availability of network connectivity to the computing hosts on the broadcast domain that do not participate in IGP routing and need a default gateway for connectivity. Routers participating in VRRP share a virtual IP address and virtual MAC address. The shared virtual IP address serves as a gateway to the default route configured on the hosts.

One of the routers is elected dynamically as a primary default of the group and is active at any given time. All other participating routing devices perform a backup role. Operators can assign priorities to devices manually, forcing them to act as primary and backup devices. The primary VRRP sends out multicast advertisements to the backup devices at regular intervals (default interval is one second). When the backup devices do not receive an advertisement for a configured period, the device with the next highest priority becomes the new primary. This process occurs dynamically, thus enabling an automatic transition with minimal traffic loss. This VRRP action eliminates the dependence on achieving connectivity using a single routing platform that can result in a single point of failure. In addition, the change between the primary and backup roles occurs with minimum VRRP messaging and no intervention on the host side.

For VRRP configuration details, refer to VRRP Configuration Hierarchy at www.juniper.net/techpubs/en_US/junos10.2/topics/reference/statement-hierarchy/vrrp-configuration-hierarchy.html.

LAG

Ethernet Link Aggregation Group (LAG) is a feature that aggregates two or more physical Ethernet links into one logical link to obtain higher bandwidth and to provide link redundancy. LAG provides high link availability and capacity which results in improved performance and availability. Traffic is balanced across all links that are members of an aggregated bundle. The failure of a member link does not cause traffic disruption. Instead, because there is multiple member links, traffic continues over active links as remaining bandwidth permits.

For LAG configuration details, refer to Understanding Aggregated Ethernet Interfaces and LACP at www.juniper.net/techpubs/en_US/junos10.0/topics/concept/interfaces-lag-overview.html.

MC-LAG

On MX Series routers, multi-chassis link aggregation (MC-LAG) enables a device to form a logical LAG interface with two or more other devices. MC-LAG provides additional benefits over traditional LAG in terms of node level redundancy, multi-homing support, and loop-free Layer2 network without running Spanning Tree Protocol (STP). The MC-LAG devices use Inter-Chassis Control Protocol (ICCP) to exchange the control information between two MC-LAG network devices.

www.juniper.net/techpubs/en_US/junos10.2/topics/reference/statement-hierarchy/vrrp-configuration-hierarchy.html



www.juniper.net/techpubs/en_US/junos10.0/topics/concept/interfaces-lag-overview.html

www.juniper.net/techpubs/en_US/junos10.0/topics/concept/interfaces-lag-overview.html


On one end of MC-LAG is an MC-LAG client device that has one or more physical links in a link aggregation group (LAG). This client device does not need to be aware of MC-LAG. On the other side of MC-LAG are two MC-LAG network devices. Each of these network devices has one or more physical links connected to a single client device. The network devices coordinate with each other to ensure that data traffic is forwarded properly.

GRES

On the MX Series, Graceful Routing Engine Switchover (GRES) redundancy can be set up if the platform has been deployed with two physical routing engines. One of the Routing Engines functions as the primary, while the other serves as a backup. When the primary Routing Engine fails, the backup Routing Engine automatically becomes the primary Routing Engine, thus increasing the availability of the device.

Any one of the following failures can trigger a switchover from the primary to the backup Routing Engine:

• Hardware failure – a hard disk error or a loss of power on the primary Routing Engine.

• Software failure – a kernel crash or a CPU lock. These failures cause a loss of keepalives from the primary to the backup Routing Engine.

• Software process failure –specific software processes that fail at least four times within the span of 30 seconds on the primary Routing Engine.

For Graceful Routing Engine Switchover (GRES) configuration details, refer to Configuring Routing Engine Redundancy at www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuration/routing-engine-redundancy-configuring.html.

NSR

Nonstop Active Routing (NSR) preserves routing and interface information in a manner similar to graceful Routing Engine switchover. However, compared to graceful Routing Engine switchover, NSR goes a step further and saves the routing protocol information on the backup Routing Engine. It also preserves the protocol connection information in the kernel. Any switchover between the Routing Engines is dynamic, is transparent to the peers and occurs without any disruption to protocol peering. For these reasons, NSR is beneficial in cases where the peer routers do not support graceful Routing Engine switchover.

For NSR configuration details, refer to Configuring Nonstop Active Routing at www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuration/nsr-configuring.html.

ISSU

In Service Software Upgrade (ISSU) facilitates software upgrades of Juniper devices in environments where there is a high concentration of users and business critical applications. Operators can use ISSU to upgrade the software from one Junos release to another without any disruption to the control plane. Any disruption to traffic during the upgrade is minimal.

www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuration/routing-engine-redundancy-configuring.html




ISSU runs only on platforms that support dual Routing Engines and requires that Graceful Routing Engine Switchover and NSR be enabled. Graceful Routing Engine Switchover is required because a switch from the primary to the backup Routing Engine must happen without any packet forwarding loss. The NSR with Graceful Routing Engine Switchover maintains routing protocol and control information during the switchover between the Routing Engines.

For ISSU configuration details, refer to Unified ISSU in the JUNOS Software High Availability Configuration, Release 10.2 at www.juniper.net/techpubs/en_US/junos10.2/information-products/pathway-pages/high-availability/high-availability.html.

RPM, Automation Scripts

Real-time Performance Monitoring (RPM) can detect when a server failure occurs. RPM probes also track round trip times, along with jitter and latency to be calculated by being carrying within Internet Control Message Protocol (ICMP) and User datagram Protocol (UDP) echo and time stamp, HTTP Get, and TCP connection messages. For configurations where RPM probe replies are not available (next hop does not support RPM), only RTT and next-hop availability are supported.

For more information on Real-Time Performance Monitoring (RPM) on Juniper Networks devices, refer to Real-Time Performance Monitoring on Juniper Networks Devices application note at www.juniper.net/us/en/local/pdf/app-notes/3500145-en.pdf.

Automation scripts can redirect traffic when a failure occurs. Event scripts allow a RPM response state to trigger alternate next hops. SLAX (Stylesheet Language Alternative Syntax) is a language for writing Junos automation scripts and is an alternative to Extensible Stylesheet Language Transformations (XSLT). Although SLAX has a distinct syntax, it has the same semantics as XSLT.

For more information on scripting refer to www.juniper.net/us/en/community/junos/script-automation/.

Generic Logical Flow Concept

As illustrated in Figure 4.2, Services Delivery Gateway processes IP flows that travel from packet gateways (GGSN, PGW) through (s)GI interface. IP flows can ingress into the Services Delivery Gateway through VLAN or VRF instances and are applied a policy routing decision. Currently, the routing decision is based on static policy or leverages the intelligent traffic steering for the JMVO solution because DSA cannot be leveraged (see footnote 1 in Chapter 2).

For further details see Chapter 3, Policy and Charging Control Standard Perspective. Ultimately the policy routing function, although not yet available, could be controlled by a PCRF entity through a diameter interface based on Gx or Sd reference point. Similarly Services Delivery Gateway could act as a Radius proxy (Radius Accounting received from packet gateways) or as a Radius end point (Radius messages proxied from the AAA server).

www.juniper.net/techpubs/en_US/junos10.2/information-products/pathway-pages/high-availability/high-availability.html



www.juniper.net/us/en/local/pdf/app-notes/3500145-en.pdf


www.juniper.net/us/en/community/junos/script-automation/

www.juniper.net/us/en/community/junos/script-automation/


CGN/PAT/ALG/FW Public(s)Gi

Private(s)Gi

PolicyRouting

IPFlows

AAA PCRF SPR

Gx, Sd

Sp

INTERNETGGSNPGW

Private Public


LoadBalancing

CGN/PAT/ALG/FW

DNS

Mobile Video Optimization Service Complex

LoadBalancing

CGN/PAT/ALG/FW

OPT

Diameter

Radius

VLAN,VRF

ServicesDeliveryGateway

Figure 4.2 Generic logical flow concept

Traffic based on the policy routing decision is directed towards specific consolidated/chained services and/or services complex. Load balancing based on ECMP or ADC may take place as needed. Depending on the traffic types, certain services are applied. Since the Services Delivery Gateway currently is not subscriber aware (see footnote 1 in Chapter 2), the granularity of optimization per subscriber, per device, per plan, or opt in /opt out decision depends on the Mobile Multimedia Optimization service complex in the initial phase. The optimization complex can act as a radius endpoint, query the PCRF or do a MIND/SPR dip to gain subscriber awareness.

For example, UE DNS traffic can be handled by a specific service complex. When the UE is assigned an IP address and other parameters, it can access services. The first response is a DNS query. The DNS traffic, identifed by the port number, can be steered to the DNS complex allowing the local cache resolver function to improve user experience. If the lifetime has expired, the UE DNS can query the next tiered DNS for resolution. This DNS traffic travels through the meaningful set of consolidated services before moving onto the Internet throug the public SGi/Gi.


Another example of a service complex pertains to traffic that can be optimized, especially HTTP traffic. Traffic identified as using TCP port 80 for which the destination IP is a well-known origin server providing video content, can be steered toward the JMVO service complex. HTTP traffic for nonvideo traffic could be sent to a web optimization service complex, or HTTP traffic as a whole (web, video) could be sent towards a multimedia optimization compex. Non HTTP traffic can be steered to the Internet.

In this chapter, we discussed the architectural approach from both a connectivity standpoint as well as a services viewpoint. In the following chapters, we cover in detail validated scenarios.

• Chapter 6, Consolidated Services provides information on validated scenarios regarding consolidated services based on this approach.

• Chapter 7, Juniper Mobile Video Optimization Solution provides a preview of the JMVO solution and associated intelligent traffic steering functional validation.

Chapter 5 – Traffic Direct Overview 35

Chapter 5

Traffic Direct Overview


This chapter discusses the Traffic Direct service concept and its key components and documents validated use cases.

Introduction

The Services Delivery Gateway provides services on the (s)Gi interface of a GGSN/PGW. It is based on the industry-leading Juniper Networks MX Series 3D Universal Edge Routers running the Junos® operating system. In today’s mobile networks, it is common for operators to deploy a variety of (s)Gi-based services each catering to the requirements of various end systems.. Examples of (s)Gi-based services include networks for laptop dongles, feature phones, smartphones, and enterprise-based services. Access Point Names (APNs) are typically used to steer traffic from a mobile device through the mobile core to the correct Gi network. These APNs can best be thought of as mobile VPNs and were defined by the Third-Generation Partnership Project (3GPP) standards body.

In an APN-based implementation, each mobile device must be configured with the appropriate APN for its device type, class of service, or user group. The mobile device passes this information up to the Serving GPRS Support Node (SGSN) or Mobility Management Entity (MME) when it attaches to the mobile network. The SGSN/MME performs a Domain Name System (DNS) lookup to get the IP address of the GGSN/PGW that is handling that APN. The GGSN/PGW then hands this traffic off to the correct Gi network for final processing.

An essential part of any mobile packet core design is the method by which data traffic is steered as it moves from the mobile device through to the correct GGSN, and from there to the correct (s)Gi network. APNs are the traditional solution to the problem, but they can be administratively complex. Not only must the mobile devices be configured with the correct APN, but the network infrastructure (SGSNs, MMEs, HSSs, DNS, GGSNs, SGWs, PGWs, etc.) must be configured correctly as well.

Juniper Networks has developed its Traffic Direct solution as an alternative to APNs for steering traffic based on specific conditions. This is a much simpler solution for addressing the challenge of making sure that users get where they need to go. The Traffic Direct feature sits on a Services Delivery Gateway and can steer traffic, based on static or dynamic policies, from the GGSN/PGW to the correct (s)Gi network while providing the ability to apply bandwidth control and QoS Class Of Service (CoS) marking. An example is the ability to steer the traffic away, when needed, from the on-net service complex owned by the mobile wireless provider to an off-net entity such as the public Internet. Juniper’s Traffic Direct Manager solution:

• Steers traffic to the correct (s)Gi networks (Internet or corporate Intranets) to provide on-net Service complex (s)Gi off-load.

• Is an alternative to the traditional method of using multiple APN’s to steer traffic.

• Eliminates the complexity associated with provisioning and management of APNs on millions of handsets.

• Leverages static or dynamic policies to apply bandwidth management and QoS marking.


As an example, Figure 5.1 shows dynamic policy bandwidth management applied to traffic flows to the Internet and Service Complex. These flows are rate limited and differentiated. This could also be achieved by static policy.

IP Flow 1IP Flow 1

Dynamic Policy–BandwidthManagement and QoS CoS Marking

IP Flow 2IP Flow 2

MX960(Services Delivery Gateway)

SRC/C4000

SERVICECOMPLEX

INTERNETDiameterJGx(App-ID 16777273)

Figure 5.1 Dynamic policy bandwidth management

Figure 5.2 as an example illustrates the capability to redirect traffic flows from the on-net service complex to the Internet. Bandwidth management can be applied simultaneously as well. This example uses dynamic policy but it could be achieved with static policy as well. A use case example would be to redirect low value but high volume traffic to the Internet in order to off load the on-net mobile wireless service complex from unnecessary or extraneous non-revenue generating traffic.

IP Flow 1IP Flow 1 Tra�c

Redirection

Dynamic Policy–BandwidthManagement and Tra�c Redirection

IP Flow 1

DiameterJGx(App-ID 16777273)

SRC/C4000


SERVICECOMPLEX

INTERNET

Figure 5.2 Redirecting traffic flows from on-net service complex to Internet

There are several instantiations of Traffic Direct for static or dynamic policy modes. Both modes leverage the 5 tuple and DSA features. These features make use of the Services Delivery Gateway’s policy routing feature. The Services Delivery Gateway is capable of routing based on any of the elements of the IP header which include the source and destination IP addresses, source and destination port numbers, and protocol type. Forwarding is handled in hardware at line rate by the Juniper Networks Junos Trio chipset. This approach is a simple way of guaranteeing that all users get to the correct (s)Gi network. DSA allows the application of static or dynamic policies when communicating to a policy control network element through a diameter interface.


Traffic Direct capabilities include:

• Static Bypass

• DSA capability (see footnote 1 in Chapter 2)

• Application Aware Traffic Steering

• Bandwidth Management

• QoS marking.

Table 5.1 Services Delivery Gateway Traffic Direct Services

Policy Type 5-Tuple DSA Redirect

Subscriber Profile

3GPP Vendor-Specific Attribute-based (VSA)

Application Identification

Bandwidth Management Marking

Static √ √1 √ √

Dynamic √ √ √ √ √

1Only if the UE or MS is using static IP.

Traffic Direct service offers three different possible policy mechanisms:

• Static Bypass: Traffic Direct uses only the Services Delivery Gateway that applies the static policies (on MX Series, DSA only).

• Subscriber Aware: Traffic Direct uses a combination of the Services Delivery Gateway and an external policy control entity. Traffic direction under this scenario can be done for the following use cases:

- Subscriber Profile: Service Activation Policy is applied based on the subscriber name attribute.

- International Mobile Equipment Identity (IMEI): The device type determines the service activation policy that is applied.

- Mobile Station - ISDN (MSISDN): The service activation policy is determined by the mobile device calling number.

NOTE: Although only the IMEI and MSISDN attributes are listed here, the use cases can extend to include other 3GPP based attributes that can be used to differentiate between subscribers.

Application Aware: Traffic Direct consists of the Services Delivery Gateway performing the application identification. The policies are applied either directly by Services Delivery Gateway (pre-configured static policy) or by the policy control network element (dynamic policy) based on the application information.

DSA and diameter features play a key role in traffic direct service capability. The following sections provide more details on both topics.


Dynamic Subscriber Awareness Services Overview

The Dynamic Subscriber Awareness (DSA) feature allows the application of policies to individual IP flow based on 5 tuples criteria. A subscriber context is created for each distinct IP flow. This feature can be used to support dynamic subscribers that are controlled by a network element such as a B-RAS or GGSN/PGW that is connected to an MX Series Ethernet Services Router acting as a Services Delivery Gateway.

DSA has the following responsibilities:

• Creates a subscriber context for each distinct IPv4 address on a given interface (subscriber context).

• Applies policies to or remove policies from the subscriber context.

• Collects statistics and reports for each individual policy for each subscriber context.

• Derives information about subscribers logging out.

DSA can associate policies with specific subscriber contexts based on IPv4 addresses and provide service activation and deactivation for these subscribers. DSA policies leveraging 5 tuples can be configured for each distinct IPv4 address for a given interface on which the service is configured. Each distinct IPv4 address is considered a subscriber and all DSA policies are applied on a per-subscriber basis.

The Multi-Services DPC (MS-DPC) maintains a table of addresses for each subscriber and any corresponding policies. If an address is not found in the subscriber table, then a new subscriber context is created. All policies are defined on a per-subscriber basis. Once the subscribers are present in the subscriber table, DSA enforces the policies active for the subscriber context. DSA can report the subscribers (dynamic policy mode) to the service activation engine (SAE) using the Diameter application so that the Policy Manager (SRC software) can manage the subscribers and services with dynamic policies. DSA policies can be downloaded dynamically from the external policy manager (such as SRC) or configured statically on the router. The Dynamic policies take precedence over static policies.

DSA policies can be set up to perform the following:

• Manage traffic by configuring filtering, rate-limiting, and QoS enforcement in the rules.

• Steer traffic by specifying the forwarding instance in the forward rule.

• Collect accounting information by service rule or by application.

NOTE: DSA is supported on Juniper Networks MX Series Ethernet Services Routers and requires the use of a Multi-Services DPC (MS-DPC) blade on the MX Series router.

When using DSA policies, administrators are required to specify the type of statistics collection (count) and the IP address used to identify the dynamic subscriber (demux) in the service rule. All service rules attached to a given service set must have the same settings for these options.


For the statistics collection type, terms and rules also cannot mix and match the following styles:

• Rule: Statistics are aggregated in one bucket for the service rule and shared with SAE. Diameter is used to report the statistics. These statistics are not written to a flat file.

• Application: Statistics are aggregated by application for a specific application, for a specific application group, or in one bucket. The statistics are reported in a flat file and not shared with SAE using Diameter application.

Subscriber instantiation is triggered for ingress packets by the IP address. When source address is specified, the source IP address of the ingress packets is used to establish the subscriber context. When destination address is specified, the destination IP address of the ingress packets is used to establish the subscriber context. If the IP address does not correspond to a known subscriber, then a new subscriber context is created to log in the dynamic subscriber.

The match conditions include local address, local port, remote address, and remote port. Table 5.2 describes how the demux value changes the IP address or port used for these terms.

Table 5.2 Demux Value Influence on Match Condition

Demux Source-Address Demux Destination-Address

Match Conditions Ingress Flows Egress Flows Ingress Flows Egress Flows

local-address Source Address Destination Address Destination Address Source Address

remote-address Destination Address Source Address Source Address Destination Address

local-port Source Port Destination Port Destination Port Source Port

remote-port Destination Port Source Port Source Port Destination Port

Juniper Networks SBR, SRC and DSA Overview

The Juniper Networks Session and Resource Control environment provides a central administrative point for managing subscribers and their services. The SRC Series software runs on Juniper Networks C Series Controllers. The SRC Series software uses the Diameter protocol for communications between the local peer on a Juniper Networks routing platform and the remote SRC Series peer on a C Series Controller. The local peer is known as the Dynamic Subscriber Awareness (DSA) and is part of the Services Delivery Gateway. The remote SRC Series peer is the service activation engine (SAE); the SAE acts as the controlling agent in the SRC Series environment. SRC provides as well a Radius end point function to gain awareness of subscribers’ information for an IP flow, Any AAA server can proxy Radius Accounting messages towards the SRC Series. Juniper Networks SBR Series performs the AAA function.

The SRC Series software enables the SAE to activate and deactivate subscriber services (described by SRC policies). The SAE installs or removes policies using a service rule policy template called __svc_rule__. This policy template indicates which policy is applied to a new subscriber session. Additional policies are bound to


new sessions; they do not affect existing sessions. Note that the policy name must be unique between PPR (Push-Profile-Request) requests. You can use the same rule name within a single request, but you cannot use the same name again in a separate request.

Statistics collection that is aggregated on a service rule basis is also shared with the SAE using the Diameter protocol.

NOTE: More than one Diameter-based application (function) can run on a router simultaneously.

Diameter Messages Exchanged by Juniper’s DSA and SAEThe DSA application is a Juniper Networks Diameter application registered with the IANA (www.iana.org) as Juniper JGx, with an ID of 16777273. DSA and SAE communicate by exchanging the Diameter messages, as defined in Table 5.3.

Table 5.3 Diameter Messages Used by DSA and the SAE

Diameter Message Code Description

AA-Request (AAR) 265Request from DSA to the SAE at new subscriber login or during SAE-DSA synchronization . The request can be one of three types: address-authorization, provisioning-request, or synchronization .

AA-Answer (AAA) 265 Response from the SAE to the DSA AA-Request message .

Accounting-Request (ACR) 271 Request from the SAE to DSA or from DSA to the SAE for statistics .

Accounting-Answer (ACA) 271 Response to the ACR message to provide statistics for each installed policy .

Abort-Session-Request (ASR)

274 Request from the SAE to DSA to log out a subscriber .

Abort-Session-Answer (ASA)

274Response from DSA to the SAE ASR message . Includes success or failure notification for the logout request .

Push-Profile-Request (PPR)

288Request from the SAE to DSA to activate or deactivate services for a subscriber .

Push-Profile-Answer (PPA) 288Response from DSA to the SAE PPR message . Includes success or failure notification for the service activation or deactivation commands in the request .

Session-Resource-Query (SRQ)

277Request from DSA to the SAE or from the SAE to DSA to initiate synchronization between DSA and the SAE .

Session-Resource-Reply (SRR)

277 Response to the SRQ message to begin synchronization .

Session-Termination-Request (STR)

275Notification from DSA to the SAE that a provisioned subscriber has logged out .

Session-Termination-Answer (STA)

275Response from the SAE to the DSA STR message . Includes success or failure notification .

Understanding Diameter AVPs for Dynamic Subscriber Awareness

Diameter conveys information by including various Attribute-Value Pairs (AVPs) in Diameter messages. Table 5.4 lists and defines the standard Diameter AVPs used in DSA interactions.


Table 5.4 Standard Diameter AVPs for DSA

Code Number Diameter AVP Description Type

263 Session-Id Specifies the subscriber session identifier . For a dynamic subscriber managed by AAA, the value is assigned by DSA to uniquely identify the subscriber session .

UTF8String

268 Result-Code Indicates whether a request completed successfully . Provides an error code if the request failed .

The following classes are recognized by Diameter:

1xxx—Informational

2xxx—Success

3xxx—Protocol errors

4xxx—Transient errors

5xxx—Permanent failures

Unrecognized classes, which begin with numerals 6–9 or 0, are handled as permanent failures .

DSA supports the following values; all non-success values are treated as permanent failures:

1001—DIAMETER_MULTI_ROUND_AUTH

2001—DIAMETER_SUCCESS

5002—DIAMETER_UNKNOWN_SESSION_ID 5012—DIAMETER_UNABLE_TO_COMPLY

Unsigned32

277 Auth-Session-State Indicates whether AAA session state is maintained . 0—STATE_MAINTAINED

1—NO_STATE_MAINTAINED

Enumerated

295 Termination-Cause Indicates the reason why a session was terminated on the access device .

1—DIAMETER_LOGOUT

2—DIAMETER_SERVICE_NOT_PROVIDED

3—DIAMETER_BAD_ANSWER

4—DIAMETER_ADMINISTRATIVE

5—DIAMETER_LINK_BROKEN

6—DIAMETER_AUTH_EXPIRED

7— DIAMETER_USER_MOVED 8—DIAMETER_SESSION_TIMEOUT

Enumerated

Juniper Networks AVPs are used in addition to the standard Diameter AVPs. These AVPs have an enterprise number of 2636. Table 5.5 lists and defines the Juniper Networks AVPs used in DSA interactions.

Table 5.5 Juniper Networks Diameter AVPs


Code Number Diameter AVP Description Type

2020 Juniper-Policy-Install Specifies policies to be activated for the subscriber . Includes Juniper-Policy-Name and Juniper-Policy-Definition .

Grouped

2021 Juniper-Policy-Name Defines the name of a policy decision . OctetString

2022 Juniper-Policy-Definition Defines a policy decision . Includes Juniper-Policy-Name, Juniper-Template-Name, and Juniper-Substitution .

Grouped

2023 Juniper-Template-Name Profile name defined by the router . DSA only supports the __svc_rule__ policy template .

UTF8String

2024 Juniper-Substitution Defines the substitution attributes . Includes Juniper-Substitution-Name and Juniper-Substitution-Value .

OctetString

2025 Juniper-Substitution-Name Defines the name of the variable to be replaced . OctetString

2026 Juniper-Substitution-Value Defines the value of the variable to be replaced . OctetString

2027 Juniper-Policy-Remove Specifies policies to be deactivated for the subscriber . Includes Juniper-Policy-Name .

Grouped

2035 Juniper-Policy-Failed Specifies the name of the policy activation or deactivation that failed .

OctetString

2046 Juniper-Logical-System Specifies the logical system . UTF8String

2047 Juniper-Routing-Instance Specifies the routing instance . UTF8String

2048 Juniper-Jsrc-Partition Specifies the logical system and routing instance for the subscriber or request . Includes Juniper-Logical-System and Juniper-Routing-Instance .

Grouped

2050 Juniper-Request-Type Describes the type of request:

1—ADDRESS_AUTHORIZATION

2—PROVISIONING_REQUEST

3—SYNCHRONIZATION

Enumerated

2051 Juniper-Synchronization-Type Describes the type of synchronization:

1—FULL-SYNC

2—FAST-SYNC

3—NO-STATE-TO-SYNC

Enumerated

2052 Juniper-Synchronization Describes the state of synchronization:

1—NO-SYNC; this is the default state

2—SYNC-IN-PROGRESS 3—SYNC-COMPLETE

Enumerated

2053 Juniper-Acct-Record Statistics data for each policy installed for this subscriber . Includes Juniper-Policy-Name .

2053


Understanding DSA and SAE Interactions

This section describes the sequences of Diameter messages exchanged between DSA and the SAE as they interact to perform the following tasks for subscriber access:

Subscriber Login

• When a dynamic subscriber logs in, DSA sends a Diameter AA-Request message to request service provisioning from the SAE that includes the Session-Id attribute for the new subscriber. If the AA-Request fails, then the subscriber is not considered logged in and the subscriber session is not managed by the SAE. Only the static DSA rules apply to the subscriber.

• The SAE returns a Diameter AA-Answer message with the Result-Code. The AA-Answer message can include the Juniper-Policy-Install AVP (AVP code 2020), which is used to specify a service to attach to the subscriber’s IP address.

DSA can send an AA-Request message to the SAE to confirm activation. The SAE returns an AA-Answer message in acknowledgment. If the AA-Request message fails or the SAE does not respond with an AA-Answer message, the subscriber session is managed by the SAE.

Service Activation and Deactivation

• The SAE policies provision subscriber services. After a dynamic subscriber is logged in, the SAE can send a PPR message to DSA to activate or deactivate services. A given PPR can include the Juniper-Policy-Install AVP (AVP code 2020) to activate a service or the Juniper-Policy-Remove AVP (AVP code 2027) to deactivate a service.

• DSA sends a PPA message to the SAE when it has completed the tasks requested in the PPR. The PPA indicates the success or failure of the actions requested in the PPR.

Resynchronization

• Either DSA or the SAE initiates the resynchronization.

• The SAE initiates resynchronization at startup or when a backup SAE takes over session control due to resource limits or conditions on the primary SAE. The SAE clears its database of all entries in preparation for the synchronization.

• DSA initiates resynchronization at startup, such as when AAA starts or restarts. DSA uses the Juniper-Last-Origin-Host AVP (AVP code 2055) to keep track of the active SAE host in a multi-SAE environment. When an SAE in a multi-SAE environment becomes active, it must send an SRQ to DSA as its first message. DSA initiates synchronization when it receives any other message type from an SAE that is different from the SAE indicated in the Juniper-Last-Origin-Host AVP.

• Both entities initiate a resynchronization by sending an SRQ message. The recipient responds with an SRR message.


Statistics Collection and Reporting per Service Rule

• Statistics information can be sent from the router to the SAE or from the SAE to the router. Both the Diameter Accounting-Request and Accounting-Answer messages include the Juniper-Acct-Record AVP (AVP code 2053) which identifies the policy for which accounting information is requested.

Subscriber Logout

• DSA can determine when there is a logout request for a dynamic subscriber in two ways:

- The SAE terminates a subscriber session by sending an ASR message to DSA.

- DSA monitors a subscriber session and starts the logout process after 30 minutes of inactivity.

• The subscriber logout triggers the final statistics aggregation for all policies and the removal of any policies installed by the SAE. DSA sends an STR message that indicates the logout event to the SAE.

Traffic Direct Validated Use Cases

Figure 5.3 illustrates the overall components involved in the Traffic Direct solution and the high level corresponding steps for applying dynamic policies. The Services Delivery Gateway is acting as a diameter client while SAE is acting as diameter server supporting JGx diameter application. The SBR Series provides the AAA server function to proxy Radius accounting messages to the SRC Series. Validation was executed for a non-roaming agreement. In case of static policy, the interaction between Services Delivery Gateway and SRC Series is not occurring.

GGSN/PGW SDG Tra�c Direct(DSA)

LDAP

SICStandard and

3GPP Dictionaries

SSR–SessionDatabase STRM

VTA

JGxDiameterResponse

(Policy Push)

DiameterRequest

Update SessionDatabase Service Profile

SSR ReaderSubscriber Record

SRC

SubscriberIP Flows

AuthenticationAuthorization

Messages

AccountingMessages

ProxyAccountingMessages

(s)Gi IP Flows

7

6

5

4

3

2

1 SAE

SBR

AAARadius

SSR(SBR)

Figure 5.3 Major components of Traffic Direct


Table 5.6 Juniper Networks Platform and Functions

Platform Functions

MX960 Series (with MS-DPC)

Services Delivery Gateway that performs the Dynamic Subscriber Awareness, Application (DSA) identification and Application-aware Access List (AACL), static traffic direction .

SBR Series (Carrier) SBR performs AAA Radius for user session and can act as a proxy .

SRC Series (with SIC, SSR, SAE)

• SRC Policy control device to apply dynamic service activation policies .

• SIC—SRC component that receives session start, modification, and stop notifications from the access manager . The start, modification, and stop notifications are Radius accounting start, interim update, and stop events .

• SSR: Session State Registrar (SSR)—SRC component that stores attachment sessions and notifies other components about updates .

• Service Activation Engine (SAE) installs or removes policies using a service rule policy template .

Traffic Direct Generic Call Flow Process

The following steps outline the call flow process, as illustrated in Figure 5.3.

1. Radius messages (Authentication and Accounting).

The Mobile Gateway contacts the radius server (SBR Series) for authentication and authorization (in case of non transparent APN) and generates Accounting Usage Data Record (UDR) which includes user specific information attributes, such as user name/NAI, MSIDN, IMSI, APN, Framed-IP, IMEI…..etc). IP traffic flows through the gateway and exit through (s)Gi reference point. Figure 5.4 shows Radius messages (Authentication, Authorization, and Accounting) that are exchanged in step 1.

Figure 5.4 Radius messages (Authentication, Authorization, and Accounting) exchanges


2. Proxy accounting messages (SBR->SRC SIC).

The AAA server does proxy UDR (start, interim, stop) to the (SIC)-SRC component. SIC translates received attributes based on different dictionaries such as 3GPP and standard Radius into a format that can be understood by the SSR component of the SRC Series.

09/30/2010 16:56:55: Determining if this radius should act as a proxy 09/30/2010 16:56:55: CProxyRequest::SetTargetAndBuildRequest(): entering 09/30/2010 16:56:55: ----------------------------------------------------------- 09/30/2010 16:56:55: ProxyRequest 09/30/2010 16:56:55: Packet Code=0x04 Id=0xdb 09/30/2010 16:56:55: Vector = 09/30/2010 16:56:55: 000: f335f184 cd02094e 20fdf8d1 dea61c15 |.5.....N .......| 09/30/2010 16:56:55: Parsed Packet : 09/30/2010 16:56:55: User-Name : String Value = [email protected] 09/30/2010 16:56:55: Class : Value = 09/30/2010 16:56:55: 000: 53425232 434cd2bb fe929b8f aac09980 |SBR2CL..........| 09/30/2010 16:56:55: 010: 11804b01 80028198 80028013 81a9d5a8 |..K.............| 09/30/2010 16:56:55: 020: a3a28194 d5a792aa 84aac8dc cea2d580 |................| 09/30/2010 16:56:55: 030: 04800f81 98cbc692 f1c4dcb9 99ceca84 |................| 09/30/2010 16:56:55: 040: fabd9806 80058180 808086b0 12800e81 |................| 09/30/2010 16:56:55: 050: a896e0c2 dab2c4cf d3c08080 8394 |.............. | 09/30/2010 16:56:55: NAS-IP-Address : IPAddress = 48.1.1.4 09/30/2010 16:56:55: NAS-Identifier : String Value = lsggsn 09/30/2010 16:56:55: Acct-Session-Id : String Value = ACCT0001 09/30/2010 16:56:55: Acct-Status-Type : Integer Value = 1 09/30/2010 16:56:55: Framed-IP-Address : IPAddress = 1.1.1.93 09/30/2010 16:56:55: 3GPP-GGSN-Address : IPAddress = 99.99.99.99 09/30/2010 16:56:55: 3GPP-PDP-Type : Integer Value = 0 09/30/2010 16:56:55: 3GPP-SGSN-Address : IPAddress = 111.111.111.111 09/30/2010 16:56:55: 3GPP-MSISDN : String Value = 11234567890 09/30/2010 16:56:55: ----------------------------------------------------------- 09/30/2010 16:56:55: ----------------------------------------------------------- 09/30/2010 16:56:55: Proxy Request 09/30/2010 16:56:55: Sent to IpAddr=47.1.1.1 Port=1813

3. SSR session database update (SRC SIC → SSR).

The SIC creates an attachment session in the SSR, which maintains the session database consisting of the various attributes associated with each subscriber.

++++++ Request ++++++Accounting Request Packet ID = 218Address = ‘47.1.1.3’ Port = ‘28000’ NAS = ‘router’(String ) User-Name = ‘[email protected]’ (16 bytes)(String ) Class = ‘SBR2CL............K...................................................’ (94 bytes) [contains control characters](IP Address) NAS-IP-Address = ‘48.1.1.4’ (4 bytes)(String ) NAS-Identifier = ‘lsggsn’ (6 bytes)(String ) Acct-Session-Id = ‘ACCT0001’ (8 bytes)(Integer32 ) Acct-Status-Type = ‘1’ (4 bytes)(IP Address) Framed-IP-Address = ‘1.1.1.93’ (4 bytes)(IP Address) 3GPP-GGSN-Address = ‘99.99.99.99’ (4 bytes)(Integer32 ) 3GPP-PDP-Type = ‘0’ (4 bytes)(IP Address) 3GPP-SGSN-Address = ‘111.111.111.111’ (4 bytes)(String ) 3GPP-MSISDN = ‘11234567890’ (11 bytes)------ End Request ------


4. Diameter messages between the MX Series and SRC Series.

The Services Delivery Gateway detects the new IP flow and creates a DSA session. Services Delivery Gateway notifies the corresponding managing SAE entity with an AAR (AA_Request) diameter request using the JGx reference point. The SAE extracts the IP address and optionally the VPN ID, Application ID from the DSA session information.

Oct 7 19:05:06 queueMessage ../../../../src/junos/usr.sbin/jptspd/jptspdSrcEngine.cc:4240 #################################### Queuing AAR for transmit ####################################Oct 7 19:05:06 getSrcSessionId ../../../../src/junos/usr.sbin/jptspd/jptspdSubscriberSession.cc:16055629499534213127:192.168.1.89 src session id : [email protected];1310720;7;1286476989

Oct 7 19:05:06 txGetMsgCb ../../../../src/junos/usr.sbin/jptspd/jptspdSrcEngine.cc:2341: SrcRw: txGetMsgCb inserting in pendingResponseQueue; hopByHopId = 22; msgId = 42; endToEndId = 1272661439

Oct 7 19:05:06 txGetMsgCb ../../../../src/junos/usr.sbin/jptspd/jptspdSrcEngine.cc:2373: txGetmsgCb() diameter msg data: hopByHopId = 22; endToEndId = 1272661439

Oct 7 19:05:06 txDoneCb ../../../../src/junos/usr.sbin/jptspd/jptspdSrcEngine.cc:2388: entered runSm ../../../../src/junos/usr.sbin/jptspd/jptspdSubscriberSession.cc:1041: 5629499534213127:192.168.1.89 sm exit; current state is logged in; after handled event EVENT_TYPE_PIC_SERVICE_SUCCESS

Oct 7 19:05:06 processRxAAMsg ../../../../src/junos/usr.sbin/jptspd/jptspdSrcEngine.cc:796

5. SAE reading from SSR (SRC).

The SAE starts managing the DSA session and calls the SSR reader authentication plug-in to obtain attachment session information –attributes- associated with the IP address from the SSR. The data from the SSR is used in the classification context.

16:49:07.611 EDT 30.09.2010 [AuthQueue-2] [SsrReaderPluginEventListener] [10] User 1.1.1.92 (session id = PiVBdRK15KCioAAX) was found in the SSR. Attributes=SSRAttSet<SubscriberSessions> { 3GPPGgsnAddr = cccc SessionStartTime = 1285894146000 SessionState = 1 DeviceType = null CalledStationID = null 3GPPmsisdn = 11234567890 AccessType = null 3GPPSgsnAddr = cccc IMSI = null UserName = [email protected] CallingStationID = null}


6. Service profile from LDAP to SAE (SRC Series).

The SAE runs the subscriber classification script, requests service activation profile from LDAP server (SPR) based on either only the subscriber name or any other pertaining attribute such as IMEI. SAE loads the subscriber profile and creates a subscriber session. The subscriber session activates any subscribed activate-on-login service.

16:49:07.618 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Loaded subscriptions for user uniqueId=sub3_11234567890,ou=default,retailerName=MTS,o=Users,o=UMC: BRONZE

16:49:07.619 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Loaded subscriber schedules for user uniqueId=sub3_11234567890,ou=default,retailerName=MTS,o=Users,o=UMC:

16:49:07.622 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Loaded subscriptions for user ou=default,retailerName=MTS,o=Users,o=UMC:

16:49:07.623 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Loaded subscriber schedules for user ou=default,retailerName=MTS,o=Users,o=UMC:

16:49:07.625 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Loaded subscriptions for user retailerName=MTS,o=Users,o=UMC:

16:49:07.626 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Loaded subscriber schedules for user retailerName=MTS,o=Users,o=UMC:

16:49:07.626 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Created UserProfile from LDAP entry retailerName=MTS,o=Users,o=UMC

16:49:07.626 EDT 30.09.2010 [default@[email protected];131072;6;1285868890] [UserLDAPDataManager] [10] Created UserProfile from LDAP entry ou=default,retailerName=MTS,o=Users,o=UMC

16:49:07.626 EDT 30.09.2010 [default@[email protected];1310720;6;1285868890] [UserLDAPDataManager] [10] Created UserProfile from LDAP entry


7. Diameter messages between the MX Series (Services Delivery Gateway) and SRC Series.

When the subscriber session is completely activated, the SAE installs corresponding policies on the Services Delivery Gateway with a policy-push using an AAA diameter response through the JGx reference point.

#################################### RECEIVED AAA (AA Response) ####################################Oct 7 19:05:06 aaResponseCb ../../../../src/junos/usr.sbin/jptspd/jptspdSrc.cc:517 #################### Processing AAR Provisioning Response for session; id = 5629499534213127 ####################

Oct 7 19:05:06 aaResponseCb ../../../../src/junos/usr.sbin/jptspd/jptspdSrc.cc:581: subscriber provision succeedOct 7 19:05:06 runSm ../../../../src/junos/usr.sbin/jptspd/jptspdSubscriberSession.cc:1026: 5629499534213127:192.168.1.89 sm entered, current state is logged in; incomming event is EVENT_TYPE_SRC_AAA

Oct 7 19:05:06 processAAA3 ../../../../src/junos/usr.sbin/jptspd/jptspdSubscriberSession.cc:665: 5629499534213127:192.168.1.89 AAR3 recived EVENT_TYPE_SRC_AAA

Oct 7 19:05:06 runSm ../../../../src/junos/usr.sbin/jptspd/jptspdSubscriberSession.cc:1041: 5629499534213127:192.168.1.89 sm exit; current state is logged in; after handled event EVENT_TYPE_SRC_AAA

Oct 7 19:05:06 processRxCtrlMsg ../../../../src/junos/usr.sbin/jptspd/jptspdSrcEngine.cc:696: event: Good-Data-Msg

Oct 7 19:05:06 processRxCtrlMsg ../../../../src/junos/usr.sbin/jptspd/jptspdSrcEngine.cc:696: event: Good-Data-Msg

Configuration Resources

Use the following links to see further details concerning these specific configurations.

To configure DSA on the Services Delivery Gateway, refer to DSA for Subscriber Access at http://juniper-federal.com/techpubs/en_US/junos/information-products/pathway-pages/subscriber-access/ptsp/subscriber-management-ptsp.html#configuration.

To configure the SRC Series to support DSA-enabled MX Series platform (Services Delivery Gateway), refer to Session and Resource Control (SRC) Software for C Series Controllers, Release 4.1 at www.juniper.net/techpubs/en_US/src4.1/information-products/pathway-pages/c-series/index.html.

In particular, Part 3 Chapters 16-19 of SRC PE Software Solution Guide 4.1 at www.juniper.net/techpubs/en_US/src4.1/information-products/topic-collections/solutions/book-solutions.pdf.

http://juniper-federal.com/techpubs/en_US/junos/information-products/pathway-pages/subscriber-access/ptsp/subscriber-management-ptsp.html#configuration



www.juniper.net/techpubs/en_US/src4.1/information-products/pathway-pages/c-series/index.html

www.juniper.net/techpubs/en_US/src4.1/information-products/pathway-pages/c-series/index.html

www.juniper.net/techpubs/en_US/src4.1/information-products/topic-collections/solutions/book-solutions.pdf

www.juniper.net/techpubs/en_US/src4.1/information-products/topic-collections/solutions/book-solutions.pdf


Validation Test Bed Setup

Figure 5.5 illustrates the test bed that was used to validate Traffic Direct service scenarios.

Server SimulationExternal Data Network

Internet

GGSN

User IP Flows

Eth148.1.1.3/8

Eth348.1.1.4/8

Eth292.2.1.2/8

Ge-3/2/492.2.1.1/8

Xe-3/0/047.1.1.2/24

Ge-3/0/045.1.1.5/30

Ge-2/0/045.1.1.6/30

Ge-4/0/096.6.1.2/8

Eth696.6.1.1/8

Eth797.7.1.1/8

Xe-0/1/0

10.13.96.25

Eth247.1.1.3/24

Eth247.1.1.1/24

Ge-0/0/25

Ge-1/0/46

10.13.96.5310.13.98.4

10.13.96.54

10.13.96.27

Ge-0/0/47

Xe-0/1/10

Xe-1/2/0

(VLAN 10)97.7.1.1/8


SBR/AAA

M120

Radius and Policy Control

Test ToolVirtual

Chassis

EX4200

EX4200

SRC/C4000

Server SimulationInternal Data Network

Services Complex

Figure 5.5 Test bed setup used to validate Traffic Direct scenario

NOTE: STRM could not be used due to some limiting integration aspects at the time of the validation effort.

Table 5.7 Juniper Networks Devices used in Setup

Device Version Number Required Purpose

MX Series (with MS-DPC) Junos 10 .3 1 Services Delivery Gateway: DSA function, services edge

M Series Junos 10 .3 1 Router to external data network/ Internet

SRC (with SIC, SSR, SAE) Junos 4 .0 2 Policy control

SBR Series (Carrier)SBR 7 .2, Sun Solaris 10 .0

AAA Radius

LandSlide 8 .5 .0 .15Simulates mobile subscribers, GGSN and Radius messages .


Validated Traffic Direct Scenarios

As shown in Figure 5.6, the following Traffic Direct scenarios have been tested with the validation lab setup to trigger use case policies:

• Static Bypass

- User based ( IP address)

- Application Id

• Subscriber Aware

- Subscriber profile

- IMEI

- MSIDN

• Application Aware.

Figure 5.6 illustrates traffic direct scenarios.

Static Bypass(User-based -IP, @-, Application ID)

Subscriber Aware(Subscriber profile, IMEI, MSISDN)

Application Aware

Static Policies on MXBandwidth Policing

Application ID5 Tuple

Dynamic Policies from SRCRadius AAA–SBR

Bandwidth PolicingSource/Destination IP

Dynamic Policies from SRCRadius AAA–SBR

Bandwidth PolicingApplication ID

Figure 5.6 Traffic Direct scenarios for static bypass, subscriber aware and application aware

The following section defines the boundary conditions for proper functional deployment of the validated Traffic Direct service (with Juniper’s SRC Series and SBR Series).

Boundary Conditions

Static Bypass

• Currently the only actions that can be assigned to a policer associated with a static DSA rule are Discard, Burst Size, and Bandwidth.

• Each individual subscriber session on the Services Delivery Gateway created as a result of static DSA policies needs to be cleared manually by the user. The other option is to wait for a time out period of thirty minutes for the session to expire.


Subscriber Aware

• At the time of testing, when merging the 3GPP and standard Radius dictionaries, the 3GPP Vendor Specific Attribute (VSA) definitions needed to be manually copied and added to the standard Radius dictionary. The 3GPP dictionary had to be converted from “ims-aaa” to “SIC” format prior to performing the merge.

The syntax of a new sub-attribute defined as part of the SAE plug-in had to conform to internal syntax and only use ASCII Latin Letters, digits or underscore.

Application Aware

• It is recommended at the time of the testing to use pre-defined signatures and ALGs when configuring Application Aware scenarios to ensure proper traffic application detection.

SAE-SRC Component

• When DSA on Services Delivery Gateway communicates with the SAE-SRC components, it is currently mandatory to set a value for the VPN ID since it is a key attribute that is part of the SAE lookup. If there is no VPN ID associated to a flow, the value of the VPN ID in this case needs to be set to an empty string to successfully pass the SAE lookup step.

• Only default naming convention can be used for the forwarding classes on Services Delivery Gateway. The forwarding classes should be defined as “assured-forwarding, expedited-forwarding, and best-effort” in accordance with SRC name recognition capability in order to successfully be able to apply dynamic policies.

NOTE: The policy control network element must support Juniper JGx.

NOTE: If this service is planned to be deployed, Juniper recommends that the previously listed steps be strictly followed to ensure proper implementation and working of the of the Traffic Direct service. In the validated Traffic Direct scenario when a static or dynamic policy calls for bandwidth management were implemented, the following were provisioned. Table 5.8 lists the forwarding classes and service profiles.

Table 5.8 Platform, Forwarding Classes and Service Policies

Platform Forwarding Classes Service Policies

MX Series best-effort

assured-forwarding

expedited- forwarding

N .A . (Static policy)

SRC Series best-effort

assured-forwarding

expedited- forwarding

Gold (2Mbps)

Silver (1 .5Mbps)

Bronze (1Mbps)


Similarly, Table 5.9 lists and defines the key 3GPP attributes that have been leveraged for the subscriber-aware scenario.

Table 5.9 3GPP Attributes Used in Subscriber-Aware Scenario

Attribute Definition Significance Used in Testing

IMEI International Mobile Equipment Identity

Used to identify the GSM/UMTS Mobile phone hardware usually printed inside the battery compartment – you can know your phone’s IMEI by typing in *#06# . Not tied to the subscriber . Cannot be transferred from device to device . Mainly used to avoid theft and to render the device useless in case of theft or fraud regardless of the SIM card .

Yes

MSISDN Mobile Station International Subscriber Directory Number

Represents the phone number and is tied to the SIM card in GSM/UMTS phones .

Yes

PDP Type PDP Context Type Used to identify if it is an IP PDP type or PPP PDP type . Yes

SGSN Address SGSN IP address Represents the IP address of the SGSN that a MS is anchored to for routing and connectivity to a specific GGSN using GTP .

Yes

GGSN Address GGSN IP address Represents the IP address of the GGSN that a MS is anchored to, for routing and service authentication/authorization purposes .

Yes

RAT Type Radio Access Network Technology Type

Identifies whether the traffic is coming from 2G (GSM/GERAN) or 3G (W-CDMA/UTRAN) and this is used by operators for billing purposes and also to apply further QoS attributes .

No

IMSI-MCC-MNC IMSI, Mobile Country Code, Mobile Network Code

Identify the subscriber, the subscriber’s home network and the home country subscriber’s number .

No

Charging ID Charging Identifier Used for charging purposes if it is prepaid or postpaid, etc . No

Although Table 5.9 lists some of the key attributes that have been used for subscriber-aware scenario. This table does not represent an exhaustive list. For the complete set of 3GPP attributes, please refer to the 3GPP TS 29.060 specification which can be downloaded at www.3gpp.org.

Static Bypass Scenario Call Flow

For this tested Traffic Direct scenario (Static Bypass), the Services Delivery Gateway uses DSA to maintain local static subscriber policies in order to execute traffic redirection, bandwidth policing and marking. The traffic redirection is performed based on the IP subnet destinations of the on-net service complex versus the off-net entity like the Internet. Figure 5.7 illustrates the high level call flow corresponding to Static Bypass.


AAAGGSN SSRSIC SAE

Create PDPReq

Create PDPResp Account

Req Start ProxiedAccount Req Update

Session DBAccountResp

AccountResp

UpdateSession Ack

DiameterQuery is

turned o�

a)

b) Or no replyto it

AuthenticationReq

AuthenticationResponse

If non-transparent

APN

UpdateSession Ack

Release PDPResp

Release PDPReq

POLICY CONTROL (SRC)PRE-PCRF SUPPORT

SERVICECOMPLEXSDG:TDLDAP iNTERNET

SPR

IP AddressAllocation

PDP ContextRemoved

Remove User Session/IP Flow

Apply Static Policies(i.e. Redirect, Bwdth, Marking)

IP FLOW

IP FLOWPDP IP FLOW

PDP IP FLOW

AccountReq Stop

Account Resp

ProxiedAccount Req

Account Resp

UpdateSession DB

30mns Idle TimerIssue if IP address reused during this time.On mobile gateway use a feature to onlyreuse allocated IP from local pool after aconfigured timeout.

Figure 5.7 High-level call flow associated with static bypass

NOTE: In this scenario Services Delivery Gateway is not made aware the user may have disconnected or its session may have been torn down. The only thing available is detection of idle time-out. Default value in Services Delivery Gateway is 30mns. If the IP address is reused during the idle timer in DSA the IP flow is not considered as a new session and previous static policy would apply. A possible workaround is to use on mobile gateway a feature to only reused allocated IP from local pool after a configured timeout.


Static Bypass Scenario Code Snippet

The following code snippet shows the static DSA configuration.

sea-mobility@SOL-MX960-54# show services ptsp rule PTSP-STATIC-RULE1 match-direction input; → Match the directiondemux source-address; → Use source IP address to trigger the creation of new subscriber sessioncount-type rule; → Define statistics reporting style term 1 { from { → Set IP destination remote-address-range { low 97.7.1.2 high 97.7.1.10; low 92.1.1.2 high 92.1.1.100;

Static Policy Rule 1 and Rule 2 configured on Services Delivery Gateway using DSA for Bandwidth Management.

} } then { forwarding-class expedited-forwarding; → Change the forwarding class count rule; → Enable collection of statistics accept; → Accept the traffic }}sea-mobility@SOL-MX960-54# show services ptsp rule PTSP-STATIC-RULE2 match-direction input;demux source-address;count-type rule;term 1 { from { remote-address-range { low 96.6.1.2 high 96.6.1.5; low 92.1.1.2 high 92.1.1.100; } } then { police PTSP-POLICER; → Set a policing action accept; }}

sea-mobility@SOL-MX960-54# show firewall

Policer Config called by the DSA on SDG for Bandwidth Management.

family inet { filter PTSP-FILTER { → Configure Firewall term 1 { from { source-address { → Set IP address to be used 92.0.0.0/8; } } then { policer PTSP-POLICER; → Set policer to be used count PTSP-CNT; accept; } } }}policer PTSP-POLICER { → Create policer associated with static DSA rule if-exceeding { → Set the policing action to include: bandwidth-limit 8k; rate limiting and classification of traffic burst-size-limit 1500; } then forwarding-class best-effort; → to Best Effort

}


When match conditions are fulfilled, DSA rules are applied to the traffic flows associated with each individual subscriber session.

The action “C-R” denotes the count rule that deals with the accounting information. DSA accounting and upload of the flat file towards STRM could not be verified at the time of validation.

The action “FC+P” shows a policing and a change in forwarding class being performed.

sea-mobility@SOL-MX960-54> show services subscriber sessionsClient-ID IP-address Underlying-interface User-name5629499534213574 92.1.1.2 ge-3/2/4.0 ip92.1.1.2@default5629499534213575 92.1.1.3 ge-3/2/4.0 ip92.1.1.3@default

Subscriber sessions created based on Static Policy.

sea-mobility@SOL-MX960-54> show services subscriber flows client-id 5629499534213575Subscriber session 5629499534213575

Data flows associated with each subscriber session.

Number of data flows: 4Data flows high-water-mark: 45-tuple Application-ID Policy-name Dir Packets Bytes Action96.6.1.2:80->92.1.1.3:2000,6 Unknown(32767) PTSP-STATIC-RULE2-1/8 O 4972 1019616 C-R97.7.1.2:80->92.1.1.3:2000,6 Unknown(32767) PTSP-STATIC-RULE1-1/19 O 1636081 344667048 C-R92.1.1.3:2000->97.7.1.2:80,6 Unknown(32767) PTSP-STATIC-RULE1/20 I 2181442 401384464 C-R+FC92.1.1.3:2000->96.6.1.2:80,6 Unknown(32767) PTSP-STATIC-RULE2/21 I 6298 1159120 P

sea-mobility@SOL-MX960-54> show services subscriber statistics client-id 5629499534213575 Aggregation-level Name/Id Packets-in Packets-out Bytes-in Bytes-outsubscriber 5629499534213575 2130136 1597844 391944448 336584480static rule PTSP-STATIC-RULE2-1/8 0 4834 0 991056static rule PTSP-STATIC-RULE1-1/19 0 1593010 0 335593424static rule PTSP-STATIC-RULE1/20 2124014 0 390817712 0

Statistics per subscriber session

Dynamic Scenario (Subscriber and Application Aware) Call Flow

For the subscriber-aware scenario, steering is executed based on destination IP using local policy DSA rule while dynamic policy rules retrieved from the SRC are applied for the following two use cases:

• Device aware: The SSR database of the SRC contains a device identifier (IMEI/MEID). The policy rules regarding bandwidth, CoS marking or even accept or reject policies are applied based on the device type.

• Subscriber profile: The SRC contains policies that can control bandwidth and CoS marking for each subscriber. QoS policies are applied based on the subscriber’s subscription billing plan, for example Gold, Silver or Bronze.

For the Application-Aware use case, steering is done on identified application based on either port number and/or protocol type. In this case the MS-DPC identifies the application and provides the SRC with the application ID. A dynamic policy tailored to the identified application is pushed to Services Delivery Gateway and applied.

Figure 5.8 illustrates the corresponding call flows for Dynamic scenario policy activation for a new IP flow.


AAAGGSN SSRSIC SAE

Create PDPReq

Create PDPResp Account

Req Start ProxiedAccount Req Update

Session DBAccountResp

AccountResp

UpdateSession Ack

AccountingPush/PullMay Take

Place

DiameterQuery mustbe enabled

SSR Reading

AuthenticationReq

AuthenticationResponse

If non-transparent

APN



SPR

IP AddressAllocation

Apply Dynamic Policies(i.e. Redirect, Bwdth, Marking)

IP FLOW

PDP IP FLOW

f

f

PDP IP FLOW

Diameter Req: AAR

Diameter Resp: AAA

Diameter Req: ACR

Diameter Req: ACA

Figure 5.8 Call flows for dynamic scenario policy activation

Upon detection of a new IP flow the Services Delivery Gateway DSA (enabled) triggers a Diameter request AAR towards the policy control entity (SAE-SRC). An AAA diameter response is expected with the corresponding Policy AVP to install in Services Delivery Gateway for the corresponding flow.


The diameter AAR message contains the following AVPs.

AAR ::= <Diameter Header: 265, REQ, 16777273><SessionId>{Origin-Host: JPTSPD}{Origin-Realm: JPTSPD}{Destination-Host: SRC}{Destination-Realm: SRC}{Auth-Session-State: STATE_MAINTAINED}{Juniper-Request-Type: PROVISIONING_REQUEST}{Framed-IP-Address}{Framed-IP-Netmask}[Juniper-Routing-Instance][Juniper-Acct-Capabilities][Juniper-Jsrc-Partition][Juniper-If-Name] * [Juniper-Policy-Failures] (AAR)* [Juniper-Policy-Successes] (AAR)

NOTE: The framed IP identifies the IP flow. The Session Id is created for every new subscriber. The Routing-Instance provides the VRF name of the interface associated with the Session Id.

The diameter AAA message contains the following AVPs.

AAA ::= Diameter Header: 265, REQ, 16777273>{<SessionId>}{Origin-Host: SRC}{Origin-Realm: SRC}[Destination-Host: JPTSPD][Destination-Realm: JPTSPD]{Auth-Session-State: STATE_MAINTAINED}[Result-Code][Error-Message][User-Name]* [Failed AVP]* [Reply Message][Juniper-Policy-Install] (AAA)

NOTE: The Juniper-Policy-Install AVP, Services Delivery Gateway must be applied dynamically.

Push /Pull accounting may take place depending on the configuration between the Services Delivery Gateway and SRC. SRC in turn can generate Call Data Records (CDR) towards a charging system or Volume Tracking Application (VTA) for quota management. This aspect was not validated during dynamic policy scenarios.

The SRC can install additional policies to an existing subscriber or remove a policy leveraging the AVP “Juniper-Policy-Remove” by sending a diameter message PPR. The Services Delivery Gateway DSA (enabled) is expected to send back a PPA to acknowledge the policy change, addition, or removal.


Figure 5.9 illustrates the corresponding call flows for Dynamic scenario policy deactivation for a normal user session disconnect or due to an idle timeout.

AAAGGSN SSRSIC SAE

ReleasePDP Req

ReleasePDP Resp

AccountReq Stop Proxied

Account Req UpdateSession DB

Account RespAccount Resp Update

Session Ack

UpdateSession

UpdateSession Status



SPR

PDP ContextRemoved

RemoveDynamic Policies

RemoveDynamic Policies

Idle Timeout

IP FLOWPDP IP FLOW

IP FLOWPDP IP FLOW

Diameter Req: ACR

Diameter Req: ASA

Diameter Req: ASR

Diameter Resp: ACA

Diameter Resp: ACA

Diameter Req: ACR

Diameter Resp: STA

Diameter Req: STR

Normal Session Disconnect

Idle Timeout Session Disconnect

Figure 5.9 Corresponding call flows for dynamic scenario policy deactivation

In a typical scenario, the UE session is terminated and the mobile gateway sends a UDR stop towards the AAA server. This forces the SAE-SRC to trigger the disconnect sequence by sending the diameter message ASR. Services Delivery Gateway DSA (enabled) acknowledges by responding with an ASA after having removed the corresponding policies. This might be preceded by the ACR/ACA sequence for accounting purpose.

In case of idle timeout termination, Services Delivery Gateway (enabled) provides, if needed, SAE-SRC with the latest accounting information through the ACR/ACA sequence. Corresponding policies are removed and Services Delivery Gateway notifies SAE-SRC of the policy removal by sending a STR, expecting to receive an STA as an acknowledgement.


Dynamic Policy Scenario Code Snippet

The following provides configuration insights for two scenarios, Subscriber Aware, and Application Aware, invoking dynamic policy.

Subscriber-Aware Scenario

Table 5.10 lists and defines the 3GPP attributes that were leveraged to perform the subscriber-aware scenario. Note, additional attributes can be used. This table represents the attributes used during the validation. The show commands displays use case information where the subscriber is identified by its IMEI.

Table 5.10 3GGP Attributes Used to Perform Subscriber-Aware Scenario

Attribute Vendor ID Type Format Format

IMEI 10415 20 String myimeivalue

MSIDN 10415 31 String 11234567890

PDP Type 10415 3 IPv4 0 .0 .0 .0

SGSN Address 10415 6 IPv4 111 .111 .111 .111

GGSN Address 10415 7 IPv4 99 .99 .99 .99

NOTE: Provisioning must be added in SBR Series and SRC Series network elements as outlined in the following steps.


1. The subscriber must be defined in the AAA server SBR Series.

Figure 5.10 Define subscriber profile in SBR Series

2. The following represent the 3GPP attributes required for the scenario to be added in the SRC/SIC Radius dictionary.

radius { format string; type 20; → Define 3GPP attribute IMEISV with type 20 vendor-id 10415;}radius { format string; type 31; → Define 3GPP attribute MSISDN with type 31 vendor-id 10415;}radius { format ipv4-address; type 7; → Define 3GPP attribute GGSN Address with type 7 vendor-id 10415;}radius { format ipv4-address; type 6; → Define 3GPP attribute SGSN Address with type 6 vendor-id 10415;}radius { constant IPV4 0; constant IPV6 2; constant PPP 1; format integer; type 3; → Define 3GPP attribute PDP Type with type 3

vendor-id 10415;


3. The SSR plug-in must be configured to translate 3GPP Radius attributes into a format that can be understood and stored by the SSR DB.

default-method database { plug-in-attribute { login-name { request-attribute User-Name; } property.3gppGgsnAddr { request-attribute 3GPP-GGSN-Address; } property.3gppSgsnAddr { request-attribute 3GPP-GGSN-Address; }

Configure plug-in attributes for SSR to understand Radius attribute information provided through SIC.

Plug-in attribute consists of information for username, properties for 3GPP attributes; session start-time; user type, the user Framed IP address that is returned from Radius and VPN ID with an empty value. (VPN ID is a non-null value when VPNs are used.)

property.devicetype { request-attribute 3GPP-IMEISV; } property.imsi { request-attribute 3GPP-IMSI; } property.msisdn { request-attribute 3GPP-MSISDN; } property.session-start-time { variable ReceiveTime; } property.session-state { variable UserStatusType; } user-inet-address { request-attribute Framed-IP-Address; } vpn-id { literal ‘’; } } }


4. Associate attributes in the SSR database for each user session.

attribute-associations { entity subscriber-sessions { field 3GPPGgsnAddr { sae-plugin-attribute property.3gppGgsnAddr; } field 3GPPSgsnAddr { sae-plugin-attribute property.3gppSgsnAddr; } field 3GPPmsisdn { sae-plugin-attribute property.msisdn; } field AccessType { sae-plugin-attribute property.access-type;

Configure attribute associations in SSR database for each subscriber session. Fields consists of information for username, properties for 3GPP attributes; session start time; access type and VPN ID with an empty value. (VPN ID is a non-null value when VPNs are used.)

} field CalledStationID { sae-plugin-attribute property.called-station-id; } field CallingStationID { sae-plugin-attribute property.calling-station-id; } field DeviceType { sae-plugin-attribute property.devicetype; } field IMSI { sae-plugin-attribute property.imsi; } field SessionStartTime { sae-plugin-attribute property.session-start-time; } field SessionState { sae-plugin-attribute property.session-state; } field UserIPAddress { sae-plugin-attribute user-inet-address; } field UserName { sae-plugin-attribute login-name; } field VpnID { sae-plugin-attribute vpn-id; } }}


5. Configure the SAE Plug-in to read attribute from the SSR database.

ssr-reader { read-attributes [ login-name property.access-type property.called-station-id property.calling-station-id property.imsi property.session-start-time property.session-state property.3gppGgsnAddr property.devicetype

SAE plug-in to read attributes from SSR database.

Reads attributes – MSISDN, GGSN address, SGSN address, Device type (IMEI), Access type, Called Station ID.

property.3gppSgsnAddr property.msisdn ];}

The following show command illustrates the Traffic Direct subscriber-aware scenario where the policy “Gold” is dynamically applied to the user based on its IMEI device type myimeivalue.

sea-mobility@SOL-C4000-25> show sae subscribers …/…User SessionUser IP 1.1.1.103User DN uniqueId=sub1_myimeivalue,ou=default,retailerName=MTS,o=Users,o=UMDevice Name default@sol-mx960Domain Name juniper.netUser Name sub1Login Name [email protected] Type DIAMETERSession [devicetype=myimeivalue, session-start-time=1285628027000,Properties 3gppSgsnAddr=cccc, 3gppGgsnAddr=cccc, session-state=1,__SSR__=true]…/…User Profile User Dn uniqueId=sub1_myimeivalue,ou=default,retailerName=MTS,o=Users,o=UMCanonymous FALSE cn sub1-myimeivalue sn sub1-myimeivalue uniqueid sub1_myimeivalue Subscription Subscription name GOLD activationorder 10000 servicename GOLD sspaction ACTIVATE_ON_LOGIN sspstate SUBSCRIBED


Application-Aware Scenario

The SRC must be configured to use application ID capability.

folder MOBILE-PTSP { → Define Policy on SRC related to DSA group MTD { list P1 { applicability both; policer { → Apply policer that limits bandwidth ratelimit { bandwidth 3000000; max-burst-size 1500; } } role junos-ptsp; rule PR { accounting; forwarding-class name forwardingClass ‘”expedited-forwarding”’; → Classify traffic to Forwarding class policer-ref name policerRef /ratelimit; precedence 100; traffic-condition TC { match-direction both; → Define direction to apply policy traffic-match-condition { application-group [ ‘”junos:web”’ ‘”junos:file-server”’ ‘”junos:enterprise”’ ]; → Application id } } type ptsp-service-rule; → Define rule type } } }

The following series of show commands clearly indicate policy Gold is dynamically applied to a user for which Application Id is HTTP, for example Junos: web.

This code snippet shows a dynamic policy being applied to the flows in Services Delivery Gateway based on the application id. In this case, application Id HTTP traffic results in change of forwarding class and policing action by dynamic policy as previously defined.

sea-mobility@SOL-MX960-54> show services subscriber flows client-id 5629499534213128 Subscriber session 5629499534213128Number of data flows: 3Data flows high-water-mark: 35-tuple Application-ID Policy-name Dir Packets Bytes Action1.1.1.129:2001->96.6.1.2:80,6 any - I 3 120 A 1.1.1.129:2001->97.7.1.2:80,6 junos:http 1348153281713537056 I 43 7352 FC+P 97.7.1.2:80->1.1.1.129:2001,6 junos:http 1348153281713537056 O 34 7504 FC+P

sea-mobility@SOL-MX960-54> show services subscriber statistics client-id 5629499534213128 Aggregation-level Name/Id Packets-in Packets-out Bytes-in Bytes-outsubscriber 5629499534213128 1625 1218 272360 256592 application junos:http 5 4 712 672


The following code snippet shows the corresponding subscriber session entry in SRC corresponding to IP flow 1.1.1.129 and indicates that the “Gold” policy is dynamically applied.

sea-mobility@SOL-C4000-25> show sae subscribers User SessionUser IP 1.1.1.129User DN uniqueId=sub12,ou=default,retailerName=MTS,o=Users,o=UMCMAC AddressDevice Name default@sol-mx960Domain Name juniper.netInterface Name ge-3/2/4.0Interface AliasInterface DescriptionInterface Type IPUser Name sub12Primary User NameLogin Name [email protected] User Type DIAMETERLogin Type ADDRNAS Port IDNAS IP 0.0.0.0Session Substitutions []Service BundleCalling Station IdVPN IdSession Properties [session-state=1, session-start-time=1285715613000, __SSR__=true]Relay Agent addressRADIUS session ID PiVBdRK1mkWCsAAHLogin time Tue Sep 28 15:13:35 EDT 2010Session Timeout -1 User Profile<snip> Subscription Subscription name GOLD activationorder 10000 servicename GOLD sspaction ACTIVATE_ON_LOGIN sspstate SUBSCRIBED


This following code snippet indicates the dynamic policy (GOLD) is associated with a subscriber for AppID HTTP pushed from SRC.

sea-mobility@SOL-MX960-54> show services subscriber dynamic-policies client-id 5629499534213128 Subscriber session 5629499534213128 policy Policy name: 1348153281713537056 rpr: 100 d: input-output Template: __svc_rule__ tpr: 100 ra: 0.0.0.0 rm: 0 lpl: 0 lph: 65535 rpl: 0 rph: 65535 p: 0 a-f: accept policer fowarding-class a-s: a-fc: expedited-forwarding a-p-i: 1 a-p-bw: 3000000 a-p-mbs: 1500 a-fu: 0 anl: agl: junos:web

NOTE: See Boundary Conditions in this chapter for conditions and customizations required for deploying Juniper’s Traffic Direct service for mobile operators.

Chapter 6 – Consolidated Services 69

Chapter 6

Consolidated Services

This chapter discusses and presents an initial set of consolidated and validated microkernel services scenarios that have been identified as being applicable for (s)GI and validated.


Overview

The physical and logical configurations (Figures 6.1 and 6.2) are similar to the approach, as described in Chapter 4 with the distinction of routing the Gn traffic. The Services Delivery Gateway is front ending the packet gateways (GGSN, PGW) and acts as a next hop router for Gn traffic. No services are applied to Gn traffic. Furthermore, in this validated scenario, the optimization service complex provides both web and video optimization. As a result, policy routing steers HTTP traffic (TCP port 80) as a whole towards the optimization complex.

Services DeliveryGateway-active

Services DeliveryGateway-standby

(s)Gi

xn

xn

xn

xn

xnxnTo Internet

From RAN

GGSN, PGW

CORETRANSPORT

DMZ

Multimedia Optimization Service Complex

Incumbent Solution


DNS Partner / Incumbent

Figure 6.1 Physical configuration



LoadBalancing

DNS

GN

DMZINTERNET

FROMRAN

CGN/PAT/ALG/FW Public(s)Gi

Private(s)Gi

PolicyRouting

Private Public

CGN/PAT/ALG/FW

Multimedia Optimization Service Complex

LoadBalancing

CGN/PAT/ALG/FW

OPT

ServicesDeliveryGateway

GGSNPGW

Figure 6.2 Logical configuration

NOTE: During validation testing, the multimedia optimization complex was simulated by using a Squid server providing HTTP transparent proxy function and represented an incumbent vendor providing both web and video optimization. No PCRF or LDAP query was performed. However, a live system can perform this function.

Identified Services

The following identified services were enabled:

• CG-NAT (IPv4) ( ALGv4 – SIP, DNS, FTP, RTSP, HTTP).

• Stateful firewall (SFW) for IPv4 and v6 .

• Load Balancing (ECMP based on Layer 3).

• RPM (for health check on DNS Servers).


In addition, the following features were leveraged to compliment the identified services:

• Firewall filters on (S)Gi.

• VRRP, LAG (and MC-LAG) for High Availability.

• Routing instances.

• Basic ALGs for the SFW and NAT functions (HTTP, FTP, SIP, RTSP, PPTP).

Boundary Conditions

The following section defines the boundary conditions for proper functional deployment of the identified and validated (as services using software release Junos 11.2B2.4.

• NAT-related: Modifying the services configuration or state when NAT/SFW mappings are active should be avoided. This limitation specifically applies when changes are made to the services configuration with Endpoint Independent Mapping /Filtering or Address Pool Pairing features and NAT/SFW mappings being active.

Workaround – Disable the Endpoint Independent Mapping/Filtering or Address Pool Pairing features if not required.

If these features are not required, check that the flows and mappings have timed out. (Use the show services stateful-firewall flows and show services Nat mappings for this purpose). The default timeout value for the mappings is 5 minutes; this value is user configurable and can be set to a 2 minute minimum.

• Loss of ECMP-based Route: ECMP routes get lost from the routing table of the routing instance each time a configuration change that causes a routing recalculation is made. For example, the configuration changes that caused the route to be lost included toggling of firewall/interfaces states.

Workaround – Restarting the routing process causes the ECMP routes to be placed back in the routing table of the routing instance.

• MC LAG Traffic Flow: There were no responses to pings from the master interface of the LAG group. However, the pings to the VRRP address were successful.

Workaround – VRRP state may need to be bounced when MC-LAG is configured to achieve connectivity across member links.

Noteworthy Items

• Using ICMP ping probes provides the state of the IP stack when compared to any other type of monitoring that tracks the state of the physical interface.

• Enabling NAT and no Stateful Firewall (SFW) still causes the SFW statistics to increment. This is because the NAT and SFW code are tightly coupled.

• Certain NAT CLI commands are associated with the SDK services mode and return an error. RPM does not support DNS pings. Instead, ICMP ping probes can be enabled to the DNS server. ECMP is not an optimal solution for load balancing since the load gets redistributed each time a link to the servers fails.


Validation Test Bed Configuration

This section covers the physical and logical configuration used for validating the identified services as applied for the selected use cases and also provides details on the software and hardware information pertaining to the Services Delivery Gateway network element.

Physical Configuration

Figure 6.3 shows the physical configuration.

The Services Delivery Gateway pair consists of two MX Series routers, SDG1 and SDG2 (with MS-DPCs) connected between the Gn and (s)Gi sides of the network.

The setup consists of two MX960 routers (SDG1 and SDG2). The core consists of a pair of EX4500 switches acting as routers (Core1 and Core 2). Two MX960 routers function as DMZ routers (DMZ 1 and DMZ2). These two DMZ routers are interconnected. The core and DMZ routers connect to the SDG pair using LAG links.

The gateway functionality was provided by carving out a logical router on each of the SDG chassis. The Spirent Test Center/Shenick tools were used to simulate the inbound and outbound IP v4/6 flows (L4-L7) from the Internet servers and UEs, respectively.

The SDGs connect to the Squid and BIND DNS servers that simulate the MSP and DNS complexes, respectively. An EX4200 switch resides between the Services Delivery Gateway and servers to terminate the LAG connections. The network consists of two levels of DNS servers. The first level of servers received the DNS requests and forwarded them to the second level of servers. If the requested information was not cached at the Level 2 servers, the requests were forwarded to the root DNS through the Services Delivery Gateway. The DNS client and root server were simulated by the Spirent Test Center tool.


EX4500

MX960DMZ 1

190.3.1.2/24 172.28.113.203

SDG 110.13.96.54

CORE 110.13.96.45

12.12.1.9/30

12.12.1.10/30

190.3.1.1

Xe 2/1/0

Xe 2/1/0

Xe 2/0/0

Xe 2/2/1

Xe 2/0/0Xe 2/2/0

Xe 11/0/1

Xe 1/0/0

Ge 0/3/551.0.0.2 - GI-PUB

Xe 2/1/0

Xe 2/0/0

Ge 1/2/8

Ge 1/2/9 Ge 0/2/5

193.32.12/24

193.32.1.1/24

200.3.1.1/24

200.3.1.2/24

STC Server

MX960

STC Client

190.100.1.2/24 190.200.1.1

190.200.1.2

101.101.101.101/24

101.101.101.1

100.100.100.150.0.0.2/30 - GI-PVT

51.0.0.2/30 - GI-PUB

50.0.0.1/30 - GI-PVT

53.1.0.1/30

DNS2 - 10.13.98.45DNS1 - 10.13.98.44

51.0.0.5/30 - GI-PUB

50.0.0.5/30 - GI-PVT

190.1.1.3/24

190.1.1.4/24192.100.1.1/24

Xe 0/0/1 Xe 0/0/0

Xe 4/0/1 Xe 4/0/0LAG 3

Ge 0/0/5

Ge 2/5

LAG 2

LAG 15

LAG 16

LAG 6

EX4500

MX960DMZ 2

172.28.113.185

SDG 210.13.96.57

CORE 210.13.96

12.12.1.13/30

12.12.1.112.12.1.2

12.12.1.14/30

112.112.1.1112.112.1.2

212.212.1.1212.212.1.2

Xe 2/1/0Xe 2/2/0

Xe 2/2/1Xe 2/2/0

MX960

STC ClientDNS Servers

191.2.1.2/24

191.2.1.1/24Xe 0/0/2Xe 0/0/3

Xe 4/0/1 Xe 4/0/0LAG 3

Ge 0/0/5

Ge 2/6

LAG 2

*Logical Router on SDG Chassis

54.1.0.1/3053.0.0.1/3054.0.0.1/30

OPT/PROXY10.13.9.6

EX4200 EX4200

EX4200

*GW 1

MX960*GW 2

MX960

100.100.100.100/24

PPTP Client

54.0.0.454.0.0.554.0.1.454.0.1.5

53.0.0.653.0.0.753.0.0.853.0.0.953.0.1.453.0.1.5

Figure 6.3 Physical configuration used for validation


Logical Configuration

Figure 6.4 shows the logical configuration.

STC Content Server

MX960DMZ 1

MX960SDG 1

193.9.9.1/24Ge-0/2/0

12.12.1.9/30

ae2190.3.1.1

ae2

190.3.1.2/24ae2

101.101.101.1/24ae16.101

101.101.101.1/24ae15.101

100.100.100.1/24ae16.101

190.200.1.1/24

192.100.1.0/24

ae3

53.0.1.124irb301

54.0.1.124irb304

54.0.0.124irb303

53.0.0.124irb300

100.100.100.1/24

190.200.1.2/24

ae15.100

12.12.1.10/30ae2

Ge-2/7VLAN99-193.9.9.0/24VLAN102-193.32.1.0/24193.32.1.0/24

10.13.96.54

172.28.113.203

GI PVT

GI PUB

GN

MX960SDG 2

10.13.96.57

PPTP Client

Ge-2/5190.1.1.3

STC Client

EX4500

CORE 1

EX Series

10.13.96.45

54.0.1.4

54.0.1.5

DNS Servers

Squid Servers(Proxy)

54.0.0.4

54.0.0.5

53.0.0.7

53.0.0.9

53.0.1.4

53.0.1.5

53.0.0.6

53.0.0.8

GI PUB

GI PUB

GN

GI PVT

Figure 6.4 Validated logical configuration


The following information summarizes the logical configuration details of the network.

• Routing Instances – Gn, Gi Private, Gi Public in addition to inet.0.

• Services – NAT, Stateful Firewall, ECMP, RPM for health check of servers.

• Traffic (IPv4) – HTTP, FTP, RTSP, DNS, PPTP, SIP.

• Traffic (IPv6) – IMS application streams (SIP traffic).

• Routing

• SDG-DMZ

- iBGP, OSPF & OSPF V3

- Static in inet.0

• SDG-Core

- iBGP, OSPF & OSPF V3

- Static in inet.0

• SDG-GW (Gi/Sgi/ Gn/ S1U)

- Static

• SDG–DNS

- Static

• SDG–Optimization Proxy

- Static

• SDG-SDG

- OSPF, iBGP, OSPFv3.

Table 6.1 lists the high availability features that were enabled among network elements.

Table 6.1 High Availability Features

High Availability Features Node Combinations

VRRP VRRP - SDG-DNS , SDG-Squid , SDG-Gateways

LAGLAG - SDG-Core , SDG-DMZ , SDG-DNS , SDG-Squid , SDG-Gateways

MC-LAG MC-LAG - SDG-DNS , SDG-Squid, SDG-Gateways

NOTE: BFD is enabled over the links between Serve Delivery Gateways for fault protection and failure recovery.

Table 6.2 lists the LAG ID members among network elements.


Table 6.2 LAG IDs

LAG Endpoints LAG ID

SDG1-SDG2 LAG1

SDG-DMZ LAG2

SDG – Core (Gn) LAG3

SDG-DNS

SDG-Squid

SDG- Primary Gateway

Primary Gateway-SDG

LAG15

LAG16

SDG-Secondary Gateway

Table 6.3 lists the VRRP group numbers among network elements.

Table 6.3 VRRP Groups

VRRP Members VRRP ID Associated VLAN IDs

SDG1, SDG2 Primary Gateway1 VRRP1 100, 101

SDG1, SGD2 Secondary Gateway VRRP2 200, 201

SDG-Squid Servers VRRP3 90

SDG-DNS Servers VRRP4 91

Hardware Components and Software Releases

Table 6.4 lists the software release levels used by Services Delivery Gateway and the blades hosted in the chassis.

Table 6.4 Tested Services Delivery Gateway Software and Hardware

SDG Elements Version Numbered Required Purpose

MX Series (MX960) Junos 11 .2B2 .4 2 Services Delivery Gateway

MS-DPC (1) 2/chassis Hosting services

16x10GE MPC 5/chassis Line card connectivity

RE 2 Routing Engine

SCB 3

NOTE: An additional blade is required if enabling Radware ADC.


Use Cases

Three main use cases (UE DNS, HTTP traffic, Non HTTP traffic) were validated. Because IP flows pass through Services Delivery Gateway, required corresponding services were applied. Table 6.5 lists the corresponding consolidated services applied for these use cases.

Table 6.5 Use Cases and Corresponding Services

Use Case Services

UE DNS (query/response)FW Filter (ACL)

ECMP, RPM, Script

HTTP (TCP port 80)FW Filter (ACL)

ECMP, RPM, Script

Non HTTP

NAT

SFW

FWL Filter (ACL)

ECMP, RPM Script

UE DNS Call Flow (to DNS Service Complex)

Figure 6.5 illustrates the corresponding call flow for the UE DNS use case.

1 Ue DNS Query

Gn, S11-S1uSAEgw LBPvt Gi/SGi

OptimizationComplex

2 DNS Query

4 DNS Query

11 DNS Response

6 DNS Query

9 DNSResponse

3 DNS Query

5 DNS Query7 DNS Query

8 DNS Response

RemoveDNS Entry

Health Check Probe(RPM, Script)

Health Check Probe(RPM, Script)

Services Delivery GatewayPublicGi/SGiNAT/ALG/FWL

DNS ComplexCache Resolver

PVTVLAN

PUBVLAN

Port 53

No NAT, OptionalTimeout Entry Only

10 DNS Response

12 DNS Response

Figure 6.5 Validated logical configuration


The following steps outline the UE DNS call flow process.

1. DNS Query received from RAN over Gn/S1u/ S5 in Gn RI (routing instance).

2. DNS Query forwarded by SDG on Gn RI to GW (GTP-U Encap).

3. DNS Query from SAEgw on Gi/SGi; interpreted as DNS UDP port 53 traffic by SDG on Gi Private RI.

4. DNS Query forwarded through SDG on Gi Private RI to LB function.

5. DNS Query load balanced towards DNS Complex providing cache resolver function and local tiered DNS.

6. If required, DNS resolver forwards query from DNS public interface over SDG GI Public RI towards Internet or second level tiered DNS cache.

7. Optionally DNS Query may be passing through ALG/FWL (not part of this validated scenario).

8. DNS Response from Internet or Services Complex returns to SDG Gi Public RI and returned to DNS Complex

9. DNS Complex caches response.

10. DNS Complex forwards DNS Response over SDG Gi Private RI to SAEgw on (S)Gi.

11. SAEgw forwards the DNS Response through SDG towards UE.

12. SDG forwards DNS Response towards UE from SDG Gn RI through RAN over Gn / S1u / S5 (GTP-U Encap).


DNS Complex Topology

The UE DNS service complex provides a two tier level DNS caching function, as illustrated in Figure 6.6. The first level provides DNS cache resolving function. Level 1 DNSs (sharing a virtual IP 6.0.0.1), can query Level 2 DNSs for updated resolution upon cache lifetime expiration or new FQDN destination. Level 2 DNS queries as needed the public domain DNs. Connectivity from UE to Level 1 DNSs use a private VLAN. Communication between levels is achieved through a separate internal VLAN. Level 2 DNS accesses the Internet through the external VLAN tied to the public (s)Gi interface.

53.0.0.6

53.0.0.7

53.0.0.8

53.0.0.9

53.0.1.4

53.0.1.5

DNS 21

DNS 22

DNS Level 1

Internal VLAN

Virtual IP 6.0.0.1

DNS Level 2

53.0.0.1

53.0.1.1

VLAN301

DNS 12

DNS 13

DNS 14VLAN302

DNS 11

VLAN303

ServicesDelivery

Gateway

GI PVT

GI PUB

Figure 6.6 DNS complex topology

Table 6.6 summarizes the IP, VLAN and routing instance scheme.

Table 6.6 IP, VLAN and Routing Instance Scheme

Node Pair VLAN Routing Instance IP

SDG-DNS Level 1 301 GI-PVT

53 .0 .0 .0/24 (level1)DNS11-53 .0 .0 .6DNS12-53 .0 .0 .7DNS13-53 .0 .0 .8DNS14-53 .0 .0 .9

SDG-DNS Level 2 302 GI-PUB53 .0 .1 .0/24 (level2)(DNS21- 53 .0 .1 .4DNS22- 53 .0 .1 .5)

Inter-DNS 303 N .A .

DNS1- 53 .0 .2 .10DNS2 - 53 .0 .2 .11DNS3- 53 .0 .2 .20DNS4- 53 .0 .2 .21

Heartbeat is enabled from the Services Delivery Gateway leveraging RPM probes towards the DNS complex to detect the status level of the DNS server. Upon failure/active detection, action can be performed through a script to activate/deactivate the corresponding next hop.


Configuration Snippets and Logs

The following code snippets and logs pertain to the DNS configuration and scenario.

GI-PUB routing instancerouting-instances { GI-PUB { instance-type virtual-router; interface ge-0/3/5.102; interface ae2.102; interface ae11.202; interface ae11.205; interface lo0.102; routing-options { static { route 190.1.1.0/24 next-hop 53.0.1.4; } }GI-PVT Routing Instance – Routing to DNS complexrouting-options { rib GI-PVT:dns.inet.0 { static { route 6.0.0.1/32 { qualified-next-hop 53.0.0.6; qualified-next-hop 53.0.0.7; qualified-next-hop 53.0.0.8; qualified-next-hop 53.0.0.9; } } }}RPMrpm { probe icmp-dns { test dns11_status { probe-type icmp-ping; target address 53.0.0.6; probe-count 5; probe-interval 1; test-interval 1; routing-instance GI-PVT; thresholds { total-loss 3; } }

Reachability to DNS Complexsea-mobility@MX960-54SDG1-RE0# run show route 6.0.0.1

GN.inet.0: 45 destinations, 49 routes (45 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

6.0.0.1/32 *[Static/5] 1d 07:23:33 > to 100.100.100.1 via irb.100

GI-PVT:dns.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

6.0.0.1/32 *[Static/5] 1d 07:23:33 to 53.0.0.6 via irb.301 to 53.0.0.7 via irb.301 to 53.0.0.8 via irb.301 > to 53.0.0.9 via irb.301


Figure 6.7 shows a screen capture of the DNS query requests and responses at the client end. The requests and responses are sent to and received from the GI-PVT facing interface of the Level 1 DNS servers.

Figure 6.7 DNS query request from client

Figure 6.8 shows the capture of DNS query responses sent to the client. The requests/responses are sent to/from the public-facing interface of the Level 2 DNS server.

Figure 6.8 Spirent test center configuration on the DNS server


Non-HTTP Traffic Call Flow (to the Internet)

Figure 6.9 illustrates the non-HTTP traffic call flow.

1 Ue non-HTTP


OptimizationComplex

2 non-HTTP

8 non-HTTPReturn Tra�c

3 non-HTTP



PVTVLAN

PUBVLAN

Not TCPPort 80 Apply all

ConsolidatedServices


4 non-HTTP

7 non-HTTP Return Tra�c

5 non-HTTP


Figure 6.9 Non-HTTP traffic call flow (to the optimization complex)

The following steps outline the non-HTTP traffic call flow process.

1. Non HTTP traffic received from RAN over Gn / S1u/ S5 in Gn RI (routing instance).

2. Non HTTP traffic forwarded by SDG on Gn RI to GW (GTP-U Encap).

3. Traffic from SAEgw on Gi / SGi; interpreted as non HTTP traffic (TCP port different from port 80) by SDG on Gi Private RI.

4. Non HTTP traffic is forwarded by SDG on Gi Private RI through SDG NAT / SFW engine.

5. NAT’d non HTTP traffic is sent over public interface through a public RI to Internet.

6. Traffic from Internet returns to SDG through a public RI and is de-NAT’d.

7. De-NAT’d traffic is routed over SDG Gi Private RI to SAEgw on (S)Gi.

8. SAEgw forwards non HTTP traffic content through SDG towards UE.

9. SDG forwards non HTTP traffic content towards UE from SDG Gn RI through RAN over Gn / S1u / S5 (GTP-U Encap).



The following code snippets and logs pertain to non-HTTP configurations and scenario.

sea-mobility@MX960-54SDG1-RE0# show routing-instances GI-PVT instance-type virtual-router;interface ge-0/3/5.101;interface sp-5/1/0.101;interface ae2.101;interface irb.101;interface irb.301;interface irb.304;interface lo0.101;routing-options { static { route 190.1.1.0/24 { next-hop [ 100.100.100.1 101.101.101.1 ]; } route 193.9.9.0/24 next-hop sp-5/1/0.101; }}service-set COMBINED-TST_SET { stateful-firewall-rules NONHTTP-SFW-TST; nat-rules FUNC-TST-RULE; next-hop-service { inside-service-interface sp-5/1/0.101; outside-service-interface sp-5/1/0.99; }}stateful-firewall { rule NONHTTP-SFW-TST { match-direction input; term 1 { from { source-address { 190.1.1.0/24; 192.100.1.0/24 } destination-address { 192.100.2.0/24; 193.9.9.0/24; } applications [ junos-ftp junos-sip junos-icmp-all junos-rtsp junos-pptp junos-dns-tcp junos-dns-udp ]; } then { accept; syslog; } } term 2 { then { accept; } } }}nat { pool PORT80-TST-54 { address-range low 63.1.1.1 high 63.1.1.254; port {


range low 80 high 7000 random-allocation; } } rule FUNC-TST-RULE { match-direction input; term 1 { from { source-address { 190.1.1.0/24; 192.100.1.0/24 } destination-address { 193.9.9.0/24; 192.100.2.0/24 } applications [ junos-http junos-rtsp junos-sip junos-ftp junos-dns-tcp junos-dns-udp junos-pptp junos-tftp junos-https junos-icmp-all junos-traceroute ]; } then { translated { source-pool PORT80-TST-54; translation-type { napt-44; } inactive: mapping-type endpoint-independent; inactive: filtering-type { endpoint-independent; } inactive: address-pooling paired; } syslog; } } }}

sea-mobility@MX960-54SDG1-RE0# run show services nat pool detail Interface: sp-5/1/0, Service set: COMBINED-TST_SET NAT pool: PORT80-TST-54, Translation type: dynamic Address range: 63.1.1.1-63.1.1.254 Port range: 80-7000, Ports in use: 2, Out of port errors: 0, Max ports used: 401372

sea-mobility@MX960-54SDG1-RE0# run show services stateful-firewall flows Interface: sp-5/1/0, Service set: COMBINED-TST_SETFlow State Dir Frm countTCP 190.1.1.10:58481 -> 193.9.9.12:5720 Forward I 3 NAT source 190.1.1.10:58481 -> 63.1.1.197:1509 TCP 193.9.9.12:21 -> 63.1.1.197:5718 Watch O 11 NAT dest 63.1.1.197:5718 -> 190.1.1.10:58480 TCP 193.9.9.12:5720 -> 63.1.1.197:1509 Forward O 4 NAT dest 63.1.1.197:1509 -> 190.1.1.10:58481 TCP 190.1.1.10:58480 -> 193.9.9.12:21 Watch I 9 NAT source 190.1.1.10:58480 -> 63.1.1.197:5718

sea-mobility@MX960-54SDG1-RE0# run show firewall Filter: TOPOLOGY_BASED Counters:Name Bytes PacketsDNS-CNT 0 0HTTP-CNT 0 0NONHTTP_CNT 593 12


Sample Syslog message Jun 2 12:19:25 MX960-54SDG1-RE0 (FPC Slot 5, PIC Slot 1) {COMBINED-TST_SET}[FWNAT]: ASP_NAT_RULE_MATCH: proto 6 (TCP) application: pptp, irb.101:192.100.1.100:49472 -> 192.100.2.100:1723, Match NAT rule-set: , rule: FUNC-TST-RULE, term: 1 Jun 2 12:19:25 MX960-54SDG1-RE0 (FPC Slot 5, PIC Slot 1) {COMBINED-TST_SET}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: pptp, irb.101:192.100.1.100:49472 -> 192.100.2.100:1723, creating forward or watch flow ; source address and port translate to 63.1.1.1:5220

Figure 6.10 shows the screen captures of FTP Client/Server.

Figure 6.10 FTP client

Figure 6.11 shows the FTP server with NAT addresses.

Figure 6.11 FTP server (NAT addresses)


HTTP Traffic Call Flow (to Multimedia Optimization Service Complex)

Figure 6.12 illustrates the HTTP traffic call flow to the Multimedia Optimization Service complex.

1 Ue HTTP Request


OptimizationComplex

2 HTTP Request

8 HTTPReturn Trac

3 HTTP Request

Health CheckProbe

(RPM Script)

Health CheckProbe

(RPM Script)



PVTVLAN

PUBVLAN

PVTVLAN

PUBVLAN

TCPPort 80

No ServicesApplied

9 HTTPReturn Trac

(4a) PCRF Query orMIND Dip for Opt-in,

Opt-out, Per User/Device Optimization

Not PerformedDuring Validation

4 HTTP Request

7 HTTP Return Trac

6 HTTP Return Trac

5 HTTP Request (Amended Header)

Figure 6.12 Non-HTTP traffic call flow (to the Internet)


The following steps outline the non-HTTP call flow process.

1. HTTP request received from RAN over Gn / S1u/ S5 in Gn RI (routing instance).

2. HTTP request traffic forwarded by SDG on Gn RI to GW (GTP-U Encap).

3. HTTP request from SAEgw on Gi / SGi; interpreted as HTTP traffic (TCP port 80) by SDG on Gi Private RI

4. HTTP request is forwarded by SDG to optimization complex on Gi Private RI. SLB was not used towards the simulated optimization service complex.

a. HTTP Request on Gi / SGi; inspected by optimization complex which can perform a PCRF query or LDAP query to MIND database to receive UE/user characteristics (Opt-In / Opt-Out, optimization level to be applied).

This particular step (4a) was not performed during validation.

5. HTTP request (with amended header) is routed from optimization complex through SDG on Gi Public RI to Internet servers to fetch origin content. If requested content is cached it can be served from cache in optimization complex.

6. HTTP Response from Internet Content Servers transit SDG on Gi Public RI to optimization complex public interface bypassing NAT and LB.

7. HTTP Response routed from optimization complex private interface over SDG Gi Private RI to SAEgw on (S)Gi

8. SAEgw forwards HTTP response and content through SDG towards UE.

9. SDG forwards HTTP response and content towards UE from SDG Gn RI through RAN over Gn / S1u / S5 (GTP-U Encap).



The following code snippets and logs pertain to HTTP configurations and scenario.

sea-mobility@MX960-54SDG1-RE0# show routing-instances GI-PVT instance-type virtual-router;interface ge-0/3/5.101;interface sp-5/0/0.0;interface ae2.101;interface ae15.101;interface irb.301;interface irb.304;interface lo0.101;routing-options { rib GI-PVT.inet.0 { static { route 193.32.1.0/24 { qualified-next-hop 54.0.0.5 { metric 5; } qualified-next-hop 54.0.0.4 { metric 5; } resolve; } } } static { route 190.1.1.0/24 { next-hop [ 100.100.100.1 101.101.101.1 ]; } route 193.1.1.0/24 next-hop 190.3.1.1; } topologies { family inet { topology GI-PVT; } }}protocols { bgp { group SDG1-DMZ1-IBGP { type internal; local-address 10.101.101.55; family inet { any; } family inet6 { any; } peer-as 65501; local-as 65501; neighbor 10.101.101.25; } } ospf { area 0.0.0.0 { interface ge-0/3/5.101; interface ae2.101; interface ae15.101; interface lo0.101; interface irb.301; interface irb.304;


} }}

sea-mobility@MX960-54SDG1-RE0# run show firewall Filter: TOPOLOGY_BASED Counters:Name Bytes PacketsDNS-CNT 0 0HTTP-CNT 1932 28Filter: __service-COMBINED-TST_SET Filter: __default_bpdu_filter__

Figure 6.13 shows the UE generated HTTP messages.

Figure 6.13 Spirent HTTP request from client side

Figure 6.14 shows a Wireshark screen capture at the content server; the Squid server performs a T-proxy on messages that have arrived from the client side.


Figure 6.14 HTTP Server

Figure 6.15 shows communication on the private Gi interface on the Squid server.

Figure 6.15 Squid Server (Private GI)

Figure 6.16 shows communication on the public Gi interface on the Squid server.

Figure 6.16 Squid Server (Public GI)

Chapter 7 – Juniper Mobile Video Optimization Solution 93

Chapter 7

Juniper Mobile Video Optimization Solution

This chapter presents the Juniper Mobile Video Optimization (JMVO) solution and covers in detail the following major topics:

• Challenges presented by video streaming

• Main types of video streaming

• Juniper solution components and functions

• Key mechanisms

• Value proposition.


Optimizing the Mobile Network for Video Delivery

Video presents a unique conundrum for mobile operators. On one hand, the ability to deliver video efficiently to mobile devices presents a significant opportunity for new services, revenue generation and competitive differentiation. Services such as interactive video, anytime and anywhere delivery of premium video content and real-time surveillance are only a few of the possible value-added services that rely on efficient delivery of video to mobile devices.

Compounding problems is the sheer volume of video traffic that is straining mobile operators’ networks to their breaking point—making it difficult to deliver video with the quality that users expect. As mobile access becomes more ubiquitous and devices more capable, subscribers will be less likely to tolerate degraded quality—rather they will expect an experience similar to that which we now enjoy on wired networks. This means that to capitalize on the growing demand for mobile video, operators must first optimize their networks to deliver video efficiently, at scale and with exceptionally high quality. Juniper Networks unique solution combines the advantages of Openwave’s Media Optimizer together with Juniper’s Media Flow Controller and the Services Delivery Gateway (based on the MX Series 3D Universal Edge Routers) to optimize the network for mobile video delivery—reducing costs and enabling profitable new services.

The ChallengeThe increasing popularity of mobile video applications is straining operator networks. RAN (Radio Access Network) capacity limitations – on the air interface and/or in the cell backhaul network - hinder operators’ ability to cost-effectively deliver video with the quality that subscribers demand. If not dealt with soon, the challenge could become even greater in the future—by all estimates, though video already accounts for a significant portion of traffic on mobile networks, it is only expected to increase further. Yankee Group predicts that by 2013, mobile traffic will be “dominated” by video, with video accounting for over 65% of total traffic.1 Delivering all this video can be challenging for mobile operators, especially across the RAN where bandwidth can be limited and upgrades costly.

While video presents traffic growth challenges, it is also the current “killer app.” Video can often be the reason a consumer will upgrade to a more powerful device or a higher tier of service—both of which generate revenue for the operator. With a network that can efficiently deliver video, an operator could potentially introduce a range of new and profitable services. This means that delivering video with the highest possible quality of experience is clearly in the operator’s best interest.

1Preparing for the 4G Video Tsunami, November 2009

Mobile operators are looking for new technologies that will help them more efficiently deliver video that consumers demand, keeping costs at a minimum while at the same time providing a foundation for future revenue growth using innovative new services. With its JMVO solution, Juniper is addressing both of these goals—mobile operators can drive down costs, and they can also more efficiently and rapidly introduce new video-based services.


Juniper Networks Mobile Video Optimization Solution Overview

Juniper is delivering a unique solution that enables operators to deliver video more efficiently, at greater scale and with a superior quality of experience. Juniper’s solution uniquely combines MX Series (Services Delivery Gateway) with the complementary capabilities of Media Flow, the Openwave Media Optimizer, and the Openwave Traffic Controller application for the Services Delivery Gateway to address the diverse challenges of video delivery. (See Figure 7.1).

RAN

MEDIA FLOW

OPENWAVETRAFFIC CONTROLLER

High Performance Cachingand Delivery Content

Intelligent Tra�c Steering

OPENWAVE MEDIA OPTIMIZERContext-aware

Video Rate Adaptation

Services Delivery Gateway(based on MX Series)

INTERNET

GGSN

MFC

Figure 7.1 JMVO solution--Media Flow Controller, Openwave applications and Services Delivery Gateway

One of the primary challenges video presents is the amount of bandwidth that it consumes in the RAN. This is primarily a result of the high per-session bandwidth required of video services. Adding to the amount of bandwidth needed is the fact that many videos are encoded at bit rates appropriate for wired devices and networks. Often a mobile device lacks the resolution to fully benefit from the high bit rates delivered to tethered devices, and often the RAN lacks the performance to support such a stream. When the RAN lacks sufficient bandwidth, subscribers see a noticeable impact to quality—videos can halt and re-start and basically become unwatchable, other connected users in the cell are also impacted, and furthermore, connections can be dropped entirely.

There are two main HTTP streaming methods, Progressive Download (PD) and Adaptive Bit Rate streaming (AS).

Progressive Download (PD). The origin server encodes the video and downloads it to the client as fast as the network will allow. Traffic is buffered by the client until it can start playing it back – a good example of this method is the popular site YouTube. It has no mechanism to modify the bit rate as network conditions change. PD counts on buffering to handle any congestion in the network.

Adaptive Bit Rate Streaming (AS). The origin server encodes the video at a number of different bit rates and plays the video at the fastest rate that the client and the network can support. As network conditions change, the bit rate can dynamically change. Apple, Microsoft, and Adobe support this method. As an example, Netflix uses Adaptive Bit Rate Streaming and many content industry providers are moving in this direction.


HTTP ABR Streaming streams at the fastest rate supported by the client and the network and as a result is a “greedy” protocol that fills any available bandwidth capacity. Adaptive streaming is typically used with Digital Rights Management (DRM) protected content. DRM is protected and cannot be transcoded, transrated or modified in any manner.

Openwave’s Media Optimizer employs a transcoding and compression engine that can adapt the rate of progressive download video content to optimize video for mobile environments. By rate adapting video content in reaction to real-time network conditions, operators can reduce the impact of video on their networks, while ensuring a superior user experience for customers. This rate adaptation can be performed in real-time; however, the Media Optimizer also tracks the popularity of content, so that popular content can be pre-fetched and optimized offline. The combination of real-time and off-line optimization—especially when combined with the caching of Media Flow (Figure 7.1) ensures that operators get the same benefits for long-tail content as they do for the most popular content. The Adaptive Streaming (AS) bandwidth consumption is controlled by manifest file editing and bandwidth throttling.

To maximize performance and efficiency, the Media Optimizer also includes an intelligent policy engine that monitors conditions in the RAN. It only optimizes a video if there are bandwidth constraints, and if it is determined that optimization will not have a negative effect on viewing experience. These unique capabilities reduce load on the optimization engine—enabling industry-leading scale—and it ensures that subscribers receive the highest possible quality of experience. The solution leverages a combination of TCP flow and playback rate monitoring.

The Media Optimizer also leverages a unique just-in-time delivery capability that limits progressive download video downloads to only the amount required for smooth playback. This eliminates the unnecessary transmission of an entire video when a user might only watch the first portion of a given video—again reducing traffic across the valuable RAN. Just-in-time (JIT) delivery provides significant bandwidth savings for the operator without any negative impact to quality for the viewer. A user typically does not watch the entire video. A user starts streaming, then stops and moves on to something else. JIT is a mechanism allowing throttling the video delivery to ensure the player does not have an excess of data in its play back buffer. Figure 7.2 illustrates the benefit of using JIT.


Figure 7.2 JIT benefits

In addition, the JMVO solution relies on the Media Flow Controller to provide highly scalable caching. Media Flow can locally cache popular content after it has been optimized, which has two primary benefits. First, caching content after optimization reduces the load on the optimization engine for subsequent requests increasing scalability of the solution, and it also alleviates traffic across the IP core network. Second, caching and delivering content locally improves a subscriber’s viewing experience by reducing response times, latency and jitter.

Media Flow is the highest performing content caching and delivery platform on the market. It converges support for virtually all content protocols and formats into a single, consolidated solution. This superior scalability and converged architecture dramatically reduce the power, space and cooling costs associated with competitive caching systems.

To direct traffic to the optimization engine and cache, Juniper is delivering an Intelligent Traffic Controller application that can be deployed on the Services Delivery Gateway. The Services Delivery Gateway is based on the industry-leading Juniper Networks MX Series 3D Universal Edge Routers. It consolidates many critical network services on a single platform, which reduces costs, simplifies network design and operations and improves performance. The new Traffic Controller application enables the Services Delivery Gateway to intelligently and dynamically determine which destinations and types of content can most benefit from optimization, and it steers this traffic—and only this traffic—to Media Flow and the optimization engine. Because not all traffic is suited for optimization, having the intelligence to direct only certain traffic to the optimization engine dramatically improves the scale and performance of the solution.


Table 7.1 lists and describes the features and benefits of the JMVO solution.

Table 7.1 JMVO Solution Features and Benefits

Feature Description Benefit

Video rate adaptation Adapts the bit rate of a video stream to a given value appropriate to mobile networks and devices .

• Decreases bandwidth across the RAN .

• Increases quality of experience in the presence of congestion .

Video caching Caches and delivers popular content after optimization .

• Reduces load on video optimization server and lessens transit traffic .

• Improves quality of experience through decreased response times and latency .

Policy enforcement engine

Determines optimization parameters based on subscriber, content and network conditions .

• Ensures optimization only occurs when network conditions and subscriber experience benefit .

Intelligent traffic steering

The Traffic Controller application running on the Services Delivery Gateway steers only select traffic that can benefit from optimization and caching to the solution .

• Improves scalability of the solution .

• Enables flexibility to optimize traffic based on diverse technical and business requirements .

Congestion detection, management and avoidance

Ability to automatically detect congestion in the network and apply appropriate optimization techniques .

• Delivers the best experience possible for given network conditions

• Improves efficiency of optimization engine

Dynamic adaptation Solution continuously monitors the Internet for sites that can benefit from optimization and modifies policies accordingly .

Enables the solution to dynamically adapt to changes in consumer viewing habits .

Just-in-time delivery (buffer management)

Limits video downloads to only the portion of the video required for smooth playback .

Eliminates wasted downloads of entire videos when a user watches only the first portion .

AS streaming control Manifests file editing and bandwidth throttling capability .

• Keeps under control upward adaption rate greediness of AS stream .

• Allows bandwidth limit DRM content

In the near term, the solution provides immediate benefits. By reducing traffic across the RAN, mobile operators can support an increased number of subscribers per geographic area. Costs are reduced because operators can defer investments in upgrading the RAN infrastructure to deal with increased traffic growth.

Longer term, the solution can lay the foundation for many new business models and revenue opportunities. With a network optimized for video, mobile operators can confidently deliver premium video content to their subscribers. Operators can also potentially work with content providers to develop new offerings that deliver video content with an assured level of quality and viewing experience.


Solution Components

The JMVO solution, which initially supports IPv4 only, consists of Juniper Networks Media Flow Controller, Services Delivery Gateway (hosting the traffic controller application), and the Openwave Media Optimizer. See Figure 7.3.

Superior User Experience

Improved Scale–Foundation For New Services

Reduced Costs

IntelligentTra�c

Steering

HighPerformance

Caching

Policy-basedVideo RateAdaptation OPENWAVE MEDIA

OPTIMIZER

Dynamic Rate-adaptationof Video

Context-awarePolicy Engine

SERVICE DELIVERYGATEWAYwith Integrated

Openwave Tra�c Controller

MX Series

MEDIA FLOW

MFC

Industry-leadingCaching Performance

Figure 7.3 Primary network components of the JMVO solution

• Juniper’s Services Delivery Gateway (MX Series):

- Whitelist is updated and uploaded into the Services Delivery Gateway through the RE-SDK.

- Intelligent traffic steering based on the whitelist and provides steering towards JMVO complex.

• Openwave’s Media Optimizer optimizes video for:

- Rate-adapting in real-time customer requests for video (typically for long tail content not previously adapted).

- Tracking popular content to pre-fetch and optimize off-line popular content.

• Juniper’s Media Flow Controller performs caching mainly for multiple bit rates transrated/coded video, rather than open Internet content.


Table 7.2 summarizes the functionality and benefits provided by each solution component.

Table 7.2 Solution Components Description and Benefits

Solution Component Function Benefit

Media Flow Controller

Highly scalable platform caches and delivers content locally, increasing response times and reducing transit traffic .

• Scalable, converged system reduces number of servers required .

• Reduces load on video optimization server

Openwave Media Optimizer

Includes the optimization engine that reduces the bit rate of the video and the policy engine which makes optimization decisions .

• Reduces traffic across the RAN

• Ensures superior user experience by eliminating congestion

Services Delivery Gateway

Provides the foundation for the Traffic Controller application, as well as other router-integrated applications .

• Provides a platform for future services, applications and capabilities .

• Enables intelligent traffic steering .

Intelligent Traffic Controller application

An application that runs on the Services Delivery Gateway and steers only select traffic for optimization and caching .

• Improves scalability of solution .

• Enables flexibility to optimize traffic based on diverse technical and business requirements .

Minimizing the Solution Cost

The following considerations have been put forward to ensure that the solution cost of Juniper’s mobile video is competitive and kept to a minimum:

• Services Delivery Gateway’s “Intelligent” traffic steering leverages the whitelist mechanism to reduce the amount of traffic as non-video traffic bypasses the optimization complex. The solution is sized to support only a subset of the data traffic, namely the video portion thereby reducing costs with respect to hardware footprint and licensing.

• External load balancing is not considered as it would add to the cost. Load balancing towards the video optimization leverages ECMP.

• The primary role of the Media Flow Controller is to provide a caching function for trans-coded/rated content from the Media Optimizer OOE, not necessarily open Internet content caching.

Mobile Video Optimization Functional Description

Juniper’s Mobile Video Optimization service uses three main components. The call flow for this service has basically three parts:

• Service Delivery Gateway and the Media Optimizer service complex

• Media Optimizer service complex and Media Flow Controller

• Media Optimizer service complex/Media Flow Controller accessing the origin content either directly or through Junos services in the Service Delivery Gateway.

The Services Delivery Gateway steers identified traffic towards the Openwave Media Optimizer (MO) service complex to perform the necessary level of optimization. To steer the intended traffic, the Services Delivery Gateway is populated with well-known IPv4 destinations corresponding to OTT video origin


servers. The Openwave complex keeps track of these destinations. The Service Delivery Gateway and Openwave Media Optimizer OAM use a whitelist mechanism. The whitelist mechanism consists of a whitelist client known as the Traffic Steering Controller (TSC) operating in the OAM blade within the Openwave Media Optimizer service complex and a White List Manager Daemon (WLMD) implemented through the RE SDK in the RE.

The whitelist client, using a time base trigger, uploads and updates the whitelist entries towards the WLMD which in turn updates the video traffic steering filter in Services Delivery Gateway’s PFEs. The current whitelist capability only supports TCP port 80 and DA IPv4. The WLMD follows the graceful RE switchover (GRES) capability. The whitelist can be pre-populated with well known destinations and learn new destinations from the sampling and video content detection mechanism. Known IPV4 destination addresses are valid for the duration of the TTL returned by DNS lookup per IP. If the DNS does not provide a TTL value, it is possible to specify one.

The Services Delivery Gateway provides a so-called sampling function allowing it to pseudo-randomly send non whitelist traffic for a specified time towards the video content detector blade within the Media Optimizer service complex to determine if the traffic is in fact video traffic. The complex can then update the whitelist accordingly.

In addition, a health check manager, known as Content Detector Monitor (CDM), checks the status of the video content detector to turn off/on the sampling function in the Services Delivery Gateway to avoid black hauling user traffic.

The user-plane traffic has to be load balanced using ECMP between the Services Delivery Gateway and the OPWV complex. Scripts, using Real-Time Performance Monitoring (RPM) probes, must be leveraged to detect the health status of the Media Optimizer core blade servers to take appropriate action leveraging Extensible Stylesheet Language Transformations (XSLT) scripts. For further details concerning RPM and XSLT, refer to what the Solution Engineering Architecture EDN/CDN team has validated at www.juniper.net/us/en/local/pdf/app-notes/3500198-en.pdf.

IP traffic entering the Openwave Media Optimizer complex, takes a different path in function for following events and criteria.

• Request type

• Type of content

• If content is present in the cache

• If a cache miss occurs

• If requested content is placed in the hotlist.

The Media Optimizer core blades load balance (static round robin) transaction requests towards the Media Flow Controllers to fetch requested optimized content from cache and detects the status of the Media Flow Controller. If a Media Flow Controller fails, it is removed from the static round robin pool. A failed Media Flow Controller returns to the pool once it is detected being back online after a timeout and a successful transaction. The JMVO service complex also performs a HTTP revalidate with the origin server to ensure that the cached content can be served.




Juniper’s Mobile Video Optimization Service Complex Sub Components

Once traffic has been determined as matching the policy requirement as previously described, it enters the JMVO service complex. This service complex has multiple sub-components that provide specific functions. The overall application runs on server blades. Figure 7.4 illustrates a high level architectural view of these functions running as a standalone solution.

Video Content(Stream Mode)

Video URLsCache Lookup

PopularSharedCache

Retrieve“Popular Videos”

for O�ineProcessing

VIDEO OPTIMIZATION SERVER(Realtime Optimization) OFFLINE OPTIMIZER

INTERNET

CONTENT AWAREMEDIATION PLATFORM

Cache

Figure 7.4 Media Optimizer high level sub-components architectural view

The Media Optimizer service complex consists of the following key sub components:

• Video Optimization Server (VOS): Provides real time dynamic optimization.

• Media optimizer platform: Represents the context-aware mediation platform, known as Media Optimizer core blade and also acts as the video content detector.

• Offline Optimization Engine (OOE): Provides off line optimization and uploads content to the cache (Media Flow Controller).

• Media Flow Cache: Provides transrated/coded cached content.


The JMVO complex acts as a video-aware policy enforcement point capable of addressing primary video traffic types in the network__HTTP-Progressive Download and HTTP-Adaptive Streaming using a combination of traffic shaping, and content transcoding. Effectively, it addresses the diverse video codecs and protocols in use both as a self-contained media traffic management solution and under direction received from the Policy and Charging Rule Function (PCRF). Policies can be based on device type, screen size, time of day, subscriber profile/plan and many other criteria. As an example, Figure 7.5 illustrates online optimization performed for a video stream with screen size resolution of 480p (watermark and JIT) but not for 720p.

Figure 7.5 Policy example –screen resolution

The key solution benefits include:

• Transcodes and Rate-adapts progressive download video to reduce video bit rate and thereby reduce congestion while maintaining user quality experience.

- Can be done in real-time or offline.

• Eliminates wasted bandwidth from partial downloads with Just-In-Time (JIT) delivery.

• Considers many intelligent factors as a context-aware approach, such as

- Content type.

- Flow latency and packet loss which can indicate network congestion and/or air interface link problems, for example the user is at the cell edge.

- User demand and preferences.

• Ensures optimization and only occurs when needed and when operator deems it beneficial.

- Consistent with “reasonable network management” principles.

- Operator also can optimize differently based upon their preferences, for example user class for managed versus unmanaged content.

• Offers high performance caching and content delivery platform.

- Delivers industry leading scale and performance.

- Enables video delivery to any screen.

- Supports all major protocols and formats.


• Caches popular content and objects.

- Stores multiple bit-rates of a given video.

- Offloads Optimization Engine, improving efficiency and performance.

- Serves subsequent requests locally, reducing response times and latency.

• Can also be deployed independently to meet caching and content delivery requirements.

- Transparent caching.

- Content delivery infrastructure.

- Converged content delivery for IPTV and multiple screens.

The JMVO complex applies a variety of video optimization capabilities including JIT delivery of content, adaptive streaming rate limits to better manage mobile traffic load and transcoding/transrating of content.

The Juniper solution can dynamically compress PD videos (see Figure 7.6) when downloaded from the origin server. The solution does not wait for the video file to be completely downloaded before the optimization process begins. Different levels of compression are available depending on the situation. Popular video can be pulled down and compressed offline at multiple bit rates and cached for future viewing.

Approaches to control adaptive streaming include traffic shaping and modifications to the manifest file. Both can cause the client to request a flow with a reduced bit rate. The Juniper solution provides comprehensive mechanisms to manage Adaptive Streaming, as shown in Figure 7.6. The Juniper solution simply tricks the mobile device into asking for a lower bit rate when necessary. Even though DRM content is protected because it is adaptively streamed, Juniper’s solution can still manage DRM content with bandwidth control.

All streaming video techniques use TCP. By monitoring video flows that pass through the Media Optimizer, it is possible to detect flows that are slowing down. Congested flows are made to slow down through the normal process of TCP flow control. In addition, the Juniper solution also tracks and compares the average download rate against the playback rate of the video. If the average download rate falls below the playback rate that is a good indication of congestion. Optimization will then occur before the video starts to stutter or freeze.


Non-optimizable Tra�c

Adaptive Streaming

Web

Network Under Stress

HTTP - PD


Adaptive Streaming

Web


HTTP - PD


Adaptive Streaming

Web


HTTP - PD


No Optimization EnableWeb Optimization

Enable HTTP-PDOptimization

Enable AdaptiveStreaming Optimization

Adaptive Streaming

Web

Stress Relieved

HTTP - PD

Network Savings

Figure 7.6 Progressive download and adaptive streaming treatment

For adaptive streaming content, the Openwave Media Optimizer service complex can shape the video traffic to a provisional limit to ensure that the traffic rate used by the flow is suitably matched to the capacity of the RAN and the capabilities of the devices in the network to achieve network savings. The AS video does not use a fixed bitrate like the progressive download video does. Instead, it seeks to maximize the throughput to each user using a “greedy” protocol. While it adapts to congestion, it also can increase the bitrate under good conditions. It is this upward adaption that needs to be managed. The Juniper solution can manipulate the manifest file used by popular player (Apple, Adobe, and Microsoft) at the beginning of streaming and dynamically squeeze the available bandwidth during streaming if needed. Figure 7.7 illustrates these two mechanisms.

MANIFEST FILE OPTIMIZATION (optional) DYNAMIC BANDWIDTH THROTTLE

Video Stream atDi�erent Bit RatesSelected

Bit StreamModifiedManifest

File

ReducedBandwidthAvailable

Bandwidth

MEDIAOPTIMIZER

Intelligent throttling (manifest file-based)

Support for internal and externalthrottling engines

Throttle the available bandwidthdynamically, based on network conditions

Policy-controlled processing

Controls tra�c flow at beginning ofstream only

Remove higher bit rate options from manifest file

Figure 7.7 Adaptive Bit Rate streaming bandwidth optimization mechanisms

Figures 7.8 to 7.10 illustrate this principle for a video played with Microsoft Silverlight:


Figure 7.8 illustrates how AS consumes available bandwidth (up to 1.5Mb/s) before any mechanism is applied.

Figure 7.8 AS Silverlight streaming with no upward bitrate limitation

Figure 7.9 illustrates the upward bitrate limitation control perform when the optimization engines edit the manifest file.

Figure 7.9 AS Silverlight upward bitrate limitation through manifest file editing


The following information in the accounting record provides insights on what was edited in the manifest file.

AS: MS-64000; -630000,470000,350000;2750000,2040000,1520000,1130000,845000

The above RBA (Record-Based Accounting) line indicates that it was a MS Silverlight Adaptive Stream. MO left 64,000 bps audio in the manifest file sent to the client. MO also removed 2750000,2040000,1520000,1130000,845000 video bitrates and left 630000,470000,350000 in the manifest file sent to the client. The stream throughput settles to an uprate limit of 630kb/s down from 1.5Mb/s.

Figure 7.10 illustrates bandwidth throttling set to 80KB and the client selects and sustains acceptable bitrate accordingly.

The video goes to a lower bitrate once the changes take effect, while the video moves on to the next chunk(s), reducing from 630kb/s to 470kb/s and then finally reducing to 350kb/s.

Figure 7.10 AS Silverlight upward bitrate limitation through bandwidth squeeze

For video traffic applicable to transcoding/transrating optimizations, the Media Optimizer core blade first performs a cache lookup. If the video is in the cache (Media Flow Controller), Media Optimizer core blade fetches the video from the cache and returns the content to the mobile device.

However, if the video is not in the cache (cache miss), Media Optimizer core blade fetches the content from the origin server and then forwards the traffic onto the VOS to perform optimization based on configured policy. VOS optimizes video content in real time and returns the result back to Media Optimizer core blade to be streamed to the mobile device. If the plan attribute VideoWatermark is enabled the video shows the corresponding logo to indicate online optimization is applied.

NOTE: The logo can be changed.


Figure 7.11 shows online optimization with watermark showing on the top right corner.

Figure 7.11 On-line optimization with watermark

It should be noted that VOS does not wait for the entire video to be downloaded from the origin server to perform optimization but instead performs optimization on the chunks of content that are received from the origin server. Figure 7.12 shows a streaming comparison of a video modified with different compression levels.

Figure 7.12 Streaming comparison of a video modified with different compression different levels


In addition, if a video has been requested by multiple users and has exceeded a configurable number of request thresholds (Hot list /popularity count) over a defined time period, the Media Optimizer core blade will fetch the highest quality version of the video from the origin server and the Offline Optimization Engine (OOE) performs offline optimization. An offline optimized video can be identified by a green frame around the video, as illustrated in Figure 7.13

Figure 7.13 Offline optimized video with green frame (represented by white dashed line)

JMVO provides Record Based Accounting (RBA) capabilities. RBA captures information useful for purposes such as billing, Management Information Systems and license revenue recognition.

Sets of data that are collected into a Media Optimizer Accounting Detail Record include:

• A basic data set that is collected regardless of the underlying protocol used.

• RBA’s own data.

• A set of data that is specific to the protocol of the originating request, for example in the case of Media Optimizer core blade - HTTP.

• Additional sets of data added by the operation of individual Service Enablers.


The following provides an example of an RBA record.

Video Link: http://megavideo.com/?v=0RQ81CDT Device: HTC Desire Z (running Android 2.2.1) AccountRecord:HTTP_NGP:1006 2011-06-14 14:54:00 ← Record Header RecordSize 2218 SchemaName MEP_HTTP_RECORD protocolVersion 2.0 hostName jun02.juniper.net recordDiscriminator 79694636 ← Correlation Id deviceIP 192.169.1.108 ← UE IP deviceBytesIn 0 deviceBytesOut 7990796 internetBytesIn 17840416 internetBytesOut 0 contentDelivered false requestReceivedTime 1308088335 internetLatency 2157 clientResponseSendTime 1308088338 clientResponseSendLatency 0 txnCompleteTime 1308088440 requestURI http://www477.megavideo.com/files/994b2487bdaba5c5677e5be53bfc017e/ method GET statusToClient 200 statusFromOrigin 200 protocolType HTTP/1.1 originContentType video/flv originContentLength 42550070 reqHdrs.accept text/xml, text/html, application/xhtml+xml, image/png, text/plain, */*;q=0.8 reqHdrs.userAgent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17 rspnsHdrs.contentLength 42550070 rspnsHdrs.contentType video/flv seData.0.seName 3014 seData.0.osLatency 0 seData.1.seName 3017 seData.1.reqLatency 0 seData.10.seName DynamicURLHandlerSE seData.10.reqLatency 0 seData.11.seName HDREXPORT seData.11.reqLatency 0 seData.12.seName HDRIMPORT seData.12.reqLatency 0 seData.13.seName HDRMANIPULATION seData.13.reqLatency 0 seData.14.seName IDENTITY seData.14.reqLatency 0 seData.15.seName PLAN_MANAGEMENT seData.15.reqLatency 2 seData.16.seName ResponseThrottleSE seData.16.pdLatency 0 seData.17.seName SeekImportSE seData.17.reqLatency 0 seData.18.seName TranslationRouterSE seData.18.reqLatency 2 seData.19.seName VideoRouterSE seData.19.pdLatency 1 seData.2.seName 3039 seData.2.reqLatency 0 seData.20.seName WebSrvClientSE seData.20.reqLatency 0 seData.3.seName 7030 seData.3.pdLatency 0


seData.4.seName 8001 seData.4.pdLatency 0 seData.5.seName AUTHORIZATION seData.5.reqLatency 0 seData.6.seName BasicACL seData.6.reqLatency 0 seData.7.seName ContentDetectionSE seData.7.osLatency 0 seData.8.seName DEVICE_MGMT seData.8.reqLatency 0 seData.9.seName DomainMonitoringClientSE seData.9.reqLatency 0 planNames Device:VideoPlan-laptop System:System,Anonymous totalTransactionTimeElapsed 105563 RT:80888;101462;4792402;17649

High compressionD dynamicOrigin size 42550070 Compressed size 17840130Played size 7990397

VDO:2;high;D;42550070;17840130;0;7990397;flv;H264;H264;AAC;AAC;266;F;T;80888;101462;0;D;I TransparentProxyRequest CD: video/x-flv NA NA

White List and Sampling Mechanisms

The White List mechanism is a key mechanism in Juniper’s Mobile Video Optimization solution. Initially, because traffic identification can be performed only for TCP port 80 and well-known destination IPv4 addresses from the origin server, the whitelist mechanism allows decreased amounts of traffic to be sent to the Media Optimizer core blade. As such, the whitelist mechanism provides an immediate total cost of ownership benefit for the video optimization complex.

NOTE: Currently, only IPv4 is supported.

The WLMD resides on the RE blade, populates the PFE video traffic steering filter and also controls the sampling function. The whitelist client (TSC) resides on the OAM blade of the OPWV server blades complex. The mechanism uses the Juniper White List Management (JWLM) protocol on top of TCP. Destination port default value is 2000 and can be configured to a different value. Figure 7.14 illustrates Juniper’s intelligent traffic steering component architecture.


RE

PFE

JTC ON JUNIPER MX SERIES ROUTER

MO COMPLEXON X86 SERVERS

WhitelistedOrigin Server

Non-whitelistedOrigin Server

Whitelisted HTTPNon-whitelisted HTTP

Non-whitelistedHTTP Packets

HeartbeatHTTP/GET

Video HTTPPackets

WhitelistUpdate

Whitelist Update

SampledHTTPPackets

Non-whitelisted HTTP

White ListManagerDaemon(WLMD)

SamplerFilter

Video Tra�cSteering

Filter

OAM TSC

Java Plugin

ECMP LB CD Monitor(part of WLMD)

Core BladeContentDetector

HTTP Client

HTTP Client

HTTP Client

Private ISP Network Internet

Core BladeMedia

Optimizer

Figure 7.14 Juniper’s intelligent traffic steering component

This component is implemented as a Juniper RE daemon that

• Listens for whitelist updates from the TSC.

• Builds and installs the whitelist as Juniper filter rules.

• Sets traffic sampling interval and duration.

• Configures sampling filter rules.

To configure the WLM daemon function, the following extensions must be present.

system { extensions { providers { openwave { license-type evaluation deployment-scope private; license-type strategic deployment-scope private; } } }

The production version will use a production license and this configuration will not be needed further.

}


The configuration for the WLM daemon falls under the following:

extensions { openwave {

The whitelist client (TSC) opens a TCP session (default port is 2000) towards the whitelist manager to upload/update the whitelist. It is done through JWLM Request, Message type 1 and includes a list of IPv4 addresses. The TSC expects to receive a JWLM Response, Message type 2 with cause code 0 which indicates success or 1 which indicates failure. The TCP session closes afterwards. It is possible to pre-populate the whitelist with well-known site addresses to minimize learning time. Automatic updates triggered by TSC are time based, for example between 3 AM and 4 AM.

traffic-controller { debug; interface xe-5/0/0.720; whitelist-manager { update-listener-port 2000; routing-instance to-MOs; }

The user traffic that is white listed is sent to the Media Optimizer core server blade pool through the ECMP load balancing function. See Using MX Series as a Server Load Balancer-- Leveraging ECMP and the Trio 3D Chipset to Integrate Functionality at www.juniper.net/us/en/local/pdf/app-notes/3500198-en.pdf.

RPM probes are defined to detect the status of the core Media Optimizer core blade: RPM HTTP probe. Get (target url http://10.17.75.4:3128)

Upon status detection change, a script is called to install/remove a filter on the egress sub interface to which logically connects the Media Optimizer core blade.

• Status failure detection: Install bypass filter script runs to install the filter and redirect traffic to internet.

• Status completion detection: delete bypass filter script runs to remove the filter.

ECMP hash is not changed since next hope routes in the table are not removed/activated/deactivated. Existing already Load balanced flows are not disturbed, flows that were going to failed core blade are redirected to internet (no optimization here but user still can access the content). New flows are load balanced between remaining core blade that is active.

For this to correctly function, the following must occur:

1. Use of sub-interface/vlan to logically connect from SDG to core blades.

2. RPM probes definition should follow a certain logic.

a. RPM probe name corresponds to the physical interface were the sub-interfaces/vlan connecting to core blades are defined.

b. RPM test names in the RPM probe ought to correspond to the sub-interface ID.



This is because the RPM result (ping test completed or failed) includes both (2a, 2b). Therefore, it is possible to fully identify on which egress the script to redirect traffic to Internet should be installed.

I.E: interfaces { ge-1/0/0 { description TO-ALL-other-MO-SERVERS; vlan-tagging; unit 4 { vlan-id 4; family inet { address 10.17.75.1/29; } } unit 10 { vlan-id 10; family inet { address 10.17.73.1/24; } } unit 12 { vlan-id 12; family inet { address 10.17.75.9/29; } } }services { rpm { probe ge-1/0/0 { test 4 { probe-type http-get; target url http://10.17.75.4:3128; probe-count 2; probe-interval 1; test-interval 2; thresholds { total-loss 1; } } test 12 { probe-type http-get; target url http://10.17.75.12:3128; probe-count 2; probe-interval 1; test-interval 2; thresholds { total-loss 1; } } } }}

The video optimization complex continues to learn new destination IP addresses. This is accomplished through the sampling function in the Services Delivery Gateway interacting with a video content detector blade (core blade) in the Media Optimizer service complex.


The sampling function is configured by a router administrator with the following parameters for the sampling:

• Carrier network prefix (10.10.0.0/16). More than one prefix can be present.

• Sample size or subnet suffix (256 host addresses).

• Sample period (Daily sampling with a given configurable restart time to proceed with new sampling definition). This time of the day follows the Juniper convention (02:11:59 -0700).

The sampling algorithm appends a random number. The resulting sample source subnet is then installed in the second term in the firewall filter.

sampler { daily-sampling { restart-time “02:11:59 -0700”; } sample-pool-size 11; net-prefixes 10.17.72.0/24; routing-instance to-ContentDetector;}

There is a health check probe to verify the status of the blade providing video content detection function. The result of this heartbeat drives the WLMD to turn off/on the sampling function for the user traffic that is not white listed to ensure it is not backhauled.

This health check heartbeat is controlled by the WLM daemon and uses HTTP Get request ping (HEAD http://integra-cd-host-ip/index.html). The heartbeat is successful unless there is a socket error or timeout. Pings are attempted at configured intervals to detect the recovery and presence of the video content detector blade to reactivate sampling at the next scheduled sampling period.

content-detector-monitor { ping-interval 2; timeout 5; ping-address 10.17.73.10; ping-port 80; }

A trace function is also available to help troubleshoot events.

traceoptions { file HO4_Test.trace; level all; flag all; }

The following code snippet is an example for configuring the whitelist, sampling, video content detection heartbeat and logging.

system { extensions { providers { openwave { license-type evaluation deployment-scope private; license-type strategic deployment-scope private; } } }}extensions { openwave { traffic-controller { debug; interface xe-5/0/0.720; whitelist-manager { update-listener-port 2000; routing-instance to-MOs; } sampler { daily-sampling { restart-time “02:11:59 -0700”; } sample-pool-size 11; net-prefixes 10.17.72.0/24; routing-instance to-ContentDetector; } content-detector-monitor { ping-interval 60; timeout 90; ping-address 10.17.73.10; ping-port 80; } traceoptions { file HO4_Test.trace; level all; flag all; } } } }

The production version will use a production license and this configuration will not be needed further.


Media Flow Controller

Although the JMVO has internal caching capability within the Media Optimizer core blades, it is turned off and the caching function is provided by Juniper’s Media Flow Controller running on Juniper Networks VXA2010 Media Flow Engine. For further details concerning the Media Flow Controller and VXA, refer to www.juniper.net/us/en/products-services/software/content-media/media-flow-solution/vxa-series/vxa2010/ and www.juniper.net/us/en/products-services/software/content-media/media-flow-solution/media-flow-controller/#features-benefits.

Media Optimizer core blade uses HTTP to fetch content from Media Flow Controller cache during a cache look up. If there is a cache miss, Media Flow Controller returns error code 404 and Media Optimizer core blade gets the content from the origin server directly. The Media Optimizer OOE uses FTP to ingest optimized content (after it has been trans-coded) into each deployed Media Flow Controller.

NOTE: The primary function of Media Flow Controller is to cache trans-rated/coded content for the JMVO. The goal is to minimize the solution cost. Media Flow Controller can provide caching for open Internet content as well. Currently, there is more than one Media Flow Controller deployed per site in a non-clustering mode to provide high availability. The Media Optimizer core blades load balance in a round robin fashion towards all deployed Media Flow Controllers. Media Flow Controller failure detection occurs when a Media Optimizer core blade attempts a transaction with the Media Flow Controller. Restoring a failed Media Flow Controller in the pool is time-based and requires one successful transaction between Media Optimizer core blade and Media Flow Controller. The Media Optimizer OOE attempts an FTP upload to all Media Flow Controller servers. Failures are not re-attempted.

The following code snippet shows administrators how to fine tune the Media Flow Controller, in addition to usual Media Flow Controller configuration, to interact with Media Optimizer core blade blades and OOEs.

enconfig t

virtual-player vp_owave type generic seek-config query-string-parm seek seek-flv-type time-msec seek-mp4-type time-msec exitexit

namespace ns_owave# This is the username and password to use in order to FTP content into Media Flow. pre-stage ftp user ns_owave_ftpuser password password match uri /

#Use the following line if Media Flow Controller has other namespaces other than this one. Otherwise, comment it out. domain <IP of MFC>

www.juniper.net/us/en/products-services/software/content-media/media-flow-solution/vxa-series/vxa2010/



www.juniper.net/us/en/products-services/software/content-media/media-flow-solution/media-flow-controller/#features-benefits



# Setting the origin server to 127.0.0.1 will ensure that a 404 is returned on a cache miss. origin-server http 127.0.0.1 8080 delivery protocol http origin-fetch content-store media uri-depth-threshold 16 origin-fetch cache-age-default 12441600 exit status active virtual-player vp_owave exit

Functional Test Setup Validation

Figure 7.15 illustrates the topology used for functional validation aspect. The main network elements used the following software release level.

MX: 11.1R1.14 OPWV: EA1 Alpha code drop MFC: image-mfc-2.1.1-qa-44_17808_247.img

INTERNET

SB Box

Services Delivery Gateway/MX240

EX2200

CDOAMOVOS

MFC-A

MFC-B

ReportingVSE

FW/NATSRX210

CoreVOS

DNS 8.8.8.8NTP 172.17.27.46

802.1q Trunk

VLAN 1210.17.75.9/29

VLAN 410.17.75.1/29

VIP 10.17.73.60/24

.70

.80

.30

.40

.12

.4

.12 10.17.72.0/24

.13 10.17.74.0/24

.1

.1

.1

.210.17.0.0/24

172.19.91.103

.50

VLAN 1010.17.73.1/24

CoreVOS

Figure 7.15 JMVO Solution Topology for Functional Validation


Main Corresponding Call Flow

This section describes the high level call flows for the following scenarios.

• Requested video is in the cache

• Requested video is not in the cache

• Traffic sampling.

Note that the following figure illustrates that video is cached. Figure 7.16 shows the white list update mechanism and scenario when the requested video is in the cache.

Tra�cControl

RE-a1RE-a2

a)

MediaOptimizer

b

MediaOptimizer

a

VOS OOE MINDPCRF

MFC-aWLClient

LB IncumbentWeb

Optimization


Video Optimization Complex Trans-ratedCache Complex

OriginServer

MFC-b

TCP EST Port

JWLM Req (Initial List Upload)

Serve Optimized Content to UE

JWLM Resp (0, Success)

Content is Present

HTTP Revalidate

Optimized Req —>Cache Lookup(HTTP Get to Fetch Content)

Video LB

TCP Close

Radius End Point/Proxy Get Subprofile/Data Plan

Health Check Probe

Trigger

Steering ==WL Video

If Policy AwareOptimizationor Opt In/Out

Decision

Probe Keep-alive

Health Check Probe

Figure 7.16 Call flow showing video in the cache


Figure 7.17 shows the scenario when requested video is not in the cache.

Tra�cControl

RE-a1RE-a2

VOS OOE MINDPCRF

MFC-aWLClient

LB IncumbentWeb

Optimization


Video Optimization Complex Trans-ratedCache Complex

OriginServer

MFC-b

Content is Not Present (Cache Miss 404)

Real-time Optimized Video Chunk Delivered to UEby Integra with Just-In-Time Delivery

Video ChunksAre Sent to VOS for

Real-time Optimization

Real-time OptimizedVideo Chunk from VOS

OOE Request HighestCorresponding Video Quality

Optimized Req —>Cache Lookup

JMVO LB

Steering ==WL Video

Opt in

Integra LB to MFC

If Content/URLMakes Hotlist

Perform O�ineOptimization

It is UploadedAfter OOE Completes

Transcoding

For illustration purpose. Making the hotlist isnot linked to user request. Here it just happens

that requested content meets hotlist requirementsto trigger OOE to fetch content from origin

Pass On Info to OOE

Upload Through FTP

Upload Through FTP

Video Chunks are Ingested

Integra in Parallel Request Content From Origin Server

MediaOptimizer

b

MediaOptimizer

a

Figure 7.17 Call flow showing video not in cache


Figure 7.18 shows mechanisms associated with the sampling function for TCP port 80 traffic that were not white listed.

Tra�cControl

RE-a1RE-a2

VOS OOE MINDPCRF

MFC-aWLClient

LB IncumbentWeb

Optimization


Video Optimization Complex Cache Complex

OriginServer

MFC-b

JWLM Req (update) /JWLM Resp (0, Success)

Need VideoIP Update

Port 80 but !=WL

Trigger

Tra�c Sampling

VideoContent Detector

UpdateTra�c

Controller

MediaOptimizer

b

MediaOptimizer

a

Figure 7.18 Call flow showing sampling of TCP port 80 traffic that was not white listed


Configuration Snippet

The following configuration snippet pertains to the MX Series router providing Services Delivery Gateway functionality with intelligent traffic steering for Juniper Mobile Video Optimization.

## Last commit: 2011-06-16 17:06:59 PDT by rootversion 11.1R1.14;groups { re0 { system { host-name MX480-Bottom-RE0; domain-name jnpr.net; backup-router 172.19.91.254 destination 172.16.0.0/12; time-zone America/Los_Angeles; root-authentication { encrypted-password “$1$z1Ov.XwI$EvWGxg/Jot09zLR2/lHgf1”; ## SECRET-DATA } name-server { 172.24.16.10; 172.24.36.10; 172.24.80.10; } login { user jnpr { uid 2001; class superuser; authentication { encrypted-password “$1$usVGUcj1$JA/9xEqNrFDImo02nP9tN.”; ## SECRET-DATA } } } services { ftp; ssh; telnet; xnm-clear-text; netconf { ssh; } web-management { http; } } syslog { file messages { any any; interactive-commands none; archive size 10m files 10; } } ntp { boot-server 172.17.27.46; server 172.17.27.46; } } interfaces { fxp0 { unit 0 { family inet { address 172.19.91.103/23;


} } } } routing-options { static { route 172.16.0.0/12 { next-hop 172.19.91.254; retain; no-readvertise; } } } } mac-flush { routing-instances { <*> { protocols { vpls { mac-flush { propagate; } } } } } } no-per-unit-traps { interfaces { <ge-*/*/*> { unit <*> { no-traps; } } <xe-*/*/*> { unit <*> { no-traps; } } <*-*> { unit <*> { no-traps; } } <ae*> { unit <*> { no-traps; } } } } schedulers-per-interface { class-of-service { interfaces { <*-*> { scheduler-map cet-sched-map; } <ae*> { scheduler-map cet-sched-map; } } } }


MTU { interfaces { <*-*> { mtu 2000; } <ae*> { mtu 2000; } } }}apply-groups re0;system { scripts { op { file delete_bypass_filter.xsl; file install_bypass_filter.xsl; } } extensions { providers { openwave { license-type evaluation deployment-scope private; license-type strategic deployment-scope private; } } }}interfaces { ge-1/0/0 { description TO-ALL-MO-SERVERS; vlan-tagging; unit 4 { vlan-id 4; family inet { address 10.17.75.1/29; } } unit 10 { vlan-id 10; family inet { address 10.17.73.1/24; } } unit 12 { vlan-id 12; family inet { address 10.17.75.9/29; } } } ge-1/0/1 { description TO-SHUTTLE; unit 0 { family inet { address 10.17.72.1/24; } } } ge-1/0/3 { description “To Internet - connects to upstream NAT device”; unit 0 { family inet {


address 10.17.0.1/24; } } } ge-1/1/3 { description “WIFI JOMO”; unit 0 { family inet { address 10.17.74.1/24; } } }}forwarding-options { hash-key { family inet { layer-3; } } enhanced-hash-key { family inet { no-destination-port; no-source-port; } }}event-options { policy openwave-mo-probe { events ping_test_failed; then { event-script install_bypass_filter.xsl; } } policy openwave-mo-probe-sucess { events ping_test_completed; then { event-script delete_bypass_filter.xsl; } } event-script { traceoptions { flag all; } file install_bypass_filter.xsl; file delete_bypass_filter.xsl; }}snmp { trap-group ASPEN;}routing-options { interface-routes { rib-group inet rg-to-hosts; } static { route 192.168.0.0/16 { next-hop 172.19.91.254; retain; no-readvertise; } route 0.0.0.0/0 next-hop 10.17.0.2; route 192.169.1.0/24 next-hop 10.17.74.13; }


rib-groups { rg-to-hosts { import-rib [ inet.0 to-MOs.inet.0 to-Sampler.inet.0 test.inet.0 ]; } } forwarding-table { export load-balancing-policy; }}policy-options { prefix-list MVO-Core { 10.17.73.0/24; 10.17.75.0/24; } policy-statement load-balancing-policy { then { load-balance per-packet; } }}firewall { filter openwave-mo-bypass { term proble { from { source-prefix-list { MVO-Core; } } then accept; } term single { then { routing-instance test; } } }}routing-instances { test { instance-type forwarding; routing-options { static { route 0.0.0.0/0 next-hop 10.17.0.2; } } } to-MOs { instance-type forwarding; routing-options { static { route 0.0.0.0/0 next-hop [ 10.17.75.12 10.17.75.4 ]; } maximum-paths 16; } } to-Sampler { instance-type forwarding; routing-options { static { route 0.0.0.0/0 next-hop 10.17.73.50; } } }


}services { rpm { probe ge-1/0/0 { test 4 { probe-type http-get; target url http://10.17.75.4:3128; probe-count 2; probe-interval 1; test-interval 2; thresholds { total-loss 1; } } test 12 { probe-type http-get; target url http://10.17.75.12:3128; probe-count 2; probe-interval 1; test-interval 2; thresholds { total-loss 1; } } } }}extensions { openwave { traffic-controller { debug; interface ge-1/1/3.0; whitelist-manager { update-listener-port 2000; routing-instance to-MOs; } sampler { daily-sampling { restart-time “09:10:00 -0700”; } sample-pool-size 8; net-prefixes 192.169.1.0/24; routing-instance to-Sampler; } content-detector-monitor { ping-interval 30; timeout 60; ping-address 10.17.73.50; ping-port 80; } traceoptions { file jtc_trace.log files 100; level all; flag all; } } }}


Server status failure detection

Jun 16 14:57:15 MX480-Bottom-RE0 rmopd[1449]: PING_PROBE_FAILED: pingCtlOwnerIndex = ge-1/0/0, pingCtlTestName = 4Jun 16 14:57:24 MX480-Bottom-RE0 last message repeated 3 timesJun 16 14:57:24 MX480-Bottom-RE0 eventd[1052]: EVENTD_ESCRIPT_EXECUTION: Trying to execute the script ‘install_bypass_filter.xsl’ from ‘/var/db/scripts/event/’

redirect filter is applied to the corresponding egress.

root@MX480-Bottom-RE0> show configuration interfaces ge-1/0/0 { description TO-ALL-MO-SERVERS; vlan-tagging; unit 4 { vlan-id 4; family inet { filter { output openwave-mo-bypass; } address 10.17.75.1/29; } } unit 10 { vlan-id 10; family inet { address 10.17.73.1/24; } } unit 12 { vlan-id 12; family inet { address 10.17.75.9/29; } }}

Script

The following script can be used to enable the Install bypass filter when RPM detects an Media Optimizer core blade failure.

<?xml version=”1.0” standalone=”yes”?><xsl:stylesheet version=”1.0” xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:junos=”http://xml.juniper.net/junos/*/junos” xmlns:xnm=”http://xml.juniper.net/xnm/1.1/xnm” xmlns:jcs=”http://xml.juniper.net/junos/commit-scripts/1.0”>

<xsl:import href=”../import/junos.xsl”/>

<xsl:template match=”/”> <event-script-results>

<xsl:variable name=”rollback_config”> <load-configuration rollback=”0”/> </xsl:variable>

<xsl:variable name=”output”>openwave-mo-bypass</xsl:variable> <xsl:variable name=”interface” select=”event-script-input/trigger-event/attribute-list/attribute[name=’test-owner’]/value”/> <xsl:variable name=”unit” select=”event-script-input/trigger-event/attribute-list/attribute[name=’test-name’]/value”/>

<xsl:variable name=”del_filter”> <load-configuration> <configuration> <interfaces> <interface> <name><xsl:value-of select=”$interface”/></name> <unit> <name><xsl:value-of select=”$unit”/></name> <family> <inet> <filter delete=”delete”/> </inet> </family> </unit> </interface> </interfaces> </configuration> </load-configuration> </xsl:variable>

<xsl:variable name=”update_config”> <load-configuration> <configuration> <interfaces> <interface replace=”replace”>


<name><xsl:value-of select=”$interface”/></name> <unit> <name><xsl:value-of select=”$unit”/></name> <family> <inet> <xsl:if test=”$output”> <filter> <output> <xsl:value-of select=”$output”/> </output> </filter> </xsl:if> </inet> </family> </unit> </interface> </interfaces> </configuration> </load-configuration> </xsl:variable> <xsl:variable name=”read_config”> <get-configuration> <configuration> <interfaces> <interface> <name><xsl:value-of select=”$interface”/></name> <unit> <name><xsl:value-of select=”$unit”/></name> <family> <inet> <filter> <output/> </filter> </inet> </family> </unit> </interface> </interfaces> </configuration> </get-configuration> </xsl:variable>

<xsl:variable name=”lock_result” select=”jcs:invoke(‘lock-configuration’)”/>

<xsl:choose> <xsl:when test=”$lock_result//message”> <xnm:error> <message> Error locking: <xsl:value-of select=”$lock_result//message”/> </message> </xnm:error> </xsl:when>

<xsl:otherwise> <xsl:variable name=”read_config_result” select=”jcs:invoke($read_config)”/> <xsl:variable name=”filter_name” select=”$read_config_result//filter-name”/>

<xsl:choose> <xsl:when test=”$filter_name=$output”/>

<xsl:otherwise> <xsl:variable name=”update_result” select=”jcs:invoke($update_config)”/>


<xsl:choose> <xsl:when test=”$update_result//message”> <xnm:error> <message> Error updating config: <xsl:value-of select=”$update_result//message”/> </message> </xnm:error> <xsl:variable name=”rollback_result” select=”jcs:invoke($rollback_config)”/> </xsl:when> <xsl:otherwise> <xsl:variable name=”commit_result” select=”jcs:invoke(‘commit-configuration’)”/> <xsl:if test=”$commit_result//message”> <xnm:error> <message> Error comitting config: <xsl:value-of select=”$commit_result//message”/> </message> </xnm:error> <xsl:variable name=”rollback_result” select=”jcs:invoke($rollback_config)”/> </xsl:if> </xsl:otherwise> </xsl:choose> </xsl:otherwise> </xsl:choose>

<xsl:variable name=”unlock_result” select=”jcs:invoke(‘unlock-configuration’)”/> </xsl:otherwise> </xsl:choose>

</event-script-results> </xsl:template></xsl:stylesheet>

The following code snippet can be used to remove shows how to Delete bypass filter when RPM detects that the Media Optimizer core blade is back in service.

<?xml version=”1.0” standalone=”yes”?><xsl:stylesheet version=”1.0” xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:junos=”http://xml.juniper.net/junos/*/junos” xmlns:xnm=”http://xml.juniper.net/xnm/1.1/xnm” xmlns:jcs=”http://xml.juniper.net/junos/commit-scripts/1.0”>

<xsl:import href=”../import/junos.xsl”/>

<xsl:template match=”/”> <event-script-results>

<xsl:variable name=”rollback_config”> <load-configuration rollback=”0”/> </xsl:variable>

<xsl:variable name=”output”>openwave-mo-bypass</xsl:variable> <xsl:variable name=”interface” select=”event-script-input/trigger-event/attribute-list/attribute[name=’test-owner’]/value”/> <xsl:variable name=”unit” select=”event-script-input/trigger-event/attribute-list/attribute[name=’test-name’]/value”/>

<xsl:variable name=”del_filter”> <load-configuration> <configuration> <interfaces> <interface> <name><xsl:value-of select=”$interface”/></name> <unit> <name><xsl:value-of select=”$unit”/></name> <family> <inet> <filter delete=”delete”/> </inet> </family> </unit> </interface> </interfaces> </configuration> </load-configuration> </xsl:variable> <xsl:variable name=”read_config”> <get-configuration> <configuration> <interfaces> <interface> <name><xsl:value-of select=”$interface”/></name> <unit>


<name><xsl:value-of select=”$unit”/></name> <family> <inet> <filter> <output/> </filter> </inet> </family> </unit> </interface> </interfaces> </configuration> </get-configuration> </xsl:variable>

<xsl:variable name=”lock_result” select=”jcs:invoke(‘lock-configuration’)”/>

<xsl:choose> <xsl:when test=”$lock_result//message”> <xnm:error> <message> Error locking: <xsl:value-of select=”$lock_result//message”/> </message> </xnm:error> </xsl:when>

<xsl:otherwise> <xsl:variable name=”read_config_result” select=”jcs:invoke($read_config)”/> <xsl:variable name=”filter_name” select=”$read_config_result//filter-name”/> <xsl:if test=”$filter_name=$output”> <xsl:variable name=”del_filter_result” select=”jcs:invoke($del_filter)”/> <xsl:choose> <xsl:when test=”$del_filter_result//message”> <xnm:error> <message> Error deleting filter: <xsl:value-of select=”$del_filter_result//message”/> </message> </xnm:error> <xsl:variable name=”rollback_result” select=”jcs:invoke($rollback_config)”/> </xsl:when> <xsl:otherwise> <xsl:variable name=”commit_result” select=”jcs:invoke(‘commit-configuration’)”/> <xsl:if test=”$commit_result//message”> <xnm:error> <message> Error committing: <xsl:value-of select=”$commit_result//message”/> </message> </xnm:error> <xsl:variable name=”rollback_result” select=”jcs:invoke($rollback_config)”/> </xsl:if> </xsl:otherwise> </xsl:choose> </xsl:if> <xsl:variable name=”unlock_result” select=”jcs:invoke(‘unlock-configuration’)”/> </xsl:otherwise> </xsl:choose>

</event-script-results> </xsl:template></xsl:stylesheet>

Summary

Juniper Networks JMVO solution can dramatically improve the efficiency of delivering video content over mobile networks. With this solution, operators can immediately reduce the costs of transporting video across their networks, and deliver an improved experience for subscribers.

Traffic Management to Minimize CapEx/OpEx

• Reduce network (RAN, backhaul) costs through managed traffic reduction.

• Reduce transcoding costs with optimized transrating on-demand.

• Increase effective bandwidth to serve more subscribers.

• MX increase optimization scalability by approximately2.5x.

• Reduced hardware footprint with consolidated traffic steering, load balancing and routing functions in a single platform.

Improve Subscriber Quality of Experience

• Continuous video playback by reducing video buffering and stalls.

• Enable quick video playback through intelligent caching.

• Active dynamic video modulation to ensure smooth playback.

Additionally, this solution can be the foundation for many new revenue generating services. Networks optimized for video delivery can enable new services based on premium content delivery and can open up new business opportunities through partnerships with video content providers.

Future Proof Solution

• Support next-generation technology, such as adaptive streaming.

• Policy integration for subscriber-aware optimization services.

• Drive new revenue streams, such as personalized rich media services and analytics.

Appendices 135

Appendices


Appendix A: Juniper Networks Products

This section describes the Juniper products that were used during validation.

The products discussed here are a subset of the complete line and focus on key devices tested with and/or expected to be most widely deployed. The products include:

• MX 3D Universal Edge Routers

• M Series Multiservice Edge Routers

• EX Series Ethernet Switches

• Junos OS

• Steel Belted Radius (SRB)

• Session and Resource Control (SRC) software

For additional details concerning these products and any other Juniper products, visit www.juniper.net.

MX 3D Universal Edge Routers

The MX Series 3D Universal Edge Routers are a family of high-performance Ethernet routers with powerful switching features designed for enterprises and service provider networks. The MX Series provides unmatched flexibility and reliability to support advanced services and applications. It addresses a wide range of deployments, architectures, port densities and interfaces. High-performance enterprise networks typically deploy MX Series routers in high-density Ethernet LAN and data center aggregation, the data center core, metro Ethernet aggregation and core layers, and Mobile packet core.

Major features are

• High-density routers optimized for Ethernet that function as Layer 2 switches or Layer 3 routers, or both, maximizing service flexibility and increasing investment protection

• Deliver the most advanced routing features, including network virtualization with MPLS, low latency multicast, and QoS, without compromising performance

• Provide the highest level of redundancy and resiliency to ensure that critical services and customers stay connected, allowing the enterprise to ensure customer satisfaction and lower costs

• Run Junos OS, a single network operating system that allows administrators to quickly and cost-effectively keep up with continuously changing business demands.

The MX Series provides carrier grade reliability, density, performance, capacity, and scale for enterprise networks with mission critical applications. Its high availability features ensure that the network is always up and running, including nonstop routing (NSR), fast reroute, and unified in-service software upgrade (ISSU). The MX Series also delivers significant operational efficiencies enabled by Junos OS, a collapsed architecture requiring less power, cooling, and space consumption, and open APIs for easily customized applications and services.

Appendices 137

The MX Series support up to 2.6 Tbps. An overview of the MX Series models can be downloaded from www.juniper.net/us/en/local/pdf/datasheets/1000208-en.pdf. Additional information on the MX Series is available at www.juniper.net/us/en/products-services/routing/mx-series. For details concerning the MX960, visit: www.juniper.net/us/en/products-services/routing/mx-series/mx960/ and MS-DPC http://www.juniper.net/us/en/local/pdf/datasheets/1000258-en.pdf

EX Series Ethernet Switches

The EX Series Ethernet Switches represent a new class of infrastructure switch for high-performance businesses. Designed to address the access, aggregation, and core layers of branch office, campus, and data center applications, EX Series switches provide the infrastructure foundation for the fast, secure, and reliable delivery of applications that support strategic business processes. EX Series switches advance the economics of networking by delivering cost saving capabilities that allow businesses to reduce capital and operational expenses. The resulting savings can fund investments in innovative initiatives that allow businesses to improve productivity, streamline operations and gain a competitive advantage.

EX Series switches are designed to address increasing demands for high availability (HA) and unified communications within high-performance enterprise networks. Working together, the EX Series switches create a standards-based network foundation that is well aligned and flexible enough to deliver all applications—everything from file services to IP telephony, messaging, presence, videoconferencing, and Web services.

EX Series switches offer sufficient scalability and performance to meet emerging requirements as well. As part of the Juniper product portfolio, the EX Series switches represent a key strategic addition that contributes to one of the industry’s most complete suite of network infrastructure product offerings.

These switches all run the same Juniper Networks Junos OS, offering consistent implementation and management with time tested Juniper routers and security solutions. Junos OS adheres to a strict development process that utilizes a common source code, follows a single release train, and builds upon a modular architecture, dramatically reducing maintenance and management overhead for Junos OS-based solutions. As a result, the Junos OS-based EX Series switches ensure consistent and predictable behavior and shared feature implementation across the entire network infrastructure.

An overview of the EX Series models can be downloaded from www.juniper.net/us/en/local/pdf/brochures/1500057-en.pdf. Additional information on the EX Series is available at www.juniper.net/us/en/products-services/switching/ex-series/.

www.juniper.net/us/en/local/pdf/datasheets/1000208-en.pdf


www.juniper.net/us/en/products-services/routing/mx-series

www.juniper.net/us/en/products-services/routing/mx-series

www.juniper.net/us/en/products-services/routing/mx-series/mx960

http://www.juniper.net/us/en/local/pdf/datasheets/1000258-en.pdf

www.juniper.net/us/en/local/pdf/brochures/1500057-en.pdf

www.juniper.net/us/en/local/pdf/brochures/1500057-en.pdf

www.juniper.net/us/en/products-services/switching/ex-series/

www.juniper.net/us/en/products-services/switching/ex-series/


Junos Operating System

A core Juniper Networks strategy is innovation through software to integrate new value into the network and reduce complexity. The Juniper Networks Junos Platform is the open software platform that delivers on this strategy. At the foundation is the Junos operating system. The Junos OS provides a common language across Juniper’s routing, switching and security devices to simplify new deployments and reduce network operation costs by up to 41% .

One Architecture

ModuleX

— A

PI —

One Release Track

Frequent Releases

10.310.210.1

T Series

Junos Space

Junos Pulse

EX8216

EX8208

NSMXpress

NSM

MX Series

M Series

J Series

SECURITY ROUTERS SWITCHES

EX3200 Line

EX2200 Line

EX4200 Line

EX4500 Line

SRX5000 Line

SRX3000Line

SRX210

SRX240SRX650

SRX100 LN1000

One OS

CoreBranch

Figure A.1 Junos platform

Unlike other network operating systems, Junos OS is enhanced through one software release train, and developed based on one modular architecture—the “power of one.”

• One operating system across platforms reduces the time and effort to plan, deploy and operate network infrastructure.

• One release train runs a network on the same software version and provides new functionality in a steady, time-tested cadence of stable releases.

• One modular software architecture provides highly available, secure and scalable software that addresses changing needs.

Source: A commissioned study conducted by Forrester Consulting on behalf of Juniper Networks, The Total Economic Impact™ of Juniper Networks Junos Network Operating System

Appendices 139

Accelerated by the “power of one” differences, Junos OS has rapidly evolved to support a diverse set of application and service needs. Juniper platforms simultaneously scale integrated security and networking capabilities without compromising performance or reliability. Introducing Junos OS-based devices can reduce the level of complexity that would otherwise be present in a network. This reduces operational challenges and improves operational productivity.

Junos OS:

• Minimizes the impact of human factors with fail-safe mechanisms

• Speeds response and resolution of unplanned events

• Reduces configuration effort and issues

• Simplifies day-to-day operations

• Interoperates and integrates with existing systems

• Simplifies new upgrades and redeploy systems

For additional information on Junos OS, see http://www.juniper.net/us/en/local/pdf/brochures/1500059-en.pdf and www.juniper.net/us/en/products-services/nos/junos/.

Steel-Belted Radius Service Provider Edition

The Steel-Belted Radius Service Provider Edition offers:

• Enhanced network security: Centralized authentication, authorization, and accounting (AAA) and management of subscribers enforce security policies.

• High-capacity server: SBR PE scales to manage the largest networks. Acting as a proxy target server, SBR SP can distribute authentication to any RADIUS server.

• Seamless integration: Seamless operation in heterogeneous environments of virtually all deployment types and manufacturers simplifies deployment and operations.

• Simplified operations: Advanced features such as XML-based GUI and replication make it simple to configure and maintain SBR PE. Reports facilitate diagnostics and troubleshooting.

• Advanced reliability: Load balancing and redundancy across all authentication and accounting systems help meet stringent uptime requirements, and guaranteed delivery of accounting data eliminates lost packets.

• Optional modules: With SBR Service Level Manager, wholesale carriers and ISPs can enforce concurrent login limits for remote users, across all SBR PE servers and network access devices. SBR EAP Expansion Module supports secure public WLAN access based on 802.1X and tunneled EAP protocols.

• Customization tools: The SBR SDK allows developers to customize SBR SP to meet unique business opportunities and technical requirements.

For additional details, visit: www.juniper.net/us/en/products-services/software/ipc/sbr-series/service-provider/sbr-sp/.For data sheet: www.juniper.net/us/en/local/pdf/datasheets/1000147-en.pdf

www.juniper.net/us/en/products-services/nos/junos/

www.juniper.net/us/en/products-services/nos/junos/

www.juniper.net/us/en/products-services/software/ipc/sbr-series/service-provider/sbr-sp/

www.juniper.net/us/en/products-services/software/ipc/sbr-series/service-provider/sbr-sp/




Session and Resource Control (SRC)

The SRC connects the service layer with the network layer of service provider networks by providing a feedback loop between applications, users, and the network. Its open interfaces allow it to integrate with any network and any service offering, regardless of where the demand is generated. The SRC allows service providers to generate additional revenue on their existing network infrastructure by adding dynamically activated services.

Unlike competitive solutions that utilize AAA for policy management or solutions that deploy static policy enforcement solutions, Juniper’s SRC Portfolio delivers granular dynamic policy enforcement on a per service level. This enables you to deliver revenue-generating services on top of existing sessions. The SRC readily interfaces with your existing subscriber management databases. This enables you to map available network resources to subscriber and service profiles. The result is differentiated services that are based on dynamic allocation of network resources with the ability to provide service specific accounting.

The SRC consists of the following components:

• C Series hardware appliance

• SRC Policy Engine: This is the required base SRC software

• SRC SOAP Gateway: This software provides the open, published web services interface.

Additional information about SRC software and hardware is available in SRC Series Session and Resource Control Modules Datasheet at http://www.juniper.net/us/en/local/pdf/datasheets/1000195-en.pdf.

Media Flow Controller (MFC)

Media Flow Controller is the innovative software system that forms the foundation of Juniper’s Media Flow Solution. Media Flow Controller is a next-generation content delivery software system that enables customers to reduce costs, and improve the profitability of delivering rich media content, while also improving quality of experience for consumers.

A ground-breaking software architecture enables the Media Flow Controller to maximize system and disk performance to deliver unmatched throughput, session density and storage scaling. In addition, Media Flow controller optimizes the efficiency of cache storage with hierarchical caching—a unique innovation which intelligently aligns the requirements of content with the memory type in which it is stored.

Media Flow Controller can be deployed on industry-standard x86-64 servers, or purchased pre-installed on the VXA Series Media Flow Engines. Optional applications such as Media Flow Publisher can further increase the functionality and value of Media Flow Controller.

For additional details, visit: www.juniper.net/us/en/products-services/software/content-media/media-flow-solution/media-flow-controller/#features-benefits



Appendices 141

Appendix B: References

Web Pages

• Juniper Networks (home page): www.juniper.net

Juniper Marketing Collateral

• Juniper Networks Wireless Carriers, www.juniper.net/us/en/solutions/service-provider/wireless-carrier/

• How Operating Systems Create Network Efficiencies, www.juniper.net/us/en/local/pdf/whitepapers/ lake_partners_network_efficiency.pdf

• Junos SDK, www.juniper.net/us/en/products-services/junos-developer/junos-sdk/

Juniper Technical Collateral

• Real-Time Performance Monitoring (RPM) on Juniper Networks Devices, www.juniper.net/us/en/local/pdf/app-notes/3500145-en.pdf

• Leveraging ECMP and RPM on MX for SLB towards MFC, www.juniper.net/us/en/local/pdf/app-notes/3500198-en.pdf

• MX960 3D Universal Edge Router, www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/mx-series/mx960/index.html

• MX Series, www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/mx-series/

• Steel-Belted Radius Service Provider Edition offers, www.juniper.net/us/en/products-services/software/ipc/sbr-series/service-provider/sbr-sp/

• Session and Resource Controller, www.juniper.net/us/en/products-services/software/ipc/src-series/

• Media Flow Controller, www.juniper.net/us/en/products-services/software/content-media/media-flow-solution/media-flow-controller/#features-benefits

Junos Configuration

• Virtual Router Redundancy Protocol (VRRP), www.juniper.net/techpubs/en_US/junos10.2/topics/reference/statement-hierarchy/vrrp-configuration-hierarchy.html

• Link Aggregation (LAG), www.juniper.net/techpubs/en_US/junos11.1/topics/concept/lag-qfx-series-overview.html, http://www.juniper.net/techpubs/en_US/junos10.0/topics/concept/interfaces-lag-overview.html

• Configuring Multichassis Link Aggregation (Multi-LAG), www.juniper.net/techpubs/en_US/junos11.1/topics/usage-guidelines/interfaces-configuring-multi-chassis-link-aggregation.html


• Bidirectional Forwarding Detection (BFD), www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/configuring-the-bfd-protocol_3.html

• Graceful Routing Engine Switchover (GRES), www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuration/routing-engine-redundancy-configuring.html

• Nonstop Active Routing (NSR), www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuration/nsr-configuring.html

• In-Service Software Upgrade (ISSU), www.juniper.net/techpubs/en_US/junos10.2/information-products/pathway-pages/high-availability/high-availability.html

• Intrusion Detection and Prevention (IDP), www.juniper.net/techpubs/en_US/junos11.1/information-products/pathway-pages/services-interfaces/router-services-intrusion-detection-properties.html

• Quality of Service (QoS), www.juniper.net/techpubs/en_US/junos10.3/information-products/pathway-pages/cos/index.html

• Application Identification, www.juniper.net/techpubs/en_US/junos11.1/information-products/pathway-pages/services-interfaces/application-identification.html

• Network address translation (NAT), www.juniper.net/techpubs/en_US/junos11.1/information-products/pathway-pages/services-interfaces/router-services-network-address-translation.html#configuration

• Stateful Firewall, www.juniper.net/techpubs/en_US/junos11.1/information-products/pathway-pages/services-interfaces/router-services-stateful-firewall.html#configuration

• Application Aware Access List, www.juniper.net/techpubs/en_US/junos11.1/information-products/pathway-pages/services-interfaces/application-aware-access-list.html

• For configuring DSA on SDG, refer to DSA for Subscriber Access at: http://juniper-federal.com/techpubs/en_US/junos/information-products/pathway-pages/subscriber-access/ptsp/subscriber-management-ptsp.html#configuration

• For configuring SRC to support DSA enabled MX platform (SDG), refer to Session and Resource Control (SRC) Software for C Series Controllers, Release 4.0 at: www.juniper.net/techpubs/en_US/src4.0/information-products/pathway-pages/c-series/index.html . In particular, Part 3 Chapters 16-19 of SRC PE Software Solution Guide 4.0 at: www.juniper.net/techpubs/en_US/src4.0/information-products/topic-collections/solutions/book-solutions.pdf

Appendices 143

Appendix C: Acronyms

AAACL application-aware access list

AAA accounting, authentication and authorization

AAR AA-Request

ADC Application Delivery Control

AF Application Function

ALG Application Layer Gateway (ALGv4)

APN Access Point Name

AVPs Attribute-Value Pairs

BBBERF Bearer Binding and Event Reporting

Function

BNG Broadband Network Gateway

BU Business Unit

CCDM Content Detector Monitor

CDR Call Data Record

CMBU Content and Media Business Unit

DDDoS Distributed Denial of Service

DNS Domain Name System

DPI Deep Packet Inspection

DRA Diameter Routing Agent

DRM Digital Rights Management

DSA Dynamic Subscriber Awareness

EEAP Extensible Authentication Protocol

ECMP equal-cost multipath

EIR Electronic Information Resource

EPC Evolved Packet Core

EPS Evolved Packet System

FFT Foundation Technologies

GGGSN Gateway GPRS Support Node

HH2H Human to Human

HSS Home Subscriber Server

IIANA Internet Assigned Numbers Authority

IDP Intrusion Detection and Prevention

IMEI International Mobile Equipment Identification

JJAS Junos Application Software

JIT just-in-time

JWLM Juniper White List Management

LLDAP Lightweight Directory Access Protocol

MM2M Machine to Machine

MBG Mobile Broadband Gateway

MBU Mobile Business Unit

MCG Mobile Control Gateway

MIND Master Integrated Network Directory

MME Mobility Management Entity

MS-DPC Multi Service-Dense Port Concentrator

MSISDN Mobile Station - ISDN

MTC Machine-Type Communciation

MVO Mobile Video Optimizatiion

NMFC Media Flow Controller

NAT Network Address Translation

NMS network management system

NPU network processing unit


OOAM Operations Administration and

Maintenance (Ethernet protocol)

OCS Online Charging System

OEM Original Equipment Manufacturer

OFCS Offline Charging System

OOE Offline Optimization Engine

OSPF Open Shortest Path First

OSS operation support systems

OTT Over The Top

PPCEF Policy and Charging Enforcement Function

PCRF Policy and Charging Rule Function

PD Progressive Download

PDN Packet Data Network

PCC Policy and Charging Control

PFE Packet Forwarding Engine

PGW PDN (Packet data Network) Gateway

PSG Platform System Groups

PPTP Point to Point Tunneling Protocol

PWE Pseudo-Wire Emulation

QQoS Quality of Service

RRadius Remote Authentication Dial-In User Server/

Service (networking protocol)

RSBU Router Services Business Unit

RTSP Real Time Streaming Protocol

SSAE service activation engine

SAE System Architecture Evolution (3GPP)

SBR Steel Belted Radius

SDG Services Delivery Gateway

SDK Junos Software Development Kit

SFW Stateful Firewall

SGSN Serving GPRS Support Node

SIC Subscriber Information Collector

SIP Session Initiation Protocol

SLAX Stylesheet Language Alternative Syntax

SPR Subscriber Profile Repository

SRC Session and Resource Control

SSR Session State Registrar

STRM Security Threat Manager Response

TTCP transmission control protocol

TDF Traffic Detection Function

TSC Traffic Steering Controller

TSU Traffic Steering Unit

UUDR User Data Record

UE DNS Domain Name System

VVAS Virtual Agent Services

VEE Virtual Execution Engine

VTA Volume-Tracking Application

VSA Vendor-Specific Attribute

WWLMD White List Manager Daemon

Services Delivery Gateway Solution

Today, mobile wireless service providers face a multitude of challenges in keeping pace with

the ever-increasing demands on their network infrastructure. Increased demand for bandwidth

is generated by multimedia, data-enabled handheld devices and streaming devices. Smart

phones have become an integral part of everyday life and the penetration rate of such devices

is reaching exponential proportions in an attempt to satisfy the unquenchable demands across

the globe. Certain applications such as video streaming are now commodities. As a result,

these simultaneous trends impact the infrastructure of existing mobile operators.

This handbook describes how mobile operators can now address the increasing demands

on their mobile packet core network infrastructure by deploying Juniper’s Services Delivery

Gateway which will enable them to offload services to maximize investment on existing

deployed mobile packet gateways, consolidate diversified/distributed services to simplify

current backend networks and prepare for v4/v6 transition and provide overall multimedia

optimization to delay/save RAN CapEx investment. Juniper’s Services Delivery Gateway is an

initiative that was proposed jointly by sales teams, MBU and the RSBU and is based on the

Juniper flagship MX Series platform and leverages the key services such as CGNAT, SLB, SFW

and others to enable mobile operators to effectively manage their traffic, optimize the usage of

their network resources and ensure quality of experience for their end subscribers.

“Tier 1 global mobile operators today are experiencing multiple challenges from several

directions. They are trying to grow their revenue by introducing new services while at the

same time dealing with the growing demands to decrease CapEx as they grow their network

infrastructure. “Success based investment” where they see a revenue return for their

investments is critical. The delivery of the Services Delivery Gateway solution to the market

is extremely timely and will enable Juniper to address these challenges that mobile operators

experience and alleviate some of the pain points in the network at the edge of the mobile

packet core. This handbook describes how mobile operators can reduce the impact of growing

bandwidth requirements on their mobile packet core network infrastructure by effectively

aggregating key services in one single node—Juniper’s Services Delivery Gateway. In addition

to describing Services Delivery Gateway as a consolidated service node, this handbook details

how Services Delivery Gateway is a key network component in the Mobile Video Optimization

solution offering from Juniper.”

− Scott Stevens

VP Technology and Worldwide Systems Engineering

Juniper Networks

7100142-002-EN Aug 2011

Se

rvices D

elive

ry Ga

tew

ay S

olu

tion

Services Delivery Gateway SolutionImplementing IP Services and Mobile Video Optimization at the Mobile Packet Core

SDG_book

Documents

Transcript of SDG_book