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 phần mềm mã nguồn mở IMS Communicator. Thành phần modun QoE tập hợp các hồ sơ khách hàng về mục đích sử dụng trong các tình huống khác nhau (nhƣ trò chuyện truyền hình trực tuyến, phim hành động…). Sau đó nó dự đoán về các mức độ hài lòng của ngƣời sử dụng dịch vụ ứng với các tham số chất lƣợng dịch vụ khác nhau tại cùng một thời gian theo dõi, định kỳ trong quá trình của phiên dịch vụ đang diễn ra.
-Thành phần máy chủ ứng dụng IPTV AS: đƣợc phát triển cho dịch vụ giá trị gia tăng IPTV, dựa trên nền tảng Sailfin. IPTV AS bao gồm các mô đun QoE, QoS để thu thập điểm ý kiến từ thiết ị đầu cuối của khách hàng, ao gồm các tham số chất lƣợng dịch vụ tƣơng ứng, ví dụ nhƣ tỷ lệ mất gói, độ trễ, iến động trễ.
Máy chủ video cũng đƣợc phát triển dựa trên máy chủ Darwin Streaming Server.
B. Lớp l i IMS:
Để áo hiệu, điều khiển phiên ho c dịch vụ, cung cấp máy chủ CSCF và cơ sở dữ liệu hồ sơ ngƣời dùng (HSS).
C. Lớp phƣơng tiện:
64
- Mạng truyền tải lõi đƣợc x y dựng với các ộ chuyển mạch OpenFlow ảo hóa và công nghệ Openflow.
- Khối điều khiển tài nguyên thích nghi chung GARC đƣợc tích hợp vào mạng lõi. Khối GARC thực hiện chức năng cầu nối bridging giữa lớp mạng và lớp ứng dụng để tối ƣu hóa kết nối end-to-end một cách tổng thể bằng cách áp dụng các cơ chế kiểm soát dịch vụ cụ thể và thích hợp với từng loại ứng dụng. Hiện tƣợng mất gói tin và gián đoạn các kết nối có thể tránh đƣợc thông qua việc quản lý lƣu lƣợng một cách thông minh trong mạng lõi và mạng truy nhập.
- Giao diện ộ điều khiển chuyển mạch sử dụng giao thức OpenFlow phiên ản 1.1, sẽ cung cấp các giao diện điều khiển Openflow để thực hiện định tuyến.
- Dựa trên cơ sở dữ liệu thu thập đƣợc của mỗi ngƣời dùng khác nhau với các loại hình dịch vụ, thành phần GARC logic thiết lập chức năng ánh xạ giữa QoE và QoS bằng cách sử dụng phƣơng pháp hồi quy tuyến tính, có công thức nhƣ sau:
MoS = α Br + β Jt + γ Plr + ε.
Trong đó các hệ số α, β, γ, ε đƣợc tính toán cho từng trƣờng hợp. Br : tốc độ it, Jt : iến động trễ jitter, Plr : tỉ lệ mất gói tin.
- Dựa trên chức năng ánh xạ QoE/QoS đã đƣợc thiết lập trên, với các hồ sơ chất lƣợng dịch vụ khác nhau để iên dịch các yêu cầu chất lƣợng trải nghiệm QoE hƣớng vào ngƣời sử dụng thành các tham số chất lƣợng dịch vụ QoS của mạng. Các quyêt định thay đổi chất lƣợng dịch vụ QoS có thể là: thay đổi cấu hình mạng để đạt đƣợc trễ truyền dẫn tốt hơn, ho c tỷ lệ mất gói ít hơn trong mạng truyền tải. Chính sách đƣợc thực hiện qua giao thức Openflow.
D. Các giao diện:
- Thành phần điều khiển OpenFlow: NOX. Giao diện giữa khối GARC và NOX để trao đổi các ản tin OpenFlow (Json qua giao thức TCP), để truyền tải các thông tin quản lý, điều khiển, giám sát, thống kê mạng.
- Đối với việc điều khiển sự ánh xạ luồng-tới-hàng đợi (flow-to-queue) thông qua chuyển các thông điệp DPCTL, do đó cho phép ph n iệt QoS giữa các luồng khác nhau.
65
- Thành phần P-CSCF của mạng lõi IMS: giao diện Gx Diameter để cung cấp các chính sách chất lƣợng dịch vụ, kết hợp với Gxx Diameter để thực hiện các chức năng áo cáo sự kiện và gán kênh truyền.
- HSS/HLR: cơ sở dữ liệu hồ sơ ngƣời dùng.
- Máy chủ ứng dụng AS: giao diện Rx mở rộng để áo hiệu các yêu cầu chất lƣợng