Giao thức điều khiển chống tắc nghẽn XCP

Trong đồ án này em xin trình bày một trong các ý kiến đề xuất được đánh giá là hợp lý nhất có thể thay thế cho giao thức TCP trong tương lai, giao thức XCP và mô phỏng sự hoạt động của n

Mục lục

THUẬT NGỮ VIẾT TẮT… ……….…4

MỞ ĐẦU… ………5

CHƯƠNG I: GIAO THỨC TCP, HOẠT ĐỘNG VÀ CƠ CHẾ KIỂM SOÁT LỖI …6

1.1 Giới thiệu về giao thức TCP………….……… 6

1.2 Nguyên tắc hoạt động và cơ chế kiểm soát tắc nghẽn……… 6

1.2.1 Cấu trúc và nguyên tắc hoạt động của TCP/IP………… ………… 6

1.2.2 Cơ chế kiểm soát tắc nghẽn……… ……….……….8

CHƯƠNG II: GIAO THỨC XCP………… ……… ….10

2.1 Sự ra đời của giao thức XCP….……… 10

2.2 Cấu trúc của giao thức XCP……… ……… 10

2.2.1 Tổng quan về giao thức XCP……… ……… 10

2.2.2 Lớp giao thức XCP………… ……….11

2.3 Nguyên tắc hoạt động và cơ chế kiểm soát lỗi…….……… 14

2.3.1 Quá trình gửi các packet ……… 14

2.3.2 Xử lý thông tin phản hồi tại người nhận ……… 15

2.3.3 Xử lý thông tin tại router………… ……… 15

2.3.4 Xử lý thông tin phản hồi tại người gửi……… ……… 19

CHƯƠNG III: PHẦN MỀM MÔ PHỎNG MẠNG NSf2.……… … 20

3.1 Giới thiệu về phần mềm mô phỏng mạng NS2… … ……… 20

3.2 Cấu trúc và nguyên tắc hoạt động của NS2 và NAM… ……… ……….20

3.2.1 Cấu trúc của NSf2……….20

3.2.2 Các đặc tính của NSf2……… 25

3.2.3 Ví dụ về một mạng cơ bản của NSf2………26

3.2.4 Khởi tạo node……… 32

3.2.5 Khởi tạo link.……….33

3.2.6 Khởi tạo Network Agents……….34

3.2.7 Các loại traffic.……… 35

3.2.8 Các dịch vụ cơ bản trong Internet……… …… 37

3.2.9 Tracing……… 38

3.2.10 Routing……… ……… 40

CHƯƠNG IV: HOẠT ĐỘNG CỦA XCP TRONG NSf2 VÀ KẾT QUẢ SO SÁNH GIỮA XCP VÀ TCP TRONG NSf2 42

4.1 Hoạt động của XCP trong NSf2……….… 42

4.1.1 Các điểm kết thúc trên XCP……… ………42

4.1.2 XCP router……… 43

4.1.3 Hàng đợi XCP……… 44

4.1.4 Các câu lệnh ví dụ XCP………44

4.2 Quá trình mô phỏng TCP và XCP trong NSf2 và kết quả so sánh giữa chúng……….48

4.2.1 Giới thiệu mô hình mô phỏng đơn giản………49

4.2.2 Kết quả với hai mô hình mô phỏng TCP và TCP……….50

CHƯƠNG V: PHIÊN BẢN NÂNG CAO CỦA XCP TRONG MẠNG HỖN TẠP: XCPfI.……… 55

5.1 Nâng cao XCP cho liên mạng hổn tạp ……… 55

5.1.1 Cấu trúc và thuật toán của XCPfi trong các router ……… 55

5.1.2 XCPfi, cấu trúc trong endfhosts……… 57

5.2 Kết quả mô phỏng XCPfi trên nsf2 ……… 57

5.2.1 Triển khai phát triển xung quanh các nonfXCP cloud……… 58

5.2.2 Kịch bản phân nhánh: 1 nonfXCP cloud phục vụ n đường XCP……… 58

5.2.3 Sự không ổn định của ước lượng băng thông……… 59

5.3 Một số phương pháp điều khiển chống tắc nghẽn mới ……….60

5.3.1 Phương pháp EWA và FEWA……… 60

5.3.2 Phương pháp ETCP……… 61

5.3.3 Phương pháp FBAfTCP……….……… 61

5.3.4 Phương pháp QSfTCP….……… 62

KẾT LUẬN… ……… 64

TÀI LIỆU THAM KHẢO……… 65

THUẬT NGỮ VIẾT TẮT

AIMD Additive Increase Multiplicative Thuật toán tăng cộng

Decrease giảm nhân

CBR Constant Bit Rate Tốc độ bít cố định

CWND Congestion Windows Kích thước cửa sổ chống tắc nghẽn

EC Efficiency Controller Điều khiển hiệu lực

FC Fairness Controller Điều khiển công bằng

FTP File Transfer Protocol Giao thức truyền tập

tin

NS Network Simulator Mô phỏng mạng

TCP Tranmission Control Protocol Giao thức điều khiển

truyền tải XCP Explicit Congestion Control Protocol Giao thức điều khiển

chống tắc nghẽn XCP UDP User Datagram Protocol Giao thức gói người

dùng

MỞ ĐẦU

Trên thế giới internet, giao thức TCP đầu tiên được định nghĩa trong RFC 793 là một giao thức quan trọng nhất đáp ứng cho nhiệm vụ đảm bảo độ tin cậy và phân chia hợp lý của băng thông tới người sử dụng cuối cùng (endfuser) TCP đã ra đời cách đây

25 năm và nó được thiết kế để làm việc trong các mạng cùng với các sản phẩm có độ trể băng thông mức thấp so với hiện nay Trong hoạt động nó sử dụng packet bị bỏ rơi cho điều khiển truyền tốc độ và sử dụng một thuật toán AIMD (thuật toán tăng cộng/giảm nhân) để điều chỉnh tốc độ gửi

Với sự phát triển của nhu cầu thông tin mạng ngay nay, nhu cầu của các dịch vụ mạng ngày càng đa dạng phong phú và đòi hỏi nhiều mức độ chất lượng dịch vụ khác nhau Xu hướng phát triển là hội tụ về mạng và hội tụ về dịch vụ Thực tế cho thấy hệ thống mạng ngày càng lớn và đa dạng mà điển hình như mạng không dây wireless links, mạng vệ tinh… TCP trở nên bất lực và thực thi một cách kém hiệu quả trong việc điều khiển chống tắc nghẽn và khôi phục dữ liệu Trước tình hình này cộng đồng

hệ thống mạng có nhiều đề xuất phát triển và nhiều ý kiến độc đáo mục đích làm cho TCP có hiệu lực hơn trong điều kiện một hệ thống mạng hiện nay và tương lai

