ENVI-based OpenFlow GUIv.0.5

Sungho Shin, Namgon Kim, and Juwon ParkNetworked Media Lab. GIST, Korea

May 11, 2010

Contents

• Goals• Drag & Drop

• Flow Management

• Flow Monitoring

• Testbed Configuration

• Networking service UI

GOALS

3

NetOpen RATunneling-basedConnectivity

DeviceMonitoring

FlowMonitoring

FlowControl

QoS-aware Routing

Level 1NetFPGA-based Capsulator (point-to-point)

Flow path control over GUI (Button, Manually)

Level 2FlowVisor support

~05/31NetFPGA-based Capsulator (point-to-multipoint)

Report traffic delivery rate for each tunnel to OpenFlow controller

Display traffic rate of each flow for each OpenFlow switch

Flow path control over GUI (Drag & Drop)

Develop a NOX application service gathering available BW from OpenFlow switches

Lev.3

3-1 ~07/31

1) Turn on/off capsulator operation2) Dynamic tunnel configuration

Report traffic delivery rate for each port and slice

Dynamic topology generation by configuring capsulator

Implement BW-aware routing algorithm as a NOX application service

3-2 ~08/30 Port Scheduler

Visualization of multiple virtualized testbeds (FlowVisor)

Flow path control for each slice

Develop new application scenario

NetOpen + MediaX

07/01 ~

ENVI-based OpenFlow GUI

Level1-1 (~Feb.) Level1-2 Level2

Flow Control

Flow & Route selection using GUI

마우스와 버튼을 이용한 주어진 flow 에 대한 route 변경 ( 단일 플로우 상황 가정 )

다중 플로우 상황에서 GUI 상에서 마우스를 통해 플로우를 선택하고 , 선택된 플로우의 경로를 마우스 드래그 액션으로 결정

FlowSpace 별로 Level2의 기능 적용 확인

Route update

주어진 flow 에 대해 주어진 route 를 이용하도록 제어하는 NOX 응용 개발

주어진 flow 에 대해 가능한 모든 경로의 목록 제공기능 추가

FlowSpace 별로 Level2의 기능 적용 확인

Monitoring

Visualization ENVI 기반으로 Topology 및 Flow 가시화

사용자가 선택한 OF Switch 의 internal status 표시 & Level1의 가시화 결과에 network monitoring info. 표현

DataNOX 의 routing component 와 Flowdb를 통해 Topology(OpenFlow switches, end nodes, links) & Flow 정보 수집

OF Switch 의 internal status & Network monitoring info. (BW, delay)

FlowVisor 로부터FlowSpace 의 정보수집

Configurationssh 를 통한 원격지에서의 OF Controller, OF Switch 프로세스 실행과 end 에서의 플로우 생성을 위한 명령 실행

Tunneling configuration support

FlowVisor Configuration

Drag & Drop

• Level 1– End1 과 End2 사이의 Path 목록은 제공된다고

가정• Level 2

– End1 과 End2 사이의 Path 목록을 구하는 함수 제공

Topology 01

• Available Paths between End01 and End02– Path 1: A-C– Path 2: A-B-C

P1 P1

End01 End02

AC

B

Topology 01 - 내부로직• 기본 로직

– OpenFlow 마다 고유의 id (datapath id) 을 가지고 있음 .– 플로우를 OpenFlow 노드로 drag & drop & mouse hover 를 하였을 경우 id 를 비교하여

다른 플로우의 경로로 변경• Case1: Path 1 에서 Path2 로의 플로우 변경

– 조건 : A-C 사이의 플로우를 select 하여 OpenFlow 노드로 drag 하였을 경우• B 노드로 hover : B 노드의 dpid 와 비교

