Một số giải pháp nâng cao chất lượng dịch vụ thoại qua mạng IP

Một số giải pháp nâng cao chất lượng dịch vụ thoại qua mạng IP Một số giải pháp nâng cao chất lượng dịch vụ thoại qua mạng IP Một số giải pháp nâng cao chất lượng dịch vụ thoại qua mạng IP luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

Tr-ờng đại học bách khoa hà nội

-

phạm lê việt

một số giải pháp nâng cao chất l-ợng dịch vụ

danh môc c¸c b¶ng

Trang

Danh mục các hình vẽ, đồ thị

Trang

ch-¬ng 1 giao thøc internet (ip)

1.1 Giao thøc Internet

1.1.1 S¬ l-îc vÒ hä giao thøc TCP/IP

TCP/IP lµ mét hä giao thøc cung cÊp ph-¬ng tiÖn truyÒn th«ng liªn m¹ng H×nh 1.1 biÓu diÔn kiÕn tróc cña hä giao thøc TCP/IP cã so s¸nh víi m« h×nh chuÈn OSI

H×nh 1.1: KiÕn tróc hä giao thøc TCP/IP

FTP: File Transfer Protocol

SMTP: Simple Mail Transfer Protocol

DNS: Domain Name System

SNMP: Simple Network Management Protocol

TCP: Transmission Control Protocol

UDP: User Datagram Protocol

ICMP: Internet Control Message Protocol

FDDI: Fiber Distributed Data Interface

M« h×nh OSI M« h×nh kiÕn tróc TCP/IP

1.1.2 Giao thức IPv4

Giao thức IPv4 đ-ợc mô tả chi tiết trong [Post81b] Giao thức IP đ-ợc sử dụng để kết nối giữa các mạng truyền số liệu Vai trò của IP t-ơng tự nh- vai trò của giao thức tầng mạng trong mô hình chuẩn OSI Đây là một giao thức kiểu không liên kết theo đó việc chuyển các khối dữ liệu gọi là datagram từ nguồn tới đích không cần phải thiết lập tr-ớc liên kết Khuôn dạng datagram của IPv4 đ-ợc biểu diễn trong hình 1.2

0 3 4 7 8 15 16 31

Source Address Destination Address Options + Padding

Data

Hình 1.2: Định dạng gói IPv4

Phần tiếp đầu IP chứa các tr-ờng sau:

bit Độ dài tối thiểu là 5 từ

➢ Type of Service: Chứa các tham số về dịch vụ, có dạng cụ thể trên hình 1.3

Hình 1.3: Cấu trúc tr-ờng Type of Service trong tiếp đầu gói IPv4

Precedence (3 bit): Tham số chỉ thị mức -u tiên gửi datagram

➢ Total Length (16 bit): Chỉ độ dài của toàn bộ datagram, kể các phần tiếp đầu, tính theo byte

➢ Identification (16 bit): Giá trị do bên gửi ấn định để bên thu nhận dạng, phục vụ cho việc tái hợp các phân đoạn của datagram

➢ Flags (3 bit):

Hình 1.4: Cấu trúc tr-ờng Flags trong tiếp đầu gói IPv4

DF: 0 – Cho phép chia nhỏ datagram, 1 - Không cho phép chia nhỏ MF: 0 - Phân đoạn cuối, 1 - Vẫn còn phân đoạn tiếp theo

➢ Time to live (8 bit): Chỉ thời gian tồn tại tối đa trên mạng của datagram tính theo giây Khi giá trị này bằng 0 thì gói bị huỷ

➢ Protocol (8 bit): Chỉ thị giao thức của tầng liền kề phía trên

Ví dụ 6 t-ơng ứng với giao thức TCP, 17 t-ơng ứng với giao thức UDP

➢ Checksum (16 bit): Mã kiểm soát lỗi phần tiếp đầu datagram

➢ Source Address (32 bit): Địa chỉ IP trạm nguồn

➢ Destination Address (32 bit): Địa chỉ IP trạm đích

➢ Options (độ dài thay đổi): Phần này có thể xuất hiện hoặc không xuất hiện trong datagram và do bên gửi quyết định có sử dụng hay không

➢ Padding (độ dài thay đổi): Dữ liệu đệm, đ-ợc dùng để độ dài phần tiếp đầu gói luôn là bội số của 32 bit

➢ Data (độ dài thay đổi): Dữ liệu, có độ dài là bội số của byte

1.1.3 Giao thức IPv6

Giao thức Internet version 6 - IPv6 [Deer98] là phiên bản mới của giao thức Internet thiết kế cho mạng Internet thế hệ mới Nhiều chức năng trong IPv4 vẫn tiếp tục đ-ợc duy trì trong IPv6 Động lực thúc đẩy việc thiết kế IPv6 là sự phát triển bùng nổ của mạng Internet làm cho không gian địa chỉ mạng bị cạn kiệt IPv6 mở rộng khả năng

đặt địa chỉ và định tuyến, mở rộng định tuyến nhiều đích (multicast routing) bằng cách bổ sung thêm tr-ờng Scope vào các địa chỉ multicast, đơn giản hoá định dạng tiếp đầu datagram, hỗ trợ nâng cao các tính năng lựa chọn, chất l-ợng dịch vụ, nhận thực và an ninh Khuôn dạng tiếp đầu datagram của IPv6 đ-ợc trình bày trong hình 1.5

0 3 4 7 8 15 16 31

Source Address

Destination Address

Hình 1.5: Định dạng tiếp đầu gói IPv6

➢ VER (4 bit): Internet Protocol version (=6)

➢ Traffic Class (8 bit): Giá trị do bên gửi đặt để chỉ thị mức độ -u tiên gửi gói mà mình mong muốn

➢ Flow Label (24 bit): Nhãn luồng, có thể đ-ợc bên gửi sử dụng để đánh dấu các gói mà nó yêu cầu bộ định tuyến IPv6 xử lý đặc biệt

➢ Payload Length (16 bit): Chiều dài tải tin, tính theo byte

➢ Next Header (8 bit): Vai trò giống nh- tr-ờng Protocol trong IPv4

➢ Hop Limit (8 bit): Giá trị này bị trừ đi 1 tại mỗi nút mạng mà nó qua Gói bị huỷ khi giá trị này bằng 0

➢ Source Address (128 bit): Địa chỉ IP trạm nguồn

➢ Destination Address (128 bit): Địa chỉ IP trạm đích

1.2 Giao thức TCP, UDP

1.2.1 Giao thức TCP

Giao thức IP cung cấp dịch vụ cố gắng tối đa, không đảm bảo tất cả các datagram

đều đ-ợc truyền tới đích Nếu trên một nút mạng xuất hiện tắc nghẽn thì các gói nằm trong hàng đợi có thể bị loại bỏ; khi có lỗi đ-ờng truyền thì gói có thể bị mất Các gói cũng có thể đến đích không theo thứ tự ban đầu TCP [Post81a] đã đ-ợc thiết kế để giải quyết những dạng lỗi nh- vậy Định dạng tiếp đầu TCP đ-ợc trình bày tại hình 1.6 trang tiếp theo

➢ Source Port (16 bit): Số hiệu cổng TCP nguồn

➢ Destination Port (16 bit): Số hiệu cổng TCP đích

➢ Sequence Number (32 bit): Số thứ tự của byte dữ liệu đầu tiên của segment ngoại trừ tr-ờng hợp bit SYN đ-ợc thiết lập Nếu bit SYN đ-ợc thiết lập thì giá trị này này là số thứ tự khởi đầu (ISN) và byte dữ liệu đầu tiên có số thứ tự là là ISN+1

➢ Acknowledgement Number (32 bit): Nếu bit điều khiển ACK đ-ợc thiết lập thì tr-ờng này chứa giá trị số thứ tự segment tiếp theo mà trạm nguồn đang chờ để nhận với ngụ ý là các segment tr-ớc đó nhận đ-ợc tốt Khi kết nối đ-ợc thiết lập thì nó luôn đ-ợc gửi đi

➢ Data Offset (4 bit): Chỉ thị số l-ợng từ 32 bit trong phần tiếp đầu TCP, nhờ đó xác định đ-ợc phần dữ liệu bắt đầu từ đâu

0 3 4 7 8 15 16 31

Sequence Number Acknowledgement Number

Offset Reserved

UR

G

AC

K

PS

H

RS

T

SY

N

FI

Hình 1.6: Định dạng tiếp đầu đơn vị dữ liệu TCP

➢ Reserved (6 bit): Dự trữ cho nhu cầu t-ơng lai

➢ Các bit điều khiển:

URG: Đặt tr-ờng Urgent Pointer

ACK: Đặt tr-ờng Acknowledgment

➢ Window (6 bit): Số byte dữ liệu, bắt đầu là byte đ-ợc chỉ thị trong tr-ờng Acknowledgement mà bên gửi segment này sẵn sàng chấp nhận

