Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)

Thiết kế hệ thống và xây dựng driver giúp tăng
tốc mã hóa trên nền tảng FPGA hỗ trợ IPSEC
VPN
Nguyễn Hồng Hòa, Nguyễn Phan Hải Phú, Bùi Quốc Bảo, Hoàng Trang
Khoa Điện-Điện Tử, Trường Đại học Bách Khoa TP. HCM
Đại học Quốc gia Thành phố Hồ Chí Minh
Email:
Tóm tắt— Trong bài báo này, chúng tôi đề xuất giải pháp
thiết kế hệ thống và xây dựng driver giao tiếp giữa khối
trung tâm với khối mã hóa trên card PCIe – FPGA để có
tăng tốc IPsec VPN cũng như giảm tải các tác vụ liên quan
đến IPsec. Với hệ thống này, nó sẽ địi hỏi độ phức tạp thấp
hơn khi không đảm nhận các giai đoạn khác trong giao
thức Encapsulating Security (ESP) cũng như giai đoạn
trao đổi khóa Internet Key Exchange (IKE) ban đầu. Với
những lợi ích và khả năng của hệ thống này, nó sẽ phù hợp
để tích hợp với các thiết bị nhúng cỡ nhỏ hay các nút mạng
có năng lực xử lý không mạnh.

overheads) sẽ chiếm tỉ lệ lớn nhất trong tổng chi phí
(overheads) [1]. Mặc dù giao thức ESP chỉ chiếm chi phí
ít cho 1 gói nhưng khi xử lý một số lượng lớn các gói
trong cùng 1 kết nối thì chi phí cho việc xử lý ESP (ESP
overheads) có thể vượt trội so với chi phí cho IKE. Đối
với một kết nối IPsec VPN có thời gian tồn tại đủ lâu,
việc thực hiện mã hóa đóng vai trị then chốt trong thời
gian xử lý gói ESP. Lựa chọn một thuật toán tối ưu cùng
việc sử dụng phần cứng tăng tốc cho việc mã hóa có thể
cải thiện thời gian quá trình xử lý gói ESP [1]. Cơng

trình [2] đã đưa ra cách nhìn tổng quan về bộ giao thức
IPsec và kiến trúc cũng như đưa ra những ứng dụng thực
tế việc triển khai IPsec có thể tăng lên sự tiêu thụ tài
nguyên của CPU một cách đáng kể. Sự tiêu thụ tài
nguyên CPU phụ thuộc vào lưu lượng IPsec hay giao
thức mã hóa đã sử dụng. Hiện tại, các thuật toán thể hiện
tốt nhất sự cân bằng giữa sự cung cấp bảo mật và hiệu
năng là GCM-AES bởi vì nó cho phép việc triển khai
trên phần cứng [2]. Với sự sẵn có của các sản phẩm
thương mại hỗ trợ việc giảm tải IPsec, các giải pháp
IPsec cung cấp sự đánh đổi giữa sự đơn giản của việc
triển khai với sự phổ biến của việc thực thi bằng phần
mềm và tổng thể hiệu suất nền tảng có thể đạt với giải
pháp phần cứng. Các giải pháp dựa trên phần mềm là
được đề xuất như là một điểm bắt đầu mặc định. Khi chi
phí CPU cho việc xử lý lưu lượng IPsec là một vấn đề,
hướng giải quyết bằng cách giảm tải phần cứng nên
được cân nhắc. Dựa trên những đánh giá của các nghiên
cứu trong các bài báo và sách đã đề cập ở trên, ta đi đến
những đánh giá chung cho việc cải thiện tốc độ IPsec
VPN nói chung cũng như hiệu năng của việc thực thi bộ
giao thức IPsec nói triêng. Ta thấy rằng việc thực thi xử
lý gói theo giao thức IPsec có thể làm tăng lên sự tiêu
thụ tài nguyên của CPU một cách đáng kể và sự tiêu thụ
tài nguyên CPU này phụ thuộc vào lưu lượng IPsec. Và
khi đó giải pháp dựa trên phần cứng tăng tốc mã hóa sẽ
đóng vai trị quan trọng trong việc đạt đến hiệu năng cao
ở trong hệ thống lớn cũng như là một cách tiếp cận hữu
ích trong việc làm giảm mức sử dụng CPU ở hệ thống
nhỏ và chậm.


