Điều khiển tắt nghẽn trong mpls

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐOÀN XUÂN TOÀN ĐIỀU KHIỂN TẮC NGHẼN TRONG MPLS Chuyên Ngành Mã Số Ngành : Kỹ Thuật Vô Tuyến – Điện Tử : 02.07.01 LUẬN VĂN THẠC SĨ Tp Hồ Chí Minh, tháng 07 năm 2004 CÔNG TRÌNH ĐƯC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC BÁCH KHOA HỒ CHÍ MINH Cán hướng dẫn khoa học : GS.TSKH ĐẶNG LƯƠNG MÔ Cán chấm nhận xét : PGS.TS VŨ ĐÌNH THÀNH Cán chấm nhận xét : TS HOÀNG ĐÌNH CHIẾN Luận văn thạc só bảo vệ HỘI ĐỒNG CHẤM BẢO VỆ LUẬN VĂN THẠC SĨ TRƯỜNG ĐẠI HỌC BÁCH KHOA, ngày tháng năm Đại học Quốc Gia Tp.Hồ Chí Minh TRƯỜNG ĐẠI HỌC BÁCH KHOA CỘNG HOÀ Xà HỘI CHỦ NGHĨA VIỆT NAM Độc Lập – Tự Do – Hạnh Phúc NHIỆM VỤ LUẬN VĂN THẠC SĨ Họ tên học viên Năm sinh Chuyên ngành : ĐOÀN XUÂN TOÀN : 04-11-1979 : Kỹ thuật Vô tuyến-Điện tử Phái : Nam Nơi sinh : Bình Dương Mã số : 2.07.01 I TÊN ĐỀ TÀI : ĐIỀU KHIỂN TẮC NGHẼN TRONG MPLS II NHIỆM VỤ VÀ NỘI DUNG : - Nghiên cứu kỹ thuật chuyển mạch nhãn đa giao thức Kỹ thuật lưu lượng MPLS Tìm hiểu giao thức phân phối nhãn-LDP Giải thuật điều khiển tắc nghẽn Xây dựng mô hình mô giải thuật điều khiển tắc nghẽn đánh giá Đánh giá III NGÀY GIAO NHIỆM VỤ (Ngày bảo vệ đề cương) : IV NGÀY HOÀN THÀNH NHIỆM VỤ (Ngày bảo vệ luận án tốt nghiệp) : V HỌ VÀ TÊN CÁN BỘ HƯỚNG DẪN : GS.TSKH ĐẶNG LƯƠNG MÔ CÁN BỘ HƯỚNG DẪN CHỦ NHIỆM NGÀNH BỘ MÔN QUẢN LÝ NGÀNH Nội dung đề cương luận văn thạc só Hội Đồng Chuyên Ngành thông qua Ngày tháng năm 2004 PHÒNG ĐÀO TẠO SĐH KHOA QUẢN LÝ NGÀNH LỜI CẢM ƠN Em xin bày tỏ lòng biết ơn sâu sắc đến thầy GS.TSKH ĐẶNG LƯƠNG MÔ , người tận tình hướng dẫn sẵn sàng giúp đở em vượt qua khó khăn suốt thời gian thực luận án tốt nghiệp Em xin bày tỏ lòng biết ơn đến tất thầy cô trường Đại Học Bách Khoa Thành Phố Hồ Chí Minh tận tình giảng dạy cho chúng em suốt thời gian qua Cuối cùng, xin bày tỏ lòng biết ơn đến gia đình bạn bè quan tâm giúp đở động viên Tp.Hồ Chí Minh, ngày 25 tháng 07 năm 2004 Học viên thực ĐOÀN XUÂN TOÀN Tóm tắt CBHD: GS.TSKH Đặng Lương Mô TÓM TẮT Internet bắt đầu vào năm 1969 Cơ quan nghiên cứu dự án cao cấp thuộc Bộ Quốc Phòng Mỹ, mang tên ban đầu ARPANET Cho đến ngày nay, Internet trải qua trình phát triển lâu dài đánh dấu phát minh, giao thức đời để thoả mãn yêu cầu phát triển Đó : IP, ISDN, BISDN, ATM… Và giai đoạn nay, đời Chuyển mạch nhãn đa giao thức (Multi_Protocol Label Switching - MPLS) nằm trình phát triển tự nhiên Sự đời Chuyển mạch nhãn hứa hẹn nhiều khả tương lai khả vượt trội Lưu thông mạng thông số mang tính ngẩu nhiên, nên MPLS cần có hỗ trợ kỹ thuật lưu lượng để điều khiển lưu thông cách hớp lý, đáp ứng yêu cầu chất lượng phục vụ khác khách hàng điều khiển tắc nghẽn để đáp ứng lại bùng nổ lưu thông tức thời, giảm tối thiểu ảnh hưởng tắc nghẽn lên mạng Không giống kỹ thuật IP, MPLS kỹ thuật trao đổi nhãn kết nối có định hướng cung cấp nhiều khả năng, chế điều khiển lưu thông cách tinh vi hiệu Trong luận án này, tập trung nghiên cứu vào chế điều khiển tắc nghẽn MPLS, cách thực tái cân lưu thông suốt trình xảy tắc nghẽn Cơ chế cho phép router chuyển mạch nhãn (Label Switched RouterLSR) mạng phát luồng lưu thông bắt đầu xảy tắc nghẽn, đánh dấu rớt gói/cell, LSR đưa thủ tục xử lý tương ứng cho trường hợp Quyết định dựa vào thoả thuận hợp đồng trước khách hàng với nhà điều hành mạng, thông tin lưu thông tức thời, Router (Router ngõ vào) thay đổi đường chuyển mạch nhãn (LSP) từ đường truyền xảy tắc nghẽn sang đường truyền mức sử dụng để phá tắc nghẽn mà trì hợp đồng với khách hàng Giải thuật mang tên FATE, Fast Acting Traffic Engineering, FATE+, chế mở rộng giao thức báo hiệu giao thức CR-LSP cung cấp thêm số chức cho LER ngõ vào, LSR lõi tắc nghẽn xảy HVTH : Đoàn Xuân Toàn Tóm tắt CBHD: GS.TSKH Đặng Lương Mô Trong trình áp dụng chế này, hệ số sử dụng tài nguyên mạng tăng lên cách định tuyến luồng lưu thông khỏi router xảy tắc nghẽn tập trung vào đường truyền mức sử dụng Hệ số mục tiêu nhà cung cấp mạng, định mức độ tận dụng tài nguyên mạng, nâng cao lợi nhuận đảm bảo hợp đồng dịch vụ Các chế điều khiển tắc nghẽn thực mô máy tính phần mềm MNS 2.0 kết hợp với NS2.1b6 chạy hệ điều hành Linux Redhat10 Kết trình bày hình ảnh mô tả dòng lưu thông biểu đồ để đánh giá kết đạt trường hợp có không áp dụng giải thuật vào mạng Trong phần cuối, Luận án trình bày bàn luận để nâng cấp khả hoạt động chế khả tích hợp vào tảng kỹ thuật MPLS HVTH : Đoàn Xuân Toaøn Abstract Internet has been exploited by US Department of Defense since 1969, called ARPANET Nowadays, it has been developed fast through many ranks and used widely in many fields such as Military, Education, and Economic… Invention of MPLS (Multi-protocol Label Switching) is natural development It supplies many new capabilities in the future basic on its outstanding Traffic is a random parameter so MPLS needs a stool for traffic control to meet different Qos (Quality of Services) of users and congestion control This thesis proposes a novel scheme to dynamically manage traffic flows through the network by re-balancing streams during periods of congestion It proposes management-based algorithms that will allow label switched routers (LSRs) within the net work to utilize mechanisms within MPLS to indicate when flows are starting to experience frame/packet loss and them to react accordingly Based upon knowledge of the customers’ service Level Agreement (SLAs), together with instantaneous flow information, the label edge routers (LERs) can them instigate changes to the LSP route and circumvent congestion that would hitherto violate the customer contracts The scheme has two principle components called FATE (Fast Acting Traffic Engineering) and FATE+ They are a novel extension to the existing CR-LDP (Constraint –based Routed Label Distribution Protocol) signaling protocol and they provide additional functionality that governs the behaviour of an ingress LER and core LSRs when congestion arises During transient periods, the efficiency of resource allocation could be increased by routing traffic away from congested resources to relatively under-utilised links Congested scheme is simulated by MNS2.0 and NS2.1b6 softwares running on Redhat Linux 10 Operating system The results are showed by animate pictures and graphs Điều Khiển Tắt Nghẽn Trong MPLS THUẬT NGỮ VÀ TỪ VIẾT TẮT ATM Asynchronous Transfer Mode BGP Border Gateway Protocol BUS Broadcast and Unknown Server CBQ Class Based Queueing CBS Committed Bust Size CDR Committed Data Rate CIN Congestion Indicatior Notification CLP Cell Lost Probability CR-LDP Constraint - Base Routed Label Distribution Protocol CR-LSP Constraint-Base Routed Label Switch Path Diffserv Differentiated Services Mode SWDN Dense Wavelengh Division Multiplexing ER-LSP Explicit Routed Label Switch Path F Forward FATE Fast Acting Traffic Engineering FEC Forward Equivalence Class FIFO First –In First –Out FR Frame Relay FTN Forward Equivalence Class-to-Next Hop Label Forwarding Entry FTP File Transfer Protocol ID Identifier CBHD: GS.TSKH Đặng Lương Mô HVTH: Đoàn Xuân Toàn Điều Khiển Tắt Nghẽn Trong MPLS IETE Internet Engineering Task Force ILM Incoming Label Map IP Internet Protocol IPv4 Internet Protocol version IPv6 Internet Protocol version IPX Internetwork Packet Exchange ISA Integarated Service Achitecture ITU International Telecommunication Union LAN Local Area Network LIB Label Information Base LDP Label Distribution Protocol LSP Label Switch Path LSR Label Switching Router MPOA Multi-Protocol Over ATM MAC Medium Access Control NAK Negative Acknowledgement NHLFE Next Hop Label Forwarding Entry NHRP Next Hop Resolution Protocol OSI Open System Interconnection OSPF Open Shortest Path First OPNET Optimised Network Engineering Tools PDU Protocol Data Unit PSTN Public Switched Telephone Network CBHD: GS.TSKH Đặng Lương Mô HVTH: Đoàn Xuân Toàn Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô Chương MÔ PHỎNG FATE VÀ FATE+ 6.1 Giới thiệu MNS2.0 MNS2.0 (MPLS Network Simulator) phần mềm độc lập mà nhúng vào Network Simulator ( phiên bảng NS2.1b6 ; NS2.1b7 ; NS2.18) MNS2.0 xây dựng để mô mạng chuyển mạch nhãn đa giao thức, hỗ trợ thiết lập đường chuyển mạch nhãn LSP cho yêu cầu QoS (CR-LSP), chức MPLS : giao thức phân phối nhãn LDP, trao đổi nhãn Để hổ trợ chức đó, MNS bao gồm nhiều thành phần : CR-LDP; Khối phân lớp MPLS; Khối phân lớp phục vụ; Khối phận điều kiển; Khối quản lý tài nguyên ; Phục vụ gói 6.3.1 Mô hình MNS hỗ trợ QoS Hình 6.1 Mô hình hỗ trợ QoS Một LSR hỗ trợ QoS xây dựng bao gồm thành phần sau : • CR-LDP : Tạo xử lý thông điệp điều khiển-cảnh báo thiết lập LSP/CR-LSP • MPLS Classifier : Thực chức liên quan tới nhãn : Đẩy nhãn vào stack; Lấy nhãn khỏi stack; trao đổi nhãn cho gói HVTH : Đoàn Xuân Toàn Trang :84 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô • Service Classiffier : Khi gói đến, khối phân lớp phục vụ thực gán gói đến vào lớp phục vụ xác định dựa vào nhãn thông tin số port đến, thông tin QoS nhãn chèn • Admission Control : Thực chức kiểm tra LSR miền MPLS có khả đáp ứng thông số lưu thông mà CR-LSP yêu cầu hay không • Resource Manager : Quản lý tài nguyên • Packet Scheduler : Quản lý gói hàng đợi Gán gói vào hàng đợi tương ứng theo yêu cầu 6.3.1 Mô hình phân lớp Mô hình phân lớp thành lớp tương ứng với mức phục vụ : ST, RT, HBT, SBT Người dùng cài đặt thông số cấu hình cho buffer CBQ : Tốc độ lưu thông, kích thước buffer, mức ưu tiên Hàng đợi ST, HBT, SBT tạo cố định thực lệnh thiết lập cấu hình mô Còn cấu hình hàng đợi RT cấp xoá tự động tương ứng với kiện mô Hình 6.2 Mô hình phân lớp lưu thông HVTH : Đoàn Xuân Toàn Trang :85 Mô FATE & FATE+ 6.2 CBHD : GS.TSKH Đặng Lương Mô Xây dựng mô hình mạng Dùng MNS xây dựng mạng có cấu trúc sau : LSR2 Node0 LSR4 LSR6 LSR1 LSR8 LSR3 LSR5 Node9 LSR7 Hình 6.3 Cấu trúc mạng MPLS Trong thông số đường truyền tương ứng : • Dung lượng đường truyền ™ Node0 – LSR1 Node9-LSR8 : dung lượng 20Mb/s ™ Các đường lại 10Mb/s • Trì hoãn truyền đường truyền 1ms 6.3 Thực mô Trong bước thực mô phỏng, tác giả thực mô nhiều trường hợp khác nhau, để làm sở đánh giá kết giải thuật FATE FATE+ MPLS • Trường hợp : Lưu thông truyền qua miền MPLS mà áp dụng giải thuật điều khiển tắc nghẽn • Trường hợp : Lưu thông truyền qua miền MPLS cóù dụng giải thuật FATE Mục đích : xác định thời gian đáp ứng xảy tắc nghẽn Mục đích : Khảo sát dòng gói rớt • Trường hợp : Lưu thông truyền qua miền MPLS cóù dụng giải thuật FATE+ Mục đích : xác định thời gian đáp ứng xảy tắc nghẽn Mục đích : Khảo sát dòng gói rớt HVTH : Đoàn Xuân Toàn Trang :86 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô 6.3.1 Không áp dụng giải thuật điều khiển tắc nghẽn Kết quaû : ========================================================== FATE SIMULATION Scenario : Without Fate ========================================================== At 0.110592 nodeid=1 Successful lspid=1000 establishment At 2.010591999999999 nodeid=1 Successful lspid=1100 establishment At 2.3999999999999999 Number of lost packets/s: 59 At 2.6000000000000001 Number of lost packets/s: 59 At 2.8000000000000003 Number of lost packets/s: 59 At 3.0000000000000004 Number of lost packets/s: 58 At 3.2000000000000006 Number of lost packets/s: 59 At 3.4000000000000008 Number of lost packets/s: 59 At 3.600000000000001 Number of lost packets/s: 59 At 3.8000000000000012 Number of lost packets/s: 58 At 4.0000000000000009 Number of lost packets/s: 59 At 4.2000000000000011 Number of lost packets/s: 58 At 4.4000000000000012 Number of lost packets/s: 59 At 4.6000000000000014 Number of lost packets/s: 59 At 4.8000000000000016 Number of lost packets/s: 59 At 5.0000000000000018 Number of lost packets/s: 58 At 5.200000000000002 Number of lost packets/s: 59 At 5.4000000000000021 Number of lost packets/s: 59 HVTH : Đoàn Xuân Toàn Trang :87 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô At 5.6000000000000023 Number of lost packets/s: 59 At 5.8000000000000025 Number of lost packets/s: 59 At 6.0000000000000027 Number of lost packets/s: 58 At 6.2000000000000028 Number of lost packets/s: 59 At 6.400000000000003 Number of lost packets/s: 59 At 6.6000000000000032 Number of lost packets/s: 59 At 6.8000000000000034 Number of lost packets/s: 58 At 7.0000000000000036 Number of lost packets/s: 59 At 7.2000000000000037 Number of lost packets/s: 59 At 7.4000000000000039 Number of lost packets/s: 58 At 7.6000000000000041 Number of lost packets/s: 59 At 7.8000000000000043 Number of lost packets/s: 59 At 7.9893999999999998 Remap to original LSP At 8.0000000000000036 Number of lost packets/s: 58 The packet number of SBT : 13839 The packet number of HBT : 27546 The Lost packet number of SBT : 1699 The Lost packet number of HBT : 110 HVTH : Đoàn Xuân Toàn Trang :88 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô 6.3.2 Áp Dụng Fate Kết quaû : ========================================================== FATE SIMULATION Scenario : Negotiate for an alternative LSP ========================================================== At 0.110592 nodeid=1 Successful lspid=1000 establishment At 2.010591999999999 nodeid=1 Successful lspid=1100 establishment At 2.3999999999999999 Number of lost packets/s: 59 At 2.3999999999999999 Send CIN message return ingress LER At 2.4030815999999993 LSR1 receive a CIN messsage Congestion detect Establish the altenative LSP At 2.4115232 nodeid=1 Successful lspid=1200 establishment At 2.4115232 Map to new LSP At 2.6000000000000001 Number of lost packets/s: 79 At 2.6000000000000001 Send CIN message return ingress LER At 7.9893999999999998 Remap to original LSP At 8.000463999993503 nodeid=1 Successful lspid=1000 establishment The packet number of SBT : 15481 HVTH : Đoàn Xuân Toàn Trang :89 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Moâ The packet number of HBT : 27650 The Lost packet number of SBT : 129 The Lost packet number of HBT : Nhận xét : Luồng lưu thông nguồn ưu tiên (SBT) bi rớt gói nhanh chóng phục hồi 6.3.3 Áp dụng Fate+ Kết : ========================================================== FATE+ SIMULATION Scenario : Re-route the LSP via an alternative downstream LSR At 0.110592 nodeid=1 Successful lspid=1000 establishment At 1.4106416000000035 nodeid=1 Successful lspid=1100 establishment At 1.5999999999999999 Number of lost packets/s: 15 At 1.5999999999999999 Send NoResource message to downstream LSR At 1.5999999999999999 Downstream LSR receive a No Resource messsage Downstream LSR negotiate for new LSP At 1.7999999999999998 Number of lost packets/s: 31 HVTH : Đoàn Xuân Toàn Trang :90 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô At 1.7999999999999998 Send NoResource message to downstream LSR At 1.7999999999999998 Downstream LSR receive a No Resource messsage At 5.0108015999989934 nodeid=1 Successful lspid=1000 establishment The packet number of SBT : 9919 The packet number of HBT : 16405 The Lost packet number of SBT : 46 The Lost packet number of HBT : Nhận xét : Fate+ đáp ứng thời gian tắc nghẽn nhanh Fate Sau đó, tác giả thực giá giá trị nguồn khác để rút kết luận hình ảnh sau : HVTH : Đoàn Xuân Toàn Trang :91 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô Trường hợp : Không áp dụng FATE Hình : Đồ thị dòng lưu thông trường hợp không áp dụng FATE Nhận xét : - - Đối với luồng lưu thông có ưu tiên cao bắt đầu rớt gói số gói đến từ nguồn vượt 55000 gói/giây Trong đó, luồng lưu thông ưu tiên thấp bắt đầu rớt gó nguồn đến vượt 35000 gói/giây Nếu nguồn trì tốc độ phát gói lên thi tắc nghẽn xảy ngày trầm trọng, có khả dẫn đ61n sụo đổ mạng hoàn toàn Trường hợp : Áp dụng chế điều khiển tắc nghẽn FATE Thực định tuyến tường minh qua hai đường : LSP1 : 1-2-4-7-8-9 LSP2 : 1-3-5-7-8-9 Tại thời điểm giây, lưu thông từ hai lớp tăng lên Xảy tắc nghẽn LSR7 cho luồng ưu tiên thấp LSR7 thực gởi thông điệp CIN hướng LSR1, LSR1 thực tổ chức thương lượng để phá tắc nghẽn Kết : HVTH : Đoàn Xuân Toàn Trang :92 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô Hình Đồ thị dòng lưu thông trường hợp áp dụng FATE Kết hai trường hợp biểu chung đồ thị: Biểu diễn hai trường hợp đồ thị Trường hợp : Áp dụng chế FATE+ Kết hoàn toàn tương tự FATE thời gian đáp ứng nhanh HVTH : Đoàn Xuân Toàn Trang :93 Mô FATE & FATE+ CBHD : GS.TSKH Đặng Lương Mô 6.4 So sánh FATE FATE+ FATE+ thực đáp ứng nhanh FATE, gởi thông điệp CIN LER ngỏ vào Tuy nhiên, FATE+ áp dụng trường hợp định tuyến “lỏng lẻo” HVTH : Đoàn Xuân Toàn Trang :94 Kết Luận Hướng Phát Triển CBHD : GS.TSKH Đặng Lương Mô Chương KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI 7.1 Nhận xét Mục đích đề tài cung cấp chế điều khiển tắc nghẽn đáp ứng nhanh cho mạng MPLS, yêu cầu tối thiểu thay đổi đường chuyển mạch nhãn LSP/CR-LSP tồn tại, đảm bảo trì hợp đồng với khách hàng suốt trình sảy tắc nghẽn FATE/FATE+ tập hợp chế thủ tục để phát tắc nghẽn luồng lưu thông giải toả tượng gói Trong MPLS, có hai dạng thiết lập đường chuyển mạch nhãn : Định tuyến tường minh “chặc” định tuyến “lỏng” FATE FATE+ áp dụng cho trường hợp theo thứ tự tương ứng Trong giải thuật FATE, LSR phát tắc nghẽn thực gởi thông điệp CIN LER ngỏ vào để LER định : Vẫn trì trạng thái rớt gói (vẫn mức độ cho phép); Thực tổ chức thương lượng cho luồng lưu thông gán vào chuổi buffer cao LSP/CRLSP tồn tại; Thay đổi LSP Trong giải thuật FATE+, LSR tắc nghẽn không gởi thông điệp CIN cho LER ngỏ vào mà tự LSR định đáp ứng lại tắc nghẽn : Tổ chức gán lưu thông vào buffer ưu tiên cao LSR; Thực định tuyến lưu thông qua LSR dòng xuống thay thế; Thực định tuyến lưu thông qua LSR dòng lên thay FATE+ không yêu cầu LER ngỏ vào phải xác định tất LSR trung gian LSP Kết mô thời gian chuyển luồng lưu thông lên buffer cao hơn; hay thay LSP; hay thay đổi LSP lên LSR dòng lên/xuống nhỏ Trả lời câu hỏi : thời gian đáp ứng có đáng kể so với trường hợp tắc nghẽn tự giải toả lượng lưu thông gởi vào LSR bị tắc nghẽn giảm xuống? Khi lưu thông chuyển đến phục vụ chuổi buffer cao hơn, nghóa lưu thông phục vụ mức giá cao Để trì lợi nhuận, nhà cung cấp dịch vụ mong muốn chuyển LSP mức ưu tiên ban đầu Ngay nhà cung cấp dịch vụ chấp nhận vấn đề này, có nhu cầu chuyển HVTH : Đoàn Xuân Toàn Trang :95 Kết Luận Hướng Phát Triển CBHD : GS.TSKH Đặng Lương Mô LSP đường ban đầu LSP nguyên thuỷ xác định tối ưu Vì vậy, tắc nghẽn giải tỏa, LSP/CR-LSP phục hồi lại ban đầu Trong chế điều khiển tắc nghẽn nào, ba vấn đề quan tâm : • Khả phát tắc nghẽn • Khả trì thông tin trạng thái đường truyền tắc nghẽn • Khả đáp ứng lại tắc nghẽn cho trường hợp cụ thể Trong FATE/FATE+ : • Dùng timer để phát tắc nghẽn • Phát xác định số gói bị thực tế để giám sát trạng thái lưu thông • Sử dụng thông điệp “Status Request” để hỗ trợ việc đưa định đáp ứng tắc nghẽn Sử dụng timer để phát tắc nghẽn không đáp ứng tức thời, yếu điểm giải thuật FATE/FATE+ Một phương pháp khác để khám phá tắc nghẽn dùng thông điệp “Status Request” LER ngỏ vào gởi theo chu kỳvào mạng Và nhận trả lời, LER ngỏ vào dựa vào giá trị gói sảy thời mà LSR cung cấp để xác định có sảy tắc nghẽn hay không Tuy nhiên, hiệu phương pháp phụ thuộc vào trường hợp cụ thể Một yếu điểm khác FATE phải gởi thông điệp “CIN” “Status Request” lên mạng làm tăng số lượng tín hiệu báo hiệu Tuy nhiên, mức độ tăng nằm mức cho phép 7.2 Đề xuất Như trình bày phần trên, chế FATE áp dụng cho mạng thực chế định tuyến chặt Còn FATE+ áp dụng cho chế định tuyến “lỏng” Để kết hợp hai chế định tuyến “chặt” “lỏng” vào mạng hai giải thuật điều khiển tắc nghẽn Tác giả đề xuất thêm vào số nhận dạng LSP (LSP ID) bit thực xác nhận loại định tuyến áp dụng cho trình thiết lập LSP này, đặt tên bit T : • T =1 : Xác nhận định tuyến tường minh chặt-> Khi LSR bị tắc nghẽn phát tắc nghẽn, thực kiểm tra bit T áp dụng FATE HVTH : Đoàn Xuân Toàn Trang :96 Kết Luận Hướng Phát Triển CBHD : GS.TSKH Đặng Lương Mô • T =0 : Xác nhận định tuyến “lỏng”-> Khi LSR bị tắc nghẽn phát tắc nghẽn, thực kiểm tra bit T áp dụng FATE+ Như vậy, FATE FATE+ kết hợp vào sử dụng đồng thời mạng 7.3 Hướng phát triển Các mục tiêu đặt cho đề tài giải thoả đáng Bên cạnh đó, số điểm cần nghiên cứu phát triển thêm : • Giảm số lượmg báo hiệu để giám sát tắc nghẽn • FATE/FATE+ không nhạy nguồn khác • Cơ chế phát tắc nghẽn Các kết mô trình bày trường hợp riêng biệt Tuy nhiên, kết hợp đồng thời FATE FATE+ vào mạng hoàn toàn thực được, người vận hành mạng mong muốn thực trì hai chế định tuyến “chặt” “lỏng” đồng thời Một hướng phát triển khác điều khiển tắc nghẽn áp dụng “trí tuệ nhân tạo” vào để điều khiển lưu thông dự đoán tắc nghẽn để có đáp ứng thích nghi trước tắc nghẽn sảy 7.4 Kết luận Mặc dù mong muốn thực nhiều nữa, thời gian có hạn, đề tài giải vấn đề đặt nghiên cứu thực mô hai chế điều khiển tắc nghẽn FATE FATE+ Trong thời gian tới, tác giả mong muốn tiếp tục nghiên cứu để cải tiến khuyết điểm hai giải thuật trên, phát triển theo hướng điều khiển tắc nghẽn HVTH : Đoàn Xuân Toàn Trang :97 TÀI LIỆU THAM KHẢO [2.0} Nguyễn Duy Nhật Viễn, “Kỹ thuật lưu lượng cung cấp QoS MPLS”, Luận văn thạc só ,2003 [2.1] Rosen.E, Rekhter.Y, Tappan.D “MPLS Label Switching Architecture”, http://search.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt Aug 1999 [3.0] Andersson.L Doolan, Feldman.N “LDP Specification” http://search/ietf/org/internet-drafts/draft-ietf-mpls-ldp-06.txt , October 1999 [3.1] Ash.J, Lee.Y, Ashwood-Smith.P al, “ LSP Modification Using CR-LSP”, http://search.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-01.txt Feb 2000 [4.1] Jamoussi.B, “Constraint-Based LSP Setup using LDP”, http://search.ietf.org/internet-drafts/draft-ietf-mpls-cr-lsp-03.txt , Sep 1999 [5.0] [6.0] Holness Felicia, Phillips Chris “ Congestion Control Mechanisms within MPLS Networks”, Septemper 2000 [5.1] Holness Felicia, Phillips Chris “ Effective Traffic Management for MPLS Networks”, July 23-26th ,2000 [6.1] Gaeil Ahn and Woojik Chun, “Design and Implementation of MPLS Network Simulator” [6.2] Holness Felicia, Phillips Chris “ Dynamic QoS for MPLS Networks”, may,22-24, 2000 [6.3] Brunonas Dekeris, LinaNarbutaite “ Congestion control mechenism within MPLS network”, ( Department of Telecommunications, Kanunas University of Technology), 1999 [6.4] Ns-2, “The Network Simulator-ns-2”, http://www.isi.edu/nsnam/ns 2003 [6.0] http://www.isi.edu/nsnam/ns/ns-contributed.html ... giai trò MPLS việc hỗ trợ điều khiển lưu lượng • Chương : Điều Khiển Tắc Nghẽn Nguyên nhân phải điều khiển tắc nghẽn, phân biệt loại tắc nghẽn Trình bày hai giải thuật điều khiển tắc nghẽn MPLS. .. kiểu điều khiển đường chuyển mạch nhãn (LSP) Có hai kiểu điều khiển để LSR thực thiết lập đường chuyển mạch nhãn : điều khiển LSP độc lập điều khiển LSP 3.4.1 Điều khiển phân bố nhãn độc lập Trong. .. 52 4.5 Ví dụ cấu trúc hàng đợi WFQ MPLS 52 CHƯƠNG : ĐIỀU KHIỂN TẮC NGHẼN TRONG MPLS 5.1 Động đời giải thuật FATE 55 5.2 Phạm vi điều khiển lưu thông 56 5.2.1 Moâi trường