1. Prakash Easwar
Philadelphia
PA - 19103
Mobile # - 215-964-7589
Email - peaswar@gmail.com
Senior Software Engineer with over 15 years of experience in the IT(telecom/ca-
ble) industry. I have over 15 years of Design experience and over 5 years of Archi-
tecture Experience. I have designed and developed software in various languages
like C/C++ (over 10 years), Java (over 5 years), Ruby/Python/Go/Perl (over 2
years). I am very new to R programming and MATLab/Octave.
I am currently reading up on machine learning concepts, algorithms and data sci-
ence in general and would love to work on projects related to machine learning or
data science.
I started off in the embedded space (Broadband) and gradually moved over to the
application space (around 2008 when I joined Comcast).
Good Working Knowledge in the following
• C, C++, Java, Ruby, Python, Perl, GO, R, Octave, Puppet.
• Git, Svn, Eclipse, Jenkins, Make, Clearcase. Agile, KanBan
• Linux, vxWorks, Nucleus, SunOS (Solaris), Windows, Mac.
• Kafka, Zookeeper, HaProxy, Nginx, Apache, InfluxDB, MongoDB, Collectd, Heka, Net-
App SDK.
• Routing, Bridging, NAT/P, SIP, VoIP, GPON, Ethernet, Sonet/SDH, APC, T1/E1 IMA/
CES, T3/E3, EFM.
• Wintegra ATM/IP Network Processor, BroadCom, Conexant, Vitesse Pacemaker. Lu-
cent ALM/ABM/APC/CelXpres, SNMP, MIBS, MIB Compliers, WebSphere, Cassan-
dra, JAVA SIP Servlet 3.0, JAVA JSR 289, SIP/SIMPLE presence model, MPEG-4/H.
264, Multicast, ATM Forum Documents, IETF RFC’s.
Status
US Citizen (As Of November, 2010)
Patents
Systems and methods for automatically configuring cross-connections in a digital sub-
scriber line access multiplexer (DSLAM) - http://patents.justia.com/patent/20010015978
LinkedIn Profile - https://www.linkedin.com/pub/prakash-easwar/1/190/a11
Github Account - https://github.com/goffersoft
1

2. Extra Curricular Activities
Golf
Tennis
Education
MS, Computer Science
December, 1992
Indian Institute of Technology
New Delhi, India
MS Mathematics
May 1991
Indian Institute of Technology
Kharagpur, India
BS Mathematics
May 1989
Calcutta University, India
2

3. Employment
November 2014 – February 2016 Comcast Corporation, Phil-
adelphia, PA - Contractor (Klaztronics)
I was part of a project that was responsible for providing a framework to collect data from
the various components in the Comcast video network that make up the video delivery
pipeline for IP enabled devices.
My role in this project was primarily that of a Systems Integrator. Specifically
• Design/Implement the Deployment Architecture for the data collection framework.
• Design/Implement the Deployment Architecture for Graphite. (This was used for to
validate and test the data that was to be gathered. This architecture would eventually
be phased out over time once the the primary monitoring architecture was in place).
• Automation for the various components. (Puppet : Kafka/Zookeeper/HaProxy/Colectd/
Heka/Nginx/Java/jmxterm/Netapp/ and some in house software components that make
up the video monitoring framework).
• Help with requirements and automation related to the data that was to be gathered
from the various video components.
• Software Development
• Kafka to Graphite (convert from collectd binary format to graphite line format) -
written in go.
• NetApp Data Collection - Use the NetApp SDK to collect data from the various
storage devices and convert that to a collected/binary format. (Perl)
• use an open source tool (jmxterm) to collect imx statistics from Kafka and con-
vert to a collectd binary format.
• Help the team with Deploying the various components in the Comcast production net-
work. (We had an intern on board for a short while who helped with this as well).
3

