Luận văn Điều khiển lưu lượng trong MPLS và triển khai MPLS trên hạ tầng mạng Việt Nam

thông thường là vẫn sử dụng địa chỉ IP sẵn có trong gói tin. Giao thức BGP ở PE router nói trên được gọi là Multiprotocol BGP (MP - BGP). MP - BGP không chỉ hỗ trợ mạng khách hàng hoạt động ở giao thức mạng là IP mà còn hỗ trợ IPx, AppleTalk v.v…do gói tin bao gồm cả địa chỉ IPv4 khi vào PE router được coi như là dữ liệu để chuyển thành VPNv4. Hình 3.9. Quá trình chuyển giao thông tin định tuyến Quá trình chuyển giao thông tin định tuyến giữa các site trong cùng một VPN được thực hiện theo các bước sau: Bước 1: CE router gửi thông tin định tuyến IPv4 được cập nhật cho PE router. Bước 2: Thông tin định tuyến IPv4 nhận được được PE router thêm vào 64 bit để chuyển thành VPNv4. Bước 3: Gói tin VPNv4 được các PE trao đổi thông qua phiên giao dịch sử dụng MP BGP. Mạng core không can thiệp vào qui trình xử lý thông tin định tuyến giữa các PE router và được các PE router xem như một kết nối vật lý. Bước 4: Ở phía PE router nhận, các gói tin VPNv4 được lược bỏ 64 bit RD, trở thành gói tin IPv4 thông thường. Bước 5: các gói tin IPv4 được chuyển tiếp cho CE router phía site nhận để tiếp tục quá trình hội tụ định tuyến giữa các site trong cùng một VPN. Hình 3.10. Kết quả chuyển giao thông tin định tuyến 3.2.3.3. Số nhận dạng đường đi (RD): RD không có vai trò thiết yếu trong mô hình hoạt động của mạng MPLS VPN. 64 bit RD chỉ cung cấp khả năng sử dụng trùng địa chỉ IPv4 (public) trùng lặp giữa các khách hàng khi dùng MPLS VPN, vốn đòi hỏi phải là duy nhất trong mạng IP truyền thống. RDs được cấu hình tại PE router như một phần của quá trình thiết lập các site trong VPN. Các CE router không nhận biết hay xử lý RDs. Chức năng duy nhất của RDs là mở rộng IPv4, do đó mỗi 64 bit RD chỉ đại diện riêng cho một site và tương ứng là một VPN duy nhất. Do đó mô hình MPLS VPN sử dụng RD chỉ trong mô hình đơn giản, khi sự trao đổi thông tin diễn ra một cách cục bộ trong từng VPN riêng biệt. Nhưng nếu các VPN khác nhau cần trao đổi thông tin hoặc khi dịch vụ yêu cầu một site thuộc về nhiều VPN khác nhau thì ta cần phải có một phương pháp linh động hơn việc chỉ sử dụng RDs. Yêu cầu về trao đổi thông tin ở trên là trao đổi giữa các C network, đương nhiên là các bảng định tuyến ảo ở các PE router vẫn cần có sự cách ly. Yêu cầu đặt ra là các bảng định tuyến ảo cần trao đổi cơ sở dữ liệu với nhau. Điều này có nghĩa là một tuyến có thể vừa là thành viên của bảng định tuyến ảo này (tương ứng với một VPN) vừa là thành viên của một bảng định tuyến ảo khác (ứng với một VPN khác). Vậy phương pháp duy nhất thỏa mãn những yêu cầu trên là mỗi một tuyến cần có thông số nhận dạng riêng. *Ví dụ về dịch vụ VoIP Để minh họa cho nhu cầu cần thiết phải có một thông số nhận dạng VPN linh động hơn RDs (chỉ phân biệt các VRF tức các VPN) cho phép phân biêt được cả các tuyến trong bảng định tuyến ảo, ta đưa ra mô hình dịch vụ VoIP sử dụng trong MPLS. Hình 3.11. Mô hình VPN chạy ứng dụng Voip Dịch vụ VoIP đặt ra các yêu cầu sau: Các site của cùng một khách hàng cần liên lac với nhau Site trung tâm (central site) là nhà cung cấp dịch vụ VoIP. Site trung tâm cần liên lạc với VoIP gateway để nhận và phát cuộc gọi trong vùng một gateway quản lý và giữa các site bị gián đoạn bởi mạng core. Các yêu cầu liên lạc trên được cụ thể theo mô hình sau: Hai khách hàng A và B đều tham gia dịch vụ VoIP. Mạng core ngăn cách các site A1, site A2 của khách hàng A (VPN A) và site B1, site B2 của khách hàng B. Site trung tâm A tham gia vào tổng đài VoIP VPN và VPN A Site trung tâm Btham gia vào tổng đài VoIP VPN và VPN B Site A1 và A2 thuộc VPN A. Site B1 và B2 thuộc VPN B. Các site trong cùng một VPN có nhu cầu liên lạc với nhau thông qua site trung tâm (tổng đài VoIP), và liên lạc giữa các site thuộc VPN khác nhau thông qua các site trung tâm và các gateway.thông qua các site trung tâm và các gateway. Hình 3.12. Phân tách khách hàng trong ứng dụng Voip 3.2.3.4. Số phân biệt đường đi (RT) RDs không thể đặc trưng cho một site tham gia nhiều VPN khác nhau. Do đó cần một phương thức sao cho một bảng định tuyến ảo nhận biết được một tuyến thuộc VRF khác là thành viên của mình. RT được ứng dụng trong cấu trúc MPLS VPN để đáp ứng yêu cầu trên. RT phải đáp ứng được hai yêu cầu: Giúp các VRF ở hai phía mạng core nhận biết nhau nhưng đồng thời cũng cách ly các bảng định tuyến ảo khác VPN. Chức năng này tương tự như chức năng của RDs. RTs phải xác định một tuyến là thành viên của VPN nào khi truyền qua mạng core bằng giao thức MP BGP. Nguyên lý làm việc của RTs: RTs được gán với một tuyến thuộc mạng khách hàng tại thời điểm thông tin định tuyến IPv4 được chuyển đổi thành VPNv4. Tiến trình này được thực hiện một cách riêng biệt đối với từng VRF và được gọi là export RT. Quá trình “export RTs” giúp thiết lập một VPN tương ứng với một bảng định tuyến và các tuyến thành viên trong bảng định tuyến đó. "Export RT" có thể trùng với VRF khác. Khi các tuyến VPNv4 được hội tụ ở PE router phía bên kia mạng core, các router PE này sẽ lựa chọn các tuyến dựa vào RTs để đưa vào vác VRF mà tuyến đó là thành viên. Quá trình này gọi là “import RTs”, mỗi VRF thực hiện riêng biệt quá trình này, do đó một tuyến có thể lá thành viên của nhiều VRF. Do tính chất phức tạp của RTs mà nó chỉ được sử dụng trong mô hình MPLS VPN phức tạp. 3.2.3.5. Hoạt động của giao thức MP - BGP. Quy trình chuyển mạch trong VPN gồm các thao tác sau: Gói tin chạy trong miền của nhà cung cấp dịch vụ mạng sử dụng tiền tố VPNv4. Tiền tố này chứa cả giá trị RT và RD. RT có thể là một thông số không bắt buộc trong cấu hình MPLS VPN, nhưng nó có thể được sử dụng tốt trong một số mạng phức tạp mà một site thuộc nhiều VPN. Hơn nữa RT cũng có thể được sử dụng để chọn lọc route nhập vào một VRF khi học các đường đi VPNv4 trong MP-BGP updates. Nhãn VPNv4 chỉ được router egress PE hiểu khi nó trực tiếp kết nối với router biên khách hàng. Next hop của router PE đó không hề biết sự tồn tại của nhãn VPNv4 mà chỉ thực hiện vai trò như những MPLS VPN router. Router PE2 nhận update MP-BGP, và đường đi được lưu trữ trong bảng chuyển tiếp tương ứng cho khách hàng A dựa trên nhãn VPN. Đường đi MP-BGP được redistribute vào bảng chuyển tiếp giữa PE-CE, và đường đi đó được quảng bá đến CE-2. Hình 3.13. Hoạt động của MP - BGP trong mạng MPLS VPN 3.2.4. Hoạt động của mặt phẳng điều khiển và mặt phẳng dữ liệu trên MPLS VPN 3.2.4.1. Mặt phẳng điều khiển: Mặt phẳng điều khiển trong mạng MPLS VPN bao gồm tất cả các thông tin định tuyến lớp 3 và các qui trình bên trong để trao đổi về khả năng của một mạng, công thêm việc gán nhãn và trao đổi dựa vào giao thức LDP hoặc CR-LDP, RSVP-TE khi có yêu cầu cao về điều khiển tải hoặc QoS. Trong mạng MPLS, giữa router biên khách hàng và router biên của nhà cung cấp dịch vụ yêu cầu một giao thức định tuyến như IGP, BGP hoặc đơn giản chỉ là định tuyến tĩnh để quảng bá thông tin NLRI. Còn trong mạng xương sống, giữa P và PE router đòi hỏi cấu hình định tuyến nội IGP (OSPF hoặc IS-IS), cộng thêm giao thức phân phối nhãn LDP. LDP được sử dụng để xác định cũng như phân phối các nhãn trong miền MPLS. IGP thì được sử dụng để trao đổi thông tin về khả năng đến được của một mạng NLRI cũng như ánh xạ NLRI đó vào MP-BGP. phiên MP-BGP được duy trì giữa các router biên của nhà cung cấp (PE) để cập nhập thông tin địa chỉ VPNv4, cộng với các thuộc tính BGP mở rộng community liên kết với địa chỉ VPNv4 tương ứng. Hình 3.14. Hoạt động của mặt phẳng điều khiển Bước 1: router PE1-AS1 nhận cập nhập IPv4 từ mạng 172.16.10.0 (mặt phẳng dữ liệu). Bước 2 : PE1-AS1 chuyển đổi địa chỉ IPv4 thành địa chỉ VPNv4 bằng cách gán số RD 1:100 và, SoO và RT 1:100 dựa trên cấu hình bảng VRF trên nó. PE1-AS1 sau đó gán nhãn VPNv4 V1 vào cập nhập của mạng 172.16.10.0/24 và viết lại thuộc tính next-hop đến loopback0 10.10.10.101 trên PE1-AS1. Loopback0 được quảng bá bởi các giao thức định tuyến nội IGP như OSPF, IS-IS và LDP. Quá trình gán nhãn và quảng bá cho loopback0 10.10.10.101/32 được thực hiện như sau: PE2-AS1 yêu cầu nhãn cho mạng 10.10.10.101/32 sử dụng cơ chế gán nhãn LDP từ các downstream láng giềng của nó, LSR P2-AS1. P2-AS1 yêu cầu nhãn cho tiền tố 10.10.10.101/32 sử dụng giao thức LDP từ downstream router là P1-AS1. P1-AS1 sau đó lại yêu cầu nhãn từ PE1-AS1. PE1-AS1 gán một nhãn implicit-null (penultimate hop popping) cho 10.10.10.101/32, thay đổi thông tin trong bảng LFIB của 10.10.10.101/32 và gửi nó cho P1-AS1 bằng một LDP reply. P1-AS1 sử dung nhãn implicit-null nhận được từ PE1-AS1 làm nhãn outbound của nó, phân phối nhãn L1 cho tiền tố 10.10.10.101, chỉnh sửa thông tin của 10.10.101/32 trong bảng LFIB và gửi nhãn này đến P2-AS1 qua LDP reply. P2-AS1 dùng nhãn L1 như là nhãn outbound của nó, phân phối nhãn L2 cho 10.10.10.101/32 và sửa thông tin trong bảng LFIB về mạng trên. Sau đó, nó gửi giá trị nhãn cho PE2-AS1 bởi 1 LDP reply. Bước 3: PE2-AS1 được cấu hình RT 1:100 trong bảng VRF nên sẽ chuyển cập nhập VPNv4 sang IPv4 và chèn thông tin định tuyến trong bảng VRF chủa khách hàng A. Sau đó nó quảng bá route này đến CE2-A. 3.2.4.2. Mặt phẳng dữ liệu: Hoạt động của mặt phẳng dữ liệu MPLS VPN bao gồm sự sử dụng label stack (chồng nhãn). Label stack trong MPLS VPN có hai nhãn, nhãn trên cùng được gán từ router egress PE, và nhãn thứ hai là nhãn VPN được gán bởi router egress PE kết nối với khách hàng quảng bá một tiền tố IP. Khi dữ liệu được gửi đến một tiền tố thuộc một VPN và được gửi qua mạng core dựa trên MPLS, chỉ có nhãn trên cùng trong label stack là được hoán đổi khi gói tin đi qua từng node mạng. Nhãn VPN còn nguyên vẹn và chỉ được bóc khi qua router egress/downstream PE. Kết quả cho ra tiền tố ứng với outgoing interface thuộc bảng VRF tương ứng trên một router phụ thuộc vào giá trị của nhãn VPN. Hình 3.15. Hoạt động của mặt phẳng dữ liệu Bước 1: CE2-A gửi gói tin với địa chỉ 172.16.20.1 đến 172.16.10.1 Bước 2: PE2-AS1 nhận gói và gán nhãn VPN V1 và nhãn LDP V2, sau đó gửi gói đến cho P2-AS1. Bước 3: P2-AS1 nhận gói tin, hoán đổi nhãn LDP L2 vào vị trí của L1. Bước 4: P1-AS1 nhận gói tin, bóc nhãn trên cùng đi vì nó nhận một nhãn implicit-null cho 10.10.10.101/32 từ PE1-AS1. Kết quả là gói tin với nhãn VPN được gửi cho PE1-AS1. Bước 5: PE1-AS1 bóc nhãn VPN, gửi gói cho CE1-A nơi mà mạng 172.16.10.0 được định vị. Nguyên tắc để hiểu MPLS VPN là nhãn VPN không bao giờ được bóc cho đến khi nó đến router egress PE. Tất cả các traffic được gửi đi tuân theo các giao thức của mạng MPLS cơ bản, và nhãn next-hop ánh xạ đến loopback của router PE downstream là được dùng để chuyển tiếp gói tin qua miền MPLS. 3.3. Quá trình xử lý thông tin định tuyến đầu cuối trong MPLS-VPN: Mô hình sau đây mô tả một cách tổng quát nhất quá trình xử lý thông tin định tuyến giữa các router trong MPLS VPN. Quá trình xử lý thông tin định tuyến trong MPLS VPN chia làm bốn bước: Bước 1: PE router nhận thông tin định tuyến từ CE router và cài đặt thông tin đó vào bảng định tuyến ảo (VRF) tương ứng. Bước 2: Các tuyến trong VRF sẽ được xuất (export) thành các thông tin định tuyến VPNv4 để thực hiện giao thức MP BGP và hội tụ phía PE router bên kia mạng core. Bước 3: Phía PE nhận được thông tin định tuyến MP BGP từ PE gửi sẽ phân tích các tuyến VPNv4 nhận được, dựa vào các thông số như RDs mà có thể update thông tin cho bảng định tuyến ảo (VRF) tương ứng và còn có thể “import” các tuyến thành viên vào VRF tương ứng (khi sử dụng RTs). Bước 4: Các tuyến VPNv4 trong VRF được chuyển thành các tuyến IPv4 dùng để hội tụ quá trình định tuyến trong C network và giữa các C network (bị ngăn cách bởi P network) với nhau. Hình 3.20. Quá trình xử lý thông tin đầu cuối dữ liệu 3.4. MPLS-VPN và quá trình chuyển gói dữ liệu: Sau khi quá trình định tuyến đã được hội tụ trong toàn bộ hệ thống MPLS VPN, các gói thông tin sẽ được chuyển giao qua mạng lõi bằng phương thức chuyển mạch nhãn. Tiến trình này được thực hiện như sau: Hình 3.21. Xử lý gói dữ liệu Khi gói tin IPv4 từ C network đi vào PE phát (Ingress PE Router) nó sẽ được PE router gán hai loại nhãn: Nhãn đầu tiên (top label) ứng với nhãn V trong mô hình trên bao gồm RDs hay RTs dùng để đáp ứng dịch vụ MPLS như đã phân tích ở các phần trên. Nhãn V này dùng cho hoạt động định tuyến MP BGP giữa các PE router. Nhãn V kết hợp với gói tin IPv4 tạo thành gói tin VPNv4, được hội tụ giữa các PE router thông qua MP BGP. Nhãn thứ hai (secondary label) được mạng core dùng để chuyển mạch nhãn. Các P router chỉ xử lý các nhãn này, phần còn lại được xem là dữ liệu. Nhãn V và L được xếp vào ngăn xếp xử lý nhãn cũa PE router và được xử lý theo nguyên tắc (LIFO – Last in first out). Các nhãn L sẽ thay đổi khi qua các P router (đóng vai trò là các LSR trong mô hình MPLS), trong khi đó nhãn V được xem là dữ liệu nên không thay đổi. Việc phân phối nhãn giữa các P router được thực hiện bằng LDP (label distribution protocol). Để mô hình MPLS VPN hoạt động có hiệu quả, cần thỏa mãn hai điều kiện: Các P router phải sử dụng LDP để phân phối nhãn đến PE router cạnh ngoài (egress PE router). Các PE router cạnh chỉ cần xử lý nhãn V, và dựa vào nội dung trong V mà nhập các thông tin định tuyến chính xác vào các VRF tương ứng. Do vậy mô hình MPLS VPN sử dụng trong thực tế như sau : Hình 3.22. Xử lý PHP Trong mô hình này tại PE router cạnh ngoài (Egress PE router) không xử lý nhãn L mà chỉ xử lý nhãn V, do nhãn L không còn cần thiết tại đây. Mô hình này gọi là PHP (Penultimate pop hop). CHƯƠNG 4: KỸ THUẬT LƯU LƯỢNG TRONG MPLS 4.1. Các khái niệm cơ bản trong điều khiển lưu lượng: 4.1.1. Kỹ thuật hàng đợi 4.1.1.1. FIFO Hàng đợi “vào trước, ra trước” (FIFO) là cơ chế mặc định cho các gói tin khi đi vào một nút mạng khi không có sự hiện diện của thuật toán đặc biệt nào tại đó. Trong hàng đợi FIFO các gói tin được xếp vào cùng một hàng đợi và được chuyển đi theo cùng một cách mà chúng được sắp xếp trong hàng đợi. Ưu điểm chính của hàng đợi FIFO là ở tính đơn giản của nó, không có bất kỳ giải thuật phức tạp nào được thiết kế riêng cho FIFO. Trong hàng đợi FIFO, các gói tin được đối xử như nhau do đó hàng đợi này chỉ dùng để sử dụng cho loại dịch vụ “nỗ lực tối đa” (BE) và cũng là loại dịch vụ được hỗ trợ duy nhất trong mạng IP truyền thống. Hình 4.1: Hàng đợi FIFO Incoming Packet Flow: luồng dữ liệu gói đi vào Router Packet Classifier: Bộ phân lớp dịch vụ dựa vào trường ToS trong tiêu đề của gói IP Packet Scheduler: Bộ lập trình xử lý Output Port: port xuất dữ liệu 4.1.1.2. PQ Hàng đợi theo độ ưu tiên là sự cải tiến của FIFO. Trước khi được đưa vào hàng đợi tương ứng, các gói tin phải được phân loại theo từng loại dịch vụ. Các hàng đợi được thiết kế theo độ ưu tiên của loại gói tin mà nó phải chứa. Các gói tin ở hàng đợi có độ ưu tiên thấp hơn chỉ được xử lý khi và chỉ khi không còn bất cứ các gói tin nào trong các hàng đợi có độ ưu tiên cao hơn. Hình 4.2: Hàng đợi PQ Hàng đợi PQ được áp dụng hiệu quả chủ yếu cho các ứng dụng thời gian thực sử dụng kỹ thuật ghép kênh theo thời gian TDM như video, thoại trên nền IP. Đối với các ứng dụng truyền dữ liệu bằng TCP thì việ tính toán phải cẩn thận vì nếu xảy ra xung đột, các gói tin báo nhận có thể gây ra sai sót trong việc xử lý các gói tin khác truyền cùng nó. Để giảm bớt nhược điểm trên của hàng đợi PQ, trong thực tế người ta sử dụng hàng đợi PQ được điều khiển tốc độ. Với loại hàng đợi này, các gói tin trong hàng đợi có độ ưu tiên cao chỉ được xử lý nếu tổng số gói tin trong hàng đợi đó nhỏ hơn một lượng xác định. Ví dụ như trong mô hình trên hàng đợi có độ ưu tiên 1 là cao nhất, giả sử ta hạn chế lượng BW tối đa mà hàng đợi này chiếm ở port xuất là 10%. Để làm việc này đơn giản người ta chỉ việc cấu hình cho bộ lập lịch xử lý gói dừng ở hàng đợi thứ nhất tối đa 10% chu kỳ của nó. 4.1.1.3. FQ Một loại hàng đợi khác dùng để chia sẻ băng thông cho các loại dịch vụ khác nhau là FQ. FQ phân chia băng thông của port xuất thành N phần bằng nhau, với N là số lớp dịch vụ. Một điều cần lưu ý là tại mỗi lần bộ lập lịch trích lấy bytes trong một hàng đợi của một lớp thì toàn bộ một gói trong hàng đợi đó phải được trích ra. FQ có hai yếu điểm lớn. Thứ nhất, vì băng thông tổng của port xuất được chia đều cho các hàng đợi của từng lớp nên FQ không thể dùng khi có yêu cầu riêng về băng thông cho từng lớp riêng biệt. Thứ hai, vì FQ trích byte cho đủ một gói trong các chu kỳ lập lịch nên sẽ xảy hiện tượng một loại lớp dịch vụ sẽ chiếm băng thông của các loại dịch vụ có tổng số byte trong một gói nhỏ hơn nó thay vì bằng nhau như mong đợi của thiết kế trong FQ. Chính vì điều này mà FQ chi được sử dụng trong các ứng dụng được truyền trên cùng một kênh vật lý mà tổng số byte trong một gói của chúng là bằng nhau. Hình 4.3: Hàng đợi FQ Incoming Packet Flow: luồng dữ liệu gói đi vào Router Packet Classifier: Bộ phân lớp dịch vụ dựa vào trường ToS trong tiêu đề của gói IP Round Robin Order: Bộ luân chuyển, dùng phân chia thời gian trong một chu kỳ cho từng hàng đợi mà hàng đợi đó được bộ lập lịch xử lý. Packet Scheduler: Bộ lập trình xử lý Output Port: port xuất dữ liệu Ví dụ: cho 4 luồng dữ liệu như hình vẽ truyền 4 loại dịch vụ với tổng số byte trong một gói của từng luồng lần lượt là:200, 100, 400, 300 byte. Vậy tỷ lệ phân chia theo băng thông tương ứng của từng luồng là: Luồng 1=200/1000= 20%; luồng 2= 100/1000=10%; Luồng 3=400/1000=40%; luồng 4=300/1000=30% Hình 4.4. Ví dụ phân bổ băng thông trong FQ 4.1.1.4. WRR Để khắc phục khuyết điểm thứ nhất của FQ, người ta thiết kế hàng đợi kiểu WRR. Khi một gói ti đi vào WRR, đầu tiên nó sẽ được phân tích để xác định loại dịch vụ. WRR phân chia băng thông tổng của port xuất thành N phần, với N là tổng số lớp. Mỗi hàng đợi ứng với mỗi lớp sẽ chiếm tỷ lệ băng thông tương ứng ở port xuất là Wi/(W1+W2 + ...WN). trong đó Wi là trọng số của loại dịch vụ đang xét. WRR sử dụng bộ lập lịch như một con quay nghĩa là thời gian bộ xử lý làm việc tại mỗi lớp dịch vụ tuân theo phần trăm tỷ lệ trọng số của nó với trọng số tổng. Tuy nhiên trong cùng một lại phân thành M luồng dữ liệu khác nhau. M luồng này được xử lý tương đương như trong trường hợp FQ nên không khắc phục được nhược điểm thứ hai của FQ. Hình 4.5: Hàng đợi WRR 4.1.1.5. WFQ (Weighted Fair Queuing) Hàng đợi kiểu WFQ khắc phục nhược điểm thứ hai của FQ. Trong WFQ khi một gói tin đi hàng hàng đợi, trước tiên nó được phân lớp để đưa vào hàng đợi thích hợp. Mỗi hàng đợi này chiếm một lượng băng thông ở port xuất theo tỷ lệ trọng số tương ứng. Một điều khác biệt ở WFQ so với FQ là thay vì bộ lập lịch xử lý gói trích xuất toàn bộ gói ở một hàng đợi ra port xuất, thay vào đó WFQ sẽ tính toán thời gian kết thúc của một gói tin xuất ra port xuất dựa vào thông tin về tỷ lệ trong số của gói tin đó. Bằng thuật toán thích hợp WFQ tính ra được độ dài của một gói (tính theo byte) và xuất ra port xuất. Bộ xử lý ước lượng thời gian cần để trích hết gói tin để đưa ra port xuất Hình 4.6: Hàng đợi WFQ Tại mỗi thời điểm bộ lập lịch tại hàng đợi, nó chỉ trích xuất từng bit sau đó đưa về bộ phân tích gói và xuất ra port xuất tương ứng với tỷ lệ trọng số. Nếu một gói tin có độ dài quá lớn, nó sẽ bị trễ rất nhiều. Đây là nhược điểm lớn nhất của WFQ. Ngoài ra mô hình này chỉ dùng trên lý thuyết mà không áp dụng trong thực tế được vì độ phức tạp trong việc xử lý từng bit một thay vì từng byte như trong các loại hàng đợi khác. Hình 4.7: Hàng đợi WFQ (Class Based) 4.1.1.6. WFQ (Class Based) Hàng đợi WFQ-Class Based có nguyên lý hoạt động tương đương như WRR, chỉ có điều khác biệt là trong M luồng dữ liệu thuộc cùng một lớp sẽ được xử lý bằng hàng đợi kiểu WFQ. Việc này làm giảm tại trong việc sử dụng giải thuật WFQ cho từng lớp. Trong mô hình dưới đây, giả sử m là số lớp được phân chia, Ni là số hàng đợi WFQ cho từng lớp. Vậy, tổng số hàng đợi WFQ cần thiết sẽ là: (N1+N2 +...+Nm) Ví dụ: Cho mô hình sau, yêu cầu phương thức xử lý khi truyền gói tin ở port xuất Hình 4.8. Ví dụ xử lý phân bổ băng thông trong WFQ Tại mỗi thời điểm bộ lập lịch xử lý cho từng hàng đợi, số byte trong tin sẽ được trích ra là 10 bytes cho gói C, 20 bytes cho gói B, 10 bytes cho gói A. vậy để xuất gói tin ra port xuất hàng đợi truyền gói C phải cần bộ lập lịch dừng lại hai lần trong một chu kỳ. Hàng đợi chứa gói tin B cần sáu lần và hàng đợi cho gói tin A là ba lần. Vậy thứ tự mà bộ lập lịch cần phải tới trước là C, A, B. 4.1.2. Trung kế lưu lượng Đặc tính này trong LSR cho phép tập hợp các đặc tính của luồng dữ liệu trong mạng như tốc độ cực đại, tốc độ trung bình, và kích cỡ burst cực đại. Những tính chất này vốn có ở tất cả các luồng dữ liệu, khi đi vào mạng MPLS chính nhờ các trung kế lưu lượng này mà dữ liệu được quản lý hiệu quả hơn. Trung kế lưu lượng được coi như một bộ thu gom dữ liệu có chung các đặc tính trên. Điều này đặc biệt quan trọng trong việc thực hiện quản lý trong kỹ thuật lưu lượng. Trung kế lưu lượng cũng giống FEC được phân biệt tại Ingress LER. Ngoài ba đặc điểm nêu trên một trung kế lưu lượng còn có đặc tính chọn lựa QoS cho các gói tin. QoS thực sự của gói tin dùng trong mạng MPLS được gán tại các trung kế lưu lượng. Trung kế lưu lượng sẽ quyết định các gói tin không có chung ba đặc tính trên được truyền đi hay không đồng thời sẽ gán mã DiffServ kèm theo gói tin đó. Khi một gói tin đi tới Ingress LER, nó sẽ được phân tích các đặc tính sau: Cổng giao tiếp với LER Gói tin thuộc về FEC nào Các tính chất của trung kế lưu lượng. Các gói tin có chung ba đặc tính trên sẽ được gán váo một LSP duy nhất 4.1.3. Giải thuật thùng rò và thùng Token 4.1.3.1. Mô hình thùng rò Mô hình thùng rò có đặc điểm là tốc độ ra không đổi bất chấp việc tốc độ nước vào thùng là bao nhiêu hay trong thùng còn bao nhiêu nuớc. Nếu thùng đầy mà lưu lượng vẫn chảy vào thì thùng sẽ đầy và tràn mất. Tương tự cho dữ liệu khi tới một router trong mạng nếu hàng đợi đã đầy thì gói tin sẽ bị “drop”. Hình 4.9: Mô hình thùng rò 4.1.3.2. Mô hình thùng Token Thùng Token có kích thước B, các gói tin chảy vào thùng được gọi là Token. Tốc độ Token chảy vào thùng không đổi là p. Nếu số Token trong thùng vượt quá B thùng sẽ tràn và bị mất, do đó B là số lượng Token tối đa trong thùng. Gọi G là kích thước gói đến, một gói là hợp lệ khi lượng Token trong thùng lớn hơn hay bằng G, đồng thời lượng Token trong thùng được giảm đi G. ngược lại khi lượng Token trong thùng nhỏ hơn kích thước gói, gói được xem là vượt mức hay không hợp lệ. Tuỳ vào các chính sách khác nhau mà các gói hợp lệ hoặc không hợp lệ được xử lý khác nhau. Hình 4.10: Mô hình thùng Token Một điều cần lưu ý trong giải thuật thùng Token là tốc độ chảy vào và tốc độ chảy ra phải bằng nhau. Thùng Token cho phép dữ liệu bùng phát ở một mức nhất định (kích thước B), nhưng không cho phép tốc độ chảy vào thùng vượt quá p trong một khoảng thời gian nhất định. 4.2. Động lực phát triển của MPLS TE: Điều khiển lưu lượng (traffic engineering) là quá trình chuyển hướng lưu lượng trên mạng xương sống để sử dụng hiệu quả băng thông hữu dụng giữa các router. Trước khi có MPLS TE, điều khiển lưu lượng được áp dụng trên IP hoặc ATM, phụ thuộc vào giao thức được sử dụng giữa các router biên trong mạng. Trên thế giới hiện nay đã khá quen thuộc với công nghệ điều khiển lưu lượng trên MPLS, song nhìn chung người ta vẫn còn sử dụng TE trên IP và ATM. Vậy tại sao cần thiết phải áp dụng và triển khai TE trên MPLS? Đó có phải là một tất yếu trong sự phát triển hiện nay? Chương này sẽ tập trung giải quyết vấn đề đó. TE trên IP hầu hết được triển khai bằng cách xác định interface cost khi nhiều đường đi cùng tồn tại giữa hai điểm trên mạng. Hơn nữa, định tuyến tĩnh cũng cho phép bẻ hướng lưu lượng theo một đường đi định trước. Hình dưới đây mô tả một mạng IP cơ bản với hai khách hàng A và B kết nối với cùng một nhà cung cấp dịch vụ. Hình 4.11. Mạng IP truyền thống Theo hình trên, có hai đường đi tồn tại giữa CE1 và CE2. Nếu tất cả các đoạn giữa các router có cost bằng nhau, CE1 và CE2 sẽ chọn đường đi qua PE1-AS1, P3-AS1, gọi là PATH1. Khách hàng B cũng sẽ lựa chọn như vậy. Nếu tất cả đều là đường T3, ví dụ trong trường hợp CE1-A gửi một luồng 45Mbps và CE1-B sau đó gửi luồng 10Mbps, một số gói sẽ bị mất tại PE1-AS1 bởi vì đường đi được dùng là PATH1. PATH2 không hề được sử dụng, vì vậy, TE có thể sử dụng tối ưu băng thông hữu dụng. Để triển khai TE sử dụng IP để hai đường PATH1 và PATH2 đều được chia tải, chúng ta cần triển khai IGP và thay đổi cost của các đoạn link để làm cho cost của PATH2 bằng với PATH1.Trong một mạng lớn, điều này thường làm tốn nhiều thời gian đề triển khai vì số lượng router rất lớn. Còn trong mạng ATM, người ta có thể điều khiển lưu lượng được nhiều hơn, bằng cách cấu hình các PVC giữa các router PE1-AS1 và PE2-AS2 với cùng một cost như nhau. Tuy nhiên, việc triển khai ATM TE gặp nhiều khó khăn bởi cần phải xây dựng mô hình mạng đấu nối đầy đủ trong mạng. Vấn đề nữa là khi một kết nối bị hư hỏng, PVC trên kết nối đó cũng không hoạt động được. Các đường link trong PVC không có khả năng tự phục hồi nên việc gây khó khăn nhiều. Khi mạng bị lỗi, các thông điệp được gửi đi trên toàn mạng. Người ta