Từ khóa- Internet Protocol Security (IPsec), Peripheral
Component Interconnect Express (PCIe), Driver giao tiếp
PCIe, OS Specific, Driver Specific.

I.

GIỚI THIỆU

Ngày nay, khi mà thời đại Internet phát triển rộng
khắp, những dịch vụ như đào tạo từ xa, mua hàng trực
tuyến, tư vấn y tế trực tuyến đã trở nên khá phổ biến với
tất cả mọi người. Từ đó, người ta đã đưa ra mơ hình mới
nhằm thỏa mãn những u cầu trên mà vẫn tận dụng
được cơ sở hạ tầng mạng vốn có, đó chính là mạng riêng
ảo (Virtual Private Network-VPN). VPN cung cấp cơ
chế mã hóa dữ liệu trên đường truyền tạo ra một đường
ống (tunnel) bảo mật giữa nơi gửi và nơi nhận và IPsec
(Internet Protocol Security) chính là một trong những
giao thức tạo nên cơ chế “đường ống bảo mật” cho VPN.
IPsec là một bộ giao thức bổ sung bảo mật đối với thông
tin trao đổi ở lớp IP trong mơ hình mạng TCP/IP. Đối
với một nút mạng điển hình, việc triển khai thực thi giao
thức IPsec được mặc định sử dụng phần mềm đơn thuần
và ít nhiều đã gây ra giảm thông lượng mạng đi qua nút
cũng như làm quá tải CPU của thiết bị đó. Khi tốc độ
mạng tăng lên, việc giảm thiểu chi phí xử lý (processing
overheads) gói IPsec là yêu cầu tất yếu trong nhiều hệ
thống đặc biệt là những gateway, những thiết bị nhúng
cỡ nhỏ nhưng đồng thời cũng đặt ra nhiều thách thức cần

phải đối mặt.
Khi xây dựng hệ thống IPsec VPN có nhiều vấn đề
gặp phải. Khi kết nối VPN tồn tại trong một khoảng thời
gian ngắn, chi phí cho q trình trao đổi khóa IKE (IKE

ISBN: 978-604-80-5076-4

202


Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)

Trong bài báo này, chúng tơi sẽ trình bày cách xây
dựng mơ hình hệ thống, trong đó phần tăng tốc mã hóa
sẽ thực hiện trên nền tảng FPGA. Và để nâng cao hơn
hiệu năng ở trong các hệ thống, thiết kế driver giúp tăng
tốc giữa khối FPGA và hệ thống chính thơng qua cổng
PCIe là một yếu tố quan trọng và được đề xuất trong bài
báo này. Với thiết kế hệ thống của chúng tôi sẽ hỗ trợ
hiệu quả cho những thiết bị nhúng để giảm tải cho CPU
khi xét đến chi phí xử lý mã hóa cho giao thức IPsec. Hệ
thống mã hóa sẽ gồm hai phần: Lõi IP thực thi mã hóa
và Linux driver. Trong đó bài báo sẽ đi sâu vào việc xây
dựng Linux driver để tích hợp thiết bị mã hóa này vào
các thiết bị nhúng Linux đang cần xử lý các vấn đề liên
quan đến IPsec VPN. Linux driver sẽ thực hiện giao tiếp
và xử lý các vấn đề truyền nhận dữ liệu giữa IPsec Stack.
Phần xây dựng bộ mã hóa và giải mã trên phần cứng sẽ
khơng được đề cập đến trong bài báo này.
Phần còn lại của bài báo được tổ chức như sau:

Chúng tôi sẽ trình bày phương thức thực hiện của giao
thức IPsec VPN trong Phần II. Phần III sẽ đưa ra mơ
hình để nâng cao hiệu suất trong việc triển khai IPsec
VPN. Chúng tôi sẽ tiến hành thiết kế phần Device Driver
cho mô hình đã được nêu bên trên trong phần IV. Phần
V sẽ cung cấp các kết quả của bài kiểm tra hệ thống để
từ đó đưa ra các nhận xét về hiệu suất của mơ hình đã đề
cập. Cuối cùng, chúng tôi kết luận bài báo trong phần
VI.
II.

Tổng quan về kết nối IPsec VPN được thể hiện bởi
hình 2:

Hình 2. Tổng quan về kết nối IPsec

