Nghiên cứu IP multicast và các ứng dụng

Multicast ra đời cũng nhằm phục vụ cho một trong những mục đích trên. Với ưu điểm tiết kiệm băng thông, giảm tải cho mạng, IP multicast là một sự thay thế tốt cho phương thức truyền unicast khi mà các công ty cần chuyển thông tin đến nhiều khách hàng trong cùng một thời điểm. Nội dung của đồ án bao gồm: Chương 1: IP multicast và các vấn đề liên quan Chương 2: Ứng dụng IP multicast với IPTV Chương 3: Xây dựng ứng dụng Group chat

DANH MỤC HÌNH VẼ 1

THUẬT NGỮ VIẾT TẮT 3

LỜI NÓI ĐẦU 5

CHƯƠNG I: IP MULTICAST VÀ CÁC VẤN ĐỀ LIÊN QUAN 6

1.1 Giới thiệu về IP Multicast 6

1.1.1 Truyền thông Unicast 6

1.1.2 Truyền thông Broadcast 6

1.1.3 Truyền thông Multicast 7

1.2 Triển khai Multicast 8

1.2.1 Nhóm Multicast 8

1.2.2 Đường hầm Multicast 8

1.2.3 Vấn đề địa chỉ trong IP Multicast 9

1.2.3.1 Địa chỉ IP Multicast 9

1.2.3.2 Ánh xạ địa chỉ IP multicast sang địa chỉ MAC 11

1.2.4 Chuyển tiếp lưu lượng Multicast 12

1.2.4.1 Cây nguồn (source tree) 12

1.2.4.2 Cây chia sẻ (shared-tree) 14

1.3 Giao thức quản lý nhóm IGMP 15

1.3.1 IGMP v1 16

1.3.2 IGMP v2 17

1.3.3 IGMP v3 19

1.4 Định tuyến trong IP Multicast 19

1.4.1 Các thuật toán trong định tuyến IP Multicast 20

1.4.1.1 Flooding 20

1.4.1.2 Cây mở rộng (Spanning Tree) 21

1.4.1.3 RPB (Reverse Path Broadcasting) 21

1.4.1.4 TRPB (Truncated Reverse Path Broadcasting) 22

1.4.1.5 RPM (Reverse Path Multicasting) 23

1.4.1.6 Core-Based Trees 24

1.4.2 Các giao thức định tuyến IP Multicast 25

1.4.2.1 PIM 25

CHƯƠNG II: ỨNG DỤNG IP MULTICAST VỚI IPTV 39

2.1 Giới thiệu về IPTV 39

2.1.1 Lịch sử phát triển IPTV 39

2.1.2 Khái niệm IPTV 39

2.1.3 Sự khác biệt giữa IPTV và truyền hình Internet 40

2.1.4 Một số đặc tính của IPTV 41

2.2 Tổ chức mạng cung cấp dịch vụ IPTV 42

2.2.1 Cơ sở hạ tầng mạng IPTV 42

2.2.2 Kiến trúc hệ thống cung cấp dịch vụ IPTV 43

2.2.3 Phương pháp truyền nội dung IPTV 46

2.2.4 Các giao thức sử dụng trong truyền tải nội dung IPTV 47

2.3 Các thiết bị phần cứng trong mạng IPTV 51

2.3.1 Thiết bị phần cứng trung tâm Headend 51

2.3.1.1 Thiết bị tiếp nhận dữ liệu đầu vào 52

2.3.1.2 Bộ mã hóa video MPEG 53

2.3.1.3 Bộ đóng gói IP 54

2.3.1.4 Bộ chuyển đổi mã video 54

2.3.1.5 Server quản lý nội dung 54

2.3.1.6 Kho video 55

2.3.1.7 Video streaming server 55

2.3.1.8 Middleware server 55

2.3.2 Thiết bị mạng gia đình 57

2.3.2.1 Mạng gia đình 57

2.3.2.2 Bộ giải mã IP – STB 58

2.4 Các dịch vụ và ứng dụng của IPTV 60

2.4.1 Truyền hình quảng bá kỹ thuật số 60

2.4.2 Video theo yêu cầu VoD 61

2.4.3 Các dịch vụ quảng cáo 61

2.5 Tình hình triển khai IPTV tại Việt Nam 62

2.5.1 Nhu cầu sử dụng dịch vụ IPTV tại Việt Nam 62

2.5.2 Tình hình triển khai IPTV của FPT 63

2.5.4 Tình hình triển khai IPTV của VNPT 64

CHƯƠNG III: XÂY DỰNG ỨNG DỤNG GROUP CHAT 66

3.1 Giới thiệu 66

3.1.1 Giới thiệu ngôn ngữ lập trình Java 66

3.1.2 IP multicast trong Java 68

3.2 Phân tích thiết kế ứng dụng Group Chat 69

3.2.1 Mô tả ứng dụng 69

3.2.2 Mô hình chức năng và hoạt động của chương trình 70

3.3 Kết quả 71

KẾT LUẬN 73

TÀI LIỆU THAM KHẢO 74

Hình 1.1: Minh họa truyền thông Unicast Error! Bookmark not defined Hình 1.2: Minh họa truyền thông Broadcast Error! Bookmark not defined Hình 1.3: Minh họa truyền thông Multicast Error! Bookmark not defined Hình 1.4: Minh họa đường hầm Multicast Error! Bookmark not defined Hình 1.5: Minh họa đường hầm Multicast Error! Bookmark not defined Hình 1.6: Chuyển đổi địa chỉ IP Multicast thành địa chỉ Ethernet/FDDI Error!

Bookmark not defined

Hình 1.7: Ví dụ về cây nguồn Error! Bookmark not defined Hình 1.8: Ví dụ IPTV đơn giản sử dụng SPT Error! Bookmark not defined Hình 1.9: Minh họa sự thay đổi các nhánh trên thực tế Error! Bookmark not defined Hình 1.10: Ví dụ về cây phân phối chia sẻ Error! Bookmark not defined Hình 1.11: Định dạng của bản tin IGMP Error! Bookmark not defined Hình 1.12: Minh họa bản tin Membership Query Error! Bookmark not defined Hình 1.13: Định dạng của bản tin IGMPv2 Error! Bookmark not defined Hình 1.14: Quá trình rời khỏi nhóm IGMPv2 Error! Bookmark not defined Hình 1.15: Minh họa cây mở rộng Error! Bookmark not defined Hình 1.16: Minh họa cây RPB Error! Bookmark not defined Hình 1.17: Minh họa thuật toán TRPB Error! Bookmark not defined Hình 1.18: Minh họa thuật toán RPM Error! Bookmark not defined Hình 1.19: Minh họa thuật toán CBT Error! Bookmark not defined Hình 1.20: Định dạng bản tin PIM Error! Bookmark not defined Hình 1.21: Minh họa quá trình thiết lập cây broadcast rút gọn Error! Bookmark not

Hình 1.30: Minh họa định tuyến liên miền Error! Bookmark not defined Hình 1.31: Hạn chế của định tuyến liên miền Error! Bookmark not defined Hình 2.1: Các thành phần của mạng IPTV Error! Bookmark not defined Hình 2.2: Mô hình kiến trúc hệ thống cung cấp dịch vụ IPTV Error! Bookmark not

defined

Hình 2.3: Minh họa kỹ thuật multicast trong IPTV Error! Bookmark not defined Hình 2.4: Minh họa tiêu đề gói tin UDP Error! Bookmark not defined Hình 2.5: Tiêu đề bản tin RTP Error! Bookmark not defined Hình 2.6: Minh họa giao thức RTSP Error! Bookmark not defined Hình 2.7: Cấu trúc trung tâm Headend IPTV Error! Bookmark not defined Hình 2.8: Cấu trúc hệ thống Middleware IPTV Error! Bookmark not defined Hình 2.9: Cấu trúc IP – STB Error! Bookmark not defined Hình 2.10: Minh họa tiến trình xử lý của IP - STP Error! Bookmark not defined

Hình 3.1: Kiến trúc multicast peer-to-peer 70

Hình 3.2: Mô tả hoạt động của chương trình Group Chat: 71

Hình 3.3: Mô tả hoạt động của ứng dụng Group Chat 71

Hình 3.4: Ứng dụng Group Chat viết bằng Java 72

ADLS Asymmetric Digital Subcriber

DHCP Dynamic Host Configuration

Protocol

Giao thức cấu hình host động

DSLAM Digital Subcriber Line Access

Multiplexer

Thiết bị tập trung thuê bao số

DVMRP Distance Vector Multicast Routing

