Các dịch vụ tích hợp và RSVP

mạng như bộ định tuyến, tổng đài chuyển mạch để thi hành các chức năng khác

nhau như:

- Chính sách: kiểm tra lưu lượng tuân thủ TSpec và thực hiện các hành

động như loại bỏ gói tin nếu nó không tuân thủ.

- Điều khiển thu nạp: Kiểm tra để biết liệu có đủ tài nguyên để đáp ứng

QoS từ chối yêu cầu nếu không đủ tài nguyên.

- Phân loại: nhận biết các gói tin cần các mức QoS cụ thể.

- Xếp hàng và lập danh mục: Đưa ra các quyết định xem khi nào gói tin

được truyền và gói tin nào bị loại bỏ điều này đảm bảo độ tin cậy với các yêu

cầu QoS được thừa nhận.

Các lớp dịch vụ

Sau khi xem xét rất nhiều khả năng, nhóm làm việc 'Các dịch vụ tích hợp'

định nghĩa hai lớp dịch vụ. Hai lớp dịch vụ này là ‘dịch vụ được bảo đảm’ và

‘tải điều khiển’. Các ứng dụng có thể lựa chọn yêu cầu mỗi trong số hai lớp dịch

vụ này phụ thuộc vào liệu lớp dịch vụ nào đáp ứng nhu cầu của chúng.

‘Dịch vụ được bảo đảm’ có xu hướng phục vụ các nhu cầu của các ứng

dụng đòi hỏi sự đảm bảo cao về băng thông và độ trễ. Để đạt được điều này, ứng

dụng cung cấp một TSpec vạch trước giới hạn cho lưu lượng mà nó phát sinh,

bao gồm những tham số như tốc độ tối đa, kích thước gói tin lớn nhất, burst size

và “token bucket rate”. Burst size và token bucket rate bao gồm chỉ tiêu kỹ thuật

token bucket đại diện cho các đặc tính băng thông của ứng dụng phát sinh dữ

liệu với tốc độ thay đổi. Một luồng lưu lượng được định rõ đặc điểm nhờ token

bucket của tốc độ r và burst size b nếu với bất cứ khoảng thời gian T nào nó

không được gửi quá rT+b byte. Một cách trực giác hơn nghĩa là một luồng có

thể gửi dữ liệu với tốc độ trung bình r byte/s nhưng thỉnh thoảng có thể gửi với

tốc độ lớn hơn r nhưng dữ liệu bùng nổ tại tốc độ lớn hơn không được lơn hơn b

byte.

Tham số quan trọng nhất trong RSpec ‘dịch vụ được bảo đảm’ là tốc độ

dịch vụ, tham số này miêu tả tổng băng thông được cấp phát cho luồng lưu

lượng. Bằng việc nhận biết tham số này, cộng với những tham số trong TSpec,

42



cộng với các tham số khác, độ trễ lớn nhất gói tin chấp nhận được có thể tính

toán được. Hơn nữa, một ứng dụng có thể điều khiển giới hạn độ trễ của nó bằng

việc tăng tốc độ dịch vụ của nó trong RSpect.

‘Dịch vụ được bảo đảm’ có thể tới với một vài đòi hỏi. Nó yêu cầu tất cả

các luồng sử dụng dịch vụ phải được xếp hàng riêng rẽ, và điều này thường dẫn

đến sử dụng mạng khá chậm. ‘Tải điều khiển’ khắc phục những nhược điểm này

bằng việc loại bỏ yêu cầu. Thay vì vậy, ‘tải điều khiển’ đơn giản chỉ cố gằng

đảm bảo rằng một ứng dụng sẽ nhận được dịch vụ tương ứng với cái mà nó sẽ

nhận được nếu nó chạy trong mạng không tải với khả năng tương xứng chỉ cho

ứng dụng đó. Để đạt được điều này, một ứng dụng sử dụng ‘tải điều khiển’ cung

cấp một TSpec giống như một ứng dụng sử dụng ‘dịch vụ được bảo đảm’ và các

thành phần mạng đảm bảo rằng

- Có đủ tài nguyên để cung cấp QoS xác định cho các luồng tải điều

khiển.

- Các luồng tải điều khiển được xếp hàng và lên kế hoạch theo cách chặn

các luồng khác không cho làm suy giảm chất lượng truyền của nó.

RSVP

Chúng ta đã xem xét về những thành phần chính trong kiến trúc dịch vụ

