Mô phỏng MPLS - TE

được đặc tả trong thuộc tính phiên (session attribute) có sẵn sàng hay không. Có 2 tình huống xảy ra: Không có đủ băng thông trên liên kết được đặc tả mà trung kế lưu lượng muốn thiết lập trên đó. Module LCAC (Link level admission control) thông báo RSVP biết về việc thiếu tài nguyên và RSVP tương ứng sẽ tạo ra bản tin PATH_ERR với mã là “Requested bandwidth unavailable”. Thêm vào đó việc quảng bá thông tin của nút cũng được khởi động. Nếu băng thông sẵn sàng, băng thông sẽ được dự trữ và sẽ chờ để bản tin RESV xác nhận việc dự trữ. Thêm vào đó khi mức ngưỡng tài nguyên bị vượt quá, thông tin về tài nguyên ngay lập tức được quảng bá bởi IGP. Trong suốt quá trình điều khiển chấp nhận (admission control), các độ ưu tiên cũng được kiểm tra. Nếu băng thông yêu cầu có sẵn, nhưng đang được sử dụng bởi các phiên có độ ưu tiên thấp hơn, các phiên có độ ưu tiên thấp hơn có thể bị lấn chiếm (bắt đầu từ độ ưu tiên thấp nhất) để giải phóng băng thông. Khi được hỗ trợ lấn chiếm, bản tin PATH_ERR hoặc/và RESV_ERR sẽ được gửi đi với mã “ policy control failure”. Chỉ định nhãn cho trung kế lưu lượng RSVP làm việc bằng cách gửi đi các bản tin PATH để thiết lập đường đi qua mạng. Trong trường hợp của kĩ thuật lưu lượng MPLS, con đường này phải nằm trong bản tin PATH bằng cách cấu hình tuyến tường minh hoặc tính toán tuyến động. Khi bản tin RESV đi theo đường ngược lại nó tương tác với MPLS để chỉ định nhãn. Nhãn cuối cùng trên đường đi là implicit-null để thông báo cho router trước đó biết đó là điểm cuối cùng của trung kế. Khi việc dự trữ RESV hoàn tất thì cũng là lúc MPLS LSP hình thành. Xét ví dụ sau để làm rõ quá trình chỉ định nhãn cho trung kế và các đích sau trung kế Hình 3-10 : Quá trình chỉ định nhãn cho trung kế Để định tuyến gói tin đến mạng của khách hàng (R7) , các bản tin hello LDP được gửi một cách tường minh đến R7. Các bản tin này tạo ra các nhãn cho phần cuối con đường đến mạng của khánh hàng. Lúc này một chồng nhãn được sử dụng. Nhãn trên cùng của chồng nhãn (nhãn 22 tại R1) xác định con đường bên trong mạng ISP.Khi nhãn trên cùng này bị gỡ bỏ khỏi chồng nhãn tại R3, 1 nhãn khác (nhãn 46) được thêm vào chồng nhãn định nghĩa con đường đến mạng khách hàng. R6 có thể sử dụng nhãn khác trong mạng của khách hàng (nhãn 44) hoặc tiếp tục gỡ bỏ nhãn 46 để đưa gói IP đến R7. Lưu lượng đến R3 có thể chỉ sử dụng nhãn trên cùng của chồng nhãn, khi đó R3 sẽ gỡ bỏ nhãn ra khỏi gói tin và chuyển gói tin IP này đến R6. Gói tin này sẽ được định tuyến đến R7 trên lớp IP. Các đối tượng RSVP Trong bản tin PATH và RESV có 5 đối tượng mà TE có liên quan: Đối tượng label_request được mang trong bản tin PATH và yêu cầu việc gán nhãn. Yêu cầu về hoán đổi nhãn cho đường hầm LSP được đề xướng bởi router lối vào. Đối tượng label nằm trong bản tin RESV. Các nhãn được cấp phát xuôi dòng và phân phối bằng các bản tin RESV. Đối tượng Explicit_Route trong bản tin PATH để yêu cầu hoặc đề xuất 1 tuyến cho trung kế lưu lượng (là 1 chuỗi các hop hình thành nên tuyến đó). Đối tượng này được sử dụng khi nút gửi biết được 1 tuyến đáp ứng được yêu cầu QoS của đường hầm và sử dụng hiệu quả tài nguyên mạng. Đối tượng Record_Route được thêm vào bản tin PATH và RESV cho phép nút gửi nhận được các thông tin về con đường thực sự mà đường hầm LSP đi qua. Đối tượng Session_Attribute được thêm vào bản tin PATH để hỗ trợ việc nhận dạng phiên và chẩn đoán. Thông tin điều khiển thêm, ví dụ như độ ưu tiên thiết lập và cầm giữ, các quan hệ (affinity) tài nguyên, bảo vệ cục bộ cũng nằm trong đối tượng này. Yêu cầu thiết lập đường RSVP Hình 3-11: Bản tin PATH Quá trình thiết lập đường được khởi xướng bởi router đầu dòng với bản tin PATH mang các thông tin như sau: Đối tượng Label_Request Đối tượng này được sử dụng để yêu cầu các router trung gian thực hiện hoán đổi nhãn cho phiên. Nó cũng xác định giao thức lớp mạng trên đường đó. Lí do là giao thức lớp mạng được gửi qua LSP không nhất thiết phải là IP và giao thức này cũng không thể được suy luận từ mào đầu lớp 2 vốn chỉ nhận biết giao thức lớp cao hơn như MPLS. Đối tượng này có thể có 3 Class_Types: Loại 1 : yêu cầu nhãn thông thường, là nhãn MPLS 32 bit nằm giữa mào đầu lớp liên kết và lớp mạng. Loại 2 : yêu cầu này đặc tả số lượng tối thiểu các giá trị VPI và VCI được hỗ trợ bởi switch đầu tiên. Loại này được sử dụng khi nhãn MPLS được mang trong mào đầu ATM. Loại 3: loại này đặc tả số lượng tối thiểu các giá trị DLCI được hỗ trợ trên switch đầu tiên. Loại này được sử dụng khi nhãn MPLS được mang trong mào đầu Frame Relay. Khi bản tin PATH đến một LSR, đối tượng Label_Request được lưu giữ trong khối trạng thái đường để sử dụng cho các bản tin làm tươi trong tương lai. Khi bản tin PATH đến đầu nhận, đối tượng này yêu cầu đầu nhận cấp phát nhãn và đặt nhãn đó trong đối tượng Label của bản tin RESV. Nếu nút không thể thực hiện hoán chuyển nhãn nó sẽ gửi lại bản tin PATH_ERR với lỗi “unknown object class”. Nếu đối tượng Label_request không được hỗ trợ end to end, nút gửi sẽ được thông báo bởi nút đầu tiên không cung cấp hỗ trợ này. Đối tượng Explicit_Route (ERO) Đối tượng này được sử dụng để đặc tả một đường rõ ràng đi qua mạng độc lập với đường đặc tả bởi IGP. Nội dung của ERO là 1 chuỗi mục dữ liệu có chiều dài thay đổi gọi là các đối tượng phụ (subobjects). Một đối tượng phụ là 1 nút trừu tượng, có thể là 1 nút hoặc 1 tập hợp nút như 1 miền tự trị. Điều này có nghĩa là đường tường minh có thể đi qua nhiều miền tự trị. Đối tượng phụ này chứa 1 bit L (Loose Route). Nếu bit này được thiết lập bằng 1, nó sẽ xác định đối tượng phụ này là 1 hop lỏng (loose hop) trên đường tường minh. Nếu bit này được thiết lập bằng 0, nó sẽ xác định rằng đối tượng phụ này là 1 hop chặt (strict hop). Một hop chặt xác định hop này kế cận về mặt vật lí với nút trước đó trên đường. Đối tượng phụ này cũng chứa 1 trường Type bao gồm các giá trị sau: 1: tiền tố IPv4, xác định 1 nút trừu tượng với 1 tập hợp tiền tố IP nằm trong tiền tố Ipv4 này.Mỗi tiền tố có độ dài 32 bit là 1 nút đơn. 2: tiền tố Ipv6, xác định 1 nút trừu tượng với 1 tập hợp tiền tố IP nằm trong tiền tố Ipv6 này.Mỗi tiền tố có độ dài 128 bit là 1 nút đơn 32 :số miền tự trị, xác định 1 nút trừu tượng bao gồm 1 tập hợp các nút thuộc về miền tự trị. Ví dụ về strict hop: Trong hình LSR ngõ vào A gửi bản tin PATH đến LSR D với ERO xác định 1 hop chặt qua B(192.213.1.1), C(192.213.2.1) và D(192.213.3.1). Khi B nhận bản tin PATH, nó sẽ quảng bá bản tin này đến C, và C quảng bá bản tin này đến D. Ở chiều ngược lại, D gửi bản tin RESV đến A qua cùng con đường. Mỗi nút trong danh sách ERO sẽ loại bỏ thông tin của nó khỏi bản tin PATH trước khi chuyển tiếp nó đi. Hình 3-12: Ví dụ về hop chặt Ví dụ về loose hop: Trong hình LSR ngõ vào A gửi bản tin PATH đến LSR D với ERO xác định hop chặt đến B. Từ router B hop lỏng được sử dụng. Khi B nhận bản tin PATH nó có thể chuyển tiếp bản tin PATH đến D qua bất kì con đường nào sẵn có. Trong hình ta thấy có 2 con đường đến D, một qua kết nối trực tiếp đến C và 1 đường khác qua router E. Việc chọn đường nào phụ thuộc vào tuyến IGP đến D đang sẵn sàng. Hình 3-13 : Ví dụ về hop lỏng Các LSR trung gian giữa đầu gửi và đầu nhận có thể thay đổi bằng cách chèn các đối tượng phụ. Ví dụ như khi LSR thay đổi 1 tuyến lỏng bằng 1 tuyến chặt buộc lưu lượng đi theo 1 đường cụ thể. Sự hiện diện của các nút lỏng trong tuyến tường minh có thể dẫn đến lặp vòng. Vấn đề này có thể được xác định bởi đối tượng Record_Route (RRO). Đối tượng Record_Route (RRO) RRO được sử dụng để thu thập thông tin tuyến chi tiết, xác định lặp vòng hoặc chẩn đoán. Bằng cách thêm RRO vào bản tin PATH, đầu gửi có thể nhận được thông tin về đường thực sự mà LSP đi trên đó. Con đường cuối cùng được ghi nhận bởi RRO có thể khác với ERO được đặc tả bởi đầu gửi. RRO có thể hiện diện trong cả bản tin PATH và RESV. RRO hiện diện trong bản tin RESV nếu RRO được ghi nhận trong bản tin PATH cần phải được gửi trở về LSR ngõ vào. RRO ban đầu chỉ chứa địa chỉ IP của đầu gửi. Khi các router trung gian nhận bản tin PATH chứa RRO, chúng sẽ lưu trữ 1 bản sao của RRO này trong khối trạng thái đường đồng thời thêm địa chỉ IP của nó vào RRO và chuyển tiếp bản tin PATH đến router tiếp theo. Khi đầu nhận gửi RRO lại cho đầu gửi qua bản tin RESV, RRO mang thông tin tuyến LSP trọn vẹn từ ngõ vào đến ngõ ra. Đối tượng Session_Attribute Đối tượng này cho phép RSVP TE thiết lập các độ ưu tiên, lấn chiếm và các đặc điểm định tuyến nhanh khác nhau. Chúng được sử dụng để chọn các LSP khác khi xảy ra lỗi trong mạng. Đối tượng này bao gồm các trường như độ ưu tiên thiết lập, độ ưu tiên cầm giữ. Các trường này ảnh hưởng đến việc 1 phiên này có thể lấn chiếm hoặc bị lấn chiếm bởi các phiên khác. Trường cờ (flag) được sử dụng với các lựa chọn như các router chuyển tiếp có thể sử dụng các cơ chế cục bộ để can thiệp vào ERO và thực hiện sửa chữa cục bộ. Các cờ khác chỉ ra rằng nút ngõ vào có thể lựa chọn để tái định tuyến mà không cần loại bỏ đường hầm. Các router trung gian trên đường thực hiện điều khiển chấp nhận (admission control) bằng cách xem xét nội dung trong đối tượng Session_Attribute. Nếu nút không thể đáp ứng được yêu cầu nó sẽ gửi lại bản tin PATH_ERR, nếu có thể đáp ứng thì thông tin nút đó sẽ được lưu trong Record_Route. Đối tượng Session Đối tượng này được thêm vào bản tin PATH giúp nhận dạng và chẩn đoán phiên. LSP_TUNNEL_IPv4 C-Type mới chứa địa chỉ IPv4 của nút ngõ vào đường hầm và một chuỗi 16 bit độc nhất tồn tại vĩnh viễn với LSP đó, thậm chí cả khi đường hầm được tái định tuyến. Đáp ứng thiết lập đường RSVP Bản tin RESV được truyền từ LSR ngõ ra ngược trở về LSR ngõ vào khi nhận được bản tin PATH. Bản tin RESV được sử dụng với nhiều chức năng bao gồm : phân phối nhãn, yêu cầu dự trữ tài nguyên dọc theo tuyến và đặc tả kiểu dự trữ (FF hoặc SE). Bản tin RESV chứa các đối tượng như Label, Record_Route, Session và Style. Các đối tượng Session và Record_Route cũng giống như trong bản tin PATH. Đối tượng Label chứa nhãn hoặc chồng nhãn được gửi từ nút xuôi dòng đến nút ngược dòng. Đối tượng Style đặc tả kiểu dự trữ. Khi bản tin RESV đến router đầu dòng, việc thiết lập tuyến LSP đã hoàn thành. Hình 3-14: Bản tin RESV Các kiểu dự trữ tài nguyên Mỗi đường hầm LSP được thiết lập với kiểu dự trữ được lựa chọn độc quyền bởi LSR ngõ ra. Tuy nhiên, LSR ngõ vào có thể chỉ cho LSR ngõ ra biết kiểu dự trữ mà nó yêu cầu bằng cách thiết lập hoặc xóa cờ “SE style desired” trong đối tượng session_attribute của bản tin PATH. Kiểu dự trữ wildcard-filter (WF) không được sử dụng trong định tuyến tường minh vì các luật hợp nhất của nó. Trong kiểu dự trữ này việc dự trữ được chia sẻ bởi tất cả người gửi cho 1 phiên. Tổng băng thông dự trữ trên liên kết không đổi không quan tâm đến đến số lượng người gửi. Kiểu này chỉ được sử dụng cho các ứng dụng mà các sender không gửi lưu lượng tại cùng 1 thời điểm. Nếu các sender gửi cùng lúc thì sẽ không có cách nào để dự trữ băng thông thích hợp. Điều này giới hạn khả năng ứng dụng của WF cho TE. Kiểu fixed-filter (FF) Đặc tả tường minh 1 danh sách các sender và tạo ra dự trữ riêng cho từng sender. Mỗi sender, được nhận dạng bởi 1 địa chỉ IP và 1 LSP ID, được dự trữ băng thông riêng và không chia sẻ với các sender khác. Bởi vì mỗi sender có dự trữ băng thông riêng của nó,1 nhãn duy nhất và 1 đường hầm LSP được tạo ra cho mỗi cặp router vào ra. Trong RSVP TE, kiểu dự trữ FF đa đường hầm LSP điểm-điểm unicast. Nếu các đường hầm LSP đi qua trên cùng 1 liên kết, tổng băng thông dự trữ trên liên kết được chia sẻ là tổng dự trữ của từng router gửi riêng rẽ. FF có thể được ứng dụng với các lưu lượng đồng thời và độc lập bắt nguồn từ các router ngõ vào khác nhau. Hình 3-15 : Kiểu dự trữ fixed - filter Trong hình LSR ngõ vào A và B tạo ra dự trữ kiểu FF hướng đến LSR D. Tổng băng thông dự trữ trên liên kết C-D bằng với tổng băng thông dự trữ được yêu cầu bởi A và B. LSR D gán các nhãn khác nhau trong bản tin RESV hướng đến A và B. Nhãn 10 được gán cho A và nhãn 20 được gán cho B. Điều này tạo ra 2 đường LSP điểm-điểm riêng biệt đó là A-C-D và B-C-D. Kiểu Shared-Explicit (SE): Kiểu này cho phép router nhận lựa chọn dự trữ tài nguyên cho 1 nhóm các router gửi thay vì chỉ dự trữ trên từng router gửi riêng rẽ như trong FF. Dự trữ kiểu SE có thể được cung cấp sử dụng 1 hoặc nhiều LSP đa điểm-điểm mỗi router gửi. Các LSP đa điểm-điểm có thể được sử dụng khi bản tin PATH không mang ERO hoặc khi các bản tin PATH có ERO tương tự nhau. Trong cả 2 trường hợp, nhãn chung được sử dụng. Các bản tin PATH từ các router gửi khác nhau có mang ERO của chính nó và các đường được lựa chọn có thể hội tụ hoặc tách rời tại bất kì điểm nào trong mạng. Khi bản tin PATH có các ERO khác nhau, các LSP riêng rẽ cho các ERO phải được thiết lập Hình 3-16: Kiểu dự trữ Shared - explicit Trong hình LSR A và B sử dụng kiểu SE để thiết lập 1 phiên với LSR D. Dự trữ tài nguyên cho liên kết C-D được chia sẻ giữa A và B. Cả 2 bản tin PATH có cùng ERO và hội tụ tại router C. D cấp phát nhãn 10 trong bản tin RESV vì vậy tạo ra LSP đa điểm-điểm. Quá trình thiết lập đường Hình 3-17: Quá trình báo hiệu thiết lập đường Quá trình thiết lập LSP được khởi xướng bởi router đầu dòng bằng cách gửi đi các bản tin PATH. Bản tin PATH chứa các các đối tượng bao gồm Session để xác định đường hầm. Các yêu cầu lưu lượng cho đường hầm nằm trong Session_Attribute. Label Request trong bản tin được xử lí bởi router cuối dòng, cấp phát nhãn tương ứng cho LSP. Đối tượng Explicit_Route (ERO) là một danh sách các hop trên LSP cần thiết lập có thể được cấu hình tĩnh hoặc qua quá trình tính toán CBR (ở đây R2-1 là giao tiếp ngõ vào trên R2). PHOP và Record_Route (RRO) là địa chỉ giao tiếp ngõ ra của router Khi router R2 nhận được bản tin PATH, nó đặt nội dung của ERO vào khối trạng thái đường (path state) và gỡ bỏ địa chỉ của nó ra khỏi ERO. R2 cũng thay đổi PHOP thành địa chỉ giao tiếp ngõ ra của nó (R2-2) và thêm địa chỉ này vào RRO. Bản tin PATH này tiếp tục được chuyển đến router tiếp theo. Một số chức năng khác cũng được thực hiện tại mỗi nút bao gồm giám sát chấp nhận lưu lượng (admission control). Khi bản tin PATH đến router cuối dòng R3, khối trạng thái đường được tạo ra và địa chỉ của R3 được gỡ bỏ khỏi ERO. RRO lúc này chứa toàn bộ đường đi từ R1. Bản tin RESV được tạo ra. Đối tượng Label_Request trong bản tin PATH yêu cầu R3 cấp phát nhãn cho LSP. Vì R3 là router cuối dòng, nó sẽ không cấp phát nhãn cụ thể mà sẽ sử dụng nhãn implicit-null. Địa chỉ giao tiếp của R3 được đưa vào RRO và PHOP. Bản tin RESV được chuyển tiếp đến địa chỉ hop kế trong khối trạng thái đường của R3. Bản tin RESV được chuyển tiếp trở lại router đầu dòng. Tại mỗi hop, quá trình nhãn được thực hiện (bao gồm cả admission control). Địa chỉ giao tiếp của R2 được thêm vào RRO và đặt vào PHOP. Nhãn có giá trị 5 được cấp phát cho LSP. Bản tin RESV được chuyển tiếp đến hop kế (thông tin này trong khối trạng thái đường). Khi bản tin RESV đến router đầu dòng, quá trình thiết lập LSP kết thúc. Nhãn được cấp phát bởi router hop kế tiếp (R2) được lưu trữ và tuyến tường minh mà đường hầm sẽ đi qua nằm trong RRO. Duy trì đường hầm LSP Giám sát đường Sau khi thiết lập đường, LSP phải được giám sát liên tục để duy trì trung kế lưu lượng mạng ở trạng thái mong muốn. Các thuộc tính QoS phải được chú ý trong quá trình thiết lập đường và được giám sát để hỗ trợ tái tối ưu hóa. Các phương pháp chẩn đoán khác nhau được thực hiện trên các đường LSP và nếu cần thiết các đường hầm sẽ bị lấn chiếm theo việc điều khiển chính sách quản trị hoặc tái định tuyến động trong trường hợp cấu trúc mạng thay đổi. Các đường hầm cũng được giám sát trong trường hợp có sự thay đổi băng thông sẵn có. Tái định tuyến, tái tối ưu hóa LSP phải được tái định tuyến khi xảy ra lỗi hoặc có sự thay đổi tài nguyên. Khi tài nguyên ở các phần khác của mạng sẵn sàng, các trung kế lưu lượng có thể được tái tối ưu hóa. Tại các thời điểm nào đó việc kiểm tra các đường tối ưu nhất cho đường hầm LSP được thực hiện và nếu đường hiện tại không phải là đường tối ưu nhất quá trình tái định tuyến được khởi xướng. Router đầu dòng cố gắng báo hiệu một đường LSP tốt hơn và chỉ sau khi thiết lập thành công đường LSP mới thì lưu lượng mới được chuyển sang đường mới. Lỗi liên kết Khi một liên kết mang trung kế lưu lượng bị lỗi, router đầu dòng xác định lỗi đó bởi các cách thức sau: IGP gửi một gói trạng thái liên kết mới với thông tin về sự thay đổi đã xảy ra. RSVP cảnh báo bằng cách gửi bản tin PATH_TEAR cho router đầu dòng. Xác định lỗi khi không có đường được thiết lập hoặc tính toán trước sẽ đẫn đến quá trình tính toán đường LSP mới. Khi router dọc theo tuyến LSP động xác định lỗi nó sẽ gửi đi bản tin PATH_TEAR cho headend. Bản tin này báo hiệu cho headend biết đường hầm đã down. Headend xóa phiên RSVP bắt đầu tính toán đường mới (PCALC) sử dụng thuật toán CSPF. Kết quả của quá trình tính toán này có thể là: Không có đường nào được tìm thấy. Headend thiết lập đường hầm down. Tìm thấy một đường khác. Quá trình thiết lập đường mới được khởi động bởi báo hiệu RSVP. Các bảng phụ cận (adjacency) được cập nhật cho giao tiếp đường hầm. Bảng CEF được cập nhật cho tất cả các chỉ mục resolve giao tiếp đường hầm. Khoảng thời gian trôi qua từ khi xác định lỗi đến khi thiết lập đường LSP mới có thể gây ra trễ cho các lưu lượng quan trọng. Do đó người ta sử dụng 1 đường dự phòng đã được thiết lập trước. Khi đó sẽ có 2 đường hầm cùng đi đến 1 đích. Ngay khi đường hầm chính hỏng toàn bộ lưu lượng sẽ được chuyển qua đường dự phòng. Lưu lượng sẽ trở lại đường hầm chính khi có các điều kiện cho việc thiết lập lại. Khi có sự hiện diện của 2 đường hầm, có 2 tùy chọn định tuyến: Định tuyến tĩnh với 2 tuyến tĩnh chỉ đến các đường hầm. Định tuyến động (autoroute). Trong trường hợp này metric của đường hầm là phí tổn IGP đến điểm cuối đường hầm, không quan tâm đến con đường thực sự. Bằng cách điều chỉnh metric này đường hầm chính có thể được ưu đãi hơn. Việc điều chỉnh metric này có thể là: Tuyệt đối (gán giá trị metric dương cho các đường hầm) Tương đối (giá trị metric IGP có thể là dương, âm hay bằng 0. Ví dụ giả sử metric nhỏ sẽ tốt hơn ta có primary: -1(metric của đường hầm giảm đi 1), secondary: 0 (giá trị metric không đổi). Tái tối ưu hóa, tái định tuyến không phá vỡ (non-disruptive) Quá trình tái định tuyến không phá vỡ được minh họa trong hình vẽ. Đối tượng Explicit_Route liệt kê các hop trên LSP R1-R2-R6-R7-R4-R9 với R1 là điểm đầu và R9 là điểm cuối trung kế. Băng thông sẵn có trên liên kết R2-R3 thay đổi dẫn đến quá trình tái tối ưu hóa. Con đường mới R1-R2-R3-R4-R9 được báo hiệu và 1 phần đường này chồng lấp lên con đường cũ. LSP hiện thời vẫn được sử dụng. Trên các liên kết chung cho LSP cũ và mới, tài nguyên được sử dụng bởi LSP cũ sẽ không được giải phóng cho đến khi luu lượng được chuyển sang LSP mới và dự trữ băng thông cũng không tăng gấp đôi. Sau khi LSP mới được thiết lập thành công, luu lượng được tái định tuyến đến con đường mới và tài nguyên dự trữ trên con đường cũ sẽ được giải phóng. Việc giải phóng này được thực hiện khi bởi router cuối dòng bằng cách thiết lập bản tin PATH_TEAR Hình 3-18: Tái định tuyến không phá vỡ Khởi tạo trước khi phá vở (Make before break) Nhược điểm của việc cấu hình 2 đường hầm và băng thông tăng gấp đôi có thể được khắc phục bằng cách dự trữ băng thông trên cùng liên kết. Các cơ chế tái tối ưu hóa này được thực hiện trong suốt quá trình tái tối ưu hóa đường hoặc khi cố gắng tăng băng thông đường hầm. Trong bản tin PATH đầu tiên, nút đầu vào hình thành đối tượng session và sender_template với cờ “shared explicit” được thiết lập. Quá trình thiết lập đường hầm sau đó diễn ra theo trình tự bình thường. Khi nhận bản tin PATH nút ngõ ra gửi lại bản tin RESV cho nút ngõ vào trong đó chỉ ra đường “shared explicit”. Khi nút ngõ vào muốn thay đổi đường đã được thiết lập, nó tạo bản tin PATH mới. Đối tượng session đang tồn tại với 1 LSP_ID mới trong đối tượng Sender_template. Nút ngõ vào tạo ERO cho tuyến mới. Bản tin PATH mới được gửi đi. Các router khi nhận bản tin PATH nhận ra việc dự trữ lần thứ 2 (dựa trên LSP_ID) này thuộc về cùng 1 phiên và chỉ dự trữ băng thông cho 1 phiên. Hình 3-19: Make before break Bảo vệ liên kết và bảo vệ tuyến Để tăng tốc quá trình tái định tuyến hoặc tái tối ưu hóa đường trong khi headend tính toán đường mới, tùy chọn Fast Reroute được sử dụng. Chuyển mạch bảo vệ MPLS triển khai đường LSP thứ cấp được thiết lập trước để dự phòng cho LSP chính đang tồn tại bằng cách bỏ qua các nút hoặc liên kết lỗi. Bằng cách này, thời gian cần để chuyển hướng lưu lượng sang đường dự phòng không bao gồm hoạt động tính toán hoặc trễ do báo hiệu. Khi xảy ra lỗi liên kết hoặc lỗi nút trên LSP chính mà không có LSP dự phòng, LSR ngõ vào sẽ tiếp tục chuyển tiếp lưu lượng đến đích như là gói IP sử dụng đường ngắn nhất theo IGP nếu đường đó tồn tại. Các loại bảo vệ trong MPLS TE bao gồm: Bảo vệ nút : mục đích của bảo vệ nút là để bảo vệ LSP khi xảy ra lỗi nút. Trong bảo vệ nút, đường LSP dự phòng tách rời khỏi khỏi LSP chính tại các nút cụ thể được bảo vệ. Khi nút bị lỗi, lưu lượng trên đường LSP chính sẽ được chuyển sang đường LSP dự phòng tại nút upstream kết nối trực tiếp với nút bị lỗi. Bảo vệ đường : bảo vệ LSP khi xảy ra lỗi tại bất kì điểm nào trên đường đã được định tuyến. Trong bảo vệ đường LSP dự phòng tách rời hoàn toàn khỏi đường LSP chính. Ưu điểm của bảo vệ đường là LSP dự phòng có thể bảo vệ tất cả các lỗi xảy ra trên LSP chính ngoại trừ điểm đầu và cuối đường. Bảo vệ đường hiệu quả hơn bảo vệ nút và bảo vệ liên kết ở khía cạnh sử dụng tài nguyên. Tuy nhiên, thời gian chuyển sang đường dự phòng của bảo vệ nút và liên kết nhanh hơn đáng kể so với bảo vệ đường khi phải mất nhiều thời gian hơn để thông báo lỗi cho các nút ở xa vị trí lỗi. Bảo vệ liên kết : mục đích của bảo vệ liên kết LSP là để bảo vệ 1 LSP khỏi lỗi liên kết cụ thể. Đường LSP dự phòng tách rời khỏi đường LSP chính tại các liên kết yêu cầu bảo vệ. Khi liên kết được bảo vệ hỏng, lưu lượng trên LSP chính sẽ được chuyển sang LSP dự phòng tại điểm đầu của liên kết lỗi. Bảo vệ liên kết Khi liên kết được bảo vệ hỏng, bản tin PATH_ERR và các cơ chế trạng thái liên kết IGP được sử dụng để thông báo cho headend. Một cờ đặc biệt trong bản tin PATH_ERR liên kết hỏng có 1 đường dự phòng. Hình 3-20: Bảo vệ liên kết Tái định tuyến với đường hầm được cấu hình trước hầu như rất nhanh. Quá trình chỉ diễn ra trong khoảng 50ms và độ trễ chỉ là thời gian xác định liên kết lỗi và chuyển mạch sang đường dự phòng (bao gồm cả việc xử lí nhãn). Khi liên kết R2-R4 bị lỗi lưu lượng sẽ được tái định tuyến sang đường hầm dự phòng NHOP R2-R3-R4 Bảo vệ nút Trong bảo vệ nút, LSP dự phòng bỏ qua nút next-hop trên đường LSP chính. Các đường LSP dự phòng này thường được gọi chung là đường hầm dự phòng next-next-hop (NNHOP) vì chúng kết cuối tại nút theo sau nút next- hop trên đường LSP chính. Khi xảy ra lỗi, đường hầm dự phòng NNHOP nút trước nút bị lỗi tái định tuyến lưu lượng trên đường LSP chính sang NNHOP vì vậy bỏ qua nút next-hop bị lỗi. Đường hầm dự phòng NNHOP cũng cung cấp bảo vệ liên kết bởi vì chúng bỏ qua các liên kết bị lỗi đi cùng với nút đó. Hình 3-21 : Bảo vệ nút Bảo vệ băng thông Các đường hầm dự phòng NHOP và NNHOP cũng có thể thực hiện bảo vệ băng thông bằng cách kết hợp băng thông dự phòng với các đường hầm này. Bảo vệ băng thông đảm bảo rằng đường dự phòng cụ thể có dung lượng đủ để đáp ứng yêu cầu băng thông của LSP được tái định tuyến. Đường hầm dự phòng này có thể được cấu hình để bảo vệ 2 loại băng thông dự phòng sau: Băng thông dự phòng giới hạn: đường hầm dự phòng cung cấp bảo vệ băng thông mà trong đó băng thông yêu cầu được đảm bảo. Vì vậy, băng thông dự phòng đầy đủ sẵn sàng khi tái định tuyến đến đường hầm dự phòng loại này, và toàn bộ băng thông của các LSP sử đụng đường hầm dự phòng này không được vượt quá băng thông dự phòng của đường hầm dự phòng. Băng thông dự phòng không giới hạn: đường hầm dự phòng không cung cấp bảo vệ băng thông. Trong trường hợp này chỉ có bảo vệ best-effort, vì vậy không có giới hạn số lượng băng thông được sử dụng bởi các LSP ánh xạ đến các đường hầm này. Các LSP không yêu cầu dự trữ băng thông trong quá trình thiết lập tuyến chỉ có thể sử dụng các đường hầm dự phòng với băng thông dự phòng không giới hạn. Các lựa chọn bảo vệ cục bộ LSR đầu tiên của đường hầm dự phòng NHOP hoặc NNHOP được gọi là điểm sửa chữa cục bộ (PLR). Khi lỗi xảy ra trên LSP chính, PLR sửa chữa LSP bị hỏng bằng cách hướng lưu lượng đi qua liên kết hoặc nút bị lỗi đến các đường hầm dự phòng NHOP hoặc NNHOP. PLR có thể triển khai các đường hầm dự phòng NHOP hoặc NNHOP theo 2 cách: Dự phòng one-to-one : một đường hầm dự phòng được tạo ra chỉ để bảo vệ cho 1 đường LSP chính tại 1 PLR. Các đường hầm dự phòng này được gọi là đường hầm detour. Dự phòng facility : một đường hầm dự phòng được tạo ra để bảo vệ cho 1 hoặc nhiều đường LSP chính đi qua PLR và 1 LSR xuôi dòng có khả năng xảy ra lỗi. Các đường hầm dự phòng facility còn được gọi là đường hầm bypass. Để bảo vệ đầy đủ cho LSP chính, mỗi nút hoặc liên kết trên LSP chính phải được bảo vệ bằng các đường hầm bypass hoặc detour. Như vậy, nếu ta có N nút trên LSP chính thì cần phải có N-1 đường hầm bảo vệ. Tuy nhiên, đường hầm detour chỉ có khả năng bảo vệ cho 1 LSP chính cụ thể trong khi đường hầm bypass có khả năng bảo vệ 1 nhóm các LSP chính cùng đi qua 1 liên kết hoặc đường chung. Hình 3-22 : Đường hầm bypass và detour Dự phòng one- to-one : Với mỗi LSP được bảo vệ với kĩ thuật one-to-one, 1 đường hầm detour được thiết lập. Trong ví dụ hình , LSP chính đi từ R21 đến R25. R22 (PLR) thực hiện bảo vệ lưu lượng bằng cách tạo ra 1 đường hầm detour hợp nhất với LSP chính tại R24. R24 được gọi là điểm hợp nhất (MP-merge point). MP chịu trách nhiệm ánh xạ nhãn ngõ vào của LSP chính và đường hầm dự phòng detour thành 1 nhãn ngõ ra duy nhất để giảm số lượng LSP trong miền MPLS. Đường hầm detour chỉ sử dụng 1 nhãn đơn. Khi xảy ra lỗi tại R23 trên LSP chính, R22 sẽ chuyển lưu lượng đi trên LSP chính sang đường hầm detour bằng hoán đổi nhãn 22 bằng nhãn 57 để gói tin đi đến R26 thay vì nhãn 23 để đến R23. Khi gói tin đến R24 (MP) với nhãn 55 thì nhãn này sẽ được hoán đổi với 25 để tiếp tục đi trên LSP chính. Hình 3-23: Dự phòng one-to-one Dự phòng facility : Trong kĩ thuật này, một đường hầm bypass đơn được sử dụng để bảo vệ cho một nhóm các LSP chính. Kĩ thuật này sử dụng chồng nhãn MPLS. Trong hình 3-24 R32 hình thành 1 đường hầm bypass để bảo vệ cho lỗi liên kết R32-R34. Đường hầm này cũng có thể bảo vệ cho bất kì đường hầm nào đi qua liên kết R32-R34 giúp cải thiện khả năng mở rộng. Khi xảy ra lỗi trên LSP chính, PLR sử dụng chồng nhãn để hướng lưu lượng đi trên đường hầm dự phòng thích hợp. Gói IP chuyển tiếp đến R35 sử dụng chồng nhãn 2 mức: nhãn trên cùng là nhãn của đường hầm dự phòng và nhãn ở dưới là nhãn của LSP chính (của MP). Hình 3-24:Bảo vệ liên kết với dự phòng facility Ví dụ trên cho thấy quá trình bảo vệ liên kết giữa R32 và R34. Trung kế lưu lượng giữa R31 và R35 đi qua liên kết này khi liên kết hoạt động và cung cấp băng thông yêu cầu. Đường hầm dự phòng giữa R32 và R34 là R32-R36-R37-R34 và sử dụng tất cả các cơ chế của MPLS TE (cấp phát nhãn, dự trữ băng thông). Đường hầm này được sử dụng khi liên kết R32-R34 hỏng. Lúc này chồng nhãn được sử dụng, tại R32 chồng nhãn bao gồm nhãn của LSP chính (34) và nhãn của LSP bảo vệ (36). Khi gói tin đến R36, nó sẽ hoán đổi nhãn 36 thành 37 và chuyển gói tin đến R37. R37 gỡ bỏ nhãn 37 và chuyển gói tin đến R34. R34 lúc này nhận được gói tin có nhãn 34 như bình thường khi không có lỗi và sẽ chuyển tiếp gói tin này đến router kế tiếp trên LSP chính. Hình 3-25: Bảo vệ nút dự phòng facility Với kĩ thuật này, trường hợp bảo vệ nút phức tạp hơn bảo vệ liên kết. Trong trường hợp này R32 cần biết nhãn được sử dụng trên liên kết R33-R34 vì R34 mong nhận được nhãn này qua đường dự phòng khi R33 bị lỗi. Đối tượng Record_Route được bổ sung cho phép R32 học nhãn này khi cờ “label recording desired” trong đối tượng Session_Attribute được thiết lập. Vì vậy, các LSR trên đường này sẽ chèn vào đối tượng Record_Route thông tin giá trị nhãn và địa chỉ IP tương ứng. RRO được tổ chức theo dạng LIFO. R32 có thể kiểm tra bản tin RESV và học tất cả các ngõ vào được sử dụng bởi các LSR xuôi dòng của LSP này. Bảo vệ đường Bảo vệ đường hỗ trợ cấu hình 2 đường vật lí sơ cấp và thứ cấp cho một LSP để bảo vệ khi xảy ra lỗi liên kết hoặc lỗi nút. Quá trình này được gọi là sửa chữa toàn cục. Đường thứ cấp được sử dụng chỉ khi xảy ra lỗi trên đường sơ cấp. Có 2 loại đường thứ cấp : dự phòng nóng (hot standby) và dự phòng lạnh (cold standby). Đường dự phòng nóng được tính toán và thiết lập trước trong khi đường dự phòng lạnh được tính toán trước nhưng không được thiết lập trước. Khi xảy ra lỗi liên kết hoặc lỗi nút, LSR ngõ vào sẽ được thông báo bởi LSR ngay trước điểm lỗi bằng RSVP TE. LSR ngõ vào ngay lập tức tái định tuyến lưu lượng từ đường sơ cấp sang đường thứ cấp. Việc sử dụng đường sơ cấp dự phòng nóng cho phép cải thiện thời gian hồi phục do không phải mất thời gian trong việc thiết lập LSP mới. Tuy nhiên nó lại lãng phí băng thông hơn so với dự phòng lạnh. Khi đường sơ cấp hoạt động trở lại, LSR ngõ vào sẽ tự động chuyển lưu lượng từ đường hầm thứ cấp trở lại đường sơ cấp. Lợi ích của đường hầm dự phòng là rõ ràng tuy nhiên giải pháp này cũng có những nhược điểm: · Đường dự phòng cũng yêu cầu các cơ chế như là đường chính, bao gồm cả cấp phát nhãn và dự trữ băng thông. · Nhìn từ khía cạnh RSVP băng thông dự trữ tăng gấp đôi. · Thời gian hồi phục tùy thuộc khoảng cách giữa vị trí lỗi và LSR ngõ vào. Hình 3-26: Bảo vệ đường Ví dụ trong hình cho thấy 2 đường hầm được cấu hình trước. LSP1 (R1-R2-R6) là đường hầm chính và LSP2 (R1-R3-R4-R5-R6) là đường hầm dự phòng. Đường vật lí của chúng là khác nhau. Trạng thái RESV khi tái định tuyến Hình 3-27: Trạng thái RESV khi tái định tuyến Trạng thái RESV không nên bị ảnh hưởng bởi Fast Reroute. Các bản tin PATH, RESV vẫn đi qua liên kết lỗi theo logic. PHOP của bản tin RESV qua R4 về R1 không thay đổi và vẫn là địa chỉ của R2. R2 biết rằng bản tin này đến qua giao tiếp khác do lỗi liên kết. Vì R6 và R7 không được nhìn thấy trong bản tin PATH, chúng có thể gặp vấn đề khi xử lí bản tin RESV đi ngược trở lại. Để khắc phục vấn đề, R4 gửi bản tin RESV trực tiếp tới địa chỉ unicast của R2. Gán lưu lượng cho trung kế lưu lượng Thay đổi luồng lưu lượng với định tuyến tĩnh và định tuyến policy LSP được tính toán bởi định tuyến ràng buộc (CBR). Khi LSP được thiết lập cho trung kế, luồng lưu lượng có thể đi qua nó. Từ khía cạnh IP, LSP là đường hầm đơn giản. Các đường hầm này chỉ được sử dụng cho định tuyến IP khi chúng được đặc tả tường minh cho định tuyến: Qua các tuyến tĩnh chỉ đến đường hầm. Qua định tuyến policy thiết lập giao tiếp hop kế đến đường hầm. Autoroute Autoroute được giới thiệu để khắc phục các vấn đề của định tuyến tĩnh trên các đường hầm MPLS-TE. Nó cho phép các router đầu dòng nhìn thấy các đường hầm như là các giao tiếp được kết nối trực tiếp và sử dụng nó trong các tính toán modified SPF. Các đường hầm MPLS-TE chỉ được sử dụng để tính toán tuyến IGP thông thường chứ không được sử dụng trong việc tính toán ràng buộc. Tất cả các đích nằm sau điểm cuối của trung kế lưu lượng đều có thể thấy được với autoroute thay vì chỉ có các đích được cấu hình tĩnh là có thể thấy được như trong định tuyến tĩnh. Autoroute chỉ ảnh hưởng đến các headend router chứ không ảnh hưởng đến các router trung gian, các router này vẫn sử dụng định tuyến IGP thông thường. Vì các đường hầm này được sử dụng trong các tính toán SPF nên metric của nó đóng vai trò rất quan trọng. Phí tổn của đường hầm phải bằng với metric IGP tốt nhất đến điểm cuối đường hầm không quan tâm đến đường LSP. Khi thiết lập các con đường tốt nhất đến đích, metric của đường hầm được so sánh với các metric của các đường hầm đang tồn tại và các metric IGP. Metric thấp hơn thì tốt hơn và nếu các đường hầm MPLS-TE có giá trị metric bằng hoặc nhỏ hơn IGP metric, nó sẽ được chọn là chặng kế tiếp đến đích. Nếu có hơn một đường hầm có giá trị metric bằng nhau và nhỏ nhất chúng sẽ được đặt trong bảng định tuyến để cung cấp thêm khả năng cân bằng tải (load balancing). Load balancing được thực hiện tỉ lệ với băng thông đã được cấu hình. Ví dụ về Autoroute Hình 3-28: Autoroute Trong hình vẽ ta thấy có 1 đường hầm MPLS TE được cấu hình giữa A và G. Đường hầm chỉ được nhìn thấy bởi router đầu dòng A. Các router trung gian không nhìn thấy đường hầm này cũng như không quan tâm‎ đến nó trong quá trình tính toán tuyến. Mặc dù LSP đi theo đường A-B-E-F-G, phí tổn của đường hầm là giá trị metric IGP tốt nhất đến điểm cuối đường hầm. Metric của liên kết F-G là 100. Tất cả các liên kết khác đều có metric là 10. Mặc dù LSP đi qua liên kết F-G, phí tổn của đường hầm chỉ là 40 (tổng metric tốt nhất của đường IGP tốt nhất A-B-C-D-G). Trong bảng định tuyến, tất cả các mạng đằng sau điểm cuối đường hầm (mạng 2/8 và 4/8) có thể đến được thông qua đường hầm vì metric của đường hầm MPLS TE bằng với metric IGP nguyên thủy. Nó được cài đặt như là hop kế tiếp đến các đích tương ứng. Đây chính là đặc điểm của autoroute. Cân bằng tải (Load balancing) Cân bằng tải phí tổn ngang nhau (Equal-cost load balancing) Chia tải có thể được thực hiện dựa trên địa chỉ nguồn và địa chỉ đích (per-scr-des-load sharing) hoặc dựa trên từng gói. Khi thực hiện chia tải dựa trên địa chỉ nguồn và địa chỉ đích, gói nằm dưới chồng nhãn sẽ được kiểm tra. Nếu dữ liệu đó là của gói IP, router sẽ thực hiện chia tải giống như gói IP thông thường. Nếu không việc chia tải sẽ được thực hiện dựa vào nhãn dưới cùng trong chồng nhãn. Chia tải dựa trên từng gói gửi tất cả các gói theo dạng luân chuyển đến các hop kế khác nhau để đến đích mà không quan tâm đến nội dung của gói. Điều này có thể làm thay đổi thứ tự các gói tin. Trong phần trước, với đặc điểm Autoroute đường hầm TE có thể được sử dụng như là hop kế tiếp khi xác định phí tổn của con đường ngắn nhất đến cuối đường hầm. Phương pháp này có 2 lựa chọn: Không chia tải giữa một tuyến IGP và một tuyến TE đến điểm cuối đường hầm Chia tải giữa một tuyến IGP và một tuyến TE đến các nút nằm sau điểm cuối đường hầm. Chia tải đến điểm cuối đường hầm Hình 3-29: Chia tải đến cuối đường hầm Nếu ta thực hiện chia tải giữa 1 tuyến TE và 1 tuyến IGP thì sẽ làm mất khả năng định tuyến tường minh lưu lượng theo con đường không phải là tối ưu nhất. Giả sử ta có 1 đường hầm TE giữa router A và C. Theo mặc định đường hầm này có phí tổn bằng với phí tổn IGP là 30. Nếu ta không loại bỏ các con đường khác để ưu tiên đường hầm TE, việc chia tải được thực hiện theo những con đường này, do đó ta không thể điều khiển lưu lượng theo cách mà ta muốn. Ta có thể chia tải theo đường A-C và đường hầm TE (khi đó 50% lưu lượng sẽ đi theo đường hầm TE) hoặc chia tải giữa 3 đường : A-C, A-B-C và đường hầm TE (khi đó 33% lưu lượng sẽ đi theo đường hầm). Cả 2 cách này ta đều không mong muốn vì sẽ rất khó để điều khiển lưu lượng trong mạng nếu không thể kiểm soát hoàn toàn các lưu lượng trong mạng. Tuy nhiên nếu muốn đưa lưu lượng theo 2 đường A-C và A-B-C ta có thể xây dựng 2 đường hầm qua chúng và chia tải trên 2 đường hầm đó. Chia tải đến các nút nằm sau điểm cuối đường hầm Tuy ta không bao giờ chia tải giữa 1 đường IGP và 1 đường hầm TE đến điểm cuối đường hầm nhưng ta có thể chia tải giữa chúng để đến các đích nằm sau điểm cuối đường hầm. Nếu có nhiều đường đến nút đích và nút này không phải là nút cuối đường hầm thì các đường này sẽ được chia tải đến giới hạn đường tối đa của IGP. Hình 3-30: Chia tải đến các đích sau đường hầm Chia tải không ngang bằng (Unequal cost sharing) Định tuyến IP thông thường thực hiện chia tải ngang bằng (equal-cost). Nếu có nhiều hơn 1 con đường giữa 2 nút và các đường này có phí tổn bằng nhau thì lưu lượng sẽ được chia bằng nhau trên các đường này. Các giao thức hiện tại có thể hỗ trợ tối đa 8 đường song song. Tuy nhiên, chia tải ngang bằng (equal-cost) không được linh hoạt. Nếu ta cố gắng cân bằng lưu lượng trong mạng bằng cách thay đổi phí tổn liên kết thì điều này thật không dễ dàng. Thay đổi phí tổn liên kết ở 1 phần của mạng có thể ảnh hưởng đến luu lượng ở các phần khác mà ta không thể dự đoán trước được. Hình 3-31: Chia tải phí tổn không ngang bằng Chia tải phí tổn không cân bằng trong IP cũng có vấn đề về lặp vòng. Vì router A không thông báo cho router B biết phải làm gì đối với lưu lượng đến từ A, và B có thể chuyển 1 phần lưu lượng này trở về A. Tuy nhiên, vấn đề này có thể được giải quyết trong MPLS TE. Nếu có 1 nhãn được gán cho gói IP đi từ A đến B và nhãn này tạo ra trong quá trình thiết lập LSP từ A đến C thì nó sẽ được B chuyển tiếp cho C mà không thực hiện tìm kiếm địa chỉ IP. Hoạt động của chia tải phí tổn không cân bằng bao gồm 2 phần: Thiết lập tỉ lệ chia tải. Cài đặt các tỉ lệ này trong bảng FIB. Tổng kết chương Các giao thức định tuyến đưa lưu lượng qua mạng theo con đường ngắn nhất mà không quan tâm đến các tham số khác dẫn đến việc sử dụng không hiệu quả băng thông sẵn có trong mạng. Kĩ thuật lưu lượng được triển khai cho phép quản lí và sử dụng băng thông tốt hơn, giải quyết tạm thời vấn đề tắc nghẽn trong mạng backbone. Một ưu điểm nữa là khả năng hồi phục nhanh, giúp giảm thiểu tỉ lệ mất gói khi xảy ra lỗi trên các liên kết hoặc các nút chuyển mạch nhãn. CHƯƠNG 4 : MÔ PHỎNG KỸ THUẬT LƯU LƯỢNG TRONG MPLS Giới thiệu công cụ mô phỏng GNS3 là 1 phần mềm giả lập mạng có giao diện đồ họa cho phép ta có thể dễ dàng thiết kế các mô hình mạng và sau đó chạy giả lập trên chúng. Tại thời điểm hiện tại GNS3 hỗ trợ giả lập các router Cisco, ATM/Frame relay/Ethernet Switch. GNS3 dựa trên dynamips và 1 phần của dynagen. Dynamips là 1 trình mô phỏng được viết bởi Christophe Fillot. Nó mô phỏng các dòng router của Cisco bao gồm 1700, 2600, 3600 và 7200 và sử dụng các IOS image chuẩn của thiết bị thực. Các tính năng được hỗ trợ trên router tùy thuộc vào các IOS image này. Dynagen là 1 giao tiếp dựa trên nền văn bản dành cho Dynamips, GNS tích hợp trình quản lí CLI của Dynagen cho phép người dùng liệt kê các thiết bị, tạm ngưng và nạp lại các thể hiện , xác định và quản lí các giá trị idlePC, bắt các gói tin. Hình 4-1 : Giao diện phần mềm GNS3 GNS3 chạy trên Windows, Linux và Mac OSX. Gói cài ñặt của phần mềm này có thể được download tại địa chỉ Nó cung cấp mọi thứ cần thiết để chạy được GNS3 trên máy tính ngoại trừ IOS của router thật. IOS này không được cung cấp rộng rãi bởi Cisco tuy nhiên ta có thể được download từ nhiều nguồn khác nhau trên Internet Nội dung và kết quả mô phỏng Cấu hình và kiểm tra các yếu tố ảnh hưởng đến quá trình lựa chọn đường trong kỹ thuật lưu lượng MPLS Các yếu tố ảnh hưởng dến việc chọn đường bao gồm: Băng thông sẵn có TE metric Affinity bit (Attribute Flag) Vấn đề lấn chiếm. Ta sẽ lần lượt thay đổi các yếu tố này lên quá trình tính toán đường ràng buộc. Mô hình mạng Trong phần này ta sẽ sử dụng 1 mô hình bao gồm 5 router R0, R1, R2, R3, R4 kết nối với nhau như trong hình minh họa. Hình 4-2: Mô hình mạng sử dụng trong phần 1 Trong mô hình trên Router R0 gồm: Cổng Loopback0 có địa chỉ IP là 10.10.10.101 Cổng GigaEthernet g1/0 địa chỉ IP 10.10.10.9 Cổng GigaEthernet g2/0 địa chỉ IP 10.10.10.1 Cổng GigaEthernet g3/0 địa chỉ IP 10.10.10.17 Router R1 gồm: Cổng Loopback0 có địa chỉ IP 10.10.10.104 Cổng GigaEthernet g1/0 địa chỉ IP 10.10.10.10 Cổng GigaEthernet g2/0 địa chỉ IP 10.10.10.13 Router R2 gồm: Cổng Loopback0 có địa chỉ IP 10.10.10.102 Cổng GigaEthernet g1/0 địa chỉ IP 10.10.10.2 Cổng GigaEthernet g2/0 địa chỉ IP 10.10.10.5 Cổng GigaEthernet g3/0 địa chỉ IP 10.10.10.26 Router R3 gồm Cổng Loopback0 có địa chỉ IP 10.10.10.106 Cổng GigaEthernet g1/0 địa chỉ IP 10.10.10.18 Cổng GigaEthernet g2/0 địa chỉ IP 10.10.10.21 Cổng GigaEthernet g3/0 địa chỉ IP 10.10.10.25 Router R4 gồm Cổng Loopback0 có địa chỉ IP 10.10.10.104 Cổng GigaEthernet g1/0 địa chỉ IP 10.10.10.14 Cổng GigaEthernet g2/0 địa chỉ IP 10.10.10.6 Cổng GigaEthernet g3/0 địa chỉ IP 10.10.10.22 Các bước thực hiện và kết quả Ta sẽ xem xét ảnh hưởng của các yếu tố đến quá trình lựa chọn đường từ R0 đến R4 bắt đầu tại R0 Khi chưa thiết lập đường hầm mà chỉ chạy giao thức định tuyến OSPF, kết quả của quá trình lựa chọn đường đến các đích hiển thị tại R0 như sau: R0# Show ip route Hình 4-3: Kết quả chọn đường tại R0 Ảnh hưởng của TE metric Ban đầu đường hầm được thiết lập đi từ R0 đến R4 có thể đi qua 1 trong 3 đường như trong topology của R0 ở hình trên (do các giao tiếp và liên kết ở đây có tính chất như nhau) Sau đó ta cấu hình thay đổi giá trị TE metric trên các liên kết R0-R1 thành 2 và R0-R2 là 3. Kết quả của quá trình lựa chọn đường cho đường hầm như sau: R0# show mpls traffic-eng tunnels tunnel 0 Hình 4-4 : Các thông tin của tunnel 0 Dựa vào kết quả thu được từ bảng ta thấy rằng khi thay đổi giá trị TE metric thì R0 đã chọn đường hầm qua cổng g3/0. Nhận xét Nếu chỉ xét đến TE metric trong quá trình tính toán đường, đường đi của tunnel 0 sau khi thiết lập là R0-R3-R4 với metric là 2 (trong bài mô phỏng này sử dụng liên kết GigaEthernet do đó metric trên mỗi liên kết mặc định là 1). Đây chính là giá trị metric thấp nhất so với 2 đường còn lại R0-R1-R4 có metric là 3 và R0-R2-R4 có metric là 4. TE metric có thể được sử dụng để đại diện cho độ trễ liên kết và cấu hình các đường hầm mang lưu lượng thoại trong khi IGP metric được sử dụng trong cấu hình các đường hầm mang dữ liệu. Ảnh hưởng của băng thông sẵn có trên các liên kết Tiếp theo ta sẽ cấu hình tunnel 1 trên R0 sử dụng IGP metric để tính toán đường nhằm có được 1 kết quả độc lập vì ở trên ta đã thay đổi TE metric nên bất kì đường hầm nào khi được thiết lập động cũng sử dụng đường đi như tunnel 0 . Kết quả cấu hình như sau: R0# show mpls traffic-eng tunnels tunnel 1 Hình 4-5:Các thông tin của tunnel 1 Lúc này đường hầm Tunnel 1 tại R0 chọn ngẫu nhiên g1/0 làm đường đi vì lúc này R0 sử dụng IGP metric mặc định nên các đường tới đích R4 bằng nhau Tiếp theo ta sẽ thay đổi băng thông sẵn có trên liên kết R2-R4 và R1-R4 sao cho nó nhỏ hơn tất cả các liên kết khác (trong bài mô phỏng này thay đổi từ 750 Mbps, là giá trị mặc định trên liên kết GigaEthernet có tốc độ 1Gbps thành 600 Mbps). Kết quả như sau: R0# show mpls traffic-eng tunnels tunnel 1 Hình 4-6: Kết quả của tunnel 1 với ảnh hưởng của băng thông dự trữ Kết quả là tunnel 1 trên R0 sẽ chọn đường đi qua cổng g3/0 tới R3-R4 là con đường có băng thông dự trữ lớn nhất. Nhận xét Quá trình cấu hình thay đổi băng thông sẵn có này chỉ là 1 cách thực hiện (thay vì phải cấu hình thêm các đường hầm khác đi qua các liên kết nêu trên và chiếm 1 phần băng thông sẵn có trên liên kết) để thấy rằng đường hầm sẽ lựa chọn đường mà các liên kết có băng thông sẵn có lớn hơn. Qua đó ta có thể thấy rằng kỹ thuật lưu lượng MPLS có xu hướng sử dụng hết tất cả các đường có thể để đến đích hay nói cách khác là nó trải lưu lượng trên toàn bộ mạng thay vì chỉ tập trung trên đường có metric nhỏ nhất. Ảnh hưởng của affinity bit (Attribute Flag) Sau đó ta tiếp tục cấu hình Affinity bit trên tunnel 1 là 0x1, mask 0x1 đồng thời thay đổi Attribute Flag trên các liên kết R0-R2, R2-R3 và R3-R4 thành 0x1. Kết quả của quá trình tính toán đường đi như sau R0# show mpls traffic-eng tunnels tunnel 1 Hình 4-7 : Kết quả của tunnel 1 với ảnh hưởng của affinity bit Kết quả là tunnel 1 chọn đường đi qua cổng g2/0 và tuyến là R0 -R2 - R3 - R4 Nhận xét Ta nhận thấy rằng mặc dù đường R0-R3-R4 đã được lựa chọn ở trên nhưng khi ta cấu hình thêm bit quan hệ (Affinity bit) trên đường hầm thì quá trình tính toán đường sẽ chỉ lựa chọn những liên kết có cờ thuộc tính (Attribute Flag) trùng với Affnity bit ở các bit được quy định trong mặt nạ (mask). Trong kết quả tính toán đường thu được ta có thể thấy rằng mặc dù đường ngắn nhất để đi từ R0 đến R4 được tính toán là R0-R3-R4 nhưng kết quả của quá trình chọn đường lại là R0-R2-R3-R4 mặc dù đường này dài hơn tất cả các đường khác. Vấn đề lấn chiếm Ta tiếp tục cấu hình thêm tunnel 2 có băng thông 600Mbps, đường đi giống như tunnel 1 nhưng với độ ưu tiên cao hơn là 5/5. Kết quả thu được như sau: R0# show mpls traffic-eng tunnels destination 10.10.10.103 brief Hình 4-8 : Kết quả thu được tại R0 khi tunnel 2 lấn chiếm tunnel 1 Kết quả thu được là có 2 đường hầm up là tunnel 0 và tunnel 2 có thể tới đích R4, lúc này tunnel 2 đã lấn chiếm tunnel 1 vì có độ ưu tiên cao hơn. Sau đó tat hay đổi độ ưu tiên của tunnel 1 thành 4/4 kết quả là: R0# show mpls traffic-eng tunnels destination 10.10.10.103 brief Hình 4-9 : Kết quả thu được tại R0 khi tunnel 1 tái lấn chiếm tunnel 2 Kết quả thu được là 2 đường hầm up là tunnel 0 và tunnel 1 có thể tới đích R4, lúc này tunnel 1 tái lấn chiếm tunnel 2 vì có độ ưu tiên cao hơn. Nhận xét Do băng thông trên các liên kết mà tunnel 1 đi qua lúc này chỉ còn lại 550 Mbps ( băng thông của tunnel 1 là 200 Mbps và băng thông dự trữ tối đa trên liên kết là 750 Mbps) nên tunnel 2 khi được thiết lập với băng thông yêu cầu là 600Mbps sẽ chiếm lấy tài nguyên đã được dự trữ trước cho tunnel 1 nhờ có độ ưu tiên cao hơn. Tunnel 1 do không có đủ tài nguyên yêu cầu nên lúc này phải ngừng hoạt động. Nếu không có quá nhiều ràng buộc trong việc thiết lập đường thì tunnel 1 có thể được tái tối ưu hóa sang 1 đường khác có khả năng đáp ứng yêu cầu về băng thông để đi đến đích. Sau đó, ngay khi ta thay đổi độ ưu tiên trên tunnel 1 trở thành 4/4 đường hầm này lại lấn chiếm trở lại tunnel 2. Tunnel 2 lúc này lại ngừng hoạt động. Hoạt động bảo vệ liên kết, bảo vệ nút và bảo vệ đường Mô hình mạng Trong phần này cũng sử dụng mô hình mạng như trong phần 1. Hình 4-10: Mô hình mạng sử dụng trong phần 2 Với các Router được kết nối và cấu hình địa chỉ Ip tương tự như phần 1 Các bước thực hiện và kết quả Bảo vệ đường Cấu hình tunnel 0 đi qua R0 - R2 - R4 với đường bảo vệ đi qua R0 - R1 - R4 Kết quả đạt được: R0# show mpls traffic-eng tunnels tunnel 0 Hình 4-11: Kết quả thu được tại R0 với đường hầm chính R0 - R2 - R4 Đường hầm chính đi từ R0 qua cổng g2/0 qua R2 đến R4 R0# show mpls traffic-eng tunnels tunnel 0 protection Hình 4-12: Kết quả thu được tại R0 với đường hầm bảo vệ R0 - R1 - R4 Đường hầm bảo vệ đi từ R0 qua cổng g1/0 qua R1 đến R4 Để kiểm tra hoạt động của đường hầm bảo vệ này ta sẽ thử ngắt giao tiếp R2 – R4 kết quả thu được như sau: R0# show mpls traffic-eng tunnels tunnel 0 Hình 4-13: Các thông tin của tunnel 0 sau khi chuyển sang đường bảo vệ Sau khi ngắt R2-R4 đường hầm chính không hoạt động và chuyển qua đường bảo vệ R0 - R1- R4. Nhận xét Bảo vệ đường cung cấp cơ chế hồi phục lỗi end-to-end. Một đường bảo vệ được thiết lập và báo hiệu trước có thể tạm thời mang lưu lượng của đường hầm chính khi xảy ra lỗi. Cơ chế này không nhanh bằng cơ chế bảo vệ nút và bảo vệ liên kết (FRR). Thời gian hồi phục tùy thuộc vào khoảng cách của điểm lỗi và điểm đầu đường hầm đồng thời cũng sử dụng nhiều tài nguyên hơn . Tuy nhiên nó vẫn nhanh hơn so với việc tái tối ưu hóa sang 1 path-option khác. Bảo vệ liên kết Các bước thực hiện Xây dựng tunnel 12 (đường hầm NHOP) để bảo vệ cho liên kết R2-R4 mà đường hầm chính (tunnel 10) đi qua. Tunnel 10 là tunnel R0 – R2 – R4 Tại R0 cấu hình cho phép bảo vệ fast reroute trên đường hầm chính . Cấu hình trên R2 (headend của đường hầm bảo vệ) giao tiếp nào được bảo vệ khi xảy ra lỗi. Kết quả Sau khi liên kết R2 – R4 bị lỗi R2# show mpls traffic-eng fast-reroute database Tại R2 ta thấy đường hầm bảo vệ đang hoạt động (active) Hình 4-14: Cơ sở dữ liệu fast-reroute tại R2 Tại R0 cũng nhận được thông tin trong bản tin RESV thông báo về đường hầm đang được sử dụng. R0# show ip rsvp detail filter dst-port 10 Hình 4-15: Thông tin trong bản tin RESV gửi về R0 Đường đi lúc này của các gói tin trên đường hầm tunnel 10 R0 # trace mpls traffic-eng tunnel 10 Hình 4-16: Đường đi của gói tin qua tunnel 10 Nhận xét Ta thấy đã xuất hiện chồng nhãn trong các gói tin MPLS đi trên tunnel 10. Ở đây nhãn 19 và nhãn implicit null là nhãn của tunnel 10 còn nhãn 16 là nhãn của tunnel 12. R2 đã đóng gói nhãn 16 của tunnel 12 cùng với nhãn implicit null của tunnel 10 để vận chuyển đến R3. Quá trình bảo vệ chỉ sử dụng đường bảo vệ trong 1 khoảng thời gian rất ngắn để giảm thiểu mất mát dữ liệu trong khi chờ đợi headend của tunnel tái tối ưu hóa đường hầm chính đi trên 1 đường khác. Bảo vệ nút Các bước thực hiện: Thiết lập tunnel 11 để bảo vệ tunnel 10 khi nút R2 xảy ra lỗi. Cấu hình tại R0 cho phép bảo vệ fast- reroute cho tunnel 10. Cấu hình tại R0 giao tiếp g2/0 được bảo vệ bởi tunnel 11. Kết quả Sau khi liên kết R0 – R2 bị lỗi R0# show mpls traffic-eng fast-reroute database Hình 4-17: Cơ sở dữ liệu fast-reroute tại R0 sau khi xảy ra lỗi R0# show mpls traffic-eng tunnels tunnel 10 Hình 4- 18: Các thông tin của tunnel 10 sau khi xảy ra lỗi Kết quả tunnel 11 được sử dụng R4#show ip rsvp sender detail filter dst-port 10 Hình 4-19: Thông tin RSVP mà R4 nhận được về tunnel 10 Nhận xét Khi phát hiện liên kết R0-R2 bị lỗi, ngay lập tức R0 chuyển sang sử dụng đường bảo vệ NNHOP là tunnel 11 để đến đích. Cũng giống như trong trường hợp trên, đường bảo vệ này chỉ tồn tại trong 1 khoảng thời gian rất ngắn trước khi đường hầm chính được tái định tuyến. Bảo vệ nút cho phép bảo vệ liên kết và nút bị lỗi. Vì vậy trong trường hợp tồn tại cùng lúc 2 đường hầm bảo vệ NHOP và NNHOP trên cùng 1 đường hầm, router đầu dòng (headend) sẽ ưu tiên sử dụng đường bảo vệ NNHOP. Tổng kết chương Trong chương này, thực hiện một số bài mô phỏng để làm rõ nguyên lí hoạt động của kĩ thuật lưu lượng trong MPLS trên các router của hãng Cisco bằng phần mềm mô phỏng GNS3. Các bài mô phỏng này không nhằm mục đích đánh giá hiệu quả của kĩ thuật lưu lượng do một số hạn chế nhất định của phần mềm mà thiên về tìm hiểu hoạt động của nó trên các thiết bị thực tế hơn.