Nghiên cứu cấu trúc và cơ chế đảm bảo chất lượng dịch vụ trên mạng internet (internet qos architectures and mechanisims for quality of service)

Do đó : mạng hiện tại không những không thể đảm bảo về chất lượng dịch vụ mà còn không thể đáp ứng tốt với các ứng dụng mới như : điện thoại Internet , hội nghị hình ảnh, hay multimedia

TRẦN THANH PHONG

Nghiên cứu cấu trúc và cơ chế đảm bảo chất lượng dịch vụ trên

mạng Internet

Internet QoS : Architectures and mechanisims for

Quality of Service

Chuyên ngành : Kỹ thuật điện tử – viễn thông

Mã số ngành : 02.07.01

LUẬN VĂN THẠC SĨ

Tp Hồ Chí Minh , tháng 08 năm 2003

Đại Học Quốc Gia Thành Phố Hồ Chí Minh

Cán bộ hướng dẫn khoa học :

PGS.TS Vũ Đình Thành

Cán bộ chấm nhận xét 1 :

TS Lê Tiến Thường

Cán bộ chấm nhận xét 2 :

TS Phạm Hồng Liên

Luận văn Thạc Sĩ được bảo vệ tại hội đồng chấm bảo vệ luận văn

Trường Đại Học Bách Khoa Tp.Hồ Chí Minh

Ngày 27 tháng 08 năm 2003 Có thể tìm hiểu luận án tại thư viện cao học Trường Đại Học Bách Khoa – Đại Học Quốc Gia TP.HCM

-0O0 -0O0

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ và tên : Trần Thanh Phong Phái : Nam

Ngày tháng năm sinh : 14-11-1972 Nơi sinh : Vĩnh Long

Chuyên ngành : Kỹ Thuật Điện tử – viễn thông Mã số : 02.07.01

Khoá (năm trúng tuyển) : 11 (2000)

I Tên đề tài :

Nghiên cứu cấu trúc và cơ chế đảm bảo chất lượng

dịch vụ trên mạng Internet

II Nhiệm vụ đề tài :

- Nghiên cứu cấu trúc và cơ chế của 3 dịch vụ : Integrated Service , Differentiated Serivce , Multi-protocol Label Switching và kỹ thuật Traffic Engineering

- Xây dựng mô hình mô phỏng của từng dịch vụ

- Đánh giá và so sánh kết quả ưu , khuyết điểm giữa các dịch vụ

- Đưa ra hướng phát triển trong tương lai

III Ngày giao nhiệm vụ (ngày bảo vệ đề cương) : 15-12-2002

IV Ngày hoàn thành nhiệm vụ (ngày bảo vệ luận văn) : 28-08-2003

V Họ và tên cán bộ hướng dẫn : PGS.TS Vũ Đình Thành

VI Họ và tên cán bộ chấm nhận xét 1 : TS Lê Tiến Thường

VII Họ và tên cán bộ chấm nhận xét 2 : TS Phạm Hồng Liên

Cán bộ hướng dẫn Cán bộ chấm nhận xét 1 Cán bộ chấm nhận xét 2

Vũ Đình Thành Lê Tiến Thường Phạm Hồng Liên

Nội dung và đề cương luận văn Thạc Sĩ đã được Hội Đồng Chuyên Ngành thông qua

Tp.HCM , ngày 12 tháng 09 năm 2003

Trưởng phòng đào tạo SĐH Chủ nhiện ngành

Vũ Đình Thành

Để hoàn tất luận văn này trong thời gian tương đối ngắn , ngoài sự nổ lực của cá nhân tôi còn có sự giúp đỡ rất nhiệt tình , cùng những góp ý rất quý báu của thầy hướng dẫn PGS.TS Vũ Đình Thành nên tôi vô cùng cảm ơn đến thầy

Tôi cũng cám ơn đến các đồng nghiệp của tôi ở công ty VDC thuộc Bưu điện TPHCM : anh Nguyễn Cao Văn (tổ trưởng tổ mạng ) , anh Phạm Thanh Hùng (trưởng đài điều hành mạng OMC) và các bạn đồng nghiệp cũng đã giúp đỡ tôi trong việc tìm tài liệu , cũng như trao đổi kinh nghiệm

Cuối cùng , tôi cũng xin chân thành cảm ơn gia đình tôi , cùng bạn bè đã động viên giúp đở tinh thần để tôi hoàn thành tốt luận văn này

Trần Thanh Phong

Tóm lượt

Internet đã trở thành một phần tối cần thiết trong cuộc sống cũng như trong công việc của chúng ta Mặc dù mạng Internet ngày nay phát triển rất nhanh không những về mức độ hoạt động mà còn về kích thước, nhưng cấu trúc cơn bản của nó vẫn không thay đổi nhiều so với những năm trước Cụ thể Internet vẫn hoạt động như một mạng “datagram network” , mà ở đó mỗi gói sẽ được phân phối một cách riêng lẽ thông qua mạng Thời gian gởi các gói tin không được đảm bảo và các gói tin có thể

bị rơi hay bị loại bỏ bởi vì nghẽn bên trong mạng Do đó : mạng hiện tại không những không thể đảm bảo về chất lượng dịch vụ mà còn không thể đáp ứng tốt với các ứng dụng mới như : điện thoại Internet , hội nghị hình ảnh, hay multimedia trực tuyến Các ứng dụng thời gian thực này (real time applications) không thể chấp nhận độ trễ cũng như độ mất mát gói tin trên đường truyền

Để khắc phục vấn đề này , vào đầu thập niên 90 tổ chức IETF (Internet Enginering Task Force ) đã phát triển các kỹ thuật mới và chuẩn hóa chúng để đảm bảo tài nguyên và sự đa dạng các dịch vụ dưới thuật ngữ Quality of Service (QoS) chất lượng dịch vụ Trong luận văn này , chúng ta sẽ khảo sát 4 loại kỹ thuật mới mà nó đã và đang được tích hợp vào khối chính để hỗ trợ cho mạng Internet [2]: dịch vụ

đảm bảo chất lượng dựa trên từng dòng lưu lượng “flow-based” gọi là “Integrated

Service“ (IntServ ) và dịch vụ đảm bảo chất lượng dựa trên các lớp dịch vụ khác

nhau “classes-based” gọi là “Differentiated Service” ( DiffServ ) là hai kỹ thuật

giải quyết những vấn đề về dự phòng và phân phối tài nguyên cho các loại lưu lượng

khác nhau trong mạng Kỹ thuật chuyển nhãn đa giao thức (Multi-Protocol Label

Switching : MPLS) và một kỹ thuật điều khiển lưu lượng (Traffic Engineering ) giúp

hỗ trợ sự hoạt động của mạng , đặc biệt cách mà các luồng tin được định tuyến bên trong mạng Đề tài được chia thành 6 chương :

Chương đầu đưa ra các vấn đề mà Internet hiện nay đang gặp phải và sau đó

trình bày các khái niệm về QoS , các đặc tính cũng như các thông số cho QoS

Chương 2 tập trung vào giải thích chi tiết về cấu trúc và cơ chế hoạt động của

3 khung làm việc (frameworks) của Integrated Service, Differentiated Service và MPLS, và ứng dụng của kỹ thuật điều khiển lưu lượng (Traffic Engineering ) Thêm vào đó, chúng ta cũng khảo sát một số giải thuật dùng cho việc mô phỏng

Chương 3 xây dựng mô hình , mô phỏng , đồng thời thiết lập một tiến trình mô

phỏng với một mạng cụ thể để minh họa cấu trúc và giải thuật của từng frameworks , để thấy rõ những hiệu quả và các hạn chế của nó

Chương 4 cho biết kết quả mô phỏng của cả ba loại frameworks theo các tham

số chính để đánh giá chất lượng dịch vụ (Quality of Service) dưới dạng đồ thị biễu diễn băng thông , độ trễ và độ thất thoát gói tin Đồng thời , cũng có thể xem tiến trình mô phỏng mạng một cách trực quan thông qua công cụ Network Simulator

Chương 5 dựa vào kết quả mô phỏng cho từng Framwork ở trên , chúng ta sẽ

đánh giá và so sánh kết quả mô phỏng từ một tập các thông số khác nhau của người sử dụng để làm rõ những ưu và khuyết điểm của từng loại dịch vụ

Chương cuối sẽ tóm tắt nội dung của đề tài , các hạn chế và đưa ra hướng