tích hợp, bây giờ chúng ta sẽ tập trung vào giao thức báo hiệu cơ sở RSVP.

RSVP là thành phần đóng vai trò quan trọng trong MPLS. RSVP là giao thức

cho phép các ứng dụng thông báo các yêu cầu về QoS với mạng và mạng đáp

ứng bằng những thông báo thành công hoặc thất bại. RSVP phải mang các

thông tin sau:

- Thông tin phân loại, nhờ nó mà các luồng với các yêu cầu QoS cụ thể có

thể được nhận biết trong mạng. Thông tin này bao gồm địa chỉ IP gửi, nhận và

số cổng UPD.

- Tiêu chuẩn kỹ thuật lưu lượng và các yêu cầu QoS, theo khuôn dạng

TSpec và RSpec, bao gồm các dịch vụ yêu cầu(có bảo đảm, tải điều khiển)

Rõ ràng là RSVP phải mang những thông tin này từ các máy chủ tới tất cả

các tổng đài chuyển mạch và các bộ định tuyến dọc theo đường truyền từ bộ gửi

43



đến bộ nhận, từ đó tất cả các thành phần mạng này phải đóng góp vào việc đảm

bảo các yêu cầu QoS của ứng dụng.

RSVP mang các thông tin này sử dụng hai loại bản tin cơ bản là bản tin

PATH và RESV. Các bản tin PATH truyền từ bộ gửi tới một hoặc nhiều bộ

nhận và bao gồm TSpec và thông tin phân loại do bộ gửi cung cấp. Một lý do

cho phép có nhiều bộ nhận là RSVP được thiết kế trực tiếp để hỗ trợ multicast.

Một bản tin PATH bao giờ cũng được gửi tới một địa chỉ mà đó là địa chỉ phiên,

nó có thể là địa chỉ unicast hoặc multicast. Chúng ta thường xem phiên đại diện

cho một ứng dụng đơn khi nó được xác nhận bằng một địa chỉ đích và số cổng

đích được sử dụng bởi ứng dụng mà chúng ta cần phải dành sẵn. Như chúng ta

sẽ xem xét sau không có lý do nào để xem xét một phiên theo cách đó cả.

Khi bô nhận nhận được bản tin PATH, nó có thể gửi bản tin RESV trở lại

cho bộ gửi. Bản tin RESV xác nhận phiên để dự trữ và bao gồm RSpec chỉ định

mức QoS bộ nhận này yêu cầu. Nó cũng bao gồm một vài thông tin xem xét

những bộ gửi nào được cho phép sử dụng tài nguyên đang được cấp phát. Hình

II- biểu diễn luồng bản tin giữa bộ gửi và nhận. Chú ý rằng dành riêng là đơn

hướng. Nếu dành riêng song hướng được yêu cầu (dự trữ thoại thông thường),

phải có một tập các bản tin truyền theo hai hướng đối ngược. Cũng chú ý rằng

các bản tin bị các bộ định tuyến dọc theo đường truyền chặn và gửi chuyển tiếp,

để cho cấp phát tài nguyên có thể thi hành tại tất cả các hop cần thiết.

Một khi dành riêng được thiết lập, các bộ định tuyến giữa bộ gửi và nhận

nhận biết các gói tin thuộc dành riêng nhờ việc kiểm tra năm trường trong các

mào đầu giao thức giao vận và IP là : địa chỉ đích, số cổng đích, số giao thức (ví

dụ UDP), địa chỉ nguồn và cổng nguồn. Chúng ta gọi một tập các gói tin được

nhận dạng theo cách này gọi là luồng dành riêng. Các gói tin trong luồng dành

riêng thường bị khống chế đảm bảo cho luồng không phát sinh lưu lượng quá so

với thông báo trong TSpec và nhận việc xếp hàng đợi và lịch trình phù hợp để

đáp ứng với QoS. Ví dụ một cách để thi hành dịch vụ bảo đảm là sử dụng bộ lập

biểu hành đợi cân bằng theo trọng số (WFQ), ở đây mỗi dành riêng khác nhau



44



được xem như một luồng với bộ lập biểu, và trọng số được ấn định cho mỗi

luồng phù hợp với tốc độ dịch vụ yêu cầu trong RSpec của nó.

Khi hoạt động trên các luồng unicast, RSVP là khá hợp lý. Nó trở nên

phức tạp trong môi trường multicast, bởi vì có thể có rất nhiều bộ nhận đưa ra

