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
trừ router LSR có tiến trình PHP trên đó sẽ thực hiện quyết định PHB ngõ vào dựa trên
entry nhãn ngoài cùng trong chồng nhãn nhận được. Nói cách khác, khi có hoạt động rút
nhãn, router LSR có tiến trình PHP sẽ thực hiện quyết định PHB ngõ vào trước khi rút
nhãn.
Hay nói tóm lại, mô hình Short Pipe có các đặc điểm sau:
+ Đường hầm QoS đi từ router PE ingress đến router PE egress.
+ Router PE egress truyền gói tin là IP và QoS được thực hiện trên interface ngõ ra dựa
trên giá trị IP DSCP hoặc IP Precedence.
+ Nhà cung cấp dịch vụ không viết chồng lên giá trị DSCP hoặc IP Precedence trong
mạng nhà cung cấp dịch vụ.
Thủ tục hoạt động của mô hình Short Pipe như sau:
Hình 4.11: Thủ tục hoạt động của mô hình Short Pipe
1. C1, CE1 truyền gói tin IP đến PE1 với giá trị DSCP là 1.
2. PE2 thiết lập trường MPLS EXP với giá trị là 5 trong các entry nhãn được chèn vào.
Giá trị IP DSCP không được copy vào trường EXP mà giá trị cho trường MPLS EXP
được thiết lập tường minh trên interface ngõ vào của router PE ingress tuỳ theo chính
sách của nhà cung cấp dịch vụ.
3. PE1 truyền gói tin đến P1.
4. P1 thiết lập trường MPLS EXP với giá trị là 5 trong entry nhãn mới (nhãn sau khi được
chuyển đổi).
5. P1 truyền gói tin đến P2.
6. P2 lấy entry nhãn IGP ra khỏi gói tin.
7. P2 truyền gói tin đến PE2.
8. PE2 lấy nhãn BGP ra khỏi gói tin.
9. PE2 truyền gói tin đến site C1, nhưng thực hiện QoS dựa trên giá trị DSCP hoặc IP
Precedence.
4.2.2.b. Thiết lập đường đi chuyển mạch nhãn

Sau khi đường hầm chuyển mạch nhãn LSP TE được tính toán. Bước tiếp theo là thiết lập
nó. Việc thiết lập này được thực hiện bằng cách sử dụng giao thức báo hiệu RSVP TE.
RSVP TE không những đóng vai trò trong việc thiết lập, duy trì đường đi, mà còn đóng
vai trò trong việc báo lỗi và loại bỏ đường đi.
RSVP-TE sử dụng các bản tin RSVP để thiết lập, duy trì (refresh), báo hiệu lỗi và loại bỏ
đường hầm chuyển mạch nhãn. Các bản tin này là Path, Resv, Path error, và Resv Error.
Mỗi bản tin bao gồm các object. Các object này có quan hệ với các attribute LSP TE như
đường đi được tính toán (còn được gọi là ERO), băng thông, preemption, các yêu cầu
định tuyến lại một cách nhanh chóng, và giá trị affinity.
RSVP TE định nghĩa một “phiên” là một dòng dữ liệu (bao gồm có địa chỉ đích và giao
thức lớp vận chuyển). Tuy nhiên, khi RSVP và MPLS kết hợp với nhau, phiên hay dòng
dữ liệu đó có thể được định nghĩa một cách linh hoạt hơn. Node ingress của một LSP có
thể sử dụng nhiều cách để xác định gói tin nào được đăng kí một nhãn. Khi nhãn được
đăng kí cho gói tin, nhãn sẽ định nghĩa “dòng” đi qua LSP. LSP đó được gọi là đường
hầm LSP vì lưu lượng đi qua nó trong suốt đối với các node trung gian dọc đường đi
chuyển mạch nhãn.
LSP_TUNNEL_IPV4 (LSP_TUNNEL_Ipv6) bao gồm các object RSVP SESSION,
SENDER_TEMPLATE và FILTER_SPEC được sử dụng để hỗ trợ đặc điểm của đường
hầm chuyển mạch nhãn. Hai giá trị được sử dụng để nhận diện và liên kết các đường hầm
như vậy bao gồm: tunnel_ID là một phần của object SESSION. Object SESSION nhận
diện đường hầm TE được cho là duy nhất. Các object SENDER_TEMPLATE và
FILTER_SPEC mang LSP ID. Và 3 object trên kết hợp với nhau tạo cho đường hầm LSP
mang tính duy nhất.
Sau khi router đầu đường hầm (tunnel headend) đã hoàn tất việc tính toán đường đi cho
đường hầm của nó, nó gửi yêu cầu thiết lập đường hầm đến mạng bằng cách tạo bản tin
Path với phiên làm việc loại LSP_TUNNEL_Ipv4 hoặc LSP_TUNNEL_Ipv6 gửi đến
router kế tiếp dọc theo đường đi đã được tính toán cho đường hầm đó đến đích. Router
gửi bản tin Path được gọi là router upstream, router nhận bản tin gọi là router
downstream.
Format của bản tin Path như sau:

Hình 4.15: Format của bản tin Path
Bao gồm các object sau:
+ Object SESSION: định nghĩa phiên RSVP.
+ Object RSVP_HOP: bao gồm địa chỉ IP của router upstream gửi bản tin này và địa chỉ
interface ngõ ra.
+ Object SENDER_TEMPLATE: bao gồm địa chỉ IP nguồn và port TCP/UDP
+ Object SENDER_TSPEC: các tham số lưu lượng như băng thông được yêu cầu dữ
trự…
+ Object TIME_VALUES: bao gồm giá trị của bộ định thời refresh R được sử dụng bởi
phía gửi bản tin.
+ Path State Block: Khối trạng thái đường đi
Khi một router RSVP downstream nhận bản tin Path, tiến hành kiểm tra format của bản
tin để chắc chắn rằng mọi thứ đều tốt. Sau đó kiểm tra lượng băng thông mà bản tin Path
yêu cầu (dựa vào thông tin có được trong object SENDER_TSPEC). Tiến trình này được
gọi là điều khiển cho phép (admission control).
Nếu tiến trình điều khiển cho phép thành công và bản tin Path được phép dành trước băng
thông, router tạo ra bản tin Path mới hay tạo ra khối trạng thái đường dẫn (path state
block - PSB) cho một phiên làm việc mà nó tham gia vào. Mỗi PSB bao gồm các tham số
nhận được từ bản tin Path như các object SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, RSVP_HOP, và interface ngõ ra được cung cấp bởi định tuyến IGP.
Khi router chuyển tiếp bản tin Path, router thêm vào địa chỉ IP của interface ngõ ra trong
object RSVP_HOP và chuyển đến router downstream kế tiếp. Khi router downstream kế
tiếp nhận bản tin Path, nó cũng tạo ra PSB, thêm vào địa chỉ IP của interface ngõ ra trong
object RSVP_HOP, và lại chuyển bản tin này đến router downstream. Tiến trình này lặp
lại cho đến khi nào bản tin Path đến đích, tức là đến router cuối đường hầm. Trong suốt
tiến trình xử lý bản tin Path, nếu có bất kì lỗi nào xảy ra tại một node dọc đường đi, từ
node đó bản tin Path Error (PathErr) sẽ được gửi trả lại phía router gửi.
Router cuối đường hầm thực hiện tiến trình điều khiển cho phép trên bản tin Path, giống
như các router downstream khác đã làm. Khi router nhận ra rằng nó chính là đích của bản
tin Path sẽ trả lời lại bằng bản tin Resv. Bản tin Resv giống như ACK gửi lại cho router

