QUẢN LÝ ĐĂNG KÝ TÀI NGUYÊN TRONG MẠNG DIFFSERV IP

BỘ GIÁO DỤC VÀ ĐÀO TẠO TẬP ĐOÀN BCVT VIỆT NAM
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
*********************************************
NGUYỄN HỒNG SƠN
CHUYÊN ĐỀ 3
QUẢN LÝ ĐĂNG KÝ TÀI NGUYÊN TRONG
MẠNG DIFFSERV IP
CHUYÊN ĐỀ CẤP TIẾN SỸ
Giáo viên hướng dẫn: TS. L Ê H ỮU L ẬP
TS. V Ũ NH Ư L ÂN
HÀ NỘI 4-2008
MỤC LỤC
2
CHUYÊN ĐỀ 3
QUẢN LÝ ĐĂNG KÝ TÀI NGUYÊN TRONG MẠNG
DIFFSERV IP
1. Tổng quan
Trong quá trình thực hiện QoS cho mạng IP, điều dễ nhận thấy là mặc dù giải
pháp IntServ (Integrated Service) đảm bảo cung cấp QoS một cách chắc chắn
nhưng lại vấp phải vấn đề khả triển (scalability) trong mạng trục (core network).
Điều này đã đã tạo động lực cho các nghiên cứu rộng hơn để phát triển một giải
pháp cung ứng QoS phi trạng thái (stateless), đó là kiến trúc Differential Service
(DiffServ). DiffServ đã trở thành giải pháp QoS thứ hai của IETF, trong đó lấy sự
khác biệt dịch vụ trên cơ sở chia lớp (class) làm nền tảng, kiến trúc này đã khắc
phục được nhược điểm của IntServ vì có tính khả triển rất tốt. Tuy nhiên, để đáp
ứng các nhu cầu của đa dạng ứng dụng trên thực tế, kiến trúc được triển khai cần
phải có các thuật toán quản lý lưu lượng nào đó.
Các giải thuật quản lý lưu lượng có thể được phân loại theo thang thời gian hoạt
động của chúng hay theo khả khả năng điều khiển. Do đó, các giải thuật này có thể
hoạt động theo mức gói, khối số liệu hay kết nối. Các nguyên lý phục vụ gói là ví
dụ về các giải thuật theo mức gói hay khối số liệu, với nhiệm vụ cung cấp các mức

phẩm chất giữa hai đầu cuối thông qua biện pháp phân loại và lập lịch lưu lượng.
Trong số các giải pháp điều khiển lưu lượng theo từng cuộc gọi hay từng kết nối
thì điều khiển chấp nhận (admission control) là một trong số các giải pháp phổ
dụng nhất. Điều khiển chấp nhận thì tùy theo vị trí hoạt động mà có thể là tập
trung hay phân tán. Đại diện tiêu biểu cho điều khiển chấp nhận nối phân tán là
RSVP (Resource reSerVation Protocol) [1] và một số các giải thuật khác được mô
tả trong [2] [3][4][5].

Các giải pháp tập trung khá phổ biến gần đây trong các mạng DiffServ là giải pháp
trong đó dùng một thành phần điều khiển gọi là Bandwidth Broker (BB). Giải
pháp này được mô tả trong [6] [7].
Ý tưởng nên cung cấp cơ chế điều khiển chấp nhận nối theo luồng cho các mạng
IP DiffServ để điều khiển tải và cải thiện chất lượng cung cấp QoS đã nhận được
sự đồng thuận trong cộng đồng nghiên cứu Internet. Như được đề nghị trong [8],
cần thiết định nghĩa thêm chức năng điều khiển chấp nhận nối (Connection
Admission Control) cho kiến trúc DiffServ, để xác định xem có cho phép một
luồng lưu lượng chạy qua một đường dẫn nào đó không. Thực tế, một hạn chế của
3
DiffServ là thiếu một lược đồ điều khiển chấp nhận kết nối chuẩn và do đó không
thể giải quyết một cách cơ bản bài toán nghẽn trên mạng Internet. Khi có quá tải
trên một lớp dịch vụ thì tất cả các luồng của lớp dịch vụ này đều chịu một sự suy
giảm chất lượng trầm trọng. Một vài giải thuật điều khiển chấp nhận nối đã được
đề nghị như trong [9] và các chỉ dẫn tham chiếu trong đó. Các đề xuất này cùng
chia sẻ ý tưởng mỗi nút mạng nên chấp nhận các luồng mới tùy vào các đo lường
nghẽn giữa nguồn và đích và tiêu chuẩn quyết định. Không có báo hiệu tường
minh trong các router và quyết định sau cùng có cho phép hay từ chối một luồng
mới được đẩy về biên của mạng IP.
Một giải pháp kết hợp việc đo lường tại mỗi nút mạng với một pha thăm dò từ đầu
cuối này đến đầu cuối kia được đề nghị trong [10] [11], được gọi là GRIP
(Gauge&Gate Reservation eith Independence Probing). Với GRIP, điều khiển

chấp nhận kết nối được thực hiện bằng cách gửi một gói thăm dò từ nguồn đến
đích. Các gói này được phát ra từ các hệ thống đầu cuối trước khi truyền số liệu để
thăm dò tính khả dụng của tài nguyên. Các router trung gian chuyển hay loại bỏ
gói thăm dò tùy vào tiêu chuẩn chấp nhận cục bộ của chúng. Nếu gói thăm dò đến
đích thành công, máy đích sẽ phản hồi bằng một gói báo nhận (ack packet) cho
nguồn. Nếu gói báo nhận về đến nguồn trước khi hết thời gian đợi theo qui định
thì hoạt động truyền sẽ bắt đầu.
Một giải pháp khác là nối tiếp của giao thức báo hiệu điều khiển tải đơn giản
(Load Control lightweight signaling protocol). Giải pháp này tập trung phát triển
một giải thuật quản lý lưu lượng ưu tiên dùng mô hình quyết định phân tán cùng
với sự tính toán trạng thái tải trên cơ sở đăng ký hay đo lường. Giải pháp này được
đề nghị trong tổ chức tiêu chuẩn IETF dưới tên gọi là quản lý tài nguyên trong
DiffServ hay RMD (Resource Management in DiffServ) [12] [13].
Cho đến nay, có thể nói GRIP và RMD là hai giải pháp nổi trội được quan tâm
nhiều nhất. Chi tiết về hai giải pháp này sẽ được trình bày cụ thể trong phần còn
lại của chuyên đề này.
2. Giải pháp GRIP
2.1. Giới thiệu
GRIP là một cơ chế điều khiển chấp nhận kết nối linh hoạt và phân tán được thiết
kế để họat động qua một DiffServ domain, nhưng vẫn tương thích với những công
nghệ Internet đang có. GRIP là giải pháp nhằm vào hạn chế vốn có của DiffServ:
DiffServ không thể cung cấp sự đảm bảo từ đầu cuối đến đầu cuối cho các luồng
lưu lượng, vì nó không có các hỗ trợ cần thiết như trao đổi báo hiệu giữa các
router và trạng thái từng luồng tại các router, cho các thủ tục điều khiển chấp nhận
kết nối. GRIP được xây dựng dựa trên ý tưởng là điều khiển chấp nhận có thể
4
được quản lý bởi một hoạt động điểm nối điểm thuần túy chỉ liên quan đến nguồn
và đích. Trong đó, GRIP gần gủi với các cơ chế phân tán được đề xuất trong các
tài liệu[14][15][16], gọi là EAC (Endpoint Admission Control). Ý tưởng của EAC
là để thiết lập một kết nối, mỗi cặp nguồn và đích khởi động pha thăm dò nhằm