Mục đích của giao thức trao đổi khóa (IKE) là
thương lượng, tạo và quản lý các liên kết bảo mật (SA)
[7]. Liên kết bảo mật (SA) là một thuật ngữ chung cho
một tập hợp các giá trị xác định các tính năng và bảo vệ
IPsec được áp dụng cho một kết nối. Các SA cũng có thể
được tạo theo cách thủ công, sử dụng các giá trị được
thỏa thuận trước bởi cả hai bên, nhưng các SA này
không thể được cập nhật; phương pháp này không mở
rộng quy mô cho các VPN quy mô lớn trong đời thực
Trong IPsec, IKE được sử dụng để cung cấp một cơ chế
an toàn để thiết lập các kết nối được bảo vệ bằng IPsec.
Các phần sau mô tả năm loại trao đổi IKE (chế độ chính,
chế độ tích cực, chế độ nhanh, thơng tin và nhóm) và
giải thích cách chúng hoạt động cùng nhau cho IPsec.

Để triển khai IPsec trong Linux Kernel, ta sẽ bắt đầu
với một sự trình bày ngắn về trình xử lý ngầm (daemon)
nằm trên khơng gian người dùng (user space) là Internet
Key Exchange (IKE) và mật mã trong IPsec. Để thiết lập
kết nối IPsec, ta cần phải thiết lập liên kết bảo mật (SA)
với sự trợ giúp của các project ở không gian người dùng
(userspace). Trong đó, địa chỉ nguồn và chỉ số tham số
bảo mật (SPI) (được gọi là trình khởi tạo và trình phản
hồi trong thuật ngữ IPsec) nên đồng ý về các tham số
như một khóa (hoặc nhiều hơn một khóa), xác thực, mã
hóa, tính tồn vẹn dữ liệu và các thuật tốn trao đổi khóa
và các tham số khác như thời gian tồn tại của khóa (chỉ
IKEv1). Trong nhân Linux, hầu hết API Crypto thực
hiện các lệnh gọi đồng bộ. Có các triển khai không đồng
bộ cho tất cả các loại thuật toán. Rất nhiều bộ phần cứng
tăng tốc sử dụng giao diện API mật mã (cryptography)
không đồng bộ để giảm tải cho việc xử lý yêu cầu liên
quan đến mã hóa. Q trình nhận gói IPsec được thể hiện
bằng lưu đồ ở hình 3. Nhìn chung, khi lớp IP nhận được
gói tin (message). Dựa theo trường giao thức của gói tin
(message), nếu là loại IPsec (AH, ESP), nó sẽ được xử
lý với XFRM framework. Đối với q trình gửi gói
IPsec, sau khi tra cứu định tuyến tin nhắn, SA sẽ được
xem xét có đáp ứng u cầu hay khơng. Nếu khơng thì
được đưa ra IP Output; nếu có, nó sẽ đi vào quá trình
XFRM và thực hiện xử lý tương ứng theo chế độ và giao
thức.

GIAO THỨC BẢO MẬT INTERNET


Giao thức bảo mật Internet, hay còn gọi là IPsec, là
một tập hợp các giao thức hỗ trợ bảo vệ thông tin liên
lạc qua mạng IP [3]. Các giao thức IPsec làm việc cùng
nhau theo nhiều cách kết hợp khác nhau để bảo vệ thông
tin liên lạc. IPsec là giao thức nằm ở lớp 3 – lớp Network
trong mơ hình OSI hay TCP/IP. Hai giao thức cốt lõi
trong IPsec, được thể hiện trong hình 1, là
Authentication Header (AH) và Encapsulating Security
Payload (ESP). Điều cần lưu ý để IPsec có thể hoạt động
là mơ hình phải có hỗ trợ trao đổi khóa (IKE) để giúp
hai điểm trên mạng có thể trao đổi thơng tin một cách
bảo mật. IKE giúp máy tính có thể trao đổi khóa để mã
hóa, phương thức mã hóa được dùng cho IPsec qua môi
trường mạng không tin cậy mà vẫn giữ được tính bảo
mật và điểm kết nối IPsec phải có hỗ trợ các bộ mã hóa,
hàm băm để hoạt động.

Hình 1. Giao thức cốt lõi của IPsec

ISBN: 978-604-80-5076-4

203


Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)

