the death of network engineer -...

40
The Death of Network Engineer Vara Varavithya

Upload: hahanh

Post on 16-Mar-2018

223 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

The Death of Network EngineerVara Varavithya

Page 2: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

วิถีแห่งแนวคิดของผู้บริหารสารสนเทศ Gen Y

อินเตอร์เน็ตก็เหมือนกับไฟฟ้า เมื่อเราต้องการใช้งาน เราก็เสียบปลั๊กเข้ากับผนัง

มันก็ใช้ได้ เราไม่จำเป็นต้องไปทำอะไรเกี่ยวกับพวกเครือข่าย

หรือเตรียมการด้านอุปกรณ์ต่างๆ นาๆ

Page 3: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

วิศวกรเครือข่ายจะต้องมี• strong IT skills

• excellent problem-solving skills

• organisational skills to prioritise tasks

• the ability to explain technical issues clearly

• good people skills

• the ability to work within a team

• a commitment to keeping up to date with the latest developments in IT.

Page 4: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

งานของวิศวกรเครือข่าย• installing and configuring new software and hardware • setting up user accounts, permissions and passwords to allow

access to the network • making sure security is at the right level to block unauthorised

access • finding and fixing network faults • putting in place preventative maintenance schedules • giving technical support to people who use the network • providing training on new systems • carrying out day-to-day administration and monitoring • planning and implementing future developments

Page 5: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

สิ่งที่องค์กรต้องการ1. The ability to administer routers, switches, gateways and oversee telecom infrastructure including the wide-area network (WAN) and local area network (LAN), as well as wireless LANs.

2. Telecom certifications, with membership or certification from the Building Industry Consulting Service International (BICSI), (CCNP) or Cisco Certified Internetwork Expert (CCIE).; certification from Avaya or Microsoft’s MCSE; and Juniper Networks’ JNCIE or JNCIP certification. 

3. Wide-Area Network (WAN) protocol skills, including MPLS, SIP and others

4. Cabling skills, including familiarity with cabling standards from ETSI, TIA and EIA

5. Good documentation practices.

6. Interpersonal and communication skills.

7. Cross-platform telecom systems skills.

8. The ability to implement quality of service (QoS) features.

9. Deep understanding of relevant metrics and analytics for telecom networks.

Page 6: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists
Page 7: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Old School Resume

• Languages : C, Unix shell scripting, T-SQL

• Database : Sybase ASE 12.x, 12.5.x, 15.x

• Operating System : SunOS, Linux, HP-UX, Windows 2003/08

• Other : Sybase Replication, Sybase IQ

Page 8: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists
Page 9: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

เราทำอะไรเป็นกันบ้าง• Network Planning

• Server Infrastructure, Security Mechanisms to prevent DDos

• IPv4 Header, IPv6 Header, ISIS, RIP, OSPF, BGP

• What is latency across the local peering

• How are the firewalls and load balancers configured?

• What are the IP addresses and routing set up?

• Router, Switch, NAT, DHCP, WiFi

Page 10: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

แล้ว...• Web 2.0 for Social Networking

• Mash-ups

• RSS and AJAX ล่ะ

• API, Rest, Python, Ruby ฯลฯ

• สถาปัตยกรรมเครือข่ายที่ดีสามารถเพิ่มประสิทธิภาพของระบบได้มาก แต่อินเตอร์เน็ตก็ความเร็วสูงขึ้นเรื่อยๆ

• ความสัมพันธ์ของวิศวกรเครือข่ายกับการบริการอินเตอร์เน็ต จะคล้าวกับวิศวกรซอฟต์แวร์กับโปรแกรมประยุกต์ของไมโครซอฟต์

Page 11: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

ผู้เชี่ยวชาญ Infrastructure• ผู้เชี่ยวชาญเฉพาะด้านสาธารณูประการ

• ทีม Network ทีม Server ทีม Storage เริ่มไม่เพียงพอที่จะจัดการกับระบบใหม่ๆ ที่ประกอบทุกอย่างเข้าด้วยกัน

• ระบบทั้งสามส่วนไม่สามารถจะแยกออกจากกันได้

• คนที่ทำ Storage จะต้องรู้ Network และ Virtualization, คนที่ทำ Virtualization ก็ต้องรู้ Network กับ Storage เช่นเดียวกัน

• ผู้รับผิดชอบ Network ก็ต้องรู้ถึงการใช้งาน Virtualization และ Storage ว่าจะกระทบอย่างไรกับคุณภาพของเครือข่าย