➢ Checksum (16 bit): Mã kiểm soát lỗi cho toàn bộ segment

➢ Urgent Pointer (16 bit): Trỏ tới số thứ tự của octet đi ngay sau dữ liệu khẩn, cho bên nhận biết đ-ợc độ dài của dữ liệu khẩn Vùng này chỉ có giá trị khi bit URG

Kết nối TCP đ-ợc thực hiện giữa hai cổng Cổng TCP đ-ợc xác định bởi địa chỉ IP

và số hiệu cổng 16 bit nhận dạng ứng dụng của trạm tạo thành một socket duy nhất trong mạng

TCP là một giao thức định h-ớng kết nối, dữ liệu chỉ đ-ợc trao đổi sau khi kết nối giữa hai cổng đã đ-ợc thiết lập xong Khi không còn nhu cầu truyền dữ liệu nữa thì liên kết đ-ợc giải phóng để trả lại tài nguyên cho mạng

Do yêu cầu truyền lại gói thoại qua mạng IP (VoIP) th-ờng là không cần thiết do yêu cầu thời gian thực nên TCP chủ yếu đ-ợc sử dụng trong giai đoạn trao đổi báo hiệu thiết lập cuộc gọi

1.2.2 Giao thức UDP

UDP (User Datagram Protocol) [Post80] là một giao thức tầng truyền tải, thuộc loại

"không liên kết" sử dụng theo yêu cầu của ứng dụng Khác với TCP, UDP không có các chức năng thiết lập và giải phóng kết nối T-ơng tự nh- IP, nó cũng không cung cấp các cơ chế xác nhận đã nhận đ-ợc dữ liệu, không sắp xếp lại các datagram nhận

đ-ợc Điều này có thể dẫn tới việc mất, trùng hoặc đảo lộn dữ liệu mà không hề có thông báo cho ng-ời gửi biết UDP vì vậy là một giao thức không an toàn

UDP có xu thế hoạt động nhanh hơn so với TCP Nó th-ờng đ-ợc dùng cho các ứng dụng không đòi hỏi độ tin cậy cao trong tầng truyền tải nh-ng lại yêu cầu trễ nhỏ Với những đặc điểm này UDP có thể đ-ợc sử dụng để truyền tải tín hiệu thoại qua mạng IP

Hình 1.7 là khuôn dạng của UDP datagram, rất đơn giản nếu so với khuôn dạng của TCP datagram

0 3 4 7 8 15 16 31

Data

Hình 1.7: Định dạng tiếp đầu đơn vị dữ liệu UDP

1.3 Giao thức điều khiển và truyền tải thời gian thực

tự trong RTP cho phép bên nhận sắp xếp lại gói theo thứ tự ban đầu

Mục đích chính ban đầu khi thiết kế RTP là để thoả mãn nhu cầu truyền các phiên hội nghị đa ph-ơng tiện nh-ng RTP không chỉ giới hạn ở ứng dụng trên Nó có thể

đ-ợc sử dụng cho các ứng dụng khác nh- l-u trữ dữ liệu liên tục, đo đạc và điều khiển

Khái niệm RTP gồm hai phần không thể tách rời là: (1) Giao thức truyền tải thời gian thực (RTP) thực hiện truyền dữ liệu có đặc tính thời gian thực và (2) Giao thức

điều khiển RTP (RTCP), giám sát chất l-ợng dịch vụ và truyền thông tin về các đối t-ợng tham gia trong một phiên truyền hội nghị đang diễn ra

RTP có tính mềm dẻo để nhờ đó cung cấp thông tin theo yêu cầu của các ứng dụng

cụ thể và th-ờng đ-ợc tích hợp vào phần ứng dụng hơn là tách riêng thành một lớp

Không nh- các giao thức truyền thống khác trong đó việc bổ sung các chức năng

đ-ợc thực hiện bằng cách làm cho giao thức tổng quát hơn hoặc bổ sung thêm phần tuỳ chọn, RTP cho phép thay đổi hay bổ sung vào tiếp đầu khi thấy cần thiết Ngoài

đặc tả kỹ thuật về RTP thì để tạo ra một đặc tả kỹ thuật trọn vẹn cho từng ứng dụng

cụ thể cần có các đặc tả kỹ thuật về định dạng tải và hồ sơ tải Định dạng tải xác

định cách thức tải (ví dụ là audio, video) đ-ợc truyền đi trong RTP Hồ sơ tải là một tập hợp các loại mã và ánh xạ của chúng lên tập hợp các loại định dạng tải

RTP th-ờng chạy phía trên giao thức UDP để sử dụng số hiệu cổng và mã sửa lỗi

Nó cũng có thể đ-ợc xem là một lớp con trong lớp truyền tải Trong phiên truyền RTP mỗi bên tham gia đ-ợc xác định bởi một cặp địa chỉ đích truyền tải gồm địa chỉ

IP kết hợp một cặp cổng cho RTP và RTCP Trong tr-ờng hợp multicast thì địa chỉ này thuộc lớp D và dùng chung cho tất cả các đối t-ợng tham gia Trong phiên truyền đa ph-ơng tiện thì mỗi ph-ơng tiện đ-ợc truyền trên một phiên RTP riêng biệt

1.3.2 Giao thức truyền tải thời gian thực RTP

Cấu trúc tiếp đầu RTP đ-ợc trình bày trong hình 1.8

0 1 2 3 4 5 6 7 8 15 16 31

Timestamp Synchronization Source Indentifier (SSRC)

Contributing Source Identifiers (CSRC)

Hình 1.8: Định dạng tiếp đầu đơn vị dữ liệu RTP

10 octet đầu tiên luôn có mặt trong tất cả các gói RTP Các tr-ờng trong phần tiếp

đầu RTP có ý nghĩa nh- sau:

➢ V (2 bit): Chỉ thị phiên bản RTP Phiên bản hiện tại là 2

➢ P (1 bit): Padding Bit Nếu bit này đ-ợc thiết lập thì nó chỉ ra rằng có một hoặc một vài octet đ-ợc chèn thêm vào cuối của gói sau phần tải tin

➢ X (1 bit): Extension Bit Nếu bit này đ-ợc thiết lập thì sau tiếp đầu cố định là một tiếp đầu mở rộng

➢ CC (4 bit): CSRC count - chứa số l-ợng các nhận dạng nguồn đồng bộ (CSRC) tiếp sau phần tiếp đầu cố định

➢ M (1 bit): Marker - đ-ợc xác định bởi hồ sơ tải Nó đ-ợc sử dụng để cho phép những sự kiện quan trọng nh- biên của khung đ-ợc đánh dấu trong một chuỗi gói

➢ PT (7 bit): Payload Type – Khuôn dạng tải RTP, đ-ợc ứng dụng sử dụng

➢ Sequence Number (16 bit): Số thứ tự Cứ mỗi gói dữ liệu RTP đ-ợc gửi đi thì giá trị này tăng thêm 1 Bên thu có thể sử dụng giá trị này để biết có bị mất gói hay không và sắp xếp lại thứ tự gói

➢ Timestamp (32 bit): Tem thời gian cho ph-ơng tiện cụ thể, chứa thời gian tức thời của octet đầu tiên của gói dữ liệu RTP Tem thời gian này phải đ-ợc lấy từ một đồng hồ có độ chính xác cao để cho phép đồng bộ tính toán thay đổi về trễ

➢ SSRC (32 bit): Nhận dạng nguồn đồng bộ Từ nhận dạng đ-ợc chọn ngẫu nhiên

để không xảy ra tr-ờng hợp hai nguồn trong cùng một phiên có cùng một từ nhận dạng Nhận dạng nguồn đ-ợc sử dụng để nhận dạng vùng thời gian và số hiệu tuần tự duy nhất Mặc dù xác suất để các nguồn sử dụng cùng một từ nhận dạng là rất thấp thì khi thiết kế RTP ng-ời ta vẫn phải chuẩn bị các giải pháp để phát hiện và giải quyết xung đột

➢ CSRC list (0-15 x 32 bit): Danh sách nhận dạng nguồn dữ liệu tham gia vào tải tin Các từ nhận dạng CSRC đ-ợc chèn vào các bộ trộn RTP Bộ trộn RTP đ-ợc

sử dụng để gộp các gói RTP từ các nguồn khác nhau vào một gói RTP Việc chèn các từ nhận dạng cho phép các bộ thu nhận biết chính xác dữ liệu của mình

1.3.3 Giao thức điều khiển truyền tải thời gian thực RTCP

Giao thức điều khiển RTP dựa trên việc truyền các gói điều khiển theo chu kỳ tới tất cả các bên tham gia trong phiên RTP Các gói điều khiển đ-ợc phân phối giống nh- các gói dữ liệu Mỗi gói RTCP là một báo cáo của bên gửi hoặc bên nhận hoặc của cả hai bên chứa số liệu thống kê nh- là số gói đã đ-ợc gửi, số gói bị mất, jitter, trễ