Kiến trúc Look-aside sẽ giúp ta giảm tải nhiều cho quá
trình xử lý gói theo giao thức ESP. Kiến trúc Look-aside
cung cấp giải pháp để tăng tốc quá trình xử lý IPsec và
tập trung chủ yếu ở giao thức ESP – được diễn ra trong

quá trình trao đổi dữ liệu trong đường hầm IPsec (Phase
2). Trong khi đó, giải pháp Flow-through có thể hỗ trợ
nhà sản xuất thiết bị gốc phát triển thiết bị VPN vì nhà
thiết kế có thể tích hợp các thiết bị Flow-through trực
tiếp vào đường dẫn chính (data path) do chúng hầu như
khơng ảnh hưởng phần cịn lại của hệ thống. Điều này
có thể làm khối lượng thiết kế hệ thống cần thiết của các
nhà phát triển OEM. Các thiết bị Flow-through có thể
giảm thêm rủi ro thiết kế bằng cách kết hợp giải pháp
IPsec/IKE được chứng nhận của ICSA Labs, đảm bảo
khả năng tương tác được kiểm tra và chứng nhận [4].
Tuy nhiên việc xây dựng hệ thống IPsec theo kiến trúc
Flow-through đòi hỏi độ phức tạp cao, chưa thật sự cần
thiết cho mơ hình tăng tốc này.
Bộ tăng tốc IPsec có thể được sử dụng để hạn chế số
chu kỳ CPU thực hiện việc xử lý IPsec-ESP. Trong các
tác vụ xử lý được đề cập ở trên, q trình mã hóa và giải
mã sẽ là hai cơng việc tính tốn nhiều nhất. Thiết bị tăng
tốc mã hóa có thể được sử dụng hiệu quả để giảm tải các
tác vụ IPsec liên quan đến việc mã hóa/giải mã. Các bộ
tăng tốc này có thể là một phần của CPU, hay là một bộ
xử lý mật mã nằm trong SoC hay là một card PCIe được
gắn thêm. Do vậy, bộ tăng tốc theo kiểu Look-aside
được mô tả như là một bộ tăng tốc mã hóa độc lập với
CPU.
Qua những đánh giá và phân tích về các giải pháp
cho việc giảm tải các tác vụ liên quan đến IPsec được đề
cập ở trên, nhóm đề xuất giải pháp thiết kế hệ thống với
khối mã hóa theo trên card PCIe - FPGA để có thể tăng
tốc IPsec VPN cũng như giảm tải các tác vụ liên quan

đến IPsec. Với hệ thống này, nó sẽ được thiết kế theo
kiểu Look-aside và đảm nhận cơng việc u cầu tính
tốn nhiều nhất - mã hóa và giải mã. Hệ thống mã hóa
này sẽ địi hỏi ít độ phức tạp hơn khi khơng đảm nhận
các giai đoạn khác trong giao thức ESP (ví dụ như giai
đoạn tra bảng SA) cũng như giai đoạn trao đổi khóa IKE
(lúc thiết lập kết nối). Với những lợi ích và khả năng của
hệ thống này, nó sẽ phù hợp để tích hợp với các thiết bị
nhúng cỡ nhỏ hay các nút mạng có năng lực xử lý khơng
mạnh.

Hình 3. Q trình xử lý IPsec Outbound
Các gói tin từ lớp 4 (UDP,TCP) xuống lớp 3 là lớp
IP. Khi bắt đầu ở lớp 3, các gói tin được chuển đến đích
bằng các tra bảng routing table, bước này gọi là IP
routing decision. Sau đó đến phần IP source address
selection, đây là bước quan trọng bởi vì khi tạo một gói
tin IP, nó phải chọn địa chỉ IP nguồn để khi gửi đến bên
thu, bên phía thu mới biết được chính xác địa chỉ IP mà
cần phải phản hồi về. Các bước tiếp theo sẽ xác định gói
đó có được mã hóa (ESP) hay xác thực (AH) khơng. Nếu
có, gói tin sẽ chuyển đến phần mã hóa hoặc phần xác
thực gói tin. Sau khi đã được mã hóa và xác thực, bước
tiếp theo sẽ kiểm tra sự thay đổi về header của gói tin.
Do ESP có 2 chế độ là chế độ tunnel và chế độ transport.
Chế độ tunnel sẽ mã hóa tồn bộ gói, bao gồm cả header
gốc và thay vào đó là một header mới. Chế độ transport
chỉ mã hóa phần data, giữ lại header gốc. Cuối cùng, gói
tin IP sẽ chuyển đến lớp dưới. Tuy nhiên, nếu như ESP
ở chế độ tunnel, thì nó sẽ tiến hành mã hóa tồn bộ gói