quyết định dành riêng cho một phiên đơn và các bộ nhận khác nhau yêu cầu các

mức QoS khác nhau. MPLS tập trung phần lớn vào các ứng dụng unicast của

RSVP, chúng ta sẽ không đi sâu vào khía cạnh multicast của RSVP ở đây.

Một điểm cuối cùng phải chú ý về RSVP là nó là giao thức ‘trạng thái

mềm’. Các đặc tính phân biệt của giao thức trạng thái mềm là trạng thái sẽ tự

động hết hiệu lực sau một thời gian trừ khi nó được làm tươi theo chu kỳ. Trong

trường hợp RSVP, điều này có nghĩa là các bản tin PATH và RESV phải được

gửi định kỳ để làm tươi lại dành riêng. Nếu chúng không được gửi trong một

khoảng thời gian xác định thì dành riêng sẽ huỷ bỏ tự động. Điều này sẽ để lại

một số hệ quả cả ưu và khuyết.

Hình II- : Các bản tin PATH truyền từ bộ gửi tới bộ nhận và các bản tin

RESV truyền theo hướng ngược lại

MPLS hỗ trợ RSVP

Trong phần này chúng ta chỉ tập trung vào vai trò của RSVP trong mạng

MPLS về khía cạnh hỗ trợ QoS, còn vai trò của nó trong điều khiển lưu lượng sẽ

được đề cập trong phần điều khiển lưu lượng.

Mục tiêu đầu tiên trong việc RSVP hỗ trợ MPLS là cho phép các LSR

(chúng phân loại gói tin nhờ việc kiểm tra nhãn chứ không phải là mào đầu IP)

nhận biết các gói tin thuộc các luồng phải thiết lập dành riêng. Nó cách khác,

cần phải tạo và phân phối kết hợp giữa các luồng và các nhãn cho các luồng có

RSVP dành riêng. Chúng ta có thể xem một tập các gói tin mà RSVP reservation

được tạo ra như là một trường hợp riêng khác của FEC.

Điều này trở nên khá dễ dàng để kết hợp các nhãn với các luồng dành

riêng trong RSVP, ít nhất là với unicast. Một đối tượng RSVP mới được định

nghĩa - Đối tường LABEL - và được mang trong bản tin RSVP RESV. Khi một

LSR muốn gửi bản tin RESV cho một luồng RSVP mới, LSR cấp phát một nhãn

45



từ trong tập nhãn rỗi, tại một lối vào trong LFIB của nó với nhãn lối vào được

đặt cho nhãn cấp phát, và gửi bản tin RESV bao gồm nhãn này trong đối tượng

LABEL. Chú ý là các bản tin RESV truyền từ bộ nhận tới bộ gửi là dưới dạng

cấp phát nhãn xuôi.

Dựa trên việc nhận bản tin RESV chứa đối tượng LABEL, một LSR thiết

lập LFIB của nó với nhãn này là nhãn lối ra. Sau đó nó cấp phát một nhãn để sử

dụng như là nhãn lối vào và chèn nó vào bản tin RESV trước khi gửi nó. Rõ

ràng là, khi các bản tin RESV truyền lên LSR ngược thì LSP được thiết lập dọc

theo tuyến đường. Cũng chú ý là, khi các nhãn được cung cấp trong các bản tin

RESV, mỗi LSR có thể dễ dàng kết hợp các tài nguyên QoS phù hợp với LSP.

Hình II- minh hoạ tiến trình. Trong trường hợp này chúng ta xem các

máy chủ không tham dự vào việc phân phối nhãn. LSR R3 cấp phát nhãn 5 cho

reservation này và thông báo nó với LSR ngược là R2. R2 cấp phát nhãn 9 cho

reservation và thông báo nó tới R1. Bây giờ đã có một LSP cho luồng dành

riêng từ R1 tới R3. Khi các gói tin phù hợp với reservation này (ví dụ gói tin gửi

từ H1 tới H2 với số cổng nguồn, đích thích hợp và số giao thức giao vận thích

hợp) tới R1, R1 phân biệt nó sử dụng thông tin mào đầu lớp giao vận và IP và

thi hành các hành động QoS thích hợp cho reservation này như khống chế, lịch

trình các gói tin trong hàng đợi lối ra. Nói cách khác, nó thi hành các chức năng

của một bộ định tuyến ‘các dịch vụ tích hợp’ chạy RSVP. Hơn nữa, R1 đưa mào

