Đánh giá hiệu quả của giao thức SCTPIP cho ứng dụng DVTS trong hội chẩn từ xa luận văn thạc sĩ

Với mong muốn xây dựng một hệ thống dùng để khám chữa bệnh – hội chẩn từ xa cho các bệnh viện, đề tài nghiên cứu này đi sâu vào việc, tìm hiểu hoạt động của hệ thống DVTS, giao thức hỗ t

Mục lục

Lời cam đoan

Mục lục

Danh mục các từ viết tắt

Danh mục bảng, hình, sơ đồ

PHẦN MỞ ĐẦU 01

CHƯƠNG 1: TỔNG QUAN 02

1.1 Những vấn đề cần giải quyết 02

1.2 Khả dụng của DVTS mang lại 03

1.2.1 Digital Video Transport System 03

1.2.2 Kết nối toàn cầu 03

1.2.3 Ứng dụng trên thế giới 04

1.2.4 Ứng dụng tại mạng nghiên cứu và đào tạo VinaREN – Việt Nam 04

1.2.5 Thực nghiệm – Đánh giá 06

1.2.5.1 Giao diện phần mềm DVTS V0.0.2 (bản cho WindowXP) 06

1.2.5.2 Thông số thiết bị 07

1.2.5.3 Kết quả thử nghiệm 08

1.3 Mục tiêu của luận văn 09

1.4 Đối tượng và phạm vi nghiên cứu của đề tài 10

1.5 Ý NGHĨA KHOA HỌC VÀ THỰC TIỄN CỦA ĐỀ TÀI 10

1.6 CẤU TRÚC CỦA LUẬN VĂN 10

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT 12

2.1 GIAO THỨC SCTP 12

2.1.1 Lịch sử 12

2.1.2/ Tầng hoạt động của giao thức SCTP 13

2.1.3/ Kiến trúc tổng quan của giao thức SCTP 13

2.1.4/ Định dạng gói tin SCTP 19

2.1.4.1/ Trường Common Header trong SCTP (màu xanh dương) 20

2.1.4.1.a/ Cổng nguồn (Source Port Number): 20

2.1.4.1.b/ Cổng đích (Destination Port Number): 21

2.1.4.1.c/ Verification Tag (thẻ xác minh): 21

2.1.4.1.d/ Checksum: 21

2.1.4.2 Mô tả Chunk SCTP 22

2.1.4.2.a Chunk type: 22

2.1.4.2.b Chunk Flags: 22

2.1.4.2.c Chunk Length: 23

2.1.4.2.d Chunk value: 23

2.2.1 Mô tả các Chunk trong SCTP 24

2.2.1.a Chunk Dữ liệu (Data Chunk) 24

2.2.1.b INIT Chunk 24

2.2.1.c INIT ACK Chunk 24

2.2.1.d SACK Chunk 25

2.2.1.e HEARTBEAT Chunk 25

2.2.1.f HEARTBEAT ACK Chunk 25

2.2.1.g ABORT Chunk 25

2.2.1.h Shutdown Chunk 25

2.2.1.i Shutdown ACK Chunk 26

2.2.1.j Shutdown Complete Chunk 26

2.2.1.k ERROR Chunk 26

2.2.1.l COOKIE ECHO Chunk 26

2.2.1.m COOKIE ACK Chunk 26

2.2.2 CÁC ĐẶC TÍNH CỦA GIAO THỨC SCTP 27

2.2.2.1 Các đặc tính cơ bản: 27

2.2.2.1.a Đa luồng (Multistreaming): 27

2.2.2.1.b Multihoming: 28

2.2.2.1.c Message Orientaion: 28

2.2.2.1.d Un-ordered Service: 29

2.2.2.1.e Extensibility: 29

2.2.2.1.f Heartbeat: 29

2.2.2.1.g Syn cookie: 29

2.2.2.1.h Strong checksum: 29

2.2.2.1.i Dịch vụ TCP nâng cao: 30

2.2.2.2 Mở rộng: 30

2.3.1 SO SÁNH CÁC ĐẶC TÍNH/DỊCH VỤ CỦA SCTP – TCP/UDP 31

2.3.1.a/ Danh sách các đặc tính mà các giao thức SCTP, TCP, UDP hỗ trợ 31

2.3.1.b/ Đa đích: Cải tiến mạnh mẽ những thất bại (thời gian chờ) 32

2.3.1.c/ Đa luồng – giảm độ trễ 33

2.3.2 Các đặc tính kèm theo của giao thức SCTP so với TCP/UDP 34

2.3.2.a/ Ranh giới thông điệp (Message boundaries) 34

2.3.2.b/ Cải thiện bảo vệ SYN-Flood – an toàn hơn 34

2.3.2.c/ Cho phép kết nối nửa đóng 36

2.3.2.d/ Kiểm soát ùn tắc dữ liệu không tin cậy/không có thứ tự 37

2.3.2.e/ Có thể điều chỉnh các thông số (Timeout, Retrans, …) 40

2.3.2.f/ Vấn đề bảo mật trong SCTP 40

2.3.2.g/ Cho phép lỗi trong SCTP 40

2.3.3 Cấu trúc gói tin 42

2.3.4 Bảng tổng hợp so sánh sự khác nhau giữa SCTP và TCP/UDP 46

2.3.5 Sơ Đồ Trạng Thái SCTP 47

2.3.6 Kết luận 49

CHƯƠNG 3: PHÂN TÍCH – ĐÁNH GIÁ GIAO THỨC VÀ SO SÁNH HỆ THỐNG DVTS 50

3.1 Bộ công cụ NS2 50

3.1.1 Tổng quan về NS 50

3.1.2 Viết một kịch bản cho NS2 52

3.1.2.a Tạo sự kiện lập lịch 52

3.1.2.b Tạo một mô hình mạng 52

3.1.2.c Tạo một lớp Transport Agent 53

3.1.2.d Tạo ra các nguồn lưu lượng truy cập 53

3.1.2.e Truy tìm/truy vết 54

3.1.2.f Phim Mạng (NAM) 54

3.1.2.g Theo dõi tập tin 54

3.2 SCTP TRONG NS2 55

3.3 THỰC HIỆN MÔ PHỎNG 57

3.3.1 Thực hiện mô phỏng tính năng giao thức SCTP 57

3.3.1.a Môi trường thử nghiệm: 57

3.3.1.b Thực hiện mô phỏng 57

3.3.1.b.1/ Mô phỏng 1 – Cơ chế bắt tay bốn bước 57

3.3.1.b.2/ Mô phỏng 2 – INIT/COOKIE-ECHO Flooding 59