4. November 2008 – May 2014 Comcast Corporation, Philadelphia,
PA - Senior (Level 4) Engineer
LCR - Least Cost Routing
I was part of a team that designed and developed a application portal that automated
the (manual) process of gathering rate decks from vendors and feeding the data to a
least cost router. Least Cost Routing allows Comcast to offload voice calls to other ven-
dors in areas where it does not provide service thereby allowing Comcast subscribers to
cal anywhere in the nation and internationally. The application portal allows vendors and
Comcast employees to post rate decks using a secure login process (Admin and Vendor
Roles) and automates the process of consolidating the rate decks from the various ven-
dors. The portal provided for data security in that vendors couldn't see each others post-
ed data.
Ruby/Sinatra/Padrino Web Framework was used to develop the application Portal which
used the MYSQL database to store and archive vendor data and consolidated rate
decks.
The team used the Agile/Kanban (Rally) methodology to track progress and meet dead-
lines. The team used a DevOps model and continuous integration(Jenkins) to get the
product to a production environment
Git was used for source code control
Dynamic DNS
I led the effort in the capacity of a POP (Product Owner Proxy) to work with the business
owners to come up with a detailed plan to build the control plane component of the Dy-
namic DNS architecture. DDNS architecture allows for 2-way communication between
legacy STBs (IPv4 only) and the national Comcast network using dynamic DNS and
IPv4 to IPv6 translation. I created the project plan and user stories in Agile and engaged
a development team to develop the DDNS control plane software.
C2Index
I worked as the lead for this project in providing a software solution to index VOD assets
(limited to advertising content in the initial phases and based on cable labs specifica-
tions) in a vendor independent fashion. The original intent was for the vendors to add
this functionality into the encoders and provide a integrated hardware solution. However
vendors are a couple of years off from implementing this and hence a software solution
to indexing VOD assets based on standard cable lab specs was desirable. The solution
itself is Java based and initially Xuggler (java based software library to manipulate
mpeg-2/mpeg-4 video streams) was supposed to be the magic bullet to provide the
hooks into the VOD assets but Xuggler fell short of expectations. Hence a lot of the
hooks had to be coded into the software.
Java 7/Servlet 3.0 was used to develop this application.
4

5. The team used the Agile/Scrum (Rally) methodology to track progress and meet
deadlines.
SVN was used for source Code control
Cable Lab Specifications
Comcast-SP-NGOD-CDN-OBJ-I03D10-121002 - Standard VOD Object Subtypes
MPEG Specification
ISO/IEC - 13818-1 - MPEG Standards
ISO/IEC - 13818-2 - MPEF2 Standards
Digital Audio Compression - AC-3, E-AC-3 H.264 - MPEG-4
C2Index and ADF
I was part of a team that worked on integrating the C2Index software into the VOD work-
flows using the MPX / RMP platform. My main role here was to provide some of the doc-
umentation necessary to move the ADF and C2Index plugin effort to its end goal.
C# was used to develop this application which is essentially a plugin ingot the RMX/
MPX Video VOD Engine (developed by thePlatform)
The team used the Agile/Scrum (Rally) methodology to track progress and meet
deadlines.
SVN was used for source Code control
Remote Tune for DTAs
I worked as part of a 2 man team to develop a prototype for the VODDTA project. This
project is related to providing VOD content to the DTA driven market. My role in this
project was to develop a framework/prototype (based on cable lab specifications) of a
mediation layer that abstracts a lot of VOD details from the end - user controller software
(for example, a Comcast customer with a IPAD try to
access/play VOD assets on his/her TV hooked up to a DTA device) using restful API’s.
Java 7/Servlet 3.0 was used to develop this application.
The team used the Agile/Scrum (Rally) methodology to track progress and meet
deadlines.
SVN was used for source Code control
Cable Lab Specifications
NG-SRM HTTP Usage - Comcast-SP-NGSRM-GEN-HTTP-I02D16
NG-SRM Stream Control (C1) - Comcast-SP-NGSRM-SRM-C1-I01
NG-SRM Streaming Server Resource Interface (R2)
NG-SRM Client Session (S1) - Comcast-SP-NGSRM-SRM-S1-I02D091
5