Trong đồ án này em xin trình bày một trong các ý kiến đề xuất được đánh giá là hợp lý nhất có thể thay thế cho giao thức TCP trong tương lai, giao thức XCP và mô phỏng sự hoạt động của nó thông qua phần mềm mô phỏng mạng NS2 và so sánh giữa XCP và TCP trong cùng một mô hình mạng đơn giản

Đồ án gồm có các nội dung sau:

Chương I: Sơ lược về giao thức TCP, hoạt động và cơ chế xử lý lỗi

Chương II: Giao thức XCP

Chương III: Mô phỏng mạng NS2

Chương VI: Hoạt động của XCP trong NS2 và kết quả so sánh giữa XCP và TCP trong NS2

Chương V: Phiên bản nâng cao của XCP trong mạng hỗn tạp

CHƯƠNG I: GIAO THỨC TCP, HOẠT ĐỘNG VÀ CƠ CHẾ KIỂM SOÁT LỖI

1.1 Giới thiệu về giao thức TCP

Vào cuối những năm 1960 đầu 1970, trung tâm nghiên cứu cấp cao ARPA thuộc bộ quốc phòng Mỹ (DoD) được giao trách nhiệm phát triển mạng ARPANET Mạng ARPANET bao gồm mạng của các tổ chức quân đội, các trường đại học, và các

tổ chức nghiên cứu được để hổ trợ cho các dự án nghiên cứu khoa học và quân đội (ngày nay đổi tên thành DARPA) Năm 1984 DoD chia ARPAPNET thành 2 phần: ARPANET phục vụ cho nghiên cứu khoa học, MILNET sử dụng cho quân đội Đầu những năm 1980, bộ giao thức mới được đưa ra làm giao thức chuẩn cho mạng ARPANET và các mạng của DoD mang tên DARPA internet protocol suit, thường được gọi là bộ giao thức TCP/IP hay còn gọi tắt là TCP/IP

TCP/IP có một số ưu điểm sau:

f Giao thức chuẩn mở sẵn sàng phát triển độc lập với phần cứng và hệ điều hành TCP/IP là giao thức lý tưởng cho việc hợp nhất phần cứng và phần mềm khác nhau ngay cả khi truyền thông trên internet Sự độc lập rành mạch với phần cứng vật lý của mạng cho phép TCP/IP hợp nhất các mạng khác nhau TCP có thể chạy trên mạng Ethernet, mạng Tokenring, mạng quay số mạng X.25, mạng ảo và mọi loại môi trường vật lý truyền thông

f Một sơ đồ địa chỉ dùng chung cho phép mỗi thiết bị TCP/IP duy nhất có một địa chỉ trên mạng ngay cả khi đó là mạng toàn cầu Internet

f Tiêu chuẩn hoá mức cao của giao thức phù hợp với ích lợi của dịch vụ người dùng Được tích hợp vào hệ điều hành UNIX, hổ trợ mô hình client – server, mô hình mạng bình đẳng, hỗ trợ kỹ thuật dẫn đường rộng

1.2 Nguyên tắc hoạt động và cơ chế kiểm soát tắc nghẽn

1.2.1 Cấu trúc và nguyên tắc hoạt động của TCP/IP

Bộ giao thức TCP/IP được phân thành 4 tầng

f Tầng mạng (Network Layer)

f Tầng Internet (Internet Layer)

f Tầng giao vận (Transport Layer)

f Tầng ứng dụng (Application Layer)

Đầu tiên, dữ liệu được xử lý bởi tầng application Tầng này có nhiệm vụ tổ chức

dữ liệu theo khuôn dạng và trật tự nhất định để tầng application ở máy khác có thể hiểu được Tầng application gửi dữ liệu xuống tầng dưới theo dòng byte nối byte Cùng với

dữ liệu, tầng application cũng gửi xuống các thông tin điều khiển khác giúp xác định địa chỉ đến, đi của dữ liệu

Khi xuống tới tầng TCP, dòng dữ liệu sẽ được đóng thành các packet có kích thước không nhất thiết bằng nhau nhưng phải nhỏ hơn 64 KB Cấu trúc của packet dữ liệu TCP gồm một phần header chứa thông tin điều khiển và sau đó là dữ liệu Sau khi đóng gói xong ở tầng TCP, dữ liệu được chuyển xuống cho tầng IP

Packet dữ liệu xuống tới tầng IP sẽ tiếp tục bị đóng gói lại thành các packet dữ liệu IP nhỏ hơn sao cho có kích thước phù hợp với mạng chuyển mạch gói mà nó dùng

để truyền dữ liệu Trong khi đóng gói, IP cũng chèn thêm phần header của nó vào packet dữ liệu rồi chuyển xuống cho tầng Datalink/Physical

Khi các packet dữ liệu IP tới tầng Datalink sẽ được gắn thêm một header khác

và chuyển tới tầng physical đi vào mạng Packet dữ liệu lúc này gọi là frame Kích thước của một frame hoàn toàn phụ thuộc vào mạng đang kết nối

Trong quá trình truyền đi trên internet, frame được các router chỉ dẫn để có thể tới đúng đích cần tới.Router thực ra là một module chỉ có hai tầng là Network và Datalink/Physical Các frame tới router sẽ được tầng Datalink/Physical lọc bỏ header

mà tầng này thêm vào và chuyển lên tầng Network (IP) Tầng IP dựa vào các thông tin điều khiển trong header mà nó thêm vào để quyết định đường đi tiếp theo cho packet

IP Sau đó packet IP này lại được chuyển xuống tầng Datalink/Physical để đi vào mạng Quá trình cứ thế tiếp tục cho đến khi dữ liệu tới đích là một máy khác trong mạng

Khi tới máy nhận, các packet được xử lý theo quy trình ngược lại với máy gửi Đầu tiên dữ liệu qua tầng datalink/physical Tại đây frame bị bỏ đi phần header và chuyển lên tầng IP Tại tầng IP, dữ liệu được bung packet IP, sau đó lên tầng TCP và cuối cùng lên tầng application để hiển thị ra màn hình

1.2.2 Cơ chế kiểm soát tắc nghẽn

TCP là giao thức phổ biến nhất hiện nay cho truyền dữ liệu tin cậy trên Internet Ngoài điều khiển chống tắc nghẽn ra nó còn thực hiện các chức năng khôi phục dữ liệu

đã mất và quản lý kết nối Điều khiển chống tắc nghẽn trong TCP thuộc loại điều khiển vòng kín phản hồi ẩn

Quản lý chống tắc nghẽn TCP dựa trên thuật toán tăng cộng giảm nhân (AIMD) Nếu xãy ra tắc nghẽn, kích thước cửa sổ giảm đi một nửa (nhân với 0.5) và ngược lại thì tăng lên một giá trị là MSS (Maximum Segment Size)