3.3.1.b.3/ Mô phỏng 3 – MultiStream 59

3.3.2 So sánh các giao thức UDP – TCP – SCTP 61

3.3.2.a Kịch bản mô phỏng 61

3.4 XÂY DỰNG ỨNG DỤNG DVTS MỚI 67

3.4.1 Mô hình: 67

3.4.1.a Mô hình cơ bản: 67

3.4.1.b Mô hình hệ thống chuẩn: 68

3.4.2 Mô tả quá trình chạy: 69

3.4.2.1 Chương trình phía Server 69

3.4.2.2 Chương trình phía Client 70

3.4.3 Giao diện chương trình DVTS mới: 70

3.4.4 Đánh giá: 72

CHƯƠNG 4: TỔNG KẾT VÀ KIẾN NGHỊ TRONG TƯƠNG LAI 73

4.1 Những Vấn Đề Được Giải Quyết 73

4.2 Những vấn đề cần nghiên cứu thêm trong tương lai 74

Tài liệu tham khảo

Phụ lục

PPID – Payload Protocol Identifier

R

RFC – Request For Comments

RTT – Round Trip Time

S

SACK – Selective Acknowledgement

SCTP – Stream Control Transport Protocol

DANH MỤC ĐỐI CHIẾU NGHĨA CÁC TỪ/CÂU

ACK – Acknowledgement – Sự Phản Hồi

Advertised receiver window credit – Cửa Sổ Nhận Uỷ Thác

Association – Hiệp hội

Association Startup and Takedown – Khởi động và ngắt một hiệp hội Blind Masquerade – Việc “Giả Mù”

Chunk – Khúc Dữ Liệu

Chunk Bundling – Đoạn/Bó dữ liệu

Chunk Flags – Cờ Bó dữ liệu

Chunk Length – Chiều dài bó dữ liệu

Chunk Type – Kiểu/Loại bó dữ liệu

Chunk Value – Giá trị bó dữ liệu

Common Header – Tiêu đề phổ biến

Congestion Control window – Cửa sổ kiểm soát tắc nghẽn

CRC – Cyclic Redundancy Check – Kiểm tra vòng (RTT) dư thừa

Destination Port Number – Số cổng của phía đích (đầu nhận)

DoS – Denial Of Services – Từ chối dịch vụ

DVTS – Digital Video Transport System – Hệ thống chuyển vận tín hiệu

Heartbeats – Những “nhịp tim” (dùng trong việc kiểm tra sự tồn tại kết nối đầu cuối một phía bất kỳ của một hiệp hội)

Improved SYN-flood protection - Cải tiến cơ chế chống tấn công SYN-lũ INIT – Initiation – Khởi tạo

Initial TSN – Khởi tạo số truyền dẫn

Initiate tag – Thẻ khởi tạo

Internet – Mạng Internet

IP – Internet Protocol – Giao thức Internet

IPSec – IP Security – Bảo mật IP

Keep-Alive – “giữ mạng sống”, thuật ngữ kiểm tra việc còn tồn tại kết nối giữa các thiết bị cuối

LAN – Local Area Network – Mạng cục bộ

Link Layer – Tầng liên kết

Maximum Segment Size – MSS – Kích thước tối đa cho phân đoạn

Message – Thông điệp

Message boundaries with reliability – Giới hạn thông điệp với độ tin cậy Message Orientaion – Hướng thuông điệp

MTU – Maximum Transmission Unit – Đơn vị truyền tải tối đa

Multihoming – Đa đích

Multistreaming – Đa luồng

Network simulator – NS – Mô phỏng mạng

Number of inbound streams – Số những dòng/luồng tin vào trong

Number of outbound streams – Số những dòng/luồng tin ra ngoài

Optional/Variable-length parameters – Các tham số chiều dài tuỳ

chọn/biến

Overhead – Tổng tải Trọng

Packet – Gói tin

Packet Validation – Gói xác nhận

Path Management – Quản lý đường dẫn

Payload protocol Identifier – PPID – Định danh giao thức tải

PCI – Protocol Control Information (protocol steering elements) - Giao

thức kiểm soát thông tin (các yếu tố chỉ đạo giao thức)

PDU – Protocol Data Unit (packet/frame on actual layer) – Giao thức đơn

vị dữ liệu (gói/khung tuỳ thuộc trên các tầng trong thực tế)

Physical Layer – Tầng vật lý

Primitives – Nguyên hàm/gốc

Rate-Adaptive – Tỉ lệ tương thích

Receive – Nhận dữ liệu

Receiver Window Size (rwnd) – Kích thước cửa sổ nhận

Round trip time – RTT – Thời gian vòng trở lại

SACK – Selective Acknowledgement – phản hồi chọn lọc

SCTP – Stream Control Transport Protocol – Giao thức điều khiển vận chuyển dòng

SCTP port number – Số cổng được gán trong SCTP

SEND – Gửi dữ liệu

Sequence Number – Số thứ tự

SDU – Service Data Unit (packet from upper layer) – Dịch vụ đơn vị dữ liệu (gói từ lớp trên)

SI – Stream Identifier Dòng/luồng định danh

Slow Start – Khởi đầu chậm

Slow Start threshold (ssthresh) – Ngưỡng khởi đầu chậm

Source Port Number – Số cổng của phía nguồn (đầu gửi)

SSN – Stream Sequence Number – Số thứ tự dòng/luồng

Stream – Luồng/dòng (sử dụng trong việc truyền dữ liệu)

SYN – Synchronize – Đồng bộ

Syn cookie – Đồng bộ cookie

TCP – Transmission Control Protocol – Giao thức điều khiển chuyển nhận TCP-Friendly Congestion Control – Kiểm soát tắc nghẽn giống với giao thức TCP

Telemedicine – Y tế từ xa

Timer – bộ thời gian

TLV – Tag, Length, Value – Thẻ, chiều dài, giá trị

Transport Address – ĐỊa chỉ chuyển vận

TSN – Transmission Sequence Number – Truyền dẫn số

UDP – User Datagram Protocol – GIao thức gói thông tin người dùng Un-ordered Service – Dịch vụ không thứ tự

Upper layer applications – Các ứng dụng lớp phía trên

User Data – Dữ liệu người dùng

User Data Fragmentation – Phân mảnh dữ liệu người dùng

Verification Tag – Thẻ xác minh

Video Conferencing – Hội nghị trực tuyến

WAN – Wide Area Network – mạng diện rộng

DANH MỤC BẢNG, BIỂU, SƠ ĐỒ, HÌNH VẼ

Chương 1: Tổng Quan 02

Hình 1.1 – Mô Hình Của Dự Án Hệ Thống Hội Nghị DVTS 04

