Tiểu luận mạng nâng cao PHÂN TÍCH TCP sử DỤNG GIAO THỨC ĐỊNH TUYẾN AODV TRÊN MẠNG MANET

TCP là giao thức điều khiển truyền dựa trên truyền tải đáng tin cậy đầu đến cuối. Đặc biệt thành phần mạng trở thành mạng không dây và mạng di động từ mạng có dây đã đề xuất nhiều thuật toán TCP được tối ưu hoá trong môi trường đa dạng. Tuy nhiên, khi TCP được tạo ra, nó được thiết kế dựa trên liên kết có dây, liên kết không dây gây ra lỗi đường truyền nhiều hơn liên kết có dây 1. Vấn đề của mạng tuỳ biến không dây là sự thay đổi đường đi, mờ dần, nhiễu, ngắt kết nối và thiết bị đầu cuối ẩn đi. Lỗi đường truyền trong mạng tuỳ biến không dây chưa chắc là do dấu hiệu tắc nghẽn không dây. Các thuật toán điều khiển tắc nghẽn của TCP đôi khi tỏ ra kém hiệu quả trong mạng không dây. Vì vậy người ta đưa vào mạng không dây một số giao thức định tuyến để khắc phục các vấn đề nói trên. Trong bài viết này, chúng tôi tìm hiểu và phân tích hoạt động của giao thức định tuyến AODV trên TCP.

Tiểu luận môn: Mạng và kỹ thuật truyền dữ liệu

Đề tài:

THỰC HIỆN PHÂN TÍCH TCP SỬ DỤNG GIAO THỨC ĐỊNH

TUYẾN AODV TRÊN MẠNG MANET

TÓM TẮT

TCP là giao thức điều khiển truyền dựa trên truyền tải đáng tin cậy đầu đến

cuối Đặc biệt thành phần mạng trở thành mạng không dây và mạng di động từ mạng có dây đã đề xuất nhiều thuật toán TCP được tối ưu hoá trong môi trường

đa dạng Tuy nhiên, khi TCP được tạo ra, nó được thiết kế dựa trên liên kết có dây, liên kết không dây gây ra lỗi đường truyền nhiều hơn liên kết có dây [1] Vấn đề của mạng tuỳ biến không dây là sự thay đổi đường đi, mờ dần, nhiễu, ngắt kết nối và thiết bị đầu cuối ẩn đi Lỗi đường truyền trong mạng tuỳ biến không dây chưa chắc là do dấu hiệu tắc nghẽn không dây Các thuật toán điều khiển tắc nghẽn của TCP đôi khi tỏ ra kém hiệu quả trong mạng không dây Vì vậy người ta đưa vào mạng không dây một số giao thức định tuyến để khắc phục các vấn đề nói trên Trong bài viết này, chúng tôi tìm hiểu và phân tích hoạt động của giao thức định tuyến AODV trên TCP

I GIỚI THIỆU

Gần đây, việc sử dụng mạng không dây là phổ biến Giao tiếp sử dụng bộ cảm biến nhỏ được gọi là công nghệ chính cho sự phát triển phổ biến các mạng cảm biến có môi trường mạng tuỳ biến mà các nút di động kết nối mạng và tự cấu hình với nhau Do đó, có nhiều nghiên cứu về môi trường của mạng cảm biến và mạng tuỳ biến được thực hiện Tuy nhiên, mạng tuỳ biến không dây đã mất định tuyến, mờ dần, ồn ào, nhiễu, cắt kết nối và vấn đề thiết bị đầu cuối bị

ẩn Nó cấu hình mô hình động từ các nút di chuyển, sự mất mát gói tin do lỗi đường truyền thì thường xuyên hơn Nguyên nhân của lỗi đường truyền trong

mạng tuỳ biến không dây thường không phải do dấu hiệu của tắc nghẽn mạng [2]

[3]

Tình huống này gây ra sự xuống cấp về hiêu suất TCP[4] Trong bài viết này, chúng tôi tìm hiểu thuật toán điều khiển tắc nghẽn của TCP và vấn đề về cơ chế trong mạng tuỳ biến không dây và sau đó, chúng tôi nghiên cứu hoạt động của giao thức định tuyến AODV trên nền TCP trong mạng tùy biến không dây

II THUẬT TOÁN TẮC NGHẼN TCP

