Mô hình cộng tác hỗ trợ định tuyến trên mạng nhiều vùng dựa trên openflow

K tài t>p trung nghiên c,u m!t h&$ng ti"p c>n khác v$i nh2ng % xut hi1n t#i %ó là cho phép nhiu controller phân b; trên các vùng m#ng khác nhau trong m#ng OpenFlow cùng nhau %iu hành các

!"I H#C QU$C GIA THÀNH PH$ H% CHÍ MINH

TR&'NG !"I H#C BÁCH KHOA

PHAN XUÂN THI(N

MÔ HÌNH C)NG TÁC H* TR+ !,NH TUY-N TRÊN M"NG NHI.U VÙNG D/A TRÊN OPENFLOW

Chuyên nghành: Khoa H!c Máy Tính

Mã s": 60.48.01

LU0N V1N TH"C S2

TP H# Chí Minh, Tháng 12 n$m 2012

CÔNG TRÌNH !"#C HOÀN THÀNH T$I TR"%NG !$I H&C BÁCH KHOA – !HQG - TPHCM

Cán b' h()ng d*n khoa h+c: … PGS TS Tho,i Nam …

Thành ph2n H'i 6;ng 6ánh giá lu1n v4n th,c s5 g;m:

(Ghi rõ h+, tên, h+c hàm, h+c v- c<a H'i 6;ng ch0m b8o v9 lu1n v4n th,c s5)

1 … TS Tr2n V3 Bình, Ch< t-ch h'i 6;ng ………

2 … TS Tr2n V4n Hoài, Th( k/ h'i 6;ng ………

3 … TS Ph,m Tr2n V3, =y viên Ph8n bi9n 1 …………

4 … TS Ph,m V4n H1u, =y viên Ph8n bi9n 2 … ………

5 … PGS TS Tho,i Nam, =y viên h'i 6;ng ………

Xác nh1n c<a Ch< t-ch H'i 6;ng 6ánh giá LV và Tr(>ng Khoa qu8n l/ chuyên nghành sau khi lu1n v4n 6ã 6(7c s?a ch.a (n@u có)

CH! T"CH H#I $%NG TR&'NG KHOA ………

!"I H#C QU$C GIA TP.HCM

Mô hình c*ng tác h2 tr3 45nh tuy6n trên m-ng nhi7u vùng d,a trên OpenFlow

II NHI)M V VÀ N&I DUNG:

• Nghiên c+u v, ki)n trúc và giao th+c m-ng OpenFlow

• Nghiên c+u , xu/t gi0i pháp c0i ti)n 1 nâng ph-m vi qu0n l2 cho m-ng dùng OpenFlow qua vi3c cho phép 4ng th5i nhi,u controller trong m-ng

• !, xu/t mô hình và giao th+c cho phép nhi,u controller cùng ho-t 6ng trong m-ng OpenFlow, kh0 n'ng c6ng tác v7i nhau trong vi3c i,u hành m-ng c8a chúng, h9 tr: cho vi3c ;nh tuy)n t*t trên toàn th1 m-ng

• Hi3n th<c, th= nghi3m h3 th*ng và ánh giá gi0i pháp

III NGÀY GIAO NHI)M V : (Ghi theo trong Q! giao , tài) …

IV NGÀY HOÀN THÀNH NHI)M V.: (Ghi theo trong Q! giao , tài) …

V CÁN B& H!8NG D9N (Ghi rõ h%c hàm, h%c v;, h%, tên): PGS TS Tho-i Nam

! "!

L!I C"M #N

Tôi xin g!i l"i c#m $n sâu s%c &'n PGS TS Tho(i Nam &ã t)n tình h*+ng d,n, giúp &- tôi th.c hi/n &0 tài nghiên c1u này Tôi c2ng xin c#m $n GS Pierre Kuonen &ã t)n tình h*+ng d,n tôi trong quá trình th.c t)p 3 Fribourg, Th4y S5

Sau cùng, tôi xin g!i l"i c#m $n chân thành &'n gia &ình và b(n bè &ã luôn bên c(nh &6ng viên và giúp &- tôi

! ""!

TÓM T!T LU"N V#N

OpenFlow là m!t ki"n trúc m#ng c$i ti"n trong %ó tách bi&t h& %i'u khi(n m#ng và h& truy'n d) li&u, cho phép các nhà nghiên kh$ n*ng l+p trình c, s- h# t.ng m#ng %( %i'u khi(n các thi"t b/ trong m#ng ph0c v0 cho các quá trình th1 nghi&m c2a h3 Tuy nhiên, ki"n trúc c2a OpenFlow l& thu!c hoàn toàn vào vi&c s1 d0ng m!t h& %i'u khi(n t+p trung g3i là OpenFlow controller ch#y trên m!t máy tính %,n %( %i'u hành ho#t %!ng c2a t4t c$ các thi"t b/ trong m#ng V5i nh)ng m#ng

có s6 l78ng thi"t b/ l5n, t.n su4t g1i yêu c.u t9 các thi"t b/ nhi'u thì vi&c s1 d0ng ch: m!t controller %( x1 l; có th( s< không %áp =ng n>i ho?c %áp =ng không hi&u qu$ s6 l78ng yêu c.u l5n g1i t9 các thi"t b/ do b/ gi5i h#n b-i kh$ n*ng x1 l; c2a m!t máy tính H,n n)a n"u môi tr7@ng m#ng có ph#m vi phân b6 r!ng thì th@i gian

