Trƣờng số thứ tự
Trường này có độ dài 16 bit. Số thứ tự tăng lên 1 sau khi mỗi gói RTP được gửi đi, nó có thể được phía nhận dùng để phát hiện mất gói tin và khôi phục lại gói tin. Ví dụ: Nếu phía nhận nhận được các gói RTP có khoảng trống giữa số 86 và 89 thì sẽ biết được rằng gói thứ 87, 88 bị mất và nó cố gắng khôi phục lại dữ liệu mất.
Trƣờng nhãn thời gian
Dài 32 bít. Nó xác định thời điểm lấy mẫu của byte đầu tiên trong dữ liệu gói RTP. Phía nhận dùng nhãn thời gian để loại bỏ jitter. Nhãn thời gian được lấy từ đồng hồ lấy mẫu ở phía gửi. Ví dụ: Nhãn thời gian tăng lên 1 sau mỗi chu kì lấy mẫu.
Trƣờng số định danh nguồn phát SSRC
Trường này dài 32 bit. Nó xác định nguồn của luồng RTP. Mỗi luồng trong một phiên RTP có một số SSRC phân biệt. SSRC không phải là địa chỉ IP của phía gửi mà là một số mà phía nguồn gán ngẫu nhiên khi một luồng mới bắt đầu. Khả năng 2 luồng được gán cùng số SSRC là rất nhỏ.
2.7. RTCP-Giao thức điều khiển RTP (RTP Control Protocol)
RTCP được dùng cùng với RTP, đặc biệt khi truyền muilticast từ một hoặc nhiều người gửi tới nhiều người nhận. Gói RTCP được truyền trong một phiên RTP từ một người tới tất cả những người khác trong phiên đó. Gói RTCP được truyền tới tất cả những người tham gia dùng địa chỉ IP multicast. Với một phiên RTP, có một địa chỉ multicast và tất cả các gói RTP, RTCP dùng địa chỉ này. Các gói RTP và RTCP được gửi qua các số cổng khác nhau [2].
Hình 2.9. Sử dụng RTCP cùng RTP
RTCP không đóng gói các đoạn audio/video. Nó được gửi theo định kì và chứa các báo cáo về phía gửi, hoặc phía nhận cho biết những số liệu thống kê trạng thái của phía gửi hoặc phía nhận. Những số liệu thống kê này gồm: Số gói tin được gửi, số gói tin mất, jitter,… Đặc tả RTP không cho biết ứng dụng làm gì với những thông tin này. Người phát triển ứng dụng có thể quyết định việc xử lý các thông tin này. Phía gửi có thể dùng thông tin này để thay đổi tốc độ truyền,… Sau đây là các loại gói tin trong giao thức RTCP.
Gói tin mô tả việc nhận
Với mỗi luồng RTP mà phía nhận nhận được, phía nhận sẽ tạo ra một báo cáo. Phía nhận sẽ gộp các báo cáo này vào một gói RTCP. Gói tin này được gửi multicast tới tất cả mọi bên tham gia phiên RTP. Các báo cáo được tạo ra gồm các trường, trong đó có các trường quan trọng gồm:
Số SSRC của luồng RTP mà báo cáo được tạo ra
Tỉ lệ gói tin bị mất trong luồng RTP. Phía nhận sẽ tính số gói tin RTP bị mất chia cho số gói tin được gửi. Nếu phía gửi nhận được báo cáo cho biết phía nhận chỉ nhận được một phần nhỏ của các gói tin được truyền, nó sẽ chuyển sang tốc độ mã hóa thấp hơn chẳng hạn.
Số thứ tự cuối cùng nhận được trong luồng gói tin RTP.
Thời gian lệch trung bình giữa các gói tin được nhận thành công tại phía nhận.
Gói tin mô tả phía gửi
Với mỗi trường RTP truyền đi, phía gửi tạo các gói tin mô tả phía gửi. Các gói tin này chứa các thông tin về luồng RTP bao gồm:
Số SSRC của luồng RTP.
Nhãn thời gian và thời gian thực của gói RTP cuối cùng được tạo trong luồng gói tin.
Số byte đã được gửi trong luồng gói tin.
Các gói tin mô tả phía gửi được sử dụng để đồng bộ hóa các luồng dữ liệu đa phương tiện khác nhau trong cùng một phiên RTP. Xét một ví dụ: Một ứng dụng Video Conference trong đó bên gửi tạo ra 2 luồng gói tin RTP độc lập: Một luồng audio, một luồng video. Các nhãn thời gian trong các gói RTP được tính theo đồng hồ lấy mẫu chứ không theo thời gian thực tế. Mỗi gói tin RTP kiểu gói tin mô tả phía gửi được gán nhãn thời gian và thời gian thực của gói tin gần nhất được tạo ra ở phía gửi. Do đó các gói tin mô tả phía gửi sẽ tạo ra một liên hệ giữa thời gian lấy mấu với thời gian thực. Phía nhận có thể dùng các thông số này để đồng bộ việc thực hiện chạy audio và video.
Gói tin mô tả nguồn
Với mỗi luồng gói tin RTP mà phía gửi truyền đi, phía gửi cũng tạo và truyền đi các gói mô tả nguồn. Những gói này chứa thông tin về nguồn gửi như: Địa chỉ email của phía gửi, tên người gửi và ứng dụng tạo ra luồng gói tin RTP, số SSRC của luồng RTP. Những gói tin này cung cấp một ánh xạ giữa định danh nguồn với tên người dùng hoặc tên máy chạy ứng dụng.
Chia sẻ băng thông trong RTCP
Xét ví dụ một phiên RTP gồm có 1 bên gửi và một số lượng lớn bên nhận. Nếu mỗi người nhận theo định kì tạo các gói RTCP, thì băng thông tổng hợp của các gói tin RTCP có thể lớn hơn nhiều so với băng thông của các gói RTP gửi bởi bên gửi. Lưu lượng RTP được gửi multicast, không thay đổi khi lượng người nhận tăng trong khi lưu lượng truyền RTCP tăng tuyến tính với số người nhận. Do đó cần phải giới hạn băng thông cho các gói tin RTCP.
Các gói tin RTCP bị hạn chế băng thông, chỉ được phép chiếm tới khoảng 5% băng thông của phiên ứng dụng. Ví dụ: Giả sử có một bên gửi, gửi video với tốc độ 2Mbps. RTCP sẽ giới hạn băng thông dành cho mình tối đa là 5%*2Mbps = 100Mbps. 75% của băng thông dành cho RTCP = 75%*100Kbps = 75Kbps được chia đều cho những người nhận, 25% còn lại = 25Kbps được giành cho người gửi. Phần 75% băng thông sẽ được chia đều cho những người nhận. Mỗi bên tham gia (nhận hay gửi) đều xác định được khoảng thời gian trung bình để truyền gói tin RTCP bằng cách lấy kích thước gói tin RTCP trung bình chia cho băng thông mà nó được cấp cho. Ví dụ số lượng bên nhận tham gia phiên ứng dụng là N, băng thông của phiên ứng dụng là R, kích thước trung bình gói tin
RTCP là S. Khi đó, thời gian trung bình mà mỗi người nhận truyền gói tin RTCP sẽ là: R S N T * 5 . 0 * 75 . 0 *
Thời gian trung bình mà phía gửi truyền gói tin RTCP sẽ là R S N T * 5 . 0 * 25 . 0 * 2.8. Kết luận
Như vậy, đối với các ứng dụng truyền thông đa phương tiện thời gian thực, như: Video Conference.... thì việc giảm tối thiểu độ trễ, giảm jitter và mất gói tin luôn được đặt lên hàng đầu và được các nhà sản xuất thiết bị truyền hình đặc biệt quan tâm giải quyết. Đến nay, đã có nhiều giải pháp cho giải quyết các vấn đề trên, giải pháp đường truyền, giải pháp tại thiết bị đầu cuối (khôi phục gói tin bị mất tại điểm nhận),.... Tuy nhiên, một trong những giải pháp quan trọng và quyết định đó là đường truyền.
Trong chương này luận văn đã trình bày một số giải pháp đảm bảo cho đường truyền tốt hơn, đó là: giải pháp giảm dữ liệu truyền trên mạng (nén video, nén audio) và giải pháp đưa ra các giao thức đặc biệt. Tuy nhiên, các giải pháp này chỉ giúp làm tăng chất lượng dịch vụ. Do vậy, các giải pháp này chưa đủ để đảm bảo cho chất lượng dịch vụ của Video Conference được tốt.
Để giải quyết vấn này, trong chương tới luận văn tiếp tục đưa ra một số giải pháp mạnh hơn, đó là các mô hình đảm bảo chất lượng vụ đang được sử dụng trên mạng hiện nay, mô hình dịch vụ tích hợp IntServ và mô hình dịch vụ phân biệt DiffServ và đưa ra mô hình đề xuất kết hợp mô hình IntServ với mô hình DiffServ sử dụng hàm ánh xạ.
Chƣơng 3
CÁC MÔ HÌNH ĐẢM BẢO CHẤT LƢỢNG DỊCH VỤ CHO TRUYỀN THÔNG ĐA PHƢƠNG TIỆN
Trong chương này, chúng tôi sẽ nghiên cứu và trình bày chi tiết từng mô hình IntServ và mô hình DiffServ. Đặc biệt, chúng tôi đưa ra một mô hình đề xuất đó là kết hợp hai mô hình IntServ và mô hình DiffServ với nhau bằng hàm ánh xạ. Các phần dưới đây là nội dung chi tiết mà chúng tôi muốn trình bày trong chương này.
3.1. Mô hình dịch vụ tích hợp IntServ (Intergrated Services)
3.1.1. Tổng quan
Trước những nhu cầu ngày càng tăng trong việc cung cấp các dịch vụ thời gian thực (thoại, video) và yêu cầu băng thông cao (các dịch vụ đa phương tiện), tổ chức IETF (Internet Engineering Task Force) đã đưa ra mô hình IntServ từ những năm đầu của thập kỷ 90 như một giải pháp hữu hiệu đảm bảo QoS IP [7].
Ý tưởng ban đầu của dịch vụ tích hợp IntServ là hỗ trợ việc dành trước tài nguyên cho các luồng lưu lượng, đượ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 intServ là các bộ định tuyến và thiết bị mạng phải dành trước nguồn tài nguyên của nó để cung cấp các mức chất lượng dịch vụ cụ thể cho các gói mang lưu lượng người dùng.
IntServ đã định nghĩa những yêu cầu cho các quá trình QoS để thỏa mãn hai mục đích: Phục vụ các ứng dụng thời gian thực và điều khiển việc chia sẻ băng thông giữa các cấp độ lưu lượng khác nhau.
Trong mô hình dịch vụ tích hợp, người ta đã đề xuất hai lớp dịch vụ bổ sung cho các dịch vụ IP truyền thống đó là:
Dịch vụ có đảm bảo - GS (Guaranteed Service): Được định nghĩa trong RFC2212 [14], cung cấp các giới hạn cứng về các độ trễ xếp hàng mà gói tin sẽ phải trải qua trong một router. Về bản chất, một phiên yêu cầu GS là yêu cầu các bit trong gói tin của nó được đảm bảo truyền đi với tốc độ không dưới một giá trị nhất định. GS đảm bảo rằng dữ liệu tới đích sau một khoảng thời gian nhất định và sẽ không bị mất do tràn bộ nhớ. Dịch vụ GS có đặc tính sử dụng băng tần dành riêng, trễ có giới hạn và không bị thất thoát gói tin. Các ứng dụng dịch vụ này có thể kể đến là: Video Conference chất lượng cao, thanh toán tài chính thời gian thực,…
Dịch vụ tải được điều khiển - CL (Control Load Service): Được định nghĩa trong RFC2211 [10], Một phiên nhận CL sẽ nhận một QoS xấp xỉ với
QoS mà cùng luồng đó sẽ nhận từ một phần mạng không có tải. Nói cách khác, phiên có thể thừa nhận rằng “một tỉ lệ phần trăm rất cao” của các gói tin sẽ đi qua router thành công mà không bị loại bỏ và sẽ chịu một độ trễ xếp hàng trong router gần như bằng 0. Dịch vụ CL không đảm bảo về băng tần hay trễ, nó phù hợp với các ứng dụng không nhạy cảm lắm với độ trễ như truyền multicast audio/video chất lượng trung bình, nó hướng tới các ứng dụng đa phương tiện được phát triển cho Internet ngày nay. Những ứng dụng này hoạt động khá tốt khi mạng có tải nhẹ, nhưng hiệu suất lại giảm mạnh khi mạng ở trong trạng thái tải nặng hơn nhiều.
Trong IntServ, một luồng IP cụ thể được nhận dạng bởi 5 thông số sau: - Địa chỉ IP nguồn
- Địa chỉ IP đích - Địa chỉ cổng nguồn - Địa chỉ cổng đích
- Giao thức chuyển vận được sử dụng (TCP hay UDP) cho luồng IP đang xét.
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 độ lớn nhất, tốc độ trung bình, kích cỡ lưu lượng 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 khác như: độ trễ, jitter và tỷ lệ mất gói tin. Nếu có yêu cầu 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 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 đi 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 chặng.
3.1.2. Kiến trúc IntServ
Hình 3.1. Mô hình hoạt động dịch vụ tích hợp IntServ
Có 4 thành phần chính tham gia vào mô hình: thành phần điều khiển chấp nhận, thành phần phân loại, thành phần lập lịch (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 (RSVP).
Thành phần đ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 không thể được chấp nhận nếu không có sẵn tài nguyên được yêu cầu. Có hai hướng tiếp cận để giải quyết xem tài nguyên nào là sẵn sàng: 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 hóa 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.
Phân loại (Classifier): Phân loại các gói của một luồng cho trước (hoặc
của một tập) để sử dụng bởi thành phần lập lịch. Giao thức RSVP sử dụng 5 tiêu đề trong gói tin IP để nhận dạng gói tin thuộc về các luồng đã yêu cầu 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à cổng đích
Lập lịch (Scheduler): Quản lý việc chuyển tiếp các gói khác nhau sử dụng hàng đợi và bộ định thời. Đây là bước cuối cùng trong việc dành trước tài nguyên. Nó quyết định gói tin nào sẽ được 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.
Giao thức dành trƣớc tài nguyên (RSVP) [7]: là giao thức được sử
dụng bởi Intserv. RSVP có thể mang dịch vụ yêu cầu và đáp ứng tương ứng của thành phần chấp nhận luồng từ máy tính tới router, từ router tới router và từ router tới máy đích. RSVP sử dụng thông điệp “Path” và “Resv”. Thông điệp Resv mang tham số dịch vụ. Thông điệp Path bắt đầu từ nguồn và được gửi tới đích. Mục đích chính là để router biết liên kết nào sẽ chuyển tiếp thông điệp giành tài nguyên (nó cũng bao gồm định nghĩa về đặc điểm lưu lượng của luồng). Thông điệp Error được sử dụng khi việc giành tài nguyên thất bại. RSVP dựa vào các giao thức định tuyến bên dưới để xác định tuyến đường cho một