IPTV Internet Protocol Television Truyền hình giao thức Internet

IRD Integrated Receiver Decoder Bộ giải mã đầu thu tích hợp

ITU – T International Telecommunications

Union – Telecommunication

Tổ chức viễn thông quốc tế về các tiêu chuẩn viễn thông

LSA Link – State Advertisement Quảng bá trạng thái liên kết

MDP Multicast Distribution Protocol Giao thức phân phối multicast

MPEG Moving Picture Experts Group Nhóm chuyên gia về ảnh động MPLS Multi – Protocol Label Switching Chuyển mạch nhãn đa giao thức MOSPF Multicast Open Shortest Part First Giao thức OSPF cho multicast NTSC National Television System Ủy ban hệ thống truyền hình quốc

gia Mỹ PIM Protocol – Independent Multicast Giao thức multicast độc lập

PSTN Public Switched Telephone

RPB Reverse Path Broadcasting Quảng bá tuyến đường nghịch đảo

đảo RPM Reverse Path Multicasting Tuyến đường multicast nghịch đảo TCP Transport Control Protocol Giao thức điều khiển truyền tải TCP/IP Transmission Control

Ngày nay hạ tầng mạng viễn thông đã phát triển với tốc độ chóng mặt và việc trao đổi thông tin trên mạng là điều tất yếu Cùng với tốc độ phát triển là sự ra đời của nhiều công nghệ mạng, nhiều kỹ thuật truyền tải giúp cho việc trao đổi dữ liệu trên mạng được nhanh chóng, chính xác và hiệu quả Multicast ra đời cũng nhằm phục vụ cho một trong những mục đích trên Với ưu điểm tiết kiệm băng thông, giảm tải cho mạng, IP multicast là một sự thay thế tốt cho phương thức truyền unicast khi mà các công ty cần chuyển thông tin đến nhiều khách hàng trong cùng một thời điểm

Cùng với việc nghiên cứu của bản thân và sự hướng dẫn của TS Nguyễn Chiến Trinh em đã thực hiện đồ án: “Nghiên cứu IP multicast và các ứng dụng” Mục đích của đồ án là đi sâu vào nghiên cứu nguyên tắc hoạt động cũng như các giao thức định tuyến trong IP multicast Qua đó phân tích và phát triển ứng dụng của IP multicast trong ICT Nội dung của đồ án bao gồm:

Chương 1: IP multicast và các vấn đề liên quan

Chương 2: Ứng dụng IP multicast với IPTV

Chương 3: Xây dựng ứng dụng Group chat

Do hạn chế về thời gian cũng như kiến thức nên chắc rằng đồ án của em vẫn còn nhiều thiếu sót Em mong nhận được các ý kiến đóng góp từ phía thầy cô và các bạn

để đề tài được hoàn thiện hơn

Em xin được gửi lời cảm ơn chân thành đến các thầy cô giáo trong khoa Viễn thông, các thầy cô trong Viện Khoa học Kỹ thuật Bưu điện, đặc biệt là thầy giáo TS Nguyễn Chiến Trinh, thầy đã tận tình hướng dẫn em hoàn thiện đồ án này Em cũng xin được gửi lời cảm ơn đến gia đình, bạn bè đã quan tâm và giúp đỡ em trong suốt thời gian làm đồ án

Hà nội, ngày 05 tháng 12 năm 2010 Sinh viện thực hiện

Nguyễn Văn Hưng

CHƯƠNG I

IP MULTICAST VÀ CÁC VẤN ĐỀ LIÊN QUAN

1.1 Giới thiệu về IP Multicast

IP Multicast là một chuẩn mở của IETF dùng để truyền dẫn các gói dữ liệu IP từ một nguồn đến nhiều đích trong một mạng LAN hay WAN Các host tham gia vào một nhóm Multicast và các ứng dụng chỉ gửi một bản sao của gói tin cho một địa chỉ nhóm Gói tin này chỉ gửi đến những điểm muốn nhận được lưu lượng đó Việc gửi bản tin Unicast và Broadcast là các trường hợp đặc biệt của phương pháp Multicast Truyền Multicast cải thiện đáng kể hiệu suất, thường sử dụng băng thông nhỏ hơn truyền truyền đơn trên mạng, và cho phép xây dựng ứng dụng phân tán hợp lý

1.1.1 Truyền thông Unicast

Truyền thông Unicast, hay còn gọi là truyền thông điểm - điểm Trong hình thức truyền thông này, nhiều host muốn nhận gói tin từ một bên gửi thì bên đó phải truyền nhiều gói tin đến các bên nhận Điều này sẽ dẫn đến gia tăng băng thông khi có quá nhiều bên nhận và không hiệu quả về nguồn và bộ đệm

Hình 1.1: Minh họa truyền thông Unicast

1.1.2 Truyền thông Broadcast

Truyền thông Broadcast cho phép truyền gói tin từ một host tới tất cả các host khác trên subnet mà không quan tâm đến việc một số host không có nhu cầu nhận gói tin

Các gói tin cho Host B Các gói tin cho Host D

Host B Host A

đó Kiểu truyền thông này được coi như là một sát thủ băng thông do việc sử dụng tài nguyên không hiệu quả

Hình 1.2: Minh họa truyền thông Broadcast

1.1.3 Truyền thông Multicast

Hình 1.3: Minh họa truyền thông Multicast

Một địa chỉ Multicast cho phép phân phối gói tin tới một tập hợp các host đã được cấu hình như những thành viên của một nhóm Multicast trong các subnet phân tán khác nhau Đây là phương pháp truyền thông đa điểm, trong đó chỉ các host có nhu cầu nhận dữ liệu mới tham gia vào nhóm Điều này hạn chế tối đa sự lãng phí băng

Gói tin cho nhóm multicast

Host B Host A

Host C

Host D

Host E Nguồn

Server

thông trên mạng, hơn nữa còn nhờ cơ chế gửi gói tin Multicast mà băng thông được tiết kiệm triệt để

1.2 Triển khai Multicast

1.2.1 Nhóm Multicast

Một vấn đề quan trọng của IP Multicast là nhóm Multicast Việc xây dựng một nhóm Multicast bắt đầu với một server đang chạy một ứng dụng Multicast như audio, video Khi một server được xây dựng, một địa chỉ Multicast Lớp D được gán cho ứng dụng đó và tất cả các thành viên của nó Một nhóm Multicast được cấp phát cho một địa chỉ lớp D làm địa chỉ đại diện cho nhóm đó Số lượng thành viên của nhóm có thể

là 0, 1 hay nhiều thành viên Các thành viên có thể nằm tại các subnet khác nhau Khi một host muốn gia nhập nhóm, nó gửi một bản tin IGMP chứa địa chỉ lớp D của nhóm mong muốn tới Mrouter cục bộ của nó (Mrouter là các router có hỗ trợ Multicast Một trong những chức năng của router này là giúp các host trên các mạng gắn trực tiếp với nó truy nhập hệ thống phân phối Multicast) Sau khi Mrouter nhận bản tin IGMP từ các host, nó chuyển tiếp tất cả lưu lượng Multicast cho nhóm các host

đó Các host có thể gia nhập nhóm hoặc rời bỏ nhóm bất cứ lúc nào

1.2.2 Đường hầm Multicast

Khi chưa có nhiều router hỗ trợ Multicast được triển khai trên mạng thì đường hầm Multicast là một giải pháp hợp lý để triển khai Multicast Hãy tưởng tượng khi số lượng Mrouter trên mạng là rất ít, ta có thể coi mỗi Mrouter như là một hòn đảo giữa rất nhiều router Unicast Hai hòn đảo này có thể kết nối trực tiếp bằng một đường liên kết vật lý hoặc một đường hầm logic Nếu một đường hầm kết nối 2 Mrouter, khi đó

nó đại diện cho một liên kết ảo điểm – điểm giữa chúng.

Hình 1.4: Minh họa đường hầm Multicast

MR Nguồn

Đóng gói unicast

Đường hầm multicast

Trong các đường hầm là các router Unicast Khi một gói tin tiến vào đường hầm,

nó được đóng gói trong một gói IP Unicast với một địa chỉ đích của Mrouter ở phía bên kia của đường hầm Khi rời khỏi đường hầm, nó được bóc tách và được xử lý tại các Mrouter Do đó, một đường hầm cho phép lưu lượng Multicast truyền liên tục giữa hai Mrouter thông qua các router Unicast

