Đôi khi một bộ định tuyến thi hành
VI. Các hoạt động trong mạng MPLS
Các hoạt động sau phải được thi hành cho việc chuyển gói tin qua mạng MPLS
1. Tạo nhãn và phân phối nhãn 2. Tạo bảng cho mỗi bộ định tuyến 3. Tạo đường chuyển mạch nhãn LSP 4. Tìm kiếm bảng nhãn, vị trí dán nhãn. 5. Gửi chuyển tiếp nhãn
VII. Các giao thức sử dụng trong MPLS 2. Giới thiệu chung
3. Các giao thức định tuyến a. OSPF b. IS-IS c. RIP d. IRGP e. BGP f. PNNI
4. Giao thức phân phối nhãn LDP
Tiêu chuẩn kỹ thuật tuân thủ LDP là một nhóm thiết kế đại diện cho rất nhiều nhà cung cấp thiết bị, được thành lập sau cuộc họp lần thứ hai của nhóm
làm việc MPLS.Như chúng ta thấy rằng kiến trúc MPLS dựa trên mô hình điều khiển, kết quả là LDP dựa trên sự hợp nhất của hai giao thức TDP và ARIS.
LDP có các tính chất cơ bản như sau:
1. Cung cấp cơ chế nhận biết LSR cho phép các LSR ngang cấp tìm kiếm nhau và thiết lập kết nối.
2. Định nghĩa bốn lớp bản tin:
♦ Các bản tin DISCOVERY
♦ Các bản tin ADJACENCY, để giải quyết vấn đề khởi tạo, duy trì, huỷ bỏ các phiên giữa hai LSR.
♦ Các bản tin LABEL ADVERTISEMENT, giải quyết thông báo,
yêu cầu, thu hồi và loại bỏ kết hợp nhãn.
♦ Các bản tin NOTIFICATION, sử dụng để cung cấp các thông tin trợ giúp và thông tin lỗi tín hiệu.
3. Chạy trên TCP cung cấp phương thức phân phối bản tin đáng tin cậy (ngoại trừ các bản tin DISCOVERY)
4. Thiết kế cho phép khả năng mở rộng dễ dàng, sử dụng các bản tin được xác định như một tập hợp các đối tượng mã hoá TLV(Kiểu, độ dài, giá trị). Mã hoá LTV nghĩa là mỗi đối tượng bao gồm một trường kiểu biểu thị về loại đối tượng chỉ định, một trường độ dài thông báo độ dài của đối tượng và một trường giá trị mà nó phụ thuộc vào trường kiểu. Các khả năng mới được thêm vào với các định nghĩa về kiểu mới. Hai trường đầu tiên có độ dài cố định và được đặt tại vị trí đầu tiên của đối tượng, điều này làm cho nó có thể dễ dàng thi hành việc loại bỏ kiểu đối tượng mà nó không nhận ra. Trường giá trị có một đối tượng có thể gồm nhiều đối tượng mã hoá TLV hơn.
a. Phát hiện LSR lân cận
Giao thức phát hiện LSR lân cận của LDP chạy trên UDP và làm việc như sau. Một LSR định kỳ gửi đi bản tin HELLO tới các cổng UDP trong tất cả các bộ định tuyến trong mạng con. Tất cả các LSR lắng nghe từ
VIII. Chất lượng dịch vụ trong MPLS
Chất lượng dịch vụ QoS chính là yếu tố điều khiển đằng sau MPLS. So sánh với các yếu tố khác, như quản lý lưu lượng và hỗ trợ VPN thì QoS không phải là lý do quan trọng nhất để triển khai MPLS. Như chúng ta sẽ thấy dưới đây, hầu hết các công việc được thực hiện trong MPLS QoS tập trung vào việc hỗ trợ các đặc tính của IP QoS trong mạng. Nó cách khác, mục tiêu là thiết lập sự giống nhau giữa các đặc tính QoS của IP và MPLS, chứ không phải là làm cho MPLS QoS chất lượng cao hơn IP QoS.
Một trong những lý do quan trọng mà MPLS hỗ trợ hơn là mở rộng mô hình IP QoS là MPLS, không giống như IP, không phải là giao thức end-to-end. MPLS không chạy trong các máy chủ, và tương lai là nhiều mạng IP không chạy MPLS vẫn tồn tại. QoS mặt khác thường có đặc tính end-to-end của liên kết giữa các LSR ngang hàng. Ví dụ, nếu một đường kết nối là đường end-to-end có độ trễ cao, độ mất mát lớn, băng thông thấp sẽ giới hạn QoS có thể cung cấp dọc theo tuyến đường end-to-end đó. Một cách khác nhìn nhận về vấn đề này là MPLS không thay đổi về căn bản mô hình dịch vụ IP. Các nhà cung cấp dịch vụ không bán dịch vụ MPLS, họ bán dịch vụ IP (hay dịch vụ Frame Relay hay các dịch vụ khác), và do đó, nếu họ đưa ra QoS thì họ phải đưa ra IP QoS (Frame Relay QoS, v.v..) chứ không phải là MPLS QoS.
Cung không thể nói rằng MPLS không có vai trò trong IP QoS. Thứ nhât, MPLS có thể giúp nhà cung cấp đưa ra các dịch vụ IP QoS hiệu quả hơn. Thứ hai, có một vài khả năng QoS mới có thể hỗ trợ qua mạng nhà cung cấp sử dụng MPLS không thực sự là end-to-end tuy nhiên có thể chứng tỏ là rất hữu ích, một trong số chúng là băng thông bảo đảm của LSP.
Do có mối quan hệ gần gũi giữa IP QoS và MPLS QoS, phần này sẽ được xây dựng xung quanh các thành phần chính của IP QoS. IP cung cấp hai mô hình QoS: Dịch vụ tích hợp (sử dụng chế độ đồng bộ với RSVP) và các dịch vụ khác nhau. Trong các phần nhỏ phía dưới chúng tôi sẽ đưa ra cái nhìn tổng quan về mỗi mô hình và mô tả về MPLS hỗ trợ các mô hình như thế nào. Và cuối
cùng là khai báo tắc nghẽn thẳng (ECN) - một khả năng khác của IP mà được MPLS hỗ trợ.
5. Các dịch vụ tích hợp và RSVP
Tổng quan về các dịch vụ tích hợp
Thuật ngữ ‘Các dịch vụ tích hợp’ đề cập tới kiến trúc QoS tổng thể được IETF tạo ra vào giữa những năm 1990. Nhóm làm việc dịch vụ tích hợp phát triển kiến trúc này với mục tiêu cho phép sự bảo đảm QoS end-to-end cho những ứng dụng cần nó. Sự đảm bảo này sẽ đảm bảo rằng một ứng dụng cần lượng băng thông tối thiểu hoặc độ trễ end-to-end mà ứng dụng có thể có được.
Một phần kết quả của nhóm làm việc là đưa ra tiêu chuẩn kỹ thuật của một số lớp dịch vụ được thiết kế để đạt được những nhu cầu của một số lượng lớn các ứng loại ứng dụng khác nhau. Các tiêu chuẩn kỹ thuật này cũng định nghĩa xem RSVP(Resource Reservation Protocol) có thể được sử dụng như thế nào để đưa ra các yêu cầu QoS sử dụng những lớp dịch vụ này. RSVP được xây dựng trong một nhóm làm việc riêng, và những cố gắng lớn đã được thực hiện để đưa ra một sự phân biệt rõ ràng giữa Dịch vụ tích hợp và RSVP. Một cách cụ thể, 'Dịch vụ tích hợp' có thể cung cấp nhiều loại giao thức báo hiệu, RSVP chỉ là một trong số đó, và RSVP có thể báo hiệu rất nhiều loại thông tin khác nhau chứ không chỉ là các yêu cầu các dịch vụ tích hợp. Mặc dù có sự phân biệt rất rõ ràng này, rất nhiều người vẫn sử dụng thuật ngữ RSVP để đề cập đến toàn bộ kiến trúc QoS 'Các dịch vụ tích hợp'. Trong đề tài này chúng tôi sử dụng RSVP để đề cập tới một giao thức báo hiệu và 'Các dịch vụ tích hợp' là một kiến trúc QoS được định nghĩa do nhóm làm việc 'Các dịch vụ tích hợp'.
Kiến trúc 'Các dịch vụ tích hợp' bao gồm một số các thành phần bổ xung cho một giao thức báo hiệu. Nó cũng bao gồm một vài định nghĩa lớp dịch vụ. Một khía cạnh khác của kiến trúc là một ứng dụng có thể xác định loại lưu lượng sẽ đi vào mạng và mức QoS mà nó muốn nhận từ mạng. Tiêu chuẩn kỹ thuật lưu lượng viết tắt là TSpec, và yêu cầu mức QoS hay là yêu cầu tài nguyên mạng được viết tắt là RSpec. 'Các dịch vụ tích hợp' cũng yêu cầu các thành phần
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,
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
đế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
đượ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