xác định xem kết nối có được phép thực hiện qua mạng hay không. Hầu hết các
EAC được đề nghị, trong pha thăm dò, node nguồn gửi các gói nhằm thể hiện các
đặc tính lưu lượng mà node nguồn muốn phát vào mạng. Khi nhận gói thăm dò
đầu tiên, node đích bắt đầu đo lường thống kê các gói thăm dò trong một khoảng
thời gian qui định. Kết thúc khoảng thời gian đo lường và dựa trên tiêu chuẩn,
node đích đưa ra quyết định có cho phép hay không và thông báo cho nguồn.
Tuy nhiên, cơ chế được mô tả có các nhược điểm liên quan đến thời gian đo lường
được thực hiện tại đích. Thật vậy, quá trình có thể tốn khoảng thời gian đáng kể để
cung cấp một sự đo lường chính xác trạng thái mạng hay sẽ cung cấp một kết quả
đo lường không tin cậy. Bên cạnh đó là ảnh hưởng của sự đo lường không chính
xác.
Để khắc phục các hạn chế này, GRIP thừa kế ý tưởng kết hợp giữa điều khiển
chấp nhận tại đầu cuối và điều khiển chấp nhận dựa vào đo lường MBAC
(measurement based admission control). MBAC được đề nghị lần đầu tiên trong
[17]. Trong đó, giao thức đăng ký linh hoạt SRP (Scalable Reservation Protocol)
được giới thiệu. Nhưng SRP lại là một giao thức báo hiệu đơn giản với các thông
điệp đăng ký tường minh khác với kỹ thuật EAC. Thật vậy, MBAC được đề nghị
như là một cách thức để giải quyết bài toán liên quan đến vấn đề khả triển
(scalability problem).Trong MBAC, mỗi router đo lưu lượng đang đổ dồn về nó.
Các quyết định của điều khiển chấp nhận được router đưa ra dựa trên kết quả của
sự đo lường này thay vì dựa trên các tính toán phân tích về giới hạn của tổn thất
hay độ trễ (và trên các mô hình lưu lượng đặc biệt). Thủ tục này không yêu cầu
duy trì thông tin trạng thái nhưng yêu cầu trao đổi thông tin báo hiệu cần thiết để
yêu cầu và chấp nhận kết nối và sau cùng là để cơ chế CAC được thực thi bởi các
router liên quan. Trong GRIP, các tác giả kết hợp các ý tưởng chủ đạo của SRP
của MBAC và EAC.
GRIP là cơ chế gồm ba thành phần sau:
-Giao thức node nguồn
-Giao thức node đích
-Tiêu chuẩn quyết đinh của router GRIP

Giao thức node nguồn và đích có thể xem như chạy tại các router biên trên mạng
của nhà cung cấp dịch vụ. Tuy nhiên từ quan điểm luận lý thì các giao thức node
nguồn và đích được xem như chạy trên các đầu cuối của người dùng.
5
2.2. Hoạt động của node đầu cuối theo GRIP
Theo GRIP thì hoạt động của các nút đầu cuối là cực kỳ đơn giản. Hình 1 mô tả
việc thiết lập một đường tải lên cho một luồng. Khi một đầu cuối yêu cầu một kết
nối với đầu cuối đích, nút nguồn khởi động một pha thăm dò bằng cách phát ra
một gói thăm dò. Cùng lúc đó, nút nguồn cũng kích hoạt bộ định thời để qui định
thời gian (timeout) cho pha thăm dò. Nếu không nhận được đáp ứng từ nút đích
cho đến khi kết thúc thời gian hạn định thì nút nguồn sẽ từ chối yêu cầu kết nối.
Ngược lại, nếu gói phản hồi đến nguồn khi chưa hết thời gian hạn định thì kết nối
sẽ được chấp nhận và kết thúc pha thăm dò. Điều khiển được chuyển về cho đầu
cuối để bắt đầu pha truyền số liệu. Vai trò của node đích là giám sát gói IP đến, xử
lý gói thăm dò và truyền một gói phản hồi nếu sẵn sàng chấp nhận yêu cầu kết nối
này.
Hình 1- Hoạt động của đầu cuối GRIP
Khi áp dụng GRIP vào kiến trúc DiffServ, một yêu cầu bắt buộc là phải dán nhãn
các gói thăm dò và gói thông tin bằng các giá trị DSCP (DiffServ Code Point)
khác nhau. Điều này cho phép các router cung cấp các phương pháp chuyển tiếp
khác nhau cho các gói thăm dò và gói thông tin, ví dụ gán dịch vụ ưu tiên cho gói
thông tin. Trong trường hợp này, gói phản hồi sẽ được gắn nhãn là một gói thông
tin có ưu tiên cao.

Hoạt động của GRIP được mô tả cũng có thể áp dụng để thiết lập kết nối song
hướng. Trong trường hợp này, nút đích sẽ phản hồi bằng gói thăm dò thay vì dùng
gói phản hồi. Một sự phản hồi cho nguồn sẽ thông qua một gói thăm dò của đích.
GRIP có thể phù hợp để cung cấp các luồng tải xuống (downlink flow). Nút nguồn
cần phát ra một gói kích hoạt để làm cho (bằng thông tin giao thức mức ứng dụng,
chứa trong phần tải của gói kích hoạt) nút đích bắt đầu pha thăm dò trên chính nút

Ứng dụng
nguồn
Node
nguồn
Node
đích
Ứng dụng
đích
Yêu cầu nối
Gói thăm dò Kiểm tra xem
nguồn có sẵn sàng
Gói phản hồi
Khoảng
thời gian
đợi
6
nguồn. Sau cùng, GRIP để cho nhà cung cấp lựa chọn tùy ý các chi tiết hiện thực
bao gồm:
-Bổ sung thông tin báo hiệu riêng trong gói thăm dò hay gói phản hồi.
-Thiết kế pha thăm dò phức tạp hơn, ví dụ bằng các thủ tục lặp lại sau khi
một thăm dò thất bại, nhiều mức định thời hơn…
-Thiết kế hoạt động của giao thức node phức tạp hơn, chẳng hạn như nhiều
gói phản hồi, đưa ra quyết định tại node đích dựa vào các đo lường trên luồng gói
thăm dò…
Với hoạt động của GRIP như mô tả thì tất cả các lược đồ EAC trở thành trường
hợp đặc biệt. Bên cạnh việc đánh nhãn gói, việc thực hiện các gói thăm dò và phản
hồi đơn giản hoàn toàn tương thích với lược đồ thiết lập kết nối của H323 dùng
UDP, trong đó đóng gói bản tin yêu cầu kết nối của H.225 vào gói UDP. Hoạt
đông của GRIP tương thích tốt với các ứng dụng hiện tại.
2.3. Hoạt động của GRIP qua domain không dùng GRIP

Cơ sở của GRIP là hủy bỏ việc thiết lập luồng mới khi không có phản hồi từ đích
trong khoảng thời gian nhất định. Trường hợp hủy bỏ luồng khi GRIP hoạt động
qua domain không dùng GRIP, ví dụ dùng các router cũ hay DiffServ router, được
mô tả trong hình 2(a).
Hình 2-Hoạt động của GRIP qua các môi trường khác nhau.
Nguồn NguồnĐích Đích
Thăm dò
Phản hồi
Định thời
chờ phản
hồi
Từ chối
Định thời
chờ phản
hồi
Chuyển gói
thăm dò
Hủy gói
thăm dò
Yêu cầu
kết nối
Yêu cầu
kết nối
(a) GRIP qua mạng
không dùng GRIP: Từ
chối vì nghẽn mạng
Từ chối
(b) GRIP qua mạng
dùng GRIP: Từ chối
theo quyết định của