6. Common Alerts Platform
This initiative was to modify the existing architecture so that it would scale to the order of
a millions of transaction per second and operationally manageable. As part of the XAN-
S1.0 architecture review, there were a series of meetings with operations and SVP’s.
One of the major outcomes of these meetings was to add one more component to the
XANS1.0 architecture. This component would provide consistent hashing functionality.
This in turn would provide the ability to breaking the XANS1.0 monolithic platform archi-
tecture into smaller manageable pod-like architecture. My roles and responsibilities
were to drive the XANS1.0 architecture review and work on the action items that came
out of this meeting.
XSAR – Service Application Router
Provides the Consistent Hashing functionality that allows for a XANS2.0 pod-like plat-
form architecture (as opposed to the XANS1.0 monolithic platform architecture). My
roles and responsibilities was to define the high level architecture/design for the XSAR
and the requirements relevant to XANS2.0
TV Alerts
This project was initiated to drive alerts to TV. One of the goals of this project was to
move away from the legacy caller ID to TV architecture and open up the possibility to
drive any kind of alerts to TV better, faster and cheaper. The thinking at the time was to
leverage the XANS platform in the core to deliver alerts to TV. The initial project objec-
tive’s was to deliver XTM notifications to TV one way messaging to TV.
My roles and responsibility for this project was build a outbound TV adaptor to deliver
notifications to the TV. I also participated in defining the overall architecture for delivering
alerts to TV.
Egress Adaptor – Video Adapter
Delivers notifications to TV. Receives sip (xtm - text messaging) notifications from
XANS1.0 Core and delivers then to TV via code big HTTP API’s. My role in this
project was to define the architecture at the service level and provide design, imple-
mentation guidelines for an external vendor to then build the system for us.
XANS 1.0 – Common Alerts Platform (November 2010 – March 2012)
XANS 1.0 was initiated with the goal of building a common alerts platform. The XANS1.0
architecture was based on the sip/simple presence architecture with the sip protocol be-
ing used in the core and a combination of sip and http protocol being used at the edge to
post and receive alerts. XANS 1.0 comprised of a SIP core and ingress/egress adaptors
at the edge. The Services that were deployed through the XANS platform were Voice-
Mail, XTM and UCID. The Services would post notification to XANS and anyone inter-
ested would be able to receive notification from XANS. The initial listeners for notifica-
tions from XANS were OTT(Mobile Platform), IMS (Voicemail – MWI notifications) and
XRE (for delivering notifications to Next generation STB’s) and Comet(for delivering noti-
fications to PC based Caller ID applications).
6

7. My roles and responsibility for this project was to come up with the overall architecture /
design/ planning /deployment of the XANS1.0 at the service level.
Ingress Adapter - Presence Adapter
This component is part of the XANS Platform. It is responsible of receiving notifications
from the various services and delivers them to the presence platform. My role in this
project was to define the architecture at the service level and provide design, implemen-
tation guidelines for an external vendor to then build the system for us.
Egress Adaptor – Comet Adapter
Delivers Caller ID notifications to PC based application. Receives sip notifications from
XANS Core and delivers then to a PC based application via a HTTP long poll connec-
tion. My role in this project was to define the architecture at the service level and provide
design, implementation guidelines for an external vendor to then build the system for us.
Remote Tune Application
The Remote tune application allowed a customer to change channels from a mobile de-
vice (iPhone / iPad) in addition to using the silver remote to change channels. I worked
on the Operational/Deployment/Training aspects of the Remote Tune project.
Caller ID to PC
Worked on the Universal Caller ID architecture . Roles and responsibilities included
maintaining one of the components in the CallerID to PC architecture. This component
would be responsible for terminating SIP messages and intelligently forwarding caller ID
notifications downstream towards the customer PC. Eventually took ownership of the
entire CallerID to PC architecture from an end-to-end perspective.
Technologies involved : Sun/Solaris, Java, Redundancy, LB, Oracle, HTTP Rest API’s,
SNMP, Log Scraping
Caller ID to PC – Double/Single Play Customers
Initially Caller ID was available to triple play customers only. Due to the early success of
the program the business unit decided to open up the caller ID application to double play
and single play customers also. Was lead engineer to support this effort. Work revolved
around Capacity Planning and Provisioning aspects of the Caller ID application (Billing/
CET Provisioning infrastructure to XAP enhancements). Technologies involved : Sun/So-
laris, Java, Redundancy, LB, Oracle, HTTP Rest API’s, SNMP, Log scraping
7