Điều khiển chống tắc nghẽn trong TCP được thực hiện như sau: khởi tạo cập nhật ngưỡng tắc nghẽn (CT) và tùy thuộc vào cửa sổ chống tắc nghẽn Wc lớn hơn hay nhỏ hơn CT lưu lượng TCP được điều khiển theo hai pha như sau:

Pha 1: Pha bắt đầu chậm (Wc < CT):

Khi một đoạn được báo là đã nhận được, Wc được tăng lên một giá trị MSS

Các packet được truyền vào kênh

Pha 2: Pha chống tắc nghẽn (Wc > CT):

Đường truyền xãy ra tắc nghẽn Giảm Wc xuống còn một nửa Cập nhật lại CT

Application Transport Internet Network Interface

Identical Packet Identical Message

Physical Net

Host B Host A

Điều khiển chống tắc nghẽn trong TCP có những nhược điểm cơ bản là:

f Thông tin phản hồi là ẩn vì vậy cửa sổ gửi luôn giảm đi một nửa khi xãy ra tắc nghẽn là không thực sự hiệu quả

f TCP không chia sẽ thông tin điều khiển, vì vậy các kết nối cùng một thời điểm đến cùng một đích (một trường hợp thường xãy ra với lưu lượng web) sẽ phải cạnh tranh, thay vì phối hợp để sử dụng băng thông mạng một cách hợp lý

Điều khiển chống tắc nghẽn của TCP không đáp ứng được đầy đủ các tiêu chí

đã nêu, cụ thể là:

f Đối với mạng NGN, đặc biệt là trong môi trường nhiều lỗi như môi trường vô tuyến, vệ tinh… thuật toán điều khiển chống tắc nghẽn của TCP không hiệu quả Thậm chí thông lượng không thể chấp nhận được

f Đối với mạng đa dịch vụ, thuật toán điều khiển chống tắc nghẽn của TCP không đem lại tính bình đẳng cần thiết cho các ứng dụng

f Đối với mạng có lưu lượng biến đổi động, biến đổi nhanh, điều khiển chống tắc nghẽn của TCP tỏ ra bất ổn định và không hội tụ

CHƯƠNG II: GIAO THỨC XCP

2.1 Sự ra đời của giao thức XCP

XCP(eXplicit Control Protocol) là một giao thức điều khiển chống tắc nghẽn Internet mới được thiết kế bởi Katabi, Handley và Rohrs từ MIT, và được công bố như một RFC phác thảo vào ngày 17/10/2004 Sự ra đời của XCP được đánh giá là một sự tiến bộ quan trọng trong điều khiển chống tắc nghẽn trên Internet XCP trình bày sự thực thi ứng dụng mạng có thể thực hiện tốt trên phạm vi rộng lớn của hệ thống mạng

Nó thu hút sự chú ý khám phá của cộng đồng bởi khả năng mà nó đạt được trong ứng dụng mạng tốc độ cao và đổ trể cao trong khi duy trì vị trí hàng đợi trong các router Trong hoạt động XCP tận dụng được tối đa giá trị cực đại của đường link và không sử dụng băng thông cho packet bị thất lạc Đặc biệt là trong giao thức XCP có sự tách biệt giữa cách giải quyết hiệu suất và công bằng trong điều khiển chống tắc nghẽn và cho phép các router đặt dung lượng hiệu lực để giải quyết công việc một cách nhanh chóng 2.2 Cấu trúc của giao thức XCP

Hình phía dưới cung cấp các thực thể tham gia trong XCP Người gửi khởi tạo header chống tắc nghẽn, các router trên đường có thể cập nhật chúng và người nhận sẽ sao chép thông tin phản hồi từ mạng vào trong một packet trở lại của dòng phản hồi

2.2.2 Lớp giao thức XCP

2.2.2.1 Sự sắp xếp trong header

f Header tắc nghẽn đặt giữa IP và giữa các header vận chuyển (TCP hoăc UDP)

Có sự sắp xếp này bởi vì XCP không truyền thông tin theo kiểu hopfbyfhop hay kiểu endftofend trong TCP hay UDP mà sử dụng kiểu endfsystemftofnetwork

f XCP đưa vào một header 20 byte giữa IP và TCP mang thông tin về băng thông đề nghị của người giửi và thông tin về các cho phép của các router

f XCP đòi hỏi tất cả các router và máy chủ trên mạng sử dụng giao thức XCP để làm việc giống như dự định trên

f Giao thức XCP cơ sở cho tất cả chỉnh sửa của băng thông trên mỗi tính toán packet Các XCP router không cần tách rời giữa các dòng dữ liệu khác nhau Nhưng phải điều chỉnh trên mỗi packet riêng lẽ XCP sử dụng một ký hiệu giao thức thiết kế bởi IANA, các IP packet chứa đựng các XCP header sử dụng ký hiệu này trong một trường của IP header để báo hiệu cho các router và endfsystems biết được một header chống tắc nghẽn XCP tiếp tới của ID header

f Standard format: biểu thị throughput, delta_throughput, và các trường RTT được sử dụng, để cho điều khiển chống tắc nghẽn XCP của các packet mang header chống tắc nghẽn standard format

f Minimal format: throughput, delta_throughput, và các trường RTT không được

sử dụng và được thiết lập giá trị bằng 0 Các router thấy một packet sử dụng minimal format phải xử lý các packet này giống như các nonfXCP packet, một router sẽ không thực thi xử lý XCP nào trên các packet này Minimal format cho phép một người nhận gửi trở lại thông tin phản hồi tới người gửi mà không cần sự điều khiển chống tắc nghẽn các packet đang mang header chống tắc nghẽn TCP chấp nhận sử dụng minimal format việc dùng minimal format được dùng một cách cân nhắc Trường format sẽ được thiết lập 0x2 biểu thị sử dụng minimal format

Giá trị format được thiết kế bởi IANA

Bảng tổng kết các giá trị của trường format:

Protocol (giao thức) : 8 bit

Trường này biểu thị mức giao thức kế tiếp được sử dụng trong phần dữ liệu của packet Giá trị cho các giao thức khác nhau được định nghĩa bởi IANA

Length (độ dài): 8 bit

Trường này biểu thị độ dài của header chống tắc nghẽn đơn vị bằng byte

Unused (chưa sử dụng): 8 bit

Trường này không được sử dụng và phải thiết lập giá trị bằng 0 trong phiên bản của XCP

RTT (vòng lặp thời gian): 32 bit

Trường này biểu thị vòng lặp thời gian đo bởi người gửi, đơn vị milliseconds, trường này là một số nguyên không dấu Giá trị nhỏ nhất gửi nhanh trong trường này là

