1.4.1- Phân luồng đệ quy
Gupta và McKeown [3, 7] đã đề xuất một kế hoạch được gọi là Recursive Flow Classification (RFC) và đã áp dụng nó để phân loại gói tin trên nhiều lĩnh vực. Phân loại một gói tin liên quan đến việc lập bản đồ bit các gói header H cho một hành động bit T định danh ( mà T = log N, TH) cho một quy tắc phân loại N. Một điều đơn giản nhưng không thực tế, phương pháp là hành động tiên quyết cho mỗi tiêu đề gói tin 2H khác nhau và lưu trữ các kết quả trong một mảng 2H × 2T.
Do đó, chỉ có một bộ nhớ truy cập là cần thiết để mang lại hành động tương ứng. Nhưng điều này sẽ đòi hỏi bộ nhớ quá nhiều. Mục đích chính của RFC là để thực hiện lập bản đồ như nhau, nhưng qua nhiều giai đoạn (phases), như trong hình 1.20. Bản đồ này được thực hiện đệ quy; ở mỗi giai đoạn, thuật toán thực hiện giảm, lập bản đồ một tập hợp các giá trị cho một tập nhỏ hơn. Trong mỗi giai đoạn, một bộ nhớ trả về giá trị ngắn hơn, đó là thể hiện bằng bit ít hơn so với
chỉ số của bộ nhớ truy cập. Hình minh họa 1.21 và gói lưu lượng kết cấu của chương trình RFC.
Nguyên tắc tổ chức lưu trư. Việc xây dựng các bảng tiền xử lý được giải thích với một quy tắc mẫu đặt C [7] thể hiện trong Bảng 1.8. Lưu ý rằng các thông tin địa chỉ đã được chọn lọc, mà làm cho nó khác với những gì chúng được sử dụng trong thực tế.
Hình 1.21 gói lưu lượng trong việc phân loại lưu lượng đệ quy Bảng 1.8- Ví dụ việc đặt quy tắc
1. Bước đầu tiên xây dựng các bảng tiền xử lý là để phân chia các trường d của tiêu đề gói tin thành nhiều phần được sử dụng cho lập chỉ số truy nhập bộ nhớ song song. Ví dụ, số lượng các khối bằng tám trong hình 1.21. Một cách để có thể cắt phần đầu gói cho bộ quy tắc C được chỉ ra trong hình 1.22.
2. Mỗi tra cứu song song sẽ vạch ra đoạn để một eqID theo các quy tắc. Hãy xem xét một đoạn của các kích thước bit b. Bảng vạch ra của nó là các mục 2b và mỗi mục chứa một eqID cho giá trị khối. Các eqID được xác định bởi những
thành phần (s) trong các quy định đáp ứng phân loại tương ứng với đoạn này. Thuật ngữ " Chunk Equivalence Set” (CES) được sử dụng để biểu thị một tập hợp các giá trị khối có cùng eqID. Để thêm hiểu ý nghĩa của “CES”, xem xét đoạn 3 cho các phân loại trong Bảng 1.8. Nếu có hai gói với giá trị giao thức nằm trong cùng một tập và có trùng tiêu đề khác, các quy tắc của phân loại là không phân biệt giữa chúng. Sau đó, các 'CES' cho đoạn 3 sẽ là:
(a) {TCP} (b) {UDP}
(c) {tất cả các số còn lại trong khoảng 0-255}
Mỗi CES có thể được xây dựng theo cách thức sau đây. Đối với một đoạn b-bit, dự án quy tắc trong phân loại về với số đường [0, 2b - 1]. Mỗi thành phần dự án cho một bộ (không nhất thiết phải liền kề) khoảng trên dòng số. Các điểm kết cuối của tất cả các khoảng dự kiến của các thành phần này tạo thành một tập hợp các khoảng không chồng chéo. Hai điểm trong cùng một khoảng luôn luôn thuộc về các thiết lập tương đương như nhau. Hai khoảng cũng trong tập hợp tương đương như nhau nếu các quy tắc được chính xác. Một ví dụ về đoạn 2 của phân loại trong Bảng 1.8 với điểm cuối của khoảng (I0... I4) và xây dựng bộ tương đương (E0... E3) được thể hiện trong hình 1.23. Bốn CES có thể được giải mã bằng cách sử dụng hai bit. Ví dụ, chúng ta có thể chỉ định '00 ' tới E1, '01' tới E0, '10 'tới E2 và '11' tới E3. Sau đó, các bảng RFC cho đoạn này là đầy với eqIDs tương ứng, chẳng hạn như bảng (20) = '01 ', bàn (23) = '11', vv.
3. Một đoạn trong các bước sau đây được hình thành bởi sự kết hợp của hai (hoặc hơn) khối thu được từ tra cứu bộ nhớ trong các bước trước đó, với một CES tương ứng. Nếu, ví dụ, các khối kết quả là các bit b chiều rộng, chúng ta lại tạo ra bộ tương đương như vậy mà hai số bit b không phân biệt bằng các quy tắc
cùng CES trong phân loại của Bảng 1.8 trong bước thứ hai. Để xác định các bộ tương đương mới cho giai đoạn này, chúng tôi tính toán tất cả các nút giao thông có thể có của các bộ tương đương từ các bước trước đó được kết hợp lại. Mỗi giao điểm khác biệt là một bộ tương đương để tạo ra đoạn mới. Ví dụ, nếu chúng ta kết hợp đoạn 2 (số cổng) và 3 (giao thức), sau đó năm CES có thể thu được:
(a) {({80}, {UDP})} (b) {({20-21}, {UDP})} (c) {({80}, {TCP})} (d) {({ gt1023}, {TCP})}
(e) {tất cả số còn lại crossproducts}.
Đây có thể được thể hiện trong một eqID ba bit, như trong hình 1.24e. Từ ví dụ này, chúng ta có thể thấy rằng số lượng bit đã được giảm từ 4 xuống 3 trong bước một (hai bit cho đoạn 2 và 3, tương ứng) và bước hai. Đối với sự kết hợp của hai bước, con số này đã giảm từ 24 xuống 3.
Hình 1.23 Ví dụ về tính toán tương đương bốn lớp E0. . . E3 cho đoạn 2 (tương ứng với số lớp vận chuyển 16-bit cổng đích) ở các quy tắc của Bảng 1.8.
Hình 3,24 tắc tổ chức lưu trữ cho các RFC cho nguyên tắc quy định tại Bảng 3.8. (a) Trường IP đích được chia thành nhiều phần và epIDs. (b) Trường IP nguồn chia thành nhiều phần và eqIDs. (c) Trường số cổng chia thành nhiều phần và eqIDs. (d) Trường giao thức chia thành nhiều phần và eqIDs. (e) Trường số cổng và trường giao thức chia thành nhiều phần và eqIDs.
Đề án phân loại. Việc phân loại các gói dữ liệu lúc đầu được chia thành nhiều phần được sử dụng cho một chỉ mục, sau đó các eqIDs cần được kết hợp thành nhiều phần của giai đoạn thứ hai, thủ tục này cho đến khi đi vào giai đoạn cuối cùng là đạt được khi tất cả các eqIDs còn lại đã được kết hợp thành chỉ một đoạn. Bảng tương ứng sẽ tổ chức các hoạt động cho gói đó.
Hiệu suất comment. Nội dung của bộ nhớ được chọn để kết quả tra cứu hẹp hơn chỉ mục. Các kết hợp khác nhau của các khối có thể mang lại các yêu cầu lưu trữ khác nhau. Nó được báo cáo [7] phân loại thời gian thực 4D lên đến quy tắc 1700, RFC xuất hiện thực tế cho tốc độ 10 Gbps trong phần cứng và 2,5 Gbps trong phần mềm. Tuy nhiên, không gian lưu trữ và thời gian tiền xử lý cho phát triển phân loại nhanh chóng lớn hơn 6000 quy tắc. Một mô tả tối ưu trong Ref. [7] làm giảm nhu cầu lưu trữ của một phân loại bốn trường từ 15.000 đến dưới 4 MB.
1.4.2- Bộ tìm kiếm không gian.
Srinivansan et al. [13] đã đề xuất một chương trình không gian tìm kiếm tuple để phân loại gói tin đa chiều với các đặc điểm kỹ thuật tiền tố. Các thuật toán tìm kiếm không gian cơ bản tuple phân loại một truy vấn vào các truy vấn phù hợp trong các bảng hash. Thuật toán này được thúc đẩy bởi sự quan sát trong khi phân loại nhiều bản sửa lỗi khác nhau, số tiền tố độ dài khác nhau có xu hướng nhỏ. Như vậy, số kết hợp khác nhau của độ dài tiền tố cũng nhỏ. Sau đó, một tuple cho mỗi kết hợp của các chiều dài trường có thể được xác định và ghép các thiết lập được biết đến của các bit cho mỗi trường theo thứ tự, một khóa hash có thể được
tạo ra để ánh xạ các quy tắc của tuple vào một bảng hash. Giả sử một phân loại C với các quy tắc N có kết quả trong M bộ dữ liệu riêng biệt. Vì M có xu hướng nhỏ hơn nhiều so với N trong thực tế, thậm chí là một tìm kiếm tuyến tính qua các thiết lập tuple có thể sẽ tốt hơn rất nhiều tìm kiếm tuyến tính thông qua phân loại này.
Nguyên tắc tổ chức lưu trư. Mỗi quy tắc R trong phân loại có thể được
ánh xạ vào bộ d có thành phần thứ i xác định độ dài của tiền tố trong trường thứ i của R. Một không gian tuple được định nghĩa là tập hợp của tất cả các bộ dữ liệu của một phân loại. Đối với mỗi tuple trong không gian tuple, một bảng hash được tạo ra lưu trữ tất cả các quy tắc ánh xạ trong các tuple. Ví dụ, Bảng 1.9 cho thấy các bộ dữ liệu và bảng hash cho các phân loại liên quan trong Bảng 1.2. Ví dụ, (1, 2) có nghĩa là độ dài của tiền tố đầu tiên là một và chiều dài của tiền tố thứ hai là hai.
Quy tắc luôn luôn xác định địa chỉ IP bằng cách sử dụng các tiền tố, vì vậy số lượng các bit chỉ định không rõ ràng. Đối với số cổng được sử dụng thường được xác định phạm vi, độ dài của một loạt các cổng được phân loại là mức nesting. Ví dụ, cổng số phạm vi đầy [0, 65535] có mức nesting và độ dài 0. Các phạm vi [0, 1023] và [1024, 65535] được coi là mức nesting 1, và như vậy. Nếu chúng ta đã có thêm khoảng [30.000, 34.000] và [31.000, 32.000], sau đó khuôn đúc sẽ có mức nesting thứ 2 và thứ 3 (thuật toán này giả định rằng số cổng phạm vi quy định tại cơ sở dữ liệu là không trùng nhau).
Trong khi mức nesting của một phạm vi giúp xác định các tuple sẽ được đặt vào, chìa khóa để xác định các quy tắc trong tuple cũng là cần thiết. Vì vậy RangeID được sử dụng, mà là một ID duy nhất cho mỗi phạm vi nesting ở bất kỳ cấp độ nào đó. Vì vậy, luôn luôn có đầy đủ các ID 0. Hai dãy ở độ sâu 1, cụ thể là, ≤ 1023 và> 1024, nhận được các ID 0 và 1, tương ứng. Giả sử chúng ta đã có
khoảng 200. . . 333, 32000. . . 34.230 và 60.000. . . 65.500 ở mức 2, sau đó chúng sẽ cho 0 ID, 1 và 2, tương ứng.
BẢNG 1.9- Ví dụ của Chương trình tìm kiếm không gian tuple
Chú ý rằng một cổng được cho trong một gói tin header có thể được ánh xạ tới một ID khác nhau ở mỗi cấp nesting. Ví dụ, với các phạm vi nêu trên, một số cổng 33.000 sẽ ánh xạ đến ba giá trị RangeID, một cho mỗi chiều dài nesting: ID 0 cho chiều dài nesting 0, ID 1 cho chiều dài nesting 1, và ID 1 cho chiều dài nesting 2. Như vậy, một số cổng trường trong gói tin header phải được biến đổi sang các giá trị tương ứng của nó trước khi RangeID tìm kiếm tuple được thực hiện. Tóm lại, mức nesting được sử dụng để xác định các tuple, và các RangeID cho mỗi cấp nesting được sử dụng để tạo phím hash, đầu vào cho hàm hash.
Đề án phân loại. Tất cả các quy tắc ánh xan cho một tuple đặc biệt có
khuôn mẫu giống nhau: một số bit trong IP nguồn và các trường điểm đến, hoặc một ký tự đại diện trong trường giao thức hoặc cụ thể ID một giao thức, và các trường cổng có chứa hoặc một ký tự đại diện hoặc một RangeID. Vì vậy, chúng ta có thể ghép số yêu cầu của các bit từ mỗi trường để xây dựng một khóa hash cho
quy tắc đó. Tất cả các quy tắc ánh xạ tới một U tuple được lưu trữ trong một bảng băm Hashtable (U). Ví dụ, các quy tắc R4 và R5 được lưu trữ trong cùng một bảng băm, nói Hashtable2. Một sự thăm dò trong một tuple U liên quan đến việc ghép các số yêu cầu của các bit từ gói tin theo quy định của U (sau khi chuyển đổi số cổng tới RangeID), và sau đó làm một hash trong Hashtable (U). Khóa sẽ được hash trong mỗi bảng để tìm ra quy luật xuất hiện. Ví dụ, các phím được hash và xuất hiện với R4 trong Hashtable2. Như vậy, với một gói P, chúng ta có thể thăm dò tuyến tính tất cả các bộ dữ liệu trong các thiết lập tuple, và xác định các ưu tiên cao nhất phù hợp với bộ lọc P.
Hiệu suất comment. Thời gian tính toán truy vấn của các không gian tìm kiếm tuple cơ bản là O (M), trong đó M là số lượng các bộ dữ liệu trong không gian tuple. Perfect hash được giả định ở đây, được lựa chọn để tránh va chạm hash. M còn rất lớn cho nhiều trường hợp thực tế. Như vậy, một sự đơn giản nhưng hiệu quả tối ưu hóa gọi là cắt tỉa tuple được đề xuất trong [13] để cải thiện tốc độ truy vấn và cập nhật hiệu năng. Khi một gói header được phân loại, tiền tố dài nhất ánh xạ được thực hiện đầu tiên trong mỗi chiều. Các tiền tố ánh xạ tốt nhất Pi trong mỗi i chiều trả về một danh sách tli tuple đó là precomputed và kết hợp với tiền tố. Mỗi tuple trong danh sách tuple từ Pi chứa ít nhất một quy tắc mà trường thứ i bằng Pi hoặc là một tiền tố của Pi. Một danh sách các tuple, danh sách các giao lộ, có nguồn gốc từ các giao điểm của tất cả tli. Đối với một truy vấn được cho, chỉ có các bộ dữ liệu có trong danh sách giao lộ cần phải được tìm kiếm. Nó sẽ được hưởng lợi nếu việc giảm không gian tuple dành bởi hiệu số cắt tỉa thêm tiền tố cá nhân (hoặc nhiều) phù hợp trên mỗi trường. Tham khảo [13] báo cáo rằng có cắt tỉa tuple chỉ ở hai trường, ví dụ, các nguồn và đích địa chỉ IP, số lượng các bộ dữ liệu cần được tìm kiếm sẽ giảm đáng kể.
Tính toán không gian lưu trữ cho tìm kiếm tuple là O (NdW) từ đó mỗi quy tắc được lưu trữ trong bảng hash một cách chính xác. Gia tăng cập nhật được hỗ trợ và yêu cầu chỉ là một bộ nhớ truy cập hash tới bảng hash liên kết với các tuple của luật sửa đổi. Tuy nhiên, việc sử dụng hash có thể đã va chạm hash là nguyên nhân các tìm kiếm/cập nhật không được quyết định.