3. Software Defined Network
● 인터넷 초기, 통신 오류를 해결하는 것이 급선무
● 개별 네트워크 장비에서 필요한 모든 기능을 구현하는 것이 용이
● 느린 네트워크 때문에 중앙 처리에 대한 부담
4. Software Defined Network
● 결론적으로 여러 문제점이 발생
1. 제조사에 대한 높은 dependency
2. 운영 자동화, 중앙 관리의 어려움
3. 효율, 비용 문제
4. 개별 처리로 인한 네트워크 복잡성 증가
개비스콘 짤 생성기 https://rajephon.github.io/gvsc/
5. Software Defined Network
● 소프트웨어 영역인 Control Plane
을 네트워크 기기로부터 분리
● 각 네트워크 노드들은 controller와
연동하기 위한 API만 가짐
● Controller가 가지는 API를 통해
다양한 application 제공 가능
6. Software Defined Network
● 네트워크 장비 제조사가 H/W (data
plane)부터 S/W(control plane)까지
black box 형태로 제공하는 것에서
● 제조사는 H/W만 만들고 나머지
기능들은 다른 업체 S/W 또는
오픈소스 S/W를 사용하는 것으로
● 무엇이 좋을까?
8. Software Defined Network
기존 네트워크 SDN
네트워크 관점 하드웨어 중심 소프트웨어 중심
구성 주도권 하드웨어 제공 벤더 사용자
기술 개방성 폐쇄적 구조 개방형 구조
연동 호환성 독자 프로토콜 표준 프로토콜
관리 효율성 비효율/고비용 운용 효율적/합리적 운용
신기술 수용 벤더의 필요에 따라 사용자 요구에 따라
시장 공정성 독과점 공정 경쟁
9. SDN Layers
● Software Defined == API enabled
1. Application layer
2. Control layer
3. Infrastructure layer
10. SDN Layers
● Infrastructure layer
● 다수의 실제 또는 가상 네트워크 장비들
● packet forwarding
● packet manipulation
● statistics gathering
11. SDN Layers
● Control layer
● SDN controller 가 위치한 layer
● 고성능 범용 서버에 controller를 설치,
빠른 네트워크 연산을 지원하게 함
● data plane resource management
● common services and libraries
● topology
● state abstraction
12. SDN Layers
● Application layer
● 사용자가 정의할 수 있는
다양한 네트워크 부가 기능을
구현하는 layer
● network services (FW, LB, Security)
● virtual network overlay
● traffic engineering
● application-aware packet computation
● 필요에 따라 추가
13. OpenFlow
● 최초의 Controller - Data Plane 인터페이스
● 흐름(flow) 정보를 제어하여 패킷의 전달 경로 및 방식을 결정
● OpenFlow를 사용하기 위해서는,
network device가 OpenFlow를 지원해야 함
(일반적으로는 펌웨어 형태)
15. OpenFlow
● OpenFlow를 지원하는 network device는 flow table을 가짐
● packet 처리시,
해당 packet에 대한 제어 정보를 flow table에 가지고 있다면 그대로 처리,
제어 정보가 존재하지 않으면
OpenFlow를 통해서 controller 에 제어 정보를 요청
17. SDN Controller
● Control plane 의 본체
● Topology Management, Path Management, Link Discovery,
Management + 네트워크 지능화
● 어떤 범위, 수준의 네트워크 지능화를 지원할 것인지가 관건
● 다양한 오픈소스 controller 들이 존재
18. SDN Controllers
Controller 주관
Beacon Stanford Univ.
Floodlight Big Switch Network
FlowER Travelping GmbH
Jaxon University of Tsukuba
Mul KulCloud
NodeFlow CISCO System
NOX ICSI
POX ICSI
Ryu NTT Communication
Trema NEC
19. SDN, 어디에 써먹을까?
● 데이터 센터에 흔하게 나타나는 East-West 트래픽에 대한 처리
● Flat Network: 네트워크 홉 최소화
● Fat Tree: 대규모 서버 Access 환경 및 최적 경로
● Fast Switching: 낮은 네트워크 대기 시간
● Simplicity: 구성, 운영, 관리 용이성
20. ● 최대 SDN based 데이터 센터 backbone network인 Google 의 G-Scale
● 각각의 최적 경로는 네트워크 사용 효율 관점에서는 최적이 아닐 수 있음
SDN, 어디에 써먹을까?
21. ● NTT 의 IaaS Platform 내의 network virtualization 을 SDN 으로 구성
● VLAN을 이용하는 것 대신, SDN/OpenFlow를 사용한 Overlay 방식을 사용
● 이를 바탕으로 NTT Communications Enterprise Cloud Data Center에 적용
SDN, 어디에 써먹을까?
22. NFV: Network Function Virtualization
● 기존 네트워크 서비스들은 특정 하드웨어에서
구현, 제품으로 제공 됨
● NFV에서는 기존 하드웨어 장비들을 가상화하고
소프트웨어 형태로 구현하여, 특정 하드웨어 대신
범용 서버에서 작동할 수 있도록 함
● 물리적인 자원 최소화, 효율성 증가, 시스템
복잡성 감소
23. NFV: Network Function Virtualization
● NFV가 반드시 SDN을 통해
구현되어야 하는 것은 아님
● 적용 범위나 성격 등 다른
점이 존재
● SDN과 상호보완적으로 동작
24. SDN / OpenFlow 동향
● OpenDaylight
● SDN / OpenFlow 를 지원하는
오픈소스 플랫폼
● 다양한 기업들이 참여
Arista Networks, Big Switch Networks, Brocade,
Cisco, Citrix, Ericsson, HP, IBM, Juniper Networks,
Microsoft, NEC, Nuage Networks, PLUMgrid,
Red Hat and VMware …