Hình 1.5 là một ví dụ minh họa đường hầm Multicast Giả sử rằng Mrouter A muốn gửi chuyển tiếp một multicast datagram tới Mrouter B A và B không được kết nối vật lý với nhau và các router trung gian giữa A và B không có khả năng multicast

Để thiết lập đường hầm, router A đóng gói multicast datagram vào trong một unicast datagram tiêu chuẩn Sau đó, toàn bộ multicast datagram (bao gồm cả dải địa chỉ multicast nguồn và đích) được vận chuyển như là phần tải tin (payload) của một unicast datagram Hay nói cách khác, một gói tin unicast mang bên trong một gói tin multicast Gói tin unicast datagram sau đó được đánh địa chỉ unicast của router B và được chuyển tiếp tới router B bởi router A Khi gói tin unicast datagram tới B, B sẽ bóc tách nó Và router B có thể chuyển tiếp gói tin multicast datagram tới các host gắn với nó, chuyển tiếp gói tin tới Mrouter hàng xóm, hoặc chuyển tiếp gói tin multicast datagram qua một đường hầm khác

Hình 1.5: Minh họa đường hầm Multicast

1.2.3 Vấn đề địa chỉ trong IP Multicast

Một địa chỉ multicast được gán tới một tập các host nhận để định nghĩa một nhóm multicast Các host gửi sử dụng địa chỉ multicast làm địa chỉ IP đích của gói tin để truyền gói tin đó tới tất cả các thành viên trong nhóm

Dải địa chỉ từ 224.0.0.0 đến 224.0.0.255 được gọi là dải địa chỉ phạm vi cục bộ, sử dụng cho các giao thức mạng trên một đoạn mạng cục bộ Các gói tin được gán địa chỉ trong dải địa chỉ này sẽ không được forward bởi các router (Bất chấp giá trị time-to-live [TTL] của gói tin là bao nhiêu) Dưới đây chỉ ra một số địa chỉ được dành riêng cho những mục đích đặc biệt:

1.2.3.2 Ánh xạ địa chỉ IP multicast sang địa chỉ MAC

Khi một router trong một subnet nhận được một gói tin multicast lớp 3, nó có thể ánh xạ một địa chỉ IP multicast này thành một địa chỉ multicast lớp 2, có thể là một địa chỉ Ethernet MAC Tại nơi nhận thiết bị giao tiếp mạng có thể dễ dàng đọc địa chỉ lớp

2 này bằng phần cứng Nếu địa chỉ nhận được là địa chỉ multicast thì gói tin sẽ được chuyển tiếp lên lớp trên Quá trình chuyển đổi từ địa chỉ IP multicast sang địa chỉ lớp 2 xảy ra bằng cách ánh xạ trực tiếp địa chỉ IP tới địa chỉ MAC Ethernet, lấy 23 bit trọngsố thấp trong địa chỉ IP chuyển thành 23 bit có trọng số thấp trong địa chỉ MAC Ethernet Hình 1.6 minh họa cơ chế ánh xạ địa chỉ, các bước tiến hành như sau:

1) Chuyển đổi địa chỉ IP sang dạng nhị phân

2) Thay thế 4 bit đầu tiên 1110 của địa chỉ IP với 6 ký tự 01-00-5E như là địa chỉ bắt đầu của địa chỉ multicast MAC

3) Thay thế 5 bit tiếp theo của địa chỉ IP với một bit 0

4) Chép 23 bit còn cuối của địa chỉ IP vào 23 bit cuối trong không gian địa chỉ MAC

5) Chuyển đổi 24 bit cuối của địa chỉ multicast từ dạng nhị phân sang dạng 6

số thập lục phân

6) Kết hợp sáu chữ số hexa đầu tiên 01-00-5E với sáu chữ số hexa vừa tính được ở bước 5 để hình thành địa chỉ multicast đầy đủ

Hình 1.6: Chuyển đổi địa chỉ IP Multicast thành địa chỉ Ethernet/FDDI

Chú ý rằng có 5 bit của địa chỉ IP không được chuyển sang địa chỉ MAC Điều 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 Do đó, một host khi nhận một khung Ethernet của một địa chỉ

239.255.0.1

1110

28 bit địa chỉ Mcast

Địa chỉ MAC

(Ethernet/FDDI) 01-00-5e-7f-00-01

multicast, nó phải kiểm tra tất cả các khung có MAC mà nó quan tâm Sau đó host này kiểm tra phần địa chỉ IP bên trong mỗi khung để nhận ra phần địa chỉ của từng nhóm multicast Ví dụ, địa chỉ multicast 224.138.8.5 (E0-8A-08-08) và 225.10.8.5 (E1-0A-08-05) đều ánh xạ tới cùng một địa chỉ Ethernet (01-00-5E-0A-08-05) Trên thực tế, hiếm khi hai ứng dụng multicast trên cùng một LAN có thể tạo ra cùng những địa chỉ MAC Nếu có xảy ra, một gói tin từ một ứng dụng multicast khác có thể sẽ được phân biệt bằng địa chỉ lớp 3

1.2.4 Chuyển tiếp lưu lượng Multicast

Có một vài phương pháp để chuyển tiếp lưu lượng IP multicast từ nguồn đến các host thu Đầu tiên ta sắp xếp một nhóm bao gồm các host thu với một địa chỉ lớp D chung để đạt được sự phân phối lưu lượng multicast hiệu quả Bước tiếp theo là tạo ra một tập hợp các đường phân phối multicast cho các router sử dụng Các giao thức được xây dựng trong các router giúp xây dựng cây phân phối multicast để chuyển tiếp các gói Hai kiểu cơ bản của cây phân phối multicast là cây nguồn (source tree) hay còn gọi là cây tuyến đường ngắn nhất SPT (Shortest Path Trees) và cây chia sẻ (shared trees)

1.2.4.1 Cây nguồn (source tree)

Đây là đạng đơn giản nhất của một cây phân phối multicast Một cây nguồn có gốc

là nguồn multicast và các nhánh được mở rộng qua mạng đến các máy thu (receiver)

Ký hiệu (S,G) được sử dụng để mô tả một cây SPT với S là địa chỉ IP của nguồn và G

là địa chỉ nhóm multicast

Hình 1.7 mô tả một ví dụ về một SPT cho nhóm 239.1.1.1, có gốc là host A và kết nối với 3 máy thu là các host B, C, D Sử dụng ký hiệu (S,G), SPT ở đây là (92.1.1.1, 239.1.1.1) Chú ý rằng kí hiệu (S,G) chỉ ra rằng tồn tại một SPT riêng cho mỗi nguồn riêng biệt gửi tới mỗi nhóm Bởi vậy, nếu host D cũng đang gửi lưu lượng tới nhóm 239.1.1.1 và các host A, B, C là các máy thu thì một SPT với ký hiệu (92.2.2.4, 239.1.1.1) cũng tồn tại

Các SPT đạt được tạo thành topo tuyến đường tối ưu giữa nguồn và các máy thu, tức là số lượng các hop là nhỏ nhất Kết quả, trễ chuyển tiếp cho việc phân phối lưu lượng multicast là thấp nhất cho mạng Tuy nhiên các Mrouter luôn phải duy trì thông tin về tuyến đường từ nó tới mỗi nguồn Trong một mạng lớn có nhiều nguồn và nhiều điểm nhận thì thông tin trạng thái tuyến đường trở thành gánh nặng với các router Các router cần phải có bộ nhớ lớn để lưu trữ bảng định tuyến

Hình 1.7: Ví dụ về cây nguồn

Các thành viên trong nhóm multicast có thể gia nhập hoặc rời nhóm bất cứ thời điểm nào vì vậy mà cây phân phối multicast phải được cập nhập một cách linh hoạt Khi các host của một nhánh nào đó ngừng yêu cầu nhận lưu lượng, các router phải xóa nhánh đó ra khỏi cây phân phối multicast và ngừng chuyển lưu lượng xuống nhánh đó

Hình 1.8: Ví dụ IPTV đơn giản sử dụng SPT

Nếu một host trong nhánh đó yêu cầu lưu lượng multicast trở lại thì router phải lập tức thay đổi cây phân phối và chuyển lưu lượng cho nhánh đó trở lại Hình 1.8 minh họa một ví dụ IPTV đơn giản Trong ví dụ này, SPT được sử dụng để phân phối hiệu quả video tới các khách hàng (user) từ xa

Hình 1.9 cho thấy việc cắt bỏ các nhánh không yêu cầu lưu lượng multicast ở một thời điểm nào đó

Hình 1.9: Minh họa sự thay đổi các nhánh trên thực tế