nghiên cứu trong tương lai để giải quyết những giới hạn của 3 frameworks trên

Abstract

The Internet has became an indispensable part of our life and work Although the Internet network now develops rapidly not only on the performance and but also in size, its basic architecture remains unchanged from its early days The Internet still oparates as a datagram network, where each packet is delivered individually through the network Delivery time of packet is not guaranteed, and packets may even be dropped or discarded because of congestion inside the network Therefore, the current network is not only unable to guarantee the quality of service but also unable to mesh well with new applications such as Internet telephone , digital video conferencing or multimedia on line , which cannot tolerate delay jitter or loss of data in transmission

To overcome these problem , in the early 1990s the Internet Engineering Task Force (IETF) has developed new technologies and standards to provide ressource assurance and service differentiation in the Internet , under the term quality of service In this project , we will examine the four technologies that have emerged as core building blocks for supporting QoS on the Internet Integrated Service and Differentiated Service are two technologies that address the issues of reserving and allocating resources to various types of flows in a network Multiprotocol Label Switching (MPLS) and traffic engineering help to improve the performance , in particular, the way traffic flows are routed inside back-bone networks The thesis divide into six main chapters :

The first chapter presents some big problems on the Internet ,QoS concepts and its chararterization as well as QoS parameters

Chapter 2 focuses on detail explaination of architectures and mechanisms of three frameworks (Integrated Service , Differentiated Service and Multiprotocol Label Switching ) as well as some implementation of the Traffic Engineering technology In addition, we also examine some algorithms to apply into simulation models and topologies

Chapter 3 will set up models and simulations and build a simulation scenario with a particular topology to illustrate the architecture and mechanism as well as useful effects and some limitations of each service

Chapter 4 shows some simulation results of the three frameworks based on some main parameters of the Quality of Service such as a graph of bandwidth , a graph

of delay and a table of the packet loss rate In addition , we are also seen a simulation scenario with graphic interface supported by a Network Simulator tool

Chapter 5 will evaluate the results based on the above simulations as well as compare the simulation results from a different parameters entered by users to clarify some strengths and limitations of each services

The last chapter summarizes the project , some limitations and give future study directions to solve the limitation of the frameworks

Nội dung

Chương 1 : Giới thiệu về Quality of Services trên Internet …8

1.1 Vấn đề Internet hiện nay 8

1.2 Các khái niệm về QoS 8

1.3 Protocols và Frameworks của QoS 10

1.4 Mục đích và đối tượng của đề tài ……….12

Chương 2 : Cấu trúc và cơ chế của các Frameworks của QoS………13

2.1 Integrated Services (IntServ) ……… 13

2.1.1 Giới thiệu về Integrated Services ………13

2.1.2 Cấu trúc của Integrated Services ………13

2.1.3 Mô hình dịch vụ của Integrated Services ……….23

2.2 Differentiated Services(DiffServ) ………26

2.2.1 Giới thiệu về Differentiated Services 26

2.2.2 Cấu trúc của Differentiated Services ………27

2.2.3 Mô hình dịch vụ của Differentiated Services ……….31

2.2.4 Các loại Per-hop Behavior 32

2.2.5 Quản lý bộ đệm và tài nguyên ……… 38

2.3 Multi-Protocol Label Switch(MPLS) ………42

2.3.1 Giới thiệu về MPLS ……… 42

2.3.2 Các hoạt động cơ bản của MPLS ……… 44

2.3.3 Các thành phần của MPLS ……….45

2.3.4 Giao thức phân bố nhãn (Label Distribution Protocol) ……….48

2.3.5 Sự phân bố và gán nhãn ………52

2.3.6 MPLS và DiffServ ………52

2.3.7 MPLS với kỹ thuật điều khiển lưu lượng (Traffic Engineering) 53

Chương 3 : Xây dựng mô hình mô phỏng……… 57

3.1 Giới thiệu về công cụ Network Simulator , ngôn ngữ OTCL và C++ phục vụ cho việc mô phỏng ………57

3.2 Mô hình mô phỏng cho IntServ ………59

3.3 Mô hình mô phỏng cho DiffServ ………65

3.4 Mô hình mô phỏng cho MPLS ………70

Chương 4 : Kết quả mô phỏng……… 74

4.1 Kết quả mô phỏng IntServ ………80

4.2 Kết quả mô phỏng DiffServ ……….85

4.3 Kết quả mô phỏng MPLS ……….91

Chương 5 : Đánh giá kết quả………96

5.1 So sánh giữa IntServ và DiffServ ……… 96

5.2 MPLS và ATM 97

Chương 6 : Hạn chế và hướng nghiên cứu tương lai ………99

6.1 Tóm tắt công việc ……….99

6.2 Những hạn chế của đề tài ………100

6.3 Hướng nghiên cứu tương lai ………101

Tài liệu tham khảo ……….103

Chương 1 : Giới thiệu về Quality of Service

1.1 Vấn đề Internet hiện nay :

Như đã nói ở trên , Internet hoạt động theo mô hình datagram cùng với giao thức TCP/IP , FTP hay UDP (Uniform Distribution Protocol) đã chứng tỏ được khả năng cung cấp các loại dịch vụ và một số nhu cầu của users Tuy nhiên, nó bộc lộ rõ một số hạn chế chẳng hạn như [2]:

™ Thứ nhất : mạng không thể đáp ứng hay hỗ trợ về chất lượng dịch vụ , sự đa

dạng của các dịch vụ đặc biệt các ứng dụng thời gian thực (real time application như : điện thoại Internet, hội nghị hình ảnh ,hay multimedia).Các ứng dụng này rất nhạy cảm với độ trễ và tốc độ của kênh truyền

™ Thứ hai : Cơ chế định tuyến đơn giản chẳng hạn như vector khoảng cách

(Distant-vector), đường đi ngắn nhất (Open Shortest Path First :OSPF ) or Broder Gateway Protocol , chủ yếu dựa trên số hops và chi phí của các links (link costs) Mặc dù , việc tiếp cận này làm cho mạng khá đơn giản, nhưng rõ ràng tài nguyên mạng không được phân bố tốt và chưa tối ưu đặc biệt là ở các trục chính của mạng “backbone link“

™ Thứ ba : chưa tối ưu hoạt động mạng , đặc biệt trong một số trường hợp sự

mất cân bằng tải ở trục chính backbone có thể dẩn tới sự dao động về lưu lượng giữa các links Điều này là một trong những yếu tố chính dẫn tới tình trạng nghẽn mạch nghiêm trọng trong thời gian dài Đó là vấn đề “Fish Problem“ mà ta sẽ xem xét sau trong phần điều khiển lưu lượng

1.2 Khái niệm về QoS :

Trong thực tế ngày nay , nhu cầu sử dụng dịch vụ trong mạng Internet hay mạng viễn thông ngày càng cao và rất đa dạng , cụ thể có một số ngừơi sử dụng có nhu cầu cao hơn những người khác và họ sẵn sàng trả chi phí cho nhu cầu đó Chẳng hạn như , một người sử dụng Internet đang lướt WEB trên mạng , đồng thời anh ta cũng muốn downoad các phim mới để xem trực tuyến , trong khi đó một số khác có

nhu cầu hội thoại bằng hình ảnh trên mạng Vấn đề đặt ra là với các nhu cầu cao và

đa dạng như thế cùng với các đặc tính rất khác nhau của các ứng dụng , đặc biệt là các ứng dụng thời gian thực (real time application ) rất nhạy với độ trễ của gói tin như : Digital Video Conference , Intenet Telephone hay multimedia Tuy nhiên cũng có các ứng dụng không đòi hỏi độ trễ thấp như : E-mail, File Transfer, Remote Access

Do đó đòi hỏi các nhà cung cấp dịch vụ (ISP) phải có một tiêu chuẩn dịch vụ (Quality

of Service : QoS ) để nhằm thõa mãn các nhu cầu trên Ngoài ra , QoS phải được xây dựng trên mô hình OSI để có thể thích nghi với các mạng Internet đang hiện có Một số thông số cơ bản nhất để đánh giá chất lượng dịch vụ được IETF [1] đưa ra là :

™ Băng thông tối thiểu (Minimum Bandwidth) : Băng thông tối thiểu mà một

ứng dụng yêu cầu

