MỤC LỤC
LỜI GIỚI THIỆU 4
TỪ VIẾT TẮT 5
CHƯƠNG I. CƠ SỞ CÔNG NGHỆ MPLS 6
I.1. Lịch sử phát triển MPLS 6
I.2. Quá trình tiêu chuẩn hoá MPLS 9
I.2.1. IP over ATM 9
I.2.2. Toshiba's CSR 10
I.2.3. Cisco's Tag Switching 10
I.2.4. IBM's ARIS and Nortel's VNS 10
I.2.5. Công việc chuẩn hoá MPLS 10
I.3. Nhóm làm việc MPLS trong IETF 11
I.3.1. Internet-Drafts: 12
CHƯƠNG II. CÁC KHÍA CẠNH KỸ THUẬT MPLS 13
II.1. Khái niệm MPLS 13
II.1.1. Khái quát MPLS 13
II.1.2. MPLS và các thành phần trong MPLS 15
II.2. Các hoạt động trong mạng MPLS 36
II.3. Các giao thức sử dụng trong MPLS 37
II.3.1. Giới thiệu chung 37
II.3.2. Các giao thức định tuyến 37
II.3.3. Giao thức phân phối nhãn LDP 37
II.4. Chất lượng dịch vụ trong MPLS 38
II.4.1. Các dịch vụ tích hợp và RSVP 39
II.4.2. Các dịch vụ khác 41
II.4.3. Khai báo tắc nghẽn thẳng 41
II.5. Quản lý lưu lượng trong MPLS 41
II.6. Bảo mật trong MPLS 41
II.7. Các ứng dụng của MPLS 41
II.7.1. Cải thiện chất lượng gửi chuyển tiếp gói tin trong mạng 41
II.7.2. Hỗ trợ QoS và CoS cho các dịch vụ khác nhau 41
II.7.3. Hỗ trợ khả năng mở rộng mạng 41
II.7.4. Tích hợp IP và ATM trong mạng 41
II.7.5. Xây dựng các mạng interoperable 41
CHƯƠNG III. ỨNG DỤNG MPLS TRONG MẠNG VPN 41
III.1. Giới thiệu về MPLS trong VPN 41
III.2. Các bộ định tuyến ảo trong MPLS VPN 42
III.3. Các mục tiêu của MPLS VPN 43
III.4. Những yêu cầu về kiến trúc MPLS VPN 44
III.5. Phác thảo về kiến trúc MPLS VPN 44
III.6. MPLS đóng vai trò cơ chế gửi chuyển tiếp 46
III.7. Cấu hình MPLS VNP có thể mở rộng 49
III.8. Nhận biết các bộ định tuyến lân cận động trong MPLS VPN 49
Cấu hình miền VPN IP 50
III.10. Ví dụ về phương pháp nhận biết các bộ định tuyến lân cận 51
III.11. Gửi chuyển tiếp trong MPLS VPN 52
III.11.1. LSP cá nhân 52
III.11.2. LSP công cộng hiệu quả cao 52
III.12. Các dịch vụ khác nhau trong MPLS VPN 53
III.13. Vấn đề bảo mật trong MPLS VPN 53
III.13.1. Bảo mật định tuyến 53
III.13.2. Bảo mật dữ liệu 53
III.13.3. Bảo mật cấu hình 53
III.13.4. Bảo mật mạng vật lý 54
III.14. Giám sát bộ định tuyến ảo trong MPLS VPN 54
III.15. Hỗ trợ QoS trong MPLS VPN 54
III.16. Xem xét về chất lượng trong MPLS VPN 58
CHƯƠNG IV. GIẢI PHÁP MPLS CỦA MỘT SỐ HÃNG 59
CHƯƠNG V. KHUYẾN NGHỊ VỀ KHẢ NĂNG ỨNG DỤNG CÔNG NGHỆ MPLS TRONG MẠNG NGN CỦA TỔNG CÔNG TY BCVT VIỆT NAM 59
CHƯƠNG VI. KẾT LUẬN VÀ KHUYẾN NGHỊ 59
TÀI LIỆU THAM KHẢO 60
70 trang |
Chia sẻ: banmai | Lượt xem: 1926 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu Nghiên cứu công nghệ chuyển mạch nhãn mpls và đề xuất các kiến nghị áp dụng công nghệ mpls trong mạng thế hệ mới ngn của tổng công ty BCVT Việt Nam, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
c yêu cầu các VPI/VCI từ các LSR xuôi lân cận (điều này một lần nữa tương tự như các phương thức được sử dụng trong việc hợp nhất khung)
Một phương thức tương tự có thể hỗ trợ các nút thi hành việc hợp nhất VP. Trong trường hợp này nút hợp nhất VP, yêu cầu một VPI/VCI hoặc một số VPI/VCI từ LSR xuôi lân cận, thay vì có thể yêu cầu một VP (được xác định bằng một VPI) nhưng một vài VCI trong VP. Hơn nữa, cho rằng nút không thi hành việc hợp nhất là LSR xuôi của hai nút khác nhau hỗ trợ việc hợp nhất VP. Nút này có thể yêu cầu một VPI/VCI(cho lưu lượng xuất phất từ nó) cộng với hai VP (một VP cho mỗi nut ngược), mỗi VP kết hợp với một tập các VCI (như được yêu cầu từ nút ngược)
Để hỗ trợ tất cả việc hợp nhất VP, VC và không hợp nhất, bởi vậy cần phải cho phép các nút ngược yêu cầu kết hợp 0 hoặc các VCI, cộng với 0 hoặc các VP (xác định bằng VPI), mỗi VP bao gồm một số các VC (được xác định bằng một tập các VCI mà chúng có ý nghĩa trong một VP). Các nút hợp nhất VP bởi vậy yêu cầu một VP, với một VCI trong đó cho lưu lượng mà nó sinh ra cộng với một VCI cho mỗi VC yêu cầu ở trên. Nút hợp nhất VC sẽ yêu cầu chỉ một VPI/VCI (từ khi chúng có thể hợp nhất tất lưu lượng upstream vào một VC). Các nút không hợp nhất sẽ chuyển tiếp bất cứ yêu cầu nào mà nó nhận được ở trên, cộng với yêu cầu một VPI/VCI cho lưu lượng mà nó sinh ra (nếu thích hợp).
Các đường ngầm và hệ thống phân cấp
Đôi khi một bộ định tuyến thi hành
Các hoạt động trong mạng MPLS
Các hoạt động sau phải được thi hành cho việc chuyển gói tin qua mạng MPLS
Tạo nhãn và phân phối nhãn
Tạo bảng cho mỗi bộ định tuyến
Tạo đường chuyển mạch nhãn LSP
Tìm kiếm bảng nhãn, vị trí dán nhãn.
Gửi chuyển tiếp nhãn
Các giao thức sử dụng trong MPLS
Giới thiệu chung
Các giao thức định tuyến
OSPF
IS-IS
RIP
IRGP
BGP
PNNI
Giao thức phân phối nhãn LDP
Tiêu chuẩn kỹ thuật tuân thủ LDP là một nhóm thiết kế đại diện cho rất nhiều nhà cung cấp thiết bị, được thành lập sau cuộc họp lần thứ hai của nhóm làm việc MPLS.Như chúng ta thấy rằng kiến trúc MPLS dựa trên mô hình điều khiển, kết quả là LDP dựa trên sự hợp nhất của hai giao thức TDP và ARIS.
LDP có các tính chất cơ bản như sau:
Cung cấp cơ chế nhận biết LSR cho phép các LSR ngang cấp tìm kiếm nhau và thiết lập kết nối.
Định nghĩa bốn lớp bản tin:
Các bản tin DISCOVERY
Các bản tin ADJACENCY, để giải quyết vấn đề khởi tạo, duy trì, huỷ bỏ các phiên giữa hai LSR.
Các bản tin LABEL ADVERTISEMENT, giải quyết thông báo, yêu cầu, thu hồi và loại bỏ kết hợp nhãn.
Các bản tin NOTIFICATION, sử dụng để cung cấp các thông tin trợ giúp và thông tin lỗi tín hiệu.
Chạy trên TCP cung cấp phương thức phân phối bản tin đáng tin cậy (ngoại trừ các bản tin DISCOVERY)
Thiết kế cho phép khả năng mở rộng dễ dàng, sử dụng các bản tin được xác định như một tập hợp các đối tượng mã hoá TLV(Kiểu, độ dài, giá trị).
Mã hoá LTV nghĩa là mỗi đối tượng bao gồm một trường kiểu biểu thị về loại đối tượng chỉ định, một trường độ dài thông báo độ dài của đối tượng và một trường giá trị mà nó phụ thuộc vào trường kiểu. Các khả năng mới được thêm vào với các định nghĩa về kiểu mới. Hai trường đầu tiên có độ dài cố định và được đặt tại vị trí đầu tiên của đối tượng, điều này làm cho nó có thể dễ dàng thi hành việc loại bỏ kiểu đối tượng mà nó không nhận ra. Trường giá trị có một đối tượng có thể gồm nhiều đối tượng mã hoá TLV hơn.
Phát hiện LSR lân cận
Giao thức phát hiện LSR lân cận của LDP chạy trên UDP và làm việc như sau. Một LSR định kỳ gửi đi bản tin HELLO tới các cổng UDP trong tất cả các bộ định tuyến trong mạng con. Tất cả các LSR lắng nghe từ
Chất lượng dịch vụ trong MPLS
Chất lượng dịch vụ QoS chính là yếu tố điều khiển đằng sau MPLS. So sánh với các yếu tố khác, như quản lý lưu lượng và hỗ trợ VPN thì QoS không phải là lý do quan trọng nhất để triển khai MPLS. Như chúng ta sẽ thấy dưới đây, hầu hết các công việc được thực hiện trong MPLS QoS tập trung vào việc hỗ trợ các đặc tính của IP QoS trong mạng. Nó cách khác, mục tiêu là thiết lập sự giống nhau giữa các đặc tính QoS của IP và MPLS, chứ không phải là làm cho MPLS QoS chất lượng cao hơn IP QoS.
Một trong những lý do quan trọng mà MPLS hỗ trợ hơn là mở rộng mô hình IP QoS là MPLS, không giống như IP, không phải là giao thức end-to-end. MPLS không chạy trong các máy chủ, và tương lai là nhiều mạng IP không chạy MPLS vẫn tồn tại. QoS mặt khác thường có đặc tính end-to-end của liên kết giữa các LSR ngang hàng. Ví dụ, nếu một đường kết nối là đường end-to-end có độ trễ cao, độ mất mát lớn, băng thông thấp sẽ giới hạn QoS có thể cung cấp dọc theo tuyến đường end-to-end đó. Một cách khác nhìn nhận về vấn đề này là MPLS không thay đổi về căn bản mô hình dịch vụ IP. Các nhà cung cấp dịch vụ không bán dịch vụ MPLS, họ bán dịch vụ IP (hay dịch vụ Frame Relay hay các dịch vụ khác), và do đó, nếu họ đưa ra QoS thì họ phải đưa ra IP QoS (Frame Relay QoS, v.v..) chứ không phải là MPLS QoS.
Cung không thể nói rằng MPLS không có vai trò trong IP QoS. Thứ nhât, MPLS có thể giúp nhà cung cấp đưa ra các dịch vụ IP QoS hiệu quả hơn. Thứ hai, có một vài khả năng QoS mới có thể hỗ trợ qua mạng nhà cung cấp sử dụng MPLS không thực sự là end-to-end tuy nhiên có thể chứng tỏ là rất hữu ích, một trong số chúng là băng thông bảo đảm của LSP.
Do có mối quan hệ gần gũi giữa IP QoS và MPLS QoS, phần này sẽ được xây dựng xung quanh các thành phần chính của IP QoS. IP cung cấp hai mô hình QoS: Dịch vụ tích hợp (sử dụng chế độ đồng bộ với RSVP) và các dịch vụ khác nhau. Trong các phần nhỏ phía dưới chúng tôi sẽ đưa ra cái nhìn tổng quan về mỗi mô hình và mô tả về MPLS hỗ trợ các mô hình như thế nào. Và cuối cùng là khai báo tắc nghẽn thẳng (ECN) - một khả năng khác của IP mà được MPLS hỗ trợ.
Các dịch vụ tích hợp và RSVP
Tổng quan về các dịch vụ tích hợp
Thuật ngữ ‘Các dịch vụ tích hợp’ đề cập tới kiến trúc QoS tổng thể được IETF tạo ra vào giữa những năm 1990. Nhóm làm việc dịch vụ tích hợp phát triển kiến trúc này với mục tiêu cho phép sự bảo đảm QoS end-to-end cho những ứng dụng cần nó. Sự đảm bảo này sẽ đảm bảo rằng một ứng dụng cần lượng băng thông tối thiểu hoặc độ trễ end-to-end có thể có được.
Một phần kết quả của nhóm làm việc là đưa ra tiêu chuẩn kỹ thuật của một số lớp dịch vụ được thiết kế để đạt được những nhu cầu của một số lượng lớn các ứng loại ứng dụng khác nhau. Các tiêu chuẩn kỹ thuật này cũng định nghĩa xem RSVP(Resource Reservation Protocol) có thể được sử dụng như thế nào để đưa ra các yêu cầu QoS sử dụng những lớp dịch vụ này. RSVP được xây dựng trong một nhóm làm việc riêng, và những cố gắng lớn đã được thực hiện để đưa ra một sự phân biệt rõ ràng giữa Dịch vụ tích hợp và RSVP. Một cách cụ thể, 'Dịch vụ tích hợp' có thể cung cấp nhiều loại giao thức báo hiệu, RSVP chỉ là một trong số đó, và RSVP có thể báo hiệu rất nhiều loại thông tin khác nhau chứ không chỉ là các yêu cầu các dịch vụ tích hợp. Mặc dù có sự phân biệt rất rõ ràng này, rất nhiều người vẫn sử dụng thuật ngữ RSVP để đề cập đến toàn bộ kiến trúc QoS 'Các dịch vụ tích hợp'. Trong đề tài này chúng tôi sử dụng RSVP để đề cập tới một giao thức báo hiệu và 'Các dịch vụ tích hợp' là một kiến trúc QoS được định nghĩa do nhóm làm việc 'Các dịch vụ tích hợp'.
Kiến trúc 'Các dịch vụ tích hợp' bao gồm một số các thành phần bổ xung cho một giao thức báo hiệu. Nó cũng bao gồm một vài định nghĩa lớp dịch vụ. Một khía cạnh khác của kiến trúc là một ứng dụng có thể xác định loại lưu lượng sẽ đi vào mạng và mức QoS mà nó muốn nhận từ mạng. Tiêu chuẩn kỹ thuật lưu lượng viết tắt là TSpec, và yêu cầu mức QoS hay là yêu cầu tài nguyên mạng được viết tắt là RSpec. 'Các dịch vụ tích hợp' cũng yêu cầu các thành phần mạng như bộ định tuyến, tổng đài chuyển mạch để thi hành các chức năng khác nhau như:
- Chính sách: kiểm tra lưu lượng tuân thủ TSpec và thực hiện các hành động như loại bỏ gói tin nếu nó không tuân thủ.
- Điều khiển thu nạp: Kiểm tra để biết liệu có đủ tài nguyên để đáp ứng QoS từ chối yêu cầu nếu không đủ tài nguyên.
- Phân loại: nhận biết các gói tin cần các mức QoS cụ thể.
- Xếp hàng và lập danh mục: Đưa ra các quyeets định xem khi nào gói tin được truyền và gói tin nào bị loại bỏ điều này đảm bảo độ tin cậy với các yêu cầu QoS được thừa nhận.
Các lớp dịch vụ
Sau khi xem xét rất nhiều khả năng, nhóm làm việc 'Các dịch vụ tích hợp' định nghĩa hai lớp dịch vụ. Hai lớp dịch vụ này là ‘dịch vụ được bảo đảm’ và ‘tải điều khiển’. Các ứng dụng có thể lựa chọn yêu cầu mỗi trong số hai lớp dịch vụ này phụ thuộc vào liệu lớp dịch vụ nào đáp ứng nhu cầu của chúng.
‘Dịch vụ được bảo đảm’ có xu hướng phục vụ các nhu cầu của các ứng dụng đòi hỏi sự đảm bảo cao về băng thông và độ trễ. Để đạt được điều này, ứng dụng cung cấp một TSpec vạch trước giới hạn cho lưu lượng mà nó phát sinh, bao gồm những tham số như tốc độ tối đa, kích thước gói tin lớn nhất, burst size và “token bucket rate”. Burst size và token bucket rate bao gồm chỉ tiêu kỹ thuật token bucket đại diện cho các đặc tính băng thông của ứng dụng phát sinh dữ liệu với tốc độ thay đổi. Một luồng lưu lượng được định rõ đặc điểm nhờ token bucket của tốc độ r và burst size b nếu với bất cứ khoảng thời gian T nào nó không được gửi quá rT+b byte. Một cách trực giác hơn nghĩa là một luồng có thể gửi dữ liệu với tốc độ trung bình r byte/s nhưng thỉnh thoảng có thể gửi với tốc độ lớn hơn r nhưng dữ liệu bùng nổ tại tốc độ lớn hơn không được lơn hơn b byte.
Tham số quan trọng nhất trong RSpec ‘dịch vụ được bảo đảm’ là tốc độ dịch vụ, tham số này miêu tả tổng băng thông được cấp phát cho luồng lưu lượng. Bằng việc nhận biết tham số này, cộng với những tham số trong TSpec, cộng với các tham số khác, độ trễ lớn nhất có thể
Các dịch vụ khác
Khai báo tắc nghẽn thẳng
Quản lý lưu lượng trong MPLS
Bảo mật trong MPLS
Các ứng dụng của MPLS
Cải thiện chất lượng gửi chuyển tiếp gói tin trong mạng
Hỗ trợ QoS và CoS cho các dịch vụ khác nhau
Hỗ trợ khả năng mở rộng mạng
Tích hợp IP và ATM trong mạng
Xây dựng các mạng interoperable
Ứng dụng MPLS trong mạng VPN
Giới thiệu về MPLS trong VPN
Phần này mô tả cách tiếp cận cho việc xây dựng các dịch vụ IP VPN trong mạng xương sống của nhà cung cấp dịch vụ. Phổ biến có hai cách tiếp cận: mô hình lai ghép và cách tiếp cận bộ định tuyến ảo. Mô hình overlay dựa trên việc tải một vài các giao thức định tuyến hiện thời để mang thông tin.
Cách tiếp cận được đưa ra ở đây không phụ thuộc vào bất cứ sự thay đổi nào trong bất cứ giao thức định tuyến nào. Những phát kiến liên quan được nhắm tới trong quá trình sử dụng mạng LAN và đạt được nhờ sử dụng ARP. Đề tài này cố gắng phân biệt giữa SP và PNA: SP thì sở hữu và quản lý các dịch vụ lớp 1 và 2 trong khi các dịch vụ lớp 3 thì chịu sự quản lý của PNA. Bằng việc cung cấp các miền định tuyến độc lập logic, PNA mang lại khả năng mềm dẻo trong việc sử dụng địa chỉ cá nhân và địa chỉ chưa được đăng ký. Lợi dụng các LSP cá nhân và lợi dụng VPNID mà nó sử dụng các tập nhãn qua các LSP dùng chung, thì bảo mật dữ liệu không còn là vấn đề.
Cách tiếp cận trong tài liệu này dựa theo RFC2917 khác với được mô tả trong RFC 2547, trong đó không có một giao thức định tuyến cụ thể nào được chuyển tải để mang các tuyến VPN. RFC2547 xác định một cách cho phép thay đổi BGP để mang các tuyến unicast VPN qua mạng xương sống SP.
Các bộ định tuyến ảo trong MPLS VPN
Một bộ định tuyến ảo là một tập các thread, cả tĩnh và động trong thiết bị định tuyến, nó cung cấp các dịch vụ định tuyến và gửi chuyển tiếp giống các bộ định tuyến vật lý. Một bộ định tuyến ảo không nhất thiết là một tiến trình hệ thống vận hành riêng rẽ (mặc dầu nó có thể là như vậy); nó chỉ đơn giản là cung cấp ảo giác mà một bộ định tuyến dành riêng sẵn sàng thoả mãn những nhu cầu của mạng mà nó kết nối vào. Một bộ định tuyến ảo, giống như bản sao vật lý của nó, là một thành phần trong một miền định tuyến. Các bộ định tuyến khác trong miền này có thể là các bộ định tuyến vật lý hay ảo. Cho rằng bộ định tuyến ảo kết nối vào một miền định tuyến xác định và bộ định tuyến vật lý có thể hỗ trợ nhiều bộ định tuyến ảo, sẽ xảy ra hiện tượng một bộ định tuyến vật lý hỗ trợ nhiều miền định tuyến.
Từ quan điểm của khách hàng VPN, đòi hỏi một bộ định tuyến ảo phải tương đương với một bộ định tuyến vật lý. Nói cách khác, với rất ít ngoại lệ và những yếu tố thứ yếu, bộ định tuyến ảo nên thiết kế cho nhiều mục đích (cấu hình, quản lý, giám sát, xử lý sự cố) giống như các bộ định tuyến vật lý. Động cơ chính đằng sau những đòi hỏi này là để tránh việc nâng cấp hoặc cấu hình lại những cơ sở đã được cài đặt của các bộ định tuyến và để tránh phải đào tạo lại các nhà quản lý mạng.
Các khía cạnh của bộ định tuyến mà một bộ định tuyến ảo cần có là:
Cấu hình của bất cứ sự kết hợp giữa các giao thức định tuyến.
Giám sát mạng
Xử lý sự cố
Tất cả các VPN đều có miền định tuyến độc lập logic. Điều này tăng cường khả năng của SP cho phép cung cấp dịch vụ bộ định tuyến ảo hoàn toàn mềm dẻo mà nó có thể phục vụ các khách hàng của SP mà không cần đòi hỏi các bộ định tuyến vật lý cho VPN. Điều này có nghĩa là các đầu tư vào phần cứng của SP là các bộ định tuyến và các liên kết giữa chúng mà chúng có thể được các khách hàng sử dụng lại.
Các mục tiêu của MPLS VPN
Cấu hình của các điểm cuối VPN đơn giản, có khả năng mở rộng trong mạng nhà cung cấp dịch vụ. Ít nhất, một bộ phận cấu hình được đòi hỏi khi một CE được thêm vào.
Không sử dụng các tài nguyên của SP điều này hoàn toàn là duy nhất và khó có thể thu được các địa chỉ và mạng con IP.
Nhận viết các VR trong đám mây SP là động. Điều này là tuỳ chọn, nhưng là mục tiêu rất giá trị.
Các bộ định tuyến ảo nên được cấu hình đầy đủ và có khả năng giám sát bởi các nhà quản trị mạng VPN. Điều này mang lại cho PNA khả năng mềm dẻo trong cả việc cấu hình VPN và nhiệm vụ cấu hình tài nguyên bên ngoài cho SP.
Chất lượng của gửi chuyển tiếp dữ liệu nên được cấu hình trong các cơ sở VPN-by-VPN. Nó được biên dịch sang GoS liên tục (hoặc rời rạc). Ví dụ như băng thông riêng, QOS, và cách chính sách dựa trên các dịch vụ gửi chuyển tiếp.
Các dịch vụ khác nhau nên được cấu hình trong các cơ sở VPN-by-VPN, có lẽ dựa trên các LSP thiết lập cho mục đích gửi chuyển tiếp dữ liệu trong VPN.
Bảo mật của các bộ định tuyến internet được mở rộng cho các bộ định tuyến ảo. Điều này có nghĩa là các chức năng định tuyến và gửi chuyển tiếp dữ liệu của bộ định tuyến ảo được bảo mật như bộ định tuyến vật lý. Ở đây có không có hiện tượng lộ thông tin từ một miền định tuyến sang miền khác.
Các giao thức định tuyến xác định không nên được áp dụng giữa các bộ định tuyến ảo. Điều này khó đảm bảo các khách hàng VPN có thể thiết lập mạng và các chính sách khi các khách hàng thấy phù hợp. Ví dụ, một vài giao thức mạnh trong công việc lọc, trong khi đó các loại khác lại mạnh trong việc xử lý lưu lượng. Các khách hàng VPN có thể muốn khai thác cả hai để thu được chất lượng mạng tốt nhất.
Không có những mở rộng đặt biệt với các giao thức định tuyến như BGP, RIP, OSPF, ISIS v.v.. Khó có thể cho phép những bổ xung cho các dịch vụ hiện có khác trong tương lai như NHRP và multicast. Thêm vào đó, sự tiến bộ và các phần bổ xung cho các giao thức hiện có (như mở rộng về xử lý lưu lượng cho ISIS và OSPF), chúng có thể dễ dàng kết hợp vào một VPN implementation.
Những yêu cầu về kiến trúc MPLS VPN
Mạng cung cấp dịch vụ phải chạy một vài mô hình định tuyến multicast cho tất cả các nút sẽ có các kết nối VPN và cho các nút phải gửi chuyển tiếp các gói tin multicast cho việc phát hiện bộ định tuyến ảo. Một giao thức định tuyến multicast cụ thể không được uỷ thác. Một SP có thể chạy MOSPF hoặc DVMRP hoặc các giao thức định tuyến khác.
Phác thảo về kiến trúc MPLS VPN
Tất cả các VPN được ấn định một VPNID và nó là duy nhất trong mạng SP. Nhận dạng này xác định chính xác một VPN mà với nó một gói tin hoặc một kết nối được kết hợp. VPNID giá trị 0 được dự trữ; nó liên kết với mạng Internet công cộng và đại diện cho mạng internet công cộng. Điều này đã được khuyến nghị, nhưng không yêu cầu các nhận dạng VPN này sẽ tuân theo RFC2685.
Dịch vụ VPN được đưa ra theo dạng dịch vụ bộ định tuyến ảo. Những VR đặt tại SPED và được hạn chế tới biên của đám mây SP. Các VR sẽ sử dụng mạng SP cho dữ liệu và điều khiển gửi chuyển tiếp gói tin nhưng mặt khác nó là vô hình phía ngoài các SPED.
Kích thước của VR giao ước với VPN trong một SPED cho trước được biểu diễn bằng số lượng tài nguyên IP như các giao diện định tuyến, các bộ lọc tuyến, các lối vào định tuyến v.v.. Điều này hoàn toàn nằm dưới sự điều khiển của SP và cung cấp granularity mà SP yêu cầu để cung cấp các lớp dịch vụ VR khởi đầu trong một mức SPED. (ví dụ: một SPED có thể là điểm tổng hợp cho một VPN và số các SPED khác có thể là điểm truy cập) Trong trường hợp này, SPED kết nối với sở chỉ huy có thể được giao kèo để cung cấp một VR lớn trong khi SPED kết nối với các đơn vị nhánh có thể nhỏ. Cung cấp này cũng cho phép SP thiết kế mạng với mục tiêu cuối cùng là phân phối tải giữa các bộ định tuyến trong mạng.
Một dấu hiệu chỉ thị cho kích thước của VPN là số SPED trong mạng SP có kết nối tới các bộ định tuyến CPE trong VPN đó. Về khía cạnh này, một VPN với rất nhiều các vị trí cần được kết nối là một VPN lớn trong khi một VPN với một vài vị trí là VPN nhỏ. Cũng vậy, có thể hiểu được rằng VPN phát triển hay thu hẹp lại về kích thước theo thời gian. Các VPN thậm chí có thể hợp nhất để kết hợp các nhà liên kết, khả năng lĩnh hội và các thoả thuận hợp tác. Những thay đổi này rất phù hợp trong kiến trúc này, khi các tài nguyên IP duy nhất không được ấn định cho các VPN. Số SPED không được giới hạn bởi bất cứ những giới hạn về cấu hình giả tạo nào.
SP sở hữu và quản lý các thực thể lớp 1 và lớp 2. Một cách chi tiết, SP điều khiểncác tổng đài chuyển mạch và các bộ định tuyến vật lý, các đường liên kết vật lý, các kết nối logic lớp 2 (như DLCI trong FrameRelay và VPI/VCI trong ATM) và LSP (và cả ấn định của chúng cho các VPN cụ thể). Trong phạm vi của VPN, SP có trách nhiệm, kết hợp và ấn định các thực thể lớp 2 cho các VPN cụ thể.
Các thực thể lớp 3 thuộc quyền quản lý của PNA. Các ví dụ về thực thể lớp 3 bao gồm các giao diện IP, sự lựa chọn các giao thức định tuyến động hoặc các tuyến tĩnh, và các giao diện định tuyến. Chú ý rằng mặc dù cấu hình lớp 3 về mặt logic là đặt dưới trách nhiệm của PNA, nhưng không nhất thiết PNA phải thi hành nó. Điều này có thể thực hiện được cho PNA để đẩy quyền quản lý IP của các bộ định tuyến ảo tới các nhà cung cấp dịch vụ. Không chú ý tới ai chịu trách nhiệm cho việc cấu hình và giám sát, cách tiếp cận này cung cấp cái nhìn đầy đủ về miền định tuyến cho PNA và cho phép PNA thiết kế mạng để đạt được mục tiêu về intranet, extranet và xử lý lưu lượng.
VPN có thể được quản lý như các bộ định tuyến vật lý hơn là các bộ định tuyến ảo được triển khai. Do đó, việc quản lý có thể được thi hành sử dụng SNMP hoặc các phương thức tương tự khác hoặc trực tiếp tại VR console (VRC)
Các công cụ xử lý lỗi chuẩn như ‘ping’, ‘traceroute’ trong miền định tuyến bao gồm các bộ định tuyến vật lý dành riêng. Do đó, việc giám sát và xử lý lỗi có thể được thi hành sử dụng SNMP hoặc các phương thức tương tự, nhưng có thể bao gồm việc sử dụng các công cụ chuẩn này. Một lần nữa, VRC có thể được sử dụng cho mục đích này giống như bất cứ bộ định tuyến vật lý nào.
Từ khi VRC là hữu hình với người sử dụng, việc kiểm tra bảo mật bộ định tuyến cần phải được đặt đúng vị trí để đảm bảo người sử dụng VPN được cho phép truy cập vào các tài nguyên lớp 3 chỉ trong VPN đó và không được phép truy cập vào các tài nguyên vật lý trong bộ định tuyến. Hầu hết các bộ định tuyến đạt được điều này thông qua việc sử dụng các quan điểm về cơ sở dữ liệu.
VCR cũng luôn sẵn sàng với SP. Nếu cấu hình và giám sát bị đẩy tới SP, SP có thể sử dụng VRC để thực hiện các nhiệm vụ này nếu nó là PNA.
Các VR trong các SPED hình thành VPN trong mạng SP. Đồng thời chúng đại diện cho miền định tuyến ảo. Chúng phát hiện các VR khác một cách tự động bằng cách sử dụng mạng LAN mô phỏng trong mạng SP.
Mỗi VPN trong mạng SP được ấn định một và chỉ một địa chỉ multicast. Địa chỉ này được lựa chọn từ phạm vi áp dụng quản lý và yêu cầu duy nhất là địa chỉ multicast có thể được xắp xếp đơn nhất vào một VPN cụ thể. Điều này có thể thực hiện tự động một cách dễ dàng trong các bộ định tuyến nhờ việc sử dụng các chức năng đơn giản để xắp xếp chính xác một VPNID cho một địa chỉ multicast. Địa chỉ multicast này cho phép một VR có thể nhận biết các VR khác và được các VR khác nhận biết. Chú ý rằng địa chỉ multicast không nhất thiết phải được cấu hình.
Việc gửi chuyển tiếp dữ liệu có thể được thực hiện theo một trong các cách sau:
Một LSP với các đặc tính hiệu quả nhất mà tất cả các VPN có thể sử dụng
Một LSP dành riêng cho một VPN và lưu lượng được xử lý thông qua các khách hàng VPN.
Một LSP cá nhân với các đặc tính khác nhau.
Chính sách dựa trên việc gửi chuyển tiếp trên kênh ảo L2 dành riêng.
Lựa chọn phương pháp tốt hơn có thể được dàn xếp giữa SP và khách hàng VPN, có thể là một phần của SLA giữa chúng. Điều này cho phép SP đưa ra các mức dịch vụ khác nhau cho các khách hàng VPN khác nhau.
Tất nhiên, việc gửi chuyển tiếp hop-by-hop cũng sẵn sàng để gửi các gói tin định tuyến và để gửi chuyển tiếp các gói tin dữ liệu người sử dụng trong các quá trình LSP thiết lập và hỏng.
Phương pháp tiếp cận này không uỷ thác các nhiệm vụ hệ thống vận hành riêng rẽ cho mỗi giao thức định tuyến nào được chạy cho mỗi VR và SPED cư trú. Các quá trình thực hiện cụ thể có thể đáp ứng nhu cầu của SPED cụ thể đang được sử dụng. Bảo dưỡng các cơ sở dữ liệu định tuyến và các bảng gửi chuyển tiếp, mỗi một cơ sở dữ liệu và bảng cho một VR, là một cách để thu được chất lượng tốt nhất cho SPED cho trước.
MPLS đóng vai trò cơ chế gửi chuyển tiếp
Chúng ta sẽ xem xét xem sử dụng BGP như thế nào để xây dựng tất cả các bộ định tuyến, thậm chí với các địa chỉ IP không duy nhất. Tuy nhiên vấn đề với việc sử dụng những bộ định tuyến này là khả năng thu thập thông tin được biểu diễn không phải dưới dạng địa chỉ IP mà dưới dạng địa chỉ VPN-IP. Và ở đây không có gì trong mào đầu IP để mang địa chỉ VPN-IP, như vậy làm thế nào để gửi chuyển tiếp các gói tin IP dọc theo các bộ định tuyến này.
Để cung cấp việc gửi chuyển tiếp các gói tin IP dọc theo các bộ định tuyến được biểu diễn dưới thuật ngữ địa chỉ VPN-IP, chúng ta sử dụng MPLS. Lý do mà MPLS giúp chúng ta làm được điều này là vì nó tách riêng thông tin sử dụng cho việc gửi chuyển tiếp tói tin với thông tin mang trong mào đầu IP. Do vậy, chúng ta có thể kết hợp LSP với các bộ định tuyến VPN-IP và sau đó gửi chuyển tiếp các gói tin IP dọc theo những bộ định tuyến đó sử dụng MPLS đóng vai trò cơ chế gửi chuyển tiếp. Nhận thấy là từ khi các địa chỉ VPN-IP bị hạn chế với nhà cung cấp dịch vụ, MPLS cũng có thể bị hạn chế đối với nhà cung cấp dịch vụ.
Để minh hoạ việc gửi chuyển tiếp được thực hiện như thế nào, đầu tiên xem xét một ví dụ được biểu diễn trong Hình III1. Chú ý là theo quan điểm MPLS thì bộ định tuyến PE chính là LSR biên. Tức là bộ định tuyến PE chuyển các gói tin không dán nhãn thành các gói tin dán nhãn và ngược lại.
Khi một bộ định tuyến CE gửi một gói tin IP tới bộ định tuyến PE, bộ định tuyến PE sử dụng cổng lối vào (giao diện mà bộ định tuyến PE nhận gói tin) để xác định VPN mà bộ định tuyến CE trực thuộc và xác định chính xác bảng gửi chuyển tiếp (còn gọi là cơ sở thông tin gửi chuyển tiếp hay FIB) liên kết với VPN đó. Một khi FIB đã được xác định, bộ định tuyến PE thi hành việc tìm kiếm địa chỉ IP bình thường trong FIB này, sử dụng địa chỉ đích trong gói tin. Kết quả của việc tìm kiếm trong FIB là bộ định tuyến PE thêm các thông tin nhãn phù hợp vào gói tin và gửi chuyển tiếp nó đi.
Hình III1 Dán nhãn tại bộ định tuyến PE
Để cải thiện các tính chất mở rộng củ cách tiếp cận này, chúng ta áp dụng hệ thống phân cấp thông tin định tuyến. Nhờ sử dụng công nghệ này,không có bộ định tuyến P nào duy trì thông tin định tuyến VPN, điều này giảm tải định tuyến trên các bộ định tuyến. Để thi hành hệ thống phân cấp thông tin định tuyến, chúng ta sử dụng không chỉ một mà hai mức nhãn, ở đây nhãn mức một kết hợp với bộ định tuyến PE lối ra, và do đó có thể gửi chuyển tiếp từ bộ định tuyến PE lối vào tới bộ định tuyến PE lối ra. Nhãn mức hai có thể được phân phối hoặc là qua LDP hoặc nếu nhà cung cấp dịch vụ muốn sử dụng điều khiển lưu lượng thì có thể qua RSVP hoặc CR-LDP. Nhãn mức hai được phân phối qua BGP cùng với các bộ định tuyến VPN-IP.
Chú ý là tuyến đường VPN-IP được phân phối qua BGP mang thuộc tính hop tiếp theo, địa chỉ của bộ định tuyến PE khởi đầu tuyến đường, và tuyến đường tới địa chỉ hop tiếp theo đó được cung cấp qua các thủ tục định tuyến trong miền của nhà cung cấp. Do vậy, chúng ta có thể nhận thấy rằng đó chính là thông tin được mang trong thuộc tính hop tiếp theo mà nó cung cấp sự móc nối giữa thông tin định tuyến trong miền và các tuyến VPN.
Để minh hoạ xem chúng ta sử dụng hệ thống phân cấp thông tin định tuyến MPLS như thế nào, xem xét ví dụ trong hình . Ví dụ biểu diễn hai vùng trong một VPN, ở đây mỗi vùng đại diện bằng một bộ định tuyến CE (CE1 và CE2). Cả PE1 và PE2 được cấu hình với Route Distinguisher phù hợp được sử dụng cho VPN đó, cũng như với BGP Community phù hợp được sử dụng khi xuất các tuyến đường tới BGP của nhà cung cấp và khi nhập các tuyến đường từ BGP nhà cung cấp. Trong PE1 giao diện kết nối PE1 với CE1 được liên kết với một bảng định tuyến của VPN đó.
Hình III2. Sử dụng tập nhãn hai mức (trang 230MPLS)
Khi PE2 nhận một tuyến đường từ CE2 với thông tin đích là 10.1.1/24, PE2 chuyển thông tin đích của tuyến đường đó từ địa chỉ IP sang địa chỉ VPN-IP, kết hợp với thuộc tính BGP Community, và xuất tuyến dường này vào BGP nhà cung cấp. thuộc tính BGP hop tiếp theo của tuyến đường này được đặt địa chỉ của PE2. Thêm vào tất cả thông tin BGP truyền thống, tuyến đường cũng mang một nhãn đại diện cho tuyến VPN-IP đó. Thong tin này được phân phối tới PE1 sử dụng BGP (đường chấm chấm). Khi PE1 nhận một tuyến đường, PE1 chuyển tuyến đường từ VPN-IP sang IP và sử dụng nó để xác định bảng gửi chuyển tiếp của VPN đó.
Hơn nữa, có một LSP từ PE1 tới PE2, nó liên kết với tuyến đường tới PE2 và được thiết lập và duy trì nhờ LDP hoặc quản lý lưu lượng MPLS. Chú ý là tuyến đường phân phối qua BGP, như là thuộc tính hop tiếp theo, điạc chỉ của PE2, và tuyến đường tới địa chỉ đó được cung cấp thông qua định tuyến trong miền nhà cung cấp. Vì vậy địa chỉ của PE2 (mang trong thuộc tính hop tiếp theo) cung cấp móc nối giữa định tuyến nhà cung cấp (định tuyến tới PE2) và các tuyến VPN (định tuyến tới 10.1.1/24). Tại điểm này bảng gửi chuyển tiếp VPN trên PE1 chứa một tuyến đường cho 10.1.1/24 và một tập nhãn mà nhãn phía trong là nhãn mà PE1 nhận qua BGP và nhãn phía ngoài là nhãn đại diện cho tuyến đường tới PE2.
Xem rằng CE1 gửi một gói tin với địa chỉ đích là 10.1.1.1. Khi gói tin tới PE1, PE1 lựa chọn bảng gửi chuyển tiếp phù hợp và sau đó thi hành việc tìm kiếm trong bảng đó. Kết quả của việc tìm kiếm đó, PE1 kết hợp hai nhãn với gói tin và gửi gói tin tới P1. P1 sử dụng nhãn phía ngoài khi đưa ra quyết định gửi chuyển tiếp và gửi gói tin đó tới P2. P2 là hop kề cuối theo kía cạnh LSP đại diện cho tuyến tới PE2, P2 đẩy nhãn phía ngoài trước khi gửi gói tin tới PE2. Khi PE2 nhận gói tin nó sử dụng nhãn mang trong gói tin (nhãn mà PE2 phân phối tới PE1 qua BGP) để đưa ra quyết định gửi chuyển tiếp. PE2 loại bỏ nhãn và gửi gói tin tới CE2.
Để đánh giá được lợi ích của khả năng mở rộng của hệ thống phân cấp thông tin định tuyến, xem xét vị dụ mạng nhà cung cấp dịch vụ gồm 200 bộ định tuyến (cả PE và P), hỗ trợ 10000 VPN, mỗi VPN có trung bình 100 bộ định tuyến. Không sử dụng hệ thống phân cấp thông tin định tuyến MPLS, mỗi bộ định tuyến P cần duy trì thông tin 10000x100=1000000 tuyến đường. Với hệ thống phân cấp thông tin định tuyến MPLS, mỗi bộ định tuyến cần duy trì chỉ 200 tuyến.
Cấu hình MPLS VNP có thể mở rộng
Một VPN điển hình phải có hàng trăm tới hàng nghìn điểm cuối trong một đám mây SP. Do đó, cấu hình nên mở rộng một cách tuyến tính về số lượng các điểm cuối. Một cách cụ thể, nhà quản trị mạng phải thêm một cặp các mục cấu hình khi một khách hàng mới gia nhập vào tập các VR hình thành nên VPN. Bất cứ thứ gì kém hơn sẽ làm cho nhiệm vụ này trở nên khó khăn đối với nhà cung cấp dịch vụ. Trong kiến trúc này, tất cả những thứ mà các nhà cung cấp dịch vụ cần phải cấp phát và cấu hình là các đường liên kết vật lý vào/ra (ví dụ như Frame Relay DLCI hoặc ATM VPI/VCI) và các kết nối ảo giữa VR và mạng LAN.
Nhận biết các bộ định tuyến lân cận động trong MPLS VPN
Các VR trong một VPN cho trước thuộc về một số các SPED trong mạng. Những VR này cần phải nhận biết về mỗi VR khác và phải được kết nối với các VR khác.
Một cách để thực hiện điều này là yêu cầu cấu hình của các VR lân cận. Ví dụ, khi một vùng mới được thêm vào VPN, điều này đòi hỏi cấu hình của tất cả các VR khác như là các VR lân cận. Điều này rõ ràng là không thể mở rộng được trên quan điểm tài nguyên mạng và cấu hình.
Nhu cầu tăng lên để cho phép những VR này nhận biết động mỗi VR khác. Phương pháp nhận biết các bộ định tuyến lân cận được làm cho thuận tiện bằng việc cung cấp cho mỗi VPN một mạng LAN mô phỏng giới hạn. Mạng LAN mô phỏng này được sử dụng theo vài cách:
Giải quyết địa chỉ sử dụng mạng LAN này để quyết định các địa chỉ IP hop kế tiếp liên kết với các VR khác.
Các giao thức định tuyến như RIP và OSPF sử dụng mạng LAN mô phỏng giới hạn cho việc nhận biết các VR lân cận và để gửi các cập nhật định tuyến.
Mạng LAN (cho mỗi VPN) được mô phỏng sử dụng địa chỉ multicast IP. Trong tầm quan trọng của việc duy trì không gian địa chỉ công cộng và vì điều này mà địa chỉ multicast cần được xác định chỉ trong không gian mạng SP.
Chúng ta sử dụng một địa chỉ từ các địa chỉ multicast trong phạm vi một tổ chức. Mỗi VPN được cấp phát một địa chỉ từ tập địa chỉ đó. Để loại trừ hoàn toàn cấu hình trong phần xem xét này, địa chỉ này được tính toán từ VPNID.
Bộ định tuyến A
151.0.0.1
Bộ định tuyến C
151.0.0.3
Bộ định tuyến B
151.0.0.2
Cấu hình miền VPN IP
Hình III1 Miền định tuyến vật lý
Miền định tuyến vật lý trong mạng SP được biểu diễn trong hình trên. Trong mạng này, các bộ định tuyến vật lý A, B và C được kết nối với nhau. Mỗi trong số các bộ định tuyến có một địa chỉ IP ‘công cộng’ được ấn định cho nó. Những địa chỉ này xác định duy nhất mỗi trong số các bộ định tuyến trong mạng SP.
Bộ định tuyến A
151.0.0.1
Bộ định tuyến C
151.0.0.3
Bộ định tuyến B
151.0.0.2
Bộ định tuyến ảo B
10.0.0.2/24
Bộ định tuyến ảo A
10.0.0.1/24
Bộ định tuyến ảo C
10.0.0.3/24
172.150.0/18
172.150.128/18
Phần cơ sở dữ liệu
172.150.128.1
172.150.64/18
Nhà cung cấp sản phẩm
Hình III2 Miền định tuyến ảo
Mỗi bộ định tuyến ảo được cấu hình nhờ PNA khi đi qua nó là một bộ định tuyến vật lý cá nhân. Tất nhiên, SP giới hạn các tài nguyên mà bộ định tuyến ảo này có thể tiêu thụ trên các cơ sở SPED-by-SPED. Mỗi VPN có một số các kết nối vật lý (tới các bộ định tuyến CPE) và một số các kết nối logic (tới mạng LAN mô phỏng). Mỗi kết nối là kết nối IP và có thể được cấu hình để sử dụng bất cứ kết hợp giữa các giao thức định tuyến chuẩn và các chính sách định tuyến để đạt được mục tiêu mạng hợp nhất cụ thể.
Để minh hoạ, trong Hình III2, ba VR đặt trong ba SPED trong VPN1. Bộ định tuyến A nằm trong VR-A, bộ định tuyến B nằm trong VR-B và bộ định tuyến C nằm trong VR-C, VR-C và VR-B có một kết nối tới các thiết bị CPE, trong khi VR-A có hai kết nối vật lý. Mỗi trong số các VR có kết nối logic IP tới ban điều hành công ty và chạy OSPF qua các kết nối này. Do đó, nó có thể định tuyến các gói tin tới 172.150.0/18 và 172.150.128/18. VR-B chạy RIP tại văn phòng chi nhánh (qua kết nối vật lý) và sử dụng RIP (qua kết nối logic) để xuất 172.150.64/18 tới VR-A. VR-A thông báo một tuyến mặc định tới VR-B qua kết nối logic. Nhà cung cấp sử dụng VR-C như kết nối extranet để kết nối tới cơ sở dữ liệu tại 172.150.128.1. Do đó, VR-C thông báo một tuyến mặc định tới VR-A qua đường kết nối logic. VR-A chỉ xuất 175.150.128.1 tới VR-C. Điều này giữ phần còn lại của mạng khỏi những vấn đề về bảo mật.
Nhà quản trị mạng sẽ cấu hình những thứ như sau:
Các kết nối OSPF tới mạng 172.150.0/18 và mạng 172.150.128/18 trong VR-A
Các kết nối RIP tới VR-B và VR-C trong VR-A
Các chính sách định tuyến trong VR-A để thông báo chỉ một tuyến mặc định tới VR-B
Các chính sách định tuyến trong VR-A để thông báo chỉ 172.150.128.1 tới VR-C
RIP trong VR-B tới VR-A
RIP trong VR-C để thông báo một tuyến mặc định tới VR-A.
Ví dụ về phương pháp nhận biết các bộ định tuyến lân cận
Trong Hình III1, SPED trong VR-A (SPED-A) sử dụng địa chỉ của 150.0.0.1/24, SPED-B sử dụng 150.0.0.2/24 và SPED-C sử dụng 150.0.0.3/24. Chú ý rằng kết nối giữa các VR là thông qua mạng LAN mô phỏng. Cho các địa chỉ giao diện trong kết nối mạng LAN mô phỏng, VR-A sử dụng 10.0.0.1/24, VR-B sử dụng 10.0.0.2/24 và VR-C sử dụng 10.0.0.3/24.
Bây giờ quan tâm tới việc VR-A gửi gói tin tới VR-B. Để thu được địa chỉ của VR-B (Địa chỉ của SPED-B), VR-A gửi một gói tin yêu cầu ARP với địa chỉ của VR-B (10.0.0.2) như địa chỉ logic. Địa chỉ logic nguồn là 10.0.0.1 và địa chỉ phần cứng là 151.0.0.1. Yêu cầu ARP này được tóm lược trong địa chỉ multicast của VPN này và gửi ra. SPED-B và SPED-C nhận một bản sao của gói tin. SPED-B nhận ra 10.0.0.2 trong phạm vi VPN1 và đáp ứng với 152.0.0.2 như địa chỉ phần cứng. Đáp ứng này được gửi tới địa chỉ multicast VPN để đề xướng cách sử dụng ARP không phân loại giúp giảm lưu lượng trong mạng.
Cấu hình thông thường sẽ cần thiết nếu phương pháp nhận biết bộ định tuyến lân cận không được sử dụng. Trong ví dụ này, VR-A sẽ được cấu hình với lối vào ARP tĩnh cho địa chỉ logic của VR-B (10.0.0.1) với địa chỉ phần cứng được đặt là 152.0.0.2.
Gửi chuyển tiếp trong MPLS VPN
Như được đề cập trong phác thảo về kiến trúc, gửi chuyển tiếp dữ liệu có thể được thực hiện theo một vài cách. Trong tất cả các công nghệ ngoại trừ công nghệ Hop-by-Hop cho việc gửi chuyển tiếp các gói tin định tuyến/điều khiển, các phương thức hiện thời đều có thể cấu hình được. Tại điểm cuối, giải quyết dựa trên việc gửi chuyển tiếp cho dịch vụ nhanh và tại điểm khác, việc gửi chuyển tiếp hiệu quả tốt nhất sử dụng LSP công cộng được áp dụng. Trật tự ưu tiên gửi chuyển tiếp như sau:
Chính sách dựa trên việc gửi chuyển tiếp
LSP cá nhân cấu hình tuỳ chọn
LSP công cộng hiệu quả cao.
LSP cá nhân
LSP này được cấu hình tuỳ chọn trong các cơ sở VPN. LSP này thường kết hợp với việc dự trữ trước băng thông và với các dịch vụ khác nhau riêng biệt hoặc lớp QOS. Nếu LSP này sẵn sàng, nó được sử dụng cho dữ liệu người sử dụng và cho việc gửi chuyển tiếp dữ liệu điều khiển cá nhân VPN.
LSP công cộng hiệu quả cao
Các gói tin VPN được gửi chuyển tiếp sử dụng LSP này nếu LSP cá nhân với băng thông xác định và các đặc tính QOS hoặc không được cấu hình hoặc hiện tại không sẵn sàng. LSP được sử dụng là một LSP được tính trước cho bộ định tuyến lối ra trong VPN0. VPNID trong mào đầu chèn thêm được sử dụng để phân các gói dữ liệu từ các VPN khác nhau tại bộ định tuyến lối ra.
Các dịch vụ khác nhau trong MPLS VPN
Việc cấu hình các LSP cá nhân cho các VPN cho phép SP đưa ra những dịch vụ khác nhau dành cho các khác hàng. Những LSP cá nhân này có thể được kết hợp với bất cứ lớp QOS L2 nào có sẵn hoặc với các điểm mã dịch vụ. Trong một VPN, nhiều LSP cá nhân với các lớp dịch vụ khác nhau có thể được cấu hình với các thông tin luồng cho việc sắp xếp các gói tin trong các LSP. Đặc tính này, cùng với khả năng thay đổi kích thước các bộ định tuyến ảo, cho phép SP cung cấp các dịch vụ hoàn toàn khác nhau tới các khách hàng VPN.
Vấn đề bảo mật trong MPLS VPN
Bảo mật định tuyến
Sử dụng các giao thức định tuyến chuẩn như OSPF và BGP theo hình thức không thay đổi của chúng có nghĩa là tất cả các các phương thức mã hoá và bảo mật (Như xác nhận MD5 của các bộ định tuyến lân cận) là hoàn toàn có sẵn trong các VR. Đảm bảo rằng các tuyến này không bị rò rỉ thông tin từ một VPN tới các VPN khác là một vấn đề phải được thực hiện. Một cách để đạt được điều này là duy trì các cơ sở dữ liệu định tuyến và gửi chuyển tiếp.
Bảo mật dữ liệu
Điều này cho phép SP đảm bảo với các khách hàng VPN rằng tất cả các gói tin dữ liệu trong một VPN không bao giờ đi chệch đường sang VPN khác. Từ quan điểm định tuyến, điều này có thể đạt được bằng việc duy trì các cơ sở dữ liệu định tuyến riêng biệt cho mỗi bộ định tuyến ảo. Từ quan điểm gửi chuyển tiếp dữ liệu, sử dụng các tập nhãn trong trường hợp các LSP dùng chung hoặc sử dụng các LSP cá nhân đảm bảo bảo mật dữ liệu. Các bộ lọc gói tin cũng có thể được cấu hình để giúp đỡ làm các vấn đề trở nên dễ dàng hơn.
Bảo mật cấu hình
Các bộ định tuyến ảo được xem như các bộ định tuyến vật lý đối với PNA. Điều này có nghĩa là chúng có thể được PNA cấu hình để có được kết nối giữa các văn phòng của một tập đoàn. Rõ ràng, SP phải đảm bảo rằng chỉ có PNA và các nhà thiết kế của PNA, những người truy cập tới các VR trên SPED trong mạng cá nhân, là có được các kết nối tới chúng. Kể từ khi bộ định tuyến ảo cân bằng về mặt chức năng với bộ định tuyến vật lý, tất cả các phương thức xác nhận có thể dùng trong phạm vi vật lý như khẩu lệnh, RADIUS là dùng được trong PNA.
Bảo mật mạng vật lý
Khi một PNA truy cập vào một SPED để cấu hình hoặc giám sát VPN, PNA đó được truy cập vào VR của VPN. PNA chỉ có quyền cấu hình và giám sát lớp 3 cho VR. Cụ thể PNA không có quyền cấu hình cho mạng vật lý. Điều này đảm bảo cho SP rằng nhà quản trị VPN sẽ không thể tác động đến mạng SP.
Giám sát bộ định tuyến ảo trong MPLS VPN
Tất cả các đặt tính giám sát bộ định tuyến dùng trong bộ định tuyến vật lý có thể dùng được trong bộ định tuyến ảo. Điều này bao gồm các công cụ như “ping” “traceroute”. Thêm vào đó, khả năng hiển thị bảng định tuyến cá nhân, cơ sở dữ liệu trạng thái liên kết, v.v.. cũng sử dụng được.
Hỗ trợ QoS trong MPLS VPN
Trong phần này chúng ta sẽ xem xét các cơ cấu mà SP sử dụng để thi hành các khía cạnh QoS. Trong phạm vi QoS, đòi hỏi phải phát triển các cơ cấu hỗ trợ QoS theo cách đủ độ mềm dẻo để hỗ trợ nhiều loại khác hàng VPN khác nhau. Ví dụ SP có thể đưa ra cho các khách hàng VPN của mình các CoS cho mỗi VPN, các ứng dụng khác nhau trong cùng một VPN có thể nhận các CoS khác nhau. Theo cách nay, dịch vụ email có thể có một CoS trong khi một vài ứng dụng thời gian thực khác có thể có các CoS khác nhau. Hơn nữa, CoS mà một ứng dụng nhận được trong một VPN có thể khác so với CoS mà một ứng dụng như vậy có thể nhận được trong VPN khác. Tức là, một tập các cơ chế hỗ trựo QoS cho phép quyết định dữ liệu nào nhận CoS nào. Hơn nữa, không phải tất cả các VPN phải sử dụng tất cả các CoS mà một nhà cung cấp dịch vụ VPN đưa ra. Do đó, một tập các cơ chế hỗ trợ QoS cho phép quyết định lại CoS nào được sử dụng để tạo ra các cơ sở per-VPN.
Trước khi mô tả các cơ chế được sử dụng trong BGP/MPLS VPN để hỗ trợ QoS, chúng ta xem xét hai mô hình được sử dụng để mô tả QoS trong phạm vi VPN là mô hình ‘pipe’ và mô hình ‘hose’.
Trong mô hình ‘pipe’ một nhà cung cấp dịch vụ VPN cung cấp cho một khách hàng VPN một QoS cố định đảm bảo cho dữ liệu đi từ một bộ định tuyến CE của khách hàng tới các bộ định tuyến CE khác. Về một ý nghĩa nào đó thì ta có thể hình dung mô hình này như một đường ống mà nó kết nối hai bộ định tuyến với nhau, và lưu lượng giữa hai bộ định tuyến trong đường ống này có những giá trị QoS xác định. Ví dụ về một loại QoS có thể được cung cấp trong mô hình ‘pipe’ là giá trị băng thông nhỏ nhất giữa hai vùng.
Ta có thể cải tiến mô hình ‘pipe’ bằng việc tạo một tập con của tất cả các lưu lượng từ một CE tới các CE khác có thể sử dụng đường ống. Quyết định cuối cùng lên lưu lượng nào có thể sử dụng đường ống mang ý nghĩa cục bộ đối với bộ định tuyến PE tại đầu ống.
Chú ý là mô hình ‘pipe’ khá giống với mô hình QoS mà các khác hàng VPN có được hiện nay với các giải pháp dựa trên FrameRelay hoặc ATM. Sự khác nhau căn bản là với ATM hay FrameRelay thì kết nối theo hai hướng trong khi trong mô hình ‘pipe’ cung cấp kết nối theo một hướng. Trên thực tế đường ống là đơn hướng không đối xứng tương ứng với kiểu lưu lượng, do đó tổng lưu lượng từ một vùng tới vùng khác có thể khác với tổng lưu lượng theo hướng ngược lại.
Hình III1 Mô hình pipe QoS
Xem xét ví dụ biểu diễn trên Error! Reference source not found., ở đây nhà cung cấp dịch vụ cung cấp cho VPN A một đường ống đảm bảo băng thông 7Mb/s cho lưu lượng từ vùng 3 đến vùng 1 và một đường ống khác đảm bảo băng thông 10Mb/s cho lưu lượng từ vùng 3 đến vùng 2. Nhận thấy rằng bộ định tuyến CE có thể có nhiều hơn một ống xuất phát từ nó (ví dụ có hai ống xuất phát từ vùng 3). Cũng như vậy, có thể có hơn một ống kết thúc tại vùng cho trước. Một ưu điểm của mô hình ‘pipe’ là nó giống với môt hình QoS đang được các khách hàng VPN sử dụng với FrameRelay hay ATM. Do đó, nó có thể là dễ hiểu đối với các khách hàng. Tuy nhiên, mô hình ‘pipe’ cũng có một vài nhược điểm. Thứ nhất, nó đòi hỏi một khách hàng VPN phải biết toàn bộ ma trận lưu lượng của nó. tức là, cho tất cả các vùng, khách hàng phải biết tổng lưu lượng đi từ một vùng đến các vùng khác. Thường thì thông tin này không có sẵn, thậm chí là nếu có thì cũng bị lỗi thời.
Trong mô hình ‘hose’, nhà cung cấp dịch vụ VPN cung cấp cho khách hàng một sự đảm bảo chắc chắn cho lưu lượng mà bộ định tuyến CE của khách hàng gửi đi và nhận về từ các bộ định tuyến CE khác trong cùng một VPN. Trong trường hợp khác khách hàng phải chỉ định bằng cách nào lưu lượng này được phân phối trong các bộ định tuyến CE. Kết quả là ngược với mô hình ‘pipe’, mô hình ‘hose’ không đòi hỏi khách hàng biết ma trận lưu lượng mà điều này là gánh nặng với các khách hàng muốn sử dụng dịch vụ VPN.
Mô hình ‘hose’ sử dụng hai tham số, ICR (ingress Committed Rate) và ECR (egress Committed Rate). ICR là tổng lưu lượng mà một CE có thể gửi tới các CE khác trong khi ECR là tổng lưu lượng mà moọt CE có thể nhận từ các CE khác. Nói cách khác, ICR đại diện cho tổng lưu lượng từ một CE cụ thể, trong khi ECR đại diện cho tổng lưu lượng tới một CE cụ thể. Chú ý là, với một CE cho trước, không đòi hỏi là ICR cân bằng với ECR.
Để minh hoạ mô hình ‘hose’, xem xét ví dụ biểu diễn trên Hình III2, ở đây nhà cung cấp dịch vụ cung cấp cho VPN B một sự đảm bảo chắc chẵn với băng thông 15Mb/s cho lưu lượng từ vùng 2 tới các vùng khác (ICR=15Mbps) mà không chú ý đến liệu lưu lượng này đi tới vùng 1 hay vùng 3 hay được phân phối giữa vùng 1 và vùng 3. Cũng như vậy nhà cung cấp dịch vụ cung cấp cho VPN B một sự đảm bảo chắc chắn với băng thông 7Mbps cho lưu lượng từ vùng 3 gửi tới các vùng khác trong cùng VPN (ICR=7Mbps), không chú ý đến liệu lưu lượng tới vùng 1 hay vùng 2 hay được phân phối trong vùng 1 và 2. Tương tự như vậy nhà cung cấp dịch vụ cung cấp cho VPN B sự đảm bảo với băng thông 15Mbps cho lưu lượng gửi tới vùng 2 (ECR=15Mpbs) mà không chú ý tới liệu lưu lượng xuất phát từ vùng 1 hay vùng 3 hay được phân phối giữa vùng 1 và vùng 3.
Mô hình ‘hose’ hỗ trợ nhiều CoS với các dịch vụ khác nhau từ mỗi trong số các đặc tính chất lượng liên quan; Ví dụ, một dịch vụ có thể có khả năng mất mát gói tin ít hơn dịch vụ khác. Với các dịch vụ đòi hỏi phải có sự đảm bảo lớn (như đảm bảo về băng thông), thì mô hình ‘pipe’ phù hợp hơn.
Hình III2 Mô hình hose QoS
Mô hình ‘pipe’ và ‘hose’ không phải là các mô hình đối ngược nhau. Nghĩa là, nhà cung cấp dịch vụ có thể cung cấp cho khách hàng VPN một sự kết hợp giữa các mô hình ‘pipe’ và ‘hose’, và có thể giúp cho khách hàng quyết định loại dịch vụ nào cần mua và loại lưu lượng nào nên có gía trị CoS nào.
Để hỗ trợ mô hình ‘pipe’ chúng ta sử dụng các LSP băng thông bảo đảm. Những LSP này bắt đầu và kết thúc tại các bộ định tuyến PE và được sử dụng để cung cấp băng thông đảm bảo cho tất cả các ống từ một PE đến các PE khác. Tức là với một cặp bộ định tuyến PE, ở đây có thể có nhiều bộ định tuyến CE gắn liền với cặp bộ định tuyến PE này mà chúng đã có các đường ống giữa chúng và hơn là sử dụng một LSP băng thông đảm bảo cho mỗi ống như vậy, chúng ta sử dụng một LSP cho tất cả.
Ví dụ trong hình Hình III1 có thể có một ống cho VPN A từ CEA3 tới CEA1 và một ống khác cho VPN B từ CEB3 tới CE2B1. Để hỗ trợ hai ống này, chúng ta thiết lập một LSP từ PE3 tới PE1 và dự trữ trong LSP băng thông có độ lớn bằng tổng băng thông của hai ống. Khi PE3 nhận gói tin từ CEA3 và gói tin có đích là một host ở vùng 1 của VPN A, PE3 quyết định dưới sự điều khiển của cấu hình cục bộ của nó xem liệu gói tin nhận CoS nào. nếu như vậy, sau đó PE3 gửi chuyển tiếp gói tin dọc theo LSP từ PE3 tới PE1.
Sử dụng một LSP băng thông cố định để mang nhiều đường ống giữa một cặp bộ định tuyến PE cải thiện tính mở rộng của giải pháp. Điều này bởi vì số LSP mà nhà cung cấp dịch vụ phải thiết lập và duy trì phụ thuộc với số cặp bộ định tuyến PE của nhà cung cấp dịch vụ hơn là phụ thuộc vào số đường ống của các khác hàng VPN mà nhà cung cấp có thể có.
Để hỗ trợ CoS trong mô hình hose, nhà cung cấp dịch vụ sử dụng các dịch vụ khác nhau với MPLS. Nhà cung cấp dịch vụ cũng sử dụng xử lý lưu lượng để cải thiện khả năng sử dụng mạng trong khi đạt được những mục tiêu về chất lượng mong muốn.
Các thủ tục mà thông qua nó bộ định tuyến PE lối vào quyết định loại lưu lượng nào nhận được CoS nào rơi vào mô hình hose hay pipe là hoàn toàn mang tính cục bộ đối với bộ định tuyến PE đó. Những thủ tục này có thể xem xét các yếu tố như giao diện lối vào, địa chỉ IP nguồn, đích, quyền ưu tiên IP, số cổng TCP, hoặc sự kết hợp của những yếu tố trên. Điều này mang lại cho nhà cung cấp dịch vụ sự mềm dẻo với khía cạnh điều khiển xem loại lưu lượng nào nhận CoS nào.
Mặc dù các khách hàng ký kết hợp đồng với nhà cung cấp dịch vụ cho số lưu lượng cụ thể trong CoS cụ thể, khách hàng có thể gửi lưu lượng quá lượng đó. Để quyết định liệu lưu lượng có nằm trong hợp đồng ký kết, nhà cung cấp dịch vụ sử dụng các chính sách tại bộ định tuyến PE lối vào. Với lưu lượng vượt khỏi giao ước, nhà cung cấp có hai khả năng lựa chọn: hoặc là loại bỏ lưu lượng này ngay lập tức tại bộ định tuyến lối vào hoặc gửi lưu lượng đi nhưng đánh dấu nó khác với các lưu lượng nằm trong hợp đồng. Với sự lựa chọn thứ hai, để giảm phân phối không đúng thủ tục, cả lưu lượng nằm trong hoặc vượt khỏi hợp đồng đều được gửi theo cùng một LSP. Lưu lượng vượt hợp đồng sẽ được đánh dấu khác và cách đánh dấu này ảnh hưởng đến khả năng loại bỏ trong trường hợp có tắc nghẽn.
Xem xét về chất lượng trong MPLS VPN
Cho mục đích tranh luận về các vấn đề chất lượng và khả năng mở rộng, các bộ định tuyến ngày nay có thể được phân chia thành hai mặt bằng: mặt bằng định tuyến và mặt bằng gửi chuyển tiếp.
Xem xét tại mặt bằng định tuyến, hầu hết các giao thức định tuyến hiện đại sử dụng một vài hình thức của phương thức tính toán tối ưu để tính toán đường đi ngắn nhất để tới được đích cuối cùng. Ví dụ, OSPF và ISIS sử dụng thuật toán Djikstra trong khi BGP sử dụng “Decision Process”. Những thuật toán này dựa trên việc phân tích cơ sở dữ liệu định tuyến và tính toán đường đi tốt nhất tới đích cuối cùng. Các đặc tính chất lượng của những thuật toán này được dựa trên hoặc là đặc tính hình học topo (ISIS và OSPF) hoặc số AS trên đường đi tới đích (BGP). Nhưng chú ý rằng mào đầu trong việc thiết lập và khởi tạo những tính toán này là rất nhỏ cho hầu hết các bộ định tuyến ngày nay. Điều này bởi vì mặc dầu chúng ta đề cập tới đầu vào tính toán định tuyến là cơ sở dữ liệu, những cơ sở dữ liệu này được nhớ trong các cấu trúc dữ liệu thường trú.
Do đó, những kết luận sau có thể được đưa ra:
Việc bắt đầu tính toán định tuyến cho một miền định tuyến không nhiều hơn việc thiết lập những đăng ký để chỉ ra các đối tượng cơ sở dữ liệu đúng.
Dựa trên 1, chất lượng của một thuật toán đưa ra hoàn toàn không tồi hơn nhờ mào đầu được yêu cầu để thiết lập thuật toán đó.
Dựa trên 2, tiếp theo, khi một số các công việc tính toán định tuyến cho một số các bộ định tuyến ảo phải được bộ định tuyến vật lý thi hành, độ phức tạp trong kết quả tính toán định tuyến không nhiều hơn tổng các độ phức tạp của việc tính toán định tuyến của các bộ định tuyến ảo riêng rẽ.
Dựa trên 3, tiếp theo liệu mô hình lai ghép được sử dụng hay một mô hình định tuyến ảo được áp dụng, các đặc tính chất lượng của một bộ định tuyến hoàn toàn phụ thuộc vào khả năng về phần cứng của nó và sự lựa chọn các cấu trúc dữ liệu và các thuật toán.
Để minh hoạ, đặt một bộ định tuyến vật lý trong N VPN, tất cả chạy cùng một giao thức định tuyến gọi là RP. Cho rằng chất lượng trung bình trong thuật toán tính toán định tuyến của RP là f(X,Y) ở đây x và y là các tham số quyết định chất lượng của thuật toán cho giao thức định tuyến đó. Như trong ví dụ, cho thuật toán Djikstra với giao thức OSPF, X có thể là số nút trong vùng trong khi Y có thể là số liên kết. Chất lượng của một VPN n tuỳ ý là f(Xn,Yn). Chất lượng của bộ định tuyến vật lý là tổng của f(Xi,Yi) cho các giá trị i chạy từ 0 tới N. Kết luận này độc lập với cách tiếp cận VPN lựa chọn (bộ định tuyến ảo hay mô hình lai ghép)
Trong trường hợp thông thường, mặt bằng gửi chuyển tiếp có hai đầu vào: bảng gửi chuyển tiếp và mào đầu gói tin. Tham số chất lượng chính là thuật toán tìm kiếm. Chất lượng tốt nhất có thể có được cho việc tìm kiếm bảng định tuyến IP bằng cách tổ chức bảng dưới một vài mô hình hình cây và sử dụng các phương pháp tìm kiếm nhị phân để thi hành việc tìm kiếm. Chất lượng của thuật toán này là O (log n)
Do đó, chỉ cần các bảng định tuyến của các bộ định tuyến ảo là riêng biệt, chi phí tìm kiếm là giá trị không đổi cho việc tìm kiếm bảng định tuyến và là O(log n) để tìm lối vào. Điều này không tồi hơn bất cứ bộ định tuyến nào và không khác so với bộ định tuyến mà áp dụng các công nghệ lai ghép để phân phối các dịch vụ VPN. Tuy nhiên, khi bộ định tuyến lai ghép sử dụng việc tích hợp nhiều bảng định tuyến VPN, chất lượng sẽ là O(log m*n) ở đây ‘m’ là số VPN mà bản định tuyến giữ.
Giải pháp MPLS của một số hãng
Khuyến nghị về khả năng ứng dụng công nghệ MPLS trong mạng NGN của Tổng công ty BCVT Việt nam
Kết luận và khuyến nghị
TÀI LIỆU THAM KHẢO
Các file đính kèm theo tài liệu này:
- BC1094.doc