TCP sử dụng thuật toán điều khiển luồng và kiểm soát tắc nghẽn, xử lý lưu lượng truy cập dữ liệu trong mạng Thuật toán điều khiển tắc nghẽn TCP gồm có bắt đầu chậm, tránh tắc nghẽn, truyền lại nhanh và phục hồi nhanh

II.1 TCP Tahoe

Hình 1: Điều khiển tắc nghẽn của TCP-Tahoe

Khi hết thời gian chờ hoặc xảy ra sự mất mát gói tin, biến ngưỡng(ssthresh) được thiết lập để được một nữa kích thước cửa sổ hiện tại Sau đó, cwnd thiết lập lại bằng 1 Khi nơi gửi nhận được tín hiệu ACK, Cwnd tăng lên từ 1 cho đến khi đạt đến ngưỡng Giai đoạn này được gọi là giai đoạn phục hồi tắc nghẽn Kích thước cửa sổ tăng lên theo cấp số nhân trong suốt giai đoạn phục hồi tắc nghẽn

và sau đó kích thước cửa sổ được tăng lên theo tuyến tính trong suốt giai đoạn tránh tắc nghẽn

II.2 TCP Reno

TCP Reno thực hiện tốt hơn so với TCP Tahoe TCP Reno có 2 giai đoạn là giai đoạn tránh tắc nghẽn và giai đoạn bắt đầu chậm nếu hết thời gian chờ ACK

và bắt đầu chậm được sử dụng như TCP Tahoe Mặt khác, khi bên gửi nhận được 3 bản sao ACK, kích thước cửa sổ tắc nghẽn được thiết lập bằng một nữa của Cwnd và bắt đầu giai đoạn tránh tắc nghẽn Sự phục hồi của TCP Reno trong cửa sổ tắc nghẽn được tối ưu hoá TCP Reno đã làm mất nhiều gói tin trong cửa

sổ tắc nghẽn gây nên hiệu suất kém Bởi vì gói tin TCP Reno có thể chỉ truyền lại một gói tin cho mỗi một RTT(round trip time)

II.3 TCP new Reno

TCP new Reno là một phiên bản cải tiến của Reno nhằm tránh sự suy giảm của Cwnd khi một vài phân đoạn từ cùng một cửa sổ của dữ liệu bị mất[5] Giống như TCP Reno, TCP new Reno cũng tham gia vào việc truyền lại nhanh

khi nhận được các gói tin trùng lặp Tuy nhiên nó khác với TCP Reno ở chổ nó không thoát khỏi việc phục hồi nhanh cho tới khi tất cả các tài liệu được ghi nhận và phục hồi nhanh Vì vậy nó khắc phục những vấn đề phải đối mặt với TCP Reno là giảm Cwnd mạnh

Giai đoạn truyền tải nhanh thì giống như TCP Reno Sự khác biệt trong giai đoạn phục hồi nhanh cho phép truyền lại trong TCP Reno, bất cứ khi nào TCP Reno đi vào việc phục hồi nhanh thì lưu ý đoạn lớn nhất là chưa thực hiện xong TCP new Reno thực tế cho phép là 1 RTT để phát hiện ra những gói tin bị mất Khi tín hiệu trả về cho đoạn truyền lại đầu tiện nhận được, sau đó ta có thể suy ra những đoạn khác đã bị mất

II.4 TCP Vegas

TCP Vegas có thể dự đoán các điều kiện sử dụng băng thông mạng Sự công bằng và hiệu quả của nó thì tốt hơn so với giải thuật TCP khác [6] Sự khác biệt giữa thông lượng trông đợi (expected throughput) với thông lượng thực tế (actual throughput) Thuật toán TCP Vegas có thể ước lượng được bang thông mạng có sẵn Nếu actual throughput và expect throughput quá gần thì giá trị của delta là tương đối ít Ta có thể xem xét việc ùn tắc không xảy ra trên mạng Nếu actual throughput rất nhỏ so với expected throughput , giá trị của delta là tương đối lớn, do vậy, mạng có thể tắc nghẽn Tuy nhiên, TCP Vegas phụ thuộc vào tỷ

lệ trông đợi trong việc tính toán băng thông

III TCP TRONG MẠNG TUỲ BIẾN KHÔNG DÂY.

Trong mạng tuỳ biến không dây, sự thay đổi thường xuyên của mô hình mạng tuỳ biến có thể làm cho TCP đầu đến cuối kiểm soát trở nên khó khăn Mạng tuỳ biến không dây có tỷ lệ lỗi bít cao do các vấn đề như mất định tuyến,

