Mục tiêu của luận văn là nghiên cứu cấu trúc mạng IP, các tiêu chí đánh giá chất lượng dịch vụ và các giải pháp cải thiện chất lượng dịch vụ mạng IP nói chung, từ đó đề xuất các giải phá
Trang 1LỜI CẢM ƠN
Luận văn Thạc sỹ kỹ thuật này được thực hiện tại Học viện Công nghệ Bưu chính Viễn thông, nay công trình nghiên cứu đã hoàn thành, tôi xin được bày tỏ lòng biết ơn chân thành tới Thầy giáo PGS.TS Lê Hữu Lập đã tận tình hướng dẫn, gợi mở, tạo mọi điều kiện thuận lợi cũng như động viên tôi trong suốt quá trình nghiên cứu
Tôi xin chân thành cảm ơn Ban Giám đốc Học viện Công nghệ Bưu chính Viễn thông, Khoa Quốc tế và đào tạo sau đại học, cùng các đồng nghiệp đã tạo điều kiện và giúp đỡ tôi hoàn thành được đề tài nghiên cứu của mình
Cuối cùng là sự biết ơn tới gia đình, bạn bè đã thông cảm, động viên giúp đỡ cho tôi có đủ nghị lực để hoàn thành luận văn
Mặc dù đã có rất nhiều cố gắng nhưng do thời gian và kiến thức còn hạn chế nên luận văn không tránh khỏi những hạn chế Kính mong các thầy cô và đồng nghiệp cho các ý kiến góp ý để tôi có thể hoàn chỉnh được kiến thức của mình, làm hành trang cho công việc sau này
Tôi xin chân thành cảm ơn!
Hoà Bình, tháng 07 năm 2011
Đỗ Thanh Tâm
Trang 2MỤC LỤC
THUẬT NGỮ VIẾT TẮT 3
DANH MỤC HÌNH VẼ 7
DANH MỤC BẢNG BIỂU 7
LỜI MỞ ĐẦU 7
CHƯƠNG I 9
CÁC TIÊU CHÍ ĐÁNH GIÁ CHẤT LƯỢNG DỊCH VỤ MẠNG IP 9
0.1 Giới thiệu chung 9
1.2.1 Băng thông 9
1.2.2 Độ trễ 10
1.2.3 Biến động trễ 11
1.2.4 Tổn thất gói 12
1.2.5 Độ tin cậy 12
3.1.2 Sơ đồ cấu trúc mạng 39
3.1.3 Giao thức truyền tải MPLS 43
3.1.4 Giao thức định tuyến 43
3.2.1 Dịch vụ VoIP 43
3.2.1.1 Khuyến nghị của ITU-T 43
3.2.1.2 Khuyến nghị của Cisco 45
3.2.2 Dịch vụ IPTV 46
3.2.2.1 Khuyến nghị của ITU-T 46
3.2.2.2 Khuyến nghị của Cisco 47
3.3.2 Đề xuất giải pháp QoS 51
3.3.2.1 Đặt vấn đề 51
3.3.2.2 Khuyến nghị 52
3.3.2.3 Xây dựng các Profile QoS cơ bản và quy ước sử dụng DSCP 53
3.3.2.4 Network control profile 54
3.3.2.5 Reatime Voice profile 54
3.3.2.6 Realtime Video profile 54
3.3.2.7 Data 1 Profile (Crictical) 55
3.3.2.8 Data 2 Profile 55
3.3.2.9 Standard Profile 55
3.3.3 Các phép ánh xạ QoS 55
3.3.3.1 Ánh xạ các QoS profile vào DSCP code 55
3.3.3.2 Ánh xạ các dịch vụ/ứng dụng sang Diffserv 56
3.3.3.3 Ánh xạ từ Diffserv code sang MPLS EXP code 57
3.3.4 Cấu hình QoS trong MAN-E 57
3.4 Kết luận 60
TÀI LIỆU THAM KHẢO 61
Trang 3THUẬT NGỮ VIẾT TẮT
Mode
Công nghệ dùng chế độ truyền không đồng bộ
cung cấp dịch vụCDN
CS1
Configuration Protocol
Giao thức cấu hình Host động
Access Multiplexer
Bộ ghép kênh truy nhập đường dây thuê bao số tập trung
MPLS mà PSC (Packet-Switch Capable) được định nghĩa theo từng
Trang 4thuật kết nối mạng
DSLAM Digital Subcriber Line Access Multiplexer Bộ ghép kênh truy nhập đường dây thuê bao số tập trung.
IS-IS Intermediate system to intermediate system Giao thức định tuyến sử dụng trong mạng MAN-E
ITU International Telecommunications Union Liên hiệp viễn thông quốc tế
Phương pháp ánh xạ DiffServ vào MPLS mà PSC (Packet-Switch Capable) được định nghĩa theo từng PHB
Trang 5MAN-E Metropolitan Area Network Ethernet Mạng Metro Ethernet
Switching
Chuyển mạch nhãn đa giao thức
MTU
PLR
PQWFQ
Trang 6XDSL
WRED weighted Random Early Detection Phát hiện sớm ngẫu nhiên với gia trọng
U-PE User Provider Edge Device Thiết bị biên giữa nhà cung cấp và người dùng
Trang 7DANH MỤC HÌNH VẼ
Hình 1.1 Băng thông khả dụng 10
Hình 1.2 Trễ tích luỹ từ đầu cuối tới đầu cuối 10
Hình 1.3 Trễ xử lý và hàng đợi 11
Hình 1.4 Tổn thất gói vì hiện tượng tràn bộ đệm đầu ra 12
Hình 2.1 Các cấp băng thông thường cung cấp cho mạng 15
Hình 2.2 Hàng đợi riêng cho các lưu lượng yêu cầu nghiêm ngặt về trễ và mất gói 16
Hinh 2.3 Mô hình dịch vụ IntServ 24
Hình 2.4 Kiến trúc IntServ 24
Hình 2.5 Cấu trúc logic của bộ điều chỉnh lưu lượng 29
Hình 2.6 Tổ chức của cơ chế lập lịch PQWFQ 30
Hình 3.1 Cấu trúc mạng 38
Hình 3.2 Mạng MAN-E Hải Dương 39
Hình 3.3 Mô hình ring 1 40
Hình 3.4 Mô hình ring 2 40
Hình 3.5 Mô hình ring 3 41
Hình 3.6 Mô hình ring 4 42
Hình 3.7 Sơ đồ khối chức năng của dịch vụ IPTV 49
DANH MỤC BẢNG BIỂU Bảng 3-1 Bảng tham số về âm thanh của ITU-T 45
Bảng 3-2 Bảng tham số thoại của Cisco 46
Bảng 3-3 Các tham số video của ITU-T 47
Bảng 3-4 Bảng ma trận hai chiều 53
Chi tiết theo như bảng 3-5: 56
Bảng 3-5 Bảng ánh xạ QoS Profile sang DSCP 56
Bảng 3-6 Bảng ánh xạ từ Diffserv sang MPLS EXP 57
LỜI MỞ ĐẦU
Trang 8Hiện nay mạng IP có vai trò thiết yếu trong lĩnh vực truyền thông, khái niệm mạng toàn IP (All IP) đã được nói đến nhiều trong những năm gần đây Sự phát triển nhanh chóng của Internet đã làm cho mạng IP trở thành giao thức không thể thiếu và ngày càng quan trọng hơn Trong khi đó, các nhu cầu về dịch vụ không còn đơn điệu như trước và trên thực tế các ứng dụng đòi hỏi QoS xuất hiện ngày càng nhiều Những thành tựu gần đây của công nghệ truyền dẫn giúp cho băng thông khả dụng trên môi trường truyền dẫn vật lý gia tăng nhanh chóng, khả năng cung ứng đường truyền tốc độ cao cho đa dịch vụ hoàn toàn khả thi Bối cảnh này đã đặt ra cho mạng IP nhiều thách thức mới, đòi hỏi mạng IP phải có các cơ chế QoS hoàn chỉnh để đáp ứng nhu cầu đa dịch vụ đang gia tăng Chính vì điều đó tôi đã chọn đề tài của luận văn là: “Nghiên cứu chất lượng dịch vụ dữ liệu thời gian thực trong mạng IP”
Mục tiêu của luận văn là nghiên cứu cấu trúc mạng IP, các tiêu chí đánh giá chất lượng dịch vụ và các giải pháp cải thiện chất lượng dịch vụ mạng IP nói chung,
từ đó đề xuất các giải pháp nhằm nâng cao chất lượng dịch vụ cho mạng Man-E, nhằm đáp ứng được yêu cầu của nhà cung cấp mạng và yêu cầu của người dùng.Luận văn bao gồm 3 chương:
Chương 1 : Các tiêu chí đánh giá chất lượng dịch vụ mạng IP
Chương 2 : Các giải pháp chính cải thiện QoS trong mạng IP
Chương 3 : Chất lượng dịch vụ dữ liệu thời gian thực trên mạng MAN-E
Trang 9CHƯƠNG I CÁC TIÊU CHÍ ĐÁNH GIÁ CHẤT LƯỢNG DỊCH VỤ MẠNG
IP
0.1 Giới thiệu chung
Những năm gần đây đã bắt đầu khuynh hướng xây dựng các hệ thống truyền thoại và video dựa vào IP Khái niệm mạng hội tụ ngày càng quen thuộc, các công nghệ IP cho phép chuyển các mạng điện thoại chuyển mạch kênh và ISDN riêng biệt sang một mạng toàn IP, nơi số liệu, thoại và video đều truyền qua cùng một hạ tầng Trong một mạng hội tụ, chất lượng dịch vụ QoS là chủ đề quan trọng nhất QoS là một thuật ngữ chỉ ra mức độ đảm bảo chất lượng số liệu được truyền nhận Trong thực tế, QoS là cơ chế đảm bảo tín hiệu âm thanh và hình ảnh truyền qua mạng tốn thời gian ít nhất mà vẫn đảm bảo tính nguyên vẹn của chúng Nếu không
có QoS thì các cuộc gọi qua mạng IP sẽ không đảm bảo và không đáp ứng được yêu cầu của người dùng
1.2 Các tham số đánh giá QoS
Chất lượng dịch vụ được đánh giá qua bốn tham số đo lường chính là băng thông, độ trễ, độ biến động trễ và độ tổn thất gói
1.2.1 Băng thông
Băng thông biểu thị tốc độ truyền dữ liệu cực đại có thể đạt được giữa 2 điểm kết nối đầu cuối Có thể giải thích qua các phép tính toán như sau: một mô hình trạng thái QoS của mạng thường được biểu diễn dưới dạng một đồ thị G(V,E) Trong đó, V là các nút còn E là các liên kết Lưu lượng vào mạng qua nút Vi và ra khỏi mạng ở nút Vj Mỗi liên kết có 2 đặc tính: C( I,j) là dung lượng liên kết, f(I,j)
là lưu lượng thực tế Gọi R(i,j) là băng thông dư Khi đó, nếu một kết nối có yêu cầu băng thông là Dk thì kết nối được coi là khả dụng khi và chỉ khi R(i,j) ≥ Dk Một kết nối mới có thể được chấp nhận nếu tồn tại ít nhật một đường dẫn khả dụng giữa
2 nút Vi và Vj Băng thông là tốc độ truyền thông tin được tính theo (bit/s)
Trang 10Hình 1.1 Băng thông khả dụng
Băng thông lớn nhất của tuyến liên kết bằng giá trị băng thông lớn nhất của một đoạn liên kết Băng thông khả dụng được tính tương đối qua giá trị băng thông lớn nhất và lượng băng thông của luồng lưu lượng Tính toán băng thông khả dụng tương đối phức tạp vì tham số băng thông mang tính lõm
1.2.2 Độ trễ
Là khoảng thời gian chênh lệch giữa các thiết bị phát và thiết bị thu Trễ tổng thể là thời gian trễ từ đầu cuối phát tới đầu cuối thu tín hiệu (còn gọi là trễ tích lũy) Mỗi thành phần trong tuyến kết nối như thiết bị phát, truyền dẫn, thiết bị chuyển mạch và định tuyến đều có thể gây ra trễ
Hình 1.2 Trễ tích luỹ từ đầu cuối tới đầu cuối
Các thành phần gây trễ chủ yếu gồm:
- Trễ hàng đợi: là thời gian một gói phải trải qua trong một hàng đợi khi nó phải đợi để truyền đi trong một liên kết khác, hay thời gian cần thiết phải đợi để thực hiện quyết định định tuyến trong bộ định tuyến Nó có thể
Trang 11bằng 0 hoặc rất lớn và phụ thuộc vào số gói có trong hàng đợi và tốc độ
xử lý
Hình 1.3 Trễ xử lý và hàng đợi
- Trễ truyền lan: thời gian cần thiết để môi trường vật lý truyền dữ liệu Ví
dụ trễ truyền lan trong các truyền dẫn quang thường nhỏ hơn trong môi trường vô tuyến
- Trễ chuyển tiếp: thời gian sử dụng để chuyển gói tin từ một tuyến này sang tuyến khác, hay thời gian được yêu cầu để xử lý các gói đã đến trong một nút Ví dụ, thời gian để kiểm tra tiêu đề gói và xác định nút tiếp theo để gửi đi
- Trễ truyền dẫn: là thời gian được yêu cầu để truyền tất cả các bít trong gói qua liên kết, trễ truyền dẫn được xác định trên thực tế của băng thông liên kết
Trang 12dòng gói đến đều đặn hơn ở máy thu Trong một số ứng dụng, như ứng dụng thời gian thực không thể chấp nhận rung pha Biến động trễ lớn có thể được xử lý bằng
bộ đệm, song nó lại làm tăng trễ nên lại nảy sinh các khó khăn khác
1.2.4 Tổn thất gói
Tổn thất gói có thể xảy ra theo từng cụm hoặc theo chu kì do mạng bị tắc nghẽn liên tục, hoặc xảy ra trên chính các trường chuyển mạch gói Mất gói theo chu kì ở khoảng 5-10% số gói phát ra có thể làm giảm chất lượng mạng xuống cấp đáng kể Từng gói bị mất không thường xuyên cũng khiến kết nối gặp khó khăn Xác suất mất gói là giá trị được nhân lên từ xác suất mất gói được kì vọng ở mỗi một trong số các nút trung gian giữa một cặp nguồn và đích Xác suất tổn thất gói là một đại lượng quan trọng của QoS với cả các ứng dụng dữ liệu hay các dịch vụ thời gian thực Khi kết nối yêu cầu truyền dữ liệu theo đúng thứ tự, thì tổn thất gói là nguyên nhân của quá trình truyền lại Điều này làm chậm quá trình xử lý truyền tin
và giảm QoS nhận được Với các ứng dụng thời gian thực, sự truyền lại gói thường không khả thi
Hình 1.4 Tổn thất gói vì hiện tượng tràn bộ đệm đầu ra
1.2.5 Độ tin cậy
Độ tin cậy cũng là một chỉ tiêu xác định chất lượng dịch vụ của một mạng
Để xác định độ ổn định của hệ thống, người ta thường xác định độ khả dụng của hệ thống, đồng nghĩa với độ khả dụng của hệ thống và được nhìn nhận từ khía cạnh mạng là độ tin cậy của hệ thống Độ khả dụng của mạng càng cao có nghĩa là độ tin cậy của mạng càng lớn và độ ổn định của hệ thống càng lớn Độ khả dụng của mạng thường được tính trên cơ sở thời gian ngừng hoạt động và tổng số thời gian hoạt
Trang 13động Lý tưởng thì một mạng phải khả dụng trong 100% thời gian Các nhà cung cấp dịch vụ đặc biệt tin cậy phải đảm bảo chỉ số khả dụng là 99,9999% hay còn gọi
là “Sáu số chín”, chỉ cho phép mất dịch vụ khoảng 2,6 giây mỗi tháng
1.3 Kết luận:
Để các hệ thống truyền thoại và video qua IP làm việc hiệu quả thì băng thông phải càng lớn càng tốt trong khi đỗ trễ, độ tổn thất gói và độ biến động trễ phải ở mức tối thiểu
Quy hoạch mạng là giải pháp để đảm bảo các tham số nói trên ở trong một giới hạn cần thiết để cung cấp một mức QoS có thể chấp nhận Công việc phải tính đến bản chất tự nhiên của hạ tầng mạng (dung lượng vật lý và các giao thức được dùng tại lớp 1, lớp 2 và lớp 3 trong mô hình tham chiếu liên kết hệ thống mở OSI)
và khi nào các tài nguyên mạng được chia sẻ Các đặc tính của ứng dụng, của đầu cuối, kỹ thuật mã hoá và nén… là ngoài phạm vi kiểm soát của nhà cung cấp dịch
vụ mạng, nên các cân nhắc cải tiến IP QoS thường chỉ đề cập đến góc độ ảnh hưởng của mạng
Trang 14CHƯƠNG II CÁC GIẢI PHÁP CHÍNH CẢI THIỆN QoS TRONG MẠNG IP
2.1 Phương thức cơ bản cung ứng QoS trong mạng IP:
Phần lớn các mạng hiện hữu đều được thiết kế cho các ứng dụng số liệu và chưa đáp ứng tốt các yêu cầu của ứng dụng thời gian thực nên QoS đều phải được thiết kế và triển khai Có ba khía cạnh quan trọng thường được xem xét trong khi thiết kế mạng IP cho tín hiệu âm thanh và video, đó là cung ứng có dự phòng cho mạng, xếp hàng và phân loại
2.1.1 Cung ứng có dự phòng cho mạng:
Giải pháp phổ biến nhất cho QoS ngày nay là cung cấp băng thông đầy đủ cho mạng Dự phòng chỉ đơn giản là xây dựng mạng có lượng băng thông nhiều hơn nhu cầu thực tế của dịch vụ âm thanh, video và các dịch vụ khác thường xuyên chạy trên mạng
Có hai mức băng thông phổ biến của Ethernet được triển khai bên trong mạng doanh nghiệp là 10Mbps và 100Mbps, gần đây cũng đã có hỗ trợ 1 Gbps theo chuẩn Giga Ethernet Trong khi đó, kết nối T-1 có dung lượng 1,5Mbps thường được dùng để nối mạng diện rộng cho doanh nghiệp hay nối vào Internet Truyền thông đa phương tiện có thể tiêu thụ lượng băng thông đáng kể vì vậy cung ứng có
dự phòng là một phần quan trọng trong qui hoạch mạng đa phương tiện của doanh nghiệp Giải pháp bước đầu được thực hiện trong bất kỳ môi trường truyền thông đa phượng tiện nào là nâng băng thông mạng bằng cách chuyển sang kiến trúc chuyển mạch Kế đến là phân đoạn mạng LAN thành nhiều mạng con sao cho băng thông khả dụng được chia sẻ bởi số lượng máy trạm nhỏ hơn
Trang 15Hình 2.1 Các cấp băng thông thường cung cấp cho mạng.
Một số cuộc gọi IP chất lượng cao có thể được cấu hình để dùng băng thông
768 kbps hay cao hơn Con số kbps này liên hệ đến lượng dữ liệu thực tế được truyền bởi mỗi máy trạm Khi thiết kế mạng QoS, cũng cần phải xem xét thông tin overhead của mạng Một cuộc gọi video dùng xấp xỉ 20% overhead Do đó, một cuộc gọi được thực hiện với tốc độ 768 kbps có thể tiêu thụ thực sự đến 920 kbps trên mạng Với mức băng thông này, chỉ có thể có một cuộc gọi có chất lượng đảm bảo trên một kết nối T-1 qua mạng WAN
Điều luật tiên quyết là băng thông tối đa được yêu cầu cho tất cả các ứng dụng cộng lại với nhau, bao gồm thoại và video không được vượt quá 75% băng thông khả dụng Tóm lại, cung cấp cho mạng một lượng bổ sung là cần thiết, tuy nhiên việc cung ứng có dự phòng cho mạng như thế vẫn chưa đủ đảm bảo một QoS thích hợp
2.1.2 Xếp hàng:
Đệm dữ liệu là yếu tố QoS quan trọng, các bộ đệm trong các thiết bị mạng có
xu hướng bị làm đầy nhanh chóng trong các mạng tốc độ cao Điều này gây nên hiện tượng mất gói, khiến cho âm thanh hay video bị cắt xén
Có thể khắc phục các yếu kém trong việc đệm dữ liệu bằng kỹ thuật xếp hàng cho số liệu âm thanh và video một cách riêng biệt bên trong các thiết bị mạng Các hàng đợi riêng biệt cho phép truyền số liệu có yêu cầu nghiêm ngặt về thời gian như âm thanh và video theo phương thức ưu tiên (hình 2.2) Để làm việc này, số
Trang 16liệu phải được phân loại theo mức ưu tiên trước khi đưa vào thiết bị truyền Căn cứ vào sự phân loại, gói số liệu được xếp vào một hàng đợi truyền phù hợp; số liệu âm thanh hay video được phân loại sao cho chúng được xếp vào một hàng đợi có trễ và tổn thất gói thấp Điều này có nghĩa là bất kỳ số liệu nào khác đến đồng thời với âm thanh hay video đều có thể bị mất Tuy nhiên, vì dạng số liệu thông thường không
bị ràng buộc về thời gian thực nên nếu có bị mất sẽ được truyền lại mà không ảnh hưởng nhiều đến chất lượng của dạng này Kỹ thuật hàng đợi cung cấp mức ưu tiên cao cho số liệu âm thanh và video nhạy cảm với trễ và tổn thất gói nhằm đảm bảo cho các gói số liệu này được truyền lại một cách kịp thời
Hình 2.2 Hàng đợi riêng cho các lưu lượng yêu cầu nghiêm ngặt về trễ và mất gói.
Các thiết bị Hub không hỗ trợ kỹ thuật xếp hàng do đó dẫn đến gia tăng xung đột trong truyền gói dữ liệu, từ đó gây ra trễ và mất gói Vì vậy các thiết bị Switch hay Router thường được dùng để thay thế các Hub trong thiết kế mạng có hỗ trợ QoS
2.1.3 Phân loại:
Kỹ thuật xếp hàng được tiến hành nhờ vào một số cơ chế phân loại hay ưu tiên gói Một vài cơ chế khác nhau dược dùng hiện nay bao gồm RSVP, IP precedence, DiffServ và MPLS
Trang 17RSVP là một giao thức dựa vào luồng đảm bảo chất lượng dịch vụ cho mỗi luồng dữ liệu Mỗi luồng dữ liệu trên một hướng giữa hai ứng dụng được xem là một luồng tách biệt Trong một hội nghị video thông thường sẽ có bốn luồng: truyền audio, nhận audio, truyền video và nhận video Trong thực tế, RSVP tỏ ra nặng nề và cồng kềnh khi thực hiện Lý do là mỗi thiết bị dọc theo đường truyền của luồng bao gồm các server, PC, router, switch… phải báo hiệu các nhu cầu QoS được đặc tả trong RSVP rất khó mở rộng ra với các qui mô mạng rất lớn.
IP precedence và DiffServ dựa trên các cơ cấu tượng tự nhau để cung cấp QoS, ở đó một vài bít bên trong header của gói dữ liệu sẽ được hiệu chỉnh Khi đến một thiết bị mạng có hỗ trợ IP precedence hay DiffServ, các gói với các bit trong header được cài đặt thích hợp được xếp vào một hàng đợi ưu tiên tương ứng và được truyền đi Với IP precedence và DiffServ, mạng phải được thiết kế sao cho cơ chế được thực hiện một cách nhất quán trong toàn mạng Các nhà cung cấp dịch vụ
đã và đang triển khai cung cấp các lớp dịch vụ theo các mức QoS khác nhau tuỳ vào
sự phân loại của DiffServ
Các Router chuẩn đưa ra các quyết định chuyển gói bằng cách thực hiện nhiệm vụ phức tạp là dò tìm định tuyến căn cứ vào địa chỉ IP đích trong mỗi gói Mỗi router sẽ thực hiện công việc một cách độc lập bằng cách phân tích header gói
và chuyển gói từ router này đến router kế cho đến khi gói đến được đích sau cùng Việc chọn bước chuyển kế tiếp cho một gói căn cứ vào kết quả phân tích header của gói và từ kết quả thực thi một thuật toán định tuyến Giải pháp này đôi khi không đủ
để hỗ trợ các nhu cầu mạng ngày nay, vì các router có thể trở thành các cổ chai của QoS, ngay cả khi IP precedence và DiffServ được dùng Trong công nghệ MPLS đã định nghĩa một giải pháp để cải thiện và đơn giản chức năng chuyển gói và để cung cấp sự đảm bảo QoS Mỗi gói được gán một nhãn định tuyến căn cứ vào một vài yếu tố bao gồm ưu tiên của gói và đích đến Chuyển mạch dựa vào nhãn là nhanh vì
nó cho phép các router đưa ra các quyết định chuyển gói dựa vào nội dung của một nhãn đơn giản thay vì phải thực hiện nhiệm vụ dò tìm phức tạp
Trang 18MPLS mang lại một số ưu điểm khác cho các mạng dựa vào IP bao gồm đảm bảo QoS gần như RSVP
2.2 Các cơ chế kiểm soát chất lượng phổ biến trong mạng IP:
Cho đến nay có ba nhóm cơ chế chính nhằm đạt được một chất lượng mạng tốt hơn mức Best-Effort truyền thống trên mạng IP, đó là:
2.2.1 Cung cấp dung lượng vượt yêu cầu:
Cung cấp lượng băng thông vượt mức yêu cầu là cơ chế kém nhất, vì hai cơ chế kia hoạt động theo nguyên lý chỉ dùng một số tối thiểu dung lượng để đáp ứng cho các hợp đồng dịch vụ Tuy nhiên, có vài yếu tố khiến cho giải pháp này trở nên hấp dẫn
- Chi phí cho băng thông trên đường trục đang giảm Bởi vì cung ứng về cáp đường dài trên mặt đất hiện nay là vượt quá nhu cầu và với công nghệ DWDM thì giá thành cho một bước sóng bổ sung hầu như là rất thấp
- Qui hoạch mạng đơn giản Việc tính toán khi nâng cấp chỉ theo nguyên tắc đơn giản là khi dung lượng yêu cầu nhiều hơn m% dung lượng khả dụng trong một khoảng thời gian nào đó thì tăng dung lượng của tuyến lên n%
- Việc cung ứng dự phòng được hoạch định dễ dàng Dung lượng truy xuất từ các nhánh là hoàn toàn biết được và tổng tốc độ số liệu không thể vượt quá tổng các liên kết truy xuất Khi có yêu cầu các liên kết truy xuất nhanh hơn,
có thể đưa ra quyết định nâng cấp dung lượng đường trục
Đây là giải pháp được dùng hầu hết trong các mạng đường trục IP Giả sử dung lượng luôn luôn thoả mãn cho giải pháp này, các gói IP có thể được nạp vào trong các frame truyền (ví dụ SONET) khi chúng đến, độ trễ và biến động trễ do độ trễ hàng đợi khác nhau trong quá trình truy xuất đường trục là nhỏ Yếu tố ảnh
Trang 19hưởng lớn nhất đến trễ là thời gian lan truyền dọc theo cáp Tuy nhiên, trong các mạng truy nhập ngoại vi thường không được lắp đặt nhiều cáp sợi quang, do đó nhìn chung dung lượng bị hạn chế Trong bối cảnh như vậy, để hỗ trợ QoS cao hơn mức Best-Offort thì điều có thể là phục vụ có phân biệt, phục vụ phần lưu lượng nào đó tốt hơn các phần còn lại bằng cách đăng ký tài nguyên một cách đặc biệt hay bằng cách xử lý ưu tiên cho chúng.
2.2.2 Đăng ký trước tài nguyên:
IntServ là kiến trúc đầu tiên được đặc tả bởi IETF để hỗ trợ QoS theo cơ chế đăng ký trước tài nguyên IntServ dùng giao thức RSVP để đăng ký tài nguyên cho từng luồng lưu lượng IntServ cũng gán một luồng số liệu đặc biệt vào khái niệm được gọi là lớp lưu lượng, lớp lưu lượng định nghĩa một mức dịch vụ nào đó Ví dụ,
có thể yêu cầu mức Best-Offort hay có thể chấp nhận một giới hạn về độ trễ nào đó Khi một lớp dịch vụ đã được gán cho một luồng số liệu, một thông điệp PATH được chuyển đi đến đích để xác định mạng có tài nguyên khả dụng hay không (dung lượng truyền, không gian bộ đệm,…) để hỗ trợ lớp dịch vụ này Nếu tất cả các thiết bị dọc theo đường dẫn đều thấy rằng có khả năng cung cấp tài nguyên theo yêu cầu, máy đích sẽ phát ra thông điệp RESV gửi đến nguồn để thông báo rằng có thể bắt đầu truyền số liệu Thủ tục này (RSVP) được lặp lại để xác nhận tài nguyên cần thiết vẫn còn khả dụng, còn gọi là quá trình làm tươi (refresh) Nếu tài nguyên yêu cầu không còn khả dụng nữa, máy thu sẽ gửi một thông điệp báo lỗi RSVP đến máy phát
Theo lý thuyết thì việc kiểm tra liên tục này có ý nghĩa là tài nguyên mạng được dùng một cách hiệu quả Khi tài nguyên khả dụng chỉ còn ở một mức tối thiểu, các dịch vụ với nhu cầu QoS nghiêm ngặt sẽ không nhận được thông điệp RESV và
sẽ biết rằng QoS không được đảm bảo Tuy vậy, dẫu cho IntServ có một số đặc tính hấp dẫn, nó vẫn có các vấn đề nội tại Ví dụ, IntServ không có phương cách để đảm bảo các tài nguyên cần thiết sẽ khả dụng khi cần đến Hơn nữa, việc đăng ký tài nguyên mạng trên căn bản từng luồng số liệu, ví dụ nhiều luồng hướng đến một
Trang 20server truyền thông trên mạng cục bộ, tất cả đều yêu cầu cùng một tài nguyên nhưng mỗi luồng lại được phục vụ một cách riêng rẽ Điều này dẫn đến thông điệp RESV phải được gửi đi một cách riêng biệt cho mỗi luồng Nói cách khác, IntServ không linh động và lãng phí tài nguyên mạng.
2.2.3 Ưu tiên hoá các dịch vụ và người dùng:
Thực chất QoS rất phong phú về ưu tiên Tại các điểm tập hợp trên mạng như router, bộ ghép kênh và chuyển mạch, các luồng số liệu với nhu cầu QoS khác nhau được kết hợp lại để truyền qua hạ tầng mạng chung Việc hỗ trợ QoS đúng mực cần có: một phương tiện để đánh dấu các luồng theo ưu tiên và cơ chế mạng để nhận dạng và tác động lên luồng theo ưu tiên đó
Với mô hình DiffServ của IETF, một thẻ nhỏ được gắn vào mỗi gói tuỳ vào lớp dịch vụ của nó Các luồng số liệu có cùng nhu cầu tài nguyên có thể được gom lại trên cơ sở thẻ nhận dạng này khi chúng đến router biên (edge router) Các router trong mạng lõi (core router) sẽ chuyển luồng số liệu đến đích dựa trên các thẻ định dạng mà không cần kiểm tra chi tiết các header của từng gói Vì hầu hết quyết định chuyển được đưa ra đều theo nguyên tắc này nên mạng lõi làm việc rất nhanh
Trong quá khứ, qui hoạch QoS hỗ trợ IntServ và DiffServ Hiện nay khuynh hướng nghiêng về dùng DiffServ kèm theo các bổ sung về khả năng đăng ký tài nguyên của RSVP tại biên Tại các biên của mạng, tài nguyên có xu thế hạn hẹp hơn nên không có nhiều luồng số liệu được duy trì
Một giải pháp tương tự để tăng tốc độ truyền số liệu qua mạng là MPLS, cũng là một thủ tục được đề xuất bởi IETF đã được giới thiệu ở phần trên Trong hoạt động IP thông thường, header của gói được kiểm tra tại các điểm trung chuyển (multiplexer, router hay switch) Điều này tốn nhiều thời gian và làm tăng tổng thời gian trễ Giải pháp hiệu quả hơn là gắn nhãn cho các gói sao cho việc phân tích các gói tại các điểm trung gian là không còn cần thiết nữa MPLS thực hiện điều này bằng cách gắn nhãn thích hợp cho các gói IP tại lối vào của các router biên trong mạng Lưu lượng đồng dạng nào đó có thể được nhóm lại trên một đường chuyển
Trang 21mạch nhãn đặc biệt, các kỹ thuật của công nghệ lưu lượng được áp dụng vào đường dẫn này để có một dung lượng nhằm đảm bảo một mức phẩm chất mong muốn cho dịch vụ.
2.3 Mô hình tích hợp dịch vụ IntServ:
Mô hình IntServ được IETF giới thiệu vào giữa thập niên 90 với mục đích hỗ trợ chất lượng dịch vụ từ đầu cuối tới đầu cuối Các ứng dụng sẽ nhận được băng thông đúng yêu cầu và truyền đi trong mạng với độ trễ cho phép
Trên thực tế giao thức RSVP là giao thức duy nhất dùng để báo hiệu cho mô hình IntServ Vì thế đôi khi người ta lầm lẫn dùng RSVP để nói về IntServ Thật ra, IntServ là kiến trúc hỗ trợ chất lượng dịch vụ mạng, còn RSVP là giao thức báo hiệu cho IntServ
Ngoài giao thức báo hiệu, mô hình tích hợp dịch vụ còn định nghĩa thêm một
số lớp dịch vụ
Một ứng dụng sẽ xác định đặc tính của luồng lưu lượng mà nó đưa vào mạng đồng thời xác định một số yêu cầu về dịch vụ mạng Đặc tính của lưu lượng Tspec (Traffic Specification) yêu cầu mức chất lượng dịch vụ Rspec (Reguired Specification) Vì thế các bộ định tuyến phải có khả năng thực hiện các công việc sau:
• Kiểm soát (Policing): Kiểm tra TSpec của luồng lưu lượng; nếu không phù hợp thì loại bỏ luồng
• Điều khiển chấp nhận: Kiểm tra xem tài nguyên mạng có đáp ứng được yêu cầu của ứng dụng hay không Nếu không thể đáp ứng, mạng sẽ từ chối
• Phân lớp (Classification): Phân loại gói dữ liệu căn cứ vào mức yêu cầu chất lượng dịch vụ của gói
• Hàng đợi và lập lịch (Queuing and scheduling): đưa gói dữ liệu vào hàng đợi tương ứng và quyết định huỷ gói dữ liệu nào khi xảy ra xung đột
2.3.1 Các lớp dịch vụ:
Trang 22Có hai lớp dịch vụ: đảm bảo dịch vụ (Guaranteed Service) và kiểm soát tải (Control load service).
Nhược điểm của lớp dịch vụ này là hiệu quả sử dụng tài nguyên mạng thấp
vì nó đòi hỏi mỗi luồng lưu lượng có hàng đợi riêng
2.3.1.2 Kiểm soát tải:
Các ứng dụng của dịch vụ này có thể chấp nhận khả năng mất dữ liệu và thay đổi độ trễ ở một mức độ nhất định Luồng dữ liệu khi đi vào mạng sẽ được kiểm tra đối chiếu với những đặc tả lưu lượng Tspec đã được đăng ký Nếu không phù hợp với các đặc tả đã được đăng ký trước thì dữ liệu sẽ được chuyển tiếp theo phương thức “nỗ lực tối đa”
2.3.2 Giao thức dành trước tài nguyên RSVP:
RSVP là giao thức báo hiệu cung cấp thủ tục để thiết lập và điều khiển quá trình chiếm giữ tài nguyên, hay nói cách khác RSVP cho phép các chương trình ứng dụng thông báo cho mạng những yêu cầu về mức chất lượng dịch vụ; và mạng sẽ hồi đáp chấp nhận hoặc không chấp nhận yêu cầu đó
Các bản tin RSVP được các bộ định tuyến hay các bộ chuyển mạch trên liên kết giữa hai đầu cuối gửi và nhận trao đổi với nhau để đáp ứng yêu cầu về mức chất lượng dịch vụ của ứng dụng
Trang 23RSVP có 2 bản tin cơ bản: bản tin Path và bản tin Resv Bản tin Path mang thông tin về đặc tả luồng lưu lượng Tspec và các thông tin như: địa chỉ IP của nút gửi, địa chỉ IP nút nhận, chỉ số cổng UDP Và khi nhận được bản tin Path, nút mnạg đích sẽ gửi lại bản tin Resv Bản tin Resv sẽ gửi kèm theo phần mô tả yêu cầu Rspec chỉ định kiểu dịch vụ tích hợp là kiểm soát tải hay đảm bảo dịch vụ; ngoài ra còn có dấu hiệu nhận dạng luồng (flow descriptor) mà mỗi bộ định tuyến trung gian
sẽ tiến hành quá trình điều khiển chấp nhận (admission control) Nếu yêu cầu không được chấp nhận, do không đủ tài nguyên mạng thì bộ định tuyến sẽ báo lỗi về phía đầu thu Nếu yêu cầu được chấp nhận thì bộ định tuyến sẽ gửi bản tin Resv đến bộ định tuyến đã gửi bản tin Path cho nó
Ngoài ra, RSVP là giao thức mềm, có nghĩa là các bản tin Path và Resv sẽ được gửi lại sau khoảng thời gian nhất định để duy trì lâu dài sự chiếm giữ tài nguyên Nếu sau khoảng thời gian này không có bản tin nào gửi đi, sự dự trữ tài nguyên sẽ bị xoá bỏ Điều này sẽ có một số ưu điểm và nhược điểm được trình bày sau:
Mặt khác, lưu lượng RSVP có thể đi qua bộ định tuyến không hỗ trợ RSVP Tại những bộ định tuyến này dịch vụ được phục vụ theo mô hình nỗ lực tối đa
Nói tóm lại, RSVP đóng vai trò quan trọng trong quá trình triển khai việc chuyển tải nhiều dịch vụ như: âm thanh, hình ảnh, và dữ liệu trong cùng một hạ tầng mạng Các ứng dụng có thể lựa chọn nhiều mức chất lượng dịch vụ khác nhau cho luồng lưu lượng của mình
2.3.3 Kiến trúc IntServ:
Cấu trúc của các bộ định tuyến và các bộ chuyển mạch có hỗ trợ RSVP trong mạng:
Trang 24Hinh 2.3 Mô hình dịch vụ IntServ
Như vậy ta thấy cấu trúc gồm các khối:
• Khối điều khiển lưu lượng bao gồm: bộ phân loại (Classifier), bộ lập lịch gói (Scheduler)
• Khối điều khiển thu nhận và thiết lập dự trữ bao gồm: thực thể điều khiển thu nhận và thực thể thiết lập dự trữ
Đầu tiên các ứng dụng đưa ra yêu cầu lớp dịch vụ: đảm bảo dịch vụ hoặc kiểm soát tải đồng thời đặt đường dẫn và chiếm giữ tài nguyên mạng cho việc truyền dữ liệu Khối điều khiển thu nhận sẽ xem xét có thể đáp ứng được các yêu cầu mà dịch vụ đưa ra hay không Bộ phân loại tiến hành phân loại và đưa các gói
dữ liệu nhận được vào hàng đợi riêng Bộ lập lịch sẽ lập cách xử lý để đáp ứng yêu cầu về chất lượng dịch vụ
Hình 2.4 Kiến trúc IntServ.
Trong hình vẽ, ở bước 1, các ứng dụng đưa ra yêu cầu mức chất lượng dịch
vụ dành cho luồng lưu lượng xác định qua giao diện dịch vụ ứng dụng Bộ điều khiển thu nhận và thiết lập dự trữ đáp ứng yêu cầu của các ứng dụng bằng cách tạo
ra các bản tin của giao thức RSVP yêu cầu chiếm giữ tài nguyên Bản tin này sẽ đi qua các bộ định tuyến nằm trên đường dẫn từ đầu gửi đến đầu thu Tại mỗi bộ định
Trang 25tuyến, khối điều khiển thu nhận sẽ tiến hành quá trình điều khiển chấp nhận kết nối, quyết định xem có thể đáp ứng được yêu cầu chất lượng dịch vụ mà ứng dụng đưa
ra hay không Nếu được, bộ định tuyến sẽ dựa vào thông tin trong bản tin RSVP để cấu hình cho bộ điều khiển lưu lượng
Chúng ta đã xem xét kiến trúc của mô hình tích hợp dịch vụ cũng như một giao thức rất quan trọng RSVP Mô hình này cho phép triển khai các ứng dụng thời gian thực và lưu lượng truyền thông trên cùng một hạ tầng mạng
2.4 Mô hình phân biệt dịch vụ DiffServ:
2.4.1 Mô hình:
DiffServ là một tập hợp công nghệ cho phép nhà cung cấp dịch vụ mạng đưa
ra các dịch vụ mạng khác nhau cho khách hàng cũng như cho các dòng lưu lượng mạng của họ DiffServ được dự trù là một môi trường để phân biệt dịch vụ khả thi
và cho phép một giải pháp module hoá các mục tiêu QoS cho các nhu cầu khác nhau của ứng dụng
Cơ sở của các mạng DiffServ là các router bên trong mạng lõi có khả năng chuyển các gói của các lưu lượng khác nhau theo cách ứng xử trên từng bước mạng khác nhau DiffServ đưa ra khái niệm DSCP, dùng 6 bit của trường ToS trong header của gói IP và do đó có thể chỉ định đến 64 giá trị mã khác nhau PHB của gói IP được chỉ ra bởi mã DSCP Kiến trúc DiffServ không dùng bất kỳ sự báo hiệu nào giữa các router, tất cả các quyết định chuyển gói đều dựa theo mã DSCP
Kiến trúc DiffServ chứa hai thành phần chính Một là nguyên tắc ứng xử (PHB) trên đường dẫn chuyển gói và thứ hai là chính sách cấu hình các thông số trên đường dẫn chuyển gói cho từng PHB
Kiến trúc DiffServ có thể được xem như là bộ tinh chế của mô hình quan hệ
ưu tiên trong đề xuất đánh dấu ưu tiên IPv4 Kiến trúc này hoàn toàn có thể làm việc với các ứng dụng hiện hữu mà không yêu cầu bất cứ thay đổi nào đối với API của chúng
Trang 262.4.2 Phát triển QoS theo cơ chế DiffServ:
2.4.2.1 Tổng quan về triển khai dịch vụ theo kiến trúc DiffServ:
Để nhận các dịch vụ từ nhà cung cấp dịch vụ, người dùng cần phải có hợp đồng mức dịch vụ SLA với nhà cung cấp dịch vụ Một SLA về cơ bản là chỉ ra lớp dịch vụ được hỗ trợ và lượng tải cho phép trong mỗi lớp Một SLA có thể là tĩnh hay động (Static SLA hay dynamic SLA) SLA tĩnh được thoả ước theo định kỳ từng tháng hay năm Một SLA động đòi hỏi người dùng phải dùng giao thức báo hiệu để yêu cầu dịch vụ cho từng cuộc gọi Người dùng có thể đánh dấu vào gói IP
để chỉ ra dịch vụ mong muốn và router nội bộ sẽ đánh dấu gói IP trên cơ sở đó Tại ngõ vào mạng của nhà cung cấp dịch vụ, gói sẽ được phân loại và điều chỉnh theo SLA đã được ký kết Lượng bộ đệm cần cho các hoạt động này cũng được chỉ ra trong SLA Khi gói đi từ domain này sang domain khác, trường ToS của nó có thể được đánh dấu lại dựa trên SLA đã ký kết giữa các domain DiffServ sử dụng các
cơ chế phân loại, chỉnh dạng và lập lịch để cung cấp các dịch vụ như:
- Premium Service cho các ứng dụng yêu cầu độ trễ và biến động trễ đều nhỏ
- Assured Service cho các ứng dụng yêu cầu độ tin cậy tốt hơn dịch vụ Effort
Best Olympic Service cung cấp bộ ba dịch vụ gồm vàng, bạc và đồng với chất lượng dịch vụ của vàng là tốt nhất và đồng là thấp nhất
Kiến trúc DiffServ chỉ định nghĩa các mã DSCP ghi trong trường ToS và các PHB Còn dịch vụ cụ thể như thế nào là do các nhà cung cấp dịch vụ quy định
DiffServ khác đáng kể so với IntServ Thứ nhất, nó chỉ có một số giới hạn các lớp dịch vụ được chỉ định Vì dịch vụ được gán theo lớp nên lượng thông tin trạng thái lớn hay nhỏ là tuỳ vào số lượng lớp thay vì số lượng luồng như IntServ, nhờ đó DiffServ có tính khả triển (scalability) cao Thứ hai, các hoạt động phân loại, điều chỉnh phức tạp chỉ diễn ra ở biên giới mạng Các router bên trong domain chỉ cần phân loại các BA Do đó, dễ dàng thực hiện và triển khai DiffServ Các mạng của nhà cung cấp dịch vụ thường có các router biên kết nối với khách hàng và
Trang 27nối với các core router Core router cần phải chuyển gói đi rất nhanh nên nhiệm vụ của chúng phải đơn giản hơn Các router biên không cần phải chuyển gói đi rất nhanh vì hầu hết các liên kết với khách hàng đều chậm Vì vậy các router biên có nhiều thời gian để phân loại và điều chỉnh lưu lượng Các router biên tại các điểm truy nhập mạng NAP là ngoại lệ vì chúng phải chuyển gói đi rất nhanh và còn phải
xử lý phân loại và điều chỉnh nên phải được trang trí tốt nhất
Trong mô hình DiffServ có thể gia tăng triển khai dịch vụ Assured Service Các router không có khả năng DiffServ sẽ bỏ qua trường ToS của gói Assured Service và chuyển gói dạng này theo dịch vụ Best-effort Tuy nhiên, vì các gói của Assured Service không bị bỏ rơi tại các DiffServ router nên chất lượng toàn cục của lưu lượng Assured Service vẫn tốt hơn so với lưu lượng của Best-offort
Assured Service có thể được thực hiện như sau: Đầu tiên, sự phân loại và điều chỉnh được thực hiện tại router ngõ vào của mạng phía ISP Nếu tốc độ của lưu lượng không vượt quá tốc độ bit được chỉ ra trong SLA thì chúng được xem nhu phù hợp với đặc tả người dùng (user profile) và ngược lại Thứ hai, tất cả các gói phù hợp hay không phù hợp đều được đặt vào một hàng đợi để tránh sai thứ tự Thứ
ba, hàng đợi được quản lý bởi một cơ chế quản lý hàng đợi gọi là phát hiện sớm ngẫu nhiên RED RED là cơ chế quản lý hàng đợi huỷ bỏ gói sớm để ngăn ngừa nghẽn mạng Điều này sẽ tác động lên cơ chế điều khiển luồng TCP tại các đầu cuối khác nhau khiến cho tốc độ truyền sẽ thay đổi Bằng cách này RED có thể ngăn chặn hàng đợi của router khỏi bị tràn và do đó tránh được động thái bỏ đuôi (tail-drop)
Dịch vụ Best-effort có thể được xử lý theo cách khác hay tượng tự với lưu lượng không phù hợp của dịch vụ Assured Service
Premium Service cung cấp dịch vụ có yêu cầu độ trễ và biến động trễ thấp cho khách hàng nên sẽ đảm bảo truyền với tốc độ đỉnh một cách cố định Mỗi khách hàng sẽ có một SLA với ISP, trong đó chỉ ra tốc độ đỉnh mong muốn cho một luồng hay một tập hợp nhiều luồng Khách hàng phải đảm bảo không để vượt quá tốc độ
Trang 28đỉnh đã ký kết, nếu không lưu lượng sẽ bị huỷ Về phía ISP sẽ đảm bảo băng thông theo hợp đồng phải luôn khả dụng cho lưu lượng của khách hàng.
Trong các mạng ISP, sự tập trung lưu lượng từ các router biên đến các core router bên trong là không thể tránh khỏi, nhưng điều này không thành vấn đề vì tốc
độ ngõ ra lớn hơn tốc độ ngõ vào rất nhiều Tuy nhiên, sự tập trung lưu lượng đến core router từ các core router khác thì không thể đảm bảo điều tương tự Bản thân DiffServ không thể giải quyết được khó khăn này Công nghệ lưu lượng phải được dùng để tránh nghẽn gây ra bởi sự phân phối lưu lượng mất cân đối
Bằng cách hạn chế lượng băng thông được yêu cầu bởi lưu lượng Premium Service, người quản trị mạng có thể đảm bảo lưu lượng của Premium Service không làm ảnh hưởng xấu đến lưu lượng của các dịch vụ khác Một cách khác là dùng WFQ giữa hàng đợi của Premium Service và hàng đợi Assured Service
2.4.2.2 Phương pháp phát triển hệ thống DiffServ:
Công việc phát triển hệ thống DiffServ liên quan đến tổ chức và phát triển hai thành phần chính là bộ điều chỉnh lưu lượng (traffic conditioner) tại router biên
và các PHB tại các router, đặc biệt là các core router Lộ trình của các gói tin là khi vào router biên chúng sẽ được điều chỉnh lưu lượng cho phù hợp với SLA, sau đó được đưa tới giao tiếp lối ra của router, tại đó chúng sẽ được đánh mã DSCP theo PHB (là EF, AF hay BE) tương ứng với SLA Công việc này liên quan đến sự phân loịa và chuyển gói vào hàng đợi tương ứng Các thức kiểm soát các hàng đợi này được xác định bởi cơ chế lập lịch (scheduling mechanism) được dùng Bộ lập lịch cho gói tin chịu trách nhiệm hướng dẫn giải phóng các gói tin từ các hàng đợi khác
và truyền chúng lên mạng một cách có trật tự Bên trong mạng, căn cứ vào các PHB của từng gói các core router sẽ chuyển các gói đi theo cách xử lý cho từng PHB Như vậy trong phần tử mạng đầu tiên là router biên sẽ được phát triển một bộ điều chỉnh lưu lượng và các PHB Trong phần tử mạng kế tiếp là các core router chỉ cần phát triển các PHB
a Phát triển bộ điều chỉnh lưu lượng:
Trang 29Bộ điều chỉnh lưu lượng sẽ gồm các thành phần con là classifier, marker, meter, remarker hay shaper hay dropper Thông thường các thành phần này được thực hiện bằng cách dùng một token bucket đơn và một token buket kép (Dual Token Bucket) Qua đó các thông số của luồng đã cam kết theo SLA được cấu hình thành một token bucket profile Các gói lấy được token được xem là các gói hợp lệ (in-profile packet) và các gói còn lại là không hợp lệ (out-profile) Các token bucket bảo vệ các luồng với cửa sổ nhỏ, ngăn chặn sự mất gói bằng cách chỉ đánh dấu hợp lệ.
Hình 2.5 Cấu trúc logic của bộ điều chỉnh lưu lượng.
b Phát triển các PHB:
Sau khi các gói đã đi qua giao tiếp đầu vào của một router mà không bị huỷ
sẽ được chèn vào giao tiếp đầu ra của router Hàng đợi tại đầu ra có thể là một hàng đợi đơn giữ tất cả các gói của các lớp lưu lượng hay gồm một số các hàng đợi, mỗi hàng đợi giữ gói cho mỗi lớp lưu lượng khác nhau Mỗi PHB được thể hiện qua hai
cơ chế: cơ chế quản lý hàng đợi và cơ chế lập lịch gói
* Cơ chế quản lý hàng đợi:
Lưu lượng của mỗi user được đánh dấu là in-profile hay out-profile Các gói in-profile được gán một mức huỷ gói (drop precedence) thấp hơn các gói out-profile
và được mã hoá bằng mã DSCP ghi trong trường ToS của gói Nguyên lý quản lý hàng đợi tích cực RED được dùng để quản lý hàng đợi cho DiffServ RED cho phép
Trang 30router huỷ gói trước khi hàng đợi bị tràn RED làm được điều này bằng cách huỷ các gói theo một xác suất tùy thuộc vào chiều dài hàng đợi trung bình Để thực hiện các mức huỷ khác nhau hay để hình thành các AFij, có các phương pháp đã được dùng như WRED, nguyên lý hàng đợi gồm nhiều RED gọi là GRED.
về thời gian thực, trong DiffServ thì dành cho EF PHB Những lưu lượng khác gồm
AF PHB và BE được lập lịch chuyển đi theo cơ chế WFQ
2.4.3 Vấn đề quản lý tài nguyên:
2.4.3.1 Khái quát hiện trạng:
Trang 31Trong quá trình thực hiện QoS cho mạng IP, điều dễ nhận thấy là mặc dù kiến trúc IntServ đảm bảo cung cấp QoS một cách chắc chắn nhưng lại vấp phải vấn
đề khả triển Vì vậy, IETF đã đề xuất DiffServ như là giải pháp thay thế, trong đó lấy sự khác biệt dịch vụ làm nền tảng và chia thành các lớp dịch vụ khác nhau, kiến trúc này đã khắc phục được nhược điểm của IntServ vì có tính khả triển rất tốt Tuy nhiên, để đáp ứng các nhu cầu của đa dạng ứng dụng trên thực tế, kiến trúc được triển khai cần phải có các giải thuật quản lý lưu lượng nào đó
Các giải thuật lưu lượng có thể được phân loại theo đơn vị thời gian hoạt động của chúng hay theo khả năng điều khiển Do đó, các giải thuật này có thể hoạt động theo mức gói, mức khối số liệu hay mức kết nối Trong số các giải pháp điều khiển lưu lượng theo từng cuộc gọi hay từng kết nối thì điều khiển chấp nhận là một trong số các giải pháp phổ dụng nhất Điều khiển chấp nhận tuỳ theo vị trí hoạt động mà có thể là tập trung hay phân tán Đại diện tiêu biểu cho điều khiển chấp nhận nối phân tán là RSVP và một số các giải thuật khác
Các giải pháp tập trung tiêu biểu được đề xuất cho mạng DiffServ là giải pháp dùng một thành phần điều khiển gọi là Bandwidth Broker(BB)
Ý tưởng cung cấp cơ chế điều khiển chấp nhận nối theo luồng cho các mạng
IP DiffServ nhằm cải thiện chất lượng dịch vụ đã nhận được sự đồng thuận trong cộng đồng nghiên cứu Internet Cần thiết định nghĩa thêm chức năng điều khiển chấp nhận kết nối cho kiến trúc DiffServ, để xác định xem có cho phép một luồng lưu lượng mới hay không Thực tế, một hạn chế của DiffServ là thiếu một cơ chế điều khiển chấp nhận kết nối chuẩn và do đó không thể giải quyết một cách cơ bản bài toán nghẽn trên mạng Internet Khi có quá tải trên một lớp dịch vụ thì tất cả các luồng của lớp dịch vụ này đều chịu một sự suy giảm chất lượng trầm trọng Một vài giải thuật điều khiển chấp nhận nối cùng với các chỉ dẫn tham khảo trong đó Các
đề xuất này cùng chia sẻ ý tưởng mỗi nút mạng nên chấp nhận các luồng mới tuỳ vào các đo lường nghẽn giữa nguồn và đích và tiêu chuẩn quyết định cục bộ Không