kể từ báo cáo cuối cùng của bên gửi, thời điểm báo cáo cuối cùng của bên gửi để ứng dụng sử dụng RTCP có bốn chức năng riêng biệt:

1) Chức năng chính là cung cấp phản hồi về chất l-ợng phân phối dữ liệu Phản hồi

có thể đ-ợc sử dụng để điều khiển mã hoá thích nghi hay chẩn đoán lỗi phân phối Chức năng phản hồi đ-ợc thực hiện thông qua các báo cáo của bên gửi và bên nhận 2) Cập nhật các thành viên tham gia phiên truyền RTCP chứa nhận dạng tầng truyền tải của các nguồn RTP và đ-ợc gọi là CNAME Do từ nhận dạng SSRC có thể thay đổi nếu xảy ra xung đột hoặc ch-ơng trình khởi động lại, các bên thu cần CNAME để cập nhật từng thành viên Các bên thu cũng cần CNAME để đồng bộ nhiều dòng dữ liệu từ một thành viên trong một tập hợp các phiên RTP, ví dụ nh-

đồng bộ audio và video

3) Hai chức năng đầu yêu cầu tất cả các thành viên gửi các gói RTCP, vì vậy tốc độ phải đ-ợc kiểm soát để RTP có thể mở rộng lên nhiều thành viên Bằng cách cho mỗi thành viên gửi các gói điều khiển của mình tới tất cả các thành viên khác, mỗi thành viên có thể xác định số l-ợng các thành viên một cách độc lập Số l-ơng này

đ-ợc sử dụng để tính toán tốc độ truyền gói

4) Chức năng thứ t- là một chức năng tuỳ chọn Chức năng này làm nhiệm vụ truyền thông tin tối thiểu điều khiển phiên, ví dụ là nhận dạng thành viên để hiển thị trên giao diện ng-ời sử dụng

CÊu tróc b¸o c¸o bªn göi vµ bªn nhËn ®-îc tr×nh bµy t¹i h×nh 1.9 vµ 1.10

0 1 2 3 4 5 6 7 8 15 16 31

SSRC of sender NTP timestamp, most significant word NTP timestamp, least significant word

RTP timestamp Sender's packet count Sender's octet count SSRC_1 (SSRC of first source)

Extended highest sequence number received

Interarrival Jitter Last SR (LSR) Delay since Last SR (DLSR) SSRC_2 (SSRC of second source)

Profile-specific extensions

H×nh 1.9: B¸o c¸o RTCP cña bªn göi

0 1 2 3 4 5 6 7 8 15 16 31

SSRC of sender SSRC_1 (SSRC of first source)

RTP timestamp Extended highest sequence number received

Interarrival jitter Last SR (LSR) Delay since last SR (DLSR) SSRC_2 (SSRC of second source)

Profile-specific extensions

H×nh 1.10: B¸o c¸o RTCP cña bªn nhËn

ch-ơng 2 chất l-ợng thoại qua mạng IP

2.1 Khái niệm chất l-ợng dịch vụ (QoS)

ITU-T định nghĩa chất l-ợng dịch vụ nh- là một mô hình phân cấp bằng cách cố gắng mô tả các dịch vụ với số l-ợng đầy đủ nhất các tham số chất l-ợng

Chất l-ợng dịch vụ VoIP là một vấn đề rất phức tạp và đặt ra nhiều thách thức Việc cung cấp các chức năng chất l-ợng dịch vụ trên các mạng IP còn nhiều hạn chế Hơn nữa mạng cũng chỉ là một phần của kiến trúc VoIP Chất l-ợng dịch vụ từ điểm

đầu đến điểm cuối là hàm chất l-ợng của tất cả các mắt xích trong dây chuyền thông tin Ng-ời sử dụng dịch vụ VoIP không quan tâm đến những thuật ngữ kỹ thuật, công nghệ hay những tham số xác định chất l-ợng dịch vụ Với ng-ời sử dụng dịch

vụ, chất l-ợng dịch vụ chính là mức độ hài lòng, không phải là một tập hợp các tham

số

Mức độ hài lòng của ng-ời sử dụng dịch vụ phụ thuộc vào chất l-ợng dịch vụ và chất l-ợng dịch vụ lại đ-ợc quyết định bởi các yếu tố sau:

- Hỗ trợ của nhà cung cấp dịch vụ

- Mức độ dễ dàng sử dụng dịch vụ

- Chất l-ợng phục vụ

Chất l-ợng phục vụ phụ thuộc vào chất l-ợng truyền tin và các thành tố liên quan

đến chất l-ợng truyền truyên nh- tài nguyên, ph-ơng tiện dịch vụ, chất l-ợng truyền dẫn và mức độ tin cậy Chất l-ợng truyền tin truyền tin đ-ợc đặc tr-ng bởi thông số mất tin và thời gian trễ Mức độ tin cậy là một tập hợp của các yếu tố nh- mức độ sẵn sàng, mức độ an toàn, khả năng và chất l-ợng bảo d-ỡng

2.2 Các ph-ơng pháp đánh giá chất l-ợng thoại:

Để đánh giá chất l-ợng thoại ng-ời ta dựa trên một trong hai ph-ơng pháp là đánh giá chủ quan và đánh giá khách quan

Ph-ơng pháp đánh giá chủ quan đ-ợc trình bày trong khuyến nghị P.800 của ITU-T Việc đánh giá chất l-ợng đ-ợc dựa trên cảm nhận của con ng-ời Ưu điểm của ph-ơng pháp này là đ-a ra kết quả tổng hợp trực tiếp từ đánh giá chủ quan của con ng-ời Nh-ợc điểm của ph-ơng pháp này là kết quả chỉ là định tính Do mỗi cá nhân

có cảm nhận và đánh giá riêng nên để kết quả có tính chính xác t-ơng đối cần phải lấy ý kiến từ rất nhiều ng-ời Ph-ơng pháp này do vậy tốn nhiều thời gian và chi phí Thông số thông dụng để chỉ thị chất l-ợng thoại là MOS (Mean Opinion Score:

điểm đánh giá trung bình) với thang điểm từ 1 đến 5 đ-ợc trình bày trong bảng 2.1

Bảng 2.1: Bảng đánh giá chất l-ợng tín hiệu thoại

Ph-ơng pháp đánh giá khách quan là ph-ơng pháp sử dụng máy đo để đo các thông

số liên quan đến tín hiệu thoại nh- mức tín hiệu, khoảng ngắt, nhiễu, tiếng vọng, xuyên âm .vv để từ đó suy ra chất l-ợng tín hiệu Khuyến nghị P.561 của ITU-T trình bày chi tiết về ph-ơng pháp đánh giá này

2.3 Các yếu tố ảnh h-ởng đến chất l-ợng VoIP

Để đánh giá QoS một cách khách quan cần sử dụng các tham số đ-ợc l-ợng hóa D-ới đây là một số tham số chính qua đó cho phép đánh giá chất l-ợng VoIP:

Tổng quát có thể chia trễ thành hai loại là trễ cố định và trễ biến đổi Ví dụ, trễ thuật toán là loại trễ cố định, trễ tắc nghẽn đ-ờng truyền là loại trễ biến đổi

Trễ từ điểm đầu đến điểm cuối của cuộc gọi qua mạng IP phụ thuộc vào các yếu tố:

1 Trễ truyền lan

Trễ truyền lan là trễ không thể tránh khỏi do việc truyền tín hiệu điện hay ánh sáng

đều bị giới hạn Với thông tin qua cáp quang thì trễ truyền lan qua nửa vòng trái đất chỉ vào cỡ 100ms nh-ng với thông tin truyền qua vệ tinh địa tĩnh thì trễ có thể lên tới 250 đến 300ms hoặc hơn nữa

Trễ mã hóa là trễ xảy ra trong bộ xử lý mã hóa tín hiệu thoại Trễ mã hóa phụ thuộc vào kích th-ớc khung và thuật toán xử lý Nếu kích th-ớc khung lớn thì bộ xử lý có thể mã hóa tín hiệu hiệu quả hơn nh-ng lại tăng độ trễ Các chuẩn mã hóa thoại hiện nay đều có kích th-ớc khung tiêu chuẩn nh- đã trình bày tại bảng

Trễ do đóng gói xảy ra do phải đóng gói các gói tin thoại tr-ớc khi truyền qua mạng Trễ đóng gói đ-ợc tính theo công thức sau:

Trong đó Tp là kích th-ớc gói (bit) và Rp là tốc độ gói thoại (bit/s)

Ví dụ: Gói 512 bit và tốc độ gói thoại là 8000 bit/s thì trễ gói là 64ms