ESP rịi quay lại lớp 3 (lớp IP).
III.

IV.

Peripheral Component Interconnect Express (sau
đây viết tắt là PCIe), như tên gọi, là một chuẩn giao tiếp
tốc độ cao dùng để giao tiếp giữa các phần tử trong hệ
thống (giao tiếp giữa vi xử lý và ngoại vi hoặc giữa các
ngoại vi). PCIe ra đời để đáp ứng nhu cầu về tốc độ khi
tần số hoạt động ngày càng cao của vi xử lý cũng như
các ngoại vi. Điểm căn bản khác biệt để PCIe đạt được
tốc độ cao hơn PCI là do PCI dùng kiểu giao tiếp song
song còn PCIe dùng kiểu truyền nối tiếp.

MƠ HÌNH TRIỂN KHAI IPSEC

Hiện nay, có rất nhiều tùy chọn để nâng cao hiệu suất
trong việc triển khai IPsec, từ triển khai phần mềm thuần
túy bằng cách sử dụng tập lệnh CPU (Instruction Set)
dành riêng cho việc mã hóa cho đến sử dụng một phần
cứng chuyên biệt cho việc giảm tải thời gian xử lý gói
IPsec. Thơng thường, có 2 kiểu kiến trúc thiết kế là
Look-aside và Flow-through để giải quyết vấn đề trên.

ISBN: 978-604-80-5076-4

THIẾT KẾ DEVICE DRIVER GIAO TIẾP
THIẾT BỊ CARD PCIE


204


Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)

Để hệ thống có thể nhận diện được thiết bị có chứa
card PCIe thì ta cần xây dựng Driver giao tiếp với yêu
cầu phải xây dựng lớp giao tiếp với card thông qua PCIe
và đảm bảo truyền nhận chính xác dữ liệu với thiết bị
card PCIe; xây dựng lớp giao tiếp với các ứng dụng cũng
như IPsec Stack trong Linux kernel để những ứng dụng
này có thể sử dụng được driver này; đảm bảo độ chính
xác của giải thuật mã hóa khi được sử dụng bởi IPsec
stack trong Linux Kernel với các ứng dụng trên lớp User
space; và đồng thời phải đạt tốc độ mã hóa và thơng
lượng IPsec VPN cao (hơn 100 Mbps). Device Driver là
khối phần mềm chính mà khi triển khai một thiết bị mới
thì lập trình viên phải lập trình lại gần như hồn tồn.
Việc tách khối Driver và khối Bus Driver giúp các thiết
bị có chức năng khác nhau mà sử dụng chung một giao
thức bus để giao tiếp với hệ thống sử dụng toàn bộ các
hàm thực hiện chức năng giao tiếp qua bus.

Hình 5. Tiến trình xử lý kết quả mã hóa và gọi hàm callback
cho IPsec

Với tiến trình (process) xử lý u cầu mã hóa, nó sẽ
khởi tạo giá trị các trường trong struct private context
của gói yêu cầu mã hóa; thực hiện kiểm tra các bộ đệm
lưu trữ dữ liệu cần xử lý ( mã hóa hoặc giải mã) và kiểm