1 ms (giá trị sẽ được làm tròn lên), giá trị lớn nhất gửi nhanh trong trường này là 4.3E9

ms hay khoảng chừng 49 ngày Giá trị của nó bằng 0 cho biết người gửi chưa biết giá trị vòng lặp thời gian

Throughput: 32 bit

Trường này biểu thị thông lượng hiện hành, cwnd/RTT, được đo bởi người gửi các đơn vị được tính theo kbps(kbyte/s) Giá trị thông lượng sẽ được tăng lên Giá trị lớn nhất có thể có trong trường này là 34 tbps và bước nhảy là 8 kbit/s

Delta_throughput: 32 bit

Trường này biểu thay đổi thông lượng theo yêu cầu hay thông lượng cấp phát

Đo bởi byte/s Đây là một giá trị tượng trưng Một ‘0’ trong bit 0 biểu thị một giá trị tích cực và một ‘1’ trong bit 0 biểu thị một giá trị không chấp nhận giá trị nhỏ nhất có thể được trong trường này là f17 Gbps Giá trị lớn nhất có thể đạt được trong trường

này là 17 Gbps với mỗi bước nhảy là 8 kbit mỗi giây và nó được thiết lập bởi người gửi biểu thị lượng thông lượng mà người gửi muốn điều chỉnh trong thông lượng của

họ, giá trị có thể được biến đổi bởi các router dọc trên đường truyền

Reverse_Feedback: giá trị thông tin phản hồi đảo ngược

Trường này biểu thị giá trị của Delta_throughput được chấp nhận thông qua dữ liệu nhận được Người nhận copy trường Delta_throughput vào trong

Reverse_Feedback vào trong packet gửi phản hồi lại trong một kết nối tương tự Nếu người nhận nhận được các packet phức tạp (multimedia) chứa một trường

Delta_throughput trước khi gửi các trường Reverse_Feedback, người nhận chịu trách nhiệm tập hợp các Reverse_Feedback này

2.3 Nguyên tắc hoạt động và cơ chế kiểm soát lỗi

2.3.1 Quá trình gửi các packet

Người gửi chịu trách nhiệm duy trì hai tham số: một ước lượng hiện hành của vòng lặp thời gian RTT tới người nhận và một cửa số chống tắc nghẽn, cwnd Người gửi có thể duy trì một thông lượng yêu cầu và một lượng yêu cầu tăng lên của thông lượng Thông lượng yêu cầu có thể được hiểu bởi một ứng dụng qua một API hoặc tốc

độ của giao diện cục bộ Người gửi có thể chọn sử dụng một giá trị hợp lý nào đó cho thông lượng yêu cầu Lượng yêu cầu tăng lên của thông lượng có được chính là do sự khác nhau của thông lượng hiện hành và thông lượng yêu cầu Nếu người gửi không có

dữ liệu để gửi tăng cửa sổ hiện hành cwnd thì lượng tăng thông lượng yêu cầu bằng 0

Khi gửi một packet, người gửi điền vào trong các trường trong header chống tắc nghẽn như sau:

f Trường Throughput thiết lập giá trị thông lượng hiện hành Giá trị này được tính như sau:

Cwnd (byte) Thông lượng hiện hành = """"""""""""""""""""

RTT (ms)

Thông lượng hiện hành có giá trị bằng 0 khi chưa biết RTT Có nghĩa là các packet đầu tiên trong một dòng sẽ sử dụng dung lượng mà nó không kiểm tra qua các thuật toán điều khiển của router, từ đó nó chỉ yêu cầu một vòng lặp đơn của một packet cho mỗi dòng để xác định một giá trị ước lượng của RTT

f Trường RTT được thiết lập giá trị vòng lặp thời gian hiện hành và nó có giá trị bằng 0 nếu vòng lặp chưa được phát hiện

f Trường Delta_throughput thiết lập giá trị lượng tăng thông lượng yêu cầu Lượng tăng thông lượng yêu cầu này được phân phối cho tất cả các packet được gửi trong một vòng lặp thời gian RTT Trường Delta_throughput của mỗi packet có giá trị như bằng thông lượng yêu cầu trừ đi thông lượng hiện hành trước đó(thông lượng hiện hành này được có giá trị bằng cwnd/RTT): Do đó công thức tính cụ thể như sau:

Thông lượng yêu cầu – cwnd*1024/RTT Delta_throughput ="""""""""""""""""""""""""""""""""""""""""""""""""

Cwnd/MSS Trong đó:

MSS: kích thước dữ liệu lớn nhất có đơn vị là byte

RTT: có đơn vị là ms

Cwnd: đơn vị là byte

Thông lượng yêu cầu: byte/s

Trong trường hợp nếu dữ liệu thiếu thông tin cwnd hiện hành, Delta_throughput

sẽ thiết lập giá trị bằng 0 tức là không có lượng thông lượng yêu cầu nào được tăng lên 2.3.2 Xử lý thông tin phản hồi tại người nhận

Người nhận XCP chịu trách nhiệm sao chép dữ liệu Delta_throughput trên các packet gửi đến vào trong trường Reverse_feedback của các packet phản hồi

2.3.3 Xử lý thông tin tại router

Công việc của một XCP router là tính toán giá trị thông tin phản hồi feedback để hệ thống đưa ra một hiệu lực tối ưu nhất và công bằng nhất Do đó XCP không có các packet bị bỏ rơi Nó hoạt động trên các kỹ thuật xử lý hàng đợi như Droptail, RED, hoặc AVQ Mục tiêu của XCP là ngăn chặn càng nhiều càng tốt các hàng đợi tạo nên lên tại các điểm mà các packet bị bỏ rơi Dựa vào tính toán thông tin phản hồi feedback, một router XCP sử dụng một điều khiển công bằng và một điều khiển hiệu lực Cả hai ước lượng tính toán này thực hiện trên toàn bộ các vòng lặp thời gian trung bình (RTT) của các dòng trên đường link, nơi xãy ra sự đổ vỡ sự hoạt động trôi chảy

của giao thức điều khiển cửa sổ gốc Các điều khiển XCP tạo dựng một điều khiển đơn quyết định mọi RTT trung bình (bộ điều khiển thời gian) Đây là một thúc đẩy quan trọng bởi cần thiết theo dõi kết quả của quyết định điều khiển trước đó trước khi thử một điều khiển mới Ví dụ, nếu router báo hiệu cho nguồn tăng lên kích thước cửa sổ của chúng, nó sẽ chờ đợi để thấy bao nhiêu băng thông dư thừa trước khi gọi nguồn tăng lên lần nữa Router duy trì một điều khiển ước lượng thời gian cho mỗi đường link được thiết lập bởi ước lượng gần nhất của giá trị trung bình RTT trên đường link này Trong khoảng thời gian Timeout, router cập nhập ước lượng của nó và quyết định điều khiển của nó

