3.6.1 T ng quan về NOX
NOX là nền tảng của khối điều khiển OpenFlow có đầy đủ tính năng và có thể mở rộng. Nó đƣợc phát triên bởi Nicira Network Inc, vai trò nhƣ một API cho các dự án nội bộ của họ. Mã nguồn của NOX đƣợc công khai năm 2008, đƣợc đánh bản quyền dƣới GPLv3. NOX đƣợc phân phối trực tiếp từ một kho lƣu trữ từ trang web của nó tại http://www.noxrepo.org.
NOX đƣợc phát triển với mô hình lập trình tập trung, nghĩa là nó có khả năng điều khiển hoàn toàn một mạng bằng cách lập trình cho khối điều khiển trung tâm- gọi là NOX. Nó dùng chuẩn OpenFlow để điều khiển các bộ chuyển mạch trong mạng. Nó đƣợc phát triển trong C++ và Python dùng Simplied Wrapper và Interface Generator SWIG để tạo ra các giao diện giữa hai ngôn ngữ này. NOX đƣợc thiết kế thực hiện các chức năng có thể dễ dàng mở rộng. NOX gồm các thành phần thực hiện các chức năng mong muốn, các thành phần này sẽ đƣợc kích hoạt khi NOX khởi tạo. NOX nhìn các mạng nhƣ một tập hợp các luồng. Mỗi luồng là một chuỗi các gói tin đƣợc xác định bởi một số các thuộc tính, ví dụ địa chỉ IP/ MAC nguồn ho c đích và các số cổng. Việc thực hiện quyết định dựa trên cơ sở cho mỗi gói tin rõ ràng sẽ không khả thi cho mạng lớn, gây tốn kém tài nguyên các bộ chuyển mạch.
Các thử nghiệm cho thấy mỗi khối điều khiển có thể xử lý tới 100.000 luồng mỗi gi y. Điều này còn phụ thuộc vào sự lập trình của các thành phần xử lý luồng và các việc nó phải xử lý.
Các bộ chuyển mạch đƣợc nhận dạng bằng các datapath ID (dpid), là các giá trị hệ 16 gồm 48 bit, và chúng là duy nhất trong mạng OpenFlow.
3.6.2 Kiến tr c của NOX
NOX gồm các thành phần cơ ản sau: Khối lõi NOX, các thƣ viện, bộ sắp lịch sự kiện, và một vài thành phần khác. Khối lõi, các thƣ viện và bộ lập lịch sự
55
kiện xây dựng nên một nền tảng gồm các thành phần thực thi các chức năng khác nhau nhƣ mô tả trong hình sau. Lập trình NOX là công việc viết các thành phần.
Khối lõi NOX là thành phần cơ ản nhất trong kiến tr c NOX. Nó điều khiển các kết nối và điều phối các thực thể, thực thi các thành phần khác nhau. Nó thực hiện việc trả lời các bản tin OpenFlow do các bộ chuyển mạch gửi đến, tạo ra các sự kiện thông qua phân hệ sự kiện NOX khi cần. Các khối lõi NOX quản lý các kết nối controlpath cho từng bộ chuyển mạch OpenFlow có kết nối với nó. NOX cũng cung cấp các thƣ viện cho các thành phần khác sử dụng. Ví dụ một giao diện kết nối mạng thực hiện các chức năng nhƣ tạo ra, biên dịch, phân tích các loại gói tin khác nhau. Sự tƣơng tác với các thiết bị chuyển mạch OpenFlow đƣợc tách ra trong các thƣ viện, và có thể đƣợc sử dụng bên trong một thành phần khác. Ví nhƣ các luồng có thể đƣợc tạo ra, xóa bỏ, ho c các gói tin có thể đƣợc gửi ra ngoài một cổng của bộ chuyển mạch bằng cách sử dụng các chức năng cung cấp bởi các thƣ viện.
56
Sau khi các bản tin OpenFlow đến, phân hệ Event NOX đƣợc kích hoạt bởi khối lõi NOX để gửi một sự kiện tới từng thành phần đăng ký. Các mũi tên trong hình vẽ minh họa các đƣờng truyền thông tin trong NOX. Các thành phần có thể truyền thông tin với các thành phần khác dùng các sự kiện ho c gọi các hàm một cách trực tiếp bằng cách bao gồm và sử dụng các hàm của các thƣ viện.
3.6.3 Các thành phần
Các thành phần là những sự trìu tƣợng hóa trong NOX chứa đựng các logic thực tế. Mỗi thành phần có một chức năng cụ thể. Trong NOX, có 3 loại thành phần đƣợc phân biệt:
Coreapps: đ y là các thành phần cơ ản, ví dụ nhƣ Messenger, SNMP, một
số thành phần thử nghiệm và các ví dụ.
Netapps: là các thành phần cung cấp dịch vụ mạng, ví nhƣ Routing,
Authenticator, Spanning-tree, Monitoring, Topology, Discovery và nhiều thành phần khác.
Webapps: NOX webserver là một thành phần loại này. Cũng có một thành
phần webservice, và một we serviceclient cơ ản để minh họa webserver và we service đƣợc sử dụng nhƣ thế nào. Mục đích của các thành phần này là để quản lý NOX thông qua các webservices.
Sự khác biệt này đƣợc thể hiện thông qua các thƣ mục khác nhau trong các mã nguồn. Mỗi thành phần lƣu trữ trong thƣ mục của riêng nó trong các danh mục chuẩn với bắt buộc là file meta.json. Đ y là file mang thông tin về thành phần, nhƣ tên của thành phần, những sự phụ thuộc của thành phần. Khai báo những sự phụ thuộc là cần thiết khi các thành phần phụ thuộc vào nhau. Ví dụ, thành phần topology tạo ra một hình vẽ về sơ đồ mạng. Nó phụ thuộc vào thành phần discovery, thành phần này tìm ra các kết nối trong mạng và tạo ra các sự kiện link_event.
57
Discovery
Thành phần này theo dõi các kết nối đang tồn tại trong mạng OpenFlow. Vì vậy giao thức khám phá lớp kết nối (Link Layer Discovery Protocol- LLDP) đƣợc sử dụng. Các khung LLDP chứa một số cấu trúc TLV (type-length-value). Những cấu trúc này chuyển thông tin về thiết bị nhận, ví dụ một loại TLV về ID của Chassis có một độ dài xác định và sẽ chuyển giá trị ID này.
Thành phần Discovery sử dụng các khung LLDP chứa TLV ID của Chassis mang datapath ID của bộ chuyển mạch, cổng ID TLV, chỉ rõ cổng ra của bộ chuyển mạch, và thời gian sống của TLV. Các khung LLDP đƣợc gửi ra từng cổng của bộ chuyển mạch. Khi một bộ chuyển mạch nhận đƣợc một khung LLDP trên một cổng, nó thông báo cho bộ điều khiển về gói tin vô danh bởi không có chỉ mục nào trong bảng luồng của bộ chuyển mạch. Khung đƣợc chuyển tới thành phần discovery bởi nó có chức năng xử lý và ph n tích gói tin đến. Nó sẽ cho biết thông tin về bộ chuyển mạch gửi, số cổng nội dung của khung LLDP, cổng nhận và cổng đến của bộ chuyển mạch, kết nối giữa các bộ chuyển mạch và các cổng đang tồn tại. Nó cũng giám sát các các kết nối đã iết thông qua việc định kỳ gửi ra các khung LLDP. Nếu một kết nối vô danh xuất hiện ho c một kết nối đang tồn tại bị mất, một sự kiện kết nối chứa các thông tin về kết nối đó đƣợc tạo ra để thông báo. Các thành phần khác có thể đăng ký các kết nối này và xây dựng cấu trúc mạng của riêng các thành phần đó dựa trên các thông tin đã xác định.
Điều quan trọng là không có các hub ho c các bộ chuyển mạch lớp 2 phi OpenFlow giữa các bộ chuyển mạch này, vì thế các gói tin LLDP sẽ đƣợc làm ngập toàn mạng và từng cổng đƣợc kết nối với nhau. Điều này là do thiếu một giao thức STP(Spanning Tree Protocol) đƣợc chuẩn hóa trong NOX và dẫn tới vòng l p trong mạng.
Cấu trúc liên kết (Topology)
Thành phần cấu trúc liên kết phụ thuộc vào thành phần Discovery. Nó duy trì trong đại diện bộ nhớ của cấu trúc liên kết mạng hiện tại bằng cách quan sát các sự kiện
58
gia nhập và rời datapath đƣợc tạo ra bởi nhân NOX và chỉ ra rằng một bộ chuyển mạch gia nhập ho c rời mạng bởi các sự kiện kết nối từ modun discovery.
Các phƣơng thức để truy vấn về trạng thái mạng hiện tại:
get datapath(): lấy danh sách các bộ chuyển mạch đang hoạt động hiện tại,
bao gồm cả các giá trị datapath ID của các bộ chuyển mạch.
get_neighbors (datapathIDsrc): lấy các bộ chuyển mạch láng giềng
trực tiếp từ các giá trị datapath ID đã cho.
is_internal(datapathID, port): Hàm Boolean kiểm tra khi kết nối
từ cổng và bộ chuyển mạch kết nối với một bộ chuyển mạch khác trong mạng OpenFlow.
get_outlinks(datapathIDsrc, datapathIDdst):Với datapathIDdst đã
cho, một danh sách các kết nối giữa 2 bộ chuyển mạch đƣợc trả về. Ngƣợc lại các kết nối từ datapath ID nguồn đƣợc trả về.
Cây mở rộng (Spanning Tree)
Modun này tạo ra một cây mở rộng cơ ản trong mạng OpenFlow. Nó không tƣơng thích với chuẩn STP đã chuẩn hóa là IEEE 802.1D. Khi một bộ chuyển mạch gia nhập mạng, thành phần cây mở rộng STP đ t giá trị bit NO FLOOD trên từng cổng của bộ chuyển mạch để ngăn ch n các gói tin đến đƣợc gửi tới các kết nối có thể dẫn tới một vòng l p trong mạng.
Cây mở rộng đƣợc tính toán nhƣ sau:
Datapath ID của từng cổng đang hoạt động của bộ chuyển mạch trong mạng đƣợc liệt kê một danh sách. Danh sách này đƣợc sắp xếp và bộ chuyển mạch có giá trị datapath ID nhỏ nhất trở thành gốc của cây mở rộng. Gốc sẽ đƣợc gỡ bỏ khỏi danh sách, mỗi kết nối hƣớng ra ngoài từ bộ chuyển mạch này sẽ đƣợc kiểm tra. Các giá trị datapath ID từ các bộ chuyển mạch có thể đến bằng 1 hop đƣợc chuyển tới m t trƣớc của danh sách và đƣợc sắp xếp, bit NO FLOOD trên các cổng tƣơng ứng đƣợc đ t về zero, vì vậy các kết nối đƣợc thêm vào cây mở rộng. Bộ chuyển mạch kế tiếp đƣợc lấy từ đầu danh sách ứng cử viên và xử lý theo cùng một cách.
59
Từ đó các ộ chuyển mạch đƣợc kết nối trực tiếp với nhau. Nếu một bộ chuyển mạch không cho phép tính năng OpenFlow nằm giữa các bộ chuyển mạch sẽ phá hủy chức năng của thành phần cây mở rộng.
Thành phần cây mở rộng là cần thiết trong mạng OpenFlow để ngăn ngừa vòng l p trong mạng. Nếu không các giao thức khác nhƣ ARP dựa trên bản tin quảng bá không thể làm việc hiệu quả.
Giám sát (Monitoring)
Thành phần giám sát lƣu giữ tất các các loại số liệu thống kê của bộ chuyển mạch. Nó có một giao diện API có thể đƣợc sử dụng để truy vấn số liệu thống kê. Tất cả
các thống kê đề cập trong phần trình bày về Flow table đƣợc định kỳ tập hợp bởi
thành phần này và có thể truy vấn để lấy ra kết quả.
JSON(JSON Messenger)
Thành phần messenger Json mở ra một cổng trên máy chủ điều khiển trên đó giao tiếp với NOX từ bên ngoài có thể diễn ra. Các bản tin đƣợc mong đợi nằm trong JavaScript Object Notation, viết tắt là JSON. JSON là một cách định dạng cấu trúc dữ liệu theo cách con ngƣời có thể đọc và trao đổi nó giữa hai ên. Nó đƣa ra các loại dữ liệu: +Số học +Chuỗi +Boolean +Mảng +Đối tƣợng +Rỗng (Null)
Nếu một bản tin đến, một sự kiện JSONmsg đƣợc tạo ra. Các thành phần khác có thể đăng ký cho sự kiện này và biên dịch bản tin JSON cho các loại mà nó có thể hiểu. Sử dụng thành phần này, các giao diện ngƣời dùng đồ họa để các thành phần NOX có thể đƣợc thực hiện bởi có sự thực thi JSON có sẵn cho hầu hết các ngôn
60
ngữ lập trình lớn hiện đại. Theo cách này, NOX có thể đƣợc truy vấn về thông tin trạng thái ho c nó thể đƣợc điều khiển từ bên ngoài. Tuy nhiên, cổng đƣợc mở cho mọi ngƣời và không có cơ chế xác thực trong phiên bản hiện có của thành phần này.
Authenticator
Thành phần authenticator giám sát các máy chủ trong mạng, vị trí của chúng, các địa chỉ MAC, địa chỉ IP, bộ chuyển mạch và các cổng kết nối liên quan. Trong phiên bản hiện tại của thành phần này, tất cả các ngƣời sử dụng kết nối mạng m c định đƣợc xác thực. Thành phần này lắng nghe các sự kiện Auth từ các thành phần khác để biết khi nào một máy cần đƣợc thêm vào danh sách các máy đã iết. Với sự kiện Packet_In, Authenticator gửi đi một Flow_In chứa các bộ chuyển mạch nguồn và đích khi các máy đang giao tiếp đã đƣợc thành phần Authenticator biết.
Routing
Thành phần routing tính toán các đƣờng đi giữa các địa chỉ MAC nguồn và đích, và thiết lập các luồng tƣơng ứng trên các bộ chuyển mạch. Nó sử dụng thuật toán tất
cả các cặp đường ngắn nhất. Modun này chỉ đơn giản là chuyển tiếp các gói tin và
không nên nhầm lẫn với việc định tuyến trong các mạng IPv4. Nó nghe sự kiện Flow_In của thành phần Authenticator và cài đ t các luồng cho các đƣờng ngắn nhất giữa hai máy trên các bộ chuyển mạch.
61
CHƢƠNG 4. ĐỀ XUẤT KIẾN TRÚC KẾT HỢP NỀN TẢNG IMS VÀ HẠ TẦNG MẠNG OPENFLOW NHẰM THỰC THI CÁC CHÍNH SÁCH ĐẢM
ẢO CHẤT LƢỢNG DỊCH VỤ TRONG MÔI TRƢỜNG IMS 4.1 Đặt vấn đề
IPTV dựa trên nền tảng IMS ngày nay đã trở thành một kiến trúc hứa hẹn cho các dịch vụ mới dựa trên nền tảng IP. Bằng cách dùng IMS làm nền tảng để điều khiển cho IPTV, kiến trúc mới đã đề xuất một loạt các đ c tính mới so với các giải pháp truyền thống. Ngoài ra, với các khả năng về điều khiển dịch vụ và phiên, IMS có thể đƣợc dùng nhƣ lớp để điều khiển chất lƣợng dịch vụ QoS và điều khiển các nguồn tài nguyên các lớp mạng ên dƣới. Tuy vậy, vẫn còn tồn tại một số vấn đề chƣa đƣợc giải quyết triệt để trong kiến trúc IPTV hiện tại.
Thứ nhất là đảm bảo nhƣ thế nào chất lƣợng của các dịch vụ IPTV theo cách tập trung vào ngƣời dùng hơn là tập trung vào các cơ chế chất lƣợng dịch vụ trên mạng. Các nghiên cứu gần đ y đã chỉ ra rằng đảm bảo QoS không có nghĩa là đảm bảo đƣợc sự thỏa mãn của ngƣời dùng. Do vậy các dịch vụ đa phƣơng tiện trong tƣơng lai cần đƣợc truyền tải dựa trên yêu cầu chất lƣợng cảm giác của ngƣời dùng, còn gọi là chất lƣợng trải nghiệm QoE.
Thứ hai là vấn đề ánh xạ một cách linh hoạt thế nào về QoE của các phiện IPTV tới các tham số QoS tập trung vào mạng và sự cung cấp các tài nguyên tƣơng ứng một cách hiệu quả. Do đó cảm giác về dịch vụ của ngƣời dùng đƣợc thỏa mãn trong khi các tài nguyên mạng đƣợc tối ƣu dựa trên các điều kiện mạng lƣới hiện có. Một kiến tr c đề xuất đƣợc tham khảo gọi là “điều khiển tài nguyên thích nghi chung” (GARC) 4 . Đ y là kiến trúc thực hiện, là chiếc cầu nối khoảng cách giữa lớp ứng dụng và lớp mạng thông qua tạo ra sự nhận biết của mỗi lớp bằng cách cho phép trao đổi các bản tin điều khiển một cách trực tiếp, để tối ƣu hóa một cách tổng thể kết nối end-to-end bằng cách áp dụng từng ứng dụng một cách phù hợp và các cơ chế kiểm soát dịch vụ đ c thù trên kết nối. Sự mất gói tin và bị gián đoạn kết nối sẽ tránh đƣợc thông qua quản lý lƣu lƣợng thông minh trong truy nhập và mạng lõi. Vấn đề thứ ba là làm thế nào nó có thể áp đ t các chính sách QoS cũng nhƣ sự cấu hình mạng mỗi phiên khác nhau trên cơ sở hạ tầng mạng một cách linh động.
62
Ví dụ, về định tuyến, bộ giải mã sửa đổi, thích ứng tốc độ bit, đ t dự phòng ăng thông, ƣu tiên lƣu lƣợng truy cập vv…
Từ các lý do trên đã dẫn tới việc cần thiết đề xuất kiến trúc mới: Thiết kế một kiến trúc mạng IPTV mới có khả năng nhận thức QoE, kết hợp IMS với hạ tầng mạng OpenFlow và có thể thích ứng với các tài nguyên mạng và các đ c tính dịch vụ dựa trên yêu cầu của ngƣời dùng. Nó cho phép ngƣời sử dụng đánh giá sự hài lòng dịch vụ của họ tại các thiết bị đầu cuối, và cho phép mạng nhận thức dịch vụ thông qua các yêu cầu chất lƣợng dịch vụ QoS của ngƣời dùng.
63
Hình 4.1 Kiến trúc kết hợp nền tảng IMS và hạ tầng mạng OpenFlow.
4.2 Mô tả kiến tr c đề xuất
Kiến tr c gồm 3 lớp nhƣ mô tả trong hình 4.1 trên.
A. Lớp ứng dụng:
-Thành phần IMS IPTV client: với thành phần QoE đƣợc tạo nguyên mẫu dựa trên