Mỗi gói tin chứa một hay nhiều khung thoại Với kích th-ớc gói cố định trễ do đóng gói không đổi vì vậy phần tiếp đầu gói càng nhỏ thì càng chứa đ-ợc nhiều khung thoại và nhờ vậy nâng cao đ-ợc hiệu quả sử dụng dung l-ợng đ-ờng truyền Phần tiếp đầu gói có thể đ-ợc nén bằng cách sử dụng CRTP (RTP header Compression) Trễ bộ đệm xử lý hiện t-ợng jitter cũng gây ra trễ Bộ đệm bên gửi chứa các khối dữ liệu thoại tr-ớc khi truyền đi để đảm bảo không mất dữ liệu và bộ đệm thu xử lý hiện t-ợng jitter

Trễ do sắp xếp chỗ xảy ra khi các gói dữ liệu vì một lý do nào đó đến bên nhận không theo đúng thứ tự và bên nhận bắt buộc phải sắp xếp lại để khôi phục tín hiệu ban đầu

Trễ do mạng gây ra bởi nhiều nguyên nhân Quá trình truyền các gói tin thoại qua mạng IP tới bên nhận qua nhiều nút mạng Mỗi nút mạng đều phải xử lý để chuyển gói tới nút tiếp theo và quá trình này gây ra trễ Trễ do mạng chịu ảnh h-ởng bởi các thông số chính sau:

- Trễ xử lý của nút mạng

- Trễ xếp hàng tại nút mạng

Trễ xử lý tại nút mạng là trễ gây ra do khả năng xử lý của bộ chuyển mạch hay bộ

định tuyến và không tham gia nhiều vào trễ tổng Trễ xếp hàng là thời gian mà gói phải đợi ở hàng đợi ra của một nút chuyển mạch định tuyến Trễ xếp hàng là loại trễ biến đổi và phụ thuộc vào l-u l-ợng dữ liệu truyền trên mạng Trễ do mạng có thể

đ-ợc khắc phục bằng cách sử dụng các giao thức đảm bảo chất l-ợng, ví dụ nh- giao thức giữ tr-ớc tài nguyên RSVP trong mô hình kiến trúc dịch vụ tích hợp (Integrated Services Architecture) của IETF Kích th-ớc gói cũng là một yếu tố ảnh h-ởng đến trễ Một số nghiên cứu đã cho thấy có một mối t-ơng quan khá chặt chẽ giữa trễ và chiều dài gói Các gói lớn có xu h-ớng bị trễ nhiều hơn các gói nhỏ

2.3.2 Jitter

Jitter là hiện t-ợng các gói tin đến đích với thời gian trễ khác nhau Tại bên

gửi tin, các gói thoại đ-ợc gửi đi đều đặn nh-ng tại bên nhận các gói lại đến không

đều đặn thậm trí sai thứ tự Các bộ giải mã yêu cầu các gói tin tới đầu vào của chúng một cách đều đặn, vì vậy jitter làm ảnh h-ởng đến việc giải mã và có thể làm giảm chất l-ợng tiếng nói Để khắc phục vấn đề này phía nhận cần có một bộ đệm jitter nằm phía tr-ớc bộ giải mã Bộ này hiệu chỉnh lại khoảng cách giữa các gói tin và làm cho chúng đến bộ giải mã một cách đều đặn Bộ đệm này cũng có thể phải sắp xếp lại các gói tin đến sai thứ tự

Kích th-ớc của bộ đệm phải đ-ợc tính toán hợp lý, đủ lớn để có thể chứa đ-ợc các gói tin tới muộn nhất rồi sắp xếp lại tr-ớc khi đ-a vào bộ giải mã nh-ng cũng phải

đảm bảo không gây trễ quá lớn

2.3.3 Gói đến sai thứ tự

Các gói thoại truyền qua mạng IP có thể đến đích không theo thứ tự ban đầu do các gói tin có thể tới đích theo các đ-ờng khác nhau với độ trễ khác nhau tùy theo tình trạng của tuyến mà gói đi qua Việc các gói đến sai thứ tự nếu không đ-ợc sắp xếp

lại sẽ gây ra hiện t-ợng tiếng nói không đ-ợc khôi phục đúng nh- ban đầu Bộ đệm jitter đ-ợc sử dụng để khắc phục hiện t-ợng trên

2.3.4 Mất gói

Mất gói gây ảnh h-ởng nghiêm trọng đến chất l-ợng tín hiệu thoại Với dữ liệu không cần truyền thời gian thực thì có thể sử dụng giao thức TCP để gửi lại gói bị mất nh-ng với các dịch vụ thời gian thực nh- thoại thì việc truyền lại là không cần thiết nếu nh- trễ quá lớn Các gói đến quá trễ không giúp ích cho việc khôi phục tín hiệu cũng bị loại bỏ

ảnh h-ởng của việc mất gói lên chất l-ợng thoại phụ thuộc vào kích th-ớc gói và vị trí mất gói Các gói chứa tín hiệu phần lặng yên có ảnh h-ởng không nhiều đến chất l-ợng thoại và các gói chứa phần đầu của tiếng nói ảnh h-ởng nghiêm trọng nhất

Hiện t-ợng mất gói đ-ợc đặc tr-ng bởi nhiều tham số khác nhau trong đó thông số

sử dụng nhiều nhất là tỷ lệ mất gói trung bình D-ới đây là một số giải pháp có thể

sử dụng để khắc phục suy giảm chất l-ợng thoại do mất gói [Perk98]

1 Sử dụng cơ chế sửa lỗi tr-ớc FEC Bên thu dựa vào mã sửa sai tr-ớc FEC để khôi phục dữ liệu

chỉ gây ra các khoảng ngắt nhỏ mà ng-ời nghe có thể chấp nhận đ-ợc Tuy nhiên ph-ơng pháp này làm tăng độ trễ do phía thu phải chờ đợi để tiếp nhận

đủ một số l-ợng gói nhất định rồi mới sắp xếp lại đ-ợc khung thoại

3 Truyền lại gói bị mất: Thực hiện trong tr-ờng hợp trễ ngắn

4 Thay thế bằng khoảng lặng: Thay thế các gói bị mất hoặc bị loại bỏ bằng các mẫu có giá trị bằng 0

nghe cảm thấy tín hiệu tự nhiên hơn

7 Nội suy: Dùng thuật toán nội suy để thay thế dạng sóng hay trải tín hiệu cho phủ đến hết cả thời gian bị mất gói.

2.3.5 Tiếng vọng

Tiếng vọng trong điện thoại xảy ra do phối hợp trở kháng trong mạch chuyển đổi hai dây - bốn dây không đ-ợc tối -u Trễ lớn làm cho hiện t-ợng tiếng vọng dễ dàng nhận ra hơn Hiện nay công nghệ chế tạo các thiết bị triệt tiếng vọng đã phát triển cao với các bộ triệt tiếng vọng thích nghi có thể loại trừ hầu nh- hoàn toàn vấn đề tiếng vọng

Ch-ơng 3

hỗ trợ chất l-ợng dịch vụ trong mạng IP

IETF đã đ-a ra hai giải pháp ở tầng mạng để giải quyết vấn đề chất l-ợng dịch vụ Giải pháp thứ nhất sử dụng mô hình dịch vụ tích hợp (Integrated Service hay IntServ) [Brad94], tìm cách giữ tr-ớc tài nguyên của tất cả các bộ định tuyến nằm trên tuyến truyền Việc này có thể thực hiện bằng cách ấn định một hàng đợi riêng cho mỗi luồng dữ liệu

Giải pháp thứ hai là triển khai mô hình dịch vụ phân biệt (Differentiated Services hay DiffServ) [Blak98], phân chia l-u l-ợng thành một số ít loại dịch vụ có mức -u tiên khác nhau trong bộ định tuyến Tất cả các gói dữ liệu đ-ợc đánh dấu và không yêu cầu giao thức báo hiệu

Do chất l-ợng dịch vụ phải có tính chất từ điểm đầu đến điểm cuối nên ng-ời dùng phải có khả năng yêu cầu chất l-ợng từ mạng Điều này có thể thực hiện bằng một trong hai kiểu báo hiệu sau:

1 Đánh dấu gói: Đây cũng chính là thông tin báo hiệu để bộ định tuyến biết phải xử lý gói ra sao Thông tin này đ-ợc chứa trong gói Giao thức sử dụng phải có các tr-ờng đặc biệt dành riêng cho việc đánh dấu Việc sử dụng tài nguyên khác của mạng là không cần thiết

2 Sử dụng giao thức báo hiệu: Cơ chế báo hiệu này cần thêm băng thông Tr-ớc khi gửi dữ liệu thì kết nối phải đ-ợc thiết lập tr-ớc Các kênh báo hiệu

đ-ợc quản lý độc lập với các kênh dữ liệu

DiffServ sử dụng h-ớng tiếp cận thứ nhất Một byte trong phần tiếp đầu gói dữ liệu

IP đ-ợc dành riêng để phân biệt loại dịch vụ yêu cầu IntServ sử dụng cơ chế thứ hai trong đó việc giữ tr-ớc tài nguyên đ-ợc thực hiện thông qua giao thức giữ tr-ớc tài nguyên (RSVP)