Điều khiển hiệu lực (Efficiency Controller):

Điều khiển hiệu lực mục đích tận dụng đường link tối đa nhất và tỷ lệ thất lạc thông tin thấp nhất Nó chỉ chú ý đến lưu lượng chung mà không quan tâm đến kết quả công bằng

Một XCP là một “windowfbased”, Điều khiển hiệu lực tính toán một yêu cầu tăng lên hay giảm xuống số lượng bytes của lưu lượng chung truyền phát trong một điều khiển thời gian (vidụ: điều khiển RTT trung bình) Giá trị thông tin phản hồi chung feedback được tính toán trong điều khiển thời gian như sau:

QS

Điều khiển công bằng (Fairness Controller):

Công việc của điều khiển công bằng là phân chia giá trị thông tin phản hồi tới từng packet riêng lẻ nhằm đạt được sự công bằng hợp lý nhất Điều khiển công bằng dựa trên nguyên tắc của TCP dùng hội tụ tới công bằng cụ thể là thuật toán tăng công

giảm nhân (AIMD) Theo đó muốn tính toán giá trị thông tin phản hồi của mỗi packet tuỳ theo kiểm soát:

nếu φ > 0,dung lượng cấp phối tăng thêm cho mỗi dòng là như nhau

nếu φ < 0, dung lượng cấp phối giảm ở mỗi dòng tỷ lệ với thông lượng hiện hành của dòng đó

Đảm bảo sự hội tụ kế tiếp cho công bằng trải dài trong thời gian giá trị thông tin phản hồi chung, ngăn chặn sự dừng lại của hội tụ, khi phạm vi hiệu lực tối ưu nhất (φ ≈ 0) Trật tự băng thông chỉ sự cấp phối đồng thời và thoả thuận vị trí của băng thông để cho toàn bộ tỷ lệ lưu lượng (và do đó hiệu lực) không thay đổi, thông lượng của các dòng riêng lẻ thay đổi dần tới trạng thái chia sẽ các dòng hợp lý

Trật tự băng thông được tính toán theo công thức sau:

h = max ( 0, γ.y f /φ/)

y là lưu lượng đầu vào trong một thời gian RTT trung bình, γ là hằng số có giá trị bằng 0.1 Công thức này chỉ ra, mỗi giá trị RTT trung bình tại đó 10% lưu lượng được phân phối lại theo thuật toán AIMD Chọn lựa 10% là một cân bằng thời gian giữa đồng quy tới công bằng và xáo trộn trật tự áp đặt lên một hệ thống là phạm vi hiệu lực tối ưu nhất

Ước tính giá trị thông tin phản hồi cho mỗi packet (H_feedback) cho phép điều khiển công bằng có hiệu lực Từ đó sự tăng lên của dòng tính bằng cộng còn sự giảm đi theo cấp số nhân, do đó thuận tiện cho tính toán giá trị thông tin phản hồi của packet có

Sự thay đổi cửa sổ chống tắc nghẽn trong giá trị thông tin phản hồi sẽ được ghi lại trong header chống tắc nghẽn Sự thay đổi chung trong cửa sổ chống tắc nghẽn của một dòng là tổng giá trị thông tin phản hồi của từng packet mà nó nhận được Do đó tính được thông tin phản hồi của từng packet thông qua phân chia sự thay đổi thông tin phản hồi bởi một số lượng các packet từ dòng i mà couter phát hiện được trong một điều khiển thời gian Số lượng này tỷ lệ với kích thước cửa sổ của dòng chia cho kích thước packet của nó

Giá trị thông tin phản hồi tích cực pi được tính theo công thức:

pi =

i

i i p

cwnd

S rtt 2 −