sự mờ dần, tiếng ồn, nhiễu, ngắt kết nối và vấn đề thiết bị đầu cuối ẩn Mạng tuỳ biến không dây cấu hình theo cấu trúc động bỡi các nút có thể di động được Tỷ

lệ lỗi bít cao của kênh không dây có nhiều loại khác nhau Các liên kết và các tuyến đường bất đối xứng ảnh hưởng tới hiệu suất TCP Trong 1 kết nối TCP, lien kết và tuyến đường thường xuyên thay đổi, quá trình định tuyến lại mất quá nhiều thời gian, thời gian này có thể vượt quá giá trị thời gian chờ TCP, kết quả làm giảm cửa sổ tắc nghẽn và hiệu suất TCP Vì vậy thuật toán điều khiển tắc đạt hiệu suất kém

Từ nguồn tới đích, các tuyến đường thường xuyên thay đổi do mỗi nút di chuyển trong môi trường không dây Giao thức định tuyến tuỳ biến không dây sử

dụng giao thức định tuyến theo yêu cầu Từ nguồn đến đích, tuyến đường có nhiều con đường, gói tin có thể đi qua nhiều con đường khác nhau để tới đích, nếu các thuộc tính không được xử lý, các gói tin được sắp xếp có thể kích hoạt truyền lại giả mạo và gây nhầm lẫn trong điều khiển tắc nghẽn TCP Việc nhận được gói có trật tự, người gửi có thể nhận được 3 bản sao ACK, rồi có thể gây ra hiệu suất kém sau khi thực hiện cơ chế kiểm soát tắc nghẽn

IV HOẠT ĐỘNG CỦA GIAO THỨC AODV( Adhoc On – Deman Distant Vector)

AODV (Ad Hoc On-Demand Distance Vector) là giao thức dựa trên thuật toán vector khoảng cách AODV tối thiểu hoá số bản tin quảng bá cần thiết bằng cách tạo ra các tuyến trên cơ sở theo yêu cầu Quá trình định tuyến của giao thức AODV có thể mô tả bằng sơ đồ sau:

Khi một nút nguồn muốn gởi một bản tin đến một nút đích nào đó và không biết rằng đã có một tuyến đúng đến đích đó, nó phải khởi đầu một quá trình khám phá đường truyền Nó phát quảng bá một gói yêu cầu tuyến (RREQ) đến các nút lân cận Các nút lân cận này sau đó sẽ chuyển tiếp gói yêu cầu đến nút

lân cận khác của chúng Quá trình cứ tiếp tục như vậy cho đến khi có một nút trung gian nào đó xác định được một tuyến “đủ tươi” để đạt đến đích AODV sử dụng số thứ tự đích để đảm bảo rằng tất cả các tuyến không lặp và chứa hầu hết thông tin tuyến hiện tại Mỗi nút duy trì số tuần tự của nó cùng với một ID quảng

bá ID quảng bá được tăng lên mỗi khi nút khởi đầu một RREQ, và cùng với địa chỉ IP của nút, xác định duy nhất một RREQ Cùng với số tuần tự và ID quảng

bá, nút nguồn bao gồm trong RREQ hầu hết số tuần tự hiện tại của đích mà nó

có Các nút trung gian có thể trả lời RREQ chỉ khi nào chúng có một tuyến đến đích mà số tuần tự đích tương ứng lớn hơn hoặc bằng số tuần tự chứa trong RREQ

Trong suốt quá trình chuyển tiếp RREQ, các nút trung gian ghi vào Bảng định tuyến của chúng địa chỉ của các nút lân cận từ khi nhận được bản sao đầu tiên của gói quảng bá, theo đó thiết lập được một đường dẫn theo thời gian Nếu các bản sao của cùng một RREQ được nhận sau đó, các gói này sẽ bị huỷ bỏ Một khi RREQ đã đạt đến đích hay một nút trung gian với tuyến “đủ tươi”, nút đích (hoặc nút trung gian) đáp ứng lại bằng cách phát đơn phương một gói đáp ứng tuyến (RREP) ngược về nút lân cận mà từ đó nó thu được RREQ Khi RREP được định tuyến ngược theo đường dẫn, các nút trên đường dẫn đó thiết lập các thực thể tuyến chuyển tiếp trong Bảng định tuyến của chỉ nút mà nó nhận được RREP Các thực thể tuyến chuyển tiếp này chỉ thị tuyến chuyển tiếp tích cực Cùng với mỗi thực thể tuyến là một bộ định thời tuyến có nhiệm vụ xoá các thực thể nếu nó không được sử dụng trong một thời hạn xác định Do một RREP chuyển tiếp trên đường dẫn được thiết lập bởi một RREQ nên AODV chỉ hỗ trợ việc sử dụng đường truyền đối xứng

