NS là bộ mô phỏng hướng sự kiện viết bằng C++, với một trình thông dịch OTcl (Object Oriented Tool Command Language) giao tiếp với người sử dụng. Để giảm thời gian xử lý gói tin và thời gian xử lý sự kiện, bộ lập lịch sự kiện và các đối tượng mạng cơ bản trong đường truyền dữ liệu được viết và dịch bằng C++. Những đối tượng được biên dịch này sẽ được kết nối tới bộ thông dịch OTcl qua trình liên kết OTcl. Trình liên kết này sẽ tạo ra các đối tượng
OTcl tương ứng với mỗi đối tượng trong C++. Các hàm và biến trong đối tượng C++ chuyển thành các hàm và biến trong đối tượng OTcl tương ứng. Do đó, việc điều khiển các đối tượng C++ có thể được thực hiện trong ngôn ngữ mô phỏng OTcl. Các lớp trong C++ được tổ chức dưới dạng cây phân cấp, và tạo ra tương ứng trong OTcl. Hai cây phân cấp này có mối quan hệ chặt chẽ với nhau, với một lớp trong cây phân cấp thông dịch OTcl thì cũng có một lớp tương ứng trong cây phân cấp biên dịch. Đỉnh của cây phân cấp OTcl là TclObject. Người sử dụng tạo ra những đối tượng mô phỏng mới thông qua trình thông dịch OTcl, những đối tượng này được thiết lập tự động thông qua các phương thức được định nghĩa trong lớp TclClass. Chúng ta có thể thay đổi các tham số cho các đối tượng mô phỏng thông qua các phương thức được định nghĩa trong lớp TclObject [11].
Hình 4.1. Sự tương đồng giữa C++ và OTcl
NS sử dụng hai ngôn ngữ là vì hai lý do. Thứ nhất, các giao thức mô phỏng yêu cầu một ngôn ngữ lập trình hệ thống có thể làm việc hiệu quả với các thao tác trên byte, các header của gói tin và cài đặt các giải thuật thực hiện trên các tệp dữ liệu lớn. Với nhiệm vụ này thì tốc độ xử lý là quan trọng, còn thời gian thay đổi chương trình và thực hiện mô phỏng ít quan trọng hơn. Thứ hai, phần lớn công việc nghiên cứu về mạng là thay đổi các tham số mô phỏng, thực hiện cấu hình mạng, hoặc thăm dò nhanh một số trường hợp được cho là có khả năng. Trong trường hợp này, thời gian lặp đi lặp lại quan trọng hơn. C++ chạy nhanh hơn nhưng khi thay đổi thì chậm hơn, nên C++ thích hợp cho việc cài đặt chi tiết các giao thức và các đối tượng mạng. OTcl chạy chậm hơn nhưng có thể thay đổi rất nhanh, thích hợp cho việc cấu hình mô phỏng.
Dưới góc độ người dùng, một hệ thống mô phỏng NS2 được mô hình hóa như sau:
Hình 4.2. NS2 dưới góc nhìn của người sử dụng
Từ mô hình trên có thể thấy, NS2 sử dụng ngôn ngữ Otcl với thư viện bao gồm các đối tượng: Bộ lập lịch các sự kiện; thư viện đối tượng các thành phần mạng và các modul thiết lập mạng. Nói cách khác, để sử dụng NS2, ta phải lập trình trên ngôn ngữ Otcl. Để cài đặt và chạy chương trình mô phỏng mạng bằng NS, ta phải viết Script trên ngôn ngữ Otcl, lập lịch cho các sự kiện, thiết lập cấu hình mạng (topo mạng) bằng cách sử dụng các đối tượng thành phần mạng, triệu gọi các hàm thư viện, báo cho các nguồn dữ liệu biết khi nào thì bắt đầu và kết thúc việc truyền gói tin trên mạng. Khi muốn tạo một đối tượng mạng mới, có thể viết mới một đối tượng hoặc bằng cách liên kết các đối tượng mạng đã có sẵn trong thư viện. Việc gắn kết đối tượng tạo nên đối tượng mới chính là điểm mạnh của NS2.
Khi mô phỏng kết thúc, NS sinh ra một hay nhiều tệp tin vết chứa các thông tin chi tiết về các sự kiện xảy ra trong mạng mô phỏng dưới dạng văn bản. Tệp vết có hai loại, tệp vết có tên mở rộng .tr và tệp vết có tên mở rộng .nam. Tệp vết có tên mở rộng .tr chứa các thông tin chi tiết về những gì xảy ra và xảy ra khi nào. Có thể thực hiện rất nhiều phân tích khác nhau dựa vào file này. Tệp vết có đuôi là .nam ghi lại các sự kiện trong mạng và các thông tin liên quan đến sự kiện, dùng cho chương trình NAM để hiển thị dưới dạng đồ hoạ topo mạng và sự hoạt động của mạng.
Bộ mô phỏng NS-2 là mã nguồn mở. Điều này có nghĩa là trong trường hợp cần thiết, muốn tăng lượng thông tin trong tệp vết hoàn toàn có thể sửa đổi mã nguồn của NS-2 để thực hiện điều này.
Để phân tích, đánh giá được các tham số hiệu suất cần thiết từ các thông tin mà NS kết xuất ra tệp tin vết, người nghiên cứu thường phải dùng thêm một số công cụ dùng để vẽ đồ thị (như XGRAPH, gnuplot,...) và công cụ để tổng hợp các dữ liệu trong các tệp tin vết. Tất nhiên, người nghiên cứu hoàn toàn có thể tự viết lấy các đoạn mã (script) hoặc chương trình để phân tích kết quả theo yêu cầu của mình. Các ngôn ngữ Awk, PERL, hoặc Tcl thường được sử dụng để làm việc này. Nhiều nhà nghiên cứu đã chia sẻ một số kịch bản mô phỏng cũng như kịch bản xử lý kết quả tệp tin vết cho cộng đồng người sử dụng NS. Đây cũng chính là lợi thế cho người mới nghiên cứu mô phỏng mạng sử dụng bộ mô phỏng NS.
4.1.3. Cấu trúc của tệp vết
Dữ liệu ra sau khi mô phỏng với NS-2 thường được lưu trong một tệp, tệp này được gọi là tệp vết (trace file). Tệp vết chứa thông tin về các sự kiện của gói tin xảy ra trong suốt thời gian mô phỏng theo từng tầng: tầng MAC, tầng mạng, tầng giao vận. Khi NS-2 ghi vết các sự kiện trong một tệp ASCII đầu ra, tệp vết có tên mở rộng .tr, với tệp vết của việc mô phỏng mạng có dây, các dòng được tổ chức thành 12 trường. Ý nghĩa của các trường là:
Hình 4.3. Các trường trong tệp vết
Ý nghĩa của các trường là:
1. event: ký hiệu sự kiện, có thể là 1 trong 4 chữ cái sau: • r (receive): có gói tin được nhận tại node “to node”.
• + (enqueue): có gói tin được xếp vào hàng đợi tại node “from node” để chờ gửi đến node “to node”.
• - (dequeue): có gói tin được gửi (send) từ node “from node” đến node “to node”.
• d (drop): có gói tin gửi từ node “from node” đến node “to node” bị loại (có thể hiểu là trên đường truyền và không đến được node “to node”).
2. time: thời điểm xảy ra sự kiện (time là giá trị thực, có tối đa 5 chữ số sau dấu chấm thập phân).
3. from node: số của node mạng gửi gói tin
4. to node: số của node mạng nhận gói tin. Hai trường from node và to node xác định đường truyền trên đó xảy ra sự kiện.
5. pkt type: cho biết loại của gói tin.
6. pkt size: kích thước của gói tin, đơn vị là byte.
7. flags: trường cờ, gồm 6 cờ, mỗi cờ tương ứng với 1 bit trong header của gói tin. Giá trị 0 của mỗi cờ được thể hiện bằng ký tự „‐„. Hiện tại, đối
với mạng có dây, NS‐2 mới chỉ sử dụng 4 cờ sau để thông báo ECN (Explicit Congestion Notification):
• “E” để báo có tắc nghẽn (CE – Congestion Experienced)
• “N” để thông báo tầng giao vận có khả năng xử lý báo hiệu ECT (ECN‐Capable Transport) trong IP header.
• “C” (ECN‐Echo): gói tin chứa thông báo tắc nghẽn, do bên nhận gửi cho bên gửi sau khi nó nhận được gói tin có cờ “E”.
• “A” for Congestion Window Reduced (CWR) in the TCP header.
• Còn 2 cờ khác nữa là: “P” cờ ưu tiên và “F” báo hiệu TCP Fast Start. 8. fid (flow id): Chứa giá trị fid của IPv6, người lập trình có thể thiết lập giá trị fid cho các gói tin thuộc mỗi kết nối khi viết chương trình mô phỏng bằng Otcl script để phục vụ cho việc phân tích tệp vết của mình và để chương trình NAM có thể hiển thị màu của các gói tin căn cứ theo giá trị của fid.
9. src addr (source address): địa chỉ nguồn gửi gói tin, có dạng “node.portʺ.
10. dst addr (destination address): tương tự src addr.
11. seq number (sequence number): số thứ tự của gói tin của giao thức tầng mạng (và tầng giao vận).
12. pkt id (packet id): chứa số định danh của gói tin. 4.1.4. Nguồn phát sinh lưu lượng
NS hỗ trợ bốn loại nguồn phát sinh lưu lượng [10]:
1. EXPOO_Traffic: tạo lưu lượng dựa vào một phân phối On/Off theo hàm mũ. Các gói tin được gửi đi với tốc độ xác định trong suốt quãng thời gian on, và không có gói tin nào được gửi trong khoảng thời gian off. Khoảng thời gian on và off được tạo ra theo phân phối hàm mũ. Kích thước các gói tin không thay đổi.
2. POO_Traffic: tạo lưu lượng dựa vào phân phối On/Off Pareto. Loại này tương tự phân phối theo hàm mũ trừ khoảng thời gian on/off được thực hiện theo phân phối pareto.
3. CBR_Traffic: tạo lưu lượng với tốc độ không đổi được định sẵn. Kích thước gói tin là cố định trong thời gian nguồn hoạt động, nhưng có thể chọn các giá trị khác nhau. Ngoài ra, một bộ tạo số ngẫu nhiên có thể được kích hoạt, để thay đổi khoảng thời gian các gói tin khởi hành trong một phạm vi nhất định.
4. TrafficTrace: là nguồn lưu lượng được ghi lại dưới dạng vết của một nguồn lưu lượng đến từ mạng thật.
4.2. Xây dựng các mô hình đảm bảo QoS bằng phần mềm NS-2
4.2.1. Thực nghiệm 1: mô phỏng mạng IP thông thường
Sử dụng một mô hình mạng gồm 12 nút router (đều là router thông thường), từ S0 đến S11, như hình 4.4.
Hình 4.4. Topo mạng thực hiện mô phỏng
Các nguồn sinh lưu lượng CBR đặt tại node 1, đích nhận lưu lượng (Null) đặt tại node 11. Nguồn sinh lưu lưu lượng FTP đặt tại node 0, đích nhận (sink) đặt tại node 2. Các kết nối giữa các nút đều là full-duplex. CBR1 tương ứng với luồng video của ứng dụng conference = 384kbps; CBR2 tương ứng với luồng voice của conference =19,2kbps.
Node 0 nối với node 1 qua đường truyền có bandwidth =150kbps, delay=5ms, nhằm hạn chế thông lượng tối đa của kết nối TCP là 150kbps. Luồng TCP sẽ cạnh tranh việc sử dụng đường truyền giữa nút S1 và S2; Nó được tôi đưa vào như lưu lượng gây nhiễu, tác động xấu đến chất lượng dịch vụ của ứng dụng video conference, dùng để đánh giá yêu cầu tài nguyên của ứng dụng này.
Thiết lập dải thông (bandwidth) của các đường truyền còn lại lần lượt là 500, 600, 700, 800, 900, 1000kbps.
Với mỗi giá trị trên, tôi thực hiện chạy mô phỏng, phân tích tệp vết và tính delay, throughput, lossrate. Từ đó vẽ đồ thị của throughput, delay, lossrate ứng với các giá trị thay đổi của bandwidth.
Kết quả nhận được trình bày trên các ở các bảng 4.1, 4.2, 4.3 và được vẽ đồ thị trên các hình 4.5, 4.6 và 4.7 sau:
Link Bandwidth (Kbps) Delay (ms) TCP (S0 > S2) Video (S1 >S11) Voice (S1 > S11) 500 975.144206512 137.280174262 90.635714285 600 975.174907514 51.8811904271 63.1231122448 700 975.204132947 47.2288131755 48.5364081632 800 975.227722543 44.4258250128 45.6533979591 900 975.249364162 42.4810113226 43.6953673469 1000 975.268583815 41.0313937210 42.1326224489
Bảng 4.1. Giá trị delay của các luồng theo bandwidth
Hình 4.5. Độ trễ trung bình của từng luồng theo bandwidth
Khi thay đổi băng thông các đường truyền (trừ đường truyền nối nút S0 và S1 được giữ không thay đổi trong tất cả các mô phỏng =150Kbps) thì độ trễ trung bình các gói tin của luồng TCP thay đổi không đáng kể. Độ trễ trung bình các gói tin của luồng voice và video giảm dần và xấp xỉ bằng nhau.
Điều này có thể được giải thích như sau: Khi banwidth có giá trị nhỏ nhất là 500kbps, tổng lưu lượng đưa vào mạng của luồng video và voice là 384kbps +19.2kbps = 403.2kbps. Phần băng thông của các đường truyền (trừ đường truyền S0-S1) còn có thể sử dụng được là 96.8kbps, trong khi đó luồng TCP có
khả năng tự thích ứng với đường truyền và đã bị hạn chế tốc độ tối đa đưa dữ liệu vào mạng là 150kbps, do đó độ trễ tăng lên cao hơn không nhiều, so với các trường hợp bandwidth được thiết lập các giá trị lớn hơn.
Luồng voice và video có độ trễ xấp xỉ như nhau và khi tăng bandwidth đến mức 600 trở lên thì delay của voice và video xấp xỉ bằng nhau.
Để so sánh thông lượng trung bình của các luồng khi băng thông thay đổi ta dựa vào bảng 4.2 và hình 4.6 sau đây:
Link Bandwidth (Kbps) Throughput (Kbps) TCP (S0 > S2) Video (S1 >S11) Voice (S1 > S11) 500 100.08048701 357.986025190 17.696321565 600 145.95820106 375.083085826 18.9369580165 700 145.98955815 375.193099897 18.9432989690 800 146.01308862 375.193099897 18.9432989690 900 146.03139364 375.193099897 18.9432989690 1000 146.04604097 375.193099897 18.9432989690 Bảng 4.2. Thông lượng trung bình của các luồng theo băng thông
Throughput của luồng voice là không đổi, giữ ở mức ~ 10Kbps. Luồng TCP throughput gần đạt được đến mức 150Kbps
Luồng video throughput gần đạt đến mức 380Kbps
Để kiểm tra tỷ lệ mất gói tin của các luồng khi băng thông thay đổi ta dựa vào bảng 4.3 và hình 4.7 sau: Link Bandwidth (Kbps) Throughput (Kbps) TCP (S0 > S2) Video (S1 >S11) Voice (S1 > S11) 500 7.75193798449613 4.01441070509522 7.1428571428571 600 9.42408376963351 0 0 700 9.42408376963351 0 0 800 9.42408376963351 0 0 900 9.42408376963351 0 0 1000 9.42408376963351 0 0
Bảng 4.3. Tỷ lệ mất gói tin của các luồng theo băng thông
Theo đồ thị trên ta thấy với bandwidth = 500kbps, lossrate của luồng video khoảng 4%, luồng voice khoảng 7.14%, luồng TCP khoảng 7.75%.
Khi ta tăng băng thông đến giá trị 600kbps trở lên lossrate của luồng video và voice là 0%, tỷ lệ mất gói của luồng TCP là giữ ở mức 9.4%. Điều này có thể giải thích là do đặt băng thông cho luồng TCP là 150Kbps nên mặc dù tăng kích thước của đường truyền lên 600, 700, 800, 900, 1000 thì tỷ lệ mất gói của luồng TCP là không đổi
Từ các kết quả trên có thể nhận xét như sau:
Khi banwidth có giá trị nhỏ nhất là 500kbps, tổng lưu lượng đưa vào mạng của luồng video và voice là xấp xỉ 400kbps (đã được tính ở trên), lưu lượng luồng TCP tối đa có thể đạt là 150kbps. Như vậy, tổng lưu lượng đưa vào mạng có thể vượt quá bandwidth của các đường truyền. Vì vậy, hàng đợi ở đầu vào đường truyền nối nút mạng S1 và S2 thường xuyên đầy, dẫn đến độ trễ trung bình của các gói tin thuộc các luồng đi qua chặng này cao và có thể có biến động trễ lớn hơn, so với các trường hợp bandwidth lớn hơn. Ngoài ra tỉ lệ mất gói tin là đáng kể.
Khi banwidth có giá trị từ 600kbps trở lên, tổng lưu lượng đưa vào mạng của tất cả các luồng trong mọi thời điểm đều không thể vượt quá 550kbps (400kbps+150kbps), tức là luôn nhỏ hơn năng lực vận chuyển của các đường truyền. Vì vậy, hàng đợi ở đầu vào đường truyền nối nút mạng S1 và S2 thường xuyên ngắn và không bao giờ đầy, dẫn đến độ trễ trung bình của các gói tin thuộc các luồng đi qua chặng này thấp và không có biến động trễ lớn. Ngoài ra, tỉ lệ mất gói tin là xấp xỉ bằng 0.
Kết luận về yêu cầu tài nguyên đối với ứng dụng video conference: Trong mọi thời điểm hoạt động của ứng dụng video conference, chất lượng dịch vụ chỉ có thể được đảm bảo nếu phần băng thông có thể sử dụng được cho ứng dụng này lớn hơn từ 10% trở lên so với lưu lượng sinh ra bởi ứng dụng.
4.2.2. Thực nghiệm 2 mô phỏng mô hình IntServ
Hình 4.8. Cấu hình mô phỏng mạng thực nghiệm 2.
Thực nghiệm 2: Mô phỏng mạng IP có hỗ trợ việc đặt trƣớc tài nguyên
Để thực hiện mô phỏng 2 thì cần có các tập lệnh để thực hiện kỹ thuật lưu lượng và các mô hình khôi phục, bảo vệ đường mà thư viện ns-2.32 không có, do vậy tôi đã sử dụng phiên bản MNSv2.0 tại website http://flower.ce.cnu.ac.kr/~fog1/mns/index.html và thực hiện biên dịch lại các tham số đường dẫn biến môi trường của MNSv2.0 để tương thích với ns-2.32.
Thiết lập cấu hình mô phỏng: Topo mạng như hình 4.7. trong đó node 0 và node 10 là router thông thường, các node từ 1 đến 9 là các router hỗ trợ RSVP tạo thành một miền IntServ.
Các nguồn sinh lưu lượng được gắn vào node R0, các đích nhận lưu lượng được gắn vào node 10. Mỗi nguồn phát lưu lượng với tốc độ 0,8Mbps, kích