ngoisaobang_khanhly
New Member
Download miễn phí Tầng trình diễn (Presentation Layer)
ATM-LSR C gửi một bản tin chuyển đổi nhãn luồng hướng đi để đáp lại bản tin yêu cầu nhãn và bản tin này sẽ được truyền ngược trở lại trên LSP cho đến khi nó tới ATM-LSR là cổng vào của FEC (ở đây là ATM-LSR A). Khi quá trình này kết thúc, LSP đã sẵn sàng để truyền dữ liệu. Phương pháp này hoạt động rất có hiệu quả trừ khi các bản tin yêu cầu nhãn hay chuyển đổi nhãn được chuyển tiếp giữa các ATM-LSR dựa trên các thông tin định tuyến không chính xác. Tình trạng này xảy ra giống với trường hợp sử dụng TTL được trình bày trước đây và tạo nên một chuyển tiếp vòng các thông tin điều khiển. Tất nhiên hiện tượng này phải được ngăn ngừa bằng cách sử dụng cơ chế bổ sung.
Lưu ý: Hiện tượng chuyển tiếp vòng thông tin điều khiển chỉ xảy ra khi sử dụng các ATM-LSR không có khả năng hợp nhất. Đó là vì một ATM-LSR sẽ trở thành ATM-LSR hợp nhất khi phải hợp nhất ít nhất hai ATM-LSR trong một FEC và nó được đặt cấu hình là hỗ trợ VC hợp nhất.
Cơ chế bổ sung hoạt động dựa trên việc sử dụng bộ đếm nút mạng TLV, trong đó có chứa số lượng các ATM-LSR mà các bản tin yêu cầu nhãn và chuyển đổi nhãn đi qua. Khi một ATM-LSR nhận được một bản tin yêu cầu nhãn và nếu như nó không phải là ATM-LSR cổng ra của FEC hay nó không có nhãn của FEC thì ATM-LSR đó sẽ khởi tạo một bản tin yêu cầu nhãn và gửi nó tới nút ATM-LSR tiếp theo. Nút ATM-LSR tiếp theo này được xác định dựa vào bảng định tuyến.
Nếu như bản tin yêu cầu nhãn khởi đầu có chứa bộ đếm nút mạng TLV thì khi ATM-LSR truyền đi bản tin yêu cầu nhãn của nó sẽ chứa trường này nhưng bộ đếm nút mạng đã được tăng lên một đơn vị. Nó ngược so với việc sử dụng TTL trong đó mỗi khi qua một nút mạng TTL lại giảm đi một đơn vị. Khi ATM-LSR nhận được một bản tin chuyển đổi nhãn, nếu như bản tin này có chứa bộ đếm nút mạng TLV thì bộ đếm này cũng được tăng lên một đơn vị khi bản tin chuyển đổi nhãn được gửi tới nút tiếp theo.
Để tải tài liệu này, vui lòng Trả lời bài viết, Mods sẽ gửi Link download cho bạn ngay qua hòm tin nhắn.
Ketnooi -
Ai cần tài liệu gì mà không tìm thấy ở Ketnooi, đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
Cũng như các chức năng khác của MPLS, chức năng định tuyến hiện của MPLS cũng được chia làm 2 phần: điều khiển và chuyển tiếp. Phần tử điều khiển chịu trách nhiệm thiết lập trạng thái chuyển tiếp (nhãn) dọc theo tuyến hiện. Phần tử chuyển tiếp sử dụng trạng thái chuyển tiếp được thiết lập bởi phần tử điều khiển cũng như các thông tin có trong các gói tin để truyền các gói tin dọc theo tuyến hiện.
III.4.3. Giao thức RSVP
Giao thức RSVP là giao thức báo hiệu đóng vai trò rất 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 sẽ đáp ứng bằng những thông báo thành công hay 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 lưu lượ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 phía gửi và phía nhận, số cổng UDP.
Chỉ tiêu kỹ thuật của luồng 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ó đảm bảo hay 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à bộ các định tuyến dọc theo đường truyền từ bộ gửi đến bộ nhận. Vì vậy tất cả các thành phần mạng phải tham gia vào việc đảm bảo các yêu cầu QoS của ứng dụng.
RSVP mang thông tin trong hai loại bản tin cơ bản là: PATH và RESV. Các bản tin PATH truyền từ bộ gửi tới một hay nhiều bộ nhận có chứa TSpec và các 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ế để hỗ trợ đa hướng. Một bản tin PATH bao giờ cũng được gửi tới một địa chỉ được gọi là địa chỉ phiên, nó có thể là địa chỉ đơn hướng hay đa hướng. Chúng ta thường xem phiên thay mặt cho một ứng dụng đơn, nó được xác nhận bằng một địa chỉ đích và số cổng đích sử dụng riêng cho ứng dụng. Trong phần tiếp theo chúng ta sẽ thấy rằng không có lý do nào để xem xét một phiên theo cách hạn chế như vậy.
Khi bộ nhận nhận được bản tin PATH, có thể gửi bản tin RESV trở lại bộ gửi, bản tin RESV xác nhận phiên có chứa thông tin về số cổng dành riêng và RSpec xác nhận mức QoS mà bộ phận yêu cầu. Nó cũng bao gồm một số thông tin xem xét những bộ gửi nào được phép sử dụng tài nguyên đang được cấp phát. Hình III.15 biểu diễn trình tự bản tin trao đổi giữa bộ gửi và bộ nhận. ở đây chúng ta lưu ý rằng các cổng dành riêng là đơn công. Nếu cần sử dụng các cổng dành riêng song công (ví dụ phục vụ cho thoại truyền thống) thì phải có các bản tin bổ sung theo chiều ngược lại. Cũng chú ý rằng các bản tin được nhận và chuyển tiếp bởi tất cả các bộ định tuyến dọc theo đường truyền thông tin, nên việc cấp phát tài nguyên có thể được thực hiện tại tất cả các nút mạng cần thiết.
Hình III.15: Gửi và nhận các bản tin PATH và RESV
Khi các cổng dành riêng được thiết lập, các bộ định tuyến nằm ở giữa bộ gửi và bộ nhận sẽ xác định các gói tin thuộc cổng dành riêng nào nhờ kiểm tra 5 trường trong phần mào đầu của IP và giao thức truyền tải đó là: địa chỉ đích, số cổng đích, số giao thức (ví dụ UDP), địa chỉ nguồn và nguồn cổng. Chúng ta gọi tập các gói tin được nhận dạng theo cách này 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 vượt quá so với thông báo trong TSpec) và xếp vào hàng đợi phù hợp với yêu cầu về QoS. Ví dụ một cách để có dịch vụ bảo đảm là sử dụng các hàng đợi có trọng số (WFQ), ở đây mỗi cổng dành riêng khác nhau được xem như một luồng đối với các hàng đợi, 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ó.
Đối với các luồng đơn hướng thì RSVP khá đơn giản. Nó phức tạp hơn trong môi trường đa hướng, bởi vì có thể rất nhiều bộ nhận dành riêng cổng cho một phiên đơn và các bộ phận khác nhau có thể yêu cầu các mức QoS khác nhau. Hiện nay MPLS chủ yếu tập trung vào các ứng dụng đơn hướng của RSVP, chúng ta sẽ không đi sâu vào khía cạnh đa hướng của RSVP.
Điểm cuối cùng phải chú ý về RSVP vì đây là giao thức “trạng thái mềm”. Đặc tính để phân biệt giao thức trạng thái mềm với các loại giao thức khác 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 liên tục theo chu kì. Điều đó có nghĩa là RSVP sẽ định kỳ gửi các bản tin PATH và RESV để làm tươi các cổng dành riêng. Nếu chúng không được gửi đi trong một khoảng thời gian xác định thì các cổng dành riêng bị tự động hủy bỏ.
III.4.3.1. MPLS hỗ trợ RSVP
Mục tiêu đầu tiên của việc bổ sung hỗ trợ RSVP vào MPLS là cho phép các LSR dựa vào việc phân loại gói tin theo nhãn chứ không phải theo mào đầu IP nhận biết các gói tin thuộc các luồng của cổng dành riêng. Nói cách khác, cần tạo và kết hợp phân phối giữa các luồng và các nhãn cho các luồng có các cổng dành riêng RSVP. Chúng ta có thể xem một tập các gói tin tạo ra bởi cổng dành riêng RSVP 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 đơn hướng. Chúng ta định nghĩa một đối tượng RSVP mới là đối tượng LABEL được mang trong bản tin RSVP RESV. Khi một LSR muốn gửi một bản tin RESV cho một luồng mới, LSR cấp phát một nhãn 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 đi bản tin RESV có chứa nhãn này. Chú ý là các bản tin RESV truyền từ bộ nhận tới bộ gửi dưới dạng cấp phát nhãn xuôi.
Khi nhận được 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ó đi. Rõ ràng là, khi các bản tin RESV truyền đế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 III.16 minh hoạ quá trình trao đổi này. ở đây chúng ta giả thiết các máy chủ không tham gia vào việc phân phối nhãn. LSR R3 cấp phát nhãn 5 cho cổng dành riêng này và thông báo tới R2. R2 cấp phát nhãn 9 cũng cho cổng dành riêng này và thông báo 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 tương ứng với cổng dành riêng 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 vận thích hợp) tới R1, R1 phân biệt nó bằng các thông tin mào đầu IP và lớp truyền tải để tạo ra QoS thích hợp cho cổng dành riêng ví dụ như đặc điểm và hàng đợi các gói tin trong hàng đợi lối ra. Nói cách khác, nó thực hiện các chức năng của một bộ định tuyến tích hợp dịch vụ sử dụng RSVP...