SDG_book
-
Upload
mp20095655 -
Category
Documents
-
view
83 -
download
11
description
Transcript of 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.
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.
Chapter 1 – Introduction 3
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
4 Services Delivery Gateway Solution
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)
Chapter 1 – Introduction 5
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.
6 Services Delivery Gateway Solution
• 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
8 Services Delivery Gateway Solution
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.
Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services 9
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.
10 Services Delivery Gateway Solution
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.
Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services 11
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
12 Services Delivery Gateway Solution
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.
Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services 13
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).
14 Services Delivery Gateway Solution
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.
Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services 15
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
16 Services Delivery Gateway Solution
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.
Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services 17
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.
18 Services Delivery Gateway Solution
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).
Chapter 2 – Services Delivery Gateway Framework and Foundation for Next Generation Services 19
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.
22 Services Delivery Gateway Solution
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.
Chapter 3 – Policy and Charging Control Standards Perspective 23
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
24 Services Delivery Gateway Solution
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)
Chapter 3 – Policy and Charging Control Standards Perspective 25
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.
26 Services Delivery Gateway Solution
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.
28 Services Delivery Gateway Solution
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
Chapter 4 – Architectural Approach 29
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.
30 Services Delivery Gateway Solution
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.
Chapter 4 – Architectural Approach 31
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.
32 Services Delivery Gateway Solution
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).
Chapter 4 – Architectural Approach 33
CGN/PAT/ALG/FW Public(s)Gi
Private(s)Gi
PolicyRouting
IPFlows
AAA PCRF SPR
Gx, Sd
Sp
INTERNETGGSNPGW
Private Public
UE DNS Service Complex
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.
34 Services Delivery Gateway Solution
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
36 Services Delivery Gateway Solution
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.
Chapter 5 – Traffic Direct Overview 37
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
MX960(Services Delivery Gateway)
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.
38 Services Delivery Gateway Solution
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.
Chapter 5 – Traffic Direct Overview 39
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.
40 Services Delivery Gateway Solution
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
Chapter 5 – Traffic Direct Overview 41
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.
42 Services Delivery Gateway Solution
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
Chapter 5 – Traffic Direct Overview 43
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
44 Services Delivery Gateway Solution
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.
Chapter 5 – Traffic Direct Overview 45
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
46 Services Delivery Gateway Solution
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
Chapter 5 – Traffic Direct Overview 47
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 ------
48 Services Delivery Gateway Solution
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}
Chapter 5 – Traffic Direct Overview 49
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
50 Services Delivery Gateway Solution
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.
Chapter 5 – Traffic Direct Overview 51
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
MX960(Services Delivery Gateway)
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 .
52 Services Delivery Gateway Solution
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.
Chapter 5 – Traffic Direct Overview 53
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)
54 Services Delivery Gateway Solution
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.
Chapter 5 – Traffic Direct Overview 55
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.
56 Services Delivery Gateway Solution
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
}
Chapter 5 – Traffic Direct Overview 57
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.
58 Services Delivery Gateway Solution
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
POLICY CONTROL (SRC)PRE-PCRF SUPPORT
SERVICECOMPLEXSDG:TDLDAP iNTERNET
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.
Chapter 5 – Traffic Direct Overview 59
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.
60 Services Delivery Gateway Solution
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
POLICY CONTROL (SRC)PRE-PCRF SUPPORT
SERVICECOMPLEXSDG:TDLDAP iNTERNET
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.
Chapter 5 – Traffic Direct Overview 61
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.
62 Services Delivery Gateway Solution
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;
Chapter 5 – Traffic Direct Overview 63
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 ‘’; } } }
64 Services Delivery Gateway Solution
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; } }}
Chapter 5 – Traffic Direct Overview 65
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
66 Services Delivery Gateway Solution
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
Chapter 5 – Traffic Direct Overview 67
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
68 Services Delivery Gateway Solution
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.
70 Services Delivery Gateway Solution
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
UE DNS Service Complex
DNS Partner / Incumbent
Figure 6.1 Physical configuration
Chapter 6 – Consolidated Services 71
UE DNS Service Complex
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).
72 Services Delivery Gateway Solution
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.
Chapter 6 – Consolidated Services 73
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.
74 Services Delivery Gateway Solution
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
Chapter 6 – Consolidated Services 75
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
76 Services Delivery Gateway Solution
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.
Chapter 6 – Consolidated Services 77
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.
78 Services Delivery Gateway Solution
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
Chapter 6 – Consolidated Services 79
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).
80 Services Delivery Gateway Solution
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.
Chapter 6 – Consolidated Services 81
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
82 Services Delivery Gateway Solution
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
Chapter 6 – Consolidated Services 83
Non-HTTP Traffic Call Flow (to the Internet)
Figure 6.9 illustrates the non-HTTP traffic call flow.
1 Ue non-HTTP
Gn, S11-S1uSAEgw LBPvt Gi/SGi
OptimizationComplex
2 non-HTTP
8 non-HTTPReturn Tra�c
3 non-HTTP
Services Delivery GatewayPublicGi/SGiNAT/ALG/FWL
DNS ComplexCache Resolver
PVTVLAN
PUBVLAN
Not TCPPort 80 Apply all
ConsolidatedServices
9 non-HTTPReturn Tra�c
4 non-HTTP
7 non-HTTP Return Tra�c
5 non-HTTP
6 non-HTTPReturn Tra�c
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).
84 Services Delivery Gateway Solution
Configuration Snippets and Logs
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 {
Chapter 6 – Consolidated Services 85
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
86 Services Delivery Gateway Solution
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)
Chapter 6 – Consolidated Services 87
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
Gn, S11-S1uSAEgw LBPvt Gi/SGi
OptimizationComplex
2 HTTP Request
8 HTTPReturn Trac
3 HTTP Request
Health CheckProbe
(RPM Script)
Health CheckProbe
(RPM Script)
Services Delivery GatewayPublicGi/SGiNAT/ALG/FWL
DNS ComplexCache Resolver
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)
88 Services Delivery Gateway Solution
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 re- quested 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).
Chapter 6 – Consolidated Services 89
Configuration Snippets and Logs
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;
90 Services Delivery Gateway Solution
} }}
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.
Chapter 6 – Consolidated Services 91
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.
94 Services Delivery Gateway Solution
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.
Chapter 7 – Juniper Mobile Video Optimization Solution 95
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.
96 Services Delivery Gateway Solution
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.
Chapter 7 – Juniper Mobile Video Optimization Solution 97
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.
98 Services Delivery Gateway 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.
Chapter 7 – Juniper Mobile Video Optimization Solution 99
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.
100 Services Delivery Gateway Solution
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
Chapter 7 – Juniper Mobile Video Optimization Solution 101
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.
102 Services Delivery Gateway Solution
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.
Chapter 7 – Juniper Mobile Video Optimization Solution 103
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.
104 Services Delivery Gateway Solution
• 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.
Chapter 7 – Juniper Mobile Video Optimization Solution 105
Non-optimizable Tra�c
Adaptive Streaming
Web
Network Under Stress
HTTP - PD
Non-optimizable Tra�c
Adaptive Streaming
Web
Network Under Stress
HTTP - PD
Non-optimizable Tra�c
Adaptive Streaming
Web
Network Under Stress
HTTP - PD
Non-optimizable Tra�c
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:
106 Services Delivery Gateway Solution
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
Chapter 7 – Juniper Mobile Video Optimization Solution 107
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.
108 Services Delivery Gateway Solution
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
Chapter 7 – Juniper Mobile Video Optimization Solution 109
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.
110 Services Delivery Gateway Solution
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
Chapter 7 – Juniper Mobile Video Optimization Solution 111
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.
112 Services Delivery Gateway Solution
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.
}
Chapter 7 – Juniper Mobile Video Optimization Solution 113
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.
114 Services Delivery Gateway Solution
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.
Chapter 7 – Juniper Mobile Video Optimization Solution 115
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.
Chapter 7 – Juniper Mobile Video Optimization Solution 117
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>
118 Services Delivery Gateway Solution
# 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
Chapter 7 – Juniper Mobile Video Optimization Solution 119
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
Services DeliveryGateway
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
120 Services Delivery Gateway Solution
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
Services DeliveryGateway
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
Chapter 7 – Juniper Mobile Video Optimization Solution 121
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
Services DeliveryGateway
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
122 Services Delivery Gateway Solution
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;
Chapter 7 – Juniper Mobile Video Optimization Solution 123
} } } } 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; } } } }
124 Services Delivery Gateway Solution
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 {
Chapter 7 – Juniper Mobile Video Optimization Solution 125
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; }
126 Services Delivery Gateway Solution
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; } } }
Chapter 7 – Juniper Mobile Video Optimization Solution 127
}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; } } }}
128 Services Delivery Gateway Solution
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; } }}
Chapter 7 – Juniper Mobile Video Optimization Solution 129
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”?><!-- * This code is provided as is by Juniper Networks SDK Developer Support. * It is provided with no warranties or guarantees, and Juniper Networks * will not provide support or maintenance of this code in any fashion. * The code is provided only to help a developer better understand how * the SDK can be used. * * Copyright (c) 2007-2008, Juniper Networks, Inc. * All rights reserved.--><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”>
130 Services Delivery Gateway Solution
<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)”/>
Chapter 7 – Juniper Mobile Video Optimization Solution 131
<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>
132 Services Delivery Gateway Solution
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”?><!-- * This code is provided as is by Juniper Networks SDK Developer Support. * It is provided with no warranties or guarantees, and Juniper Networks * will not provide support or maintenance of this code in any fashion. * The code is provided only to help a developer better understand how * the SDK can be used. * * Copyright (c) 2007-2008, Juniper Networks, Inc. * All rights reserved.--><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>
Chapter 7 – Juniper Mobile Video Optimization Solution 133
<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
136 Services Delivery Gateway Solution
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/.
138 Services Delivery Gateway Solution
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
140 Services Delivery Gateway Solution
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
142 Services Delivery Gateway Solution
• 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
144 Services Delivery Gateway Solution
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