tra các điều kiện entry của của scatter gather list; thêm
gói yêu cầu mã hóa vào danh sách hàng đợi và tiến trình
này sẽ lập lịch cho 1 work thực thi tiến trình “xử lý và
gửi gói yêu cầu cho lớp device-specific” trong tương lai.
Cuối cùng, tiến trình sẽ kết thúc bằng cách trả về giá trị
“đang xử lý” cho API gọi nó và kết thúc tiến trình. Việc
triển khai mã hóa trên bộ phần cứng tăng tốc thường sử
dụng giao diện API mã hóa bất đồng bộ, đơn giản bởi vì
các tác vụ xử lý mã hóa khơng thể bị blocking cho đến
khi thực hiện xong. Vì vậy, tiến trình này được thiết kế
sẽ kết thúc ngay sau khi thêm các gói yêu cầu vào danh
sách hàng đợi
Với tiến trình thiết lập và gửi gói yêu cầu cho lớp
device-specific, nó lấy gói yêu cầu mã hóa từ trong hàng
đợi; thực hiện cấp phát và khởi tạo gói yêu cầu vận
chuyển tương ứng với các gói yêu cầu mã hóa. Những
gói yêu cầu này có chứa các dữ liệu cần mã hóa phù hợp
với định dạng dữ liệu trên FPGA và tiến hành gửi gói
yêu cầu vận chuyển xuống lớp xử lý device-specific
driver.
Sơ đồ hình 6 giải thích cách hoạt động của q trình
di chuyển dữ liệu qua lại giữa card FPGA và Host dùng
DMA qua PCIe. Trong đó: “Tiến trình sử dụng” và
“Tiến trình phục vụ ngắt” là các tiến trình bình thường
và chạy ở bối cảnh tiến trình. “Trình phục vụ ngắt MSI”
chạy ở bối cảnh ngắt.
Tiến trình gọi API để di chuyển dữ liệu dùng DMA
bị rơi vào trạng thái Sleep trong q trình hoạt động. Do
đó, khơng thể gọi hàm này trong ngữ cảnh ngắt hoặc
Bottom Halves. Hàm ngắt phục vụ cho user_irq được


Hình 4. Tiến trình yêu cầu xử lý mã hóa

Khối Driver gồm hai phần là OS specific và phần
Device specific. OS Specific giúp cung cấp cho hệ hành
các dịch vụ cơ bản của thiết bị (ví dụ như đọc, ghi vào
bộ nhớ của thiết bị) theo một chuẩn chung. Điều này
giúp việc phát triển hệ điều hành một cách độc lập mà
không ảnh hưởng đến các driver cũ. Trong khi đó, device
specific có chức năng điều khiển thiết bị thực hiện đúng
tính năng của nó. Lấy driver cho card mạng làm ví dụ:
Phần OS specific của driver sẽ đảm bảo việc giao tiếp
mạng với các module khác của hệ thống theo đúng
chuẩn cũng như cung cấp các dịch vụ cho các hệ thống
khác trong nhân Linux. Phần Device specific nhận các
yêu cầu từ phần OS specific và thực hiện cấu hình, kiểm
sốt q trình hoạt động của card mạng và trả về kết quả
cho lớp OS specific.

ISBN: 978-604-80-5076-4

205


Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)

thực hiện trong bối cảnh ngắt, do đó, khơng được dùng
các hàm có thể gây Sleep. Trình phục vụ ngắt để báo
việc hồn tất một lượt di chuyển dữ liệu bằng DMA chỉ
lập lịch cho tiến trình phục vụ ngắt. Việc đánh thức tiến

trình gọi API di chuyển dữ liệu bằng DMA được thực
hiện bởi tiến trình phục vụ ngắt ở bối cảnh tiến trình.
Kiến trúc khối phần mềm sử dụng API di chuyển dữ
liệu dùng DMA được thể hiện trong hình 7. Gồm hai tiến
trình con và hai danh sách liên kết. “Danh sách yêu cầu
mã hóa” là nơi lưu trữ các u cầu từ “Tiến trình u cầu
mã hóa” và sẽ được một tiến trình khác đảm nhiệm
nhiệm vụ di chuyển dữ liệu sang card FPGA, mã hóa, di
chuyển dữ liệu đã mã hóa trở lại bộ nhớ chính.

Hình 7. Mơ hình kiến trúc phần mềm

V.

KẾT QUẢ THỰC HIỆN

Trong phần này, chúng tôi sẽ thực hiện các bài kiểm
tra để khảo sát tốc độ truyền nhận dữ liệu theo gói trên
thực tế.
Trước hết, hệ thống router của chúng tôi được chế
tạo như trong hình 8 dưới đây để thực nghiệm, và đo
đạc các kết quả. Marvell ARM Cortex A9 được lựa
chọn làm CPU cho Router với tần số hoạt động cao nhất
là 1.6 GHz. Đối với khối mã hóa, chúng tơi sử dụng
core FPGA XC7A200TFBG484 – 2 thuộc dòng Artix 7
của Xilinx. Vùng nhớ RAM Inbound (bộ nhớ lưu trữ
data mã hóa) và vùng nhớ RAM Outbound (bộ nhớ lưu
trữ data đã mã hóa) có dung lượng 16KB, trong khi
dung lượng của một gói data gửi xuống để mã hóa dưới
2KB [10]. Như vậy, hệ thống sẽ không bị tăng quá mức