1.2.4.2 Cây chia sẻ (shared-tree)

Không giống như cây nguồn (có gốc ở nguồn multicast), cây chia sẻ sử dụng 1 gốc chung đặt ở một điểm đã lựa chọn trên mạng Gốc chung này được gọi là một điểm hẹn RP (Rendezvous Point) hay còn gọi là lõi Hình 1.10 minh họa một cây chia sẻ cho nhóm 239.1.1.1 với gốc dùng chung Khi sử dụng cây chia sẻ, các nguồn gửi lưu lượng của chúng tới gốc (RP) và sau đó lưu lượng được chuyển tiếp dọc theo cây chia

sẻ tới tất cả các máy thu (receiver) Trong ví dụ này, lưu lượng multicast từ cả 2 nguồn được chuyển tới router đặt tại RP và sau đó lưu lượng được chuyển tiếp dọc thoe cây chia sẻ tới các host B, C và D Tất cả các nguồn trong nhóm multicast sử dụng chung cây chia sẻ Sử dụng ký hiệu (*,G) để biểu diễn cây, với “*” là 1 wildcard có nghĩa là tất cả các nguồn Cây chia sẻ trong Hình 1.10 được ký hiệu là (*, 239.1.1.1)

Cây chia sẻ đòi hỏi số lượng về thông tin trạng thái trên mỗi router là nhỏ nhất, bởi vậy bộ nhớ yêu cầu cho mỗi router là tối ưu Tuy nhiên, các tuyến đường giữa nguồn

và các máy thu (receiver) có thể không phải là tối ưu theo hopcount Điều này gây ra khó khăn trong việc xác định vị trí đặt RP trên mạng khi thực hiện thiết kế 1 cây chia

sẻ

Hình 1.10: Ví dụ về cây phân phối chia sẻ

1.3 Giao thức quản lý nhóm IGMP

Giao thức quản lý nhóm IGMP là cơ chế truyền thông giữa host và router gắn trực tiếp với mạng đó Router sử dụng IGMP để xác định có hay không có thành viên nhóm multicast trong subnet Nếu có thành viên trong nhóm, router sẽ tham gia vào nhóm multicast đó và chuyển tiếp dữ liệu multicast đến host trong nhóm

Hai mục đích quan trọng nhất của IGMP là:

 Thông báo cho Mrouter biết rằng có một host muốn nhận lưu lượng multicast của một nhóm cụ thể

 Thông báo cho Mrouter biết rằng có một máy muốn rời một nhóm multicast (nói cách khác, có một máy không còn quan tâm đến việc nhận multicast nữa)

IGMP sử dụng một địa chỉ lớp D dành riêng là 224.0.0.1 Đây là một nhóm cố định cho tất cả các Mrouter trong hệ thống IP Multicast Nó đảm bảo tính sẵn sàng của 1 địa chỉ Multicast thông qua subnet có thể liên kết với Mrouter của nó

IGMPv1 được đưa ra trong RFC 1112 (tháng 8/1989) và v2 được giới thiệu trong RFC 2236 (tháng 8/1997)

Phiên bản mới nhất IGMPv3 được chỉ ra trong RFC 3376 (tháng 8/2002) là sự kết hợp của v1 và v2

Hình 1.11: Định dạng của bản tin IGMP

- Trường version dài 4 bit mang giá trị 0x1 đối với IGMPv1

- Trường Type dài 4 bit xác định loại bản tin truy vấn:

 Type = 0x1 : bản tin truy vấn thành viên Membership Query

 Type = 0x2 : bản tin báo cáo thành viên Membership Report

- Trường unused dài 8 bit không sử dụng nên mang giá trị 0x00

- Trường Checksum dài 16 bit dùng để kiểm tra lỗi header

- Trường Group Address dài 32 bit chứa địa chỉ nhóm multicast, mang giá trị 0.0.0.0 khi loại bản tin là Membership Query, mang giá trị địa chỉ nhóm multicast khi loại bản tin là Membership Report

Theo định kỳ, cứ 60 giây các Mrouter gửi bản tin Membership Query để xác định xem các host này còn quan tâm tới việc nhận lưu lượng multicast nữa không? Bản tin Query này được đánh địa chỉ nhóm tất cả các host trong mạng (224.0.0.1) và có IP TTL = 1 Điều này có nghĩa là bản tin Query không bị chuyển tiếp bởi bất cứ Mrouter nào khác

Khi một host nhận bản tin Query, nó sẽ trả lời bằng 1 bản tin Membership Report cho mỗi nhóm mà nó tham gia Khi nhận được bản tin Membership Query, host sẽ thiết lập một thời gian ngẫu nhiên (10 giây đối với IGMPv1) Khi hết thời gian này, host sẽ tiến hành gửi thông điệp Membership Report để xác lập mối quan hệ Khi host đầu tiên gửi bản tin Membership Report, các host khác trên cùng đoạn mạng sẽ nhận được bản tin này, bộ đếm thời gian bị loại bỏ và sẽ không gửi bản tin Membership Report đi nữa

Hình 1.12: Minh họa bản tin Membership Query

Các host có thể tham gia vào một nhóm ở bất cứ thời điểm nào bằng cách gửi bản tin Membership Report đến nhóm đó Tuy nhiên do IGMPv1 không hỗ trợ cơ chế cho phép một host rời nhóm khi host đó không còn muốn nhận lưu lượng multicast nữa Bởi vậy nếu một host muốn rời khỏi nhóm, nó sẽ không gửi Membership Report trong

ba chu kỳ truy vấn liên tiếp của router Điều này có nghĩa là theo mặc định thì lưu lượng 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 lưu lượng multicast nữa Các Mrouter cũng không lưu danh sách tri tiết các host thuộc về mỗi nhóm multicast Nó chỉ cần biết những nhóm multicast nào đang tồn tại trên những công nào của nó

Hình 1.13: Định dạng của bản tin IGMPv2

- Trường Type dài 8 bit, mỗi giá trị trường Type ứng với một loại bản tin:

Type = 0x11 : Bản tin truy vấn thành viên Membership Query (Chia làm 2 kiểu: Thứ nhất là bản tin General Query dùng để xác định nhóm nào trên mạng có thành viên hoạt động Thứ hai là bản tin Group-Specific Query dùng để xác định một nhóm

multicast cụ thể có thành viên hoạt động)

 Type = 0x12 : Bản tin báo cáo thành viên Membership Report Version 1

 Type = 0x16 : Bản tin báo cáo thành viên Membership Report Version 2

 Type = 0x17 : Bản tin rời khỏi nhóm Leave Group

- Trường Checksum dài 16 bit dùng để kiểm tra lỗi header

- Trường Group Address chứa địa chỉ nhóm Đối với bản tin General Query, trường này mang giá trị 0.0.0.0 Đối với bản tin Group Specfic, trường này sẽ chứa địa chỉ của nhóm multicast được tuy vấn

IGMPv2 có một số khác biệt so với IGMPv1 Một cải tiến đó là IGMPv2 có hỗ trợ

cơ chế rời nhóm Hình 1.14 minh họa quá trình rời khỏi nhóm 224.2.155.145 của host H2 Đầu tiên, host H2 gửi bản tin Leave Group tới địa chỉ tất cả các Mrouter 224.0.0.2, thông báo rằng nó muốn rời khỏi nhóm 224.2.155.145 Vì Mrouter không biết có bao nhiêu host trong đoạn mạng thuộc về nhóm 224.2.155.145 nên nó phải gửi một bản tin Group-Specific Query để xác định xem liệu còn thành viên nào trong nhóm 224.2.155.145 không? Nếu không nhận được trả lời sau một thời gian (theo mặc định

là 1 giây), router sẽ kết luận là không cần thiết gửi lưu lượng multicast cho nhóm đó nữa Trong ví dụ, host H3 gửi bản tin Membership Report trả lời router rằng nó vẫn đang tham gia nhóm

Hình 1.14: Quá trình rời khỏi nhóm IGMPv2

Một chức năng quan trọng khác được bổ sung trong IGMPv2 là tiến trình Querier Election (lựa chọn router truy vấn) Trong mạng đa truy nhập (multiaccess) có nhiều router trong một đoạn mạng, IGMPv2 sử dụng địa chỉ IP trong bản tin General Query

để lựa chọn router truy vấn IGMP Tiến trình thực hiện như sau:

i Khi các Mrouter IGMPv2 bắt đầu chạy, mỗi router sẽ gửi multicast một bản tin IGMPv2 General Query tới tất cả Mrouter (224.0.0.1) với địa chỉ giao diện trong trường địa chỉ IP nguồn (Source IP Address) của bản tin