%áp =ng cho các yêu c.u t9 các thi"t b/ - xa b/ $nh h7-ng do %! trA b*ng thông c2a k"t n6i gi)a controller và các thi"t b/ trong m#ng Vì v+y vi&c cho phép nhi'u controller ho#t %!ng %Bng th@i trong m#ng là m!t gi$i pháp h)u hi&u cho v4n %' này HC tr8 hi&n t#i c2a OpenFlow cho phép tri(n khai m#ng OpenFlow nhi'u controller trong %ó mCi controller qu$n l; m!t vùng m#ng con trong m#ng Tuy nhiên hi&n nay ch7a có c, ch" nào %( các controller c!ng tác v5i nhau trong vi&c

%i'u khi(n các thi"t b/ trong m#ng H& qu$ là các controller không th( %/nh tuy"n các gói tin liên vùng trong m#ng m!t cách hi&u qu$ Tr75c yêu c.u nh7 v+y, lu+n v*n nghiên c=u và %' xu4t m!t mô hình cho phép các controller - các vùng m#ng con trong m#ng c!ng tác v5i nhau trong vi&c %i'u hành m#ng, trên c, s- %ó xây dDng gi$i pháp nâng cao hi&u qu$ %/nh tuy"n trên các vùng m#ng OpenFlow

! """!

ABSTRACT

OpenFlow is an innovative network architecture which decouples control plane and data plane, allowing researchers the ability to program their networks, control the behaviour of network switches for their experiments However, current OpenFlow architecture relies completely on the use of a centralized controller to manage all switches connecting to it in the network For networks with large number of switches, depending on a controller to manage all switches in the network becomes unfeasible Thus allowing distributed multiple controllers in managing OpenFlow network is an appropriate solution for OpenFlow scalability Current OpenFlow support allows deploying multi-controllers networks in which each controller is responsible for operating each smaller domain in the network, however there is currently no mechanism for these controllers to cooperate with the each other As a result, the controllers cannot effectively process cross-domain packets This paper proposes building a collaborative model for multi-domains OpenFlow networks that allows different network domains to collaborate with each other in an efficient way In addition, a routing solution is proposed based on the model to achieve higher network performance

! "#!

L!I CAM "OAN

Tôi xin cam !oan r"ng b#n lu$n v%n t&t nghi'p này là k(t qu# nghiên c)u th*c s* do chính tôi th*c hi'n Ngo+i tr, các k(t qu# tham kh#o t, các công trình khác nh- !ã ghi rõ trong lu$n v%n, các công vi'c nêu trong lu$n v%n là trung th*c và ch-a t,ng !-.c công b& trong b/t k0 công trình nào khác ho1c !-.c n2p !3 l/y m2t b"ng c/p 4 m2t tr-5ng nào khác

! "!

M!C L!C

L!I C"M #N ……… i

TÓM T$T LU%N V&N ……… ii

ABSTRACT ………iii

L!I CAM 'OAN ……… iv

M(C L(C ……… v

DANH M(C HÌNH ………ix

CH)#NG 1 GI*I THI+U ', TÀI ……… 1

1.1 '-t v.n /0 ……… 1

1.2 Gi1i thi2u /0 tài ……… 3

1.2.1 Tên /0 tài ……… 3

1.2.2 Gi1i h3n c4a /0 tài ……… 3

1.2.3 M5c tiêu /0 tài ……… 5

1.2.4 6 ngh7a khoa h8c và th9c ti:n ……… 5

1.3 Quy trình th9c hi2n ……… 7

CH)#NG 2 C# S; L6 THUY<T ……… 12

2.1 T=ng quan v0 OpenFlow ……… 12

2.2 OpenFlow switch ……….14

2.2.1 Flow-Table ……… 14

2.2.2 Các lo3i Action chính trong OpenFlow switch ……… 15

2.2.3 Kênh giao ti>p b?o m@t OpenFlow ……… 16

2.2.4 Giao thAc OpenFlow ……… 16

2.3 NhBng lCi ích c4a m3ng d9a trên OpenFlow ……… 17

! "#!

CH!"NG 3 NH#NG CÔNG TRÌNH NGHIÊN C$U LIÊN QUAN ………… 20

3.1 H% &i'u khi(n phân b) cho m*ng OpenFlow (HyperFlow) ……… 21

3.2 Ki+n trúc m, r-ng cho h% &i'u khi(n m*ng OpenFlow n-i b- (ASIC) … 23

3.3 .' xu/t s0 d1ng nhi'u controller cho m*ng OpenFlow ……… 25

CH!"NG 4 MÔ HÌNH VÀ GI2I PHÁP 3NH TUY4N 5 XU6T ………… 29

4.1 Mô hình chia s7 thông tin gi8a các vùng m*ng OpenFlow ……… 30

4.2 Gi9i pháp &:nh tuy+n &' xu/t ……… 32

4.2.1 Các thành ph;n chính trong mô hình RMOF ……… 33

4.2.2 Quy trình x0 l< trong mô hình RMOF ……… 39

4.2.3 Ph=>ng pháp dò tìm các liên k+t liên vùng ……… 42

4.2.4 Ph=>ng pháp tính chi phí &:nh tuy+n gi8a các switch liên vùng trong m-t vùng m*ng ……… 44

4.2.5 Ph=>ng pháp tính &=?ng &:nh tuy+n toàn c1c ……… 44

CH!"NG 5 GIAO TH$C TRAO @I THÔNG TIN TRONG MÔ HÌNH .5 XU6T ……… 48

5.1 Các nhóm thông &i%p chính trong giao thAc RMOF ……… 49

5.2 Header cBa thông &i%p trong giao thAc RMOF ……… 50

5.3 Thông &i%p &)i xAng ……… 51

5.3.1 Thông &i%p RMOF_HANDSHAKE ……… 51

5.3.2 Thông &i%p RMOF_ECHO_REQUEST ……… 52

5.3.3 Thông &i%p RMOF_ECHO_REPLY ……… 52

5.4 Thông &i%p trao &Ci thông tin &Dc tính cBa controller ……… 52

5.4.1 Thông &i%p RMOF_CONTROLLER_FEATURES_REQUEST 52

5.4.2 Thông &i%p RMOF_CONTROLLER_FEATURES_REPLY …… 53

! "##!

5.5 Thông !i"p c#p nh#t thông tin topology toàn c$c ……….… 53

5.5.1 Thông !i"p RMOF_CDLINK_ADD ……… 54

5.5.2 Thông !i"p RMOF_CDLINK_REMOVE ……… 55

5.6 Thông !i"p !%nh tuy&n ……… 55

5.6.1 Thông !i"p RMOF_ROUTE_INS_REQUEST ……… 55

5.6.2 Thông !i"p RMOF_ROUTE_INS ……… 56

5.7 Thông !i"p !%nh v% host !ích ……… 58

5.7.1 Thông !i"p RMOF_ADDR_AUTHENTICATION_REQUEST … 58 5.7.2 Thông !i"p RMOF_ADDR_AUTHENTICATION_REPLY ….… 58 CH'(NG 6 HI)N TH*C HÓA MÔ HÌNH VÀ GI+I PHÁP ,-NH TUY.N ,/ XU0T ……….61

6.1 L1a ch2n n3n t4ng controller: Beacon ……… 61

6.2 C4i ti&n n3n t4ng Beacon controller ……… 62

6.3 Hi"n th1c hóa thành ph5n RMOF collaborator ……… 66

6.4 Các quy trình x6 l7 trong h" th8ng ……… 68

CH'(NG 7 ,ÁNH GIÁ ……… 71

7.1 Tri9n khai m:ng OpenFlow và h" !i3u khi9n !;<c hi"n th1c ……….72

7.2 Các b;=c ti&n hành th6 nghi"m ……… 73

7.3 K&t qu4 th6 nghi"m ……… 74

7.4 ,ánh giá ……… 76

CH'(NG 8 K.T LU>N ……… 78

8.1 T?ng k&t ……… 78

8.2 H;=ng phát tri9n ……… 80

TÀI LI)U THAM KH+O ……… 81

! "###!

PH! L!C: CH"#NG TRÌNH TRI$N KHAI M%NG OPENFLOW

GI& L'P TRONG TH( NGHI)M …… ……… 84 BÀI BÁO KHOA H*C ……… 86

! "#!

DANH M!C HÌNH

Hình 1.1 Quy trình th!c hi"n lu#n v$n ……….8

Hình 2.1 Ki%n trúc c&a m't m(ng OpenFlow ……….13

Hình 2.2 Các tr)*ng thông tin trong m't Flow-Entry ……… 14

Hình 2.3 Các thông tin trong tr)*ng Match-Fields c&a m't Flow-Entry ……… 15

Hình 3.1 Minh h+a mô hình HyperFlow ……… 22

Hình 3.2 Ki%n trúc ASIC ……….……… 23

Hình 4.1 Thi%t k% t,ng quan c&a mô hình RMOF ……… 31

Hình 4.2 Các thành ph-n chính trong mô hình RMOF ……… 34

Hình 4.3 Minh h+a m't liên k%t liên vùng ……… 35

Hình 4.4 Các tr)*ng thông tin trong b.ng các liên k%t liên vùng ……… 35

Hình 4.5 Các tr)*ng thông tin trong b.ng chi phí /0nh tuy%n )1c l)2ng ……… 36

Hình 4.6 Khung nhìn topology toàn c3c quan sát /)2c t4 RMOF collaborator … 37 Hình 4.7 Các tr)*ng thông tin trong b.ng ch5 d6n /0nh tuy%n ……… 38

Hình 4.8 Quy trình x7 l8 c&a controller trong mô hình RMOF……… 40

Hình 4.9 Quy trình x7 l8 tìm /)*ng /i toàn c3c trong mô hình RMOF ………… 42

Hình 4.10 Minh h+a vi"c tính /)*ng /0nh tuy%n toàn c3c 9 RMOF collaborator 46

Hình 6.1 Các thành ph-n chính c&a n:n t.ng Beacon controller ……… 61

Hình 6.2 Các thành ph-n chính c&a n:n t.ng Beacon sau khi /)2c c.i ti%n …… 66

Hình 6.3 Các mô-/un ph-n m:m chính trong RMOF collaborator ……… 68

Hình 6.4 Quá trình x7 l8 thi%t l#p k%t n;i trong h" th;ng /)2c hi"n th!c …… 69

Hình 6.5 Quá trình x7 l8 gói tin liên vùng trong h" th;ng /)2c hi"n th!c …… 70

! "!

Hình 7.1 Topology c!a m"ng OpenFlow th# nghi$m ……… 72 Hình 7.2 Thông l%&ng gi'a hai host trong k(ch b)n * các l+n ,o khác nhau … 75

Nh& chúng %ã bi"t m#ng máy tính ngày nay %óng vai trò r)t quan tr.ng trong

%-i s;ng con ng&-i Nó tr+ thành m!t c= s+ h# t8ng không th4 thi"u %&'c trong các c= quan, tr&-ng h.c, b1nh vi1n, vi1n nghiên c,u, … và là thành ph8n n(n t5ng cho s9 phát tri4n kinh t" và khoa h.c k0 thu>t c/a m.i qu;c gia trên th" gi$i Tuy nhiên c= s+ h# t8ng m#ng h8u nh& b7 l1 thu!c vào các thi"t b7 m#ng v>t l6 (switch, router,…) %&'c cung c)p b+i các nhà s5n xu)t thi"t b7 m#ng, mà trong %ó các giao th,c %(u %&'c cài %3t s?n và n(n t5ng c@ng nh& hi1n th9c c/a chúng b7 che gi)u vì l6 do c#nh tranh th7 tr&-ng H=n n2a các nhà cung c)p thi"t b7 %(u có xu h&$ng phát tri4n các giao th,c và n(n t5ng riêng, %i(u này dAn %"n s9 không nh)t quán trong các chính sách (policy) c/a các thi"t b7 m#ng, gây ra nhi(u khó kh*n cho vi1c nghiên c,u c5i ti"n trên m#ng máy tính Ngoài ra, vi1c c)u hình cho các thi"t b7 m#ng hi1n nay ch/ y"u ph5i thao tác tr9c ti"p trên các thi"t b7, %i(u này làm m)t nhi(u th-i gian và công s,c và %ây là m!t tr+ ng#i không nhB cho vi1c tri4n khai các thay %Ci, c5i ti"n lên h1 th;ng m#ng cho mDc %ích thE nghi1m các nghiên c,u v( m#ng máy tính

Tr&$c tình hình %ó và v$i mDc tiêu xây d9ng m!t n(n t5ng m+ v$i giao th,c hoàn ch<nh, th;ng nh)t cho h1 th;ng m#ng máy tính, OpenFlow %ã hình thành và phát tri4n Ki"n trúc OpenFlow cho phép các thi"t b7 m#ng v>t l6 %&'c qu5n l6, %i(u

! #!

khi4n b+i m!t h1 %i(u khi4n tách bi1t %&'c t>p trung hóa Nh- %ó, vi1c c)u hình thi"t b7, %i(u khi4n vi1c xE l6, hành vi c/a các thi"t b7 m#ng %&'c th9c hi1n hoàn toàn và tr9c ti"p bFng l>p trình, bFng ph8n m(m, theo th-i gian th9c, d9a trên n(n t5ng OpenFlow controller %&'c xây d9ng V$i nh2ng &u %i4m c/a mình, ki"n trúc m#ng OpenFlow %&'c kG v.ng là ki"n trúc t&=ng lai c/a m#ng máy tính, %ã và

%ang thu hút m!t c!ng %Hng l$n gHm nhi(u nhà khoa h.c tI nhi(u n&$c trên th" gi$i c@ng nh& các công ty l$n (%i4n hình nh& NEC, IBM, Google, SwissCom,…) tham gia nghiên c,u phát tri4n, và %ã %&'c hJ tr' c5 ph8n c,ng (OpenFlow switch, router, access point), ph8n m(m (switch 5o) c@ng nh& công cD hJ tr' tri4n khai m#ng gi5 l>p (Mininet)

Tuy nhiên, bên c#nh nh2ng l'i ích mang l#i so v$i ki"n trúc m#ng hi1n hành, ki"n trúc OpenFlow hi1n t#i ch< cho phép duy nh)t m!t controller ho#t %!ng trên m!t máy tính %=n qu5n l6 toàn b! các thi"t b7 trong m#ng Ki(u này khi"n cho m#ng OpenFlow b7 gi$i h#n v( kh5 n*ng %áp ,ng các request tI các thi"t b7 và s; l&'ng thi"t b7 có th4 hJ tr' trong m#ng do b7 l1 thu!c vào m!t controller trong khi kh5 n*ng xE l6 c/a m!t máy tính là có h#n Hi1n vAn ch&a có nhi(u %( xu)t gi5i pháp hJ tr' nhi(u controller trong m#ng OpenFlow Các %( xu)t này ho3c ch&a %i vào gi5i quy"t v)n %( kh5 n*ng m+ r!ng c/a OpenFlow, ho3c %( xu)t mô hình chung nh&ng ch&a có gi5i pháp cD th4 cho các v)n %( %3t ra trên mô hình %3t bi1t là v)n %( %7nh tuy"n, ho3c %( xu)t nâng cao kh5 n*ng %áp ,ng request nh&ng ch< áp dDng cho m#ng n!i b! mà không phù h'p v$i m#ng có ph#m vi phân b; r!ng,… Nh2ng %( xu)t này nhìn chung %(u ch&a tri1t %4 và mJi %( xu)t %(u tHn t#i nh2ng nh&'c %i4m riêng

V$i mDc tiêu nghiên c,u gi5i pháp m+ r!ng cho OpenFlow hJ tr' nhi(u controller trong m#ng, %( tài %( xu)t m!t h&$ng ti"p c>n khác, %ó là cho phép nhi(u controller %&'c phân b; trên các vùng m#ng con trong m#ng OpenFlow cùng nhau ho#t %!ng %4 %i(u hành các thi"t b7 trong m#ng V$i ki"n trúc t>p trung hóa vào m!t controller nh& hi1n t#i thì tr+ ng#i l$n nh)t trong cách ti"p c>n này %ó là v)n %(

%7nh tuy"n gi2a các vùng m#ng B+i vì v$i ki"n trúc này mJi controller ch< có th4

! $!

nLm thông tin và qu5n l6 %&'c các switch ho3c router k"t n;i tr9c ti"p v$i nó trong vùng m#ng mà không có b)t kG thông tin nào v( các thi"t b7 + bên ngoài ph#m vi này H1 qu5 là các controller không có kh5 n*ng tìm %&'c %&-ng %7nh tuy"n h'p l6 cho các gói tin liên vùng trong m#ng và ch< %4 cho switch t9 xE l6 theo c= ch" lan truy(n flooding Kây hi4n nhiên không ph5i là m!t c= ch" %7nh tuy"n hi1u qu5, vì v>y nhi1m vD %3t ra cho %( tài là %( xu)t và xây d9ng gi5i pháp gi5i quy"t v)n %(

%7nh tuy"n liên vùng này Tr&$c h"t, %( tài %( xu)t mô hình cho phép các controller qu5n l6 các vùng m#ng kh5 n*ng c!ng tác v$i nhau, chia sM các thông tin %7nh tuy"n, trên c= s+ %ó xây d9ng ph&=ng pháp %7nh tuy"n hi1u qu5 gi2a các vùng m#ng OpenFlow Gi5i pháp %( xu)t th9c s9 c5i ti"n %&'c kh5 n*ng %7nh tuy"n gi2a các vùng trong m#ng nh- c= ch" cung c)p các ch< dAn %7nh tuy"n hi1u qu5 cho các controller qu5n l6 các vùng m#ng

1.2 Gi+i thi,u )* tài

1.2.1 Tên !" tài

Mô hình c!ng tác hJ tr' %7nh tuy"n trên m#ng nhi(u vùng d9a trên OpenFlow

(A collaborative model for routing in multi-domains OpenFlow networks)

1.2.2 Gi#i h$n c%a !" tài

K( tài nghiên c,u v)n %( m+ r!ng ki"n trúc c/a OpenFlow %4 cho phép nhi(u controller cùng ho#t %!ng trong m#ng nhFm t*ng kh5 n*ng m+ r!ng và kh5 n*ng xE l6 c/a h1 %i(u khi4n trong m#ng Kây v;n là m!t v)n %( khó vì ki"n trúc m#ng, giao th,c và t)t c5 các n(n t5ng controller hi1n nay ch< cho phép m!t controller trong m#ng và m.i thông tin %i(u khi4n %(u %&'c t>p trung hóa vào controller này K( tài t>p trung nghiên c,u m!t h&$ng ti"p c>n khác v$i nh2ng %( xu)t hi1n t#i %ó là cho phép nhi(u controller phân b; trên các vùng m#ng khác nhau trong m#ng OpenFlow cùng nhau %i(u hành các OpenFlow switch và router trong m#ng H&$ng ti"p c>n này có &u %i4m là cho phép nhi(u controller cùng nhau ho#t

! %!

%!ng trong m#ng qua %ó có th4 nâng cao kh5 n*ng %áp ,ng các request KHng th-i vi1c phân b; các controller giúp nó có kh5 n*ng %&'c ,ng dDng cho môi tr&-ng m#ng có ph#m vi r!ng Ngoài ra h&$ng ti"p c>n này giúp t>n dDng %&'c nh2ng &u

%i4m v;n có c/a ki"n trúc OpenFlow qua vi1c %4 các controller tr9c ti"p qu5n l6 các thi"t b7 trong vùng m#ng c/a chúng Trong h&$ng ti"p c>n này thì v)n %( c)p bách %3t ra cho %( tài %ó là nghiên c,u gi5i pháp %7nh tuy"n gi2a các vùng trong m#ng OpenFlow Trong gi$i h#n v( th-i gian c/a m!t lu>n v*n t;t nghi1p, %( tài ch< t>p trung gi5i quy"t v)n %( trên, %( xu)t và %ánh giá gi5i pháp %7nh tuy"n gi2a các vùng trong m#ng OpenFlow N!i dung cD th4 v( gi5i pháp này sN %&'c trình bày trong ch&=ng 4 và ch&=ng 5

N!i dung c/a quy4n lu>n v*n %&'c trình bày nh& sau:

! Ch&=ng 1: gi$i thi1u v( %( tài, gi$i h#n và mDc tiêu c/a %( tài Trong ch&=ng này c@ng trình bày k" ho#ch th9c hi1n lu>n v*n

! Ch&=ng 2: trình bày các c= s+ l6 thuy"t liên quan %"n %( tài nh& ki"n trúc OpenFlow, OpenFlow switch, nh2ng v)n %( tHn t#i trong m#ng máy tính hi1n t#i và &u %i4m c/a OpenFlow

! Ch&=ng 3: trình bày các nghiên c,u có liên quan bao gHm các ki"n trúc m#ng OpenFlow nhi(u controller, các nghiên c,u v( ki"n trúc hJ tr' nhi(u controller cho m#ng OpenFlow Nh2ng nghiên c,u này chính là c= s+ dAn

%"n cách ti"p c>n l9a ch.n trong %( tài và bài toán %7nh tuy"n %3t ra c8n gi5i quy"t

! Ch&=ng 4: trình bày mô hình chia sM thông tin %( xu)t %4 cho phép nhi(u controller phân b; trên các vùng m#ng khác nhau và c!ng tác v$i nhau qu5n l6 hi1u qu5 các switch và router trong m#ng OpenFlow (%3t tên là mô hình RMOF), bài toán %7nh tuy"n gi2a các vùng m#ng %3t ra và gi5i pháp %7nh tuy"n xây d9ng d9a trên mô hình %( xu)t

! Ch&=ng 5: trình bày thi"t k" c/a giao th,c %&'c sE dDng trong mô hình %( xu)t dành cho vi1c chia sM thông tin %7nh tuy"n c/a các controller (%3t tên là giao th,c RMOF) Kây là giao th,c %&'c thi"t k" d9a trên vi1c nghiên c,u

! &!

sâu v( giao th,c OpenFlow và tham kh5o m!t s; giao th,c %7nh tuy"n khác c/a m#ng máy tính Kây có th4 %&'c xem nh& m!t s9 m+ r!ng cho giao th,c OpenFlow qua vi1c thIa k" cách thi"t k" Header c/a thông %i1p, bC sung thêm các lo#i thông %i1p dùng cho vi1c trao %Ci thông tin trong mô hình

! Ch&=ng 6: vi"t v( hi1n th9c c/a mô hình và gi5i pháp %7nh tuy"n %ã %( xu)t, trong %ó trình bày nh2ng c5i ti"n %( ngh7 cho flatform c/a OpenFlow controller %4 chúng có th4 chia sM thông tin v( topology, ti"p nh>n và xE l6 thông tin v( %7nh tuy"n nh>n %&'c %4 %7nh tuy"n các gói tin liên vùng

! Ch&=ng 7: các %ánh giá nhFm ch,ng minh gi5i pháp %7nh tuy"n %&'c %( ngh7

là hi1u qu5

! Ch&=ng 8: tCng k"t nh2ng vi1c làm %&'c, ch&a làm %&'c c@ng nh& h&$ng phát tri4n c/a %( tài

! PhD lDc: bài báo khoa h.c k"t qu5 c/a nghiên c,u này

1.2.3 M&c tiêu !" tài

K( tài này có mDc tiêu nghiên c,u sâu v( m#ng OpenFlow + nhi(u khía c#nh khác nhau bao gHm ki"n trúc, giao th,c và c5 hi1n th9c c/a n(n t5ng OpenFlow controller, c@ng nh& nh2ng nghiên c,u d9a trên OpenFlow, trong %ó t>p trung v( v)n %( m+ r!ng ki"n trúc OpenFlow %4 cho phép nhi(u controller cùng ho#t %!ng trong m#ng nhFm nâng cao tính m+ r!ng c/a OpenFlow và kh5 n*ng xE l6 c/a h1

%i(u khi4n trong m#ng Trên c= s+ %ó nghiên c,u phát tri4n cho m!t h&$ng ti"p c>n t>n dDng %&'c nh2ng &u %i4m v;n có c/a ki"n trúc OpenFlow và có kh5 n*ng ,ng dDng cho môi tr&-ng m#ng có ph#m vi r!ng mà m!t controller khó có th4 %áp ,ng hi1u qu5, %ó là h&$ng ti"p c>n cho phép phân b; nhi(u controller trên các vùng m#ng con trong m#ng OpenFlow K( tài %( xu)t mô hình và gi5i pháp %4 gi5i quy"t bài toán c)p thi"t %3t ra trên h&$ng ti"p c>n này %ó là v)n %( %7nh tuy"n gi2a các vùng m#ng OpenFlow

1.2.4 ' ngh(a khoa h)c và th*c ti+n

" - ngh.a khoa h/c

! '!

K( tài phát tri4n m!t h&$ng ti"p c>n m$i cho v)n %( m+ r!ng c/a m#ng OpenFlow so v$i nh2ng cách ti"p c>n hi1n nay Mô hình RMOF %&'c %( xu)t cho phép k"t h'p nhi(u controller phân b; cùng ho#t %!ng trong m#ng OpenFlow thay

vì ch< cho phép m!t controller nh& ki"n trúc OpenFlow hi1n nay, qua %ó nâng cao kh5 n*ng %áp ,ng và kh5 n*ng m+ r!ng c/a h1 %i(u khi4n trong m#ng OpenFlow Th>t v>y, ki"n trúc OpenFlow t>p trung toàn b! các xE l6 %i(u khi4n m#ng vào controller, do %ó controller này ph5i xE l6 và %áp ,ng liên tDc các request tI các thi"t b7 (switch, router) %4 %i(u khi4n các luHng giao thông trong m#ng Do kh5 n*ng xE l6 c/a m!t máy tính là h2u h#n nên m!t controller ch< có th4 hJ tr' qu5n l6 m!t s; l&'ng thi"t b7 nh)t %7nh V$i vi1c k"t h'p nhi(u controller cùng ho#t %!ng m!t cách c!ng tác trong m#ng OpenFlow mô hình RMOF làm t*ng %&'c s; l&'ng thi"t b7 có th4 hJ tr' trong m#ng lên nhi(u l8n H=n n2a, gi5i pháp %7nh tuy"n hoàn ch<nh %&'c %( xu)t th9c s9 c5i ti"n %&'c kh5 n*ng %7nh tuy"n gi2a các vùng m#ng trong mô hình, khi"n cho vi1c %7nh tuy"n gi2a các vùng m#ng %&'c th9c hi1n m!t cách hi1u qu5 theo nh2ng %&-ng %7nh tuy"n %&'c tính toán m!t cách h'p l6

Mô hình RMOF v$i nhân t; chính là c= ch" chia sM thông tin gi2a các m#ng OpenFlow có th4 %&'c ,ng dDng làm n(n t5ng c= s+ %4 %( xu)t gi5i pháp cho các bài toán chung trên nhi(u m#ng OpenFlow có liên k"t mà vi1c gi5i quy"t chúng %òi hBi s9 c!ng tác tI t)t c5 các m#ng này ChOng h#n nh& v)n %( cân bFng t5i, v)n %( c5nh báo t)n công tI ch;i d7ch vD phân tán (DDoS),… trên m!t nhóm các m#ng OpenFlow

" - ngh.a th0c ti1n

Mô hình cùng v$i gi5i pháp %7nh tuy"n %&'c %( xu)t qua vi1c hJ tr' phân b; nhi(u controller trong m#ng, nâng cao kh5 n*ng %áp ,ng và kh5 n*ng m+ r!ng cho h1 %i(u khi4n trong m#ng OpenFlow, có th4 %&'c ,ng dDng cho vi1c tri4n khai m#ng OpenFlow có s; l&'ng thi"t b7 l$n ho3c môi tr&-ng m#ng %&'c phân b; trên ph#m vi r!ng mà m!t controller có th4 sN không %áp ,ng %&'c ho3c %áp ,ng không hi1u qu5

! (!

Hi1n t#i OpenFlow %ã %&'c tri4n khai + các tr&-ng %#i h.c l$n và m!t s; trung tâm nghiên c,u trên th" gi$i cho mDc %ích nghiên c,u, thE nghi1m Trong t&=ng lai khi OpenFlow phát tri4n m#nh và %&'c phC bi"n r!ng rãi thì nhu c8u tri4n khai OpenFlow trên các môi tr&-ng m#ng l$n h=n sN tr+ nên c)p thi"t Khi %ó m!t gi5i pháp cho phép nhi(u controller %&'c phân b; cùng song song ho#t %!ng và c!ng tác v$i nhau %4 %i(u hành c= s+ h# t8ng m#ng nh& %( tài %( xu)t sN là m!t gi5i pháp ti(m n*ng %4 ,ng dDng và tri4n khai trong th9c t"

Ngoài ra, gi5i pháp %7nh tuy"n %&'c %( xu)t trong %( tài ngoài kh5 n*ng áp dDng cho m!t m#ng OpenFlow nhi(u vùng còn có th4 %&'c áp dDng %4 nâng cao hi1u qu5 %7nh tuy"n gi2a các m#ng OpenFlow có liên k"t m#ng v$i nhau (có %&-ng liên k"t m#ng tr9c ti"p gi2a chúng), b+i vì các vùng m#ng này v( b5n ch)t c@ng chính là các m#ng OpenFlow v$i m!t controller qu5n l6 các switch k"t n;i %"n nó

1.3 Quy trình th0c hi,n

K( tài lu>n v*n này %&'c nghiên c,u trong hai h.c kG IV và V c/a quá trình h.c th#c s: theo ph&=ng th,c nghiên c,u, bao gHm 28 tu8n Th-i gian nghiên c,u cho %( tài này %&'c chia thành hai giai %o#n chính và %&'c bi4u diPn trong bi4u %H sau:

! )!

Hình 1.1: Quy trình th0c hi,n lu2n v3n

Chi ti"t c/a các công vi1c trong tIng giai %o#n nh& sau:

" Giai !o$n 1 (14 tu,n):

Kây là giai %o#n tìm hi4u và nghiên c,u các ki"n th,c n(n t5ng v( OpenFlow + t)t c5 các khía c#nh bao gHm ki"n trúc, giao th,c, và nh2ng nghiên c,u trên OpenFlow %ã %&'c %( xu)t TI %ó %&a ra %ánh giá v( nh2ng &u %i4m và kh5 n*ng ,ng dDng c/a OpenFlow cho các v)n %( v( m#ng máy tính hi1n nay, nh2ng v)n %(

%ã %&'c gi5i quy"t và nh2ng m3t h#n ch" ch&a gi5i quy"t %&'c c/a OpenFlow Trên c= s+ %ó xác %7nh v)n %( mà %( tài sN t>p trung nghiên c,u, %( xu)t h&$ng ti"p c>n, gi$i h#n v)n %( cD th4 c8n gi5i quy"t trên cách ti"p c>n này và %( ngh7 ra gi5i pháp cho v)n %( Giai %o#n này gHm các công vi1c cD th4 nh& sau:

! 1.1 Nghiên c,u tCng quan v( OpenFlow (tu8n 1-4): tìm hi4u các ki"n th,c v( m#ng OpenFlow bao gHm ki"n trúc c/a OpenFlow, OpenFlow switch, cách controller xE l6 các gói tin và %i(u hành các luHng giao thông trong m#ng OpenFlow, nghiên c,u %3c t5 c/a giao th,c OpenFlow

! 1.2 Tìm hi4u các nghiên c,u trên OpenFlow (tu8n 5-6): tìm hi4u các nghiên c,u d9a trên n(n t5ng OpenFlow %ã %&'c %( xu)t hi1n nay Các

! *!

nghiên c,u này có th4 %&'c phân làm hai nhóm, %ó là nh2ng nghiên c,u phát tri4n nhFm hoàn thi1n thêm cho OpenFlow và nh2ng nghiên c,u v>n dDng n(n t5ng c/a OpenFlow %4 gi5i quy"t m!t s; v)n %( c/a m#ng máy tính nh& cân bFng t5i, b5o m>t ch;ng t)n công tI ch;i d7ch vD,… Vi1c tìm hi4u nh2ng nghiên c,u này nhFm bC sung cho nh2ng ki"n th,c %ã tìm hi4u %&'c v( OpenFlow %4 tI %ó có %&'c %ánh giá tCng th4 và toàn di1n h=n v( OpenFlow, nh2ng v)n %( %ã gi5i quy"t %&'c và ch&a gi5i quy"t %&'c trên n(n t5ng này

! 1.3 Nghiên c,u v( v)n %( m+ r!ng ki"n trúc OpenFlow %4 cho phép nhi(u controller %Hng th-i ho#t %!ng trong m#ng kh5 n*ng m+ r!ng (scalability) c/a ki"n trúc OpenFlow (tu8n 7-8): d9a trên %ánh giá v( vi1c ki"n trúc OpenFlow ch< cho phép m!t controller %i(u hành các thi"t b7 và

%5m nh>n t)t c5 các xE l6 trong m#ng có th4 5nh h&+ng %"n tính m+ r!ng, h#n ch" v( s; l&'ng thi"t b7 có th4 hJ tr' và kh5 n*ng %áp ,ng c/a controller khi s; l&'ng request l$n, %( tài %i vào nghiên c,u v)n %( này Tìm hi4u các cách ti"p c>n, gi5i pháp %ã %&'c %( xu)t v( v)n %( cho phép nhi(u controller trong m#ng OpenFlow và %ánh giá nh&'c %i4m c/a chúng

! 1.4 L9a ch.n h&$ng ti"p c>n và %ánh giá tính kh5 thi (tu8n 9): %&a ra h&$ng ti"p c>n cho phép nhi(u controller cùng ho#t %!ng trong m#ng OpenFlow, phân nhóm các thi"t b7 trong m#ng theo vùng %4 các controller qu5n l6 Kánh giá nh2ng &u %i4m, h#n ch", tìm hi4u m,c %! hJ tr' hi1n t#i c/a OpenFlow %4 %ánh giá tính kh5 thi c/a nó

! 1.5 Xác %7nh bài toán %7nh tuy"n c8n gi5i quy"t (tu8n 10): xác %7nh v)n

%( then ch;t c8n gi5i quy"t trong h&$ng ti"p c>n này %ó là v)n %( %7nh tuy"n gi2a các vùng trong m#ng Hi1n t#i OpenFlow hJ tr' tri4n khai m#ng nhi(u vùng v$i nhi(u controller qu5n l6, tuy nhiên vi1c %7nh tuy"n gi2a các vùng ch&a %&'c hJ tr' Các controller hi1n t#i ch< sE dDng c= ch" flooding %4 %7nh tuy"n các gói tin liên vùng trong m#ng Bài toán %3t

ra là ph5i nghiên c,u gi5i pháp cho v)n %( %7nh tuy"n này

! "+!

! 1.6 K( xu)t mô hình chia sM thông tin gi2a các vùng m#ng (tu8n 11-12):

tI vi1c xác %7nh nguyên nhân c/a v)n %( %7nh tuy"n trên %ó là do các controller ch< nLm %&'c thông tin c/a các thi"t b7 m#ng trong vùng qu5n l6 c/a nó, các thi"t b7 m#ng + trong các vùng khác bên ngoài ph#m vi c/a

nó thì h8u nh& controller không có thông tin, và s9 thi"u thông tin này khi"n controller không th4 tìm %&'c %&-ng %7nh tuy"n h'p l6 cho các gói tin liên vùng, %( tài %( xu)t mô hình cho phép các controller chia sM v( vùng m#ng do chúng qu5n l6 %4 tI %ó xây d9ng nên gi5i pháp %7nh tuy"n gi2a các vùng trong m#ng

! 1.7 Nghiên c,u và %( xu)t gi5i pháp %7nh tuy"n (tu8n 13-14): nghiên c,u

và %&a ra %( xu)t ban %8u cho gi5i pháp %7nh tuy"n gi2a các vùng trong m#ng d9a trên mô hình chia sM thông tin %ã %( xu)t

" Giai !o$n 2 (14 tu,n):

Trong giai %o#n này, tôi t>p trung nghiên c,u hoàn thi1n gi5i pháp %7nh tuy"n %ã %( xu)t trong giai %o#n 1, %( xu)t giao th,c RMOF cho vi1c trao %Ci thông tin trong mô hình, ti"n hành nghiên c,u sâu vào n(n t5ng OpenFlow controller và hi1n th9c c/a nó, ti"n hành hi1n th9c mô hình và gi5i pháp %ã %( xu)t, tri4n khai h1 th;ng %ã hi1n th9c và thE nghi1m %4 %ánh giá hi1u qu5 c/a gi5i pháp %7nh tuy"n Giai %o#n này gHm các công vi1c cD th4 sau:

! 2.1 Hoàn thi1n gi5i pháp %7nh tuy"n (tu8n 15-16): nghiên c,u hoàn thi1n gi5i pháp %7nh tuy"n %ã %( xu)t + tu8n 13-14 c/a giai %o#n 1

! 2.2 K( xu)t giao th,c cho vi1c trao %Ci thông tin gi2a collaborator và các controller (tu8n 17-18): nghiên c,u và %( xu)t ra giao th,c sE dDng cho vi1c trao %Ci các thông tin v( topology m#ng và thông tin %7nh tuy"n gi2a thành ph8n collaborator và các controller trong mô hình

! 2.3 Nghiên c,u n(n t5ng OpenFlow controller (tu8n 19): tìm hi4u các n(n t5ng OpenFlow controller hi1n nay, so sánh các &u nh&'c %i4m và %! hi1u qu5 gi2a các n(n t5ng này, l9a ch.n n(n t5ng cho vi1c hi1n th9c sN ti"n hành, %i vào nghiên c,u sâu hi1n th9c c@ng nh& mã nguHn bên d&$i

%i1p %7nh tuy"n; xây d9ng các gói ph8n m(m bC sung %4 th9c hi1n %7nh tuy"n các gói tin liên vùng trong mô hình

! 2.5 Tri4n khai h1 th;ng và %ánh giá gi5i pháp %7nh tuy"n (tu8n 25): ti"n hành tri4n khai h1 th;ng %ã hi1n th9c và thE nghi1m %ánh giá k"t qu5 c/a gi5i pháp

! 2.6 Vi"t bài báo khoa h.c (tu8n 19-24): tCng h'p các k"t qu5 nghiên c,u v( mô hình và gi5i pháp %7nh tuy"n %( xu)t %4 vi"t bài báo khoa h.c

! 2.7 Vi"t báo cáo lu>n v*n (tu8n 17-28): hoàn thành báo cáo lu>n v*n và chuQn b7 b5o v1

! "#!

CH!"NG 2 C" S4 L- THUY5T

2.1 T6ng quan v* OpenFlow

Trong ph8n này sN trình bày tCng quan v( OpenFlow [1,7,9], là %;i t&'ng mà

%( tài nghiên c,u M!t m#ng OpenFlow bao gHm h1 %i(u khi4n (Control Plane) và h1 truy(n d2 li1u (Data Plane) H1 truy(n d2 li1u bao gHm các OpenFlow switch ch7u trách nhi1m tr9c ti"p truy(n %i các gói tin trong m#ng theo tIng nhóm có cùng chung m!t s; %3c tính g.i là Flow H1 %i(u khi4n là m!t controller + xa ch7u trách nhi1m qu5n l6 các OpenFlow switch và sE dDng m!t t>p l1nh chuQn %4 %i(u hành các luHng giao thông trong m#ng H1 %i(u khi4n này %óng vai trò nh& m!t “h1 %i(u hành m#ng” %5m trách t)t c5 các xE l6 liên quan %"n vi1c %i(u hành m#ng M.i công vi1c %i(u khi4n %i(u %&'c t>p trung v( controller này và các switch ch< %óng vai trò truy(n d2 li1u mà không %5m trách b)t kG xE l6 nào cho phép các gói tin

%&'c truy(n %i v$i t;c %! t;i &u h=n

MJi OpenFlow switch ch,a m!t ho3c nhi(u b5ng Flow-Table làm nhi1m vD tra c,u và truy(n %i các gói tin, và m!t kênh giao ti"p %&'c b5o m>t (Secure Channel) k"t n;i switch %"n m!t controller + xa Kênh giao ti"p này %&'c controller

sE dDng %4 %i(u hành t)t c5 các switch trong m#ng thông qua m!t giao th,c chuQn

là giao th,c OpenFlow MJi b5ng Flow Table ch,a các mDc g.i là các Flow-Entry

%&'c sE dDng nh& các lu>t %4 xE l6 các gói tin so trùng %&'c Controller có th4 thêm, c>p nh>t ho3c h/y các Flow-Entry trong Flow-Table và %ây là cách mà nó

%i(u hành các luHng giao thông trong m#ng MJi Flow-Entry gHm 6 tr&-ng thông tin %&'c g.i tên l8n l&'t là Match-Fields, Priority, Counters, Instructions, Timeouts

và Cookie Trong %ó các tr&-ng quan tr.ng nh)t là Match-Fields %4 %7nh ngh:a Flow, Instructions cho switch bi"t c8n xE l6 nh& th" nào %;i v$i các gói tin so trùng

%&'c, và Counters %4 dùng cho mDc %ích thông kê m!t s; thông tin nh& s; l&'ng gói tin, s; byte,… %&'c xE l6 b+i Flow này (hình 2.1)

! "$!

Hình 2.1: Ki7n trúc c8a m9t m:ng OpenFlow

Khi m!t OpenFlow switch nh>n %&'c m!t gói tin, nó sN tra c,u trong b5ng Flow-Table %4 tìm Flow-Entry có tr&-ng Match-Fields so trùng %&'c v$i tr&-ng t&=ng ,ng trên gói tin N"u tìm th)y m!t Flow-Entry nh& v>y, switch sN th9c thi các l1nh %&'c %7nh ngh:a trong Flow-Entry này %4 xE l6 gói tin và c>p nh>t các Counters Trong tr&-ng h'p không tìm th)y, switch sN %óng gói gói tin %ó trong m!t thông %i1p g.i là Packet-In và gEi %"n controller Controller khi nh>n %&'c thông %i1p này có th4 gEi thông %i1p tr5 l-i %4 thêm m!t Flow-Entry m$i vào b5ng Flow-Table c/a switch %4 switch có th4 c*n c, vào %ó xE l6 gói tin, ho3c controller ch< %=n gi5n tr9c ti"p h/y gói tin nh>n %&'c Kây chính là c= ch" cho phép controller qu5n l6 các OpenFlow switch và %i(u hành các luHng giao thông trong m#ng OpenFlow

Hi1n nay ki"n trúc OpenFlow %ã %&'c ch)p nh>n r!ng rãi b+i c!ng %Hng khoa h.c trên khLp th" gi$i và %ã %&'c s9 %8u t& nghiên c,u phát tri4n và hJ tr' c/a nhi(u tr&-ng %#i h.c l$n (nh& Stanford University, University of Washington, MIT, Priceton University, …) và h=n 50 doanh nghi1p l$n trên th" gi$i (nh&: IBM, Juniper, Cisco, VMWare, Microsoft, Google, Facebook,…) OpenFlow %ã %&'c hJ tr' c5 ph8n c,ng (OpenFlow switch), ph8n m(m (các OpenFlow switch 5o) và c5

Flow Entry n 5-&2

! "%!

công cD gi5 l>p m#ng OpenFlow phDc vD cho mDc %ích nghiên c,u nh& Mininet [16]

2.2 OpenFlow switch

M!t OpenFlow switch bao gHm 3 thành ph8n (hình 2.1):

! M!t ho3c nhi(u b5ng Flow-Table v$i các l1nh g.i là Action t&=ng ,ng trong các Flow-Entry c/a b5ng %4 cho switch bi"t c8n ph5i xE l6 m!t gói tin so trùng %&'c nh& th" nào

! M!t kênh giao ti"p b5o m>t (Secure Channel) k"t n;i các switch v$i m!t controller + xa, cho phép các gói tin và các l1nh %&'c trao %Ci gi2a controller và các switch sE dDng m!t giao th,c chuQn là giao th,c OpenFlow

! Giao th,c OpenFlow cung c)p m!t ph&=ng th,c m+ và tiêu chuQn cho controller giao ti"p v$i các OpenFlow switch trong m#ng SE dDng giao th,c này, controller có th4 thêm, c>p nh>t, và h/y các Flow-Entry trong switch m!t cách ch/ %!ng b+i ng&-i qu5n tr7 ho3c t9 %!ng bFng l>p trình các ph8n m(m trên n(n t5ng c/a controller

2.2.1 Flow-Table

MJi Flow-Table trong OpenFlow switch gHm các Flow-Entry MJi Entry ch&a thông tin mà switch c*n c, vào %ó %4 xE l6 gói tin, bao gHm 6 tr&-ng thông tin có tên g.i l8n l&'t là: Match-Fields, Priority, Counters, Instructions, Timeouts và Cookie R ngh:a c/a các tr&-ng thông tin này nh& sau (hình 2.2):

Fow-Hình 2.2: Các tr;<ng thông tin trong m9t Flow-Entry [9]

! Tr&-ng Match-Fields %7nh ngh:a Flow (trong m#ng OpenFlow các gói tin

%&'c l&u thông theo nhóm có cùng m!t s; %3c %i4m nh)t %7nh g.i là Flow, mJi Flow %&'c %7nh ngh:a b+i m!t Flow-Entry t&=ng ,ng) và %&'c

sE dDng %4 ti"n hành vi1c so trùng v$i các gói tin %"n K7nh d#ng c/a các

Table 1: Main components of a flow entry in a flow table

• match fields: to match against packets These consist of the ingress port and packet headers, and

optionally metadata specified by a previous table

• priority: matching precedence of the flow entry

• counters: to update for matching packets

• instructions to modify the action set or pipeline processing

• timeouts: maximum amount of time or idle time before flow is expired by the switch

• cookie: opaque data value chosen by the controller May be used by the controller to filter flow

statistics, flow modification and flow deletion, not used when processing packets

A flow table entry is identified by its match fields and priority: the match fields and priority takentogether identify a unique flow entry in the flow table The flow entry that wildcards all fields (all fieldsomitted) and has priority equal 0 is called the table-miss flow entry (see 5.4)

Packet In

Start at table 0

Match in table n?

Update counters Execute instructions:

• update action set

• update packet/match set fields

• update metadata

Table n?

Goto-Execute action set

Yes

Yes

miss flow entry exists?

Table-Drop packet No

Yes

Figure 3: Flowchart detailing packet flow through an OpenFlow switch

On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure 3 The switchstarts by performing a table lookup in the first flow table, and based on pipeline processing, may performtable lookups in other flow tables (see 5.1)

! Tr&-ng Counters th;ng kê các thông tin nh& s; l&'ng gói tin, s; byte

%&'c xE l6 b+i Flow-Entry, th-i gian tI khi gói tin cu;i cùng %&'c xE l6 b+i Flow-Entry (%4 giúp h/y các Flow-Entry không còn ho#t %!ng trong switch)

! Tr&-ng Instructions %&'c sE dDng %4 %7nh ngh:a t>p l1nh xE l6 c/a Entry, t>p l1nh này sN cho switch bi"t ph5i xE l6 gói tin so trùng %&'c nh&

Flow-th" nào

! Tr&-ng Timeouts %7nh ngh:a th-i gian t;i %a ho3c th-i gian nhàn rJi t;i

%a tr&$c khi Flow h"t hi1u l9c trong switch

! Tr&-ng Cookie là giá tr7 d2 li1u trong su;t %&'c ch.n b+i controller, %&'c controller sE dDng %4 l.c các giá tr7 th;ng kê c/a Flow, ch<nh sEa Flow ho3c ch.n Flow Tr&-ng này không %&'c sE dDng trong vi1c xE l6 gói tin

Hình 2.3: Các thông tin trong tr;<ng Match-Fields c8a m9t Flow-Entry [8]

MJi OpenFlow %&'c %7nh ngh:a m!t nhi(u l1nh xE l6 g.i là Action, các l1nh này sN %&'c switch áp dDng %4 xE l6 khi có m!t gói tin %"n switch V( c= b5n có lo#i 3 Action chính là:

! Action 1: Truy(n %i gói tin c/a Flow %"n m!t ho3c nhi(u cCng cho tr&$c

Action này cho phép các gói tin %&'c %7nh tuy"n trên m#ng OpenFlow

! Action 2: Kóng gói và truy(n %i gói tin c/a Flow t$i controller Gói tin sN

%&'c %&a vào Secure Channel, + %ây nó %&'c %óng gói và gEi %"n controller Action này th&-ng %&'c sE dDng cho gói tin %8u tiên trong m!t

This document describes the requirements of an OpenFlow Switch We recommend that you read the latest version of the OpenFlow whitepaper before reading this specification The whitepaper is available on the Open Networking Foundation website (https://www.opennetworking.org/standards/open-flow) This specification covers the components and the basic functions of the switch, and the OpenFlow protocol to manage an OpenFlow switch from a remote controller.

Controller

Flow Table

Flow Table

Secure Channel

Figure 1: Main components of an OpenFlow switch.

An OpenFlow Switch consists of one or more flow tables and a group table, which perform packet lookups and forwarding, and an OpenFlow channel to an external controller (Figure 1) The switch communicates

with the controller and the controller manages the switch via the OpenFlow protocol.

Using the OpenFlow protocol, the controller can add, update, and delete flow entries in flow tables,

both reactively (in response to packets) and proactively Each flow table in the switch contains a set of flow

entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching

packets (see 5.2).

Matching starts at the first flow table and may continue to additional flow tables (see 5.1) Flow entries match packets in priority order, with the first matching entry in each table being used (see 5.3) If a matching entry is found, the instructions associated with the specific flow entry are executed If no match

is found in a flow table, the outcome depends on configuration of the table-miss flow entry: for example, the packet may be forwarded to the controller over the OpenFlow channel, dropped, or may continue to the next flow table (see 5.4).

Instructions associated with each flow entry either contain actions or modify pipeline processing (see 5.9) Actions included in instructions describe packet forwarding, packet modification and group table

Match Fields Priority Counters Instructions Timeouts Cookie

Table 1: Main components of a flow entry in a flow table

• match fields: to match against packets These consist of the ingress port and packet headers, and

optionally metadata specified by a previous table

• priority: matching precedence of the flow entry

• counters: to update for matching packets

• instructions to modify the action set or pipeline processing

• timeouts: maximum amount of time or idle time before flow is expired by the switch

• cookie: opaque data value chosen by the controller May be used by the controller to filter flow

statistics, flow modification and flow deletion, not used when processing packets

A flow table entry is identified by its match fields and priority: the match fields and priority takentogether identify a unique flow entry in the flow table The flow entry that wildcards all fields (all fieldsomitted) and has priority equal 0 is called the table-miss flow entry (see 5.4)

5.3 Matching

Packet In

Start at table 0

Match in table n?

Update counters Execute instructions:

• update action set

• update packet/match set fields

• update metadata

Table n?

Goto-Execute action set

Yes

Yes

miss flow entry exists?

Table-Drop packet

No

Yes

Figure 3: Flowchart detailing packet flow through an OpenFlow switch

On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure 3 The switchstarts by performing a table lookup in the first flow table, and based on pipeline processing, may performtable lookups in other flow tables (see 5.1)

12 !2012 The Open Networking Foundationc

to be sent between a controller and the switch using (3) The

OpenFlow Protocol, which provides an open and standard

way for a controller to communicate with a switch By

speci-fying a standard interface (the OpenFlow Protocol) through

which entries in the Flow Table can be defined externally,

the OpenFlow Switch avoids the need for researchers to

pro-gram the switch

It is useful to categorize switches into dedicated OpenFlow

switches that do not support normal Layer 2 and Layer 3

processing, and OpenFlow-enabled general purpose

com-mercial Ethernet switches and routers, to which the

Open-Flow Protocol and interfaces have been added as a new

fea-ture

Dedicated OpenFlow switches A dedicated OpenFlow

Switch is a dumb datapath element that forwards packets

between ports, as defined by a remote control process

Fig-ure 1 shows an example of an OpenFlow Switch

In this context, flows are broadly defined, and are limited

only by the capabilities of the particular implementation of

the Flow Table For example, a flow could be a TCP

con-nection, or all packets from a particular MAC address or

IP address, or all packets with the same VLAN tag, or all

packets from the same switch port For experiments

involv-ing non-IPv4 packets, a flow could be defined as all packets

matching a specific (but non-standard) header

Each flow-entry has a simple action associated with it;

the three basic ones (that all dedicated OpenFlow switches

must support) are:

1 Forward this flow’s packets to a given port (or ports)

This allows packets to be routed through the network

In most switches this is expected to take place at

line-rate

2 Encapsulate and forward this flow’s packets to a

con-troller Packet is delivered to Secure Channel, where

it is encapsulated and sent to a controller Typically

used for the first packet in a new flow, so a controller

can decide if the flow should be added to the Flow

Table Or in some experiments, it could be used to

forward all packets to a controller for processing

3 Drop this flow’s packets Can be used for security, to

curb denial of service attacks, or to reduce spurious

broadcast discovery traffic from end-hosts

An entry in the Flow-Table has three fields: (1) A packet

header that defines the flow, (2) The action, which defines

how the packets should be processed, and (3) Statistics,

which keep track of the number of packets and bytes for

each flow, and the time since the last packet matched the

flow (to help with the removal of inactive flows)

In the first generation “Type 0” switches, the flow header

is a 10-tuple shown in Table 1 A TCP flow could be

spec-ified by all ten fields, whereas an IP flow might not include

the transport ports in its definition Each header field can

be a wildcard to allow for aggregation of flows, such as flows

in which only the VLAN ID is defined would apply to all

traffic on a particular VLAN

The detailed requirements of an OpenFlow Switch are

de-fined by the OpenFlow Switch Specification [6]

OpenFlow-enabled switches Some commercial

switches, routers and access points will be enhanced with

Port ID SA DA Type SA DA Proto Src Dst

Table 1: The header fields matched in a “Type 0”

OpenFlow switch

the OpenFlow feature by adding the Flow Table, SecureChannel and OpenFlow Protocol (we list some examples inSection 5) Typically, the Flow Table will re-use existinghardware, such as a TCAM; the Secure Channel and Proto-col will be ported to run on the switch’s operating system

Figure 2 shows a network of OpenFlow-enabled commercialswitches and access points In this example, all the FlowTables are managed by the same controller; the OpenFlowProtocol allows a switch to be controlled by two or morecontrollers for increased performance or robustness

Our goal is to enable experiments to take place in an isting production network alongside regular traffic and ap-plications Therefore, to win the confidence of network ad-ministrators, OpenFlow-enabled switches must isolate ex-perimental traffic (processed by the Flow Table) from pro-duction traffic that is to be processed by the normal Layer 2and Layer 3 pipeline of the switch There are two ways toachieve this separation One is to add a fourth action:

ex-4 Forward this flow’s packets through the switch’s mal processing pipeline

nor-The other is to define separate sets of VLANs for mental and production traffic Both approaches allow nor-mal production traffic that isn’t part of an experiment to beprocessed in the usual way by the switch All OpenFlow-enabled switches are required to support one approach orthe other; some will support both

experi-Additional features If a switch supports the header mats and the four basic actions mentioned above (and de-tailed in the OpenFlow Switch Specification), then we call it

for-a “Type 0” switch We expect thfor-at mfor-any switches will port additional actions, for example to rewrite portions ofthe packet header (e.g., for NAT, or to obfuscate addresses

sup-on intermediate links), and to map packets to a priorityclass Likewise, some Flow Tables will be able to match onarbitrary fields in the packet header, enabling experimentswith new non-IP protocols As a particular set of featuresemerges, we will define a “Type 1” switch

Controllers A controller adds and removes flow-entriesfrom the Flow Table on behalf of experiments For example,

a static controller might be a simple application running

on a PC to statically establish flows to interconnect a set

of test computers for the duration of an experiment Inthis case the flows resemble VLANs in current networks—

providing a simple mechanism to isolate experimental trafficfrom the production network Viewed this way, OpenFlow

! "'!

Flow m$i, %4 controller có th4 quy"t %7nh xem có thêm Flow vào Table hay không Ho3c là trong m!t s; thE nghi1m nó có th4 %&'c sE dDng %4 truy(n t)t c5 các gói tin %"n controller %4 xE l6

Flow-! Action 3: H/y gói tin Action này có th4 %&'c sE dDng trong v)n %( b5o m>t, %4 h#n ch" các cu!c t)n công tI ch;i d7ch vD, ho3c gi5m b$t các luHng gói tin broadcast gi5 m#o tI các End-Host

Ngoài 3 lo#i Action trên, OpenFlow còn có thêm m!t lo#i Action th, 4 n2a,

%ó là truy(n %i các gói tin c/a Flow qua %&-ng ;ng (pipeline) xE l6 thông th&-ng c/a switch Lo#i Action này ch< có trên các OpenFlow-enabled switch

2.2.3 Kênh giao ti-p b.o m/t OpenFlow.

Kênh giao ti"p b5o m>t %&'c sE dDng trong m#ng OpenFlow (Secure Channel) là m!t kênh giao ti"p d9a trên k"t n;i %&'c b5o m>t dùng cho quá trình trao %Ci các gói tin và l1nh xE l6 gi2a controller và các switch trong m#ng Thông qua kênh giao ti"p này, controller có th4 c)u hình và qu5n l6 các switch, nh>n các s9 ki1n tI switch và gEi các l1nh %4 giúp các switch xE l6 các gói tin T)t c5 các thông %i1p OpenFlow ph5i %&'c %7nh d#ng theo giao th,c OpenFlow K"t n;i c/a kênh giao ti"p OpenFlow %&'c mã hóa sE dDng giao th,c SSL ho3c TSL %4 %5m b5o %! b5o m>t trong vi1c trao %Ci thông tin gi2a controller và các OpenFlow

2.2.4 Giao th0c OpenFlow

Giao th,c OpenFlow là m!t ngôn ng2 cho vi1c giao ti"p gi2a controller và các switch k"t n;i %"n nó Giao th,c OpenFlow hJ tr' 3 nhóm thông %i1p chính là Controller-to-Switch, thông %i1p b)t %Hng b! và thông %i1p %;i x,ng, mJi nhóm thông %i1p bao gHm nhi(u ki4u con (chi ti"t %3c t5 c/a tIng thông %i1p có th4 tham kh5o + [6,8,9]):

! Nhóm thông %i1p Controller-to-Switch %&'c t#o b+i controller và dùng %4 tr9c ti"p qu5n l6 ho3c ki4m tra tr#ng thái c/a switch Nhóm này gHm các thông %i1p: thông %i1p Feature (%4 controller request các thông tin %3c

%i4m c/a switch), thông %i1p c)u hình (%4 controller thi"t l>p và truy v)n

%7nh ngh:a kèm khi Flow-Entry %&'c t#o ra), thông %i1p Port-status (%&'c switch gEi %"n controller khi có thay %Ci + các cCng c/a nó), và thông %i1p báo lJi (%4 switch thông báo cho controller khi có lJi x5y ra trong nó)

! Nhóm thông %i1p %;i x,ng %&'c t#o b+i Switch ho3c Controller và không c8n ph5i có request tI phía %;i di1n Nhóm này gHm các thông %i1p: thông %i1p Hello (trao %Ci gi2a switch và controller khi bLt %8u k"t n;i), thông %i1p Echo (dùng %4 ki4m tra tr#ng thái c/a k"t n;i gi2a switch và controller), và thông %i1p thE nghi1m (%&a ra m!t d#ng chuQn %4 dành cho vi1c c5i ti"n giao th,c có th4 x5y ra trong t&=ng lai)

2.3 Nh=ng l>i ích c8a m:ng d0a trên OpenFlow

OpenFlow hi1n nay %ã %&'c ch)p nh>n và hJ tr' r!ng rãi tI nhi(u tr&-ng %#i h.c và t>p %oàn l$n trên th" gi$i và %ang %&'c kG v.ng có th4 thay th" ki"n trúc m#ng hi1n hành trong t&=ng lai Ki(u này ch,ng tB nó là m!t gi5i pháp m#ng mang l#i nhi(u l'i ích thi"t th9c Nh2ng l'i ích c/a m#ng OpenFlow bao gHm [4]:

" !i"u khi#n t$p trung c%a các môi tr&'ng multi-vendor:

H1 %i(u khi4n c/a OpenFlow có th4 %i(u hành b)t kG thi"t b7 m#ng có hJ tr' OpenFlow nào tI b)t kG m!t nhà cung c)p thi"t b7 m#ng (vendor) nào, bao gHm các switch, router, và các switch 5o Thay vì ph5i qu5n l6 các nhóm thi"t b7 tI các nhà cung c)p thi"t b7 khác nhau, nhà qu5n tr7 m#ng có th4 sE dDng các công cD qu5n l6

! ")!

và %i(u khi4n d9a trên OpenFlow %4 nhanh chóng tri4n khai, c)u hình và c>p nh>t các thi"t b7 trên toàn th4 m#ng

" Gi(m )* ph+c t,p qua vi-c t )*ng hóa:

M#ng d9a trên OpenFlow cung c)p h1 (framework) qu5n l6 và t9 %!ng hóa m#ng m!t cách linh ho#t, cho phép có th4 tri4n khai các công cD t9 %!ng hóa b)t kG công vi1c qu5n l6 nào mà hi1n nay chúng ta vAn %ang ph5i th9c hi1n bFng tay Nh2ng công cD t9 %!ng này sN gi5m chi phí (overhead) %i(u hành, gi5m tính không

Cn %7nh do các lJi %i(u hành, và hJ tr' các mô hình qu5n l6 bFng d7ch vD Service) %ang nCi lên hi1n nay và mô hình d7ch vD t9 phDc vD (self-service) d9 phòng Thêm vào %ó v$i OpenFlow, các ,ng dDng d9a trên n(n %i1n toán %ám mây

(IT-as-a-có th4 %&'c qu5n l6 thông qua các h1 th;ng d9 phòng và qu5n l6 thông minh, qua

%ó gi5m chi phí (overhead) ho#t %!ng trong khi làm t*ng %! linh %!ng trong qu5n l6

" T/c )* c(i ti0n cao h1n:

Vi1c tuân theo OpenFlow sN làm gia t*ng các c5i ti"n trong m#ng b+i vì OpenFlow cho phép các nhà %i(u hành m#ng th9c s9 l>p trình và tái l>p trình cho h1 th;ng m#ng theo th-i gian th9c %4 %#t %&'c các yêu c8u nghi1p vD n5y sinh và

%òi hBi n5y sinh c/a ng&-i dùng BFng cách 5o hóa c= s+ h# t8ng m#ng và trIu t&'ng hóa nó tI nh2ng d7ch vD m#ng cá nhân, chOng h#n OpenFlow cho phép kh5 n*ng %i(u ch<nh hành vi c/a m#ng và cho ra các d7ch vD m$i và các kh5 n*ng m$i cho m#ng trong m!t kho5ng th-i gian ngLn, có th4 ch< vài gi-

" !* tin c$y và tính b(o m$t )&2c nâng cao:

OpenFlow mang l#i kh5 n*ng %7nh ngh:a c)u hình và các chính sách m#ng (network policy) + m!t m,c cao (nh2ng %7nh ngh:a này sau %ó sN %&'c d7ch và chuy4n xu;ng c= s+ h# t8ng m#ng qua giao th,c OpenFlow) M!t ki"n trúc d9a trên OpenFlow lo#i bB %&'c vi1c c)u hình bFng tay các thi"t b7 m#ng mJi khi có m!t

%i4m cu;i, d7ch vD, %&'c thêm vào ho3c h/y bB, hay khi có m!t s9 thay %Ci v(

" Kh( n3ng thích nghi t/t h1n v4i nhu c5u c%a ng&'i dùng:

BFng cách t>p trung hóa vi1c %i(u khi4n và t#o ra thông tin tr#ng thái s?n cho các ,ng dDng + m,c cao h=n, m!t c= s+ h# t8ng m#ng d9a trên OpenFlow có th4 thích nghi t;t h=n v$i các yêu c8u th&-ng thay %Ci c/a ng&-i sE dDng ChOng h#n nh&, m!t doanh nghi1p truy(n t5i m#ng có th4 cho ra m!t d7ch vD truy(n hình cung c)p cho các ng&-i dùng có tr5 phí %! phân gi5i cao h=n theo m!t cách t9 %!ng và trong su;t Ngày nay, ng&-i dùng h8u nh& ph5i l9a ch.n rõ ràng v( thi"t l>p %! phân gi5i, %i(u mà m#ng có th4 hJ tr' ho3c không hJ tr', dAn %"n s9 ch>m trP và gián %o#n 5nh h&+ng %"n vi1c %áp ,ng nhu c8u c/a ng&-i dùng V$i m#ng d9a trên OpenFlow, ,ng dDng truy(n hình có th4 dò ra b*ng thông có th4 trong m#ng trong th-i gian th9c và t9 %!ng %i(u ch<nh %! phân gi5i t&=ng ,ng

Gi5i pháp Maestro [23] tìm cách t*ng c&-ng hi1u su)t xE l6 c/a controller bFng cách xây d9ng m!t hi1n th9c n(n t5ng controller m$i có cùng tên trong %ó có hi1u su)t xE l6 c/a controller %&'c nâng cao h=n so v$i các n(n t5ng controller hi1n nay nh& NOX[12], Beacon[13], Floodlight[14] và Trema[15]

Gi5i pháp Difane [24] tr5 m!t s; lu>t %i(u khi4n v( các OpenFlow switch BFng cách cài %3t s?n m!t s; lu>t truy(n d2 li1u, mJi khi có gói tin %"n switch mà

so trùng %&'c v$i các lu>t này thì switch có th4 t9 xE l6 mà không c8n gEi request cho controller Theo cách này thì gi5i pháp DIFANE làm gi5m b$t gánh n3ng cho controller và có th4 n$i r!ng ph#m vi c/a m!t controller

Gi5i pháp v( ki"n trúc kh5 l>p trình sE dDng OpenFlow [21] %( xu)t m!t ki"n trúc linh ho#t và có kh5 n*ng m+ r!ng cho n(n c/a OpenFlow controller Tính linh ho#t và kh5 n*ng m+ r!ng c/a ki"n trúc này %#t %&'c nh- thi"t k" controller nh& m!t h1 th;ng mô-%un hóa và phân b; trên m!t cluster gHm nhi(u server Vi1c mô-

%un hóa controller và tri4n khai phân b; trên nhi(u server này là m!t cách ti"p c>n

%4 nâng cao kh5 n*ng xE l6 c/a controller, giúp cho nó có th4 %5m nhi1m qu5n l6

%&'c m#ng OpenFlow l$n h=n Và nh& v>y, nhi(u server có th4 c!ng tác v$i nhau

%4 cùng phDc vD cho m!t OpenFlow controller

! #"!

Các gi5i pháp + trên %ã th9c s9 nâng cao %&'c kh5 n*ng xE l6 và hi1u su)t c/a controller ho3c gi5m t5i xE l6 trên controller, qua %ó cho phép tri4n khai trên m#ng OpenFlow có kích th&$c và s; l&'ng thi"t b7 l$n h=n Tuy nhiên các gi5i pháp này nhìn chung %(u ch&a tri1t %4 b+i vì m3c dù nâng cao %&'c hi1u su)t xE l6 ho3c gi5m t5i l&'ng xE l6 cho controller thì vi1c ch< hJ tr' m!t controller trong m#ng vAn mang nh2ng h#n ch" nh)t %7nh nh)t là %;i v$i m#ng có ph#m vi phân b; r!ng V$i nh2ng m#ng di1n r!ng này thì th-i gian %áp ,ng cho các request c/a các switch + kho5ng cách xa so v$i controller sN b7 5nh h&+ng do %! trP trên b*ng thông m#ng

TI nh2ng h#n ch" + nhóm gi5i pháp th, nh)t + trên và do ph#m vi c/a %( tài ch< t>p trung nghiên c,u h&$ng ti"p c>n cho phép nhi(u controller cùng ho#t %!ng trong m#ng OpenFlow nên trong ph8n này ch< trình bày chi ti"t nh2ng %( xu)t hi1n

có trong h&$ng ti"p c>n này

3.1 H, )i*u khiAn phân bB cho m:ng OpenFlow (HyperFlow)

Nh>n th)y h#n ch" c/a OpenFlow trong vi1c phD thu!c vào m!t controller

%=n %4 qu5n l6 toàn b! các thi"t b7 trong m#ng, nhóm tác gi5 Amin Tootoonchian

và Yashar Ganjali nêu 6 t&+ng v( vi1c cho phép nhi(u controller trong m#ng OpenFlow trong mô hình %&'c %( xu)t là HyperFlow [10] HyperFlow sE dDng nhi(u controller %3t phân b; trong m#ng, mJi controller qu5n l6 m!t vùng m#ng con gHm các OpenFlow switch k"t n;i v$i nó trong m#ng Các switch %óng vai trò truy(n d2 li1u trong m#ng và các controller %óng vai trò ra các quy"t %7nh %i(u hành trong m#ng HyperFlow sE dDng m!t h1 thu phát s9 ki1n %4 chia sM thông tin gi2a các controller trong m#ng H1 thu phát s9 ki1n này ho#t %!ng d9a trên m!t h1 th;ng file phân b; có tên là WheelFS %4 duy trì m!t khung nhìn nh)t quán trên toàn cDc

và hJ tr' vi1c trao %Ci thông tin gi2a các controller MJi controller %&'c cài %3t m!t ch&=ng trình cho phép nó có th4 nh>n các s9 ki1n (event) v( nh2ng thay %Ci trên h1 th;ng và phát %i các s9 ki1n khi có nh2ng s9 thay %Ci trong vùng m#ng c/a nó mà

có th4 5nh h&+ng %"n toàn th4 m#ng Các controller khi nh>n %&'c m!t s9 ki1n

%&'c phát %i tI m!t controller nào %ó thì chúng sN ti"n hành c>p nh>t l#i tr#ng thái

! ##!

m#ng c/a mình d9a vào s9 ki1n này Mô hình HyperFlow có th4 %&'c minh h.a

nh& hình 3.1

Hình 3.1: Minh h/a mô hình HyperFlow [10]

MJi controller trong mô hình k"t n;i v$i 3 kênh bao gHm kênh d2 li1u (data), kênh %i(u khi4n (control) và m!t kênh c/a chính nó (%&'c minh h.a nh&

%ám mây + trên hình vN) Các s9 ki1n c>p nh>t tr#ng thái m#ng %&'c gEi vào kênh

d2 li1u và các thông báo %7nh kG c/a controller %&'c gEi vào kênh %i(u khi4n Khi

m!t controller mu;n gEi m!t thông tin nào %ó cho m!t controller khác trong m#ng

thì nó sN gEi thông tin này vào kênh %i(u khi4n c/a controller nh>n Controller nh>n

có th4 l)y thông tin này tI kênh %i(u khi4n c/a nó và n"u mu;n gEi thông tin tr5 l-i

thì nó sN ti"n hành theo cách t&=ng t9, %ó là gEi thông tin vào kênh %i(u khi4n c/a

controller gEi Vi1c chia sM thông tin trong h1 th;ng %&'c th9c hi1n b+i c= ch" %.c

và ghi các file vào h1 th;ng file phân b; WheelFS

" Nh2n xét:

Mô hình HyperFlow nêu 6 t&+ng v( vi1c sE dDng nhi(u controller %Hng th-i ho#t %!ng trong m#ng OpenFlow, mJi controller qu5n l6 các vùng m#ng con là các

nhóm switch k"t n;i v$i controller trong m#ng Vi1c b; trí phân b; các controller

trong m#ng cho phép các yêu c8u tI các switch %&'c %áp ,ng b+i controller cDc b!

nh- %ó làm gi5m th-i gian %áp ,ng request c/a các switch HyperFlow c@ng %( ra

%&'c m!t c= ch" cho phép các controller có th4 chia sM thông tin c>p nh>t tr#ng thái

Figure 2: High-level overview of HyperFlow Each controller runs NOX with the HyperFlow application atop, subscribes to the control, data, and its own channel in the publish/subscribe system (depicted with a cloud) Events are published to the data channel and periodic controller advertisements are sent to the control channel Controllers directly publish the commands targeted to a controller to its channel Replies to the commands are published in the source controller.

fraction of network events cause changes to the

network-wide view (on the order of tens of events per second

for networks of thousands of hosts [3]) The majority

of network events (i.e., packet in events) only request

service (e.g., routing) (c) The temporal ordering of

events, except those targeting the same switch, does not

affect the network-wide view (d) The applications only

need to be minimally modified to dynamically identify

the events which affect their state (unlike direct state

synchronization which requires each application to

di-rectly implement state synchronization and conflict

res-olution).

2.1 Event Propagation

To propagate controller events to others, HyperFlow

uses publish/subscribe messaging paradigm The

pub-lish/subscribe system that HyperFlow uses must

pro-vide persistent storage of published events (to propro-vide

guaranteed event delivery), keep the ordering of events

published by the same controller, and be resilient against

network partitioning (i.e., each partition must continue

its operation independently and upon reconnection,

par-titions must synchronize) The publish/subscribe

sys-tem should also minimize the cross-site 2 traffic required

to propagate events, i.e., controllers in a site should get

most of the updates of other sites from nearby

con-trollers to avoid congesting the cross-region links

Fi-nally, the system should enforce access control to ensure

authorized access.

We implemented a distributed publish/subscribe

sys-tem satisfying the above requirements using WheelFS [9].

WheelFS is a distributed file system designed to offer

flexible wide-area storage for distributed applications.

2 A site is a highly-connected component of the network with

a large bisection bandwidth However, the bandwidth and

connectivity between regions is limited Typically network

devices in a single site are geographically co-located.

It gives the applications control over consistency, bility, and data placement according to their require-

dura-ments via semantic cues These cues can be directly

embedded in the pathnames to change the behavior

of the file system In WheelFS, we represent nels with directories and messages with files To imple-

chan-ment notification upon message arrival (i.e., new files in

the watched directories) HyperFlow controller tion periodically polls the watched directories to detect changes.

applica-Each controller subscribes to three channels in the network: the data channel, the control channel, and its own channel All the controllers in a network are granted permissions to publish to all channels and sub- scribe to the three channels mentioned The HyperFlow application publishes selected local network and appli- cation events which are of general interest to the data channel Events and OpenFlow commands targeted to

a specific controller are published in the respective troller’s channel Additionally, each controller must pe- riodically advertise itself in the control channel to fa- cilitate controller discovery and failure detection Ac- cess control for these channels are enforced by the pub- lish/subscribe system.

con-HyperFlow is resilient to network partitioning cause WheelFS is Once a network is partitioned, WheelFS

be-on each partitibe-on cbe-ontinues to operate independently Controllers on each partition no longer receive the ad- vertisements for the controllers on the other partitions and assume they have failed Upon reconnection of par- titions, the WheelFS nodes in both partitions resyn- chronize Consequently, the controllers get notified of all the events occurred in the other partition while they

3

! #$!

m#ng %4 duy trì m!t khung nhìn toàn cDc nh)t quán trong m#ng và trao %Ci m!t s; thông tin gi2a các controller

Tuy nhiên, cách ti"p c>n chia sM thông tin d9a trên h1 th;ng file phân b;

%&'c %( xu)t ch< có th4 phù h'p cho vi1c trao %Ci các s9 ki1n x5y ra không th&-ng xuyên %4 %#t %&'c s9 nh)t quán v( tr#ng thái m#ng trên toàn cDc, chOng h#n nh& %4 c>p nh>t các thay %Ci v( tr#ng thái c/a các liên k"t m#ng H=n n2a, vi1c trao %Ci thông tin bFng cách %.c và ghi các file vào h1 th;ng file phân b; không %5m b5o tính tin c>y và %! b5o m>t c8n thi"t %4 cho vi1c trao %Ci các thông tin trong m!t h1 th;ng m#ng Các thông tin m#ng c8n %&'c trao %Ci bFng các thông %i1p th9c s9 theo m!t giao th,c %7nh s?n v$i %! b5o m>t cao, %i(u này HyperFlow ch&a làm

%&'c

Ngoài ra, HyperFlow ch&a gi5i quy"t %&'c v)n %( %7nh tuy"n gi2a các vùng m#ng OpenFlow trong m#ng, %i(u mà các n(n t5ng OpenFlow hi1n nay %(u ch&a hJ tr' mà ch/ y"u ch< sE dDng c= ch" lan truy(n flooding %4 truy(n các gói tin liên vùng trong m#ng Nh& v>y HyperFlow ch&a th4 %5m b5o các switch trong m#ng ho#t %!ng m!t cách h'p l6, %3c bi1t là ho#t %!ng %7nh tuy"n c/a chúng

3.2 Ki7n trúc mC r9ng cho h, )i*u khiAn m:ng OpenFlow n9i b9 (ASIC)

Nh>n th)y kh5 n*ng c/a m!t controller cho vi1c %5m trách xE l6 các yêu c8u (request) tI các switch trong m#ng OpenFlow b7 gi$i h#n, nhóm tác gi5 P Lin, J Bi

và H Hu %( xu)t m!t ki"n trúc m+ r!ng cho h1 %i(u khi4n c/a OpenFlow g.i là ASIC [21] Ki"n trúc này cho phép nhi(u controller %Hng th-i ho#t %!ng trong m#ng và có s9 c!ng tác v$i nhau %4 t*ng kh5 n*ng %áp ,ng các request tI các switch trong m#ng H1 %i(u khi4n c/a ASIC gHm 3 t8ng: t8ng %8u tiên là m!t b! cân bFng t5i (Load Balancer), t8ng th, hai là các OpenFlow controller k"t n;i v$i b! cân bFng t5i, và t8ng th, ba là m!t h1 l&u tr2 phân b; cho vi1c chia sM d2 li1u (hình 3.2)

! #%!

Hình 3.2: Ki7n trúc ASIC [21]

Trong ASIC, b! cân bFng t5i %&'c sE dDng %4 truy(n các request tI các thi"t

b7 trong m#ng cho các controller xE l6 B! cân bFng t5i là m!t thi"t b7 có th4 phân

bC các request cho các controller (có th4 là m!t router, OpenFlow switch,…) và

vi1c phân bC request cho controller có th4 th9c hi1n bFng các gi5i thu>t ch.n (nh&

Round-Robin, Hash Scheduling,…) Khi m!t request kh+i t#o dòng d2 li1u %"n h1

%i(u khi4n c/a ASIC, %8u tiên nó sN %&'c b! cân bFng t5i + t8ng th, nh)t truy(n

%"n các controller %3t + t8ng th, hai Sau %ó controller nh>n %&'c request sN tính

toán %&-ng %7nh tuy"n bFng cách truy xu)t %"n khung nhìn toàn cDc (Global

Network View) + t8ng th, ba và sau %ó gEi tr9c ti"p các thông %i1p tr5 l-i cho các

OpenFlow switch t&=ng ,ng %4 cài %3t %&-ng %7nh tuy"n Vi1c cài %3t %&-ng %7nh

tuy"n %&'c th9c hi1n theo c= ch" xE l6 thông th&-ng c/a OpenFlow hi1n nay %ó là

gEi các thông %i1p %4 thêm các Flow Entry vào các Flow Table c/a switch nFm trên

%&-ng %i tìm %&'c ASIC sE dDng m!t h1 th;ng file phân b; %4 duy trì m!t khung

nhìn toàn cDc cho các controller và sE dDng c= ch" %1m b! nh$ (memory caching)

%4 nâng cao t;c %! truy xu)t d2 li1u c/a khung nhìn toàn cDc cho controller H1

th;ng file này là n=i controller l)y d2 li1u cho vi1c tính toán %&-ng %7nh tuy"n c/a

mình

3 THE ASIC ARCHITECTURE

3.1 Overview of ASIC

The capability of a single controller for handling the data flow

initialization requests is limited In order to deal with large-scale

networks which have vast amounts of initialization requests, this

paper suggests a multi-controller collaboration and network view

sharing method to process the requests in parallel ASIC is a

powerful logical controller and mainly includes three levels: the

first layer is a load balancing system; the second layer is the

controller cluster; and the third layer is a distributed storage

system for data sharing In ASIC, the load balancer only forwards

the requests, and the functions of each controller are equivalent

When a data flow initialization request packet arrives at the logic

controller, firstly it is forwarded to a physical controller located in

the second level by the load balancing system in the first level

Then, the physical controller calculates the routing path by calling

the global network view in the third level, and then installs the

routing path to the corresponding OpenFlow switches Further, for

the replying routing path packet, the physical controller sends

them directly to the OpenFlow switches without passing through

the load balancer in the first level In detail, the routing path is

expressed by the OpenFlow entries in a flowtable [4] The routing

path installation is the process that the controller installs the

flowtable entries into the corresponding OpenFlow switches by a

secure channel described in the OpenFlow protocol

3.2 Load Balancing to Initialization Requests

Reply

Global Network View Figure 3 Applying the load balancing to OpenFlow network

As shown in the figure above, all the data flow requests within a

domain are distributed to different controllers by the load

balancing equipment, and the load balancer can do the requests

distribution by a variety of algorithms like round-robin scheduling

[19], or hash scheduling algorithm [20] by the IP address All the

physical controllers are equivalent Their tasks are to calculate the

routing path based on the global network view, generating

OpenFlow entries, and installing the entries to the corresponding

OpenFlow switches From the prospective of a single controller,

the role of the controller in ASIC is the same as that in the current

OpenFlow environment

In the actual network environment, the load balancer or packet

dispatcher can be selectively adopted according to the number of

requests For example, networks might use a router as a balancer

(using the policy routing model [21]: turning off the route learning

function and forwarding packets according to the statically

configured rules such as forwarding certain packets to a specific

port), an OpenFlow switch (distributing requests by the action

attribute [4] in flowtable), a professional Web load balancer (like

the F5-BIG-LTM-8950 product of F5 corporation), or a software such as Click Router [22][23]

3.3 Storage Cluster for Data Sharing

In order to achieve the data sharing for the distributed control plane and to provide a consistent global view for each controller, this paper suggests adopting a mature data storage system which must include at least two parts: 1) persistent storage which must support transaction (A transaction is a group of operations, any operation in the group fails, the whole group must be undone or rolling back); 2) caching storage Controllers directly deal with the caching storage in both reading and writing, and the persistent storage could be used for data analysis or maintain network status during a reboot process We explain the data cluster in two steps

Step 1: To give the readers a concrete picture of the persistent

data storage, this paper takes the MySQL [24] database for example which could be replaced by other arbitrary persistent storage systems such as DHT (distributed hash table) MySQL is a mature technology with good scalability in both reading and writing A feasible design for the data sharing in OpenFlow is as shown below:

Replication

Read from Slave DB

!

Controller

Figure 4 Writing and reading mechanism to the distributed

storage of the shared data

In the figure above, one master database might correspond to several slave databases The master database is responsible for data writing (INSERT, DELETE, and UPDATE) while the slave databases are responsible for data reading (SELECT) The data consistency between the master database and slave databases can

be achieved by the data replication mechanism Thus, the scalability in data reading can be achieved by increasing the number of the slave databases At the same time, to achieve the scalability in data writing, the master database should be split A network administrator can vertically split the master database based on the actual requirement to form groups of one-master and multi-slave unit For example, by grouping according to the source IP address, data with related source IP address is written to

a same master-slaves database group Meanwhile, in order to obtain a global view of the domain, the controller needs to read data fragments from slave databases of corresponding group units according to the actual requirement and, then, assemble the data fragments together, which is shown in the data reading process

Step 2: Furthermore, in order to accelerate the data reading and

writing speed, ASIC adopts a memory caching system (such as Memcached, [25] [26]) The memory caching system can cache data in the memory to shorten the data reading time compared to reading directly from the database Therefore, based on the MySQL master-slaves architecture, to further accelerate the data reading speed, the data cluster in ASIC adds a memory caching system as shown below:

23

! #&!

" Nh2n xét:

Gi5i pháp c/a ASIC cho phép nhi(u controller song song ho#t %!ng trong m#ng OpenFlow Gi5i pháp này dùng thi"t b7 cân bFng t5i %4 ch.n controller xE l6 khi có request tI các thi"t b7 trong m#ng, nh- %ó gi5m t5i %&'c s; l&'ng request c8n

xE l6 trên mJi controller, giúp nâng cao kh5 n*ng %áp ,ng các request tI các thi"t b7 trong m#ng OpenFlow Gi5i pháp này có th4 ,ng dDng cho m#ng OpenFlow có t8n su)t request tI các thi"t b7 là l$n mà m!t controller có th4 không %áp ,ng %&'c ho3c

%áp ,ng v$i t;c %! h#n ch"

Tuy nhiên, ASIC ch< phù h'p cho m#ng cDc b! b+i vì theo gi5i pháp này t)t c5 các request %(u ph5i %i vào m!t thi"t b7 cân bFng t5i tr&$c khi %&'c phân bC cho các controller xE l6 K;i v$i nh2ng môi tr&-ng m#ng %&'c phân b; trên ph#m vi r!ng thì th-i gian %áp ,ng cho request c/a các switch + xa thi"t b7 cân bFng t5i có th4 b7 5nh h&+ng do %! trP b*ng thông c/a k"t n;i gi2a các switch bà thi"t b7 cân bFng t5i Ngoài ra cách xE l6 gói tin request c/a ASIC có thêm m!t b&$c trung gian

là ph5i qua b! cân bFng t5i tr&$c rHi m$i %"n %&'c controller %4 %&'c xE l6 thay vì

%&'c truy(n tr9c ti"p %"n controller nh& c= ch" hi1n t#i c/a OpenFlow Ki(u này có th4 làm t*ng th-i gian %áp ,ng request

3.3 %* xu(t sD dEng nhi*u controller trong m:ng OpenFlow

Trong %3c t5 m$i nh)t c/a OpenFlow switch (phiên b5n 1.3 [9], n*m 2012)

có trình bày %( xu)t v( vi1c sE dDng nhi(u controller trong m#ng OpenFlow Theo

%( xu)t này, mJi OpenFlow switch trong m#ng có th4 thi"t l>p k"t n;i v$i m!t controller ho3c v$i nhi(u controller V$i nhi(u controller, %! tin c>y %&'c nâng cao b+i vì switch có th4 ti"p tDc xE l6 các gói tin theo c= ch" OpenFlow n"u nó b7 m)t k"t n;i v$i m!t controller trong m#ng S9 bàn giao trách nhi1m gi2a các controller

%&'c qu5n l6 b+i chính các controller và %i(u này cho phép kh5 n*ng phDc hHi nhanh khi có lJi x5y ra và cân bFng t5i c/a controller Trong %( xu)t này, m!t c= ch" ph;i h'p gi2a các controller %&'c sE dDng trong các controller %4 ch.n ra gi2a chúng m!t controller sN ch7u trách nhi1m qu5n l6 tr9c ti"p các switch trong m#ng

! #'!

Trong giai %o#n thi"t l>p k"t n;i, các switch ph5i k"t n;i %"n t)t c5 các controller mà nó %&'c c)u hình %"n và duy trì các k"t n;i này v$i t)t c5 các controller m!t cách %Hng th-i Các controller có th4 gEi các thông %i1p yêu c8u Controller-to-Switch và các thông %i1p tr5 l-i hay các thông %i1p báo lJi liên quan

%"n các thông %i1p yêu c8u này ph5i %&'c gEi %"n ch< duy nh)t k"t n;i controller liên quan %"n thông %i1p yêu c8u %ó V$i các thông %i1p b)t %Hng b! có th4 %&'c gEi %"n nhi(u controller cùng lúc

" Nh2n xét:

Nh& v>y, %( xu)t này cho phép nhi(u controller %Hng th-i ho#t %!ng trong m!t m#ng OpenFlow nh&ng ch< m!t controller chính trong s; %ó làm nhi1m vD tr9c ti"p qu5n l6 t)t c5 các switch trong m#ng, các controller khác h8u nh& ch< %&'c sE dDng cho mDc %ích phDc hHi (recovery) %4 t*ng c&-ng tính tin c>y trong m#ng T)t c5 các controller h&$ng %"n cùng m!t c= s+ h# t8ng m#ng Gi2a chúng ch&a có s9 liên h1 nào v$i nhau và ch&a có c= ch" nào %4 các controller chia sM công vi1c %i(u hành m#ng c/a chúng c@ng nh& c!ng tác v$i nhau %4 qu5n l6 các thi"t b7 trong m#ng

3.5 %ánh giá các giFi pháp và l0a ch/n h;+ng ti7p c2n

Nh& v>y, nh2ng h&$ng ti"p c>n hi1n t#i v( v)n %( cho phép nhi(u controller

%Hng th-i ho#t %!ng trong m#ng OpenFlow hi1n nay %(u có nh2ng m3t h#n ch" riêng Gi5i pháp HyperFlow cho phép tri4n khai nhi(u controller trong m#ng OpenFlow và %( xu)t c= ch" chia sM thông tin gi2a các controller Tuy nhiên c= ch" trao %Ci thông tin này ch&a hi1u qu5 và HyperFlow c@ng ch&a có gi5i pháp cho v)n

%( %7nh tuy"n gi2a các vùng m#ng trong m#ng Gi5i pháp ASIC sE dDng nhi(u controller cùng ho#t %!ng trong m#ng và sE dDng m!t thi"t b7 cân bFng t5i %4 phân các request cho các controller xE l6 Gi5i pháp này giúp gi5m t5i %&'c s; request c8n xE l6 trên mJi controller và qua vi1c sE dDng nhi(u controller sN nâng cao kh5 n*ng %áp ,ng các request trong m#ng Tuy nhiên gi5i pháp này ch< phù h'p cho m#ng cDc b! ho3c m#ng có ph#m vi phân b; không r!ng b+i vì t)t c5 các request

Nh2ng nghiên c,u và %ánh giá v( các h&$ng ti"p c>n hi1n nay trong v)n %( cho phép m!t ki"n trúc có nhi(u controller trong m#ng OpenFlow chính là c= s+ cho vi1c l9a ch.n h&$ng ti"p c>n c/a %( tài %ó là nghiên c,u phát tri4n gi5i pháp cho phép nhi(u controller %&'c phân b; trong m#ng và cùng nhau ho#t %!ng %4 qu5n l6 các thi"t b7 trong m#ng m!t cách hi1u qu5 Trong h&$ng ti"p c>n này, các controller sN %&'c phân b; trong m#ng OpenFlow, mJi controller ch7u trách nhi1m qu5n l6 m!t vùng m#ng cDc b! bao gHm các OpenFlow switch ho3c router k"t n;i

%"n nó trong m#ng H&$ng ti"p c>n này có nh2ng &u %i4m sau:

! Vi1c cho phép nhi(u controller cùng nhau qu5n l6 trong m#ng sN làm t*ng

%áng k4 kh5 n*ng m+ r!ng c/a m#ng OpenFlow Th>t v>y, tính m+ r!ng c/a OpenFlow hi1n nay b7 gi$i h#n do b7 l1 thu!c vào m!t controller ch#y trên m!t máy tính %=n trong khi kh5 n*ng tính toán, xE l6 c/a m!t máy tính là có h#n Và th9c t" là mJi controller ch< hJ tr' %&'c m!t s; l&'ng thi"t b7 nh)t %7nh trong m#ng v$i t8n su)t c/a các request trong m#ng gEi

%"n controller nh)t %7nh N"u có m!t gi5i pháp cho phép nhi(u controller cùng ho#t %!ng và phân chia công vi1c qu5n l6 trong m#ng theo m!t c= ch" nh)t quán trên toàn th4 m#ng thì h1 %i(u khi4n c/a m#ng có th4 hJ tr' s; l&'ng switch c@ng nh& t8n su)t request nhi(u h=n %áng k4

! Trên m!t môi tr&-ng m#ng có ph#m vi phân b; r!ng, vi1c phân b; các controller trong m#ng cho phép các switch ho3c router trong m#ng %&'c

%áp ,ng b+i controller trong vùng m#ng cDc b! c/a mình và %ây chính là