tài ngun khi tăng tốc độ mã hóa.

Hình 6. Sơ đồ kiến trúc phần mềm driver XDMA của Xilinx

Việc tách cơng việc mã hóa sang một tiến trình khác
giúp tổng thể q trình thực hiện khơng bị phụ thuộc vào
ngữ cảnh (context), làm việc lập trình trở nên đơn giản
hơn. Tương tự, “danh sách gọi callback” là nơi lưu trữ
các yêu cầu thực hiện hàm callback. Do thời gian thực
hiện hàm callback có thể thay đổi và có thể sẽ mất thời
gian, việc thực hiện nó được chuyển riêng sang một tiến
trình khác để tối ưu hóa việc sử dụng card FPGA để mã
hóa.

ISBN: 978-604-80-5076-4

Hình 8. Hệ thống router của chúng tôi chế tạo để thử nghiệm

Bài kiểm tra được thực hiện với hai mơ hình driver
để so sánh sự ảnh hưởng của thiết kế khối phần mềm đến
tốc độ truyền nhận trên cả hai mơ hình. Lược bỏ đi q
trình khởi động mã hóa và chờ ngắt để di chuyển dữ liệu
lên trên RAM của Host, bài kiểm tra này thể hiện tốc độ
truyền nhận theo gói mà hai kiểu thiết kế đã nêu có thể
đạt được nếu bỏ qua sự cồng kềnh trong giao thức bắt
tay giữa phần mềm và khối thực hiện chức năng mã hóa.

206



Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)

Chúng tôi sẽ tính tốn tốc độ khi cấu hình PCIe từ 1
làn đến 4 làn khi áp dụng trên cả 2 CPU là core i5 7500
và SoC Mavell Cortex A9. Chúng tôi sẽ sử dụng module
test để mơ phỏng q trình u cầu xử lý theo giao thức
IPsec. Trong bài kiểm tra này, ta sẽ sử dụng 3 gói yêu
cầu mã hóa với 3 dung lượng khác nhau, lần lượt là 320
bytes, 1120 bytes, 1500 bytes. Cách đo của module test
được thể hiện cụ thể qua các bước sau:
▪ Module test khởi tạo timer với thời gian 10 giây
▪ Thực hiện gửi gói yêu cầu mã hóa liên tục xuống
card FPGA
▪ Sau mỗi lần kết quả mã hóa được gửi từ driver lên
đến hàm callback của module test, biến đếm số gói
mã hóa sẽ tăng lên 1.
▪ Q trình này sẽ kết thúc sau 10 giây và in ra màn
hình số gói mã hóa được. Từ số gói mã hóa, ta có
thể tính được tốc độ mã hóa hay thơng lượng mã
hóa như sau:
𝑇ℎơ𝑛𝑔 𝑙ượ𝑛𝑔 =

và SFP, do đó khi gắn card FPGA với 1 làn PCI thì tốc
độ được thấy trong hình 10, ta thấy tốc độ cũng tăng dần
khi dung lượng gói tăng.
Từ bài kiểm tra tốc độ truyền dữ liệu khi chưa có
hoạt động mã hóa, ta suy ra được nút thắt cổ chai trong
cả quá trình hiện tại là khối driver mã hóa. Nguyên nhân
là do driver hoạt động chưa hiệu quả, q trình bắt tay
vẫn cịn rườm rà. Kênh truyền chưa được sử dụng triệt

để. Do có thêm vấn đề xử lý các vấn đề liên quan đến
việc mã hóa, tốc độ truyền nhận giảm từ 800Mbps còn
302Mbps trên router và từ 7000Mbps xuống còn
430Mbps trên PC – 4 làn.
VI.

KẾT LUẬN