8. July 2005 – July 2008 Zhone Technologies, Largo, Florida
Senior Software Engineer
Voice Residential Gateway
Investigated various Architectures to cost reduce the existing Voice Residential
Gateway product.
Project Lead For a Voice Residential gateway product managing up to 3
Software Developers. The product was developed based on the Jungo software
stack using Linux OS. The software for the product was maintained under
Clearcase. Cross Platform Development was done on a Linux PC (UBUNTU,
RED HAT Flavors)
The product required knowledge of the following hardware.
Intel FreeXScale, Legerity Slics, CopperGate HPNA, Marvell Ether Switch,
BroadLight BL2000, GPON SFF.
The product included GPON and ActiveE as part of the WAN interfaces. The
product supported up to 2 voice lines (Legerity Part with 2 SLICS) and
provided support for VOIP (SIP, MGCP), HPNA, LAN interfaces.
The work primarily revolved around maintaining the Jungo software stack and
the voice gateway (VOIP functionality). Bug-fixes were primarily in the area of
routing , WEB GUI, VOIP (SIP, MGCP), Legerity Slics. Added support for Teen
Service/Distinctive Ringing. Added Software for new Cost reduced GPON
hardware.
ATM/IP DSLAM
Project Lead For the a DSLAM Based System. Focus was primarily on maintaining the
system with the following additional feature development.
IPOA
Designed and developed the IPOA feature for the 8820 DSLAM.
I was part of a team that investigated various Architectures to Cost Reduce the
aggregation Blade and move from legacy ATM architecture to a IP architecture.
EFM linecard
Was part of a team that designed and developed a EFM line card. My roles and
responsibilities was to update the FM driver and implement the /snap miss.
Filter middleware
Designed and developed a Filter Middleware module to support filtering of IP
Network/Transport/Application Level packets for the layer2 IP DSLAM product.
8