3.1 Kiến trúc các dịch vụ tích hợp của IETF

Kiến trúc các dịch vụ tích hợp (IntServ) đ-ợc IETF bắt đầu nghiên cứu vào năm

1994 là cách tiếp cận đầu tiên của IETF để hỗ trợ nhiều dịch vụ của các ứng dụng khác nhau với chất l-ợng chấp nhận đ-ợc dựa trên việc mở rộng cấu trúc IP hiện có [Post91]

Các ứng dụng có khả năng yêu cầu và đ-ợc đáp ứng với một mức chất l-ợng nhất

định từ mạng thay cho dịch vụ "Cố gắng tối đa" IETF định nghĩa hai loại dịch vụ là

"Dịch vụ đảm bảo" (Guaranteed Service) và "Tải đ-ợc kiểm soát" (Controlled load) Dịch vụ "Tải đ-ợc kiểm soát" h-ớng tới việc cung cấp dịch vụ với chất l-ợng của một mạng không tải cho ng-ời sử dụng ngay cả khi mạng bị nghẽn Dịch vụ này còn

đ-ợc biết đến nh- là dịch vụ "tốt hơn cố gắng tối đa" và đ-ợc định nghĩa trong [Wroc97b] Dịch vụ này có thể sử dụng tốt cho các ứng dụng audio và video trực tuyến hay các giao dịch trên nền web

“Dịch vụ đảm bảo" được xác định tại [Shen97a] luôn cung cấp chất lượng dịch vụ như được xác định bởi các tham số chất lượng “Dịch vụ đảm bảo” được dùng cho các dịch vụ t-ơng tác có yêu cầu khắt khe về thời gian thực nh- điện thoại IP và truyền hình hội nghị

Để cung cấp đ-ợc dịch vụ này, một kênh ảo đ-ợc tạo ra cho từng luồng l-u l-ợng tr-ớc khi truyền dữ liệu IETF định nghĩa luồng nh- là một dòng các gói dữ liệu có cùng địa chỉ nguồn, địa chỉ đích và số hiệu cổng Với cơ chế báo hiệu ngoài băng này, IntServ sử dụng giao thức RSVP Dựa trên các yêu cầu của ứng dụng, một hồ sơ chất l-ợng dịch vụ với các tham số l-u l-ợng thích hợp đ-ợc tạo ra và tài nguyên

đ-ợc giữ tr-ớc trên từng nút mạng dọc theo tuyến Do bộ định tuyến có bộ đệm, khả năng xử lý và dung l-ợng đ-ờng truyền kết nối giữa các bộ định tuyến giới hạn nên

có khả năng yêu cầu dịch vụ bị từ chối khi tài nguyên bị dùng hết Điều này trái ng-ợc với ý t-ởng ban đầu về một mạng IP không kết nối, cố gắng tối đa và chia sẻ tài nguyên công bằng

3.1.1 Giao thức giữ tr-ớc tài nguyên (RSVP phiên bản 1)

RSVP đ-ợc nghiên cứu thiết kế từ năm 1993 và phát triển thành một RFC vào năm

1997 RSVP là một giao thức báo hiệu khá mềm dẻo, cho phép bổ sung thêm tài nguyên cho kết nối hiện tại và giải phóng tài nguyên không cần thiết Việc giữ tr-ớc tài nguyên giữa hai mạng có hỗ trợ RSVP đ-ợc thực hiện cho từng chặng và trong những bối cảnh nhất định có khả năng hợp nhất hai hay nhiều luồng dữ liệu trong một yêu cầu giữ tr-ớc tài nguyên

RSVP sử dụng trong IPv4 và IPv6 là các giao thức phi kết nối RSVP đ-ợc thiết kế

để thiết lập các đ-ờng dẫn qua mạng IP và đảm bảo băng thông RSVP không có chức năng định tuyến nh-ng có khả năng sử dụng các tuyến và đ-ờng dẫn hiện có Việc phân bổ tài nguyên đ-ợc thực hiện một chiều cho dù các ứng dụng có thể yêu cầu các kết nối hai chiều Với những yêu cầu thông tin hai chiều, hai luồng RSVP

đ-ợc thiết lập

RSVP là giao thức định h-ớng ng-ời nhận Nó định nghĩa hai loại bản tin (PATH và RESV) trong đó ng-ời nhận luôn là phía phải yêu cầu chất l-ợng dịch vụ cho luồng dữ liệu

RSVP cũng còn đ-ợc gọi là giao thức trạng thái mềm Mỗi nút mạng đều phải tự l-u giữ, cập nhật và duy trì trạng thái của tất cả các luồng dữ liệu Do IP là một giao thức không an toàn nên có thể xảy ra tình trạng một bản tin báo hiệu cho một luồng

cụ thể bị mất Nếu điều này xảy ra thì t-ơng tự nh- hiện t-ợng mạch bị treo, tài nguyên mạng bị lãng phí Để loại bỏ hiện t-ợng này ng-ời ta đã đ-a ra cơ chế "trạng thái mềm" mà theo đó bên gửi và bên nhận gửi các bản tin PATH và RESV theo chu

kỳ Nếu trong một thời gian nhất định mà nút mạng không thấy bản tin nào thì luồng

sẽ bị xoá

Do RSVP sử dụng giao thức IP làm giao thức truyền tải nên các bản tin RSVP có thể

đ-ợc gửi qua các mạng không hỗ trợ RSVP Tuy nhiên khi đó chất l-ợng dịch vụ không đ-ợc đảm bảo khi qua phần mạng không hỗ trợ RSVP

Hình 3.1 biểu diễn mô hình RSVP chuẩn của IETF [Brad97] RSVP là một giao thức thuộc lớp 4 Nó không phải là một giao thức truyền tải mà là giao thức báo hiệu

điều khiển luồng dữ liệu

ứng dụng

Điều khiển

l-u l-ợng

Tiến trình RSVP

Điều khiển chính sách

Điều khiển chấp nhận

Lớp mạng IPLớp liên kết dữ liệu

Điều khiển l-u l-ợng

Điều khiển chính sách

Điều khiển chấp nhận

Xếp chuyển gói

Phân loại gói

Lớp liên kết dữ liệu

Tiến trình RSVP

Dữ

liệu RSVP

Tiến trình định tuyến

Tiến trình RSVP

Xếp chuyển góiPhân loại

gói

Khối Phân loại gói dựa vào nội dung của gói (ví dụ nh- tiếp đầu gói IP, số hiệu cổng) để quyết định gói thuộc về loại chất l-ợng dịch vụ nào

Các gói sau khi phân loại đ-ợc chuyển tới giao diện ra sang khối Xếp chuyển gói

Nó sử dụng các cơ chế quản lý l-u l-ợng để đảm bảo gói đ-ợc chuyển đi theo đúng yêu cầu

Các quy tắc cụ thể cho khối Điều khiển chính sách, Điều khiển chấp nhận và Phân loại gói quyết định đặc điểm kỹ thuật của các dịch vụ t-ơng ứng và không phải là một phần của RSVP Khối Xếp chuyển gói là một thực thể độc lập có nhiệm vụ quản lý, đảm bảo các tham số chất l-ợng dịch vụ

Cấu trúc dữ liệu và các bản tin RSVP

RSVP định nghĩa các cấu trúc dữ liệu sau đây sử dụng cho các đối t-ợng trong các bản tin RSVP:

- TPSEC: Mô tả các thuộc tính dữ liệu do bên gửi truyền đi Nó có thể bao gồm các tham số nh- là tốc độ truyền trung bình, tốc độ cao nhất, kích th-ớc gói lớn nhất và một số tham số khác

- FILTERSPEC: Cấu trúc dữ liệu chứa các địa chỉ (địa chỉ IP và số hiệu cổng) của tất cả các bên gửi đã đ-ợc cho phép trong một phiên

- SENDER TEMPLATE: Chứa một địa chỉ IP của bên gửi và có thể là một vài thông tin bổ sung để nhận dạng chính xác bên gửi

- ADSPEC: Thông tin về đặc tính kỹ thuật đ-ợc chuyển trong bản tin PATH Một ADSPEC nhận đ-ợc từ bản tin PATH đ-ợc chuyển tới khối điều khiển l-u l-ợng nội tại Khối này gửi ng-ợc lại một ADSPEC mới chứa thông tin về khả năng hỗ trợ chất l-ợng dịch vụ và sau đó ADSPEC này đ-ợc gửi đi tiếp trong bản tin PATH ADSPEC đ-ợc sử dụng để chuyển các đặc tính chất l-ợng dịch vụ của bên gửi tới bên nhận để ng-ời nhận có thể quyết định băng thông và trễ có thể yêu cầu

- FLOWSPECT: Mô tả các tham số chất l-ợng dịch vụ mong muốn trong bản tin RESV, th-ờng bao gồm loại dịch vụ, hai bộ tham số, RSPEC xác định chất l-ợng

dịch vụ mong muốn, và TSPECT mô tả luồng dữ liệu

