Recommandé
Recommandé
Contenu connexe
Similaire à Service Chaining on SGi-LAN.pptx
Similaire à Service Chaining on SGi-LAN.pptx (20)
Dernier
Dernier (20)
Service Chaining on SGi-LAN.pptx
- 1. Service Chaining on SGi-LAN
- 2. Agenda ● Market Outlook ● Challenges ● Acme Solutions ● Next Steps
- 3. /// Mobility Report 2015 * ● Nearly Flat Growth in Subscriptions in WE ● 10x Mobile Data Traffic in Western Europe ■ 70% Of Traffic Will Be Video * Ericsson Mobility Report - November 2015 www.ericsson.com
- 4. Challenges Today SUBSCRIBERS ASSETS (TCO) OPERATIONS MARKETING ENGINEERING SERVICES REVENUE RELEVANT, VALUABLE, INNOVATIVE, AGILE, ELASTIC MANAGE, QoE, OPTIMIZE, LOWER OPEX RoI
- 5. Acme Networks Vision On Action Plan
- 6. Partnership with OTTs: Revenue Share Model ● Mobile billing (Netflix inclusive) ● Customized plans which include OTT subscriptions (WHATSAPP + E-PLUS ) ● Service Optimization Launch Digital Platforms in response to changing consumption behavior ● App Stores ● Partnership with mainstream online retailers (ebay, Amazon, …) Innovative and Valuable Services: ● 1.8 Billion Mobile IoT devices forecasted by 2021 (CAGR 67%) ● Custom Ad insertion ● Business Cloud Services Monetize: New Revenue Models
- 7. Manage & Optimize: How Can Technology Help? 1. Facilitate Agile creation of new services which support New Revenue Models 1. Improve Operational Efficiency, by means of end to end service visibility, reducing troubleshooting times 1. Significantly improve QoE contributing to Customer Retention 1. Provide a cost effective path for scaling your capacity and performance to support market demand, effectively reducing CAPEX & OPEX 1. Chained Service Enablers!
- 9. ● Mobile Pipe Zone: RAN + EPC IP-CAN (Connectivity Access Network) ● Mobile Service Zone: Between Mobile Pipe Zone and Internet: ○ Ecosystem of Service Enablers providing Value Added Services ○ Improving QoE ○ Monetizing Mobile Broadband Traffic ○ Potentially reducing CAPEX & OPEX ● Service Function Chaining: Definition of an ordered list of service enablers for any given traffic flow The Mobile Service Zone and Network Ossification
- 10. 3GPP: TR23.718 & TS 29.212 Arch Enhancement for Flexible Mobile Service steering: Sd (TDF) & St (SCTCF) - Dec 2015 IETF: RFC 7498 & 7665 Service Function Chaining (SFC) Architecture (NSH header) - Oct 2015 ONF: L4-L7 Service Function Chaining Solution Architecture - June 2015 BBF: Flexible Service Chaining SD-‐326_Rev03 - Oct 2014 Ongoing Standardization Initiatives
- 11. MANAGE AND OPTIMIZATION CHALLENGES Manually configuring service & security policies is complex, time consuming and error-prone Our SGi-LAN deployment is hardwired, multivendor and static making it difficult to change and scale Inefficient use of subscription based service enablers (not enough granularity) RECAP WHAT IS OUR SOLUTION?
- 15. 1. Service Function Path identification 2. Transport independent service function chain 3. Per-packet network and service metadata The Key Enabler: NSH NSH HEADERDraft-ietf-sfc-nsh-04.txt 21st March 2016
- 16. Use Case 1: Corporate User
- 17. Use case 2: Pay as you go under 18
- 19. CHALLENGE SOLUTION BENEFIT Manually configuring service & security policies is complex, time consuming and error-prone SCTCF & TDF orchestrate policies across all service enablers and PoPs in a matter of seconds Agile and Reliable deployment of New Services Ossified SGi-LAN Hard to evolve and scale NFV based solution with SF Proxy ensures interoperability with all Service Enablers Elastic SGi-LAN Reduce OPEX Transitioning strategy (CAPEX) Inefficient use of service enablers (not enough granularity) SCTCF builds Service Chain Paths using only relevant Service Enablers based on multiple inputs (Gx, St, Sd) Reduce OPEX Increase QoE Wrap Up
- 20. THANK YOU Q&A
- 21. Opening the door for more discussions with other stake holders (Mobile Edge Computing)? Solution Roadmap?
Notes de l'éditeur
- I chose Ericsson’s report above all others (Cisco, Citrix, ….) because it provides more insight on the areas I believe are more relevant for this discussion. Cisco does’t split geographically as well as /// and Citrix doesn’t provide traffic forecasts but app usage trends and traffic volume per device Penetration = 129% in Western Europe (545 Million Subscriptions) M2M is expected to grow at an annual growth rate of 25 percent up to 2021, driven by new use cases In total, Ericsson estimates 1.5Billion M2M cellular devices by 2021 Western Europe currently have the largest subscriber to data volume ratio due to high penetration of high-end user devices and well built-out 3G and LTE networks with affordable packages of large data volumes. This leads to higher data usage per subscription. Today Video is 50% of all traffic Youtube dominates the video with 50-55% share of all video traffic Netflix, where available is already taking 10-20% of the video share Social media, particularly on smartphones (as opposed to mobile PCs or tablets) accounts for 15% of total generated traffic In 2021 70% of global mobile traffic will be video. Interestingly, Cisco’s Visual Networking Index forecast for 2020 agrees with these figures.
- I CHOSE THIS GRAPH TO STEER AWAY FROM SILO’ED APPROACHES TO COMMON BUSINESS CHALLENGES. As we have seen, Mobile Data occupies the highest mindshare in the business. The cost of operating, let alone scaling, your mobile internet infrastructure shows no sign of slowing down, and the question of who pays for mobile internet usage has traditionally fallen to the two main players in this exchange – the operators and their subscribers. But, there are other constituents with a vested interest in the reliability, affordability, and adoption of mobile internet usage: OTT PROVIDERS Advertisers Retailers And other companies whose business model relies on consumer mobile connectivity. In other words , there are other players in the ecosystem making profits out of your and your customers expenditure, taking a slice of your pie in a party you have not been invited to. Telefónica, France Telecom and Deutsche Telekom all say Google should start paying them for carrying bandwidth-hungry content such as YouTube video over their networks. César Alierta, chairman of Telefónica says that if no revenue sharing agreement was possible between the internet search engines led by Google and the network operators, regulators should supervise a settlement. Stéphane Richard, France Telecom CEO: “Let’s see the development of digital society in terms of the winners and the victims. Today, there is a winner who is Google, there are victims that are content providers, and to a certain extent, network operators." René Obermann, Deutsche Telekom’s chief executive:“There is not a single Google service that is not reliant on network service,” he says. “We cannot offer our networks for free.”
- I have rationalized an approach to the previous challenges based on 3 main areas: “Manage” CHALLENGES would mean to deploy an intelligent policy and charging control solution that would assure proper allocation of network resources, based on subscriber’s needs and what the network can deliver. “Optimize” CHALLENGES centre on addressing needs for faster access speeds and consistent service quality; letting subscribers enjoy an optimized mobile internet experience. AND LOWER CAPEX “Monetize” CHALLENGES primarily have hovered around restricting excessive usage by a few users whilst driving mass adoption, flexibility to create tariff plans based on speed, services, traffic, time, Most operators have invested in advanced and stand alone solutions to address the high growth they have experienced on mobile data. They keep enhancing the fat pipes and have added peripheral solutions such as optimization and acceleration to manage their networks gracefully. However the outcome of this has not been as impactful as envisaged and the challenges remain the same, namely how to Manage, Optimize and Monetize. I call it the MOM challenge for the mobile operator. It’s not that you have not attempted to address the above challenges. In fact you have gone ahead and deployed specialized and niche solutions to manage data traffic. These solution modules are typically deployed from independent best-of-breed vendors whose focus is on addressing individual problems and they sure do a great job in overcoming the challenges given to them however things fail when these individual vendors need to work together and collectively offer a seamless experience for operators and their subscribers.
- Partnership with OTTs: Revenue Share Model (Netflix, Youtube,...) / WHATSAPP + E-PLUS (TEF GERMANY MVNO) Digital Platforms for instance, entertainment consumption through phones, tablets, and computers now takes up about half of total media consumption. NTT DoComo launched dMarket (CAGR 50% over the first two years) Making Internet of Things (IoT) mobile: lets consumers use their mobile phones to control household electrical appliances such as fridges, TV, washing machines, coffee makers, and indoor thermostats. E.g TomTom Lifetime Service
- If we look at the previous slide, there are significant synergies between Operations & Engineering working on both Services and Infrastructure. We unify both Challenges in this slide for the sake of simplicity: Facilitate Agile creation of new services which support third party agreements Improve operational efficiency, by means of end to end service visibility, reducing troubleshooting times Significantly improve QoE contributing to customer retention Provide a cost effective path for scaling your capacity and performance to support market demand, effectively reducing CAPEX & OPEX
- Service Enablers are the processes at application layer that interact with user traffic in order to improve, enhance, secure QoE as well as provide insight on trends, patterns, etcc for market intelligence / visibility Let’s have a look in more detail to Service Enablers and what they bring: There are a myriad of players in this ecosystem, each of them being a specialist in at least one particular Service Function. Whats happening in the industry is that they tend to complement their offering with capabilities from other vendors, for simplicity of sales to SPs . rebadged under their name at an extra cost. Most of them are gearing or have already geared their portfolio to include VNF versions in their offering
- The Mobile Pipe Zone described as RADIO ACCESS AND CORE core networks, providing BEARER SERVICESfor carrying mobile broadband traffic. The other zone is the Mobile Service Zone, allocated between the bearer services (Mobile Pipe Zone) and the Internet, with a collection of SERVICE ENABLERS for providing Value Added Services (VAS). These service enablers include, for example, TCP Optimization, Video optimization, Web caching, HTTP header enrichment, firewalls, AND: Greatly improve QoE Lower operational costs Monetize the traffic by providing differentiated service handling. This is the area of the network where I want to focus our attention. Chaining of Service Enablers (Network Functions) in Hardware HAS BEEN the De facto Standard: Hardwired service chains are hard to deploy and change, leading to network Ossification: Rigid and Britle The issue today is that the APPLICATION LAYER (consumer services) is very dynamic and agile, yet the underlying network remains static. Besides, since all traffic flows pass through every service enabler, and even if you already have Traffic Steering in pLace, this model has several deficiencies: It requires considerable effort to insert new service enablers or to upgrade existing ones. Every change of a single enabler may lead to a reconfiguration of all service enablers that are chained. A failure of a single enabler may interrupt the overall service. Each enabler has to process and forward all the traffic flows, which increases the overall processing, the traffic delay and also service costs To address this, the industry needs to migrate towards service centric programmable networks
- 3rd Generation Partership Project envisaged the need for an enhancement on the way Service Enablers are steered from the PCRF, based on subscriber and application profiles, alleviating the Gx interface. The nature of Service enablers or the routing of traffic between those service enablers is out of the scope of 3GPP. Its all about providing policies for traffic steering through interfaces defined by 3GPP: Gx, St, Sd IETF on the other hand It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. NSH being the major contribution ONF, focuses on the SDN / NFV angle to L4-L7 service function chaining (SFC), and the information necessary for the SDN Controller’s northbound interface (NBI) and southbound interface (SBI). The intent is to build a common base for concrete NBI specifications and OpenFlow (OF) extensions needed for SFC. Interestingly enough, BBF approaches a similar requirement from fixed line operators.
- Our solution comprises the infrastucture that accomodates an ecosystem of Service Enablers, any function, any vendor, any location. Facilitates Agile deployment of new services Simplifies enforcement of end to end service policies Unifies / provides visibility and Reducing troubleshooting time Improves QoE Reduces OPEX All of you are familiar with this virtual layered model. The solution scales multidimensionally by means of the following:
- SCALE UP: Traffic levels are steadily increasing as a matter of routine for most enterprises as new users, features, and functions are added to existing applications. On top of this, numerous events, not all of which are predictable, routinely cause temporary spikes in demand. NetScaler Pay-As-You-Grow is a simple, 100% software based, on-demand licensing model that breaks the hardware dependency of competing offerings. With Pay-As-You-Grow, customers can purchase a NetScaler solution that meets their needs today, confident they can quickly and easily ‘scale up’ in the future without the need for costly and disruptive hardware replacements. All it takes is a simple software license upgrade to increase performance by up to 5x. SCALING OUT: Scaling UP provides on-demand scalability up to the physical limit of an NFV appliance. When situations where even greater capacity is required, Acme cluster operates as a single entity to simplify operational management tasks. Policy changes are made just once and are automatically propagated across all nodes. LINEAR SCALING SCALING IN: MVNOs & 3rd PARTIES Scale the number of application or business units that can be supported. The result, predictably, has been appliance sprawl and steadily increasing network complexity. What MNOs need instead is a way to support multiple tenants with a single physical device that can also be used to consolidate any existing, SERVICE ENABLERS. :
- TDF: Traffic Detection Function Traffic Detection Function / 3GPP TS 29.212.: From PCRF to TDF PCRF contains the names of several dozen video streaming and social networking plans among others. The PCRF manages subscriber session-level decisions, including associating subscribers with plans, and sends this to the TDF via Sd interface. ADC stands for "Application Detection and Control", where the "Control" part refers to PCEF : enforcement of policies like traffic throttling, blocking or redirection, application based charging, usage monitoring etc) The TDF contains a detailed policy of how to manage the Layer-7 data flows on a per-subscriber basis for each plan. However TDF lacks the necessary global view to apply multiple policies influence by a number of different inputs (not only PCRF) and cannot combine all necessary policies into a particular SERVICE CHAIN since it has not intelligence enough or full visibility to do so. This is achieved via the St interface: The St interface is used to provide traffic steering policy to the SCTCF, together with a traffic descriptor describing the traffic data flow for which the traffic steering policy applies. Application reporting from SCCTF to PCRF is not required over the St interface although beneficial. Sd is the chosen reporting interface back to PCRF. The functionality of the SCTCF includes the following: - The SCTCF is the receiver of the traffic steering policy and supports control plane functionality to terminate the St interface. - The SCTCF performs a mapping of the traffic steering policy to service chain specific identifiers and procedures and mapping of the traffic descriptor to convey traffic steering information, which comprises service chain identifiers and other information which is required by the SGi-LAN implementation (TDF AND SFF) to the SGi-LAN. - Receiving metadata from the PCRF and activating/deactivating their reporting IETF is working on some of the aspects of flexible traffic steering solution.through "Service Function Chaining Architecture" Among the other functions, the architecture defines Service Classification Function (SFC Classifier)whic is similar, if not the same as 3GPPs TDF. It performs L3/L4 or L7 parameter based traffic classification, performs SFC encapsulation based on the operator policy. SFC encapsulation enables service function path selection and sharing of metadata/context information when required. The SFF examines the Network Service Header to determine how to forward the traffic. In the current solution, for enforcing the traffic steering policy, the SFC Classifiers, SFFs and SFs are located in the (S)Gi-LAN and receive instructions from the SCTCF for how to classify and route traffic. When the optional packet marking in PCEF/TDF is applied, traffic classification in SGi-LAN based on L3/L4 rules is sufficient. Furthermore, since the solution does not define the location of the SFC Classifier(s), it allows multiple classifiers that may be distributed in the (S)Gi-LAN, in line with the IETF architecture (see TS 29.212 [4]). St interface: The St interface is defined between the PCRF and a Service Chain Traffic Controller Function (SCTCF) SCTCF: ensures Traffic Steering policy is implemented in the SGi-LAN. The SCTCF performs a mapping of the traffic steering policy to service chain specific identifiers procedures and mapping of the traffic descriptor to convey traffic steering information, which e.g. comprises service chain identifiers and other information which is required by the SGi-LAN implementation, to the SGi-LAN. The details for how the SCTCF ensures that the traffic steering policy received from PCRF is enforced in the SGi-LAN is out of 3GPP scope.Receiving metadata from the PCRF and activating/deactivating their reporting
- Configuring network services and security policies into an application network has traditionally been the most complex, tedious and time-consuming aspect of deploying new applications. For a cloud provider to stand up applications in minutes and not days, easily configuring the right service nodes (e.g. a load balancer or firewall), with the right application and security policies, to support the specific workload requirements, independent of location in the network is a clear obstacle that has to be overcome. Let’s say, for example, you have a world-beating best-in-class firewall positioned in some rack of your data center. You also have two workloads that need to be separated according to security policies implemented on this firewall on other servers a few hops away. The network and security teams have traditionally had a few challenges to address: If traffic from workload1 to workload2 needs to go through a firewall, how do you route traffic properly, considering the workloads don’t themselves have visibility to the specifics of the firewalls they need to work with. Traffic routing of this nature can be implemented in the network through the use of VLAN’s and policy-based routing techniques, but this is not scalable to hundreds or thousands of applications, is tedious to manage, limits workload mobility, and makes the whole infrastructure more error-prone and brittle. The physical location of the firewall or network service largely determines the topology of the network, and have historically restricted where workloads could be placed. But modern data center and cloud networks need to be able to provide required services and policies independent of where the workloads are placed, on this rack or that, on-premises or in the cloud. Whereas physical firewalls might have been incorporated into an application network through VLAN stitching, there are a number of other protocols and techniques that generally have to be used with other network services to include them in an application deployment, such as Source NAT for application delivery controllers, or WCCP for WAN optimization. The complexity of configuring services for a single application deployment thus increases measurably. Cisco was first to address these problems when we started enabling virtual networks with Nexus 1000V. Nexus 1000V was first to implement a technology called “service chaining” in a feature called vPath. vPath ran in the Nexus 1000V switch and hypervisor to intercept network traffic and re-route it to the required virtual service nodes. Initially, it really wasn’t service chaining because it only worked for one service at a time, specifically the Virtual Security Gateway (VSG) firewall, but eventually it allowed for multiple service node hops between workloads, such as going through VSG and then a NetScaler 1000V application delivery controller. vPath worked very well in VXLAN virtual overlay networks, and still remains a key component of Nexus 1000V virtual networking deployments, but vPath is limited to virtual network services, and the ideal service chaining solution should support both physical and virtual services, as well as physical and virtual networks and workloads. Service chaining has a lot of synergy with Software Defined Networking (SDN) technology because it is essentially a policy construct. For example, a service chain may implement a policy that all TCP port 80 traffic must first pass through a firewall and then an intrusion prevention system (IPS) before ending in a load balancer and the destination address. This concept is particularly relevant in the Cisco Application Centric Infrastructure (ACI) policy model, where policies are applied to application network profiles (ANP), which define how application workloads and services should work together, and the policies that are implemented throughout the application network. Understanding which policies are applied at which service nodes, and how each workload can reach those services is a foundation of the ACI policy model. Along comes Network Services Headers (NSH), a new Service Chaining protocol… Based on the early success of vPath, but needing to extend the concept to physical devices and networks, as well as addressing more “chaining” requirements for more extensive cloud use cases, Cisco developed Network Services Headers (NSH), a new service chaining protocol that is rapidly gaining acceptance in the industry. Based on lessons learned in earlier versions of vPath, and realizing that NSH would only succeed with broad acceptance from a wide variety of network services and security vendors, Cisco moved to propose NSH as a standard and brought a multi-vendor proposal to the IETF: RFC 7665 Service Function Chaining Architecture NSH is added to network traffic, in the packet header, to create a dedicated services plane that is independent of the underlying transport protocol. In general, NSH describes a sequence of service nodes that the packet must be routed to prior to reaching the destination address and adds this metadata information about the packet and/or service chain to an IP packet. NSH is typically inserted by a network node, often on ingress into a network (The SFC Domain). NSH is inserted between the original packet or frame and any outer network transport encapsulation such as MPLS,VXLAN, GRE, etc. As NSH is transport agnostic, it can be carried by many widely deployed transport protocols. NSH requires a control plane to exchange values with participating service nodes and to provision those nodes with information such as the service paths (and by association the service chains) that need to be supported. It is applicable to many different environments, so it does not mandate a single control protocol—rather, widely-used control planes must add support for service chaining via NSH . Commonly used protocols—both centralized and distributed—support (or will evolve to support) NSH-based service chaining and vary depending on deployment and operator requirements. The open source OpenDaylight (ODL) SFC project, for example, provides an SDN approach to service chaining via a controller. The controller platform is agnostic with respect to southbound provisioning protocols, and it uses the appropriate ODL protocols for a given device/service chain combination. These southbound protocols include Open-Flow with Open vSwitch (details) and Netconf/YANG (details). NSH Benefits As described earlier, network services are currently tightly linked to topology. The IETF SFC group’s “Problem Statement” draft describes additional limitations in existing deployments. To address these limitations, NSH offers a vastly simplified and unified data plane. Specifically, it decouples the service topology from the actual network topology. Rather than being viewed as a “bump in the wire,” a service function becomes an identifiable resource available for consumption from any location in the network. Agile, elastic service insertion is a core component of any modern network. As service chaining matures, interoperability is a must. The proposed NSH protocol standard provides the required data-plane information needed to construct topologically independent service paths and greatly simplify the provisioning of network services and the deployment of associated applications.
- In this scenario, a corporate user is using his company’s provided iphone to watch a tv series in netflix (service which he/she is paying himself) while at the same time is receiving emails from customers and his/her office. It is important to note here that three different policies are combined and applied: A corporate policy with the user’s company contract which provides anti-spam services on the wire A Netflix agreement ($) to optimize video delivery to netflix and VF subscribers (both residential & business) A device detection policy which indicates that the user is using an iPhone 5 and needs TCP optimization
- In this scenario a minor is using is Pay As You Go Android smartphone to: Chat with friends through Facebook Massenger, Browse articles in Amazon UK Watch his/her favourite Video Blog There are existing agreements with Amazon for VF to place relevant ads (new music albums, clothing promotions, etc….) on the subscribers Chrome browser. Amazon provides the content (thanks to header enrichment demographic data) and pays for the associated downlink traffic. Ad Insert and Header enrichment Service Enablers are involved in this Service Chain There is a different agreement with youtube who just wants to get demographic & location based info through header enrichment. They already have an ad insert service. Also, there are no agreements with Facebook hence their traffic is not treated. Best Effort bearer service as per the T’s&C’s in the Pay As You Go mobile data contract On top of this, the subscriber is a minor and his/her parents selected the Under-18 PAYG tariff plan which includes Parental Control, meaning it cannot be bypassed (the way a parental control app can be)
- The solution was originally designed bearing in mind a mature and saturated ecosystem of vendors and solutions in your Mobile Services Zone, hence seamless interoperability with existing deployments is provided through South-Northbound APIs (primarily RESTful). Stage number 1 does not require St interface since we are at a very early stage and we ignore the maturity level of this development in your PCRF providers (although we know they are working on it. It is going to happen). Steering information can be exchanged through the existing Gx. When it comes to Sd interface (already available in a numer of implementations), the Application Detection and Control (PCEF) can be provided inline the Gi interface when properly instantiated i your PGW. Bear in mind that I am showing here a single PoP approach. Ubiquity is easily achieved following the NFV model, in which the NFV (SFC) Orchestrator overlooks and speaks to multiple STFC, TDFs and NSH Proxies across the Nation.
- Vodafone: Adrian Neal, Peter Cosimini, Adam Pollard, Guenter Klas