router bên trong
7
Trong trường hợp này, việc từ chối luồng chỉ đơn thuần là do nghẽn mạng. Khi
nghẽn xảy ra, thời gian trễ hành trình (từ khi truyền gói thăm dò đến khi nhận
phản hồi) có thể lớn hơn định thời chờ phản hồi trong pha thăm dò, do đó việc
thiết lập kết nối bị từ chối. Tính ổn định được đảm bảo bởi khi nghẽn gia tăng thì
xác suất thiết lập kết nối thành công sẽ suy giảm một cách tương ứng. Do đó, số
lượng luồng được phép sẽ giảm và sự nghẽn mạng sẽ sớm kết thúc.
Các router có thể theo nguyên tắc bỏ qua các gói thăm dò, chỉ xử lý chúng như là
các gói IP thông thường. Khi có sự phân biệt gói như trong ngữ cảnh của DiffServ
thì hoạt đông của GRIP sẽ được cải thiện. Điều này được thực hiện khi các
DiffServ router được cấu hình để phân biệt các gói thông tin và các gói thăm dò
nhờ vào giá trị trong DSCP và phục vụ gói thông tin với ưu tiên cao hơn gói thăm
dò. Gói thăm dò cần phải trãi qua thời gian trễ xấu hơn so với các gói thông tin
thuộc về các kết nối đang được chấp nhận. Vì vậy, các thăm dò có thể phát hiện
nghẽn sớm hơn và kịp thời từ chối kết nối mới tại các router biên.
2.4. Hoạt động của GRIP qua domain dùng GRIP
Sử dụng GRIP qua DiffServ như là biện pháp đảm bảo cung cấp QoS. Cần thiết
nâng cấp các router với các tiêu chuẩn quyết định hiệu quả có thể ngăn chặn thăm
dò một cách tường minh. Điều này dựa trên cơ sở là trong tương lai QoS sẽ được
triển khai linh hoạt bằng cách nâng cấp router một cách độc lập trong các domain.
Trong hình 2(b) các router mạng được giả sử là có thể nhận biết các gói thăm dò
với chức năng điều khiển chấp nhận. Do đó, chúng có thể hủy gói thăm dò một
cách thông minh căn cứ vào các ước lượng QoS cung cấp cho các luồng đã được
chấp nhận, đồng thời căn cứ vào các dự báo nghẽn hỗn hợp. Vì sự mất gói thăm
dò dẫn đến từ chối chấp nhận luồng mới tại các điểm kết cuối với người dùng nên
về căn bản các router có thể cải thiện được QoS cung cấp trong một domain.
Hoạt động của một router GRIP được mô tả trên hình 3. Giả sử router chỉ kiểm
soát lưu lượng GRIP. Các lớp lưu lượng khác (ví dụ best effort) có thể được kiểm
soát bởi các phương tiện hàng đợi bổ sung với ưu tiên thấp. Tại mỗi ngõ ra của

router, GRIP hiện thực hai hàng đợi riêng biệt, một cho các gói số liệu thuộc về
các luồng đã được chấp nhận và một hàng đợi cho lưu lượng thăm dò. Các gói sẽ
được chuyển đến các bộ đệm tương ứng tùy vào mã DSCP của chúng. Các router
GRIP đo lường lưu lượng đã được chấp nhận đang dồn về nó. Trên cơ sở thực
hiện đo lường lưu lượng, router áp dụng tiêu chuẩn quyết định và chuyển qua lại
liên tục giữa hai trạng thái: chấp nhận và từ chối. Khi ở trạng thái chấp nhận, hàng
đợi thăm dò chứa các gói thăm dò và phục vụ chúng tùy theo cơ chế ưu tiên được
mô tả. Ngược lại, khi trong trạng thái từ chối router hủy tất cả các gói thăm dò đến
được chứa trong hàng đợi thăm dò và chặn tất cả các gói thăm dò mới đến.
8
Hình 3-Hoạt động của router GRIP
Nói các khác, router tác động như một cái cổng đối với luồng thăm dò, cửa đóng
hay mở là dựa vào các ước lựơng lưu lượng. Tiêu chuẩn quyết định cũng có thể
dựa trên phương tiện đơn giản hơn so với đo lường, ví dụ giới hạn số lượng các
gói thăm dò có thể chấp nhận bằng cách giới hạn bộ đệm thăm dò. Cơ chế này
cung cấp một tuyến báo hiệu không tường minh đến các điểm cuối. Mỗi router
chịu trách nhiệm mang tính cục bộ để quyết định có chấp nhận luồng mới hay
không, hay là nó bị nghẽn. Quyết định của router được giả sử là trong hai trạng
thái chấp nhận và từ chối và nó quảng bá đến các đầu cuối bằng cách cho phép gói
thăm dò đi qua (chấp nhận) hay chặn các thăm dò lại (từ chối). Khi router trong
trạng thái chấp nhận đồng nghĩa với cho phép một kết nối mới qua nó. Khi router
trong trạng thái từ chối, nó không chuyển tiếp gói thăm dò đi tiếp. Vì quyết định
điều khiển chấp nhận phân tán liên quan đến sự tiếp nhận thành công gói thăm dò
tại đích nên ngăn chặn các gói thăm dò có nghĩa là từ chối tất cả các nổ lực kết nối
có đường đi ngang qua router đó. Ngược lại, một kết nối thành công khi và chỉ khi
tất cả các router mà gói thăm dò tương ứng đi qua đều ở trong trạng thái chấp
nhận.
2.5. Điều khiển lưu lượng tại biên của domain
Trong GRIP domain, nguồn lưu lượng được điều chỉnh tại biên của mạng bằng cơ
cấu DLB (Dual Leaky Buckets) chuẩn. Chọn lựa này xuất phát từ thực tế rằng

Hàng đợi
đảm bảo
QoS
Server
Điều khiển quyết
định theo tiêu chuẩn
Server
ưu tiên
Hàng đợi
Thăm dò
Server
Hàng đợi
dịch vụ
best effort
Server
Đo lường
Chấp nhận/Từ chối
9
trong quá khứ có rất nhiều luật CAC đã được đề nghị và một tập các mô tả lưu
lượng khác nhau đã được giới thiệu nhưng chưa có một giải pháp nào là hoàn
chỉnh. Các tác giả của GRIP cho rằng một trong các lý do là thiếu một mô hình
lưu lượng nguồn chuẩn và đơn giản. Thật vậy, sự tồn tại nhiều lọai nguồn (ví dụ
thoại, MPEG, FTP, WEB, báo hiệu…) là tồn tại nhiều định nghĩa các mô hình
nguồn và giải thuật giám sát. Điều này có nghĩa là về nguyên tắc mỗi nguồn có
một tập mô tả lưu lượng riêng và giải thuật giám sát riêng. Do đó, thiết kế và thực
hiện một CAC đơn giản và khả triển cho tất cả các loại lưu lượng là rất phức tạp.
Để khắc phục vấn đề này một bộ điều chỉnh lưu lượng chuẩn gọi là DLB đã được
dùng trong GRIP.
DLB sẽ điều chỉnh lưu lượng được phát ra bởi một nguồn trước khi vào mạng.
Lưu lượng được điều chỉnh được đặc tính hóa qua bốn tham số, độc lập với nguồn.

Các tham số này gồm: tốc độ đỉnh (peak rate), sai số (tolerance) của tốc độ đỉnh,
tốc độ có thể chịu được (sustainable rate) và sai số của nó. Tốc độ có thể chịu
được là một giới hạn trên (upper bound) của tốc độ trung bình của kết nối. Sai số
của tốc độ có thể chịu được tính theo tham số MBS (Maximum Burst Size). MBS
được dùng để cài giới hạn trên cho chiều dài của một khối số liệu liên tục (burst)
tại tốc độ đỉnh. Thay vì tham số MBS, tham số TBS (Token Bucket Size) cũng
thường được dùng. Sai số của tốc độ đỉnh được giả sử bằng không hay bao hàm
trong tốc độ đỉnh. Do đó, mỗi DLB điều chỉnh lưu lượng nguồn được mô tả bằng
ba tham số mô tả lưu lượng sau:
-P
s
: tốc độ đỉnh (byte/giây)
-r
s
: tốc độ có thể chịu được (byte/giây)
-B
TS
: kích thước token bucket (byte)
Kích thước token bucket TBS liên hệ với tham số MBS qua biểu thức:

B
TS
=(MBS-1)(P
s
-r
s
)/P
s
Các tham số DLB có thể được định nghĩa một lần cho một lớp lưu lượng (ví dụ
VoIP), hay được chọn bởi user bằng cách cân nhắc giữa các nhu cầu tài nguyên và

giá cả dịch vụ.
Ở đây, yêu cầu DLB thực hiện sao cho lưu lượng không nhỏ hơn đặc tả tốc độ có
thể chịu được. Điều này được đảm bảo bằng cách phát ra các gói giả (dummy
packet) để không lãng phí token. Lưu ý rằng giả sử này là không thực tế vì nếu
một user yêu cầu một dịch vụ QoS và trả tiền trên cơ sở các tham số DLB đã chọn
thì gần như không có cơ hội nào để lãng phí. Kết quả là số byte , b(T), được phát
ra bởi nguồn trong một cửa sổ thời gian T (tính bằng giây) có giới hạn trên và dưới
như sau:
10
Max (r
s
T-B
TS
,0)≤ b(T)≤r
s
T+B
TS
(1)
Sau cùng, giả sử rằng các nguồn được chia theo lớp lưu lượng, mỗi lớp bao gồm
các nguồn đồng nhất và độc lập (cùng tham số DLB). Lưu ý rằng một phương
pháp có thể kiểm soát các nguồn hỗn tạp như sau. DiffServ chia lưu lượng thành
các lớp khác nhau, mỗi lớp có yêu cầu đặc biệt. Trong điều kiện số lượng lớp nhỏ
thì các luồng hỗn tạp có nhu cầu đặc biệt có thể tạo nên một lớp. Mỗi lớp có thể
được kiểm soát theo cách thức khác nhau, với cặp mã DSCP cho gói thăm dò và
cho gói số liệu khác nhau riêng cho mỗi lớp, bằng các cơ chế lập lịch phù hợp
tương tự như những gì đã được định nghĩa trong kiến trúc DiffServ.
2.6. Tiêu chuẩn quyết định
Chìa khóa của GRIP là định nghĩa một tiêu chuẩn quyết định có thể đem đến sự
đảm bảo chất lượng cho cơ chế QoS. Theo ngữ cảnh lưu lựơng được mô tả ở trên
cho phép một số giả sử như sau:

(i) Mỗi nguồn lưu lượng được điều chỉnh bởi một DLB
(ii) Các nguồn lưu lượng là đồng nhất, được đặc tính hóa bởi các tham số
giống nhau của DLB
(iii) Các nguồn không lãng phí dịch vụ
Các điều trên tuy có cứng nhắc nhưng cho phép định nghĩa một tiêu chuẩn quyết
đinh có thể đảm bảo QoS một cách chắc chắn.
Tiêu chuẩn quyết định một cách cục bộ trên mỗi liên kết ngõ ra của router được
thực hiện căn cứ vào sự ước lượng theo thời gian thực về số nguồn đang hoạt động
và dựa trên tính toán số nguồn tối đa, gọi là K, có thể chấp nhận mà không làm
giảm chất lượng các luồng đang chạy. Trong đó K được xem như là một nút điều
chỉnh, cho phép người quản trị domain cài đặt mức chất lượng. Ví dụ, xét một liên
kết có dung lượng C byte/giây và một bộ đệm FIFO có kích thước B byte, nếu
mục tiêu chất lượng là không có gói nào bị mất thì số lượng luồng K tối đa có thể
chấp nhận là:
( )
STS
SSTS
PB
rPBCB
K
−+
=
(2)
Trong đó P
S
, r
S
, B
TS
là các tham số DLB của các nguồn được điều khiển. Các kết

quả được cung cấp trong [18] cho phép đánh giá giá trị của K như xác xuất mất gói
hay trễ được kèm giữ ở dưới mức định trước. Nói chung, điều dễ thấy là bất kỳ
mức chất lượng nào đều có thể được áp đặt bằng cách chọn một tham số K phù
hợp.
11
Trong các cơ chế điều khiển chấp nhận dựa vào trạng thái, sẽ là đảm bảo nếu theo
dõi số các kết nối đã được chấp nhận N và chấp nhận yêu cầu kết nối mới nếu N
vẫn còn nhỏ hơn hay bằng K. Điều này ngụ ý về một giao thức báo hiệu phù hợp.
Ngươc lại nếu ước lượng các kết nối được chấp nhận theo thời gian thì tránh được
nhu cầu báo hiệu và duy trì trạng thái.
2.7. Ước lượng số nguồn đã chấp nhận
GRIP ước lượng lưu lượng trung bình tại mỗi ngõ ra của router bằng một cửa sổ
trượt. Trong một cửa sổ có kích thước T, mỗi router đếm số byte chuyển qua liên
kết đang xét. Để xác định chiều dài của cửa sổ đo lường T, thường dùng khoảng
thời gian của trường hợp ngõ ra DLB xấu nhất được đặc tính hóa theo khoảng thời
gian hoạt động (ON) với số liệu được phát ở tốc độ đỉnh và khoảng thời gian im
lặng (OFF), cả hai đều có chiều dài xác định. Chiều dài của khoảng thời gian xấu
này được xác định như sau:
S
S
SS
TS
OFFON
r
P
rP
B
TTT
−
=+=