RSVP đặt ra bảy loại bản tin khác nhau Cụ thể nh- sau:

1 Bản tin PATH: Bên gửi theo chu kỳ tạo một bản tin PATH cho từng luồng dữ liệu của nó Bản tin này chứa những đối t-ợng và cấu trúc dữ liệu sau:

- SENDER_TSPEC: Các tham số l-u l-ợng của luồng, h-ớng đi

- SENDER_TEMPLATE: Nhận dạng ng-ời gửi

- PHOP-Address Object: Địa chỉ IP của nút RSVP tr-ớc đó Mỗi nút chèn

địa chỉ của chính nó vào tr-ờng này

- ADSPEC: Mô tả khả năng hỗ trợ chất l-ợng dịch vụ

Bản tin PATH chứa thông tin trạng thái đ-ờng dẫn tại từng nút trên h-ớng đi, trong đó bao gồm các dữ liệu liên quan đến bên gửi

2 Bản tin RESV: Bên nhận bắt đầu việc giữ tr-ớc tài nguyên bằng cách gửi bản tin RESV Bản tin này chứa yêu cầu giữ tài nguyên từng chặng cho luồng dữ liệu từ bên gửi đến bên nhận Bên gửi đ-ợc yêu cầu gửi một bản tin RESV_CONF Bản tin này chứa các tham số chất l-ợng dịch vụ d-ới dạng FLOWSPEC và FILTERSPEC Bản tin RESV tạo và duy trì trạng thái giữ tr-ớc tài nguyên tại từng nút mạng nơi chứa toàn bộ dữ liệu liên quan đến phiên truyền

3 Bản tin PathTear: Bản tin PathTear đ-ợc bên gửi gửi tới bên nhận một cách t-ờng minh hoặc khi có hiện t-ợng quá giờ tại bất cứ một nút nào Nút mạng nhận đ-ợc bản tin PathTear sẽ huỷ cấu trúc dữ liệu trạng thái đ-ờng dẫn t-ơng ứng

4 Bản tin ResvTear: Khi nhận đ-ợc bản tin ResvTear nút mạng huỷ trạng thái giữ tài nguyên t-ơng ứng Các bản tin này đ-ợc bên nhận gửi tới bên phát một cách t-ờng minh hoặc khi xảy ra quá giờ tại bất cứ nút mạng nào

5 Bản tin PathErr: Khi có lỗi xuất hiện trong quá trình xử lý bản tin PATH (ví dụ sai địa chỉ IP đích), PathErr đ-ợc chuyển tới bên gửi Các bản tin

PathErr không thay đổi trạng thái của bất cứ nút mạng nào mà chúng đi qua; chúng chỉ thông báo cho bên gửi

6 Bản tin ResvErr: Khi có lỗi xuất hiện trong quá trình giữ tài nguyên (ví dụ tài nguyên cạn kiệt), ResvErr đ-ợc chuyển tới bên nhận Đối t-ợng ERROR_SPECT xác định lỗi và chứa địa chỉ IP của nút mạng phát hiện ra lỗi

7 Bản tin ResvConf: Bản tin ResvConf đ-ợc gửi để xác nhận yêu cầu giữ tr-ớc tài nguyên đã đ-ợc đáp ứng thành công Chúng chỉ đ-ợc gửi khi đ-ợc yêu cầu thông qua đối t-ợng RESV_CONFIRM trong bản tin RESV

Khi ứng dụng tại bên gửi khởi động báo hiệu RSVP, các đối t-ợng quan trọng nh- SENDER_TEMPLATE và TSPEC đ-ợc đ-a vào trong bản tin PATH theo đ-ờng dẫn đ-ợc quyết định bởi giao thức định tuyến IP

Tại mỗi chặng, bộ định tuyến xử lý bản tin RSVP bằng cách thiết lập trạng thái

đ-ờng dẫn và l-u trữ địa chỉ IP của bộ định tuyến h-ớng tới lên Ngoài ra, bộ định tuyến cũng cập nhật đối t-ợng ADSPEC chứa trong bản tin PATH nhận đ-ợc

Hình 3.2 trình bày tiến trình trao đổi các bản tin RSVP cơ bản

Hình 3.2: Tiến trình trao đổi các bản tin RSVP cơ bản

Bản tin PATH cung cấp thông tin nhận dạng và đặc tính l-u l-ợng của ứng dụng gửi,

đặc tính của đ-ờng dẫn đã đ-ợc định tuyến và thông tin chỉ dẫn cách truyền ng-ợc lại bên gửi bản tin PATH Với thông tin này, ứng dụng báo cho khối RSVP Process chấp nhận yêu cầu giữ tài nguyên Một bản tin RESV đ-ợc tạo ra chứa thông tin mô tả luồng (gồm FILTERSPEC và FLOWSPEC) FILTERSPEC nhận dạng địa chỉ nguồn và số hiệu cổng của ứng dụng gửi và FLOWSPEC chứa thông tin l-u l-ợng và mức chất l-ợng dịch vụ mà ứng dụng nhận đang yêu cầu

Bản tin RESV theo h-ớng ng-ợc lại, tới bên gửi Khối Điều khiển l-u l-ợng tại tất cả các bộ định tuyến trung chuyển đ-ợc cập nhật t-ơng ứng Nếu tài nguyên yêu cầu vẫn còn thì chúng đ-ợc phân bổ ở từng bộ định tuyến

Sau khi nhận đ-ợc bản tin RESV, ứng dụng có thể truyền dữ liệu qua mạng

3.1.2 Các loại dịch vụ đ-ợc hỗ trợ trong kiến trúc IntServ

3.1.2.1 Dịch vụ Tải đ-ợc điều khiển (Controlled Load - CL)

Dịch vụ “Tải được điều khiển” [Wroc97b] được sử dụng để hỗ trợ các ứng dụng đã

đ-ợc phát triển trên mạng IP nh-ng lại nhạy cảm với tình trạng quá tải Mục tiêu của dịch vụ “Tải được điều khiển” là làm cho các ứng dụng nhận đ-ợc một mức dịch vụ nh- là dịch vụ "cố gắng tối đa" trong mạng chịu tải nhẹ Mạng cung cấp dịch vụ

“Tải được điều khiển” phải đảm bảo các điều kiện sau đây:

- Có tỷ lệ các gói đ-ợc gửi thành công qua mạng cao tiệm cận với tỷ lệ lỗi gói của ph-ơng tiện truyền dẫn

- Trễ của phần lớn các gói đ-ợc chuyển đi không v-ợt quá nhiều so với trễ nhỏ nhất của bất kỳ một gói nào đ-ợc gửi thành công

Để thỏa mãn những điều kiện trên, mỗi thành phần mạng chấp nhận yêu cầu dịch vụ

“Tải được điều khiển” phải đảm bảo có đủ tài nguyên để xử lý l-u l-ợng yêu cầu trong TSPEC Điều này bắt buộc phải thực hiện thông qua cơ chế điều khiển chấp nhận động Tất cả các tài nguyên quan trọng liên quan đến hoạt động của phần tử mạng nh- băng thông, không gian bộ đệm, năng lực xử lý của bộ xếp chuyển gói phải đ-ợc xem xét tr-ớc khi chấp nhận yêu cầu

Dịch vụ “Tải được điều khiển” không sử dụng các tham số mục tiêu cố định như trễ

và mất gói Nó chỉ cam kết cung cấp dịch vụ gần nh- t-ơng đ-ơng với dịch vụ cố gắng tối đa trong mạng tải nhẹ Khái niệm "gần nh- t-ơng đ-ơng với dịch vụ cố gắng tối đa ở mạng chịu tải nhẹ" là một khái niệm mơ hồ nh-ng theo IETF thì khó

có thể định nghĩa khác hơn Với từng dòng dữ liệu dịch vụ “Tải được điều khiển” tại một phần tử mạng có thể:

- Hầu nh- không xảy ra hiện t-ợng trễ xếp hàng trung bình trong mọi khoảng thời gian lớn hơn đáng kể so với thời gian truyền tăng tốc đột biến

- Hầu nh- không xảy ra mất gói do nghẽn trong bất cứ khoảng thời gian nào

lớn hơn đáng kể so với thời gian truyền tăng tốc đột biến

Với cách định nghĩa nh- trên thì các các sự kiện trễ hoặc mất gói trong thời gian ngắn có thể xảy ra trong điều kiện mạng hoạt động bình th-ờng Chỉ các sự kiện diễn ra trong thời gian dài hơn mới đ-ợc coi là coi là có sự cố

Do dịch vụ “Tải được điều khiển” không định dạng lại lưu lượng theo các tham số thùng thẻ tại tất cả các nút mạng, l-u l-ợng truyền qua mạng có thể biến thiên trên

đ-ờng đi Mức độ hạn chế của dung l-ợng bộ đệm có thể dẫn tới mất gói do nghẽn Vì vậy bổ sung dung l-ợng bộ đệm để phục vụ cho phần l-u l-ợng tăng đột biến là cần thiết