Page 12: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

ในโลกของระบบ เหมือนมี นั้น เรามักจะพูดถึง

• Virtualization

• Networking

• Storage

• Server

• Datacenter Hardware

แล้วเราจะอยู่กันอย่างไรในโลกของกลุ่มเมฆ เราจะกลายเป็น กระดาษเจาะรูหรือปล่าว

Page 13: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

สำนักคอมฯ• ถ้าศูนย์บริการข้อมูลหรือ Data Center สามารถให้บริการผู้ใช้เป็นส่วนใหญ่ได้แลัว

• การบริการจะเน้นเรื่องของราคาและความสะดวกในการใช้งานเป็นหลัก

• การบริการของสำนักคอมพิวเตอร์จะเปลี่ยนไปเป็นการเชื่อมโยงบูรณาการกระบวนงานของผู้ใช้งาน

Page 14: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Software Defined• เครือข่ายคอมพิวเตอร์เริ่มเปลี่ยนไปนิยามโดยซอฟต์แวร์ ที่สามารถบริหารจัดการได้ในภาพรวม และเป็นอัตโนมัติ

• เราต้องการวิศวกรเครือข่ายสายพันธุ์ใหม่ที่จะเชื่อมโยงส่วนต่างๆ จากผู้ใช้งาน ข้อมูล แอฟพลิเคชั่น และอุปกรณ์เครือข่ายทุกระดับเข้าด้วยกัน

• โดยวิศวกรเครือข่ายสายพันธุ์ใหม่นี้จะมีลักษณะที่เป็นนักพัฒนาโปรแกรมมากกว่าพวกผู้เชี่ยวชาญเครือข่าย

• มีความสามารถในการเขียนพวก Ruby Python หรือภาษาอื่นๆ เพื่อให้ส่วนประกอบต่างๆ มันคุยกันได้

Page 15: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

วิศวกรเครือข่ายประจำมหาวิทยาลัย• มีหน้าที่ประจำคือการประชุม

• ถ้าเกิด Network Down ขึ้นมา ก็เป็นหน้าที่ต้องจัดการให้ได้

• ในระบบเครือข่าย สัญชาติญาณของวิศวกรเครือข่ายต้องตรวจสอบ Layer 1 ก่อน

• ซึ่งความวิเศษของ SDN หรือที่เขาเรียกว่า Orchestration ไม่ได้เปลี่ยนแปลงวิธีคิดดังกล่าว

• เราจะต้องรู้ Topology ของเครือข่าย ถ้า Router Switch Firewall มีปัญหา เราก็ต้องไปปรึกษาผู้เชียวชาญ อาจจะเป็นไปได้ว่าวิศวกรเครือข่าย GenX ของเราต้องผันตัวไปเป็นผู้เชี่ยวชาญอุปกรณ์เฉพาะด้านต่างๆ และรวมกลุ่มกันเปิดบริการอย่างเป็นระบบ ปล่อยสายพันธุ์ใหม่ Gen Y เขียน Ruby Python ไป

Page 16: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

SDN จะกระทบอะไรกับเรา• สุดท้ายแล้ว มีการคาดการณ์ว่าระบบ SDN และ เครือข่ายเสมือน จะทำงานอยู่บนเครือข่ายเดิมของเรา SDN จะถูกสร้างบนเครือข่ายเดิม ไม่ได้มาทดแทน

• โดยสามารถบริหารนโยบายการใช้งานเพื่อให้สามารถออกแบบและบริหารจัดการได้ง่ายขึ้น อย่างไรก็ตามไม่ได้หมายความว่าเราไม่ต้องการผู้คนที่มีความรู้ความสามารถเรื่องระบบเครือข่ายแบบเดิมๆ

• ในกรณีที่ SDN เข้ามามีบทบาทช่วยบริหารจัดการ วิศวกรเครือข่ายควรจะมีชีวิตที่ดีขึ้น โดยใช้เวลาในการทำงานระดับสูงมาขึ้น เช่นเขียนโปรแกรมควบคุม Controller

• ในขณะเดียวกันจำนวนของวิศวกรเครือข่าย มีความต้องการมากยิ่งขึ้นตามการขยายตัวของเครือข่าย จำนวนผู้คนที่ดูแลเครือข่าย Gen X อาจจะพอๆ คน Gen Y ที่บริหารจัดการเครือข่าย

