TCVN9802-5:2017

Tiêu chuẩn quốc gia TCVN 9802-5:2017 về Giao thức Internet phiên bản 6 (IPv6) - Phần 5: Giao thức phát hiện đối tượng nghe multicast TIÊU CHUẨN VIỆT NAM TCVN 9802-5:2017 GIAO THỨC INTERNET PHIÊN BẢN 6 (IPV6) - PHẦN 5: GIAO THỨC PHÁT HIỆN ĐỐI TƯỢNG NGHE MULTICAST Internet protocol version 6 (IPv6) - Part 5: Multicast listener discovery protocol Lời nói đầu TCVN 9802-5:2017 được xây dựng trên cơ sở RFC 3810 (2004) “Multicast Listener Discover y Version 2 (MLDv2) for I Pv6 ” của Nhóm đặc trách về kỹ thuật Internet (IETF). TCVN 9802-5:2017 do Viện Khoa học Kỹ thuật Bưu điện, Học viện Công nghệ Bưu chính Viễn thông biên soạn, Bộ Thông tin và Truyền thông đề ngh ị , Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố. GIAO THỨC INTERNET PHIÊN BẢN 6 (IPV6) - PHẦN 5: GIAO THỨC PHÁT HIỆN ĐỐI TƯỢNG NGHE MULTICAST Internet protocol version 6 (IPv6) - Part 5: Multicast listener discovery protocol 1 Phạm vi áp dụng Ti ê u chuẩn này quy định những đặc tả kỹ thuật của giao thức phát hiện đối tượng nghe multicast phiên bản 2 (MLDv2) cho IPv6. T iê u chu ẩ n này áp dụng cho các thiết bị nút IPv6 (gọi tắt là nút hoặc nút IPv6) yêu cầu hỗ trợ multicast theo chính sách lọc nguồ n , tức l à các nút có nhu cầu nghe các gói tin theo một địa chỉ multicast ch ỉ từ những địa chỉ nguồn cụ thể hay từ tất cả các nguồn khác trừ những địa chỉ nguồn cụ thể. 2 Tài liệu viện dẫn Các tài liệu viện dẫn sau là cần thiết cho việc áp dụng tiêu chuẩn này. Đ ối với các tài liệu viện dẫn ghi năm công bố th ì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm c ô ng bố thì áp dụng phiên bản mới nhất, bao g ồ m cả các sửa đổi (nếu có). TCVN 9802-1:2013, Giao thức Internet phiên bản 6 (IPv6) - Phần 1: Quy định kỹ thuật. TCVN 9802-2:2015, Giao thức Internet phiên bản 6 (IPv6) - Ph ầ n 2: Kiến trúc địa chỉ IPv6. TCVN 9802-3:2015, Giao thức Internet phiên bản 6 (IPv6) - Phần 3: Giao thức phát hiện nút mạng lân cận. RFC 4443, Internet Control Message Protocol (ICMPv 6 ) for t he Internet Protocol Vers i on 6 (IPv6) spe cifi cation, March 2006 (G i ao thức bản t i n đ iề u khiển Internet cho IPv6) . RFC 2711, IPv6 Router Alert Option, October 1999 (T ùy chọn cảnh báo Router lPv6) . RFC 2462, IPv6 Stateless A dd ress Autoconfiguration , December 1998 (Tự động c ấ u hình địa chỉ IPv6 phi trạng th á i) . RFC 2464, Transmission of IPv6 Packets over Ethernet Networks, December 1998 (Truy ề n c á c gói tin IPv6 qua mọng E thern et) . 3 Thuật ngữ và định nghĩa Tiêu chuẩn này sử dụng các thuật ngữ sau đây. 3.1 Nút (node) Th iết b ị thực thi IPv6. 3.2 Bộ định tuyến (router) Nút có khả năng chuyển tiếp các gói tin IPv6 không được định địa chỉ trực tiếp cho nút mạng đó. 3.3 Host Bất kỳ nút nào mà không phải là router. 3.4 Tầng trên (upper layer) Tầng giao thức ngay phía trên IPv6. Ví dụ, các giao thức truyền tải như TCP và UDP, giao thức điều khiển ICMP, giao thức định tuyến như OSPF và các giao thức Internet hoặc giao thức tầng thấp hơn thực thi kết n ố i kiểu đường hầm thông qua IPv6 như IPX, AppleTalk, hoặc chính IPv6. 3.5 Liên kết (link) M ộ t phương tiện hoặc môi trường kết nối mà qua đó các nút mạng có thể kết nối với nhau tại tầng liên kết, nghĩa là tầng ngay b ê n dưới IPv6 như Ethernet; các liên kết PPP; X.25, Frame Relay hoặc các mạng ATM; và tầng Internet (hoặc tầng cao hơn) thực thi kết nối “đường hầm” như các đường hầm qua IPv4 hoặc IPv6. 3.6 Giao d iện (interface) Một giao tiếp của nút để gắn vào liên kết. 3.7 Địa chỉ (address) Một định danh tầng I Pv6 cho một giao diện hoặc một nhóm giao diện. 3.8 Gói tin (packet) Ph ầ n mào đầu IPv6 cộng với phần dữ liệu của gói tin. 3.9 Thiết b ị truy vấn (Querier) Các router có thể gửi đi các bản tin Query. 3.10 Thiết bị không truy vấn (Non-Querier) Rouler không có chức năng gửi đi các bản tin Query. 3.11 S ocket Tham số cụ thể được sử dụng để phân biệt giữa các thực thể gửi yêu cầu IP multicast khác nhau (ví dụ, các chương trình, các ứng dụng) trong các nút. 3.12 Địa chỉ link-layer (link-layer address) Định danh tầng liên kết cho một giao diện. Ví dụ, bao gồm những địa chỉ IEEE 802 cho các liên kết Ethernet. 3.13 Địa chỉ link-local (link-local address) Một địa chỉ unicast ch ỉ ở trong phạm vi liên kết mới có thể được sử dụng đ ể hướng tới những nút mạng lân cận. Tất c ả giao diện trên router phải có một địa chỉ link-local. Và giao diện trên các host phải có một địa chỉ link-local. 3.14 Địa chỉ on-link (on-link) Một địa chỉ được gán cho một giao diện trên một liên kết cụ thể. Một nút mạng xem một địa chỉ là địa chỉ on-link nếu: - Địa chỉ đó được bao hàm bởi một trong các tiền tố cửa liê n kết (chẳng hạn đã được chỉ thị bởi cờ on-link trong tùy chọn Pre f ix Information), hoặc - Một router lân cận xác định địa chỉ đó là đích đến của bản tin Redirect, hoặc - Nhận được một bản tin Neighbor Advertisement cho địa chỉ (mục tiêu) đó, hoặc - Nhận được bất kỳ một bản tin Neighbor Discovery từ địa chỉ đó. 3.15 Địa chỉ off-link (off-link) Ngược lại với địa chỉ “on-link”; là địa chỉ mà không được gán cho bất kỳ giao diện nào trên một liên kết cụ thể. 4 Chữ viết tắt DAD ICMPv6 IPv6 LLQC LLQ I LLQT MLD MLDv 1 MLDv2 MALI QQI QQIC OSPF TCP UDP Phát hiện địa chỉ trùng lặp Giao thức bản tin điều khiển cho IPv6 Giao thức Internet phiên bản 6 Số lượng truy vấn đối tượng nghe cuố i cùng Khoảng thời gian truy vấn đối tượng nghe cuối c ù ng Thời gian truy vấn đối tượng nghe cuối cùng Phát hiện đối tượng ngh e multicast Phát hiện đối tượng nghe multicast phiên bản 1 Phát hiện đối tượng nghe multicast p hiê n bản 2 Khoảng thời gian nghe địa chỉ multicast Kho ả ng thời gian truy vấn của Querier Mã khoảng thời gian truy vấn của Querier Querier Giao thức định tuyến tìm đường ngắn nhất Giao thức điều khiển truyền dẫn Giao thức dữ liệu người dùng Duplicate Address Detection Internet Control Message Protocol vers i on 6 Internet Protocol version 6 Last Listener Qu er y Count Last Listener Que r y Interval Last Listener Query Time Multicast L i stener Discovery Multicast Listener Discovery version 1 Multicast Listener Discovery version 2 Multicast Address Listening Interval Querier Query Interval Querier Query Interval Code Open Shortest Path First Transm i ssion Control Protocol User Datagram Protocol 5 Tổng quan Giao thức MLD nói chung (bao gồm cả MLDv1 và MLDv2) là giao thức bất đối xứng, vì giao thức này quy định cách xử lý riêng biệt cho các đối tượng nghe địa chỉ multicast (tức là các host và router nghe các gói tin multicast) và các router multicast. Mục đích của MLD là cho phép router multicast xác định những địa chỉ multicast và những ngư ồ n có đối tượng nghe quan tâm đến các địa chỉ và nguồn này trên mỗi liên k ế t trực tiếp của router. Thông tin thu thập bởi MLD được cung cấp cho giao thức định tuy ế n multicast của router, để đảm bảo rằng các gói tin multicast được phân phối đến tất cả các liên kết có đối tượng nghe quan tâm đến những gói tin này. Các router multicast chỉ cần biết tối thiểu một nút trên liê n kết kết nố i vào nó đang nghe các gói tin theo một địa chỉ multicast cụ thể, từ một nguồn cụ thể; một router multicast không yêu cầu phải theo dõi các nhu cầu của từng nút lân cận một cách riêng lẻ. Với giao thức MLDv2, router multicast thực hiện vai trò router trên mỗi liên kết trực tiếp. Nếu một router multicast có nhiều giao diện được kết nối vào cùng một liên kết, router đó chỉ cần thực hiện giao thức MLDv2 trên một trong các giao diện đó. Cách xử lý của router phụ thuộc vào việc có hay không những router multicast khác trên cùng mạng con. Nếu có nhiều router multicast tr ê n mạng con th ì sử dụng cơ chế bầu chọn Querier đ ể lựa chọn một router multicast duy nhất đóng vai tr ò là Querier. Tất cả các router mu l ticast trong mạng con lắng nghe các bản tin được gử i từ đối tượng nghe địa chỉ multicast và duy trì cùng trạng thái về thông tin nghe multicast. Điều này đ ể các router này có thể đảm nhiệm vai trò Querier trong trường hợp Querier hiện tại xảy ra lỗi. Tuy nhi ê n, chỉ duy nhất một Querier gửi định kỳ hoặc kích hoạt các bản tin Query trong mạng con, như được mô tả trong điều 10.1. Một đối tượng nghe địa chỉ multicast thực hiện vai trò đối tượng nghe trong giao thức MLDv2 trên tất cả các giao diện hỗ trợ multicast, ngay cả khi có nhiều giao diện trong số các giao diện này được kết nối vào cùng một liên kết. 5.1 Thiết lập trạng thái nghe multicast trên các đối tượng nghe địa chỉ multicast Các giao thức tầng trên và các ứng dụng chạy trên nút nghe địa chỉ multicast sử dụng các lời gọi giao diện dịch vụ xác định để yêu cầu t ầ ng IP cho phép hoặc vô hiệu hóa chức năng tiếp nhận các gói tin được gửi đến các địa chỉ multicast cụ thể. Nút giữ trạng thái nghe địa chỉ multicast cho từng socket mà tại đó có các l ời gọi giao diện dịch vụ. Ngoài trạng thái nghe multicast theo từng socket này, một nút cũng phải duy trì và tính toán trạng thái nghe multicast cho từng giao diện của nó. Trạng thái này bao gồm tập hợp các bản ghi, với mỗi bản ghi chứa một địa chỉ multicast IPv6, mộ t chế độ lọc và một danh sách nguồn. Chế độ lọc có thể l à INCLUDE hoặc EXCLUDE. Trong chế độ INCLUDE, nút chỉ có thể nhận các gói tin có đ ịa chỉ nguồn nằm trong danh sách nguồn gửi tới một đ ịa chỉ multicast cụ thể. Trong chế độ EXCLU D E, thì nút chỉ nhận được, các gói tin có địa chỉ nguồn nằm ngoài danh sách nguồn gửi tới địa chỉ mult i cast cụ thể. Đối với một giao diện cho trước, tồn tại nhiều nh ấ t một bản ghi ch o m ỗ i địa chỉ multicast. Trạng thái từng giao diện này nhận được từ trạng thái t ừ ng s ocket, nhưng có thể khác với trạng thái từng s ocket v ì các socket khác nhau có sự khác biệt về các chế độ lọc và/hoặc các danh sách nguồn cho cùng địa chỉ multicast và giao diện. Sau khi gói tin multicast được chấp nhận, việc phân phối gói tin này tới ứng dụng phụ thuộc vào trạng thái nghe multicast của s ocket m à ứng dụng đó đã kết nối (và có thể cũng phụ thuộc vào các điều kiện khác như cổng nào của tầng truyền tải mà s ocket sử dụng). Chú ý rằng các bản tin MLDv2 không phụ thuộc vào việc lọc nguồn và phải luôn được xử lý bởi các host và router. 5.2 Trao đ ổ i các bản tin giữa Querier và các nút nghe Có ba loại bản tin Query MLDv2: bản tin General Query (truy vấn thông thường), bản tin Multicast Address Spec ifi c Query (truy vấn địa chỉ multicast cụ thể) và bản tin Multicast Address and Source Speci f ic Query (truy vấn địa chỉ multicast và nguồn cụ thể). Các Quer i er định kỳ gử i đi các bản tin General Query để nắm bắt các th ô ng tin về đối tượng nghe địa chỉ multicast từ một liên kết được kết nối. Các bản tin General Query này được sử dụng để xây dựng và làm mới trạng thái của đối tượng nghe địa chỉ multicast bên trong tất cả các router multicast trên liên kết. Các nút ph ả n hồi các bản tin General Query này bằng cách báo cáo lại trạng thái nghe địa chỉ multicast từng giao diện của chúng, thông qua các bản tin Current State Report (báo cáo trạng thái hiện tại) được gửi đến một địa chỉ multicast cụ thể mà tất cả các router trên liên kết đều lắng nghe. Mặt khác, nếu trạng thái nghe của một nút thay đổi, nút n à y ngay lập tứ c thông báo những thay đổi này thông qua một bản tin State Change Report (báo cáo thay đổi trạng thái). Bản tin State Change Report chứa các Filter Mode Change Record (bản gh i thay đổi chế độ lọc) hoặc các Source List Change Record (bản ghi t hay đổi d anh sách nguồn) hay các bản ghi của cả loại loại trên. Mô tả chi tiết của các bản tin Report được t rình bày ở điều 8.2.12. Những thay đổi trạng thái của cả router và đối tượng nghe đều được thiết lập khi một bộ đếm thời gian cụ thể kết th ú c, hoặc khi nhận được một bản tin MLD (sự thay đổi trạng thái đối tượng nghe có thể được kích hoạt bằng việc yêu cầu một lời gọ i giao diện dịch vụ). Do đó, để nâng cao tính ổn định của giao thức, để tránh sự không đáng tin cậy có thể có của việc trao đổi gói tin, các bản tin sẽ được truyền lại nhiều lần, Hơn nữa, các bộ đếm thời gian được thiết lập đ ể kiểm tra việc mất mát bản tin có thể có, và để đợi việc truyền l ại. Để tránh quá tải liên kết, các bản tin General Que r y và Current State Report theo đ ị nh kỳ không áp dụng quy tắc này, gi ả định rằng thông thường các bản tin này không tạo ra sự thay đổi trạng thái và mục đích ch í nh của chúng l à làm mới trạng thái đang tồn tại. Do đó, ngay cả khi một bản tin như vậy bị mất, trạng thái tương ứng sẽ được làm mới trong chu kỳ báo cáo tiếp theo. Trái với các bản tin Current State Report, các bản tin State Change Report được truyền l ại vài l ầ n, để tránh chúng b ị mất tại một hoặc nhiều router multicast. Số lượng của bản tin truyền lạ i phụ thuộc vào biến Robustness. Biến này cho phép điều chỉnh giao thức theo sự mất mát gói tin dự kiến tr ê n một li ên kết. Nếu một liên kết được dự k iến là m ấ t gó i (ví dụ như kết nối không dây), giá trị của b iế n Robustness sẽ được t ă ng lên. MLD là ổn định với [biến Robustness] -1 gói tin bị m ấ t. Tiêu chuẩn này khuyến nghị giá trị mặc định của biến Robustness là 2 (chi tiết được tr ì nh bày trong điều 12). CHÚ TH Í CH: Tên các bộ đếm/biến nằm trong dấu ngoặc vuông thể hiện g i á tr ị của các bộ đ ế m/b iế n này. Nếu xảy ra nhiều sự thay đổi tới cùng một bảng lưu trữ trạng thái từng giao diện trước khi hoàn thành việc truyền lại tất cả các bản tin State Change Report cho thay đổi đầu t iê n, th ì mỗi sự thay đổi bổ sung s ẽ kích hoạt việc truyền lại một bản tin State Change Report mới ngay lập tức. Điều 9.1 tr ì nh bày phương pháp tính toán nội dung của bản t i n mớ i này. Những bản tin State Change Report truyền lại mới sẽ được lập lịch, để đảm bảo rằng mỗi một sự thay đổi trạng thái sẽ được truyền tối thi ể u [biến Robustness ] lần. Nếu qua bản tin State Change Report, một nút trên một liên kết thể hiện việc không còn muốn l ắ ng nghe một địa chỉ multicast (hoặc một nguồn) cụ thể nữa, Quer i er phải tr uy vấn các đ ối t ượng nghe khác của địa chỉ multicast (hoặc nguồn) này trước khi xóa địa chỉ multicast (hoặc nguồn) ra khỏi mục lưu trữ trạng thái đối tượng nghe địa chỉ multicast và dừng truyền lưu tượng tương ứng. Như vậy, Querier gửi một bản tin Multicast Address Speci f ic Query đ ể xác minh rằng các nút vẫn đang lắng nghe địa chỉ mu lt icast cụ thể này hay không. Tương tự, Querier gửi một bản tin Multicast Address and Source Specific Query để xác minh rằng, với một địa chỉ multicast cụ thể, c ó nút nào vẫn đang nghe theo một bộ các nguồn cụ thể hay không. Điều 8.1.13 mô tả chi tiết từng loại bản tin Query này. Cả hai bản tin “Multicast Address Specific Query” và “Multicast Address and Source Specific Query” chỉ được g ử i để đáp lại các bản tin State Change Report mà không đáp lại các bản tin Current State Report. Sự khác biệt giữa ha i loại bản tin Rep o rt này nhằm t ránh cho router đối xử với tất cả các bản tin Multicast Listener Report như những thay đổi trạng thái có khả năng xảy ra. B ằ ng cách này, cơ chế rời đi nhanh của MLDv2 có thể không hiệu quả nếu bản tin State Change Report b ị mất, và router ch ỉ nhận được b ả n tin Current State Report. Tuy nhiên, nó tránh được việc xử lý gia t ăng ở router và giảm lưu lượng MLD trên liên k ết. Các nút phản hồi các bản tin Query ở trên qua bản t i n Current State Report, chứa trạng thái Nghe Địa C hỉ Multicast (Multicast Address Listening) cho từng giao diện của chúng chỉ với các địa chỉ multicast (hoặc nguồn) được truy vấn. Đ ể đảm bảo tính ổ n định của giao thức, tất cả các bản tin Query ngoại trừ các bản tin General Query theo định kỳ, đều được gửi lại vài lần trong một khoảng thời gian nhất định, số lượng bản tin truyền lại phụ th uộc vào biến Robustness. Nếu trong khi l ập lịch cho bản tin Query mới, tồn tại các bản tin Query đang ở trạng thái chờ được truyền lại cho cùng địa chỉ multicast, thì các bản t i n Query mới và các bản tin Query đang ở trạng thái chờ phải được sáp nhập. Ngo à i ra, các b ả n tin Report về host nhận được đối với một địa chỉ multicast có các bản tin Query đang ở trạng thái chờ có thể ảnh hưởng tới nội dung của các bản tin Query đó. Tính ổn định của giao thức cũng được nâng cao bằng việc sử dụng cờ S (Ngăn chặn xử lý phía router). Như đã mô tả ở trên, khi Querier gửi đi một bản tin Multicast A ddress Specific Query hoặc bản tin Multicast Address and Source Specific Query, sẽ có những bản tin Query được lập l ị ch đ ể truyền lại. Trong bản tin Query đầu tiên, cờ S được xóa. Khi Querier gửi bản tin Query này, nó làm gi ả m bộ đếm thời gian cho địa chỉ multicast (hoặc nguồn) có liên quan thành một giá trị cho trước; tương tự, bất kỳ router multicast non-querier nào nhận được truy v ấ n cũng tự hạ thấp bộ đếm thời gian của mình thành giá tr ị tr ê n. Tuy nhiên, trong khi đợi các bản tin Query được lập lịch tiếp t heo được gửi, router có thể nhận được một bản tin Report cập nhật bộ đếm thời gian. Các bản tin Query được lập lịch vẫn ph ả i được gửi đ ể đ ả m bảo rằng router non-querier vẫn giữ trạng thái của nó đồng bộ với Querier hiện tại (do router non-querier có thể kh ô ng nhận được truy vấn đầu tiên). Tuy nhiên, bộ đếm thời gian không nên được hạ thấp lần nữa. Do đó, Querier thiết lập giá trị cờ S trong các bản tin Query tiếp theo. 5.3 Thiết lập trạng thái đối tượng nghe đ ịa chỉ multicast trên router multicast Các router multicast thực thi MLDv2 (có thể là Querier hoặc không) giữ trạng thái đối tượng nghe cho từng đ ịa chỉ multicast đối với mỗ i liên kết. Trạng thái đối tượng nghe địa chỉ multicast này bao gồm một chế độ lọc, một bộ đếm thời gian cho chế độ lọc, và một danh sách nguồn, với bộ đếm thời gian cho t ừng nguồn trong danh sách. Chế độ lọc được sử dụng để thu gọn trạng thái lắng nghe toàn diện cho một địa multicast thành một tập b é nhất, t ất cả các nút đang ở trạng t hái lắng nghe đều được chú ý. Chế độ lọc có thể thay đổi để phù hợp với việc nhận từng loại bản tin Report cụ thể, hoặc khi điều kiện bộ đếm thời gian nào đó xu ấ t hiện. Một router có chế độ lọc là “INCLUDE” (chế độ bao gồm) đối với một địa chỉ mult i cast cụ thể trên một giao diện nhất định nếu tất c ả các đối tượng nghe trên liên kết đang theo dõi đ ịa chỉ đó ở trong chế độ INCLUDE. Trạng thái router được thể hiện bằng INCLUDE (A), trong đó A là danh sách các nguồn, được gọi l à “Danh sách INCLUDE” ( danh sách bao gồm). Danh sách INCLUDE là một tập hợp các nguồn mà một hay nhiều đối tượng nghe tr ê n liên kết có yêu cầu nhận. Tất cả các nguồn từ danh sách INCLUDE sẽ được router chuyển tiếp. Bất kỳ nguồn nào khác không nằm trong danh sách INCLUDE sẽ bị router chặn lại. Một nguồn có thể được thêm vào danh sách INCLUDE hiện tại nếu một đối tượng nghe có chế độ INCLUDE gửi một bản tin Current State Report hoặc bản tin State Change Report chứa nguồn đó. M ột nguồn trong danh sách INCLUDE được liên kết với một bộ đếm thời gian cho nguồn, bộ đếm này được cập nhật bất cứ khi nào một đối tượng nghe trong chế độ INCLUDE gửi đi bản tin Report xác nhận đối tượng nghe này vẫn đang quan tâm đến nguồn cụ thể đó. Nếu bộ đếm thời gian cho một nguồn trong danh sách INCLUDE kết thúc, nguồn này sẽ bị xóa khỏi danh sách INCLUDE. Bên cạnh cơ chế “rời nhóm mềm” ở trên, cũng còn một cơ chế “ rời nhóm nhanh” trong MLDv2; cơ chế này cũng dựa trên việc sử dụng các bộ đếm thời gian cho nguồn. Khi một nút trong chế độ INCLUDE không còn nhu cầu theo dõi một nguồn cụ thể, các router multicast trên liên kết hạ thấp bộ đếm thời gian của chúng cho nguồn đó xuống một giá trị nhất định. Quer i er sau đó gửi một bản tin Multicast Address and Source S pecific Query, để xác minh rằng có đối tượng nghe nào khác đang theo dõi nguồn đó hay không. Nếu nhận được một bản tin Report cho nguồn này trước khi bộ đếm thời gian kết thúc, th ì tất cả các router trên liên kết số cập nhật bộ đếm thời gian cho nguồn. Nếu không, nguồn s ẽ bị xóa khỏi danh sách INCLUDE. Việc xử lý danh sách INCLUDE theo các bản tin Report nhận được, được ch i tiết t rong điều 10.4.1 và 10.4.2. Một router sẽ có chế độ EXCLUDE (chế độ ngoại trừ) đối với một địa chỉ multicast cụ thể trên một giao diện nhất đ ị nh nếu có tối thiểu một đối tượng nghe trong chế độ EXCLUDE cho địa chỉ đó trên liên kết. Khi nhận được bản tin Report đầu tiên từ đối tượng nghe này, router sẽ thiết lập bộ đếm thời gian cho chế độ lọc tương ứng với địa chỉ đó. Bộ đếm thời gian này được thiết lập lại mỗi khi đối tượng nghe trong chế độ EXCLUDE xác nhận trạng thái nghe của nó qua bản tin Current State Report. Bộ đếm thời gian này cũng được cập nhật khi một đối tượng nghe ở trong chế độ INCLUDE, thông báo th a y đổi chế độ l ọc của nó qua bản tin State Change Report. Bộ đếm thời gian cho chế độ lọc kết thúc đồng nghĩa với việc không còn đối tượng nghe nào nữa ở trong chế độ EXCLUDE trên liên kết. Trong trường hợp này, router chuyển về chế độ INCLUDE cho đ ịa chỉ multicast trên. Khi router ở trong chế độ EXCLUDE, trạng thái của router được thể hiện bằng EXCLUDE (X, Y), trong đó X được gọi là “Danh sách được yêu cầu” và Y được gọi là “ Danh sách EXCLUDE ” ( danh sách ngoại trừ). T ấ t cả các gói tin từ các nguồn nằm ngoài danh sách EXCLUDE, sẽ được chuyển tiếp bởi router. Danh sách được yêu cầu không gây ả nh hưởng gì đến việc chuyển tiếp. Tuy nhiên, router phải duy tr ì danh sách được yêu cầu vì hai lý do sau đây: - Đ ể theo dõi các nguồn mà đối tượng nghe trong chế độ INCLUDE đang lắng nghe. Đi ề u này nhằm đảm bảo một sự chuyển đổi liền mạch của router sang chế độ INCLUDE, khi không còn đối tượng nghe nào trong chế độ EXCLUDE nữa. Sự chuyển đ ổ i này sẽ không làm ngắt qu ã ng lưu lượng tới các đối tượng nghe trong chế độ INCLUDE cho địa chỉ multicast đó. Do đó, ở thời điểm chuyển đổi, danh sách được yêu cầu nên chứa tập hợp các nguồn m à các nút trong ch ế độ INCLUDE yêu cầu rõ ràng, Khi router c huy ể n sang chế độ INCLUDE, các nguồn trong danh sách được yêu cầu sẽ chuy ể n sang danh sách INCLUDE, và danh sách EXCLUDE được xóa bỏ. Trước khi thực hiện việc chuy ể n tiếp n à y, danh sách được yêu cầu có thể chứa một dự đoán không chính xác về những nguồn mà các đối tượng nghe trong chế độ INCLUDE đang lắng nghe - có thể quá lớn hoặc quá nhỏ. Sự không chính xác này là do danh sách được yêu cầu có thể được sử dụng cho mục đích khóa nhanh s ẽ được mô tả dưới đây. Nếu chức năng khóa nhanh được thực hiện, vài nguồn có thể bị xóa kh ỏ i danh sách được y ê u cầu để giảm trạng thái router. Tuy nhiên, trong trường hợp đó bộ đếm thời gian cho chế độ l ọc cũng được cập nhật. Do đó, trước khi thực hiện chuyển đổ i , các đối tượng nghe trong chế độ INCLUDE sẽ có đủ thời gian để xác nhận lại sự quan tâm của chúng với nguồn bị loại bỏ, và xây dựng lại danh sách đư ợ c yêu cầu cho phù hợp. Giao thức đảm bảo rằng khi xảy ra chuyển đổ i sang chế độ INCLUDE th ì danh sách được yêu cầu là chính xác. Ch i tiết về việc chuy ể n đổi của router sang chế độ INCLUDE được mô tả trong điều A.3, Phụ lục A. - Để cho phép chế độ khóa nhanh các nguồn không được khóa trước đây. Nếu router nhận được bản tin Report chứa một yêu cầu như vậy, các nguồn có l iê n quan sẽ được thêm vào danh sách được yêu cầu. Bộ đếm thời gian của chúng sẽ được thiết lập về một giá trị nh ỏ nhất định, và một bản tin Multicast Address and Source Spec ific Query được gửi bởi Querier đ ể kiểm tra c ó n ú t nào trên liên kết vẫn còn quan tâm đến những nguồn đó nữa không. Nếu không nút nào thông báo mối quan tâm của chúng đến những nguồn cụ thể đó, bộ đếm thời gian của những nguồn này sẽ kết thúc. Sau đó, các nguồn này được chuy ể n từ danh sách được yêu cầu sang d anh sách EXCLUDE. Từ thời điểm này, các nguồn trên sẽ bị router chặn lại. Việc xử lý trạng thái router trong chế độ EXCLUDE theo các bản tin Report nhận được, được ch i tiết trong Bảng 10.4.1 và 10.4.2. Các xử l ý của cả router và đối tượng ngh e MLDv2 được mô tả trong tiêu chuẩn này đều đảm bảo tính t ương thích ngược với các host và router MLDv1. Tính tương thích này được chi tiết trong điều 11. 6 Giao diện dịch vụ cho việc yêu cầu nhận IP Multicast Trong hệ thống IP, một giao diện dịch vụ được sử dụng bởi các giao thức tầng trên hoặc các chương trình ứng dụng để yêu cầu tầng IP cho phép hoặc vô hiệu hóa khả năng tiếp nhận các gói tin được gửi tới những địa chỉ IP multicast cụ thể. Để tận d ụng đầy đ ủ những tính năng của MLDv2, giao diện dịch vụ IP của n ú t phải hỗ trợ hoạt động sau đây: IPv 6 MulticastListen (socket, giao diện, địa chỉ multicast IPv6, chế độ lọc, danh sách ng uồ n) Trong đó: - “ S ocket” l à một tham số cụ thể được sử dụng để phân biệt giữa các thực th ể gửi yêu cầu khác nhau (ví dụ, các chương trình, các quy trình) trong các nút; tham số socket c ủ a các cuộc gọi hệ thống Unix BSD là một ví dụ cụ thể. - “Giao diện” là một bộ định danh cục bộ của giao diện mạng trên đó việc nhận địa chỉ multicast cụ thể được cho phép hoặc vô hiệu hóa. Các giao diện có thể là vật lý (ví dụ giao diện Ethernet) hoặc ảo (ví dụ điểm kết thúc của chuyển mạch kênh ảo Frame Relay hoặc một đư ờ ng hầm IP- trong-IP). Trong trường hợp việc triển khai được cho phép thông qua một tham số giao diện “không rõ ràng ” đặc biệt, yêu cầu s ẽ được áp dụng trên giao diện “chính” hoặc “giao diện mặc định” của nút (có thể được xác định bởi cấu hình hệ thống). Nếu thực hiện việc tiếp nhận cùng một địa chỉ multicast trên nhiều giao diện, IPv6MultlcastListen sẽ được yêu cầu một cách riêng biệt cho từng giao diện mong muốn. - “Địa chỉ multicast IPv6” là một địa chỉ multicast gắn với các yêu cầu. Nếu có yêu cầu tiếp nhận nhiều địa chỉ mu l ticast trên một giao diện cụ thể, thì IPv6MulticastLinten s ẽ được thực hiện một cách riêng biệt cho từng địa chỉ mong muốn. - “Chế độ lọc” có thể là INCLUDE hoặc EXCLUDE. Trong chế độ INCLUDE, chỉ các gói tin có địa chỉ nguồn được liệt kê trong danh sách địa chỉ nguồn mới có thể gửi đến một địa chỉ multicast cụ thể. Trong chế độ EXCLUDE, chỉ các gói tin có địa chỉ nguồn nằm ngo à i danh sách địa chỉ nguồn mới có thể gửi đến một địa chỉ mul ti cast cụ thể. - “Danh sách nguồn” là một danh sách không theo th ứ tự (danh sách này có thể không chứa nguồn nào) chứa những địa chỉ mà từ đ ó việc tiếp nhận multicast được yêu cầu hoặc từ chối, phụ t huộc vào chế độ lọc. Việc thực thi có thể gặp phải một số hạn chế về kích thước của danh sách nguồn. Khi giới hạn danh sách nguồn bị vượt quá, giao diện dịch vụ có thể gặp lỗi. Với một tập hợp socket, giao diện, và địa chỉ multicast I Pv6 nhất định, chỉ duy nhất một chế độ lọc và danh sách nguồn có thể có hiệu lực tại một thời điểm. Tuy nhiên, hoặ c chế độ lọc hoặc danh sách nguồn hoặc cả hai có thể được thay đổi bởi các yêu cầu IPv6Mu l ticastListen tiếp theo cho cùng s ocket, giao diện, v à địa chỉ Multicast IPv6. Mỗi yêu cầu đến sau thay thế hoàn toàn bất kỳ yêu cầu nào trước đó đối với từng s ocket, giao diện, và địa chỉ multicast cụ thể. Giao thức MLDv1 không hỗ trợ các bộ lọc nguồn, và có giao diện dịch vụ đơn giản hơn, MLDv1 bao gồm các chức năng bắt đầu lắng nghe và dừng lắng nghe để cho phép hoặc vô hiệu h ó a việc nghe một địa chỉ multicast cụ thể (từ tất cả các nguồn) trên một giao diện nhất định. Các hoạt động tương ứng của MLDv1 trong giao diện dịch v ụ mớ i như sau: Hoạt động bắt đầu nghe tương đương với: IPv6MulticastListen ( s ocket, giao diện, địa chỉ multicast IPv6, EXCLUDE, { }) Và hoạt động dừng lắng nghe tương đương với: IPv6Mu l ticastListen ( s ocket, giao diện, địa chỉ multicast IPv6, I NCLUDE, { } ) Trong đó { } là một danh sách nguồn trống. 7 Trạng thái nghe multicast được duy trì bởi các nút 7.1 Trạng thái từng socket Với mỗi socket mà trên đó IPv6MulticastListen được yêu cầu, nút ghi lại trạng thái nghe multicast được mong muốn cho socket đó. Trạng thái đó bao gồm một tập hợp các bản gh i có dạng: (giao diện, địa chỉ multicast lPv6, chế độ l ọ c, địa chỉ nguồn) Trạng thái cho từng socket đưa ra để phản hồi lại từng yêu cầu của IPv6MulticastListen trên từng socket như sau: - Nếu chế độ lọc được yêu cầu là INCLUDE và danh sách nguồn được yêu cầu không chứa nguồn nào, th ì mục tương ứng với giao diện và địa chỉ multicast được yêu cầu s ẽ b ị xóa nếu nó hi ể n thị. Nếu không có mục nào được hiển thị, yêu cầu s ẽ không có tác dụng. - Nếu chế độ lọc được yêu cầu là EXCLUDE hoặc danh sách nguồn được yêu cầu không phải là trống, mục tương ứng với giao diện và địa chỉ multicast được yêu cầu, nếu xuất hiện sẽ được thay đổi đ ể chứa chế độ lọc và danh sách nguồn được yêu cầu. Nếu không có mục nào xuất hiện, một mục mới sẽ được tạo ra, sử dụng các tham s ố được chỉ thị trong yêu cầu. 7.2 Trạng thái từng giao diện Ngoài trạng thái nghe multicast từng socket, một nút cũng phải d u y trì hoặc t í nh toán trạng thái lắng nghe multicast cho từng giao diện của nó. Trạng thái này chứa một tập hợp các bản ghi theo dạng: (Địa chỉ multicast I Pv6, chế độ lọc, danh sách nguồn) Chỉ duy nh ấ t một bản ghi cho từng địa chỉ multicast tồn tại cho một giao diện nhất định. Trạng thái từng giao diện n à y nhận được từ trạng thái từng socket, nhưng có thể có sự khác biệt vì các socket khác nhau có những chế độ lọc và/hoặc các danh sách nguồn khác nhau cho cùng địa chỉ multicast và giao diện. V í dụ, giả sử một ứng dụng hay chương trình yêu cầu hoạt động trên socket s 1 như sau: IPv 6 MulticastListen (s1, i, m, INCLUDE, {a, b, c}) yêu cầu việc đón nhận các gói tin được gửi tới địa chỉ multicast m trên giao diện i, chỉ khi chúng đến từ nguồn a, b hoặc c. Giả sử một ứng dụng hay chương trì nh khác yêu cầu hoạt động trên socket s2 như sau: IPv6MulticastListen (s2, i, m, INCLUDE, {b, c, d}) yêu cầu việc đón nhận những gói t i n được gửi tới cùng địa chỉ multicast m tr ê n cùng giao diện i, chỉ kh i chúng đến từ nguồn b, c hoặc d. Đ ể thỏa mãn việc đón nhận các yêu cầu của cả hai socket thì giao diện i cần nhận được các gói tin được gử i tới đ ịa chỉ m từ bất kỳ nguồn nào trong a, b, c h a y d. Do đó, trong ví dụ này, trạng thái lắng nghe của giao diện i cho địa chỉ multicast m có chế độ lọc INCLUDE và danh sách nguồn {a, b, c, d}. Sau khi một gói tin multicast được ch ấ p nhận tại tầng IP của giao diện, việc phân phối tiếp theo của gói tin này t ớ i ứng dụng hay tiến trình đang lắng nghe trên một s o cket cụ thể phụ thuộc vào trạng thái nghe multicast của socket ( và cũng phải phù hợp với những điều kiện khác, như cổng của tầng giao vận nào mà socket đang sử dụng) . Do đó nếu g ó i tin đến trên giao diện i , có đ í ch là địa chỉ multicast m, với đị a chỉ nguồn a, nó có thể được phân phối v à o socket s1 mà không phải là socket s2. Chú ý rằng, bản tin MLDv2 không phụ thuộc vào việc lọc nguồn và phải được xử lý bởi các host và router. Việc yêu cầu lọc các gói t i n d ự a vào trạng thái đón nhận multicast của socket là một tính năng mới của giao diện dịch vụ này. Giao diện dịch vụ trước đó không mô tả việc lọc dựa tr ê n trạng thái nghe multicast; hơn nữa, hoạt động bắt đầu nghe multicast trên mỗi socket chỉ đơn giản làm cho nút bắt đầu nghe địa chỉ multicast trên một giao diện cụ thể; các gói tin được gửi tới địa chỉ multicast đó có t hể được phân phối cho tất cả các socket, dù chúng đã bắt đầu nghe hay chưa. Quy tắc thông thường đ ể trạng thái từng giao diện nhận được từ trạng thái từng socket như sau: với từng cặp (giao diện, địa chỉ multicast) riêng biệt xuất hiện trong trạng thái từng socket, một bản ghi từng giao diện được tạo ra cho địa chỉ multicast này trên giao diện đó. Tất cả các bản ghi socket chứa cùng cặp (giao diện, địa chỉ multicast) được xem xét như sau: - Nếu bất kỳ bản ghi socket nào có chế độ lọc l à EXCLUDE thì chế đ ộ lọc của bản ghi giao diện là EXCLUDE, và danh sách nguồn của bản ghi giao diện là phần giao cắt của các danh sách địa chỉ nguồn cho tất c ả các bản ghi socket trong chế độ lọc EXCLUDE, tr ừ đi các địa chỉ nguồn xuất hiện trong bất kỳ bản ghi socket nào có chế độ lọc INCLUDE. Ví dụ, nếu các bản ghi socket cho địa chỉ multicast m trên giao diện i là: từ socket s 1: (i , m , EXCLUDE, {a, b, c, d}) từ socket s2: (i, m, EXCLUDE, {b, c, d, e}) từ socket s3: (i, m, INCLUDE, {d, e, f}) bản ghi giao diện tương ứng trên giao diện i là: (m, EXCLUDE, {b, c}) Nếu socket thứ tư được thêm vào như sau: Từ socket s4: ((i, m, EXCLUDE, { }) bản ghi giao diện s ẽ tr ở thành: (m, EXCLUDE, { }) - Nếu tất cả các bản ghi socket có một chế độ lọc là INCLUDE th ì chế độ lọc của bản ghi giao diện là INCLUDE, v à danh sách nguồn của bản ghi giao diện là kết hợp của các danh sách nguồn của tất cả các bản ghi socket. Ví dụ, nếu các bản ghi socket cho địa chỉ multicast m trên giao diện i là: từ sock e t s1: (i, m, INCLUDE, {a, b, c}) từ socket s2: ( i , m, INCLUDE, {b, c, d}) từ socket s3: (i, m, INCLUDE, {e, f }) thì bản ghi giao diện tương ứng trên giao diện i là: (m, INCLUDE, {a, b, c, d, e, f}) Việc thực hiện KHÔNG ĐƯỢC sử dụng bản ghi giao diện EXCLUDE cho một địa chỉ multicast nếu tất cả các socket cho địa chỉ multicast này ở trong trạng thái INCLUDE. Nếu t à i nguyên hệ thống b ị giới hạn khi tính toán danh sách nguồn cho trạng thá i từng giao diện, một lỗi PHẢI được tr ả về giao diện đã yêu cầu. Các quy luật ở trên cho việc nhận biết trạng thái từng giao diện được đánh giá lại bất cứ khi nào một yêu cầu IPv 6 MulticastListen làm thay đổi trạng thát từ n g socket bằng cách thêm vào, xóa bỏ hay chỉnh sửa bản ghi trạng thái từng socket. Chú ý rằng một thay đổi của trạng thá i từng socket không nhất thiết dẫn đến một sự thay đổi trong trạng thái từng giao diện. 8 Các định dạng bản tin MLDv2 là một giao thức con của ICMPv6, đo đó, các dạng bản tin của MLDv2 l à một tập con của các bản tin ICMPv6, và các bản tin MLDv2 được định nghĩa trong các gói IPv6 b ở i giá trị trường Next Header bằng 58. Tất c ả các bồn tin MLDv2 được mô tả trong tiêu chuẩn này PHẢI được gửi với địa chỉ nguồn l i nk-local, trường Ho p Limit có giá trị bằng 1, và tùy chọn Router Alert IPv6 [RFC2711] trong mào đầu Hop-by-Hop Opt i ons (tùy chọn Router Al e rt nhằm mục đích để các rou t er kiểm tra các bản tin MLDv2 được gửi tới các địa chỉ multicast IPv6 mà router không có nhu cầu). Các bản tin Report MLDv2 có thể được gửi với địa chỉ nguồn được thiết lập thành địa chỉ không xác định [TCVN 9802- 2:2015], nếu giao diện gửi không có một địa chỉ nguồn I Pv6 link-local hợp lệ. Hai loại bản tin MLD liên quan đến giao thức MLDv2 được mô tả trong tiêu chuẩn này: - B ả n tin Multicast Listener Query (trường Type có giá trị bằng 130 theo hệ thập phân), - Bản tin Multicast Listener Report phiên bản 2 (Trường Type có giá trị bằng 143 theo hệ thập phân). Để đảm bảo tính tương tác với các nút triển khai MLDv1 (điều 11), việc triển khai MLDv2 cũng phải hỗ trợ hai loại bản tin sau: - Bản tin Multicast Listener R e por t phiên bản 1 (Trường Type có giá trị bằng 131 theo hệ thập phân) [RFC2710], - Bản tin Multicast Listener Done (hoàn thành nghe multicast) phiên bản 1 (Trường Type có giá trị bằng 132 theo hệ thập phân) [R F C2710]. Các loại bản t i n không được nhận b i ết PHẢI được tự động b ỏ qua. Các loại bản tin khác có thể được sử dụng bởi các phiên bản hoặc các phần mở rộng MLD mới hơn, bởi các giao thức đ ị nh tuyến multicast hoặc một số phương pháp khác. Trong phần còn lại của tiêu chuẩn này, bản tin Multicast Listener Query, bản tin Multicast Listener Report, bản tin Multicast L i stener Done được gọi tắt l à bản tin Query, bản tin Report, và bản tin Done một cách tương ứng. 8.1 Bản tin Mu l ticast Listener Query Các bản tin Multicast Listener Query được gửi bởi các Querier để truy vấn trạng thái nghe multicast của các giao diện lân cận. Các bản tin Query có định dạng bản tin như sau: Hình 1 - Định dạng bản tin Query 8.1.1 Trường Code (Mã) Được khởi tạo bằng 0 bởi bên gửi; được bên nhận bỏ qua. 8.1.2 Trường Checksum (kiểm tra tổng) Trường Checksum ICMPv6 chuẩn thực h i ện kiểm tra toàn bộ bản tin MLDv2, cộng thêm “mào đầu ả o” của các trường mào đầu IPv6 [RFC 4443]. Đ ể tính toán lỗi, trường Checksum được thiết lập bằng 0. Khi một gói tin được gửi, trường Checksum PH Ả I được xác minh trước khi xử lý gói tin đó. 8.1.3 T rườ ng Max i mum Respond Code (Mã phản hồi t ố i đa) Trường Maximum Respond Code quy định thời gian cho phép tối đa tr ước khi gửi một bản tin Report phản hồi. Thời gian thực tế cho phép, được gọ i là trễ phản hồi tối đa, thể hiện theo đơn vị mili-giây, và được nhận từ mã phản hồi tối đa như sau: Nếu giá tr ị trường Max i mum Respond Code nh ỏ hơn 32768 th ì trễ ph ả n hồi tối đa bằng giá trị của trường Maximum Respond Co d e. Nếu giá trị t rư ờng Maximum Respond Code lớn hơn hoặc bằng 32768 thì trễ phản hồi tối đa bằng [(mant | 0x1000) (exp+3)]. Trong đó, k ý hiệu mant và exp được quy định như sau: Các giá trị nhỏ của trễ phản hồi tối đa cho phép các router MLDv2 điều chỉnh “trễ rời nh ó m ” (thời gian g i ữa thời điểm nút cuối cùng trên liên kết dừng nghe một địa chỉ multicast cụ thể và thời điểm giao thức định tuyến được thông báo rằng không còn một đối tượng nghe nào nữa cho địa chỉ đó). Các giá trị lớn hơn, đặc biệt theo bậc lũy thừa, cho phép điều chỉnh sự bùng nổ của lưu lượng MLD trên một liên kết. 8.1.4 Trường Reserve (Dự phòng) Được kh ở i tạo bằng 0 bởi bên gửi, được bên nhận b ỏ qua. 8.1.5 Trường Multicast Address (Địa chỉ Mu l t i cast) Trong bản tin General Query, trường Mu l ticast Address được thiết lập về 0. Trong bản tin Multicast Address Spe cif ic Query hoặc bản tin Multicast Address and Source Specific Query, trường này được thiết lập thành địa chỉ multicast được truy vấn. 8.1.6 Trường Resv Được khởi tạo bằng 0 bởi bên gửi, được b ê n nhận b ỏ qua . 8.1.7 Trường S Flag (Cờ S) - Ngăn ch ặ n xử lý phía router Khi được thiết lập bằng 1, cờ S yêu cầu bất cứ router multicast nào đang nhận bản tin ngừng cập nhật các bộ đếm thời gian như chúng vẫn thực hiện ngay sau khi nhận được một bản tin Query. Tuy nhiên cờ S không ngăn chặn việc bầu chọn Querier hoặc xử lý bản tin Query phía host thông thường mà router có thể được yêu cầu thực hiện (khi router trở thành đối tượng nghe multicast). 8.1.8 Trường QRV (biến Robustness của Quer i er) Nếu khác 0, trường QRV chứa giá trị [biến Robustness] được sử dụng bởi Querier. Nếu [biến Robustness] của Querier vượt quá 7 (giá trị tối đa của trường QRV), trường QRV được đặt bằng 0. Các router nhận giá trị QRV từ bản tin Query vừa nhận được gần nhất như là giá trị [biến Robustness] của chính nó. Nếu trường QRV vừa nhận được gần nhất bằng 0 thì router sẽ sử dụng g i á t rị [biến Robustness] mặc định được quy định trong điều 12.1, hoặc một giá trị đã được cấu hình cố định. 8.1.9 Trường QQIC (Mã khoảng thời gian truy vấn của quer i er) Trường QQIC quy định [khoảng thời gian truy vấn] được sử dụng bởi Q u erier. Khoảng thời gian thực tế, được g ọi là khoảng thời gian truy vấn của Queri e r (viết tắt là QQI), được thể hiện theo đơn v ị giây, và được nhận từ QQIC như sau: Nếu QQIC < 128,="" giá="" trị="" khoảng="" thời="" gian="" truy="" vấn="" của="" querier="" bằng="" giá="" trị="" của="" trường="" qqic="" nếu="" qqic="">= 128, giá trị khoảng thời gian truy vấn của Querier b ằ ng: (mant | 0x10) (exp + 3) Trong đó, ký hiệu e xp và mant được quy định như sau: Các router multicast không phải là Querier hiện tại sẽ nhận giá trị QQI từ b ả n tin Query nhận được gần nh ấ t như là giá trị [khoảng thời gian truy vấn] của chính nó. Nếu giá trị QQI vừa nhận được bằng 0 thì các router sẽ sử dụng giá trị [khoảng thời gian truy vấn] mặc định được quy định trong điều 12.2. 8.1.10 Number of Sources [N] (Số lượng nguồn) Trường Number of Sources (N) quy định số lượng địa chỉ nguồn đang có mặt trong bản tin Query. Số lượng này bằng 0 t rong một bản tin General Query hoặc bản tin Multicast Address Specific Query và khác không trong một bản tin Multicast Address and Source Specific Query. Số lượng này được gi ớ i hạn bởi MTU của liên kết m à bản tin Query được g ửi . Ví dụ, trên một liên kết Ethernet v ới MTU bằng 1500 octet, mào đầu IPv6 (40 octet) cùng với tùy chọn Router A l ert thành 48 octet; do đó, còn lại 1424 octet cho các địa chỉ nguồn sẽ giới hạn số lượng địa chỉ nguồn bằng 89 (1424/16). 8.1.11 Source Address [ i] (Địa chỉ nguồn) Các trường Source Address [i] là một véc tơ của n địa chỉ unicast, trong đó n là giá trị của trường Number of Sources [ N ] . 8.1.12 Dữ liệu bổ sung Nếu trường Payload Length trong mào đầu IPv6 của một bản tin Query nhận được quy định rằng sau các trường được mô tả ở trên có xu ấ t hiện các octet dữ liệu bổ sung, th ì việ c triển khai MLDv2 PHẢI sử dụng các oct e t này để tính toán xác minh Checksum MLD nhận được nhưng mặt khác PHẢ I bỏ qua các octet bổ sung đó. Khi gửi một bản tin Query, việc thực thi MLDv2 KHÔNG ĐƯỢC bao gồm những octet bổ sung sau các trường, được mô tả ở trên. 8.1.13 Các loại của bản tin Query Bản tin Query có ba loại như sau: - “B ả n tin General Query” được gử i bở i Querier đ ể biết được những địa chỉ multicast nào có đối tượng nghe trên một liên kết được kết nối. Trong bản tin General Query, cả trư ờ ng Multicast Address và trường N u mber of Sources (N) đều bằng 0. - “Bản tin Multicast Address Spe cifi c Query” được gửi bởi Querier đ ể biết được rằng một địa chỉ multicast cụ thể có đối tượng nghe nào trên một liên kết được kết nối hay không. Trong bản tin Multicast Address Specific Query, trường Multicast Address chứa địa chỉ multicast đang được theo dõi, trong khi trường Number of Sources (N) được đặt bằng 0. - “Bản tin Multicast Address and Source Specific Query” được gửi bởi bộ Querier đ ể biết được rằng các nguồn từ danh sách xác định cho một địa chỉ multicast cụ thể có đối tượng nghe nào trên một liên kết được kết nối hay không. Trong bản tin Multicast Address and Source Specific Query, trường Multicast Address chứa địa chỉ m ulticast đang được theo dõi, trong khi các trường Source Address [i] chứa các địa chỉ nguồn được theo dõi. 8.1.14 Những đ ịa chỉ nguồn cho các bản tin Query Tất cả các bản tin Query MLDv2 PHẢI được gửi với địa chỉ nguồn IPv6 link-local hợp lệ. Nếu một nút nhận được bản t i n Query có địa chỉ nguồn IPv6 là địa chỉ không xác định (::), hoặc các địa chỉ khác không phải đ ịa chỉ IPv6 hợp lệ, nút PHẢI loại b ỏ tự động bản tin này và N Ê N ghi lại cảnh báo. 8.1.15 Những địa chỉ đích cho các bản tin Query Trong MLDv2, các bản tin General Query được gửi t ớ i địa chỉ multicast tất cả các nút trong phạm vi l iên kết (FF02::1). Các bản tin Multicast Address Specific Query và bản tin Multicast Address and Source Specific Query được gửi có địa chỉ đích là địa chỉ multicast được theo dõi. Tuy nhiên, một nút PH Ả I chấp nhận và xử lý bất kỳ bản tin Query nào có trường Destination Address chứa những địa chỉ (unicast hoặc multicast) được gán cho giao diện mà bản tin Query tới. Điều này có thể hữu ích trong một số trường hợp, chẳng hạn cho mục đích tìm và sửa lỗi. 8.2 B ả n tin Multicast Listen e r R e port phiên bản 2 Các bản tỉn Multicast Li stener Report ph iê n bản 2 được gửi bởi các nút IP để thông báo (tới các router lân cận) trạng thái nghe multicast hiện tại hoặc để thay đổi trạng thái nghe multicast của các giao diện của chúng. Hình 2 tr ì nh bày định dạng của bản tin Report. Hlnh 2 - Định dạng bản tin Report Mỗi Multicast Address Record (bản ghi địa chỉ multicast) trong bản tin Report có định dạng như Hình 3. Hình 3 - Định dạng Multicast Address Record (bản ghi địa chỉ multicast) 8.2.1 Trường Reserved (Dự phòng) Trường Reserved được đặt bằng 0 khi truyền và được bên nhận bỏ qua. 8.2.2 Trường Checksum (Kiểm tra tổng) Trường Checksum ICMPv6 chuẩn thực hiện kiểm tra toàn bộ bản t in MLDv2, cộng thêm “mào đầu ảo” của trường mào đầu I Pv6 [ TCVN 9802-1:2013, RFC 4443]. Đ ể tính toán kiểm tra t ổng, trường Checksum được đặt bằng 0. Khi một gói tin được nhận, trường Checksum PHẢI được xác minh trước khi xử lý nó. 8.2.3 Trường Nr of Mcast Address Records (Số lượng các bản ghi địa chỉ Multicast M) Trường Nr of Mcast Address Records (M) quy định số lượng các Multicast Address Record được hiển thị trong một bản tin Report. 8.2.4 Trường Multicast Address Record (Bản ghi địa ch ỉ Multicast) Mỗi Multicast Address Record là một khối các trường chứa thông tin ở máy gửi đang nghe một địa chỉ multicast đơn l ẻ trên giao diện mà từ đó bản tin Report được gửi. 8.2.5 Trường Record Type (Loại bản ghi) Trường này quy định loại Multicast Address Record. Xem điều 8.2.12 về các mô tả chi tiết cho các loại bản ghi khả dụng khác nhau. 8.2.6 Trường Aux Data Len (Chiều dà i dữ liệu b ổ tr ợ ) Trường Aux Data Len chứa chiều dài của trường dữ liệu bổ trợ trong Multicast Address R e cord, theo đơn vị từ 32-bit. N ó có thể b ằ ng 0 nhằm thể hiện không có dữ liệu bổ trợ nào. 8.2.7 Trường Number of Sources [N] (Số lượ ng Ngu ồn ) Trường Number of Sources quy định số lượng địa chỉ nguồn được hi ể n th ị trong Multicast Address Record. 8.2.8 Trường Multicast Address (Địa chỉ multicast) Trường Multicast Address chứa địa chỉ multicast của Multicast Address Record. 8.2. 9 T rườ ng Source Address [i] (Địa chỉ Nguồn) Các trường Source Address là một véc tơ của n các địa chỉ unicast, trong đó n là giá trị của trường Number of Sources (N) trong bản ghi. 8.2.10 Tr ườ ng Auxiliary Data (Dữ liệu bổ trợ) Nếu xuất hiện, trư ờ ng Auxiliary Data chứa các thông tin bổ sung liên quan đến Multicast Address Record này. Giao thức MLDv2 quy định tại tiêu chu ẩ n này không định nghĩa bất kỳ dữ liệu bổ trợ nào. Do đó, các thực th i MLDv2 KHÔNG ĐƯỢC bao gồm bất kỳ dữ liệu bổ trợ (tức là, PHẢI thiết lập trường Aux Data Len bằng 0) trong b ấ t kỳ Multicast Address Record được truyền nào, và PHẢI bỏ qua những dữ liệu như vậy nếu chúng xuất hiện trong Multicast Address Record nhận được. Nội dung và mã hóa nội bộ của trường Auxiliary Data được định nghĩa bởi các phiên bản hoặc phần m ở rộng của MLD trong tương la i sẽ sử dụng trường này. 8.2.11 Dữ liệu bổ sung Nếu trường Paytoad Length trong mào đầu IPv6 của bản tin Report nhận được chỉ thị rằng sau Multicast Address Record cuối cùng có những octet dữ l i ệu bổ sung thì các thực thi MLDv2 PHẢI sử dụng các octet đó trong việc tính toán xác minh trường Checksum MLD nhận được nhưng mặt khác PHẢI bỏ qua các octet bổ sung đ ó . Khi gửi một bản tin Report, thực th i MLD KH Ô NG ĐƯỢC chứa các octet bổ sung sau Multicast Address Record cuối cùng. 8.2.12 Các loại Multicast Address R e cord Bản tin Report có thể có một số loại Multicast Address Record khác nhau như sau: - Current State Record (bản ghi trạng thái hiện tại) được một nút gửi đi để phản hồi lại bản tin Query nhận được trên một giao diện. Bản tin Report chứa bản ghi này thông báo trạng thái lắng nghe hiện tại của giao diện đã nhận bản tin Query, đối với một địa chỉ mult icast . Trường Record Type của Current State Record có thể là một trong hai giá trị sau: Giá trị Tên và ý nghĩa 1 MODE _IS _INCLUDE - quy định rằng giao diện có chế độ lọc là INCLUDE cho một địa chỉ multicast cụ thể. Các trường Source Address [ i ] trong Multicast Address Record l à danh s á ch nguồn của giao diện cho một địa chỉ multicast cụ th ể . Bản gh i MODE_IS _I NCLUDE không bao giờ được gử i với một danh sách nguồn trống. 2 MODE _IS _EXCLUDE - quy định rằng giao diện có chế độ lọc là EXCLUDE cho một địa chỉ multicast cụ th ể . Các trường Source Address [ i] trong Multicast Address Record nếu có sẽ là danh sách nguồn của giao diện cho địa chỉ multicast cụ thể. - Filter Mode Change Record (bản ghi thay đổi chế độ lọc) được gửi bởi một nút bất cứ khi nào một yêu cầu cục bộ IPv6Mu l t i cast Li sten gây ra một thay đ ổi về chế độ lọc của bản gh i trạng thái giao diện cho một địa chỉ multicast cụ th ể (tức là thay đ ổi từ INCLUDE sang EXCLUDE, hoặc từ EXCLUDE sang INCLUDE), đ ể xác minh danh sách nguồn có thay đổi cùng thời điểm hay không. Bản tin Report chứa b ả n ghi này được gửi đi từ giao diện mà thay đổi xảy ra. Trư ờ ng Record Type của Filter Mode Change Record có thể là một trong hai giá trị sau: Giá trị Tên và ý nghĩa 3 CHANGE_TO_INCLUDE MODE - quy định rằng giao diện được thay đổi sang chế độ lọc INCLUDE cho một địa chỉ multicast cụ thể. Các trường Source Address [ i ] trong Multicast Address Record nếu có sẽ là danh sách nguồn mới của giao diện đối với một đ ịa chỉ multicast cụ thể. 4 CHANGE_TO_EXCLUDE_MODE - quy định rằng giao diện được thay đổi sang chế độ lọc EXCLUDE cho một địa chỉ multicast cụ thể. Trường Source Address [i] trong Multicast Address Record nếu có sẽ là danh sách nguồn mới của giao diện đối với đ ịa chỉ multicast cụ thể. - Source List Change Record (bản ghi thay đổi danh sách nguồn) được gửi bởi một nút bất cứ khi nào một yêu cầu IPv6MulticastL i sten cục bộ gây ra một sự thay đổi danh sách nguồn, điều đó không có nghĩa là thay đổi chế độ lọc của một bản ghi trạng thái giao diện cho một địa chỉ multicast cụ thể. Bản ghi này chứa trong bản tin Report được g ửi từ giao diện đã xảy ra thay đổi. Trường Record Type của Source List Change Record có thể là một trong hai giá trị sau: Giá trị Tên và ý nghĩa 5 ALLOW_NEW_SOURCE - quy định rằng các trường Source Address [i] trong Multicast Address Record này chứa một danh sách nguồn bổ sung mà nút mong muốn lắng nghe các gói tin cho một địa chỉ multicast cụ thể. Nếu thay đ ổi xảy ra tại d anh sách nguồn INCLUDE, đây là những địa chỉ được thêm vào danh sách, nếu thay đổi xảy ra tại danh sách nguồn EXCLUDE, đây l à những địa chỉ được xóa khỏi danh sách. 6 BLOCK_OLD_SOURCE - quy định rằng các trư ờ ng Source Address [i] trong Multicast Address Record này ch ứ a một danh sách các nguồn mà nút không còn mong muốn l ắng nghe các gói tin cho một địa chỉ multicast cụ thể. Nếu thay đổi sang danh sách nguồn INCLUDE, đây l à những địa chỉ đã được xóa khỏi danh sách, nếu thay đổ i sang danh sách nguồn EXCLUDE, đây là những địa chỉ được thêm vào danh sách. Nếu sự thay đổi danh sách nguồn dẫn đến cả việc cho phép các nguồn mới và xóa các nguồn cũ, th ì hai bản ghi địa chỉ ng u ồn multicast s ẽ được gửi với cùng địa chỉ multicast, một bản cho loại ALLOW_NEW_SOURCES, một cho loại BLOCK_OLD_SOURCES. Khái niệm State Change Record được sử dụng để tham chiếu đến hoặc F ilter Mode Change Record hoặc Source List Change Record. Những biểu diễn sau được sử dụng đ ể mô tả nội dung của Multicast Address Record liên quan đến một địa chỉ multicast cụ thể: IS_IN ( x ) - Loại bản ghi là MODE_IS INCLUDE, các địa chỉ nguồn x IS_EX ( x ) - Loại bản ghi là MODE_IS_EXCLUDE, các địa chỉ nguồn x TO _I N ( x ) - Loại bản ghi là CHANGE_TO _ NCLUDE_MODE, các địa chỉ nguồn x TO_EX ( x ) - Loại bản ghi l à CHANGE_TO_EXCLUDE_MODE, các địa chỉ nguồn x ALLO W ( x ) - Loại bản ghi là ALLOW_NEW_SOURCES, các địa chỉ nguồn x BLOCK ( x ) - Loại bản ghi là BLOCK_OLD_S O URCES, các đ ịa chỉ nguồn x Trong đó x là: - Chữ viết hoa (ví dụ “A”) đại diện cho một tập các địa chỉ nguồn hoặc - Bi ể u diễn nhi ề u tập hợp các địa chỉ nguồn (ví dụ “A+B”) trong đó, “A+B” có nghĩa là tập hợp kết hợp giữa A và B, “A*B” có nghĩa là ph ầ n giao giữa A và B, “A-B” có nghĩa là loại bỏ tất cả các thành phần của tập B từ tập A. 8.2.13 Các địa chỉ nguồn cho bản tin Report Một bản tin Report MLDv2 PH Ả I được gửi với một địa chỉ IPv6 link-local hợp lệ, hoặc địa chỉ không xác định (::) nếu giao diện gửi không yêu cầu địa chỉ link-local hợp lệ. Các bản tin Report gửi đi với địa chỉ không xác định đ ể h ỗ tr ợ việc sử dụng IP multicast trong giao thức phát hiện nút mạng lân cận [TCVN 9802-3:2015]. Với giao thức tự động cấu hình đ ịa chỉ phi trạng thái [được định nghĩa trong RFC 2462], một nút được yêu cầu tham gia nhiều nhóm multicast IPv6 khác nhau để thực hiện chức năng phát hiện địa chỉ trùng (DAD). Trước khi thực hiện DAD, địa chỉ d u y nhất mà nút báo cáo sử dụng cho việc gửi là một địa chỉ thăm dò, không thể được sử dụng cho truyền thông. Do đó, địa chỉ không xác định phải được sử dụng. Mặt khác, router PHẢI tự động bỏ qua những gói tin không có địa chỉ link-local hợp lệ, mà không tác động đến nội dung của các gói tin đó. Do đó, một bản tin Report sẽ bị bỏ qua nếu router kh ô ng xác định được địa chỉ nguồn của gói tin thuộc về liên kết được kết nối với giao diện nhận g ó i tin đó. Bản tin Report được gửi với địa chỉ không xác định cũng bị router loại bỏ. Điều này giúp tăng cường bảo m ật, v ì các nút báo cáo không xác định s ẽ không thể làm ảnh hưởng đến trạng thái các router MLDv2. Tuy nhiên, nút báo cáo đã thay đổi trạng thái nghe của m ì nh đối với các địa chỉ multicast được chứa trong Multicast Address Record của bản tin Report. Từ thời điểm này, n ú t báo cáo s ẽ xử lý các gói tin được gử i tới các địa chỉ multicast đó theo trạng thái nghe mới này. Khi đ ị a chỉ link- l ocal là hợp lệ, nút N Ê N phát đi các bản tin Report MLDv2 mới cho t ấ t cả các địa chỉ multicast đã tham gia trên giao diện. 8.2.14 Địa chỉ đích của các bản tin Report Các bản tin Multicast Listener Report phiên bản 2 được gửi với địa chỉ IP đích là FF02:0:0:0:0:0:0:16 (địa chỉ mà tất cả các router multicast MLDv2 có kh ả năng nghe). Một nút hoạt động trong chế độ tương thích với phiên bản 1 gửi các bản tin Report phiên bản 1 tới địa chỉ multicast được xác định t rong trường Muiticast Address của bản tin Report. Ngoài ra , một nút PHẢI chấp nhận và xử lý bất kỳ bản tin Report phiên bản 1 nào có trường Destination Address chứa bất kỳ địa chỉ IPv6 (unicast hoặc multicast) được gán cho giao diện mà bản tin Report đó đến. Điều này là hữu ích cho một số m ụ c đích như tìm và sửa lỗi. 8.2.15 Kích th ư ớc bản tin Repor t Nếu tập hợp các Multicast Address Record được yêu cầu trong bản tin Report không phù hợp với giới hạn kích thước của bản tin Report (được xác định theo MTU của liên kết mà nó sẽ được gửi) thì các Multicast Address Record c ầ n được gửi trong nhiều bản tin Report để báo cáo toàn bộ các bản ghi. Nếu một Mu l ticast Address Record chứa quá nhiều địa chỉ nguồn do đó bản ghi này không phù hợp với giới hạn kích thước của bản tin Report th ì : - Nếu loại bản ghi không phải l à IS_EX hoặc là TO_EX, bản ghi đó sẽ được chia thành nhiều Multicast Address Record; mỗi bản ghi như vậy chứa một tập con khác nhau của các địa chỉ nguồn v à sẽ được gửi trong các b ản tin Report riêng biệt. - Nếu loại bản ghi là IS_EX hoặc là TO_EX, một Multicast Address Record đơn lẻ được gửi với nhiều địa chỉ nguồn nhất có thể; các địa chỉ nguồn còn lại s ẽ không được báo cáo. Mặc dù l ựa chọn địa chỉ nguồn nào để báo cáo là tùy ý, ti ê u chuẩn này khuyến nghị báo cáo một tập hợp giống nhau các nguồn trong mỗi bản tin Report tiếp theo. 9 Mô tả giao thức đối với các đối tượng nghe địa chỉ multicast MLDv2 là giao thức b ấ t đối xứng, v ì giao thức này quy định rõ ràng các cách xử lý riêng biệt cho các đối tượng nghe địa chỉ multicast (các host và router lắng nghe các gói tin multicast) và các router multicast. Phần n à y mô tả chức năng của MLDv2 áp dụng cho tất cả các đối tượng nghe địa chỉ multicast. (Chú ý rằng một router multicast cũng là một đối tượng nghe multicast thực hiện c ả hai chức năng của MLDv2; nó nhận và phản hồi lại các bản tin MLD của chính mình, cũng như các bản tin MLD của các nút mạng lân cận nó.) Chức năng router của MLDv2 được mô tả trong điều 10. Trong phần này, một nút thực hiện giao thức trên tất cả các giao diện hỗ trợ việc tiếp nhận multicast, ngay c ả khi có nhiều giao diện kết nối trên cùng liên kết. Để hoạt động tương tác với các router multicast đang chạy giao thức MLDv1, các nút duy trì biến Host Compatibility Mode (biến chế độ tương thích host) cho mỗ i giao diện mà việc tiếp nhận multicast được hỗ trợ. Phần n à y mô tả việc xử l ý của các nút nghe địa chỉ multicast trên các giao diện mà Host Compat i bility Mode = MLDv2. Giải thuật để xác định biến Host Compatibiltt y Mode và cách xử lý nếu giá trị của biến này được thiết lập là MLDv1, được mô t ả trong điều 11. Địa chỉ multicast tất cả các nút trong phạm vi liên kết (FF02::1) được xử lý như một trường hợp đặc biệt, Trên tất cả các nút - tức là tất cả các host và router bao gồm cả các router multicast - việc lắng nghe các gói tin có đích là địa chỉ multicast tất cả các nút từ tất cả các nguồn, được cho phép trên tất cả các giao diện mà việc nghe multicast được hỗ trợ. Không có bản tin MLD nào được gửi mà không liên quan đến địa chỉ multicast t ấ t c ả các nút trong phạm vi liên kết hoặc c ũ ng không phải là địa chỉ multicast có giới hạn bằng 0 (dự ph ò ng) hoặc 1 (node-local). Có 3 loại sự kiện có thể kích hoạt các hoạt động của giao thức MLDv2 trên 1 liên kết: - Thay đổi của trạng thái nghe từng giao diện, đ ư ợc gây ra bởi yêu cầu cục bộ IPv6MulticastListen - Bắt đầu một bộ đếm thời gian cụ thể - Tiếp nhận một bản tin Query (Các bản tin MLD nhận được không phải là bản tin Query sẽ được tự động bỏ qua, trừ khi ch ú ng được sử dụng cho việc tương tác với các n ú t thực thi MLDv1). Các ph ầ n tiếp theo mô tả các hoạ t động được thực hiện cho từng trường hợp. T ê n các bộ đếm thời gian và bộ đếm, cùng g i á tr ị mặc định của chúng được quy định trong đi ề u 12. 9.1 Xử lý theo sự thay đổi của trạng thái từng giao diện Yêu cầu IPv6MulticastListen có thể gây ra sự thay đổi trạng thái nghe mu l ticast của một giao diện, theo các quy tắc trong điều 7.2. Mỗi một thay đổi như vậy ảnh hướng đến bản ghi từng giao diện đối với một địa chỉ multicast đơn lẻ. Một thay đổ i của trạng thái từng giao diện buộc nút phải ngay lập tức truyền đi bản tin State Change Report từ giao diện đó. Loại và nội dung c ủ a các Multicast Address Record trong bản tin Report đó được xác định bằng cách so sánh chế độ lọc và danh sách nguồn cho địa chỉ multicast b ị ảnh hưởng trước và sau thay đổi, theo bảng dưới đây. Nếu thay đổi là việc tạo ra một bản ghi từng giao diện mới hoặc thay đổ i là việc xóa bản gh i từng giao diện, th ì Multicast Address Record này được xem là có chế độ lọc INCLUDE v à danh sách nguồn trống. Trạng thái cũ Trạng thái mớ i Bản ghi State Change Record được gử i INCLUDE (A) EXCLUDE (A) INCLUDE (A) EXCLUDE (A) INCLUDE (B) EXCLUDE (B) EXCLUDE (B) INCLUDE (B) ALLOW (B-A), BLOCK (A-B) ALLOW (A-B), BLOCK (B-A) TO_EX (B) TO _I N (B) Nếu danh sách nguồn được tính toán cho State Change Record ALLOW hoặc BLOCK là tr ố ng, bản ghi đó được bỏ qua kh ỏ i bản tin Report. Để chắc chắn rằng bản tin State Change Repo r t không bị mất bởi một hay nhiều router multicast thì ([biến Robustness] -1) bản tin này sẽ được lập lịch để truyền lại, qua bộ đếm thời gian truyền lại, ở khoảng thời gian được chọn ngẫu nhiên trong khoảng (0, [khoảng thời gian báo cáo không theo thăm dò]). Nếu xảy ra thêm nhiều thay đổi tớ i cùng một bản ghi trạng thái từng giao diện trước khi hoàn thành việc truyền lại t ấ t cả các bản tin State Change Report cho thay đổi đầu tiên, mỗi thay đổi bổ sung như vậy sẽ kích hoạt v i ệc truyền ngay lập tức một bản tin State Change Report m ớ i. Nội dung của bản tin Report mớ i được tính toán như sau: - Với bản tin Report đầu tiên, trạng thái từng giao diện cho địa chỉ multicast bị tác động trước và sau thay đổi cuối cùng sẽ được so sánh. - Bản ghi thể hiện sự khác nhau được xây dựng theo bảng ở trên. Tuy nhiên, các bản ghi này không được truyền trong 1 bản tin riêng biệt, m à thay vào đó chúng được sáp nhập với nộ i dung của bản tin Report đang ở trạng thái chờ để tạo ra một bản tin State Change Report mới. Các quy tắc cho việc tính toán bản tin Report được sáp nhập này được mô tả dưới đây. Việc truyền bản t i n State Change Report được sáp nhập sẽ chấm dứt việc truyền lại các bản tin State Change Report trước đó cho cùng địa chỉ multicast, và trở thành bản đầu tiên của [biến Robustness] bản tin State Change Report mới được truyền lại. Những bản tin được lặp lại này cần thiết để chắc chắn rằng m ỗ i một thay đổi trạng thái này được truyền lại tối thi ể u [biến Robustness] lần. Mỗi lần một nguồn trong một bản tin Report khác được tính toán ở tr ê n, trạng thái truyền lại cho nguồn đó cần được duy trì cho đến khi [biến Robustness] bản t in State Change Report được n ú t gửi đi. Điều này được thực hiện đ ể chắc chắn r ằ ng một chuỗi các thay đổi trạng thái thành công không phá vỡ tính ổ n định của tiêu chuẩn. Các nguồn trong trạng thái truyền lại có thể được giữ trong danh sách truyền lại với t ừng địa chỉ multicast, vớ i một bộ đếm truyền lại cho nguồn được liên kết tới mỗi nguồn trong danh sách. Khi một nguồn nằm trong danh sách, bộ đếm của nó được thiết lập bằng [biến Robustness]. Mỗi lần bản tin State Change Report được gửi, bộ đếm này s ẽ giảm 1 đơn v ị . Khi bộ đếm tiến về 0, nguồn sẽ bị xóa khỏi danh sách truyền lại đối với địa chỉ multicast đó. Nếu thay đổi trạng thái nghe cho từng giao diện tạo ra một bản tin Report mới, là một thay đổi chế độ lọc thì [biến Robustness] bản tin State Change Report tiếp theo sẽ chứa một Filter Mode Change Record. Đ iề u này áp dụng ngay cả khi có những thay đổi danh sách nguồn xảy ra trong chu kỳ t r ước đó. Nút phải duy t rì trạng thái truyền lại cho địa chỉ multicast cho đến khi [biến Robustness] bản tin State Change Report được g ửi . Điều này có th ể được thực hiện th ô ng qua một bộ đếm truyền lại chế độ lọc cho từng địa ch ỉ multicast. Khi chế độ lọc thay đổi, bộ đếm được đặt về [biến Robustness]. Mỗi lần một bản tin State Change Report được gửi, bộ đếm sẽ gi ả m 1 đơn vị. Khi bộ đếm tiến về 0, tức là [biến Robustness] bản tin State Change Report với các Filter Mode Change Record được truyền sau khi thay đổi chế độ lọ c cuối cùng, và nếu các thay đổi danh sách nguồn dẫn đến các bản tin Report bổ sung được lập lịc h th ì bản tin State Change Report tiếp theo s ẽ bao gồm các Source List Change Record. Mỗi lần thay đổi trạng thái nghe cho từng giao diện tạo ra việc truyền ngay lập tức một bản tin State Change Report mới, nội dung của bản tin Report sẽ được xác m inh như sau. Nếu bản tin Report chứa F il ter Mo d e Change Record, tức là bộ đếm tr uyền lại chế độ lọc cho địa chỉ multicast đó có giá trị lớn hơn 0, và nếu chế độ lọc hiện tại của giao diện là INCLUDE th ì bản tin Report sẽ chứa một bản ghi TO _I N; nếu không thì bản tin này sẽ chứa bản ghi TO_EX. Nếu bản tin Report chứa các Source List Change Record, tức là bộ đếm truyền lại chế độ lọc cho địa chỉ multicast bằng 0, thì bản tin Report s ẽ chứa một bản gh i ALLOW và một bản ghi BLOCK. Nội dung của các bản ghi này được xây theo b ả ng sau đây: Bản ghi Các nguồn được bao gồm TO_IN Tất cả các nguồn trong trạng thái từng giao diện hiện tại phải được chuyển t i ếp TO_EX Tất cả các nguồn trong trạng th á i từng giao diện hiện tại phải được chặn ALLOW Tất cả các nguồn có trạng thái truyền lại (tất cả các nguồn từ d anh sách truyền lại) phải được chuyển tiếp BLOCK Tất cả các nguồn có trạng thái truyền lại phải được chặn Nếu danh sách nguồn được t í nh toán cho một trong hai bản ghi ALLOW hoặc bản ghi BLOCK là trống, bản ghi đó được loại bỏ kh ỏ i bản tin State Change Report. Chú ý rằng: Khi bản tin State Change Report đầu ti ê n được gửi, bản tin Report đang ch ờ để sáp nhập với bản tin này có thể được đối x ử như là một bản tin Source Change Report với các bản gh i ALLOW và BLOCK là trống (không có nguồn nào có tr ạng thái truyền lại). Việc thiết lập bản tin State Change Report đã l ê n lịch, được kích hoạt bằng cách bật bộ đếm thời gian truyền lại, thay vì thay đổi trạng thái nghe cho từng giao diện, được mô tả trong điều 9.3. 9.2 Xử lý kh i nhận bản tin Query Sau khi nhận được bản t i n Query MLD, nút kiểm tra địa chỉ nguồn của bản tin có phải địa chỉ link-local hợp lệ kh ô ng, trường Ho p Limit có được thiết lập bằng 1 v à tùy chọn Router Alert có được thể hiện trong mào đầu các Hop-by-Hop Options của gói tin IPv6 hay kh ô ng. Nếu bất kỳ kiểm tra nào có lỗi, gói t i n sẽ b ị loại bỏ. Nếu tính hợp lệ của bản tin MLD được xác m i nh, nút bắt đầu xử lý bản tin Query. Thay vì phản hồi ngay lập tức, nút làm trễ phản hồi của nó theo một khoảng thời gian ngẫu nhiên, được giới hạn bởi giá trị tr ễ phản hồi tối đa nhận được từ trường Maximum Response Co de trong bản tin Query nhận được. Một nút có thể nhận nhiều bản tin Query trên các giao diện khác nhau và theo nhiều loại khác nhau (v í dụ như bản tin General Query, bản tin Multicast Address Specific Query hay bản tin Multicast Address and Source Speci fi c Query), mỗi loại có thể yêu cầu trễ phản hồi riêng. Trước khi lập lịch để phản hồi lại một bản tin Query, đầu tiên nút phải xem xét các phản hồi được lập lịch đang ở trạng thái chở trước đó v à trong nhiều trường hợp phải lập lịch cho một phản hồi kết hợp. Do đó, v ớ i mỗi giao diện mà nút đ ả m nhiệm chức năng đối tượng nghe của giao thức MLDv2, nút phải có kh ả năng duy tr ì trạng thái như sau: - Bộ đếm thời gian của giao diện cho việc lập lịch các phản hồi lại những bản tin General Query - Bộ đếm thời gian của địa chỉ multicast cho việc lập lịch các phản hồi lại những bản tin Multicast Address Specific Query (hoặc b ả n tin Multicast Address and Source Specific Query), cho từng địa chỉ multicast mà nút phải báo cáo lại; - Danh sách các nguồn cho từng địa chỉ multicast được báo cáo đ ể phản hồi lại bản tin Multicast Address and Sourc e Specific Query. Khi một bản tin General Query hợp lệ mới đến trên một giao diện, nút k iể m tra có bản ghi trạng thái nghe cho từng giao diện nào để báo cáo hay không. Tương t ự, khi một bản tin Multicast Address Specific Query (bản tin Multicast Address and Source Specific Query) hợp lệ mới đến tr ê n một giao diện, nút phải kiểm tra có bản ghi trạng thái nghe cho từng giao diện tương ứng với địa chỉ multicast (và nguồn) được truy vấn hay không. Nếu có, trễ cho việc phản hồi được lựa chọn ngẫu nhiên trong khoảng (0, [trễ phản hồi tối đa]), trong đó tr ễ phản hồi tối đa nhận được từ trường Maximum Response Code trong bản tin Query nhận được. Các quy tắc sau được sử dụng để xác định rằng bản tin Report cần được lập lịch hay không, và cần lập lịch loại bản tin Report nào. (Các quy tắc được xem xét theo thứ tự và chỉ có quy tắc phù hợp đầu tiên được áp dụng). 1. Nếu có một phản hồi đang ở trạng thái ch ờ cho bản tin General Query trước đó được lập lịch sớm hơn trễ được chọn, thì không cần lập lịch bất kỳ hồi đáp bổ sung nào. 2. Nếu bản tin Query nhận được là bản tin General Query th ì bộ đếm thời gian của giao diện được sử dụng để lập lịch cho b ả n tin hồi đáp lại bản tin General Query ngay sau trễ được lựa chọn. Bất kỳ phản hồi đang ở trạng thái chờ nào t rước đó cho b ả n tin General Query đều b ị hủy bỏ. 3. Nếu bản tin Query nh ậ n được l à bản tin Multicast Address Specific Query hoặc bản t i n Multicast Address and Source Specific Query và không c ó phản hồi đang ở trạng thái ch ờ nào cho bản tin Query trước đó về địa chỉ multicast này thì bộ đếm thời gian của địa chỉ multicast được sử dụng để lập lịch bản tin Report. Nếu bản tin Query nhận được là bản tin Multicast Address and Source specitic Query, danh sách các nguồn được yêu cầu được lưu để sử dụng khi phát đi phản hồi. 4. Nếu có 1 phản h ồ i đang ở trạng thái chờ cho bản tin Query trước đ ó được lập lịch cho địa chỉ mult ic ast này, và bản tin Query mới là bản tin Multicast Address Speci fi c Query hoặc danh sách nguồn được lưu liên quan t ớ i địa chỉ multicast này l à trống, thì d anh sách nguồn cho địa chỉ multicast được xóa và một phản hồi duy nhất được lập lịch , sử dụng bộ đếm thời gian của địa chỉ multicast. Phản hồi mới được lập lịch để gửi đi tại thời gian nhỏ hơn giữa thời gian còn lại cho bản tin Report đang chờ xử lý và trễ đã được chọn. 5. Nếu bản tin Query nhận được là bản tin Multicast Address and Source Specific Query và tồn tại một phản hồi đang ở trạng thái chờ cho địa chỉ multicast này với danh sách nguồn không trống, thì danh sách địa chỉ nguồn multicast được mở rộng để chứa danh sách các nguồn trong bản tin Query mới và phản hồi được lập lịch, sử dụng bộ đếm thời gian địa chỉ multicast. Phản hồi mới được lập lịch đ ể gửi đi tại thời gian nh ỏ hơn giữa thời gian c ò n lại cho bản tin Report đang chờ xử lý và trễ đã được chọn. 9.3 Xử lý khi bộ đếm thời gian kết thúc Có nhi ề u bộ đếm thời gian sẽ gây ra các tác động lên nút đối tượng nghe địa chỉ multicast MLDv2 khi nó kết thúc. Tất cả các tác động này liên quan đến các bản tin Report đang chờ xử lý được lập lịch ở nút. 1. Nếu bộ đếm thời gian của giao diện kết thúc (tức là có một phản hồi đang ở trạng thái chờ cho bản tin General Query), thì một Current State Record được gửi cho từng địa chỉ multicast mà một giao diện cụ thể đang nghe, như điều 7.2. Current State Record mang địa chỉ multicast và c hế độ lọc có liên quan của nó (MODE_IS_INCLUDE hoặc MODE_IS_EXCLUDE) cùng danh sách nguồn. Nhiều Current State Record được đóng gói trong các bản tin Report riêng l ẻ đến một mức độ l ớn nhất có thể. Th u ật toán n à y có thể dẫn đến việc bùng nổ các gói tin khi một nút lắng nghe một lượng lớn các địa chỉ multicast. Thay v ì sử dụng bộ đếm thời gian của giao diện, việc thực thi được khuyến ngh ị truyền những bản tin Report như vậy trong khoảng th ờ i gian (0, [trễ phản hồi tối đa]). Chú ý rằng bất kỳ việc thực thi nào như vậy đều KHÔNG ĐƯỢC gửi đi một bản tin Report ngay sau khi nhận được bản tin General Query. 2. Nếu bộ đếm thời gian của địa chỉ multicast kết thúc và danh sách các địa chỉ nguồn được ghi cho địa chỉ multicast đ ó là trống (tức là, có một phản hồi đang ở trạng thái chờ cho bản tin Multicast Address Specific Query), sau đó nếu và chỉ nếu giao diện đang có trạng thái nghe cho địa chỉ multicast đó, thì một Current State Record sẽ được gửi cho địa chỉ đó. Current State Record n à y mang đ ịa chỉ multicast và chế độ lọc có liên quan của nó (MODE_IS _I NCLUDE hoặc MO D E _I S_EXCLUDE) và danh sách nguồn. 3. Nếu bộ đếm thời gian của địa chỉ multicast kết thúc và danh sách nguồn đã được ghi cho địa chỉ multicast đó không phải là rỗng (tức là có một phản hồi đang ở trạng thái chờ cho bản tin Multicast Address and Source Specific Query), th ì nếu và chỉ nế u giao diện có trạng thái nghe cho địa chỉ multicast đó, th ì các nội dung của Current State Record tương ứng sẽ được xác định từ trạng thái từng giao diện và bản ghi phản hồi đang ở trạng thái chờ, như được quy định trong bảng sau đây: Trạng thái cho từng giao diện Tập hợp các nguồn trong bản ghi phản h ồ i đang ở trạng thái chờ Current State Record INCLUDE (A) EXCLUDE (A) B B I S _I N (A*B) I S _I N (B -A ) Nếu Current State Record là một tập hợp rỗng của các danh sách nguồn, thì không có phản hồi nào được gửi. Sau khi các bản tin Raport đã yêu cầu được tạo ra, các danh sách nguồn có liên quan t ớ i bất kỳ các địa chỉ multicast được báo cáo nào đều được xóa b ỏ . 4. Nếu bộ đếm thời gian cho việc truyền lại của một địa chỉ multicast kết thúc (tức là có một bản tin State Change Report đang ở trạng thái chờ cho đ ị a chỉ multicast đó), các nộ i dung của bản tin Report được xác định như sau: Nếu bản tin Report chứa Filter Mode Change Record, tức là bộ đếm truyền lại chế độ lọc cho đ ịa chỉ multicast đó có một giá trị lớn hơn 0, và nếu chế độ lọc hiện tại của giao diện là INCLUDE, thì bản t i n Report s ẽ chứa bản ghi TO _I N, ngược lại bản tin này sẽ chứa bản ghi TO_EX. Trong cả ha i trường hợp, bộ đếm truyền lại chế độ lọc cho địa chỉ multicast đó được giảm một đơn v ị sau khi truyền bản tin Report. Nếu bản tin Report chứa các Source List Change Record, tức là bộ đếm truyền l ại chế độ lọc cho địa chỉ multicast đó bằng 0, th ì bản này s ẽ chứa bản ghi ALLOW hoặc BLOCK. Nội dung của các bản ghi này được xây dựng theo bảng dưới đây: Bản ghi Các nguồn được bao gồm TO_IN Tất cả các nguồn t rong trạng thái từng giao diện hiện tại phải được chuyển tiếp. TO_EX Tất cả các nguồn trong trạng thá i t ừ ng giao diện hiện tại phải được chặn. ALLOW T ấ t c ả các nguồn có trạng thái truyền lại (tức là tất cả các nguồn từ danh sách truyền lại) phải được chuyển tiếp. Với mỗi nguồn nằm trong bản tin Report, bộ đếm truyền lại nguồn của nó được giảm 1 đơn v ị sau khi truyền bản tin này. Nếu bộ đếm tiến về 0, nguồn được xóa khỏi danh sách truyền lại cho địa chỉ multicast đó. BLOCK Tất cả các nguồn có trạng thái truyền lại (tức là tất cả các nguồn từ d anh sách truyền lại) phải được chặn. Với mỗi nguồn nằm trong bản tin này, bộ đếm truyền lại nguồn của nó được giảm 1 đơn vị sau khi truyền bản tin Report. Nếu bộ đếm tiến về 0, ng uồn sẽ bị xóa kh ỏ i danh sách truyền lại cho địa chỉ multicast đó. Nếu danh sách nguồn được tính toán cho bản gh i ALLOW hoặc bản ghi BLOCK là rỗng, th ì bản ghi đó sẽ bị loại bỏ khỏi bản tin State Change Report. 10 Mô tả của giao thức cho router multicast Mục đích của MLD là cho phép router multicast xác định được những địa chỉ multicast nào có đối tượng nghe trên liên k ế t được kết nối trực tiếp. So với MLDv1, MLDv2 bổ sung khả năng cho phép router multicast xác định được những nguồn nào có đối tượng nghe thuộc các nút lân cận, đối với các gói tin được gử i tới bất kỳ địa chỉ multicast cụ thể nào. Các thông tin thu thập b ở i MLD được cung cấp cho giao thức định tuyến mu l ticast đ ể router sử dụng nhằm đảm bảo các gói tin multicast được phân phối t ớ i tất cả các liên kết có đ ối tượng mong muốn nghe. Phần này mô tả chức năng MLDv2 được thực hiện bởi router multicast. Các router multicast có thể trở thành các đối tượng nghe địa chỉ multicast, và do đó cũng thực hiện chức năng đối tượng nghe multicast của MLDv2, như được m ô tả trong điều 9. Một rou t er mu lt icast thực thi giao thức trên mỗi liên kết được kết nối trực tiếp của nó. Nếu một router multicast có nhiều giao diện kết nối tới cùng một liên kết, nó chỉ c ầ n thực thi giao thức này qua một trong số các giao diện đó. Với mỗi giao diện mà qua đó router thực thi giao thức MLD, router phải cấu h ì nh giao diện đó để nghe tất cả các địa chỉ multicast tầng liên kết (link-layer) trong IPv6. Ví dụ, router kết nối Ethernet phải thiết lập bộ lọc tiếp nhận đ ịa chỉ Ethernet của nó ch ấ p nhận tất cả các địa chỉ multicast Ethernet bắt đầu với giá trị hexa là 3333 [RFC2464]; trong trường hợp giao diện Ethernet không hỗ trợ việc lọc dải địa chỉ như vậy, th ì nó phải được cấu h ì nh để chấp nhận tất cả các địa chỉ multicast Ethernet, nhằm đáp ứng các yêu cầu của MLD. Trên m ỗ i giao diện sử dụng giao thức này, router PHẢI cho phép tiếp nhận địa chỉ multicast t ấ t c ả các router có khả n ă ng hỗ trợ MLDv2 trong phạm vi liên kết từ tất cả các ng uồ n, và PHẢI thực hiện chức năng đ ố i tượng nghe địa chỉ multicast của MLDv2 với địa chỉ này trên giao diện đó. Các router multicast chỉ cần biết trên một liên kết được kết nối có tối th iể u một nút đang nghe các gói tin cho một địa chỉ multicast cụ thể từ một nguồn cụ thể; một router multicast không cần theo dõi các nhu cầu của từng nút lân c ậ n một cách riêng l ẻ . MLDv2 được tương thích ngược với giao thức MLDv1. Chi tiết được mô tả trong điều 11. 10.1 Các điều kiện ch o những bản tin Query Cách xử lý của router thực thi giao thức MLDv2 phụ thuộc v à o việc có nhi ề u router multicast trên cùng một mạng con hay không. Trong tr ư ờng hợp đ ó , cơ chế bầu chọn Querier được sử dụng để lựa chọn một router multicast duy nhất đóng vai trò l à Querier. Tất cả các router multicast trên mạng con lắng nghe các bản tin được gửi từ các đối tượng nghe multicast và duy tr ì cùng một trạng thái thông tin nghe multicast để nếu Queri e r hiện tại gặp sự cố, các router multicast này có thể đảm nhiệm chức năng Querier một cách nhanh chóng và chính xác. Tuy nhiên, chỉ có duy nhất một Quer i er gử i địnhkỳ hoặc kh ở i tạo các bản tin Query trên miền mạng. Quer i er định kỳ gửi các bản tin General Query để yêu cầu thông tin của đối tượng nghe địa chỉ multicast từ một liên kết được kết nối. Các bản tin Query này được sử dụng để thiết lập và l à m mới trạng thái đối tượng nghe địa chỉ multicast của router tr ê n các liên kế t được kết nối. Các nút phản hồi lại các bản tin Query này bằng cách thông báo trạng thái nghe địa chỉ multicast của ch ú ng (và danh sách các nguồn mà chúng đang nghe) qua các Current State Record hiện tại trong bản tin Report MLDv2. Với chức năng đối tượng nghe địa chỉ multicast, một nút c ó thể thể hiện mối quan tâm trong việc có nghe các lưu lượng đến từ các nguồn nhất định hay không. Kh i trạng thái nghe mong muốn của nút thay đổi, nút s ẽ thông báo các thay đổi này bằng cách sử dụng các Filter Mode Change Record hoặc Source List Change Record. Các bản gh i này chỉ th ị một thay đổi trạng thái r õ ràng về địa chỉ multicast tại một nút trong danh sách nguồn của Multicast Address Record hoặc chế độ lọc của nó. Khi nút kết thúc việc nghe địa chỉ multicast hoặc không còn nhu cầu nhận lưu lượng từ một nguồn cụ thể, Querier phải truy vấn các đối tượng nghe khác của địa chỉ multicast hoặc của nguồn trước khi xóa địa chỉ multicast (hoặc nguồn) khỏi trạng thái đối tượng nghe địa chỉ mu l ticast của n ó và ngừng truyền lưu lượng. Để cho phép tất cả các nút trên một liên kết phản hồi lại những sự thay đ ổ i trong việc nghe đ ịa chỉ multicast, Querier sẽ gửi đi các bản tin Query cụ thể. Một bản tin Multicast Address Specific Query được gửi để xác minh rằng không có nút nào đang nghe 1 địa chỉ multicast xác định hoặc đ ể thiết lập lại trạng thái nghe cho 1 địa chỉ multicast xác định. Các bản tin Multicast Address Specific Query được gửi kh i Querier nhận được State Change Record chỉ th ị rằng một nút ngừng theo dõi một địa chỉ multicast. Chúng cũng được gửi để cho phép router chuyển nhanh từ chế độ EXCLUDE sang chế độ INCLUDE, trong trường hợp nhận được một State Change Recor d yêu cầu việc chuyển đ ổ i này. Bản tin Multicast Address and Source Specific Query được sử dụng đ ể xác minh rằng không có nút nào trên liên kết đang nghe lưu lượng từ một tập hợp nguồn cụ thể. Các bản tin Mul t icast Address and Source Specific Query liệt kê các nguồn cho một địa chỉ multicast cụ thể không còn nhu cầu được chuyển tiếp nữa. Bản tin Query này được Querier gửi đ i , đ ể xác định có hay không một (các) nút đang nghe các gó i tin được gửi đến đ ịa chỉ multicast cụ thể từ các đ ịa chỉ nguồn cụ thể. Các bản tin Multicast Address and Source Specific Query chỉ được gửi để phản h ồ i lại các State Change Record mà không bao giờ phản hồ i lạ i các Current State Record. 10.2 Trạng thái MLD được duy trì bởi các router multicast Các router multicast thực th i giao thức MLDv2 lưu trạng thái cho từng địa chỉ multicast đối với từng liên kết được kết nối. Trạng thái địa chỉ multicast này bao gồm 1 chế độ lọc, một danh sách các nguồn và các bộ đếm thời gian khác nhau. Đối với từng li ê n kết được kết nối mà MLD đang thực hiện, router multicast ghi lại trạng thái nghe cho từng liên kết đó. Trạng thái đ ó bao g ồ m một tập hợp các b ả n ghi theo dạng sau: (Địa chỉ multicast IPv6, chế độ lọc, Ch ế độ lọc của router, (các bản ghi nguồn)) Mỗi một bản gh i nguồn được biểu diễn theo dạng: (Địa chỉ nguồn iPv6, bộ đếm thời gian c ủ a nguồn) Nếu tất cả các nguồn cho một địa chỉ multicast đang được lắng nghe, thì chế độ lọc của router được thiết lập sang EXCLUDE v ớ i danh sách bản ghi nguồn không chứa địa chỉ nguồn nào. Điều này có nghĩa rằng tất cả các ng uồ n cho địa chỉ multicast này đều được chuyển tiếp. Trường hợp này của MLDv2 tương đương với trạng thái nghe của MLDv1. 10.2.1 Đ ịn h nghĩa các chế độ lọc của router Để giảm trạng thái nội bộ, các router MLDv2 d uy t rì một chế độ l ọc đối với từng địa chỉ multicast trên t ừng liên kết được kết nối. Chế độ lọc này được sử dụng để t ổ ng hợp tất cả các trạng thái nghe địa chỉ multicast thành một tập hợp nhỏ nh ấ t chứa trạng thái nghe của tất cả các nút. Chế độ lọc có thể thay đổi tương ứng với việc nhận các loại Multicast Address Record cụ thể hoặc khi các điều kiện cho một bộ đếm thời gian nào đó x ả y ra. Trong các phần tiếp theo, thuật ngữ “chế độ lọc của router” được sử dụng để đề cập đến chế độ lọc của một địa chỉ multicast cụ thể trong router. Điều 10.4 mô tả những thay đổi về chế độ lọc của router cho từng Multicast Address Record nhận được. Một router ở chế độ INCLUDE cho một địa chỉ multicast cụ thể trên 1 giao diện xác định nếu t ấ t cả các đối tượng nghe trên liên kết đang theo dõi địa chỉ đó ở chế độ INCLUDE. Trạng thái router được biểu diễn bằng INCLUDE (A), trong đó A được gọi là “danh sách INCLUDE”. Danh sách INCLUDE là một tập hợp các nguồn mà tồn tại tối thi ể u một đối tượng nghe trên liên kết có yêu cầu muốn nhận gói tin. Tất cả các nguồn trong danh sách INCLUDE sẽ được chuyển tiếp bởi router. Bất kỳ nguồn nào không nằm trong danh sách INCLUDE s ẽ bị router chặn lại. Một router sẽ có chế độ lọc là EXCLUDE cho một địa chỉ multicast cụ thể trên một giao diện xác định nếu có tối thiểu một đối tượng nghe trong chế độ EXCLUDE đang có nhu cầu nghe địa chỉ này trên liên kết. Khi nhận được một Multicast Address Record, chế độ lọc của router cho địa chỉ multicast đó được cập nhật để kiểm soát tất cả các nguồn được yêu cầu sử dụng ít trạng thái nhất. Theo quy tắc, kh i nhận được Multicast Address Record có chế độ lọc EXCLUDE thì chế độ lọc của router cho địa chỉ multicast đó sẽ được thiết lập thành EXCLUDE. Tuy nhiên, nếu tất cả các nút với Multicast Address Record có chế độ lọc được thiết lập là EXCLUDE dừng báo cáo, thì chế độ lọc của router cho địa chỉ multicast đó sẽ được chuyển ngược lại chế độ IN C LUDE. Việc chuyển trạng thái này xảy ra khi bộ đếm thời gian chế độ lọc kết thúc, và được g i ả i thích cụ thể trong đ iề u 10.5. Khi router ở trong chế độ EXCLUDE, trạng thái router được biểu diễn bằng EXCLUDE (X, Y ), trong đ ó X là “ danh sách được yêu cầu” và Y là “danh sách EXCLUDE”. Tất cả các nguồn nằm ngoài danh sách EXCLUDE sẽ được chuyển tiếp bởi router. Danh sách được yêu cầu không ảnh hưởng đến việc chuyển tiếp này. Tuy nhiên, nó vẫn được duy trì v ì một số lý do, được giải thích trong điều 10.2.3. Việc xử lý chính xác trạng thái router ở cả chế độ INCLUDE và EXCLUDE, theo các bản tin Report nhận được được thể hiện chi tiết trong các b ả ng điều 10.4.1 và 10.4.2. 10.2.2 Định nghĩa các bộ đếm thời gian cho chế độ lọc Bộ đếm thời gian cho chế độ lọc chỉ được sử dụng khi router ở chế độ EXCLUDE cho một địa chỉ multicast cụ thể, và nó thể hiện khoảng thời gian cho chế độ lọc EXCLUDE của router đối với địa chỉ multicast đó, sau khi hết thời gian này router sẽ chuy ể n sang chế độ INCLUDE. Bộ đ ế m thời gian cho c hế độ lọc là một bộ đếm thờ i gian đếm giảm dần về ngư ỡ ng nhỏ hơn 0. Bộ đếm thời gian cho chế độ lọc tồn tại cho từ ng Multicast Address Record. Các bộ đếm thời gian cho chế độ lọc được cập nhật theo các loại Multicast Address Record nhận được. Nếu một bộ đếm thời gian cho chế độ lọc kết thúc mà chế độ lọc của router cho một địa chỉ multicast là EXCLUDE, th ì không còn đối tượng nghe nào ở chế độ EXCLUDE tr ê n liên kết được kết nối. Tại thời đi ể m này, router chuyển sang chế độ lọc INCLUDE. Điều 10.5 mô tả các hoạt động xảy ra khi bộ đếm thời gian cho chế độ lọc của chế độ EXCLUDE kết thúc. Bảng sau tổng hợp ý nghĩa của bộ đếm th ời gian. Điều 10.4 mô tả chi tiết v ề việc thiết lập bộ đếm thời gian cho chế độ lọc đối với từng loại Multicast Address Record nhận được. Chế độ lọc của router Giá trị bộ đếm thời gian cho chế độ lọc Các hoạt động / khuyến ngh ị INCLUDE EXCLUDE EXCLUDE Không được sử dụng Bộ đếm thời gian > 0 Bộ đếm thời gian = 0 Tất cả các đối tượng nghe ở chế độ EXCLUDE Tối thiểu một đối tượng nghe ở chế độ EXCLUDE Không còn đối tượng nghe nào ở chế độ EXCLUDE cho một địa chỉ multicast . Nếu danh sách được yêu cầu là rỗng thì x ó a Multicast Address Record. Nếu không, chuyển sang chế độ lọc INCLUDE, các nguồn trong danh sách được yêu cầu được chuyển sang danh sách INCLUDE, và danh sách EXCLUDE sẽ bị xóa b ỏ . 10.2.3 Định nghĩa các bộ đếm thời gian cho nguồn Bộ đếm thời gian cho nguồn là một bộ đếm thời gian đếm gi ả m dần về ngưỡng nhỏ hơn 0. Mỗi bản ghi nguồn có một bộ đếm thời gian cho nguồn đó. Các bộ đếm th ờ i gian cho nguồn được cập nhật theo loại và chế độ lọc của Multicast Address Record nhận được. Điều 10.4 mô tả việc thiết lập bộ đếm thời gian cho nguồn đối với từng loại Multicast Address Record nhận được. Trong các phần sau của tiêu chuẩn này, các quy ước v ề chữ viết tắt như sau được sử dụng. B i ến MALI viết tắt của khoảng thời gian nghe địa chỉ multicast (Multicast Address L i s t ening Interval), là khoảng thời gian mà trạng thái nghe địa chỉ multicast sẽ kết thúc. Biến LLQT viết tắt của thời gian truy vấn đối tượng nghe cuối cùng (Last Listener Query Time), là thời gian tổng cộng mà rou t er đợi bản tin Report, sau khi Querier gửi đi bản tin Query đầu tiên. Trong suốt khoảng thời gian này, ro u ter sẽ truyền lại [LLQC] -1 bản tin Query. LLQT thể hiện “trễ rời nhóm”, hoặc sai lệch thời gian giữa việc truyền t hay đổi trạng thái đố i tượng nghe và việc thay đổi th ô ng tin khi truyền qua giao thức định tuyến. Nếu router có chế độ lọc INCLUDE thì một nguồn có thể sẽ được bổ sung vào danh sách INCLUDE hiện tại nếu có một đối tượng nghe ở chế độ INCLUDE gửi đ i bản t i n Curre n t State Report hoặc bản tin State Change Report chứa nguồn này. Mỗi nguồn từ danh sách INCLUDE được li ê n kết với một bộ đếm thời gian cho nguồn - được cập nhật bất cứ khi nào một đối tượng nghe trong chế độ INCLUDE gử i đi một bản tin Report để xác nhận mối quan tâm của đối tượng nghe này tới một địa chỉ nguồn cụ thể. Nếu bộ đếm thời gian cho nguồn từ danh sách INCLUDE kết thúc, nguồn s ẽ bị xóa khởi danh sách INCLUDE. Nếu không c ò n bản ghi nguồn nào nữa, Multicast Address Record sẽ bị xóa khỏi router. Bên cạnh phương thức “ rời nhóm mềm” này, còn 1 phương thức “rời nhóm nhanh” của MLDv2; được dựa trên việc sử dụng bộ đếm thời gian cho nguồn. Khi một nút ở trong chế độ INCLUDE muốn ngừng nghe một nguồn cụ thể, tất cả các router multicast trên liên kết ph ả i hạ thấp bộ đếm thời gian của m ì nh cho nguồn đó xuống thành một khoảng thời gian nhỏ bằng LLQT mili-giây. Querier sau đó gửi đi một bản tin Multicast Address and Source Specific Query, để xác minh rằng có đối tượng nghe n à o khác cho nguồn đ ó còn trên liên kết nữa hay không. Nếu nh ậ n được bản tin Report tương ứng trước khi bộ đếm thời gian kết thúc, tất cả các router multicast trên liên kết sẽ cập nhật bộ đếm thời gian cho nguồn của m ìn h. Nếu không, nguồn sẽ bị xóa khỏi danh sách INCLUDE. Việc xử lý danh sách INCLUDE theo bản tin Report nhận được được cụ thể trong bảng điều 10.4.1 và 10.4.2. Bộ đếm thời gian cho nguồn được xử l ý độc lập khi chế độ lọc của router cho địa chỉ multicast là chế độ EXCLUDE. Với các nguồn trong d anh sách được yêu cầu có bộ đếm thời gian nguồn đang chạy th ì các nguồn này được chuy ể n tiếp bởi router. Với các nguồn trong danh sách EXCLUDE có bộ đếm thời gian cho nguồn được thiết lập bằng 0 thì những nguồn này sẽ bị router chặn lại. Nếu bộ đếm thời gian của một nguồn trong danh sách được yêu cầu kết th ú c thì nguồn này sẽ được chuy ể n sang danh sách EXCLUDE. Sau đó router thông báo cho các giao thức định tuyến rằng không còn đối tượng nghe nào trên liên kết có nhu cầu nhận lưu lượng từ nguồn này nữa. Router phải duy trì danh sách được yêu cầu v ì 2 lý do sau: - Để theo dõi các nguồn mà đối tượng nghe có chế độ lọc INCLUDE đang lắng nghe. Điều này nhằm đảm bảo việc chuyển đổi liền mạch của router sang chế độ INCLUDE, khi không còn đối tượng nghe nào ở chế độ EXCLUDE nữa. Việc chuyển đổi này s ẽ không làm gián đoạn lưu lượng tới những đối tượng nghe ở chế độ INCLUDE vẫn đang theo dõi địa chỉ multicast đó. Do đó , tại thời đi ể m chuyển đổi, danh sách được yêu cầu s ẽ chứa tập hợp các nguồn mà các nút có chế độ lọc INCLUDE đã yêu cầu một cách rõ ràng. Khi router chuyển sang chế độ INCLUDE, các nguồn trong danh sách được yêu cầu sẽ chuyển sang danh sách INCLUD E , và d anh sách EXCLUDE s ẽ b ị xóa bỏ. Trước khi chuyển, danh sách được yêu cầu có thể chứa những dự đoán không ch í nh xác về các nguồn mà những đối tượng nghe trong chế độ INCLUDE đang nghe - có thể quá lớn hoặc quá nh ỏ . Những dự đoán không ch í nh x ác này dựa theo thực tế rằng danh sách được yêu cầu cũng được sử dụng cho mục đích ngăn chặn nhanh chóng, như được mô tả dưới đây. Nếu tồn tại một yêu cầu chặn nhanh như vậy, nhiều nguồn có thể b ị xóa khỏi danh sách được yêu cầu (như được chỉ ra trong điều 10.4.1 và 10.4.2) nhằm hạn chế trạng thái rouler. Tuy nhiên, trong mỗi trường hợp như vậy, bộ đếm thời gian cho chế độ lọc cũng được cập nhật. Do đó, trước kh i thực hiện chuyển đổi, các đối tượng nghe trong chế độ INCLUDE sẽ có đủ thời gian để xác minh lại mối quan tâm của các đối tượng này với các ng uồ n bị loại trừ, và thiết lập lại danh sách được yêu cầu phụ hợp. Giao thức đảm bảo rằng khi xảy ra chuyển đổi sang chế độ I NCLUDE, danh sách được yêu cầu là chính xác. - Để cho phép việc ch ặ n nhanh các nguồn không được chặn trước đó. Nếu router nhận được bản tin Report chứa một yêu cầu như vậy, các nguồn có liên quan phải được thêm vào danh sách được yêu cầu. Các bộ đếm thời gian của chúng được thiết lập về một giá trị nhỏ bằng LLQT m ili -giây, và một bản tin Multicast Address and Source Specific Query được gửi bởi Querier, đ ể kiểm tra rằng còn nút còn trên liên kết vẫn c ò n mong muốn nghe các nguồn này nữa không. Nếu không nút nào xác nhận mối quan t âm của n ó tới việc nhận lưu lượng từ nguồn cụ thể n à y nữa, thì bộ đếm thời gian cho nguồn này sẽ kết thúc. Sau đó , nguồn này sẽ được chuyển từ danh sách được yêu cầu sang d anh sách EXCLUDE. Từ thời điểm đó, nguồn sẽ bị router chặn lại. Việc xử lý của trạng thái router có chế độ EXCLUDE, theo các bản tin Report nhận được, được cụ thể hóa trong điều 10.4.1 và 10.4.2. Khi chế độ lọc của router cho địa chỉ multicast là EXCLUDE, bản ghi nguồn chỉ được xóa khi bộ đếm thời gian cho chế độ lọc kết thúc, hoặc khi một bản ghi địa chỉ nguồn mớ i nhận được làm thay đổi danh sách b ả n ghi nguồn của router. 10.3 Các quy tắc chuyển tiếp nguồn MLDv2 cụ thể Khi một router multicast nhận được một gói dữ liệu từ một nguồn nào đó có đích là một địa chỉ multicast cụ thể, router phải quyết định có chuyển tiếp gói dữ liệu này sang liên kết được kết nối hay không. Giao thức định tuyến multicast được sử dụng để điều phối quyết định này, và sẽ sử dụng các thông tin MLDv2 để đảm bảo rằng tất cả các nguồn/ các địa chỉ multicast mà có đối tượng nghe t rên một liên kết đều được chuyển tiếp sang liên kết đó. Các th ô ng tin MLDv2 không ph ủ định các thông tin định tuyến multicast, ví dụ, nếu chế độ lọc MLDv2 cho một địa chỉ multicast là EXCLU D E, router có thể vẫn chuyển tiếp các gói tin có nguồn được loại trừ này sang liên kết. Bảng sau mô tả các khuyến nghị chuyển tiếp được tạo bởi MLDv2 tới giao thức đ ị nh tuyến cho các lưu lượng được kh ở i tạo từ một nguồn có đích là một địa chỉ multicast. Đây cũng l à tổng hợp các hành động diễn ra khi kết th ú c bộ đếm thời gian nguồn d ựa trên chế độ lọc của router của một địa chỉ multicast. Chế độ lọc của router Giá trị bộ đếm thời gian cho nguồn Hành động / khuyến nghị INCLU D E Bộ đếm thời gian > 0 Đề nghị chuyển tiếp lưu l ượng từ ngu ồ n INCLUDE Bộ đếm thời gian == 0 Đề nghị dừng chuyển tiếp lưu lượng từ nguồn và xóa b ỏ bản ghi nguồn. Nếu không có bản ghi nguồn nào, thì xóa Multicast Address Record EXCLUDE Bộ đếm thời gian > 0 Đề nghị chuyển tiếp lư u lượng từ nguồn EXCLUDE Bộ đếm thời gian == 0 Đề nghị không chuyển tiếp lưu lượng từ ng uồ n. Chuyển nguồn từ d anh sách được yêu cầu sang danh sách EXCLUDE (không xóa bản ghi nguồn) EXCLUDE Không có nguồn nào Đề ngh ị chuyển tiếp lưu lượng từ tất cả các nguồn 1 0 .4 X ử l ý khi nhận bản tin Report Khi nhận được bản tin Report MLD, router sẽ kiểm tra: địa chỉ nguồn của bản tin có phải đ ịa chỉ link-local hợp lệ, trư ờ ng Hop Limit có được th i ết lập bằng 1, và tùy chọn Router Al e rt có xuất hiện trong mào đầu Hop-by-Hop Options của gói tin IPv6 hay không. Nếu bất kỳ kiểm tra nào b ị lỗi, thì gói tin sẽ bị bỏ qua. Nếu tính hợp lệ của bản tin MLD được xác minh, router sẽ bắt đầu xử lý bản tin Report. 1 0 .4.1 Khi nhận các Current State Record Kh i nhận được các Current State Record, router cập nhật cả bộ đếm thời gian cho chế độ lọc và bộ đếm thời gian cho nguồn của nó. Trong một số trường hợp, việc nhận được một loại Multicast Address Record sẽ làm thay đổi chế độ lọc của router cho một địa chỉ multicast. Bảng dưới đây mô tả các hành động x ả y ra với trạng thái của router khi nhận được Current State Record, bao gồm cả trạng thái và các bộ đếm thời gian. Nếu router ở trong chế độ lọc INCLUDE cho một địa chỉ multicast, ký hiệu INCLUDE (A) sẽ được sử dụng, trong đ ó A biểu hiện danh sách INCLUDE có liên quan. Nếu router ở trong chế độ EXCLUDE cho một địa chỉ multicast cụ thể th ì sử dụng ký hiệu EXCLUDE (X, Y), trong đó X th ể hiện danh sách được yêu cầu và Y th ể hiện danh sách EXCLUDE có liên quan. Trong phần “hành động” của bảng trạng thái router, thì ký hiệu ‘(A)=J' có nghĩa là tập hợp A của các b ả n ghi nguồn sẽ c ó bộ đếm thời gian cho nguồn được thiết lập bằng giá trị J. “Xóa A” có nghĩa rằng tập hợp A các bản gh i nguồn sẽ được xóa. “Bộ đếm thời gian cho chế độ lọc = J” có nghĩa rằng giá trị của bộ đếm thời gian cho chế độ lọc đối với địa chỉ multicast sẽ được thiết lập bằng giá trị J. Trạng thái router Bản tin Report nhận được Trạng thái router mới Hành động INCLUDE (A) IS_ IN (B) INCLUDE (A +B ) (B)=MALI INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0 Xóa (A-B) Bộ đếm thời gian cho chế độ lọc = MA LI EXCLUDE (X,Y) IS_ IN ( A ) EXCLUDE (X+A, Y-A) (A) = MALI EXCLUDE (X,Y) IS_EX ( A ) EXCLUDE (A-Y,Y*A) (A - X - Y) = MALI Xóa (X-A) Xóa (Y-A) Bộ đếm thời gian cho chế độ lọc = MALI 10.4.2 Khi nhận các F il ter Mode Change Record và Source List Change Record Khi có một thay đổi trong trạng thái toàn cục của địa chỉ multicast xảy ra tại 1 nút, nút này s ẽ gửi đi Source List Change Record hoặc là Filter Mode Change Record cho địa chỉ multicast đó. Đối với các Current State Record, các router phải xử lý được các bản ghi này và thay đổi trạng thái của chính chúng để phản hồi lại trạng thái nghe mới của liên kết. Các Querier phải truy vấn các nguồn hoặc các địa chỉ multicast mà không còn được yêu cầu chuyển liếp nữa. Khi router gửi hoặc nhận một bản tin Query cho một tập hợp cụ th ể các nguồn, nó giảm bộ đếm thời gian nguồn của mình cho các địa chỉ đó tới một g i á tr ị thời gian bằng LLQT theo đơn vị mi li- giây. Nếu các Multicast Address Record nhận được để phản hồi lại các bản tin Query cho việc nghe các nguồn được truy vấn, thì các bộ đếm thời gi a n tương ứng sẽ được cập nhật. Các bản tin Multicast Address Specific Query cũng có thể được sử dụng để cho phép router chuyển đổi nhanh chóng từ chế độ EXCLUDE sang chế độ INCLUDE, trong trường hợp nhận được một Multicast Address Recor d yêu cầu việc chuyển đổi này. Bộ đếm thời gian cho chế độ lọc đối với địa chỉ multicast đó được làm giảm đến một giá trị bằng LLQT theo mili-giây. Nếu nhận được bất kỳ Multicast Address Record nào có chế độ EXCLUDE mong muốn nghe địa chỉ multicast trên trong khoảng thời gian này, thì bộ đếm thời gian cho chế độ lọc sẽ được cập nhật và yêu cầu giao thức đ ị nh tuyến chuyển tiếp địa chỉ multicast mà không gặp bất kỳ gián đoạn nào. Nếu không, router s ẽ chuyển sang chế độ INCLUDE cho địa chỉ multicast đó. Trong suốt LLQT (theo m ili -g i ây), router MLD tiếp tục yêu cầu giao thức định tuyến chuyển tiếp lưu lượng từ những địa chỉ multicast hoặc những nguồn được truy vấn. Router sẽ không thực hiện việc này nếu sau LLQT theo milli-giây mà không nh ậ n được một bản gh i nào thể hiện mối quan tâm đến địa chỉ hoặc các nguồn được truy vấn, sau đó router có thể loại b ỏ địa chỉ multicast hoặc các nguồn này kh ỏi liên kết. Bảng dưới đây mô tả các thay đổi trong trạng thái địa chỉ multicast và các hành động xảy ra khi nhận được các Filter Mode Change hoặc Source List Change Record. Bảng này cũng mô tả các bản tin Query được gửi b ởi Querier khi một b ả n tin Report cụ th ể nhận được. Các bản tin Query gửi đi được biểu diễn bằng các ký hiệu. Ký hiệu ‘Q(MA)' để mô tả việc gửi b ả n tin Multicast Address Speci fi c Query tới một đ ịa chỉ multicast MA. Ký hiệu 'Q(MA,A)’ để mô tả việc gửi bản tin Multicast Address and Source Spec ifi c Query t ớ i địa chỉ multicast MA với danh sách nguồn A. Nếu danh sách nguồn A không chứa nguồn nào vì một hành động nào đó (ví dụ A*B) thì không có bản tin Query nào được gửi. Để duy tr ì tính ổn định củ a giao thức, các bản tin Query được định nghĩa trong cột hành động của bảng sau cần được truyền trong [LLQC] lần mỗi bản tin được gửi đi sau mỗi khoảng thờ i gian bằng [LLQI]. Nếu trong khi lập lịch cho các bản tin Query mới, tồn tại các bản tin Query đang ở chế độ chờ được gửi cho cùng 1 địa chỉ multicast, thì các bản tin Query mới và các bản tin Query đang được chờ sẽ được gộp lại. Ngo à i ra, các bản tin Report của host nhận được cho một địa chỉ multicast có các bản tin Query đang ở trạng thái chờ có thể ảnh hưởng tới nội dung của các bản tin Query đó. Điều 10.6.3 mô tả tiến trình xây dựng v à duy t rì trạng thái của các bản tin Query đang chờ. Trạng thái router Bản tin Report nhận được Trạng thái router mới Hành động INCLUDE (A) CHO PHÉP (B) INCLUDE (A+B) (B)= MALI INCLUDE (A) CH Ặ N (B) INCLUDE (A) Gửi đi Q(MA,A*B) INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A) = 0 Xóa (A-B) Gửi đi Q(MA,A*B) Bộ đếm thời gian cho chế độ lọc = MALI INCLUDE (A) TO_IN INCLUDE (A+B) (B) = MALI Gửi đi Q(MA,A-B) EXCLUDE (X,Y) CHO PHÉP (A) EXCLUDE(X+A,Y-A) (A)= MALI EXCLUDE (X,Y) CHẶN (A) EXCLUDE (X+(A-Y),Y) (A-X-Y) = bộ đếm thời gian cho chế độ lọc Gửi đi Q(MA,A-Y) EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y) = bộ đếm thời gian cho chế độ lọc Xóa (X-A) Xóa (Y-A) Gửi đi Q(MA,A-Y) Bộ đếm thời gian cho chế độ lọc = MALI EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=MALI Gửi đi Q(MA,X-A) Gửi đi Q(MA) 10.5 Chuyển đổi các chế độ lọc của router Bộ đếm thời gian cho chế độ lọc được sử dụng như một cơ chế cho việc chuyển đổi chế độ lọc của router từ EXCLUDE sang INCLUDE. Khi bộ đếm thời gian cho chế độ lọc EXCLUDE của router kết thúc, router giả định rằng không có nút nào có chế độ lọc EXCLUDE hiện diện trong liên kết được kết nố i . Do đó, router chuyển sang chế độ lọc INCLUDE với địa chỉ multicast Một router sử dụng các nguồn trong danh sách được yêu cầu làm trạng thái của nó cho việc chuyển sang chế độ lọc INCLUDE. Các nguồn trong danh sách được yêu cầu được chuyển sang danh sách INCLUDE, trong khi các nguồn trong danh sách EXCLUDE bị xóa bỏ. V í dụ, nếu trạng thái của router cho một địa chỉ multicast là EXCLUDE(X,Y) và bộ đếm thời gian cho chế độ lọc đối với địa chỉ multicast đó kết thúc, router sẽ chuyển sang chế độ lọc INCLUDE với trạng thái INCLUDE(X). Nếu tại thời điểm chuyển đổi danh sách được yêu cầu (X) là rỗng. Multicast Address Record sẽ b ị xóa kh ỏ i router. 10.6 Các xử lý khi nh ậ n bản tin Query Khi nhận được một bản tin Query, router kiểm tra địa chỉ nguồn của bản tin c ó phải là một địa chỉ link-local hợp lệ, trường Hop Limit có được thiết l ậ p bằng 1, và tùy chọn Router Alert có xuất hiện trong mào đầu Hop - by-Hop Options của gói tin IPv6 hay kh ô ng. Nếu b ấ t kỳ kiểm tra nào có lỗi, gói tin sẽ được loại bỏ. Nếu tính hợp lệ được xác minh, router s ẽ b ắ t đầu xử lý bản tin Quer y . 10.6.1 C ậ p nhật bộ đếm thời gian MLDv2 sử dụng cờ S (chặn xử lý phía router) để đảm bảo tính ổ n định như được giải thích trong điều 5.1. Khi một router gửi đi hoặc nhận một bản tin Query có cờ S r õ ràng, nó phải cập nhật bộ đếm thời gian của mình để phản hồi lại giá trị kết thúc chính xác cho địa chỉ multicast và nguồn đang được truy vấn. Bảng tiếp theo mô tả các xử lý của bộ đếm thời gian khi gửi và nhận một bản tin Multicast Address Specific Query hoặc bản tin Multicast Address and Source Specific Query với cờ S không được thiết lập. Truy vấn Xử lý Q(MA,A) Bộ đếm thời gian nguồn cho các nguồn trong A được hạ thấp về LLQT Q(MA) Bộ đ ế m thời gian cho chế độ lọc được hạ về LLQT Khi một router gửi và nhận một bản tin Query v ớ i cờ S được thiết lập, nó sẽ không cập nhật bộ đếm thời gian của m ì nh. 10.6.2 Bầu chọn Querier Với từng mạng con, MLDv2 sẽ chỉ lựa chọn một router duy nhất ở trạng thái Querier; tất cả các router khác trong mạng con sẽ ở trạng thái non-Querier. MLDv2 s ử d ụng cơ chế bầu chọn Queri e r dựa trên địa chỉ IPv6 giống như MLDv1. Khi một router bắt đầu hoạt động trong một miền mạng, theo mặc định nó sẽ xem m ì nh nh ư một Querier. Do đó, nó sẽ gửi đi nhiều bản tin General Query cách nhau một khoảng thời gian nhỏ (xem điều 12.6 và 12.7). Khi một router nhận một bản tin Query có địa chỉ IPv6 thấp hơn đỉa chỉ I Pv6 của nó, nó thiết lập bộ đếm thời gian hiển thị Querier khác thành một giá trị được gọi là thời gian kết thúc hiển thị Querier khác; nếu trước đó router ở trạng thái Querier, nó s ẽ chuyển sang trạng thái non-Querier và ngừng gửi các bản tin Query trên liên kết này. Sau khi bộ đếm thời gian hi ể n thị Querier khác kết thúc, nó s ẽ tr ở lại trạng thái Querier và bắt đầu gửi đi các bản tin General Query. Tất cả các bản tin Query MLDv2 PHẢI được gửi với tiền tố đ ịa c hỉ nguồn link-local FE80::/64. Do đó, với mục đích bầu chọn Quer i er MLDv2, địa chỉ I Pv6 A được xem như là thấp hơn địa chỉ IPv6 B nếu ID giao diện địa chỉ A (tượng trưng bởi 64 bít cuối của địa chỉ A) là thấp hơn ID giao diện địa chỉ B (64 bit cuối của địa chỉ B). 10.6.3 Thiết lập và gửi đi các bản tin Query cụ thể 10.6.3.1 Thiết lập và gửi đ i các b ả n tin Multicast Address Speci fi c Query Khi xuất hiện một hành động “gửi Q(MA)”, bộ đếm thời gian cho chế độ lọc của router phải được hạ thấp về giá trị LLQT. Querier ngay sau đó s ẽ gửi đi một bản tin Multicast Address Specific Query và lập lị ch truyền lại [LLQC -1] bản tin Query, mỗi bản tin được gửi đi sau mỗi khoảng thời gian bằng [LLQ I ], trong thời gian [LLQT]. Khi phát đi một bản tin Multicast Address Specific Query, nếu giá trị của bộ đếm thời gian cho chế độ lọc lớn hơn LLQT, thi cờ S được thiết lập trong bản tin Query. 10.6.3.2 Thiết lập và gửi đi c á c b ả n tin Multicast Address and Source Spe cifi c Query Khi một Querier phát hiện hành động “gửi Q(MA,X) ” như trong bảng điều 10.4.2, các xử lý sau đây phải được thực hiện đối với mỗ i nguồn trong X gửi đi địa chỉ multicast MA, có bộ đếm thời gian cho nguồn l ớn hơn LLQT: - Giảm thời gian bộ đếm thời gian cho nguồn bằng LLQT; - Thêm các nguồn vào danh sách truyền lại; - Thiết lập bộ đếm cho việc truyền lại nguồn đối với từng nguồn bằng [LL C C ] . Querier sau đó phải ngay lập tức gửi đi bản tin Multicast Address and Source Specific Query cũng như lập lịch truyền lại [LLQC -1] bản tin Query, mỗi bản tin được gửi đi sau mỗi khoảng thời gian bằng [LLQI], trong thời gian [LLQT] . Nội d ung của các bản tin Query này được tính toán như sau: Khi thiết lập bản tin Multicast Address and Source Specffic Query cho địa chỉ multicast MA, ha i bản tin Query riêng biệt được gửi đi cho đ ịa chỉ mu l ticast này. Bản tin Query đầu tiên có bit S được th i ết lập và chứa tất cả các nguồn có trạng thái truyền lại (tức là các nguồn từ danh sách truyền lại của địa chỉ multicast), và bộ đếm thời gian lớn hơn LLQT. Bản tin Query thứ 2 có b i t S không được thiết lập và chứa các địa chỉ nguồn có trạng thái truyền lại và bộ đếm thời gian nhỏ hơn hoặc bằng LLQT. Nếu một trong hai bản tin được tính to á n không chứa bất kỳ nguồn nào, thì router sẽ ngừng truyền bản tin đó. Chú ý rằng: Nếu một bản tin Multicast Address Specific Query được lập lịch để truyền cùng thời điểm với bản tin Multicast Address and Source Spec ific Query cho cùng địa chỉ multicast, th ì việc truyền bản tin Multicast Address and Source Specific Query với bit S được thiết lập có thể bị chặn lại. 11 Tính tương thích với MLDv1 Các host và router MLDv2 tương thích với các host và router chưa được nâng cấp lên MLDv2. Tính tương th í ch này được duy trì do các host và router thực hiện các xử lý thích hợp phụ thuộc vào phiên bản của MLD đang hoạt động trên các host và router trong mạng. 11.1 Sự khác biệt về phiên bản của bản tin Query Phiên bản MLD của bản tin Query được xác định như sau: Bản tin Query MLDv1: độ dà i = 24 octet Bản tin Query MLDv2: độ dà i >= 28 octet Bản tin Query không phù hợp với các điều kiện ở trên (ví dụ bản tin Query có độ d ài 26 octet) PHẢI được tự động bỏ qua. 11.2 Cách xử lý của đối tượng nghe địa chỉ multicast 11.2.1 Trường hợp có sự hiện diện của rou t er MLDv1 Đ ể tương thích với các router MLDv1, các host MLDv2 PHẢI hoạt động trong chế độ t ương thích với phiên bản 1. Các host MLDv2 PHẢI giữ trạng thái cho từng giao diện cục bộ trên góc độ quan tâm đến chế độ tương thích của mỗi liên kết được kết nối. Tính tương thích của host được xác định từ biến chế độ tương thích host (Host Compatibil i ty Mod e ) mà có thể l à một trong hai giá trị sau: MLDv1 hoặc MLDv2. Chế độ tương thích host của một giao diện được thiết lập là MLDv1 bất cứ khi nào một bản tin Quer y MLDv1 nhận được trên giao diện đó. Tại cùng thời điểm, bộ đếm thời gian th ể hiện Querier phiên bản cũ cho giao diện được đặt bằng g iá tr ị [thời gian chờ cho Querier phiên bản cũ hơn] giây. Bộ đếm thời gian được thiết lập lại bất cứ khi nào một bản tin Query MLDv1 được nhận trên giao diện đó. Nếu bộ đếm thời gian thể hiện Quer i er ph iê n bản cũ hơn kết th ú c, host s ẽ chuyển được sang chế độ tương thích host là MLDv2. Khi chế độ tương thích host là MLDv2, host hoạt động bằng cách sử dụng giao thức MLDv2 trên giao diện được thiết lập, Khi chế độ tương thích host là MLDv1, host sử dụng duy nhất giao thức MLDv1 trên giao diện đó. Quer i er MLDv1 s ẽ gửi bản tin General Query có trường Maximum Response Code được đặt bằng trễ phản hồi tối đa mong muốn, tức là dải đầy đủ của trường này là thuật toán lũy thừa và tuyến t í nh như được mô tả trong điều 8.1.3 s ẽ không được sử dụng. Bất cứ kh i nào host thay đổi chế độ tương thích của nó, nó sẽ hủy bỏ tất c ả các các bộ đếm thời gian truyền lại và các phản hồi đang trong trạng thái chờ của mình. 11.2.2 Trườn g hợp có sự hiện diện của các đ ối tượ n g nghe địa chỉ multicast MLDv1 Một hos t MLDv2 có thể được đặt trê n một liên kết có các host MLDv1. Host này có thể cho phép bản tin Report MLDv2 của nó được chặn bởi một b ả n t i n Report phiên b ả n 1. 11.3 Cách xử lý của router multicast 11.3.1 Trường hợp có sự hiện diện của router MLDv1 Router MLDv2 có thể được đặt trong mạng mà ở đó có sự xuất hiện của tố i thiểu một router MLDv1. Các yêu cầu sau phải được áp dụng: - Nếu một router MLDv1 có mặt trên một liên k ế t, Querier PHẢI sử dụng phiên bản MLDv1 trên mạng. Các router mong muốn tương thích với MLDv1 PHẢI có một tùy chọn cấu h ì nh để hoạt động trong chế độ MLDv1; nếu router MLDv1 c ó mặt trên 1 liên kết, ngườ i quản trị hệ thống phải c ấ u h ì nh một cách rõ ràng tất cả các router MLDv2 hoạt động trong chế độ MLDv1. Khi ở trong chế độ MLDv1, Querier PHẢI định kỳ gửi đi các bản tin General Query b ị cắt bỏ trường Multicast Address (tức là chiều dài bản tin bằng 24 octet), và cũng NÊN cảnh báo nếu nhận được bản tin Query MLDv2 (các cảnh báo như vậy phải được giới hạn tốc độ). Querier PHẢI đưa giá trị trễ phả n hồi tối đa vào trong trường Maximum Response Code, tức là thuật toán tính giá trị được mô tả trong điều 8.1.3 phải không được sử dụng. - Nếu một router không được cấu hình rõ ràng việc sử dụng MLDv1 và nhận được một bản tin General Query MLDv1, nó NÊN ghi lại cảnh báo. Những cảnh báo này PHẢI được giới hạn tốc độ. 11.3.2 Trường hợp có sự hiện diện của đ ố i tượng nghe địa chỉ multicast MLDv1 Router MLDv2 có thể được đặt trong mạng mà các host chưa được hỗ trợ lên MLDv2. Để tương thích với các host MLDv1, router MLDv2 PH Ả I hoạt động trong chế độ tương thích với phiên bản 1. Các router MLDv2 duy tr ì chế độ tương thích cho từng Multicast Address Record. Chế độ tương thích của địa chỉ multicast được xác định từ biến chế độ tương thích địa chỉ multicast (Multicast Address Compat i bility Mode), có thể l à 1 trong 2 trạng thái sau: MLDv1 hoặc MLDv2. Chế độ tương thích đ ịa chỉ multicast của một Multicast Address Record được thiết lập là MLDv1 bất cứ khi nào router n hận được bản tin Report MLDv1 cho địa chỉ multicast đó. Tại cùng thời điểm, bộ đếm thời gian biểu hiện host ph iê n bản cũ hơn cho một địa chỉ multicast được thiết lập bằng gíá trị [kết thúc thời gian th ể hiện host phiên bản cũ hơn] giây. Bộ đếm thời gian này được thiết lập lại khi nhận một bản tin Report MLDv1 mới cho địa chỉ multicast đó. Nếu bộ đếm thời gian biểu hiện host phiên bản cũ hơn kết thúc, router s ẽ chuyển chế độ tương thích địa chỉ multicast th à nh MLDv2 cho địa chỉ multicast đó. Chú ý rằng khi router chuyển chế độ tương thích địa chỉ multicast thành MLDv2 cho một địa chỉ multicast, nó s ẽ mất thời gian thu thập lại các thông tin trạng thái về nguồn cụ thể. Các thông tin về nguồn cụ thể sẽ được xác định qua bản tin General Query tiếp theo, nhưng các nguồn n ê n chặn sẽ kh ô ng b ị chặn cho tới [khoảng thời gian nghe địa chỉ multicast] sau đó. Khi chế độ tương thích địa chỉ multicast l à MLDv2, router hoạt động bằng cách sử dụng giao thức ML D v2 ch o địa chỉ multicast đó. Khi chế độ tương thích địa chỉ multicast là MLDv1, router sẽ dịch các bản tin MLDv1 cho địa chỉ multicast đ ó thành các bản ghi MLDv2 tương ứng: Bản tin MLDv1 Bản ghi MLDv2 tương ứng Report Done IS _EX ( { } ) TO_IN ( { } ) Các bản tin mang bản ghi BLOCK MLDv2 được bỏ qua , vì là danh sách nguồn trong các bản tin chứa bản ghi TO_EX () (tức là các bản ghi TO_EX () được đối xử như là TO_EX ({ } )). Mặt k hác, Querier tiếp tục gửi các bản tin Query MLDv2 bất k ể chế độ tương thích địa chỉ multicast của nó. 12 Danh sách các bộ đếm thời gian, bộ đếm và giá trị mặc định của chúng Hầu hết các bộ đếm thời gian này đều có thể c ấ u hình được. Nếu không sử dụng giá trị mặc đ ị nh, thì giá trị các bộ đếm này phải thống nhất giữa tất cả các nút trên một liên kết. 12.1 Biến Robustness Biến Robustness cho phép hiệu chỉnh số gói tin có thể bị mất được dự đoán trước trên một liên kết. Nếu một liên kết được dự đoán là có mất gói, giá trị của biến Robus t ness có thể được tăng lên. MLD là ổn định với [biến Robustness] -1 gó i tin mất. Giá trị của biến Robustness KHÔNG ĐƯỢC được bằng 0, và KHÔNG NÊN bằng 1. G i á trị mặc định: 2. 12.2 Khoảng thời gian tru y vấn Khoảng thời gian truy vấn quy định khoảng thời gian giữa các bản tin General Query được Querier gửi đi. Giá trị mặc định: 125 giây. Bằng cách thay đổi [khoảng thời gian truy vấn], người quản t rị có thể hiệu chỉnh s ố lượng bản tin MLD tr ê n liên kết; giá trị này càng lớn sẽ l à m cho các bản tin Query MLD được gửi ít thường xuyên hơn. 12.3 Khoảng th ời gian phản h ồi truy vấn Trễ phản hồi tối đa được sử dụng để tính toán trư ờ ng Maximum Response Code trong các bản tin General Query định kỳ. Giá trị mặc đ ị nh l à 10 giây. Bằng cách thay đ ổ i [khoảng thời gian phản hồi truy vấn], người qu ả n tr ị có thể hiệu chỉnh sự bùng phát của các bản tin MLD trên liên kết; giá trị càng lớn làm cho lưu lượng càng ít bùng phát, vì các phản hồi host được dàn trải t rong một khoảng thời gian lớn hơn. Thời gian (theo giây) của [khoảng thời gian phản hồ i truy vấn] phải nhỏ hơn [khoảng thời gian truy vấn]. 12.4 Khoảng thời gian lắng nghe địa chỉ multicast Kho ả ng thời gian lắng nghe địa chỉ multicast (MALI) là khoảng thời gian trước khi một router multicast quyết định kh ô ng còn đối tượng nghe cho một địa chỉ multicast hoặc một nguồn cụ thể nào nữa trên một liên kết. Giá t rị này PHẢI bằng: ([biến Robustness] X [ khoảng thời gian truy vấn]) + [ khoảng thời gian phản hồi truy vấn]. 12.5 Khoảng thời gian hiện diện Querier khác Khoảng thời gian hiện diện Querier khác là tổng thời gian trước khi một router multicas t quyết định không còn router multicast khác ở trạng thái Querier. Giá trị mặc định PHẢI bằng: ([biến Robustness] X [khoảng thời gian truy vấn]) + 1/2 [khoảng thời gian phản hồi truy vấn]. 12.6 Khoảng thời gian truy vấn khi kh ở i động Khoảng thời gian truy vấn khi khởi động là thời gian giữa các bản tin General Query được gửi bởi Querier kh i khởi động. G i á tri mặc định: 1/4 [khoảng thời gian truy vấn]. 12.7 S ố lượng truy vấn kh i kh ở i động Số lượng truy vấn khi khởi độ n g là s ố các bản tin Query được gửi đi khi khởi động và cách nhau bởi [khoảng thời gian truy vấn khi kh ở i động]. Giá trị mặc định: [biến Robustness]. 12.8 Khoảng thời gian truy vấn đối tượng nghe cuối cùng Khoảng thời gian truy vấn đối tượng nghe cuối cùng (gọi tắt là LLQI) là trễ phản hồi tối đa được sử dụng để tính toán trư ờ ng Maximum Response Code trong các bản tin Multicast Address Specific Query gửi đ i đ ể hồ i đáp lại các bản tin Done ph iê n bản 1. Đó cũng là trễ phản hồi tối đa được sử d ụ ng để tính toán trường Max i mum Response Code trong bản tin Multicast Address and Source Specific Query. Giá trị mặc định: 1000 (1 giây). Chú ý rằng với các giá trị LLQI lớn h ơ n 32.768 giây, có thể được thể hiện bằng một tập hữu hạn các giá trị tương ứng với các giá trị liên tiếp của tr ườ ng Max i mum Response Code. Khi chuyển đổi thời gian được cấu h ì nh sang giá trị trường Maximum Response Code, thì khuyến nghị sử dụng giá trị chính xác nếu c ó th ể , hoặc giá trị nhỏ hơn tiếp theo nếu giá trị được yêu cầu không thể thể hiện một cách ch í nh xác. Giá trị này có thể được hiệu ch ỉ nh để thay đổi “trễ rời nhóm ” của liên kết. Giá trị này càng nhỏ s ẽ càng làm giảm thời gian phát hiện sự rời đi của đối tượng nghe cuối cùng cho một địa chỉ multicast hoặc nguồn. 12.9 S ố lượng truy vấn đối tượng nghe cuối cùng Số lượng truy vấn đối t ượng nghe cuối cùng (viết tắt là LLQC) là số bản tin Multicast Address Speci f ic Query được gửi đi trước khi router giả định rằng không còn đối tượng nghe cục bộ nào. LLQC cũng là số lượng bản tin Multicast Address and Source spec if ic Query được gửi đi trước khi router gi ả định rằng không còn đối tượng nghe nào đối với một nguồn cụ thể. Giá trị mặc định: bằng giá trị [biến Robustness]. 12.10 Thời gian truy vấn đối t ượ ng nghe cuối cùng Thời gian truy vấn đối tượng nghe cuối cùng (viết tắt l à LLQT) l à giá trị thời gian được th ể hiện bằng: [LLQI] X [LLQC]. Đây không phải là giá trị có thể thay đổi được, nhưng vẫn có thể được hiệu chỉnh bằng cách thay đ ổ i các thành phần của nó. 12.11 Khoảng thời gian báo cáo không theo th ă m dò Khoảng thời gian báo cáo không theo thăm dò là thời gian giữa các bản tin phát lại của bản tin Report ban đầu mà một nút th ể hiện mối quan tâm tới một địa chỉ multicast. Giá trị mặc định: 1 giây. 12.12 Thời gian ch ờ cho Querier phiên bản cũ hơn Thời gian chờ cho Quer i er phiên bản cũ hơn là khoảng thời gian chờ cho việc chuyển trạng thái của một host ngược l ạ i chế độ tương thích host MLDv2. Khi nhận được một bản tin Query MLDv1, các host MLDv2 phải thiết lập bộ đếm thời gian cho Querier phiên bản 1 về giá trị [thời gian chờ cho Querier phiên bản cũ hơn]. Giá trị này PHẢI bằng: [biến Robustness] X [khoảng thời gian truy vấn] + ([khoảng thời gian phản hồi truy vấn]). Trong đó, giá trị [khoảng thời gian truy vấn] là giá trị có trong bản tin Query cuối cùng nhận được. 12.13 Khoảng thời gian chờ cho host phiên bản cũ hơn Khoảng thời gian chờ cho host phiên bản cũ hơn là thời gian chờ cho việc chuyển trạng thái router ngược lại chế độ tương thích địa chỉ multicast MLDv2 cho một địa chỉ multicast cụ thể. Khi nhận được một bản tin Report MLDv1 cho địa chỉ multicasl đó, router thiết lập bộ đếm thời gian host phiên bản 1 thành giá trị [khoảng thời gian chờ cho host phiên b ả n cũ hơn]. Giá trị này PHẢI bằng ([biến Robustness] X [khoảng thời gian truy vấn]) + ([khoảng thời gian phản hồi truy vấn]). 12.14 Cấu hình các bộ đếm thời gian Phần này đưa ra các lời khuyên cho các nhà quản trị mạng về việc làm sao để hiệu chỉnh các cài đặt cấu hình cho mạng của người qu ả n trị. Những th ự c thi của router có thể hiệu ch ỉ nh các c à i đặt này một cách l i nh động dựa trên việc thay đổi các thuộc tính đặc trưng của từng mạng. 12.14.1 Biến Robustness Biến Robustness cho phép hiệu ch ỉ nh số gói tin có thể b ị mất được ước lượng trên một liên kết. MLDv2 là ổn định với giá trị [biến Robustness]-1 gói tin bị mất, ví dụ, nếu biến Robustness được thiết lập về giá trị mặc đ ị nh bằng 2, MLDv2 là ổn định với một gói d uy nhất bị mất nhưng có thể hoạt động không hoàn hảo nếu có nhiều mất gói xảy ra. Trên các liên kết có m ấ t gói, giá trị của biến Robustness sẽ được tăng lên để cho phép ước lượng mất gói có thể xảy ra. Tuy nhiên, việc tăng giá trị biến Robustness này cũng làm tăng trễ rời nhóm của một liên kết (thời gian giữa thời điểm đối tượng nghe cuối cùng ngừng theo dõi một nguồn hoặc một địa chỉ và thời điểm lưu lượng ngừng chuyển tiếp). 12.14.2 Khoảng thời gian truy vấn Tổng lưu lượng MLD theo định kỳ là tỷ lệ nghịch với khoảng thời gian truy vấn. Khoảng thời gian truy vấn càng lâu dẫn tới tổng lưu lượng MLD càng thấp. Giá trị của khoảng thời gian truy vấn PHẢI lớn hơn hoặc bằng trễ phản hồi tối đa được sử dụng để tính toán trường Maximum Respond Code trong các bản tin General Query. 12.14.3 Trễ phản hồi tối đa Tính ổn định của lưu lượng MLD là tỷ lệ nghịch với trễ phản hồi tối đa. Giá trị trễ phản hồi tối đa càng lâu sẽ dàn trải bản tin R e port trong một khoảng thời gian càng lâu. Tuy nhiên, trễ phản hồi tối đa càng lâu trong các bản tin Multicast Address Spe cifi c Query và bản tin Multicast Address and Source Specif i c Query sẽ m ở rộng trễ rời nhóm (thời gian giữa thời điểm đ ối tượng nghe cuối cùng ngừng t heo dõ i một nguồn hay một địa chỉ multicast và thời điểm lưu lượng ngừng chuyển tiếp). Tốc độ dự kiến của các bản t i n Report có thể được tính toán bằng cách ch i a giá trị trễ phản hồi tối đa cho số lượng đối tượng báo cáo được ước lượng. Trễ phản hồi tối đa có thể được tính toán một cách linh động cho từng bản tin Query bằng cách sử dụng số lượng đối tượng báo cáo được dự k iến nh ư sau : Loại bản tin Query S ố lượng bản tin Report được dự ki ế n Bản tin General Query Tất cả các nút trên liên kết Bản tin Multicast Address Specif i c Query Tất cả cáo nút trên liên kết thể hiện mối quan tâm tới địa chỉ multicast Bản tin Multicast Address and Source Specific Query Tất cả các nút trên liên kết thể hiện mối quan tâm tới nguồn và địa chỉ multicast 13 Các vấn đề an toàn bảo mật Dưới đây là các trường hợp khác nhau của từng loại bản t i n b ị gi ả mạo. Chú ý rằng trước khi xử lý một bản tin MLD, nút sẽ xác minh rằng địa chỉ nguồn của bản tin có phải một địa chỉ link-local hợp lệ không, trường Hop Limit có được thiết lập bằng 1 không, và tùy chọn Router Alert có được thể hiện trong mào đầu Hop-by-Hop Options của gói tin IPv6 không. Nếu bất kỳ kiểm tra nào trong các kiểm tra này xảy ra lỗi, gói tin sẽ bị loại bỏ. Điều này bảo vệ nút MLDv2 khỏi hoạt động trên các bản tin MLD b ị giả mạo có nguồn gốc o ff-li nk. Do đó phần tiếp theo chỉ đề cập t ớ i các ảnh hưởng của giả mạo on-link. 13.1 Bản tin Query Bản tin Query bị giả mạo từ một máy với địa chỉ IPv6 thấp hơn so với Querier hiện tại sẽ làm cho nhiệm vụ Querier được chỉ định cho đố i tượng giả mạo. N ế u sau đó đố i tượng giả mạo không gửi đi bất kỳ bản tin Query nào, bộ đếm thời gian cho Querier khác của các router khác sẽ kết thúc và một router sẽ tiếp tục vai trò Querier. Trong suốt thời gian này, nếu Querier bỏ qua các bản tin Done, lưu lượng có thể sẽ chuyển sang những địa chỉ multicast không có đối tượng nghe trong thời gian l ê n đến [khoảng thời gian đối tượng nghe địa chỉ multicast]. Bản tin Query ph iê n bản 1 b ị g i ả mạo sẽ đặt các đối tượng nghe MLDv2 trên liên kết đó sang chế độ tương thích host MLDv1 . Kịch bản này có thể được tránh bằng cách sử dụng các host MLDv2 có tùy chọn c ấ u hình bỏ qua các bản tin ph i ên bản 1 một cách hoàn toàn. Một tấn công DoS trên một nút có thể được tiến hành thông qua các bản tin Multicast Address and Source Specific Query b ị giả mạo. Kẻ tấn công có thể tìm ra trạng thái nghe của một nút cụ thể với một bản tin General Query. Sau đ ó , chúng có thể gửi đi một lượng lớn các bản tin Multicast Address and Source Specific Query, mỗi bản tin này có một danh sách ng uồ n lớn hoặc/ và trễ phản hồi tối đa dài. Mỗi nút sẽ phải chứa và duy trì các nguồn được quy định trong tất cả các bản tin Query đ ó cho tới kh i chúng gửi đi các phản hồi được làm trễ. Điều này có th ể tiêu t ố n cả về bộ nhớ và CPU khi ghi lại các nguồn trong danh sách nguồn của các bản tin Query thành công. Để b ả o vệ lạ i các tấn cống DoS như vậy, việc thực thi ngăn xếp nút s ẽ giới hạn số lượng bản tin Multicast Address and Source Specific Query cho từng địa chỉ multicast trong khoảng thời gian này, và/hoặc chỉ ghi lạ i một s ố hữu hạn các nguồn. 13.2 Các bản tin Current State Report Bản tin Report bị gi ả mạo làm cho các router multicast nghĩ rằng có các đối tượng nghe một địa chỉ mu l ticast trên một liên kết trong khi không tồn tại đối tượng nào. Tuy nhiên, v ì việc nghe một địa chỉ mu lt icast trên một host l à một hành động không cần cấp quyền, nên người sử dụng có thể đạt được các kết quả tương tự mà không giả mạo bất kỳ bản tin nào. Bản tin Report phiên bản 1 bị gi ả mạo có thể đặt rout e r vào trong chế độ tương thích địa chỉ multicast MLDv1 cho một địa chỉ multicast cụ thể, nghĩa là router sẽ b ỏ qua các bản tin trạng thái nguồn cụ thể MLDv2. Điều này có thể làm cho lưu lượng chuyển từ nh ữ ng nguồn không mong muốn trong thời gian lên đến [khoảng thời gian đối tượng nghe địa chỉ multicast]. Điều này có thể được giải quyết bằng cách thiết lập cá c router có một c ấ u hình chuyển mạch cho phép bỏ qua các bản tin phiên bản 1 một cách hoàn toàn. Điều này phá vỡ tính tương thích tự động với các host phiên bản 1, nên nó sẽ ch ỉ được sử dụng trong trường hợp việc lọc nguồn là cần thiết. 13.3 Bản tỉn State Change Report Bản tin State Change Report b ị giả mạo sẽ làm cho Querier gửi đi các bản tin Multicast Address Speci f ic Query và bản tin Multicast Address and Source Specific Query cho một nguồn nhất định dưới dạng h ỏ i đáp. Điều này gây ra những xử lý bổ sung trên mỗi router và trên mỗi đối tượng nghe của địa chỉ multicast nhưng không thể gây ra mất lưu lượng mong muốn. Phụ lục A (Tham khảo) Lý do thiết kế căn bản A.1 Sự cần thiết của các bản tin thay đổi t rạng thái MLDv2 chỉ rõ 2 loại bản tin Report: bản tin Current State Report và bản tin State Change Report. Phần này mô tả l ý do căn bản cho sự cần thiết của cả hai loại bản tin Report trên. Router cần phân biệt các bản tin Report đượ c sử dụng cho việc ph ả n h ồ i lạ i các bản tin Query cho việc thay đổi trạng thái của từng giao diện. Các bản tin Report được sử dụng ch ủ yếu để làm mới l ạ i trạng thái đang tồn tại của router, thì không gây ra sự chuyển đổi trạng thái tại các router. Các bản tin Report được gửi để phản hồi các thay đổi trong trạng thái từng giao diện, thì yêu cầu router có các xử lý để hồi đáp lại b ả n tin Report đã nhận (xem điều 7.4). Việc không có khả nă n g phân biệt giữa hai loại bản tin Report s ẽ làm cho router xử lý tất cả các bản tin Report giống như các thay đổi có kh ả năng xảy ra trong trạng thái và có thể làm tăng thêm các xử lý tại router cũng như làm tăng lưu lượng MLD trên liên kết. A.2 Việc ngăn chặn host Trong MLDv1, một host sẽ không gửi đi bản tin Report đang ở trạng thái chờ nếu một bản tin tương tự đã được gửi đi bởi một đối tượng nghe khác trên li ên kết. Trong ML D v2, việc ngăn chặn các b ả n tin Report đã b ị gỡ bỏ. Các ý sau giải thích rõ ràng tính năng này. 1. Các router có thể muốn theo dõi trạng thái đối tượng nghe multicast theo từng host trên một giao diện. Điều này s ẽ cho phép router thực thi tính n ă ng rờ i nhóm nhanh (ví dụ, cho cơ chế điều khiển tắc nghẽn multicast được phân tầng), cũng như theo dõi trạng thái đối tượng nghe cho các mục đích bảo mật hoặc thống k ê . Tiêu chuẩn hiện tại không yêu cầu router thực thi việc theo dõi từng host. Tuy nhi ê n, việc không ngăn chặn các thông báo từ host trong MLDv2 tạo ra k hả năng thực thi quyền sở hữu hoặc các cách xử lý chính xác trong tương lai của router (khi đó, router có khả năng hỗ tr ợ tính năng theo dõi từng host), trong khi tương tác với các đối tư ợ ng nghe và router MLDv2 đang thực th i tiêu chuẩn này. 2. Việc ngăn chặn bản tin Report không hoạt động trên mạng LAN được bắc cầu (bridged LAN). Nhiều thiết bị bắc cầu hoặc các bộ chuyển mạch tầng 2/ tầng 3 thực thi MLD snooping không chuyển tiếp các bản tin MLD qua các phần tử LAN để hạn chế việc ngăn chặn báo cáo đối tượng mul ti cast. 3. Việc chấm dứt ngăn chặn bản tin Report khiến host phải xử lý ít b ả n tin hơn; điều này dẫn tới việc máy thực thi có trạng thái đơn giản hơn. 4. Trong MLDv2, một bản tin Report đơn l ẻ gộp nhiều Multicast Address Record để gi ả m số lượng gó i t i n gửi đ i . Để so sánh, phiên bản MLDv1 y ê u cầu rằng mỗi địa chỉ m u lticast được báo cáo trong một bản tin riêng r ẽ . A.3 Chuyển chế độ lọc của router từ EX C LUDE sang I NCLUDE Nếu trên một liên kết có các nút ở các chế độ EXCLUDE và INCLUDE với một địa chỉ multicast độc lập, router phải ở chế độ EXCLUDE (điều 7.2.1). Trong chế độ EXCLUDE, router chuyển tiếp lưu l ượng từ các nguồn nằm ngoài danh sách EXCLUDE. Nếu tất cả các nút trong chế độ EXCLUDE dừng nghe hoặc không còn khả dụng, router phải được chuyển ngược về chế độ INCLUDE một cách liền mạch, m à lưu lượng tới các đối tượng nghe đang tồn tại kh ô ng bị gián đoạn. Một trong nhiều phương án để thực thi điều này là cho phép các router theo dõi tất các nguồn mà các nút đang ở trong chế độ INCLUDE đang nghe, ngay cả khi router ở trong chế độ EXCLUDE. Nếu bộ đếm thời gian cho chế độ lọc cho một địa chỉ multicast kết thúc (tức là không còn nút nào trong chế độ EXCLUDE trên liên kết) thì sau đó router s ẽ chuyển sang chế độ INCLUDE một cách liền mạch; các nguồn từ danh sách được yêu cầu sẽ chuyển sang danh sách INCLUDE, trong khi các nguồn trong danh sách EXCLUDE sẽ b ị xóa bỏ. Phụ lục B (Tham khảo) Bảng đối chiếu nội dung tương đương của TCVN 9802-5:2017 và tài liệu RFC 3810 TCVN 9802-5:2017 Tài liệu RFC 3810 1 Phạm vi áp dụng 2 Tài liệu viện dẫn 3 Thuật ngữ và đ ị nh nghĩa 4 Chữ viết tắt 5 Tổng quan giao thức Section 2 5.1 Thiết lập trạng thái nghe multicast tr ê n các đối tượng nghe địa chỉ multicast Section 2.1 5 . 2 Việc trao đổi các bản tin giữa Querier v à các nút nghe Section 2.2 5.3 Thiết lập trạng thái đối tượng nghe địa chỉ mu l icast trên router multicast Section 2.3 6 Giao diện dịch vụ cho việc yêu cầu nhận IP Multicast Section 3 7 Trạng thái nghe multicast được duy trì bở i các nút Section 4 7.1 Trạng thái từng socket Section 4.1 7.2 Trạng thái từng giao diện Section 4.2 8 Các định dạng bản tin Section 5 8.1 Bản tin Multicast Listener Query Section 5.1 8.2 Bản tin Multicast Listener Report Section 5.2 9 Mô tả giao thức đối với các đối tượng nghe đ ịa chỉ multicast Section 6 9.1 Xử lý theo sự thay đổi của trạng thái từng giao diện Sect i on 6.1 9.2 Xử lý khi nhận bản tin Query Sact i on 6.2 9.3 Xử lý khi bộ đếm thời gian kết thúc Section 6.3 10 Các m ô tả của giao thức cho router multicast Sect i on 7 10.1 Các điều kiện cho những bản t i n Query Section 7.1 10.2 Trạng thái MLD được duy trì bởi các router multicast Section 7.2 10.3 Các quy tắc chuyển tiếp nguồn MLD cụ thể Section 7.3 10.4 Xử lý khi tiếp nhận bản tin Report Sect i on 7.4 10.5 Chuyển đổi các chế độ lọc của router Section 7.5 10.6 Các xử lý khi nhận bản tin Query Section 7.6 11 Tính tương thích với MLDv1 Section 8 11.1 Sự kh á c biệt về phiên bản của bản tin Query Sect i on 8.1 11.2 Cách xử lý của đối tượng nghe địa chỉ multicast Section 8.2 11.3 Cách xử lý của router mul t icast Section 8.3 12 Danh sách các bộ đếm thời gian, bộ đếm và g i á trị mặc định của chúng Section 9 12.1 Biến Robustness Section 9.1 12.2 Khoảng th ời gian truy vấn Section 9.2 12.3 Khoảng thời gian phản hồi truy vấn Section 9.3 12.4 Khoảng thời gian lắng nghe địa chỉ multicast Section 9.4 12.5 Khoảng thời gian hiện diện Querier khác Sect i on 9.5 12.6 Khoảng thời gian truy vấn kh i kh ở i động Section 9.6 12.7 Số lượng truy vấn khi khởi động Section 9.7 12.8 Khoảng thời gian t ruy vấn đối tượng nghe cuối cùng (LLQI) Section 9.8 12.9 Số lượng t ruy vấn đối tượng nghe cuối cùng (LLQC) Section 9.9 12.10 Thời gian truy vấn đối tượng nghe cuối cùng (LLQT) Section 9.10 12.11 Khoảng thời gian báo cáo không theo thăm dò Section 9.11 12.12 Thời gian chờ của Querier phiên bản cũ hơn Section 9.12 12.13 Khoảng thời gian chờ host phiên bản cũ hơn Sect i on 9.13 12.14 Cấu hình các bộ đếm th ờ i gian Sect i on 9.14 13 Các vấn đề an toàn bảo mật Section 10 13.1 Bản tin Query Section 10.1 13.2 Các bản tin Current State Report Section 10.2 13.3 Các bản t in State Change Report Section 10.3 Phụ lục A (tham khảo) Lý do th iết kế căn bản APPENDIX A. Design Rationale Phụ lục B (tham khảo) Bảng đối chiếu nội dung t ư ơng đương của TCVN 9802-5:2017 và tài liệu RFC 3810 Thư mục tài liệu tham kh ả o [1] RFC 3810, Multicast Listener Discovery Version 2 (ML D v2) for lPv6. [2] RFC 2710, Multicast Listener Discovery (MLD) for IPv6. [3] RFC 4443, Internet Con t ro l Message Protocol (ICMPv 6 ) for the Internet Protocol Version 6 (IPv6) Speci f ication. MỤC LỤC 1 Phạm vi áp dụng 2 Tà i liệu viện dẫn 3 Thuật ngữ và định nghĩa 4 Chữ viết tắt 5 Tổng quan giao thức 5.1 Thiết lập trạng thái nghe multicast trên các đối tượng nghe đ ị a ch ỉ multicast 5.2 Trao đổi các bản tin giữa Querier và các nút nghe 5.3 Thiết lập trạng thái đối tượng nghe địa chỉ multicast trên router multicast 6 Giao diện dịch vụ cho việc yêu cầu nhận IP Multicast 7 Trạng thái nghe multicast được duy trì b ở i các nút 7.1 Trạng thái từng socket 7.2 Trạng thái từng giao diện 8 Các định dạng bản tin 8.1 Bản tin Multicast Listener Query 8.2 B ả n tin Multicast Listener Report 9 Mô tả giao thức đối với các đối tượng nghe địa chỉ multicast 9.1 Xử lý theo sự thay đổi của trạng thái từng giao diện 9.2 Xử lý khi nhận bản tin Query 9.3 Xử lý khi bộ đếm thời gian kết thúc 10 Mô tả của giao thức cho router multicast 10.1 Các điều kiện cho những bản tin Query MLD 10.2 Trạng thái MLD được duy tr ì bởi các router multicast 10.3 Các quy tắc chuyển tiếp nguồn MLDv2 cụ thể 10.4 Xử lý k h i nhận bản tin Report 10.5 Chuyển đổi các chế độ lọc của router 10.6 Các xử lý khi nhận bản tin Query 11 Tính t ư ơng thích với MLDv 1 11.1 Sự khác biệt v ề ph iê n bản của bản tin Query 11.2 Cách xử lý của đối tượng nghe địa chỉ multicast 11.3 Cách xử lý của router multicast 12 Danh sách các bộ đếm thời gian, bộ đếm và giá trị mặc định của chúng 12.1 Biến Robustness 12.2 Khoảng thời gian truy vấn 12.3 Khoảng thời gian phản hồi truy vấn 12.4 Khoảng thời gian lắng nghe địa chỉ multicast 12.5 Khoảng thời gian hiện diện Querier khác 12.6 Khoảng thời gian truy vấn khi khởi động 12.7 Số lượng truy vấn khi khởi động 12.8 Khoảng thời gian truy vấn đối tượng nghe cuối cùng 12.9 Số lượng truy vấn đối tượng nghe cuối cùng 12.10 Thời gian truy vấn đối tượng nghe cuối cùng 12.11 Khoảng thời gian báo cáo không theo t h ăm dò 12.12 Thời gian chờ cho Querier phiên bản cũ hơn 12.13 Khoảng thời gian chờ cho host phiên bản cũ hơn 12.14 Cấu hình các bộ đếm thời gian 13 Các vấn đề an toàn bảo mật 13.1 Bản tin Query 13.2 Các bản tin Current State Report 13.3 Bản tin State Change Report Phụ lục A (tham khảo) Lý do thiết kế căn bản Phụ lục B (tham khảo) Bảng đối chiếu nộ i dung tươ ng đương của TCVN 9802-5:2017 và tài liệu RFC 3810 Thư mục tà i liệu tham khảo