SDN과 OpenFlow 의 배경과 전망
1. IT 산업의 Trend
- 80년대 컴퓨팅, 2000년대 Network, 2010년대 클라우딩으로 산업의 중심이 이동
- 클라우드 서비스, 모바일 서비스, 스마트 TV, BIG Data, 사물인터넷 등 상이한 특성의 인터넷 서비스 증가는 서비스의 환경에 따라 동적으로 제어될 수 있는 유연한 구조의 요구 증대를 유발
- 반도체 기술의 발달 역시 Special Purpose HW 기반에서 고성능 General Purpose HW 기반에 SW로 차별화를 구현하는 방식
2. SDN 등장 배경
- Network 산업의 폐쇠성
- Cisco 장비에 Junior OS를 설치할 수 있는가?
- 이기종 벤더가 쉽게 통합 될 수 있는가? - 인프라의 강건성(Roubust)
인프라의 동작이 다양한 서비스와 환경에 따라 동적으로 제어(Programable)될 수 있는가?
- 망의 재구성을 위해 분산된 모든 노드의 회선을 운영자가 직접 수정 해주어야 함
- 현재 네트워크 장비는 각각이 여러 계층에 걸친 수많은 프로토콜(현재 10000 여개)을 지 원하여 동작하도록 하는 구조로 관리나 운영이 복잡하고 Human Error가 발생도 빈범함. 결과적으로 OPEX 상승의 주원인이 됨. - 결과적으로 사용자가 원하는 설정이나 제어를 자유롭게 하는 데에 한계가 노출. 네트워크 장비 업체에 의해 주어진 인터넷 환경에서 서비스를 제공했던 ISP 업자들의 이러한 제약으로부터 자유로워지고 싶은 새로운 패러다임을 요구
☞ SDN
3. SDN의 등장과 ONF
- SDN의 기술배경
- 전형적으로 낮은 성능의 CPU가 장착된 HW 스위치에서 네트워크 제어 기능(Control Plane)이 개발되고 실행될 수 있는 환경을 분리
- SDN은 라우터나 스위치 등의 기본 네트워크 장비에 관계없이 사용자가 통제 권한을 가지며, 별도의 소프트웨어 컨트롤러가 트래픽 흐름을 제어하는 사용자 중심의 네트워크를 의미
- 하나의 물리적 네트워크에 상이한 성격의 다수의 서비스가 가능 해지고, 관리의 중앙집중화가 이루어져 빠른 시간 내에 장애의 원인 규명 및 보수가 가능해짐
- 토폴로지 관리를 Controller에서 Virtual Machine 상에서 처리하기 때문에 NFV 가 가능
- ONF (Open Network Foundation) 설립
- 2011년 3월 22일- 비영리, 상호 이익을 바탕- 2명의 창립자인 UC 버클리 대학 교수인 Scott Shenker와 스탠포드 대학 교수인 Nick McKeown과 6개 회사 도이치 텔레콤, 페이스북, 구글 마이크로소프트, 버라이즌, 야후로 구성
- 현재 772개의 회원사를 보유, 국내는 ETRI, KT, 삼성, SKT가 가입
4. SDN과 Legacy 인터넷 장비의 비교
5. SBI & NBI
- SouthBound Interface Protocol
- 컨트롤러와 네트워크 장비간의 통신을 위한 프로토콜로 ONF가 주축이 된 OpenFlow가 사용됨
- 시스코는 시장을 고려 이전과 같은 패턴으로 자사만의 프로토콜인 OpFlex를 발표 (14/04) - NorthBound Interface Protocol
- REST Protocol, ...
☞ ONF는 설립 후 현재까지 제어평면과 전달 평면의 분리 여부와는 상관없이, SouthBound Interface 즉, 네트워크 장비를 프로그래밍할 수 있는 인터페이스에 초점을 맞추었고, 그 결과 2014년 현재 OpenFlow V1.4가 발표.
☞ 지금까지 발표된 시제품은 모두 OpenFlow V1.0을 지원하며, MPLS-TE를 (T-SDN) 일부 지원하기 위해서는 적어도 V1.4기반에서 구현되어야 함.
6. OpenFlow Switch의 구조
- OpenFlow Switch- 장비는 궁극적으로 Flow를 관리자의 요구에 맞게 처리하면 됨
- 기존의 복잡한 DB와 Management를 수행했던 장비는 Flow Table만을 관리
7. SDN 과도기
- Hybrid SDN
- 기존의 Legacy망에서 SDN망으로 이동은 점진적으로 이루어져야 함 --> 과도기
- 기 구현된 장비에 SDN SBI를 지원하기 위한 Secure Channel을 통한 OpenFlow를 탑재해서 SDN Controller에 반응하면서 기존의 네트워크 통신이 이루어짐
- 다양한 SouthBound Interface Protocol
- TL1, SNMP, NETCONF
- LegacyFlow
- 현재 이미 설치된 장비나 기 구현된 장비 또는 SDN을 지원하지 않은 CHIP이 대다수이다. 이러한 장비가 SDN망의 Controller와 연동 하기 위해서 OpenFlow 프로토콜을 SW로 구현하고 Flow 테이블을 서비스에 맞게 해석 미들웨어 API를 사용하여 정합하는 방식이 사용될 듯 하다.
- 과도기의 Controller는 OpenFlow 뿐만 아니라 SNMP, NETCONF 등 기존에 널리 쓰이는 프로토콜을 통해서 Flow 테이블을 전달 할 수 있도록 한다.
8. 고려사항
- 중앙집중식 컨트롤러
OpenFlow Switch에 주어진 트래픽과 일치하는 Flow 항목이 없는 경우, 해당 트래픽을 Controller에게 넘겨서 처리하기 때문에 수반되는 지연 (수십~수백ms) --> 공급업체들의 통상적인 설치에서는 엔드포인트가 컨트롤러에게 알려져 있기 때문에 플로우 테이블을 미리 완성해서 해결
- 컨트롤러 표준의 부재
- 현재 Controller 의 표준은 없다. 결국 각 업체들마다 자사 목표 시장의 필요사항을 가장 잘 충족시키는 컨트롤러를 제시
- ISP 마다 다른 컨트롤러를 사용할 경우?
9. SDN 전망
- 도입시 기대효과
- 현재 40~50%인 네트워크 자원의 활용도를 100%로 끌어 올릴 수 있다. (구글)
- EAST-WEST 트래픽을 혁신적으로 줄일 수 있다.
- SDN을 도입한 ISP는 최대 50%까지 비용 절감을 할 수 있다.
(ex, NTT컴즈는 본사와 해외 데이타센터간 네트워크 연결하기 위해 5일 가량이 소요됐지만 SDN도입 후 수 분 내에 완료할 수 있었다) - ASIC으로 구현되는 OpenFlow 빅스위치사의 CEO는 Broadcom의 Trident II 칩에 기대를 걸고 있다.
- 저가의 HW웨어에 고가의 SW 플랫폼으로의 전환
OpenFlow를 지원하는 Chip과 SW가 없는 White Box 장비 (ex BareMetal WhiteBox)
--> 보편화 될 경우 CISCO사가 가장 큰 타격이 될 수 있다. (OpenFlow에 반대하고 자사만의 프로토콜을 선택한 이유?)
- 창조적 서비스
제공되는 HW 를 이용해서 프로그래밍을 할 수 있기 때문에 보다 다양한 서비스가 가능하다.
(안드로이드 플랫폼에 개발되는 다양한 앱)- 결국 CISCO로 대변되는 속칭 대마(?)들은 Controller 시장에서 맞붙게 되고, 창조를 기치로 수많은 애플리케이션(트래픽 엔지니어링, 네트워크 감시, 보안통제 등) 개발 업체들이 등장할 것
- SDN의 세상은 무섭게 다가오고 있다. (ONF 관계자, 4~6년 후)
노키아의 사례를 관과하지 말자.
[참고자료]
구글링 여기저기에서...
[덧붙히는 글]
SDN이 화두입니다. 여기를 가도 저기를 가도 SDN 얘기가 심심찮게 들립니다. 그래서 도대체 SDN이 뭐하는 놈인가.. 구글링(?)을 했고 그 결과를 가볍게 정리한 결과물입니다.
긴 시간 리서치를 한 사항은 아니므로 깊이 있게 다룬 내용은 아니고 탄생 배경과 전망에 이르는 간단한 소개 자료에 가깝습니다. 개인적으로 T-SDN쪽에 관심이 있는데, 이 분야는 정착하는 데 적잖은 복병이 숨어 있는 것 같습니다. 다시 말해 SDN의 세상은 가시적이지만 T-SDN은 다소 회의적인 것이 CISCO사를 비롯한 대마(?)들의 독자적인 행보 때문입니다. 뭐 어찌됐든 지금 네트워크 산업의 폐쇄적이고 더딘 발전은 인정해야겠지요. 그 변화의 마중물이 SDN이 될지는 더 지켜봐야겠습니다.
'IT Tech > Network' 카테고리의 다른 글
Example applications supported by a DCN (0) | 2014.07.07 |
---|---|
IEEE 802.3ah EFM OAM Tutorial and etc docus (2) | 2013.07.15 |
In-Band(IB) vs Out-Of-Band(OB) Management for MPLS-TP (0) | 2011.11.27 |
ETH-CSF (CSF) - Ethernet OAM, Y.1731 정리 노트 (0) | 2011.11.19 |
ETH-DM (1DM, DMM, DMR) - Ethernet OAM, Y.1731 정리 노트 (0) | 2011.11.19 |
ETH-LM (CCM, LMM, LMR) - Ethernet OAM (Y.1731) 정리 노트 (0) | 2011.11.19 |
ETH-AIS (AIS) - Ethernet OAM (Y.1731) 정리 노트 (0) | 2011.11.19 |
ETH-LT (LTM, LTR) - Ethernet OAM (Y.1731) 정리 노트 (0) | 2011.11.19 |
ETH-LB (LBM, LBR) - Ethernet OAM (Y.1731) 정리 노트 (0) | 2011.11.19 |
ETH-CC (CCM), ETH-RDI - Ethernet OAM (Y.1731) 정리 노트 (3) | 2011.11.19 |