– if(gm.getHovered().toSting().equals(“ b 의 dpid) : 참이면 변경 메세지 실행

• Case2: Path 2 에서 Path1 로의 플로우 변경– 조건 : A-B 사이 , B-C 의 사이 플로우를 select 하여 OpenFlow 노드로 drag 하였을 경우

• A 노드 또는 C 노드로 hover : A 노드 또는 C 노드의 dpid 비교– else if(gm.getHovered().toString().equals(“a 의 dpid”)||

gm.getHovered().toString().equals(“c 의 dpid”)) : 참이면 변경 메세지 실행

• Case3: 나머지 조건의 경우– 잘못된 플로우의 변경 조작으로 간주하여 , System error 메세지 출력

Topology 02

• Available Paths between End01 and End02– Path 1: A-C-E– Path 2: A-B-C-E– Path 3: A-C-D-E– Path 4: A-B-C-D-E

P1P1

End01 End02

A

B

C

D

E

Question-Flow 를 Path1 에서 Path2 로 이동시키려 하는 경우 , 화면상에는 어떻게 표시되는가 ? (1) 인가 ? (2) 인가 ? 왜 그렇게 되는가 ?-즉 , 프로그램 내부적으로 가능한 경로의 목록은 제공되었다고 가정했을 때 그 중 어느 것을 선택할 것인가의 문제임

(1)

(2)

Topology 02 - 내부로직• 현재의 Drag/Drop 은 one hop 단위로 제공된다고 이해됨• Case1: Path 1 에서 Path2 로의 플로우 변경• 이 경우는 (1) 의 경우가 됩니다 . 조건은 즉 A-C 사이의 플로우를 select 하여 B 노드로 drag

하였을 경우 입니다 .

• Case2: Path 1 에서 Path3 로의 플로우 변경• 이 경우의 조건은 C-E 사이의 플로우를 select 하여 D 노드로 drag 하였을 경우 입니다 .

• Case3: Path 1 에서 Path4 로의 플로우 변경• 이 경우의 조건은 A-C 사이의 플로우를 select 하여 B 노드로 drag 하여 path2 로 변경후 , C-E

사이의 플로우를 select 하고 D 노드로 drag 하여 Path4 로 변경입니다 .

• 또는 C-E 사이의 플로우를 select 하고 D 노드로 drag 하여 , Path3 로 변경후 , A-C 사이의 플로우를 select 하여 B 노드로 drag 하여 Path4 로 변경합니다 .

• 두 번에 걸쳐서 진행해야 한다는 것으로 이해됨

• 각 Case 에서의 조건이외서 동작이 되지 않게 하는 겁니다 .– 잘못된 동작으로 간주하고 , 변경 메세지 전달을 하지 않으며 , system error 메세지 출력

Topology 02 - 구현• 이를 위해서는

– 각 OpenFlow id (OpenFlow switch id 로 수정 )

– 각 노드 사이에 형성된 flow id (OpenFlow switch 사이에 형성된 flow id 로 수정 )

– 내부적인 가능한 경로의 목록 작성 ( 이건 이미 가정에서 제공된다고 했음 )

• 현재 OpenFlow Switch id( 고정값 ) 만을 이용해서 Path 의 경로를 변경해 주는 방법을 진행하였습니다 .

– OpenFlow switch 라고 표현• 예를 들면

– Path1 에서 Path2 로의 변경은 ( 어떤 위치 ) 에 있는 플로우를 select 해서 B 노드로 drag 하였을 경우 변경– Path1 에서 Path3 으로의 변경은 ( 어떤 위치 ) 에 있는 플로우를 select 해서 D 노드로 drag 하였을 경우 변경– Question) 선택된 flow 의 id 는 알지 못하는가 ?

• 플로우의 id 를 적용하지 않은 이유는 플로우의 id 정보가 고정적인것이 아니라 , 플로우가 생길때마다 변경이 되기 때문입니다 . ( 즉 예를 들면 A-C 사이의 플로우의 id 가 아니라 , A-C 사이에 플로우가 생성될 때마다 id 가 변경이 됩니다 .)

• Question) 만약 flow 가 일정시간 이상 지속된다고 가정하면 , flow id 가 고정이라고 가정할 수 있나 ?

• 이 부분은 차후에 생각을 좀 더 해봐야 겠습니다 .

• 금일까지 OpenFlow id 를 이용해 변경하는 방법을 적용하였고 ,