Trong AODV, các tuyến đươc duy trì điều kiện như sau: Nếu một nút nguồn chuyển động, nó phải khởi động lại giao thức khám phá tuyến để tìm ra một tuyến mới đến đích Nếu một nút trên tuyến chuyển động, nút lân cận luồng lên của nó chú ý đến chuyển động đó và truyền một bản tin “Khai báo sự cố đường thông” (một RREP không xác định) đến mỗi nút lân cận tích cực luồng lên để thông báo cho các nút này xoá phần tuyến đó Các nút này thực chất truyền một “Thông báo sự cố đường thông” đến các nút lân cận luồng lên Quá trình cứ tiếp tục như vậy cho đến khi đạt đến nút nguồn Nút nguồn sau đó có thể

chọn khởi động lại một quá trình khám phá tuyến cho đích đó nếu một tuyến vẫn cần thiết [4]

Ngoài ra, giao thức này sử dụng bản tin HELLO được phát quảng bá định

kỳ bởi một nút để thông báo cho tất cả các nút khác về những nút lân cận của nó Các bản tin HELLO có thể được sử dụng để duy trì khả năng kết nối cục bộ của một nút Tuy nhiên, việc sử dụng bản tin HELLO là không cần thiết Các nút lắng nghe việc truyền lại gói dữ liệu để đảm bảo rằng vẫn đạt đến chặng kế tiếp Nếu không nghe được việc truyền lại như thế, nút có thể sử dụng một trong số các kỹ thuật, kể cả việc tiếp nhận bản tin HELLO Các bản tin HELLO có thể liệt kê các nút khác mà từ đó nút di động đã nghe tin báo, do đó tạo ra khả năng liên kết lớn hơn cho mạng

V THỰC HIỆN PHÂN TÍCH TCP SỬ DỤNG GIAO THỨC ĐỊNH

TUYẾN AODV

Hình 2 Mô hình mô phỏng

Để đánh giá hiệu suất của mỗi thuật toán TCP, chúng tôi thực hiện một mô phỏng NS2 trên mô hình mạng đơn giản Như thể hiện trong hình 2, nút 1 là nguồn, nút 5 là nút đích Ngoài ra có nhiều nút di động như là bộ định tuyến giữa nút 1 và nút 5 Lưu lượng dữ liệu thí nghiệm là phiên FTP trên TCP Kích thước gói tin TCP là 1040 byte và TCP ACK là 60 byte Các lớp liên kết sử dụng IEEE 802.11 giao thức MAC [8] và băng thông là 10Mbps Thời gian trì hoãn đường truyền là 10ms, sử dụng giao thức định tuyến AODV

Như thể hiện trong hình 2, bắt đầu thời gian mô phỏng là 10 giây và sau đó nút 3 rời khỏi phạm vi giữa nút 2 và nút 4 sau 70 giây Khi mô phỏng 120 giây, tuyến đường sẽ được thiết lập lại bỡi vì nút 3 được đặt giữa nút 4 và nút 5, thời gian kết thúc mô phỏng là 150 giây

Khi lớp vận chuyển chọn TCP Tahoe, TCP Reno, TCP new Reno và TCP vegas trong mạng tuỳ biến không dây Hình 3 cho thấy số thứ tự của gói tin ACK

Trong hình 2, kích thước cấu trúc liên kết thiết lập 800m Mô phỏng so sánh hiệu suất của mỗi thuật toán TCP

Mạng tuỳ biến không dây không có tuyến đường cố định và cấu hình cấu trúc liên kết động do các nút di động Như thể hiện trong hình 2(b), số thứ tự của mỗi TCP là không tăng sau 70 giây bỡi vì con đường bị cắt do nút 3 di chuyển Con đường định tuyến lại sau 120 giây Nhưng TCP Tahoe có số thứ tự không tăng cho đến khi ACK được đến bỡi gói chuyển tiếp, TCP Tahoe không gửi các gói tin khác nên số thứ tự không được tăng lên TCP new Reno cho biết con số thấp hơn hoàn toàn so với thuật toán TCP khác TCP new Reno hứng chịu thực