ii Khi một router IGMPv2 nhận bản tin General Query, nó so sánh địa chỉ IP nguồn của bản tin với địa chỉ giao diện của nó Router nào có địa chỉ IP nhỏ nhất trong subnet sẽ được lựa chọn là router truy vấn IGMP

iii Các router không truy vấn bắt đầu chạy một bộ đếm thời gian (theo mặc định, thời gian này là 250 giây) mà được reset bất cứ khi nào router nhận được một bản tin General Query từ router truy vấn Nếu chạy hết khoảng thời gian này, router sẽ coi như router truy vấn không còn hoạt động nữa, và tiến trình lựa chọn được chạy lại để chọn ra một router truy vấn mới

1.3.3 IGMP v3

IGMPv3 giới thiệu bổ sung bản tin Group-Source Report cho phép một host có thể quyết định nhận lưu lượng từ các nguồn riêng biệt của một nhóm multicast Một bản tin Group-Source Report cho phép một host chỉ ra địa chỉ IP của nguồn cụ thể mà nó muốn nhận Bản tin Exclusion Group-Source Report cho phép một host nhận dạng chính xác các nguồn mà nó không muốn nhận lưu lượng Cuối cùng, bản tin Leave Group trong IGMPv2 được nâng cấp thành bản tin Group-Source Leave Điều này cho phép một host rời khỏi toàn bộ nhóm hay chỉ ra các địa chỉ IP riêng biệt của cặp (nguồn, nhóm) mà nó muốn rời khỏi

1.4 Định tuyến trong IP Multicast

Để hỗ trợ truyền thông multicast, một router cần phải hỗ trợ ít nhất một trong các giao thức định tuyến multicast Với router Unicast, có một số giao thức định tuyến như RIP và OSPF thường được sử dụng để xác định đường đi từ nguồn tới đích cho gói tin Tuy nhiên, các giao thức đó không phù hợp với bản chất phi vật lý của các nhóm multicast Do đó các Mrouter phải hỗ trợ một số thuật toán định tuyến và giao thức dành riêng cho multicast

Định tuyến lưu lượng multicast phức tạp hơn nhiều so với định tuyến lưu lượng unicast Số lượng các máy thu trong một phiên multicast có thể khá lớn Các router mạng phải có khả năng chuyển địa chỉ multicast sang địa chỉ host Trong định tuyến multicast, các router tương tác để trao đổi thông tin về các router hàng xóm Giao thức quản lý nhóm sẽ chọn một router làm router bổ nhiệm DR (Desinated Router) cho mỗi mạng vật lý DR thường là router gần nhất với gốc

Sử dụng các giao thức định tuyến multicast, các Mrouter thiết lập linh hoạt các cây đường đa điểm sử dụng thông tin thành viên nhóm có được từ việc truyền thông IGMP Các cây đường đa điểm đó chỉ ra các tuyến đường từ một máy phát tới tất cả

máy thu Các giao thức định tuyến IP multicast thường theo một trong hai dạng sau: dạng tập chung hoặc dạng phân tán

 Định tuyến multicast dạng tập chung:

Các thành viên nhóm multicast được phân bố tập chung trong toàn mạng với nhiều mạng con chứa ít nhất một thành viên nhóm, có đặc trưng là chiếm băng thông lớn Các giao thức định tuyến dạng tập trung bao gồm: DVMRP, MOSPF và PIM-DM Các giao thức này dựa vào kỹ thuật phát tán thông tin tới tất cả các router mạng

 Định tuyến multicast dạng phân tán:

Dạng phân tán: thành viên trong nhóm nằm phân tán tại nhiều vùng của mạng và không yêu cầu băng thông lớn Nó dựa vào kỹ thuật lựa chọn để thiết lập và duy trì cây multicast, sử dụng một quá trình khởi tạo máy thu (receiver-initiated process) Có nghĩa là một router chỉ xây dựng cây phân phối multicast khi một trong các host thuộc mạng con của nó là thành viên của một nhóm multicast nào đó Các giao thức định tuyến dạng phân tán gồm: CBT và PIM-SM

1.4.1 Các thuật toán trong định tuyến IP Multicast

Một giao thức định tuyến multicast chịu trách nhiệm cho việc xây dựng các cây phân phối lưu lượng multicast và thực hiện chuyển tiếp các gói tin multicast Mục này

sẽ khám phá một số các thuật toán sử dụng bởi các giao thức định tuyến multicast

1.4.1.1 Flooding

Thuật toán Flooding là kỹ thuật đơn giản nhất cho việc phân phối gói tin multicast tới tất cả các router trên một liên mạng Thủ tục flooding bắt đầu khi một router nhận được một gói tin mà được đánh địa chỉ tới một nhóm multicast Router sử dụng cơ chế của giao thức để xác định xem liệu đây có phải là lần đầu tiên nó gặp gói tin đặc biệt này hay không? Nếu đó là lần đầu tiên, gói tin sẽ được chuyển tiếp tới tất cả các giao diện của router, ngoại trừ giao diện mà vừa nhận gói tin Nếu router đã từng gặp gói tin trước đây, nó sẽ lập tức huy gói tin Thuật toán flooding thực hiện rất đơn giản vì router không phải duy trì bảng định tuyến, nó chỉ cần lưu lại dấu vết của các gói tin gần đây nhất Tuy nhiên, flooding làm phát sinh một số lượng lớn các gói tin bản sao, điều này tiêu phí băng thông mạng Ngoài ra, thuật toán flooding giúp sử dụng tài nguyên bộ nhớ một cách hiệu quả, vì mỗi router chỉ cần duy trì một mục bảng riêng cho mỗi gói tin gần đây nhất

1.4.1.2 Cây mở rộng (Spanning Tree)

Một giải pháp hiệu quả hơn flooding là lựa chọn một subnet của topo mạng để hình thành một cây mở rộng

Cây mở rộng định nghĩa một cấu trúc cây mà chỉ có một tuyến đường hoạt động giữa bất cứ 2 router nào đó Hình 1.15 minh họa một liên mạng và một cây mở rộng có gốc đặt tại router R

Hình 1.15: Minh họa cây mở rộng

Một khi cây mở rộng đã được xây dựng, một Mrouter chuyển tiếp gói tin multicast tới tất cả các giao diện là một phần của cây mở rộng, ngoại trừ cái giao diện mà nó vừa nhận gói tin Chuyển tiếp gói tin dọc theo các nhánh của một cây mở rộng đảm bảo rằng gói tin multicast sẽ không bị quay vòng và gói tin sẽ dần dần tới tất cả các router trên liên mạng Giải pháp cây mở rộng giúp tập trung lưu lượng trên một số lượng nhỏ các liên kết và có thể cung cấp tuyến đường hiệu quả giữa mạng nguồn và các thành viên trong nhóm

1.4.1.3 RPB (Reverse Path Broadcasting)

Thuật toán RPB hiện đang được sử dụng trong các Mbone (mạng xương sống của

hệ thống đa điểm), là một cải tiến của thuật toán cây mở rộng (Spanning Tree) Trong thuật toán này, thay bằng việc xây dựng một cây mở rộng mạng diện rộng, một cây mở rộng tuyệt đối sẽ được xây dựng cho mỗi nguồn Thuật toán này thực tế khá là đơn giản Bất cứ khi nào router nhận một gói tin multicast trên liên kết “L” và từ nguồn

“S”, router sẽ kiểm tra xem liên kết L có thuộc về tuyến đường ngắn nhất từ nguồn tới router không? Nếu đúng, gói tin sẽ được chuyển tiếp trên tất cả các liên kết, ngoại trừ

L Nếu L không thuộc về tuyến đường ngắn nhất từ nguồn tới router, gói tin sẽ bị hủy Thuật toán RPB dễ dàng hoàn thiện bằng cách xem xét thực tế nếu router không nằm trên tuyến đường ngắn nhất giữa node nguồn và một hàng xóm, gói tin sẽ bị hủy ở

router hàng xóm Bởi vậy trong trường hợp này không cần phải chuyển tiếp gói tin cho hàng xóm đó

Hình 1.16 là một ví dụ về cách xây dựng cây phân phối lưu lượng sử dụng thuật toán RPB với hai trường hợp nguồn là A và C

Trường hợp nguồn là C, gói tin sẽ được chuyển tiếp đến B và E Tại B, có các hàng xóm là A và E, gói tin sẽ được chuyển tiếp đến A mà không phải E vì B nằm trên tuyến đường ngắn nhất từ C đến A

