Download DOCSIS 3.1 & SDN:

Post on 13-Feb-2017




2 download

Embed Size (px)


<ul><li><p>DOCSIS 3.1 &amp; SDN: SDN Ground Truth Experiences </p><p>David Early, Ph.D. Applied Broadband, Inc. </p></li><li><p>SDN is easy, right? </p><p>Photo: Bell Labs </p></li><li><p>SDN and PacketCable Multimedia </p><p>Photo: Bell Labs </p><p>ApplicationApplication</p><p>Application Support</p><p>Orchestration</p><p>Abstraction</p><p>Control Support</p><p>Data transport &amp; processing</p><p>Application-control Interface</p><p>Resource-control Interface</p><p>Application Layer</p><p>SDN ControlLayer</p><p>ResourceLayer</p><p>(From PKT-SP-MM-I06-110629) </p></li><li><p>OpenDaylight (ODL): Starting Point </p><p>Photo: Bell Labs </p><p>OpenDaylight is a collaborative, open source project to advance Software-Defined Networking (SDN). OpenDaylight is a community-led, open, industry-supported framework, consisting of code and blueprints, for accelerating adoption, fostering new innovation, reducing risk and creating a more transparent approach to Software-Defined Networking. </p></li><li><p>ODL PacketCable Plugin </p><p>Photo: Bell Labs </p><p> Created by CableLabs Provides all the necessary components to support basic PCMM: </p><p> Packetcable PCMM Provider Packetcable PCMM Model Southbound ODL plugin supporting PCMM/COPS protocol driver Packetcable PCMM RESTCONF Service API </p><p> Limited to SCN based gates OOTB Jumpstart: Modify Code rather than writing from scratch </p></li><li><p>Ground Truth: Implementation </p><p>Photo: Bell Labs </p><p> Adapt existing Applications Telephony Congestion </p><p> Use a common REST interface </p><p> Based on Yang models Common for all applications Adaptable to unique circumstances </p><p> ODL internal communications between the datastores and PCMM plugin </p><p> COPS-PR to the CMTS CMTS</p><p>ODL</p><p>Tele</p><p>phon</p><p>y</p><p>Con</p><p>gesti</p><p>on</p><p>Vid</p><p>eo</p></li><li><p>Ground Truth </p><p>Photo: Bell Labs </p><p> Successfully set gates in the lab Off the shelf opensource, minimal modifications </p><p> Premise shows promise Modular approach to scale and flexibility </p><p> Future: </p><p> Scalability Survivability Manageability </p></li><li><p>Ground Truth: Current Limitations </p><p>Photo: Bell Labs </p><p>Examples: Not all PCMM Traffic Profiles and DOCSIS MAC layer </p><p>scheduling types are supported yet </p><p> The ODL REST API does not return any explicit (ACK/NACK) operational information to the requesting ODL Application. Just 200 OK </p><p>Nothing earth shatteringly bad, but work to be done. </p></li><li><p>How do you eat an elephant? </p><p>Photo: Bell Labs </p><p>One bite at a time: Evolutionary approach </p><p> Do one thing well, move on Dont boil the ocean Only implement what is needed Leverage other peoples work Remember scale and flexibility </p><p> Keep it Modular </p></li><li><p>Thank you </p></li><li><p>VIRTUAL MACHINE PLACEMENT STRATEGIES FOR VIRTUAL </p><p>NETWORK FUNCTIONS </p><p>Adam Grochowski Juniper Networks </p></li><li><p>NFV/VNF Considered NFV gaining traction in the industry. OpenStackDefacto Virtual </p><p>Infrastructure Manager (VIM). NFV workloads differ from traditional </p><p>cloud workloads. </p><p>Its about the network now. </p></li><li><p> CPU RAM Storage Availability zone IOPS </p><p>Nova Workload Filters Filter examples: </p><p>Good candidate? </p><p>Host4 </p><p>Host2 </p><p>Host1 </p><p>Host2 </p><p>Host3 </p><p>Host4 </p><p>Filter </p><p>Host1 </p><p>Host2 </p><p>Host3 </p><p>Host4 </p><p>Weight </p></li><li><p> OpenStack doesnt care. Will plumb the network. Will also place VM on </p><p>non-viable host. </p><p>What About the Network? </p></li><li><p>What We Need New network-related attributes </p><p> Port bandwidth Requested bandwidth </p><p>Class NetworkFilter(filters.BaseHostFilter): ""Network Filter Utilization"" def host_passes(self, host_state, filter_properties): """Only return hosts with sufficient available BW.""" instance_type = filter_properties.get('instance_type') requested_bw = instance_type[bandwidth_mb'] </p></li><li><p>Needed: </p><p>Its About the Network Now </p><p>New OpenStack development </p><p> Addition of network-based </p><p>placement </p><p>Provide quality service for network functions </p><p> Improve server utilization, </p><p>improve ROI </p><p>To: </p></li><li><p>Thank you. </p></li><li><p>Assessing Network and Equipment Failures in the New SDN/NFV </p><p>Architectures </p><p>Marlon Roa Infinera </p></li><li><p>Transport network Change in management topology </p><p>SDN Ctl </p><p>Legacy Management Low bandwidth Relax latency need, if any Connectivity protection objective </p><p> Failure not customer affecting HA at NMS/ OSS level </p><p>SDN/NFV Management: High bandwidth &amp; QoS methods </p><p> Data &amp; control traffic Service/data process latency critical </p><p> Forces clusters closer to nodes Connectivity protection requirement HA at former NMS level and near key nodes </p><p>NFV MANO </p><p>NFV MANO </p><p>SDN Ctl NMS NMS </p><p>NMS HA Cluster </p><p>Service continuity is not only a customer expectation, but often a </p><p>regulatory requirement, as telecommunication networks are considered to be part of critical </p><p>national infrastructure, and respective legal obligations for service </p><p>assurance/business continuity are in place (NFV ETSI [2] specification). </p><p> Effects: Extended downtime or </p><p>execution error </p><p>SDN Controller HA Clusters </p><p>NFV MANO HA Clusters </p></li><li><p> Sample functions SDN: Route, re-route, cross-connect, etc. NFV: Functions part of data-path Deliver carrier-grade performance </p><p> Failure prevention: </p><p> SDN/NFV: Hardware protection at certain nodes </p><p> Openflow 1.2: Slave/master/same No standard protection </p><p> Reboot/reset recovery complexity Hardware choices: </p><p> Processor, memory, I/O Operating temp SW compatibility </p><p>SDN Controller / NFV MANO Hardware </p></li><li><p>SDN Controller/Orchestrator NFV MANO connectivity </p><p> Sample functions Heartbeat monitor Sync backups SDN/NFV coexisting (ETSI/ONF) Controller/Orchestrator as in NMS/OSS model SDN/NFV HA Clusters closer to nodes </p><p> Failure prevention: </p><p> HA design: Cluster, HA monitors, Load balancers, low latency </p><p> Connectivity redundancy between host servers New sub-network </p><p> Security of link (Ex: IPsec) due to remote controllers </p><p> Link media upgrades to relief congestion </p></li><li><p>SDN/ NFV Controller to Node connectivity </p><p> Sample functions Legacy configuration and PM data SDN service affecting decisions Execution and OAM of VNFs Security for new customer traffic path </p><p> Failure prevention: </p><p> Redundant, symmetric, low latency paths (NFV) </p><p> Increase management link requirement QoS (Control, Customer), latency, speed </p><p> Security of link (Ex: IPsec) Function download and execution </p><p>validation </p></li><li><p>SDN/NFV deployment and the cost increase </p><p> New deployment challenges for control layer New Qualification testing </p><p> Multi-vendor, non-standard HW &amp; SW New redundant control-layer HW/SW at nodes New carrier-grade connectivity intra-nodes &amp; among </p><p>control clusters </p><p> Non-trivial cost of deployment today. Tomorrow: Industry certification of HW/SW bundles (Ex: MEF with ETH) As SDN &amp; NFV mature, reduced cost and complexity </p><p> Normalize redundancy of connection to nodes Clear best-practices for resiliency of controllers should </p><p>become clear </p><p>Have you estimated OPEX &amp; CAPEX of actual SDN &amp; NFV deployment? </p></li><li><p>THANK YOU </p><p>Marlon Roa Technical Solutions Director </p></li><li><p>DOCSIS 3.1 Overdrive: Dynamic Optimization Using a Programmable Physical Layer </p><p>Jason Schnitzer Applied Broadband, Inc. </p></li><li><p> Shannon &amp; DOCSIS </p><p>Photo: Bell Labs </p><p>CMTS HFC CM </p></li><li><p>Photo: Bell Labs </p><p>DOCSIS 3.1 OFDM Profile Optimization </p></li><li><p>Profile Management Application (PMA) </p><p>Photo: Bell Labs SOURCE: CableLabs, VNE-TR-SDN-ARCH-V01-150623 </p></li><li><p>D3.1 Programmable Optimization System </p><p>Photo: Bell Labs </p><p>Separation of Data and Control Planes Data forwarding via DOCSIS resources Control plane hosts application Abstraction of Network Complexity CMTS Vendor Abstraction layer (CVAL) Visibility instrumentation normalization Common control interface Programmatic Interaction Common Data Model (YANG Defined) RESTCONF API </p></li><li><p>Optimization Information Model A Big Data Problem </p><p>Photo: Bell Labs </p><p>DsRxMer FEC Codewords RxPower </p></li><li><p>Current Art </p><p>Photo: Bell Labs </p><p>Capabilities Measurement &amp; control plane Complete data model collection in </p><p>production network Profile control proven in lab Basic optimization logic using </p><p>simple network policies Limitations Small number of simple profiles Proprietary control interfaces (CLI) Limited data model (SNMP MIBS) </p></li><li><p>Future Work </p><p>Photo: Bell Labs </p><p>Protocols Define standard profile control </p><p>interfaces on D3.1 CCAP API for OPT REQ-RSP Formalize PMA architecture OpenDaylight SDN integration Analysis &amp; Control Historical data analysis Standard CMTS APIs Profile Optimization and control in </p><p>production D3.1 network </p></li><li><p>Thank you </p></li><li><p>Evaluation of virtualizing DOCSIS MAC by software in data center </p><p>Li Zhang, Xin Yang, Lifan Xu Huawei Technologies Co.,Ltd. </p></li><li><p>Virtualized DOCSIS MAC introduce DOCSIS MAC consists of data plane, control plane, and management plane. </p><p> the control and management plane are all software in CCAP implementation; the data plane is almost hardware like FPGA to guarantee high throughput and low latency. </p><p> In order to evaluate DOCSIS MAC virtualization, we break down the DOCSIS MAC to </p><p>several functionality modules, then build NFV simulation modules to estimate how many generic CPU cores are needed and what performance it can achieve. </p><p> The NFV platform we used is DPDK(Data Plane Development Kit) which provides a set of </p><p>data plane libraries for fast packet processing. </p><p> The Hardware we used is Huawei FusionServer RH2288 which can provide Intel Xeon 12 cores 2.6GHz-64bits processor, 8*10GE NIC and 128G RAM. </p></li><li><p>DOCSIS MAC Break Down </p><p>Ethernet RX MAC</p><p>Service Flow Classifier</p><p>Downstream Scheduler</p><p>Bonding Channel </p><p>Distributor</p><p>DOCSIS Framer</p><p>MPEG2 Framer</p><p>DEPI Encapsulate</p><p>*Only for data traffic *Not apply for D3.1</p><p>UEPI Decapsulate</p><p>Concatenation Fragmentation</p><p>DOCSISDeFramer</p><p>AES/DES Encryption</p><p>AES/DES Decryption</p><p>Frame Distributor</p><p>Upstream Scheduler</p><p>Upstream Scheduler</p><p>Dynamic Service Flow </p><p>Changes</p><p>Multicast Control</p><p>Load Balancing</p><p>CM Control</p><p>Encryption Key Exchange</p><p>Subscriber Management</p><p>Channel Management</p><p>QoS Profile Management</p><p>Modulation Profile </p><p>Management</p><p>QoS Profile Management</p><p>DOCSISOSSI</p><p>CM Management</p><p>Downstream Data Plane</p><p>DOCSIS MAC Control</p><p>DOCSIS MAC Mangement</p><p>Upstream Data Plane</p><p>*Only for data traffic *Not apply for D3.1</p><p>Ethernet TX MAC</p></li><li><p>MAC Data Plane Evaluation </p><p>DS Data Plane Modules CPU Cycles Eth RX and Classifier 1948 Downstream Scheduler 1318 Bonding Channel Distributor 218 AES Encryption 16384 DOCSIS Framer 353 MPEG2 Framer slicing 7631 DEPI tunnel 651 Total 28503 </p><p>US Data Plane Modules CPU Cycles Eth TX 1552 Upstream Scheduler 818 Frame Distributor 318 AES Decryption 16384 DOCSIS Deframer 2553 Concatenation Fragmentation 5931 UEPI tunnel 502 Total 28058 </p><p>Table 1. 2000bytes packet DS data plane CPU cycles </p><p>Table 2. 2000bytes packet US data plane CPU cycles </p><p>Packet Size DS Cycles US Cycles 64 Bytes 21065 20672 128 Bytes 21103 20768 256 Bytes 21814 21410 512 Bytes 22602 22244 1024 Bytes 24811 24362 1518 Bytes 27009 26453 2000 Bytes 28503 28058 </p><p>Table 3. CPU cycles for typical packet length </p><p> The MAC data plane modules are driven by packets, the performance of software forwarding relates with packet size </p><p> we choose 64, 128, 256, 512, 1024, 1518 and 2000 bytes packet size to count processing cycles; Longer packets can get higher bits/s throughput, 2000 bytes is the max packet size defined in D3.1 </p><p>MULPI spec. </p><p> AES encryption and decryption is biggest CPU cycles consumer even if we use intel AES-NI library as acceleration engine. </p></li><li><p>MAC MGMT and Control Evaluation </p><p>Figure 1. Upstream Scheduler CPU usage </p><p> Unlike data plane, MAC control and management threads are driven by events not packets. </p><p> The processing of almost modules are not heavy except upstream scheduler. </p><p> Upstream scheduler operation is cycle base and it is about 1.5ms 2ms; </p><p> Figure 1 gives a typical X86 CPU computing usage curve in different number of Cable Modem, we can get every 1000 CMs needs 0.556 X86 CPU cores. </p><p> other MAC control and management modules only needs 0.218 X86 CPU cores for 1000 CMs. </p><p> The total MAC MGMT and Control plane need 0.774 X86 CPU cores for 1000 CMs. </p></li><li><p>Virtualized MAC Evaluation Summary If we choose the packet size distribution profile shown in the below table: </p><p>Length 64 128 256 512 1518 Packets Percent 50% 10% 15% 10% 15% Bits Percent 8.9% 3.5% 10.6% 14.1% 62.9% </p><p> The CPU cores consumption of the whole DOCSIS MAC software can be summed as: Cores = 3.54 T + 0.556 C + 0.218 C </p><p> Where: T is throughput in Gbps; C is the number of cable modem in one </p><p>thousand. </p><p> The right figure CPU consumption curve for small HUB with 10K HHPs, typical HUB with 30K HHPs and big HUB with 50K HHP. </p><p> Given a HUB with 30K subscribers and 80Gbps bandwidth, about 300 X86 cores are needed. </p></li><li><p>Conclusion There still is a big gap between CPU implementation and FPGA implementation for </p><p>DOCSIS MAC The power consumption of X86 CPU MAC is 24 times of FPGA MAC; The hardware cost is about 77 times. </p><p> Now the generic X86 servers in the cloud are designed for applications which need huge memory and storage, actually the access forwarding device dont require that. </p><p> The DOCSIS MAC virtualization needs a new generic hardware platform for Access network device NFV. </p><p>Early_INTX_D3.1_SDNGROUNDTRUTH-FINALDOCSIS 3.1 &amp; SDN: SDN Ground Truth ExperiencesSDN is easy, right?SDN and PacketCable MultimediaOpenDaylight (ODL): Starting PointODL PacketCable PluginGround Truth: ImplementationGround TruthGround Truth: Current LimitationsHow do you eat an elephant?Thank you</p><p>Grochwoski_INTX Bandwidth Aware VM Scheduleing Deck_PROOF01_051216VIRTUAL MACHINE PLACEMENT STRATEGIES FOR VIRTUAL NETWORK FUNCTIONSNFV/VNF ConsideredNova Workload FiltersWhat About the Network?What We NeedIts About the Network NowThank you.</p><p>Roa-Marlon_Spring Tech Forum 2016_Infinera_SDN_160511Assessing Network and Equipment Failures in the New SDN/NFV ArchitecturesTransport network Change in management topologySDN Controller / NFV MANO HardwareSDN Controller/Orchestrator NFV MANO connectivitySDN/ NFV Controller to Node connectivitySDN/NFV deployment and the cost increase Thank you</p><p>Schnitzer_INTX-D31-OVERDRIVE-FINALDOCSIS 3.1 Overdrive: Dynamic Optimization Using a Programmable Physical LayerShannon &amp; DOCSISDOCSIS 3.1 OFDM Profile Optimization Profile Management Application (PMA)D3.1 Programmable Optimization SystemOptimization Information Model A Big Data ProblemCurrent ArtFuture WorkThank you</p><p>Sun-Evan_Spring Tech Forum 2016 - PPT Evaluation of virtualizing DOCSIS MAC by software in data centerEvaluation of virtualizing DOCSIS MAC by software in data centerVirtualized DOCSIS MAC introduceDOCSIS MAC Break DownMAC Data Plane EvaluationMAC MGMT and Control EvaluationVirtualized MAC Evaluation SummaryConclusion</p></li></ul>


View more >