đầu nhãn vào các gói tin và chèn giá trị nhãn lối ra là 9 trước khi gửi chuyển tiếp

gói tin tới R2.

Khi R2 nhận gói tin mang nhãn 9, nó tìm kiếm nhãn đó trong LFIB và tìm

tất cả các trạng thái liên quan đến QoS để xem kiểm soát luồng, xếp hàng đợi

gói tin, v.v.. như thế nào. Điều này tất nhiên không cần kiểm tra mào đầu lớp

giao vận và IP. Sau đó R2 thay thế nhãn trên gói tin với một nhãn lối ra từ LFIB

của nó(mang giá trị 5) và gửi gói tin đi.

Chú ý rằng, việc tạo ra kết hợp nhãn được điều khiển bởi các bản tin

RSVP,

Hình II- : Nhãn phân phối trong bảng tin RESV

46



RSVP và khả năng mở rộng

Các dịch vụ khác nhau

Tổng quan về các dịch vụ khác nhau

MPLS hỗ trợ Các dịch vụ khác nhau

Khai báo tắc nghẽn thẳng ECN

Tổng quan về ECN

MPLS hỗ trợ ECN

ii.



Quản lý lưu lượng trong MPLS



iii.



Bảo mật trong MPLS



iv.



Các ứng dụng của MPLS

1.



Cải thiện chất lượng gửi chuyển tiếp gói tin trong mạng



2.



Hỗ trợ QoS và CoS cho các dịch vụ khác nhau



3.



Hỗ trợ khả năng mở rộng mạng



4.



Tích hợp IP và ATM trong mạng



5.



Xây dựng các mạng interoperable



47



Chương III: Ứng dụng MPLS trong mạng VPN

I.



Giới thiệu về MPLS trong VPN

Phần này mô tả cách tiếp cận cho việc xây dựng các dịch vụ IP VPN



trong mạng xương sống của nhà cung cấp dịch vụ. Phổ biến có hai cách tiếp cận:

mô hình lai ghép và cách tiếp cận bộ định tuyến ảo. Mô hình overlay dựa trên

việc tải một vài các giao thức định tuyến hiện thời để mang thông tin.

Cách tiếp cận được đưa ra ở đây không phụ thuộc vào bất cứ sự thay đổi

nào trong bất cứ giao thức định tuyến nào. Những phát kiến liên quan được

nhắm tới trong quá trình sử dụng mạng LAN và đạt được nhờ sử dụng ARP. Đề

tài này cố gắng phân biệt giữa SP và PNA: SP thì sở hữu và quản lý các dịch vụ

lớp 1 và 2 trong khi các dịch vụ lớp 3 thì chịu sự quản lý của PNA. Bằng việc

cung cấp các miền định tuyến độc lập logic, PNA mang lại khả năng mềm dẻo

trong việc sử dụng địa chỉ cá nhân và địa chỉ chưa được đăng ký. Lợi dụng các

LSP cá nhân và lợi dụng VPNID mà nó sử dụng các tập nhãn qua các LSP dùng

chung, thì bảo mật dữ liệu không còn là vấn đề.

Cách tiếp cận trong tài liệu này dựa theo RFC2917 khác với được mô tả

trong RFC 2547, trong đó không có một giao thức định tuyến cụ thể nào được

chuyển tải để mang các tuyến VPN. RFC2547 xác định một cách cho phép thay

đổi BGP để mang các tuyến unicast VPN qua mạng xương sống SP.

II.



Các bộ định tuyến ảo trong MPLS VPN

Một bộ định tuyến ảo là một tập các thread, cả tĩnh và động trong thiết bị



định tuyến, nó cung cấp các dịch vụ định tuyến và gửi chuyển tiếp giống các bộ

định tuyến vật lý. Một bộ định tuyến ảo không nhất thiết là một tiến trình hệ

thống vận hành riêng rẽ (mặc dầu nó có thể là như vậy); nó chỉ đơn giản là cung

cấp ảo giác mà một bộ định tuyến dành riêng sẵn sàng thoả mãn những nhu cầu

của mạng mà nó kết nối vào. Một bộ định tuyến ảo, giống như bản sao vật lý của

nó, là một thành phần trong một miền định tuyến. Các bộ định tuyến khác trong

miền này có thể là các bộ định tuyến vật lý hay ảo. Cho rằng bộ định tuyến ảo

kết nối vào một miền định tuyến xác định và bộ định tuyến vật lý có thể hỗ trợ



48