Hình 1.16: Minh họa cây RPB

Thuật toán RPB khá là hiệu quả và dễ dàng thực hiện Nó không yêu cầu router biết về toàn bộ cây mở rộng, và cũng không yêu cầu kỹ thuật đặc biệt để dừng việc chuyển tiếp gói tin (giống như làm trong thuật toán flooding) Hơn nữa, nó đảm bảo việc phân phối hiệu quả vì gói tin multicast luôn luôn đi theo tuyến đường ngắn nhất

từ trạm nguồn tới nhóm đích

Giới hạn chính của thuật toán RPB đó là nó không nắm bắt số lượng thành viên tham gia nhóm multicast khi xây dựng cây phân phối Kết quả là gói tin có thể chuyển tiếp một cách không cần thiết tới các subnet mà không có thành viên vào trong nhóm đích

1.4.1.4 TRPB (Truncated Reverse Path Broadcasting)

Thuật toán TRPB được đề xuất để khắc phục những giới hạn của thuật toán RPB TRPB hoạt động tương tự như RPB, tuy nhiên cùng với sự giúp đỡ của IGMP, các router có thể xác định số lượng thành viên của một nhóm hiện đang tồn tại trên mỗi subnet lá (subnet lá là subnet chỉ kết nối với duy nhất một router) Router sẽ không chuyển tiếp gói tin tới một subnet lá nếu subnet này không tồn tại một thành viên nào của nhóm đích

Hình 1.17 minh họa hoạt động của thuật toán TRPB Trong ví dụ này B là router nguồn sẽ gửi gói tin tới nhóm G1 Đầu tiên gói tin được chuyển tiếp tới router A và D

vì giao diện của router A và D có ít nhất một thành viên của nhóm G1 Gói tin sẽ không được chuyển tiếp tới router C vì giao diện của nó không tồn tại thành viên nào của nhóm G1

Thuật toán TRPB đã loại bỏ được một số giới hạn của RPB, tuy nhiên nó chỉ giải quyết được một phần của vấn đề Nó khử bỏ được lưu lượng không cần thiết trên subnet lá nhưng không xem xét số lượng thành viên của một nhóm khi xây dựng các nhánh của cây phân phối

Hình 1.17: Minh họa thuật toán TRPB

1.4.1.5 RPM (Reverse Path Multicasting)

Đây là thuật toán nâng cao từ các thuật toán RPB và TRPB RPM tạo một cây phân phối mà nối chỉ:

- Các subnet với các thành viên nhóm, và

- Các router và các subnet dọc theo tuyến đường ngắn nhất tới các subnet tồn tại thành viên của nhóm

RPM cho phéo cây phân phối cắt xén bớt vì vậy mà gói tin chỉ chuyển tiếp dọc theo các nhánh mà dẫn tới các thành viên của nhóm đích

Khi một router nhận một gói tin cho một nhóm G, đầu tiên gói tin chuyển tiếp dựa theo thuật toán TRPB tới tất các router trong liên mạng Các router mà kết nối với các subnet lá được gọi là các router lá Thuật toán TRPB đảm bảo rằng mỗi router lá nhận gói tin multicast thứ nhất Nếu có ít nhất một thành viên nhóm G trong trên một subnet

lá, router lá chuyển tiếp gói tin dựa trên thông tin IGMP Nếu không tồn tại thành viên nào của nhóm G trên subnet lá, router của subnet lá đó (router cha) sẽ gửi một bản tin prune (cắt xén) quay ngược trở lại giao diện đã nhận gói tin trước để đó thông báo với router đã chuyển gói tin cho nó (router cha) rằng không cần thiết phải chuyển gói tin dành cho nhóm G tới đây nữa Bản tin prune có giá trị TTL = 1 Router cha nhận bản

tin prune và ghi chép lại thông tin prune trong bộ nhớ Định kỳ, thông tin prune bị xóa

bỏ khỏi bộ nhớ của tất cả các router và gói tin kế tiếp cho nhóm G lại được chuyển tiếp tới tất cả tới tất cả các router lá Kết quả là xuất hiện các bản tin prune mới, cho phép cây phân phối multicast thích nghi với việc thay đổi yêu cầu phân phối lưu lượng multicast của liên mạng

Hình 1.18: Minh họa thuật toán RPM

Vẫn có một số vấn đề cần phải cải biến đối với thuật toán RPM Giới hạn thứ nhất

là các gói tin multicast theo định kỳ phải chuyển tiếp tới tất cả các router trong liên mạng Nhược điểm thứ hai là mỗi router phải duy trì thông tin trạng thai cho tất cả các nhóm và nguồn Thông tin này sẽ khuếch đại khi số lượng nguồn và nhóm trong liên mạng được mở rộng

1.4.1.6 Core-Based Trees

Không giống với các thuật toán trên, CBT tạo một cây phân phối lưu lượng riêng cho mỗi nhóm Nói cách khác, cây được sử dụng cho việc chuyển tiếp gói tin multicast của một nhóm riêng biệt Mỗi một cây riêng không hề để ý tới node nguồn Một router hoặc một tập các router được lựa chọn làm router lõi của một cây phân phối Tất cả các gói tin dành cho một nhóm nào đó sẽ được chuyển tiếp như là một gói tin unicast

G

G

Nguồn S (S, G)

G

Router Subnet lá mà không tồn tại thành viên nào trong nhóm G Subnet lá có tồn ít nhất một thành viên trong nhóm G Nhánh hoạt động

Nhánh đã cắt bỏ Bản tin prune

tới router lõi Sau đó, gói tin được chuyển tiếp tới tất cả các giao diện đóng vai trò một

bộ phận của cây phân phối (ngoại trừ giao diện đã nhận gói tin)

Từ đó, CBT xây dựng chỉ một cây phân phối cho mỗi nhóm multicast Mrouter sẽ không phải lưu trữ quá nhiều thông tin như là các thuật toán khác Mặt khác, CBT không yêu cầu gửi định kỳ gói tin multicast tới tất cả các router trên mạng Điều này giúp gìn giữ băng thông cho mạng

Hình 1.19: Minh họa thuật toán CBT

1.4.2 Các giao thức định tuyến IP Multicast

1.4.2.1 PIM

PIM là một tập hợp các giao thức định tuyến multicast, mỗi giao thức được thiết kế tối ưu cho một môi trường cụ thể Có hai giao thức PIM chính là PIM – Dense Mode, còn gọi là PIM – DM (kiểu tập chung) và PIM Sparse Mode, còn gọi là PIM – SM (kiểu phân tán) Giao thức PIM thứ ba là Bi-directional PIM ít khi được sử dụng Các Mrouter sử dụng PIM để xác định các Mrouter khác cần nhận được gói tin multicast Thông thường, mỗi giao thức PIM – DM hay PIM – SM sẽ được sử dụng trên một miền multicast riêng Tuy nhiên, chúng có thể được sử dụng cùng nhau trong một miền multicast, PIM – DM cho một số nhóm và PIM – SM cho vài nhóm khác Định tuyến với các giao thức PIM độc lập với các cơ chế của các giao thức định tuyến unicast Tuy nhiên, bất kỳ sự triển khai nào hỗ trợ PIM đều yêu cầu sự có mặt của một giao thức định tuyến unicast để cung cấp thông tin bảng định tuyến PIM không gửi

hoặc nhận các cập nhập định tuyến giữa các router như thể giao thức định tuyến unicast truyền thống trên mạng IP: Thay vào việc xây dựng bảng định tuyến multicast riêng biệt, PIM sử dụng thông tin định tuyến unicast để hỗ trợ chức năng chuyển tiếp gói tin Các router hỗ trợ giao thức PIM còn được gọi là các PIM router Các router chạy giao thức PIM chọn một router PIM hàng xóm (thông thường là router có địa chỉ

IP của giao diện kết nối với nó cao nhất) làm router chỉ định

Mac Header IP Header PIM Header Data

0 3 4 7 8 15 16 31 Version Type Reserved Checksum

Tất cả các giao thức PIM đều chung định dạng bản tin điều khiển Hình 1.20 minh họa định dạng của bản tin PIM Chi tiết các trường như sau:

- Trường Version dài 4 bit, phiên bản của PIM