™ Độ trễ (Delay) : độ trễ trung bình của một gói tin bao gồm ba thành phần chính : độ trễ của kênh truyền (propagation delay ) chủ yếu do tốc độ ánh sáng , độ trễ nguồn phát (transmission delay) là khoảng thời gian gởi gói tin lên đường truyền và độ trễ do hàng đợi (queuing delay) do gói tin phải

đợi trong các hàng đợi

™ Độ trễ Jitter (Delay Jitter) : Các gói tin khác nhau có độ trễ tổng cộng

khác nhau tại bộ thu Sự chênh lệch về độ trễ lớn nhất và độ trễ nhỏ nhất mà các gói tin được nhận tại bộ thu được gọi là Delay Jitter Độ trễ Jitter rất quan trọng đối với các ứng dụng thời gian thực Nó làm giảm đáng kể chất lượng dịch vụ hay méo dạng tín hiệu tại đầu thu Hình sau cho thấy sự phân bố độ trì hoãn và độ trì hoãn Jitter

™ Độ thất thoát gói tin (Loss Rate): Tỉ lệ giữa tổng số gói tin nhận được trên

tổng số gói tin đã phát Tỉ lệ này sẽ tăng nhanh trong trường hợp nghẽn mạng Tỉ lệ này có thể được giải quyết bằng các biện pháp như : cấp phát băng thông và bộ đệm đủ cho các ứng dụng có nhu cầu

Delay distibution and delay jitter

1.3 Các giao thức và các khung làm việc của QoS :

Mặc dù với sự phát triển của kỹ thuật Dense Wave Length Division Multiplexer và kỹ thuật quang thì băng thông có thể không bao giờ trống hay ít nhất là trong tương lai gần Do đó nghẽn xãy ra là điều khó tránh khỏi, đồng thời mạng Internet hiện nay không thể cung cấp bất cứ tài nguyên nào để đảm bảo cho người dùng vì nó ít có khả năng quản lý tài nguyên mạng [2] Những vấn đề này đã dẫn đến sự phát triển của các protocols và cấu trúc hỗ trợ QoS chẳng hạn : Integrated Service (IntServ) , Differentiated Service (DiffServ) và Multi Protocol Lable Switching ( MPLS ) Những Frameworks này sử dụng các cách tiếp cận để đảm bảo một số mức độ về dịch vụ cho người dùng Nói chung , hai vấn đề chính của mạng Internet hiện nay mà QoS phải giải quyết [2] là :

™ Sự phân phối tài nguyên mạng (resource allocation)

™ Sự tối ưu hoá hoạt động của mạng (performance optimazation)

IntServ và DiffServ được thiết kế nhằm giải quyết vấn đề phân phối tài nguyên mạng trong khi MPLS cùng Traffic Engineering thì giải quyết vấn đề tối ưu hoá sự hoạt động của mạng

IntServ được phát triển vào đầu thập niên 90 hỗ trợ các ứng dụng real time

Nó cung cấp QoS thông qua cơ chế thiết lập sự dành trứơc tài nguyên cho các ứng dụng trên (resource reservation mechanism) Cơ chế này giúp đảm bảo băng thông cho từng ứng dụng riêng lẻ Một ứng dụng phải yêu cầu thiết lập dành tài nguyên trước khi nó gởi gói tin Một giao thức sẽ thiết lập dành tài nguyên giữa users và các routers cũng như giữa các routes bên trong mạng để đảm bảo tài nguyên mạng sẽ được dành trên suốt đường đi của gói tin IntServ đưa ra 2 mô hình dịch vụ tùy theo

mức độ đảm bảo : dịch vụ đảm bảo tuyệt đối (guaranteed service ) và dịch vụ tải có kiểm soát hay ít đảm bảo (controlled load service )

DiffServ được phát triển vào năm 1997 sử dụng cách tiếp cận khác cho việc

phân bố tài nguyên Nó sử dụng khái niệm “loại dịch vụ “ (Class of Service: CoS) để phân loại lưu lượng của người sử dụng tại nút vào của mạng (ingress node) thành các lớp dịch vụ khác nhau , sau đó mỗi lớp dịch vụ sẽ nhận được các mức độ xử lý khác nhau trong mạng DiffServ sử dụng sự kết hợp giữa các chính sách (policy) , sự cấp phát lưu lượng (provisioning) và độ ưu tiên lưu lượng (traffic prioritization) để đáp ứng yêu cầu đa dạng của các loại dịch vụ Chính điều này sẽ làm cho các nút chính bên trong mạng (core node) chỉ thực hiện việc chuyển các gói tin hay xử lý chúng với tốc độ rất cao hơn Ngược lại, sự đảm bảo dịch vụ trong mạng DiffServ dựa trên sự phân bố tài nguyên mạng nhưng điều này thường khó bởi vì bản chất của lưu lượng là luôn thay đổi Do đó , DiffServ thường không đảm bảo tuyệt đối như IntServ

MPLS cung cấp QoS thông qua việc cải thiện sự hoạt động và sử dụng tài

nguyên mạng một cách hiệu quả Bằng cách sử dụng các nhãn (label) có chiều dài cố định được mã hoá đưa vào header của gói (giữa lớp 2 và lớp 3) , MPLS đưa ra một cơ chế chuyển các gói tin với tốc độ nhanh hơn các routers IP thông thường bởi vì các nút chính bên trong mạng không phải thực hiện việc tra cứu bảng của gói tin IP ở lớp 3 (việc này chỉ thực hiện ở các nút ngoài của mạng ) và như thế các nút chính bên trong chỉ đơn giản chuyển các gói tin kèm theo nhãn của nó Hơn thế , MPLS cũng cung cấp

mô hình linh động hơn IP over ATM Đặc biệt MPLS hộ trợ tốt các kỹ thuật điều

khiển lưu lượng như : Traffic Engineering với Constraint-based routing (kỹ thuật

định tuyến có hỗ trợ QoS )

1.4 Mục đích và đối tượng của đề tài :

Đề tài tập trung vào các mục tiêu chính sau :

¾ Thứ nhất : tập trung khảo sát các cấu trúc và cơ chế của các khung làm việc

(Frameworks) có hỗ trợ chất lượng dịch vụ như : Dịch vụ đảm bảo chất lượng

dựa trên từng dòng lưu lượng (Intergated Service :IntServ) , dịch vụ đảm bảo

chất lượng dựa trên các lớp dịch vụ khác nhau ( Differentiated Service

:DiffServ) , dịch vụ chuyển nhãn đa giao thức (Multiprotocol Label Switching Service : MPLS ) và kỹ thuật điều khiển lưu lượng (Traffic Engineering:TE)

Các dịch vụ này hoàn toàn có thể tích hợp vào mạng IP hiện nay do nó được xây dựng theo mô hình OSI

¾ Thứ hai : để minh họa sự hoạt động và hiệu quả của các Framework này , một

số mô hình mô phỏng được tạo ra dựa trên các giao thức và mô hình dịch vụ trên để nhằm nâng cao hơn nữa chất lượng dịch vụ và đồng thờiø phát triển thành một công cụ để hỗ trợ cho việc giảng dạy và nghiên cứu sau này Một giao tiếp đồ họa được phát triển cho việc mô phỏng , thông qua đó người sử dụng có thể dễ dàng thay đổi các thông số mô phỏng

¾ Thứ ba : kết quả của việc mô phỏng các Frameworks trên sẽ được đánh giá ,

phân tích và so sánh giữa các Frameworks và so với lý thuyết Từ đó có thể đưa ra các giải pháp tốt hơn nhằm nâng cao chất lượng QoS trong tương lai

Chương 2 : Cấu trúc và cơ chế của các Frameworks

của QoS

Chương này mô tả chi tiết cấu trúc của các Frameworks của QoS như IntServ, DiffServ và MPLS Đồng thời giải thích về các mô hình dịch vụ cùng sự quan hệ giữa MPLS và DiffServ , kỹ thuật điều khiển lưu lượng như Traffic engineering và Constaint-based routing (định tuyến có hỗ trợ đảm bảo chất lượng dịch vụ )

2.1 Integrated Services : (InteServ)

2.1.1 Giới thiệu về Integrated Services

Mục đích của IntServ là đảm bảo băng thông , có thể kiểm soát độ trễ từ đầu cuối đến đầu cuối cho người sử dụng Thêm vào đó mô hình còn chia sẽ băng thông đối với nhiều loại lưu lượng khác nhau Do đó IntServ hỗ trợ tốt cho các loại ứng dụng bao gồm : dịch vụ hỗ trợ tối đa (Best–Effort Service) đang sử dụng hiện nay , các ứng dụng thời gian thực (Real Time service) và chia sẻ băng thông giữa các link [3]