Trong bài báo này, chúng tôi đã xây dựng mơ hình
để thực hiện giao thức IPsec VPN với khả năng tăng tốc
do thực hiện việc mã hóa trên nền tảng FPGA qua giao
tiếp PCIe. Đồng thời, thiết kế driver cho thiết bị để khơi
mã hóa/giải mã có thể giao tiếp trực tiếp được với hệ
thống cũng được đề xuất chi tiết. Xét về yếu tố tốc độ
kênh truyền, kết quả của bài báo đã cho thấy các quá
trình xử lý ngắt, khởi tạo sẽ làm giảm tốc độ trên thiết bị
PC và cả trên thiết bị Router (so với tốc độ truyền nhận
tối đa). Chi phí xử lý trên driver gây ra tác động rất lớn
đối với thực hiện truyền nhận dữ liệu. Và do vậy, các
nghiên cứu chuyên sâu hơn không thể bỏ qua phần thiết
kế driver giao tiếp giữa các khối trong cùng một hệ
thống.

𝑆ố 𝑔ó𝑖 𝑡𝑟𝑢𝑦ề𝑛 đượ𝑐 × 𝑠ố 𝑏𝑦𝑡𝑒 𝑚ỗ𝑖 𝑔ó𝑖 × 8
𝑇ℎờ𝑖 𝑔𝑖𝑎𝑛 𝑡𝑟𝑢𝑦ề𝑛

LỜI CẢM ƠN
Hình 9. Tốc độ truyền nhận theo gói XDMA IP PCIe 2.0
trên PC


Nghiên cứu này được tài trợ bởi Bộ Khoa học và
Công nghệ trong khuôn khổ đề tài mã số KC.01.24/1620. Chúng tôi xin cảm ơn Trường Đại học Bách Khoa,
ĐHQG-HCM đã hỗ trợ thời gian, phương tiện và cơ sở
vật chất cho nghiên cứu này.
TÀI LIỆU THAM KHẢO

Hình 10. Tốc độ truyền nhận theo gói XDMA IP PCIe 2.0 x1
trên Router

Hình 9 cho thấy kết quả khi ta dùng FPGA giao tiếp
với PC thông qua PCIe, ta tính được tốc độ tăng dần khi
dung lượng mỗi lần gửi tăng lên và tốc độ với PCIe 4 làn
(432 Mbps) cao hơn tốc độ 1 làn (260 Mbps). Điều này
là dễ hiểu vì khi tăng dung lượng mỗi lần truyền/gửi thì
sự ảnh hưởng do độ trễ của phần mềm trở nên ít hơn.
Mặc dù khi tăng cấu hình PCIe từ 1 làn lên 4 làn, tốc độ
về mặt lý thuyết sẽ phải tăng lên gấp 4, tuy nhiên trên
thực tế sự chênh lệch không lớn như vậy chỉ khoảng 1.6
lần. Từ đây có thể suy ra nguyên nhân làm giảm tốc độ
truyền gửi phần lớn là do sự ảnh hưởng của phần mềm
(phản ứng chậm).
Trong bài kiểm tra trên Router, do board Router
chúng tôi sử dụng với 3 làn PCIe dùng cho mô-đun Wifi

ISBN: 978-604-80-5076-4

[1]

Craig A. Shue, Minaxi Gupta, "IPsec: Performance Analysis
and Enhancement," IEEE International Conference on

Communications, 2007.

[2]

O. Morrison, "IPsec: Protocol Challenges and Performance
Analysis and Enhancements," 2014.

[3]

IETF, RFC 2401: Security Architecture for the Internet
Protocol.

[4]

R. Friend, "Making the gigabit IPsec VPN architecture secure,"
2004, p. Computer.

[5]

Alberto Ferrante, Vincenzo Piuri, and Jeff Owen, "IPsec
Hardware Resource Requirements," IEEE Conference Paper,
2005.

[6]

E. Barker, Q. Dang, S. Frankel, K. Scarfone and P. Wouters,
"Guide to IPsec VPNs," NIST Special Pubication, 2020.

[7]
[8]


IETF, "RFC 2409: , The Internet Key Exchange (IKE)".
IETF, "RFC 4106: The Use of Galois/Counter Mode (GCM) in
IPsec Encapsulating Security Payload (ESP)".

[9] I. Corp, "White paper: Intel IPsec Acceleration," 2019.
[10] N. M. Garcia, Mário M. F., Paulo P. M., “The Ethernet Frame
Payload Size and Its Effect on IPv4 and IPv6 Traffic”, 2008.

207