Page 17: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

โอกาส สร้าง Gen Y• มีโอกาสที่เปิดกว้างในการที่จะเป็นวิศวกรเครือข่ายสายพันธ์ุใหม่

• ถ้าเป็นผู้เชี่ยวชาญ และโปรแกรมเมอร์ จะได้รับการตอบรับ เป็นอย่างมาก และเป็นที่ต้องการ

• วิศวกรเครือข่ายควรเรียนรู้เรื่องการเขียนโปรแกรมเพื่อใช้งาน API ที่จะสามารถเข้าถึงการใช้ Applications และ ระบบของผู้ใช้งานได้

• Python for Network Engineer

• Week1 - Why Python, the Python Interpreter Shell, Strings

• Week2 - Numbers, Lists

• Week3 - Conditionals and For Loops

• Week4 - While loops, Dictionaries, and Exceptions

• Week5 - Review and Exercises

• Week6 - Functions

• Week7 - Files and Regular Expressions

• Week8 - Modules and Packages

• Week9 - Classes and Objects

• Week10 - Paramiko SSH, Telnet, and Pickle

Page 18: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

http://www.plexxi.com/2013/06/the-death-of-network-engineer-long-live-network-engineers/

Page 19: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists
Page 20: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists
Page 21: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Network Functions Virtualization (NFV)

ETSI ISG

Page 22: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Network Functions• Multicast Broadcast

• Proxy

• Firewall

• Load Balancer

• A set of CDN Servers

• A Smart Phone

• DHCP

• DNS

• Caching services

• Email Services

• Communication Services

Page 23: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Software Implementation of Network

White box implementation

Standard API’s Between Modules

Network Function Modules

Firewall, NAT, DHCP, DNS, Rate Limiting

Implementation in Virtual Machines

Routers, Remote Access, Residential Gateway, Set top box, CDN

Action Steps of NFV

Page 24: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

17-7©2013 Raj Jainhttp://www.cse.wustl.edu/~jain/cse570-13/Washington University in St. Louis

NFV and SDN RelationshipNFV and SDN Relationship�

Concept of NFV originated from SDN �

First ETSI white paper showed overlapping Venn diagram �

It was removed in the second version of the white paper�

NFV and SDN are complementary. One does not depend upon the other.

You can do SDN only, NFV only, or SDN and NFV.�

Both have similar goals but approaches are very different.�

SDN needs new interfaces, control modules, applications. NFV requires moving network applications from dedicated

hardware to virtual containers on commercial-off-the-shelf (COTS) hardware

NFV is present. SDN is the future.�

Virtualization alone provides many of the required features�

Not much debate about NFV.

Page 25: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Addition to IaaS PaaS SaaS

ETSI

ETSI GS NFV 001 V1.1.1 (2013-10) 12

Figure 1: Mapping IaaS and NaaS within the NFV Infrastructure

The resources to be pooled between these services are the physical network, storage and compute resources. In the NFV model these would be considered as the Compute, Hypervisor and Network domains of the Network Function Virtualisation Infrastructure. In the Cloud Computing model, these resources would be considered as elements supporting IaaS or NaaS cloud computing service models. The PaaS and SaaS cloud computing service models provide software based capabilities that have to run over some infrastructure (perhaps the same infrastructure that may be offering IaaS or NaaS service). The computing nodes of the NFV Infrastructure will be located in NFVI-PoPs such as central offices, outside plant, specialized pods or embedded in other network equipment or mobile devices. The physical location of the infrastructure is largely irrelevant for cloud computing services, but many network services have some degree of location dependence. The resource pooling concept includes a notion of multi-tenancy - where the same pool of resources supports multiple applications from different administrative or trust domains. Figure 2 illustrates an NFVIaaS supporting both cloud computing applications as well as VNF instances from different administrative domains.

Figure 2: NFVIaaS Multi-tenant Support