2.1.2 Cấu trúc của Integrated Services

Sự tiếp cận InteServ sử dụng một sơ đồ dành trước tài nguyên dựa trên từng dòng lưu lượng yêu cầu Một ứng dụng phải dành hẳn tài nguyên ( chẳng hạn băng thông ) suốt quảng đường đi của nó trước khi truyền các gói tin đi cùng một số thông

số liên quan đến QoS ở trên : độ trễ (delay), độ mất mát gói tin (packet loss) Mục

đích chính của InteServ là đảm bảo chất lượng dịch vụ thông qua các cơ chế chính : xây dựng một giao thức thiết lập sự dành trước tài nguyên (Resource Reservation Protocol ) và tính toán độ trễ tối đa cho các ứng dụng

QoS Routing Agent Admission control

Reservation Setup Agent

Resource reservation table

Control Plane

Flow identification Packet scheduler

Data Plane

Hình 1: Mô hình chuẩn của Integrated Services [2]

Hình 1 cho thấy mô hình chuẩn của InteServ Mô hình này chứa 2 phần logic :

Control Plane và Data Plane Control Plane chịu trách nhiệm cho việc thiết lập dành

cơ chế dành trước tài nguyên và Data Plane chịu trách nhiệm chuyển gói tin đi tùy theo trạng thái của việc thiết lập sự dành trước [2] Trước khi gởi các gói tin đi , đầu tiên ứng dụng phải mô tả đặc tính của luồng lưu lượng cũnng như các yêu cầu về QoS

theo dạng Flow specification [5] (flowspec) và sau đó gởi yêu cầu thiết lập (setup ) sự

dành trước đến mạng Khi router nhận yêu cầu về cung cấp sự dành trước tài nguyên này , đầu tiên nó sẽ tham chiếu đến module định tuyến để tìm hop (đường đi ) tiếp theo của gói tin để chuyển các yêu cầu đó Kế đến , nó yêu cầu module kiểm soát

ngõ vào (admission control) xem xét xem có nguồn tài nguyên nào đủ đáp ứng nhu

cầu không Nếu tiến trình thiết lập thành công , thông tin về lưu lượng dành trước sẽ

được đưa vào trong bảng dành sẵn tài nguyên (resource reservation table ) Thông

tin trong bảng này được dùng để điều khiển module nhận dạng lưu lượng ngõ vào

(Flow Identification) và module xử lý gói tin (packet scheduler) Khi gói tin đến

Flow Identification sẽ chọn gói tin thuộc lưu lượng dành sẵn đưa vào hàng đợi

(queues) thích hợp Sau đó module packet scheduler sẽ phân bố tài nguyên cho lưu

lượng dựa vào thông tin dành sẵn trong bảng Phần tiếp theo sẽ giải thích chi tiết mỗi thành phần trong mô hình

Resource Reservation Setup (thiết lập dành trứơc tài nguyên ): như đã nói

ở trên , trạng thái dành sẵn phải được giữ tại các hosts đầu cuối và các routers trong suốt đường đi đã thiết lập sự dành sẵn Tổ chức kỹ thuật Internet (IETF)

đã phát triển một protocol gọi là “ Resource Reservation Protocol (RSVP)”

[4] Giao thức cũng mang thông tin đặc tính về lưu lượng và các yêu cầu dành trước tài nguyên Protocol này khá phức tạp , nó hỗ trợ các loại cơ chế dành sẵn khác nhau Hoạt động cơ bản của protocol này có thể giải thích như sau theo hình 2 :

Hình 2 : Cơ chế thiết lập dành trước tài nguyên mạng [4]

o Tại nút phát sẽ gởi bản tin PATH với các đặc tính QoS yêu cầu trong phần mô tả đặc tính về lưu lượng (flowspec) đến nút thu

o Tại mỗi nút trung gian trong suốt đường đi sẽ chuyển bản tin PATH đến hop tiếp theo bằng cách sử dụng giao thức định tuyến thông thường như OSPF Đồng thời, các routers trung gian này cũng cập nhật trạng thái cần

thiết cho bản tin RESV để tìm đường đi dành trước từ nút thu đến nút phát

o Khi nhận được bản tin PATH, nút thu sẽ trả lời bằng bản tin RESV cho nút phát, các nút trung gian cũng lần lượt chuyển bản tin RESV đến nút phát theo đường đi đã được thiết lập trước Bản tin RESV cũng chứa thông tin về yêu cầu tài nguyên và trạng thái RESV cũng được update tại các nút trung gian

o Các nút trung gian có thể chấp nhận hay từ chối yêu cầu Nếu tất cả các nút trung gian chấp nhận yêu cầu RESV thì nút phát mới có thể bắt đầu gởi gói tin trên đường đã được thiết lập trước

• Reservation Styles (kiểu dành trước ): Một yêu cầu về Reservation phải

bao gồm một tập các tùy chọn được tập hợp lại gọi là kiểu thiết lập Reservation Kiểu Reservation có chức năng xác định được nhiều yêu cầu và gọp chúng lại để chuyển các yêu cầu này đến các nút tiếp theo Có 2

kiểu Reservation :

o Wild-card-filter (WF) style : Một sự dành trước sẽ được chia sẻ

theo yêu cầu lớn nhất từ tất cả các nút nguồn phát khác nhau Kiểu

WF này có thể biễu diễn theo hàm WF(*,{Q}) ,trong đó : * : tập các nguồn yêu cầu , Q : yêu cầu của các nguồn

o Fixed-filter (FF) style : Ngược lại kiểu WF , FF cung cấp một sự

dành trước riêng biệt và cụ thể đối với mỗi nguồn phát FF có thể biểu diễn theo hàm FF(S1(Q1), S2(Q2), … Sn(Qn)) Trong đó :

S1,S2,……Sn : là nguồn yêu cầu , Q1,Q2,…Qn : là yêu cầu của từng nguồn riêng biệt

Hình 3 sau minh hoạ các kiểu yêu cầu dành trứơc tài nguyên theo mode upstream

(mode đáp ứng yêu cầu dành trước từ router phát đến router thu ) Trong đó :

o I1,I2 , O1, O2: các giao tiếp ngõ vào và ra

o B : đơn vị yêu cầu sự dàng trước (băng thông chẳng hạn)

Tại giao tiếp ngõ ra O1,O2 (kiểu WF), thì sự dành trước tài nguyên được thực hiện theo yêu cầu tài nguyên cao nhất cho tất cả các nguồn phát yêu cầu là (4B) Trong khi kiểu

FF thì dành trước cho từng nguồn phát riêng biệt S1(4B) , S2 (5B) , S3(3B)

Admission Control : Mạng phải thường xuyên theo dõi tình trạng sử dụng tài

nguyên của mạng để có thể cung cấp đủ tài nguyên cho các ứng dụng và cũng đảm bảo rằng các tham số cam kết ban đầu không được vi phạm [6] Nó sẽ từ chối một yêu cầu dành trước tài nguyên cho một ứng dụng mới nếu nó nhận thấy tài nguyên hiện tại không thể cung cấp đủ cho ứng dụng Module kiểm soát ngõ vào (Admission Control) thực hiện nhiệm vụ này như là một phần của quá trình thiết lập RVSP trước khi một yêu cầu thực sự được chấp nhận Admission Control có 2 nhiệm vụ chính :

o Xác định một sự dành trước tài nguyên của một ứng dụng mới đến có thể được thiết lập hay không , dựa trên các chích sách của nó (policies)

o Theo dõi và đo lường tài nguyên đang sử dụng

Có 2 cách tiếp cận cho Admission control : dựa trên các thông số (parameter

based) và dựa vào các phép đo (measurement based) Trong cách tiếp cận

parameter based , một tập các đặc tính của luồng tin sẽ được dùng để tính toán tài nguyên mạng cần thiết cho luồng tin Tuy nhiên , phương pháp này thường dẫn đến sự sử dụng tài nguyên mạng thấp bởi vì rất khó đưa ra mô hình lưu lượng một cách chích xác , đặc biệt là đối lưu lượng thời gian thực Trong khi cách tiếp cận

“measurement based” mạng sẽ đo tải lưu lượng thực sự để quyết định chấp nhận yêu cầu cho luồng thông tin mới Có nhiều giải thuật cho Admission Control:

o Simple Sum : giải thuật này đảm bảo tổng băng thông yêu cầu cho tất

cả luồng tin hiện tại và luồng tin mới không vượt quá khả năng của đường truyền Giải thuật này chấp nhận một luồng tin mới nếu thõa điều kiện sau :

Trong đó : V : Băng thông tổng cộng

R : Băng thông của link

Ci : Băng thông yêu cầu của luồng thứ i mới đến

o Measure Sum : Ngược lại giải thuật Simple Sum , giải thuật này sẽ đo

đạc để ước lượng tải của luồng tin đang hiện hữu và sau đó nó cho phép luồng tin mới đến nếu thõa điều kiện [6]:

R Ci

Trong đó : V~ : tải ước lượng của các luồng tin

η : hệ số sử dụng của người dùng Tức là : băng thông thực tế sử dụng phải luôn nhỏ hơn tổng băng thông yêu cầu

o Acceptance region :giải thuật này tính toán vùng chấp nhận để tối ưu

sự sử dụng mạng để chống lại việc thất thoát gói tin Vùng này thường gần bằng với tải đo đạc thực tế các luồng đang sử dụng và tốc độ đỉnh của luồng tin mới Đối với luồng tin được biểu diễn bằng bộ lọc token bucket (r,b) thì tốc độ đỉnh của luồng này được tính theo phương trình :

U b R

Trong đó : U : làhệ số sử dụng của người sử dụng

o Equivalent bandwidth : giải thuật này tính toán băng thông tương

đương nhau cho một tập các luồng tin theo hàm C(p) với p : xác suất tối

đa của tải

Để bổ sung cho các giải thuật trên, mạng phải đo tải thực sự của các luồng tin đang sử dụng Có 2 phương pháp đo đơn giản và hiệu quả [6]:

o Cửa sổ thời gian (Time Window ) : phương pháp này sử dụng cùng với

giải thuật Measure-Sum

Hình 4 : Time Window measurement for network load

Đây là phương pháp đo lường tải của mạng dựa vào cửa sổ thời gian Tốc độ ước tính trung bình được tính toán trong mỗi khoảng thời gian lấy mẫu S Tại cuối khoảng thời gian cửa sổ T, trung bình tải của mạng cao nhất sẽ được dùng làm tốc độ ước tính cho cửa sổ tiếp theo Khi luồng tin mới đến thì tải ước lượng này sẽ tăng lên sao cho : tốc độ tin mới đến (V )+ tốc độ ước tính(Ci) < băng thông tối đa của link (R) Giả sử có n khoảng lấy mẫu trong chu kỳ đo T và Ci là tốc độ trung bình đo được trong khoảng thời gian lấy mẫu S thì ta có :

[C C C n]

Rate Estimate_ =max 1, 2, (2.4.1)

o Exponenitial Averaging :

Giải thuật đo tốc độ trung bình lưu lượng đến trong khoảng thời gian lấy mẫu S theo hàm đáp ứng xung với trọng số W :

S v w v w

Từ (2.4.2) ta thấy trọng số w nhỏ thì phù hợp với sự thay đổi nhỏ và ngược lại

Flow identification : Tại mỗi router , Flow identifiaction sẽ kiểm tra xem mỗi

gói tin vào có thuộc lưu lượng yêu cầu dành trước tài nguyên không bằng cách

đọc thông tin từ 5 trường chính trong packet header : địa chỉ nguồn ( source IP

address) ,địa chỉ đích (destination IP address ),mã nhận dạng giao thức ( protocol ID),thiết bị của nguồn và đích (source port và destination port)

Sau đó nó so sánh với thông tin về lưu lượng đã dành trước trong bảng RSVP Nếu gói tin nằm trong luồng tin dành sẵn thì nó sẽ chuyển gói tin đến bộ xử lý

gói tin (packet scheduling) với trạng thái dành sẵn tương ứng trong bảng RSVP

Packet Scheduling : Packet Scheduler chịu tránh nhiệm phân bố tài nguyên

cho từng lưu lượng riêng biệt Khi tài nguyên mạng không thể đáp ứng tất cả

các luồng tin thì các gói tin sẽ được đưa vào các hàng đợi (queues) tại các

routers Vì thế , Packet Scheduler phải xác định gói tin nào được nhận tài nguyên Packet Scheduler đóng vai trò quan trọng trong mô hình IntServ bởi vì nó ảnh hưởng trực tiếp đến sự phân bố băng thông và độ trễ của gói tin Vì sự

quan trọng mà một số các giải thuật scheduling được phát triển :

o Generalized Processor Sharing (GPS) :

GPS là một giải thuật hàng đợi lý tưởng hoạt động theo mô hình chia sẽ băng thông

“fluid model” , mô hình này chia sẽ băng thông công bằng cho luồng lưu lượng dựa trên các trọng số , mô hình này thích hợp cho các gói tin có cùng kích thước Hình 5 sau mô tả hai luồng tin trong hàng đợi như sau :

Fluid Model Flow 1 Flow 2

có tốc độ dịch vụ là R phục vụ cho N flows đang active và mỗi flow thứ I có trọng số là φi Ta gọi : S(i,τ,t)là lượng dữ liệu được phục vụ cho flow thứ i trong khoảng thời gian ( tτ, ) Thì ta sẽ luôn có tỉ lệ :

j

i t j S

t i S

φ

φτ

τ ≥

),,(

),,( Ngoài ra trong khoảng ( tτ, ) flow thứ i nhận một tốc độ mà server chia sẽ theo tỉ lệ sau :

Trong đó V : số các flows đang active trong khoảng thời gian này

Như vậy , từ công thức trên cho ta thấy GPS cung cấp một sự phân bố tài nguyên cho các flows trong hàng đợi một cách công bằng theo tốc độ yêu cầu của từng flows dựa vào việc gán trọng số cho từng flow Ngược lại , các flow không active (tốc độ phát dữ liệu thực tế nhỏ hơn tốc độ yêu cầu của chúng ) sẽ nhận được đầy đủ dịch vụ mà không cần đưa qua hàng đợi , chỉ những tài nguyên còn lại mới được phân bố lại cho các flows đang active tùy theo trọng số của chúng

Khi ứng dụng phát theo dạng token bucket thì độ sâu bucket b và token rate lúc đó sẽ phải đảm bảo :

o Weighted Fair Queing (WFQ)

Ngược lại với mô hình Fluid Model , WFQ sử dụng mô hình theo trình tự các gói tin

“packetized model” (hình 6), các gói được nhận và phát đi theo thời điểm khác nhau theo nguyên tắc :

k i k i k i

L F

i

k i k

i k

i

L t V F F

φ

+

Trong đó : V(t) là hàm tuyến tính theo thời gian

Thời gian trễ của WFQ có thể được tính theo công thức :

L r

L K r

b

1

max max

)1

K : số hop

Lmax : kích thước tối đa của gói

i

r : tốc độ dự trữ cho flow I

R : tốc độ dịch vụ cho mỗi hop m

Từ công thức (2.9) cho ta thấy độ trễ của WFQ lớn hơn GPS : thành phần 1 thì gống với GPS , thành phần 2 là độ trì hoãn thêm của gói qua các hop , thành phần thứ 3 : cho thấy các gói được phục vụ từng gói một

o Weighted Robin Round (WRR)

Có một số trường hợp kích thứơc của gói cố định thì ta có cách tính độ trễ đơn giản hơn Server chỉ cần xem xét các active flow và chọn các gói phát theo các trong số của chúng Thí dụ : có 2 flow A và B cùng chia sẽ một link với các trọng số như sau 1 và 2 Thì đầu tiên Server sẽ chọn một gói từ A và 2 gói từ B , và tiếp tục như thế

o Deficit Round Robin (DRR)

DRR cũng tương tự như WRR nhưng nó tính toán kích thước đang sử dụng của gói Sau đó , mỗi flow sẽ có một bộ đếm (được gán một số bit ban đầu ) Khi một gói phát

đi thì số bit này giảm tương đương kích thước gói Số bit này được gán dựa trên trọng số của flow và khi flow ngừng phát hay tình trạng nghỉ thì số bit này được đặt lại giá trị ban đầu

Các giải thuật Scheduling này yêu cầu sự phân phối băng thông công bằng trong khi vẫn giữ được sự sử dụng tài nguyên cao

2.1.3 Mô hình dịch vụ của IntServ