Một vấn đề khác có thể nảy sinh là l-u l-ợng từ nguồn có thể liên tục giữ ở tốc độ thẻ và đôi lúc lại tăng tốc Khi đó trễ xếp hàng sẽ tăng lên Để kiểm soát ảnh h-ởng dài hạn của l-u l-ợng tăng tốc đột biến, dịch vụ "Tải đ-ợc kiểm soát" có thể phải xin thêm băng thông để l-u thoát hết l-u l-ợng tăng tốc

Yêu cầu dịch vụ "Tải đ-ợc kiểm soát" đ-ợc thực hiện thông qua việc gửi các tham

số l-u l-ợng (TSPEC) tới nút mạng bằng TOKEN_BUCKET_TSPEC định nghĩa trong [Shen97b] TSPEC chứa các thuộc tính đ-ợc trình bày trong bảng 3.1 trang sau

Bảng 3.1: Các tham số dịch vụ Tải đ-ợc kiểm soát

đ-ợc kiểm soát

Tốc độ tối đa p đảm bảo cho TSPEC t-ơng thích với các dịch vụ kiểm soát chất l-ợng dịch vụ khác và có thể bỏ qua khi thực thi dịch vụ "Tải đ-ợc kiểm soát" vì phần tử mạng luôn có thể giả định tốc độ dữ liệu tới thành phần này chính là tốc độ

đ-ờng kết nối tới giao diện của phần tử mạng Kích th-ớc gói nhỏ nhất đ-ợc kiểm soát m có nghĩa tất cả các gói IP nhỏ hơn m sẽ đ-ợc tính là có kích th-ớc m Kích th-ớc gói tối đa M là kích th-ớc gói lớn nhất

Kiểm soát l-u l-ợng

Dịch vụ "Tải đ-ợc kiểm soát" đ-ợc cung cấp dựa trên cơ sở l-u l-ợng của luồng tuân thủ TSPEC yêu cầu ban đầu Các tham số thùng thẻ của TSPEC yêu cầu l-u l-ợng không đ-ợc v-ợt quá rT + b với bất kỳ khoảng thời gian T nào Các gói vi phạm giới hạn trên đ-ợc coi là không tuân thủ tiêu chuẩn l-u l-ợng Ngoài ra các gói có kích th-ớc lớn hơn M cũng đ-ợc coi là không tuân thủ tiêu chuẩn l-u l-ợng Khi có các gói không tuân thủ tiêu chuẩn l-u l-ợng đi tới thì mỗi phần tử mạng phải

đến l-u l-ợng cố gắng tối đa

3 Vừa phải tuân thủ với 1 và 2 nh-ng vẫn phải cố gắng chuyển l-u l-ợng v-ợt tiêu chuẩn d-ới dạng l-u l-ợng cố gắng tối đa nếu nh- tài nguyên vẫn còn đủ

Ngoài những yêu cầu ở mục 2 và 3 phía trên, dịch vụ "Tải đ-ợc kiểm soát" không xác định rõ cách xử lý những l-u l-ợng không tuân thủ Có thể cho phép giảm cấp dịch vụ đối với toàn bộ các gói của luồng hoặc chỉ lọc ra những gói không tuân thủ

và chuyển đi ở mức dịch vụ thấp hơn

Để triển khai dịch vụ "Tải đ-ợc kiểm soát" có thể sử dụng cơ chế xếp hàng với hai mức -u tiên Mức -u tiên cao sử dụng cho dịch vụ "Tải đ-ợc kiểm soát" và mức thấp cho dịch vụ cố gắng tối đa Sử dụng một thuật toán điều khiển chấp nhận để giới hạn l-u l-ợng vào hàng đợi có mức -u tiên cao

Một giải pháp khác là dựa trên các phần tử mạng hỗ trợ cơ chế nh- xếp hàng công bằng theo trọng l-ợng hay xếp hàng theo loại l-u l-ợng Trong tr-ờng hợp này có thể ánh xạ l-u l-ợng "Tải đ-ợc kiểm soát" vào một loại l-u l-ợng có dung l-ợng đủ

để không gây ra quá tải

Có nhiều kỹ thuật có thể sử dụng để phân tách l-u l-ợng không tuân thủ và l-u l-ợng cố gắng tối đa Có thể sử dụng một hàng đợi -u tiên thấp cho l-u l-ợng không tuân thủ Cũng có thể sử dụng kỹ thuật xếp hàng công bằng để phân bổ một tỷ lệ phần trăm nhất định tài nguyên sẵn có cho các loại dịch vụ cố gắng tối đa khác Một cách giải quyết là phân bổ cho mỗi luồng "Tải đ-ợc kiểm soát" một tỷ lệ băng thông dịch vụ cố gắng tối đa cho l-u l-ợng v-ợt mức Một cách khác là sử dụng WFQ để phân toàn bộ l-u l-ợng "Tải đ-ợc kiểm soát" v-ợt mức thành một loại riêng Ngoài ra cơ chế RED cũng có thể đ-ợc dùng để xử lý l-u l-ợng "Tải đ-ợc kiểm soát"

3.1.2.2 Dịch vụ đảm bảo - Guaranteed Service (GS)

Với "Dịch vụ đảm bảo", các gói dữ liệu sẽ đ-ợc chuyển với độ trễ đ-ợc đảm bảo trong giới hạn nhỏ và không bị loại bỏ do hiện t-ợng tràn hàng đợi nếu l-u l-ợng

của luồng dữ liệu nằm trong giới hạn l-u l-ợng định tr-ớc "Dịch vụ đảm bảo" không cố gắng để giảm thiểu jitter, không kiểm soát trễ nhỏ nhất hay trễ trung bình

mà chỉ tập trung kiểm soát trễ xếp hàng tối đa Thêm nữa, để tính toán trễ tối đa, trễ

đ-ờng truyền cũng phải đ-ợc xác định và cộng vào trễ xếp hàng T-ơng tự nh- dịch

vụ "Tải đ-ợc kiểm soát", "Dịch vụ đảm bảo" cũng thực thi chính sách điều khiển chấp nhận

Các phần tử mạng phải đảm bảo hoạt động gần giống nh- mô hình dòng chất lỏng Mô hình dòng chất lỏng hoạt động ở tốc độ R là mô hình dịch vụ cung cấp bởi một kênh thuê riêng băng thông R kết nối giữa nguồn và đích Trong mô hình dòng chất lỏng, l-u l-ợng tuân thủ tham số thùng thẻ (r,b) và đ-ợc phục vụ bởi một kênh băng thông R sẽ có trễ không v-ợt quá b/R khi R lớn hơn hoặc bằng r Nh- vậy mỗi thành phần mạng phải đảm bảo trễ xếp hàng của bất kỳ gói dữ liệu nào cũng phải nằm trong giới hạn:

D R

C R



Trong đó C (byte) và D (s) là sai lệch tối đa so với mô hình chất lỏng

C là sai số phụ thuộc tốc độ Nó thể hiện l-ợng trễ có thể xảy ra do đối với gói do các tham số tốc độ của luồng

D là sai số không phụ thuộc tốc độ, thể hiện mức độ biến thiên của thời gian chuyển gói qua phần tử mạng trong tr-ờng hợp xấu nhất

Yêu cầu "Dịch vụ đảm bảo" đ-ợc bắt đầu bằng việc gửi tham số l-u l-ợng TSPEC

và dịch vụ mong muốn RSPEC tới phần tử mạng T-ơng tự nh- dịch vụ "Tải đ-ợc kiểm soát", TSPEC cũng có các tham số thùng thẻ (r, b), tốc độ tối đa (p), đơn vị dữ liệu nhỏ nhất đ-ợc kiểm soát (m) và kích th-ớc gói tối đa (M) Tuy nhiên tốc độ tối

đa p ở đây có ý nghĩa khác Đó là tốc độ tối đa mà nguồn và bất cứ điểm định dạng dòng dữ liệu nào đ-ợc phép truyền dữ liệu vào mạng Điều này có nghĩa trong bất cứ khoảng thời gian nào dữ liệu gửi đi không đ-ợc v-ợt quá M+pT Ngoài ra p phải lớn hơn hoặc bằng so với tốc độ thùng thẻ (r)

RSPEC gồm tham số tốc độ R (byte/s) và tham số S (s), trong đó R phải lớn hơn hoặc bằng r và S là giá trị không âm Giá trị tốc độ R trong RSPECT có thể lớn hơn

R trong TSPEC vì tốc độ lớn hơn sẽ giảm trễ xếp hàng S cho biết sự khác nhau giữa trễ mong muốn và trễ thực tế khi giữ tr-ớc tài nguyên ở mức R S có thể đ-ợc phần

tử mạng sử dụng để giảm tài nguyên giữ tr-ớc cho

luồng dữ liệu

Kiểm soát l-u l-ợng