- Trường Type dài 4 bit xác định loại bản tin PIM Có các loại bản tin PIM như sau:

 Hello: Các router gửi bản tin Hello cho các router hàng xóm để khám phá lẫn nhau

 Register: Khi một nguồn lần đầu tiên gửi luồng multicast tới một nhóm, gói tin sẽ được đóng gói trong bản tin Register và gửi tới RP để đăng ký với RP việc luồng lưu lượng sẽ chuyển qua RP

 Register-Stop: Bản tin Register-Stop gửi đến nguồn để thông báo dừng việc đăng ký

 Join/Prune: Router gửi bản tin Join cho router hàng xóm theo đường lên để thông báo nó muốn nhận lưu lượng multicast Nó cũng gửi bản tin Prune khi không muốn nhận lưu lượng multicast nữa

 Bootstrap: Sử dụng để phân phối thông tin RP trong trạng thái ổn định

 Assert: Dùng để ngăn ngừa những nỗ lực vô ích khi có nhiều router kết nối vào cùng mạng LAN (multiaccess) Thay vì gửi nhiều bản sao của những gói multicast vào LAN, bản tin Assert cho phép các router bắt tay thỏa thuận với nhau Router thắng sẽ chịu trách nhiệm chuyển tiếp lưu lượng multicast vào LAN

 Graft (chỉ sử dụng trong PIM – DM): một router gửi bản tin Graft cho router hàng xóm theo đường lên để thông báo rằng nó muốn quay trở lại một nhánh mà trước đó đã bị cắt bỏ khỏi cây phân phối lưu lượng

 Candidate-RP-Advertisement: Quảng bá router tham gia ứng cử RP

 State-Refresh: Yêu cầu cập nhập lại trạng thái của cây phân phối hiện tại

- Trường Checksum dài 16 bit, để kiểm tra lỗi ở tiêu đề

- Trường Data dài 32 bit

a) PIM – Dense Mode

Các PIM router có thể được cấu hình theo kiểu Dense Mode (còn gọi là PIM – DM) nếu các host tham gia vào nhóm multicast nằm ở khắp mọi nơi trên các subnet Địa chỉ multicast nguồn trở thành gốc của cây phân phối, và cây này được xây dựng từ

nguồn đến đích Cơ chế này còn được ký hiệu là (S,G) trong đó đường đi từ nguồn S đến các thành viên trong nhóm G là duy nhất

Giao thức PIM – DM hiệu quả khi máy gửi và nhận là gần nhau, ít máy gửi và nhiều máy nhận, mật độ lưu lượng multicast cao, luồng lưu lượng multicast là không đổi Cây phân phối multicast được xây dựng bằng cách cho phép phát tán lưu lượng multicast từ nguồn đến tất cả các router trong mạng Cây phân phối sẽ phát triển từ trên xuống dưới Trong một thời gian ngắn, lưu lượng không cần thiết sẽ được lưu chuyển giốn như trong truyền thông Broadcast Tuy nhiên, khi các router nhận được luu lượng cho một nhóm, router sẽ quyết định các subnet của nó có máy nào muốn nhận dữ liệu hay không? Nếu muốn, router sẽ duy trì trạng thái im lặng và để luồng lưu lượng multicast tiếp tục truyền Nếu không có host nào đăng ký cho nhóm multicast đó (thông qua IGMP), router sẽ gửi bản tin Prune đến các router hàng xóm theo đường lên Nhánh của cây phân phối sau đó sẽ bị cắt bỏ sao cho các lưu lượng không cần thiết sẽ không được phát tán về hướng đó nữa

PIM – DM sẽ nhận biết các thiết bị hàng xóm bằng cách trao đổi các gói tin Hello Thông tin hàng xóm này sẽ được sử dụng trước để xây dựng cây đến tất cả các hàng xóm Sau đó, các nhánh cây không cần thiết sẽ bị cắt bỏ Khi một luồng multicast bắt đầu, cây sẽ được xây dựng Cây sẽ chỉ tồn tại khi các thành viên tích cực còn tồn tại Nếu một host mới đăng ký tham gia nhóm, nhánh của phân đoạn mạng đó sẽ được đính thêm vào cây

b) PIM – Sparse Mode

Giao thức định tuyến multicast PIM – DM hữu ích khi các ứng dụng multicast là dày đặc và ta cần phân phối lưu lượng đến hầu như toàn bộ mạng Tuy nhiên, nếu chỉ cần phân phối lưu lượng đến một vài subnet, PIM – DM vẫn phát tán lưu lượng trên toàn bộ liên mạng, điều này gây ra lãng phí băng thông và tại nguyên Trường hợp này, PIM – SM có thể được dùng để giảm lãng phí tài nguyên mạng Trong PIM – SM, cây multicast không mở rộng đến router cho đến khi một host đã tham gia vào một nhóm Cây phân phối được xây dựng từ các node lá và mở rộng về phía gốc Hay nói cách khác, cây được xây dựng từ dưới lên Một router yêu cầu được nhận gói tin chỉ khi:

- Router đã nhận được một yêu cầu nhận gói tin từ một vài router hàng xóm

- Có ít nhất một host trên một subnet của router đó đã gửi bản tin Membership Report thông báo muốn tham gia nhóm

SM hoạt động dựa trên ý tưởng cấu trúc cây chia sẻ, trong đó gốc của cây không nhất thiết phải là nguồn multicast Thay vào đó, gốc là các router PIM – SM thường được đặt ở trung tâm của mạng Router làm gốc này gọi là Rendezvous Point (RP) Cây từ RP đến các thành viên thực chất là một cây con của cây từ nguồn đến các thành viên Nếu một router ở bất kỳ đâu trong mạng có thể đăng ký với RP, cấu trúc cây này

sẽ hoàn tất Các luồng multicast được mô tả bởi ký hiệu (*,G) bởi vì cây luôn cho phép bất cứ nguồn nào gửi đến một nhóm

Khi một host tham gia vào một nhóm multicast dùng IGMP, router cục bộ sẽ chuyển các thông điệp Membership Report về gốc của cây multicast Mỗi router dọc theo tuyến đường sẽ thêm nhánh đó vào cây chia sẻ Quá trình loại bỏ nhánh được thực hiện khi tất cả các thành viên của một nhóm rời khỏi nhóm đó

c) PIM Sparse – Dense Mode

PIM có khả năng hỗ trợ của hai chế độ Dense và Sparse vì cả hai tồn tại trên những nhóm multicast khác nhau trên một mạng Cisco cho phép chế độ lai Sparse – Dense Mode cho phép một PIM router sử dụng chế độ Dense hay chế độ Sparse tùy thuộc vào từng nhóm Nếu một nhóm có RP được định nghĩa, Sparse – Mode được sử dụng Còn nếu không, Dense – Mode sẽ được sử dụng

1.4.2.2 DVMRP

DVMRP là một giao thức định tuyến distance-vector được thiết kế để hỗ trợ việc chuyển tiếp lưu lượng multicast qua một liên mạng DVMRP xây dựng cây phân phối lưu lượng sử dụng thuật toán TRPB DVMRP được phát triển từ giao thức định tuyến RIP Sự khác biệt giữa RIP và DVMRP đó là RIP tính toán số lượng hop tới đích, trong khi DVMRP lại tính toán số lượng hop quay trở lại nguồn Khi thiết lập cây phân phối lưu lượng, DVMRP cho phép router phát flooding (tràn ngập) datagram tới tất cả các giao diện trừ giao diện dẫn ngược về nguồn datagram Các router DVMRP phải chạy các quá trình định tuyến riêng cho các gói tin multicast và unicast Để thiết lập cây nguồn, DVMRP sử dụng khái niệm cây broadcast rút gọn TBT (Truncated Broadcast Tree), là cây mở rộng đường đi ngắn nhất từ mạng nguồn tới tất cả các router trong mạng TBT được xây dựng cho tất cả các mạng con nhờ việc cập nhập thông tin định tuyến DVMRP định kỳ giữa các router trong mạng Giống như RIPv2, thông tin cập nhập DVMRP chứa mặt nạ mạng (subnet mask) cùng metric của tuyến đường (tính theo hop count) cho biết cost để tới một subnet cụ thể trong mạng Tuy nhiên, khác với RIPv2, router DVMRP cấp dưới sử dụng quảng bá Roison – Reverse

(PR) để thông báo cho một router cấp trên liên kết này thuộc TBT của mạng nguồn S

PR này được tạo ra bằng cách thêm 32 vào metric được quảng bá và gửi lại về phía router cấp trên

Hình 1.21: Minh họa quá trình thiết lập cây broadcast rút gọn

Xét ví dụ ở hình 1.21, trong mạng đang diễn ra quá trình trao đổi thông tin cập nhập DVMRP cho mạng nguồn S1

Hình 1.22: Cây broadcast rút gọn của mạng nguồn S1 thu được