Where a Service Provider (#2) runs VNF instances on the NFVI/cloud infrastructure of another Service Provider (#1), this would be relying a on some sort of commercial service agreement between them. Figure 3 is intended to illustrate this example. Service Provider #1 will require that only authorized entities should be able to load and operate VNF instances on its NFV Infrastructure. The set of resources (e.g. compute / hypervisor /network capacity, bindings to network terminations, etc.) that Service Provider #1 make available to Service Provider #2 would be constrained. Service Provider #2 shall be able to integrate its VNF instances running on Service Provider#1's NFV Infrastructure into an end to end network service instance along with VNF instances running on its own NFV infrastructure. Figure 3 is intended to illustrate this example.

ETSI

ETSI GS NFV 001 V1.1.1 (2013-10) 12

Figure 1: Mapping IaaS and NaaS within the NFV Infrastructure

The resources to be pooled between these services are the physical network, storage and compute resources. In the NFV model these would be considered as the Compute, Hypervisor and Network domains of the Network Function Virtualisation Infrastructure. In the Cloud Computing model, these resources would be considered as elements supporting IaaS or NaaS cloud computing service models. The PaaS and SaaS cloud computing service models provide software based capabilities that have to run over some infrastructure (perhaps the same infrastructure that may be offering IaaS or NaaS service). The computing nodes of the NFV Infrastructure will be located in NFVI-PoPs such as central offices, outside plant, specialized pods or embedded in other network equipment or mobile devices. The physical location of the infrastructure is largely irrelevant for cloud computing services, but many network services have some degree of location dependence. The resource pooling concept includes a notion of multi-tenancy - where the same pool of resources supports multiple applications from different administrative or trust domains. Figure 2 illustrates an NFVIaaS supporting both cloud computing applications as well as VNF instances from different administrative domains.

Figure 2: NFVIaaS Multi-tenant Support

Where a Service Provider (#2) runs VNF instances on the NFVI/cloud infrastructure of another Service Provider (#1), this would be relying a on some sort of commercial service agreement between them. Figure 3 is intended to illustrate this example. Service Provider #1 will require that only authorized entities should be able to load and operate VNF instances on its NFV Infrastructure. The set of resources (e.g. compute / hypervisor /network capacity, bindings to network terminations, etc.) that Service Provider #1 make available to Service Provider #2 would be constrained. Service Provider #2 shall be able to integrate its VNF instances running on Service Provider#1's NFV Infrastructure into an end to end network service instance along with VNF instances running on its own NFV infrastructure. Figure 3 is intended to illustrate this example.

Page 26: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

VNF Architecture

• \

ETSI

ETSI GS NFV 002 V1.1.1 (2013-10) 10

• Implementation details of the architecture itself.

5.2 High-Level NFV Framework Network Functions Virtualisation envisages the implementation of NFs as software-only entities that run over the NFV Infrastructure (NFVI). Figure 1 illustrates the high-level NFV framework. As such, three main working domains are identified in NFV:

• Virtualised Network Function, as the software implementation of a network function which is capable of running over the NFVI.

• NFV Infrastructure (NFVI), including the diversity of physical resources and how these can be virtualised. NFVI supports the execution of the VNFs.

• NFV Management and Orchestration, which covers the orchestration and lifecycle management of physical and/or software resources that support the infrastructure virtualisation, and the lifecycle management of VNFs. NFV Management and Orchestration focuses on all virtualisation-specific management tasks necessary in the NFV framework.

Figure 1: High-level NFV framework

The NFV framework enables dynamic construction and management of VNF instances and the relationships between them regarding data, control, management, dependencies and other attributes. To this end, there are at least three architectural views of VNFs that are centred around different perspectives and contexts of a VNF. These perspectives include:

• a virtualisation deployment/on-boarding perspective where the context can be a VM,

• a vendor-developed software package perspective where the context can be several inter-connected VMs and a deployment template that describes their attributes,

• an operator perspective where the context can be the operation and management of a VNF received in the form of a vendor software package.

Within each of the above contexts, at least the following relations exist between VNFs:

• VNF Forwarding Graph (VNF-FG) covers the case where network connectivity does matter, e.g. a chain of VNFs in a web server tier (e.g. firewall, NAT, load balancer), as described in use case Service Chains (VNF Forwarding Graphs) in GS NFV 001 [3].

• VNF Set covers the case where the connectivity between VNFs is not specified, e.g. virtualised residential gateway as described in the use case Virtualisation of the Home Environment in GS NFV 001 [3].

Within the present document, the specific context of a VNF and the forwarding aspects of a VNF-FG are considered. Other VNF relations are for further study.

Page 27: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

VNF Forwarding Graph

ETSI

ETSI GS NFV 002 V1.1.1 (2013-10) 11

6 Network Services in NFV

6.1 Introduction to Network Services in NFV An end-to-end network service (e.g. mobile voice/data, Internet access, a virtual private network) can be described by an NF Forwarding Graph [1] of interconnected Network Functions (NFs) and end points.

6.2 Virtualisation of Functional Blocks for Network Services A network service can be viewed architecturally as a forwarding graph of Network Functions (NFs) interconnected by supporting network infrastructure. These network functions can be implemented in a single operator network or interwork between different operator networks. The underlying network function behaviour contributes to the behaviour of the higher-level service. Hence, the network service behaviour is a combination of the behaviour of its constituent functional blocks, which can include individual NFs, NF Sets, NF Forwarding Graphs, and/or the infrastructure network.

The end points and the network functions of the network service are represented as nodes and correspond to devices, applications, and/or physical server applications. An NF Forwarding Graph can have network function nodes connected by logical links that can be unidirectional, bidirectional, multicast and/or broadcast. A simple example of a forwarding graph is a chain of network functions. An example of such an end-to-end network service can include a smartphone, a wireless network, a firewall, a load balancer and a set of CDN servers. The NFV area of activity is within the operator-owned resources. Therefore, a customer-owned device, e.g. a mobile phone is outside the scope as an operator cannot exercise its authority on it. However, virtualisation and network-hosting of customer functions is possible and is in the scope of NFV (e.g. see use cases Virtual Network Platform as a Service (VNPaaS) and Virtualisation of the Home Environment in GS NFV 001 [3]).

Figure 2 illustrates the representation of an end-to-end network service that includes a second nested NF Forwarding Graph as indicated by the network function block nodes in the middle of the figure interconnected by logical links. The end points are connected to network functions via network infrastructure (wired or wireless), resulting in a logical interface between the end point and a network function. These logical interfaces are represented in the figure with dotted lines. In Figure 2, the outer end-to-end network service is made up of End Point A, the inner NF Forwarding Graph, and End Point B, while the inner NF Forwarding Graph is composed of network functions NF1, NF2 and NF3. These are interconnected via logical links provided by the Infrastructure Network 2.

NF 1

NF 2

NF 3

Infrastructure Network 1

Infrastructure Network 2

Infrastructure Network 3

End Point A

End Point B

End-to-end network service

Network Function (NF) Forwarding Graph

Figure 2: Graph representation of an end-to-end network service

Figure 3 shows an example of an end-to-end network service and the different layers that are involved in its virtualisation process. In this example, an end-to-end network service can be composed of only VNFs and two end points. The decoupling of hardware and software in network functions virtualisation is realized by a virtualisation layer. This layer abstracts hardware resources of the NFV Infrastructure.

The NFVI-PoPs includes resources for computation, storage and networking deployed by a network operator as indicated in Figure 3.

Page 28: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Virtual Network Function as A Services

ETSI

ETSI GS NFV 001 V1.1.1 (2013-10) 17

Figure 6: vE-CPE Location Examples

Figure 7 presents the functionality re-distribution as a result of the virtualisation of the CPE. The enterprise local traffic is handled by a local L2 or L3 switch providing physical connectivity (and possibly further functionality), and the enterprise LAN is extended to the Operator NFV Network located vE-CPE. Example functionality provided by the vE-CPE in Figure 7 includes routing, VPN termination, QoS support, DPI, NG-FW and a WOC (WAN Optimization Controller). We contrast the case of a non-virtualised customer site served by a non-virtualised CPE, and that of a site served by a vE-CPE. The dotted purple lines indicate where this vE-CPE functionality may be located.

Figure 7: Non-Virtualised CPE and vE-CPE

Page 29: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Virtual Network Platform as a Services

• Access Point and Selective Tunnelling

ETSI

ETSI GS NFV 001 V1.1.1 (2013-10) 22

The VNPaaS is similar to the VNFaaS, but differs mainly in the scale of the service and programmability or scope of control provided to the consumer of the service. The VNPaaS provides a larger scale service typically providing a virtual network rather than a single virtual network function. The VNFaaS is limited to configuring the set of VNF instances made available by the service provider, whereas the VNPaaS typically provides the capability for the consumer of the service to introduce their own VNF instances as well. A simple example of the concepts described above could be an email service hosted by the operator for another enterprise. Within the scope of NFV the email server can be described as a VNF. In a typical VNPaaS the hosting service provider provides an installation of an email server without any configuration e.g. mail domains, mailboxes, users configuration, etc. The enterprise has full admin control of the email server and needs to apply all configurations on its own, potentially with support of the hosting service provider. Additionally, the enterprise might deploy other VNF instances connected to the email server to allow advanced use cases e.g. a spam protection service. In a VNPaaS scenario the enterprise gets an email service pre-configured for a certain email domain and a basic set of configurations to run the mail service. The enterprise may be able to administrate user mailboxes via an interface provided by the hosting operator. The actual email server is typically hidden behind a frontend provided by the hosting service provider.

The type of services supported on VNPaaS can range from a simple firewall service for a single enterprise to a whole business communication suite based on IMS network for a 3rd party. A service may either be orchestrated out of existing services (VNF Forwarding Graph), deployed as new elements, or implemented as a combination of both.

Figure 11 depicts an example of sharing network resources.

Figure 11: Example of 3 party enterprises sharing a Service Provider's infrastructure

There are 4 entities represented in the setup. The hosting service provider owns the infrastructure and resells shares of the infrastructure resources to 3rd parties. Enterprise A uses two VNF instances one of which is connected to a VNF instance in the hosting service provider's network. Enterprise B deployed a standalone VNF instance which is not connected to a VNF instance in the hosting service provider's network but might have connectivity to the enterprise corporate network. Operator A uses 3 VNF instances connected to one of the hosting Service Provider's VNF instances and also having connectivity to Operator A's home network.

The figure does not show how each of the VNF instances have been deployed but indicates that the Orchestration interface provides a part specific to each entity and having the hosting service provider sitting in between to apply policies for each entity.

Page 30: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Software Defined Network

Page 31: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

VMs need VN• Many services run on a single flat LAN to

interconnecting VMs, NAS

• Geographically isolation can be solved with

• Layer 2 VPN,

• Layer 3 MPLS VPN

• How to manage servers in multi-tenant data center that need unique address

Page 32: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Virtual Network• Not only IP routing, in some case we need to

deliver packets using MAC address for VM Mobility.

• IP and MPLS can create overlay virtual networks

• Layer 3 VPN, Layer 2 VPN

• Manage devices using XML/Netconf, SNMP

• Very complex to manage network

Page 33: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Data Plane and Control Plane

Management Station

Command Line InterfaceXML/NetconfSNMPI2RS

Page 34: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Control Plane • Centralized control plane

• experimental SDN

• Semi centralized control plane

• modern SDN controllers

• Fully distributed control plane

• Internet, highly resilient

Page 35: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Controller Functions• Classical Controller Functions: ARP processing,

MAC address learning

• Forwarding table

• Routing Information Base: RIB keep loop-free network

• Forwarding Information Base: FIB

Page 36: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

SDN Concepts

• Directly programmable • Agile: dynamically adjust network-wide traffic

• Programmatically configured

• Open standards-based • Centralize control

control plane

data plane

Page 37: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Flow table entriesOpenFlow Flow Table

Match rule Action Stats

Switchport

VLANID

VLANpcp

MACsrc

MACdst

Ethtype

IPsrc

IPdst

IPToS

IPProt

L4sport

L4dport

1. Forward packet to zero or more ports 2. Encapsulate and forward to controller 3. Send to normal processing pipeline 4. Modify Fields 5. Any extensions you add!

Packet + byte counters

Page 38: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

OpenFlow

Switching

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

* 00:1f:.. * * * * * * * port6

Flow Switching

port3

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6

Firewall

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Forward

* * * * * * * * 22 drop

Page 39: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

Software Defined Storage

SDN for StorageSoftware Defined Networks

Storage Server

Servers

ALL SSDDisk Array

Web ClusterSDN Switches

M

DatacenterPolicy Controller

Software Defined Computing

VMVM VM VM VM VM

HypervisorAPIs

APIs

APIsAPIs

APIs

APIs

APIsAPIs APIs

APIs

Page 40: The Death of Network Engineer - uni.net.thuni.net.th/wunca_regis/wunca32_doc/21/012_TheDeathOfNetwork... · • providing training on new systems ... • Week2 - Numbers, Lists

สรุป• Virtualization รวมทุกสิ่งเข้าด้วยกันเป็นเนื้อเดียวโดยซอฟต์แวร์

• ผู้เชี่ยวชาญเครือข่ายแบบท่านๆ ต้องรู้เรื่องคนอื่นมากขึ้น เช่น Software Dev., Storage, Computing

• จากที่ Config iOS เขียน Perl คงต้องมาหัดเรียนโปรแกรมที่ซับซ้อนมากยิ่งขึ้น