Nh ng kèm theo ó là những thách ử ạ ạ ộ ố ư đthức không nhỏ đặt ra với những nhà cung cấp dịch vụ, làm sao để đáp ứng tốt nhất yêu cầu dịch vụ ngày càng khắt khe của người dùng, từ những
Giới thiệu chung v ề Chất lượng dị ch v ụ (QoS)
Định nghĩa QoS
Chất lượng trên quan đ ể i m của người dùng
Người dùng cuối Người dùng cuối
Khả năng phân biệt giữa các lớp dữ liệu khác nhau, sao cho người dùng có thể xử lý các loại dữ liệu khác nhau theo cách khác nhau
Khả năng đảm bảo cung cấp tài nguyên và phân biệ ị t d ch vụ trong mạng
- Khả ă n ng không g i được gói ử
- Mô hình hoá và mô phỏng
Hình trên minh họa một mạng đầu cuối, trong đó QoS được định nghĩa theo hai cách: từ góc độ người sử dụng và từ góc độ của hệ thống mạng Theo quan điểm của người dùng, QoS thể hiện chất lượng dịch vụ mà người dùng nhận được từ nhà cung cấp dịch vụ hoặc ứng dụng, chẳng hạn như âm thanh, video, và dữ liệu.
Chất lượng dịch vụ mà người dùng cuối nhận được bị ảnh hưởng bởi các yếu tố như độ trễ, jitter và tỷ lệ mất gói tin Mức độ suy yếu của hệ thống mạng này phụ thuộc vào các cơ chế QoS cụ thể được áp dụng trong mạng.
Hệ thống mạng thường truyền tải nhiều loại dữ liệu với các yêu cầu hiệu năng khác nhau, do đó mức độ ảnh hưởng đối với dịch vụ có thể không đồng nhất giữa các loại dịch vụ khác nhau Để đảm bảo chất lượng dịch vụ (QoS) trong mạng, cần tính đến các yêu cầu hiệu năng mâu thuẫn và cân bằng các yếu tố khác nhau nhằm đạt được hiệu suất tối ưu nhất.
Một số phương pháp kiểm soát QoS
Nếu không sử dụng cơ chế đảm bảo QoS, một mạng IP sẽ cung cấp các dịch vụ
"Trong mạng IP, QoS (Quality of Service) cho phép phân biệt và xử lý các gói tin theo cách khác nhau, thay vì xử lý tất cả gói tin giống nhau Hai cơ chế QoS chính trong mạng IP là Integrated Service (IntServ) và Differentiated Service (DiffServ) Để đảm bảo QoS, hệ thống mạng cần thực hiện hai nhiệm vụ quan trọng."
Trong bài viết này, chúng ta sẽ phân biệt các loại thông lượng dữ liệu và dịch vụ, giúp người dùng có khả năng xử lý một hoặc nhiều loại dữ liệu khác nhau Việc hiểu rõ sự khác biệt giữa các loại dữ liệu này sẽ nâng cao hiệu quả trong việc quản lý và sử dụng thông tin.
- Tuỳ theo loại dữ liệu khác nhau mà có cơ chế ử x lý, phân biệt dịch vụ và đảm bảo tài nguyên cung cấp khác nhau
Các chức năng cơ bản của mạng IP được mô tả trong hình 1.3, bao gồm hai nhiệm vụ chính Nhiệm vụ đầu tiên liên quan đến việc thực hiện các giao diện người dùng và mạng-mạng, trong khi nhiệm vụ thứ hai tập trung vào việc bảo trì hệ thống mạng Để thực hiện nhiệm vụ thứ hai, việc quản lý hệ thống mạng là yếu tố quan trọng, nhằm phân biệt sản phẩm của các nhà cung cấp khác nhau.
Hình 1.3 Những yêu cầu chức năng chung của IP QoS
Hình 1.4 Cấu trúc một b định tuyến IP ộ
Hình 1.4 minh họa các yêu cầu từ hình 1.3 dưới dạng lưu đồ khối của thiết bị định tuyến IP (IP Router) Lưu đồ này mô tả chuỗi xử lý cho một cặp đầu vào và đầu ra, trong đó các gói tin được tiếp nhận tại một đầu vào và được chuyển tiếp đến một đầu ra cụ thể.
Ánh d u gói tin trong IP header là quá trình thiết lập giá trị các bit trong trường thích hợp để phân biệt các loại gói tin IP khác nhau Ví dụ, một gói tin có thể được phân biệt thông qua địa chỉ nguồn, địa chỉ đích, hoặc cả hai.
Một gói tin khi đến cổng vào của thiết bị định tuyến có thể được đánh dấu hoặc không Nếu gói tin đã được đánh dấu, nó có thể được đánh dấu lại Khi gói tin di chuyển qua nhiều miền (domain) DS, gói tin đó sẽ được ánh dấu trong một miền cụ thể.
DS có thể phả đi ánh dấu lại khi nó vào m t vùng DS khác phụộ thuộc vào cam kết dịch vụ (SLA) giữa 2 vùng
Phân loại gói tin là quá trình nhóm các gói tin dựa trên các quy tắc phân loại cụ thể Việc phân loại này có thể bắt đầu từ người dùng cuối Trong hệ thống mạng, gói tin được chọn lọc dựa trên các trường trong header, phục vụ cho việc định hướng lưu lượng Có hai phương thức chính để phân loại gói tin.
- Phân loạ đi a trường (Multi-Field, MF)
- Phân loại dựa theo hành vi (Behavior Aggregate, BA) Địa chỉ ngu n/ íchồ đ
Trường DS Định danh giao thức Cổng nguồn/đích
Giao diện vào vân vân
Bộ phân loại đa trường Các lớp gói tin
Hình 1.5 Phân loại gói tin đa trường
Phương pháp phân loại đa trường (MF) cho phép phân loại các gói tin dựa trên một chuỗi giá trị trong các trường của header Bên cạnh các trường trong header, các thông số khác như định danh giao diện đến cũng có thể được sử dụng để cải thiện hiệu quả phân loại.
Phương pháp phân loại BA được bi u di n trên hình 1.6 Trong phương pháp ể ễ này, các gói tin được phân loại dựa trên giá trị DiffServ Code Point (DSCP)
Hình 1.6 Phương pháp phân loại BA
1.3.3 Đ ề i u hoà thông l ượng Đ ềi u hoà thông lượng s ki m tra xem l u lượng d li u đến tại một cổng vào có ẽ ể ư ữ ệ phù hợp với tốc độ thông lượng cam kết giữa người dùng và nhà cung cấp dịch vụ hay không Đ ềi u hoà thông lượng bao gồm việ đc o đạc thông lượng dựa theo tốc độ lưu lượng thiết lập sẵn và đánh dấu ho c ánh d u l i các gói tin dựa theo đầu ra ặ đ ấ ạ của việ đc o đạc Các gói tin có thể ị b loại bỏ ỳ tu thuộc vào chính sách đ ềi u hoà
Hình 1.7 Module đ ềi u hoà thông lượng
Typically, traffic shaping regulates data throughput by comparing the actual data rate against the Committed Information Rate (CIR) and the Peak Information Rate (PIR) To effectively manage CIR and PIR, three additional parameters are utilized: Peak Burst Size (PBS), Committed Burst Size (CBS), and Excess Burst Size (EBS).
1.3.3.2 Tốc độ d li u ữ ệ Để minh hoạ cho các thông s tốc độ dữ ệố li u, ta xét trường h p chuy n ti p gói ợ ể ế tin của một bộ định tuyến IP trong hình 1.8 Các gói tin đến các cổng vào của bộ định tuyến IP theo các đường truyền ho c ặ đường kết nối vật lý Các gói tin này được định tuyến d a theo địa ch ích c a chúng M i c ng ra c a b định tuy n được kết ự ỉ đ ủ ỗ ổ ủ ộ ế nối tới một bộ định tuyến ho c thiết bị khác bằng đường kết nối vật lý Do đó, gói tin ặ tới thiết bị khác (next-hop) Một bảng chuyển tiếp gói tin đã được lưu trữ sẵn trong b ộ định tuyến, bảng này sẽ ánh xạ các gói tin ở cổng vào đến cổng ra tương ứng
B ộ định tuyến IP Đường truyền tin Đường truyền tin
Hình 1.8 Cổng vào, cổng ra và đường truyền tin Tốc độ dòng
Tại một bộ định tuyến biên, dòng dữ liệu có thể đến từ người dùng cuối hoặc mạng LAN của họ Ngược lại, ở bộ định tuyến trung tâm, dòng dữ liệu thường là một đường truyền "backbone" tốc độ cao, vận chuyển dữ liệu từ nhiều kết nối người dùng có tốc độ thấp hơn.
Tốc độ dòng là số lượng bit được truyền qua một đường truyền dữ liệu, được đo bằng bit/giây Trong các đường truyền tín hiệu số, các bit được gửi tại các thời điểm xác định, được gọi là “vị trí bit” Tốc độ dòng được biểu diễn bằng số lượng vị trí bit trong một giây.
Vị trí bit của mạch truyền tín hiệu đã được xác định, do đó bit không thể truyền với tốc độ lớn hơn tốc độ dòng của hệ thống Khoảng thời gian giữa hai vị trí bit liên tiếp trên một đường truyền tín hiệu tỉ lệ nghịch với tốc độ dòng, được gọi là vị trí thời gian liên bit (inter-bit position time).
Tốc độ dữ liệu tối đa (PIR)
Tốc độ dữ liệu tối đa (PIR) là tốc độ mà nhà cung cấp dịch vụ cam kết cung cấp cho người sử dụng Tốc độ này phụ thuộc vào tốc độ đường truyền của từng khách hàng cụ thể, và PIR của người dùng không thể vượt quá tốc độ dòng của họ Đơn vị đo lường PIR là byte/giây, phản ánh tốc độ truyền tải gói tin IP, bao gồm cả header, trong khi các thông tin khác từ tầng 1 và 2 không được tính vào.
Tốc độ dữ liệu cam kết (CIR)
Mô hình Integrated Service
Tổng quan mô hình Integrated Service
Mô hình Dịch vụ Tích hợp được phát triển để mở rộng kiến trúc và giao thức Internet, nhằm cung cấp các dịch vụ tích hợp, bao gồm cả dịch vụ IP thời gian thực và không thời gian thực Sự mở rộng này đáp ứng nhu cầu ngày càng cao về các dịch vụ thời gian thực cho các ứng dụng mới như hội nghị, hội thảo từ xa và giả lập phân tán.
Mô hình IntServ mô tả cách thức áp dụng chất lượng dịch vụ (QoS) trong mạng IP Các chuẩn khác đã được phát triển để xác định các giao thức sử dụng nhằm thực thi QoS hiệu quả.
- Đặt trước tài nguyên được thực hi n b ng giao th c RSVP (Resource ệ ằ ứ Reservation Protocol)
- Đ ềi u khiển nhận được thực hiện trên bộ định tuyến hoặc được chuyển sang các máy chủ ậ t p trung
2.1.1 Những yêu cầu về QoS
Mô hình dịch vụ tích hợp (Integrated Service - IS) tập trung vào thời gian truyền tải các gói tin, trong đó độ trễ của từng gói tin đóng vai trò quan trọng trong việc đảm bảo chất lượng dịch vụ mạng.
Trong chương này, chúng ta sẽ tìm hiểu về hai loại ứng dụng mạng Loại ứng dụng thứ nhất yêu cầu các gói tin phải đến đúng thời điểm xác định; nếu không, gói tin sẽ không có giá trị, được gọi là ứng dụng thời gian thực Loại ứng dụng thứ hai thì luôn chờ cho đến khi gói tin đến, và những ứng dụng này được gọi là ứng dụng mềm dẻo (không phải thời gian thực).
2.1.1.1 Các ứng dụng thời gian thực
Trong ứng dụng thời gian thực, tín hiệu được truyền dưới dạng các gói tin từ nguồn phát đến phía nhận, với độ trễ khác nhau khi đi qua mạng Phía nhận sẽ tổng hợp các gói tin và tái hiện tín hiệu một cách trung thực nhất thông qua việc phát lại tín hiệu Các gói tin đến sau sẽ không có ý nghĩa và bị loại bỏ Để chọn giá trị thích hợp cho thời gian phát lại tín hiệu, ứng dụng cần xác định độ trễ do hệ thống mạng gây ra Thông số này có thể được cung cấp bởi hệ thống mạng dưới dạng một hình thức đảm bảo chất lượng dịch vụ hoặc qua quá trình theo dõi hoạt động của ứng dụng Ứng dụng cần phải biết thông số này, nhưng nó không nhất thiết phải là hằng số trong quá trình truyền.
Hiệu năng của một ứng dụng phát trực tuyến được đánh giá dựa trên hai yếu tố chính: độ trễ và độ trung thực Đặc biệt, các ứng dụng liên quan đến tương
Kết nối giữa hai đầu cuối là rất nhạy cảm với độ trễ, đặc biệt trong các ứng dụng yêu cầu độ trung thực cao như video call Ngược lại, các ứng dụng khác như truyền phát phim hay bài giảng không yêu cầu khắt khe về độ trễ Mỗi loại ứng dụng có những yêu cầu khác nhau về độ trung thực, bao gồm ứng dụng cần độ trung thực cao nhất và ứng dụng có thể chấp nhận mất mát một phần độ trung thực.
2.1.1.2 Các ứng d ng mụ ềm dẻo
Khác với các ứng dụng thời gian thực, các ứng dụng mềm d o không loại bỏ các gói tin nếu độ trễ truyền lan quá lớn, mà luôn đợi dữ liệu đến Điểm khác biệt chính là các ứng dụng này sử dụng dữ liệu ngay lập tức thay vì đưa vào bộ đệm, và quyết định chờ dữ liệu đến thay vì tiếp tục hoạt động mà thiếu dữ liệu Các ứng dụng mềm d o được sử dụng phổ biến trên Internet, ví dụ như các dịch vụ tương tác như Telnet, X, NFS, cũng như các dịch vụ truyền dữ liệu theo đợt như FTP và các dịch vụ truyền dữ liệu không đồng bộ như thư điện tử, fax.
Mô hình dịch vụ thích hợp cho các ứng dụng tương tác là mô hình “nỗ lực tối đa” (best-effort hay as-soon-as-possible, ASAP) Mô hình này cho phép các ứng dụng tương tác có mức ưu tiên cao hơn các người dùng tương tác truyền dữ liệu theo đợt, trong khi các ứng dụng truyền dữ liệu theo đợt lại có mức ưu tiên cao hơn các ứng dụng truyền dữ liệu không đồng bộ.
Bằng cách này, các bộ định tuyến có thể làm giảm độ tr cho các gói tin bình ễ thường
Mô hình đặt trước tài nguyên cho phép ứng dụng yêu cầu một mức chất lượng dịch vụ cụ thể Trong trường hợp đơn giản, ứng dụng sẽ yêu cầu một mức chất lượng và hệ thống mạng sẽ đồng ý hoặc từ chối yêu cầu đó Tuy nhiên, trong thực tế, tình huống thường phức tạp hơn, khi hệ thống cung cấp nhiều loại mức chất lượng dịch vụ khác nhau, và ứng dụng sẽ chọn mức phù hợp từ các mức đã được định nghĩa sẵn.
Hệ thống mạng có khả năng cấp phát mức tài nguyên thấp hơn yêu cầu và thông báo cho ứng dụng về chất lượng dịch vụ được cung cấp Một ví dụ điển hình là mô hình đặt trước "hai lần", trong đó yêu cầu dịch vụ được truyền từ các nguồn Si đến các đích Rj Các bộ định tuyến trên đường truyền sẽ điều chỉnh các thông số để phản ánh khả năng cung cấp dịch vụ Phía nhận sẽ tạo ra yêu cầu về dịch vụ cần thiết và gửi ngược lại yêu cầu này về phía gửi Các thiết bị trên đường truyền nhận yêu cầu có thể điều chỉnh nếu cần, so sánh với yêu cầu ban đầu để đảm bảo tài nguyên cần thiết được dành sẵn.
Những yêu cầu cơ ả b n của IntServ
Đối với IntServ, một luồng IP được xác định bởi các thông s sau: ố
Để đặt trước tài nguyên cho một luồng, cần cung cấp các đặc tả chi tiết về luồng đó, bao gồm thông lượng và yêu cầu dịch vụ Các đặc trưng thông lượng bao gồm tốc độ tối đa, tốc độ trung bình, kích thước bản tin tối đa và các thông số rò ống thẻ Yêu cầu dịch vụ cần thiết bao gồm băng thông tối thiểu và các tiêu chí hiệu năng như độ trễ, jitter và tỷ lệ mất gói tin Giao thức IntServ sử dụng RSVP để thực hiện việc đặt trước tài nguyên cho luồng.
Giao thức đặt trước tài nguyên (RSVP)
RSVP, được mô tả trong RFC 2205, là giao thức đặt trước chất lượng dịch vụ cho mạng IP, hỗ trợ cả IPv4 và IPv6 Giao thức này cho phép đặt trước tài nguyên mạng để đảm bảo chất lượng dịch vụ trong quá trình truyền tải dữ liệu.
Các bên gửi và nhận sẽ trao đổi bản tin RSVP để thiết lập việc phân loại và chuyển tiếp gói tin qua các node trên đường truyền Bên gửi yêu cầu đặt trước, nhưng việc xác định tài nguyên hiện có và thực hiện đặt trước phụ thuộc vào bên nhận Trạng thái đặt trước tài nguyên của các node RSVP không cố định và được cập nhật thường xuyên.
RSVP không phải là giao thức định tuyến mà là một giao thức phục vụ chất lượng dịch vụ Các bản tin RSVP tuân theo đường đi của các gói tin IP, được xác định bởi bảng định tuyến trong các bộ định tuyến Mỗi node trên đường truyền đều phải giữ trạng thái đặt trước, điều này khiến RSVP không phù hợp với các mạng lớn và có khả năng mở rộng kém.
Hình 2.1 Hoạt động c a giao thức RSVP ủ
Một phiên RSVP đượ định nghĩa bởi 3 thông số: c
Hình 2.1 minh họa quy trình hoạt động của RSVP, trong đó bên gửi khởi tạo phiên bằng cách gửi bản tin PATH đến bên nhận Bản tin PATH chứa thông tin về đặc điểm của luồng dữ liệu Khi bản tin PATH di chuyển qua mạng, các bộ định tuyến sẽ ghi nhận định danh và các thông số của luồng dữ liệu Khi nhận được bản tin RESV tương ứng, các bộ định tuyến sẽ đối chiếu thông tin trong bản tin PATH với thông số trong bản tin RESV Cuối cùng, khi bên nhận nhận được bản tin PATH, họ sẽ phản hồi bằng một bản tin RESV, trong đó chứa thông tin liên quan đến việc đặt trước tài nguyên.
2.3.3 Cấu trúc bản tin RSVP
Mỗi bản tin RSVP bao gồm một header chung, tiếp theo là nhiều đối tượng khác nhau Mỗi đối tượng này có header riêng và sau đó là nội dung cụ thể của từng đối tượng.
Header RSVP chung Đối tượng 1 Đối tượng 2 Đối tượng N
Dữ liệu bản tin RSVP
Hình 2.2 Cấu trúc bản tin RSVP
Header của RSVP có định dạng chung dài 64 bit, bao gồm 4 bit cho chỉ số phiên bản RSVP, 4 bit cho loại tin nhắn, 8 bit cho mã loại tin nhắn RSVP, 16 bit cho checksum, 8 bit TTL (Thời gian sống), 8 bit dành riêng và 16 bit cho độ dài bản tin.
Nếu trường check sum được đặt là 0, điều này có nghĩa là bản tin không có check sum Trường Send_TTL xác định giá trị TTL của IP cho bản tin Độ dài của RSVP bao gồm cả header và các đối tượng đi kèm, trong đó các đối tượng này có thể có độ dài khác nhau.
Hình 2.3 Định dạng header chung của RSVP
Có 7 loại bản tin RSVP:
Trường loại bản tin Loại bản tin
Bảng 2.1 Các loại bản tin RSVP
Trong 7 loại bản tin này, các bản tin RESV và PATH được sử dụng nhi u nh t ề ấ cho việc đặt trước tài nguyên Các bản tin khác bao gồm các bản tin lỗi, b n tin theo ả đường xuống, b n tin đặt trước theo chiều xuống và bản tin xác nhận ả Định dạng đối tượng RSVP được mô tả trong hình 2.4 Một đối tượng RSVP bao gồm 32 bit header, tiếp sau là nội dung đối tượng với kích thước không cố định Kích thước của đối tượng là bội số của 32 bit và tối đa là 65 528 bit
Classnum C type Độ dài Nội dung đối tượng
Hình 2.4 Định dạng đối tượng bản tin RSVP
Các đối tượng RSVP được phân loại theo lớp và loại, trong đó trường "Class-Num" xác định lớp đối tượng, còn trường "C Type" xác định một đối tượng duy nhất trong lớp đó.
Các lớp đối tượng sau thường được dùng trong các bản tin RSVP:
- SENDER_TEMPLATE Đối tượng FLOWSPEC chứa các thông số sau về ị d ch v c n cung cấp: ụ ầ
- Tốc độ ng thẻ (đặt trước phía nhận) ố
- Kích cỡ ố ng th (đặt trước phía nh n) ẻ ậ
- Tốc độ truyền dữ liệu tố đi a (đặt trước phía nhận)
Trong bản tin RESV, lớp đối tượng bắt buộc là STYLE (Class-Num = 8), bao gồm một đối tượng duy nhất với C-Type = 1 Đối tượng này định nghĩa kiểu đặt trước tài nguyên.
Phiên b nả Cờ Loại bản tin
= 1 RSVP checksum TTL gửi Dành riêng Độ dài RSVP
SESSION RSVP_HOP TIME_VALUES SENDER_TEMPLATE SENDER_TSPEC
Hình 2.6 Định dạng bản tin RSVP PATH
Hình 2.6 mô tả định dạng một bản tin PATH Bản tin PATH được xác định bằng cách thiết lập trường loại bản tin trong header RSVP thành một
Mỗi node hỗ trợ RSVP trong quá trình truyền tải sẽ xử lý b n tin PATH và thiết lập trạng thái đường truyền cho phiên dữ liệu của phía gửi, dựa trên các thông số yêu cầu của luồng dữ liệu (FLOWSPEC).
Phiên b nả Cờ Loại bản tin
= 2 RSVP checksum TTL gửi Dành riêng Độ dài RSVP
SESSION RSVP_HOP TIME_VALUES FLOWSPEC FILTERSPEC
Hình 2.7 Định dạng bản tin RSVP RESV
Bản tin RESV yêu cầu đặt trước tài nguyên giữa các node thông qua một con đường riêng biệt cho luồng dữ liệu, từ phía nhận đến phía gửi Con đường này cũng chính là con đường mà bản tin PATH sử dụng.
Các kịch bản sử ụ d ng IntServ thường gặp
Hình 2.8 Các kịch bản sử ụ d ng RSVP thường gặp
Hình trên mô tả 3 kịch bản thường gặp khi triển khai các cơ ch QoS cho hệ ế thống mạng thông qua RSVP:
Kịch bản đầu tiên là kích hoạt RSVP trên tất cả các giao diện của bộ định tuyến trong mạng Phương pháp này thường được sử dụng trong các mạng doanh nghiệp, nơi có khả năng dự đoán được các luồng RSVP về số lượng và đường truyền Các nhà cung cấp dịch vụ lớn hơn thường ít có xu hướng sử dụng RSVP trong toàn bộ hệ thống, do RSVP yêu cầu quá nhiều phiên đặt trước đồng thời trên một giao diện thiết bị, hoặc vì các bộ định tuyến không đủ khả năng đảm bảo chất lượng cho các luồng độc lập trên các giao diện băng thông lớn.
Kịch bản thứ hai liên quan đến việc sử dụng giao thức RSVP trong mạng, nơi thông tin thường bị giảm và xảy ra tình trạng tắc nghẽn Các bộ định tuyến biên sẽ đánh dấu các luồng RSVP, cho phép các luồng này được xử lý hiệu quả bởi các bộ định tuyến nhân hỗ trợ DiffServ.
- Kịch b n thứ ba là sử dụả ng RSVP trên biên gi i c a m ng và ph thu c vào ớ ủ ạ ụ ộ việc chuyển tiếp gói tin “nỗ ự ố l c t t nhất” trong nhân
2.5 Ưu đ ể i m và nhược đ ể i m của mô hình Ư đ ểu i m chính c a RSVP: ủ
- Thiết lập các yêu cầu chất lượng dịch vụ theo từng luồng dữ liệu riêng biệt
Hệ thống mạng cần đảm bảo chất lượng cho các luồng dữ liệu Tuy nhiên, khuyết điểm của RSVP là không phù hợp với các hệ thống mạng lớn, vì sẽ có quá nhiều luồng RSVP đồng thời.
RSVP là giao thức thông báo cho các thiết bị mạng về thông số của luồng dữ liệu, bao gồm địa chỉ IP và số hiệu cổng Tuy nhiên, một số ứng dụng sử dụng các số hiệu cổng động khiến cho các thiết bị mạng gặp khó khăn trong việc nhận diện Để giải quyết vấn đề này, người ta sử dụng cơ chế NBAR nhằm bổ sung cho RSVP, giúp cải thiện khả năng nhận diện các luồng dữ liệu.
RSVP cho phép hệ thống mạng từ chối các phiên RSVP khi băng thông trên các giao diện đã đạt đến giới hạn tối đa, tức là tất cả băng thông đã được đặt trước.
Nhược điểm lớn nhất của RSVP là không thích hợp cho các mạng lớn, đặc biệt khi số lượng luồng dữ liệu cần đảm bảo chất lượng lên đến hàng ngàn luồng.
Chương 3 Mô hình Differentiated Service
Chương ba của bài viết tập trung vào mô hình đảm bảo chất lượng dịch vụ Differentiated Service (DiffServ), một mô hình ưu việt hơn IntServ và ngày càng được áp dụng rộng rãi Nội dung chương được chia thành bốn phần chính: phần 3.1 và 3.2 cung cấp cái nhìn tổng quan và các khái niệm cơ bản về DiffServ, phần 3.3 đi sâu vào chi tiết của mô hình này, và phần 3.4 so sánh những ưu điểm của DiffServ so với IntServ.
3.1 Tổng quan mô hình Differentiated Service (DiffServ)
Mô hình DiffServ tổng hợp các luồng dữ liệu thành một số lượng nhỏ các lớp dữ liệu mà không phân biệt giữa các luồng riêng lẻ Trong DiffServ, băng thông và tài nguyên mạng được phân bổ cho các lớp dữ liệu thay vì cho từng luồng dữ liệu riêng biệt Mục tiêu chính của DiffServ là tối ưu hóa hiệu suất trong nội bộ một vùng mạng.
DS thay vì tập trung vào đảm bảo chất lượng trên đường truyền đầu cuối – u cuối đầ
DiffServ cung cấp một số phương pháp xử lý lớp dữ liệu tương đối khác nhau, nhưng không thể đảm bảo một mức chất lượng dịch vụ tuyệt đối Để đạt được chất lượng dịch vụ mong muốn, cần áp dụng các phương pháp kiểm soát nhận vào (admission control) tại biên giới các vùng DS nhằm kiểm soát lượng dữ liệu vào mạng Khác với IntServ, nơi sử dụng RSVP để đặt trước băng thông, chất lượng dịch vụ trong DiffServ được cung cấp mà không cần đặt trước.
Thuật ngữ “DiffServ” đề cập đến việc xử lý dữ liệu của người dùng trong mạng của nhà cung cấp dịch vụ, xác định loại dịch vụ mà người dùng nhận được từ nhà cung cấp, chẳng hạn như ISP Dịch vụ DiffServ được thiết lập dưới một Thỏa thuận mức dịch vụ (SLA) giữa khách hàng và nhà cung cấp dịch vụ DiffServ.
DiffServ được định nghĩa qua các thông số dễ hiểu cho người dùng, như Thoả thuận điều hòa thông lượng (TCA) và các thông số liên quan đến thông lượng, bao gồm độ trễ và băng thông Với định nghĩa dịch vụ DiffServ đã được xác định trước, nhiệm vụ của nhà cung cấp dịch vụ là thiết kế hệ thống mạng nhằm đáp ứng các yêu cầu xử lý dữ liệu của người dùng theo thỏa thuận dịch vụ (SLA).
3.2 Thoả thuận mức dịch vụ (SLA) và Thoả thuậ Đ ề n i u hoà thông lượng (TCA)
Thỏa thuận mức dịch vụ (SLA) là một thỏa thuận giữa nhà cung cấp và người sử dụng, trong đó nhà cung cấp cam kết cung cấp dịch vụ cho người dùng SLA có thể được chia thành hai loại: SLA tĩnh, được thương lượng định kỳ hàng tháng hoặc hàng năm, và SLA động, cho phép thương lượng dịch vụ theo yêu cầu của người sử dụng.
Thông thường SLA bao gồm:
- Loại dịch vụ ầ c n cung cấp
- Hiệu n ng dă ịch vụ cần thi t ph i cung c p, trong đó bao gồm 2 vấn đề chính: ế ả ấ độ tin cậy và độ sẵn sàng
- Quy trình thông báo các lỗi xảy ra đối với d ch vị ụ, bao gồm các thông tin về người cần liên lạc, định dạng thông báo lỗi, …
- Khoảng thời gian quy định từ lúc bắt đầu x y ra lỗi đến lúc khôi phụ ỗả c l i
Quy trình theo dõi chất lượng dịch vụ bao gồm các bước xác định những chỉ số hiệu năng cần theo dõi và thông báo kịp thời khi xảy ra lỗi Cần xác định rõ ai sẽ là người theo dõi, các thông số cụ thể nào sẽ được giám sát, và khoảng thời gian thực hiện các lần đo đạc là bao lâu để đảm bảo hiệu quả trong việc duy trì chất lượng dịch vụ.
- Trách nhiệm của nhà cung cấp dịch vụ khi không đảm bảo được cam kết
SLA bao gồm Thoả thuận điều hoà thông lượng (TCA), được sử dụng để xác định các luật nhận biết dịch vụ mà người dùng áp dụng nhằm đạt được chất lượng dịch vụ mong muốn Nhà cung cấp sử dụng các luật này để thiết lập giới hạn TCA xác định các luật phân loại, profile dữ liệu tương ứng và các luật đo đạc, đánh dấu, loại bỏ, cũng như điều tiết cho các luồng dữ liệu TCA bao gồm toàn bộ các luật điều tiết dữ liệu có trong SLA, cùng với các luồng theo yêu cầu của dịch vụ tương ứng.
Một miền trong mạng IP thường chỉ một khu vực địa lý có biên giới rõ ràng, nơi áp dụng một chính sách nhất định Miền mạng IP là tập hợp các địa chỉ IP nằm dưới quyền kiểm soát của một tổ chức Miền IP có thể bao gồm nhiều mạng nhỏ, có thể tách biệt về địa lý nhưng vẫn thuộc cùng một tổ chức.
Tổng quan mô hình Differentiated Service (DiffServ)
Mô hình DiffServ tổng hợp các luồng dữ liệu thành một số lượng nhỏ các lớp dữ liệu, không phân biệt từng luồng riêng lẻ Với DiffServ, băng thông và tài nguyên mạng được phân bổ cho các lớp dữ liệu thay vì cho từng luồng dữ liệu riêng biệt Mục tiêu chính của DiffServ là tối ưu hóa hiệu suất trong nội bộ một vùng mạng.
DS thay vì tập trung vào đảm bảo chất lượng trên đường truyền đầu cuối – u cuối đầ
DiffServ cung cấp các phương pháp xử lý lớp dữ liệu tương đối khác nhau, nhưng không thể đảm bảo chất lượng dịch vụ tuyệt đối Để đạt được mức chất lượng dịch vụ mong muốn, cần áp dụng các phương pháp kiểm soát nhan (admission control) tại biên để giới hạn lưu lượng dữ liệu vào mạng Khác với IntServ sử dụng RSVP để đặt trước băng thông, chất lượng dịch vụ trong DiffServ được cung cấp mà không cần đặt trước.
Thuật ngữ “DiffServ” đề cập đến cách xử lý dữ liệu người dùng trong mạng của nhà cung cấp dịch vụ, xác định loại dịch vụ mà người dùng có thể nhận từ nhà cung cấp, chẳng hạn như ISP Dịch vụ DiffServ được thiết lập dựa trên Thỏa thuận mức dịch vụ (SLA) giữa khách hàng và nhà cung cấp dịch vụ DiffServ.
DiffServ được định nghĩa qua các thông số dễ hiểu cho người dùng, như Thoả thuận điều hòa thông lượng (Traffic Conditioning Agreement - TCA) và các thông số liên quan đến thông lượng, bao gồm độ trễ và băng thông Dựa trên định nghĩa dịch vụ đã xác định, nhà cung cấp dịch vụ cần thiết kế hệ thống mạng nhằm đáp ứng các yêu cầu xử lý dữ liệu của người dùng theo thỏa thuận dịch vụ (SLA).
Tho ả thuận mức dị ch v ụ (SLA) và Thoả thuậ Đ ề n i u hoà thông lượng (TCA)
Thỏa thuận mức dịch vụ (SLA) là hợp đồng giữa nhà cung cấp và người sử dụng, trong đó nhà cung cấp cam kết về chất lượng dịch vụ Có hai loại SLA: SLA tĩnh được thương lượng định kỳ hàng tháng hoặc hàng năm, và SLA động cho phép điều chỉnh dịch vụ theo yêu cầu của người dùng.
Thông thường SLA bao gồm:
- Loại dịch vụ ầ c n cung cấp
- Hiệu n ng dă ịch vụ cần thi t ph i cung c p, trong đó bao gồm 2 vấn đề chính: ế ả ấ độ tin cậy và độ sẵn sàng
- Quy trình thông báo các lỗi xảy ra đối với d ch vị ụ, bao gồm các thông tin về người cần liên lạc, định dạng thông báo lỗi, …
- Khoảng thời gian quy định từ lúc bắt đầu x y ra lỗi đến lúc khôi phụ ỗả c l i
Quy trình theo dõi chất lượng dịch vụ bao gồm việc xác định các chỉ số hiệu năng cần theo dõi, như độ tin cậy và tốc độ phản hồi Cần chỉ định rõ ai sẽ thực hiện việc theo dõi, những thông số nào sẽ được giám sát, và khoảng thời gian giữ liệu cho các lần đo đạc Ngoài ra, việc thông báo khi xảy ra lỗi là rất quan trọng để đảm bảo chất lượng dịch vụ luôn được duy trì.
- Trách nhiệm của nhà cung cấp dịch vụ khi không đảm bảo được cam kết
SLA bao gồm Thoả thuận điều hoà thông lượng (TCA), được sử dụng để xác định các luật nhận biết dịch vụ Người dùng áp dụng các luật này nhằm đạt được chất lượng dịch vụ mong muốn, trong khi nhà cung cấp sử dụng chúng để thiết lập các giới hạn TCA xác định các luật phân loại, các profile dữ liệu tương ứng, cùng với các luật đo đạc, đánh dấu, loại bỏ và điều tiết cho các luồng dữ liệu Nó bao gồm toàn bộ các luật điều tiết dữ liệu có trong SLA, cũng như các luồng dữ liệu theo yêu cầu của dịch vụ tương ứng.
Mô hình Differentiated Service
Một miền trong mạng IP thường được xác định bởi một khu vực địa lý cụ thể, nơi áp dụng một chính sách nhất định Một miền mạng IP là tập hợp các địa chỉ IP nằm dưới quyền kiểm soát của một tổ chức Miền IP có thể bao gồm nhiều mạng nhỏ, mặc dù các mạng này có thể tách biệt về mặt địa lý nhưng vẫn thuộc về cùng một tổ chức.
Một miền IP được xem là hỗ trợ DiffServ khi nó có khả năng cung cấp dịch vụ phân loại và quản lý lưu lượng dữ liệu Miền này có thể bao gồm cả phần hỗ trợ và không hỗ trợ DiffServ Một miền DS là tập hợp các node DS liên tiếp, hoạt động theo chế độ dịch vụ giống nhau và áp dụng các nhóm PHB (Per Hop Behavior) trên mỗi node Biên giới của miền DS bao gồm các node biên giới có nhiệm vụ phân loại và điều hòa lưu lượng dữ liệu, đảm bảo rằng các gói tin trong miền DS được đánh dấu thích hợp Các node trong miền DS quy định hành vi chuyển tiếp gói tin dựa trên mã DS, ánh xạ giá trị này để thực hiện các PHB tương ứng.
Trong một hệ thống DS, việc xác định PHB hoặc ánh x tự động là rất quan trọng Nếu trong miền DS có một hoặc nhiều node không hỗ trợ DS, chất lượng dịch vụ sẽ bị giảm và không đảm bảo được SLA.
Miền DS Các luồng thông lượng
Hình 3.1 minh họa một miền DS cùng với các thành phần chính của nó Node DS nằm ở biên của miền được gọi là node DS biên giới, trong khi node DS nằm trong miền được gọi là node DS nội miền.
Có hai loại node biên giới: node biên giới vào và node biên giới ra Node biên giới vào là cổng tiếp nhận dữ liệu từ miền dữ liệu (DS), kết nối với node nội miền trong cùng miền DS hoặc với node biên giới của miền khác.
DS khác, hoặc v i m t node không phải là DS Một node nội miền chỉ có thể kết nối với các node nội miền khác hoặc node biên giới trong cùng miền, và không thể kết nối trực tiếp với một node ngoại miền.
Không có yêu cầu bắt buộc nào đòi hỏi một miền DS chỉ có thể ch a các node ứ
DS, tuy nhiên nếu trong một miền DS có chứa các node không phải là DS, hi u qu ệ ả của DiffServ sẽ giảm đi rõ rệt
Hình 3.2 Một miền DS và các mạng nhỏ bên trong
Một miền dịch vụ (DS) có thể chứa nhiều miền nhỏ khác nhau Việc xử lý các gói tin trong miền được quy định bởi một tập hợp các quy tắc chính sách hành vi (PHB) Do một miền DS nằm dưới sự kiểm soát của một tổ chức, có thể xây dựng và áp dụng một tập hợp các quy tắc PHB cố định trên các nút trong miền DS.
Hình 3.3 minh họa một vùng DiffServ (DS) bao gồm một hoặc nhiều miền DS liên tục, thu thập nhiều tổ chức quản lý khác nhau Điều này cho phép một vùng DS cung cấp dịch vụ DiffServ trên các đường truyền IP, kết nối qua nhiều mạng thuộc các nhà cung cấp khác nhau.
Các miền Dịch vụ Chất lượng (DS) độc lập hoạt động theo chính sách và quy định riêng biệt Mỗi miền DS có khả năng sử dụng mã DS riêng (DSCP) cho từng loại dữ liệu Để triển khai DiffServ trong một vùng DS, các miền DS thành viên cần thống nhất về một Thỏa thuận Cấp dịch vụ (SLA) tại các giao diện giữa các miền DS.
Trong SLA, các nhà cung cấp cần thống nhất cách biên dịch DSCP và xử lý thông lượng dữ liệu giữa các miền Một phương pháp khác là áp dụng chính sách điều hòa thông lượng, bao gồm một tập hợp PHB và ánh xạ DSCP cho toàn vùng DiffServ Hình 5-15 minh họa sự khác biệt giữa miền 1 và miền 2 của hai ISP khác nhau Để đảm bảo cung cấp dịch vụ DiffServ từ đầu cuối đến đầu cuối, việc thiết lập SLA giữa hai nhà cung cấp là cần thiết.
3.3.3 Đánh dấu gói tin trong DiffServ
DiffServ sử dụng trường Type of Service (ToS) trong IPv4 và trường Traffic Class (TC) trong IPv6 để đánh dấu gói tin Khi các bộ định tuyến hoạt động trong chế độ bình thường mà không hỗ trợ DiffServ, các trường ToS và TC sẽ được sử dụng theo cách thông thường.
Khi các bộ định tuyến IPv4 và IPv6 hoạt động trong chế độ hỗ trợ DiffServ và là một node DS, các trường ToS và TC sẽ được ghi đè và định nghĩa lại thành trường DiffServ (DS) Điều này có nghĩa là không có trường riêng biệt cho DiffServ trong header IP; thay vào đó, các trường ToS và TC được sử dụng để thực hiện nhiệm vụ đánh dấu DiffServ.
3.3.3.1 Đánh d u gói tin trong các bộ định tuyến thông thường ấ
Hình 3.4 Trường Loại dịch vụ (ToS) trong header IPv4
Hình 3.4 mô tả trường ToS trong header IPv4 Trong một bộ định tuyến thông thường, 8 bit của ToS được định nghĩa trong RFC 791 được cho trong bảng sau:
Thiết lập bit ưu tiên IP Loại thông lượng
Bảng 3.1 Các bit ưu tiên IP
Thiết lập bit Bit D Bit T Bit R
0 Trễ thông thường Thông lượng thông thường Độ tin cậy bình thường
1 Trễ thấp Thông lượng cao Độ tin cậy cao
Bảng 3.2 Các chỉ thị hiệu năng
Ba bit đầu tiên (bit 0, 1, 2) của trường ToS được gọi là các bit ưu tiên IP Theo bảng 3.1, các bit ưu tiên IP tương ứng với các loại thông lượng khác nhau RFC 791 quy định rằng giá trị 111 (ưu tiên điều khiển mạng) chỉ được sử dụng trong các mạng nội bộ, trong khi giá trị 110 (ưu tiên điều khiển liên mạng) chỉ được áp dụng cho các điều khiển gateway.
Ba bit tiếp theo (bit 3, 4, 5) trong trường ToS xác định các đặc trưng hiệu năng của dịch vụ cho các gói tin Bảng 3.2 trình bày các tính năng của các bit D, T và R trong trường ToS Hai bit cuối cùng (6 và 7) của trường ToS được dự kiến sử dụng cho các ứng dụng trong tương lai.
Trong header IPv6, trường TC và Flow Label (FL) đều liên quan đến chất lượng dịch vụ Mặc dù cả hai trường này đều quan trọng, hiện tại chưa có ứng dụng nào khai thác trường FL Trường TC hoạt động tương tự như trường ToS trong IPv4, giúp cải thiện quản lý chất lượng dịch vụ.
Khi một bộ định tuyến sử ụ d ng DiffServ, 8 bit của trường ToS và TC được ghi đè thành trường DS Hình 3.5 mô tả định ngh a trường DS ĩ
Trong 8 bit c a trủ ường DS, 6 bit đầu được dùng để đánh dấu các gói tin DiffServ,
Kiến trúc MPLS
Kiến trúc MPLS được mô tả trong RFC 3031, trong đó một node MPLS là một thiết bị chạy MPLS với khả năng chuyển tiếp gói tin dựa trên nhãn Một miền MPLS bao gồm các node MPLS liền kề, thuộc cùng một miền định tuyến hoặc một miền quản lý, thường do cùng một nhà cung cấp dịch vụ Internet (ISP) quản lý.
Node vào LER Node ra
Các node vào và ra của MPLS, được gọi là node MPLS biên, có nhiệm vụ xử lý dữ liệu khi nó đi vào hoặc ra khỏi miền MPLS Bộ định tuyến chuyển mạch nhãn (LSR) là một node MPLS có khả năng chuyển tiếp các gói tin Lớp 3, trong khi bộ định tuyến nhãn biên (LER) là một LSR nằm tại node vào hoặc ra.
Một miền MPLS được hình thành bởi một nhóm các LSR có cùng mức MPLS Miền này có khả năng được chia thành nhiều miền nhỏ hơn Bộ định tuyến biên trong miền MPLS có thể hoạt động như bộ định tuyến vào hoặc ra.
Khi một gói tin vào miền MPLS, bộ định tuyến phân tích header và gán gói tin vào một lớp FEC Việc ánh xạ FEC được thực hiện bằng cách sử dụng nhãn, với các lớp dịch vụ khác nhau sử dụng nhãn và FEC khác nhau Gói tin sau đó được chuyển tiếp ngay lập tức đến bộ định tuyến tiếp theo mà không cần phân tích thêm Nhãn được sử dụng tại mỗi node như một chỉ mục trong bảng, xác định node tiếp theo và nhãn mới Tất cả quá trình chuyển tiếp trong miền MPLS được quyết định bởi nhãn, và con đường của gói tin qua các LSR được gọi là LSP (Label-Switched Path) Nhãn gán với FEC có thể thay đổi trong miền MPLS, với mỗi bộ định tuyến sử dụng một bảng ánh xạ nhãn để xác định nhãn nào đi với FEC nào.
Để thiết lập bảng định tuyến chuyển tiếp gói tin, các bộ định tuyến cạnh nhau cần có thỏa thuận trước khi gửi gói tin Trong một miền MPLS, nếu một bộ định tuyến nhận gói tin với nhãn mà nó không hiểu, nó sẽ phải phân tích header tầng mạng của gói tin hoặc loại bỏ gói tin đó.
Trong mạng MPLS, một gói tin có thể mang nhiều nhãn khác nhau, đặc biệt khi miền MPLS được chia thành nhiều miền nhỏ Các nhãn này được sắp xếp trong một chồng nhãn, cho phép mạng MPLS hỗ trợ kiến trúc phân lớp Tuy nhiên, quá trình xử lý gói tin mang nhãn không phụ thuộc vào mức độ phân lớp; việc xử lý luôn diễn ra trên nhãn ở vị trí trên cùng của chồng nhãn mà không quan tâm đến các nhãn khác ở trên hoặc dưới.
Một gói tin không nhãn tương đương với một gói tin có chồng nhãn rỗng với độ sâu bằng 0 Khi chồng nhãn của gói tin có độ sâu m, các nhãn sẽ được đánh số thứ tự từ 1 đến m, bắt đầu từ dưới lên, trong đó nhãn dưới cùng được đánh mức 1.
1, nhãn trên cùng đánh mức m
Trong một miền MPLS, Ru và Rd là hai bộ định tuyến quan trọng, với thỏa thuận rằng khi Ru gửi một gói tin mang nhãn L tới Rd, giá trị L sẽ được ánh xạ tới FEC F Điều này cho thấy sự hợp tác giữa hai bộ định tuyến trong việc gán nhãn và quản lý lưu lượng mạng.
FEC F là một phần quan trọng trong việc gửi gói tin từ R u tới R d Trong mối quan hệ này, L trở thành nhãn ra của R u, trong khi FEC F là nhãn vào của R d Điều này có nghĩa là nhãn L chỉ tương ứng với FEC F giữa R u và R d, và không nhất thiết phải tương ứng với F cho bất kỳ gói tin nào khác không gửi từ R u đến R d Tóm lại, việc biểu diễn F bằng L chỉ có giá trị trong mối quan hệ giữa R u và R d.
RSVP-TE là giao thức tín hiệu được sử dụng để thiết lập LSP, bao gồm hai loại bản tin cơ bản: PATH và RESV Bản tin PATH di chuyển từ phía gửi đến phía nhận, mang theo yêu cầu gán nhãn cho một LSP cụ thể Nhãn này được xác định dựa trên đường truyền tin và được phân phối qua các bản tin RESV.
Chồng nhãn được biểu diễn bằng một chuỗi các phần tử nhãn M i ph n t ỗ ầ ử nhãn được biểu diễn bởi 4 byte (hình 4.3)
Header tầng mạng và gói tin
Hình 4.3 Thông tin nhãn của MPLS
Trong môi trường không phải ATM, nhãn chứa 20 bit, 3 bit trường thử nghiệm, 1 bit chỉ định nhãn trong chồng, và 8 bit Time-To-Live (TTL) Ngược lại, trong môi trường ATM, phần tử nhãn chỉ chứa nhãn mã hóa trường VCI/VPI.
MAC header Shim header IP header
GFC VPI VCI PTI CLP HEC
Các phần tử chồng nhãn nằm sau header tầng Liên kết dữ liệu và trước header tầng mạng Đỉnh của chồng nằm đầu tiên, trong khi đáy của chồng nằm sau cùng trong thứ tự xuất hiện trong gói tin Mỗi phần tử nhãn được chia nhỏ thành các thành phần khác nhau.
- Đáy chồng (S): bit này được thiế ật l p để ch định ph n t ang áy ch ng, ỉ ầ ử đ ở đ ồ và bị xoá với tấ ảt c các ph n t khác ầ ử
Giá trị Time-To-Live (TTL) được mã hóa bằng 8 bit, được gán cho trường IP TTL khi gói tin bắt đầu được đánh dấu Giá trị này sẽ giảm dần khi gói tin di chuyển qua các node MPLS Cuối cùng, khi nhãn MPLS được loại bỏ, giá trị TTL của MPLS sẽ được sao chép vào trường IP TTL.
- Dùng thử nghiệm: 3 bit này được dùng với mục đích th nghi m, ử ệ
Giá trị nhãn 20 bit chứa thông tin quan trọng về nhãn của gói tin Khi gói tin có nhãn được chuyển đến, giá trị này được phân tích từ đỉnh của ngăn xếp Nhờ đó, bộ định tuyến có thể xác định node tiếp theo để chuyển tiếp gói tin và thực hiện các thao tác cần thiết trên ngăn xếp nhãn, như thay thế phần tử đỉnh hoặc loại bỏ nó.
Bộ định tuyến không chỉ biết node tiếp theo và thao tác với chồng nhãn mà còn có khả năng thu thập nhiều thông tin khác để chuyển tiếp gói tin chính xác Việc thêm nhiều nhãn vào gói tin có thể làm tăng kích thước gói vượt quá giá trị MTU, do đó, LSR cần hỗ trợ một tham số xác định kích thước bản tin IP tối đa Bất kỳ bản tin nào có kích thước lớn hơn giá trị này sẽ bị chia nhỏ để đảm bảo quá trình truyền tải diễn ra suôn sẻ.
4.2.3.2 Hoạt động cơ ả b n của chồng nhãn
Giả sử một LSP m c m cho m t gói tin P là m t chu i có th tựứ ộ ộ ỗ ứ các b ộ định tuyến {R 1 ,…, Rn} Khi đó những bộ định tuyến này sẽ có những thuộc tính sau:
- R1 là bộ định tuyến vào, do đó nó s đẩy nhãn vào ch ng nhãn c a P, t ó ẽ ồ ủ ừ đ thu được chồng nhãn có độ sâu m
- Với mọi i, 1 < i < n, P có chồng nhãn độ sâu m khi t i LSR Rớ i, và có chồng nhãn có độ sâu không quá m khi di chuyển từ R1 tới Rn-1
- Với mọi i, 1 < i < n, Ri gửi P t i Rớ i+1 bằng cách s dụử ng nhãn t i ạ đỉnh chồng (nhãn mức m) làm chỉ mục t i b ng ánh x nhãn c a nó và m t giá tr nhãn ớ ả ạ ủ ộ ị mức m mới
- Với mọi i, 1 < i < n, nếu mộ ệt h th ng S nh n đượố ậ c P sau khi nó được g i b i ử ở
Phân phối nhãn
Việc yêu cầu gán nhãn FEC có thể bắt đầu bằng LSR theo chiều xuôi hoặc chiều ngược Để đảm bảo điều này, mỗi LSR có thể gán nhãn một cách độc lập, và việc
Giao thức phân phối nhãn bao gồm các thao tác cho phép một LSR thông báo cho các LSR khác về ánh xạ FEC-nhãn mà nó đã gán Hai LSR sử dụng giao thức này để trao đổi thông tin ánh xạ FEC-nhãn được gọi là hai node ngang hàng.
Hai LSR có thể phân phối nhãn ngang hàng cho một tập hợp ánh xạ nhất định, nhưng không đảm bảo tính tương đồng với các ánh xạ khác Giao thức phân phối nhãn bao gồm các thao tác thương lượng giữa hai node để trao đổi nhãn Giả sử một ánh xạ nhãn L tại FEC F được phân phối từ Ru, nó sẽ mang theo một số thuộc tính nhất định Nếu Ru là node cha của node Ri trong F, Ru cũng cần phải phân phối ánh xạ nhãn (không nhất thiết là nhãn L) đến FEC F cho Ri, cùng với các thuộc tính mà nó nhận được từ Ru.
Trong mạng MPLS, có nhiều giao thức phân phối nhãn khác nhau, bao gồm các giao thức BGP và RSVP được mở rộng để hỗ trợ việc phân phối nhãn Bên cạnh đó, còn tồn tại những giao thức mới được định nghĩa đặc biệt cho mục đích phân phối nhãn.
4.3.1 Phân phố i xuôi dòng t nguyện và xuôi dòng theo yêu cầu ự
Một LSR ngược chiều có thể yêu cầu một ánh x nhãn tường minh cho một FEC nhất định, quá trình này được gọi là phân phối nhãn theo yêu cầu xuôi dòng Đồng thời, kiến trúc MPLS cũng cho phép LSR xuôi chiều phân phối ánh xạ nhãn cho các LSR ngược chiều mà không cần yêu cầu nhãn tường minh, điều này được gọi là phân phối nhãn xuôi dòng tự nguyện.
4.3.2 Các chế độ ch n nhãn: tự do và bảo thủ ặ
Một LSR Rd có khả năng phân phối một ánh x nhãn cho một FEC nhất định, mặc dù Rd không phải là hop tiếp theo của Ru trong FEC đó.
Trong trường hợp này, Ru có hai lựa chọn: Thứ nhất, trong chế độ chặn nhãn tự do, Ru sẽ duy trì và theo dõi các ánh xạ Thứ hai, trong chế độ chặn nhãn bảo thủ, Ru sẽ loại bỏ ánh xạ đó.
Trong chế độ chuyển nhãn tự do, Rặu có thể sử dụng ánh xạ nhãn ngay khi Rd trở thành hop tiếp theo của FEC Ngược lại, trong chế độ chuyển nhãn bảo thủ, Ru cần yêu cầu gửi lại nhãn khi Rd trở thành hop tiếp theo.
Chế độ chặn nhãn tự do cho phép hệ thống nhanh chóng điều chỉnh theo sự thay đổi của đinh tuyến, trong khi chế độ chặn nhãn bảo thủ yêu cầu LSR chỉ cần duy trì một số lượng nhãn rất ít.
4.3.3 Kiểm soát LSP: có thứ ự t và độc lập
Một số FEC liên quan đến các tiền tố địa chỉ được phân phối trong thuật toán định tuyến động Việc lập các LSP cho các FEC này có thể thực hiện theo hai cách: kiểm soát LSP tự do hoặc kiểm soát LSP có thứ tự.
Với kiểm soát LSP tự do, mỗi LSR sẽ tự động gán nhãn cho FEC nhất định khi nhận được thông báo, đồng thời phân phối nhãn đó cho các node ngang hàng Quy
Kiểm soát LSP có thứ tự cho phép m t LSR gán nhãn cho một FEC nhất định, nhằm xác định rõ ràng nó là LSR của FEC đó hoặc đã nhận được ánh xạ nhãn từ hop tiếp theo Để đảm bảo thông lượng của một FEC nhất định theo một con đường với các thông số đã được xác định, việc sử dụng kiểm soát LSP có thứ tự là cần thiết.
Với kiểm soát độc lập, một số LSR có khả năng chuyển nhãn thông lượng dữ liệu trước khi LSP hoàn tất, dẫn đến việc một số dữ liệu của FEC có thể đi qua các đường khác nhau Trong khi đó, kiểm soát có thứ tự ngược lại đảm bảo rằng tất cả dữ liệu sẽ đi trên cùng một con đường.
Hai chế độ kiểm soát, bao gồm kiểm soát có thứ tự và kiểm soát độc lập, không hoạt động đồng thời với nhau Tuy nhiên, nếu không phải tất cả các LSR trong LSP áp dụng kiểm soát theo thứ tự, thì hành vi của hệ thống mạng sẽ thể hiện nhiều đặc tính của kiểm soát độc lập Điều này xảy ra vì không thể đảm bảo rằng một LSP chỉ được sử dụng khi nó đã được thiết lập hoàn chỉnh.
4.3.4 Phân phối nhãn ngang hàng và phân cấp
Xử lý hop áp chót
Hình 4.5 Các đường hầm LSP lồng nhau
Xét LSP {R1, R2, R3, R4}, khi R1 nhận gói tin không nhãn P, nó sẽ cập nhật chồng nhãn và chuyển tiếp gói tin lên đường truyền R2 và R3 không kết nối trực tiếp mà là hai đầu của một đường hầm LSP Gói tin P sẽ đi qua con đường thực tế {R1, R2, R2 1, R2 2}.
Trên quan đ ểi m của LSP mức 2, node ngang hàng phân phối nhãn của R 2 là
MPLS hỗ trợ Differentiated Service
Trong miền MPLS, LSP được thiết lập thông qua giao thức báo hiệu MPLS Tại các bộ định tuyến nhãn vào (LSR), mỗi gói tin sẽ được gán một nhãn và được truyền theo chiều đường truyền Chức năng cơ bản của nhãn tại mỗi LSR trung gian là ánh xạ tới hop tiếp theo để đảm bảo việc chuyển tiếp gói tin hiệu quả.
Trong miền DiffServ, các gói tin IP cùng yêu cầu xử lý giống nhau được nhóm thành một BA Tại các node vào, gói tin được phân loại và đánh dấu bằng mã DSCP tương ứng với BA Tại các node trung gian, DSCP giúp chọn PHB phù hợp để quyết định cách xử lý gói tin, và có thể dẫn đến việc loại bỏ gói tin trong một số trường hợp OA là tập hợp các BA có chung ràng buộc.
MPLS cung cấp khả năng dự đoán và phục hồi nhanh chóng hơn các hệ thống IP hop tới hop khi có thay đổi trong topology Những khả năng này làm tăng độ tin cậy của MPLS, cung cấp nhiều mức bảo vệ khác nhau cho các LSP Để hỗ trợ DiffServ trên mạng MPLS, quản trị viên cần linh hoạt trong việc ánh xạ BA tới các LSP, đảm bảo phù hợp với DiffServ, kiểm soát thông lượng và các mục tiêu bảo vệ trong mạng.
Khi một gói tin đến một LSR, ngoài việc chuyển tiếp dựa trên FEC, còn có hai thông tin quan trọng khác là lớp dịch vụ và mức ưu tiên Hai yếu tố này cần được xem xét để LSR xử lý gói tin theo yêu cầu đã được thiết lập trước đó.
Lớp dịch vụ của một gói tin thông thường được xác định trước và thường được mạng theo header gói tin, hoặc được rút ra từ nhãn gói tin theo một bảng ánh xạ nhãn gói tin tới lớp dịch vụ của mạng Ngược lại, mức ưu tiên loại bỏ gói tin được xác định động, do đó nó luôn được kèm theo header gói tin.
3 bit EXP của MPLS shim header có thể được dùng để lưu tr thông tin khi c n ữ ầ
Sử dụng EXP, có 2 loại LSP có thể kết hợp lại để hỗ ợ tr DiffServ trên MPLS:
Các LSP có khả năng vận chuyển nhiều OA, đặc biệt trong trường hợp EXP, vận chuyển PHB tới LSR để áp dụng lên gói tin PHB chứa thông tin về việc xử lý gói tin và mức ưu tiên loại bỏ của nó Loại lớp sắp xếp PHB này, gọi là PHB Scheduling Class (PCS), được rút ra từ EXP, và các LSP tương ứng được gọi là E-LSP Với E-LSP, nhãn là kết hợp giữa FEC và tập các BA vận chuyển qua E-LSP Nếu tất cả các BA được hỗ trợ đều được vận chuyển trên E-LSP, nhãn sẽ bao gồm toàn bộ FEC Trong trường hợp E-LSP, một LSP đơn có thể hỗ trợ 8 BA của một FEC, và trường EXP được LSR dùng để xác định PHB tương ứng cần áp dụng lên gói tin.
Các LSP chỉ có một OA, và việc xử lý gói tin được LSR thực hiện dựa trên giá trị nhãn của gói tin, với mức độ ưu tiên được ghi trong trường EXP của MPLS shim header Loại PSC này được gọi là PSC chỉ dựa trên nhãn, và LSP tương ứng được gọi là LSP chỉ dựa trên nhãn (L-LSP) Đối với L-LSP, nhãn của gói tin mang ý nghĩa của FEC và OA, cho phép thiết lập một LSP riêng cho mỗi cặp FEC-OA PSC được xác định rõ ràng tại thời điểm thiết lập nhãn, giúp LSR dễ dàng rút ra giá trị nhãn PSC thích hợp cho gói tin Khi sử dụng shim header, mức độ ưu tiên loại bỏ gói tin được ghi trong shim header, trong khi khi không sử dụng shim header, mức độ ưu tiên này được ghi trong header tầng liên kết dữ liệu.
Với một FEC đã xác định, người quản trị hệ thống có thể lựa chọn các LSP thuộc hai loại khác nhau trong miền MPLS-DiffServ Việc lựa chọn các LSP phù hợp và cách gửi các BA qua các LSP này là rất quan trọng để đảm bảo hiệu quả tối ưu trong việc duy trì chất lượng dịch vụ.
Có thể có nhiều hợp nhất (LSP) sử dụng cùng một chỉ định (OA) cho một kết nối đầu cuối (FEC) nhất định, nhằm mục đích cân bằng tải cho OA Để tuân thủ các quy định về sắp xếp, tất cả các gói tin của một luồng nhỏ có thể được vận chuyển qua nhiều đường dẫn (BA) của cùng một OA, nhưng phải được đảm bảo rằng tất cả các BA này đều được xử lý trên cùng một LSP Ngược lại, mỗi LSP cần phải có khả năng hỗ trợ tất cả các BA của OA.
Thiết lập một E-LSP hoặc L-LSP với yêu cầu đặt trước băng thông có nghĩa là các yêu cầu về băng thông cho LSP được thông báo kịp thời để thiết lập LSP Những yêu cầu báo hiệu băng thông này cho phép các LSR sử dụng để điều chỉnh việc thiết lập nhằm thực hiện kiểm soát LSP trên nguồn tài nguyên DiffServ Đồng thời, các yêu cầu này cũng có thể được sử dụng để thực hiện các điều chỉnh tài nguyên DiffServ liên quan đến các PSC.
Khi các yêu cầu về băng thông được báo hiệu trong quá trình thiết lập L-LSP, băng thông này sẽ được liên kết với PSC của L-LSP Do đó, các LSR sử dụng băng thông yêu cầu để kiểm soát đầu vào có thể thực hiện chức năng kiểm soát đầu vào trên các tài nguyên DiffServ dành cho PSC, chẳng hạn như trên băng thông đảm bảo cho các PSC.
Khi yêu cầu về băng thông được báo hiệu tại thời điểm thiếu hụt, bảng băng thông đó sẽ được liên kết với toàn bộ LSP, tức là toàn bộ tập các PSC Do đó, các LSR sử dụng bảng thông yêu cầu để kiểm soát đầu vào, nhằm thực hiện chức năng kiểm soát đầu vào trên các tài nguyên toàn cục được chia sẻ bởi các PSC, chẳng hạn như băng thông tổng cộng của đường truyền.
Mô hình Gửi nhãn cho các bộ định tuyến hỗ trợ MPLS trong mô hình
Các OA khác nhau của một FEC có thể di chuyển trên các LSP khác nhau, do đó, quyết định tráo nhãn của một LSR DiffServ phụ thuộc vào BA của gói tin chuyển tiếp Một LSR có khả năng phân tích trường IP DS của gói tin, dẫn đến phương pháp xác định PHB áp dụng cho gói tin đến và mã hóa PHB vào gói tin đi sẽ khác biệt so với các bộ định tuyến không hỗ trợ MPLS DiffServ.
Để mô tả vi chuyển tiếp nhãn của các LSR DiffServ, hành vi chuyển mạch nhãn của LSR DiffServ có thể được mô hình hóa qua bốn bước chính.
- Xác định PHB đ ựi d a theo i u hoà thông lượng Đ ề
- Mã hoá các thông tin DiffServ vào gói tin
Quá trình này xác định gói tin thuộc về BA nào PHB tới có thể xác định bằng cách phân tích phần tử chồng nhãn hoặc IP header
4.5.2 Xác định PHB đ i d ựa theo Đ ề i u hoà thông lượ ng
Quá trình điều hòa thông lượng không bắt buộc và có thể áp dụng lên một LSR, bao gồm cả việc nâng cấp hoặc giáng cấp BA Mục đích là xác định việc chuyển tiếp DiffServ trên MPLS, với lưu ý rằng một PHB được áp dụng và chuyển cho các LSR khác từ một LSR xác định có thể khác với PHB liên kết với gói tin đến (hay còn gọi là PHB đến).
Khi không có quá trình đ ềi u hoà thông lượng, PHB đi sẽ giống hệt PHb đến
Việc tráo nhãn được thực hi n b i các LSR trên các gói tin đến được gán nhãn ệ ở bằng cách sử dụng ánh x nhãn t i (ILM) ánh x nhãn v i m t ho c nhi u NHLFE ạ ớ ạ ớ ộ ặ ề
Ngoài ra, việc gán nhãn lên các gói tin đến không mang nhãn được thực hiện bằng cách ánh xạ FEC t i một hoặc nhiều NHLFE (ánh xạ FTN) ớ
Một ngữ cảnh DiffServ cho một nhãn đượ định nghĩa bao gồm: c
- Loại LSP (E-LSP hay L-LSP)
- Ánh xạ Encaps-to-PHB cho nhãn tới
- Ánh xạ PHB-to-Encaps cho nhãn đi
Trong ngữ cảnh DiffServ, thông tin có thể được lưu trữ trong ILM cho mỗi nhãn đến Bên cạnh đó, NHLFE cũng có khả năng chứa các thông tin cần thiết khác để xử lý gói tin Đồng thời, một ngữ cảnh DiffServ cũng có thể được lưu trong NHLFE cho các nhãn đi Thông tin ngữ cảnh DiffServ này được ghi vào ILM và FTN tại thời điểm thiết lập nhãn.
Nếu nhãn tương ứng với một E-LSP mà không có ánh xạ EXP-PHB nào được xác định tường minh tại thời điểm thiết lập LSP, việc thiết lập các PHB hỗ trợ sẽ được thực hiện bằng tập PHB của ánh xạ EXP-PHB đã được cấu hình trước Ngược lại, nếu nhãn tương ứng với một E-LSP có ánh xạ EXP-PHB đã được xác định tường minh, việc thiết lập các PHB hỗ trợ sẽ dựa trên tập PHB của ánh xạ EXP-PHB đó Trong trường hợp nhãn tương ứng với một L-LSP, việc thiết lập các PHB hỗ trợ sẽ được thực hiện dựa trên tập PHB tạo nên PSC được báo hiệu tại thời điểm thiết lập LSP.
Khi ILM (hoặc FTN) ánh xạ một nhãn nhất định tới nhiều NHLFE có nhiều hơn một thành phần, chỉ một thành phần sẽ được chọn trước khi gói tin được chuyển tiếp Hơn nữa, một nhãn tối có thể được ánh xạ tới nhiều NHLFE để phục vụ cho mục đích của DiffServ Khi một nhãn ánh xạ tới nhiều NHLFE, LSR DiffServ phải chọn một trong các NHLFE, và ngữ cảnh DiffServ của NHLFE này sẽ xác định PHB cho gói tin chuyển tiếp.
Khi một nhãn FEC ánh xạ tới nhiều NHLFE trong PHB, việc cân bằng tải trên nhiều LSP có thể gặp khó khăn Để tuân thủ các ràng buộc sắp xếp, tất cả các gói tin trong một luồng nhỏ phải được gửi qua cùng một LSP.
4.5.4 Mã hoá các thông tin DiffServ vào gói tin
Quá trình này xác định cách mã hoá các trường chứa thông tin DiffServ trong gói tin truyề đn i (ví dụ, trường EXP trong MPLS shim header, ATM CLP, …)
4.6 Ứng dụng của MPLS Ý tưởng chủ yếu c a MPLS là sử ụủ d ng cơ ch chuyển tiếp gói tin dựa trên nhãn ế có thể kết h p các nhi u module i u khi n khác Mỗợ ề đ ề ể i module i u khi n chịu trách đ ề ể nhiệm gán và phân phối một tập nhãn, đồng thời với các thông tin đ ềi u khi n liên ể quan Ví dụ, m t bộ ộ định tuyến MPLS có thể ồ g m có:
Module định tuyến unicast xây dựng bảng định tuyến dựa trên các giao thức định tuyến IP thông thường, gán nhãn cho các đường, và phân phối nhãn qua giao thức phân phối nhãn (LDP).
- Một module đ ềi u hoà, kiểm soát thông lượng, module này xác định con đường tường minh để truyền dữ ệ li u có ki m soát ể
Mạng riêng ảo (VPN) là một module xây dựng các bảng định tuyến chuyên dụng cho VPN thông qua giao thức BGP, đồng thời phân phối nhãn liên quan đến các đường truyền VPN.
MPLS cho phép các module gán nhãn cho gói tin theo nhiều tiêu chí khác nhau, tách biệt việc chuyển tiếp gói tin khỏi nội dung header Thuộc tính này rất quan trọng cho các chức năng như kiểm soát, điều hòa lưu lượng và hỗ trợ VPN.
4.6.1 Kiểm soát, đ ề i u hoà thông lượng
Kiểm soát và điều hòa thông lượng là khả năng quản lý các luồng thông lượng trong mạng nhằm giảm thiểu tắc nghẽn và tối ưu hóa băng thông Các luồng thông lượng IP truyền thống thường được định tuyến theo cơ chế hop tới hop, sử dụng giao thức IGP (Interior Gateway Protocol) để xác định đường đi ngắn nhất cho việc chuyển tiếp gói tin Tuy nhiên, việc sử dụng con đường ngắn nhất có thể dẫn đến những vấn đề nghiêm trọng, vì nó phụ thuộc vào thông tin tĩnh về kết nối mà không xem xét các tài nguyên mạng có thể sử dụng hoặc yêu cầu của thông lượng trên con đường đó.
- Đường ngắn nhất từ nhiều nguồn phát có thể ch ng lên nhau, tạo thành tắc ồ nghẽn trên các đường kết nối đó
- Thông lượng từ nguồn phát tớ đi ích có thể vượt quá khả năng c a con ủ đường ngắn nhất, trong khi m t đường khác dài h n l i không được s d ng ộ ơ ạ ử ụ hết
4.6.1.1 Ví dụ đ ề i u hoà thông lượng
Hình 4.7 Tắc nghẽn xảy ra khi sử ụ d ng phương pháp chọn đường ngắn nhất
Trong hình 4.7, có hai đường đi từ bộ định tuyến C đến bộ định tuyến E, gọi là đường 1 và đường 2 Nếu bộ định tuyến chọn đường C-D-E để truyền dữ liệu đến E, nó sẽ gửi tất cả dữ liệu qua đường này, dẫn đến tình trạng tắc nghẽn, trong khi đường C-F-G-H-E lại không bị ảnh hưởng Để tối ưu hóa hiệu suất, việc chuyển một phần dữ liệu sang các liên kết khác là cần thiết Một cách tiếp cận thông thường là thiết lập chi phí cho đường C-D-E tương đương với chi phí cho đường C-F-G-H-E, nhưng cách này không hiệu quả trên các mạng có topo phức tạp Do đó, việc sử dụng định tuyến tường minh của MPLS là giải pháp linh hoạt, cho phép tách một phần dữ liệu ra khỏi đường bị tắc nghẽn và chuyển sang một đường khác.
Giải pháp điều hòa thông lượng dựa trên khả năng của MPLS cho phép thiết lập nhãn và đường gán nhãn thông qua nhiều module kiểm soát khác nhau Chẳng hạn, module điều hòa thông lượng có thể tạo ra hai đường gán nhãn: đường 1 từ B đến E và đường 2 từ A đến E Bằng cách thiết lập các chính sách lựa chọn gói tin cho các đường này, người dùng có thể kiểm soát thông lượng hiệu quả trên cả hai đường.
Để khắc phục tình trạng tắc nghẽn và điều tiết thông lượng, IETF đã đưa ra giải pháp định tuyến dựa trên ràng buộc và IGP nâng cao Mỗi LSP có thể được gán một hoặc nhiều thuộc tính nhằm kiểm soát con đường một cách hiệu quả Những thuộc tính này sẽ được sử dụng để tính toán đường đi cho LSP.
- Băng thông: băng thông tối thiểu có thể đặt trước trên LSP
- Thuộc tính đường: thuộc tính quyết định xem đường LSP được thiết lập bằng tay hay được tự động tính toán bằng định tuyến dựa trên ràng bu c ộ
- Mứ ưc u tiên thi t l p: quyếế ậ t định LSP nào s nh n ẽ ậ được tài nguyên khi có nhiều LSP cạnh tranh nhau
- Mứ ưc u tiên lưu giữ: quyết định một tài nguyên giữ bởi m t LSP có th bị ộ ể LSP khác lấy m t hay không ấ
- Lực h p dẫn (màu): thuấ ộc tính của LSP do người quản trị thiế ật l p
- Khả năng thích nghi: xác định kh năả ng chuy n LSP sang một ể đường khác tối ưu hơn khi có thể
- Khả năng ph c h i: khả năụ ồ ng định tuy n l i LSP khi con đường hiệế ạ n t i g p ạ ặ sự cố
Ứ ng d ng c a MPLS 76 ụ ủ
Trong các chương trước, luận văn đã trình bày các mô hình đảm bảo chất lượng dịch vụ cơ bản, đặc biệt trong chương 4 với các khái niệm cơ bản về các cách thức đảm bảo chất lượng dịch vụ trong mạng MPLS Chương này sẽ đi sâu vào việc đánh giá chất lượng một số dịch vụ dữ liệu trên mạng MPLS thông qua các phương pháp đánh giá định tính và định lượng Mục đích của việc đánh giá là đưa ra các mô hình áp dụng QoS cho một số trường hợp cung cấp dịch vụ tiêu biểu.
5.1 Đặc trưng của MPLS và những tiêu chí đánh giá QoS
Trong hệ thống mạng MPLS, việc đảm bảo chất lượng dịch vụ (QoS) có những điểm khác biệt rõ rệt so với mạng IP truyền thống Những khác biệt này chủ yếu xuất phát từ các đặc trưng của MPLS trong xử lý và định tuyến gói tin Hai yếu tố chính tạo nên ưu điểm lớn nhất của MPLS là khả năng quản lý lưu lượng và tối ưu hóa đường truyền.
- Việc sử dụng phương pháp chuyển mạch nhãn làm tăng tốc độ xử lý gói tin của các thiết bị chuyển mạch, định tuyến
Việc sử dụng nhãn gán cho đường đi giúp định tuyến dữ liệu có chung đặc tính trên những con đường xác định, từ đó đảm bảo chất lượng dịch vụ Điều này rất quan trọng vì trên những con đường này, các phương pháp đảm bảo QoS có thể được áp dụng để đạt được chất lượng yêu cầu.
MPLS mang lại lợi ích vượt trội trong việc định tuyến tường minh và phân loại gói tin, cho phép áp dụng các phương pháp đảm bảo chất lượng dịch vụ khác nhau cho từng lớp gói tin Ban đầu, MPLS được phát triển nhằm tăng tốc độ xử lý gói tin trong chuyển mạch và định tuyến Mục tiêu chính của MPLS là hỗ trợ điều tiết, tối ưu hóa thông lượng và đảm bảo chất lượng dịch vụ.
MPLS đã nhanh chóng trở thành công nghệ lý tưởng cho các nhà cung cấp dịch vụ nhằm đảm bảo chất lượng dịch vụ đến tay người dùng Mặc dù thời gian phát triển còn ngắn, nhưng MPLS đã thu hút sự chú ý đặc biệt và được áp dụng rộng rãi Dựa trên những đặc trưng nổi bật, chương cuối cùng sẽ tập trung vào việc đánh giá các dịch vụ dữ liệu trên MPLS.
5.1.2 Các tiêu chí đánh giá QoS
Đánh giá chất lượng mộ t s d ch v d ố ị ụ ữ liệu trên mạng
Thực hiện mô phỏng và đánh giá
5.2.1 Xây dựng môi trường mô phỏng
Môi trường thực hiện các mô phỏng trong chương năm gồm có:
- Môi trường phần cứng: 1 máy tính nền Intel, bộ vi xử lý Pentium IV 2,8 GHz,
Môi trường phần mềm cần thiết bao gồm hệ điều hành Windows XP Service Pack 2, phần mềm mô phỏng môi trường Linux trên Windows là Cygwin phiên bản 1.5.18-1, và phần mềm mô phỏng mạng NS-2 phiên bản 2.28, được sử dụng trên Cygwin.
Các kịch bản mô phỏng được thực hiện trên phần mềm NS-2
5.2.2 Đ ánh giá QoS cho d liệu thông thường ữ
Luận văn này sẽ tiến hành so sánh chất lượng dịch vụ giữa hai giao thức UPD và TCP khi chúng được truyền tải trên một đường truyền MPLS (MPLS trunk).
Hình 5.1 Mối liên hệ gi a lu ng, trunk, LSP và đường kết nối ữ ồ
TCP và UDP phản ứng khác nhau với tình huống tắc nghẽn mạng TCP có cơ chế kiểm soát tắc nghẽn, tự động điều chỉnh tốc độ truyền dữ liệu khi xảy ra mất gói tin, trong khi UDP không có cơ chế này và không thực hiện điều chỉnh nào Mặc dù lý thuyết cho phép xây dựng ứng dụng UDP có khả năng thích ứng với tắc nghẽn, nhưng thực tế rất ít ứng dụng như vậy được phát triển.
Hình 5.2 Topo mạng mô phỏng TCP & UDP
Hình 5-2 minh họa topo mạng mô phỏng với 6 bộ định tuyến và 6 đầu cuối Tất cả các bộ định tuyến đều hỗ trợ công nghệ MPLS, cho phép tối ưu hóa hiệu suất mạng.
Trong mạng có 3 luồng dữ liệu mô phỏng nh sau: ư
- Đầu cuối phát S 1 gửi dữ liệu UDP với đầu cuối nhận D 1
- Các đầu cuối phát S2 và S3 gửi dữ liệu TCP tường ứng tới các đầu cuối nhận
- S1 gửi dữ liệu UDP với tốc độ cố định, S2 và S3 là những nguồn phát FTP liên tục, gửi dữ liệu FTP trong giới hạn tắc nghẽn cho phép
Hai luồng TCP có sự khác biệt về kích thước gói tin: Luồng TCP1 giữa S2 và D2 có kích thước 512 byte, trong khi Luồng TCP2 giữa S3 và D3 có kích thước 1024 byte Bên cạnh đó, luồng UDP có kích thước gói tin là 210 byte.
Trong hình vẽ, có hai đường kết nối từ bộ định tuyến R2 tới R5: đường R2-R3-R5 với tốc độ 45 Mbps và đường R2-R4-R5 với tốc độ 15 Mbps Ngoài ra, đường kết nối R1-R2 và R5-R6 có tốc độ cao hơn, đạt 60 Mbps.
- Độ trễ trên tất cả các đường truyền là 5 ms
5.2.2.2 Các kịch bản mô phỏng Để phân tích ảnh hưởng c a MPLS trunk lên t c độ dữ ệủ ố li u, luận văn sử ụ d ng 4 kịch bản thử nghiệm Trong mỗi kịch bản, tố độc luồng UDP được thay đổi, sau đó thông lượng dữ liệu c a củ ả 3 luồng được đo đạc và phân tích
Kịch bản 1: không sử dụng MPLS
Trong kịch bản 1, mạng mô phỏng áp dụng mô hình định tuyến truyền thống thay vì MPLS, dẫn đến việc toàn bộ thông lượng dữ liệu được truyền qua đường kết nối R2-R3-R5 Do đó, đường R2-R4-R5 không được sử dụng.
Kết quả đo đạ được biểu diễn trong hình sau: c
Hình 5.3 Kịch b n sả ử ụ d ng phương pháp định tuyến thông thường
- Khi tốc độ luồng UDP tăng dần, thông lượng của 2 luồng TCP giảm dần
- Khi tốc độ luồng UDP đạt 45 Mbps, thông lượng 2 luồng TCP giảm dần về 0
- Thông lượng luồng TCP có kích thước gói tin lớn (TCP2) lớn hơn thông lượng luồng TCP có kích thước gói tin nhỏ (TCP1)
Từ đồ thị thông lượng, có thể nhận thấy rõ ràng rằng tốc độ luồng UDP tác động như thế nào đến hai luồng TCP Điều này xảy ra do cả ba luồng đều được định tuyến trên cùng một đường mạng.
Khi tốc độ luồng UDP tăng lên trong mạng R2-R3-R5, tốc độ của hai luồng TCP giảm xuống do cơ chế tự động điều chỉnh tốc độ truyền tin của TCP khi phát hiện tắc nghẽn Đồ thị cho thấy khi tốc độ luồng UDP đạt 45 Mbps, tốc độ của hai luồng TCP giảm về 0, dẫn đến toàn bộ băng thông của mạng R2-R3-R5 bị chiếm dụng hoàn toàn bởi UDP, không còn băng thông cho TCP Điều này cho thấy rằng thông lượng dữ liệu sẽ bị ảnh hưởng lớn bởi tắc nghẽn, do sự không đồng nhất giữa thông lượng dữ liệu và tắc nghẽn gây ra.
Kịch bản 2: sử dụng 2 trunk MPLS
Kịch bản 2 sử dụng 2 trunk MPLS để truyền dữ liệu như sau:
- Trunk thứ nhất dùng để truyền 2 luồng UDP và TCP1 trên LSP R1-R2-R3-R5-
R6 (đường truyền băng thông cao)
- Trunk thứ hai dùng để truyền luồng TCP2 trên LSP R 1 -R2-R4-R5-R6 (đường truyền băng thông thấp)
Trong kịch bản 2, tốc độ luồng UDP được thay đổi và ở đầu đầu cuối nhận tiến hành o đ đạc thông lượng cả 3 luồng dữ liệu
Kết quả đo đạ được biểu diễn trong hình sau: c
Hình 5.4 Kịch b n sử ụả d ng 2 trunk, trong đó 1 trunk có cả thông lượng TCP và
- Khi tốc độ luồng UDP tăng dần, thông lượng của luồng TCP1 giảm dần
Khi tốc độ luồng UDP đạt 45 Mbps, thông lượng của luồng TCP1 giảm dần về 0, trong khi thông lượng của TCP2 được cải thiện đáng kể và gần như ổn định Điều này xảy ra vì TCP2 được truyền qua đường truyền LSP không có dữ liệu UDP, do đó không bị ảnh hưởng bởi tắc nghẽn từ luồng UDP Ngược lại, TCP1, khi truyền trên cùng một trunk với luồng UDP, chịu tác động lớn từ sự biến động tốc độ của luồng UDP Khi tốc độ của luồng UDP tăng lên, tắc nghẽn xảy ra và TCP1 tự động giảm tốc độ truyền để thích ứng.
Việc chia thông lượng truyền trên các trunk MPLS khác nhau có thể cải thiện hiệu năng hệ thống, nhưng chưa đủ để đảm bảo chất lượng dịch vụ cho một số ứng dụng nhất định Để đảm bảo chất lượng dịch vụ cho một luồng nhất định, cần tách các luồng UDP và TCP, truyền trên các trunk khác nhau Điều này giúp khi một luồng UDP tăng tốc độ truyền tin, sẽ không ảnh hưởng đến các luồng TCP khác.
Kịch bản 3: sử dụng 3 trunk riêng biệt cho 3 luồng dữ liệu
Kịch bản 3 sử dụng 3 trunk riêng biệt cho 3 luồng dữ liệu như sau:
- Trunk thứ nhất dùng cho luồng dữ liệu UDP, truyền trên LSP R1-R2-R3-R5-R6
(đường truyền băng thông cao)
- Trunk thứ hai dùng cho luồng dữ liệu TCP1, truyền trên LSP R1-R2-R3-R5-R6
(đường truyền băng thông cao)
- Trunk thứ ba dùng cho luồng dữ liệu TCP2, truyền trên LSP R1-R2-R4-R5-R6
Để đảm bảo việc xử lý độc lập cho hai trunk trên LSP R1-R2-R3-R5-R6, các băng thông thấp được quản lý thông qua Hàng đợi dựa theo lớp (Class Based Queuing - CBQ) Phương pháp này giúp tách biệt dữ liệu của luồng UDP và luồng TCP, từ đó cung cấp băng thông hiệu quả cho các luồng dữ liệu.
Kết quả đo đạ được biểu diễn trong hình sau: c nh 5.5 Kịch b n sử ụả d ng các trunk khác nhau cho các luồng khác nhau
- Khi tốc độ luồng UDP tăng dần, thông lượng của luồng TCP1 không bị ả nh hưởng
Thông lượng của luồng TCP2 không bị ảnh hưởng bởi tốc độ của luồng UDP và gần như giữ hằng số Kết quả cho thấy tốc độ luồng UDP không tác động đến thông lượng của cả hai luồng TCP1 và TCP2, với thông lượng của chúng cũng gần như không đổi Điều này chứng tỏ rằng việc cách ly các luồng TCP và UDP có thể đảm bảo một mức chất lượng dịch vụ nhất định cho những nguồn dữ liệu nhạy cảm với tắc nghẽn Tuy nhiên, việc cách ly này yêu cầu sử dụng thêm một số hàng đợi mới trong bộ định tuyến cho các loại dữ liệu khác nhau, như đã trình bày trong chương 1 Mặc dù vậy, hiệu quả đạt được là rất đáng kể.
Kịch bản 4: không sử dụng trunk đầu cuối – đầu cuối
Kịch bản 4 không sử dụng trunk từ đấu cuối đế đần u cu i, mà chỉ thiết lập trunk từ bộ định tuyến Rế 2 Trong tình huống này, các luồng dữ liệu vẫn có sự ảnh hưởng lẫn nhau vì bộ định tuyến R1 không phân biệt được các loại dữ liệu khác nhau.
- Trunk thứ nhất dùng cho luồng dữ liệu UDP, truyền trên LSP R 2 -R 3 -R 5 -R 6 (đường truyền băng thông cao)
- Trunk thứ hai dùng cho luồng dữ liệu TCP1, truyền trên LSP R2-R3-R5-R6
(đường truyền băng thông cao)
- Trunk thứ ba dùng cho luồng dữ liệu TCP2, truyền trên LSP R2-R4-R5-R6
(đường truyền băng thông thấp)
Kết quả đo đạ được biểu diễn trong hình sau: c
Hình 5.6 Kịch bản không s d ng trunk đầu cu i – đầu cu i ử ụ ố ố
- Khi tốc độ luồng UDP tăng dần, thông lượng của 2 luồng TCP giảm dần
- Khi tốc độ luồng UDP tằng đến 45 Mbps, thông lượng luồng TCP1 giảm dần về 0
Mô hình đề xuất cho việc đảm bảo chất lượng dịch vụ trong mạng MPLS
Việc đánh giá chất lượng dịch vụ trong mạng MPLS phụ thuộc vào nhiều yếu tố, đặc biệt là loại dữ liệu mà hệ thống cung cấp Bài viết này tập trung vào việc đánh giá một số loại dữ liệu phổ biến trên mạng MPLS, từ đó phát triển mô hình đảm bảo chất lượng cho các dịch vụ này Mô hình sẽ áp dụng nhiều phương pháp và giao thức đặc trưng của MPLS để cải thiện hiệu suất và độ tin cậy của dịch vụ.
Để đảm bảo chất lượng dịch vụ cho các dịch vụ TCP, UDP và VoIP trong mạng MPSL, cần thực hiện các yêu cầu từ kết quả thử nghiệm với dữ liệu thông thường và dữ liệu tiếng nói VoIP.
Phân tách các luồng dữ liệu trên các trunk khác nhau là cần thiết để đảm bảo mỗi luồng được xử lý một cách hiệu quả trong miền MPLS Điều này giúp các luồng dữ liệu mang tính chất khác nhau không ảnh hưởng đến nhau, từ đó nâng cao hiệu suất và độ tin cậy của hệ thống mạng.
Việc thiết lập các trunk MPLS cần phải được thực hiện từ đầu cuối đến đầu cuối để đảm bảo hiệu quả cách ly luồng dữ liệu Nếu không thực hiện đúng cách, hiệu quả cách ly có thể bị giảm đáng kể hoặc thậm chí không còn tác dụng.
- Dữ liệu tiếng nói truyền trên miền MPLS nên sử dụng các lu ng EF cho vi c ồ ệ chuyển tiếp gói tin
Đối với dữ liệu nhạy cảm về thời gian, việc quản lý thông lượng các luồng dữ liệu đầu vào trong miền MPLS là rất quan trọng để đảm bảo khả năng áp ngưỡng của các đường kết nối Nếu không, chất lượng dịch vụ sẽ không được đảm bảo.
Với những nhận xét như vậy, lu n v n bước đầ đềậ ă u xu t mô hình đảm bảo chất ấ lượng dịch vụ cho mạng MPLS như hình sau:
Hình 5.12 Mô hình đề xuất đảm bảo chất lượng dịch vụ
Trong mô hình này, các luồng dữ liệu với đặc tính khác nhau được chuyển tiếp qua các MPLS trunk riêng biệt để đảm bảo chất lượng từng luồng mà không ảnh hưởng đến hiệu suất của các luồng khác Các luồng dữ liệu tiếng nói sẽ sử dụng các luồng EF của DiffServ, đồng thời cần đảm bảo yêu cầu về băng thông tại LSR vào của miền MPLS.
Kết luận và hướng phát triển đề tài
Trong 5 chương, luận văn đã trình bày được những vấn đề quan trọng nhất trong việc đảm bảo chất lượng dịch vụ cho các mạng IP nói chung và mạng MPLS nói riêng Các phương pháp kiểm soát chất lượng d ch v c b n trong mạng IP như ị ụ ơ ả kiểm soát hàng đợi, sắp xếp gói tin được trình bày trong chương 1 Chương 2 và 3 đề cập đến các mô hình đảm b o ch t lượng d ch vụả ấ ị truy n thốề ng nh IntServ và ư DiffServ Chương 4 đi vào tìm hi u ch t lượng d ch v trong m ng MPLS, m t công ể ấ ị ụ ạ ộ nghệ mới, phát triển rất mạnh mẽ trong vài năm trở ại đây và hứa hẹn rất nhiều tiềm l năng, đặc biệt khi áp dụng trong các hệ thống mạng của các nhà cung cấp dịch vụ vốn đã có yêu cầu rất cao về việc kiểm soát QoS Để có cái nhìn toàn diện, luận văn đi sâu vào ánh giá ch t lượng mộđ ấ t s dịố ch v trên m ng MPLS v i 2 lo i d li u ụ ạ ớ ạ ữ ệ tiêu biểu có nh ng yêu c u rữ ầ ất khác nhau về ch t lượng dịch vụ Các kếấ t qu mô ả ph ng ã ỏ đ đưa ra những gợi ý cho việc xây d ng mô hình và lựa chọn giải pháp cho ự việc đảm bảo chất lượng dịch vụ trong mạng chuyển mạch nhãn
Phạm vi trình bày của luận văn rất rộng, bao gồm nhiều vấn đề quan trọng trong các hệ thống mạng IP hiện tại Do thời gian và phạm vi hạn chế, không thể tránh khỏi những thiếu sót và một số vấn đề chưa được trình bày một cách đầy đủ Tuy nhiên, cách tiếp cận toàn diện này cho phép luận văn có cái nhìn tổng quát trên nhiều bình diện, với hy vọng rằng những kết quả đạt được sẽ là nền tảng vững chắc cho các nghiên cứu sau này.
Trong giai đ ạo n tiếp theo, đề tài sẽ phát triển theo hướng sau:
Tiếp tục triển khai thử nghiệm các hệ thống phức tạp gần với thực tế hơn trên mạng MPLS, nhằm đưa ra những đánh giá và nhận xét có cơ sở thực tiễn hơn.
Dựa trên các đánh giá và nhận xét, chúng tôi sẽ tiếp tục hoàn thiện mô hình dịch vụ, tập trung nghiên cứu và cung cấp các thông số cụ thể hơn nhằm đảm bảo chất lượng dịch vụ tối ưu.
- Đi sâu vào việc đảm bảo chất lượng dịch vụ cho các ứng dụng truyền thông đa phương ti n, đặc bi t là âm thanh và hình nh ệ ệ ả
Nghiên cứu chất lượng dịch vụ trong môi trường không đồng nhất là rất quan trọng, đặc biệt khi các hệ thống mạng có nhiều thành phần khác nhau Việc áp dụng các công nghệ đa dạng như công nghệ không dây, có dây và truyền thông vệ tinh giúp cải thiện hiệu suất và độ tin cậy của dịch vụ.