Trong "Dịch vụ đảm bảo" có hai dạng kiểm soát l-u l-ợng Dạng thứ nhất là kiểm soát giản đơn, theo đó l-u l-ợng tới đ-ợc so sánh với TSPEC Dạng thứ hai là định dạng lại l-u l-ợng với mục đích khôi phục dạng l-u l-ợng để tuân thủ với TSPEC Kiểm soát đơn giản đ-ợc thực hiện ở rìa mạng Định dạng lại đ-ợc thực hiện ở các

điểm rẽ nhánh l-u l-ợng nguồn và tất cả các điểm gộp nguồn Định dạng lại chỉ cần thiết khi TSPEC ở kết nối h-ớng ra nhỏ hơn TSPEC đã đ-ợc giữ tr-ớc ở trên kết nối ngay phía tr-ớc

Các tham số thùng thẻ và tốc độ tối đa đòi hỏi l-u l-ợng phải tuân thủ trong toàn bộ thời gian Tổng l-u l-ợng dữ liệu truyền đi phải không v-ợt quá M + min[pT, rT+b-M]

Các gói không tuân thủ, theo đề xuất của IETF, nên (không bắt buộc) đ-ợc xử lý nh- l-u l-ợng dịch vụ cố gắng tối đa - dịch vụ mặc định trong mạng

Dịch vụ "Dịch vụ đảm bảo" có khả năng cung cấp băng thông ổn định, trễ ít nên có thể sử dụng để truyền tải l-u l-ợng VoIP và các ứng dụng thời gian thực khác

Mỗi bản tin PATH chứa TSPEC và các tham số đã mô tả ở trên và ADSPEC chứa các tham số C, D và tổng của chúng Nh- vậy mỗi thành phần mạng h-ớng xuống

có thể tính đ-ợc phân bổ bộ đệm cần thiết để không gây ra mất gói Host 2 biết chính xác các tham số và có thể gửi bản tin RESV chứa TSPEC và RSPEC Cấu trúc

và ý nghĩa của RSPEC đ-ợc mô tả trong [Shen97a]

Hình 3.3 biểu diễn tổng quát tiến trình trao đổi các bản tin RSVP để giữ tr-ớc Dịch

vụ đảm bảo giữa hai trạm trên mạng IP

Hình 3.3: Tiến trình trao đổi các bản tin RSVP cho dịch vụ đảm bảo

3.1.3 Tóm l-ợc về kiến trúc các dịch vụ tích hợp

ý th-ởng bản đầu của dịch vụ tích hợp là giữ tr-ớc băng thông cố định cho từng ng-ời sử dụng hoặc từng ứng dụng t-ơng tự nh- trong mạng điện thoại Để tiết kiệm tài nguyên, l-u l-ợng đến đ-ợc -ớc l-ợng ở đây tốc độ dữ liệu giữ tr-ớc không đ-ợc

sử dụng trong toàn bộ thời gian

IntServ khác với mạng điện thoại truyền thống là việc giữ tr-ớc băng thông mềm dẻo hơn và có thể thay đổi động ngay trong phiên truyền

IntServ chỉ có thể đ-ợc sử dụng cho các ứng dụng qua một giao diện API đặc biệt Windows 2000/XP cung cấp một loại API này nh- là một phần của Winsock2 Nh-ợc điểm lớn nhất của IntServ là nó tính quy mô không cao Các bản tin PATH

và RESV phải đ-ợc gửi theo chu kỳ cho từng luồng dữ liệu có thể tạo ra một l-u l-ợng rất lớn trong những mạng lớn và trong các bộ định tuyến ở trung tâm mạng Việc duy trì thông tin trạng thái cho hàng vạn luồng dữ liệu và quản lý hàng nghìn hàng đợi cũng rất phức tạp

Chính những điều này làm cho IntServ cùng với RSVP phiên bản 1 không thực sự thích hợp cho các mạng IP lớn

3.2 Kiến trúc các dịch vụ phân biệt của IETF

3.2.1 Khái niệm về DiffServ

Một nhóm làm việc khác của IETF (DiffServ) chuyển trọng tâm vào một mô hình hỗ trợ chất l-ợng dịch vụ ở quy mô hơn Các công nghệ chuyển mạch và định tuyến phát triển rất nhanh, các bộ định tuyến và chuyển mạch ở trung tâm mạng không nên phải xử lý các luồng dữ liệu đơn lẻ cũng nh- quản lý trạng thái của từng đối t-ợng sử dụng

DiffServ, đ-ợc chuẩn hoá vào năm 1998 [Blak98], sử dụng cơ chế đánh dấu gói, theo đó mỗi gói đ-ợc đều mang thông tin dịch vụ trong một tr-ờng dành riêng đặc biệt Mục tiêu thiết kế DiffServ là có thể sử dụng nó cho các ứng dụng hiện tại mà không cần phải sửa đổi Theo h-ớng này, DiffServ phân loại các luồng dữ liệu đơn

từ trạm tới trạm và gộp chúng lại tại rìa của mạng thành một số luồng nhất định theo theo cấp độ chất l-ợng dịch vụ Nh- vậy sẽ chỉ có một số l-ợng nhỏ các loại dịch vụ trong vùng mạng DiffServ

Việc phân loại đ-ợc thực hiện cho từng gói tại bộ định tuyến đầu vào mạng DiffServ Các tr-ờng khác nhau trong tiếp đầu gói, địa chỉ đích và số hiệu cổng có thể đ-ợc sử dụng để phân loại

Các gói dữ liệu đ-ợc đánh dấu theo loại dịch vụ bằng cách ấn định cho chúng một giá trị gọi là mã dịch vụ phân biệt (DSCP) Với IPv4, DSCP đ-ợc chứa trong tr-ờng TOS, với IPv6, DSCP đ-ợc chứa trong byte Traffic Class

Bộ định tuyến lõi mạng DiffServ kiểm tra giá trị DSCP và quyết định ph-ơng pháp

xử lý gói Việc chuyển gói đ-ợc thực hiện theo từng chặng tức là mỗi nút DiffServ

tự quyết định cách thức các luồng đ-ợc chuyển đi Việc phục vụ một luồng với một giá trị DSCP nhất định nhận đ-ợc tại mỗi chặng đ-ợc gọi là "ứng xử theo chặng" - PHB Mỗi PHB là sự mô tả cách thức chuyển, có thể giám sát đ-ợc từ bên ngoài và

có thể xác định đ-ợc qua các tham số tài nguyên (ví dụ nh- băng thông và bộ đệm) hoặc theo yêu cầu của nguồn dữ liệu chuyển tới mạng (ví dụ là mất gói, trễ, jitter) Các nút biên mạng DiffServ có thể kết nối từ một miền DiffServ này tới một miền DiffServ khác hoặc các hệ thống không t-ơng thích DiffServ Chúng có nhiệm vụ hỗ trợ thực thi các cam kết l-u l-ợng trong các bản thoả thuận chất l-ợng dịch vụ giữa hai vùng mạng Nhiều vùng DiffServ tập hợp với nhau tạo thành khu vực DiffServ có khả năng cung cấp các dịch vụ phân biệt qua biên giới các vùng DiffServ

3.2.2 Cấu trúc bộ định tuyến hỗ trợ DiffServ

Hình 3.4 biểu diễn các chức năng chính của bộ định tuyến nằm ở biên mạng và lõi mạng Các gói dữ liệu vào mạng qua một bộ định tuyến nằm ở biên mạng, chuyển qua các bộ định tuyến lõi mạng và ra khỏi mạng qua một bộ định tuyến biên khác Khối phân loại l-u l-ợng đ-ợc mô tả trong [Blak98], theo đó có hai kiểu bộ phân loại Bộ phân loại BA (Behaviour Aggregate Classifier) phân loại gói dựa trên giá trị tr-ờng DS có trong bộ định tuyến lõi Bộ phân loại MF căn cứ vào các tr-ờng khác của gói để phân loại gói là một thành phần của bộ định tuyến biên Nó có thể dựa vào cổng vật lý, tiếp đầu gói IP hoặc tiếp đầu giao thức truyền tải Các bộ phân loại gói có thể sử dụng:

- Giao diện vật lý

- Địa chỉ IP nguồn, đích hoặc một nhóm địa chỉ IP

- Tr-ờng giao thức trong tiếp đầu gói IP

- Số hiệu cổng nguồn, đích của giao thức truyền tải

Các luồng dữ liệu đ-ợc chuyển tới các bộ định tuyến đầu vào mạng và tới điều khiển l-u l-ợng nằm trong bộ định tuyến biên Trong khối điều khiển l-u l-ợng chứa các

bộ phận đo l-u l-ợng, đánh dấu, định dạng l-u l-ợng và hủy gói Khối đo l-u l-ợng kiểm tra xem gói có phù hợp với hồ sơ l-u l-ợng trong thỏa thuận dịch vụ hay không và chuyển thông tin trạng thái tới các bộ phận chức năng khác