max(φ đảm bảo luôn sử dụng giá trị thông tin phản hồi tích cực (+)

Tổng tỷ lệ tăng lên lưu lượng của tất cả các dòng trong tổng quát bằng tổng các giá trị thông tin phản hồi tích cực của một dòng chia cho RTT của nó

cwnd

S rtt d

h

.

) 0 , max(φξ

Tương tự tính toán cho giá trị thông tin phản hồi tiêu cực (f) Khi giá trị thông tin phản hồi chung là tiêu cực (φ< 0) Trong trường hợp này lượng thông lượng giảm

đi của dòng thứ i tỷ lệ với thông lượng hiện hành của nó Do vậy sự thay đổi theo yêu cầu trong kích thước cửa sổ của dòng tỷ lệ với cửa sổ kích thước hiện thời của nó Giá trị thông tin phản hồi yêu cầu thay đổi của mỗi packet tính bằng cách chia cho số lượng packet mà router phát hiện được trong một khoảng thời gian d Vì thế giá trị thông tin phản hồi của mỗi packet tỷ lệ với kích thước packet và RTT của dòng

Công thức tính giá trị thông tin phản hồi ni như sau:

i i n

n =ξ .Trong đó ξnlà hằng số

Giống như trong trường hợp tăng thêm, sự giảm lưu lượng chung là tổng của sự ước lượng giảm riêng của tất cả các dòng

h max( φ, 0 )

Và ξnđược tính theo công thức:

∑

− +

=

i p

S d

h

.

) 0 , max( φξ

2.3.4 Xử lý thông tin phản hồi tại người gửi

Khi các packet được người nhận gửi quay trở lại người gửi ví dụ: sự đáp lại của TCP, cwnd của người gửi được cập nhật các thông tin trong trường Reverse_feedback theo công thức:

Cwnd= max (cwnd + feedback*RRT*g1, MSS)

Trong đó:

Cwnd: cửa số chống tắc nghẽn hiện hành

Feedback: Trường Reverse_feedback từ người nhận.(có thể :+ hoặc f)

RTT: ước lượng vòng lặp thời gian hiện thời

g1: Thừa số chuyển đổi: có giá trị bằng 0.001s/ms

Khi một cwnd hiện hành không được sử dụng, XCP sẽ giảm bớt nó khi đã lỗi thời để tránh sự đột ngột xuất hiện của dữ liệu trong mạng khi ứng dụng khởi động dữ liệu là chậm Katabi đưa ra một thuật toán để giải quyết vấn đề này Mỗi RTT mà người gửi không sử dụng cwnd để gửi đi thì cwnd sẽ được tính lại theo công thức: cwnd = max (0.5 ( cwnd " k ), MSS)

Trong đó K là số byte trước đây chưa gửi được

CHƯƠNG III: PHẦN MỀM MÔ PHỎNG MẠNG NSU2

3.1 Giới thiệu về phần mềm mô phỏng mạng NSU2

NS (phiên bản) là phần mềm mô phỏng mạng điều khiển sự kiện riêng rẽ hướng đối tượng, được phát triển tại UC Berkely, viết bằng ngôn ngữ C++ và OTcl NS rất hữu ích cho việc mô phỏng mạng diện rộng (WAN) và mạng local (LAN) Bốn lợi ích lớn nhất của NSf2 phải kể đến đầu tiên là:

f Khả năng kiểm tra tính ổn định của các giao thức mạng đang tồn tại

f Khả năng đánh giá các giao thức mạng mới trước khi đi vào sử dụng

f Khả năng thực thi những mô hình mạng lớn mà gần như chúng ta không thực thi được trong thực tế

f Khả năng mô phỏng nhiều loại mạng khác nhau

NSf2 là phần mềm mã nguồn mở có sẵn cho cả window và linux ở đây ta chỉ xem xét cài đặt trong linux với phần mềm hỗ trợ NAM

3.2 Cấu trúc và nguyên tắc hoạt động của NS2 và NAM

3.2.1 Cấu trúc của NSE2

Hình sau biểu diễn kiến trúc thư mục NSf2 và NAM trong môi trường Linux NSf2 và NAM đều là các thư mục con của nsfallinonef2.28 NSf2 bao gồm các thực thi

mô phỏng (bằng mã C++ và mã OTcl), các kịch bản Otcl kiểm tra tính hiệu lực và các kịch bản OTcl minh họa

NSf2 thực thi các giao thức mạng như Giao thức điều khiển truyền tải (TCP) và Giao thức gói người dùng (UDP); các dịch vụ nguồn lưu lượng như Giao thức truyền tập tin (FTP), Telnet, Web, Tốc độ bit cố định (CBR) và Tốc độ bit thay đổi (VBR) ; các kỹ thuật quản lý hàng đợi như Vào trước Ra trước (Drop Tail), Dò sớm ngẫu nhiễn (RED) và CBQ; các thuật toán định tuyến như Dijkstra… NS cũng thực thi multicasting và vài giao thức lớp Điều khiển truy cập đường truyền (MAC) đối với mô phỏng LAN

Kịch bản OTcl

f Simulation Program: Chương trình Mô phòng

f Otcl: Bộ biên dịch Tcl mở rộng hướng đối tượng

f NS Simulation Library: Thư viện Mô phỏng NS

f Event Scheduler Objects: Các đối tượng Bộ lập lịch Sự kiện

f Network Component Objects: Các đối tượng Thành phần Mạng

f Network Setup Helping Modules: Các mô đun Trợ giúp Thiết lập Mạng

f Plumbling Modules: Các mô đun Plumbling

f Simulation Results: Các kết quả Mô phỏng

NS là Bộ biên dịch Tcl mở rộng hướng đối tượng; bao gồm các đối tượng Bộ lập lịch Sự kiện, các đối tượng Thành phần Mạng và các mô đun Trợ giúp Thiết lập Mạng (hay các mô đun Plumbing)

Để sử dụng NSf2, user lập trình bằng ngôn ngữ kịch bản OTcl User có thể thêm các mã nguồn Otcl vào NSf2 bằng cách viết các lớp đối tượng mới trong OTcl Những lớp này khi đó sẽ được biên dịch cùng với mã nguồn gốc Kịch bản OTcl có thể thực hiện những việc sau:

f Khởi tạo Bộ lập lịch Sự kiện

f Thiết lập Mô hình mạng dùng các đối tượng Thành phần Mạng

f Báo cho nguồn traffic khi nào bắt đầu truyền và ngưng truyền packet trong Bộ lập lịch Sự kiện

f Thuật ngữ plumbing được dùng để chỉ việc thiết lập mạng, vì thiết lập một mạng nghĩa là xây dựng các đường dữ liệu giữa các đối tượng mạng bằng cách thiết lập con trỏ “neighbour” cho một đối tượng để chỉ đến địa chỉ của đối tượng tương ứng Mô đun plumbing OTcl trong thực tế thực hiện việc trên rất đơn giản Plumbing làm nên sức mạnh của NS

f Thành phần lớn khác của NS bên cạnh các đối tượng Thành phần Mạng là Bộ lập lịch

Sự kiện Bộ lập lịch Sự kiện trong NSf2 thực hiện những việc sau:

Tổ chức Bộ định thời Mô phỏng

Huỷ các sự kiện trong hàng đợi sự kiện

Triệu gọi các Thành phần Mạng trong mô phỏng

Phụ thuộc vào mục đích của user đối với kịch bản mô phỏng OTcl mà kết quả mô phỏng có thể được lưu trữ như file trace Định dạng file trace sẽ được tải vào trong các ứng dụng khác để thực hiện phân tích:

File nam trace (file.nam) được dùng cho công cụ Minh họa mạng NAM

File Trace (file.tr) được dùng cho công cụ Lần vết và Giám sát Mô phỏng XGRAPH hay TRACEGRAPH

Luồng các sự kiện cho file Tcl chạy trong NS

f NAM Visual Simulation Mô phỏng ảo NAM

f Tracing and Monitoring Simulation Mô phỏng Lần vết và Giám sát

Hình sau biểu diễn kiến trúc chung của NS User có thể tưởng tượng mình đang đứng ở góc trái dưới, thiết kế và chạy các mô phỏng trong Tcl Tcl dùng các đối tượng

mô phỏng trong OTcl Các đối tượng Bộ lập lịch Sự kiện và hầu hết các đối tượng Thành phần Mạng thực thi bằng C++ và sẵn có cho OTcl qua một liên kết OTcl Liên kết OTcl này được thực thi dùng TclCL Tất cả đã làm nên NS, bộ biên dịch Tcl mở rộng hướng đối tượng và các thư viện mô phỏng mạng

Tracing and Monioring Simulation

NS sử dụng hai ngôn ngữ lập trình: Ngôn ngữ kịch bản (Tcl – Tool Command Language, đọc là tickle) và Ngôn ngữ lập trình hệ thống (C/C++)

NS là tầng biên dịch Tcl để chạy các kịch bản Tcl

Bằng cách sử dụng C++/OTcl, bộ mô phỏng mạng phải hoàn toàn là hướng đối tượng Hình sau chỉ ra các đối tượng C++ có liên kết OTcl Khi đó, nếu chúng tạo nên một phân cấp thì các đối tượng OTcl cũng có một phân cấp tương ứng như vậy

TclCL là ngôn ngữ được sử dụng để cung cấp liên kết giữa C++ và OTcl Các kịch bản Tcl/OTcl được viết để thiết lập và cấu hình topology của mạng TclCL cung cấp liên kết giữa phân cấp lớp, khởi tạo đối tượng, nối kết biến và gửi lệnh

TclCL hoạt động như liên kết giữa A và B

NSf2 sử dụng 2 ngôn ngữ là vì bộ mô phỏng cần thực hiện hai công việc khác nhau Ngôn ngữ C++:

f Mô phỏng giao thức chi tiết yêu cầu ngôn ngữ lập trình hệ thống

f Thao tác trên byte, xử lý gói, thực thi thuật toán

f Tốc độ thời gian thực là quan trọng nhất

f Thực hiện bất kỳ việc gì mà cần phải xử lý tứng packet của một luồng

f Thay đổi hành vi của lớp C++ đang tồn tại theo những hướng đã không được lường trước

Ngôn ngữ Otcl:

Mô phỏng những thông số hay cấu hình thay đổi

Tham dò nhanh một số tình huống

Thời gian tương tác (thay đổi mô hình hay chạy lại) là quan trọng

Cấu hình, thiết lập hay những gì chỉ làm một lần

Thực hiện những cái ta muốn bằng cách thao tác trên các đối tượng C++ đang tồn tại

Ví dụ như các link là những đối tượng OTcl liên kết các mô đun delay (trì hoãn), queueing (hàng đợi) và possibly loss (khả năng mất mát) Còn nếu muốn thực hiện những việc chuyên nghiệp hơn thì cần phải tạo ra đối tượng C++ mới

Hầu hết định tuyến được viết bằng OTcl (dù thuật toán Dijkstra lõi viết bằng C++) Mô phỏng HTTP có từng luồng bắt đầu tại OTcl nhưng việc xử lý từng gói lại được viết bằng C++ Phương pháp này chạy tốt cho đến khi có đến 100 luồng bắt đầu thời gian

mô phỏng mỗi giây Nói chung, nếu phải triệu gọi Tcl nhiều lần mỗi giây thì có lẽ nên chuyển sang C++

Về phương diện mã nguồn, NSf2 được viết với 100k dòng mã lệnh C++, 70k dòng mã Tcl và 20k dòng tài liệu

3.2.2 Các đặc tính của NSE2

NSf2 thực thi những tính năng sau:

Các kỹ thuật quản lý hàng đợi Router như DropTail, RED, CBQ,

Multicasting

Mô phỏng mạng không dây

Được phát triển bởi Sun Microsystems + UC Berkeley (Dự án Daedalus)

Thuộc mặt đất (di động, adhoc, GPRS, WLAN, BLUETOOTH), vệ tinh

Chuẩn IEEE 802.11 có thể được mô phỏng, các giao thức MobilefIP và adhoc như DSR, TORA, DSDV và AODV

3.2.3 Ví dụ về một mạng cơ bản của NSE2

Về cơ bản, NS là trình biên dịch OTcl với các thư viện đối tượng mô phỏng mạng Biết lập trình bằng OTcl sẽ giúp sử dụng NS dễ dàng Ví dụ sau sẽ giúp chúng ta tiếp cận với OTcl Chạy ví dụ này bằng cách gõ lệnh “ns nsfsimple.tcl” tai dấu nhắc hệ thống

Topology mạng đơn giản và kịch bản mô phỏng

Mạng trên bao gồm 4 node (n0, n1, n2, n3) Duplex link (liên kết truyền nhận

dữ liệu hai chiều diễn ra đồng thời) giữa node n0 và n2, n1 và n2 có bandwidth (băng thông) = 2 Mbps, delay (thời gian trì hoãn) = 10 ms Duplex link giữa n2 và n3 có bandwidth = 1.7 Mbps và delay = 20 ms Các node dùng hàng đợi DropTail, max size (kích thuớc lớn nhất) = 10 Agent “tcp” gắn với n0 và agent “sink” gắn với n3 Agent

“tcp” có thể tạo packet với max size = 1 KByte Agent tcp “sink” tạo và gửi packet dạng ACK cho sender (sender là agent gửi packet đi) và giải phóng packet nhận được Agent “udp” gắn với n1 sẽ kết nối với agent “null” gắn với n3 Agent “null” chỉ giải phóng packet đã nhận được Bộ khởi tạo lưu lượng “ftp” và “cbr” tương ứng được gắn vào agent “tcp” và “udp” “cbr” được cấu hình để tạo ra packet 1 KByte tại tốc độ 1 Mbps “cbr” được thiết lập cho start bắt đầu tại thời điểm 0.1 giây và kết thúc tại thời điểm 4.5 giây, “ftp” bắt đầu lúc 1.0 giây và kết thúc lúc 4.0 giây

#Create a simulator object

set ns [new Simulator]

#Define different colors for data flows (for NAM)

$ns color 1 Blue

$ns color 2 Red

#Open the NAM trace file

set nf [open out.nam w]

#Execute NAM on the trace file

exec nam out.nam &

#Set Queue Size of link (n2"n3) to 10

$ns queue"limit $n2 $n3 10

#Give node position (for NAM)

$ns duplex"link"op $n0 $n2 orient right"down

$ns duplex"link"op $n1 $n2 orient right"up

$ns duplex"link"op $n2 $n3 orient right

#Monitor the queue for link (n2"n3) (for NAM)

#Setup a FTP over TCP connection

set ftp [new Application/FTP]

$ftp attach"agent $tcp

$ftp set type_ FTP

#Setup a UDP connection

set udp [new Agent/UDP]

$udp set fid_ 2

#Setup a CBR over UDP connection

set cbr [new Application/Traffic/CBR]

$cbr attach"agent $udp

$cbr set type_ CBR

$cbr set packet_size_ 1000

$cbr set rate_ 1mb

$cbr set random_ false

#Schedule events for the CBR and FTP agents

$ns at 0.1 "$cbr start"

$ns at 1.0 "$ftp start"

$ns at 4.0 "$ftp stop"

$ns at 4.5 "$cbr stop"

#Detach tcp and sink agents (not really necessary)

$ns at 4.5 "$ns detach"agent $n0 $tcp ; $ns detach"agent $n3 $sink"

#Call the finish procedure after 5 seconds of simulation time

$ns at 5.0 "finish"

#Print CBR packet size and interval

puts "CBR packet size = [$cbr set packet_size_]"

puts "CBR interval = [$cbr set interval_]"

#Run the simulation

Tạo Bộ lập lịch (mặc định là Calender scheduler f Bộ lập lịch Thời gian)

Đối tượng “Simulator” có các hàm thành viên thực hiện những việc sau:

Tạo đối tượng ghép như các node và các link

Connect (nối) các đối tượng Thành phần Mạng đã được tạo lại với nhau (ví dụ như hàm attachfagent)

Gán giá trị cho các tham số cho các đối tượng Thành phần Mạng (thường là cho các đối tượng ghép)

Tạo các connection giữa các agent (ví dụ như tạo connection giữa “tcp” và “sink”) Xác định tuyến tùy chọn trình diễn NAM

v.v…

Hầu hết các hàm thành viên dùng cho mục đích thiết lập mô phỏng (được đề cập đến như các hàm plumbing) và cho mục đích lập lịch Tuy nhiên cũng có những hàm là cho việc trình diễn bằng NAM Các thực thi cho các hàm thành viên của đối tượng

“Simulator” được định vị trong file “nsf2/tcl/lib.nsflib.tcl”

$ns color fid color: gán màu các packet cho luồng có mã nhận dạng luồng fid Hàm thành viên này của đối tượng Simulator được dùng cho việc trình diễn NAM, và không

có tác dụng gì trên mô phỏng thực tế

$ns namtracefall file"descriptor: hàm thành viên này yêu cầu mô phỏng lưu lại các dấu vết mô phỏng vào trong định dạng đầu vào cho NAM Đồng thời có thể cung cấp tên file mà trace (dấu vết) sẽ được ghi vào bằng lệnh $ns flushftrace Tương tự, hàm thành viên tracefall dùng lưu trace theo định tuyến dạng chung

proc finish{}: được gọi sau khi mô phỏng đã kết thúc Trong hàm này các tiến trình postfsimulation (mô phỏng thông báo) được xác định

set n0 [$ns node]: hàm thành viên node khởi tạo một node node trong NS là đối tượng ghép bao gồm address (địa chỉ) và port classifiers (bộ phân loại cổng) User có thể tạo node bằng các tạo riêng đối tượng address và port classifier và nối chúng lại với nhau.Tuy nhiên các hàm thành viên của đối tượng Simulator đã thực hiện việc này rất đơn giản Xem file “nsf2/tcl/lib/nsflib.tcl” và “nsf2/tcl/lib/nsfnode.tcl” để viết Simulator tạo node như thế nào

$ns duplexflink node1 node2 bandwidth delay queue"type: tạo hai simplex link (liên kết đơn) với bandwidth và delay xác định tuyến, nối hai node xác định lại với nhau

Trong NS, hàng đợi đầu ra của node được thực thi như một phần của link, vì vậy user nên xác định luôn queueftype khi khởi tạo link Giống như node, link là đối tượng ghép, user có thể tạo và nối các link với các node Mã nguồn link được tìm trong file

“nsf2/tcl/lib/nsflib.tcl” và “nsf2/tcl/lib/nsflink.tcl” Cần chú ý là ta hoàn toàn có thể chèn các mô đun lỗi vào trong thành phần link để mô phỏng một link hay bị mất gói cũng như chèn thêm bất kỳ đối tượng mạng nào

$ns queueflinit node1 node2 number: xác định giới hạn hàng đợi của hai simplex link kết nối node1 và node2 với nhau

$ns duplexflinkfop node1 node2 … : dùng cho NAM

Quá trình tiếp theo là thiết lập các agent như TCP, UDP; các nguồn traffic như FTP, CBR; connect các agent với các node và connect các nguồn traffic với các agent set tcp [new Agent/TCP]: lệnh tạo ra một agent TCP, và đây cũng là cách để tạo ra bất

kỳ agent hay nguồn traffic nào Các agent và các nguồn traffic chứa trong các đối tượng cơ bản thực (không phải trong các đối tượng kép), hầu như được thực thi trong C++ và được liên kết đến OTcl Vì vậy, không có hàm thành viên nào của một đối tượng Simulator xác định là có thể tạo ra các instance của các đối tượng này Để tạo được agent và nguồn lưu lượng thì user cần phải biết tên lớp của các đối tượng này (Agent/TCP, Agent/TCPSink, Application/FTP v.v ) Xem thêm trong file "nsf2/tcl/libs/nsfdefault.tcl" File này chứa các thiết lập giá trị tham số cấu hình mặc định cho các đối tượng mạng sẵn có

$ns attachfagent node agent: hàm thành viên attachfagent gắn agent vào node Hàm này sẽ gọi hàm thành viên attach của một node xác định tuyến, để gắn agent vào node

đó Vì vậy, user có thể làm tương tự, như $n0 attach $tcp chẳng hạn Ngoài ra, một agent có thể dùng hàm attach của nó để gắn một nguồn traffic vào chính nó

$ns connect agent1 agent2: hàm thiết lập liên kết luận lý giữa hai agent, bằng cách thiết lập địa chỉ đích đến mạng của nhau và cặp địa chỉ cổng

Bây giờ giả sử rằng tất cả cấu hình mạng đã được thực hiện Tiếp theo là ghi kịch bản

mô phỏng Đối tượng Simulator hiện có nhiều hàm thành viên lập lịch

$ns at time “string”: hàm này yêu cầu scheduler (bộ lập lịch) lập lịch cho “string” thực thi vào thời gian time Trong NS, thực tế thì nguồn traffic không truyền dữ liệu thật, nhưng nó lại thông báo cho agent phía dưới rằng nó có dữ liệu cần truyền Khi đó agent

sẽ tạo ra packet để truyền dữ liệu ấy đi

Cuối cùng là chạy mô phỏng bằng lệnh $ns run

Ví dụ trên đã cho chúng ta những hình dung cơ bản về cách khởi tạo node, link, agent, traffic…Trên cơ sở đó sẽ giới thiệu chi tiết các hoạt động này Đồng thời ta sẽ biết thêm về các dịch vụ cơ bản trong Internet, tracing, routing…Nắm vững được chúng sẽ giúp thực thi được những bài mô phỏng hiệu quả và lợi ích nhất

Trong NSf2, một mạng máy tính bao gồm các node được nối với nhau bởi các link Các event được lập lịch để truyền dọc theo các link, nghĩa là truyền giữa các node Agent được gắn vào node để tạo các packet khác nhau (như agent TCP hay agent UDP) Traffic source (nguồn lưu lượng) chính là application (ứng dụng) được gắn vào agent Hình sau biểu diễn hai node, một link giữa hai node, một agent gắn vào node 1

và một application gắn vào agent đó

Sự liên kết các đối tượng cơ bản trong NS

Kịch bản OTcl cho lập lịch sự kiện: Tạo bộ lập lịch, Lập lịch sự kiện, Khởi động bộ lập lịch như sau:

set ns [new Simulator]

$ns at <time> <event>

$ns run

3.2.4 Khởi tạo node

Node là đối tượng ghép từ đối tượng node entry và classifiers Trong NS có hai loại node Node unicast có một address classifier (bộ phân loại địa chỉ) làm nhiệm vụ định tuyến tuyến unicast và một port classifier (bộ phân loại cổng) Node multicast có thêm một classifier (bộ phân loại) làm nhiệm vụ phân loại các packet multicast với các packet unicast và multicast classifier (bộ phân loại multicast) để định tuyến multicast