upstream.
Format của bản tin Resv như sau:
Hình 4.16: Format của bản tin Resv
Địa chỉ IP nguồn của bản tin Resv là địa chỉ của node khởi tạo bản tin. Nói cách khác, địa
chỉ IP đích là địa chỉ của router upstream, là router mà nó đã nhận được bản tin Path
trước đó. Trước khi chuyển tiếp bản tin Resv đến upstream, mỗi node kiểm tra địa chỉ IP
đích của bản tin Resv nhận được. Địa chỉ IP đí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 (nguồn 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: Khối trạng thái dành trước băng thông
Khi bản tin Resv đi theo hướng upstream đến đầu đường hầm, nó tạo ra khối trạng thái
dành trước băng thông (Reservation State Block - RSB) trong mỗi node dọc đường đi.
Mỗi RSB lưu htông tin có được từ các object trong bản tin Resv, như:
+ Object SESSION
+ Object RSVP_HOP
+ Object FLOWSPEC
+ Object FILTERSPEC
+ Object STYLE (chỉ ra cách dành trước băng thông, ví dụ như việc dành trước băng
thông có thể được chỉ định cho mỗi phía gửi, hoặc là chia sẽ bởi nhiều phía gửi)
Trong suốt tiến trình xử lý bản tin Resv, nếu có bất kì lỗi nào xảy ra trên đường đi, bản
tin lỗi ResvErr sẽ được phát ra và được gửi theo hướng downstream đến phía thu.
Bản tin Resv không những chỉ có ACK cho việc dành trước băng thông mà còn có cả

nhãn ngõ vào mà router upstream sử dụng để gửi gói tin đi xuống LSP TE đến đích. Vậy
quá trình phân phối nhãn theo yêu cầu downstream (downstream-on-demand) này sẽ
được thực hiện như thế nào ?
Khi router upstream gửi bản tin Path sẽ thêm object LABEL_REQUEST để chỉ thị rằng
nó yêu cầu ánh xạ nhãn cho đường đi này và đồng thời cung cấp thông tin giao thức lớp
mạng được mang qua đường đi đó. Lý do là vì giao thức lớp mạng gửi xuống đường hầm
không phải là IP, cũng như không phải là giao thức lớp 2, nó định nghĩa giao thức lớp cao
hơn như MPLS chẳng hạn.
Nếu router gửi nhận biết rằng route để đi đến đích đáp ứng được các yêu cầu QoS của
đường hầm, sử dụng nguồn tài nguyên hiệu quả, router sẽ quyết định sử dụng route. Để
làm điều này, nó thêm object EXPLICIT_ROUTE vào bản tin Path. Sau khi phiên đã
được thiết lập thành công, router gửi nhận biết rằng đã tìm thấy một route khác tốt hơn,
nó tự động định tuyến lại phiên làm việc bằng cách đơn giản là thay đổi object
EXPLICIT_ROUTE. Bằng việc thêm object RECORD_ROUTE vào bản tin Path, router
gửi có thể nhận thông tin về route mà đường hầm chuyển mạch nhãn sẽ đi qua. Nó có thể
sử dụng object này để yêu cầu thông báo về sự thay đổi trong mạng. Object
RECORD_ROUTE giống như path-vector, do đó có thể được sử dụng để chống loop.
Cuối cùng là object SESSION_ATTRIBUTE được thêm vào bản tin Path với mục đích là
để nhận diện và chuẩn đoán phiên. Các thông tin điều khiển như độ ưu tiên thiết lập và
nắm giữ (setup priority và hold priority), các affinity về nguồn tài nguyên, v.v…cũng
được thêm vào object này. Router dọc đường đi có thể sử dụng giá trị ưu tiên thiết lập và
nắm giữ cùng với object SENDER_TSPEC và POLICY_DATA có trong bản tin Path.
Điều này đã tạo cho bản tin Path được sử dụng như là phương tiện để kiểm tra băng
thông tồn tại ở một độ ưu tiên nào đó dọc toàn bộ đường đi trước khi chiếm quyền các
tiến trình dành trước băng thông có độ ưu tiên thấp hơn. Khi object EXPLICIT_ROUTE
được hoàn tất, bản tin Path được chuyển đến router kế tiếp dọc đường đi được chỉ ra bởi
ERO. Mỗi node dọc đường đi sẽ ghi lại ERO trong khối trạng thái đường dẫn PSB của
nó. Các node cũng điều chỉnh ERO trước khi chuyển tiếp bản tin Path. Trong trường hợp
này, ERO được điều chỉnh cũng được lưu vào trong PSB bên cạnh ERO mà router nhận
được trước đó.

Object LABEL_REQUEST yêu cầu các router trung gian và router cuối đường hầm cung
cấp ánh xạ nhãn cho phiên làm việc RSVP. Nếu một router không thể đáp ứng được yêu
cầu này, nó sẽ gửi bản tin PathErr. Nếu object LABEL_REQUEST không được hỗ trợ
đầu cuối đến đầu cuối, router gửi sẽ được router không hỗ trợ object này 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 cho router upstream. Công
đoạn này lại được tiếp tục tại mỗi router trung gian trên đường hầm, đến khi nào bản tin
Resv đến router đầu đường hầm. Lúc này đường hầm chuyển mạch nhãn đã được thiết
lập. Router này sẽ sử dụng nhãn mà router downstream kế cận nó cấp phát để vận chuyển
lưu lượng qua đường hầm chuyển mạch nhãn.
Tất cả quá trình tạo đường hầm chuyển mạch nhãn mà ta đã nhắc trên sẽ được làm rõ
trong ví dụ sau:
Hình 4.17: Tiến trình tạo ra đường hầm chuyển mạch nhãn
Giả sử rằng R1 đã thực hiện tính toán đường đi và biết rằng nó muốn dành trước băng
thông dọc đường đi R1 -> R2 -> R3 -> R5 -> R6 -> R7. Quá trình thiết lập đường đi diễn
ra như sau:
1. R1 gửi bản tin Path đến R2. R2 nhận bản tin path, kiểm tra để đảm bảo rằng bản tin là
đúng, và kiển tra lượng băng thông mà R1 yêu cầu được dành trước để xem thử nó có đáp
ứng được hay không. Nếu nó thấy có lỗi hoặc không đáp ứng được lượng băng thông mà
R1 yêu cầu, nó sẽ gửi bản tin lỗi PathErr ngược trở lại R1. Giả sử mọi thứ đều tốt, đi đến
bước 2.
2. R2 gửi bản tin Path đến R3. R3 thực hiện tiến trình như R2.
3. R3 gửi bản tin Path đến R5, quá trình kiểm tra diễn ra như ở trên.
4. R5 gửi bản tin Path đến R6, quá trình kiểm tra diễn ra như ở trên.
5. R6 gửi bản tin Path đến R7, quá trình kiểm tra diễn ra như ở trên.
6. R7 là router cuối đường hầm, gửi bản tin resv đến R6. Bản tin này chỉ thị nhãn R7

mong muốn thấy trên gói tin khi nhận gói tin cho đường hầm này. Vì R7 là router cuối
đường hầm nên nó sẽ gửi nhãn implicit-null.
7. R6 gửi bản tin Resv đến R5 và chỉ thị rằng nó muốn thấy nhãn ngõ vào 42 cho đường
hầm này. Có nghĩa là khi R6 nhận nhãn 42, nó sẽ loại bỏ nhãn đó (vì nhãn của R7 là
implicit-null) và gửi gói tin đến R7.
8. R5 gửi bản tin resv đến R3, báo hiệu nhãn 10921. Khi R5 nhận gói tin với nhãn 10921,
nó sẽ chuyển đổi nhãn thành 42 và gửi gói tin đến R6.
9. R3 gửi bản tin Resv đến R2, báo hiệu nhãn 21.
10. R2 gửi bản tin đến R1, báo hiệu nhãn 18.
Tại điểm này, R1 nhận được bản tin Resv, nó biết nhãn sẽ sử dụng để đi qua đường hầm
này. Và đường hầm được thiết lập.
4.2.2.c. Duy trì đường hầm chuyển mạch nhãn : refresh và reroute
RSVP là giao thức trạng thái mềm (soft – state protocol) nên cần phải được refresh lại
tiến trình dành trước băng thông theo chu kì bằng cách báo hiệu lại. Các tiến trình dành
trước băng thông (reservation) được gửi đi bằng cách sử dụng bản tin Path và Resv.
Không có sự khác biệt giữa bản tin Path và Resv được sử dụng để thiếp lập LSP ban đầu
với hai bản tin này khi sử dụng chúng để refresh việc dành trước băng thông, format của
gói tin là như nhau.
Các bản tin RSVP được truyền đi sử dụng IP. Mỗi node RSVP tuần hoàn truyền bản tin
Path và Resv để điều khiển việc mất bản tin RSVP. Các bản tin Path và Resv có một
object là TIME_VALUES chỉ ra giá trị cho chu kì refresh (R) được sử dụng bởi phía gửi
bản tin. Khi một node nhận được bản tin Path và Resv khởi tạo đường đi, sau khi tạo ra
được trạng thái RSVP, node đó sử dụng giá trị R để xác định giá trị cho thời gian sống L
(lifetime) của trạng thái RVSP (thời gian sống là khoảng thời gian tuần hoàn tối đa để
một node vẫn duy trì trạng thái của nó nếu nó không nhận được bản tin refresh nào từ
láng giềng). Do đó, phụ thuộc vào khoảng thời gian sống, một node có thể bỏ qua việc
mất bản tin refresh. Vì các RSVP giử bản tin refresh tuần hoàn nhưng nó phải tránh việc
gửi đồng bộ giữa các router. Vì lý do này, bộ định thời refresh nên được thiết lập ngẫu
nhiên có giá trị nằm trong khoảng [0,5R, 1,5R].
Giả sử thời gian L được chia ra thành K lần, thì RSVP có thể bỏ qua (K-1) lần mất gói tin

RSVP liên tiếp mà không giải phóng trạng thái RSVP. Để tránh việc mất trạng thái xảy ra
tại thời điểm không mong đời, RFC 2205 đề nghị rằng giá trị L nên được thiết lập L >=
(K + 0,5)*1,5*R. Giá trị mặc định là K = 3, R = 30, tức là các bản tin Path và Resv được
gửi 30 giây một lần.Vậy trạng thái RSVP sẽ tồn tại ít nhất 157.5 giây mà nếu không nhận
được bản tin refresh từ láng giềng. Ta biết các bản tin Path và Resv không phải lúc nào
cũng được gửi 30 giây một lần, nếu thường hợp độ trễ xấu nhất là được gửi 30 giây cộng
với 50%jitter. Do đó, có có thể gửi khoảng 15 giây hoặc 45 giây. Vậy với khoảng thời
gian sống là 157.5 giây đủ để cho router có thể có 3 lần có trường hợp jitter xấu nhất (với
tất cả các gói tin bị mất) trước khi timeout.
Thời gian sống càng dài thì càng cho phép một node có thể bỏ qua việc mất càng nhiều số
bản tin RSVP. Dẫn đến kéo dài thời gian để phát hiện sự cố của láng giềng. Lúc đó lưu
lượng dữ liệu đến đích qua láng giềng bị lỗi sẽ bị rơi vào hố đen trong một khoảng thời
gian dài (cho đến khi trạng thái RSVP bị giải phóng).
Việc gửi bản tin refresh tuần hoàn không phát hiện ra được xự cố nhanh chóng. RSTV có
cơ chế cho phép một node có thể phát hiện ra lỗi RSVP một cách nhanh chóng và vẫn
cho phép gửi bản tin refresh tuần hoàn với giá trị lớn để giảm việc gửi bản tin refresh
trong mạng.
+ Phát hiện lỗi RSVP – TE
Đặc điểm RSVP-TE cũng định nghĩa bản tin Hello mới để phát hiện lỗi nhanh của một
node và lỗi kênh điều khiển RSVP. Lỗi của node khác với lỗi kênh điều khiển như sau:
+ Lỗi node: là lỗi mà trong đó một node mất mặt phẳng điều khiển của nó (hoặc một
thành phần của mặt phẳng điều khiển như thành phần RSVP – TE), nhưng mặt phẳng
chuyển tiếp của nó vẫn tiếp tục hoạt động bình thường.
+ Lỗi kênh điều khiển: là lỗi mà trong đó một node mất mặt phẳng điều khiển của nó (khi
một kết nối RSVP down chẳng hạn) với láng giềng, nhưng node đó vẫn tiếp tục hoạt
động đúng (ví dụ như mặt phẳng điều khiển và chuyển tiếp của nó vẫn không bị ảnh
hưởng).
Hello mở rộng được thiết kế đặc biệt do đó một side có thể sử dụng cơ chế này trong khi
side khác không cần sử dụng. Việc phát hiện lỗi láng giềng có thể được khởi tạo tại bất kì
thời điểm nào. Có thể là khi láng giềng học được về nhau, hoặc là khi láng giềng chia sẽ

trạng thái Path hay Resv.
RSVP – TE Hello mở rộng bao gồm một bản tin Hello, một object HELLO_REQUEST,
và một object HELLO_ACK. Các object HELLO_REQUEST và HELLO_ACK bao gồm
các trường instance nguồn (Src_instance) và instance đích (Dst_instance). Trường
Src_instance là trường 32 bit trong đó bên gửi quảng bá một giá trị instance duy nhất đến
láng giềng RSVP. Mỗi giá trị instance riêng biệt, duy nhất được duy trì cho mỗi láng
giềng RSVP. Sau khi phía gửi đã quảng bá giá trị Src_instacne đến láng giềng (giá trị này
khác 0), nó không được thay đổi giá trị này trừ khi mối liên lạc với láng giềng bị mất
hoặc là khi nó khởi động lại.
Dst_instance là một trường 32 bit trong đó một node phản ánh giá trị Src_instance nhận
được cuối cùng từ láng giềng. Nếu một node không nhận được bất kì giá trị Src_instance
nào từ láng giềng, nó thiết lập trường Dst_instance bằng 0. Để phát hiện lỗi về mặt phẳng
điều khiển của láng giềng, node tập hợp và lưu giá trị Src_instance mà nó nhận được từ
láng giềng, giám sát giá trị Src_instance của nó, các giá trị này được phản xạ ngược trở
lại bởi láng giềng trong trường Dst_instance.
Để giám sát trạng thái của láng giềng, node tuần hoàn (tại mỗi khoảng Hello) gửi các bản
tin Hello với các object yêu cầu đến láng giềng. Và nó trông đợi object ACK từ láng
giềng. Khi nhận được object từ láng giềng, nó so sánh giá trị Src_instance nhận được với
giá trị trước đó. Node gửi request sẽ coi như láng giềng có sự cố nếu xảy ra một trong các
điều kiện sau:
+ Giá trị Src_instance mới nhận được khác với giá trị trước.
+ Láng giềng không phản xạ ngược trở lại giá trị Src_instance đúng của node gửi yêu
cầu.
+ Node gửi yêu cầu không nhận được bất kì trả lời nào từ láng giềng trong khoản thời
gian được cấu hình (mặc định là 3.5 khoảng Hello). Ví dụ, nếu khoảng Hello được thiết
lập là 50ms, node có thể phát hiện ra lỗi láng giềng trong khoảng thời gian 175ms.
+ Cơ chế Make-before-break
Make-before-break là cơ chế cho phép ta thay đổi một vài đặc tính của đường hầm TE
(tức là thay đổi băng thông và đường đi mà đường hầm lấy) mà không có việc mất dữ
liệu hay băng thông được đăng kí hai lần (double booking).

Giả sử ta xét ví dụ sau:
Hình 4.18: Ví dụ về cơ chế Make-Before-break
Nếu R1 báo hiệu yêu cầu 35Mb đến mạng, nó đi qua đường trên cùng là R1-R2-R5. Tức
là để dư ra trên kết nối từ R1 đến R2 là 10Mb (băng thông này được gọi là băng thông có
thể dùng được), và dư ra trên kết nối từ R2 đến R5 là 65Mb băng thông có thể dùng được.
Giả sử tại một thời điểm nào đó, R1 muốn tăng kích thước dữ trữ băng thông của nó lên
thành 80Mb. Yêu cầu này phải đi qua đường dưới vì đường trên không thể đáp ứng được.
Do đó R1 dữ trự 80Mb dọc đường đi từ R1-R3-R4-R5. Vậy còn dư ra trên mỗi kết nối là
20Mb. Có một khoảng thời gian ngắn trong quá trình dữ trự băng thông, R1 sẽ dữ trữ
luôn trên cả hai con đường, do đó tổng số băng thông dữ trữ của nó là 115Mb. Tuy nhiên,
35Mb dữ trự sẽ bị giải phóng sau khi 80Mb dữ trự được thiết lập. Make-before-break đơn
giản chỉ là cơ chế cho biết rằng router đầu đường hầm khôgn nên giải phóng băng thông
dữ trự cũ cho đến khi băng thông dữ trự mới được thành lập, điều này sẽ hạn chế đến
mức nhỏ nhất việc mất dữ liệu. Có nghĩa là trong khi định tuyến lại từ dữ đường hầm cũ
sang đường hầm mới, make-before-break đã tạo ra cơ chế cho phép truyền lưu lượng từ
đường hầm cũ vào trong đường hầm mới trươc khi giải phóng đường hầm cũ.
Để hỗ trợ make-before-break, cần thiết trên các kết nối đó phải có phần chung giữa
đường hầm mới và đường hầm cũ, việc dữ trự không nên được tính toán hai lần vì điều
này có thể làm cho điều khiển cho phép loại bỏ đường hầm mới.
Lúc này lại nảy sinh tình huống khác là khi muốn tăng băng thông của đường hầm TE.
Dữ trự băng thông mới sẽ vượt quá mức yêu cầu mà trên kết nối có thể đáp ứng được.
Nếu có chính sách được các node trung gian áp đặt trên bản tin Path, nếu bản tin Path yêu
cầu quá nhiều băng thông thì sẽ bị loại bỏ.
Như ví dụ sau đây:
Hình 4.19: Ví dụ về cơ chế Make-Before-break(tiếp theo)
Hình vẽ của ví dụ này cũng giống như ví dụ trươc, chỉ khác ở chỗ là kết nối từ R4 đến R5
đã bị down. R1 vẫn yêu cầu dữ trữ 35Mb băng thông qua đường hầm từ R1-R2-R5. Giả
sử lúc này R1 muốn dữ trự 80Mb. Vậy R1 sẽ thực hiện như thế nào? Nó không thể đi qua
con đường là R1-R3-R4-R2-R5 vì trước đó nó đã dữ trữ 35Mb trên kết nối từ R1-R2-R5.
R1 cũng không thể phá bỏ đường hầm TE cũ để xây dựng đường hầm mới được vì đó đã

vi phạm vào cơ chế make-before-break.
Nhưng trong RSVP TE có một cơ chế để giải quyết vấn đề đó. Cơ chế đó được gọi là
Share Explicit (SE).
Kiểu dành trước băng thông Share Explicit
SE là kiểu dành trước băng thông cho phép đường hầm chuyển mạch nhãn đang tồn tại
chia sẽ băng thông với bản thân nó để tránh việc yêu cầu dành trước băng thông hai lần.
Điều này sẽ tránh được tình huống như ví dụ đặt ra ở trên.
Vậy SE hoạt động như thế nào ?
SE có hai thành phần:
+ Yêu cầu kiểu dành trước băng thông SE từ mạng.
+ Có khả năng nhận biết tiến trình dành trước băng thông được cho giống với tiến trình
đang tồn tại, do đó băng thông nên được chia sẽ.
Router đầu đường hầm (tunnel headend) sử dụng cờ có trong object
SESSION_ATTRIBUTE để yêu cầu tiến trình dành trước băng thông SE. Object
LSP_TUNNEL_SESSION sẽ thu hẹp bán kính của phiên RSVP thành một đường hầm cụ
thể. Tất cả các dữ trự băng thông được nhận diện dưới một đường hầm duy nhất nhờ vào
sự kết hợp của {địa chỉ phía router gửi, LSP ID, địa chỉ đích, Tunnel ID, extended tunnel
ID}. Trong đó hai phần đầu tiên ở trong object SENDER_TEMPLATE và 3 phần còn lại
ở trong object SESSION. Nếu hai bản tin Path có tất cả 5 yếu tố trên giống nhau, chúng
được xem như là cùng một tiến trình.
Địa chỉ của router gửi là RID của router đầu đường hầm. Địa chỉ đích là RID của router
cuối đường hầm. Bộ nhận diện đường hầm mở rộng (Extended tunnel ID) hoặc là mang
giá trị 0 hoặc là địa chỉ IP của router và tunnelID là interface tunnel ở đầu đường hầm (ví
dụ đầu đường hầm có interface tunnel 1 thì tunnel ID là 1), LSP ID giống như
“instantiation counter”, tức là nó không có giá trị cụ thể, mỗi lần khi có sự thay đổi hoặc
là về yêu cầu băng thông hoặc là sự thay đổi về đường mà nó sử dụng, thì LSP ID sẽ tăng
lên 1.
Quy tắc của tiến trình dữ trữ SE cho MPLS TE là nếu hai tiến trình dành trước băng
thông có 5 yếu tố giống nhau, ngoại trừ việc có giá trị LSP ID khác nhau (có nghĩa là hai
tiến trình cho các LSP khác nhau) thì chúng chia sẽ băng thông.

Để thực hiện reroute, Ingress node sẽ lấy giá trị LSP ID mới và tạo ra
SENDER_TEMPLATE mới. Sau đó nó tạo ra ERO mới để định nghĩa đường đi mới.
Khi hoàn tất nó gửi bản tin Path mới sử dụng object SESSION cũ cộng với
SENDER_TEMPLATE, ERO mới. Nó tiếp tục sử dụng LSP cũ và refresh bản tin Path
cũ. Trên những kết nối nào không có giữ phần chung giữa hai đường đi, bản tin Path mới
sẽ được xem như là thiết lập đường hầm LSP mới. Trên các liên kết có giữ phần chung
của hai đường đi, object SESSION và kiểu SE chia sẽ cho phép LSP được thiết lập nguồn
tài nguyên chia sẽ với LSP cũ. Một khi node ingress nhận được bản tin Resv cho LSP
mới, nó có thể truyền lưu lượng và giải phóng LSP cũ.
Để thực hiện tăng băng thông, một bản tin Path mới với giá trị LSP ID mới có thể sử
dụng để yêu cầu băng thông dữ trữ lớn hơn trong khi LSP ID hiện tại tiếp tục được
refresh để đảm bảo rằng việc dữ trữ không bị mất nếu dành trước băng thông lớn hơn có
sự cố.
Nói chung cả hai quá trình định tuyến lại hay yêu cầu dành trước băng thông nhiều hơn
đều dựa vào giá trị của LSP ID để thực hiện.
Trở lại ví dụ trên: giả sử RID của R1 là 1.1.1.1 và RID của R5 là 5.5.5.5. Quá trình xử lý
của R1 khi gửi thông tin và R4 nhận thông tin sẽ diễn ra như sau :
Bước 1:
+ R1 truyền: gửi tiến trình dành trước băng thông cho {SA=1.1.1.1,LSP ID= 1, EA =
5.5.5.5, TID = 8, XTID = 0}, yêu cầu là dành trước 35Mb dọc đường đi từ R1-R2-R5.
Gọi tiến trình này là Res1.
+ R2: chuyển tiếp Res1 đến R5. đánh dấu interface từ R2 đến R5 có 35Mb đã được dành
trước cho đường hầm này và 65Mb băng thông vẫn còn có thể sử dụng được.
Bước 2:
+ R1 truyền: gửi tiến trình dành trước băng thông cho {SA = 1.1.1.1, LSP ID=2, EA =
5.5.5.5, TID = 8} dọc đường đi từ R1-R3-R4-R2-R5, yêu cầu dành trước cho 80Mb băng
thông. Gọi tiến trình này là Res2
+ R2: kiểm tra tiến trình và nhận ra rằng tiến trình giống như tiến trình trước, ngoại trừ
LSP ID cho phép dành trước mới được tái sử dụng băng thông được dữ trữ trước đó và
phân phối cho đường hầm này 80-35 = 45Mb băng thông thêm vào trên kết nối từ R2 đến

R5. kết nối R2 – R5 được đánh dấu với 80Mb băng thông được dành trước và 20Mb băng
thông không được dành trước.
Theo cách này, cả hai Res1 và Res2 đều được phép cùng tồn tại cho đến khi nào Res1 bị
loại bỏ ra khỏi mạng.
4.2.2.d. Loại bỏ đường đi
Nếu một router (thường là router đầu đường hầm) quyết định rằng việc dành trước băng
thông không còn cần thiết nữa, nó sẽ gửi bản tin PathTear xuống cùng một đường mà nó
đã gửi bản tin Path. Bản tin ResvTear được gửi đi để trả lời lại cho bản tin PathTear và để
thông báo rằng router cuối đường hầm đã loại bỏ việc dành trước băng thông. Như các
bản tin Refresh, bản tin PathTear không phải đ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ó thể sự dụng định tuyến 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 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ó nghĩa là ràng buộc về băng thông chặt chẽ hơn, khả năng đạt được
hiệu quả chất lượng dịch vụ cao (cả về độ trễ, độ jitter, độ mất mát).
Với DS – TE, mỗi đường hầm TE MPLS được thiết lập riêng biệt cho mỗi lớp dịch vụ
DiffServ khác nhau. Sau đó, khi thực hiện định tuyến dựa trên ràng buộc đối với những
đường hầm này, nguồn tài nguyên có thể sử dụng thật sự tương ứng với 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 pool (subpool là một phần của global
pool).
Ví dụ, DS – TE có thể được sử dụng để đảm 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 thông thường.
Bên cạnh đó, thông qua khả năng áp đặt phần trăm băng thông cho lưu lượng được đảm
bảo tối đa trên bất kì kết nối nào, nhà quản trị mạng có thể điều khiển trực tiếp các tham
số hoạt động đầu cuối đến đầu cuối mà không phải phụ thuộc vào các tính chất về định
tuyến đường đi ngắn nhất. Điều này thích hợp cho các ứng dụng đòi hỏi các yêu cầu về
QoS cao (như các ứng dụng thời gian thực).
DS- TE giúp cho nhà cung cấp dịch vụ thực hiện điều khiển cho phép riêng biệt và tính
toán route riêng cho các 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 có thể được
định tuyến lại dọc đường đi khác với các yêu cầu băng thông không thay đổi.
Nói một cách ngắn gọn, MPLS 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ể 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 như thế nào đó là tùy thuộc vào hợp đồng cam kết
mức độ dịch vụ (SLA) giữa nhà cung cấp và khách hàng.