Xem mẫu
- 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
DAD Phát hiện địa chỉ trùng lặp Duplicate Address Detection
ICMPv6 Giao thức bản tin điều khiển cho IPv6 Internet Control Message Protocol
version 6
IPv6 Giao thức Internet phiên bản 6
Internet Protocol version 6
LLQC Số lượng truy vấn đối tượng nghe
cuối cùng Last Listener Query Count
LLQI
Khoảng thời gian truy vấn đối tượng Last Listener Query Interval
LLQT nghe cuối cùng
Last Listener Query Time
MLD Thời gian truy vấn đối tượng nghe
cuối cùng Multicast Listener Discovery
- MLDv1 Phát hiện đối tượng nghe multicast Multicast Listener Discovery version
1
MLDv2 Phát hiện đối tượng nghe multicast
phiên bản 1 Multicast Listener Discovery version
MALI 2
Phát hiện đối tượng nghe multicast
QQI phiên bản 2 Multicast Address Listening Interval
QQIC Khoảng thời gian nghe địa chỉ Querier Query Interval
multicast
OSPF Querier Query Interval Code
Khoảng thời gian truy vấn của Querier
TCP Open Shortest Path First
Mã khoảng thời gian truy vấn của
Querier Querier Transmission Control Protocol
UDP
Giao thức định tuyến tìm đường ngắn User Datagram Protocol
nhất
Giao thức điều khiển truyền dẫn
Giao thức dữ liệu người dùng
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
ĐịaChỉ 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ộtnguồ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ínhtươ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ùngsocket,
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ể
đượcsử 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ếnmulticast 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 viliê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:
Giá trị Tên và ý nghĩa
- 1 MODE_IS_INCLUDE - quy định rằng giao diện có chế độ lọc là INCLUDE cho
một địa chỉ multicast cụ thể. Các trường Source Address [i] trong Multicast
Address Recordlà danh sách nguồn của giao diện cho một địa chỉ multicast cụ
thể. Bản ghiMODE_IS_INCLUDE không bao giờ được gửi với một danh sách
nguồn trống.
2 MODE_IS_EXCLUDE - quy định rằng giao diện có chế độ lọc là EXCLUDE cho
một địa chỉ multicast cụ thể. Các trường Source Address [i] trong Multicast
Address Record nếu có sẽ là danh sách nguồn của giao diện cho địa chỉ
multicast cụ thể.
- Filter Mode Change Record (bản ghi thay đổi chế độ lọc) được gửi bởi một nút bất cứ khi nào một
yêu cầu cục bộ 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:
Giá trị Tên và ý nghĩa
3 CHANGE_TO_INCLUDE MODE - quy định rằng giao diện được thay đổi sang
chế độ lọc INCLUDE cho một địa chỉ multicast cụ thể. Các trường Source
Address [i] trong Multicast Address Record nếu có sẽ là danh sách nguồn mới
của giao diện đối với một địa chỉ multicast cụ thể.
4 CHANGE_TO_EXCLUDE_MODE - quy định rằng giao diện được thay đổi sang
chế độ lọc EXCLUDE cho một địa chỉ multicast cụ thể. Trường Source Address
[i] trong Multicast Address Record nếu có sẽ là danh sách nguồn mới của giao
diện đối vớiđịa chỉ multicast cụ thể.
- Source List Change Record (bản ghi thay đổi danh sách nguồn) được gửi bởi một nút bất cứ khi nào
một yêu cầu 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:
Giá trị Tên và ý nghĩa
5 ALLOW_NEW_SOURCE - quy định rằng các trường Source Address [i] trong
Multicast Address Record này chứa một danh sách nguồn bổ sung mà nút
mong muốn lắng nghe các gói tin cho một địa chỉ multicast cụ thể. Nếu thay
đổi xảy ra tại danh sách nguồn INCLUDE, đây là những địa chỉ được thêm vào
danh sách, nếu thay đổi xảy ra tại danh sách nguồn EXCLUDE, đây là những
địa chỉ được xóa khỏi danh sách.
6 BLOCK_OLD_SOURCE - quy định rằng các trường Source Address [i] trong
Multicast Address Record này chứa một danh sách các nguồn mà nút không
còn mong muốnlắng nghe các gói tin cho một địa chỉ multicast cụ thể. Nếu thay
đổi sang danh sách nguồn INCLUDE, đây là những địa chỉ đã được xóa khỏi
danh sách, nếu thay đổisang danh sách nguồn EXCLUDE, đây là những địa chỉ
được thêm vào danh sách.
Nếu sự thay đổi danh sách nguồn dẫn đến cả việc cho phép các nguồn mới và xóa các nguồn cũ,
thìhai bản ghi địa chỉ 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ảomậ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 địnhtrong
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
nguon tai.lieu . vn
