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

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 Discovery Version 2 (MLDv2) for IPv6” 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.

Tiê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 (ICMPv6) for the Internet Protocol Version 6 (IPv6) specification, March 2006 (Giao thức bản tin đ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 Address 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 Ethernet).

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)

Thiế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 diệ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 IPv6 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  Socket

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 Prefix 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

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 multicast 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ế độ EXCLUDE, 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ỉ multicast 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 cho 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 socket, nhưng có thể khác với trạng thái từng socket 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 socket 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à socket 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 Specific Query (truy vấn địa chỉ multicast cụ thể) và bản tin Multicast Address and Source Specific Query (truy vấn địa chỉ multicast và nguồn cụ thể). Các Querier đị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 ghi thay đổi chế độ lọc) hoặc các Source List Change Record (bản ghi thay đổi danh 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 trì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 Query 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ự kiến là mất gói (ví dụ như kết nối không dây), giá trị của biế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 giá trị của các bộ đếm/biế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 tiê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 tin 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, Querier phải truy 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 Specific Query để xác minh rằng các nút vẫn đang lắng nghe địa chỉ multicast 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 hai loại bản tin Report này nhằm trá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 tin Current State Report, chứa trạng thái Nghe Địa Chỉ 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ụ thuộ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 tin 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 Address 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 theo đượ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 thá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ỉ multicast 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. Querier sau đó gử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 đ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 chi tiết trong đ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 thay đổ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 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 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. Chi 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ó liê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 Specific 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 danh 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 chi tiết trong Bảng 10.4.1 và 10.4.2.

Các xử lý của cả router và đối tượng nghe 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:

IPv6MulticastListen (socket, giao diện, địa chỉ multicast IPv6, chế độ lọc, danh sách nguồn)

Trong đó:

- “Socket” 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ỉ multicast 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ỉ multicast 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ụ thuộ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 IPv6 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 IPv6MulticastListen tiếp theo cho cùng socket, 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 socket, 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 (socket, giao diện, địa chỉ multicast IPv6, EXCLUDE, { })

Và hoạt động dừng lắng nghe tương đương với:

IPv6MulticastListen (socket, giao diện, địa chỉ multicast IPv6, INCLUDE, { })

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 ghi 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 duy 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 IPv6, 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 s1 như sau:

IPv6MulticastListen (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 tin được gửi tới cùng địa chỉ multicast m trên cùng giao diện i, chỉ khi 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 hay 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 socket 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 tin 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ó thể đượ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 s1: (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ừ socket 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 IPv6MulticastListen làm thay đổi trạng thát từng 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 link-local, trường Hop Limit có giá trị bằng 1, và tùy chọn Router Alert IPv6 [RFC2711] trong mào đầu Hop-by-Hop Options (tùy chọn Router Alert nhằm mục đích để các router 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 IPv6 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 Report 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) [RFC2710].

Các loại bản tin không được nhận biế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 Listener 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 Multicast 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 hiệ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  Trường Maximum 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 Maximum 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 Code.

Nếu giá trị trườ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 giữ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ỉ Multicast)

Trong bản tin General Query, trường Multicast Address được thiết lập về 0. Trong bản tin Multicast Address Specific 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 Querier)

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 giá trị [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 querier)

Trường QQIC quy định [khoảng thời gian truy vấn] được sử dụng bởi Querier. Khoảng thời gian thực tế, được gọi là khoảng thời gian truy vấn của Querier (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 exp 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 trong 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 Alert 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 octet 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 Number of Sources (N) đều bằng 0.

- “Bản tin Multicast Address Specific 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ỉ multicast đ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 tin 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 liê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 Listener Report phiên bản 2

Các bản tỉn Multicast Listener Report phiê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 tin MLDv2, cộng thêm “mào đầu ảo” của trường mào đầu IPv6 [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 Record, 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  Trườ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 thi 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 lai 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ữ liệ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 thi 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 Record

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ỉ multicast. Trường Record Type của Current State Record có thể là một trong hai giá trị sau:

- 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ộ IPv6MulticastListen gây ra một thay đổi về chế độ lọc của bản ghi 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:

- 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 IPv6MulticastListen 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:

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ỉ nguồ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 Filter 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_IN (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

ALLOW (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_SOURCES, 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ỉ duy 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-local 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 trong 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 Report

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 Multicast 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 Compatibility Mode = MLDv2. Giải thuật để xác định biến Host Compatibiltty 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 giá 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 multicast 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 ghi 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.

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 Report 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 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 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 tin 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 tin 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ỳ trước đó. Nút phải duy trì 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ịch 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 minh 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ó 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_IN; 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 ghi 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:

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 ghi 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ý khi nhận bản tin Query

Sau khi nhận được bản tin 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 Hop 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 tin sẽ bị loại bỏ.

Nếu tính hợp lệ của bản tin MLD được xác minh, 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 Code 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 Specific 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 Source 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 kiể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 trướ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 tin 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ỉ multicast này, và bản tin Query mới là bản tin Multicast Address Specific 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ì danh 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à chế độ 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ể.

Thuậ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_INCLUDE hoặc MODE_IS_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:

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 tin Report sẽ chứa bản ghi TO_IN, ngược lại bản tin này sẽ chứa bản ghi TO_EX. Trong cả hai 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:

Nếu danh sách nguồn được tính toán cho bản ghi 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 multicast để 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 router multicast 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 nguồ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 thiể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 cho 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 Querier 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 Querier gửi địnhkỳ hoặc khởi tạo các bản tin Query trên miền mạng.

Querier đị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. Khi 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 ghi 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ỉ multicast 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 khi 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 Record 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 Multicast 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 thi 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 ghi 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 nguồ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  Định nghĩa các chế độ lọc của router

Để giảm trạng thái nội bộ, các router MLDv2 duy trì 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, khi 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ế độ INCLUDE. 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 giả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 chế độ 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.

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. Biến MALI viết tắt của khoảng thời gian nghe địa chỉ multicast (Multicast Address Listening 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à router đợ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, router 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 thay đổ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 tin Current 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ình. 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 danh 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 INCLUDE, và danh 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 khi 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 nguồ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ế độ INCLUDE, 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 mili-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 danh 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 trê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à EXCLUDE, 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.

10.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 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 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.

10.4.1  Khi nhận các Current State Record

Khi 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 ghi 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.

10.4.2  Khi nhận các Filter 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 giá trị thời gian bằng LLQT theo đơn vị mili- 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 gian 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 Record 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 mili-giâ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 ghi 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 Specific 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 Specific 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 trì trạng thái của các bản tin Query đang chờ.

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 Query.

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.

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 Querier 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ỉ IPv6 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 chỉ nguồn link-local FE80::/64. Do đó, với mục đích bầu chọn Querier MLDv2, địa chỉ IPv6 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 Specific 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 [LLQI], 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 Specific 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 [LLCC].

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 dung 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, hai bản tin Query riêng biệt được gửi đi cho địa chỉ multicast này. Bản tin Query đầu tiên có bit S được thiế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ó bit 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 Specific 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 router 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 Compatibility Mode) 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 Query 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 giá 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 Querier phiê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 đó.

Querier 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ứ khi 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ường hợp có sự hiện diện của các đối tượng nghe địa chỉ multicast MLDv1

Một host 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 tin 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 Compatibility 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 nhậ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 phiê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 MLDv2 cho đị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:

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 khá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 Robustness 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. Giá trị mặc định: 2.

12.2  Khoảng thời gian truy 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 trị 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 trong 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á 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.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 multicast 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 khi khởi động. Giá tri mặc định: 1/4 [khoảng thời gian truy vấn].

12.7  Số lượng truy vấn khi khởi động

Số lượng truy vấn khi khởi động 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 phiê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 Maximum 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 Maximum 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 Specific 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 specific 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 Querier 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 linh độ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 duy 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 Report 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 Specific Query và bản tin Multicast Address and Source Specific 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 theo 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 tin Report có thể được tính toán bằng cách chia 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ự kiến như  sau:

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 tin 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 off-link. 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 phiên bản 1 bị giả 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 phiê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 nguồ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 khi 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ỉ multicast 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ỉ multicast 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 router 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 Specific 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 trạ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ăng 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 MLDv2, 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 khả 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 thi 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 multicast.

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 tin gửi đi. Để so sánh, phiên bản MLDv1 yêu cầu rằng mỗi địa chỉ multicast đượ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ừ EXCLUDE sang INCLUDE

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

Thư mục tài liệu tham khảo

[1] RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for lPv6.

[2] RFC 2710, Multicast Listener Discovery (MLD) for IPv6.

[3] RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.

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ý khi 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 MLDv1

11.1  Sự khác biệt về phiê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 thă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