Kỹ Thuật Lưu Lượng Trong Mplsvpn doc

QoS (Quanlity of Service) là một khái niệm dùng để đề cập đến tất cả các khía cạnh liên quan đến hiệu quả hoạt động của mạng. QoS bao gồm hai thành phần chính: + Tìm đường qua mạng nhằm cung cấp cho dịch vụ được yêu cầu. + Duy trì hiệu lực hoạt động của dịch vụ. Hai mô hình cung cấp chất lượng dịch vụ được sử dụng phổ biến ngày nay là: + Mô hình dịch vụ tích hợp IntServ (Intergrated Services). + Mô hình dịch vụ phân biệt DiffServ (Differentiated Services). Có nhiều nguyên nhân giải thích tại sao mô hình IntServ không được sử dụng để theo kịp mức độ phát triển của Internet. Thay vào đó, IntServ chỉ được sử dụng phổ biến trong các mô hình mạng với quy mô nhỏ và trung bình. Trong khi đó, DiffServ lại là mô hình cung cấp chất lượng dịch vụ có khả năng mở rộng. Cơ chế hoạt động của mô hình này bao gồm quá trình phân loại lưu lượng và tại thành phần biên mạng, quá trình xếp hàng tại mỗi nút mạng và xử lý huỷ gói trong lõi mạng. Trong đó, phần lớn các quản lý xử lý được thực hiện tại thành phần biên mạng mà không cần phải lưu giữ trạng thái của các luồng lưu lượng trong lõi mạng. Khi cung cấp dịch vụ MPLS/VPN cho khách hàng, yêu cầu đặt ra là khả năng cung cấp chất lượng dịch vụ đáp ứng được một số lượng lớn các kháng hàng VPN với những yêu cầu đa dạng của họ. Ví dụ, một nhà cung cấp dịch vụ có thể cung cấp nhiều lớp chất lượng dịch vụ cho một VPN và những ứng dụng khác nhau trong VPN sẽ thuộc về những phân lớp dịch vụ khác nhau. Với cách thức này, dịch vụ mail sẽ thuộc về một lớp dịch vụ COS (Class of Service) nào đó trong khi những ứng dụng thời gian thực có thể thuộc về một lớp dịch vụ khác. Hơn nữa lớp dịch vụ COS của một ứng dụng thuộc về một VPN nào đó có thể khác với lớp dịch vụ của cùng ứng dụng đó nhưng lại thuộc về VPN khác. Có nghĩa là mỗi VPN độc lập trong việc ấn định lớp dịch vụ. Và tuỳ mạng, tuỳ nhà cung cấp dịch vụ mà ta lại xét chất lượng dịch vụ cho từng VPN khác nhau. Có nhà cung cấp dịch vụ chỉ cung cấp một giá trị EXP duy nhất cho tất cả VPN, có nhà cung cấp lại cung cấp độc lập cho từng VPN. Nhưng dù thế nào đi nữa đó cũng chỉ là cách sử dụng giá trị EXP trong mạng lõi, hoàn toàn độc lập với việc quy định về chất lượng dịch vụ của khách hàng. Do đó, trong phần này khi đi phân tích chất lượng dịch vụ cho khách hàng VPN, ta đi phân tích về QoS trong MPLS và các cơ chế liên quan, đồng thời đi phân tích kỹ thuật lưu lượng trong MPLS, sự kết hợp giữa QoS và TE trong mạng MPLS khi cung cấp chất lượng dịch vụ cho VPN khách hàng. 4.1. QoS trong MPLS 4.1.1. Differentiated Service (Diff-serv) Nhiệm vụ chính của Diff-serv là: + Phân loại lưu lượng tại biên mạng. + Điều chỉnh lưu lượng này tại biên mạng. Diff-serv là mô hình có sự phân biệt dịch vụ trong mạng do đó nhiều ứng dụng khác nhau, bao gồm cả lưu lượng thời gian thực có thể được đáp ứng mức dịch vụ của chúng trong khi vẫn có khả năng mở rộng các hoạt động trong mạng IP lớn. Khả năng mở rộng có thể đạt được bằng: + Chia nhỏ lưu lượng ra thành nhiều lớp khác nhau. + Anh xạ nhiều ứng dụng vào trong các lớp dịch vụ này trên biên mạng. Chức năng ánh xạ này đựơc gọi là phân loại (classification) và điều hoà (conditioning) lưu lượng. Việc phân loại có thể dựa trên nhiều cách thức như sửa dạng lưu lượng, đánh rớt gói tin, và cuối cùng là đánh dấu trường DS (Diff-serv ) trong mào đầu gói tin để chỉ thị lớp dịch vụ cho gói tin. + Cung cấp các xử lý cố định cho mỗi lớp dịch vụ tại mỗi hop (được gọi là Per-hop behavior - PHB) tương ứng với các yêu cầu QoS của nó). PHB bao gồm hàng đợi, phân lịch, và các cơ chế đánh rớt gói tin. 4.1.1.a. Trường DS của Diff-serv Trường DS là trường được quá trình điều hoà và phân loại lưu lượng sử dụng tại biên mạng để mã hoá giá trị DSCP. Giá trị này được các router Diff-serv sử dụng tại mỗi hop để lựa chọn PHB thích hợp cho mỗi gói tin. DSCP là giá trị 6 bit, được mang trong trường ToS của mào đầu gói tin. Với 6 bit có thể tạo ra đến 64 lớp dịch vụ. Tuy nhiên, trong thực tế chỉ có một số lớp dịch vụ được triển khai. Giá trị IP Precedence (đạt được từ 3 bit có trọng số lớn nhất trong trường ToS) có thể được ánh xạ đến trường DSCP, vừa vặn với các bit trong trường này. Tập hợp các gói tin có cùng giá trị DSCP, và di chuyển qua mạng theo cùng một hướng được gọi là tập hợp hành vi (Behavior Aggregate - BA). PHB sẽ thực hiện các chức năng của nó (hàng đợi, phân lịch, đánh rớt) cho bất kì gói tin nào thuộc về một BA. 4.1.1.b. Per-hop Behavior trong Diff - serv Có 4 PHB quan trọng trong khi triển khai Diff-serv là: Default PHB (PHB mặc định), Class – selector PHB (PHB lựa chọn theo lớp), Expedited Forwaring PHB (PHB chuyển tiếp ưu tiên nhất – EF PHB), Assured forwarding PHB (PHB chuyển tiếp được đảm bảo – AF PHB). + Default PHB: PHB mặc định Default PHB là PHB tương ứng với tiến trình chuyển tiếp gói tin best-effort, nó là mặc định trên tất cả các router. Nó chỉ đơn giản phân phối càng nhiều gói tin càng tốt. PHB này không có sự cam kết về chất lượng dịch vụ cho gói tin. Các gói tin được ánh xạ đến PHB này sẽ có giá trị DSCP là 0. + Class – selector PHB Trong một vài triển khai IP QoS, giá trị IP Precedence thường được sử dụng vì tính đơn giản và dễ sử dụng của nó. Do đó, để cho tương thích với các giá trị Precedence, các giá trị DSCP được định nghĩa dưới dạng xxx000 (trong đó x có thể là 0 hay 1). Các giá trị đó được gọi là class – selector codepoint. Giá trị mặc định là 0. PHB kết hợp với một class – selector codepoint được gọi là Class – selector PHB. Các PHB này sẽ có cùng kiểu chuyển tiếp như các node sử dụng giá trị IP Precedence. Ví dụ, các gói tin có giá trị DSCP là 101000 (IP Precedence là 101) sẽ có độ ưu tiên chuyển tiếp lớn hơn các gói tin có giá trị DSCP là 011000 (IP Precedence 011). + EF PHB: PHB chuyển phát nhanh EF PHB là PHB đáp ứng cho gói tin các dịch vụ có việc mất gói tin thấp (low - loss), độ trễ thấp (low - delay), độ jitter thấp (low - jitter). EF PHB đảm bảo rằng lưu lượng của nó được phục vụ ở tốc độ ít nhất là bằng với tốc độ dịch vụ cam kết. Các ứng dụng như VoIP, video, thương mại điện tử được sử dụng PHB này. Bất kì lưu lượng nào vượt qúa hợp đông lưu lượng sẽ bị huỷ bỏ. Giá trị DSCP cho EF là 101110. + AF PHB: PHB chuyển phát đảm bảo Đây là công cụ được sử dụng để đưa ra các mức dịch vụ đảm bảo chuyển tiếp cho gói tin của người dùng. Có tất cả 4 lớp AF. Trong mỗi lớp AF, một gói tin được đăng kí một trong 3 mức ưu tiên đánh rớt, tức là gói tin có 3 giá trị ưu tiên đánh rớt khác nhau trong cùng một lớp dịch vụ. Mỗi PHB sẽ tương đương với một lớp khác nhau và được gọi là AFij, trong đó i là lớp AF, và j là độ ưu tiên đánh rớt. Mỗi lớp AF được chỉ định với số lượng nguồn tài nguyên nhất định phụ thuộc vào hợp đồng mức dịch vụ SLA (Service Level Agreement) của khách hàng, gồm có băng thông và không gian bộ đệm. Việc chuyển tiếp được thực hiện độc lập dọc mỗi lớp AF. Vì có 4 lớp nên các lớp có thể là AF1y, AF2y, AF3y, AF4y. Trong mỗi lớp Afx, có đến 3 giá trị ưu tiên đánh rớt. Nếu có nghẽn xảy ra trong mạng Diff-serv trên một kết nối nào đó, các gói tin thuộc về lớp AF nào đó sẽ bị đánh rớt. Độ ưu tiên đánh rớt của các gói tin là như sau: dp(AFx1)<=dp(AFx2)<=dp(AFx3)<=dp(AFx4), trong đó dp(AFxy) là xác suất mà các gói tin của lớp Afxy bị đánh rớt. Ví dụ, AF23 sẽ bị đánh rớt trước AF22, AF22 sẽ bị đánh rớt trước AF21. Lớp AFx có thể được biểu diễn bằng giá trị DSCP xyzab0, trong đó xyz là 001, 010, 011, 100 và ab là bit ưu tiên đánh rớt. Bảng sau đây là giá trị của Ip Precedence và DSCP trong các PHB: Bảng 4.1: Bảng giá trị của IP Precedence và DSCP trong các PHB 4.1.1.c. Các cơ chế Diff-serv + Phân loại và điều hoà gói tin Hai chức năng này được thực hiện tại biên mạng giữa khách hàng và nhà cung cấp dịch vụ hoặc giữa hai mạng nhà cung cấp dịch vụ với nhau. Nó được áp đặt trên mỗi gói tin đi vào và dùng nhận diện lưu lượng với nhiều dịch vụ khác nhau (phân loại), sau đó áp đặt giá trị Diff-serv cho mỗi lưu lượng đó (điều hoà). Rõ ràng, chính sách phân loại và điều hoà lưu lượng đáp ứng yêu cầu của khách hàng các các lớp dịch vụ do nhà cung cấp đưa ra. + Việc phân loại có thể dựa trên trường DS, có thể dựa trên các giao thức được vận chuyển như SMTP, HTTP, hoặc là địa chỉ nguồn và đích. Phân loại lưu lượng được sử dụng để chuyển tiếp gói tin đến trạng thái điều hoà lưu lượng thích hợp. Bộ phân loại hoạt động ở hai chế độ: o Bộ phân loại tổng hợp hành vi (BA) phân loại các gói tin chỉ dựa trên giá trị DSCP. o Bộ phân loại đa trường (multifield) phân loại các gói tin bởi nhiều trường trong gói, như là địa chỉ, số cổng… + Điều hoà lưu lượng bao gồm nhiều thành phần sau : hoạt động đo (meter), hoạt động đánh dấu (marker), hoạt động sửa dạng (shaper), và hoạt động đánh rớt gói tin (dropper). o Hoạt động đo (meter): Sau khi gói tin được phân loại, meter sẽ đo tốc độ luồng lưu lượng. o Hoạt động đánh dấu thiết lập trường DS của mào đầu gói tin dựa vào kết quả có được từ bộ đo. o Hoạt động sửa dạng sẽ làm trễ vài gói tin trong luồng dữ liệu được phân loại, định hướng lưu lượng trước khi đi vào miền Diff-serv. o Hoạt động đánh rớt sẽ đánh rớt gói tin trong luồng dữ liệu đó (ví dụ các gói tin vượt quá profile được nhận diện trong bộ đo). Tiến trình này được gọi là policing. Các gói tin được đưa đến bộ điều hoà lưu lượng có thể là in-profile hoặc là out-of-profile. Các gói in-profile là các gói tuân thủ theo hợp đồng mức dịch vụ giữa khách hàng và nhà cung cấp. Các gói out-of-profile nằm bên ngoài hợp đồng SLA, hoặc do hành vi mạng mà các gói này đến bộ điều hoà, tại đây bộ điều hoà sẽ có những xử lý thích hợp. Sơ đồ của cơ chế phân loại và điều hoà đến lưu lượng: Hình 4.1: Sơ đồ cơ chế phân loại và điều hoà đến lưu lượng PHB không đưa ra các cơ chế thực thi cụ thể cho gói tin. Để miêu tả cho một PHB cụ thể, nhà quản trị mạng kích hoạt, điều chỉnh, và kết hợp các cơ chế phân lịch gói tin thích hợp cũng như kích hoạt các cơ chế quản lý hàng đợi (như Priority Queueing, Class-based Weight Fair Queue) hay các cơ chế quản lý nghẽn như (WRED, CAR )được các router Diff-serv hỗ trợ. 4.1.2. MPLS hỗ trợ DiffServ Với quan điểm của Diff-serv, mục tiêu của MPLS đơn giản là cho phép dịch vụ Diff-serv giống nhau được đưa ra bởi đầu cuối người dùng sẽ trong suốt qua mạng MPLS. Trong mạng IP, các router Diff-serv nhận diện PHB và áp đặt vào gói tin bằng cách nhìn vào trường DS trong mào đầu gói tin. Tuy nhiên, trong mạng MPLS, mào đầu gói tin được đóng gói sau mào đầu MPLS nên trường Diff-serv sẽ trong suốt đối với các router LSR. Do đó, PHB được áp đặt cho gói tin được đưa đến router nhờ vào phương tiện khác. Mỗi entry chồng nhãn trong mào đầu MPLS có 3 bit trong trường EXP. Cơ chế để các router LSR nhận ra PHB cho gói tin là ánh xạ giá trị DSCP của gói tin vào trường EXP MPLS của nhãn. Như vậy có hai trường hợp xảy ra khi Diff-serv đi qua MPLS: + DS LSR ánh xạ các giá trị DSCP vào PHB thích hợp. + DS LSR ánh xạ các giá trị trường EXP vào PHB thích hợp. Như mô tả trong hình vẽ sau : Hình 4.2: Anh xạ giá trị DSCP vào trường EXP của nhãn MPLS Có hai phương pháp để áp đặt PHB cho gói tin được định nghĩa trong MPLS: + Sử dụng E-LSP Bằng cách sử dụng 3 bit của trường EXP một LSP có thể có đến 8 PHB. Những LSP này được gọi là EXP-infered-PSC-LSP hay gọi tắt là E-LSP vì lớp phân lịch PHB (PSC) của gói tin được vận chuyển trong LSP này phụ thuộc vào giá trị trường EXP của gói tin. Với phương pháp này, router có thể sử dụng nhãn để thực hiện quyết định chuyển tiếp, và trường EXP có thể được sử dụng để xác định cách xử lý đối với gói tin như thế nào. Việc ánh xạ giữa các giá trị EXP và PHB phụ thuộc vào ánh xạ được cấu hình trước, nhưng ánh xạ này cũng có thể được báo hiệu tường minh khi thiết lập LSP. Còn việc router lựa chọn hàng đợi và độ ưu tiên phụ thuộc vào trường EXP. Ví dụ về sử dụng E – LSP để vận chuyển lưu lượng từ EF PHB và từ lớp AF1 được minh hoạ như sau: Hình 4.3: Sử dụng E-LSP để vận chuyển lưu lượng + Sử dụng L – LSP Mỗi LSP riêng biệt có thể được thiết lập cho mỗi PHB. Với những LSP như vậy, PSC được báo hiệu tường minh tại lần thiết lập nhãn, sau đó LSR có thể suy ra từ giá trị nhãn PSC được áp đặt cho gói tin. Trường EXP chỉ được sử dụng khi áp đặt giá trị ưu tiên đánh rớt cho gói tin. Phương pháp này được gọi là Label-only-infered-PSC LSP, hay còn gọi là L – LSP vì PSC có thể được suy ra từ giá trị nhãn mà không cần bất kì thông tin nào khác (bất chấp giá trị trường EXP ). Ví dụ về việc vận chuyển lưu lượng trên hai L – LSP riêng biệt từ EF PHB và lớp AF1 như sau: Hình 4.4: Sử dụng L-LSP để vận chuyển lưu lượng Hình vẽ 4.5 biết quá trình hoạt động Diff-serv qua mạng MPLS: Đầu tiên, router biên nhận diện PHB để áp đặt vào gói tin IP đi vào, sau đó chọn lựa LSP ngõ ra dựa trên đích của gói tin, và có thể là trên PHB. Cuối cùng, router này thiết lập giá trị trường EXP để chỉ thị PHB được áp đặt. Khi router biên nhận diện PHB áp đặt cho gói tin đi vào, nó phụ thuộc vào trạng thái phân loại lưu lượng giống như Diff-serv cho IP. Do đó, PHB có thể chỉ đơn giản được lấy từ trường DS trong mào đầu gói tin IP nhận, hoặc có thể dựa trên bất kì trường nào khác trong mào đầu IP. Diff-serv qua MPLS có thể sử dụng các giao thức báo hiệu MPLS như LDP, TE để thiết lập, duy trì, và loại bỏ E – LSP, L – LSP. Tuy nhiên, E – LSP phụ thuộc vào ánh xạ được định nghĩa trước giữa giá trị EXP và PHB, nên không cần thiết phải sử dụng các giao thức báo hiệu này. Ngày nay khi triển khai Diff-serv qua MPLS sử dụng E – LSP vì triển khai nó đơn giản trong mạng lõi, và vì nó không quá trình báo hiệu LSP nào được yêu cầu khi triển khải Diff-serv. Nó chỉ cần cấu hình trước các PHB trên router, do đó có thể phân loại gói tin dựa trên giá trị EXP trong mào đầu MPLS để áp đặt PHB cần thiết. Còn L – LSP có thể được sử dụng trong tương lai, khi mà mạng lõi yêu cầu cần có hơn 8 PHB trong mạng. Để hỗ trợ hoạt động trên, MPLS sử dụng các mode đường hầm QoS. Các mode này định nghĩa quản lý PHB MPLS và IP thông qua việc ánh xạ giữa giá trị IP DSCP và MPLS EXP. Đường hầm cho MPLS Diff-serv bao gồm ba mode chính. Khách hàng có thể chọn bất kì mode nào để vận chuyển lưu lượng của mình. Điều đó tuỳ thuộc vào thoả thuận giữa họ với nhà cung cấp dịch vụ. Đi qua đường hầm là khả năng của QoS được trong suốt từ một biên mạng này đến biên mạng khác của mạng. Một đường hầm bắt đầu từ nơi nhãn được chèn vào gói tin (push), và kết thúc tại nơi nhãn bị lấy ra khỏi gói tin (pop). Có 3 phương thức để chuyển gói tin qua mạng qua đường hầm đó là: + Pipe mode + Short pipe mode + Uniform mode Cả 3 mode trên chỉ ảnh hưởng đến router biên LSR, tức là tại nơi nhãn được đặt vào gói tin hoặc là nơi nhãn bị loại bỏ ra khỏi gói tin. Chúng không ảnh hưởng gì đến quá trình chuyển đổi nhãn tại các router trung gian. Nhà cung cấp dịch vụ có thể quan tâm hoặc không quan tâm đến gói tin của khách hàng. Ví dụ, nếu mạng của khách hàng C1, có giá trị IP Precedence là 5 quy định cho voice. Trong mạng của khách hàng C2, giá trị IP Precedence là 3 quy định cho voice. Nhà cung cấp dịch vụ không muốn hai giá trị này cho voice. Họ sẽ lựa chọn các giá trị từ 3 bit EXP. Chẳng hạn, nhà cung cấp sẽ chọn giá trị cho voice là 2. Quan sát gói tin của khách hàng, nhìn vào giá trị IP Precedence/DSCP. Sau đó thiết lập mỗi gói tin thoại của khách hàng có giá trị là 2 trong trường MPLS EXP. Giá trị này sẽ được kiểm tra trong mạng lõi MPLS. Một giải pháp khác có thể là thiết lập giá trị DSCP về 2, nhưng điều này sẽ phải thay đổi PHB của khách hàng. Mô hình đường hầm MPLS DiffServ đạt được kết quả như trên mà không cần thay đổi giá trị DSCP. 4.1.2.a. Mô hình Pipe Trong mô hình Pipe nhà cung cấp dịch vụ cung cấp cho khách hàng VPN sự cam kết về chất lượng dịch vụ đối với lưu lượng đi giữa router CE này đến router CE khác trong cùng VPN. Và các node trung gian trong mạng backbone (router P) hoàn toàn bị che dấu đi. Các gói tin đi qua đường hầm phải vận chuyển hai mảng thông tin Diff-serv: + Thông tin Diff-serv có ý nghĩa với các node trung gian dọc LSP. Thông tin này còn được gọi là thông tin Diff-serv LSP. + Thông tin Diff-serv được router ingress vận chuyển đến router egress. Các router P không hề biết đến thông tin này, nên nó còn đựơc gọi là thông tin Diff-serv đi qua hầm (tunneled Diff-serv information). Mô hình Pipe sử dụng thích hợp khi khách hàng và nhà cung cấp dịch vụ thuộc về những miền Diff-serv khác nhau (miền Diff-serv của nhà cung cấp dịch vụ bắt đầu ở interface ngõ vào trên router igress PE và kết thúc ở interface ngõ ra trên router PE egress), khi nhà cung cấp dịch vụ muốn áp đặt chính sách của họ và khách hàng có yêu cầu rằng các chính sách QoS của khách hàng hoàn toàn trong suốt khi đi qua mạng của nhà cung cấp. Ví dụ như nhà cung cấp cung cấp dịch vụ VPN có cả Diff-serv. Giả sử tập hợp các site được quản lý dưới chính sách quản trị chung và cũng đang được hỗ trợ về dịch vụ Diff- serv. Nếu quản trị site VPN nhà cung cấp dịch vụ không có cùng chung chính sách Diff- serv (chẳng hạn không hỗ trợ cùng số lượng PHB), thì hoạt động của Diff-serv trong mô hình Pipe sẽ cho phép chính sách Diff-serv của các site VPN hàng toàn trong suốt khi qua mạng nhà cung cấp và không đổi từ router ingress đến router egress. Mô hình hoạt động của nó như sau: Hình 4.6: Mô hình hoạt động Pipe mode Trong đó: (M) là thông tin Diff-serv LSP. (m) là thông tin Diff-serv đi qua hầm. (*) LSP egress kiểm tra thông tin Diff-serv LSP nhận được ở mào đầu ngoài cùng (tức là trước khi có hoạt động pop xảy ra) để áp dụng các chính sách chuyển tiếp Diff-serv (tức là vận chuyển gói tin đến đích theo đúng PHB). I : LSP ingress node. E : LSP egress node. Với mô hình Pipe, thông tin Diff-serv LSP cần phải được vận chuyển đến router Egress để nó có thể áp đặt chính sách chuyển tiếp trên đó. Thông tin Diff-serv đi qua hầm cũng cần phải được vận chuyển đến router egress để nó có thể được chuyển đến downstream xa hơn. Vì cả hai thông tin Diff-serv trên đều cần được chuyển đến router egress nên mô hình Pipe không hoạt động với PHP. Để hỗ trợ mô hình Pipe qua LSP không có hoạt động PHP, LSR thực hiện quyết định PHB ngõ vào và mã hoá thông tin Diff-serv theo các bước sau: + Khi nhận được gói tin không có gán nhãn, LSR thực hiện quyết định PHB ngõ vào dựa trên mào đầu gói tin IP mà nó nhận được. + Khi nhận được gói tin có gán nhãn, LSR thực hiện quyết định PHB ngõ vào trên nhãn ngoài cùng trong chồng nhãn. Đặc biệt khi hoạt động pop được thực hiện trên LSP, LSR thực hiện quyết định PHB ngõ vào trước khi loại bỏ nhãn ra khỏi gói tin (trước khi pop). + Khi thực hiện chèn nhãn (push), LSR: o Mã hoá thông tin Diff-serv tương ứng với PHB ngõ ra trên entry nhãn được truyền đi. o Mã hoá thông tin Diff-serv tương ứng với PHB ngõ vào trong mào đầu gói tin được đóng gói (có thể đó là nhãn được chuyển đổi hoặc là mào đầu IP). + Khi chỉ thực hiện quá trình chuyển đổi nhãn, LSR mã hoá thông tin Diff-serv trên entry nhãn được truyền đi bao gồm có nhãn được chuyển đổi. + Khi thực hiện hoạt động pop, LSR không thực hiện mã hoá thông tin Diff-serv trong mào đầu gói tin. Vì các chính sách QoS egress PE-to-CE trong mô hình Pipe độc lập với giá trị MPLS EXP cuối cùng, nên giá trị này phải được bảo vệ trước khi nhãn cuối cùng bị lấy ra khỏi gói tin. Trên router PE cuối cùng trên đường đi, giá trị MPLS EXP được copy vào giá trị QoS group (là các giá trị DSCP/IP precedence). Sau đó, hàng đợi ngõ ra hoặc các chính sách đánh rớt gói tin được thực hiện dựa trên giá trị của QoS group. + Mô hình Pipe với Explicit Null LSP: Khi router CE được nhà cung cấp quản lý, một vài nhà cung cấp không muốn đánh dấu MPLS EXP lưu lượng khách hàng từ router PE, và đặt các chính sách này bên ngoài interface ngõ vào của router CE (tức là quản lý router CE). Tuy nhiên, vì kết nối CE-to- PE là IP chứ không phải là MPLS, do đó khó khăn là làm cách nào nhà cung cấp thiết lập việc đánh dấu QoS mà không ảnh hưởng đến đánh dấu IP Diff-serv khách hàng đã thiết lập. Explicit Null LSP là giải pháp được đưa ra để giải quyết trường hợp trên. Explicit Null LSP có các đặc điểm sau: + Đường hầm QoS đi từ router CE ingress qua router PE và đến router CE egress. + Có một explicit NULL LSP được thiết lập từ router CE đến router PE. Entry nhãn bao gồm một trường MPLS EXP, nhưng không mang giá trị nhãn cho mục đích chuyển tiếp. Giá trị nhãn là 0 (nhãn mang giá trị null) cho tất cả các gói tin đến router PE ingress. Nhãn này được sử dụng chỉ để bảo vệ việc đánh dấu trường MPLS EXP của nhà cung cấp qua kết nối CE-to-PE. Trên router PE, giá trị MPLS EXP được copy vào nhãn MPLS thông thường (những nhãn dành cho mục đích chuyển tiếp) và nhãn explicit null bị loại bỏ đi. + Router PE egress loại bỏ entry nhãn và chuyển tiếp gói tin là IP, nhưng QoS được thực hiện trên interface ngõ ra dựa trên trường MPLS EXP mà router PE egress đã nhận được. + Nhà cung cấp dịch vụ không viết chồng lên giá trị IP Precedence trong mạng nhà cung cấp dịch vụ. Hình vẽ sau mô tả tổng quan mô hình Pipe với explicit NULL LSP: Hình 4.7: Mô hình Pipe với explicit Null LSP Trong hình vẽ trên: 1. Gói tin IP đến ở C1, router CE1 với giá trị DSCP là 1. 2. C2, CE1 thiết lập trường MPLS EXP với giá trị là 5 trong quá trình chèn nhãn Null. 3. Gói tin đi qua mạng nhà cung cấp dịch vụ với giá trị trường MPLS EXP là 5. 4. Mỗi router trong mạng nhà cung cấp dịch vụ nhìn trường MPLS EXP và thực hiện QoS dựa trên giá trị đó. 5. Khi gói tin đi đến router PE egress để đến mạng C1, nó thực hiện quyết định QoS dựa trên trường MPLS EXP của gói tin, mặc dù gói tin được truyền đi như là gói tin IP. Thủ tục hoạt động của MPLS EXP như sau: Hình 4.8: Thủ tục hoạt động của MPLS EXP trong Pipe mode Hình vẽ trên mô tả hoạt động mô hình Pipe với explicit Null LSP cho khách hàng C1 sử dụng dịch vụ MPLS VPN. Vì sử dụng dịch vụ MPLS VPN nên có hai entry nhãn MPLS trong chồng nhãn. Hoạt động như sau (các con số trong vòng tròn là từng bước hoạt động của nó mà ta sẽ nhắc dưới đây): 1. Gói tin IP đến ở router CE1, router CE được nhà cung cấp quản lý, có giá trị DSCP là 1. 2. Entry nhãn explicit NULL được chèn vào gói tin có giá trị trường EXP là 5. 3. Gói tin được truyền đến PE1 trên explicit NULL LSP. 4. Router PE1 lưu giá trị của trường EXP và loại bỏ entry explicit Null. Router PE1 chèn nhãn mới vào gói tin IP. Mỗi entry nhãn được thiết lập có giá trị trường MPLS EXP là 5. 5. Gói tin được truyền đến P1. 6. Tại P1 giá trị EXP nhận được được copy vào entry nhãn mới (vừa được chuyển đổi). 7. Gói tin được truyền đến P2. 8. Tại P2, nhãn ở trên đỉnh được lấy ra. 9. Gói tin được truyền đến PE2. 10. PE2 lưu giá trị trường MPLS EXP trong QoS group và discard-class, và loại bỏ entry nhãn ra khỏi gói tin. 11. Trong khi truyền gói tin đến CE2, PE2 thực hiện QoS trên interface ngõ ra của nó dựa trên giá trị MPLS EXP được lưu trước đó (qos-group và discard class). 12. Gói tin đến CE2. 4.1.2.b. Mô hình Short Pipe Mô hình Short Pipe cũng tương tự như mô hình Pipe, chỉ khác ở chỗ là trong mô hình Short Pipe, bất kì sự thay đổi nào trong việc đánh dấu nhãn xảy ra trong mạng nhà cung cấp dịch vụ không được truyền đến byte IP ToS khi gói tin đi ra khỏi mạng MPLS. Hoạt động của Short Pipe không có PHP như sau: Hình 4.9: Hoạt động của Short Pipe không có PHP Trong đó: (M) : thông tin Diff-serv LSP (m) : thông tin Diff-serv tunneled I : node ingress E : node egress Vì router PE egress áp đặt chính sách chuyển tiếp dựa trên thông tin Diff-serv tunneled, thông tin Diff-serv LSP không cần được truyền bởi node thực hiện PHP đến router PE egress. Do đó, mô hình Short Pipe có thể hoạt động với PHP. Được miêu tả như sau: Hình 4.10: Hoạt động của Short Pipe có PHP Trong đó: (M) : thông tin Diff-serv LSP (m) : thông tin Diff-serv tunneled (*) : LRR thực hiện PHP dựa trên thông tin Diff-serv LSP có được trong mào đầu ngoài cùng (trước khi pop) để áp đặt phương thức chuyển tiếp Diff-serv của nó (tức là áp đặt PHB cho gói tin) I : node LSR ingress E : node LSR egress P : node thực hiện PHP Mô hình Short Pipe sử dụng thích hợp khi nhà cung cấp dịch vụ VPN và khách hàng VPN yêu cầu chính sách Diff-serv VPN của họ được áp đặt trên kết nối từ egress PE đến site VPN đích hơn là chính sách QoS của nhà cung cấp dịch vụ trên đó. Để hỗ trợ mô hình Short Pipe qua đường chuyển mạch nhãn LSP đã xây dựng không có PHP, LSR thực hiện quyết định PHB ngõ vào và mã hoá thông tin Diff-serv giống như trong mô hình Pipe. Ngoại trừ là khi nhận gói tin có gán nhãn, LSR quan tâm đến mào đầu (entry nhãn hoặc mào đầu IP) được sử dụng để dùng cho việc chuyển tiếp. Đặc biệt, khi hoạt động rút nhãn xảy ra thì LSR thực hiện quyết định PHB ngõ vào sau khi rút nhãn. Để hỗ trợ mô hình Short Pipe qua một LSP có PHP, LSR thực hiện quyết định PHB ngõ vào và mã hoá thông tin Diff-serv như trường hợp trên (trường hợp không có PHP), ngoại [...]... tĩnh hoặc cơ chế định tuyến ràng buộc dựa trên thuật toán tìm đường ngắn nhất để định tuyến lưu lượng trong đường hầm 4.3 Mô hình DS – TE Kỹ thuật lưu lượng MPLS cho phép định tuyến ràng buộc lưu lượng IP Một trong những ràng buộc đó là đáp ứng băng thông được yêu cầu qua những đường đi chọn trước Mô hình DS – TE là mô hình kết hợp giữa kỹ thuật lưu lượng trong MPLS với dịch vụ phân biệt (DiffServ) cho... bảo rằng lưu lượng được định tuyến qua mạng, trên mỗi kết nối, không bao giờ vượt quá 35% (hoặc bất kì phần trăm nào khác) của dung lượng kết nối đối với lưu lượng được « đảm bảo » (ví dụ thoại chẳng hạn), trong khi có thể tăng đến 100% dung lượng kết nối cho lưu lượng thông thường Giả sử các cơ chế QoS cũng được sử dụng trên mỗi kết nối để xắp xếp lưu lượng được ‘đảm bảo’ đó ra hàng đợi từ lưu lượng. .. tập hợp lưu lượng rời rạc (ví dụ như lưu lựơng thoại và lưu lượng dữ liệu) Ví dụ, nhà cung cấp dịch vụ có thể bán hai dịch vụ thoại cho hai khách hàng, cả hai đều yêu cầu chặt chẽ độ ưu tiên dịch vụ Tuy nhiên, nếu nghẽn xảy ra trên một node tại điểm không đủ băng thông cho lưu lượng thoại cả hai khách hàng, MPLS DS-TE có thể báo hiệu trình trạng này trở về cho router đầu đường hầm, lúc đó lưu lượng thoại... thông báo cho biết Router đích trong đường hầm chuyển mạch nhãn sẽ trả lời lại LABEL_REQUEST bằng object LABEL có trong bản tin Resv của nó Mỗi node nhận bản tin Resv có object LABEL sẽ sử dụng nhãn đó cho việc vận chuyển lưu lượng ngõ ra trong đường hầm LSP này Nếu router đó không phải là router đầu đường hầm, nó sẽ chỉ định nhãn mới và đặt vào object LABEL tương ứng trong bản tin Resv mà nó sẽ gửi... tài nguyên được yêu cầu như băng thông hay độ trễ) Các thủ tục quản lý lưu lượng (như điều khiển cho phép kết nối (connection admission control - CAC) và phân lịch lưu lượng) sử dụng TSPEC và RSPEC trên các node dọc đường đi để cung cấp các yêu cầu về chất lượng dịch vụ (QoS) Object FILTER_SPEC được sử dụng để thiết lập các tham số trong việc phân loại gói tin tại một node + Reservation State Block:... DS-TE đảm bảo được các vấn đề kỹ thuật lưu lượng, thích hợp cho các ứng dụng thời gian thực như thoại hay hội nghị truyền hình Khi thực hiện chất lượng dịch vụ cho khách hàng VPN Nhà quản trị có thể lựa chọn các phương pháp đường hầm DiffServ để thực hiện quá trình ánh xạ giữa giá trị DSCP và giá trị MPLS EXP Bên cạnh đó, nếu nhà cung cấp muốn sự đảm bảo hoạt động chất lượng dịch vụ tốt hơn thì có thể... tốt hơn thì có thể dùng mô hình DS-TE Nói tóm lại, việc cung cấp chất lượng cho khách hàng VPN đó chính là việc xây dựng một cơ chế đảm bảo chất lượng dịch vụ trong mạng lõi MPLS Còn chính sách về QoS của khách hàng hoàn toàn trong suốt đối với mạng nhà cung cấp Và trong mạng lõi đó, nhà cung cấp sẽ xây dựng các cơ chế để bảo đảm chất lượng dịch vụ như ta đã phân tích trên đây Sử dụng cơ chế nào, sử dụng... đi đến tất cả cá router trong đường hầm theo hướng downstream Nó chỉ cần gửi cho router downstream láng giềng, router đó sẽ gửi lại bản tin ResvTear Sau đó router downstream này sẽ gửi bản tin PathTear đến router downstream khác kế cận nó… 4.2.3 Chuyển tiếp lưu lượng xuống đường hầm Sau khi thiết lập LSP TE thành công, bước tiếp theo là xây dựng cách thức để chuyển tiếp lưu lượng xuống đường hầm Có... những lớp dịch vụ này có thể được đảm bảo Giống như TE, DS – TE nằm trong mặt phẳng điều khiển DS – TE phụ thuộc vào MPLS DiffServ trong đường đi của dữ liệu (hoặc là E-LSP, hoặc là L-LSP) Mục đích cơ bản của DS-TE là khả năng áp đặt các ràng buộc băng thông khác nhau cho các loại lưu lượng khác nhau Băng thông đó được gọi là subpool, trong khi băng thông đường hầm TE thông thường được gọi là global... đích đó được lưu trong object RSVP_HOP của PSB tương ứng Với cách này đảm bảo được bản tin Resv được vận chuyển dọc route mà bản tin Path đã sử dụng theo hướng downstream Bản tin Resv mang object SESSION, object RSVP_HOP, các object mô tả luồng (flow descriptor), và một số object khác Object mô tả luồng bao gồm các object FLOWSPEC và FILTER_SPEC Object FLOWSPEC mang TSPEC (các tham số lưu lượng) và RSPEC . buộc dựa trên thuật toán tìm đường ngắn nhất để định tuyến lưu lượng trong đường hầm. 4.3. Mô hình DS – TE Kỹ thuật lưu lượng MPLS cho phép định tuyến ràng buộc lưu lượng IP. Một trong những. đi phân tích về QoS trong MPLS và các cơ chế liên quan, đồng thời đi phân tích kỹ thuật lưu lượng trong MPLS, sự kết hợp giữa QoS và TE trong mạng MPLS khi cung cấp chất lượng dịch vụ cho VPN. hình DS – TE là mô hình kết hợp giữa kỹ thuật lưu lượng trong MPLS với dịch vụ phân biệt (DiffServ) cho phép ta có thể thực hiện ràng buộc định tuyến với lưu lượng mà ta đã đảm bảo. Điều này có