Router A và B quảng bá metric 1 tới router C và D Với router D, thông báo từ B là đường tốt nhất tới mạng nguồn S1 Router D gửi lại thông báo PR (metric = 33) tới B

Nó thông báo với B rằng router D thuộc TBT của mạng nguồn S1 Với rouer C, nó nhận thông báo từ cả A và B với cùng metric Căn cứ vào địa chỉ IP thấp nhất, router C gửi thông báo PR trở lại router B Bây giờ B biết rằng nó có hai nhánh của TBT: một

Đường tới mạng nguồn có metric „n‟

Thông báo ngược gửi router cấp trên Router phụ thuộc vào cấp trên để nhận lưu lượng từ nguồn

n

tới router C và một tới router D Khi luồng thông tin cập nhập DVMRP qua toàn bộ

mạng, mỗi router gửi thông tin PR tới router cấp trên trong TBT cho mạng nguồn S1

Kết hợp các bản tin PR, thu được S1 TBT như hình vẽ 1.22

Nếu có một nguồn multicast được kích hoạt trong mạng S1, router DVMRP trong

mạng sẽ bắt đầu phát flooding lưu lượng này qua S1 TBT Nếu có một mạng nguồn

khác S2, cần một TBT cho S2 như sau:

Hình 1.23: Cây broadcast rút gọn của mạng nguồn S2 thu được

Ví dụ quá trình flooding và rút gọn:

Nguồn S bắt đầu gửi lưu lượng multicast tới nhóm G Ban đầu lưu lượng được

flooding tới tất cả các rouer trong mạng qua TBT và tới máy thu 1

Hình 1.24: Flooding các gói multicast (S,G) qua TBT

Do router C là node lá trong TBT và không cần nhận lưu lượng, nó gửi bản tin rút

gọn (S,G) DVMRP tới router B Tương tự với router X,Y

của D<C<B<A

Cây broadcast rút gọn S2 Địa chỉ mạng của D<C<B<A

Router B nhận bản tin rút gọn (S,G) và cắt bỏ luồng cảu lưu lượng (S,G) tới router

C Router E nhận bản tin rút gọn từ tất cả router DVMRP lân cận trong subnet, nó bỏ giao diện Ethernet nối với router X và Y Lúc này, tất cả các giao diện luồng xuống của router E trong TBT đã bị loại bỏ và nó không còn nhu cầu nhận lưu lượng Nó gửi bản tin rút gọn (S,G) tới router D trong TBT

Hình 1.25: Minh họa quá trình rút gọn

Router D nhận đươc bản tin này, nó cắt giao diện và lưu tới router E

Hình 1.26: Minh họa trạng thái rút gọn cuối cùng

Tuy nhiên vì DVMRP là giao thức flood và rút gọn, các nhánh được cắt giảm của TBT sẽ timeout và khi lưu lượng được phát flooding theo các nhánh của TBT, lại tiếp

tục quá trình gửi các bản tin rút gọn tới TBT nhằm làm giảm lưu lượng không mong muốn

Các chức năng của router DVMRP:

Khi một router DVMRP khởi tạo, nó tự coi là router chủ cho mạng con nội hạt cho tới khi nhận bản tin Host Membership Query từ router hàng xóm có địa chỉ IP thấp hơn Để tránh nhân bản các gói tin multicast khi có nhiều router DVMRP trong một subnet, thì một router được chọn là router bổ nhiệm cho mạng con nguồn cụ thể

Nếu có nhiều router DVMRP trong các subnet, các router chọn router có địa chỉ IP thấp nhất làm router bổ nhiệm Router này chị trách nhiệm truyền định kỳ bản tin IGMP Host Membership Query

1.4.2.3 MOSPF

Như chúng ta đã biết, OSPF là giao thức định tuyến dạng link-state thường dùng để triển khai trên hệ thống mạng phức tạp OSPF tự xây dựng cơ chế đảm bảo độ tin cậy chứ không sử dụng các giao thức truyền tải như TCP để đảm bảo độ tin cậy OSPF là giao thức định tuyến classless (giao thức định tuyến classless chứa mặt nạ mạng kèm địa chỉ mạng trong các cập nhập định tuyến) nên có hỗ trợ VLSM và các mạng không liên tục (discontiguous network) OSPF sử dụng thuật toán Dijkstra để xây dựng bảng định tuyến Đây là thuật toán xây dựng đường đi ngắn nhất SPT để đi tới đích Bản tin quảng bá LSA mang thông tin của router và trạng thái hàng xóm lân cận Dựa trên các thông tin học được khi trao đổi các bản tin LSA, OSPF sẽ xây dựng topology mạng MOSPF là mở rộng của giao thức định tuyến OSPF và do đó đòi hỏi OSPF như là giao thức định tuyến cơ sở Cùng với unicast OSPF, tất cả các MOSPF router trong cùng một vùng phải có cùng cơ sở dữ liệu liên kết sao cho tất cả các router MOSPF trong một vùng có thể tính toán cùng một thuật toán SPT

 Danh sách các giao diện mà có thành viên trong nhóm

Hình 1.27 minh họa một ví dụ về định tuyến MOSPF nội vùng

Hình1.27: Minh họa định tuyến nội vùng

Ở đây, vùng Area1 có các thành viên của nhóm A,B trong khi vùng Area2 chỉ chứa các thành viên của nhóm A Các router kết nối trực tiếp với các thành viên truyền các LSA thành viên nhóm để thông báo sự tồn tại của các thành viên trong mạng LSA thành viên nhóm không truyền qua giữa các vùng Area1 và Area2 Khi tất cả các router trong một vùng biết vị trí các thành viên nhóm multicast trong các đoạn mạng, chúng có thể sử dụng thuật toán Dijkstra để xây dựng SPT cho bất cứ cặp (nguồn – nhóm) nào Sử dụng các SPT này, router có thể thực hiện các thuật toán SPF (bao gồm RPB, TRPB, RPM) để kiểm tra xem, khi gói tin multicast đến một giao diện, các giao diện còn lại của router có nằm trên cây phân phối lưu lượng không? Nếu có, router sẽ chuyển tiếp bản sao của gói tin ra bên ngoài giao diện nằm trên cây phân phối

Trong ví dụ trên, nguồn nằm trên vùng Area1 bắt đầu gửi lưu lượng multicast ( tới nhóm B Khi dữ liệu tới router trong vùng, nó thực hiện tính toán Dijkstra

và xây dựng cây phân phối lưu lượng cho Cây này nối tới tất cả các thành viên nhóm B và sử dụng để chuyển tiếp lưu lượng multicast cho nhóm B Trong vùng Area2, nguồn bắt đầu gửi lưu lượng multicast ( tới nhóm A Router trong vùng Area2 sử dụng thông tin thành viên nhóm trong cơ sử dữ liệu MOSPF để thực

Area0

MOSPF Router Thành viên nhóm Nguồn

hiện tính toán và xây dựng cây phân phối lưu lượng cho Lưu lượng ( được chuyển tiếp như hình vẽ

b) Định tuyến liên vùng

Trong MOSPF, các Mrouter kết nối hai vùng tới vùng backbone được gọi là các router biên MABR Các router này chịu trách nhiệm chuyển tiếp các thông tin định tuyến và lưu lượng multicast giữa các vùng Các router trong vùng backbone phải biết được sự tồn tại của các thành viên trong các vùng khác Để tạo điều kiện thuận lợi cho việc này, các MABR tóm lược các thông tin LSA thành viên nhóm trong vùng kết nối với vùng backbone thành thông tin LSA thành viên tóm lược LAS (Summary Membership LSA) và phát flood vào trong vùng backbone Để truyền lưu lượng multicast giữa các vùng, các MABR sử dụng một cờ “Wildcard Receiver” (được đặt là bit W, có nghĩa là wildcard) trong trường “rtype” của gói tin router LSA Bit W chỉ ra rằng router quảng bá mong muốn nhận được tất cả lưu lượng multicast Và bởi vậy, bản thân MABR là một máy thu wildcard

Hình 1.28 : Minh họa thiết lập đường truyền liên vùng

Hình 1.28 minh họa quá trình tóm lược các thông tin thành viên nhóm LSA và phát flood vào trong vùng backbone Trong ví dụ này, Area1 gồm một thành viên nhóm A

và hai thành viên nhóm B Các thông tin thành viên nhóm này được tóm lược bởi

Area0

MOSPF Router Thành viên nhóm Nguồn

Cờ máy thu wildcard LSA thành viên tóm lược