9. May 1997 – July 2005 Paradyne Corporation, Largo, Florida -
Senior Software Engineer
ATM DSLAM
Worked on a DSLAM based system which supported up to 2 aggregation/management
blades (ATM Uplinks ➔ T3/E3, SONET/SDH, T1/E1/IMA. IP Uplinks ➔ GigE, 10/100
Ethernet) and up to 18 Line Cards with port densities ranging between 8 and 48 ports
per linecard. The Line Cards provided support for various line technologies from
DSL(ADSL, ADSL2+, SHDSL) to T1/E1 (ATM/IMA/Circuit Emulation), POTS (with MGCP
VOIP functionality). The Software for the product was maintained under Clearcase. The
Operating System for the DSLAM based system was vxWorks. Cross Platform Devel-
opment was done on SUN Solaris Based Systems.
The product required knowledge of the following hardware.
BM405, Wintegra (MIPS), MP360/860, MP180 (Security Co-Processor), FPGA, SFP,
Vitesse Pacemaker (ATM Switch), Lucent ALM/ABM/APC/CelXpres (ATM Switch), Win-
tegra (IP NPU, T1/E1, Circuit Emulation),, PMC-Sierra(SONET/SDH), Conexant Mind-
Speed(T3/E3/IMA/T1/E1), Dallas Framer (T1/E1), Infineon (EFM), DSL Line Hardware
(Conexant, BroadCom, Texas Instruments, Paradyne).
The product required knowledge of the NetPlane software stack which primarily provided
support for ATM (Control and management plane), Card Level Redundancy/Load Shar-
ing Support, a messaging Interface to facilitate the development of a Single Managed
Entity.
The product required knowledge of the Wintegra Software Stack. The software provided
support for developing the IP NPU, ATM switch functionality and Circuit emulation.
Worked in the following areas during the Design, Development phase of this product.
System/Software Architecture
Was part of a team that was responsible for the Software Architecture. The Archi-
tecture was Driven By the Following Requirements
Single Management Entity, Common Software Modules (Separation of Platform
Specific code from Platform independent code., Redundancy (1:1), Code Reuse
(Write Once Use Everywhere)
Circuit Emulation
Worked as Part of a team to provide Circuit Emulation Services over T1/E1
Lines. Designed and Developed a DS0 Device Driver (Wintegra), Designed and
Developed a AAL1 Device Driver (Wintegra), Implemented the DS0 MIB (IETF)
and the CES MIB (ATM Forum)
9

10. Redundancy
APS (Automatic Protection Switching For Sonet) – APS provides line level re-
dundancy for sonet. Worked on designing and implementing the APS monitoring
tasks and the APS controller tasks as per the Bellcore Specification for Sonet
(GR-253). Line Level Redundancy (1:1) – In this case a switchover would be
caused by the failure of the Active Physical Uplink. Worked as part of a team to
Design and Implement Line Level Redundancy independent of a physical medi-
um. Worked with the Netplane Redundancy SubSystem. System Level Redun-
dancy (1:1) – In this case a switchover would be caused if the active system fails
to respond (due to software/hardware failure). Worked as part of a team to De-
sign and Implement Line Level Redundancy independent of a physical medium.
Worked with the Netplane Redundancy SubSystem.
Device Drivers
Designed and Developed the following Device DriversEthernet (IBM405,
MPC860), SONET/SDH, APS, SFP (SFP MSA)
Maintained/Enhanced the following Device Drivers
PPPOAOE, T3/E3, T1/E1, IMA, ATM Switch drivers, Wintegra IP NPU drivers.
Middleware
• Designed and Implemented Standard/Enterprise MIBS in the Following
areas - Ethernet, IMA, Bridge, Routing, Sonet APS, Sonet , DS0, CES,
Entity, IF, ATM, SFP
• Maintained/Enhanced the following Middleware modules. - PPPOAOE.
• Maintained/Enhanced the following applications -Telnet, FTP, PING,
TraceRoute, DHCP,
• ATM - Was part of a team that worked on the ALM/ABM Chipset -
Worked in the areas of CAC, Bandwidth Management
IP Routing
Was Part of a team that maintained and enhanced an existing TCP/IP Stack
• Design and Develop a Network Address Translator.
• Design and Develop the Concept Of Redundant Default Routes using
ARP’s to
• determine when the next hop router went down.
• Enhance the Fragmentation and Reassembly SubSystem to support large
IP Packets.
• Enhance the Routing Table to support CIDR (Classless Inter Domain
Routing)
• Maintaining the TCP/UDP/ICMP/Socket Layer/IP/ARP layer of the Proto-
col stack.
• IP Security – IPSEC (MD5/HMAC Authentication, DES/3DES Encryption)
10

11. 802.1D/802.1Q Bridging
Was Part of a Team that Designed and Developed a Layer2 Bridge To support 24
DSL ports and 1 Uplink port (Ethernet, OC3, DS3). The Bridge Supported 8021Q
Vlans, 8021D, Bridge Filters, Snooping IP/ARP/DHCP Packets to provide for IP
scoping. The Management Data was inband. In other words, the Management
Data was intermixed with the Data Packets.
December 1995-May 1997 - Ciber Inc., Red Bank, NJ - Software
Consultant to AT&T Paradyne
Modem Bank Manager
Worked as part of a team that designed a system to efficiently manage a pool of
dialup(modem) Connections. The responsibilities of this system included establishing/
tearing down a connection when required and to ensure that all the modems shared the
traffic load equally. This was part of a bigger system to support voice traffic(POTS and
Mobile) over the internet. The voice data coming from the internet would eventually be
passed onto a Voice Gateway to gain access to the POTS Network or a Wireless net-
work.
Network Management (SNMP)
Worked as part of a team to design and develop a Simple Network Management Proto-
col (SNMP) agent for an embedded system. The function of the agent was to satisfy
queries from a Network Management Station (NMS) and also inform an NMS about any
events (Traps) that take place on the system. Modifies the Agent To Support the concept
of a Single Logical Entity using Community Strings to provide multiple Views. Imple-
mented Standard MIBs. Designed and implemented enterprise Specific MIBS.
11