Hình 1.2 – Giao Diện Chương Trình DVTS Trên Window XP (V0.0.2) 07

Hình 1.3 – Mô Hình Thử Nghiệm Hệ Thống DVTS 07

Bảng 1.1 – Thông Số Thiết Bị Trong Mô Hình Thực Nghiệm 07

Hình1.4 – Thử Nghiệm Trên Laptop, Hình 1.5 – Thử Nghiệm Trên PC 08

Chương 2: Cơ Sở Lý Thuyết 12

Bảng 2.1 – Tầng Hoạt Động Của Giao Thức SCTP 13

Hình 2.1 – Mô Hình Kiến Trúc Giao Thức SCTP 14

Hình 2.2 – Định Dạng Một Gói Tin SCTP 19

Bảng 2.2 - Các Loại Trong Chunk Type (RFC4960) 24

Hình 2.3 – Mô Tả Đặc Tính Đa Luồng 27

Hình 2.4 – Mô Tả Đặc Tính Đa Đích 28

Bảng 2.3 – So Sánh Đặc Tính SCTP Vs TCP/UDP 32

Hình 2.5 – Truyền Dữ Liệu TCP Và SCTP 34

Hình 2.6: Bảo Toàn TCP, Hình 2.7: Bảo Toàn SCTP/UDP 34

Hình 2.8 – Cơ Chế Bắt Tay 3 Bước Của TCP 35

Hình 2.9 – Cơ Chế Bắt Tay 4 Bước Của SCTP 35

Hình 2.10 – Ngắt Kết Nối TCP, Hình 2.11 – Ngắt Kết Nối SCTP 36

Hình 2.12 – Thành Phần PDU Trên Các Lớp Khác Nhau 43

Hình 2.13– Thành Phần Gói Tin Của TCP Và SCTP Với IPv4 Trong Mạng

Ethernet 44

Hình 2.14 – Thành Phần Của Gói Tin Giao Thức UDP 45

Hình 2.15 – Thành Phần Của Gói Tin Giao Thức TCP 45

Hình 2.16 – Thành Phần Của Gói Tin Giao Thức SCTP 46

Bảng 2.4 – So Sánh Thuôc Tính SCTP – TCP/UDP 47

Hình 2.17 – Sơ Đồ Trạng Thái Giao Thức SCTP 48

Chương 3: Phân Tích – Đánh Giá Giao Thức Và So Sánh Hệ Thống DVTS 50

Hình 3.1 – Giao Diện Tương Tác NS2 Giữa Otcl Và C++ 51

Hình 3.2 – Giao Diện Đa Đích NS2 Cho SCTP 56

Bảng 3.1 - Kết Quả Bắt Tay Bốn Bước Trong SCTP 59

Hình 3.3 – Kết Quả Chống Flood Trong SCTP 59

Bảng 3.2 – Kết Quả Mô Phỏng Multistream 60

Hình 3.4 Và 3.5 – Kết Quả Mô Phỏng Multistream 61

Hình 3.6 – Mô Hình Mô Phỏng TCP 62

Hình 3.7 – Kết Quả Đo Độ Trễ Trên TCP 63

Hình 3.8 – Mô Hình Mô Phỏng UDP 64

Hình 3.9 – Kết Quả Đo Độ Trễ Trên UDP 64

Hình 3.10 – Mô Hình Mô Phỏng SCTP 65

Hình 3.11 – Kết Quả Đo Độ Trễ Trên SCTP 66

Hình 3.12 – Tổng Hợp Độ Trễ Của 3 Giao Thức 67

Bảng 3.3 – Tổng Hợp Thông Tin Trên 3 Giao Thức 67

Hình 3.13 – Mô Hình Hệ Thống DVTS Cơ Bản 68

Hình 3.14 – Mô Hình Chuẩn Hệ Thống DVTS 69

Hình 3.15 – Giao Diện Kết Và Kết Nối Thành Công Trên DVTS (Mới) 71

Hình 3.16 – Giao Diện Kết Nối Webcam/Camera Trên Máy Cài DVTS 71

Hình 3.17 – Giao Diện Nhận Video Và Chat Máy Cài DVTS Từ Xa 72

Chương 4: Tổng Kết Và Kiến Nghị Trong Tương Lai 73

Hình 4.1 – Các Bài Báo Viết Về SCTP (2007) 75

PHẦN MỞ ĐẦU

Cách đây hơn mười bốn năm, ngày 19/11/1997, dịch vụ Internet chính thức có mặt tại Việt Nam Việc sử dụng Internet có vẻ như đã trở nên rất quen thuộc và cần thiết hầu hết với mọi người Ngoài việc sử dụng Internet vào các mục đích phục vụ cho: kinh doanh, tìm kiếm thông tin, giải trí, …, thì Internet ngày nay còn được sử dụng nhiều vào việc phục vụ cho các mục đích liên quan đến trao đổi trực tuyến như: hội họp, tư vấn, đào tạo, hội chẩn, ELearning… vì nó giúp giải quyết công việc một cách nhanh chóng, hiệu quả, hạn chế việc phải di chuyển, giảm sự tốn kém về thời gian cũng như nâng cao hiệu quả kinh tế

Hiện tại mô hình khám chữa bệnh, hỗ trợ chẩn đoán bệnh, mổ, … trực tuyến thông qua việc sử dung Internet, đã trở thành mối quan tâm hàng đầu tại các bệnh viện lớn của hầu hết các nước trên thế giới cũng như các nước trong khu vực Châu Á và tại Việt Nam Trong đó, phần mềm mà các bệnh viện thường sử dụng trong hệ thống khám chữa bệnh trực tuyến là Digital Video Transport System (DVTS), chạy trên nền giao thức Transmission Control Protocol / Internet Protocol (TCP/IP)

Với mong muốn xây dựng một hệ thống dùng để khám chữa bệnh – hội chẩn từ xa cho các bệnh viện, đề tài nghiên cứu này đi sâu vào việc, tìm hiểu hoạt động của hệ thống DVTS, giao thức hỗ trợ và các vấn đề liên quan, nhằm mục đích xây dựng một hệ thống DVTS chạy trên cơ sở hạ tầng mạng trong nước đáp ứng được nhu cầu thực tế

CHƯƠNG 1: TỔNG QUAN 1.1 Những vấn đề cần giải quyết

Hiện nay, việc sử dụng hệ thống “hội nghị trực tuyến” (video

conferencing) để giải quyết các vấn đề trong cuộc sống như là : hội họp, thảo luận, đào tạo từ xa, và đặc biệt là sử dụng hệ thống hội nghị trực tuyến trong y học (telemedicine), …, đã trở nên phổ biến