min
(3)
Kích thước cửa sổ T≥T
min
để có thể bắt được chu kỳ nhỏ nhất của nguồn liên quan
đến ngõ ra DLB trong trường hợp xấu nhất.
Giả sử số luồng N trên một liên kết là cố định, nghĩa là không có luồng mới đến
hay mới đi. Vì lưu lượng được phát ra bởi mỗi nguồn được điều chỉnh bởi một
DLB và vì nguồn là có nhu cầu lớn, dễ thấy số byte A(T) đo được trong thời gian
của cửa sổ T bị giới hạn bởi:
( )
)()(
TSS
N
MAXTSS
N
MIN
BTrNATABTrNA +=≤≤−=
(4)
Với điều giả sử ở trên, tồn tại một kích thước cửa sổ nhỏ nhất sao cho số luồng N
được đánh giá một cách chính xác. Kích thước cửa sổ nhỏ nhất, được ký hiệu sau
đây như là cửa sổ chính xác T
ex
, có thể được xác định bởi áp đặt một điều kiện:
N
MIN
N
MAX
AA <
−1

(5)
Từ đó ta có:
( )
S
TS
ex
r
BN
T
12 −
>
(6)
Công thức này ngụ ý rằng cửa sổ chính xác có thể kéo dài một lượng đáng kể nữa.
Thủ tục đo lường hoạt động trên nền hệ thống mà không ảnh hưởng đến thời gian
thiết lập luồng giống như trong một số lược đồ EAC. Tuy nhiên, ngay cả khi
12
không bị ràng buộc thời gian đo lường ngắn, chúng ta cũng muốn tránh dùng
thường xuyên một cửa sổ chính xác, vì kích thước của nó có thể đạt giá trị trong
một vài phút, tùy vào các tham số của DLB. Một cửa sổ quá lớn có vài nhược
điểm sẽ đề cập đến ở phía sau. Giải pháp là cân đồi giữa kích thước cửa sổ với độ
chính xác của số luồng N.
Tổng quát, với một cửa sổ T cho trước và một A(T) byte đo được trong thời gian
của cửa sổ, theo (4) thì số luồng là ngẫu nhiên trong dải:






−

=≤≤






+
=
TSS
MAX
TSS
MIN
BTr
TA
NN
BTr
TA
N
)()(
(7)
Nếu không có ước đoán nào được thực hiện trên đặc tính thống kê của quá trình
phát cho mỗi nguồn (tùy vào nguồn lưu lượng đổ vào DLB, ở đây không dựa vào
bất kỳ giả thuyết nào về động thái của nguồn), sự phân bố của N giữa hai cực vẫn
không thể biết. Để cung cấp một ước lượng vừa đủ, lược đồ điều khiển chấp nhận
ước lượng số luồng được chấp nhận như là N
est
=N
MAX
và một luồng mới được chấp

nhận nếu N
est
≤K.
Tóm lại, router ở trong trạng thái chấp nhận và các gói thăm dò được phép đi qua
cổng khi:
K
BTr
TA
N
TSS
est
≤






−
=
)(
(8)
Rõ ràng, T càng lớn, dải trong (7) càng hẹp và hiệu suất kênh càng cao.
Biểu thức (7) cho thấy, khi kích thước cửa sổ gia tăng, các chặn N
MAX
và N
MIN
trở
nên gần nhau và khi đạt được cửa sổ chính xác thì N
est

được đánh giá một cách
chính xác. Để đánh giá tính hiệu quả của thủ tục ước lượng, định nghĩa tham số
N
est,min
như là giá trị nhỏ nhất của N thỏa mãn điều kiện:
K
MIN
N
MAX
AA ≥
(9)
Tham số N
est,min
là số luồng nhỏ nhất có thể phát ra số byte lớn hơn hay bằng với số
byte phát ra bởi K luồng. Giải bất phương trình (9) theo N ta được:






+
−
=
TSS
TSS
est
BTr
BTr
KN

min,
(10)
13
Do đó, tham số N
est,min
biểu diễn cho ước lượng xấu nhất, xảy ra khi tất cả các
nguồn đều phát ra ở mức tối đa, nhưng luật ước lượng vốn bảo thủ xem chúng
phát ra với mức tối thiểu. Do đó, tham số này là số lượng luồng tối thiểu được
chấp nhận, nó có thể khiến cho luật điều khiển chuyển router sang trạng thái từ
chối.
Một khía cạnh quan trọng khác là định kích thước cửa sổ đo lường, đây là chủ đề
cơ bản trong lý thuyết MBAC. Nhìn chung, trong các hệ thống MBAC, một cửa sổ
tối ưu là cân đối giữa hai yếu tố:
(i) Cần một cửa sổ đo lường dài, để khắc phục sự yếu kém của hệ thống khi
phân biệt các trạng thái khác biệt; một cửa sổ dài cho phép sự tách biệt
tốt giữa các khoảng cách truyền gói liên quan đến số lượng luồng hoạt
động khác nhau.
(ii) Cần một cửa sổ nhỏ để tác động nhanh đối với các thay đổi của số luồng
đang hoạt động do các luồng đến và đi.
2.8. Quản lý quá độ và bảo vệ ngăn xếp (Transient management and stack
protection)
Đánh giá số luồng có thể chấp nhận N
est
được thực hiện bằng cách đếm số gói số
liệu. Tuy nhiên, khi một router chấp nhận gói thăm dò của một luồng cho trước,
các gói số liệu liên hệ chưa được phát ra bởi nguồn. Nói cách khác, tồn tại một
khoảng thời gian quá độ, trong đó router được nạp luồng mới nhưng nó không thể
xử lý được lưu lượng liên quan. Điều này ngụ ý rằng, khi có số lớn luồng hoạt
động trong một khoảng thời gian rất ngắn, có thể xảy ra sự phân phối vượt quá giá
trị K và do đó QoS không được đảm bảo trong tất cả các điều kiện hoạt động.

Trong các điều kiện thông thường, luật điều khiển chấp nhận cung cấp các biên dự
phòng đủ để tránh các hiệu ứng quá độ để ngăn chặn sự phân phối quá mức đảm
bảo. Mặc dù vậy, để cung cấp các đảm bảo nghiêm ngặt trong bất kỳ điều kiện
hoạt động nào, có thể triệt tiêu hiệu ứng quá độ bằng cách dùng lược đồ bảo vệ
ngăn xếp (satck protection).
Trong hoạt động của GRIP, mỗi gói thăm dò được chấp nhận (gói thăm dò tìm
thấy cửa mở), có thể phát ra một luồng gói mới (trừ khi các router tiếp theo trên
đường tới đích từ chối nó). Khắc phục vấn đề kích hoạt luồng mới bằng cách dùng
một biến ngăn xếp (stack), biến này định nghĩa một vùng nhớ để giữ các luồng quá
độ. Bất cứ khi nào có một gói thăm dò được chấp nhận thì ngăn xếp gia tăng một
đơn vị. Một bộ định thời bằng với khoảng thời gian T của cửa sổ được khởi động
và ngăn xếp giảm tuyến tính với tốc độ 1/T cho đến khi bộ định thời hết hạn.
14
Cơ sở của kỹ thuật này được lý giải một cách đơn giản bằng cách xem trường hợp
một luồng đơn được chấp nhận vào thời điểm t
1
. Bỏ qua trễ hành trình (round trip
delay), tại thời điểm t, với t-t
1
<T, luồng được chấp nhận đã góp mặt vào sự đo
lường trong khoảng thời gian (t
1
,t), trong khi nó không được tính trong khoảng
thời gian (t-T,t
1
). Thật vậy, ngăn xếp tuyến tính tại thời điểm t bằng:
T
tt
1
1

−
−
(11)
Và nó bù vào sự thiếu hụt gói bởi nguồn không phát ra trong khoảng thời gian (t-
T,t
1
). Cơ chế này làm thay đổi điều kiện cổng router (8) như sau: Router trong
trạng thái chấp nhận khi:
KSTACK
BTr
TA
N
TSS
STACKest
≤






+
−
=
+
)(
(12)
Hoạt động được mô tả rõ ràng là tối ưu nếu mỗi gói được chấp nhận đều dẫn đến
một kết nối mới. Thật vậy, biến ngăn xếp sẽ tính toán hợp lý đến sự xuất hiện của
tất cả các luồng mà chúng trở nên hoạt động trong T giây sau cùng. Nhược điểm

chính của cơ chế này là các router tiếp theo dọc đường tới đích có thể chặn một số
các gói thăm dò. Trong trường hợp này, ngăn xếp sẽ thực hiện đăng ký quá độ vào
tài nguyên hệ thống cho một luồng không có thực, điều này làm giảm hiệu suất sử
dụng liên kết.
3. Giải pháp quản lý tài nguyên RMD (Resource Management in DiffServ)
3.1. Giới thiệu
RMD là một cơ cấu được đặc tả trong [12] [13] [19] và được thiết kế cho quản lý
đăng ký tài nguyên động từ biên tới biên (edge-to-edge) trong một DiffServ
domain. RMD mở rộng kiến trúc DiffServ bằng các khái niệm đăng ký và đặc tính
mới. Nó được thiết kế sao cho phù hợp với các nhu cầu quản lý tài nguyên của
mạng truy nhập vô tuyến dựa vào IP (IP-based Radio Access Network). Cơ cấu
RMD là cơ cấu mở, có thể liên kết hoạt động tốt với các cơ chế quản lý tài
nguyên khác sử dụng rộng rãi trong các mạng DiffServ. Đây là cơ cấu được cho là
đơn giản có đặc tính khả triển và chi phí hiện thực thấp.
Vì được thiết kế theo hướng mở rộng khái niệm DiffServ, nên RMD dựa vào các
nguyên lý của DiffServ để cung cấp QoS và duy trì đặc tính khả triển của
DiffServ. RMD làm mạnh kiến trúc DiffServ qua một số khái niệm mới rất cần để
cung cấp tài nguyên động và điều khiển chấp nhận trong DiffServ domain. Trong
cơ cấu RMD bài toán đăng ký phức tạp trong domain được chuyển thành đăng ký
15
tài nguyên đơn giản trong một node. Theo đó có hai giao thức được định nghĩa
trong RMD đó là PHR (Per Hop Reservation) và PDR (Per Domain Reservation).
Cơ cấu RMD và các giao thức PDR và PHR được mô tả trong hình 4.
Hình 4- Cơ cấu RMD
Giao thức PDR được dùng để thực hiện đăng ký tài nguyên trong một domain
hoàn chỉnh. PDR chỉ được dùng tại các router biên. Giao thức PHR được dùng để
đăng ký tài nguyên từng chặng giữa hai router nối trực tiếp. PHR được dùng trong
tất cả các router của DiffServ domain.Trong một DiffServ Domain, các giao thức
PHR và PDR có thể được dùng một cách đồng thời. PHR là giao thức được định
nghĩa mới hoàn toàn trong khi giao thức PDR cũng có thể là một trong các giao

thức đã có như RSVP (Resource reSerVation Protocol), SNMP (Simple Network
Management Protocol), COPS (Common Open Policy Service)…
3.2. Ngữ cảnh hoạt động của cơ cấu RMD
Có hai ngữ cảnh hoạt động khác nhau mà cơ cấu RMD có thể áp dụng. Ngữ cảnh
thứ nhất được mô tả trong hình 5 gồm có các nút mạng đầu vào, nút mạng đầu ra
và các nút trung gian. Ngữ cảnh thứ hai được diễn tả trong hình 6, bao gồm các
nút như hình 5 nhưng được bổ sung một nút “oracle” (hay agent) nó liên quan đến
sự đăng ký theo domain, nhưng không cung cấp bất kỳ tài nguyên nào. Cũng có
thể kết hợp cả hai ngữ cảnh hoạt động này lại với nhau.
DiffServ Domain
Per Domain Reservation (PDR)
Per Hop Reservation (PHR)
16
Hình 5- Ngữ cảnh hoạt động thứ nhất
Hình 6- Ngữ cảnh hoạt động thứ hai.

Hình 7 và hình 8 mô tả các mối giao tiếp ngang hàng trong hoạt động truyền thông
của hai giao thức PDR và PHR trong cả hai ngữ cảnh hoạt động khác nhau.
Hình 7- Các thực thể PDR và PHR ngang hàng trong ngữ cảnh hoạt động thứ
nhất.
Trong ngữ cảnh hoạt động thứ nhất, giao thức PDR được dùng giữa router ngõ vào
và router ngõ ra (ingress và egress). Router ngõ vào nhận yêu cầu QoS từ ngoài và
khởi động đăng ký vào domain. Giao thức PHR được dùng giữa tất cả các router
theo từng chặng dọc theo đường đi từ router ngõ vào đến router ngõ ra. Giao thức
PDR có thể dùng giao thức PHR hay bất kỳ giao thức nào bên dưới vào việc vận
chuyển các bản tin PDR.
Ingress
node
Interior
node

Interior
node
Interior
node
Egress
node
Ingress
node
Interior
node
Interior
node
Interior
node
Egress
node

“Oracle”
PHR PHR PHR PHR PHR
PDR PDR
Interior Interior Interior Egress
17
QoS Request
Ingress
Hình 8- Các thực thể PDR và PHR ngang hàng trong ngữ cảnh hoạt động thứ hai.
Trong ngữ cảnh hoạt động thứ hai, “oracle” nhận yêu cầu QoS từ ngoài vào và
dùng một giao thức PDR hướng đến router ngõ vào và router ngõ ra để thực hiện
đăng ký vào domain. “Oracle” không dùng giao thức PHR. Trong cơ cấu RMD
này tất cả các bản tin báo hiệu PHR đều được phát ra và bị hủy bỏ tại các router
biên (ngõ vào và ngõ ra), không phải tại host cuối.Tất cả các thông điệp PDR đều

được phát ra và bị hủy bỏ tại các router biên hay tại “oracle”.
3.3. Giao thức PDR
Thành phần giao thức PDR giao tiếp với các yêu cầu tài nguyên từ bên ngoài (ví
dụ qua RSVP) và giao tiếp với thành phần giao thức PHR để kiểm soát tài nguyên
trong domain từ đầu cuối này đến đầu cuối kia.
Giao thức PDR quản lý đăng ký tài nguyên trên từng domain và được hiện thực tại
các biên của domain. Giao thức này kiểm soát các yêu cầu đăng ký tài nguyên
động và có thể dựa vào kết quả đăng ký theo từng chặng (PHR). Các yêu cầu đăng
ký tài nguyên động được xem như các yêu cầu QoS từ bên ngoài. Yêu cầu QoS
trong hình từ 5 đến 8, được phát vào từ bên ngoài và các giao thức khác nhau có
thể được dùng để tạo ra các yêu cầu này.
Thành phần PDR có thể dịch yêu cầu tài nguyên và ánh xạ sang một DSCP thích
hợp được dùng trong DiffServ domain. Tùy thuộc vào các giao thức bên ngoài hay
lược đồ đăng ký tài nguyên, các giao thức PDR khác nhau có thể được định nghĩa
để tương thích với yêu cầu ở trên. Giao thức PDR hình thành một liên kết giữa
lược đồ đăng ký tài nguyên bên ngoài và PHR từ biên tới biên (edge-to-edge).
Giao thức PDR có thể nhận diện và chỉ ra bất kỳ yêu cầu bên ngoài nào để thiết
lập và bảo trì tài nguyên bằng cách dùng danh định luồng.
Danh định luồng chỉ được dùng bởi các nút biên để hỗ trợ chức năng đăng ký trên
từng domain. Tùy vào kiểu PDR được dùng, có thể có các danh định luồng khác
PHR PHR PHR PHR
PDR PDRPDR
QoS
Request
Interior
InteriorIngress Egressoracle
18
nhau. Ví dụ một danh định luồng có thể là một kết hợp địa chỉ IP nguồn và địa chỉ
IP đích và mã DSCP. Danh định luồng được dùng để nhận diện trạng thái và sẽ
được giữ trong các nút biên.

Căn cứ vào nhu cầu hoạt động, PDR được định nghĩa các loại thông điệp báo hiệu
sau:
Các thông điệp của PDR chỉ được xử lý bởi các nút biên trong domain. Chức năng
của PDR có thể được mô tả qua một số thông điệp được dùng để trao đổi thông tin
PDR (như danh định luồng, địa chỉ…) giữa các nút biên. Các thông điệp PDR
cũng có thể được đóng gói trong các thông điệp của PHR khi cần.
-PDR_Reservation_Request: Thông điệp báo hiệu được phát ra bởi nút ngõ vào
(ingress node) để khởi động hay cập nhật trạng thái PDR tại nút ngõ ra (egress
node).
-PDR_Refresh_Request: Thông điệp này được truyền từ nút ngõ vào đến nút ngõ
ra để làm tươi trạng thái PDR tại nút ngõ ra. Thông điệp này có thể được đóng gói
trong thông điệp PHR. Khi bất kỳ thông điệp PDR nào được đóng gói trong thông
điệp PHR thì thông điệp PDR đó nên chứa thông tin được yêu cầu bởi nút ngõ ra
liên hệ với thông điệp báo hiệu PHR đang đóng gói thông điệp PDR. Ví dụ danh
định luồng PDR hay địa chỉ IP của nút ngõ vào.
-PDR_Release_Request: Thông điệp này chỉ được dùng khi PDR không dùng
nguyên tắc trạng thái đăng ký mềm (reservation soft sate principle). Thông điệp
này được gửi từ nút ngõ vào đến nút ngõ ra để giải phóng các luồng một cách
tường minh.
-PDR_Reservation_Report: Thông điệp được gửi từ nút ngõ ra đến nút ngõ vào để
thông báo rằng yêu cầu đăng ký tài nguyên đã được nhận và yêu cầu này được
chấp nhận hay bị từ chối. Thông điệp tương tự có thể được dùng để thông báo một
yêu cầu hiệu chỉnh đã được nhận và yêu cầu hiệu chỉnh này được chấp nhận hay bị
từ chối.
-PDR_Refresh_Report: Thông điệp được truyền từ nút ngõ ra đến nút ngõ vào để
thông báo đã nhận được bản tin yêu cầu làm tươi hay cập nhật làm tươi và đã được
xử lý.
-PDR_Congestion_Report: Thông điệp được dùng để thông báo tình trạng nghẽn
nghiêm trọng, được truyền từ nút ngõ ra đến nút ngõ vào.
-PDR_Request_info: Thông điệp được đóng gói trong thông điệp báo hiệu PHR và

được gửi từ nút ngõ vào đến nút ngõ ra. Thông điệp này chứa thông tin được yêu
cầu bởi nút ngõ ra liên hệ đến thông điệp báo hiệu PHR đang gói thông điệp PDR
này. Ví dụ danh định luồng PDR và địa chỉ IP của nút ngõ vào.
Hoạt động của PDR sẽ được minh họa trong mối tương tác với PHR trong mục
3.5.
19
3.4. Giao thức PHR
Giao thức PHR mở rộng PHB (Per Hop Behavior) của DiffServ bằng cách bổ sung
giải pháp quản lý tài nguyên động. PHB được định nghĩa như là một động thái có
thể quan sát được từ bên ngoài áp dụng vào bất kỳ nút DiffServ nào để tiếp nhận
các gói có cùng mã DSCP chạy qua liên kết theo một hướng nhất định. Mã DSCP
được dùng để phân biệt dịch vụ và được biểu diễn bằng sáu bit trong trường ToS
(Type of Service) của gói IPv4 hay trong trường TC (Traffic Class) của gói IPv6.
Giao thức PHR được dùng để đăng ký từng chặng cho từng PHB. Giao thức này
được tối ưu để giảm thiểu các nhu cầu xử lý tại các nút trung gian bên trong
domain. Ví dụ, các nút được hiện thực giao thức này không cần quan tâm xử lý
theo từng luồng.
Cơ cấu RMD định nghĩa hai nhóm PHR khác nhau:
-Nhóm PHR dựa vào đăng ký (Reservation-Based PHR)
-Nhóm PHR dựa vào đo lường (Measured-Based PHR)
PHR dựa vào đăng ký cho phép đăng ký tài nguyên linh động theo từng PHB
trong mỗi nút trên đường đi từ biên này đến biên kia của domain. Các nút dùng
một giao thức trong nhóm này duy trì một trạng thái đăng ký cho mỗi PHB, do đó
không cần thông tin theo từng luồng. Điều này được thực hiện bằng cách kết hợp
trạng thái đăng ký mềm và nguyên tắc giải phóng tường minh. Các tài nguyên
được đăng ký có thể được giải phóng khi nó không được làm tươi theo đinh kỳ
hay khi chúng được yêu cầu giải phóng một cách tường minh bằng thông điệp
chức năng xác định.
Các yêu cầu đăng ký được báo hiệu theo đơn vị tài nguyên, có thể theo một tham
số như băng thông hay các tham số kết hợp phức tạp. Mỗi PHB sẽ được đặt một

ngưỡng tài nguyên cho phép đăng ký tối đa. Ngưỡng này có thể được cấu hình
bằng tay hay cấu hình động.
Hiện có một giao thức PHR dựa vào đăng ký được định nghĩa, đó là RODA PHR
(RMD On DemAnd PHR). Giao thức này được đặc tả trong [13]. RODA PHR là
một giao thức unicast giữa các biên (edge-to-edge) cho một DiffServ domain, với
mục tiêu thiết kế là để đơn giản, giá thành thấp và tính khả triển cao.
PHR dựa vào đo lường là nhóm giao thức báo hiệu về khả năng của tài nguyên
trong đường đi từ biên đến biên mà không duy trì trạng thái đăng ký trong nút.
Tính khả dụng của tài nguyên được kiểm tra bằng phương tiện đo lường trước khi
chấp nhận bất kỳ yêu cầu QoS nào. Đo lường được thực hiện theo lưu lượng thời
gian thực.
20
Ưu điểm của nhóm dựa vào đo lường là hiệu suất cao hơn và không cần phải duy
trì trạng thái. Chỉ có thông tin về lưu lượng yêu cầu của user và ngưỡng tải cho
phép trên từng PHB là được lưu giữ.
Nhìn chung một giao thức PHR có một tập các chức năng liên quan và tương tự
như PDR nó tùy thuộc vào kiểu mạng nơi RMD được áp dụng.
Để thực hiện chức năng giao thức, PHR được định nghĩa ba loại thông điệp báo
hiệu sau:
-PHR_Resource_Request: Thông điệp báo hiệu thông dụng cho cả hai nhóm PHR,
nhưng vai trò của nó là khác nhau giữa hai nhóm: Trong PHR dựa vào đăng ký thì
thông điệp này được nút ngõ vào phát ra để khởi động hay cập nhật đăng ký trạng
thái mềm trên đường đi đến nút ngõ ra. Trong PHR dựa vào đo lường thì thông
điệp này được nút ngõ ra phát ra để kiểm tra trạng thái của mỗi nút dọc theo
đường đi đến nút ngõ ra.
-PHR_Refresh_Update: Thông điệp báo hiệu được phát ra bởi nút ngõ vào để khởi
động, cập nhật hay làm tươi đăng ký trạng thái mềm trên từng DSCP trong đường
đi từ nút vào đến nút ra. Nếu có thể tất cả các nút đều xử lý thông điệp này với ưu
tiên cao hơn thông điệp PHR_Resource_Request.
-PHR_Resource_Release: Thông điệp này được dùng chỉ khi cơ cấu RMD hỗ trợ

thủ tục giải phóng tường minh. Thông điệp này được phát ra bởi nút ngõ vào để
giải phóng một phần trong các tài nguyên đã đăng ký trên mỗi PHB. Hơn nữa,
thông điệp này chỉ ra lượng tài nguyên phải được giải phóng một cách rõ ràng.
3.5. Hoạt động của RMD
Hoạt động bình thường của RMD được minh họa qua hai trường hợp dùng hai
nhóm PHR khác nhau
3.5.1. Hoạt động khi dùng PHR dựa vào đăng ký
Tùy thuộc vào chức năng của giao thức báo hiệu bên ngoài trong mối liên kết hoạt
động với RMD, có hai trường hợp:
-Giao thức bên ngoài không tạo trạng thái đăng ký trong nút biên
-Giao thức bên ngoài tạo trạng thái đăng ký trong nút biên
(i) Trường hợp không tạo trạng thái đăng ký
Khi một yêu cầu QoS đến ingress node, giao thức PDR phải phân loại nó thành
các PHB phù hợp. Cần tính toán đơn vị tài nguyên theo yêu cầu này, đó là tham số
băng thông. Trạng thái PDR sẽ được liên kết với một danh định luồng (flow ID).
21
Nếu yêu cầu QoS được thỏa mãn cục bộ thì ingress node sẽ phát thông điệp
PHR_Resource_Request và PDR_Reservation_Request được đóng gói trong thông
điệp PHR_Resource_Request. Thông điệp PDR này có thể chứa thông tin như địa
chỉ IP của ingress node và danh định luồng.
Các nút trung gian nhận được PHR_Resource_Request phải nhận diện PHB của
nó và nếu có thể cấp tài nguyên cho yêu cầu này. Nút trung gian cấp tài nguyên
bằng cách thêm lượng yêu cầu vào tổng tài nguyên đã đăng ký cho lớp PHB tương
ứng.
Động thái chấp nhận hay từ chối PHR_Resource_Request của egress node tương
tự như các nút trung gian. Sau khi xử lý thông điệp PHR_Resource_Request,
egress node tách thông điệp PDR_Reservation_Request và tạo ra hay nhận diện
danh định luồng và trạng thái. Để thông báo việc đăng ký thành công cho ingress
node, egress node sẽ gửi cho ingress một thông điệp PDR_Reservation_Report.
Sau khi nhận được thông điệp này ingress node sẽ thông báo cho nguồn bên ngoài

về sự đăng ký thành công này, nguồn sẽ truyền số liệu ngay sau đó.
Nếu tài nguyên cần được làm tươi thì ingress node sẽ phát thông điệp
PDR_Refresh_Request để làm tươi trạng thái mềm PDR trong egress node. Một
thông điệp PHR_Refresh_Update được dùng để làm tươi trạng thái mềm PHR
trong tất cả các nút dọc đường đi đến egress node và cả egress node. Thông điệp
PDR_Refresh_Request sẽ được đóng gói trong PHR_Refresh_Update. Đinh kỳ
làm tươi PHR phải bằng nhau trong tất cả các nút biên và nút trung gian.
Các nút trung gian nhận PHR_Refresh_Update sẽ làm tươi hay cập nhật trạng thái
đăng ký liên hệ đến PHB tương ứng. Sau khi xử lý PHR_Refresh_Update, egress
node phải nhận dạng danh định luồng được mang trong đó. Nhờ vậy trạng thái
PDR của luồng tương ứng sẽ được làm tươi một cách tức thời. Egress node sẽ gửi
PDR_Refresh_Report về cho ingress node để thông báo chấp nhận và xử lý thông
điệp PHR_Refresh_Update.
Bên cạnh nguyên tắc xử lý trạng thái đăng ký mềm, các tài nguyên PHR trong bất
cứ nút nào đều có thể được giải phóng một cách tường minh bằng một thông điệp
báo hiệu yêu cầu giải phóng. Trong cách này, ingress node sẽ tạo ra một thông
điệp PHR_Release_Request và sẽ ghi vào trong đó lượng tài nguyên PHR đã yêu
cầu được đặc tả trong trạng thái đăng ký PDR. Bất cứ nút nào nhận thông điệp
PHR_Release_Request phải nhận dạng DSCP và giải phóng lượng băng thông
đăng ký liên quan đến nó. Điều này có thể thực hiện bằng cách trừ vào tổng số tài
nguyên PHR đã đăng ký của PHB tương ứng.
Sơ đồ hình 9 trình bày hoạt động bình thường trong trường hợp đăng ký thành
công.
22
Hình 9-Hoạt động đăng ký thành công.
Nếu không có tài nguyên cục bộ khả dụng, ingress node sẽ từ chối yêu cầu QoS
ngay tức thời và sẽ không phát ra bất kỳ thông điệp báo hiệu nào liên quan đến
yêu cầu này.
Nếu tài nguyên là thiếu trên các nút trung gian (interior node) hay trên egress node
thì các nút này phải đánh dấu và chuyển thông điệp PHR_Resource_Request đi

nhằm chỉ ra sự thiếu hụt tài nguyên này và không có đăng ký nào được xúc tiến tại
ingress node.
Khi dùng nhóm PHR dựa vào đăng ký, ngoài việc bị đánh dấu, một thông điệp
PHR_Resource_Request cũng chứa số nút trung gian đã xử lý thành công thông
điệp này. Con số này có thể được nhận dạng bởi trường TTL (time-to-live) trong
gói IP. Mỗi lần gói IP được chuyển qua một nút, giá trị TTL của nó giảm đi một.
Interior Egress
QoS request
PHR_Refresh_Update
(PDR_RefReq)
PHR_Refresh_Update
(PDR_RefReq)
PHR_Reservation_Report
Data
PHR_Refresh_Update
(PDR_RefReq)
PHR_Resource_Release
(PDR_ReqInfo)
PHR_Resource_Release
(PDR_ReqInfo)
PHR_Resource_Release
(PDR_ReqInfo)
PHR_Refresh_Report
PHR_Resource_Request
(PDR_ResReq)
PHR_Resource_Request
(PDR_ResReq)
PHR_Resource_Request
(PDR_ResReq)
23

InteriorIngress
Do đó nếu ingress node có thể khởi tạo giá trị TTL cho gói IP của bất kỳ thông
điệp PHR nào được gửi đến egress node thì bất kỳ nút trung gian nào đều có thể
biết có bao nhiêu nút trước nó đã xử lý thông điệp này.
Sau khi nhận một thông điệp PDR_Reservation_Report bị đánh dấu, ingress node
sẽ từ chối yêu cầu QoS từ ngoài. Đồng thời, ingress node sẽ khởi động một thủ tục
giải phóng tường minh để giải phóng các tài nguyên không cần thiết trong các nút
đã dành cho luồng bị chối từ này.
Trong trường hợp này, ingress node sẽ phát ra một thông điệp
PHR_Release_Request có chứa lượng tài nguyên. Nó cũng chèn giá trị TTL vào
trường TTL của gói IP của thông điệp này. Thông điệp này cũng sẽ đóng gói
thông điệp PDR_Request_Info trong đó.
Hình 10-Hoạt động đăng ký thất bại.
Bất cứ nút nào nhận thông điệp PHR_Resource_Release đều phải nhận dạng
DSCP và giải phóng phần băng thông tương ứng. Điều này được thực hiện bằng
cách lấy tổng tài nguyên PHR bị chiếm dụng của DSCP trừ đi một lượng bằng
đúng số tài nguyên được chỉ ra trong thông điệp. Ngoài ra, giá trị TTL được giảm
đi một. Khi giá trị này bằng không thì thông điệp PHR_Resource_Release đạt đến
nút trung gian đã đánh dấu thông điệp PHR_Resource_Request và nó sẽ bị hủy.
Điều này có nghĩa là thông điệp này sẽ không giải phóng thêm tài nguyên nào nữa.
Hình 10 mô tả hoạt động trong trường hợp đăng ký không thành công.
Ingress Interior Interior Egress
QoS
request
PHR_Resource_Request
(PDR_ResReq)
PHR_Resource_Request
(PDR_ResReq)
PHR_Resource_Request
(PDR_ResReq) bị đánh

dấu
Thực hiện đánh dấu
vì thiếu tài nguyên
PHR_Reservation_Report bị
đánh dấu
Từ chối
yêu cầu
QoS
PHR_Resource_Release
(PDR_ReqInfo)
24
(ii) Trường hợp tạo trạng thái đăng ký
Hình 11-Hoạt động đăng ký thành công có tạo trạng thái từ giao thức bên ngoài.
Trong trường hợp này một giao thức bên ngoài khởi động và duy trì các trạng thái
(trên từng luồng hay một tập hợp luồng) tại ingress node hay egress node. Trong
RMD thì các trạng thái này được dùng bởi các PDR để kiểm soát việc đăng ký tài
nguyên trong DiffServ domain như là các trạng thái PDR, được xác định thông
qua danh định luồng (flow ID) và mã DSCP.
Egress
QoS request
PHR_Refresh_Update
(PDR_ReqInfo)
PHR_Refresh_Update
(PDR_ReqInfo)
PHR_Reservation_Report
Data
PHR_Refresh_Update
(PDR_ReqInfo)
PHR_Resource_Release
(PDR_ReqInfo)

PHR_Resource_Release
(PDR_ReqInfo)
PHR_Resource_Release
(PDR_ReqInfo)
PHR_Refresh_Report
PHR_Resource_Request
(PDR_ReqInfo)
PHR_Resource_Request
(PDR_ReqInfo)
PHR_Resource_Request
(PDR_ReqInfo)
External
protocol
External
protocol
Giao thức bên ngoài khởi tạo trạng thái PDR
External
protocol
External
protocol
Giao thức bên ngoài
duy trì trạng thái PDR
25
Ingress Interior Interior