Đa liên kết điểm điểm MLP (Multilink PPP) cho phép các gói phân mảnh đƣợc gửi tới cùng một trạm đầu xa tại cùng thời điểm thông qua nhiều liên kết điểm điểm. Tải trọng có thể đƣợc tính toán trên đầu gửi, đầu ra hoạc cả hai để xác định lƣu lƣợng giữa các trạm xác định. MLP có thể phân phối băng thông theo yêu cầu để giảm thiểu trễ truyền dẫn trên các liên kết WAN.
Lƣu lƣợng đến giao diện bao gồm các gói IP voice và các gói cỡ lớn, Khi chuyển đến giao diện đầu vào các gói sẽ đƣợc sắp xếp vào hàng đợi dựa trên đặc tính phân loại của gói mỗi gói. Sau khi đã đƣợc xếp vào hàng đợi các gói lớn sẽ bị phân mảnh thành các gói nhỏ hơn và chuẩn bị xen kẽ với các gói thoại IP, các gói này sẽ đƣợc gửi đi theo lịch trình của cơ chế hàng đợi đƣợc cấu hình.
Chú ý rằng để đảm bảo đúng thứ tự của các gói tin khi đƣợc truyền và thiết lập lại, LFI bổ xung các tiêu đề đa liên kết vào các gói phân mảnh và sắp xếp chúng vào hàng đợi để gửi đi.
2.5.2 Các giải thuật nén. [9] 2.5.2.1. Thông số nén: 2.5.2.1. Thông số nén:
Nén liên quan đến thuật toán toán học mà cho phép mã hóa các gói tin gốc thành các chuôic byte ngắn hơn rồi gửi đến đầu thu. Tại đầu nhận thuật toán giải nén thực hiện khôi phục gói tin gốc từ chuỗi bít mà nó nhận đƣợc.
Một vài năm gần đây, một số nhà toán học, chuyên gia máy tính phát triển các thuật toán mới mà ứng dụng trong các điều kiện đặc biệt nhằm tiết kiệm số byte cần đƣợc gửi đi.
Để so sánh thuật toán nén với nhau thông thƣờng sử dụng hệ số nén (compression ratio) đƣợc tính bằng tỉ lệ giữa số byte của gói tin gốc chia cho số byte sau khi đã đƣợc nén. Tùy thuộc vào kiểu dữ liệu đƣợc nén, thuật toán nén mà hệ số nén và tiêu tốn bộ nhớ, CPU là khác nhau.
Trong các Router của Cisco các công cụ nén đƣợc chia thành 2 mảng chính bao gồm nén tải tin (Payload compression) và nén tiêu đề (Header compresion). Nén tải tin sẽ thực hiện nén cả phần dữ liệu và tiêu đề trong khi đó nén tiêu đề chỉ thực hiện nén phần tiêu đề. Cả 2 loại nén này đều chiếm tài nguyên bộ nhớ và CPU, tuy nhiên nén tải tin yêu cầu ít hơn.
Cấu trúc của các loại nén nhƣ sau:
10/17/2006 - 10/24/2006 IP TCP Dữ liệu Nén tải tin TCP header IP UDP RTP Dữ liệu Nén RTP Hình 2.9: Các kiểu nén. 2.5.2.2. Nén tải tin:
Cisco IOS hỗ trợ ba phƣơng thức nén khác nhau đƣợc sử dụng trên nền giao thức lớp 2. Hiệu quả sử dụng của các giải thuật này cũng rất khác nhau tuy nhiên đặc biệt hiệu dụng trong việc tiết kiệm tài nguyên đặc biệt bộ nhớ và hiệu quả sử dụng CPU cho Router. Các giải thuật bao gồm:
Predictor.
STAC hay Stacker là một giải thuật đƣợc xây dựng dựa trên nền tảng giải thuật nén LZ (Lempel – Ziv). Giải thuật LZ ( thỉnh thoảng còn đƣợc gọi là LZW ) tìm kiếm trong byte truyền dữ liệu những chuỗi dƣ thừa và thay thế bằng các Token ngắn hơn (Các Token này đƣợc xây dựng từ trƣớc và lập nên một thƣ viện). Thƣ viện này đƣợc xây dụng trong thời gian thực (real time), và không cần thiết thay đổi thƣ viện bởi vì thƣ viện này đƣợc xây dựng lại từ thu nhận dữ liệu trạm đầu xa.
MPPC cũng sử dụng cùng giải thuật LZ.
Cả hai giải thuật này cho kết quả nén rất tốt tuy nhiên chúng đòi hỏi tần suất CPU làm việc cao.
Giải thuật Predictor là một giải thuật đơn giản, rất nhanh và tần suất CPU làm việc không cao tuy nhiên tỉ lệ nén là tƣơng đối thấp. Giải thuật này dựa trên việc đoán trƣớc thứ tự byte tiếp theo trong luồng dữ liệu thông qua thƣ viện đơn giản, thƣ viện này đƣợc xây dựng lại từ trạm gửi hoặc dữ liệu nén và không cần thay đổi trong mỗi trặng. STAC, MPPC và Predictor là những thuật toán thƣờng đƣợc sử dụng thực hiện nén tải tin tại lớp 2 trên các liên kết Point – to – Point giữa các Router Cisco. STAC và MPPC đòi hỏi tần suất hoạt động của CPU cao nhƣng có tỉ lệ nén lớn, thủ tục nén và giải này thƣờng phát sinh trễ nên sử dụng trên các liên kết tốc độ thấp. Stacker cho phép khả năng điều chỉnh.
Predictor đƣợc xem nhƣ là khá đơn giản nó có thể triển khai trên các liên kết tốc độ cao, trễ và tần suất sử dụng CPU thấp tuy nhiên đòi hỏi bộ nhớ lớn và hiệu quả nén là thấp hơn so với 2 thủ tục kia.
Phạm vi sử dụng của các giải thuật đƣợc mô tả theo hình sau:
Đặc tính Stacker MPPC Predictor
Sử dụng thuật toán Lempel-Ziv (LZ) Có Có No
Sử dụng thuật toán Predictor m Không Không Có
High-Level Data Link Control (HDLC) Có Không Không
Hỗ trợ với Link Access Procedure, Balanced (LAPB) Có Không Có
Hỗ trợ với Frame Relay Có Không Không
Hỗ trợ với Point-to-Point Protocol (PPP) Có Có Có
Hỗ trợ vớiATM (Sử dụng multilink PPP) Có Có Có
Bảng 2.3: Đặc tính các thuật toán nén.
2.5.2.3 Nén tiêu đề - Header:
Tất các phƣơng thức nén đều cùng chung một mục đích đó là hạn chế dƣ thừa khi gửi dữ liệu trên môi trƣờng truyền dẫn. Các trƣờng thông tin tiêu của các gói trong cùng một luồng không thay đổi nhiều trong suốt quá trình truyền đó bởi vậy việc các thông tin này thực sự gây lãng phí băng thông. Nhƣ vậy một vấn đề đặt ra là cần nén tiêu đề này để hạn chế băng thông.
Nén header là cách mà không truyền lặp lại thông tin tiêu đề của các gói trong suốt một phiên giao tiếp. Chú ý rằng nén tiêu đề thực hiện trên cơ sở liên kết link – by – link, và không thể thực hiện qua nhiều Router, bởi vì các Router cần đầu đủ thông tin trƣờng tiêu đề lớp 3 để có thể định tuyến tới hop kế tiếp.
Nén tiêu đề đƣợc thực hiện trên các giao tiêp ở các kết nối lớp truyền dẫn. Khi các gói tin đƣợc chuyển đến thuật toán nén tiêu đề sẽ nén tiêu đề lớp 3 và lớp 4 vào một khung và thay thế chúng bởi 1 session. các gói sẽ đƣợc gửi tới đầu ra hàng đợi và đƣợc truyền tới trạm đầu xa. Tại đầu xa quá trình giải nén đƣợc thực hiện và chuyển tiếp tới quá trình xử lý tiếp theo.
Với việc nén tiêu đề các khung lớp 2 sẽ nhỏ đi từ đó thời gian truyền cũng giảm đi do đó giảm tổng trễ.
Có 2 phƣơng thức nén tiêu đề đó là: Nén tiêu đề TCP
Nén tiêu đề RTP
Phần lớn các ứng dụng Internet sử dụng TCP nhƣ một giao thức truyền tải và đa phần các thông tin tiêu đề TCP là cố định hoặc có thể đoán trƣớc đƣợc thông qua một phiên. Với việc nén TCP header (bao gồm IP 20 byte và TCP 20 byte header) có thể làm giảm
Real-Time Rrotocol (RTP) là giao thức chuẩn internet đƣợc sử dụng truyền tải các dữ liệu thời gian thực RTP. Nó cung cấp các chức năng mạng truyền dẫn đầu cuối đến đầu cuối phục vụ các ứng dụng nhƣ thoại, video hoạc dữ liệu mô phỏng thông qua dịch vụ mạng đơn nhóm (unicast) hay đa nhóm (multicast).
RTP bao gồm 2 phần tải tin và tiêu đề (header). Phần tải tin của RTP là một giao thức nhỏ mà cung cấp khôi phục lại, phát hiện lỗi và nhận dạng nội dung.
Phần tiêu đề của RTP là tƣơng đối lớn, bao gồm IP header (IPH), User Datagram Protocol (UDP) header, tạo nên IP/UDP/RTP header.
Để giảm thiểu lãng phí băng thông không cần thiết, nén RTP header là một biến pháp hữu hiệu để tiết kiệm tài nghuyên.
CRTP nén IP/UDP/RTP header trong gói tin RTP từ 40 byte xuống còn xấp xỉ 2-5 byte. Bên cạnh đó việc giải nén có thể khôi phục lại trƣờng tiêu đề mà không gây mất mát thông tin.
CRTP là cơ chế nén hop-by-hop tƣơng tự nhƣ nén tiêu đề TCP. CRTP làm giảm chiều dài của tiêu đề do đó nó làm giảm đƣợc độ trễ. CRTP đặc biệt hữu ích đói với tải tin có cỡ gói nhỏ ví nhƣ thoại VoIP có cỡ gói 20 bytes sử dụng nén CRTP có thể làm giảm cỡ gói xấp xỉ 240%. Nó cũng rất hữu hiệu trong các ứng dụng truyền tải cả lƣu thoại và dữ liệu trên các liên kết tốc độ thấp.
Không nên sử dụng CRTP trên bất cứ liên kết tốc độ cao nào (lớn hơn E1). Chỉ nên sử dụng CRTP trên giao tiếp WAN tại đó băng thông xác định và lƣu lƣợng chủ yếu là dữ liệu RTP.
Trên các giao tiếp Serial sử dùng đóng gói Frame Relay, HDLC hay PPP đều hỗ trợ tính năng với CRTP. Bên cạnh đó CRTP cũng đƣợc hỗ trợ trên các giao tiếp ISDN.
Kết luận:
Bên cạnh các giải pháp về mạng, dịch vụ đƣợc cung cấp bởi Cisco. Các đặc tính QoS của Cisco là một thành phần không thể thiếu nhằm đảm bảo chất lƣợng của các dịch vụ một cách an toàn hơn.
Các công cụ QoS của Cisco giải quyết 5 vấn đề chính trong mạng đó là: Phân loại gói, Quản lý tắc nghẽn, Tránh tắc nghẽn, Kiểm soát và Sửa dạng lƣu lƣợng, Các cơ chế liên
kết hiệu quả. Trong mỗi phƣơng thức này có nhiều cách xử lý gói tin khác nhau. Tùy vào đặc điểm dịch vụ trong mạng, yêu cầu chất lƣợng dịch vụ cần đặt ra và quy mô mạng mà ta cần nghiên cứu lựa chọn các công cụ sao cho phù hợp
CHƢƠNG 3 : TỔ HỢP THOẠI VÀ DỮ LIỆU TRONG MẠNG IP-177 IP-177
3.1. Tổ hợp thoại và dữ liệu:
Tổ hợp thoại và dữ liệu là đặc biệt quan trọng đối với ngƣời thiết kế mạng. Nó mang lại sự tiết kiệm về chi phí cho các nhà cung cấp và đa dạng hóa dịch vụ cho khách hàng.
Ngày nay, xu thế tổ hợp dịch vụ ngày càng phát triển bởi vì chỉ có nhƣ vậy các nhà cung cấp mới có thể sử dụng hiệu quả một cách tối đa tài nguyên mạng bao gồm trang thiết bị, kênh truyền, nhân công mạng đồng thời tạo sức hút đối với khách hàng để họ sử dụng dịch vụ của mình.
Tuy nhiên cũng phải thấy rằng các dịch vụ khác nhau thì chúng có các yêu cầu kỹ thuật khác nhau. Do vậy trƣớc khi triển khai tổ hợp cần phải nghiên cứu kỹ lƣỡng các đặc tính của chúng và có phƣơng án QoS hợp lý để tránh làm suy giảm chất lƣợng mạng.
3.2. Các thuộc tính của Thoại và Dữ liệu: [8,12] 3.2.1. Các thuộc tính của Thoại: 3.2.1. Các thuộc tính của Thoại:
Thoại mã hóa trên khuôn dạng dữ liệu bao gồm 3 loại: VoIP, VoFR, VoATM. Mỗi loại có công nghệ truyền dẫn khác nhau và đặc tính khác nhau. Trong phần lớn công nghệ ứng dụng hiện nay thoại đƣợc mã hóa trên nền giao thức IP. Do vậy ở đây ta giới hạn chỉ xét đặc tính chung của VoIP.
Trong thực tế các thuộc tính thoại VoIP đƣợc truyền dựa trên giao thức vận chuyển thời gian thực RTP và gói IP có cấu trúc nhƣ sau:
IP UDP RTP Tải tin thoại
20 Byte 8 Byte 12 Byte Biến đổi
Dải Port 16384 – 32767 (port chẵn) Thông thƣờng: G711: 160 Byte G729a: 20 Byte Hình 3.1: Cấu trúc gói IP
Tiến trình thực hiện một cuộc gọi VoIP nhƣ sau: Các tín hiệu thoại tƣơng tự đƣợc gửi đến Gateways đƣợc số hóa, mã hóa đóng gói xắp xếp tải tin sau đó gửi đến Router. Router dựa vào thông số địa chỉ đích trong từ mào đầu xác đinh đƣờng đi và định tuyến các cuộc gọi xuyên qua mạng. Tại đầu thu quá trình đƣợc thực hiện ngƣợc lại biến đổi thành tín hiệu tƣơng tự đƣa đến thuê bao ngƣời nghe.
Chu trình thực hiện cuộc gọi theo lƣu đồ sau:
Hình 3.2: Lƣu đồ thực hiện cuộc gọi.
Trong mã háo thoại có nhiều chuẩn mã hóa khác nhau. Hiện nay các thiết bị của Cisco chủ yếu chuẩn mã hóa G711, G726, G729, G723.1 ACELP với các đặc tính:
Mã hóa Tốc độ (kbps) Cỡ tải tin
G.711 (PCM) 64 160 byte
G.726 ADPCM 32 80 byte
G.723.1 ACELP 5.3 20 byte Bảng 3.1: Các lọai chuẩn mã hóa thông dụng.
Tất cả luồng tải tin thoại có chung đặc tính QoS. Để triển khai các công cụ QoS cho nó ta cũng cần tìm hiểu kỹ càng các đặc tính đó.
3.2.1.1. Băng thông thoại VoIP:
Các cuộc thoại thiết lập với một tốc độ cố định và cỡ gói là tƣơng đƣơng nhƣ nhau. Băng thông thực tế cần thiết cho tải tin thoại tùy thuộc vào các hệ số sau:
- Mã hóa - Từ mào đầu
- Cấu trúc khung liên kết dữ liệu - Nén
Phần lớn các thiết bị thoại hiện nay đều sử dụng chuẩn mã hóa G711 và G729 tƣơng ứng với băn thông kênh thoại là 64 kbps và 8 kbps. Trong thực tế ngƣời ta thƣờng coi băng thông của kênh thoại chính là bằng thông cần thiết cho tải tin và bỏ qua các từ mào đầu IP, UDP, RTP và cấu trúc khung lớp 2.
Môi trƣờng Cỡ mào đầu Cỡ mào đầu IP/UDP/RTP Mã hóa Băng thông tải Băng thông tổng Ethernet 14 40 bytes G.711 64 kbps 85.6 kbps MLPPP/FR 6 40 bytes G.711 64 kbps 82.4 kbps Ethernet 14 40 bytes G.729 8 kbps 29.6 kbps MLPPP/FR 6 40 bytes G.729 8 kbps 26.4 kbps
Bảng 3.2: Băng thông yêu cầu với các kiểu liên kết dữ liệu khác nhau.
3.2.1.2. Trễ trong thoại VoIP:
Chất lƣợng của thoại sẽ suy giảm đáng kể khi có quá nhiều trễ xẩy ra, các cuộc gọi nghe bị bậm bõm do mất quá nhiều gói gây lên. Trễ thoại bao gồm đầy đủ các đặc điểm trễ nhƣ đã phân tích ở phần trƣớc. Thông thƣờng chúng có đặc tính nhƣ sau.
Trễ do mã hóa, đây là loại trễ cố định và có giá trị khác nhau tùy thuộc vào loại mã hóa sử dụng. Điển hình trễ này khoảng 10 ms.
Trễ đóng gói , chúng cũng là một loại trễ cố định. Thông thƣờng với chuẩn G711 và G729 trễ khoảng 20 ms ( thời gian để đóng gói hoàn thành một gói tin là 20 ms).
Hai loại trễ trên đều không thể hạn chế đƣợc bằng công cụ QoS.
Trễ lan truyền là loại trễ biến đổi và phụ thuộc vào chiều dài và tốc độ của các thiết bị truyền tin. Trong mạng hiện nay, trễ này dƣới 5ms/ 100 km.
Loại trễ trên có điểm là phụ thuộc vào cự ly và phƣơng thức truyền tin và ta không thể hạn chế các trễ này đƣợc.
Các loại trễ khác bao gồm trễ hàng đợi, trễ truyền nối tiếp, trễ mạng, trễ bộ đệm, trƣợt là các trễ mà ta có thể kiểm soát đƣợc và có thể sử dụng các công cụ QoS để hạn chế chúng.
Nhƣ vậy, ta có thể nhận tháy rằng trong tiến trình thiết lập một cuộc gọi bao gồm nhiều thành phần trễ cố định và thay đổi khác nhau. Do đó một vấn đề đặt ra là trễ bao nhiêu để đảm bảo chất lƣợng của dịch vụ.
Theo tiêu chuẩn ITU và Cisco giới hạn trễ cho một cuộc gọi là nhƣ sau:
Trễ 1 hƣớng ( ms) Mô tả
0 – 150 Theo khuyến nghị ITU G.114 [1]
0 – 200 Theo chuẩn của Cisco
150 – 400 Theo khuyến nghị của ITU G.114 dịch vụ bắt đầu suy giảm nhƣng vẫn chấp nhận đƣợc
400 + Theo khuyến nghị của ITU G.114 không thể chấp nhận đƣợc trong mọi trƣờng hợp
Bảng 3.3: Tiêu chuẩn trễ của ITU và Cisco
Jitter trong thoại là nguyên nhân dẫn đến hiện tƣợng mất âm trong quá trình trao đổi thông tin . Hai bên đầu nghe tín hiệu bập bõm và không liên tục. Hiện tƣợng này là do quá trình biến đổi Jitter tăng quá nhanh hoặc giảm đột ngột.
Để hiểu rõ về Jitter trong thoại ta xét một ví dụ sau:
Bộ đệm Jitter 20ms - Gói 1
Không có tải tin thoại T- X: Khoảng thời
gian nhận đƣợc gói 1
20ms - Gói 2 20ms - Gói 1 Bộ đệm Jitter
Không có tải tin thoại T- X +20 : Khoảng thời gian nhận đƣợc gói 2, không có trƣợt 20ms - Gói 2 Bộ đệm Jitter T- X +40 : Gói thứ 3 vẫn chƣan nhận đƣợc Gói tin thứ nhất 20ms - Gói 3 Bộ đệm Jitter T- X +60 : Gói thứ 3