|
DAD
ICMPv6
IPv6
LLQC
LLQI
LLQT
MLD
MLDv1
MLDv2
MALI
QQI
QQIC
OSPF
TCP
UDP
|
Phát hiện địa chỉ trùng lặp
Giao thức bản tin điều khiển cho IPv6
Giao thức Internet phiên bản 6
Số lượng truy vấn đối tượng nghe cuối cùng
Khoảng thời gian truy vấn đối tượng
nghe
cuối cùng
Thời gian truy vấn đối tượng nghe cuối cùng
Phát hiện đối tượng nghe multicast
Phát hiện đối tượng nghe multicast
phiên
bản
1
Phát hiện đối tượng nghe multicast phiên bản 2
Khoảng thời gian nghe địa chỉ multicast
Khoảng thời gian truy vấn
của Querier
Mã khoảng thời gian truy vấn của
Querier Querier
Giao thức định tuyến tìm đường ngắn
nhất
Giao thức điều khiển truyền dẫn
Giao thức dữ liệu người dùng
|
Duplicate Address Detection
Internet Control Message Protocol
version 6
Internet Protocol version 6
Last Listener Query Count
Last Listener Query Interval
Last Listener Query Time
Multicast Listener
Discovery
Multicast Listener Discovery version
1
Multicast Listener Discovery version 2
Multicast Address Listening Interval
Querier Query Interval
Querier Query
Interval Code
Open Shortest Path First
Transmission Control
Protocol
User Datagram Protocol
|
5 Tổng quan
Giao thức MLD nói chung (bao gồm cả MLDv1
và MLDv2) là giao thức bất đối xứng, vì giao thức này quy định cách xử lý riêng
biệt cho các đối tượng nghe địa chỉ multicast (tức là các host và router nghe
các gói tin multicast) và các router multicast. Mục đích của MLD là cho phép
router multicast xác định những địa chỉ multicast và những ngưồn có đối tượng
nghe quan tâm đến các địa chỉ và nguồn này trên mỗi liên kết trực tiếp của
router. Thông tin thu thập bởi MLD được cung cấp cho giao thức định tuyến multicast của
router, để đảm bảo rằng các gói tin multicast được phân phối đến tất cả các
liên kết có đối tượng nghe quan tâm đến những gói tin này.
Các router multicast chỉ cần biết tối
thiểu một nút trên liên kết kết nối vào nó đang
nghe các gói tin theo một địa chỉ multicast cụ thể, từ một nguồn cụ thể; một
router multicast không yêu cầu phải theo dõi các nhu cầu của từng nút lân cận một
cách riêng lẻ.
Với giao thức MLDv2, router multicast
thực hiện vai trò router trên mỗi liên kết trực tiếp. Nếu một router multicast
có nhiều giao diện được kết nối vào cùng một liên kết, router đó chỉ cần thực
hiện giao thức MLDv2 trên một trong các giao diện đó. Cách xử lý của router phụ
thuộc vào việc có hay không những router multicast khác trên cùng mạng con. Nếu
có nhiều router multicast trên mạng con thì sử dụng cơ chế bầu chọn Querier để lựa chọn một
router multicast duy nhất đóng vai trò là Querier. Tất cả các router 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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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,
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
- Để 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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
- “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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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})
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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})
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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 phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Để đả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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Đượ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:
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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).
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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ợ)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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 Record là danh sách nguồn của giao diện cho một địa
chỉ multicast cụ thể. Bản ghi MODE_IS_INCLUDE
không bao giờ được gửi với một
danh sách nguồn trống.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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:
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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ốn lắng nghe
các gói tin cho một địa chỉ multicast cụ thể. Nếu thay đổi sang danh sách nguồn
INCLUDE, đây là những địa
chỉ đã được xóa khỏi danh sách, nếu thay đổi sang danh sách nguồn
EXCLUDE, đây là những địa chỉ được thêm vào danh sách.
Nếu sự thay đổi danh sách nguồn dẫn đến
cả việc cho phép các nguồn mới và xóa các nguồn cũ, thì hai bản
ghi địa chỉ 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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
Trạng thái cũ
Trạng thái mới
Bản ghi State Change Record được gửi
INCLUDE (A)
EXCLUDE (A)
INCLUDE (A)
EXCLUDE (A)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
EXCLUDE (B)
EXCLUDE (B)
INCLUDE (B)
ALLOW (B-A), BLOCK (A-B)
ALLOW (A-B), BLOCK (B-A)
TO_EX (B)
TO_IN (B)
Nếu danh sách nguồn được tính toán cho
State Change Record ALLOW hoặc BLOCK là trống, bản ghi đó được bỏ qua khỏi bản tin
Report.
Để chắc chắn rằng bản tin State Change
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ò]).
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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:
Bản ghi
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
TO_IN
Tất cả các nguồn trong trạng thái từng
giao diện hiện tại phải được chuyển tiếp
TO_EX
Tất cả các nguồn trong trạng thái từng giao
diện hiện tại phải được chặn
ALLOW
Tất cả các nguồn có trạng thái truyền
lại (tất cả các nguồn từ danh sách truyền lại) phải được chuyển tiếp
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Tất cả các nguồn có trạng thái truyền
lại phải được chặn
Nếu danh sách nguồn được tính toán cho một
trong hai bản ghi ALLOW hoặc bản ghi BLOCK là trống, bản ghi đó được loại bỏ khỏi bản tin
State Change Report.
Chú ý rằng: Khi bản tin State Change
Report đầu tiên được gửi, bản
tin Report đang chờ để sáp nhập với bản tin này có
thể được đối xử như là một bản
tin Source Change Report với các bản 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ạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
- 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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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:
Trạng thái cho từng giao diện
Tập hợp các nguồn trong bản ghi phản hồi đang ở trạng
thái chờ
Current State Record
INCLUDE (A)
EXCLUDE (A)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
B
IS_IN (A*B)
IS_IN (B-A)
Nếu Current State Record là một tập hợp
rỗng của các danh sách nguồn, thì không có phản hồi nào được gửi. Sau khi các bản
tin Raport đã yêu cầu được tạo ra, các danh sách nguồn có liên quan tới bất kỳ các địa
chỉ multicast được báo cáo nào đều được xóa bỏ.
4. Nếu bộ đếm thời gian cho việc truyền
lại của một địa chỉ multicast kết thúc (tức là có một bản tin State Change
Report đang ở trạng thái chờ cho địa chỉ multicast đó), các nội dung của bản
tin Report được xác định như sau: Nếu bản tin Report chứa Filter Mode Change Record,
tức là bộ
đếm
truyền lại chế độ lọc cho địa chỉ multicast đó có một giá trị lớn hơn 0, và nếu chế
độ lọc
hiện
tại của giao diện là INCLUDE, thì bản 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:
Bản ghi
Các nguồn được bao gồm
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Tất cả các nguồn trong trạng
thái từng giao diện hiện tại phải được chuyển tiếp.
TO_EX
Tất cả các nguồn trong trạng thái từng giao diện
hiện tại phải được chặn.
ALLOW
Tất cả các nguồn có trạng
thái truyền lại (tức là tất cả các nguồn từ danh sách
truyền lại) phải được chuyển tiếp. Với mỗi nguồn nằm trong bản tin Report, bộ
đếm truyền lại nguồn của nó được giảm 1 đơn vị sau khi truyền bản
tin này. Nếu bộ đếm tiến về 0, nguồn được xóa khỏi danh sách truyền lại cho địa
chỉ multicast đó.
BLOCK
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Tất cả các nguồn có trạng thái truyền
lại (tức là tất cả các nguồn từ danh sách truyền lại) phải
được chặn. Với mỗi nguồn
nằm trong bản tin này, bộ đếm truyền lại nguồn của nó được giảm 1 đơn vị sau
khi truyền bản tin Report. Nếu bộ đếm tiến về 0, nguồn sẽ bị xóa
khỏi danh sách
truyền lại cho địa chỉ multicast đó.
Nếu danh sách nguồn được tính toán cho
bản 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ẻ.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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:
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
Chế độ lọc của router
Giá trị bộ đếm thời gian cho chế độ
lọc
Các hoạt động / khuyến nghị
INCLUDE
EXCLUDE
EXCLUDE
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Bộ đếm thời gian > 0
Bộ đếm thời gian = 0
Tất cả các đối tượng nghe ở chế độ
EXCLUDE
Tối thiểu một đối tượng nghe ở chế độ
EXCLUDE
Không còn đối tượng nghe nào ở chế độ EXCLUDE cho
một địa chỉ multicast. Nếu danh
sách được yêu cầu là rỗng thì xóa Multicast Address Record. Nếu
không, chuyển sang chế độ lọc INCLUDE, các nguồn trong danh sách được yêu cầu
được chuyển sang danh sách INCLUDE, và danh sách EXCLUDE sẽ bị xóa bỏ.
10.2.3 Định nghĩa
các bộ đếm thời gian cho nguồn
Bộ đếm thời gian cho nguồn là một bộ đếm
thời gian đếm giảm dần về ngưỡng
nhỏ hơn 0. Mỗi bản ghi nguồn có một bộ đếm thời gian cho nguồn đó. Các bộ đếm
thời gian cho
nguồn được cập nhật theo loại và chế độ lọc của Multicast Address Record nhận
được. Điều 10.4 mô tả việc thiết lập bộ đếm thời gian cho nguồn đối với từng loại
Multicast Address Record nhận được.
Trong các phần sau của tiêu chuẩn này,
các quy ước về chữ viết tắt
như sau được sử dụng. 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 phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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ạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Chế độ lọc của router
Giá trị bộ đếm thời gian cho nguồn
Hành động / khuyến nghị
INCLUDE
Bộ đếm thời gian > 0
Đề nghị chuyển tiếp lưu lượng từ nguồn
INCLUDE
Bộ đếm thời gian == 0
Đề nghị dừng chuyển tiếp lưu lượng từ
nguồn và
xóa
bỏ bản ghi
nguồn. Nếu không có bản ghi nguồn nào, thì xóa
Multicast Address Record
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Bộ đếm thời gian
>
0
Đề nghị chuyển tiếp lưu lượng từ
nguồn
EXCLUDE
Bộ đếm thời gian == 0
Đề nghị không chuyển tiếp lưu lượng
từ nguồn. Chuyển nguồn
từ danh sách được
yêu cầu sang
danh
sách EXCLUDE (không xóa bản ghi nguồn)
EXCLUDE
Không có nguồn nào
Đề nghị chuyển tiếp lưu lượng
từ tất cả các nguồn
10.4 Xử lý khi nhận bản
tin Report
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
Trạng thái router
Bản tin Report nhận được
Trạng thái router mới
Hành động
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
IS_IN (B)
INCLUDE (A+B)
(B)=MALI
INCLUDE (A)
IS_EX (B)
EXCLUDE (A*B, B-A)
(B-A)=0
Xóa (A-B)
Bộ đếm thời gian cho chế độ lọc = MALI
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
IS_IN (A)
EXCLUDE (X+A, Y-A)
(A) = MALI
EXCLUDE (X,Y)
IS_EX (A)
EXCLUDE (A-Y,Y*A)
(A - X - Y) = MALI
Xóa (X-A)
Xóa (Y-A)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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ờ.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Bản tin Report nhận được
Trạng thái router mới
Hành động
INCLUDE (A)
CHO PHÉP (B)
INCLUDE (A+B)
(B)= MALI
INCLUDE (A)
CHẶN (B)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Gửi đi Q(MA,A*B)
INCLUDE (A)
TO_EX (B)
EXCLUDE (A*B,B-A)
(B-A) = 0
Xóa (A-B)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Gửi đi Q(MA,A*B)
Bộ đếm thời gian cho chế độ lọc = MALI
INCLUDE (A)
TO_IN
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
(B) = MALI
Gửi đi Q(MA,A-B)
EXCLUDE (X,Y)
CHO PHÉP (A)
EXCLUDE(X+A,Y-A)
(A)= MALI
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
CHẶN (A)
EXCLUDE (X+(A-Y),Y)
(A-X-Y) = bộ đếm thời gian cho chế độ
lọc
Gửi đi Q(MA,A-Y)
EXCLUDE (X,Y)
TO_EX (A)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
(A-X-Y) = bộ đếm thời gian cho chế độ
lọc
Xóa (X-A)
Xóa (Y-A)
Gửi đi Q(MA,A-Y)
Bộ đếm thời gian cho chế độ lọc =
MALI
EXCLUDE (X,Y)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
EXCLUDE (X+A,Y-A)
(A)=MALI
Gửi đi Q(MA,X-A)
Gửi đi Q(MA)
10.5 Chuyển đổi
các chế độ lọc của router
Bộ đếm thời gian cho chế độ lọc được sử
dụng như một cơ chế cho việc chuyển đổi chế độ lọc của router từ EXCLUDE sang
INCLUDE.
Khi bộ đếm thời gian cho chế độ lọc
EXCLUDE của router kết thúc, router giả định rằng không có nút nào có chế độ lọc
EXCLUDE hiện diện trong liên kết được kết nối. Do đó, router chuyển sang chế độ lọc
INCLUDE với địa chỉ multicast
Một router sử dụng các nguồn trong
danh sách được yêu cầu làm trạng thái của nó cho việc chuyển sang chế độ lọc
INCLUDE. Các nguồn trong danh sách được yêu cầu được chuyển sang danh sách
INCLUDE, trong khi các nguồn trong danh sách EXCLUDE bị xóa bỏ. Ví dụ, nếu trạng
thái của router cho một địa chỉ multicast là EXCLUDE(X,Y) và bộ đếm thời gian
cho chế độ lọc đối với địa chỉ multicast đó kết thúc, router sẽ chuyển sang chế
độ lọc INCLUDE với trạng thái INCLUDE(X). Nếu tại thời điểm chuyển đổi danh
sách được yêu cầu (X) là rỗng. Multicast Address Record sẽ bị xóa khỏi router.
10.6 Các xử lý khi
nhận bản tin
Query
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
10.6.1 Cập nhật bộ đếm
thời gian
MLDv2 sử dụng cờ S (chặn xử lý phía
router) để đảm bảo tính ổn định như được
giải thích trong điều 5.1. Khi một router gửi đi hoặc nhận một bản tin Query có
cờ S rõ ràng, nó phải
cập nhật bộ đếm thời gian của mình để phản hồi lại giá trị kết thúc chính xác
cho địa chỉ multicast và nguồn đang được truy vấn. Bảng tiếp theo mô tả các xử
lý của bộ đếm thời gian khi gửi và nhận một bản tin Multicast Address Specific
Query hoặc bản tin Multicast Address and Source Specific Query với cờ S không
được thiết lập.
Truy vấn
Xử lý
Q(MA,A)
Bộ đếm thời gian nguồn cho các nguồn
trong A được hạ thấp về LLQT
Q(MA)
Bộ đếm thời gian cho chế
độ lọc được hạ về LLQT
Khi một router gửi và nhận một bản tin
Query với cờ S được
thiết lập, nó sẽ không cập nhật bộ đếm thời gian của mình.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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:
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
- 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 phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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 đó.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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:
Bản tin MLDv1
Bản ghi MLDv2 tương ứng
Report
Done
IS_EX ( { } )
TO_IN ( { } )
Các bản tin mang bản ghi BLOCK MLDv2
được bỏ qua, vì là danh
sách nguồn trong các bản tin chứa bản ghi TO_EX () (tức là các bản ghi
TO_EX () được đối xử
như là TO_EX ({
} )).
Mặt 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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
([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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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:
Loại bản tin Query
Số lượng bản tin Report được dự kiến
Bản tin General Query
Tất cả các nút trên liên kết
Bản tin Multicast Address Specific Query
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Bản tin Multicast Address and Source Specific
Query
Tất cả các nút trên liên kết thể hiện
mối quan tâm tới nguồn và địa chỉ multicast
13 Các vấn đề an
toàn bảo mật
Dưới đây là các trường hợp khác nhau của
từng loại bản 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.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Một trong nhiều phương án để thực thi
điều này là cho phép các router theo dõi tất các nguồn mà các nút đang ở trong
chế độ INCLUDE đang nghe, ngay cả khi router ở trong chế độ EXCLUDE. Nếu bộ đếm
thời gian cho chế độ lọc cho một địa chỉ multicast kết thúc (tức là không còn
nút nào trong chế độ EXCLUDE trên liên kết) thì sau đó router sẽ chuyển sang
chế độ INCLUDE một cách liền mạch; các nguồn từ danh sách được yêu cầu sẽ chuyển
sang danh sách INCLUDE, trong khi các nguồn trong danh sách EXCLUDE sẽ bị xóa bỏ.
Phụ
lục B
(Tham khảo)
Bảng đối chiếu nội dung tương đương của TCVN 9802-5:2017
và tài liệu RFC 3810
TCVN
9802-5:2017
Tài liệu
RFC 3810
1 Phạm vi áp
dụng
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
3 Thuật ngữ
và định nghĩa
4 Chữ viết tắt
5 Tổng quan
giao thức
Section 2
5.1 Thiết lập
trạng thái nghe multicast trên các đối tượng nghe địa chỉ multicast
Section 2.1
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 2.2
5.3 Thiết lập trạng thái đối tượng
nghe địa chỉ mulicast trên
router multicast
Section 2.3
6 Giao diện
dịch vụ cho việc yêu cầu nhận IP Multicast
Section 3
7 Trạng thái
nghe multicast được duy trì bởi các nút
Section 4
7.1 Trạng thái từng socket
Section 4.1
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 4.2
8 Các định dạng
bản tin
Section 5
8.1 Bản tin
Multicast Listener Query
Section 5.1
8.2 Bản tin Multicast
Listener Report
Section 5.2
9 Mô tả giao
thức đối với các đối tượng
nghe địa chỉ
multicast
Section 6
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 6.1
9.2 Xử lý khi
nhận bản tin Query
Saction 6.2
9.3 Xử lý khi bộ
đếm thời gian kết thúc
Section 6.3
10 Các mô tả của
giao thức cho router multicast
Section 7
10.1 Các điều
kiện cho những bản tin Query
Section 7.1
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 7.2
10.3 Các quy tắc
chuyển tiếp nguồn MLD cụ thể
Section 7.3
10.4 Xử lý khi
tiếp nhận bản tin Report
Section 7.4
10.5 Chuyển đổi
các chế độ lọc của router
Section 7.5
10.6 Các xử lý
khi nhận bản tin Query
Section 7.6
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 8
11.1 Sự khác biệt về phiên
bản của bản tin Query
Section 8.1
11.2 Cách xử lý
của đối tượng nghe địa chỉ multicast
Section 8.2
11.3 Cách xử lý của router multicast
Section 8.3
12 Danh sách
các bộ đếm thời gian, bộ đếm và giá trị mặc định của
chúng
Section 9
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 9.1
12.2 Khoảng thời gian truy
vấn
Section 9.2
12.3 Khoảng thời
gian phản hồi truy vấn
Section 9.3
12.4 Khoảng thời
gian lắng nghe địa chỉ multicast
Section 9.4
12.5 Khoảng thời
gian hiện diện Querier khác
Section 9.5
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 9.6
12.7 Số lượng truy vấn khi khởi động
Section 9.7
12.8 Khoảng thời
gian truy vấn đối
tượng nghe cuối cùng
(LLQI)
Section 9.8
12.9 Số lượng truy vấn đối
tượng nghe cuối cùng (LLQC)
Section 9.9
12.10 Thời gian
truy vấn đối tượng nghe cuối cùng (LLQT)
Section 9.10
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 9.11
12.12 Thời gian
chờ của Querier phiên bản cũ hơn
Section 9.12
12.13 Khoảng thời
gian chờ host phiên bản cũ hơn
Section 9.13
12.14 Cấu hình
các bộ đếm thời gian
Section 9.14
13 Các vấn đề
an toàn bảo mật
Section 10
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Section 10.1
13.2 Các bản tin
Current State Report
Section 10.2
13.3 Các bản tin State
Change Report
Section 10.3
Phụ lục A (tham khảo)
Lý do thiết kế căn bản
APPENDIX A. Design Rationale
Phụ lục B (tham khảo)
Bảng đối chiếu nội dung tương đương của TCVN
9802-5:2017 và tài liệu RFC 3810
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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ể
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
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