Phần trước đã mô tả các các thành phần chính của InteServ Trong phần này , chúng ta sẽ giải thích giao tiếp giữa mạng và người sử dụng trong IntServ Framework

Flow Specifcation : Để thiết lập một yêu cầu dành trước tài nguyên thì ứng

dụng phải được mô tả đặc tính cũng như các yêu cầu của luồng tin đó Trong IntServ , Flow Specification [5] đảm nhiệm chức năng này , là một tập các thông số về lưu lượng chẳng hạn :

o Peak rate : Tốc độ cao nhất mà nguồn có thể phát dữ liệu Tốc độ này

thường bị giới hạn bởi tốc độ thiết bị phần cứng Tốc độ đỉnh có thể được tính từ kích thước của gói tin và khoảng thời gian nghỉ giữa các gói

o Average rate : tốc độ truyền trung bình được tính toán theo sự di

chuyển của cửa sổ thời gian

o Burst size : Lượng dữ liệu tối đa được đưa vào mạng với tốc độ đỉnh

o Minimum Bandwidth : Băng thông tối thiểu mà ứng dụng yêu cầu

Khoảng thời gian đo băng thông sẽ ảnh hưởng trực tiếp đến kết quả đo băng thông

o Delay: độ trễ trung bình hay độ trễ tối đa bao gồm 3 thành phần : thời

gian trì hoản (do tốc độ ánh sáng , khoảng cách ), thời gian truyền ( thời gian gởi một gói vào đường truyền ) và độ trễ hàng đợi (thời gian đợi một gói )

o Delay jitter : độ chênh lệch giữa độ trễ nhỏ nhất và độ trễ lớn nhất của

gói tin Độ trễ jitter phải nhỏ hơn độ trễ tối đa và độ trễ đợi hàng

o Loss rate : tỉ lệ thất thoát hay mất gói tin trên tổng các gói tin được

phát Độ thất thoát này phụ thuộc vào việc nghẽn của mạng Độ thất thoát này có thể được giải quyết bằng việc phân bố đủ băng thông cho luồng tin và tài nguyên của mạng

Với IntServ, thuật ngữ mô tả lưu lượng theo các tham số của bộ điều phối lưu lượng (leaky bucket parameters (r,b)) Leaky bucket là một loại điều phối luồng tin rất phổ biến Cơ chế có thể giải thích như sau :

Token arrival rate r

Bucket depht b Packet in Packet out

From source

Packet buffer

Hình 7 : A leaky bucket with rate r and depth b

Các token được đưa vào bucket với một tốc độ không đổi r và được sử dụng để kiểm soát các gói tin ngõ vào Khi một gói tin đến , bộ điều phối sẽ gởi gói tin này ngõ ra nếu như trong bucket có đủ token Khi một gói đã gởi đi thì bộ điều phối sẽ lấy ra số token bằng đúng kích thước gói đã gởi đi Nếu gói tin đến không đủ số token để gởi đi thì nó sẽ được đưa vào bộ đệm chờ khi đủ token thì gói tin mới có thể được gởi đi Độ sâu của bucket (depth b ) là số token tối đa của bucket Một khi token bucket đạt tới giá trị b , thì bộ điều phối sẽ hủy bỏ các token tiếp tục đến cho đến khi nào kích thước của token bucket nhỏ hơn b

Một nguồn lưu lượng với các tham số (r,b) sẽ có peak rate

số Tspec (Traffic specification) và đặc tính về dịch vụ yêu cầu Rspec (Service Specification) [8]

Tspec mô tả các nguồn lưu lượng theo các tham số sau :

o Bucket rate (r : bytes/sec) : tốc độ token đến bucket

o Peak rate (p : bytes/sec) : tốc độ tối đa mà nguồn có thể phát gói tin

o Bucket depth (b : byte) : kích thước của token bucket

o Minimum policed unit (m : bytes ) : kích thước tối thiểu của một gói ,

nếu kích thước này nhỏ hơn giá trị m thì gói sẽ được tính bằng giá trị m

o Maximum packet size (M : bytes) : Kích thước gói tối đa có thể chấp

nhận

Rspec mô tả các nguồn lưu lượng theo 2 tham số sau :

o Service rate (R : bytes/sec) : tốc độ hay băng thông yêu cầu

o Slack Term (S : msec) : độ trễ cho phép cho một nút nhưng vẫn đảm

bảo yêu cầu độ trễ từ đầu cuối đến đầu cuối Từ các tham số Tspec và Rspec ta có thể tính được độ trễ hàng đợi tối đa của một luồng tin theo công thức :