tế là 1 RTT khi nó phát hiện ra gói tin bị mất Kết quả là TCP new Reno tạo ra hiệu suất kém Nhưng TCP Reno có hiệu suất tốt nhất so với thuật toán TCP khác Mặc dù lỗi đường truyền gây ra mất mát nhiều gói tin trong mạng tuỳ biến không dây, khi bên gửi nhận được 3 bản sao ACK kích thước cửa sổ được thiết

lập là một nữa của Cwnd và bắt đầu giai đoạn tránh tắc nghẽn Có thể cho TCP Reno thực hiện thông lượng cao trong mạng tuỳ biến không dây

Từ hình 4(a) đến 4(d) cho thấy kích thước cửa sổ của mỗi TCP Ở hình 4(d), kích thước cửa sổ tắc nghẽn của TCP Vegas có thay đổi nhỏ bỡi vì kích thước cửa sổ tăng hoặc giảm nhiều như một đoạn theo tỷ lệ trông đợi, cái mà gửi đi sự tính toán của đoạn

Thể hiện trong hình 4(a) đến 4(c), đường dẫn bị cắt do nút di chuyển sau 70 giây, TCP thiết lập để được một nữa của kích thước cửa sổ tắc nghẽn và kích thước cửa sổ tắc nghẽn thiết lập lại một, sau đó bắt đầu khởi động chậm Mô phỏng về thuật toán TCP là tương tự như cơ chế kiểm soát tắc nghẽn TCP Khi con đường bị cắt là 70 giây, kích thước cửa sổ tắc nghẽn của mỗi thuật toán TCP thiết lập một nữa của Cwnd Sau khi con đường định tuyến là 120 giây, kích thước cửa sổ tắc nghẽn tăng theo cấp số nhân, nó bắt đầu khởi động chậm TCP công nhận tình huống tắc nghẽn mạng để định tuyến lại bỡi nút di động Tóm lại,

nó được coi là kết quả của tình huống là thực hiện thuật toán điều khiển tắc nghẽn khi kích thước của nó trở thành một Cuối cùng thuật toán TCP kích hoạt thuật toán điều khiển tắc nghẽn không cần thiết gây ra hiệu suất kém

Hình 5:Thông lượng của TCP Tahoe và TCP new Reno

Hình 5 cho thấy thông lượng của TCP Tahoe và TCP new Reno Như hình 3

và 4, thuật toán TCP Tahoe và TCP new Reno thực hiện kém hơn so với thuật toán TCP khác TCP Tahoe tăng việc truyền lại do nhiều gói tin bị mất bỡi nút di động Khi TCP Tahoe thực hiện việc truyền lại thì nó không có hiệu quả cho bộ đếm thời gian truyền dẫn không được sử dụng Mặc dù TCP new Reno trở nên khó khăn trong một kết nối TCP, tuyến đường và sự lien kết thường xuyên thay đổi, quá trình định tuyến lại thường mất nhiều thời gian, thời gian này có thể vượt quá giá trị của thời gian chờ TCP, kết quả là phải giảm cửa sổ tắc nghẽn, tỷ

lệ lỗi bít cao…tiến hành hồi phục ở cuối thời gian mô phỏng nhưng nói chung nó vẫn có hiệu suất kém Từ khi TCP new Reno xảy ra nhiều tổn thất gói tin, nó

cũng có nhiều RTT Có thể TCP new Reno không chính xác trong mạng tuỳ biến không dây, nơi mà sự bùng nổ về tổn thất gói tin thường xuyên xảy ra

Hình 6: Thông lượng của TCP Reno và TCP Vegas

Hình 6 cho thấy thông lượng của TCP Reno và TCP Vegas TCP Reno và TCP Vegas thực hiện tốt hơn so với TCP Tahoe và TCP new Reno Đặc biệt TCP Reno đã tăng tương đối tại thời điểm bắt đầu Tuy nhiên TCP Reno tạo ra hiệu suất không tốt như TCP Vegas do gói tin bị tổn thất thường xuyên Tuy nhiên, TCP Reno thực hiện thông lượng tốt hơn TCP khác sau 120 phút Thuật toán TCP Vegas dự đoán trước về tốc độ truyền Bỡi vì TCP Vegas không thể dự đoán chính xác sự tắc nghẽn của mạng trong mạng tuỳ biến không dây, nơi mà

sự bùng nổ về tổn thất gói tin thường xuyên xảy ra Thông lượng TCP Vegas

tương đối thấp hơn TCP Reno