pres_all_latest
- 1. Prakash Easwar Philadelphia PA - 19103 Mobile # - 215-964-7589 Email - [email protected] 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