Luận văn Đánh giá hiệu quả đảm bảo qos cho truyền thông đa phương tiện của chiến lược quản lý hàng đợi wred

1 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ VŨ XUÂN BẢO ĐÁNH GIÁ HIỆU QUẢ ĐẢM BẢO QoS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN CỦA CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI WRED LUẬN VĂN THẠC SĨ Hà Nội - 2011 2 LỜI CAM ĐOAN Tôi xin cam đoan đây là công trình nghiên cứu của bản thân. Các số liệu, kết quả trình bày trong luận văn này là trung thực và chưa từng được ai công bố trong bất kỳ công trình luận văn nào trước đây. Học viên Vũ Xuân Bảo 3 LỜI CẢM ƠN Trước hết tôi xin gửi lời cảm ơn sâu sắc nhất tới người hướng dẫn tôi, thầy giáo PGS.TS. Nguyễn Đình Việt – Giảng viên khoa Công nghệ Thông tin trường Đại học Công nghệ Đại học Quốc gia Hà Nội, người đã định hướng đề tài và tận tình hướng dẫn, chỉ bảo trong suốt quá trình thực hiện luận văn cao học. Tôi xin gửi lời cảm ơn tới các thầy cô đã giảng dạy tôi trong suốt quá trình nghiên cứu, học tập, các thầy cô trong ban chủ nhiệm lớp K15T1, những người rất quan tâm tới lớp, giúp tôi và các bạn có được kết quả như ngày hôm nay. Sau cùng, tôi xin dành tình cảm đặc biệt và biết ơn tới gia đình, người thân của tôi, những người đã ủng hộ, khuyến khích tôi rất nhiều trong quá trình học tập cũng như quá trình thực hiện luận văn này. Do điều kiện nghiên cứu có hạn, nên bản luận văn không tránh khỏi sơ suất, kính mong nhận được sự góp ý của thầy cô, bạn bè và đồng nghiệp để bản luận văn được hoàn thiện hơn. Hà Nội, tháng 06 năm 2011 Vũ Xuân Bảo 4 MỤC LỤC LỜI CAM ĐOAN .................................................................................................................1 LỜI CẢM ƠN.......................................................................................................................3 MỤC LỤC ............................................................................................................................4 DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT ..............................................................7 DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ .............................................................................9 DANH MỤC CÁC BẢNG ................................................................................................11 ĐẶT VẤN ĐỀ ....................................................................................................................12 1. Mục đích và ý nghĩa của đề tài ..................................................................................12 2. Đối tượng và phạm vi nghiên cứu .............................................................................13 3.Cấu trúc các chương ....................................................................................................13 Chương 1. TỔNG QUAN ..................................................................................................14 1.1 Mạng Internet và các dịch vụ...................................................................................14 1.1.1 Mạng Internet ........................................................................................................14 a. Lịch sử phát triển mạng Internet ............................................................................14 b. Giao thức tầng giao vận: TCP và UDP .................................................................15 1.1.2 Đặc điểm vận chuyển lưu lượng kiểu “Cố gắng tối đa ” [2] ..............................17 a. Tỉ lệ mất mát gói tin có thể rất lớn khi xảy ra tắc nghẽn ..................................17 b. Độ trễ end-to-end có thể vượt quá giới hạn chấp nhận được ...........................18 c. Jitter là không thể tránh khỏi và làm giảm chất lượng âm thanh .....................18 1.2 Truyền thông đa phương tiện và yêu cầu chất lượng dịch vụ (QoS) ....................19 1.2.1 Một số thí dụ về truyền thông đa phương tiện ....................................................19 1.2.1.1 Ứng dụng Email, FTP ....................................................................................19 1.2.1.2 Ứng dụng truyền dòng (Streaming) âm thanh, hình ảnh lưu trước .............20 1.2.1.3 Ứng dụng Streaming cho âm thanh, hình ảnh truyền trực tiếp (live) .........21 1.2.1.4 Ứng dụng hình ảnh âm thanh tương tác thời gian thực ...............................21 1.2.1.5 Ví dụ về điện thoại VoIP ...............................................................................22 1.2.2 Khái niệm QoS ......................................................................................................24 1.2.3 Yêu cầu QoS cho truyền thông đa phương tiện ..................................................25 1.3 Các tham số hiệu năng chủ yếu của mạng liên quan đến việc đảm bảo QoS .......26 1.3.1 Băng thông (bandwidth) .......................................................................................26 1.3.2 Độ trễ (delay) và biến thiên độ trễ (jitter) ...........................................................26 a. Độ trễ (delay) ..........................................................................................................26 b. Biến thiên độ trễ (Jitter) .........................................................................................26 1.3.3 Tỉ lệ mất mát gói tin ..............................................................................................27 1.3.4 Một số tham số khác: ............................................................................................27 a. Tính sẵn sàng – độ tin cậy ......................................................................................27 b. Bảo mật ...................................................................................................................28 Kết luận chương..............................................................................................................29 Chương 2. CÁC MÔ HÌNH ĐẢM BẢO QoS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN ....................................................................................................................................30 2.1 Mô hình IntServ (Integrated Service) .....................................................................30 2.1.1 Tổng quan ..............................................................................................................30 2.1.2 Kiến trúc IntServ ...................................................................................................31 2.1.2.1 Điều khiển chấp nhận.....................................................................................31 5 2.1.2.2 Nhận dạng luồng ............................................................................................32 2.1.2.3 Lập lịch gói .....................................................................................................32 2.1.2.4 Các dịch vụ của IntServ .................................................................................32 2.1.3 Giao thức dành trước tài nguyên - RSVP ............................................................32 2.1.3.1 Tổng quan .......................................................................................................32 2.1.3.2 Hoạt động của RSVP .....................................................................................33 2.1.3.3 Các kiểu RSVP dành trước tài nguyên .........................................................33 2.2 Mô hình DifServ (Differentiated Service) ..............................................................34 2.2.1 Tổng quan ..............................................................................................................35 2.2.2 Cấu trúc DiffServ ..................................................................................................36 2.2.3 Đánh dấu gói DiffServ ..........................................................................................38 2.2.3.1. Đánh dấu gói trong các router thông thường...............................................38 2.2.3.2.Trường DiffServ (DS) ....................................................................................39 2.2.4 Hành vi theo từng chặng (PHB) ...........................................................................40 2.2.4 .1 PHB chuyển tiếp nhanh (Expedited Forwarding) .......................................40 2.2.4.2 PHB chuyển tiếp đảm bảo (AF) ....................................................................42 2.2.5.Ví dụ về Differentiated Services ......................................................................43 Kết luận chương..............................................................................................................44 Chương 3: CÁC PHƯƠNG PHÁP ĐẢM BẢO QoS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN .................................................................................................................45 3.1. Phương pháp bỏ đuôi - DropTail .......................................................................45 3.2. Phương pháp loại bỏ ngẫu nhiên – RED................................................................46 3.2.1 Tổng quan ..............................................................................................................46 3.2.2 Thuật toán ..............................................................................................................48 3.2.3 Thiết lập các tham số ............................................................................................50 a. Trọng số hàng đợi wq .............................................................................................50 b. Thiết lập minth và maxth .......................................................................................51 c. Thiết lập xác suất loại bỏ tối đa maxp ...................................................................52 3.2.4 Một số đánh giá về RED.......................................................................................52 3.3 Phương pháp loại bỏ ngẫu nhiên theo trọng số - WRED.......................................53 a. Cấu trúc của DiffServ .............................................................................................55 b. Hàng đợi RED trong module DiffServ..................................................................55 c. Router lõi và router biên.........................................................................................56 d. Các chính sách - Policy ..........................................................................................57 3.4 Một số phương pháp khác........................................................................................58 3.4.1. Tốc độ truy cập cam kết (CAR - Committed Access Rate)...............................58 3.4.1.1. Cơ chế hoạt động...........................................................................................58 3.4.1.2. Các chức năng của CAR ...............................................................................59 3.4.1.3. Mô hình chiếc thùng và thẻ bài ....................................................................60 3.4.2 Định dạng lưu lượng tổng quát - GTS (Generic Traffic Shaping) ....................61 a. Cơ chế hoạt động của GTS.....................................................................................61 b. Kết luận ...................................................................................................................62 Kết luận chương..............................................................................................................63 Chương 4. ĐÁNH GIÁ VÀ SO SÁNH WRED VỚI DROP-TAIL VÀ RED ...............64 4.1. Giới thiệu bộ mô phỏng mạng NS-2 ......................................................................64 4.2. Thiết lập tô-pô mạng mô phỏng .............................................................................64 4.3. Kịch bản mô phỏng .................................................................................................65 4.4. Đánh giá hiệu năng truyền thông đa phương tiện khi sử dụng DropTail và RED67 6 4.4.1 Kịch bản 1: Tăng cường độ tắc nghẽn với các nguồn phát TCP........................67 a. Kết quả.....................................................................................................................67 b. Nhận xét ..................................................................................................................68 4.4.2. Thí nghiệm 2: Tăng cường độ tắc nghẽn với nguồn phát UDP....................69 a. Kết quả.....................................................................................................................69 b. Nhận xét: .................................................................................................................71 4.5. Đánh giá hiệu năng truyền thông đa phương tiện khi sử dụng WRED ...............71 4.5.1. Mô phỏng WRED TSW2CM và TSW3CM.......................................................71 a. Cấu hình mô phỏng.................................................................................................72 b. Phương thức thu thập kết quả ................................................................................72 c. Kết quả.....................................................................................................................73 d. Nhận xét ..................................................................................................................78 4.5 So sánh và kết luận chung........................................................................................80 4.6 Hướng nghiên cứu tiếp theo ....................................................................................81 4.6.1 SNA ToS (System Network Architecture Term of Service................................81 4.6.2 QoS VoIP Solution................................................................................................82 4.6.3 QoS trong streaming video ...................................................................................83 TÀI LIỆU THAM KHẢO .................................................................................................85 7 DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT AF Assured Forwarding Chuyển tiếp đảm bảo AQM Active Queue Management Quản lý hàng đợi động ARPANET Advanced Research Projects Agency Network Mạng trung tâm nghiên cứu cấp cao CA Congestion Avoidance Tránh tắc nghẽn CAR Committed Access Rate Tốc độ truy cập cam kết CBR Constant Bit Rate Tốc độ bit cố định CBS Commited Burst Size Kích thước burst cam kết CL Controlled Load Tải được điều khiển CIR Commited Information Rate Tốc độ thông tin cam kết CP Code Point Điểm mã CV Coefficient of Variation Hệ số biến thiên DiffServ Differentiated Service Dịch vụ khác biệt DNS Domain Name System Hệ thống tên miền DS Diffierentiated Service Dịch vụ khác biệt DSCP Difserv Code-Point Điểm mã dịch vụ khác biệt ECN Explicit Congestion Notification Thông báo nghẽn cụ thể EF Expedited Forwarding Chuyển tiếp ngay FCFS First Come First Server Vào trước phục vụ trước FEC Forward Error Correction Sửa lỗi trước FIFO First In First Out Hàng đợi theo nguyên tắc vào trước ra trước FF Fixed - Filter Bộ lọc cố định FTP File Transport Protocol Giao thức truyền file GTS Generic Traffic Shaping Sửa dạng lưu lượng GS Guaranteed Service Dịch vụ đảm bảo HTTP HyperText Transfer Protocol Giao thức truyền tải siêu văn bản IETF Internet Engineering Task Force Tổ chức đặc nhiệm kỹ thuật Internet IntServ Integrated Service Dịch vụ tích hợp IP Internet Protocol Giao thức Internet ISP Internet Service Provider Nhà cung cấp dịch vụ Internet LAN Local Area Network Mạng cục bộ MPLS Multi protocol lable Switching Chuyển mạch nhãn đa giao thức NFSNET National Science Foundation Network Mạng Quỹ khoa học Quốc gia NS Network Simulator Bộ mô phỏng mạng 8 OSI Open Systems Interconection Mô hình liên kết các hệ thống mở PCM Pulse Code Modulation Điều và giải điều chế mã xung PHB Per-Hop Behavior Hành vi từng chặng PIR Peak Information Rate Ngưỡng tần suất gửi QoS Quality of Service Chất lượng dịch vụ RED Random Early Detection; Random Early Drop Phát hiện sớm ngẫu nhiên Loại bỏ sớm ngẫu nhiên RFC Request For Comment Đề nghị duyệt thảo và bình luận RSVP Resource Revervation Protocol Giao thức dành trước tài nguyên RTT Round Trip Time Thời gian khứ hồi SS Slow Start Khởi động chậm SE Shared – Explicit Chia sẻ rõ ràng SLA Service level agreement Thỏa thuận mức dịch vụ SMTP Simple Mail Transfer Protocol Giao thức truyền thư điện tử đơn giản TCP Transmission Control Protocol Giao thức điều khiển truyền dẫn TDM Time Division Multiplexing Dồn kênh phân chia thời gian trTCM two rate Three Color Marking Đánh dấu 3 màu hai tốc độ TSW Time Sliding Window Cửa sổ trượt theo thời gian TOS Type Of Service Loại dịch vụ UDP User Datagram Protocol Giao thức bản tin người sử dụng WAN Wide Area Network Mạng diện rộng WF Wildcard – Filter Bộ lọc kí tự đại diện WFQ Flow-Based Weighted Fair Queuing Xếp hàng công bằng có trọng số dựa trên luồng WRED Weighted RED RED theo trọng số 9 DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ Hình 1.1: FTP truyền file giữa các hệ thống..................................................................19 Hình 2.1 : Mô hình dịch vụ tích hợp IntServ .................................................................30 Hình 2.2 Hoạt động của RSVP ......................................................................................32 Hình 2.3 Các ống chia sẻ được dành riêng ....................................................................33 Hình 2.4 Các bước của DiffServ ...................................................................................34 Hình 2.5 Miền IP ............................................................................................................35 Hình 2.6 Một miền DS và các mạng con .......................................................................35 Hình 2.7 Miền DiffServ .................................................................................................36 Hình 2.8 Vùng DS ...........................................................................................................36 Hình 2.9 Trường DS........................................................................................................38 Hình 2.10 Ví dụ về cài đặt EF ........................................................................................40 Hình 2.11 Ví dụ về DiffServ...........................................................................................42 Hình 3. 1 Thuật toán RED .............................................................................................46 Hình 3. 2 Giải thuật chi tiết của RED ............................................................................48 Hình 3. 3 Cơ chế làm việc của WRED được minh hoạ trong hình vẽ trên..................53 Hình 3. 4 Vị trí router lõi và biên trong miền DiffServ ................................................55 Hình 3. 5 Sơ đồ khối của CAR .......................................................................................58 Hình 3. 6 Lưu đồ thuật toán CAR được minh họa họa ở hình trên ..............................59 Hình 3. 7 Mô hình chiếc thùng và thẻ bài ......................................................................60 Hình 3. 8 Sơ đồ các khối chức năng của GTS ...............................................................61 Hình 4.1 Cấu trúc mô phỏng...........................................................................................64 Hình 4. 2 Tỉ lệ packet bị mất của DropTail và RED.....................................................66 Hình 4. 3 Kích thước hàng đợi của DropTail và RED..................................................67 Hình 4. 4 Thông lượng của DropTail và RED...............................................................67 Hình 4. 5 Kích thước hàng đợi của DropTail và RED..................................................68 Hình 4. 6 Thông lượng của Droptail và RED................................................................69 Hình 4. 7 Tỉ lệ packet bị mất của Droptail và RED .....................................................69 Hình 4. 8 Kích thước hàng đợi RED, WRED-TSW2CM , WRED-TSW3CM ..........72 Hình 4. 9 Kết quả so sánh thông lượng của RED với hai chính sách của WRED .....72 Hình 4. 10 Kích thước hàng đợi của RED, tsw2cm và tsw3cm (Kịch bản 2) .............73 Hình 4. 11 Kết quả so sánh thông lượng của RED với ba chính sách của WRED .....74 Hình 4. 12 Kết quả so sánh đường thông lượng trung bình của RED với ba chính sách của WRED ......................................................................................................74 10 Hình 4. 13 Kết quả so sánh đường thông lượng trung bình của RED với ba chính sách của WRED ......................................................................................................75 Hình 4.14 Kích thước hàng đợi của RED, tsw2cm và tsw3cm (Kịch bản 3) ..............76 Hình 4. 15 Kết quả so sánh thông lượng của RED với ba chính sách của WRED .....76 Hình 4. 16 Kết quả so sánh thông lượng trung bình của RED với ba chính sách của WRED.............................................................................................................77 Hình 4.17 Kiến trúc mạng TOS ......................................................................................81 Hình 4.18 Sơ đồ hệ thống VoIP trong doanh nghiệp ....................................................82 Hình 4.19 Sơ đồ hệ thống Streaming Video trong doanh nghiệp.................................83 11 DANH MỤC CÁC BẢNG Bảng 1.1 Thống kê các loại trễ từ đầu cuối đến đầu cuối ...............................................28 Bảng 2.1 Các kiểu dành riêng của RSVP.........................................................................32 Bảng 2.2 IPv4 Header 24 byte..........................................................................................37 Bảng 2.3 Trường TOS trong IPv4 header ........................................................................37 Bảng 2.4 IPv6 Header 48 byte..........................................................................................37 Bảng 2.5 Các bit IP precedence........................................................................................38 Bảng 2.6 Các chỉ thị về hiệu năng ....................................................................................38 Bảng 2.7 Các khối giá trị DSCP .......................................................................................39 Bảng 2.8 Các DSCP của AF .............................................................................................41 Bảng 4.1 Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 1........73 Bảng 4.2 Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 2........75 Bảng 4.3 Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 3........77 12 ĐẶT VẤN ĐỀ 1. Mục đích và ý nghĩa của đề tài Trong xu hướng phát triển bùng nổ thông tin ngày này, các nhu cầu về thông tin liên lạc ngày càng mở rộng, đi đôi với nhu cầu cao về chất lượng dịch vụ. Vấn đề đặt ra là làm thế nào để tăng tốc độ truyền tin, sao cho lượng thông tin có thể được chuyển tải nhanh nhất, đạt độ tin cậy cao nhất mà không xảy ra tình trạng tắc nghẽn. Vì vậy, vấn đề rất quan trọng là phải thiết kế, xây dựng các mạng, hệ thống mạng đáp ứng được các yêu cầu chung nhất nêu trên. Thông tin ở đây được gọi là “dữ liệu”. Dữ liệu được truyền đi không chỉ đơn thuần là dạng văn bản (text) đơn giản, mà là dữ liệu đa phương tiện (multimedia) bao gồm cả hình ảnh tĩnh, động (video), âm thanh (audio),… Các ứng dụng đa phương tiện phổ biến hiện nay như điện thoại qua mạng (Internet telephony), hội thảo trực tuyến (video conferencing), xem video theo yêu cầu (video on demand)... đang ngày càng được sử dụng rộng rãi. Đối với truyền thông đa phương tiện, điều quan trọng nhất là phải đảm bảo chất lượng dịch vụ (QoS), tức là đảm bảo độ trễ và biến thiên độ trễ - jitter đủ nhỏ, thông lượng đủ lớn, hệ số sử dụng đường truyền cao và tỷ lệ mất gói tin không vượt quá một mức độ nhất định có thể chấp nhận được. Để làm được điều này cần phải đồng thời áp dụng các cơ chế điều khiển lưu lượng đối với các giao thức truyền thông kiểu end-to-end (cụ thể là TCP) và những cơ chế đặc biệt thực hiện đối với mạng, cụ thể là thực hiện ở các bộ định tuyến (router). Khi có quá nhiều gói tin được đưa vào mạng (hay một phần của mạng), sẽ làm cho hiệu năng của mạng giảm đi vì các nút mạng không còn đủ khả năng lưu trữ, xử lý, truyền đi, chúng bắt đầu bị mất các gói tin dẫn đến sự tắc nghẽn trong mạng máy tính. Để tận dụng được băng thông của đường truyền, nhưng vẫn tự thích ứng được với các luồng thông tin cùng chia sẻ đường truyền chung và tránh sự tắc nghẽn mạng, giao thức TCP sử dụng các kỹ thuật: khởi động chậm – SS, tránh tắc nghẽn – CA và giảm tốc độ phát lại các gói tin bị mất do tắc nghẽn theo cấp số nhân. Thực thể TCP bên gửi duy trì một cửa sổ gọi là cửa sổ tắc nghẽn dùng để giới hạn lượng dữ liệu tối đa có thể gửi đi liên tiếp ở mức không vượt quá kích thước vùng đệm của nơi nhận khi xảy ra tắc nghẽn. Kích thước cửa sổ được tính như sau: Kích thước được phép = min (kích thước gói tin, kích thước cửa sổ tắc nghẽn) Khi bị mất một gói tin, thực thể TCP bên gửi giảm kích thước cửa sổ tắc nghẽn đi một nửa, nếu việc mất gói tin tiếp diễn, kích thước cửa sổ tắc nghẽn lại giảm tiếp theo cách trên (cho tới khi chỉ còn bằng kích thước của một gói tin). Với những gói tin vẫn còn nằm trong cửa sổ được phép, thời gian chờ để được gửi lại sẽ được tăng lên theo hàm mũ cơ số 2 sau mỗi lần phát lại. Các router cần theo dõi độ dài hàng đợi và sử dụng các tín hiệu điều khiển để thông báo với các máy tính trên mạng rằng đã hoặc sắp xảy ra tắc nghẽn để chúng có phản ứng phù hợp giúp giải quyết tình trạng tắc nghẽn. Ngoài ra chúng cũng cần có các 13 chiến lược quản lý hàng đợi thích hợp và hiệu quả để tùy vào từng trường hợp cụ thể, xử lý một cách tối ưu việc vận chuyển thông tin trong mạng. Đây là lý do tôi lựa chọn và tiến hành nghiên cứu đề tài này với sự giúp đỡ nhiệt tình của thầy giáo PGS.TS. Nguyễn Đình Việt. Trong phạm vi của đề tài luận văn tốt nghiệp – “Đánh giá hiệu quả đảm bảo QoS cho truyền thông đa phương tiện của chiến lược quản lý hàng đợi WRED”, tôi tập trung nghiên cứu chiến lược quản lý hàng đợi WRED, so sánh chiến lược này với các chiến lược quản lý hàng đợi khác từ đó có những đánh giá, đưa ra các kết quả so sánh hiệu năng giữa các mô hình. 2. Đối tượng và phạm vi nghiên cứu Đề tài tập trung nghiên cứu lý thuyết về đảm bảo chất lượng dịch vụ (QoS) và các chiến lược quản lý hàng đợi: − DROPTAIL − RED (Random Early Drop) − WRED (Weighted RED) Đề tài sử dụng bộ công cụ mô phỏng mạng NS2 để đánh giá và so sánh hiệu năng của các chiến lược quản lý hàng đợi trên. 3.Cấu trúc các chương Ngoài phần mở đầu và kết luận, nội dung của luận văn này được trình bày như sau: Chương 1: Tổng quan , Chương 2: Các mô hình đảm bảo QoS cho truyền thông đa phương tiện , Chương 3: Các phương pháp đảm bảo QoS cho truyền thông đa phương tiện, Chương 4: Đánh giá và so sánh WRED với DROPTAIL, RED. 14 Chương 1: TỔNG QUAN 1.1 Mạng Internet và các dịch vụ 1.1.1 Mạng Internet a. Lịch sử phát triển mạng Internet Từ đầu những năm 1960, đã xuất hiện các mạng xử lý trong đó các trạm cuối (terminal) thụ động được nối vào một máy xử lý trung tâm. Vì máy xử lý trung tâm làm tất cả mọi việc: quản lý các thủ tục truyền dữ liệu, quản lý sự đồng bộ của các trạm cuối,… trong khi đó các trạm cuối chỉ thực hiện chức năng nhập xuất dữ liệu mà không thực hiện bất kỳ chức năng xử lý nào nên hệ thống này vẫn chưa được coi là mạng máy tính. Giữa năm 1968, Cục các dự án nghiên cứu tiên tiến (ARPA – Advanced Research Projects Agency) của Bộ Quốc phòng Mỹ đã xây dựng dự án nối kết các máy tính của các trung tâm nghiên cứu lớn trong toàn liên bang, mở đầu là Viện nghiên cứu Standford và 3 trường đại học (Đại học California ở Los Angeless, Đại học California ở Santa Barbara và Đại học Utah). Mùa thu năm 1969, 4 trạm đầu tiên được kết nối thành công, đánh dấu sự ra đời của ARPANET, đây chính là mạng liên khu vực (WAN) đầu tiên được xây dựng. Giao thức truyền thông dùng trong ARPANET lúc đó được đặt tên là NCP (Network Control Protocol). Giữa những năm 1970, họ giao thức TCP/IP được Vint Cerf và Robert Kahn phát triển cùng tồn tại với NCP, đến năm 1983 thì hoàn toàn thay thế NCP trong ARPANET và giao thức TCP/IP chính thức được coi như một chuẩn đối với ngành quân sự Mỹ và tất cả các máy tính nối với ARPANET phải sử dụng chuẩn mới này. Trong những năm 70, số lượng các mạng máy tính thuộc các quốc gia khác nhau đã tăng lên, với các kiến trúc mạng khác nhau (cả về phần cứng lẫn giao thức truyền thông), từ đó dẫn đến tình trạng không tương thích giữa các mạng, gây khó khăn cho người sử dụng. Trước tình hình đó, vào năm 1984 tổ chức tiêu chuẩn hoá quốc tế ISO đã cho ra đời mô hình tham chiếu cho việc kết nối các hệ thống mở (Reference Model for Open Systems Interconnection - gọi tắt là mô hình OSI). Với sự ra đời của mô hình OSI và sự xuất hiện của máy tính cá nhân, số lượng mạng máy tính trên toàn thế giới đã tăng lên nhanh chóng. Đã xuất hiện những khái niệm về các loại mạng LAN, WAN... ARPANET được chia ra thành hai phần: phần thứ nhất dành cho quân sự, được gọi là MILNET; phần thứ hai là một ARPANET mới, kết nối các mạng phi quân sự, dành cho việc nghiên cứu và phát triển. Tuy nhiên hai mạng này vẫn được liên kết với nhau nhờ giao thức liên mạng IP. Tới tháng 11/1986 đã có tới 5089 máy tính được nối vào ARPANET, và đã xuất hiện thuật ngữ “Internet”. Năm 1987, mạng xương sống (backborne) NSFnet (National Science Foundation Network) ra đời với tốc độ đường truyền 1,5Mbps, nhanh hơn so với tốc độ 56Kbps trong ARPANET thời kỳ đầu đã thúc đẩy sự tăng trưởng của Internet. Mạng Internet dựa trên NSFnet đã được mở rộng ra ngoài biên giới của nước 15 Mỹ để phục vụ cho các mục đích thương mại toàn cầu. Đến năm 1990, quá trình chuyển đổi sang Internet - dựa trên NSFnet kết thúc. NSFnet giờ đây cũng chỉ còn là một mạng xương sống thành viên của mạng Internet toàn cầu. Nhiều doanh nghiệp đã chuyển từ ARPANET sang NSFNET và do đó sau gần 20 năm hoạt động, ARPANET không còn hiệu quả đã ngừng hoạt động vào khoảng năm 1990. Với khả năng kết nối mở, Internet đã trở thành một mạng lớn nhất trên thế giới, mạng của các mạng, xuất hiện trong mọi lĩnh vực thương mại, chính trị, quân sự, nghiên cứu, giáo dục, văn hoá, xã hội... Cũng từ đó các dịch vụ trên Internet không ngừng phát triển. Ngày nay khi cơ sở hạ tầng của mạng Internet được nâng cao (đặc biệt là về băng thông) đã làm cho nhu cầu sử dụng các ứng dụng đa phương tiện qua mạng tăng lên nhanh chóng. b. Giao thức tầng giao vận: TCP và UDP Bộ giao thức TCP/IP là một bộ các giao thức truyền thông mà Internet và hầu hết các mạng máy tính thương mại hiện nay đang chạy trên đó. Bộ giao thức này được đặt tên theo hai giao thức chính của nó là TCP - giao thức điều khiển giao vận và IP - giao thức liên mạng. Như nhiều bộ giao thức khác, bộ giao thức TCP/IP có thể được coi là một tập hợp các tầng, mỗi tầng giải quyết một tập các vấn đề có liên quan đến việc truyền dữ liệu, và cung cấp cho các giao thức tầng cấp trên một dịch vụ được định nghĩa rõ ràng dựa trên việc sử dụng các dịch vụ của các tầng thấp hơn. Về mặt lô-gic, các tầng trên gần với người dùng hơn và làm việc với dữ liệu trừu tượng hơn, chúng dựa vào các giao thức tầng cấp dưới để biến đổi dữ liệu thành các dạng mà cuối cùng có thể được truyền đi một cách vật lý. − TCP: là giao thức điều khiển vận chuyển, nằm ở lớp tương tự lớp Transport trong mô hình OSI và là một trong những giao thức cốt lõi của bộ giao thức TCP/IP, nhằm kết nối các máy tính trên mạng với nhau, chia sẻ và trao đổi dữ liệu. TCP hỗ trợ nhiều giao thức ứng dụng phổ biến trên Internet như HTTP, FTP, SMTP… Trong bộ giao thức TCP/IP, TCP là tầng trung gian giữa Internet Protocol (IP) bên dưới và tầng ứng dụng bên trên, là giao thức truyền dữ liệu chính xác, tin cậy. TCP đòi hỏi phải thiết lập kết nối trước khi truyền dữ liệu. Đó là quá trình bắt tay 3 bước(3-way handshake).  Bước 1: Client yêu cầu mở cổng cho một dịch vụ (ví dụ: web port 80) bằng cách gửi gói tin SYN (gói tin TCP yêu cầu kết nối) tới server (máy chủ dịch vụ web), trong gói tin SYN thì trường số thứ tự (sequence number) được gán một giá trị ngẫu nhiên X.  Bước 2: Server sẽ trả về cho Client gói tin SYN – ACK chấp nhận cho thiết lập kết nối, tham số acknowledgment được gán giá trị bằng X+1, tham số sequence number được gán một giá trị ngẫu nhiên Y.  Bước 3: Để hoàn tất quá trình thiết lập kết nối( 3 – way handshake) thì Client phải gửi cho Server thêm một gói tin là ACK tới Server, với số sequence 16 number được gán là X+1, số acknowledgment được gán là Y+1 (số Y nhận của Server) nhằm cho Server biết là đã thiết lập kết nối với Client hợp lệ. Các kết nối sử dụng TCP có 3 giai đoạn: 1. Thiết lập kết nối; 2. Truyền dữ liệu; 3. Kết thúc kết nối. TCP giải quyết nhiều vấn đề nhằm cung cấp cho ứng dụng sử dụng nó một dòng dữ liệu đáng tin cậy, cụ thể là: 1. Dữ liệu đến đích đúng thứ tự; 2. Không có lỗi (thật ra là các gói dữ liệu có lỗi được truyền lại); 3. Dữ liệu trùng lặp bị loại bỏ; 4.Điều khiển lưu lượng và điều khiển tắc nghẽn trong việc truyền và nhận dữ liệu. − UDP: là một trong những giao thức cốt lõi của bộ giao thức TCP/IP. UDP không cung cấp sự truyền tin cậy và đảm bảo đúng thứ tự truyền nhận, các gói dữ liệu có thể đến không đúng thứ tự hay bị mất mà không có thông báo cho bên gửi. Tuy nhiên UDP nhanh và hiệu quả hơn đối với các ứng dụng truyền những file kích thước nhỏ và yêu cầu khắt khe về thời gian. Do bản chất không trạng thái nên UDP hữu dụng trong việc trả lời các truy vấn nhỏ cho số lượng lớn người yêu cầu. UDP hỗ trợ việc xây dựng các dịch vụ phổ biến như DNS, streaming media, VoiIP, TFTP… UDP không thực hiện quá trình bắt tay khi gửi và nhận thông tin, do đó được gọi là connectionless (không kết nối). UDP không đảm bảo cho các tầng phía trên rằng thông điệp đã được gửi thành công, đó là đặc điểm truyền không tin cậy. UDP thích hợp với rất nhiều ứng dụng dựa vào một số đặc điểm được mô tả chi tiết hơn như sau:  Không cần thiết lập kết nối (No connection establishment): UDP không yêu cầu quá trình thiết lập kết nối như TCP, do đó nó không làm chậm quá trình truyền dữ liệu. Đó là lý do tại sao DNS lại chạy nhanh hơn khi sử dụng UDP (DNS có thể chạy cả trên TCP lẫn UDP).  Không cần lưu giữ trạng thái kết nối (No connection state): UDP không cần lưu giữ các thông tin về trạng thái hoạt động của kết nối như TCP (thí dụ: thông số gửi và nhận gói tin, ACK, sequence number, …), do đó tiêu tốn ít tài nguyên hệ thống hơn so với TCP, giúp các server có thể phục vụ nhiều client hơn.  Tổng phí cho phần tiêu đề các gói tin nhỏ hơn (Small segment header overhead): trong khi header của TCP có kích thước 20 bytes thì header của UDP chỉ có 8 bytes, làm cho gói tin UDP nhỏ hơn và có thể truyền đi nhanh hơn.  Tốc độ gửi không được điều hòa (Unragulated send rate): TCP có cơ chế điều tiết tốc tộ truyền khi gặp những đường truyền hỏng hay khi mạng bắt đầu bị tắc nghẽn, cơ chế này không thích hợp cho những ứng dụng thời gian thực (có thể chấp nhận một tỉ lệ mất gói tin nhất định, không cần phát lại để đảm bảo tính kịp thời). Trong khi đó, tốc độ phát của thực thể giao thức UDP chỉ phụ thuộc vào tốc độ gửi của ứng dụng sử dụng UDP để truyền chứ không phụ thuộc vào 17 mạng có bị tắc nghẽn (congestion ) hay không. Do đó ứng dụng có thể áp dụng các cơ chế khác nhau theo yêu cầu của nó. 1.1.2 Đặc điểm vận chuyển lưu lượng kiểu “Cố gắng tối đa ” [2] Giao thức IP cung cấp dịch vụ cố gắng tối đa, nghĩa là nó cố gắng chuyển mỗi datagram từ nguồn đến đích một cách nhanh nhất có thể. Tuy nhiên nó không đảm bảo độ trễ cũng như jitter của các gói tin. Mặt khác TCP và UDP đều chạy trên IP, chúng cũng không đảm bảo về mặt độ trễ cho các gói tin. TCP truyền tin cậy nhưng việc áp dụng cơ chế này dẫn đến việc phải phát lại các gói tin bị mất cho đến khi thành công, vì vậy có thể gây ra độ trễ rất lớn; ngoài ra việc áp dụng cơ chế cửa sổ trượt có kích thước thay đổi cũng dẫn đến jitter lớn. UDP không sử dụng cơ chế biên nhận do đó không tin cậy. Đặc điểm vận chuyển kiểu “cố gắng tối đa” của các giao thức nói trên không thích hợp cho sự phát triển các ứng dụng đa phương tiện trên Internet. Tuy nhiên, chúng đã được sử dụng phổ biến trên Internet ngay từ khi Internet mới hình thành, do đó để truyền thông đa phương tiện trên Internet người ta đã và đang áp dụng giải pháp thực tế là sửa đổi và cải tiến chúng chứ không thay thế bằng các giao thức hoàn toàn mới. Cho đến nay, các ứng dụng truyền thông multimedia sử dụng các giải pháp này đã làm tăng chất lượng dịch vụ lên đáng kể, song vẫn còn nhiều hạn chế, đòi hỏi tiếp tục được nghiên cứu, cải tiến. Chẳng hạn đối với các ứng dụng truyền audio/video được lưu trữ trước thì độ trễ trung bình trong khoảng từ 5-10s là chấp nhận được, tuy nhiên ở những thời điểm tắc nghẽn thì độ trễ có thể tăng đến mức không chấp nhận được. Đối với các ứng dụng truyền thông đa phương tiện thời gian thực kiểu có tương tác, yêu cầu về độ trễ và jitter còn cao hơn nữa, do đó các yêu cầu này thường không được đáp ứng. Người ta đã đề xuất và áp dụng một số biện pháp để cải thiện chất lượng của các ứng dụng truyền thông multimedia, như sau: - Cơ chế loại bỏ jitter ở phía nhận - Khôi phục các gói tin bị mất tại phía nhận - Nén dữ liệu audio/video - Sử dụng giao thức RTP ở tầng giao vận Dưới đây là những hạn chế của dịch vụ cố gắng tối đa: a. Tỉ lệ mất mát gói tin có thể rất lớn khi xảy ra tắc nghẽn Chúng ta xem xét một UDP segment được tạo ra bởi ứng dụng một điện thoại Internet. Nó được đóng gói trong một IP datagram và IP datagram được chuyển tới phía nhận. Datagram được truyền trên mạng qua các bộ đệm trong các router. Nếu một trong các bộ đệm của router đã đầy thì datagram sẽ không được nhận vào. Trong trường hợp này, IP datagram bị loại bỏ và coi như bị mất, không tới được phía nhận. Sự mất mát gói tin có thể được loại bỏ bằng cách gửi gói tin bằng TCP. TCP có cơ chế biên nhận nên sẽ truyền lại các gói tin bị mất. Tuy nhiên, cơ chế truyền lại nói chung là không thể chấp nhận được đối với ứng dụng thời gian thực như là điện 18 thoại Internet bởi vì nó làm tăng độ trễ. Hơn nữa, theo cơ chế điều khiển tắc nghẽn trong TCP, sau khi mất gói tin, tốc độ phát tại phía gửi có thể giảm tới mức thấp nhất, điều này ảnh hưởng nghiêm trọng tới chất lượng âm thanh tại phía nhận. Vì thế, hầu hết các ứng dụng điện thoại Internet đều chạy trên UDP và không thực hiện truyền lại các gói tin bị mất. Trên thực tế, tỉ lệ mất gói tin từ 1% tới 20% là có thể chấp nhận được, phụ thuộc vào cách âm thanh được nén sau đó được truyền đi và phụ thuộc vào cách che đậy sự mất gói tin của phía nhận như thế nào. Cơ chế sửa lỗi FEC (Forward Error Correction) có thể được dùng để che đậy sự mất gói tin. Tuy nhiên, nếu đường truyền giữa bên gửi và bên nhận bị tắc nghẽn trầm trọng, tỉ lệ mất gói tin vượt quá 10-20%, khi đó sẽ không có cách nào đạt được chất lượng âm thanh mong muốn. Đây là hạn chế của dịch vụ cố gắng tối đa. b. Độ trễ end-to-end có thể vượt quá giới hạn chấp nhận được Độ trễ end-to-end là tổng của thời gian xử lý và chờ trong hàng đợi của các router dọc theo đường truyền từ người gửi đến người nhận, thời gian truyền và thời gian xử lý của phía nhận. Với các ứng dụng tương tác thời gian thực như điện thoại Internet, độ trễ end-to-end nhỏ hơn 150ms được coi là không có vấn đề gì (giác quan con người không cảm nhận được sự khác biệt), độ trễ từ 150-400ms là có thể được chấp nhận được, độ trễ lớn hơn 400ms là quá lớn, không thể chấp nhận được. Phía nhận của ứng dụng điện thoại Internet sẽ không nhận bất kì gói tin nào đến trễ hơn một ngưỡng nhất định, ví dụ 400ms. Do đó, các gói tin đến trễ hơn ngưỡng trên thì coi như là mất. c. Jitter là không thể tránh khỏi và làm giảm chất lượng âm thanh Một trong những thành phần tạo nên độ trễ end-to-end là thời gian chờ ngẫu nhiên ở hàng đợi của router. Do thời gian chờ ngẫu nhiên này, độ trễ end-to-end có thể thay đổi đối với từng gói tin, sự biến đổi này được gọi là jitter. Ví dụ: xét 2 gói tin được sinh ra liên tiếp nhau trong một đoạn của ứng dụng điện thoại Internet. Phía gửi phát gói tin thứ 2 sau gói tin đầu 20ms. Nhưng tại bên nhận, khoảng thời gian giữa 2 lần nhận 2 gói tin đó có thể lớn hơn hoặc nhỏ hơn 20ms. Chúng ta có thể thấy rõ hơn như sau: giả sử gói tin đầu tiên tới khi hàng đợi router hầu như là rỗng, nó sẽ được truyền đi ngay, nhưng trước khi gói tin thứ hai tới thì một lượng lớn gói tin từ các nguồn khác đổ về làm đầy hàng đợi, gói tin thứ hai này được xếp vào cuối hàng đợi và phải chờ một khoảng thời gian nhất định trước khi được chuyển tiếp. Như vậy rõ ràng hai gói tin sẽ đến đích trong khoảng thời gian lớn hơn 20ms (có thể lên tới vài giây hoặc nhiều hơn). Ngược lại, giả sử gói tin đầu tới cuối hàng đợi (hàng đợi lúc đó hầu như rất đầy), gói tin thứ 2 tới hàng đợi đó và ngay sau gói tin thứ nhất. Khi đó độ lệch thời gian hai gói đến đích sẽ nhỏ hơn 20ms. 19 Nếu phía nhận bỏ qua jitter và chạy ngay đoạn âm thanh ngay khi nhận được, kết quả chất lượng âm thanh sẽ rất kém. Có thể loại bỏ jitter bằng các cách sau: đánh số số tuần tự các gói tin, gán nhãn thời gian cho các gói tin, tạm dừng chạy. 1.2 Truyền thông đa phương tiện và yêu cầu chất lượng dịch vụ (QoS) 1.2.1 Một số thí dụ về truyền thông đa phương tiện Với các ứng dụng truyền thống, dữ liệu là tĩnh (text, image…) có thể chấp nhận độ trễ và độ thăng giáng lớn nhưng không chấp nhận sự mất mát dữ liệu. Trái lại, với các ứng dụng truyền thông đa phương tiện, chủ yếu truyền dữ liệu audio, video chất lượng ứng dụng thay đổi rất nhạy với độ trễ, biến thiên độ trễ và phụ thuộc vào một số tham số mạng khác như băng thông, tỉ suất lỗi... Để hạn chế sự tổn thất gói tin trong giới hạn nhất định, ngoài các phương pháp đảm bảo QoS, các nhà sản xuất mạng đưa ra các chuẩn CODEC, giải thuật bù tổn thất gói tin như che dấu một phần hoặc hoàn toàn, các phương thức điều khiển lịch trình tái tạo gói tin của bộ đệm tái tạo tại đầu nhận. Các ứng dụng đa phương tiện được sử dụng trên Internet ngày nay rất đa dạng, đòi hỏi phải đảm bảo các thông số QoS ở mức độ khác nhau như: − Các ứng dụng đa phương tiện dạng streaming đòi hỏi phải đảm bảo về thông lượng. − Dịch vụ điện thoại IP hoặc VoIP (Voice over IP) đòi hỏi một số giới hạn chặt về trễ và biến thiên độ trễ. − Dịch vụ hội nghị truyền hình (Video Teleconferencing – VTC) đòi hỏi biến thiên độ trễ thấp. − Các đường truyền dành riêng (dedicated link) đòi hỏi phải đảm bảo cả hai yếu tố là thông lượng và hạn chế tối đa trễ và biến thiên trễ. − Một số các ứng dụng bảo vệ thiết yếu (ví dụ như thiết bị cứu hộ điều khiển từ xa) đòi hỏi độ sẵn sàng ở mức độ cao (còn gọi là hard QoS). 1.2.1.1 Ứng dụng Email, FTP Ứng dụng thư điện tử (Email): Email là một dịch vụ phổ biến nhất trên Internet trước khi World Wide Web ra đời, người sử dụng trên mạng có thể gửi email để trao đổi các thông báo cho nhau trên phạm vi thế giới một cách nhanh chóng, thuận lợi và rẻ tiền. Đây là một dịch vụ mà hầu hết các mạng diên rộng đều cài đặt và cũng là dịch vụ cơ bản nhất của một mạng khi gia nhập Internet. Trong một thời gian dài, nhiều người sử dụng máy tính tham gia mạng chỉ dùng duy nhất dịch vụ này. Dịch vụ này sử dụng giao thức SMTP (Simple Mail Transfer Protocol) trong họ giao thức TCP/IP. Đặc điểm của dịch vụ thư điện tử là không tức thời (off-line) - tất cả các yêu cầu gửi đi không đòi hỏi phải được xử lý ngay lập tức. Khi người sử dụng gửi một bức thư, hệ thống sẽ chuyển thư này vào một vùng riêng (gọi là spool) cùng với các thông tin về người gửi, người nhận, địa chỉ máy nhận... Hệ thống sẽ chuyển thư đi bằng một chương trình không đồng bộ (background). Chương trình gửi thư này sẽ xác định địa 20 chỉ IP máy cần gửi tới, tạo một liên kết với máy đó. Nếu liên kết thành công, chương trình gửi thư sẽ chuyển thư tới vùng spool của máy nhận. Nếu không thể kết nối với máy nhận thì chương trình gửi thư sẽ ghi lại những thư chưa được chuyển và sau đó sẽ thử gửi lại. Khi chương trình gửi thư thấy một thư không gửi được sau một thời gian quá lâu (ví dụ 3 ngày) thì nó sẽ trả lại bức thư này cho người gửi. Với cơ chế hoạt động như trên thì rõ ràng đối với dịch vụ E-mail không đòi hỏi yếu tố thời gian thực do vậy yêu cầu QoS đòi hỏi không quá lớn. Khi mạng xẩy ra tắc nghẽn các mail có thể không cần phải được chuyển đi, mà đợi khi mạng rỗi trở lại thì thực hiện truyền. Tuy nhiên một yêu cầu đối vơi Email đó là độ tin cậy, các gói gửi đi phải đảm bảo đến đích và nội dung cần phải chính xác hoàn toàn. Do vậy đòi hỏi mạng không làm mất gói, hoặc khi có xẩy ra mất gói thì phải có cơ chế truyền lại an toàn do vậy Email sử dụng TCP. Ứng dụng truyền file: FTP (File Transfer Protocol) là giao thức truyền một file từ một máy tính (host) này tới tới một máy tính khác trên mạng Internet. Hình dưới diễn tả tổng quan về FTP Hình 1.1: FTP truyền file giữa các hệ thống Dịch vụ FTP có những yêu cầu giống với dịch vụ Email về chất lượng truyền dẫn, nó không đòi hỏi nhiều về độ trễ hay jitter, các file có thể đến đích nhanh khi có nhiều băng thông hay chậm khi băng thông bị hạn chế nhưng điều quan trọng là toàn bộ file phải được nhận đầy đủ và không có lỗi. FTP cũng sử dụng giao thức TCP để khi có mất gói hay lỗi gói thì có sự truyền lại. 1.2.1.2 Ứng dụng truyền dòng (Streaming) âm thanh, hình ảnh lưu trước Trong các ứng dụng này, các client đưa ra yêu cầu các file âm thanh, hình ảnh nén được lưu trữ trong máy chủ. Các file âm thanh được lưu trước có thể gồm thu thanh bài giảng của một giáo sư, một bài hát, một bản giao hưởng, nội dung từ một kênh radio quảng bá, hoặc một đoạn ghi âm lịch sử. Các file video được lưu trước có thể gồm có các video về một bài giảng của giáo sư, đủ một bộ phim, các chương trình tivi đã ghi lại từ trước, phim tài liệu, các hình ảnh về các sự kiện lịch sử, các clip nhạc hình hay hoạt hình. Có ba đặc tính quan trọng để phân biệt các lớp ứng dụng này. Stored Media: các nội dung media đã được ghi trước và được lưu tại máy chủ. Do vậy, người dùng có thể tạm dừng, tua lại và tua nhanh cũng như chọn điểm xem của 21 chương trình. Thời gian từ khi một client đưa ra yêu cầu đến khi hình ảnh hiện ra tại client vào khoảng 1 tới 10 giây là có thể chấp nhận được. Streaming: Máy khách bắt đầu hiển thị các âm thanh hình ảnh sau khi nó nhận được một phần của file từ máy chủ. Có nhiều sản phẩm phần mềm phục vụ cho streaming đa phương tiện, thí dụ: RealPlayer của hãng RealNetwork và Windows Media của Microsoft. Tuy nhiên cũng có các ứng dụng như Napster yêu cầu tòan bộ file phải được dowload trước khi bắt đầu hiển thị (play). Continuous playout: Việc bắt đầu hiển thị một hình ảnh dựa vào định thời gốc của hình ảnh này (nhãn thời gian của nguồn gửi hình ảnh). Cách này tạo ra một độ trễ nhất định cho việc phân phát dữ liệu. Dữ liệu phải được nhận từ máy chủ kịp thời cho việc hiển thị ở máy khách; ngược lại thì mọi thứ trở nên vô nghĩa. 1.2.1.3 Ứng dụng Streaming cho âm thanh, hình ảnh truyền trực tiếp (live) Lớp ứng dụng này tương tự như các chương trình radio và tivi truyền quảng bá kiểu cổ điển, ngoại trừ việc truyền dẫn là thông qua Internet. Các ứng dụng này cho phép một người dùng nhận nhận chương trình radio hoặc tivi truyền trực tiếp từ bất cứ nơi nào trên thế giới. Bởi vì streaming của âm thanh hình ảnh trực tiếp không được lưu trước, một máy khách không thể tua nhanh. Hơn nữa với phần dữ liệu đã được lưu trong bộ nhớ của máy khách, thì các hành động tương tác như là dừng và tua lại là có thể thực hiện ở một số ứng dụng. Các ứng dụng truyền trực tiếp, quảng bá online thường có nhiều máy khách nhận cùng một chương trình. Việc phân bố âm thanh/ hình ảnh tới nhiều nơi nhận có thể đạt được bằng kỹ thuật multicast. Thí dụ là điện thoại Internet (Internet phone). Một thí dụ khác là hội thảo truyền hình (video conferencing), cho phép một người có thể giao tiếp bằng âm thanh và hình ảnh với một hay nhiều người khác theo phương thức thời gian thực. Đây là tương tác có cảm nhận, các thành viên tham gia có thể trao đổi với nhau thông qua tiếng nói và hình ảnh trong thời gian thực. Trong ứng dụng hội thảo truyền hình, người dùng có thể nói hoặc di chuyển bất kỳ lúc nào họ muốn. 1.2.1.4 Ứng dụng hình ảnh âm thanh tương tác thời gian thực Lớp ứng dụng này cho phép người dùng sử dụng âm thanh hình ảnh để truyền thông có tương tác với người khác theo thời gian thực. Âm thanh tương tác thời gian thực thường được đề cập tới là điện thoại Internet, theo quan điểm từ phía người dùng, nó tương đương như dịch vụ điện thoại chuyển mạch kênh cổ điển. Điện thoại Internet có thể cung cấp bằng các tổng đài nội bộ PBX, dịch vụ này tương tự điện thoại đường dài nhưng với giá cả thấp. Nó cũng cung cấp cả dịch vụ tích hợp điện thoại máy tính, kết nối nhóm thời gian thực, các dịch vụ chuyển hướng, định danh người gọi, lọc người gọi và nhiều dịch vụ khác. Hiện nay đã có nhiều sản phẩn điện thoại Internet. Với các video tương tác hay còn gọi là hội nghị truyền hình thì cũng có nhiều sản phẩm khác nhau, thí dụ NetMeeting của Microsoft. Chú ý rằng, đối với các ứng dụng âm thanh hình ảnh tương tác, một user có thể nói hoặc di chuyển bất cứ lúc nào. Với một cuộc hội thoại tương tác giữa nhiều người, trễ từ lúc một người nói và di chuyển cho tới khi hành động đó được chuyển tới đầu nhận nên nhỏ hơn một vài trăm ms. Với 22 âm thanh, độ trễ nhỏ hơn 150ms là không thể cảm nhận được đối với người nghe. Độ trễ từ 150ms tới 400ms là có thể chấp nhận được, và độ trễ lớn hơn 400ms là có thể dẫn đến cuộc hội thoại mà các bên không hiểu nhau nói gì. 1.2.1.5 Ví dụ về điện thoại VoIP Tầng IP cung cấp các dịch vụ best-effort, không đảm bảo bất cứ điều gì về độ trễ end-to-end của các gói, biến động trễ hay việc mất gói trong luồng dữ liệu. Các ứng dụng đa phương tiện tương tác thời gian thực, như là điện thoại Internet và hội nghị truyền hình thời gian thực thường rất nhạy cảm với thời gian trễ gói tin, biến thiên độ trễ (jitter) và mất gói. Chính vì vậy cần phải có các kỹ thuật để đảm bảo các ứng dụng âm thanh, hình ảnh khi truyền qua mạng mà các giá trị về trễ, jitter và mất gói không vượt quá mức quy định. Chúng ta đề cập chi tiết đến ứng dụng điện thoại Internet – VoIP dưới đây. a. Khái niệm VoIP VoIP viết tắt bởi Voice over Internet Protocol, hay còn được gọi dưới các tên khác như: Internet telephony, IP Telephony, Broadband telephony, Broadband Phone và Voice over Broadband. VoIP là một công nghệ cho phép truyền âm thanh thời gian thực qua Internet, sử dụng giao thức IP. Trong đó tín hiệu âm thanh (voice signal) từ nguồn âm sẽ được chuyển đổi thành các gói dữ liệu (data packets) IP, sau khi đến bên nhận lại được chuyển thành tín hiệu âm thanh để phát ra cho người nhận. VoIP sử dụng kỹ thuật số và yêu cầu kết nối băng thông tốc độ đủ cao như của đường truyền DSL hoặc cáp. b. Các kiểu kết nối sử dụng VoIP − Computer to Computer: Với 01 kênh truyền Internet có sẵn, là một dịch vụ miễn phí được sử dụng rộng rãi khắp nơi trên thế giới. Chỉ cần người gọi (caller) và người nhận (receiver) sử dụng chung 1 VoIP service (Skype, MSN, Yahoo Messenger,…), 2 headphone và microphone, sound card. Thời gian cho cuộc hội thoại kiểu này là không bị giới hạn. − Computer to phone: Là dịch vụ có phí. Người sử dụng phải trả tiền để có 1 account và phần mềm (thí dụ của: VDC, Evoiz, Netnam,…). Với dịch vụ này 1 máy PC có thể kết nối tới 1 máy điện thoại thông thường ở bất cứ đâu (tuỳ thuộc phạm vi cho phép trong danh sách các quốc gia mà nhà cung cấp cho phép). Người gọi sẽ bị tính phí dựa trên lưu lượng cuộc gọi và khấu trừ vào tài khoản hiện có. Ưu điểm : đối với các cuộc hội thoại quốc tế, người sử dụng sẽ tốn ít phí hơn 1 cuộc hội thoại thông qua 2 máy điện thoại thông thường. Ngoài ra còn có ưu điểm là chi phí rẻ, dễ lắp đặt. Nhược điểm: chất lượng cuộc gọi phụ thuộc vào tình trạng kết nối internet và dịch vụ của nhà cung cấp. − Phone to Phone: Là dịch vụ có phí. Người sử dụng không cần 01 kết nối Internet mà chỉ cần 1 VoIP adapter kết nối với máy điện thoại. Lúc này máy điện thoại trở thành 1 IP phone. 23 c. Các thành phần trong mạng VoIP Các thành phần cốt lõi của một mạng VoIP bao gồm: Gateway, VoIP Server, IP network và thiết bị cho người dùng (End User Equipments). − Gateway: là thành phần giúp chuyển đổi tín hiệu analog sang tín hiệu số (và ngược lại).  VoIP gateway : là các gateway có chức năng làm cầu nối giữa mạng điện thoại thường (PSTN ) và mạng VoIP.  VoIP GSM Gateway: là các gateway có chức năng làm cầu nối cho các mạng IP, GSM và cả mạng analog. (Cần đưa GSM vào bảng chữ viết tắt) − VoIP server : là các máy chủ trung tâm có chức năng định tuyến và bảo mật cho các cuộc gọi VoIP.  Trong mạng H.323 chúng được gọi là gatekeeper.  Trong mạng SIP các server được gọi là SIP server. − IP network: là mạng sử dụng giao thức IP, thường là Internet. End user equipments: Softphone và máy tính cá nhân bao gồm 01 headphone, 01 phần mềm và 01 kết nối Internet. Các phần mềm miễn phí phổ biến như Skype, Ekiga, GnomeMeeting, Microsoft Netmeeting, SIPSet,... Có thể sử dụng điện thoại thông thường nối với một IP adapter để kết nối với VoIP server. Adapter là 01 thiết bị có ít nhất 01 cổng RJ11 (để gắn với điện thoại) , RJ45 (để gắn với đường truyền Internet hay PSTN) và 01 cổng cắm nguồn. d. Phương thức hoạt động VoIP truyền tín hiệu tiếng nói thông qua mạng IP. Do vậy, trước hết giọng nói (voice) sẽ phải được chuyển đổi thành dòng bit và dòng bit này được đóng gói thành các packet để sau đó được truyền tải qua mạng IP và cuối cùng sẽ được chuyển lại thành tín hiệu âm thanh đến người nghe ở bên nhận. Tiến trình hoạt động của VoIP thông qua 2 bước: Bước 1: Thiết lập cuộc gọi (Call Setup): trong quá trình này , người gọi sẽ phải xác định vị trí (thông qua địa chỉ của người nhận) và yêu cầu một kết nối để liên lạc với người nhận. Khi địa chỉ người nhận được xác định là tồn tại trên các proxy server thì các proxy server giữa hai người sẽ thiết lập một cuộc kết nối cho quá trình trao đổi dữ liệu voice. Bước 2 Xử lý dữ liệu tiếng nói (Voice data processing): Tín hiệu giọng nói (analog) sẽ được chuyển đổi sang tín hiệu số (digital) bằng cách lấy mẫu và lượng tử hóa, sau đó được nén lại nhằm tiết kiệm băng thông đường truyền sau đó sẽ được mã hóa (tính năng bổ sung nhằm tránh các bộ phân tích mạng _sniffer ). Các mẫu bit tín hiệu tiếng nói (voice samples) sau đó sẽ được đưa vào các gói dữ liệu để được vận chuyển trên mạng. Giao thức dùng cho VoIP thường là RTP (Real-Time Transport Protocol). Một gói tin RTP có các trường ở phần tiêu đề chứa dữ liệu cần thiết cho việc biên dịch lại các gói tin sang tín hiệu voice ở thiết bị người nghe. Các gói tin 24 voice được truyền đi bởi giao thức UDP. Ở thiết bị cuối, tiến trình được thực hiện ngược lại e. Các giao thức của VoIP (VoIP Protocols) VoIP cần hai loại giao thức: Signaling protocol và Media Protocol. Giao thức Signaling protocol: điều khiển việc cài đặt cuộc gọi. Các loại signaling protocols bao gồm: H.323, SIP, MGCP, Megaco/H.248 và các loại giao thức dùng riêng như UNISTIM, SCCP, Skype, CorNet-IP,… Giao thức Media Protocol: điều khiển việc truyền tải voice data qua môi trường mạng IP. Các loại Media Protocols như: RTP ( Real-Time Protocol), RTCP (Real- Time Control Protocol), SRTP (Secure Real-Time Transport Protocol) và SRTCP (Secure RTCP). Giao thức Signaling Protocol sử dụng TCP vì cần độ tin cậy cao, trong khi giao thức Media Protocol sử dụng UDP. Các nhà cung cấp có thể sử dụng các giao thức riêng hay các giao thức mở rộng dựa trên nền của một trong hai giao thức tiêu chuẩn quốc tế là H.323 và SIP. Ví dụ Nortel sử dụng giao thức UNISTIM (Unified Network Stimulus) Cisco sử dụng giao thức SCCP (Signaling Connection Control Part). Việc sử dụng các giao thức riêng này gây khó khăn trong việc kết nối giữa các sản phẩm của các hãng khác nhau. 1.2.2 Khái niệm QoS Chất lượng dịch vụ là một vấn đề khó định nghĩa chính xác và theo cách định lượng, bởi vì nhìn từ các góc độ khác nhau người ta có thể có quan điểm về chất lượng dịch vụ khác nhau. Ví dụ, với người sử dụng dịch vụ thoại, chất lượng dịch vụ cung cấp tốt khi thoại được rõ ràng, tức là chúng ta phải đảm bảo tốt về giá trị tham số trễ, biến thiên độ trễ và giá trị tham số mất gói tin với một tỉ lệ tổn thất nào đó có thể chấp nhận được. Nhưng đối với khách hàng là người sử dụng trong truyền số liệu ở ngân hàng thì điều tối quan trọng là độ tin cậy, có thể chấp nhận trễ lớn, biến thiên độ trễ lớn, nhưng thông số mất gói tin, độ bảo mật kém thì không thể chấp nhận được. Từ góc nhìn của nhà cung cấp dịch vụ mạng, công việc đảm bảo QoS cho các dịch vụ mà họ cung cấp cho người sử dụng là thực hiện các biện pháp để duy trì các mức QoS theo nhu cầu, với cơ sở hạ tầng mạng hiện có, thỏa mãn các tiêu chuẩn như độ tin cậy, tính bảo mật và băng thông với thời gian trễ chấp nhận được... Với các dịch vụ đa phương tiện chất lượng cao như nghe nhạc, xem phim trực tuyến, VoIP,… được truyền trên mạng thì quá trình phát và nhận theo thời gian thực đòi hỏi phải triển khai một mạng có hỗ trợ việc đảm bảo chất lượng dịch vụ. ATM (Asynchronous Transfer Mode) là một giao thức được thiết kế để có thể triển khai thực hiện đảm bảo chất lượng dịch vụ ở nhiều mức. Việc triển khai chất lượng dịch vụ sử dụng mạng IP đòi hỏi phải có thêm một số dịch vụ như dành trước tài nguyên, sử dụng giao thức RSVP (Resource Reservation Protocol), cho phép băng thông có thể được đăng ký để dành trên những thiết bị mạng trung gian như bộ định tuyến. 25 Với những phân tích nêu trên, có thể định nghĩa chất lượng dịch vụ dựa trên hai quan điểm: chất lượng dịch vụ theo quan điểm đánh giá của người sử dụng cuối và chất lượng dịch vụ theo quan điểm mạng. Đối với người sử dụng, chính là sự thỏa mãn về chất lượng dịch vụ người đó nhận được từ nhà cung cấp mạng cho một loại hình dịch vụ hoặc một ứng dụng mà người đó thuê bao. Ví dụ: dịch vụ thoại, video hoặc truyền dữ liệu,... Với quan điểm mạng, thuật ngữ chất lượng dịch vụ là các cơ chế, công cụ đảm bảo cho các mức dịch vụ khác nhau thỏa mãn các tiêu chuẩn như độ tin cậy, tính bảo mật cao, băng thông đủ lớn với thời gian trễ cần thiết cho một ứng dụng đặc biệt nào đó. Thông thường, mạng thường phải truyền tải nhiều loại gói tin với các yêu cầu về hiệu năng là khác nhau. Có thể loại gói tin đó là rất quan trọng trong dịch vụ này nhưng lại không quá quan trọng trong dịch vụ khác. Vì thế một cơ chế đảm bảo chất lượng dịch vụ được triển khai trong một mạng phải xem xét đến sự xung đột các yêu cầu về hiệu năng và cân bằng các yếu tố khác nhau để đạt được sự kết hợp tốt nhất giữa chúng. 1.2.3 Yêu cầu QoS cho truyền thông đa phương tiện Ban đầu khi xây dựng mạng Internet, yêu cầu chất lượng dịch vụ cho các ứng dụng chưa được chú trọng. Vì vậy toàn bộ hệ thống mạng Internet bấy giờ hoạt động dựa trên nguyên tắc “cố gắng tối đa” – best effort. Thời kỳ đó, trong các gói tin IP người ta sử dụng 4 bits để mô tả loại dịch vụ và 3 bits để cung cấp khả năng xử lý ưu tiên cho các gói tin. Chúng không đủ để đáp ứng đủ các yêu cầu của hệ thống Internet ngày nay với các dịch vụ phát triển mạnh như âm thanh, hình ảnh, đa phương tiện,… Có rất nhiều vấn đề có thể xảy ra đối với các gói tin khi chúng di chuyển từ nguồn đến đích như: − Trễ (delay): do routers phải tìm kiếm trong bảng định tuyến, do thời gian gói tin truyền trên đường truyền. − Biến thiên độ trễ (jitter): chủ yếu do các gói tin phải chờ ở bộ đệm của các router để được chuyển tiếp hoặc phải phát lại do bị mất. Các dữ liệu dạng audio bị ảnh hưởng nhiều bởi vấn đề này. − Mất gói tin (loss packets): chủ yếu do tắc nghẽn trong mạng. Chất lượng truyền tải qua mạng sẽ bị ảnh hưởng xấu do tác động của các yếu tố chủ yếu nêu trên. Từ góc nhìn của các dịch vụ vận chuyển đầu cuối - đầu cuối, tỷ lệ tổn thất gói tin tổng cộng bao gồm tỷ lệ tổn thất trên mạng và tỷ lệ tổn thất do hủy gói tại bộ đệm bên nhận do gói tin đến trễ quá giới hạn chấp nhận được. Độ trễ tổng quát bao gồm trễ truyền qua mạng và trễ bộ đệm, gây nên do thời gian lưu gói tin tại bộ đệm chờ được tái tạo (tại bên nhận). Ngoài tỷ lệ tổn thất gói tin và độ trễ tổng quát, chất lượng tín 26 hiệu thu nhận còn phụ thuộc vào các chuẩn CODEC, giải thuật bù tổn thất gói tin và các phương thức điều khiển lịch trình tái tạo gói tin của bộ đệm tái tạo tại đầu nhận. 1.3 Các tham số hiệu năng chủ yếu của mạng liên quan đến việc đảm bảo QoS 1.3.1 Băng thông (bandwidth) Băng thông biểu thị tốc độ truyền dữ liệu cực đại có thể đạt được giữa hai điểm kết nối hay là số lượng bit trên giây mà mạng sẵn sàng cung cấp cho các ứng dụng. Nếu có băng thông đủ lớn thì các vấn đề như nghẽn mạch, kỹ thuật lập lịch, phân loại, trễ… chúng ta không phải quan tâm, nhưng điều này khó xảy ra vì băng thông của mạng là có hạn. Khi được sử dụng như một tham số của QoS, băng thông là yếu tố tối thiểu mà một ứng dụng cần có để hoạt động được, thí dụ như thoại PCM 64 kb/s cần băng thông là 64 kb/s. 1.3.2 Độ trễ (delay) và biến thiên độ trễ (jitter) a. Độ trễ (delay) Trễ liên quan chặt chẽ với băng thông. Với các ứng dụng giới hạn băng thông, băng thông càng lớn thì trễ càng nhỏ. Trễ nói ở đây là độ trễ đầu cuối- đầu cuối (end- to-end), là thời gian cần thiết để gửi một gói tin từ nguồn đến đích, nó là tổng độ trễ của việc xử lý gói tin, thời gian gói tin phải xếp hàng chờ được gửi đi tại các router, và thời gian gói tin trên đường truyền. − Trễ hàng đợi: là thời gian gói tin phải trải qua trong một hàng đợi để được truyền đi trong một liên kết khác, hay thời gian cần thiết phải đợi để thực hiện quyết định định tuyến trong bộ định tuyến. Nó có thể bằng 0 hoặc rất lớn tuỳ thuộc vào số gói tin có trong hàng đợi và tốc độ xử lý. − Trễ truyền lan: là thời gian cần thiết để môi trường vật lí truyền tín hiệu mang dữ liệu. − Trễ chuyển tiếp: là thời gian để chuyển gói tin từ một tuyến này sang một tuyến khác, hay thời gian được yêu cầu để xử lí các gói đã đến trong một nút. Ví dụ, thời gian để kiểm tra tiêu đề gói tin và xác định nút tiếp theo để gửi đi. − Trễ truyền dẫn: là thời gian để truyền tất cả các bít trong gói qua liên kết, trễ truyền được xác định thực tế trên băng thông liên kết. Các ứng dụng truyền thông đa phương tiện đòi hỏi độ trễ các gói tin nằm trong khoảng cho phép, được quy định bởi một ngưỡng cụ thể. Các nghiên cứu thực nghiệm cho biết, đối với Interent phone, nếu độ trễ nhỏ hơn 150 ms thì người nghe không nhận biết được độ trễ, nếu độ trễ nằm trong khoảng 150 đến 400 ms thì có thể chấp nhận được, nếu độ trễ vượt quá 400 ms thì cuộc đàm thoại bị hỏng hoàn toàn, vì người nhận sẽ không để ý đến bất kỳ gói tin nào bị trễ hơn ngưỡng nêu trên. Do đó, các gói tin bị trễ hơn ngưỡng cho phép, thực tế được coi là bị mất. b. Biến thiên độ trễ (Jitter) Biến thiên độ trễ là sự khác biệt về độ trễ của các gói khác nhau trong cùng một dòng lưu lượng. Nguyên nhân chủ yếu gây ra hiện tượng jitter do sự sai khác trong 27 thời gian xếp hàng của các gói liên tiếp nhau trong một hàng gây ra. Jitter là yếu tố ảnh hưởng lớn đến QoS của truyền thông đa phương tiện, tỉ lệ nghịch với QoS của truyền thông đa phương tiện. Trong các ứng dụng truyền thông đa phương tiện như Internet phone hoặc Audio on-demand, jitter có thể được hạn chế bằng cách thực hiện kết hợp ba kỹ thuật: đánh số thứ tự các gói tin (sequence number), gán nhãn thời gian (timestamp) và làm trễ việc chơi (delaying playout). Người gửi đặt một sequence number vào mỗi gói tin và tăng giá trị này lên mỗi khi một gói tin mới được tạo ra, nhờ vậy người nhận có thể dùng sequence number để khôi phục thứ tự đúng của các gói tin nhận được. Timestamp tương tự như sequence number, người gửi dán tem mỗi gói tin, tem mang thông tin về thời gian mà gói tin đó được sinh ra. Để lấy được thứ tự đúng của các gói tin từ sequence number và timestamp, người nhận cần nhận tất cả các gói tin theo thứ tự. Playout delay được sử dụng cho mục đích này. Playout delay phải đủ dài để nhận được hầu hết các gói tin trước thời điểm chúng được sử dụng. Playout delay được chia làm hai loại: cố định hoặc có thể thay đổi trong thời gian hội thảo. 1.3.3 Tỉ lệ mất mát gói tin Tỉ lệ mất gói là tỉ số của số lượng gói bị mất trên tổng số gói tin đưa vào mạng trong quá trình truyền. Mất gói tin thường do hai nguyên nhân chính: gói tin bị loại bỏ do mạng bị tắc nghẽn và do bị lỗi trên đường truyền. Với truyền thông đa phương tiện, tỉ lệ mất gói từ 10-20% có thể chấp nhận được, phụ thuộc vào tín hiệu được mã hoá và được che giấu ở phía nhận như thế nào. Tuy nhiên, trong trường hợp tắc nghẽn nghiêm trọng, sự mất mát gói tin vượt quá 20%, tín hiệu ở phía đầu nhận là khó chấp nhận ví dụ như âm thanh bị ngắt quãng, thậm chí không nghe được. Tỉ lệ mất gói tin cao làm tăng độ trễ và jitter. Truyền thoại rất nhạy cảm với việc mất gói, việc truyền lại gói của TCP thường không phù hợp vì khi phát hiện có sự mất gói tin, thực thể gửi TCP sẽ giảm tốc độ gửi xuống mức tối thiểu, có thể dẫn đến đứt đoạn tiếng nói. Vì thế hầu hết các ứng dụng truyền thông đa phương tiện không chạy trên TCP mà lại sử dụng UDP, trong đó không có các cơ chế điều khiển tắc nghẽn và khắc phục lỗi như trong TCP. 1.3.4 Một số tham số khác: a. Tính sẵn sàng – độ tin cậy Để xác định độ ổn định của hệ thống người ta thường xác định độ khả dụng của hệ thống, nhìn từ khía cạnh mạng thì nó chính là độ tin cậy của hệ thống. Độ khả dụng của của mạng càng cao nghĩa là độ tin cậy của mạng càng lớn và độ ổn định của hệ thống càng lớn. Độ khả dụng của mạng thường được tính trên cơ sở thời gian ngừng hoạt động và tổng thời gian hoạt động. Ví dụ, độ khả dụng của các hệ thống chuyển mạch gói hiện nay là 99,995% thì thời gian ngừng hoạt động trong một năm vào khoảng 26 phút. 28 b. Bảo mật Bảo mật là một thông số mới trong danh sách QoS, nhưng lại là một thông số quan trọng. Thực tế, trong một số trường hợp độ bảo mật có thể được xét ngay sau băng thông. Gần đây, do sự đe dọa thường xuyên của các hacker và sự lan tràn của virus trên mạng Internet toàn cầu đã làm cho bảo mật trở thành một trong các vấn đề hàng đầu. Hầu hết các công cụ và chính sách bảo mật đều liên quan tới tính riêng tư, sự tin cậy và xác thực khách và chủ. Các công cụ và chính sách bảo mật thường được gắn với các phương pháp mật mã (gồm cả mã hoá và giải mã). Các phương pháp mật mã cũng được sử dụng trên mạng cho việc xác thực, nhưng các phương pháp này thường không liên quan đến giải mã. Hiện nay, giao thức bảo mật chính thức cho mạng IP là IPSec – IP Security hỗ trợ bảo mật trong thương mại điện tử trên Internet và ngăn ngừa gian lận trong môi trường VoIP. Một bit trong trường loại dịch vụ (ToS) trong phần tiêu đề gói IP được đặt riêng cho ứng dụng để bảo mật khi chuyển mạch gói. Tuy nhiên, có một vấn đề thực tế là không có sự thống nhất giữa các nhà sản xuất bộ định tuyến khi sử dụng trường ToS. Người sử dụng và ứng dụng có thể thêm phần bảo mật của riêng mình vào mạng và thực tế cách này đã được thực hiện trong nhiều năm. Nếu có bảo mật thì thường dưới dạng một mật khẩu truy nhập vào mạng. Một thông số QoS bảo mật điển hình hiện nay là "mã hoá và xác thực đòi hỏi trên tất cả các luồng lưu lượng". Vì vậy khi truyền dữ liệu đã được mã hoá, kết nối điện thoại Internet chỉ cần xác thực để ngăn chặn gian lận. 29 Kết luận chương Chương I nói về tổng quan chất lượng dịch vụ trong mạng IP. Trình bày khái niệm chất lượng dịch vụ, các tham số của QoS với những đặc tính kỹ thuật của nó. Từ đó kết luận, QoS có thể giúp giải quyết một số vấn đề như: mất gói, jitter, và xử lý trễ. Nhưng một số vấn đề mà QoS không thể giải quyết được như là trễ lan truyền, trễ do mã hóa, giải mã và trễ do số hóa. Điều quan trọng là phải biết phần nào không thể thay đổi và phần nào có thể điều khiển được theo như bảng 1-2 (trích tài liệu: Tiêu chuẩn G.114 “One-way transmission time”). Trễ cố định Trễ thay đổi Trễ cố định Trễ thay đổi Trễ mã hóa G.729 (5 ms) 5 ms Trễ mã hóa G.729 (10 ms/frame) 20 ms Trễ đóng gói bao gồm trong trễ mã hóa Trễ xếp hàng trên trung kế 64 kbps 6 ms Trễ chuyển nối tiếp trên trung kế 64 kbps 3ms Trễ truyền lan (trên các dây riêng) 32ms Trễ mạng (Vd Frame Relay) Đệm loại bỏ Jitter 2-200ms Tổng cộng – Giả sử Jitter Buffer 50 ms 110ms Bảng 1. 1 Thống kê các loại trễ từ đầu cuối đến đầu cuối 30 Chương 2: CÁC MÔ HÌNH ĐẢM BẢO QoS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN Chương này trình bày hai mô hình triển khai đảm bảo chất lượng dịch vụ (QoS) khác nhau ở mức liên mạng (IP), đó là: IntServ và DiffServ. Mỗi mô hình sẽ có những đặc điểm riêng để phù hợp với những yêu cầu chức năng IP QoS của các loại dịch vụ như đã trình bày trong chương 1. Trong khi mô hình IntServ đi theo hướng dành trước tài nguyên thì DiffServ thì đi theo hướng phân lớp lưu lượng và đưa ra các ứng xử khác nhau với các lưu lượng khác nhau. 2.1 Mô hình IntServ (Integrated Service) 2.1.1 Tổng quan Dịch vụ tích hợp đi theo hướng hỗ trợ việc dành trước tài nguyên cho các luồng lưu lượng. Trái ngược với kiến trúc chuyển phát datagram (các gói sẽ đi qua các tuyến khác nhau tại mọi thời điểm chúng được gửi), dịch vụ tích hợp cho phép dành toàn bộ một tuyến cho luồng dữ liệu. Điều này được thực hiện bởi việc thiết lập một tuyến dành trước tài nguyên trước khi gửi dữ liệu. Thực chất của mô hình này là các bộ định tuyến và các thiết bị mạng phải dành trước tài nguyên của nó để cung cấp các mức chất lượng dịch vụ tùy theo nhu cầu của người sử dụng. Điều này yêu cầu các bộ định tuyến phải có khả năng điều khiển các luồng lưu lượng. Có hai dịch vụ được định nghĩa: − Dịch vụ có đảm bảo - Guaranteed Service (GS) : GS cung cấp các dịch vụ chất lượng cao như: Dành riêng băng thông, giới hạn độ trễ tối đa và không bị mất gói tin trong hàng đợi. Các ứng dụng có thể kể đến: Hội nghị truyền hình chất lượng cao, thanh toán tài chính thời gian thực,... − Dịch vụ kiểm soát tải - Controlled Service (CL): CL không đảm bảo về băng thông hay trễ, nhưng khác với các dịch vụ kiểu “Best Effort” ở điểm không giảm chất lượng một cách đáng kể khi tải mạng tăng lên. Dịch vụ này phù hợp cho các ứng dụng không nhạy cảm lắm với độ trễ hay mất gói như truyền hình multicast audio/video chất lượng trung bình. Trong IntServ, một luồng IP riêng biệt được nhận dạng bởi 5 thông số sau: − Nhận dạng giao thức − Địa chỉ IP đích − Địa chỉ cổng đích − Địa chỉ IP nguồn − Địa chỉ cổng nguồn IntServ sử dụng giao thức RSVP (Resource Reservation Protocol) cho việc đặt trước tài nguyên cho một luồng, bao gồm một mô tả đặc trưng lưu lượng và các yêu cầu dịch vụ. Mô tả lưu lượng bao gồm tốc độ đỉnh, tốc độ trung bình, kích cỡ lưu 31 lượng bùng phát và các yêu cầu dịch vụ bao gồm băng thông nhỏ nhất được yêu cầu và các yêu cầu hiệu năng khác như trễ, jitter và tỷ lệ mất gói. Nếu có cam kết việc dự phòng, luồng đó được đưa vào bảng dự phòng tài nguyên. Khi gói tin đến, khối nhận dạng luồng sẽ nhận dạng gói tin thuộc về luồng đặt trước và đặt chúng vào trong hàng đợi phù hợp để nhận được dịch vụ yêu cầu. Trong quá trình truyền từ nguồn tới đích gói tin phải đi qua nhiều chặng. Việc lựa chọn đường dẫn phù hợp cho chặng kế tiếp tại một nút là nhiệm vụ khó khăn do các hạn chế trong định tuyến IP truyền thống. Đường dẫn cần được lựa chọn có thể đã đáp ứng được yêu cầu định ra. Tuy nhiên, định tuyến IP thường sử dụng các số đo như trễ, chặng (hop) hay một số thông số khác để tính toán đường đi ngắn nhất. Do vậy đường dẫn ngắn nhất có thể không có khả năng chấp nhận việc đặt trước tài nguyên trong khi đó đường dẫn dài hơn lại có khả năng đó. Vấn đề định tuyến có thể trở nên phức tạp bởi một số ứng dụng yêu cầu nhiều tham số QoS (ví dụ về băng thông và các yêu cầu về tỉ lệ mất gói tin). Tìm kiếm đường dẫn phù hợp trong nhiều điều kiện ràng buộc rất phức tạp. Chính vì lí do đó mô hình đảm bảo QoS cho gói tin IP đầu tiên này không yêu cầu gắn các cơ chế định tuyến đảm bảo QoS trong kiến trúc IntServ. Kiến trúc này giả sử rằng khối chức năng định tuyến của bộ định tuyến sẽ thực hiện định tuyến từng bước (hop by hop). 2.1.2 Kiến trúc IntServ Intserv có 4 thành phần, thành phần điều khiển việc chấp nhận luồng mới, thành phần phân loại, lập lịch gói (3 thành phần này cung cấp việc điều khiển lưu lượng) và giao thức dành trước tài nguyên. Hình 2.1 : Mô hình dịch vụ tích hợp IntServ 2.1.2.1 Điều khiển chấp nhận Xử lí hai nhiệm vụ cơ bản là chấp nhận hay từ chối các yêu cầu dành trước tài nguyên và giám sát việc sử dụng tài nguyên. Việc dành trước tài nguyên cho một yêu cầu mới sẽ không thể được chấp nhận nếu không có sẵn tài nguyên theo yêu cầu. Có 32 hai hướng tiếp cận để giải quyết xem tài nguyên nào là sẵn sàng đó là dựa theo đo đạc và dựa theo tham số. − Trong hướng tiếp cận dựa theo tham số, điều khiển chấp nhận sẽ tính toán các nguồn tài nguyên khả dụng dựa trên các chỉ tiêu kỹ thuật và yêu cầu dành trước tài nguyên hiện tại. − Trong hướng tiếp cận theo đo đạc, điều khiển chấp nhận đo lưu lượng thực sự trong mạng và sử dụng các phương pháp thống kê để quyết định xem tài nguyên nào khả dụng. Hướng tiếp cận này có ưu điểm là tối ưu hoá việc sử dụng mạng, mặc dù không đảm bảo chặt chẽ các cam kết tài nguyên. 2.1.2.2 Nhận dạng luồng RSVP sử dụng 5 trường trong tiêu đề trong gói tin IP để nhận dạng gói tin thuộc về các luồng dành trước tài nguyên trong nút. Các trường này bao gồm địa chỉ IP nguồn, địa chỉ IP đích, định danh giao thức, cổng nguồn và đích. 2.1.2.3 Lập lịch gói Là bước cuối cùng trong việc dành trước tài nguyên. Bộ lập lịch gói tin thực hiện việc cấp phát tài nguyên. Nó quyết định gói tin nào sẽ gửi kế tiếp khi tuyến kết nối đi đã sẵn sàng. Do đó nó tác động đến trễ mà gói tin phải chịu trong bộ định tuyến và bộ định tuyến không trực tiếp loại bỏ gói tin. 2.1.2.4 Các dịch vụ của IntServ Mô hình dịch vụ IntServ có thể sử dụng giao thức báo hiệu RSVP cung cấp nhiều loại hình dịch vụ khác nhau. − Guaranteed Rate Service: loại hình này cho phép dành sẵn độ rộng băng thông để phù hợp với những yêu cầu của chúng. Ví dụ ứng dụng VoIP có thể dành 32 Mbps từ đầu cuối đến đầu cuối sử dụng loại hình dịch vụ này. QoS sử dụng xếp hàng cân bằng trọng số (WFQ) kết hợp với giao thức dành sẵn tài nguyên (RSVP) để cung cấp loại hình dịch vụ này. − Controlled Load Service: loại hình này cho phép các ứng dụng có độ trễ thấp và tốc độ lưu lượng cao thậm trí ngay cả khi tắc nghẽn. Ví dụ các ứng dụng không nhạy cảm với thời gian thực như khi phát lại băng ghi âm cuộc hội thoại có thể sử dụng loại hình dịch vụ này. QoS sử dụng RSVP kết hợp với Weighted Random early Detect (WRED) cung cấp loại hình dịch vụ này. 2.1.3 Giao thức dành trước tài nguyên - RSVP 2.1.3.1 Tổng quan RSVP được định nghĩa trong chuẩn RFC 2205. RSVP là một giao thức thiết lập dành riêng cho IP QoS. Nó hỗ trợ cả IPv4 và IPv6 và thích hợp cho cả multicast và unicast IP. Trong RSVP, tài nguyên được dành riêng cho mỗi một định hướng cụ thể. Các trạm nguồn và đích trao đổi bản tin RSVP để thành lập phân lớp dịch vụ và trạng thái chuyển tiếp tại mỗi nút. Nguồn khởi tạo yêu cầu dành riêng nhưng việc xác 33 định các tài nguyên sẵn sàng và sự dành riêng thực tế bắt đầu từ đầu cuối thu. Trạng thái của tài nguyên dành riêng tại các node RSVP không cố định và được thay đổi một cách định kỳ. RSVP không phải là một giao thức định tuyến. Các bản tin RSVP có hướng giống với hướng các gói IP được xác định bởi các bảng định tuyến trong các router IP. RSVP cung cấp một vài kiểu dành riêng. RSVP là một giao thức phức tạp. Do mỗi một nút trên tuyến phải giữ trạng thái dành riêng, với các mạng lớn, RSVP trở thành không thực tế, bởi không có khả năng mở rộng tùy ý. 2.1.3.2 Hoạt động của RSVP Một phiên RSVP thường được định nghĩa bởi ba tham số sau: − Địa chỉ đích − Nhận dạng giao thức − Cổng đích Hình 2.2 Hoạt động của RSVP Hình trên chỉ ra hoạt động của RSVP. Phía trạm phát (Host nguồn) gửi đi một bản tin PATH tới trạm đích với một luồng hay một “phiên”. Bản tin PATH bao gồm một chỉ thị luồng xác định cho luồng đó Khi bản tin PATH đi qua các router trên một tuyến, các router đăng ký nhận dạng luồng và chỉ thị luồng này. Khi bản tin PATH đến trạm đích, nó sẽ gửi trở lại bản tin RESV mang thông tin về các tài nguyên được các router chấp nhận đặt trước. Các gói IP của luồng gửi đi theo hướng của bản tin PATH. 2.1.3.3 Các kiểu RSVP dành trước tài nguyên Có ba loại kiểu dành riêng được định nghĩa trong chuẩn RFC 2205 như đã chỉ ra trong bảng dưới đây. Sự dành riêng Lựa chọn người gửi Riêng biệt Chia sẻ Toàn bộ Bộ lọc cố định (FF) Chia sẻ rõ ràng (SE) Lựa chọn Không định nghĩa Bộ lọc kí tự đại diện(WF) Bảng 2.1 Các kiểu dành riêng của RSVP 34 Điều khiển người gửi sẽ điều khiển lựa chọn những người gửi. Hai kiểu điều khiển người gửi đã được định nghĩa. Trong kiểu lựa chọn cụ thể, một dãy “cụ thể” tất cả những người gửi được lựa chọn được chỉ ra. Trong lựa chọn bất kỳ, tất cả những người gửi đến phiên đều được lựa chọn. Điều khiển chia sẻ điều khiển việc xử lý dành riêng cho những người gửi khác nhau trong cùng một phiên. Hai kiểu điều khiển chia sẻ được định nghĩa. Trong kiểu dành riêng riêng biệt, việc dành riêng được thực hiện cho mỗi đường lên của người gửi. Trong kiểu dành riêng được chia sẻ, tài nguyên dành riêng được chia sẻ bởi nhiều đường lên của các người gửi. Hình 2.3 Các ống chia sẽ được dành riêng Như đã chỉ ra trong bảng Các kiểu dành riêng của RSVP, có bốn sự kết hợp chia sẻ điều khiển và điều khiển lựa chọn người gửi có thể xảy ra. Tuy nhiên, một trong bốn sự kết hợp này chưa được định nghĩa. Ba kiểu còn lại là kiểu Fixed – Filter, kiểu Shared – Explicit (SE) và kiểu Wildcard – Filter (WF). Hình Các ống chia sẽ được dành riêng chỉ ra một băng thông “pipe” được dành riêng được chia sẻ bởi nhiều người gửi. 2.2 Mô hình DifServ (Differentiated Service) Việc đưa ra mô hình IntServ có vẻ như giải quyết được nhiều vấn đề liên quan đến QoS trong mạng IP. Tuy nhiên trong thực tế mô hình này đã không đảm bảo được QoS xuyên suốt (end to end), do tính khả mở (Scalability) kém. Đã có nhiều cố gắng nhằm thay đổi điều này nhằm đạt một mức QoS cao hơn cho mạng IP, và một trong những cố gắng đó là sự ra đời của DiffServ (xem mô hình Differentiated Service) Phần này trình bày các vấn đề sau: − Kiến trúc các dịch vụ phân biệt (DiffServ) − Đánh dấu gói trong mô hình DiffServ 35 − Các điểm mã DiffServ (DSCP’s) − Thực hiện theo từng chặng (PBH) 2.2.1 Tổng quan Ở DiffServ, các luồng lưu lượng riêng biệt không được tách biệt mà được tổ hợp lại thành một số lớp lưu lượng. Trong DiffServ, băng thông và các tài nguyên mạng khác được cấp phát cho các lớp lưu lượng mà không dành cho các luồng riêng biệt. Trọng tâm chính của DiffServ là dựa trên miền DS mà không phải là các đường đi end to end của gói tin. Thuật ngữ “DiffServ” mô tả toàn bộ việc xử lý lưu lượng của khách hàng cùng với một mạng của nhà cung cấp dịch vụ và định nghĩa dịch vụ mà khách hàng có thể trông đợi từ nhà cung cấp dịch vụ, ví dụ một nhà cung cấp Internet – ISP (Internet Service Provider). Một dịch vụ DiffServ được định nghĩa dựa theo thỏa thuận mức dịch vụ - SLA (Service Level Agreement) giữa một khách hàng (ví dụ, một ứng dụng khách hàng có thể là VoIP, TCP, vv…) và một mạng của nhà cung cấp dịch vụ DiffServ. Hình 2.4 Các bước của DiffServ Một DiffServ được định nghĩa bằng thuật ngữ của các tham số mà khách hàng hiểu như thỏa thuận điều kiện lưu lượng -TCA (Traffic Condition Ageement), các hồ sơ lưu lượng (ví dụ, các tham số gáo rò – Licky Bucket), thông số hiệu năng (ví dụ thông lượng, trễ, ưu tiên loại bỏ), bằng cách đó các gói không được cấu hình sẽ bị xử lý, và thêm vào đánh dấu và định dạng của lưu lượng. Hình 2.4 chỉ ra các bước cơ bản trong việc cung cấp các dịch vụ DiffServ. Các gói khách hàng đến tại router có đánh dấu (hoặc không) DSCP. Router kiểm tra DSCP của các gói và phân lớp các gói bằng phương thức kết hợp hành vi – BA (Behavior Aggregation). 36 2.2.2 Cấu trúc DiffServ Nhìn chung, một miền trong mạng IP thường tương ứng với một khu vực địa lý có ranh giới xung quanh và có một chính sách nhất định hoặc khả năng có thể thực hiện được. Một miền IP là một mạng IP chịu sự điều khiển của một nhà quản lý có thẩm quyền. Một miền IP có thể bao gồm một vài mạng, có thể phân tán về mặt địa lý nhưng cùng được quản lý bởi một nhà quản trị. Hình 2.5 Miền IP Hình 2.6 Một miền DS và các mạng con Một mạng IP có thể coi là một DS, nếu nó có khả năng cung cấp dịch vụ DiffServ. Một miền IP có thể có một phần là DS và một phần không phải DS. Một miền DS là một phần có chức năng DS của miền IP. Hình 2.5 minh họa một miền IP mà bao gồm cả miền DS và không phải miền DS 37 Hình 2.7 Miền DiffServ Hình 2.8 Vùng DS Hình 2.7 chỉ ra một miền DS và các phần tử chính của nó. Miền DS gồm các nút ở biên và các nút bên trong. Các nút ở biên lại bao gồm các “Node vào” và các “Node ra”. Các nút ở biên thực hiện chức năng giám sát lưu lượng đưa vào miền DS... Thuật ngữ khóa được sử dụng trong việc mô tả cấu trúc DS đã được định nghĩa trong chuẩn RFC 2457. Một node IP hay thiết bị được gọi là “DS–compliant” nếu nó hỗ trợ DifServ. Hình 2.8 chỉ ra một vùng DS, bao gồm một hoặc nhiều hơn các miền DS tiếp giáp phụ thuộc các quyền hạn hành chính khác. Vì thế, một vùng DS có thể cung cấp DiffServ qua các tuyến IP mở rộng qua các mạng dưới nhiều quyền hạn. Nhìn chung, các miền DS riêng biệt hoạt động với chính sự giám sát của chúng và PHB, mỗi miền DS có thể sử dụng DSCP của riêng nó. Để cung cấp DiffServ qua một số vùng DS, các miền DS phải thiết lập một SLA tại giao diện giữa các miền DS này. 38 2.2.3 Đánh dấu gói DiffServ DiffServ sử dụng trường Kiểu dịch vụ (ToS) của tiêu đề Ipv4 và trường lớp lưu lượng (TC) của tiêu đề IPv6 cho đánh dấu các gói. Khi các router IPv4 và IPv6 hoạt động theo phương thức thông thường và không nhận ra các thông tin DiffServ trong phần tiêu đề gói tin, các trường ToS và TC được sử dụng như đối với các gói tin bình thường khác. Bảng 2.2 IPv4 Header 24 byte 2.2.3.1. Đánh dấu gói trong các router thông thường. Bảng 2.2 là cấu trúc gói tin IPv4, trong đó có thể thấy trường ToS 8 bit có thể được sử dụng cho các thông tin DiffServ. Trong một router thông thường (router không hỗ trợ DiffServ) 8 bit của trường ToS được định nghĩa theo chuẩn RFC 791. Ba bit đầu tiên (bit 0, 1, 2) được dành cho việc xác lập mức ưu tiên của gói tin IP, như mô tả trên Bảng 2.5. Thí dụ RFC 791 chỉ rõ rằng gói tin điều khiển mạng, với 3 bit đầu của trường ToS bằng 111 chỉ được sử dụng với một mạng riêng; và gói tin với 3 bit đầu của trường ToS bằng 110 chỉ được thiết lập bởi người quản trị gateway. Precedence D T R 0 0 3 bit 1 bit 1 bit 1 bit 1 bit 1 bit Bảng 2.3 Trường TOS trong IPv4 header Bảng 2.4 IPv6 Header 48 byte 39 Ba bit tiếp theo (bit 3, 4, 5) được mô tả trên Bảng 2.6, định nghĩa các đặc điểm liên quan đến hiệu năng và QoS. Bảng 2.6 chỉ ra cách thiết lập D-bit, T-bit, và R-bit của trường ToS và các ý nghĩa tương ứng. Hai bit cuối cùng (bit 6 và 7) của trường ToS được dành cho tương lai. Các bit IP Precedence Kiểu lưu lượng 111 Điều khiển mạng 110 Điểu khiển kết nối liên mạng 101 Khẩn cấp 100 Ghi đè Flash 011 Flash 010 Trung bình 001 Ưu tiên 000 Thông thwờng Bảng 2.5 Các bit IP precedence Thiết lập Bit Bit D Bit T Bit R 0 Trễ thường Lưu lượng thường Độ tin cậy thường 1 Trễ nhỏ Lưu lượng cao Độ tin cậyc cao Bảng 2.6 Các chỉ thị về hiệu năng Hình 2.9 Trường DS Bảng 2.4 mô tả tiêu đề gói tin IPv6. Nó bao gồm 8 trường, trong đó trường lớp lưu lượng - TC (Traffic Class) dài 8 bit, trường nhãn luồng FL (Flow Label) dài 20 bit. Cả hai trường này đều thích hợp cho việc thực hiện đảm bảo QoS. Tuy nhiên, cho đến thời điểm hiện nay, không có các ứng dụng quan trọng nào trên Internet sử dụng trường FL. Còn trường TC cung cấp khả năng tương tự như trường ToS của tiêu đề gói tin IPv4. 2.2.3.2.Trường DiffServ (DS) Khi một router được sử dụng cho DiffServ như một nút DS, các trường 8 bit như trường ToS trong IPv4 và trường TC trong IPv6, được router ghi đè như trường 40 DiffServ (DS). Hình 2.9 mô tả việc ghi đè này. Trong 8 bit của trường DS, 6 bit được sử dụng cho việc đánh dấu các gói DiffServ và hai bit cuối hiện chưa được định nghĩa, để dành cho tương lai. 6 bit được sử dụng cho đánh dấu các gói DiffServ được gọi là điểm mã DS (DSCP – DS Code Point). Vì vậy, đánh dấu các gói trong DiffServ chính là việc thiết lập giá trị các bit thuộc DSCP. Sáu bit trong trường DSCP có thể cung cấp 64 giá trị DSCP khác nhau. RFC 2474 phân chia 64 giá trị DSCP thành 3 nhóm như trong bảng 2.7. Dải (nhóm) Không gian mã điểm Chính sách gán 1 xxxxx0 Hoạt động chuẩn 2 xxxx11 Thí nghiệm 3 xxxx01 Thí nghiệm Bảng 2.7 Các khối giá trị DSCP Bit cuối cùng (ví dụ , bit thứ 6) của nhóm DSCP thứ nhất được ấn định là bit 0. Năm bit khác của nhóm DSCP này có thể là bit 0 hoặc bit 1. Vì thế, nhóm 1 có 32 giá trị DSCP khác nhau. Nhóm DSCP thứ nhất yêu cầu các hoạt động theo tiêu chuẩn của IETF và được nhận dạng phổ biến. Nhóm DSCP 2 có 2 bít cuối được ấn định là “11”. 4 bit còn lại được phép nhận các giá trị khác nhau, như vậy tổng cộng có 16 giá trị DSCP thuộc nhóm 2. Nhóm DSCP 2 không yêu cầu các hoạt động tiêu chuẩn và được sử dụng cho thử nghiệm và các mục đích nội bộ. Các gói DiffServ được truyền trong một mạng nội bộ riêng có thể được đánh dấu bởi nhóm DSCP 2, các gói thuộc nhóm này không được nhận dạng bên ngoài mạng nội bộ. Nhóm DSCP 3 luôn luôn kết thúc với “01”, nhóm này cũng có 16 giá trị DSCP khác nhau như nhóm 2. Nhóm này được dành cho việc thử nghiệm và sử dụng trong mạng nội bộ; tuy nhiên điểm khác biệt so với nhóm 2 là nhóm DSCP 3 có thể sử dụng cho các hoạt động tiêu chuẩn nếu cần thiết. 2.2.4 Hành vi theo từng chặng (PHB) DiffServ sử dụng phương pháp phân loại kết hợp hành vi BA. Trong phương pháp phân loại này, các gói được phân loại chỉ dựa trên các giá trị DSCP và không có các tham số khác. Bằng việc các gói được xử lý tại mỗi router dẫn đến việc dễ dàng mở rộng mạng DS. Một PHB mô tả kỹ thuật bên trong một mạng và không tuân theo người sử dụng đầu cuối. Có hai kiểu PHB tiêu chuẩn: PHB chuyển tiếp nhanh (EF) và PHB có đảm bảo (AF). 2.2.4 .1 PHB chuyển tiếp nhanh (Expedited Forwarding) PHB chuyển tiếp nhanh (EF) được xác định ban đầu bởi chuẩn RFC 2598, mà sau đó được thay thế bởi chuẩn RFC 3246. Giá trị DSCP được đề nghị cho PHB EF là “101110”. Với PHB EF, các gói được chuyển tiếp với tổn hao thấp, trễ thấp và jitter 41 thấp. PHB EF yêu cầu một số lượng cổng đầu ra kết nối băng thông đủ lớn để làm cho trễ thấp, tổn hao thấp và jitter thấp. PHB EF có thể thực hiện được nếu cổng đầu ra kết nối băng thông đủ lớn cộng với kích cỡ bộ đệm nhỏ và các tài nguyên mạng khác được dành cho các gói EF cho phép tốc độ phục vụ µ của router đối với các gói EF trên một cổng đầu ra vượt quá tốc độ đến λ của các gói tin tại cổng đó. Điều này có nghĩa là các gói với PHB EF được xem xét với một số lượng đã cấp phát trước băng thông đầu ra và một ưu tiên bảo đảm tổn hao cực tiểu, trễ cực tiểu và jitter cực tiểu trước khi đưa vào hoạt động. PHB EF thích hợp cho mô phỏng kênh, mô phỏng đường dây được thuê riêng, và các dịch vụ thời gian thực như thoại, video mà không bỏ qua các giá trị tổn hao, trễ và jitter cao. Hình 2.10 Ví dụ về cài đặt EF Hình 2.10 chỉ ra một ví dụ về sự thực hiện PHB EF. Đây là một kỹ thuật lập lịch hàng đợi ưu tiên đơn giản. Tại các biên của miền DS, các lưu lượng gói EF được ưu tiên tùy theo các giá trị đã thỏa thuận bởi SLA. Hàng đợi EF trong hình cần đưa các gói tin ra với tốc độ µ cao hơn tốc độ đến λ của các gói tin. Để cung cấp PHB EF qua một miền DS kiểu end-to-end, băng thông tại các cổng đầu ra của các router lõi cần được cấp phát trước đó để đảm bảo yêu cầu μ > λ. Việc này có thể thực hiện bởi một quá trình cấu hình dự phòng từ trước. Trong hình, các gói EF được đặt tại hàng ưu tiên (hàng đợi bên trên). Với chiều dài như vậy, hàng đợi có thể hoạt động với μ > λ. Do EF được sử dụng trước tiên cho các dịch vụ thời gian thực như thoại và video và do các dịch vụ thời gian thực sử dụng UDP thay thế cho TCP, RED nhìn chung 42 không thích hợp cho các hàng đợi EF bởi vì các ứng dụng sử dụng UDP sẽ không đáp ứng cho loại bỏ gói ngẫu nhiên và RED sẽ tách các gói không cần thiết. 2.2.4.2 PHB chuyển tiếp đảm bảo (AF) PHB AF được xác định bởi RFC 2597. Mục đích của PHB AF là để phân phối các gói tin cậy và vì thế trễ và jitter được coi là không quan trọng bằng mất gói. PHB AF thích hợp cho các dịch vụ không phải thời gian thực như các ứng dụng sử dụng TCP. PHB AF trước tiên định nghĩa 4 lớp: AF1, AF2, AF3, AF4. Cùng với mỗi một trong những lớp AF này, các gói sau đó được phân lớp thành ba lớp con với ba mức ưu tiên tách biệt. Bảng 2.8 chỉ ra bốn lớp AF và 12 lớp AF con và các giá trị DSCP cho 12 lớp con AF được xác định bởi RFC 2597. RFC 2597 cũng cho phép thêm vào nhiều hơn ba mức ưu tiên tách biệt cho sử dụng nội bộ. Tuy nhiên, những mức ưu tiên tách ra này sẽ chỉ có ý nghĩa trong nội bộ. Lớp PHB Lớp con PHB Loại gói DSCP AF41 Thấp 100010 AF42 Trung bình 100100 AF4 AF43 Cao 100110 AF31 Thấp 011010 AF32 Trung bình 011100 AF3 AF33 Cao 011110 AF21 Thấp 010010 AF22 Trung bình 010100 AF2 AF23 Cao 010110 AF11 Thấp 001010 AF12 Trung bình 001100 AF1 AF13 Cao 001110 Bảng 2.8 Các DSCP của AF PHB AF đảm bảo rằng các gói được chuyển tiếp đi với xác suất phân phát tới đích cao cùng với giới hạn của tốc độ được thoả thuận trong một SLA. Nếu lưu lượng AF tại một cổng vào vượt quá tốc độ ưu tiên trước đó, đây là việc không tuân theo thỏa thuận hay “ngoài hồ sơ”, các gói vượt quá này sẽ không được phân phát tới đích với xác suất cao như các gói thuộc lưu lượng đã xác định hay các gói “trong hồ sơ”. Khi có tắc nghẽn mạng, các gói ngoài hồ sơ được loại bỏ trước khi các gói trong hồ sơ bị loại bỏ. Khi các mức dịch vụ được định nghĩa bằng cách sử dụng các lớp AF, định lượng và chất lượng khác nhau giữa các lớp AF có thể được nhận biết bằng cách cấp phát số lượng băng thông và không gian bộ đệm khác nhau cho bốn lớp AF. Không giống như 43 EF, hầu hết lưu lượng AF là lưu lượng không thời gian thực sử dụng TCP, và chiến lược quản lý hàng đợi RED là một chiến lược quản lý hàng đợi thích nghi AQM (Adaptive Queue Management) thích hợp để sử dụng cho PHB AF. Bốn lớp PHB AF có thể được thực hiện như bốn hàng đợi riêng biệt. Băng thông cổng đầu ra được chia thành bốn hàng đợi AF. Với mỗi hàng đợi AF, các gói được đánh dấu bằng ba “màu” tương ứng với ba mức ưu tiên tách biệt. Ngoài 32 nhóm DSCP 1 đã được định nghĩa trong bảng 2.8, 21 DSCP đã được chuẩn hoá như sau: một cho PHB EF, 12 cho PHB AF và 8 cho CSCP. Có 11 nhóm DSCP 1 vẫn còn khả dụng cho các tiêu chuẩn khác. 2.2.5.Ví dụ về Differentiated Services Chúng ta sẽ xem xét một ví dụ về mô hình và cơ chế hoạt động của Differentatied Service. Kiến trúc của Differentatied Service gồm hai tập chức năng cơ bản: Chức năng biên: gồm phân loại gói tin (Packet classification) và điều hòa lưu lượng (traffic conditioning). Ở biên vào của mạng, các gói đến sẽ được đánh dấu. Đặc biệt, trường DS nằm trên phần header gói được thiết lập một giá trị nhất định. Ví dụ trên hình 2.12 các gói được gửi từ H1 tới H3 sẽ được đánh dấu tại R1, trong khi các gói từ H2 tới H4 được đánh dấu tại R2. Những nhãn được đánh dấu trên gói nhận được chính là định danh lớp dịch vụ mà nó thuộc vào. Các lớp lưu lượng khác nhau sẽ nhận được các dịch vụ khác nhau trong mạng lõi. Định nghĩa của RFC sử dụng thuật ngữ tổng hợp hành vi (behavior aggregate) mà không dùng thuật ngữ class traffic. Sau khi được đánh dấu, một gói có thể được chuyển tiếp ngay lập tức vào mạng, trễ một khoảng thời gian trước khi được chuyển đi, hoặc có thể bị loại bỏ. Chúng ta sẽ thấy có nhiều yếu tố ảnh hưởng tới việc gói bị đánh dấu như thế nào, và chúng được chuyển tiếp ngay, trễ lại hay bị loại bỏ. Hình 2.12 Ví dụ về DiffServ Chức năng lõi: Khi một gói đã được đánh dấu DS đi đến một router hỗ trợ DiffServ (Diffservcapable router), các gói được chuyển tiếp tới router kế tiếp dựa vào 44 kỹ thuật hành vi theo từng chặng (per-hop behavior) gắn với các lớp của gói. Hành vi (Ứng xử) từng chặng ảnh hưởng tới bộ đệm của router và băng thông đường truyền được chia sẻ giữa các lớp đang cạnh tranh nhau về lưu lượng. Một nguyên tắc quan trọng của kiến trúc Differentiated Service là các cư xử từng chặng của router sẽ chỉ dựa vào đánh dấu gói hay lớp lưu lượng mà nó thuộc vào. Bởi vậy, nếu các gói được gửi từ H1 tới H3 như trong hình sẽ nhận được cùng đánh dấu như các gói từ H2 tới H4, khi đó các router mạng cư xử các gói hoàn toàn giống nhau, mà không quan tâm gói xuất phát từ H1 hay H2. Ví dụ, R3 không phân biệt giữa các gói từ h1 và H2 khi chuyển tiếp các gói tới R4. Bởi vậy, kiến trúc Differentatied Service tránh được việc phải giữ trạng thái trên router về các cặp nguồn đích riêng biệt - đây là vấn đề quan trọng đối với vấn đề mở rộng mạng. Kết luận chương Chương 2 đã đưa ra và làm rõ hai mô hình chính của việc triển khai, cài đặt chất lượng dịch vụ trong mạng IP. Khi mà mô hình truyền thống best-effort có nhiều nhược điểm thì các mô hình ra đời sau như IntServ và DiffServ đã giải quyết phần nào các vấn đề mà best-effort không giải quyết được. IntServ đi theo hướng đảm bảo chất lượng dịch vụ cho từng luồng riêng, nó được xây dựng gần giống với mô hình chuyển mạch kênh với việc sử dụng giao thức dành trước tài nguyên RSVP. IntSer phù hợp với các dịch vụ đòi hỏi băng thông cố định không bị chia sẻ như các dịch vụ VoIP, dịch vụ multicast Tivi. Tuy nhiên IntSer có những nhược điểm như sử dụng nhiều tài nguyên mạng, khả năng mở rộng không cao và không mềm dẻo. DiffServ ra đời với ý tưởng giải quyết những nhược điểm của mô hình IntServ. DiffServ đi theo hướng đảm bảo chất lượng dựa trên nguyên lý hành vi theo từng chặng căn cứ vào mức ưu tiên của các gói tin đã được đánh dấu. Việc đưa ra chính sách với các loại lưu lượng khác nhau là do người quản trị quyết định và có thể thay đổi theo thực tế nên nó rất mềm dẻo. DiffServ tận dụng tốt tài nguyên mạng hơn, tránh được tình trạng nhàn rỗi băng thông và năng lực xử lý trên router, ngoài ra mô hình DifServ có thể triển khai trên nhiều miền độc lập do vậy khả năng mở rộng mạng trở nên dễ dàng. 45 Chương 3: CÁC PHƯƠNG PHÁP ĐẢM BẢO QoS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN Trong các mạng chuyển mạch gói, các luồng gói tin khác nhau thường phải chia sẻ đường truyền trên suốt chặng đường đến trạm đích. Để đảm bảo việc phân phối dải thông cho các luồng công bằng và đạt hiệu quả cao nhất cần phải có các cơ chế phục vụ thích hợp tại các nút mạng, đặc biệt là tại gateways hoặc routers, những nơi thường xuyên có nhiều luồng dữ liệu khác nhau đi qua. Bộ lập lịch có nhiệm vụ phục vụ gói tin của luồng đã chọn và quyết định gói tin nào sẽ được phục vụ tiếp theo. Ở đây luồng được hiểu là tập các gói tin thuộc cùng một lớp ưu tiên, hoặc cùng phát ra từ một nguồn, hoặc cùng có cùng địa chỉ nguồn và đích... Ở trạng thái bình thường khi không có tắc nghẽn xảy ra các gói tin sẽ được gửi đi ngay khi chúng được chuyển tới. Trong trường hợp xảy ra tắc nghẽn nếu như không áp dụng các phương pháp đảm bảo QoS, thời gian tắc nghẽn kéo dài có thể phát sinh rớt gói, ảnh hưởng đến chất lượng dịch vụ. Trong một số trường hợp hiện tượng tắc nghẽn kéo dài và lan rộng trong mạng, rất dễ dẫn đến hiện tượng mạng bị “treo”, hoặc các gói bị loại bỏ nhiều gây ảnh hưởng nghiêm trọng đến chất lượng dịch vụ. Vì vậy trong chương này, tại các mục 3.2 và 3.3, chúng tôi giới thiệu một số kỹ thuật giám sát tải trọng lưu lượng mạng điển hình nhằm tiên đoán và ngăn chặn nghẽn mạch trước khi nó xảy ra thông qua biện pháp làm rớt (loại bỏ) gói tin sớm khi mới có dấu hiệu sắp xảy ra tắc nghẽn. 3.1. Phương pháp bỏ đuôi - DropTail DropTail là cách thức quản lý hàng đợi đơn giản, truyền thống dựa vào cơ chế FIFO. Tất cả các gói tin đến được xếp vào hàng đợi, khi hàng đợi đầy thì những gói tin đến sau sẽ bị loại bỏ. Do đặc tính đơn giản, dễ triển khai mà DropTail đã được sử dụng nhiều năm trên hệ thống router ở Internet, tuy nhiên giải thuật này có những nhược điểm như sau: − Không tránh được hiện tượng “Lock out”: Xảy ra khi có 1 hay vài dòng lưu lượng độc chiếm hàng đợi, làm cho các gói tin của các kết nối khác không thể đi qua router. Hiện tượng này ảnh hưởng rất lớn tới các giao thức truyền tin cậy như TCP, theo giải thuật chống tắc nghẽn thì khi bị Lock out, luồng kết nối TCP sẽ giảm kích thước cửa sổ (window size) và thực hiện giảm tốc độ truyền gói tin theo hàm số mũ. − Có thể gây nên hiện tượng Global Synchronization: Là kết quả khi hiện tượng “Lock out” xảy ra nặng nề. Một số các router lân cận có hàng đợi bị độc chiếm bởi 1 số kết nối, khiến cho hàng loạt các kết nối TCP khác không thể đi qua và đồng loạt giảm tốc độ truyền. Sau khi các kết nối độc chiếm kia tạm ngừng, 46 hàng đợi được giải phóng, thì cũng phải mất 1 thời gian đáng kể thì các kết nối TCP mới có thể trở lại tốc độ ban đầu. − Hiện tượng Full Queue: Dữ liệu truyền trên Internet thường xuyên có sự bùng nổ, các gói tin đến router thường theo từng cụm chứ không phải lần lượt. Vì thế cơ chế hoạt động của DropTail khiến cho hàng đợi có thể dễ dàng bị đầy trong 1 khoảng thời gian dài, dẫn đến thời gian trễ trung bình của các gói tin lớn. Để tránh hiện tượng này thì với DropTail chỉ có cách là tăng bộ đệm của router, cách này tỏ ra hết sức tốn kém và không hiệu quả. − Không đảm bảo QoS: Với cơ chế DropTail thì không có cách nào để ưu tiên những gói tin quan trọng được truyền qua router sớm hơn khi tất cả đang ở trong hàng đợi. Trong khi đó với truyền thông đa phương tiện, việc bảo đảm kết nối, tốc độ ổn định là hết sức quan trọng mà thuật toán DropTail không thể thỏa mãn được. Vấn đề của việc chọn kích thước bộ đệm của các router ở trong mạng là thực hiện “hấp thụ” các bùng nổ lưu lượng trong thời gian ngắn nhưng không gây ra trễ xếp hàng quá lớn. Điều này là cần t