• 각 OpenFlow id 로 drag 하였을 경우 3 의 내용을 적용하는 부분을 내일 진행할 예정입니다 .

Topology 03

• Available Paths between End01 and End02– Path 1: A-B-C-D– Path 2: A-E-F-H-D– Path 3: A-E-G-H-D

P1P1

End01 End02

A

B C

DE

Question-Flow 를 Path3 에서 Path2 로 이동시키려 하는 경우 , 화면상에는 (1) 에서 (2) 로 표현되는가 ?- 또 Path2 에서 Path1 으로 이동시키는 경우 화면상에 (2) 에서 (3) 으로 표현하는 것이 가능한가 ?-그리고 , 화면상에 보이는 것은 사용자의 drag 액션에 대한 결과이고 , 실제 토폴로지에 반영되는 것은 drop 액션의 결과인데 이를 구별하여 동작하도록 구현되었는가 ?

F

GH

(1)

(2)

(3)

Topology X

P1 P2 P1 P2

End01 End02

Google Map Example

• http://maps.google.com/maps?f=d&source=embed&saddr=Europa+Dr,+Chapel+Hill,+Orange,+North+Carolina+27514&daddr=35.924853,-79.035044+to:218+Conner+Dr,+Chapel+Hill,+NC+27514&hl=en&geocode=FfMgJAIdUgBK-ykXJRX4ucKsiTHuLtOE3TPLYw%3B%3BFZdFJAId0xtK-ymxQGObrcKsiTG9p3Hfi1e3XQ&mra=dpe&mrcr=0&mrsp=1&sz=15&via=1&sll=35.927425,-79.034&sspn=0.019495,0.038581&ie=UTF8&ll=35.927425,-79.034&spn=0.019495,0.038581

Daum Map Example

• http://local.daum.net/map/index.jsp?SP=RIS&sX=463590&sY=480672&eX=466301&eY=477891&map_type=TYPE_MAP&map_hybrid=true&sName=%B1%A4%C1%D6%B0%FA%C7%D0%B1%E2%BC%FA%BF%F8&eName=%B7%D4%B5%A5%B8%B6%C6%AE+%C3%B7%B4%DC%C1%A1

FLOW MANAGEMENT

16

Flow Management

• 각 스위치의 flow table entry 에는 동일한 정보가 들어가지만 , 각 스위치에서는 이를 다른 id로 관리한다

• Controller 나 GUI 입장에서 Flow 들을 manage 하기 위해 id 를 할당해야 한다

• 일단은 현재 GUI 에 이런 management 가 어떻게 이루어지고 있는지 파악해야 한다

17

Daum Map Example

Flow Monitoring

Levels of Flow Monitoring

Level Content

1.1

- 스위치 선택시 해당 스위치가 지닌 플로우의 목록을 보여주고 , 그 중 하나를 선택할 수 있도록 한다 - GUI 레벨에서 가능해야 함 , 스위치의 모니터링 결과가 GUI 에서 표현된다는 점에 차이가 있음 ( 스위치 수준의 모니터링은 충남대의 결과물을 이용할 수 있음 )

1.2.- 스위치의 정보 표시 ( 포트별 대역폭 사용량은 device monitoring)- 선택된 플로우의 대역폭 사용량을 출력함

2.1

- Ver. 1.1. 의 플로우 목록중 하나를 선택하면 , 다른 스위치들 내에서 동일한 플로우 entry 를 찾아 표현- 즉 , Flow 목록 중 하나를 선택하면 , 해당 플로우의 네트워크 경로가 표시되어야 함- 이 부분은 현재 화면에 보여지는 플로우가 실제로 우리가 manage 할 수 있는 수준의 것이냐는 것과 관련됨- 즉 , 홉단위의 플로우가 표현된 것이 마치 하나인 것처럼 보이는 것과 실제로 그것이 하나의 flow object 로 관리가 되는 것과는 차이가 있음

19

Wish List• 각 스위치의 flow 목록