Hội nghị trực tuyến là hệ thống thiết bị (bao gồm cả phần cứng và phần mềm) truyền tải hình ảnh và âm thanh giữa hai hoặc nhiều địa điểm từ xa kết nối qua đường truyền mạng Internet, WAN hay LAN, để đưa tín hiệu âm thanh và hình ảnh của các phòng họp đến với nhau như đang ngồi họp cùng một phòng họp; Thiết bị này cho phép hai hoặc nhiều địa điểm (phụ thuộc vào thiết bị phần cứng) cùng đồng thời liên lạc hai chiều thông qua việc truyền video và âm thanh [1]

Nhưng để có được hệ thống trên thực không dễ dàng chút nào, bởi ngoài việc đầu tư thiết bị (chi phí cao), cơ sở hạ tầng (điểm đặt hệ thống), thì vấn đề quan tâm nhất vẫn là nhân lực (vận hành hệ thống)

Vậy làm thế nào để có một hệ thống đáp ứng được hội nghị trực tuyến nhưng khắc phục được những hạn chế trên?

Một hệ thống đơn giản và hiệu quả đang được sử dụng phổ biến hiện nay ở nhiều Mạng Nghiên cứu và Đào tạo Quốc gia (NREN) ở các nước như: Hàn Quốc, Nhật Bản, Thái Lan, Trung Quốc, Đài Loan, Indonesia, Malaysia,

Philippine, Úc, Tây Ban Nha…đó chính là sử dụng phần mềm Hệ thống

truyền hình ảnh kỹ thuật số (Digital Video Transport System – DVTS)

với nhiều lợi ích [5]:

 Hệ thống thiết lập đơn giản

 Phần mềm (Server, Client) cung cấp trên cả Linux, Window

 Kinh phí thấp

 Dễ sử dụng (không cần đào tạo nhân lực)

1.2 Khả dụng của DVTS mang lại

1.2.1 Digital Video Transport System [4]