End-to-end worst-case queuing delay (Dq)=

)(

)(

r p R

R p b

−

Từ (2.11) ta có thể thấy rằng : nếu p >> R, r thì : Dqmax=

R

b chỉ phụ thuộc vào

độ sâu của bucket và tốc độ dịch vụ hay băng thông yêu cầu Rõ ràng , lượng dữ liệu tối đa mà một nguồn có thể gởi bị giới hạn bởi độ sâu của token bucket , vì thế chiều dài hàng đợi sẽ không vượt quá giá trị b Ngược lại nếu giá trị p nhỏ hay có thể so sánh với R thì giá trị Dq sẽ giảm và nếu p nhỏ hơn giá trị R thì coi như không còn độ trễ vì mạng có khà năng cung cấp dịch vụ nhanh hơn nguồn phát

Controlled Load Service (dịch vụ có kiểm soát tải : CLS)

Trong khi cung cấp một sự đảm bảo băng thông nghiêm ngặt và giới hạn độ trễ thì Guaranteed Service sẽ không sử dụng tài nguyên mạng một cách hiệu quả bởi

vì nó phải dành trước tài nguyên cho tình huống xấu nhất Ngược lại , Controlled Load Service thì không cung cấp bất cứ một sự đảm bảo nghiêm ngặt cho độ trễ hay bandwidth nhưng nó cung cấp chất lượng QoS tốt gần với QoS cho luồng tin nhận được từ mạng không tải , thậm chí trong trường hợp quá tải bằng cách sử dụng module kiểm soát ngõ vào (admission control) Controlled Load Service thích hợp cho những ứng dụng thời gian thực mà có thể chịu được sự thay đổi về độ trễ

2.2 Differentiated Services : (DiffServ)

2.2.1 Giới thiệu về Differentiated Services

Trong khi cấu trúc IntServ cung cấp một cơ chế tốt hơn “best -effort” service, đảm bảo tốt về QoS (băng thông , độ trễ đầu cuối đến đầu cuối ) nhưng nó có một số

nhược điểm là độ linh hoạt không cao và hơi phức tạp về cấu trúc và về quản lý trạng thái dành trước suốt quảng đường đi của gói tin , đặc biệt là khi mạng phát triển lớn và đa dạng như hiện nay DiffServ được phát triển để cung cấp các mức độ khác nhau về dịch vụ đồng thời cũng hỗ trợ nhiều loại ứng khác nhau [10] Cấu trúc của DiffServ khác với IntServ ở một số khía cạnh khác nhau Cấu trúc IntServ phân bố tài nguyên mạng cho từng luồng lưu lượng (traffic flow) riêng biệt , ngược lại DiffServ chia lưu lượng thành nhiều lớp xử lý khác nhau và phân bố tài nguyên dựa trên các lớp này Nếu nhìn dưới góc độ sự hoạt động và các ứng dụng thì DiffServ đưa ra cách giải quyết vấn đề đơn giản hơn Chẳng hạn, tại các nút chính chỉ cần xử lý các gói tin theo các chính sách (policy) đã được gán trong các lớp của gói tin mà không cần phải thiết lập sự dành trước tài nguyên mạng Điều này giúp tăng sự hoạt động của mạng , đồng

thời linh hoạt hơn so với mạng IntServ

2.2.2 Cấu trúc về Differentiated Services

Cấu trúc của Differentiated Service thì tương đối đơn giản , ý tưởng chính là phân loại và kiểm soát lưu lượng ngõ vào mạng DS tại các nút bìa ngoài của mạng Tại đây , lưu lượng sẽ được gán vào tập các hành vi xử lý khác nhau (Behaviour Aggegates ) tùy theo các mã dịch vụ DSCP (Differentiated Service CodePoint ) được mã hoá trong header của gói tin Trong phạm vi mạng DS , các gói này được xử lý và chuyển đi tùy theo các hành vi này Mô hình dịch vụ DiffServ bao gồm các thành phần và các khái niệm chính như : : vùng DiffServ (DiffServ Region ), Phân loại lưu lượng (Traffic Classification ) và chức năng kiểm soát gói tin (Conditioning ) Để hiểu rõ , làm thế nào mà DiffServ có thể thực hiện nhu cầu đảm bảo QoS thông qua các chức năng trên , chúng ta xem xét từng thành phần cũng như từng chức năng của mạng DS

DiffServ region

Hình 8 cho thấy một miền cơ bản “ DS domain” Một DS domain bao gồm một tập các nút kề nhau cùng hoạt động theo chính sách phân bố dịch vụ (policy) và một tập PHB (Per Hop Behaviour ) được bổ sung cho mỗi nút Các nút bìa ngoài của mạng (boundary or edge nodes) là các nút mà có thể kết nối với các nút khác trong cùng

mạng DS hay các mạng non-DS Các nút này chịu trách nhiệm phân loại và kiểm soát lưu lượng vào Đồng thời nó cũng có thể hoạt động như một nút vào hay nút ra tùy thuộc vào hướng lưu lượng Các nút ở trong (interror or core nodes ) là những nút mà có thể kết nối với các nút bên trong và các nút ở ngoài Một hay nhiều domain tạo thành một vùng DS Lưu lượng vào sau khi được phân loại và kiểm tra điều kiện sẽ được đánh dấu và gán vào một PHB thích hợp

SLA: Service Level Agreement

SLA

Boundary node Interior node

Hình 8 : Differentiated Services domain [2]

Per-Hop Behaviors (PHBs)

Tại mỗi nút , việc xử lý việc chuyển các gói tin được mô tả bằng thuật ngữ per hop behavior (PHB) Mỗi PHB được định nghĩa bởi một gía trị 6 bits gọi là Differentiated Service CodePoint (DSCP) dùng để mô tả cách thức xử lý gói tin qua từng hop Các PHB là các đơn vị cơ bản để phân bố tài nguyên đến các BA (behavior aggregates) Việc phân bố này có thể là toàn bộ hay theo một tỉ lệ nào đó Thí dụ như , PHB có thể chỉ rõ băng thông tối thiểu cần đảm bảo cho một tập BA hay PHB có thể yêu cầu phân bố băng thông trên các link theo một trọng số nào đó Nhiều PHB có thể kết hợp như là PHB group

Service Level Agreement (SLA) :

Trong cấu trúc DiffServ , PHB có thể được xem như một dịch vụ nằm ở phía nhà cung cấp dịch vụ , còn đối với người sử dụng thì nó phải được định nghĩa rõ ràng và chi tiết hơn thông qua một khái niệm là : hợp đồng dịch vụ (Service Level Agreement :SLA)

Một trong những thành phần quan trọng của SLA là hợp đồng kiểm soát lưu lượng

(Traffic conditioning Agreement : TCA ) TCA mô tả các tham số mô tả , yêu cầu về

lưu lượng hay các chính sách (policing) để xử lý lưu lượng khi không đảm bảo yêu

cầu cam kết Các tham số cụ thể như :

o Các tham số về Token Bucket (tốc độ , kích thứơc gói tối đa, tổng số dữ liệu

tối đa cần gởi ) cho mỗi loại lưu lượng

o Băng thông yêu cầu , độ trễ và độ ưu tiên rơi các gói tin

o Phương pháp xử lý các gói tin vi phạm cam kết

o Các chính sách đánh dấu (marking) và lọc (shaping) được cung cấp bởi nhà

cung cấp

Ngoài thành phần TCA , SLA cũng chứa các tham số khác qui định các đặc tính như :

độ an toàn (security) , giám sát (monitoring), tính cước (accounting )

Structure of Differentiated Service Field

Như đã nói ở trên các router tại các nút sẽ xử lý và chuyển các gói đi tùy thuộc

vào PHB của nó mà được biễu diễn thông qua giá trị DSCP Tất cả các gói tin có

cùng giá trị DSCP sẽ được chuyển đến một BA và cùng được xử lý như nhau Một

trường DS củs DiffServ (trong IP header ) gồm 8 bits [11] DiffServ định nghĩa trường

này :

Hình 9 : Differentiated Service Field

Sáu bits đầu tiên được dùng như một DSCP để mã hóa PHB cho mỗi gói tại các

nút mạng , vì thế có tối đa 64 PHB Hai bits cuối không dùng 64 DSCP này được chia

2 xxxx11 Experimental and local use

but may be subject to standards action

Trong số 32 DSCP chuẩn của pool 1 dùng để gán giá trị và quản lý thì có một

DSCP mặc nhiên (default PHB CodePoint ) có giá trị <000000> Việc xử lý lưu lượng trên các gói này cũng giống như dịch vụ “best effort” Pool 2 có 16 DSCP dùng cho thí nghiệm và pool 3 có 16 DSCP dùng cho thí nghiệm hay dùng cho việc gán khi pool

1 dùng hết

Traffic classification and conditioning

Trong DiffServ , các nút bìa ngoài của mạng có nhiệm vụ là xác định các gói tin nào sử dụng cho lớp xử lý tương ứng và chúng cũng đảm bảo rằng lưu lượng thích hợp cho SLA của người sử dụng Một khi các gói tin đi qua các nút ngoài để vào mạng bên trong thì sự phân bố tài nguyên được thực hiện dựa trên các lớp xử lý này Ngoài ra , các nút bìa ngoài sẽ dịch một TCA (Traffic Conditioning Agreement) thành một tập các đặc tính của lưu lượng (Traffic profile) cho mỗi người sử dụng đồng thời cung cấp một số qui địmh để xác định xem một gói có nằm trong traffic profile hay không Những chức năng cụ thể mà các nút được thực hiện được mô tả theo các khối sau ở hình 10

Hình 10 : Logical Blocks of classification and conditioning[10]

Classification

Meter

Remarker Shaper Dropper

Marker Classifier

Conditioning

o Classifier : đảm nhiệm việc chia một luồng dữ liệu ngõ vào thành các nhóm

nhỏ dựa vào thông tin trên các header của các gói tin Để cung cấp sự đa dạng về nhu cầu và các ứng dụng khác nhau của người sử dụng, DiffServ đưa ra hai loại classifiers : Behavior Aggregrates (BA) classifier và Multi-field (MF) classifier BA classifier lựa gói dựa trên giá trị DSCP trong các header của gói MF classifier lựa gói dựa trên sự kết hợp của nhiều fields trong header của gói như : source address, destination address, source port, destination port, protocol ID và giao tiếp vào

o Meter : đối với mỗi lớp xử lý , module meter sẽ đo luồng lưu lượng từ người

dùng để xem các gói có nằm trong traffic profile hay không Nếu các gói nằm trong traffic profile (in-profile packets) được phép vào mạng , ngượi lại các gói out-of-profile sẽ được kiểm tra thêm dựa trên các tham số trong TCA Ngõ ra sẽ được chuyển đến module Marker or Shaper/Dropper cho việc xử lý tiếp theo

o Maker : Module này có nhiệm vụ là gán một giá trị DSCP trong trường DS

field và sau đó đưa các gói tin đã được đánh dấu này vào các lớp xử lý trong mạng Bởi vì các gói phải chuyển qua nhiều miền quản lý khác nhau nên khi một gói vi phạm traffic profile thì gói này có thể được đánh dấu lại với giá trị DSCP khác Các gói này sẽ được ưu tiên rơi đầu tiên khi nghẽn xãy ra

o Shaper/Dropper : Shaper sẽ làm trễ các gói mà nó vi phạm tham số lưu

lượng đã thỏa hiệp (out-of-profile) của luồng lưu lượng đến để nó phù hợp với tham số lưu lượng (traffic profile) đã thỏa hiệp Sự khác nhau giữa shaper và marker là marker chỉ đơn giản đánh dấu một gói và để nó vào mạng trong khi shapper thì ngăn không cho các gói out-of-profile vào mạng cho đến khi luồng lưu lượng thõa mãn các điều thỏa hiệp trong traffic profile Dropper có cùng chức năng như Shaper nhưng Dropper có thể cho rơi một số packets để đảm bảo các traffic profile còn lại

2.2.3 Mô hình của Differentiated Services

Các dịch vụ được mô tả theo dạng SLA (Service Level Agreement ) [10] trên hình 10 thực sự là một hợp đồng dịch vụ giữa người sử dụng và một nhà cung cấp dịch vụ SLA có thể bao gồm TCA (Traffic Conditioning Agreement) mà chỉ rõ các tham số dịch vụ đối với traffic profile Đối với DiffServ , các services phải có nhiều thành phần làm việc bên trong : traffic conditioning tại nút ngoài , sự dự trữ trên mạng , đưa dòng lưu lượng vào PHB dựa trên DSCP và PHB-based forwarding bên trong mạng Quá trình tạo ra nhiều loại QoS khác nhau bởi các schedules quản lý bộ đệm tại các nút bên trong

2.2.4 Các loại Per-hop behaviour (PHB)

Có ba loại PHB được định nghĩa trong DiffSev tương ứng với 3 loại lưu lượng : Best effort , Assured Forwarding và Expedited Forwarding

Best Effort : default PHB , không xử lý các yêu cầu về lưu lượng

Assured Forwarding (AF PHB): AF được xây dựng một cấu trúc bao gồm 4

nhóm xử lý các gói tin khác nhau [12], mỗi nhóm xử lý chứa 3 mức độ ưu tiên rơi khác nhau Đối với mỗi nhóm xử lý sẽ được phân bố một băng thông tối thiểu và vùng đệm riêng Do đó các users có thể đăng ký dịch vụ dựa trên các nhóm xử lý này và các gói sẽ được đánh dấu với các code AF DSCP tương ứng Khi các gói tin trong hàng đợi vượt quá giá trị ngưỡng cho trước thì các gói tin có độ ưu tiên rơi cao nhất sẽ rơi trước tiên Cấu trúc các codepoint AF PHB được cho theo bảng sau :

Low Drop Preference Medium Drop Preference High Drop Preference

Như đã nói ở phần cấu trúc của trường DS field gồm có : 5 bits của pool 1 , 3 bits đầu tiên của trường DS này được mã hóa cho lớp xử lý và 2 bits tiếp theo mã hóa cho độ ưu iên rơi Có tất cả 12 AF PHB được mã hóa bởi 12 AF DSCP tương ứng các AF PHB này được ký hiệu qui ước như sau :

AFij i=1,2,3 : group , j=1,2,3,4 : Drop Preference Trong trường hợp nghẽn mạch , các gói thuộc AFij có thể được rơi trước các gói AFik với điều kiện j>k

Các gói thuộc các nhóm xử lý của nhiều lưu lượng khác nhau sẽ được sắp xếp theo cùng một nhóm xử lý trong hàng đợi Hình 11 là một thí dụ về AF PHB và một quá trình sắp xếp các hàng đợi tương ứng (packet en-queue )

AF31

AF11 AF12

AF21 AF22

AF41 AF42 AF43

Queues 001010

Hình 11 : example of AF PHB and en-queue process [22]

Các cơ chế xử lý rơi của các gói tin trong AF cũng sử dụng một số cơ chế khác nhau : WFQ (Weighted Fair Queuing ) , WRR (Weighted Round Robin) hay RED (Random Early Detection) sẽ xem xét sau

Expedited Forwarding (EF PHB) [13] : được thiết kế cho dịch vụ đảm bảo

với độ trễ thấp , độ thất thoát gói tin thấp và băng thông đảm bảo qua các miền DS khác nhau trong mạng Trong trường DS filed thì DSCP được gán cho

EF PHB là <101110> Có nhiều loại cơ chế xử lí các hàng đợi mà có thể áp

dụng vào EF PHB Cách đơn giản nhất là sử dụng hàng đợi ưu tiên với tốc độ token tương ứng Hàng đợi dành cho lưu lượng EF phải có độ ưu tiên cao nhất trong hệ thống để đảm bảo các đặc tính xử lý EF Tuy nhiên tốc độ token cũng phải giới hạn tổng số luồng lưu lượng sử dụng EF để cho các luồng khác (không phải EF ) luôn bị đói tài nguyên do các luồng EF sử dụng hết trong trường hợp nghẽn xãy ra Một cách khác là sử dụng các cơ chế WFQ hay WRR có sử dụng các trọng số khác nhau Trọng số được dùng là theo tỉ lệ tương ứng các băng thông phân bố dựa trên sự phân bố tỉ lệ tốc độ

Traffic Policy : Cơ chế chích sách (policy) là phần quan trọng nhất để hỗ trợ

việc đo lường , đánh dấu và kiểm soát lưu lượng ngõ vào tại các nút bìa ngoài Bởi vì các đặc trưng của lưu lượng được mô tả theo dạng token bucket nên các policy đề cập được gọi là chính sách xử lý gói tin theo mô hình token bucket (token bucket policy ) Mục đích các policy được dùng xác định xem lưu lượng có nằm trong in-profile hay out-of-profile Sau đây sẽ giải thích chi tiết giải thuật dùng hai token bucket policy để chia lưu lượng ngõ vào thành hai nhóm với 3 độ ưu tiên rơi khác nhau Hình 12 cho thấy việc sử dụng 2 bộ policer để

đo và đánh dấu lưu lượng vào

Yellow Green

Token Bucket P Token bucket C

Hình 12 : Metering and Marking used by dual Token Bucket Agorithm[24]

Cơ chế này sử dụng 2 bộ điều phối lưu lượng Token Bucket P và C Trong đó : Token Bucket P có 2 tham số chính : tốc độ đỉnh của lưu lượng (Peak Information Rate : PIR) và kích thước lưu lượng tối đa (Peak Burst Size : PBS) Token Bucekt

C sử dụng 2 tham số : tốc độ lưu lượng cam kết (Commmitted Information Rate :

CIR) và kích thước lưu lượng cam kết tối đa (Committed Burst Size : CBS) Mỗi gói sẽ được gán cho một màu tùy theo kết quả thử gói khi đi qua 2 token bucket :

o Nếu gói qua 2 bộ thử thì gói sẽ được đánh dấu theo màu xanh (green )

o Nếu gói chỉ qua bộ thử P nhưng không qua bộ thử C thì được gán màu vàng (yellow)

o Nếu gói không qua 2 bộ thử P và C thì nó sẽ được gán màu đỏ (red )

Giải thuật sẽ được chia thành 2 phần : phần tính toán kích thước token và đánh dấu màu cho gói tin với các kí hiệu qui ước sau :

PIR : Tốc độ lưu lượng đỉnh hay tối đa

PBS : Kích thước lưu lượng đỉnh

CIR : Tốc độ lưu lượng cam kết

CBS : Kích thước lưu lượng cam kết

Pkt_size : kích thước gói

Pkt_arrival : thời gian đến của gói tin trước

P_tk : bộ đếm token cho bucket P

C_tk : bộ đếm token cho bucket C

Khi gói tin đến , số token sử dụng trong bucket được tính toán như sau :

Elapsed_time = Time_Now() – Pkt_arrival;

P_tk = min[(P_tk +Elapsed_time *PIR),PBS];

C_tk = min[(C_tk +Elapsed_time *CIR),CBS];

Một khi các token trong bucket P và C được tính toán thì việc đánh dấu màu cho gói tin được thực hiên như sau :

If the paket is precolored as RED

Mark the paket as RED ; Else if the paket is precolored as YELLOW

Mark the packet as YELLOW;

Một số giải thuật khác hỗ trợ các cơ chế đo lường và đánh dấu gói tin :

Single-rate Three Color Marker (srTCM) [24]

srTCM sử dụng hai bộ Token Bucket với cùng một tốc độ để đo luồng dữ liệu

trên các IP header của gói tin vào và sau đó sẽ đánh dấu gói tin theo các màu qui định như : GREEN , YELLOW và RED tương ứng 3 mức độ rơi của mỗi gói tin theo mỗi lớp dịch vụ Việc đánh dấu này dựa trên 3 tham số chính :

Committed Information Rate (CIR )

Committed Burst Size (CBS)

Excess Burst Size (ECS)

stTCM cũng có hai mode hoạt động : Color-blind Mode ( gói tin đến chưa được đánh

dấu trước khi đến ) và Color-Aware Mode (gói tin đến đã được đánh dấu trước khi đến ) Giả sử hai bộ Token Bucket C và E có cùng tốc độ chung CIR , và kích thước của Token C và E tại thời điểm ban đầu là : Tc(0) = CBS , Te(0)=ECS Khi đó :

Khi một gói có kích thước B đến tại thời điểm t thì stTCM sẽ hoạt động theo 2 mode Color-Blind :

If the packet is precolored as GREEN