– 각 스위치를 선택시 스위치의 정보와 함께 스위치를 통과하는 flow 목록을 표현• Flow Table 정보를 가져올 수 있는가 ?

– Flow Table 의 정보를 수집 방법• 1. 각 OpenFlow switch 의 ‘ ./dpctl dump-flows’ 를 통해 수집• 2. NOX 를 통한 방법

– 1 과 2 의 구체적인 방법 ??

• Flow 별 네트워크 특성– 대역폭 사용량 (bps)– Loss 나 delay 확인 가능한가 ?– Java 의 sigar 라이브러리를 활용하는 방법

• sigar 를 통해 cup, memory, tx,rx 의 정보 등을 수집할 수가 있습니다 .– sigar 의 어떤 목록이 있고 , 어떤 목록을 활용할 것인가 ?

• 토폴로지 전체의 flow 목록– 발생된 flow 의 목록을 표현

• End-to-End network monitoring– Available bandwidth ??

• End-to-End flow monitoring– Delay, loss ?? (End 를 이용한 제어 솔루션을 통해서 가능 , ping, iperf)

• End-to-End Network monitoring 은 충남대쪽의 정보를 GUI 에 어떤식으로 표현을 할 것인가 ?• End-to-End flow monitoring 은 생각을 좀 더 해봐야 할 것 같습니다 .

Testbed Configuration

Wish List

• 테스트베드내의 모든 머신에 대한– 원격접속 / 시동 / 재시동 / 종료 /– 프로세스시작 / 종료

• Controller• FlowVisor• OFSwitch• Endhost

• 스위치의 목록 선택을 통한 새로운 topology 구성– Flowvisor 이용

• Tunneling– 사용할 Tunneling solution 선택 및 설정

• 장치의 추가 / 제거– 새로운 장치를 추가 (host, netfpga, of switch,

controller)– SNAC 처럼 탭을 여러개 만들어서

• 한 탭에는 장치의 목록을 보여주고 ( 추가 / 제거도 여기에서 )

• 다른 탭에서는 장치들 사이의 연결관계를 보여줌• 해당 장치가 다른 장치와 어떻게 연결되어있는지의

정보는 controller 를 통해서 알 수 있음

23

손으로 GUI 의 모습을 그려보자

장치목록 tab

24

플로우 목록 tab

25

Physical network substrate tab & Virtual Network tab

• Physical network substrate tab

– 모든 switch 와 end host 가 어떻게 연결되어 있는지를 표현

– Flowvisor 와 Controller 도 표현됨

– 이 탭에서 switch 들을 선택하고 , 이들을 flowvisor 를 통해 controller 와 연결하여 virtual network 를 생성

• Virtual network tab

– Flowvisor 를 통해 구성된 가상의 네트워크를 표현하고 관리

26

Review

• Ngkim> testbed configuration ui 로서 필요한 기능들을 좀 더 구체적으로 적어 보았음– 현재 적어놓은 것처럼 바로 구현하려고 하기보다는

단위 기능별로 구현하고 , 추후에 통합하는 형태로 진행

• 단위 기능에서도 일단 command line, 그 후 gui• 구현할 기능 중 우선 순위를 결정할 필요가 있음

27

NETWORKING SERVICE UI

28

Networking Service UI

• NetOpen UI Software (Version 0.2)

– NetOpen RA 의 Software-defined (Programmable & Virtualized) Networking 서비스에 대한 가시화 ( 모니터링 결과 ) 및 제어를 위한 사용자 인터페이스

– (Version 0.1.1) Packet Routing Service 개발– (Version 0.1.2) Tunneling Service 개발– (Version 0.1.3) Packet Routing Service 와 Tunneling Serivce 의 연동

• 목표– 가장 먼저 packet routing service 를 개발하여 OF substrate 를 통해 연결된

end 사이의 연결성을 제공하고 ,

– 다음으로 tunneling service 를 개발하여 직접 연결되지 않은 OF substrate 사이의 연결을 제공하는 방법을 제공하며 ,

– 최종으로는 이 둘을 필요에 따라 수동으로 연동하여 확장된 네트워크의 연결성을 제공

29