RSVP có một số cơ chế cần thiết để thực hiện báo hiệu phân phối nhãn nhằm ràng buộc định tuyến. IETE đã chuẩn hóa phần mở rộng kỹ thuật lưu lượng RSVP- TE, định nghĩa các ứng dụng của RSVP-TE như hỗ trợ phân phối nhãn theo yêu cầu
để cấp phát tài nguyên cho các LSP định tuyến tường minh. Tổng kết cách dùng
RSVP-TE để hỗ trợ tái định tuyến Ộmake-before-breakỢ, theo đõi đường thực sự được chọn qua chức năng ghi tuyến cũng như hỗ trợ ưu tiên và lấn chiếm.
Nguyên lý chức năng của RSVP là thiết lập các dự trữ cho luồng gói đơn hướng.
Các bản tin RSVP thường đi theo con đường hop-by-hop của định tuyến IP nếu không hiện diện tùy chọn tuyến tường minh (explicit route). Các router hiểu RSVP dọc theo đường có thể chặn và xử lý bất cứ bản tin nào. RFC 2205 định nghĩa 3 kiểu
bản tin RSVP: thiết lập dự trữ (reservation setup), tear down, và error. RSVP-TE
cũng định nghĩa thêm bản tin Hello. 2.5.1 Các bản tin thiết lập dự trữ RSVP
RSVP sử dụng khái niệm dự trữ ở đầu nhận. Trước tiên đầu gửi phát ra một bản
tin PATH nhận diện một luồng và các đặc tắnh lưu lượng của nó. Bản tin PATH chứa
Chương 2 Định tuyến báo hiệu
một session-ID, sender-template, label-request, sender-Tspec và tùy chọn là đối tượng tuyến tường minh ERO (explicit route object). $ession-ID chứa một địa chỉ IP đắch đi kèm một nhận dạng hầm 16 bit (tunnel ID) để nhận diện một đường hầm
LSP. Như đã trình bày ở chương trước, chỉ có ingress-LSP mới cần biết về FEC được
gán vào một đường hầm LSP. Do đó, không giống như LDP, FEC ánh xạ vào đường
hầm LSP không bao gồm trong bất kỳ bản tin RVSP nào. Đối tượng iabel-request hỗ trợ chế độ công bố nhãn theo yêu cầu. Ếenđer-template chứa địa chỉ TP của đầu gởi
đi kèm với một LSP ID có hỗ trợ phương thức Ộmake-before-breakỢ khi thay đổi
đường đi của một đường hầm LSP. Đặc tắnh lưu lượng Tspec sử dụng tốc độ đỉnh
(peak rate), thùng token (token bucket) để định nghĩa tốc độ và kắch cỡ bùng phát,
đơn vị khống chế tối thiểu (minimum policed unit) và kắch thước gói tối đa.
Khi bản tin PATH đi đến đắch, bên nhận đáp ứng bằng một bản tin RESV nếu nó đồng ý khởi tạo việc gán kết nhãn được yêu cầu trong bản tin PATH. Bản tin RESV được truyền về theo đường ngược chiều với bản tin PATH bằng cách dùng thông tin
hop kể trước trong bản tin PATH. RESV cũng chứa cùng session-ID như ở bản tin
PATH tương ứng, đối tượng ghi tuyến tùy chọn (rou(e record) và thông tin lệ thuộc kiểu dự trữ (reservation style). Kiểu FF (fixed filter) có một nhãn và Tspec được ấn
định cho mỗi cặp sender-receiver. Kiểu SE (shared explicit) ấn định một nhãn khác
nhau cho mỗi sender, nhưng tất cả chúng phải áp dụng cùng một dự trữ luồng rõ
ràng. Đối tượng record-route ghi nhận tuyến đường thực tế được chọn bởi LSP bắt
đầu từ egress dẫn ngược về ingress. Nó có thể được một router dùng để ghim một tuyến tường minh thả lỏng bằng cách copy tuyến ghi được trong bản tin RESV sang
đối tượng tuyến tường minh ERO trong một bản tin PATH được gửi theo chiều ngược lại.
2.5.2 Các bản Tear Down, Error và Hello của RSVP-TE
RSVP-TE định nghĩa 2 bản tin dành cho việc giải tỏa LSP là PATH TEAR và RESV TEAR. Hai bản tin này được gửi theo chiều ngược với bản tin PATH và RESV tương ứng. Bản tin TEAR xóa bỏ bất kỳ trạng thái đã cài đặt liên quan đến bản tin
PATH hay RESV. Các bản tin TEAR cũng có thể dùng để xóa các trạng thái đáp
ứng cho một lỗi ở bước đầu tiên trong hoạt động tái định tuyến.
Có các bản tin thông báo lỗi cho bản tin PATH và RESV cũng như bản tin RESV CONFIRMATTION tùy chọn. Các bản tin lỗi cho biết có sự vi phạm chắnh sách, mã hóa bản tin hoặc một số sự cố khác. Vắ dụ, khi một LSP thấy rằng nó không thể hỗ trợ Tspec đặc tả trong một bản tin RESV, nó sẽ không chuyển tiếp bản tin RESV về cho phắa upstream, thay vào đó nó tạo ra một bản tin RESVERR gửi cho phắa
downstream để xóa bỏ nỗ lực thiết lập LSP. Tuyến tường minh và các tùy chọn record-route của RSVP-TE có một số các mã lỗi để phục vụ cho việc debug.
RFC 3209 định nghĩa bản tin Hello tùy chọn cho RSVP-TE, nó cho phép một
LSR phát hiện một neighbor bị lỗi nhanh hơn khi so với RSVP làm tươi tình trạng
Chương 2 Định tuyến báo hiệu
hoặc phát hiện lỗi đường truyền bằng một giao thức định tuyến IP. Điều này khá hữu ắch trong việc tái định tuyến nhanh.
2.5.3 Thiết lập tuyến tường minh điều khiển tuần tự theo yêu cầu
Hình 34 vắ dụ việc trao đổi bản tin RSVP-TE sử dụng đối tượng tuyến tường minh
ERO (explicit route object) để cài đặt một LSP đi qua một con đường không phải là
đường ngắn nhất. Router R1 xác định rằng nó sẽ ấn định FEC Ộz./⁄16Ợ cho một đường hầm LSP, và nó tắnh ra một tuyến tường minh R4-R5-R3 để đi đến hop kế cho
FEC đó. R1 khởi tạo việc thiết lập LSP này bằng cách phát ra một bản tin PATH đến
R4 với một ERO, Tspec, sender template (có chứa địa chỉ của sender) và một đối
tượng label request. Mỗi bản tin RESV liên quan đến đường hầm LSP này đều mang
session-ID và filter-spec nguyên thủy của sender RI để giữ mối tương quan với
nhau. Tiếp theo, R4 tiếp nhận yêu cầu này và gửi bản tin PATH đến router kế tiếp
ghi trong ERO là R5. Đến lượt mình, R5 gửi bản tin này đến egress-router R3.
Tại đắch đến của bản tin PATH, R3 xác định rằng liên kết chặng R3-R5 có thể hỗ trợ cho yêu cầu và đó là hop cuối cùng trên đường dẫn cho FEC Ộ4.5/16Ợ. R3 đáp
ứng bằng bản tin RESV có chứa ERO, Tspec của dung lượng dự trữ, một filter spec
thỏa mãn bên gửi, và gán một nhãn null ngầm (implicit null) cho chặng liên kết này.
Theo RFC 3031, nhãn null là một quy ước được dùng trong phân phối nhãn cho phép
egressrouter (ở đây là R3) báo hiệu cho đối tác upstream của nó biết rằng đây là hop
áp cuối (penultimate hop) của LSP, do vậy cần gỡ nhãn đỉnh của stack (xem LEIB
của LSR R5). Tiếp theo, R5 thu nạp bản tin RESV yêu cầu cho chặng R5-R4, ấn
định nhãn B và gởi bản tin RESV đến router kể trước trong ERO là R4. Cuối cùng, R4 chấp nhận yêu câu, ấn định nhãn A và gởi bản tin RESV ngược về R1. Đến lúc
này, đường LSP được thiết lập xong và các gói có nhãn cho FEC Ộz.b⁄16Ợ được
chuyển tiếp qua đường hầm.
Swilcwed sổ
Path (LSP} ` Cm1 > Ở Nha nG TT 2 xắ Ừ 3
PHtS: ENU = H4, PS, PT Tzặệc, LaAb@i RẠocest ệ tạẨn: SA x 44, nã, 83;
Yopee; tawei FieQ0921 l#ăt EfQ x Rẻ, ÂS, N3;
Ì ỞỞỞỞỞ-->| T5p$c: Làbt: ệéqde5S:
PiESvV: SIAO x.NG P"X, NGy
Nàệg: ESEFES Đ5/R3: SE FẺ, T3pEC, FHtếIrSpeS,
lASv, Đ có 515.R%. ? $ Ề ặ
Hg2uc ERO= RA.PRSANG: EE. | Sogeo, Pitersebe, Labaicl le CẾI " JEESX Hưt
TopeẠ, Fil7evorec, ào 3iex *
ặEẠ CỊT CHỨT 6Ô |IĐ +CSJT CIỤT ##đú [1x |GIứT CHỨC FEc GIIT sụt
Jặ tidLFPE #ƑP |LBLÍJ !F 8đẢHLFEÍI |IE |LBCV | ệ@ HHLFặ (E + Fặ
z\.EaƯ { G - Pu & 3 | Ừ 5 4 Ki 8 PCGặ .bết G 5
F1 FiB ựệ4LCFiB FsLFiB F3 FIB
Hình 2.44: Thiết lập LSP với RSVP-TE
Khác với giao thức LDP, các bản tin RSVP-TE không mang EEC, vì chỉ duy nhất
có R1 cần biết về ánh xạ giữa FEC và đường hầm LSP.
Chương 2. Định tuyến báo hiệu
2.5.4 Giảm lượng overhead làm tươi RSVP
RSVP là giao thức trạng thái mềm (soft-state), tiến trình phát một bản tin PATH và bản tin RESV hồi đáp tương ứng phải được định kỳ làm tươi, thường khoảng 30s
một lần. Phương pháp làm tươi này để phòng các bản tin bị mất và trong trường hợp
định tuyến từng chặng sẽ tự động chuyển dự trữ tài nguyên sang đường mới khi có
bất kỳ thay đổi định tuyến IP. Tất nhiên, việc xử lý dành cho khởi tạo các bản tin
PATH và RESV lớn hơn nhiều so với việc làm tươi trạng thái một bản tin đã nhận
trước đó, tuy nhiên với một số lượng lớn các LSP thì việc xử lý làm tươi có ảnh
hưởng đáng kể đến hiệu năng.
Một cách để giải quyết là tăng chu kỳ làm tươi, nhưng cũng sẽ làm tăng độ trễ
báo hiệu khi mất bản tin. RFC 2961 đặc tả một giải pháp cho hạn mức xử lý và vấn
để trễ báo hiệu. Cơ chế này bao gồm việc bó gọn bản tin để giảm tải xử lý, cũng như các cách để router dễ dàng nhận dạng một bản tin không thay đổi hơn. Việc hồi báo
bản tin cũng được bổ sung để chuyển tải tin cậy bản tin RSVP và xử lý trường hợp
mất các bản tin PATH TEAR và RESV TEAR vì hai bản tin này không được làm tươi trong hoạt động RSVP. Cuối cùng, giải pháp này định nghĩa một bản tin tổng
kết (summary) để làm tươi trạng thái mà không yêu cầu truyền toàn bộ bản tin làm tươi. Các cải tiến này nhằm giảm lượng overhead làm tươi của RSVP trong mạng
MPLS.
Chương 3 Tổng quan VPN và MPLS VPN
CHƯƠNG 3
TỔNG QUAN VPN VÀ MPLS VPN
3.1 Cấu trúc mạng riêng ảo VPN ( Virtual Private Network)
3.1.1 Tổng quan
Về mặt lịch sử, mạng diện rộng (WAN) tư nhân được cung cấp bởi các kết nối leased line chuyên dụng tạo ra kết nối point-to-point (điểm đến điểm) giữa 2 trạm khách hàng. Những mạng như thế thì quá đắt để lắp đặt, đặc biệt là nếu các kết nối giữa các trạm cần hỗ trợ một số đường dự trữ.
Mạng riêng ảo (VPNỞVirtual Private Network), là một giải pháp, trong đó một mạng mà các kết nối của khách hàng trên các vùng được dùng trên một cơ sở hạ
tầng chung. VPN có thể kết nối giữa hai hệ thống đầu cuối hoặc giữa hai hay nhiều mạng.VPN có thể được xây dựng dùng đường hầm và sự mã hoá. Mạng này đối với
người dùng là mạng riêng, cung cấp khả năng và chắnh sách như một mạng riêng. Một mạng riêng ảo có thể xây dựng dựa trên kỹ thuật lớp 2 truyền thống như frame
relay hay ATM.
3.1.1 Mô hình mạng ảo (Virtual Network Models)
Hình 3.1: Mô hình mạng ảo Đồ án tốt nghiệp Trang 55
Chương 3 Tổng quan VPN và MPLS VPN
Các loại đồ hình VPN (VPN topology) Hub and spoke (mạng hình sao)
*._ Mỗi nhánh liên lạc trực tiếp với điểm trung tâm *._ Phù hợp với luồng dữ liệu của nhiều công ty
" Trung tâm xử lý dữ liệu chắnh đặt ở trung tâm
+ Định tuyến chỉ là phụ + Số lượng đường hầm nhỏ
Ộ Khó cấu hình bằng tay * Trung tâm có thể nghẽn cổ chai
Mesh
*. Số lượng đường hầm lớn = Dễ dàng cấu hình bằng tay + Định tuyến được tối ưu nhất Overlay Network (Mạng chồng lấn)
*_ Dịch vụ (được quản lý) dựa trên IPsec
+. Nhiều đường hầm có nhiều mắt lưới (highly mesh) riêng biệt ". Mỗi VPN gateway phải biết mỗi VPN gateway khác
rA (FR, ATM, etc.)
Hình 3.2: Mô hình mạng chông lấn (Overlay Network)
Ở
Chương 3 Tổng quan VPN và MPLS VPN
Peer to peer Model (kiểu ngang hàng)
* Mạng MPLS
*_ Mỗi VPN gateway chỉ biết router public ngang hàng của nó
"_ Trao đổi thông tin định tuyến
"_ Mạng nhà cung cấp dịch vụ phổ biến thông tin định tuyến
* Mạng public route traffic giữa các gateway của cùng một VPN.
. Provider ca (MPLSAPN) Hình 3.3: Mô hình mạng publc
3.1.2 Các yêu cầu cho VPN :
RFC 2764 định nghĩa một cấu trúc chung cho các VPN dựa trên nên IP, bao
gồm các yêu cầu cho một giải pháp VPN.
Việc truyền dữ liệu không trong suốt giữa các trạm VPN, bởi vì khách hàng
có thể dùng các giao thức không IP hay các địa chỉ IP được quản trị cục bộ
không duy nhất ngang qua mạng của nhà cung cấp dịch vụ.
Bảo mật của việc truyền dữ liệu qua VPN tránh được sự sai lệch, sự thay
đổi, sự quấy phá hay rình mò dữ liệu của khách hàng.
QoS đảm bảo việc đáp ứng các yêu cầu kinh doanh của khách hàng về mặt băng thông, sử dụng và dự trữ.
Chương 3 Tổng quan VPN và MPLS VPN
3.1.3 Phân loại VPN :
Có 4 loại VPN được định nghĩa trong REC 2764 đó là :
+ Virtual Leased Line (VLL) cung cấp các đường kết nối điểm - điểm
định hướng kết nối giữa các trạm VPN. Khách hàng nhận mỗi VLL
như là một đường riêng (vật lý) mang tắnh chuyên dụng, mặc dù thực
tế nó được cung cấp bởi một đường hầm IP đi qua mạng trục
(backbone). Giao thức đường hầm IP tận dụng một VLL có khả năng chuyển tải bất kỳ giao thức nào mà khách hàng sử dụng giữa các trạm
được kết nối bằng VLL đó.
* Virtual Private LAN Segment (VPLS) cung cấp một LAN mô phỏng giữa các trạm VPLS. Như với các VLL, thì một VPLS VPN đòi hỏi sử
dụng các đường hầm IP trong suốt đối với các giao thức được chuyển
tải trên LAN mô phỏng đó. LAN có thể được mô phỏng bằng cách
dùng một đường hầm đạng lưới (mesh) giữa các trạm khách hàng hay bằng việc ánh xạ mỗi VPLS đối với một địa chỉ IP multicast riêng biệt.
* Virtual Private Routed Networks (VPRNs) mô phỏng một mạng được
route dựa trên IP chuyên dụng giữa các trạm khách hàng. Mặc dù một VPRN nhưng nó phải chuyển tải lưu lượng IP được đối xử như một routing domain riêng biệt từ mạng của nhà cung cấp bên dưới, bởi vì VPRN có khả năng dùng các địa chỉ IP được ấn định bởi không
phải duy nhất một khách hàng. Mỗi mạng của khách hàng nhận thấy
rằng bản thân nó hoạt động cách ly và tách rời khỏi mạng Internet Ở
Vì vậy nó tự do gán các địa chỉ IP bằng bất cứ kiểu nào mà nó thắch. Các địa chỉ này không được quảng bá ra ngoài VPRN bởi vì chúng
không được đảm bảo là duy nhất và rộng hơn nhiều so với bản thân
VPN.
* Virtual Private Dial Neworks (VPDNs) cho phép các khách hàng
đồng ý cho SP sự cung cấp và quản lý quay số vào truy xuất vào các mạng của họ. Thay vì mỗi khách hàng thiết lập các server truy xuất
của riêng mình và dùng các phiên PPP giữa một vị trắ trung tâm và các user ở xa, SP cung cấp một hay nhiều server chia sẻ việc truy xuất. Các phiên PPP cho mỗi VPDN được đi qua đường hầm từ server
truy xuất của SP đến một điểm truy xuất vào mạng của mỗi khách
hàng được gọi là bộ truy xuất tập trung (access concentrator).
Chương 3 Tổng quan VPN và MPLS VPN
Loại VPN cuối cùng cung cấp ở dạng truy xuất đặc biệt đến một mạng
khách hàng. IETF đã chỉ định giao thức đường hầm lớp 2 (L2TP), được thiết
kế rõ ràng để cung cấp các khả năng chứng thực và ghép kênh bắt buộc cho
việc mở rộng các phiên PPP từ một bộ xử lý tập trung L2TP của khách hàng (LAC) đến L2TP Network Server (LứS). mặt phẳng điều khiển).
3.1.4 Giao thức đường hầm VPN :
Giao thức đường hầm được sử dụng cho VPNs là IPsec, IP-in-IP, L2TP,
GRE, và MPLS :
IP Security ( IPSec), được phát triển bởi IETF, IPSec là chuẩn mở mà đảm
bảo việc bảo mật truyền dẫn và chứng thực user trên mạng công cộng. Không như các kỹ thuật mã hoá khác, hoạt động IPSec tại lớp mạng (Network) của mô hình OSI bảy lớp. Vì vậy, nó có thể được bổ sung một cách độc lập các ứng
dụng đang chạy trên mạng. Kết quả là mạng có thể được bảo mật mà không cần bổ sung và bảo mật kết hợp cho mỗi ứng dụng riêng.
+. Hơn nữa lợi ắch khác của IPsec là nó là không kết nối - một đường hầm
IPsec giữa các thiết bị PE không dùng bất kỳ tài nguyên nào trong các P
router. Trạng thái duy nhất đòi hỏi là một số thông tin bảo mật bị chia sẻ