Báo cáo Tìm hiêu công nghệ IP muliticast

91 trang phuongnguyen 170

Download

Bạn đang xem 20 trang mẫu của tài liệu "Báo cáo Tìm hiêu công nghệ IP muliticast", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bao_cao_tim_hieu_cong_nghe_ip_muliticast.pdf

Nội dung text: Báo cáo Tìm hiêu công nghệ IP muliticast

TRƯỜNG . KHOA .  Báo cáo tốt nghiệp Đề tài: TÌM HIÊU CÔNG NGHỆ IP MULITICAST
LỜI CẢM ƠN Tôi xin chân thành cảm ơn TS. Ngô Khánh Vân, người đã tận tình hướng dẫn, chỉ bảo tôi trong suốt thời gian dài thực hiện đề tài. Tôi xin chân thành cảm ơn PGS.TS Nguyễn Văn Tam, công tác tại Viện công nghệ thông tin, đã chỉ bảo và cho tôi những lời khuyên quý báu để hoàn thiện luận văn. Tôi xin chân thành cảm ơn các thầy cô trong trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội đã giảng dạy, truyền đạt và tạo điều kiện học tập tốt nhất cho tôi trong suốt thời gian học tập cũng như trong quá trình thực hiện luận văn. Hà Nội, tháng 08 năm 2009 Trương Công Ái
I MỤC LỤC LỜI CẢM ƠN MỤC LỤC DANH MỤC CÁC TỪ VIẾT TẮT DANH SÁCH HÌNH VẼ DANH SÁCH CÁC BẢNG MỞ ĐẦU 1 1. Đặt vấn đề 1 2. Đối tượng và mục tiêu luận văn 1 3. Hướng tiếp cận 2 4. Kết cấu của luận văn 2 CHƯƠNG 1 3 CƠ BẢN VỀ IP MULTICAST 3 1.1 Mở đầu 3 1.2 Các thành phần tham gia vào truyền thông multicast 5 1.3 Địa chỉ multicast 7 1.4 Cây phân phối multicast 9 1.4.1 Cây nguồn 9 1.4.2 Cây chia sẻ 10 1.5 Chuyển tiếp multicast 13 1.6 Đường trục multicast 15 1.7 Giao thức quản lý nhóm Internet 17 1.7.1 Giao thức IGMPv1 17 1.7.1.1 Thông điệp Host Membership Report 18 1.7.1.2 Thông điệp Host Membership Query 19 1.7.2 Giao thức IGMPv2 19 1.7.2.1 Lựa chọn router truy vấn 20 1.7.2.2 Thông điệp rời nhóm 21 1.7.2.3 Truy vấn cho từng nhóm 21 1.7.3 Giao thức IGMPv3 21
I 1.7.3.1 Lọc dữ liệu 21 1.7.3.2 Thông điệp IGMPv3 Host Membership Query 22 1.7.3.3 Thông điệp IGMPv3 Host Membership Report 23 CHƯƠNG 2 25 ĐỊNH TUYẾN MULTICAST 25 2.1 Giao thức định tuyến multicast véctơ khoảng cách 25 2.1.1 Tìm kiếm hàng xóm 25 2.1.2 Trao đổi thông báo định tuyến 26 2.1.3 Cắt nhánh 29 2.1.4 Ghép nhánh 31 2.2 Giao thức PIM Dense Mode 33 2.2.1 Tìm kiếm hàng xóm 33 2.2.1.1 Thông điệp Hello 33 2.2.1.2 Router được chỉ định 33 2.2.1.3 Cây phân phối multicast 34 2.2.2 Cắt nhánh 35 2.2.3 Cơ chế xác nhận 37 2.2.4 Ghép nhánh 38 2.3 PIM Sparse Mode 39 2.3.1 Mô hình tham gia 39 2.3.2 Cây chia sẻ 40 2.3.2.1 Tham gia cây chia sẻ 40 2.3.2.2 Cắt nhánh trên cây chia sẻ 43 2.3.3 Cây đường đi ngắn nhất 45 2.3.3.1 Tham gia cây đường đi ngắn nhất 45 2.3.3.2 Cắt nhánh trên cây đường đi ngắn nhất 47 2.3.4 Thông điệp Join/Prune 48 2.3.5 Đăng ký nguồn dữ liệu 49 2.3.5.1 Thông điệp PIM Register 49 2.3.5.2 Thông điệp PIM Register – Stop 50 2.3.6 Chuyển từ cây chia sẻ sang cây đường đi ngắn nhất 50
I 2.4 Giao thức Multicast Open Shortest Path First 54 2.4.1 Định tuyến multicast trong vùng 54 2.4.2 Định tuyến multicast trên nhiều vùng 56 2.4.3 Định tuyến multicast trên các vùng tự trị 59 CHƯƠNG 3 61 SỬ DỤNG ACCESS GRID XÂY DỰNG 61 HỆ THỐNG HỘI NGHỊ TRUYỀN HÌNH DỰA TRÊN IP MULTICAST 61 3.1 Các khái niệm chung về dịch vụ hội nghị truyền hình 61 3.1.1 Hệ thống hội nghị truyền hình 62 3.1.2 Các thành phần cơ bản của hội nghị truyền hình 63 3.2 Giao thức RTP 64 3.2.1 Khuôn dạng RTP header 64 3.2.2 Các ứng dụng sử dụng RTP 65 3.2.2.1 Thoại hội nghị đơn giản 65 3.2.2.2 Thoại và truyền hình hội nghị 67 3.2.2.3 Bộ trộn và bộ biên dịch 67 3.3 Đồng bộ luồng hình ảnh và âm thanh 68 3.4 Sử dụng Access Grid xây dựng một hội nghị truyền hình 70 3.4.1 Các thành phần của Access Grid 70 3.4.2 Sử dụng Access Grid client để tham gia vào hội nghị truyền hình 73 KẾT LUẬN 76 HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI 77 TÀI LIỆU THAM KHẢO
II DANH MỤC CÁC TỪ VIẾT TẮT Từ viết tắt Viết đầy đủ Nghĩa tiếng Việt ABR Area Border Router Router biên vùng AG Access Grid Phần mềm hỗ trợ xây dựng ứng dụng hội nghị truyền hình AS Autonomous System Vùng tự trị ASBR Autonomous System Router trên biên vùng tự trị Border Routers DR Designated Router Router được lựa chọn DVMRP Distance Vector Multicast Giao thức định tuyến multicast véc- Routing Protocol tơ khoảng cách IGMP Internet Group Giao thức quản lý nhóm Internet Management Protocol LAN Local Area Network Mạng nội bộ LSA Link-State Advertisement Thông điệp quảng bá trạng thái liên kết MABR Multicast Area Border Router biên vùng multicast Router MBONE Multicast Backbone Đường trục multicast MOSPF Multicast Open Shortest Giao thức định tuyến multicast dựa Path First trên thuật toán đường đi ngắn nhất MCU Multipoint Control Unit Bộ điều khiển đa điểm OSPF Open Shortest Path First Giao thức định tuyến unicast dựa trên thuật toán đường đi ngắn nhất
II PIM Protocol Independent Giao thức định tuyến multicast độc Multicast lập PIM-DM Protocol Independent Giao thức định tuyến multicast độc Multicast Dense Mode lập theo mô hình tập trung PIM-SM Protocol Independent Giao thức định tuyến multicast độc Multicast Sparse Mode lập theo mô hình phân tán RAT Robust Audio Tool Công cụ truyền âm thanh trong ứng dụng hội nghị truyền hình RIP Routing Information Giao thức thông tin định tuyến Protocol RPF Reverse Path Forwarding Kiểm tra đường dẫn ngược RP Rendezvous Point Điểm hẹn RTCP Real Time Transport Giao thức điều khiển truyền thông Control Protocol thời gian thực RTP Realtime Transport Giao thức truyền thông thời gian Protocol thực SPT Shortest Path Tree Cây đường đi ngắn nhất TTL Time To Live Thời gian tồn tại gói tin VIC Video Conference Ứng dụng video trong hội nghị truyền hình
III DANH SÁCH HÌNH VẼ Hình 1.1: Truyền thông unicast và multicast 3 Hình 1.2: Các thành phần tham gia vào truyền thông multicast 6 Hình 1.3: Định dạng của địa chỉ IP lớp D 7 Hình 1.4: Ánh xạ địa chỉ IP multicast sang địa chỉ MAC 8 Hình 1.5: Cây đường đi ngắn nhất của host A 9 Hình 1.6: Cây đường đi ngắn nhất của host B 10 Hình 1.7: Cây chia sẻ 11 Hình 1.8: Cây chia sẻ hai chiều 12 Hình 1.9: Cây chia sẻ một chiều sử dụng cây SPT 12 Hình 1.10: Cây chia sẻ một chiều sử dụng định tuyến unicast 13 Hình 1.11: Giới hạn TTL 14 Hình 1.12: Cơ chế đường hầm liên kết các ốc đảo multicast 15 Hình 1.13: Đóng gói IP multicast theo cơ chế tunneling 16 Hình 1.14: Cơ chế đường hầm liên kết các MRouter 16 Hình 1.15: Thông điệp IGMPv1 18 Hình 1.16: Thông điệp IGMPv2 19 Hình 2.1: Tìm hàng xóm trong DVMRP 26 Hình 2.2: Trao đổi định tuyến DVMRP bước 1 27 Hình 2.3: Trao đổi định tuyến DVMRP bước 2 28 Hình 2.4: Trao đổi định tuyến DVMRP bước 3 29 Hình 2.5: Cắt nhánh trong DVMRP bước 1 30 Hình 2.6: Cắt nhánh trong DVMRP bước 2 31 Hình 2.7: Ghép nhánh trong DVMRP bước 1 32 Hình 2.8: Ghép nhánh trong DVMRP bước 2 32 Hình 2.9: Cây phân phối PIM-DM 35 Hình 2.10: Cắt nhánh trong PIM-DM bước 1 36 Hình 2.11: Cắt nhánh trong PIM-DM bước 2 36 Hình 2.12: Cắt nhánh trong PIM-DM bước 3 37 Hình 2.13: Xác nhận trong PIM-DM 38
III Hình 2.14: Ghép nhánh trong PIM-DM 39 Hình 2.15: Tham gia cây chia sẻ PIM bước 1 40 Hình 2.16: Tham gia cây chia sẻ PIM bước 2 41 Hinh 2.17: Tham gia cây chia sẻ PIM bước 3 42 Hình 2.18: Tham gia cây chia sẻ PIM bước 4 42 Hình 2.19: Tham gia cây chia sẻ PIM bước 5 43 Hình 2.20: Tham gia cây chia sẻ PIM bước 6 43 Hình 2.21: Cắt nhánh trên cây chia sẻ bước 1 44 Hình 2.22: Cắt nhánh trên cây chia sẻ bước 2 44 Hình 2.23: Cắt nhánh trên cây chia sẻ bước 3 45 Hình 2.24: Tham gia cây đường đi ngắn nhất bước 1 46 Hình 2.25: Tham gia cây đường đi ngắn nhất bước 2 46 Hình 2.26: Tham gia cây đường đi ngắn nhất bước 3 47 Hình 2.27: Cắt nhánh trên cây đường đi ngắn nhất bước 1 47 Hình 2.28: Cắt nhánh trên cây đường đi ngắn nhất bước 2 48 Hình 2.29: Cắt nhánh trên cây đường đi ngắn nhất bước 3 48 Hình 2.30: Chuyển sang cây SPT bước 1 51 Hình 2.31: Chuyển sang cây SPT bước 2 51 Hình 2.32: Cắt bỏ nguồn khỏi cây chia sẻ bước 3 52 Hình 2.33: Cắt bỏ nguồn khỏi cây chia sẻ bước 4 53 Hình 2.34: Cắt bỏ nguồn khỏi cây chia sẻ bước 5 53 Hình 2.35: Vùng MOSPF chứa nguồn và thành viên nhóm G 55 Hình 2.36: Cây đường đi ngắn nhất MOSPF SPT cho mạng N3 và N4 56 Hình 2.37: Thông điệp nhóm tóm tắt trong vùng đường trục 57 Hình 2.38: Cây đường đi ngắn nhất SPT trong vùng đường trục 58 Hình 2.39: Nguồn trong vùng không phải đường trục 59 Hình 2.40: Lưu lượng multicast xuống các miền MOSPF 60 Hình 3.1: Thành phần của hội nghị truyền hình 63 Hình 3.2: Khuôn dạng RTP header 64 Hình 3.3: Các thành phần của Access Grid 70 Hình 3.4: Desktop node 71
III Hình 3.5: Office node 72 Hình 3.6: Room node 72 Hình 3.7: Mối quan hệ giữa multicast và Access Grid 73 Hình 3.8: Profile Dialog 73 Hình 3.9: Điền địa chỉ virtual venue để kết nối 73 Hình 3.10: Venue client 74 Hình 3.11: Cửa sổ video 74 Hình 3.12: Cửa sổ audio 75
IV DANH SÁCH CÁC BẢNG Bảng 1.1: Các trường trong thông điệp IGMPv1 18 Bảng 1.2: Các trường trong thông điệp IGMPv2 20 Bảng 1.3: Các trường trong thông điệp IGMPv3 Host Membership Query 22 Bảng 1.4: Các trường trong thông điệp IGMPv3 Host Membership Report 24
1 MỞ ĐẦU 1. Đặt vấn đề Ngày nay mạng Internet và các ứng dụng trên mạng ngày càng trở nên thông dụng, vì thế có một lượng rất lớn các thông tin cần phải chuyển tiếp đến nhiều nơi trong cùng một thời gian. Phần lớn các ứng dụng trên mạng hiện nay sử dụng phương pháp truyền dữ liệu unicast, đây là phương pháp truyền dữ liệu từ điểm tới điểm, tức là dữ được truyền từ một người gửi tới một người nhận. Tuy nhiên với một số ứng dụng yêu cầu phải thường xuyên gửi dữ liệu từ một điểm tới nhiều điểm, dữ liệu được gửi từ một người gửi tới nhiều người nhận, phương pháp truyền dữ liệu unicast trở nên không hiệu quả. Trong trường hợp này, các ứng dụng sử dụng unicast phải đóng gói cùng một dữ liệu nhiều lần và lần lượt gửi chúng từ điểm tới điểm. Một cách khác để thực hiện việc truyền dữ liệu từ điểm đến nhiều điểm là sử dụng broadcast, đây là phương pháp gửi dữ liệu từ một điểm đến tất cả các điểm. Dễ thấy rằng cả hai phương pháp trên đều gây nên những sự lãng phí tài nguyên mạng, khi đó multicast là một sự thay thế tốt nhất, phương pháp này giúp ta tiết kiệm được băng thông mạng cũng như cải thiện được tốc độ truyền dữ liệu. Multicast là phương pháp truyền dữ liệu từ điểm tới nhiều điểm, trong đó một nguồn gửi sẽ gửi lưu lượng tới một nhóm nguồn nhận thông qua địa chỉ nhóm multicast. Trong phương pháp multicast có các giao thức cho phép các máy tính có thể gia nhập vào nhóm để nhận dữ liệu hay rời bỏ nhóm một cách dễ dàng, các giao thức định tuyến cũng được xây dựng cho phép các ứng dụng có thể gửi dữ liệu một cách hiệu quả trên mạng. 2. Đối tượng và mục tiêu luận văn Xuất phát từ vấn đề nêu trên, luận văn xác định IP multicast là đối tượng nghiên cứu với những vấn đề tập trung chủ yếu như sau: − Tìm hiểu các thành phần cơ bản của quá trình truyền dữ liệu multicast gồm: địa chỉ multicast, cây multicast, chuyển tiếp multicast cũng như quá trình
2 tham gia nhóm multicast thông qua giao thức Internet Group Management Protocol. − Tìm hiểu các giao thức định tuyến cơ bản được sử dụng trong truyền thông multicast như giao thức định tuyến Distance Vector Multicast Routing Protocol, giao thức định tuyến Protocol Independent Multicast và giao thức định tuyến Multicast Open Shortest Path First. − Tìm hiểu khả năng áp dụng của multicast trong ứng dụng thời gian thực. 3. Hướng tiếp cận Với mục tiêu là tìm hiểu công nghệ IP multicast, luận văn được tiếp cận theo hướng tập trung nghiên cứu các khái niệm, tìm hiểu các giao thức phổ biến của multicast từ đó chỉ ra được các ưu điểm, nhược điểm cũng như khả năng áp dụng của IP multicast vào các ứng dụng. 4. Kết cấu của luận văn − Luận văn gồm phần mở đầu, 03 chương và kết luận. − Chương 1: Trình bày các vấn đề cơ bản của IP multicast như địa chỉ multicast, cây phân phối multicast, chuyển tiếp multicast và quá trình tham gia nhóm multicast. − Chương 2: Trình bày các giao thức định tuyến được sử dụng trong truyền thông multicast gồm giao thức định tuyến Distance Vector Multicast Routing Protocol, giao thức định tuyến Protocol Independent Multicast theo hai mô hình tập trung và phân tán và giao thức định tuyến Multicast Open Shortest Path First. − Chương 3: Tìm hiểu về hội nghị truyền hình, ứng dụng phần mềm Access Grid để xây dựng hệ thống hội nghị truyền hình dựa trên IP multicast. − Cuối cùng là kết luận và hướng nghiên cứu tiếp theo của luận văn.
3 CHƯƠNG 1 CƠ BẢN VỀ IP MULTICAST 1.1 Mở đầu IP multicast là một nhóm các công nghệ và tiêu chuẩn cho phép việc truyền tải đa điểm – đa điểm như hội nghị, hay truyền tài điểm – đa điểm như việc quảng bá âm thanh, video trên Internet. Việc ứng dụng công nghệ này ngày càng phát triển do nhu cầu ngày càng cao đối với các ứng dụng đa phương tiện và sự cải tiến công nghệ IP multicast. Multicast là thuật ngữ kỹ thuật, có nghĩa một gói tin có thể được gửi đến nhiều nơi trong cùng thời điểm. Cách thức thông thường trong việc truyền thông tin trên Internet là sử dụng các giao thức unicast, các giao thức này gửi các gói tin đến mỗi điểm thu tại một thời điểm. Trên mạng multicast, một gói tin có thể được gửi từ một máy tính đến một vài máy tính khác, thay vì gửi gói tin đó lần lượt đến từng máy tính. Do 5, 10 hay 100 máy có thể nhận được cùng gói tin nên băng thông được tiết kiệm. Khi sử dụng multicast để gửi đi gói tin thì không cần thiết phải biết địa chỉ của những người cần nhận luồng tin multicast đó: dữ liệu được quảng bá theo một phương thức mà những người quan tâm đến nó có thể nhận được. Hình 1.1: Truyền thông unicast và multicast Các mạng hỗ trợ multicast cung cấp nhiều dịch vụ và các ứng dụng cho người sử dụng đầu cuối. Nhiều ứng dụng hỗ trợ multicast là các ứng dụng đa
4 phương tiện, tuy nhiên còn có nhiều loại ứng dụng khác nhau sử dụng công nghệ IP multicast cho các mục đích không phải đa phương tiện. Các ứng dụng thời gian thực bao gồm: truyền hình trực tiếp, đài phát thanh, hội nghị truyền hình, các ứng dụng không phải thời gian thực như truyền file, dữ liệu, video theo yêu cầu Truyền tải multicast đưa lại nhiều ưu điểm so với unicast truyền thống. Băng thông của mạng được tận dụng hiệu quả hơn do nhiều luồng dữ liệu được thay thế bởi một luồng dữ liệu multicast. Công nghệ này đem lại chất lượng tối ưu do cần ít bản sao dữ liệu để chuyển đi và xử lý tại các nút mạng. Để có thể có được các ưu điểm của IP multicast, thì khả năng định tuyến multicast phải được hỗ trợ tại các nút mạng. Tùy thuộc vào chính sách sử dụng và nhu cầu của người sử dụng, thì các vấn đề liền quan đến định tuyến, độ tin cậy, đánh địa chỉ mạng và các giao thức truyền tải đa phương tiện có tầm quan trọng đối với nhà vận hành mạng. Multicast không chỉ đem lại lợi ích cho người sử dụng đầu cuối. Hầu hết các ứng dụng multicast là dựa trên UDP, việc sử dụng giao thức này có thể dẫn đến các ảnh hưởng phụ không mong muốn (các gói tin có thể bị hủy) so với các ứng dụng unicast tương tự dựa trên TCP. Tuy nhiên, việc thiếu kiểm soát nghẽn có thể dẫn đến việc suy giảm chất lượng mạng tổng thể. Các gói tin trùng có thể thỉnh thoảng được tạo ra khi các topo mạng multicast thay đổi. Trong tương lai việc triển khai IPv6 sẽ đem lại multicast có sẵn cho người sử dụng mạng. Phần mềm định tuyến tin cậy hơn với các giao thức mới sẽ tận dụng được hạ tầng mạng. Với multicast có sẵn, các vấn đề định tuyến sẽ được giải quyết dễ dàng hơn và băng thông sẽ được tiết kiệm hơn. Multicast là một công nghệ tương đối mới cho phép các khách hàng được hưởng lợi từ các ứng dụng thời gian thực mà đáng ra phải yêu cầu một lượng băng thông cực lớn. Công nghệ này cho phép nhiều loại công ty đưa các sản phẩm của họ đến các nhóm người với chi phí thấp so với unicast. Multicast giảm lưu lượng mạng và tiết kiệm băng thông cho phép người dùng khai thác khả năng sử dụng cực đại có thể của Internet. Multicast cung cấp cho các người sử dụng liên quan đến Internet (các người sử dụng đầu cuối, nhà vận hành mạng, ISP và
5 các công ty liên quan khác) giải pháp khả thi kinh tế và kỹ thuật cho vấn đề truyển tải khối lượng thông tin lớn đến các nhóm người dùng được lựa chọn. Để có được multicast trên Internet hay các mạng Intranet, cách đầu tiên là kết nối các ốc đảo mạng hỗ trợ multicast với các đường hầm IP multicast. Do các đường hầm này không khả phân cấp và không đưa lại các ưu điểm kế thừa của multicast, bước kế tiếp là thay thế hạ tầng đường hầm với hạ tầng định tuyến multicast thực sự. Công nghệ multicast hiện tại đưa ra các thách thức khác nhau cho việc định tuyến và đánh địa chỉ, hiện nay thử thách lớn nhất là để thiết lập hạ tầng toàn cầu có tính tin cậy và có tính khả phân cấp tương tự như hạ tầng mạng Internet unicast ngày nay. Trong khi giao thức mạng IP tự bản thân nó cung cấp các cơ chế kế thừa đối với IP multicast, các giao thức lớp cao hơn không hỗ trợ nó. Mặc dù các giao thức không tin cậy như UDP, RTP có thể sử dụng trên nóc của IP multicast, TCP và các giao thức truyền tải tin cậy hơn trong các môi trường unicast không hộ trợ multicast. Do vậy các giao thức truyền tải multicast phải được phát triển và vì thế không có giao thức truyền tải mục đích chung cho mọi trường hợp, tuy nhiên lại xuất hiện các giao thức khả cấu hình cao và các giao thức được chuyên biệt cao cho các mục đích truyền tải tin cậy đặc biệt trong môi trường IP multicast. 1.2 Các thành phần tham gia vào truyền thông multicast Để tham gia vào quá trình trao đổi dữ liệu các máy tính và router cần hỗ trợ giao thức multicast, khi đó các máy có thể gửi hay nhận lưu lượng multicast. Máy nguồn gửi dữ liệu multicast tới một địa chỉ nhóm, đây là một địa chỉ lớp D. Các máy trạm muốn nhận các gói tin multicast sẽ liên hệ với router cục bộ để đăng ký tham gia nhóm và nhận dữ liệu. Các router sẽ sử dụng một giao thức định tuyến multicast để xác định các mạng con có các thành viên của nhóm và chuyển dữ liệu multicast tới các máy nhận. Nếu mạng con không có thành viên của nhóm, router sẽ không chuyển dữ liệu tới mạng đó. Ta sẽ tìm hiểu các thành thành phần tham gia vào truyền thông multicast và hoạt động của chúng trong mạng qua minh hoạ trên hình 1.2:
6 Hình 1.2: Các thành phần tham gia vào truyền thông multicast Trong mô phỏng trên hình 1.2 các hoạt động diễn ra như sau: − Host A trong Subnet 1 là một nguồn multicast và gửi dữ liệu multicast tới địa chỉ nhóm. − Host B trong Subnet 1 gửi yêu cầu tham gia nhóm tới router cục bộ của nó. Bởi vì Host B đã gia nhập vào nhóm nên giao diện mạng của nó sẽ lắng nghe các gói dữ liệu gửi tới địa chỉ nhóm. Các máy tính còn lại trong Subnet 1 không tham gia nhóm nên chúng sẽ lọc bỏ các lưu lượng gửi tới địa chỉ nhóm multicast. − Router sẽ chuyển dữ liệu multicast tới tất cả các mạng con có thành viên của nhóm. Trong trường hợp này, router sẽ chuyển dữ liệu từ Subnet 1 tới Subnet 3. − Host C trong Subnet 3 đã tham gia vào nhóm do đó nó sẽ nhận dữ liệu multicast. − Host D trong Subnet 3 gửi yêu cầu tới router để tham gia nhóm, sau khi tham gia nhóm giao diện mạng của nó sẽ lắng nghe và nhận các dữ liệu gửi tới địa chỉ nhóm. Các thành phần tham gia vào truyền thông multicast:
7 − Host (bao gồm nguồn hoặc đích): là các là các máy tính tham gia kết nối vào mạng và hỗ trợ quá trình gửi và nhận dữ liệu multicast. − Router: là các router hỗ trợ giao thức multicast, nó có khả năng xử lý các yêu cầu tham gia hay rời nhóm và có giao thức định tuyến multicast để xác định và chuyển dữ liệu tới các mạng con. − Địa chỉ multicast: là địa chỉ lớp D, nó chính là địa chỉ của nhóm multicast. − Nhóm multicast: là một tập các thiết bị đầu cuối lắng nghe dữ liệu gửi tới một địa chỉ multicast. − MBone: viết tắt của từ Internet multicast backbone là một phần của Internet hỗ trợ quá trình định tuyến và gửi dữ liệu multicast. 1.3 Địa chỉ multicast Các router phải có phương thức để phân biệt dữ liệu dạng multicast với dạng unicast hay broadcast. Điều này thực hiện thông qua việc gán địa chỉ IP, bằng cách dùng địa chỉ lớp D từ 224.0.0.0 đến 239.255.255.255 cho multicast các thiết bị mạng có thể nhanh chóng lọc ra các địa chỉ multicast bằng cách đọc 4 bit bên trái của một địa chỉ. Bốn bit này của một địa chỉ multicast luôn luôn bằng 1110, hình 1.3 thể hiện định dạng của một địa chỉ lớp D. 28 bits Class D 1 1 1 0 Multicast Group ID Hình 1.3: Định dạng của địa chỉ IP lớp D Làm thế nào để một router kết hợp một địa chỉ multicast của IP với một địa chỉ MAC. Do không có cơ chế tương đương với giao thức phân giải địa chỉ như trong truyền thông unicast, một dạng giá trị đặc biệt dành riêng cho địa chỉ MAC của multicast sẽ được dùng. Các địa chỉ này bắt đầu bằng 01005E, phần 28 bit sau của địa chỉ IP multicast sẽ được ánh xạ vào 23 bit thấp của địa chỉ MAC bằng một giải thuật đơn giản.
8 224 - 239 X Y Z IP Multicast 1110 5 bit 28 bit Không sử dụng Ánh xạ sang địa chỉ MAC Multicast 0 0 0 0 0 0 0 1 0 0000000010111010 MAC Address 01 00 5E X Y Z Hình 1.4: Ánh xạ địa chỉ IP multicast sang địa chỉ MAC Hình 1.4 cho thấy cơ chế ánh xạ địa chỉ, chỉ có 23 bit cuối của địa chỉ là được chép từ địa chỉ IP sang địa chỉ MAC. Tuy nhiên chú ý rằng có 5 bit của địa chỉ IP không được chuyển sang địa chỉ MAC. Ánh xạ này làm nảy sinh một vấn đề là có thể có 32 địa chỉ multicast khác nhau có thể ánh xạ vào cùng một địa chỉ MAC. Sự nhập nhằng này dẫn đến một vấn đề nhỏ khi host multicast nhận một Ethernet frame của địa chỉ multicast. Một địa chỉ MAC có thể tương ứng với 32 địa chỉ IP multicast khác nhau. Vì vậy, khi một host nhận dữ liệu nó kiểm tra tất cả các frame có MAC mà nó quan tâm. Sau đó host này phải kiểm tra phần địa chỉ IP bên trong mỗi frame để nhận ra phần địa chỉ của từng nhóm multicast. Sau đây là một số không gian địa chỉ được dành riêng của multicast: − Toàn bộ không gian địa chỉ multicast: 224.0.0.0 - 239.255.255.255. − Địa chỉ link-local: 224.0.0.0 - 224.0.0.255 được dùng bởi các giao thức định tuyến. Router sẽ không chuyển các gói tin có địa chỉ này. Các địa chỉ bao gồm địa chỉ tất cả các host 224.0.0.1, tất cả các router 224.0.0.2, tất cả các OSPF router 224.0.0.5 đây là địa chỉ các nhóm cố định vì các địa chỉ này được xác định trước. − Khoảng địa chỉ dành cho quản trị 239.0.0.0 - 239.255.255.255 được dùng trong các miền multicast khác nhau, giống như dãy địa chỉ dành riêng trong RFC1918. Địa chỉ này không được sử dụng giữa các miền multicast nên nó có thể được dùng lại nhiều lần.
9 − Địa chỉ toàn cục 224.0.1.0 - 238.255.255.255 được dùng bởi bất cứ đối tượng nào. Các địa chỉ này được sử dụng trên Internet vì vậy địa chỉ này phải duy nhất. 1.4 Cây phân phối multicast Để phân phối dữ liệu multicast tới tới tất cả các máy nhận, cây phân phối multicast được sử dụng, nó có tác dụng điều khiển đường đi của dữ liệu truyền trên mạng. Có hai loại cơ bản của cây phân phối multicast là cây nguồn và cây chia sẻ. 1.4.1 Cây nguồn Dạng đơn giản nhất của cây phân phối là cây nguồn,với gốc của nó chính là nguồn dữ liệu multicast và các nhánh của nó dẫn tới các đầu cuối nhận dữ liệu trên mạng. Do loại cây này sử dụng đường đi ngắn nhất nên còn có tên là cây đường đi ngắn nhất (Shortest Path Tree – SPT). Hình 1.5 biểu diễn một ví dụ của cây SPT cho nhóm 224.1.1.1 có gốc tại host A là nguồn dữ liệu và hai máy nhận là host B và host C. Hình 1.5: Cây đường đi ngắn nhất của host A
10 Hình 1.6: Cây đường đi ngắn nhất của host B Ký hiệu đặc biệt (S, G) chỉ ra một cây SPT trong đó S là địa chỉ IP của nguồn dữ liệu và G là địa chỉ của nhóm multicast. Áp dụng cho mạng như trên hình 1.5 ký hiệu có thể được viết như sau (192.1.1.1, 224.1.1.1). Mỗi ký hiệu (S, G) ứng với một nguồn gửi dữ liệu vì thế nếu host B cũng gửi dữ liệu tới nhóm 224.1.1.1 và các host A và C là các máy nhận thì ký hiệu (S, G) ứng với nguồn B sẽ là (192.2.2.2, 224.1.1.1) như trong hình 1.6. 1.4.2 Cây chia sẻ Không có gốc ứng với từng nguồn như cây nguồn, các cây chia sẻ sử dụng một gốc chung duy nhất tại một điểm đã chọn trên mạng. Gốc chia sẻ này còn được gọi là điểm hẹn (Rendezvous Point – RP). Hình 1.7 thể hiện một cây chia sẻ cho nhóm 224.2.2.2 với gốc cây tại router D. Khi sử dụng cây chia sẻ, nguồn phải gửi lưu lượng của nó tới gốc và sau đó lưu lượng này được chuyển tiếp theo các nhánh của cây đến các đầu cuối nhận dữ liệu. Trong hình 1.7 dữ liệu multicast từ host A và host D được gửi tới gốc cây là router D và theo nhánh cây đến hai máy nhận là host B và host C. Bởi vì tất cả
11 các nguồn trong nhóm multicast cùng sử dụng chung một cây chia sẻ, một ký hiệu (*, G) được sử dụng để biểu diễn cây. Trong đó ký hiệu * có nghĩa là tất cả các nguồn và G biểu diễn địa chỉ nhóm multicast. Vì thế cây chia sẻ trong hình 1.7 có thể được viết (*, 224.2.2.2). Hình 1.7: Cây chia sẻ Cây chia sẻ được chia làm hai loại: cây một chiều và cây hai chiều. Trong cây hai chiều dữ liệu có thể truyền lên và xuống để tới tất cả các máy nhận. Hình 1.8 thể hiện một ví dụ của cây chia sẻ hai chiều, trong đó dữ liệu từ host B được gửi ngược lên gốc cây và từ gốc cây được gửi xuống router B đến router A và đến máy nhận. Cây chia sẻ một chiều chỉ cho dữ liệu multicast đi xuống theo chiều từ gốc cây đến các máy nhận. Vì thế nguồn dữ liệu cần sử dụng một cách khác để gửi dữ liệu tới gốc cây và từ đó chuyển tới các máy nhận. Một phương pháp được sử dụng đó là cho gốc của cây chia sẻ tham gia vào một cây SPT có gốc là nguồn dữ liệu. Hình 1.9 minh họa một cây chia sẻ một chiều trong đó gốc của cây tham gia vào cây SPT có gốc là host B và dữ liệu được gửi từ B tới gốc. Khi gốc cây nhận
12 dữ liệu nó sẽ gửi dữ liệu xuống các nhánh để tới các máy nhận. Giao thức định tuyến PIM sử dụng phương pháp này để lấy dữ liệu từ nguồn tới router RP. Hình 1.8: Cây chia sẻ hai chiều Hình 1.9: Cây chia sẻ một chiều sử dụng cây SPT
13 Hình 1.10: Cây chia sẻ một chiều sử dụng định tuyến unicast Một cách khác để gửi dữ liệu multicast tới gốc cây là cho gốc cây kết nối trực tiếp với nguồn và dữ liệu được gửi tới gốc thông qua phương thức unicast. Giao thức định tuyến CBT sử dụng phương pháp này khi một máy nguồn chỉ gửi dữ liệu tới nhóm (máy nguồn chỉ gửi dữ liệu và không nhận dữ liệu từ nhóm). Trong hình 1.10 host A là nguồn chỉ gửi dữ liệu nó không tham gia vào nhóm multicast vì thế nó không thuộc một nhánh trên cây chia sẻ. Trong ví dụ trên router A đóng gói dữ liệu multicast từ host A và sử dụng định tuyến unicast để gửi gói tin trực tiếp đến gốc cây. Tại gốc cây dữ liệu được mở gói và gửi xuống các nhánh cây để tới máy nhận. 1.5 Chuyển tiếp multicast Trong cơ chế định tuyến unicast, lưu lượng được chuyển tiếp qua mạng theo một đường duy nhất từ nguồn tới đích. Router unicast không thực sự quan tâm đến địa chỉ nguồn, nó chỉ quan tâm đến địa chỉ đích và cách để chuyển tiếp lưu lượng tới đích. Router quét bảng định tuyến của nó và chuyển tiếp một bản sao duy nhất qua giao diện hướng đến đích. Trong cơ chế multicast nguồn gửi dữ
14 liệu tới một nhóm các máy thông qua địa chỉ nhóm được lưu trong trường địa chỉ đích của một gói tin IP. Vì thế các gói tin multicast không thể chỉ đơn giản xác định đường đi tiếp theo cho gói tin dựa vào địa chỉ đích như trong giao thức định tuyến unicast. Các router thường phải gửi dữ liệu lên nhiều giao diện của nó để đến được tất cả các máy nhận. Chính vì thế giao thức định tuyến multicast phức tạp hơn so với định tuyến unicast. Hầu hết các phương pháp định tuyến multicast sử dụng chuyển tiếp theo đường dẫn ngược (Reverse Path Forwarding – RPF) như là một cơ chế kiểm tra chính để quyết định chuyển tiếp hay loại bỏ một gói tin. Khi một gói tin multicast đến router, router sẽ thực hiện kiểm tra RPF đối với gói tin. Địa chỉ nguồn của gói tin sẽ được kiểm tra để biết rằng gói tin đó có được nhận từ giao diện có đường đi ngắn nhất trở lại nguồn (giao diện RPF) hay không. Nếu kiểm tra RPF thành công gói tin được chuyển tiếp, nếu kiểm tra thất bại router sẽ loại bỏ gói tin đó. Cách thức để router xác định giao diện là RPF đối với một gói tin phụ thuộc vào giao thức định tuyến được sử dụng. Một số giao thức multicast duy trì một bảng định tuyến multicast riêng của nó để sử dụng vào kiểm tra RPF như giao thức DVMRP. Có những giao thức khác sử dụng bảng định tuyến unicast ở trên router để xác định giao diện RPF như giao thức PIM hay CBT. Mỗi lần một gói tin multicast được chuyển tiếp bởi router giá trị trường TTL (Time To Live) trong IP header sẽ giảm đi một. Nếu giá trị TTL của gói tin giảm về không, router sẽ loại gói tin. Giới hạn TTL có thể được áp dụng cho một giao diện cụ thể của một router multicast để ngăn chặn các gói tin multicast có giá trị TTL nhỏ hơn ngưỡng được chuyển qua giao diện. Trong hình 1.11 minh họa một router áp dụng giới hạn TTL cho các giao diện của nó. Hình 1.11: Giới hạn TTL
15 Trong hình 1.11, gói tin multicast đến router từ cổng Serial0, giả sử rằng kiểm tra RPF thành công và các cổng còn lại của router đều có trong danh sách cổng ra cho nhóm multicast, vì thế dữ liệu sẽ được chuyển tiếp đến các cổng. Tuy nhiên do router áp dụng giới hạn ngưỡng TTL tại các giao diện vì thế gói tin chỉ được chuyển tiếp ra các cổng Serial1 và Ethernet0, còn ở cổng Serial2 ngưỡng TTL là 64 lớn hơn giá trị TTL của gói tin là 23 vì thế gói tin không được chuyển tiếp. 1.6 Đường trục multicast Mạng đường trục multicast – MBone được xây dựng nhằm đánh giá các ứng dụng cũng như các giao thức được xây dựng phục vụ truyền thông multicast dữ liệu, audio và video. MBone được thiết kế hoạt động ở lớp trên của Internet và được cấu thành bởi mạng lưới các ốc đảo multicast. Các ốc đảo giao tiếp với mạng bên ngoài thông qua một bộ định tuyến có khả năng xử lý các gói IP multicast thông qua hỗ trợ giao thức quản lý nhóm Internet IGMP và các giao thức định tuyến khác được xác định là một MRouter hay IP multicast router. Tiếp giáp với các ốc đảo là các bộ định tuyến IP truyền thống chỉ hỗ trợ xử lý các gói IP unicast được xác định là các URouter (IP unicast router). Các MRouter của các mạng khác nhau kết nối thông qua các liên kết ảo từ điểm tới điểm thông qua cơ chế đường hầm – tunneling. Kết quả là MBone được hình thành nhờ tập hợp các MRouter được nối với nhau bởi các đường hầm bao phủ toàn mạng. Hình 1.12: Cơ chế đường hầm liên kết các ốc đảo multicast
16 Đường hầm là cơ chế cho phép chuyển gói dữ liệu multicast từ MRouter nguồn đến MRouter đích thông qua các bộ định tuyến. MRouter nguồn thực hiện đóng gói và chuyển tiếp dữ liệu. Việc đóng gói theo cơ chế đường hầm thực hiện bổ sung thêm phần tiêu đề IP mới với địa chỉ đích là địa chỉ IP unicast của MRouter ở đầu bên kia của đường hầm và địa chỉ nguồn là địa chỉ IP unicast của MRouter đang gửi gói tin đó. Hình 1.13: Đóng gói IP multicast theo cơ chế tunneling Các bộ định tuyến trung gian nằm trên tuyến liên kết từ MRouter nguồn đến MRouter đích sẽ xem gói này như gói dữ liệu unicast bình thường và truyền đi theo thông tin trong bảng định tuyến unicast. Ốc đảo multicast đích ở phía bên kia của đường hầm sẽ nhận gói unicast này và tách phần header đã được thêm vào rồi sau đó gửi gói dữ liệu đó đi một cách thích hợp. Với bộ định tuyến các gói dữ liệu được xem như đến từ MRouter lân cận và trong suốt đối với các bộ định tuyến trung gian. Đường đi trung gian đã bị ẩn đi đối với bộ định tuyến này. Khi đó các MRouter xử lý các gói IP multicast tương tự như các bộ định tuyến xử lý các gói IP unicast như thể hiện trên hình 1.13. Hình 1.14: Cơ chế đường hầm liên kết các MRouter
17 Như thể hiện trên hình 1.14, MRouter R2 muốn gửi một gói tin IP đa hướng tới MRouter R5. Trước hết, R2 sẽ đóng vỏ gói tin (chuyển từ gói IP đa hướng thành gói IP đơn hướng) rồi chuyển tiếp tới URouter R3. Gói đa hướng này sẽ đi theo tuyến R3-R7-R8-R5. Như vậy, theo cơ chế đường hầm, với MRouter R5 thì gói tin này được xử lý với địa chỉ nguồn đến từ R2. 1.7 Giao thức quản lý nhóm Internet Để nhận dữ liệu multicast từ một nguồn, các máy nhận đầu tiên phải tham gia vào một nhóm multicast, nhóm này được xác định thông qua địa chỉ multicast. Một host có thể tham gia vào một nhóm multicast bằng cách gửi các yêu cầu đến router gần nhất. Tác vụ này được thực hiện thông qua giao thức quản lý nhóm Internet - IGMP (Internet Group Management Protocol). Giao thức IGMP phát triển từ giao thức Host Membership Protocol, được mô tả trong tài liệu của Deering. IGMP phát triển từ IGMPv1 (RFC 1112) đến IGMPv2 (RFC 2236) và phiên bản mới nhất IGMPv3 (RFC 3376). Các thông điệp IGMP được đóng gói trong IP datagram với trường protocol number bằng 2, trong đó trường TTL có giá trị bằng 1. Các gói IGMP chỉ được truyền trong mạng LAN và không được tiếp tục chuyển sang LAN khác do giá trị TTL của nó. Hai mục đích quan trọng nhất của IGMP là: − Thông báo cho router multicast biết rằng có một máy muốn nhận dữ liệu từ một nhóm multicast. − Thông báo cho router biết có một máy muốn rời nhóm multicast (nói cách khác, máy đó không còn quan tâm đến việc nhận dữ liệu multicast nữa). Các router thường dùng IGMP để duy trì thông tin cho từng giao diện để biết những nhóm multicast nào router cần phải truyền dữ liệu và những host nào muốn nhận. 1.7.1 Giao thức IGMPv1 Giao thức IGMP phiên bản 1 bao gồm 2 loại thông điệp là Host Membership Report và Host Membership Query. Định dạng của thông điệp IGMPv1 được thể hiện như trong hình 1.15:
18 0 3 4 7 8 15 16 31 Version Type Unused Checksum Group Address Hình 1.15: Thông điệp IGMPv1 Giá trị của các trường trong IGMPv1 được mô tả trong bảng 1.1: Bảng 1.1: Các trường trong thông điệp IGMPv1 Tên trường Độ dài Mô tả Version 4 bit Chỉ định phiên bản của giao thức và luôn có giá trị là 1 Type 4 bit Xác định 2 kiểu thông điệp có giá trị: 0x1 cho Host Membership Query 0x2 cho Host Membership Report Unused 8 bit Chứa giá trị 0 khi gửi và bị bỏ qua khi nhận Checksum 16 bit Dùng để kiểm tra lỗi trong quá trình truyền dữ liệu Group Address 32 bit Được gán về giá trị 0.0.0.0 khi router gửi gói tin Host Membership Query và được gán giá trị địa chỉ nhóm multicast khi một máy gửi thông điệp Host Membership Report 1.7.1.1 Thông điệp Host Membership Report Để tham gia vào một nhóm, host sẽ gửi một thông điệp Host Membership Report tới router cục bộ, nó không cần quan tâm có các host khác trên mạng con đã là thành viên của nhóm hay chưa. Thông điệp này sử dụng địa chỉ 224.0.0.1 (địa chỉ all-hosts) như địa chỉ đích và chứa địa chỉ nhóm mà host muốn tham gia.
19 1.7.1.2 Thông điệp Host Membership Query Một router IGMPv1 sẽ gửi một cách định kỳ (mỗi 60 giây) thông điệp Host Membership Query đến tất cả các host để kiểm tra xem các host này có còn quan tâm nhận dữ liệu multicast nữa không. Các host có thể tham gia vào các nhóm multicast ở bất kỳ thời điểm nào. IGMPv1 không có cơ chế để cho phép một host rời khỏi một nhóm nếu host đó không còn muốn nhận dữ liệu từ nhóm multicast. Thay vào đó, router sẽ kết luận là một cổng của nó không còn thuộc về một nhóm multicast nào nếu cổng đó không nhận được thông điệp Host Membership Report trong ba chu kỳ truy vấn liên tiếp. Điều này có nghĩa là, dữ liệu multicast vẫn gửi vào một phân đoạn mạng trong ba chu kỳ truy vấn liên tiếp sau khi tất cả các thành viên của nhóm không còn lắng nghe dữ liệu multicast nữa. 1.7.2 Giao thức IGMPv2 Giao thức IGMP phiên bản 2 là sự mở rộng các chức năng của IGMP phiên bản 1 bao gồm: − Một phương thức để xác định router nào sẽ gửi các thông điệp truy vấn multicast khi có nhiều router cùng kết nối vào một mạng con. − Một thông điệp mới được sử dụng khi một host muốn rời nhóm. − Một thông điệp mới cho phép router truy vấn cho từng nhóm cụ thể thay vì tất cả các nhóm. − Phiên bản mới của thông điệp Host Membership Report. Định dạng của thông điệp IGMPv2 được thể hiện như trong hình 1.16: 0 7 8 15 16 31 Type Max RTime Checksum Group Address Hình 1.16: Thông điệp IGMPv2
20 Giá trị của các trường trong IGMPv1 được mô tả trong bảng 1.2: Bảng 1.2: Các trường trong thông điệp IGMPv2 Tên trường Độ dài Mô tả Type 8 bit Xác định 4 kiểu thông điệp có giá trị: 0x11 cho Host Membership Query 0x12 cho IGMPv1 Host Membership Report 0x16 cho IGMPv2 Host Membership Report 0x17 cho Leave Group Message Maximum 8 bit Chỉ ra khoảng thời gian tối đa (tính bằng giây) Response Time mà một host có thể phản hồi thông tin truy vấn, chỉ sử dụng trong các thông điệp truy vấn Checksum 16 bit Dùng để kiểm tra lỗi trong quá trình truyền dữ liệu Group Address 32 bit Được gán giá trị 0.0.0.0 trong gói tin truy vấn và gán địa chỉ nhóm nếu thông điệp là cho từng nhóm cụ thể. Các thông điệp Host Membership Report hoặc thông điệp Leave Group có thể mang địa chỉ của nhóm trong trường này 1.7.2.1 Lựa chọn router truy vấn Khác với IGMPv1, trong đó giao thức định tuyến multicast sẽ lựa chọn router truy vấn, IGMPv2 sử dụng một phương thức lựa chọn đơn giản để chọn một router trên mỗi mạng con để gửi định kỳ các thông điệp Host Membership Query. Router được chọn là router có địa chỉ IP nhỏ nhất. Khi một router nhận được một gói tin truy vấn từ một router nào đó, nó sẽ kiểm tra địa chỉ nguồn của gói tin đó. Nếu địa chỉ nguồn của router cục bộ nhỏ hơn địa chỉ nguồn trong gói tin vừa đến, router sẽ vẫn tiếp tục gửi gói tin query vì nó biết rằng nó sẽ giữ vai
21 trò truy vấn. Còn nếu địa chỉ nguồn của gói tin truy vấn nhỏ hơn, router sẽ từ bỏ vai trò truy vấn và không gửi gói tin. 1.7.2.2 Thông điệp rời nhóm Khi một host muốn rời nhóm, nó sẽ gửi một thông điệp tới địa chỉ 224.0.0.2 (địa chỉ all-routers). Khi nhận được thông điệp rời nhóm, router sẽ gửi truy vấn cho từng nhóm cụ thể tới mạng con chứa host. Nếu router không nhận được được trả lời của truy vấn nó sẽ quyết định rằng trên mạng con đó không còn thành viên nào của nhóm và không đẩy dữ liệu multicast tới đó nữa. Nếu router nhận được phản hồi, nghĩa là trên mạng con đó vẫn còn host là thành viên của nhóm và nó sẽ tiếp tục chuyển dữ liệu tới. Sử dụng thông điệp rời nhóm làm giảm đi các dữ liệu thừa mà router chuyển đến các mạng con khi không còn thành viên nào của nhóm. 1.7.2.3 Truy vấn cho từng nhóm Một thông điệp Host Membership Query được gửi tới địa chỉ 224.0.0.1 để tìm ra các nhóm multicast có thành viên trên mạng con. Trong IGMPv2 các router còn có thể gửi thông điệp cho từng nhóm cụ thể tới một địa chỉ nhóm để xác định nhóm đó có thành viên trên một mạng con hay không. 1.7.3 Giao thức IGMPv3 IGMP phiên bản 3 mở rộng chức năng của IGMPv2 bằng việc hỗ trợ tính năng multicast cho từng nguồn cho phép các host lọc dữ liệu đi vào dựa trên địa chỉ IP nguồn. Với IGMPv3 có thể có nhiều nguồn cho một dòng dữ liệu multicast vì thế các host có thể gia nhập nhóm và nhận dữ liệu từ các nguồn gần nhất. IGMPv3 còn cải tiến thông điệp Host Membership Query và thêm phiên bản mới của Host Membership Report. 1.7.3.1 Lọc dữ liệu Đây là khả năng cho phép một host chỉ ra nó sẽ nhận nguồn dữ liệu multicast từ địa chỉ nguồn xác định. Với IGMPv1 và IGMPv2 một host thông báo nhóm thành viên mà không quan tâm nguồn của dữ liệu gửi tới nhóm. Nếu dữ liệu multicast gửi tới nhóm từ nhiều nguồn, một mạng con có thể nhận dữ liệu
22 multicast từ mỗi nguồn. IMGPv3 cho phép một host chỉ rõ hai thuộc tính sau đây cho các nhóm multicast cụ thể: − Danh sách các nguồn mà host nhận dữ liệu. − Danh sách các nguồn mà host không nhận dữ liệu. Các multicast router và các giao thức định tuyến multicast sử dụng thông tin cho từng nguồn cụ thể trong IGMPv3 Host Membership Report để ngăn việc chuyển các thông điệp multicast từ một nguồn tới một mạng con không có thành viên của nhóm. 1.7.3.2 Thông điệp IGMPv3 Host Membership Query IGMPv3 Host Membership Query có cùng giá trị kiểu và có cùng định dạng với IGMPv2 Host Membership Query ngoài trừ nó thêm một số trường ở sau trường địa chỉ nhóm. Các trường này cung cấp các tham số truy vấn cho router và chỉ rõ các nguồn được chấp nhận và không được chấp nhận ứng với mỗi nhóm multicast. Danh sách các nguồn được chấp nhận và không chấp nhận chỉ được sử dụng cho truy vấn tới một nhóm cụ thể có sử dụng tính năng lọc dữ liệu. Bảng 1.3 mô tả các trường trong thông điệp IGMPv3 Host Membership Query: Bảng 1.3: Các trường trong thông điệp IGMPv3 Host Membership Query Tên trường Độ dài Mô tả Type 8 bit Xác định 4 kiểu thông điệp có giá trị: 0x11 cho Host Membership Query 0x12 cho IGMPv1 Host Membership Report 0x16 cho IGMPv2 Host Membership Report 0x17 cho Leave Group Message Maximum 8 bit Chỉ ra khoảng thời gian tối đa (tính bằng giây) Response Time mà một host có thể phản hồi thông tin truy vấn, chỉ sử dụng trong các thông điệp truy vấn Checksum 16 bit Dùng để kiểm tra lỗi trong quá trình truyền dữ liệu
23 Group Address 32 bit Được gán giá trị 0.0.0.0 trong gói tin truy vấn và gán địa chỉ nhóm nếu thông điệp là cho từng nhóm cụ thể. Các thông điệp Membership Report hoặc thông điệp Leave Group có thể mang địa chỉ của nhóm trong trường này Reserved (Dành 4 bit Chứa giá trị 0 khi gửi và bị bỏ qua khi nhận riêng) Suppress 1 bit Gán giá trị 1 để chi rõ các router nhận dừng cập nhật thời gian khi nhận một truy vấn Querier’s 3 bit Chỉ ra các gói datagram mong đợi trên mạng. Robustness IGMP có thể lấy lại QRV-1 gói datagram bị Variable (QRV) mất Querier’s Query 8 bit Chỉ ra khoảng thời gian tính bằng giây mà Interval router đợi giữa hai truy vấn thông thường Code(QQIC) Number of 16 bit Chỉ số lượng địa chỉ nguồn chứa thông điệp Sources truy vấn Source Addresses 32 bit Chứa địa chỉ IP của nguồn multicast 1.7.3.3 Thông điệp IGMPv3 Host Membership Report Host sử dụng thông điệp IGMPv3 Host Membership Report để chỉ rõ các nhóm multicast mà nó muốn gia nhập, với mỗi địa chỉ nhóm kèm theo danh sách những địa chỉ nguồn mà host muốn nhận dữ liệu multicast và nguồn nào host không muốn nhận. Thông điệp IGMPv3 Host Membership Report chứa một dãy các bản ghi nhóm. Mỗi nhóm chứa địa chỉ nhóm multicast và một danh sách liên kết các nguồn. Thông điệp IGMPv3 Host Membership Report được gửi tới địa chỉ 224.0.0.22, đây là địa chỉ dành riêng cho router multicast hỗ trợ IGMPv3.
24 Bảng 1.4: Các trường trong thông điệp IGMPv3 Host Membership Report Tên trường Độ dài Mô tả Type 8 bit Xác định 3 kiểu thông điệp có giá trị: 0x12 cho IGMPv1 Host Membership Report 0x16 cho IGMPv2 Host Membership Report 0x22 cho IGMPv3 Host Membership Report Reserved 8 bit Chứa giá trị 0 khi gửi và bị bỏ qua khi nhận Checksum 16 bit Dùng để kiểm tra lỗi trong quá trình truyền dữ liệu Reserved 16 bit Chứa giá trị 0 khi gửi và bị bỏ qua khi nhận Number of 16 bit Chứa số lượng của nhóm bản ghi trong thông Records điệp Group Records Variable Mỗi bản ghi chỉ ra địa chỉ IP cho nhóm multicast tham gia hay rời và danh sách các nguồn nhận dữ liệu và không nhận dữ liệu
25 CHƯƠNG 2 ĐỊNH TUYẾN MULTICAST Các giao thức định tuyến multicast được chia làm ba loại chính gồm: giao thức hoạt động theo mô hình tập trung (dense mode) như DVMRP và PIM-DM, các giao thức hoạt động theo mô hình phân tán (sparse mode) như PIM-SM và giao thức hoạt động theo mô hình trạng thái liên kết (link-state) như MOSPF. Các giao thức dense mode hoạt động theo cơ chế quảng bá và loại bỏ trong đó các router cho rằng trên các mạng con tồn tại ít nhất một máy nhận dữ liệu multicast, vì thế chúng gửi dữ liệu xuống tất cả các mạng cho đến khi nhận được thông báo dừng gửi dữ liệu. Với cơ chế này các giao thức dense mode phù hợp với các mạng máy tính nhỏ, trong đó lưu lượng multicast được truyền tới hầu hết các máy trên mạng. Các giao thức sparse mode hoạt động theo cách ngược lại, các router sẽ không gửi dữ liệu lên mạng trừ khi nó nhận được yêu cầu gửi dữ liệu từ các máy nhận. Điều này làm giảm dữ liệu dư thừa truyền trên mạng, giúp cho các giao thức sparse mode phù hợp với các mạng lớn, với số lượng các máy tham gia nhận dữ liệu nhiều nhưng nằm rải rác trên các mạng con. 2.1 Giao thức định tuyến multicast véctơ khoảng cách Giao thức định tuyến multicast véctơ khoảng cách (Distance Vector Multicast Routing Protocol – DVMRP) là giao thức định tuyến multicast đầu tiên được sử dụng phổ biến. DVMRP được phát triển dựa trên giao thức định tuyến unicast Routing Information Protocol (RIP) với một số thay đổi đề phù hợp với cơ chế multicast. 2.1.1 Tìm kiếm hàng xóm Tìm kiếm router hàng xóm là một quá trình quan trọng bởi vì các router sử dụng giao thức DVMRP cần phải duy trì một danh sách các router hàng xóm để thực hiện chuyển tiếp multicast. Điều này đặc biệt đúng khi DVMRP hoạt động trên mạng đa truy cập như mạng Ethernet, bởi vì trên mạng có thể có nhiều router
26 DVMRP cùng tham gia. Để thực hiện điều đó, các thông điệp thăm dò DVMRP Probe được các router gửi một cách định kỳ tới địa chỉ all-DVMRP-router (224.0.0.4). Trên hình 2.1 thể hiện cơ chế tìm kiếm hàng xóm thông qua hoạt động của 2 router. Hình 2.1: Tìm hàng xóm trong DVMRP Các bước hoạt động của cơ chế tìm kiếm được minh họa trên hình 2.1 gồm: − Đầu tiên router 1 gửi một gói tin thăm dò, lúc này router 1 chưa phát hiện được các hàng xóm vì thế danh sách hàng xóm trong gói tin là rỗng. − Router 2 nhận được thông điệp thăm dò từ router 1, nó thêm địa chỉ IP của router 1 vào danh sách các router hàng xóm của giao diện đã nhận gói tin. − Router 2 gửi thông điệp thăm dò lên mạng, trong đó có chứa địa chỉ IP của router 1 trong danh sách hàng xóm. − Router 1 nhận được thông điệp từ router 2 thêm địa chỉ IP của router 2 vào danh sách hàng xóm. Và ở chu kỳ gửi gói tin tiếp theo tiếp theo, router 1 gửi thông điệp lên mạng với địa chỉ IP của router 2 trong danh sách hàng xóm. Khi một router nhận được thông điệp thăm dò trong đó địa chỉ IP của nó có trong danh sách hàng xóm, router biết rằng đã có một kết nối hai chiều được thiết lập thành công giữa nó và hàng xóm, khi đó hai router có thể trao đổi dữ liệu với nhau. 2.1.2 Trao đổi thông báo định tuyến
27 Các thông báo định tuyến của DVMRP được gửi một cách định kỳ theo cách giống với giao thức định tuyến unicast RIP. Một điểm khác biệt quan trọng là DVMRP quảng bá các đường đi cùng với subnet mask cho phép DVMRP hoạt động được trên giao thức classless. Trên hình 2.2 thể hiện một mạng multicast bao gồm 2 router sử dụng DVMRP kết nối với nhau. Hình 2.2: Trao đổi định tuyến DVMRP bước 1 Trong bảng định tuyến của 2 router có chứa một số đường đi mà các router đã học được thông qua giao diện S0. Giả sử router 2 gửi thông điệp thông báo trước như trên hình 2.3.
28 Hình 2.3: Trao đổi định tuyến DVMRP bước 2 Thông báo định tuyến từ router 2 chứa hai đường đi và được gửi tới router 1. Router 1 thêm một thực thể cho mạng 204.1.16.0/24 vào bảng định tuyến của nó, ngoài ra vì router 2 có giá trị metric tới mạng 151.10.0.0 nhỏ hơn nên router 1 cập nhật thực thể đã có trong bảng định tuyến với giá trị metric mới là 4 và giao diện ra là E0. Sau đó router 1 phản hồi bằng cách gửi thông điệp thăm dò của nó lên mạng để tới router 2. Trong gói tin gửi tới router 2, router 1 đã sử dung kỹ thuật Poison Reverse với hai đường đi mà nó đã nhận trên cổng E0 bằng cách thêm giá trị ngưỡng (32) vào giá trị metric hiện tại. Kỹ thuật Poison Reverse trong DVMRP được sử dụng để thông báo tới một router là có một router khác phụ thuộc vào nó trong việc nhận dữ liệu từ một nhóm multicast. Vì thế router 2 biết rằng router 1 ở phía dưới trong cây multicast của nguồn dữ liệu và mong muốn nhận dữ liệu multicast từ hai mạng này thông qua router 2. Router 2 nhận thông báo và thêm vào bảng định tuyến của nó một thực thể mới cho mạng 198.14.32.0/24 như trong hình 2.4.
29 Hình 2.4: Trao đổi định tuyến DVMRP bước 3 Sau khi cập nhật bảng định tuyến router 2 sẽ gửi một thông báo Poison Reverse cho đường đi 198.14.32.0/24 nhận từ router 1 bằng cách thêm ngưỡng vào giá trị metric. Điều này cho router 1 biết router 2 là ở phía dưới và nhận dữ liệu multicast từ mạng nguồn 198.14.32.0/24 thông qua router 1. 2.1.3 Cắt nhánh DVMRP sử dụng cây nguồn để điều khiển đường đi của luồng dữ liệu, ban đầu dữ liệu multicast được gửi xuống tất cả các nhánh của cây. Để giảm lưu lượng dư thừa cần có một cơ chế cắt các nhánh cây mà trên đó không có các máy nhận dữ liệu. Vì thế tại các router lá không có máy nhận dữ liệu kết nối trực tiếp, một thông điệp DVMRP Prune được gửi ngược lên cây multicast để yêu cầu dừng gửi dữ liệu không mong muốn và cắt bỏ nhánh khỏi cây multicast. Trên hình 2.5 mô tả mạng với một nguồn hoạt động S gửi dữ liệu multicast tới nhóm G.
30 Hình 2.5: Cắt nhánh trong DVMRP bước 1 Máy nhận 1 tham gia vào nhóm multicast G và nhận dữ liệu từ S. Các đường mũi tên chỉ ra luồng lưu lượng (S, G) ban đầu đi xuống cây multicast (được thể hiện bởi các mũi tên đứt nét) trước khi thực hiện quá trình cắt nhánh. router C không phải là router được chọn để gửi dữ liệu (Designated Router – DR) cho mạng có máy nhận 1 kết nối vì thế nó trở thành một router lá. Vì thế router C gửi một thông điệp DVMRP Prune tới router B để yêu cầu dừng gửi dữ liệu không cần thiết (S, G). Khi nhận được thông điệp router B phản hồi bằng cách cắt bỏ đường đi tới router C. Lúc này cả hai router X và Y cũng là router lá vì thế nó gửi thông điệp Prune tới router E để yêu cầu cắt khỏi cây multicast. Router E biết rằng nó chỉ có 2 router hàng xóm, và vì cả hai router đã gửi thông điệp cắt nhánh nên router E cũng gửi thông điệp Prune cho lưu lượng (S, G) lên router D. Router D nhận thông điệp từ E sẽ cắt bỏ đường đi tới router E như trong hình 2.6.
31 Hình 2.6: Cắt nhánh trong DVMRP bước 2 2.1.4 Ghép nhánh Mỗi thông điệp cắt bỏ nhánh có một giá trị thời gian timeout, vì thế nếu một nhánh đã bị cắt bỏ khỏi cây multicast sau khi hết thời gian timeout nó lại có thể nhận dữ liệu từ nguồn. Tuy nhiên DVMRP còn hỗ trợ một cơ chế cho phép các nhánh cây bị cắt bỏ có thể ghép trở lại mà không cần phải đợi hết khoảng thời gian này. Để thực hiện điều này, router gửi một thông điệp DVMRP Graft tới router phía trên để thông báo nó muốn được ghép trở lại cây multicast. Sau khi router phía trên nhận được nó sẽ phản hồi lại bằng thông điệp Graft-Ack và chuyển tiếp lưu lượng multicast xuống router phía dưới. Trên hình 2.7 tiếp tục mô tả mạng như phần trước, giả sử lúc này máy nhận 2 trên router Y tham gia vào nhóm multicast và nhận dữ liệu từ nguồn S gửi tới nhóm G. Router Y biết rằng nó đang ở trạng thái bị cắt bỏ khỏi cây multicast của nguồn S vì thế nó gửi một thông điệp Graft tới router E. Khi router E nhận được thông điệp, router E chuyển trạng thái cho cổng kết nối với router Y từ trạng thái cắt bỏ sang trạng thái chuyển tiếp dữ liệu và gửi một thông điệp xác nhận Graft-Ack trở lại router Y.
32 Hình 2.7: Ghép nhánh trong DVMRP bước 1 Sau đó router E tiếp tục gửi tới router D một thông điệp Graft để yêu cầu nhận dữ liệu multicast gửi tới nhóm G. Cuối cùng khi router D nhận được thông điệp từ router E nó phản hồi bằng một thông điệp Graft-Ack và chuyển tiếp dữ liệu multicast qua giao diện của nó để đến router E như trên hình 2.8. Hình 2.8: Ghép nhánh trong DVMRP bước 2
33 2.2 Giao thức PIM Dense Mode Giao thức PIM (Protocol Independent Multicast) có tên là giao thức multicast độc lập bởi vì nó hoạt động độc lập với giao thức định tuyến IP unicast. PIM không quan trọng giao thức nào được sử dụng để tạo ra bảng định tuyến unicast (bao gồm cả bảng định tuyến tĩnh) trên router, mà nó sử dụng thông tin từ bảng định tuyến unicast để thực hiện quá tình kiểm tra Reverse Path Forwarding (RPF) từ đó đưa ra quyết định gửi dữ liệu. Bởi vì PIM không phải duy trì dữ liệu của bảng định tuyến, nó sẽ không cần thực hiện các quá trình gửi và nhận các thông báo cập nhật đường đi trong bảng định tuyến giữa các router như các giao thức khác, điều đó làm giảm đáng kể lưu lượng truyền trên mạng. PIM có thể cấu hình để hoạt động theo hai cơ chế là dense mode và sparse mode, trong phần này chúng ta sẽ tìm hiểu về PIM dense mode (PIM – DM) bao gồm các quá trình cơ bản như: tìm kiếm hàng xóm, cắt bỏ và ghép thêm nhánh trên cây phân phối multicast, cơ chế xác nhận. 2.2.1 Tìm kiếm hàng xóm 2.2.1.1 Thông điệp Hello Cũng giống như giao thức DVMRP, PIM-DM sử dụng cơ chế tìm kiếm hàng xóm để thiết lập mối liên kết với router hàng xóm. Trong PIM-DMv1 thông điệp tìm kiếm có tên là Router Query được đóng gói trong thông điệp IGMP và được gửi tới địa chỉ 224.0.0.2 (địa chỉ all-routers). Trong PIM-DMv2 thông điệp thăm dò có tên là Hello được gửi theo chu kỳ 30 giây tới địa chỉ 224.0.0.13 (địa chỉ all-PIM-routers). Trong thông điệp Hello chứa một giá trị Holdtime để thông báo cho các máy nhận biết khoảng thời gian hiệu lực của kết nối giữa hai máy bị hết nếu không có thông điệp Hello khác được gửi trong thời gian đó. 2.2.1.2 Router được chỉ định Ngoài việc thiết lập mối liên kết hàng xóm, thông điệp PIM Hello cũng được sử dụng để tìm ra router được chỉ định để gửi dữ liệu (Designated Router – DR) cho mạng đa truy cập. Thông qua thông điệp Hello các router sẽ biết được router nào trên mạng có giá trị địa chỉ IP cao nhất, và router đó được chọn làm
34 DR cho mạng. Khi trong một phân đoạn mạng có nhiều router cùng tồn tại, người quản trị mạng thông thường cần chỉ định một router là DR. Tuy nhiên việc thay đổi địa chỉ IP của router để chỉ định một router là DR thường khó khăn hoặc không thể thực hiện. Để thực hiện điều này, trong thông điệp PIMv2 Hello thêm vào một lựa chọn về độ ưu tiên DR-Priority. Khi đó các router có độ ưu tiên cao sẽ được chọn làm DR, nếu có hai hay nhiều router cùng độ ưu tiên thì giá trị IP được so sánh để bầu chọn. 2.2.1.3 Cây phân phối multicast Bởi vì PIM-DM là một giao thức dense mode, cây nguồn (hay cây đường đi ngắn nhất) được sử dụng để chỉ ra quá trình phân phối dữ liệu tới các máy nhận trên mạng. Các cây nguồn được xây dựng bằng cách sử dụng cơ chế quảng bá và loại bỏ (flood and prune) ngay khi nguồn multicast bắt đầu truyền dữ liệu. Không như DVMRP là giao thức sử dụng bảng định tuyến multicast của riêng nó, PIM- DM sử dụng thông tin về hàng xóm của nó để xây dụng cây nguồn. Trong PIM- DM các router kết nối với nguồn được cho là ở trên cây đường đi ngắn nhất SPT và các hàng xóm PIM-DM khác ở các nhánh phía duới của nguồn dữ liệu. Cây SPT ban đầu chính là cây quảng bá (broadcast tree) bởi vì router gửi dữ liệu tới tất cả các hàng xóm của nó, mà không biết trên các router đó có tồn tại các máy nhận dữ liệu hay không. Hình 2.9 thể hiện một ví dụ về việc quảng bá dữ liệu multicast trên mạng PIM-DM xuống cây quảng bá multicast. Trong mạng trên hình 2.9, nguồn dữ liệu multicast gửi dữ liệu tới router A và B từ đó gửi tiếp xuống các router PIM-DM phía dưới là router C và D. Ta thấy rằng luồng dữ liệu ban đầu trước khi có các hoạt động cắt nhánh có nhiều đường đi dư thừa, như là router C nhận hai luồng dữ liệu giống nhau, hay router C và D cùng gửi dữ liệu tới một phân đoạn mạng. Cây quảng bá này sẽ được điều chỉnh để loại bỏ dư thừa khi quá trình loại bỏ nhánh được hoàn tất.
35 Hình 2.9: Cây phân phối PIM-DM 2.2.2 Cắt nhánh Các router PIM-DM gửi thông điệp cắt nhánh Prune lên router phía trên của nó khi có một trong các điều kiện sau: khi dữ liệu đến từ một giao diện không phải là giao diện RPF hay khi một router nhận thấy phân đoạn mạng phía sau nó không tồn tại các máy nhận muốn nhận dữ liệu từ nhóm multicast. Trên hình 2.10, giả sử metric cho đường đi từ router A đến C tốt hơn đường đi từ router B đến C, lúc đó router C gửi thông điệp Prune tới router B vì dữ liệu đến nó trên giao diện không phải là giao diện RPF đối với nguồn. Ở bước tiếp theo, router B phản hồi lại thông điệp Prune được gửi từ C và đường đi từ router B đến router C bị loại bỏ khỏi cây multicast. Ngoài ra router I là một router lá không có các máy nhận dữ liệu kết nối tới, vì thế nó gửi một thông điệp Prune tới router E. Router E phản hồi lại bằng cách loại bỏ đường đi tới router I và bởi vì router E cũng không có các máy nhận dữ liệu kết nối trực tiếp nó cũng sẽ gửi dữ liệu tới router C và D. Tuy nhiên vì máy nhận 1 kết nối trực tiếp tới cùng giao diện, router C và D sẽ bỏ qua thông điệp Prune từ E. Điều đó có nghĩa dữ liệu từ nguồn vẫn tiếp tục được gửi tới router E và E tiếp tục gửi thông điệp Prune lên router C và D.
36 Hình 2.10: Cắt nhánh trong PIM-DM bước 1 Hình 2.11: Cắt nhánh trong PIM-DM bước 2 Trong cơ chế cắt nhánh trên mạng đa truy cập, các router PIM-DM mong muốn nhận thông điệp Join từ các hàng xóm để phản hồi lại thông điệp Prune của hàng xóm khác trên cùng một giao diện. Router G và H trong hình 2.12 là một ví dụ của cơ chế hoạt động trên.
37 Hình 2.12: Cắt nhánh trong PIM-DM bước 3 G là một node lá và không có các máy nhận dữ liệu kết nối tới vì thế nó gửi thông điệp Prune lên mạng tới router F. Tuy nhiên thông điệp Prune được gửi tới địa chỉ all-PIM-router vì thế router H cũng nhận được thông điệp gửi tới F. Bởi vì H có các máy nhận yêu cầu nhận dữ liệu, H sẽ gửi một thông điệp PIM Join và nó sẽ hủy bỏ thông điệp Prune được gửi từ G. Để đảm bảo quá trình Prune hoạt động hiệu quả các router PIM-DM khi nhận một thông điệp Prune sẽ không xử lý ngay mà đợi 3 giây để các router khác gửi thông điệp Join. Nếu sau khoảng thời gian này, router không nhận được thông điệp Join thì nó sẽ thực hiện quá trình cắt nhánh. 2.2.3 Cơ chế xác nhận Trở lại mạng trong hình 2.12, nguồn dữ liệu bây giờ chỉ gửi tới các máy nhận trên mạng. Tuy nhiên vẫn còn một vấn đề nữa, đó là việc trùng lặp dữ liệu được gửi bởi router C và D lên mạng để tới máy nhận 1. Để giải quyết vấn đề trên, PIM sử dụng một cơ chế xác nhận để bình chọn ra một router DR cho nguồn multicast. Cơ chế xác nhận hoạt động theo quy tắc sau: nếu một router nhận dữ liệu multicast trên cổng mà cổng đó cũng gửi dữ liệu từ nguồn, thì router sẽ gửi một thông điệp PIM Assert tới cổng mà nó nhận dữ liệu để tìm ra router được lựa chọn. Trong thông điệp PIM Assert chứa giá trị metric tới nguồn, lúc đó
38 các router trên mạng kiểm tra giá trị metric và router nào có giá trị metric tốt nhất sẽ được chọn làm router gửi dữ liệu. Các router khác sẽ ngừng gửi dữ liệu và loại bỏ cổng của nó ra khỏi cây multicast. Trong trường hợp có nhiều router có cùng metric, địa chỉ IP sẽ được kiểm tra và router nào có địa chỉ IP cao nhất sẽ được chọn. Mạng trong hình 2.13 router C và D cùng gửi thông điệp PIM Assert lên mạng, giả sử router C và D có cùng metric và router C có địa chỉ IP lớn hơn. Lúc này router C sẽ được chọn làm router gửi dữ liệu còn router D sẽ ngừng gửi dữ liệu và loại bỏ giao diện của nó ra khỏi cây multicast. Hình 2.13: Xác nhận trong PIM-DM 2.2.4 Ghép nhánh PIM-DM cũng hỗ trợ khả năng ghép trở lại cây multicast một nhánh cây đã bị cắt bỏ trước đó. Hình 2.14 thể hiện một mạng với một máy nhận thứ 3 tham gia vào nhóm multicast trên router I.
39 Hình 2.14: Ghép nhánh trong PIM-DM Khi router I nhận thông điệp gia nhập nhóm multicast IGMP từ máy nhận 3, router I gửi một thông điệp Graft tới router E để yêu cầu nhận dữ liệu. Router E nhận thông điệp Graft từ router I nó trả lời bằng cách gửi lại I một thông điệp Graft-Ack. Bởi vì trước đó router E đã gửi thông điệp để cắt bỏ khỏi cây multicast vì thế nó cũng gửi một thông điệp Graft tới router C. Tương tự router C sẽ gửi lại E một thông điệp Graft-Ack, và lúc này dữ liệu multicast được gửi từ router C qua router E và I để tới máy nhận 3. 2.3 PIM Sparse Mode 2.3.1 Mô hình tham gia PIM-SM tuân theo hoạt động của giao thức sparse mode, trong đó dữ liệu multicast chỉ được gửi tới các máy nhận trên mạng khi có yêu cầu. Trong PIM- SM yêu cầu được thực hiện thông qua cơ chế tham gia tường minh (Explicit Join), thông điệp PIM Join sẽ được gửi qua từng chặng để đến được gốc của cây multicast (gốc của cây multicast trong PIM-SM là router RP đối với cây chia sẻ hay là router kết nối trực tiếp với nguồn dữ liệu trong cây đường đi ngắn nhất). Khi thông điệp Join đi theo cây để lên tới gốc, các router trên đường đi tạo một trạng thái để gửi dữ liệu multicast vì thế dữ liệu multicast yêu cầu sẽ được gửi trở
40 lại cây. Tương tự, khi dữ liệu multicast không được yêu cầu nữa, router sẽ gửi thông điệp Prune lên gốc cây để cắt bỏ các luồng dữ liệu không cần thiết. Khi thông điệp Prune đi qua các chặng trên cây các router cũng cập nhật trạng thái của nó, bỏ đi trạng thái gửi dữ liệu tương ứng với nhóm multicast. Điểm quan trọng trong mô hình tham gia tường minh là trạng thái gửi dữ liệu trong các router được tạo ra như là kết quả của thông điệp Join. Đó là sự khác biệt quan trọng so với giao thức dense mode, là các giao thức mà trạng thái gửi dữ liệu của router được tạo bởi dữ liệu multicast đến router đó. 2.3.2 Cây chia sẻ Các hoạt động của PIM-SM xoay quanh một cây chia sẻ một chiều, trong đó gốc cây được gọi là điểm hẹn RP (Rendezvous Point). Cây chia sẻ còn có một tên khác là cây RP được viết tắt là RPT vì gốc của nó ở tại điểm RP. Router ở chặng cuối (router kết nối trực tiếp với máy nhận dữ liệu) muốn nhận dữ liệu từ một nhóm multicast nó sẽ tham gia vào cây chia sẻ. Khi router không muốn nhận dữ liệu từ nhóm multicast nữa, nó sẽ cắt bỏ khỏi cây chia sẻ. 2.3.2.1 Tham gia cây chia sẻ Trên hình 2.15 thể hiện bước đầu tiên trong quá trình tham gia vào cây chia sẻ, trong bước này máy nhận 1 tham gia vào nhóm multicast G bằng cách gửi thông điệp IGMP Report. Hình 2.15: Tham gia cây chia sẻ PIM bước 1
41 Bởi vì máy nhận 1 là máy đầu tiên tham gia vào nhóm multicast, router C tạo một trạng thái (*, G) trong bảng định tuyến multicast của nó cho nhóm G. Router C đặt giao diện của nó vào danh sách các cổng ra của thực thể (*, G) như trên hình 2.16 (được thể hiện bằng mũi tên). Bởi vì router C đã tạo một thực thể trạng thái mới (*, G) nó cũng gửi một PIM (*, G) Join tới router RP để tham gia vào cây chia sẻ (được thể hiện bằng mũi tên đứt nét trong hình 2.16). Để gửi gói tin tới RP router C sử dụng bảng định tuyến unicast để xác định giao diện cần chuyển gói tin. Hình 2.16: Tham gia cây chia sẻ PIM bước 2 Router RP nhận thông điệp (*, G) Join và bởi vì nó chưa có trạng thái cho nhóm multicast G. Router RP sẽ tạo một thực thể trạng thái (*, G) trong bảng định tuyến multicast của nó và thêm một đường đi tới router C vào danh sách các cổng ra. Lúc này, cây chia sẻ cho nhóm G được xây dựng từ router RP tới C và máy nhận 1 như trên hình 2.17, dữ liệu multicast cho nhóm G được gửi tới router RP và theo cây chia sẻ đi xuống máy nhận 1.
42 Hinh 2.17: Tham gia cây chia sẻ PIM bước 3 Tiếp tục ví dụ và giả sử rằng có một máy nhận 2 tham gia vào nhóm multicast như trên hình 2.18. Tương tự máy nhận cũng thông báo nó muốn nhận dữ liệu multicast trên nhóm G bằng cách gửi thông điệp IGMP tới router E. Hình 2.18: Tham gia cây chia sẻ PIM bước 4 Router E chưa có trạng thái cho nhóm G, nó sẽ tạo một thực thể trạng thái mới trong bảng định tuyến multicast của nó và thêm cổng vào danh sách cổng ra (được thể hiện bằng mũi tên trong hình 2.19). Router gửi một thông điệp (*, G) Join tới router C để gia nhập cây chia sẻ (thể hiện bằng mũi tên đứt nét trong hình 2.19).
43 Hình 2.19: Tham gia cây chia sẻ PIM bước 5 Khi router C nhận thông điệp (*, G) từ router E nó nhận thấy rằng đã tồn tại trạng thái (*,G) cho nhóm G. Vì thế router C đơn giản chỉ cần thêm đường đi tới router E vào danh sách cổng ra. Trong hình 2.20 thể hiện kết quả của cây chia sẻ, bao gồm router C và E với các đường đi tới các máy nhận dữ liệu. Hình 2.20: Tham gia cây chia sẻ PIM bước 6 2.3.2.2 Cắt nhánh trên cây chia sẻ Bởi vì PIM-SM sử dụng mô hình Explicit Join để xây dựng cây multicast vì thế nó cũng sử dụng thông điệp Prune để cắt bỏ các nhánh cây khi chúng không còn nhận dữ liệu nữa. Trên hình 2.21 máy nhận 2 rời nhóm multicast G bằng cách gửi thông điệp IGMP Leave.
44 Hình 2.21: Cắt nhánh trên cây chia sẻ bước 1 Router E chỉ có một máy nhận tham gia vào nhóm multicast vì thế cổng đó bị loại bỏ khỏi danh sách cổng ra của trạng thái (*, G), điều này được thể hiện bằng cách bỏ mũi tên từ router E trên hình 2.22. Khi giao diện bị loại bỏ, danh sách cổng ra cho thực thể (*, G) là rỗng, điều đó chỉ ra router E không cần nhận dữ liệu cho nhóm multicast G nữa. Lúc đó router E gửi một thông điệp (*, G) Prune tới router RP để yêu cầu cắt bỏ nó khỏi nhánh cây multicast. Hình 2.22: Cắt nhánh trên cây chia sẻ bước 2 Khi router C nhận thông điệp Prune, nó loại bỏ đường đi tới router E trong danh sách các cổng ra của thực thể (*, G). Tuy nhiên router C vẫn còn máy nhận 1 kết nối và nhận dữ liệu multicast từ nhóm G, vì thế router C vẫn tiếp tục duy trì cây chia sẻ do đó thông điệp Prune sẽ không được gửi tiếp tới router RP.
45 Hình 2.23: Cắt nhánh trên cây chia sẻ bước 3 2.3.3 Cây đường đi ngắn nhất Không giống như giao thức sparse mode khác, giao thức PIM-SM không giới hạn người dùng phải nhận dữ liệu multicast thông qua cây chia sẻ. Các máy nhận cũng có thể nhận dữ liệu multicast thông qua cây đường đi ngắn nhất SPT. Bằng cách tham gia cây SPT, dữ liệu multicast sẽ được đưa trực tiếp tới máy nhận mà không thông qua router RP, điều đó giúp giảm tải trên router RP. Nhược điểm của cây SPT là router phải tạo và duy trì các thực thể trạng thái (S, G) trong bảng định tuyến multicast của chúng. Tuy nhiên, việc duy trì thông tin trạng thái trên các router PIM-SM sử dụng cây đường đi ngắn nhất vẫn ít hơn so các router sử dụng giao thức dense mode. Lý do là cơ chế quảng bá và loại bỏ được sử dụng bởi các giao thức dense mode yêu cầu các router duy trì trạng thái (S, G) trong bảng định tuyến cho tất cả các nguồn hoạt động, cho dù không có các máy nhận yêu cầu nhận dữ liệu. Điều đó lý giải tại sao giao thức PIM-SM được khuyến khích sử dụng hơn so với các giao thức dense mode. 2.3.3.1 Tham gia cây đường đi ngắn nhất Bằng cách gửi một thông điệp (S, G) Join tới nguồn, router có thể tham gia vào cây đường đi ngăn nhất cho nguồn S đó và có thể nhận dữ liệu multicast được gửi từ nguồn tới nhóm multicast G. Trên hình 2.24 thể hiện một ví dụ của thông điệp (S, G) Join được gửi tới nguồn để tham gia cây SPT. Trong đó máy nhận 1 đã tham gia vào nhóm G và yêu cầu nhận dữ liệu từ nhóm.
46 Hình 2.24: Tham gia cây đường đi ngắn nhất bước 1 Bởi vì router E muốn tham gia cây SPT cho nguồn S nó gửi một thông điệp (S, G) Join tới nguồn. Khi router C nhận thông điệp tham gia nó tạo một thực thể (S, G) vào bảng định tuyến của nó và thêm giao diện đã nhận gói tin vào danh sách cổng ra (được thể hiện bằng mũi tên trên hình 2.25). Bởi vì router tạo một trạng thái mới (S, G) vì vậy nó cũng gửi một thông điệp (S, G) Join tới nguồn (được thể hiện bằng mũi tên đứt nét trên hình 2.25). Hình 2.25: Tham gia cây đường đi ngắn nhất bước 2
47 Cuối cùng khi router A nhận được thông điệp (S, G) Join nó thêm đường đi vào danh sách cổng ra của thực thể (S, G) và hình thành cây đường đi ngắn nhất SPT từ nguồn S tới máy nhận như hình 2.26. Hình 2.26: Tham gia cây đường đi ngắn nhất bước 3 2.3.3.2 Cắt nhánh trên cây đường đi ngắn nhất PIM-SM cũng có thể cắt bỏ các nhánh trên cây SPT thông qua thông điệp (S, G) Prune tương tự như quá trình cắt nhánh trên cây chia sẻ. Xét mạng như trên hình 2.27, giả sử lúc này router E không còn các máy nhận dữ liệu nữa, vì thế không cần thiết gửi dữ liệu đến nó. Vì vậy router E gửi một thông điệp (S, G) Prune tới nguồn để yêu cầu cắt bỏ nó khỏi cây SPT. Hình 2.27: Cắt nhánh trên cây đường đi ngắn nhất bước 1
48 Router C nhận được thông điệp (S, G) Prune nó loại bỏ cổng nhận thông điệp ra khỏi danh sách cổng ra của thực thể (S, G). Lúc này danh sách cổng ra cho thực thể (S, G) là rỗng vì thế router C gửi một thông điệp (S, G) Prune tới nguồn yêu cầu cắt bỏ nó ra khỏi cây multicast. Hình 2.28: Cắt nhánh trên cây đường đi ngắn nhất bước 2 Khi router A nhận được thông điệp (S, G) Prune từ C nó loại bỏ cổng đã nhận thông điệp ra khỏi danh sách cổng ra. Tuy nhiên, vì router A là router kết nối trực tiếp với nguồn S nên router A không gửi thông điệp Prune nữa, mà nó chỉ đơn giản loại bỏ các gói tin được gửi đến từ S vì danh sách cổng ra của (S, G) bây giờ là rỗng. Hình 2.29: Cắt nhánh trên cây đường đi ngắn nhất bước 3 2.3.4 Thông điệp Join/Prune Các phần trước đây chúng ta đã nhắc đến thông điệp PIM Join và PIM Prune như hai thông thông điệp khác nhau với mục đích làm sáng tỏ quá trình
49 tham gia hay cắt bỏ nhánh. Tuy nhiên thức tế PIM chỉ sử dụng một thông điệp đơn Join/Prune cho cả hai chức năng. Mỗi thông điệp Join/Prune chứa cả hai danh sách Join và Prune và một trong hai danh sách đó có thể rỗng. Các thực thể Join và Prune trong thông điệp Join/Prune có cùng một định dạng chung, bao gồm các thông tin như sau: − Địa chỉ nguồn multicast: địa chỉ IP của nguồn multicast để thực hiện quá trình Join hay Prune, nếu cờ Wildcard được bật thì trường này chứa địa chỉ của router RP. − Địa chỉ nhóm multicast: địa chỉ nhóm multicast để thực hiện quá trình Join hay Prune. − Cờ Wildcard (WC bit): chỉ ra rằng thực thể là một thông điệp (*, G) Join/Prune. − Cờ RP Tree (RP bit): thông điệp Join/Prune là thích hợp và cần được gửi lên cây chia sẻ. 2.3.5 Đăng ký nguồn dữ liệu Trong cây chia sẻ PIM-SM chúng ta đã biết cách router gửi thông điệp (*, G) tới cây chia sẻ cho nhóm multicast G. Tuy nhiên PIM-SM sử dụng cây chia sẻ một chiều nên dữ liệu multicast chỉ có thể đi theo chiều từ gốc cây xuống các nhánh. Vì thế nguồn dữ liệu cần phải có một cách khác để gửi dữ liệu của nó tới router RP. Tuy nhiên trước tiên router RP cần phải được thông báo về nguồn đang tồn tại. Để làm điều này PIM-SM sử dụng thông điệp PIM Register và Register-Stop để thực hiện quá trình đăng ký nguồn dữ liệu. Quá trình này sẽ thông báo với router RP một nguồn đang hoạt động trên mạng và phân phối các gói tin multicast đầu tiên tới RP để tiếp tục được gửi xuống các nhánh cây. 2.3.5.1 Thông điệp PIM Register Thông điệp PIM Register được gửi từ router DR kết nối với nguồn dữ liệu tới router RP, với hai mục đích là: − Báo cho router RP biết rằng S là nguồn hoạt động và đang gửi dữ liệu tới nhóm G.
50 − Gửi các gói tin multicast đầu tiên từ S (các gói tin được đóng gói trong một thông điệp PIM Register) tới RP để gửi xuống cây chia sẻ tới máy nhận. Vì thế khi một nguồn multicast bắt đầu gửi dữ liệu, router DR nhận gói tin multicast từ nguồn và tạo một thực thể trạng thái (S, G) trong bảng định tuyến multicast. Tiếp đó router DR đóng gói mỗi gói tin multicast trong các thông điệp PIM Register riêng rẽ và gửi tới router RP. Khi router RP nhận một thông điệp PIM Register, đầu tiên nó sẽ mở gói thông điệp và nhận được gói tin multicast trong đó. Nếu gói tin là của một nhóm multicast có các máy nhận RP gửi gói tin xuống các nhánh cây phù hợp. Sau đó router RP tham gia vào cây đường đi ngắn nhất của nguồn S và có thể nhận dữ liệu trực tiếp từ nguồn mà không cần nhận thông qua thông điệp PIM Register nữa. Nếu như gói tin multicast trong thông điệp PIM Register không có máy nào yêu cầu nhận (lúc đó danh sách cổng ra cho trạng thái (S, G) là rỗng) thì router RP sẽ loại bỏ thông điệp multicast và không gửi thông điệp Join trở lại nguồn. 2.3.5.2 Thông điệp PIM Register – Stop Router RP sử dụng thông điệp PIM Register-Stop để thông báo với router DR ngừng việc gửi các thông điệp PIM Register khi thỏa mãn một trong hai điều kiện sau: − Khi router RP bắt đầu nhận dữ liệu multicast từ nguồn thông qua cây (S, G) SPT giữa nguồn và RP. − Khi router RP không cần nhận dữ liệu nữa vì trên nó không còn tồn tại các máy yêu cầu nhận dữ liệu multicast. Khi router DR nhận thông điệp Register-Stop nó biết router RP không cần nhận dữ liệu nữa vì thế nó ngừng việc đóng gói và gửi các thông điệp Register. 2.3.6 Chuyển từ cây chia sẻ sang cây đường đi ngắn nhất PIM-SM hỗ trợ khả năng cho phép router DR ở chặng cuối (là router kết nối trực tiếp với các máy nhận dữ liệu) có thể chuyển từ cây chia sẻ sang cây SPT cho một nguồn multicast. Điều này được thực hiện tự động thông qua việc đặt ra một ngưỡng SPT-Threshold của băng thông mạng, khi giá trị băng thông đạt ngưỡng router DR sẽ tham gia vào cây SPT.
51 Xét mạng có hai nguồn và hai máy nhận như trên hình 2.30, bởi vì router C là router DR chặng cuối nó có một lựa chọn để chuyển sang cây SPT cho nguồn S1 và S2. Để làm đó router C gửi thông điệp (S1, G) Join tới nguồn G như được thể hiện bằng mũi tên đứt nét trên hình 2.30. Hình 2.30: Chuyển sang cây SPT bước 1 Khi router A nhận thông điệp Join, nó thêm cổng nhận thông điệp vào danh sách cổng ra cho thực thể (S1, G) vào bảng multicast của nó. Lúc này đường đi từ router A đến router C được thiết lập và dữ liệu có thể truyền trực tiếp tới router C theo cây (S1, G) SPT. Hình 2.31: Chuyển sang cây SPT bước 2
52 Chúng ta có thể thấy tại thời điểm này có hai đường đi đối với luồng dữ liệu multicast (S1, G) đến router C, đó là thông qua cây chia sẻ và cây SPT điều này gây trùng lặp dữ liệu cũng như lãng phí băng thông mạng. Vì thế cần có cơ chế thông báo với router RP để cắt bỏ dữ liệu multicast (S1, G) khỏi cây chia sẻ. Để thực hiện điều này một kiểu đặc biệt của thông điệp Prune được sử dụng. Thông điệp này có tên là (S, G) RP-bit Prune bởi vì nó có cờ RP được gán trong danh sách các thực thể Prune. Như phần trước ta đã biết cờ RP chỉ ra rằng thông điệp là phù hợp với cây chia sẻ và cần được gửi lên trên để tới router RP. Sử dụng cờ này trong thông điệp (S1, G) Prune và gửi nó lên cây chia sẻ để thông báo tới các router trên cây loại bỏ nguồn dữ liệu multicast S1 ra khỏi cây. Trên hình 2.32 router C gửi một thông điệp (S1, G) RP-bit Prune tới router RP để loại bỏ nguồn dữ liệu S1 khỏi cây multicast. Sau khi nhận được thông điệp router RP trạng thái gửi dữ liệu multicast của nó vì thế dữ liệu (S1, G) sẽ không được gửi xuống nhánh cây đến router C. Tuy nhiên sau khi loại bỏ đường đi tới router C danh sách cổng ra cho trạng thái (S1, G) trên router RP là rỗng vì thế nó không cần nhận dữ liệu multicast từ nguồn nữa. Hình 2.32: Cắt bỏ nguồn khỏi cây chia sẻ bước 3 Để ngừng luồng dữ liệu không cần thiết từ nguồn gửi tới, router RP gửi thông điệp (S1,G) Prune trở lại nguồn. Thông điệp Prune (được thể hiện bằng
53 mũi tên đứt nét trên hình 2.33) được gửi theo từng chặng và qua router B trước khi đến router A. Hình 2.33: Cắt bỏ nguồn khỏi cây chia sẻ bước 4 Bây giờ cây (S1, G) SPT đã được cắt bỏ nhánh chỉ còn đường đi giữa router A và router C. Router E vẫn tiếp tục nhận dữ liệu từ router C và nó không biết router C đã chuyển qua cây đường đi ngắn nhất. Dữ liệu từ nguồn S2 vẫn tiếp tục được gửi qua cây chia sẻ để tới các máy nhận 1 và 2 như đường mũi tên trên hình 2.34. Hình 2.34: Cắt bỏ nguồn khỏi cây chia sẻ bước 5
54 2.4 Giao thức Multicast Open Shortest Path First Giao thức Multicast Open Shortest Path First (MOSPF) được định nghĩa trong RFC 1584 là một mở rộng của giao thức định tuyến unicast trạng thái liên kết Open Shortest Path First (OSPF). MOSPF cung cấp sự mở rộng về định dạng dữ liệu và các đặc tả hoạt động từ OSPF. Sự mở rộng này cho phép dữ liệu multicast được truyền trên mạng OSPF bằng cách sử dụng cây đường đi ngắn nhất như là một phần của các router MOSPF. Trong phần này chúng ta sẽ tìm hiểu các khái niệm và cơ chế của hoạt động MOSPF bao gồm các phần sau: định tuyến multicast trong vùng, định tuyến multicast nhiều vùng và định tuyến multicast trên nhiều vùng tự trị (autonomous system - AS). 2.4.1 Định tuyến multicast trong vùng MOSPF là mở rộng của giao thức định tuyến unicast OSPF và do vậy đòi hỏi OSPF như giao thức định tuyến cơ sở. Khái niệm cơ bản của định tuyến MOSPF trong vùng dựa vào giả thiết trạng thái trong mô tả OSPF đó là “nếu các router trong một vùng biết các phân đoạn mạng có các thành viên của nhóm multicast, các router đó có thể sử dụng thuật toán Dijkstra để xây dựng cây đường đi ngắn nhất cho bất kỳ các cặp nhóm, mạng nguồn trong vùng”. Một mở rộng quan trọng của MOSPF trong định dạng dữ liệu để hỗ trợ multicast là sử dụng một thông điệp quảng bá trạng thái liên kết của nhóm (group Link-State Advertisement – LSA nhóm). Thông điệp LSA nhóm này được phát tán định kỳ trong cả vùng giống như LSA của giao thức OSPF. Mỗi LSA nhóm có các thông tin cơ bản sau: địa chỉ nhóm multicast, định danh router quảng bá, danh sách các giao diện mạng của router (xác địn bởi địa chỉ IP) có các thành viên của nhóm. Sau khi cơ sở dữ liệu của các router trong vùng được đồng bộ, sự kết hợp của LSA nhóm với router và mạng LSA cung cấp cho mỗi router MOSPF thông tin cần thiết để xây dựng cây đường đi ngắn nhất cho các cặp nhóm và mạng trong vùng. Để xây dựng cây này mỗi router MOSPF sử dụng thuật toán Dijkstra để xây dựng một cây đường đi ngắn nhất multicast đơn có gốc tại mạng nguồn. Hình 2.35 là một ví dụ của một vùng OSPF có ba nguồn multicast và các thành
55 viên hoạt động của nhóm G ở trên các vị trí khác nhau của mạng. Sau khi cơ sở dữ liệu được đồng bộ mỗi router có khả năng xây dựng một cây SPT cho nguồn 1, 2 và 3. Lưu ý rằng cây SPT này là riêng biệt cho các cặp nguồn và mạng con, và không phân biệt các nguồn trên một mạng. Vì thế mặc dù có 3 nguồn trên mạng N3 cho nhóm G chỉ có một cây SPT cho nguồn mạng được xây dựng. Hình 2.35: Vùng MOSPF chứa nguồn và thành viên nhóm G Hình 2.36A chỉ ra kết quả của cây đường đi ngắn nhất MOSPF (N4, G) SPT với gốc là mạng nguồn N4 và chứa nguồn 1 và 3. Hình 2.36.B chỉ ra kết quả cây (N3, G) SPT với gốc tại mạng nguồn N3 có chứa nguồn 2.
56 Hình 2.36: Cây đường đi ngắn nhất MOSPF SPT cho mạng N3 và N4 2.4.2 Định tuyến multicast trên nhiều vùng Ở phần trên chúng ta tìm hiểu cách MOSPF định tuyến trong một vùng OSPF. Phần này minh họa cơ chế mà MOSPF thực hiện để chuyển tiếp gói tin giữa các vùng OSPF. Điều này xảy ra khi một nguồn multicast ở trong một vùng trong khi người nhận ở trong vùng khác. Cách thức MOSPF sử dụng để quản lý định tuyến multicast trên nhiều vùng có nhiều điểm giống với cách OSPF thực hiện. Trong OSPF các router liên kết một vùng thuộc lớp thứ hai tới vùng đường trục được gọi là ABR (area border router- router trên biên của vùng) và được chịu trách nhiệm để chuyển tiếp thông tin định tuyến (trong dạng của một thông điệp tóm tắt LSA - summary LSA) và dữ liệu unicast giữa hai vùng. Các router ABR không truyền tuyến đường hay các thông điệp LSA giữa các vùng, mà chỉ truyền các thông điệp LSA tóm tắt giữa các vùng. Để hỗ trợ multicast trên nhiều vùng, RFC 1584 định nghĩa chuyển tiếp multicast liên vùng là một tập con của các OSPF ABR trong mạng và được cấu hình để thực hiện các tác vụ multicast liên quan như: tóm tắt thông tin thành viên nhóm trong vùng 0 và chuyển tiếp gói tin multicast giữa các vùng. Các router thực hiện chức năng này được gọi là router multicast trên biên của vùng (multicast area border routers – MABR).
57 Để dữ liệu multicast theo cấu trúc phân cấp của OSPF (từ vùng đường trục tới các vùng lớp thứ hai) router trên vùng đường trục cần biết các router multicast trên biên của vùng (MABR) nào đang được kết nối có thành viên hoạt động của nhóm multicast. Các router MABR tóm tắt thông tin của thành viên nhóm multicast trong vùng và phát tán tới vùng đường trục thông qua LSA nhóm. Tuy nhiên, không như OSPF LSA tóm tắt được phát tán đối xứng xuyên qua biên của vùng, các LSA nhóm tóm tắt phát tán không đối xứng và chỉ theo chiều từ vùng không đường trục sang vùng đường trục. Hình 2.37: Thông điệp nhóm tóm tắt trong vùng đường trục Trong ví dụ trên hình 2.37, vùng 1 chứa một thành viên của nhóm A ( ) và hai thành viên nhóm B ( ). Thông tin thành viên trong nhóm được tóm tắt trong thông điệp MABR1 và được phát tán đến vùng đường trục (vùng 0) thông qua LSA nhóm. Tương tự vùng 2 chứa hai thành viên nhóm A và thông tin được tóm tắt và phát tán tới vùng đường trục thông qua MABR2. Hình 2.38 chỉ ra 2 nguồn hoạt động S1 và S2 gửi dữ liệu tới các nhóm multicast tương ứng B và A. Thông tin thành viên nhóm được phát tán tới vùng đường trục bởi các router MABR1 và MABR2 cho biết đường đi từ nguồn tới các nhóm. Theo đó cây (S1, B) và cây (S2, B) được xây dựng trong vùng đường
58 trục cho phép lưu lượng nhóm A và B được truyền tới vùng 1 và 2 một cách thích hợp. Hình 2.38: Cây đường đi ngắn nhất SPT trong vùng đường trục Trong ví dụ trên nguồn nằm trên vùng đường trục và dữ liệu được lấy xuống tới các vùng không phải đường trục. Tuy nhiên trong thực tế thường xuyên gặp phải trường hợp các nguồn không nằm trên vùng đường trục, trong trường hợp này MOSPF xử lý bằng cách định nghĩa một cờ để báo hiệu người nhận multicast. Cờ báo hiệu đó chỉ ra router mong muốn nhận tất cả các dữ liệu multicast. Tất cả các router multicast trên biên vùng (MABR) để nhận dữ liệu multicast từ các nguồn trong vùng không phải đường trục và từ đó có thể chuyển tiếp tới các router trên vùng đường trục nếu cần. Trên hình 2.39 thể hiện mạng với nguồn (S1, B) và (S2, A) bây giờ ở trong mạng không phải đường trục. Nguồn (S2, A) ở trên vùng 2 và cây đường đi ngắn nhất cho trường hợp định tuyến cho nhiều vùng vẫn được xây dựng bình thường, tuy nhiên lúc này MABR2 đánh dấu nhận dữ liệu muticast vì thế nó được thêm vào cây SPT (S2, A). Tương tự trên vùng 1 MABR1 cũng được thêm vào cây đường đi ngắn nhất (S1, B). Lúc này dựa vào cây đường đi ngắn nhất trên vùng đường trục các router MABR1 và MABR2 có thể tới các vùng.
59 Hình 2.39: Nguồn trong vùng không phải đường trục Trên hình 2.39 ta thấy nguồn B không có các thành viên của nhóm multicast hoạt động phía ngoài vùng 1 tuy nhiên lưu lượng vẫn được gửi tới MABR1 do kết quả của việc sử dụng cờ báo nhận trên MABR1, điều này làm tăng băng thông trên mạng cũng như các xử lý trên router. 2.4.3 Định tuyến multicast trên các vùng tự trị Trong phần này chúng ta sẽ tìm hiểu về cơ chế mà MOSPF thực hiện khả năng định tuyến trên các vùng tự trị (autonomous system - AS). Trong định tuyến unicast OSPF sử dụng các router tại biên của các vùng tự trị (autonomous system border routers - ASBR) để chuyển tiếp dữ liệu tới các miền OSPF. Tương tự MOSPF cũng sử dụng các router multicast trên vùng biên (Multicast AS Border Routers - MASBR) để chuyển tiếp dữ liệu muticast tới các router trên vùng đường. Khi lưu lượng vào từ một miền khác thông qua MASBR lưu lượng này được chuyển qua đường trục tới MABR dựa vào LAS nhóm rút gọn. Tiếp theo dữ liệu từ các router MABR tiếp tục được phát tán tới các thành viên nhóm multicast dựa vào cây đường đi ngắn nhất được minh họa như trên hình 2.40.
60 Hình 2.40: Lưu lượng multicast xuống các miền MOSPF
61 CHƯƠNG 3 SỬ DỤNG ACCESS GRID XÂY DỰNG HỆ THỐNG HỘI NGHỊ TRUYỀN HÌNH DỰA TRÊN IP MULTICAST 3.1 Các khái niệm chung về dịch vụ hội nghị truyền hình Hội nghị truyền hình công cộng lần đầu tiên được tổ chức vào tháng 04/1903 giữa trụ sở AT&T và Bell Laboratory. Vào thời điểm đó âm thanh và hình ảnh được truyền đi với chất lượng “chấp nhận được”. Và từ đó vấn đề trao đổi trực tiếp qua khoảng cách xa được quan tâm nhiều. Đến năm 1934 cuộc chiến về chuẩn giữa các công ty bắt đầu và kết thúc là chuẩn tivi tương tự với băng thông 4,2MHz (525 dòng, 30 ảnh/giây). Tới năm 1964 AT&T giới thiệu sản phẩm hội nghị truyền hình đầu tiên là Picturephone. Hệ thống này chỉ yêu cầu công suất xử lý là 1MHz và cung cấp tính năng sử dụng chung dữ liệu đầu tiên. Tới năm 1971 đã có hội nghị truyền hình vượt đại dương với hệ thống LME của Ericsson. Và tới những năm 1990 với sự ra đời và phát triển mạnh của mạng Internet, hội nghị truyền hình trên máy tính được giới thiệu. Hội nghị truyền hình ở dạng cơ bản nhất là việc truyền hình ảnh và lời nói một cách đồng bộ giữa hai hay nhiều địa điểm xa nhau giống như các nhóm trao đổi thông tin tại cùng một địa điểm. Việc này được thực hiện bằng cách sử dụng máy quay (để lưu trữ và truyền hình ảnh tới các địa điểm khác), microphone (để bắt và chuyển lời nói tới các địa điểm khác) và loa (để có thể nghe được từ các địa điểm khác). Mặc dù có thể có nhiều yếu tố phức tạp hóa hệ thống, tuy nhiên về cơ bản một hệ thống hội nghị truyền hình vẫn cần thiết các yếu tố nêu trên. Các ứng dụng của trường hợp đầu bao gồm đào tạo từ xa, các cuộc họp, hội thảo, tư vấn và thông tin từ xa. Các ứng dụng cho trường hợp sau bao gồm việc truy cập tới các vùng sâu, vùng xa như y tế từ xa, đào tạo từ xa, truy cập vào các thiết bị nguyên tử, trạm vũ trụ Hội nghị truyền hình cũng được dùng để quan
62 sát động vật hoang dã trong trạng thái tự nhiên, thiết lập hệ thống giám sát, an toàn 3.1.1 Hệ thống hội nghị truyền hình Một hệ thống hội nghị truyền hình sẽ gồm hai hay nhiều điểm sử dụng các thiết bị đầu cuối để trao đổi hình ảnh, âm thanh và dữ liệu cho nhau. Các thiết bị đầu cuối này có thể kết nối trực tiếp với nhau, kết nối thông qua Gateway hay kết nối thông qua Multipoint Control Unit (MCU). Các thiết bị đầu cuối cũng có thể chịu sự quản lý của một Gatekeeper. Mỗi Gatekeeper (GK) sẽ quản lý một nhóm các thiết bị đầu cuối, các Gateway (GW) và các MCU định ra một vùng (zone) của hệ thống hội nghị truyền hình. Hội nghị truyền hình điểm – điểm: hội nghị truyền hình bao gồm 2 dạng: điểm – điểm và đa điểm. Trong hội nghị truyền hình điểm – điểm, hai thiết bị hội nghị truyền hình kết nối trực tiếp với nhau. Việc kết nối này có thể thông qua việc quản lý của Gatekeeper hoặc kết nối trực tiếp thông qua IP giữa hai thiết bị đầu cuối. Các ứng dụng phần mềm hội nghị truyền hình trên máy tính thường hỗ trợ cả 2 loại hình này. Hội nghị truyền hình đa điểm: đối với hội nghị truyền hình đa điểm có hai cấu hình chính là tập trung và không tập trung. Trong cấu hình đa điểm tập trung, tất cả các thiết bị đầu cuối tham gia hội nghị sẽ trao đổi thông tin theo dạng điểm – điểm với thiết bị quản lý MCU. Các thiết bị đầu cuối sẽ chuyển các dòng thông tin về âm thanh, hình ảnh và dữ liệu tới MCU. Bộ phận MC trong MCU sẽ quản lý hội nghị một cách tập trung. Phần MP trong MCU sẽ xử lý các dữ liệu âm thanh, hình ảnh và dữ liệu và gửi lại từng thiết bị đầu cuối. Đối với hội nghị truyền hình đa điểm không tập trung, các thiết bị đầu cuối sẽ multicast các dòng thông tin về âm thanh, hình ảnh và dữ liệu tới tất cả các thiết bị đầu cuối khác tham gia hội nghị mà không sử dụng MCU. Các thiết bị đầu cuối khi đó phải có nhiệm vụ: − Tổng hợp các dòng thông tin về âm thanh nhận được. − Lựa chọn một hoặc nhiều dòng thông tin về hình ảnh để hiển thị.
63 Trong cấu hình không tập trung, các MP cho âm thanh và hình ảnh là không cần thiết. Các thiết bị đầu cuối vẫn trao đổi với nhau trên kênh điều khiển (kênh điều khiển H.245 đối với hệ thống H.323) đối với MC để quản lý cuộc hội thảo. Các dòng thông tin về dữ liệu vẫn xử lý tập trung bởi MP của MCU. Hệ thống hội nghị truyền hình đa điểm cũng có thể có cầu hình trộn lẫn giữa tập trung và không tập trung. 3.1.2 Các thành phần cơ bản của hội nghị truyền hình Có 5 thành phần cơ bản cấu hình nên hội nghị truyền hình: Conferencing Connecting Hearbeat Network – services Network – transport Hình 3.1: Thành phần của hội nghị truyền hình − Network transport: hay là tầng giao vận mạng, là lớp mạng được sử dụng để trao đổi thông tin giữa các điểm của hội nghị truyền hình. Network transport có thể là IP, ISDN, ATM, Frame Relay, DSL − Network services: hay các dịch vụ mạng, là các tính năng được cung cấp bởi lớp giao vận mạng. Các tính năng này bao gồm chất lượng dịch vụ, dịch vụ multipoint hoặc multicast. − Connecting: cung cấp cơ chế để 2 hay nhiều điểm có thể gọi cho nhau. Việc này đòi hỏi nhiều tính năng như directory services, dịch vụ authentication, và authorization cho phép kiểm tra người có thể sử dụng dịch vụ hội nghị truyền hình, dịch vụ accounting cho phép tính tiến đối với sử dụng dịch vụ. − Heartbeat: chỉ được thực hiện trong một hội nghị truyền hình. Nó cung cấp thông tin phía sau để hội nghị truyền hình có thể chạy tốt. Các thông tin này bao gồm performance feedback, để nơi nhận thông báo nơi gửi chậm xuống
64 vì nó không xử lý kịp thông tin, hoặc nó không nhận được thông tin, connectivity feedback, được dùng để thông báo về tình trạng kết nối giữa các điểm hội nghị truyền hình. − Conferencing: là điểm chính trong hội nghị truyền hình. Nó chính là các tín hiệu âm thanh và hình ảnh, thường được nén lại và mã hóa. Các tín hiệu âm thanh và hình ảnh này là nội dung của hội nghị truyền hình và cần được chia sẻ cho tất cả các điểm tham gia hội nghị. Ngoài âm thanh và hình ảnh, hội nghị truyền hình còn có thể hỗ trợ việc chia sẽ dữ liệu hoặc chương trình như chia sẻ file giữa các điểm 3.2 Giao thức RTP Giao thức truyền tải thời gian thực (RTP – Realtime Transport Protocol) được IETF phát triển như là một giao thức ở lớp ứng dụng để truyền tải các dịch vụ đa phương tiện. RTP cung cấp dịch vụ truyền dữ liệu thời gian thực từ đầu cuối đến đầu cuối, như các dịch vụ audio và video tương tác. Bản thân RTP không cung cấp bất kỳ một cơ chế nào để đảm bảo truyền dữ liệu theo thời gian thực hay đảm bảo QoS cho dịch vụ, mà nó dựa trên các lớp dưới để thực hiện điều đó. RTP cho phép phía nhận tái tạo lại trật tự gói tin như ở phía gửi bằng cách sử dụng trường Sequence Number trong RTP header. 3.2.1 Khuôn dạng RTP header Khuôn dạng RTP header như sau: Hình 3.2: Khuôn dạng RTP header 12 byte đầu tiên được đưa ra trong mọi gói tin RTP. Danh sách các chỉ số CSRC chỉ được chèn vào tại bộ trộn. Ý nghĩa các trường như sau:
65 − V (Version): độ dài 2 bit. Trường này xác định độ dài của RTP. − P (Padding): độ dài 1 bit. Nếu bit này là 1 thì gói tin sẽ có một hoặc nhiều hơn một octet bù được chèn vào cuối mỗi gói tin (vì một số thuật toán mã hóa sử dụng các kích thước block cố định). − X (Extension): độ dài 1 bit. Nếu bit này là 1 thì sẽ có phần mào đầu mở rộng sau phần mào đầu cố định. − CC (CSRC Count): độ dài 4 bit. CC xác định số lượng các CSRC indentifier sau phần mào đầu cố định. − M (Marker): độ dài 1 bit. Trường này được sử dụng để cho phép đánh dấu các sự kiện quan trọng như các giới hạn khung trong luồng gói tin. − PT (Payload Type): độ dài 7 bit. Trường này định nghĩa cấu trúc của tải tin RTP để ứng dụng có thể biên dịch được tải tin. − Sequence Number: độ dài 16 bit. Khi một gói tin RTP được đi thì trường này được tăng lên 1 đơn vị. Phía nhận sử dụng trường này để phát hiện các gói tin bị mất và khôi phục lại trật tự gói tin. − Timestamp: độ dài 32 bit. Trường này chứa thông tin về thời điểm lấy mẫu của octet đầu tiên trong gói dữ liệu RTP. Trường này được sử dụng cho mục đích đồng bộ và tính toán độ biến thiên trễ (jitter). − SSRC: độ dài 32 bit. Trường SSRC được sử dụng để xác định nguồn đồng bộ. − CSRC: có từ 0 đến 15 mục, mỗi mục có chiều dài 32 bit. 3.2.2 Các ứng dụng sử dụng RTP 3.2.2.1 Thoại hội nghị đơn giản Nhóm nghiên cứu của IETF đang nghiên cứu giao thức sử dụng các dịch vụ thoại dùng IP multicast trên nên mạng Internet công cộng. Dịch vụ này dùng một địa chỉ nhóm multicast và một cặp cổng. Trong đó một cổng được sử dụng cho dữ liệu thoại, và cổng kia được sử dụng cho các bản tin điều khiển (RTCP). Thông tin địa chỉ và cổng được gửi cho các thành viên nhóm multicast. Nếu dịch vụ bảo mật được sử dụng thì các gói tin dữ liệu và gói tin điều khiển đều được
66 mã hóa. Trong trường hợp đó phải tạo ra khóa mã và khóa mã được gửi cho các thành viên của nhóm multicast. Phần mềm thoại hội nghị ở tại đầu cuối của mỗi thành viên của nhóm multicast gửi dữ liệu thoại theo từng đoạn ngắn (với khoảng thời gian thoại là 20 ms). Mỗi đoạn dữ liệu thoại sẽ được gắn thêm một RTP header, sau đó cả RTP header và dữ liệu thoại lại tiếp tục được đóng gói trong gói tin UDP. RTP header sẽ chỉ ra rằng kiểu mã hóa thoại (PCM, ADPCM hoặc LPC) nào được sử dụng trong mỗi gói tin, nhờ vậy phía gửi có thể thay đổi kiểu mã hóa trong suốt quá trình thoại hội nghị. Mạng Internet cũng giống như các mạng gói khác thường xẩy ra hiện tượng mất gói tin, trật tự gói tin đến bị thay đổi và thời gian trễ của mỗi gói tin khác nhau. Để khắc phục những vấn đề này, RTP header có chứa trường thông tin định thời và trường thứ tự của mỗi gói tin (Sequence Number). Những thông tin này cho phép phía nhận khôi phục lại thông tin định thời và do đó các đoạn thoại được phát ra liên tục với tần suất 20ms. Việc khôi phục thông tin định thời được thực hiện riêng biệt cho mỗi nguồn gói tin RTP trong nhóm thoại hội nghị. Phía nhận cũng có thể sử dụng trường Sequence Number để ước lượng xem có bao nhiêu gói tin bị mất. Vì các thành viên của nhóm thoại hội nghị có thể tham gia và rời khỏi nhóm ở bất kỳ thời điểm nào trong suốt quá trình thoại hội nghị. Một điều quan trong là các thành viên của nhóm cần phải biết được những thành viên nào đang tham gia vào thoại hội nghị tại bất kỳ thời điểm nào và các thành viên nhận dữ liệu thoại có đảm bảo chất lượng không. Để giải quyết vấn đề này, mỗi ứng dụng thoại trong nhóm thoại hội nghị định kỳ phải gửi cho các thành viên khác báo cáo nhận (reception) bao gồm cả tên người dùng của nó trên cổng RTCP. Báo cáo nhận cho biết thành viên này nhận dữ liệu thoại có tốt không và thông tin trong báo cáo này có thể được sử dụng để điều khiển lựa chọn kiểu mã hóa thoại thích hợp. Ngoài ra các thông tin như tên người dùng và các thông tin xác nhận khác có thể được sử dụng để điều khiển các giới hạn băng thông. Khi mỗi thành viên của nhóm thoại hội nghị rời khỏi nhóm thì nó phát đi bản tin RTCP để báo cho các thành viên khác trong nhóm biết.
67 3.2.2.2 Thoại và truyền hình hội nghị Khi cả phương tiện thoại và video được sử dụng trong nhóm hội nghị, thì dữ liệu thoại và dữ liệu video được phát đi theo các phiên RTP riêng biệt. Các gói tin RTCP được phát đi cho mỗi phương tiện sử dụng các cặp cổng UDP hoặc các địa chỉ multicast khác nhau. Khi một người dùng tham gia vào thoại và video thì người dùng đó phải sử dụng cùng một tên nhận dạng trong các gói tin RTCP cho cả hai phiên đó ngoài ra không có bất kỳ một sự kết hợp nào tại mức RTP giữa các phiên thoại và video. Một trong những động cơ của việc chia tách này là để cho phép một số thành viên trong nhóm hội nghị chỉ nhận dữ liệu thoại hoặc video tùy theo họ lựa chọn. Mặc dù có sự tách biệt giữa các phiên thoại và video nhưng sự đồng bộ giữa thoại và video có thể đạt được bằng cách sử dụng thông tin định thời chứa trong các gói tin RTCP cho cả hai phiên thoại và video. 3.2.2.3 Bộ trộn và bộ biên dịch Xem xét trong trường hợp một số thành viên của nhóm hội nghị ở một vùng nào đó kết nối tới nhóm thoại hội nghị thông qua các kênh tốc độ thấp trong khi phần lớn các thành viên khác lại kết nối qua các kênh tốc độ cao. Thay vì bắt tất cả các thành viên trong nhóm hội nghị sử dụng tốc độ thấp, người ta sử dụng một bộ chuyển tiếp ở mức RTP hay còn được gọi là bộ trộn đặt tại phía các thành viên có tốc độ thấp. Các bộ trộn đồng bộ lại các gói tin thoại đầu vào để tái tạo lại khoảng thời gian không đổi 20ms giữa các đoạn thoại được tạo ra ở phía gửi, ghép các luồng thoại này thành một luồng, chuyển kiểu mã hóa thoại sang kiểu mã hóa thoại tốc độ thấp và chuyển luồng gói này lênh kênh tốc độ thấp. Các gói tin này có thể được phát unicast tới một người nhận hoặc được phát multicast trên một địa chỉ khác tới nhiều người nhận. Một số thành viên của nhóm thoại hội nghị có thể kết nối thông qua kênh tốc độ cao nhưng gói tin vẫn không thể đi đến được thông qua IP multicast. Ví dụ các thành viên này nằm sau một firewall ở mức ứng dụng, firewall này không cho phép bất kỳ một gói tin IP nào đi qua. Trong trường hợp này người ta sử dụng một bộ chuyển tiếp ở mức RTP khác được gọi là bộ biên dịch (translator).
68 Trong trường hợp như ví dụ trên sử dụng hai bộ biên dịch được lắp đặt ở hai phía của firewall. Bộ biên dịch ở phía ngoài sẽ nhận tất cả các gói tin multicast và chuyển cho bộ biên dịch ở phía trong firewall. Bộ biên dịch này sau đó sẽ gửi các gói tin multicast cho nhóm multicast bị giới hạn trong vùng mạng nội bộ. 3.3 Đồng bộ luồng hình ảnh và âm thanh Việc truyền tải hình ảnh và âm thanh qua mạng bằng các ứng dụng riêng biệt sẽ dẫn đến việc người sử dụng cảm thấy khoảng thời gian trễ giữa phần tiếng và phần hình. Một số ứng dụng có yêu cầu chất lượng cao, đòi hỏi thời gian trễ giữa hình và tiếng phải đủ nhỏ để đạt được hiệu quả mong muốn. Việc đồng bộ hóa hình và tiếng có thể được thực hiện bằng cách làm chậm lại việc phát tín hiệu hình hoặc tiếng để hai tín hiệu này đồng bộ với nhau về mặt thời gian. Mạng MBone là mạng multicast bên trong mạng Internet. Các phần mềm audio cho MBone, ví dụ như Rat, Nevot và các công cụ video như Vic, Ivs không hỗ trợ đồng bộ đường hình và tiếng. Bộ phần mềm gồm công cụ audio Rat (robust audio tool) và công cụ video Vic (video conference) do UCL phát triển là bộ phần mềm đầu tiên hỗ trợ đồng bộ hình tiếng. Công cụ rat và vic đều sử dụng giao thức thời gian thực RTP của IETF để hỗ trợ các tính năng cần thiết cho giao tiếp video và audio sử dụng multicast. Cơ chế đồng bộ của rat sử dụng nhãn thời gian trong gói tin RTP để xác định thời gian làm trễ gói tin. Việc gửi tín hiệu âm thanh qua mạng chuyển mạch gói đòi hỏi khả năng bảo vệ mất gói tin và trễ end-to-end thấp. Yêu cầu trễ thấp đồng nghĩa với việc kích thước gói tin phải nhỏ và tần suất gửi gói tin cao. Kích thước gói tin âm thanh trong mạng Internet tương đương với khoảng 20 đến 80 ms. Trong khi đó thì công cụ video thường có tốc độ quét ảnh thấp, chỉ từ 2 đến 10 hình/giây, chứ không cao như trong truyền hình (tốc độ 24 hình/giây). Lý do tốc độ quyết thấp là để tiết kiêm băng thông mạng, nhất là khi có nhiều nguồn video cùng được phát một lúc. Ngoài ra, thời gian xử lý video tại thiết bị đầu cuối cũng khá lớn khiến cho thời gian trễ giữa thời điểm bắt và hiển thị hình thường khá lớn. Mỗi khung hình video thường được chia nhỏ trước khi gửi qua mạng.
69 Mạng MBone là mạng chuyển mạch gói chia sẻ có hỗ trợ multicast. Các thiết bị định tuyến vẫn hoạt động trên nguyên tắc đến trước phục vụ trước (FIFO) và vẫn trộn lẫn lưu lượng từ nhiều nguồn khác nhau thành một luồng lưu lượng. Điều này gây ra trễ jitter giữa các gói tin của một luồng gói tin thời gian thực. Khi luồng tin chứa thông tin âm thanh, trễ jitter phải được loại bỏ vì nếu không thì âm thanh phát ra tại thiết bị đầu cuối sẽ trở nên khó hiểu. Kỹ thuật thường được dùng để loại bỏ jitter là sử dụng một bộ đệm tái tạo âm thanh. Bộ đệm này cho phép lưu gói tin và làm trễ thời điểm phát tiếng, do vậy có thể giảm trễ jitter giữa các gói tin ở đầu ra. Cơ chế bộ đệm này phải có khả năng thích ứng do trễ jitter trên mạng MBone có thể thay đổi tùy từng thời điểm. Việc tính toán thời gian làm trễ gói tin phải dựa trên thời gian truyền gói tin qua mạng. Vì thời gian làm trễ gói tin và tỷ lệ gói tin đến kịp thời có liên quan đến nhau, người ta thường chọn thời gian làm trễ sao cho tỷ lệ gói tin đến nơi kịp thời là 99,9%. Trễ jitter cũng ảnh hưởng đến các ứng dụng video (hình ảnh sẽ bị giật). Tuy nhiên, đứng trên phương diện của người sử dụng, việc này không ảnh hưởng nhiều đến chất lượng của ứng dụng. Các công cụ video hiện thời như vic hay ivs đều hiển thị khung hình ngay khi nhận và giải mã gói tin. Sự khác biệt giữa trễ tiếng và hình thường thay đổi khá lớn do thời gian xử lý tín hiệu audio và video khác nhau. Vì vậy để có thể đồng bộ đường hình và tiếng cần phải làm trễ một trong hai đường hình tiếng tại đầu nhận. Các thử nghiệm với người sử dụng cho thấy, hai luồng tín hiệu hình tiếng không nhất thiết phải đồng bộ hoàn toàn và có thể lệch nhau 80 – 100 ms mà người sử dụng vẫn cảm thấy thoải mái. Việc làm trễ đường tiếng vẫn được thực hiện với một bộ đệm. Trong khi đó, các phần mềm video thường không dùng bộ đệm ở đầu ra, nhưng với yêu cầu đồng bộ hệ thống video cũng phải sử dụng bộ đệm. Trễ đường hình thường lớn hơn trễ đường tiếng. Trễ đường tiếng không được quá lớn để đảm bảo độ tương tác của hệ thống. Vì vậy phải có sự thống nhất giữa hệ thống hình và tiếng, tức là ta phải có phương thức báo hiệu giữa hai hệ thống hình và tiếng để hai đường có thể đồng bộ với nhau.