DVTS là một phần mềm ứng dụng để gửi và nhận tín hiệu hình ảnh, âm thanh chất lượng cao thông qua đường truyền mạng máy tính ở tốc độ 30 Mbps Phần mềm này được phát triển bởi dự án WIDE do Giáo sư, Tiến sĩ Jun Murai, Đại học Keio, Nhật Bản đứng đầu Phần mềm này đã được giới thiệu và trình diễn lần đầu tiên tại Hội nghị Siêu tính toán tổ chức tại Orland, Florida năm 1988 DVTS có thể chạy trên hệ điều hành khác nhau và hệ thống phân phối hình ảnh chất lượng cao với chi phí thấp bằng việc kết nối DVTS với máy tính cá nhân thông qua cổng giao tiếp IEEE1394 (http://www.DVTS.jp)

1.2.2 Kết nối toàn cầu

Thông qua việc kết nối cáp quang băng thông rộng giữa tỉnh thành, các quốc gia với việc sử dụng hệ thống DVTS làm cầu nối đã giúp cho chuyên gia của các lĩnh vực có thể trao đổi, hợp tác với nhau trong nhiều lĩnh vực và phạm vi Xem hình 1.1

Hình 1.1 – Mô hình của dự án Hệ thống hội nghị DVTS

1.2.4 Ứng dụng tại mạng nghiên cứu và đào tạo VinaREN – Việt Nam

VinaREN là mạng Nghiên cứu và Đào tạo Việt Nam hoạt động tháng 3 –

2008, mang lại nhiều lợi ích trong hoạt động nghiên cứu và đào tạo cho các đơn vị thành viên tham gia kết nối và sử dụng hệ thống DVTS Một trong

những lợi ích thiết thực và đem lại hiệu quả cao cho các thành viên đó chính

là việc tổ chức tham gia vào các diễn đàn, hội nghị, hội thảo từ xa qua mạng VinaREN, mạng TEIN

Khi tổ chức tham gia các sự kiện, các kỹ sư công nghệ thông tin, các giáo

sư, bác sĩ đến từ các trường đại học, bệnh viện trong nước như: Đại học Bách Khoa Hà Nội, Đại học Thuỷ lợi, Đại học Y Hà Nội, Đại học Huế, Bệnh viện Trung ương Quân đội 108, Học viện Quân y, Bệnh viện Bạch Mai, Bệnh viện Nhi Trung ương, Bệnh viện Việt Đức,….đã có điều kiện được phổ biến thêm những kiến thức, kỹ thuật chuyên môn mới

Thông qua việc truyền nhận hình ảnh qua DVTS, các giáo sư, bác sĩ của các bệnh viện đã có điều kiện tham gia các cuộc phẫu thuật nội soi được thực

hiện trực tiếp tại các phòng mổ của các bệnh viện ở nước ngoài như: Prince

of Wales Hospital, Hong Kong Mạng VinaREN phối hợp với Bệnh viện 108

tổ chức tham gia sự kiện “International GI Endoscopy Live Demonstration” diễn ra tại Bangkok, Thailan Tại sự kiện này, các bác sĩ của Việt Nam tiếp tục có dịp tham gia vào những ca mổ được thực hiện trực tiếp tại các phòng

mổ của các bệnh viện

Ngoài ra mạng VinaREN và một số đơn vị thành viên đã cùng phối hợp tổ chức thành công khi tham gia các diễn đàn, hội nghị, hội thảo từ xa với các tổ chức, các mạng nghiên cứu và đào tạo nước ngoài như [2]:

 Về E-Learning:

- Diễn đàn CanalAVIST – ICT Forum, ngày 31/7 và 1/8/2008 Các nước tham gia: Việt Nam, Úc, Nhật Bản, Xingapo, Thái Lan (http://www.canalavist.org/ict-forum)

- Diễn đàn Asian School on Computer Science, ngày 16 và 17/11/2008 Các nước tham gia: Thái Lan, Việt Nam, Phillipin, Xingapo (http://www.interlab.ait.ac.th/ascs/)

 Về Telemedicine:

- Diễn đàn Medical, ngày 11 và 19/9/2008 Các nước tham gia:Việt Nam, Inđônêxia, Nhật Bản, Hàn Quốc, Malaixia, Thái Lan, Xingapo (http://www.canalavist.org/med-forum)

- Hội thảo “23rd International WorkshoponTherapeutic Endoscopy” (với phần trình diễn “Live Demonstration of Endoscopy”, tổ chức ngày 9/12/2008 Các nước tham gia: Nhật Bản, Hồng Kông, Thái Lan, Đài Loan, Việt Nam

- Hội thảo chuyên đề “Tele-lecture of Laparoscopic Colo-Rectal Surgery” tại Hội nghi APAN lần thứ 27 (www.apan.net )

1.2.5 Thực nghiệm – Đánh giá

1.2.5.1 Giao diện phần mềm DVTS V0.0.2 (bản cho WindowXP)

Hình 1.2 – Giao diện chương trình DVTS trên Window XP (V0.0.2)

ình 1.2 – Giao diện chương trình DVTS trên Window XP (V0.0.2)

1.2.5.3 Kết quả thử nghiệm

Qua quá trình nghiên cứu triển khai và ứng dụng thực tiễn, có thể thấy một

số ưu điểm của việc sử dụng DVTS đó là:

 Cài đặt phần mềm đơn giản, không mất nhiều thời gian, có thể tải phần mềm về từ Internet (nguồn miễn phí);

 Giao diện đơn giản, dễ thao tác và sử dụng;

 Các đơn vị thành viên, cá nhân có thể tham gia diễn đàn, hội nghị, hội thảo từ xa, đào tạo từ xa (chỉ cần cài đặt phần mềm DVTS trên máy tính cá nhân) mà không cần phải mua sắm đầu tư một bộ thiết bị Hội nghị trực tuyến chuyên dụng, đắt tiền;

 Hình ảnh, âm thanh được gửi đi và nhận đến có chất lượng cao… Đồng thời, hệ thống DVTS cũng có một vài nhược điểm:

 Âm thanh phải sử dụng âm li điều chỉnh âm thanh mới chất lượng tốt…

 Phần mềm không tự lưu trữ, việc lưu trữ phụ thuộc máy quay video

 Không truyền được dữ liệu dạng text (chat)

 Có một khung hình nhận video

 “Độ trễ” nhất định trong quá trình truyền/nhận video

 Vấn đề liên quan tới “thời gian thực”

 Yêu cầu băng thông lớn

Vậy làm sao, tiếp cận giải pháp nào để giúp ta có thể khắc phục nhược điểm trên?

Để khắc phục tình trạng trên, đề tài đề nghị hai thử nghiệm sau:

- Thứ nhất (mục tiêu chính) là thay thế giao thức UDP – TCP/IP đang tồn tại trên hệ thống cũ, bằng giao thức SCTP/IP

- Thứ hai là xây dựng hệ thống Digital Video Transport System (DVTS) có thể truyền hình ảnh, âm thanh chất lượng cao với các mục tiêu như sau:

 Chạy trên mạng internet:

 Kết nối từ Camera/WebCam qua: IEEE 1394, USB 2.0, hoặc kết nối từ các thiết bị sẵn có tích hợp trên máy tính/Laptop

 Kết nối âm thanh trực tiếp trên máy tính (sound onboard)

 Truyền text (chat)

 Lưu trữ Video (trực tiếp trên máy tính)

 Xem lại Video

1.3 Mục tiêu của luận văn

 Nghiên cứu, nắm vững các thành phần của giao thức SCTP

 So sánh và đánh giá những đặc tính nổi trội của giao thức SCTP so với giao thức TCP/UDP Để từ đó chứng minh những đặc tính nổi trội mà giao thức SCTP mang lại

 So sánh và đánh giá việc mô phỏng quá truyền nhận dữ liệu trên giao thức SCTP và TCP/UDP Đề từ đó làm tiền đề cho việc đề xuất

sử dụng giao thức SCTP trong ứng dụng DVTS mới

 Xây dựng ứng dụng DVTS mới với các ưu điểm đã nêu như mục tiêu

ở trên

1.4 Đối tượng và phạm vi nghiên cứu của đề tài

 Thu thập dữ liệu, các bài báo và tham khảo thông tin từ những người đã tiếp cận với hệ thống DVTS và giao thức SCTP

 Phân tích điểm mạnh yếu của hệ thống DVTS, mặt hạn chế của hệ thống trên đối với hệ thống mạng y tế nước ta

 Tham khảo về giao thức SCTP (các thành phần, cấu trúc, tạo kết nối, ngắt kết nối, truyền/nhận gói tin, … ) cần thiết làm cơ sở cho việc mô phỏng

1.5 Ý nghĩa khoa học và thực tiễn của đề tài

Việc sử dụng hệ thống truyền hình trong y tế thực sự trở nên cần thiết Áp dụng các phương tiện kỹ thuật, công nghệ xây dựng một hệ thống ứng dụng phục vụ cho mục đích này là một hướng mở đồng thời, việc thực nghiệm so sánh giữa các giao thức (SCTP vs UDP/TCP) cũng đặt ra cho các nhà tư vấn một sự cân nhắc khi lựa chọn giao thức trên hệ thống

1.6 Cấu trúc của luận văn

Nội dung đề tài này được trình bày thành bốn chương:

Chương 1: Tổng quan

Giới thiệu và đưa ra những ưu điểm mà hội nghị truyền hình đem lại cho ngành y tế Từ đó giới thiệu hệ thống hội nghị truyền hình đã và đang được các nước trong khu vực sử dụng Đồng thời nêu ra những ưu – nhược điểm còn tồn tại từ hệ thống này khi áp dụng vào hệ tấng mạng ở nước ta Từ đó nêu ra mục tiêu của đề tài và ý nghĩa khoa học mà đề tài đem lại

Chương 2: Cơ sở lý thuyết

Chương này sẽ tập trung vào việc tìm hiểu giao thức SCTP, đồng thời so sánh các đặc tính – dịch vụ cơ bản của giao thức SCTP với giao thức UDP/TCP trên phương diện lý thuyết và nêu lên được những ưu điểm thực sự của giao thức SCTP so với giao thức TCP/UDP

Chương 3: Phân tích – so sánh đánh giá giao thức và so sánh hệ thống DVTS

 Tập trung xây dựng các mô phỏng để có thể so sánh đánh giá các đặc tính cũng như truyền/nhận của giao thức SCTP với giao thức UDP/TCP

 So sánh việc sử dụng hệ thống DVTS cải tiến với hệ thống DVTS truyền thống

Chương 4: Tổng Kết Và Kiến Nghị Trong Tương Lai

Phần này đưa ra những kết luận đúc kết được trong quá trình thực hiện đề tài và nêu ra định hướng phát triển hệ thống sau này Đồng thời, phần này nêu tóm tắt các kết quả đạt được và những hạn chế của đề tài

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT

2.1 Giao Thức SCTP

2.1.1 Lịch sử

SCTP ra đời vào năm 1998 sau khi nhóm làm việc của IETF được triệu tập để thiết kế một cơ chế giao vận tin cậy để truyền báo hiệu điều khiển cuộc gọi trên mạng Internet Kết quả là Sigtran ra đời cho phép truyền các bản tin SS7 trên mạng IP Vấn đề chính mà Sigtran cần giải quyết chính mà TCP chưa đáp ứng đó là:

 Head of line blocking: vấn đề xảy ra khi gửi các bản tin độc lập trên

kết nối TCP đã được thiết lập, thì các bản tin được nhận sau bị trễ và lưu trong bộ đệm của tầng giao vận của phía nhận, tới khi các bản tin trước đó bị mất được truyền lại và tới đích Mà ở đó, các bản tin sau thường thiết lập các cuộc gọi độc lập Như vậy, trễ ở các bản tin sau là nguyên nhân sinh ra Timeout trong điều khiển cuộc gọi, gây ra lỗi không mong muốn trong quá trình điều khiển cuộc gọi

 Multihoming: khi một máy trạm với nhiều đường/cách thức truy cập

Internet với mục đích dự phòng, không muốn đợi để định tuyến trong khi mạng bị tắc nghẽn để truyền tin với trạm ngang hàng với nó Với báo hiệu cuộc gọi, độ trễ này là không thể chấp nhận được khi mà ta có nhiều đường truyền (Moderm, Card mạng, Wireless) Lí do là TCP chỉ gắn một đường kết nối giữa hai đầu cuối nên sẽ không thể giải quyết được vấn đề này

Cân nhắc những vấn đề này, Sigtran được thiết kế như là một giao thức tầng giao vận mới cho phép mang báo hiệu cuộc gọi trên mạng IP Đồng thời, IETF mở rộng phạm vi của nhóm thiết kế từ một nhóm nhỏ đến một nhóm

chuyên trách để thiết kế một giao thức giao vận có thể phục vụ nhiều mục đích và hoạt động tốt với nhiều ứng dụng

Năm 2000, SCTP được chuẩn hoá theo IETF trong tài liệu RFC2960 và được cập nhật trong tài liệu RFC4960 Giao thức SCTP là giao thức tin nhắn theo định hướng tin cậy để truyền thông điệp giữa các máy tính trong cùng mạng IP

2.1.2/ Tầng hoạt động của giao thức SCTP

Giao thức SCTP hoạt động tại tầng giao vận cùng với các giao thức UDP

và TCP, được mô tả qua hình vẽ sau [11]:

Upper layer applications

TCP, UDP, SCTP

IP Link Layer Physical Layer Bảng 2.1 – Tầng hoạt động của giao thức SCTP

2.1.3/ Kiến trúc tổng quan của giao thức SCTP

Được mô tả thông qua một Association (hiệp hội) SCTP [3] như hình 2.1

Hình 2.1 – Mô hình kiến trúc giao thức SCTP Trong đó [13]:

 Association Startup and Takedown: một Association được khởi

xướng bởi một yêu cầu từ người sử dụng SCTP

 Sequenced Delivery within Streams: Thuật ngữ "dòng" được sử dụng

trong SCTP để chỉ một chuỗi các thông điệp người dùng sẽ được gửi đến các lớp giao thức phía trên theo thứ tự với các thông điệp khác trong cùng một dòng Điều này là trái ngược với việc sử dụng giao thức TCP, ở đó dùng để chỉ một chuỗi các byte (trong luận văn này một byte được coi là tám bit) Người sử dụng SCTP có thể xác định số dòng được hỗ trợ bởi Association tại thời gian khởi động Association Con

số này dùng đàm phán với Endpoint ở xa Thông điệp người sử dụng có liên quan đến số luồng (SEND, Receive primitives (nguyên thủy)) Trong đó, SCTP thiết lập một số thứ tự cho mỗi Stream được thông qua

nó trước khi đến người sử dụng SCTP Ở phía bên nhận, SCTP đảm bảo rằng thông điệp được gửi đến người dùng SCTP theo thứ tự trong một stream cho trước Tuy nhiên, khi một trong những stream có thể bị chặn để chờ thông điệp người dùng trong của trình tự tiếp theo, việc phân phối từ những stream khác vẫn có thể tiến hành SCTP cung cấp một cơ chế để bỏ qua trình tự/thứ tự phân phối Thông điệp người dùng được gửi bằng cách sử dụng cơ chế này được giao cho người sử dụng

SCTP ngay sau khi chúng nhận được

 User Data Fragmentation: Khi cần thiết, những fragments SCTP của

thông điệp người dùng đảm bảo rằng gói SCTP (Packet SCTP) đi qua các lớp bên dưới sẽ phù hợp với đường dẫn MTU Bên đầu nhận, các fragments được lắp ráp lại thành những thông điệp hoàn chỉnh trước

khi được đưa đến người sử dụng SCTP

 TCP-Friendly Congestion Control: Acknowledgement và chức năng

tránh tắc nghẽn thì chịu trách nhiệm gửi lại gói tin khi hết thời gian mà không nhận được Acknowledgement Việc gửi lại gói tin có điều kiện bởi thủ tục tránh tắc nghẽn sử dụng giống như trong TCP

 Chunk Bundling: Gói tin SCTP khi chuyển giao cho các lớp phía dưới

gồm một tiêu để phổ biến (common header) bằng một hay nhiều khối Mỗi Chunk có thể chứa dữ liệu người dùnh hoặc thông tin điều khiển SCTP Người sử dụng SCTP có thể chọn để yêu cầu Bundling nhiều hơn một thông điệp trong một gói SCTP Hàm chunk bundling của SCTP chịu trách nhiệm gửi đầy đủ gói tin SCTP và được loại bỏ vào

cuối lúc nhận

 Packet Validation: một trường xác minh bắt buộc có chiều dài là 32

bits bao gồm trong tiêu đề phổ biến trong SCTP Giá trị thẻ xác minh được chọn bởi mỗi một thiết bị cuối của một Asscociation kể cả

Association startup Các gói tin nhận được mà không có thẻ xác minh

sẽ bị loại bỏ, như là một cách bảo vệ chống lại các cuộc tấn công giả

mù (blind masquerade) và chống lại gói tin SCTP cũ từ các Association trước đó Thuật toán Adler32 sẽ thiết lập trên mỗi gói tin người gửi để cung cấp thêm cơ chế chống hỏng dữ liệu trên mạng Người nhận một gói tin SCTP với kiểm tra Adler-32 không hợp lệ sẽ âm thầm loại bỏ

gói tin đó

 Path Management: Chức năng quản lý đường dẫn SCTP chọn địa chỉ

vận chuyển đích cho mỗi gói tin gửi đi SCTP dựa trên hướng dẫn của người dùng SCTP và cảm nhận trạng thái hiện tại có thể đủ điều kiện tới đích đã thiết lập Chức năng quản lý đường màn hình thông quan những heartbeats khi mà lưu lượng truy cập gói tin là không đủ cung cấp thông tin và khuyên người dùng SCTP khi có bất cứ thay đổi nào liên quan đến địa chỉ truyền vận tại đầu cuối Chức năng quản lý đường dẫn cũng chịu trách nhiệm cho việc báo cáo đến các địa chỉ truyền vận vùng đủ điều kiện để những đầu cuối phía xa bao gồm cả Association startup và báo cáo địa chỉ truyền vận trở lại từ những đầu cuối phía xa đến những người dùng SCTP

o Tại Associationd Startup, một đường dẫn chính được xác định cho mỗi điểm cuối (End – point) và sử dụng cho việc gửi các gói tin SCTP

o Tại nơi nhận, việc quản lý đường dẫn sẽ có trách nhiệm xác minh

sự tồn tại hợp lệ của một SCTP Asssociation bên trong gói SCTP được thông qua trước khi xử lý các tiến trình khác

o Chú ý: quản lý đường dẫn và xác nhận gói tin được thực hiện cùng một lúc Do đó, mặc dù mô tả một cách riêng biệt như ở

trên nhưng thực tế nó không thể thực hiện thành các mục riêng biệt

 SCTP Association [3]: Một SCTP Association thì được định nghĩa bởi

2 SCTP endpoint (điểm đầu – điểm cuối) Mỗi SCTP endpoint được xác định bởi một địa chỉ IP và 1 cổng (port) Điều đó có nghĩa là cùng 1 địa chỉ IP có thể định nghĩa nhiều Association khác nhau miễn là số cổng (SCTP port number) là khác nhau Ví dụ đối với SGSN Alcatel-Lucent thì họ thường dùng địa chỉ IP khác nhau để phân biệt các Association, còn SGSN Huawei thì họ lại phân biệt Association bằng cách chọn cổng SCTP khác nhau Tổ hợp địa chỉ IP@ + Port (transport address, địa chỉ vận tải) là duy nhất cho mỗi SCTP Endpoint

(@IP 1, port A) ———– Association ————- (@IP 2, port B)

Trong trường hợp multi-homing thì SCTP endpoint được định nghĩa bởi nhiều địa chỉ IP+port, tức nhiều địa chỉ vận tải

(@IP 1, port A) — Association —([@IP 2, port B][@IP 3, port B])

Như vậy, Association hình phía trên có 2 đường định tuyến khác nhau để hướng về SCTP Endpoint 2 Người ta gọi đó là path Tức một association có thể có nhiều path Khi một path bị hỏng (ví dụ hư router) thì association vẫn còn được giữ nguyên, không bị đứt

Về việc khai báo cổng SCTP ở 2 đầu thiết bị, cổng SCTP ở 2 đầu không nhất thiết phải giống nhau Thông thường người ta hay khai báo giống nhau cho dễ, nhưng cũng có thể hoàn toàn khai báo khác nhau Quan trọng là ở đầu A phải biết là đầu B dùng port nào (để gửi message

SCTP cho đúng) và ngược lại ở đầu B phải khai báo port mà đầu A dùng để lắng nghe bản tin SCTP

Trong 1 SCTP Association thì hai đầu đều gửi một cách đều đặn các thông điệp SCTP HEARTBEAT (nhịp tim) về đầu bên kia và chờ đầu bên kia trả lời lại bằng HEARTBEAT ACK (đã nhận được HEARTBEAT) Nhờ vào đó mà các SCTP Endpoint kiểm tra được là Association còn sống hay đã chết, hoặc một path của Association còn sống hay đã chết

 SCTP Endpoint: là điểm gửi/nhận gói tin SCTP tại tầng vật lý Trên

một Host đa đích, một SCTP Endpoint thì đại diện cho các điểm ngang hàng với nó như là một tập các địa chỉ chuyển vận đích đủ điều kiện mà các gói tin SCTP có thể gửi và thiết lập một địa chì chuyển vận nguồn

mà gói tin SCTP có thể nhận Tất cả các địa chỉ chuyển vận được sử

dụng bởi một SCTP Endpoint phải có cùng số Cổng, nhưng có thể

dùng nhiều địa chỉ IP Một địa chỉ chuyển vận đã xác định bởi một SCTP Endpoint không thể được sử dụng bởi một SCTP Endpoint khác

 Stream: Một kênh logic đơn hướng được thành lập từ một SCTP

Endpoint này đến SCTP Endpoint khác trong cùng hiệp hội, trong đó tất cả các thông điệp người dùng được phân phối theo thứ tự ngoại trừ những dịch vụ không được cung cấp theo thứ tự

2.1.4/ Định dạng gói tin SCTP [17]

Hình 2.2 – Định dạng một gói tin SCTP SCTP truyền dữ liệu theo dạng các thông báo (messages), mỗi thông báo chứa một hoặc nhiều gói tin Một gói tin SCTP được chia thành nhiều chunk (đoạn) dữ liệu, mỗi đoạn có thể thuộc về một luồng logic khác nhau trong phạm vi liên kết Trong hình 2.2 trình bày cấu trúc một gói tin SCTP Các phân đoạn dữ liệu của các chunk có thể có kích thước khác nhau, tuy nhiên tổng kích thước gói tin SCTP nhỏ hơn hoặc bằng MTU liên kết Một số kiểu

chunk được định nghĩa trước theo RFC SCTP, bao gồm các chunk dành cho khởi tạo liên kết, tải dữ liệu, lựa chọn báo nhận SACK,… Những Chunk này thì được chia thành các phần: ConTrol Chunks (Bó điều khiển) và Data Chunks (Bó dữ liệu) Thông tin về dữ liệu thì được chuyển tiếp bằng data Chunks (màu xanh lá) và những thông tin điều khiển được chuyển bằng Control Chunk (màu đỏ)

2.1.4.1/ Trường Common Header trong SCTP (màu xanh dương)

SCTP common header chiếm 12 bytes đầu tiên (từ bit 0 – 95), phần có màu xanh dương trong hình 2.2 và cung cấp cho ta các thông tin:

 Xác định gói tin SCTP đó thuộc về Association nào và xác minh toàn vẹn dữ liệu của tầng vận chuyển

 Một chi tiết khá thú vị là việc xác minh Association không chỉ sử dụng cổng (port) nguồn và đích mà còn sử dụng cả địa chỉ IP

 Các SCTP common header cũng bao gồm một thẻ xác minh để phân biệt giữa hai trường hợp Association khác nhau và bảo vệ chống lại các cuộc “tấn công mù” bằng cách đặt dữ liệu vào một Association đã tồn tại

 Chi tiết các thành phần của trường Common Header:

2.1.4.1.a/ Cổng nguồn (Source Port Number): 16 bits (unsigned integer) [13]

Đây là số cổng người gửi SCTP Nó có thể được sử dụng bởi người nhận kết hợp với địa chỉ IP nguồn, cổng đích SCTP và có thể là địa chỉ IP đích để xác định các Association mà gói tin này thuộc về

2.1.4.1.b/ Destination Port Number (Cổng đích): 16 bits (unsigned

integer) [13]

Đây là số cổng SCTP xác định đích của gói tin Các máy chủ tiếp nhận sẽ

sử dụng cổng này số để truyền nhiều gói tin SCTP đến đúng thiết bị đầu cuối / ứng dụng

2.1.4.1.c/ Verification Tag (thẻ xác minh): 32 bits (unsigned integer) [13]

Người nhận được gói tin này sẽ sử dụng “thẻ xác minh” để kiểm tra người gửi gói tin SCTP Trên việc chuyển/nhận, giá trị “thẻ xác minh” này phải được thiết lập để giá trị của Tag Bắt đầu nhận được từ thiết bị đầu cuối ngang hàng trong quá trình khởi tạo liên kết, với các trường hợp ngoại lệ sau đây:

 Một gói tin lưu trữ một Chunk init phải có “thẻ xác minh” là 0

 Một gói có chứa một đoạn SHUTDOWN - COMPLETE với các thiết lập T-bit phải có “thẻ xác minh” sao chép từ các gói tin với các đoạn SHUTDOWN - ACK

 Một gói có chứa một đoạn hủy bỏ có thể có thẻ xác minh được sao chép từ các gói tin được hủy bỏ bởi người gửi

 Một đoạn init phải là đoạn duy nhất trong các gói tin SCTP mang nó

2.1.4.1.d/ Checksum: 32 bits (unsigned integer) [13]

Đây là trường lưu trữ việc kiểm tra gói tin SCTP Khi gửi một gói tin SCTP, các thiết bị đầu cuối phải tăng cường tính toàn vẹn dữ liệu truyền tải bao gồm cả các Adler -32 giá trị tổng kiểm tra tính trên gói tin, như mô tả dưới đây Sau khi gói tin được xây dựng (có chứa tiêu đề SCTP phổ biến và kiểm soát một hoặc nhiều hơn hoặc dữ liệu khối ), Việc truyền nhận sẽ:

 Điền vào các “thẻ xác minh” thích hợp trong tiêu đề phổ biến SCTP và khởi tạo các lĩnh vực kiểm tra = 0

 Tính toán các Adler-32 checksum của toàn bộ gói, bao gồm cả tiêu đề phổ biến SCTP và tất cả các khối

 Đặt giá trị kết quả vào trường checksum trong tiêu đề chung, và để phần còn lại của các bit không thay đổi

2.1.4.2 Mô tả Chunk SCTP [13]

Các Chunk, tạo nên thành phần còn lại của gói tin – hình 2.2 Trong hình 2.2, Chunk đầu tiên thì có màu xanh lá, và khối chunk cuối cùng được đánh dấu màu đỏ Cũng trong minh hoạ trên, mỗi Chunk thì được định dạng với 1 trường Chunk Type, 1 trường Flag, 1 trường Length và 1 trường Value Trong gói tin SCTP, mỗi chunk có định dạng giống nhau, nhưng trên mỗi chunk nội dung có thể khác nhau Mỗi Chunk hoặc phải kết thúc hoặc được thêm đến 32 bits cho phần kế tiếp

2.1.4.2.a Chunk type:

8 Byte (256 bit) của trường Chunk Type thì đại diện cho các loại Chunk RFC4960 đã định nghĩa một danh sách Chunk và hiện nay có 15 loại đã được xác định, trong đó có 14 chunk điều khiển và một Chunk dữ liệu (xem bảng 2.2)

0, thì chiều dải của trường sẽ được thiết lập là 4 Khi đó trường Chunk length

sẽ không tính thêm bất kỳ Chunk nào khác

2.1.4.2.c Chunk Length: [13]

Là một số nguyên 16bit kiểu Unsigned và lưu trữ chiều dài của trunk trong byte Trường này không bao gồm độ dài của bộ đệm (Padding)

2.1.4.2.d Chunk value: [13]

Đây là một trường có độ dài thay đổi chứa dữ liệu sẽ được truyền đi Kiểu

dữ liệu mà nó mang phụ thuộc vào loại Chunk

2 INIT ACK initiation acknowledgement

4 HEARTBEAT Heartbeat request

5 HEARTBEAT ACK Heartbeat acknowledgement

8 SHUTDOWN ACK Shutdown acknowledgement

10 COOKIE ECHO State cookie

11 COOKIE ACK Cookie acknowledgement

12 ECNE Explicit congestion notification echo

(reserved)

13 CWR Congestion window reduced (reserved)

COMPLETE shutdown complete

63 IETF-defined chunk extensions

Bảng 2.2 - Các loại trong Chunk Type (RFC4960)

2.2.3 Mô tả các Chunk trong SCTP [13] [19]

Tùy thuộc vào giá trị của các loại Chunk, chúng ta có thể miêu tả chúng như sau:

2.2.3.a Chunk Dữ liệu (Data Chunk)

Chunk này mang dữ liệu người dùng cùng với thông tin như TSN (truyền trình tự số), SSN (nhiều dòng có thể được truyền như là một phần của một Association duy nhất) vv Trường này được mô tả tương tự SN (sequence) trong TCP, ngoại trừ việc nó đã chuyển đến những Chunk từ phần tiêu đề

2.2.3.b INIT Chunk

Chunk này tương ứng với segment SYN trong TCP trong việc khởi tạo các phân đoạn Nội dung chứa trong thẻ khởi tạo, được dùng như một thẻ xác minh trong tất cả các segment khác được gửi bởi người nhận INIT Số lượng các dòng inbound và outbound trong một Association cũng được trao đổi trong việc gửi các Chunk này Đoạn Chunk INIT cũng chứa window size nhận được giới thiệu cùng với một hoặc nhiều IP sẽ được sử dụng trong các Association hỗ trợ Multihoming ISN (Initial Sequence Number) cũng là một thành phần của chunk INIT

2.2.3.c INIT ACK Chunk

Chunk này dùng để phản hồi Chunk INIT Chunk này định dạng tương tự như Chunk INIT ngoại trừ việc nó chứa tình trạng Cookie, được tạo bởi