• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.
Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

Giao thức chiếm trước tài nguyên-RSPV

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Giao thức chiếm trước tài nguyên-RSPV

    Tác giả:
    Trần Thị Tố Uyên
    GIAO THỨC CHIẾM TRƯỚC TÀI NGUYÊN-RSPV
    (RESOURCE RESERVATION PROTOCOL)

    - RSVP là một cơ chế báo hiệu dùng để dành riêng tài nguyên trên một mạng. RSVP không phải là một giao thức định tuyến. Việc quyết định tuyến do IGP (gồm cả các mở rộng TE) và CSPF.
    - Công việc của RSVP là báo hiệu và duy trì tài nguyên dành riêng qua một mạng. Trong MPLS TE, RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-plane layer); không có chính sách lưu lượng trên mặt phẳng chuyển tiếp (forwarding-plane). Khi sử dụng cho các mục đích khác (như VoIP hay DLSW+reservations), RSVP có thể được dùng để dành riêng không gian hàng đợi công bằng có trọng số (WFQ – Weighted Fair Queuing) hay xây dựng các ATM SVC.
    - RSVP có ba chức năng cơ bản:
    • Thiết lập và duy trì đường đi (Path setup and maintenance)
    • Hủy đường đi (Path teardown)
    • Báo lỗi (Error signalling)
    - RSVP là một giao thức trạng thái mềm (soft-state protocol). Nghĩa là cần tái báo hiệu trên mạng để làm tươi định kỳ cho nó. Với RSVP, một yêu cầu bị hủy nếu nó được chỉ định xóa khỏi mạng bằng RSVP hay hết thời gian dành riêng (reservation times out).
    1. Các chức năng của RSVP:
    1.1 Thiết lập và duy trì đường đi:
    Thiết lập đường đi (Path Setup):
    - Sau khi đầu đường hầm (tunnel headend) hoàn thành CSPF cho một đường hầm cụ thể, nó gửi một thông điệp Path đến nút kế tiếp (next-hop) dọc theo đường đi đã tính toán đến đích. LSR gửi thông điệp Path được gọi là LSR ngược dòng (upstream router), và LSR nhận thông điệp được gọi là LSR xuôi dòng (down-stream router). LSR ngược dòng con duoc goi la trạm trước đó ( phop – previous hop).
    - Sau khi LSR xuôi dòng nhận một thông điệp Path, nó kiểm tra định dạng của thông điệp, sau đó kiểm tra lượng băng thông mà thông điệp yêu cầu. Tiến trình này được gọi là điều khiển chấp nhận (admission control).
    - Nếu việc kiểm tra này thành công và thông điệp Path được phép dành riêng băng thông như nó yêu cầu, LSR xuôi dòng tạo một thông điệp Path mới và gửi đến nút kế trong đối tượng tuyến tường minh (ERO – Explicit Route Object). Thông điệp Path tiếp tục được chuyền đi đến khi nào chúng đến được nút cuối cùng trong ERO – đuôi đường hầm MPLS TE (tunnel tail).
    - Đuôi đường hầm thực hiện điều khiển chấp nhận trên thông điệp Path giống như các LSR xuôi dòng khác. Khi nó nhận ra rằng nó là đích đến của thông điệp Path nó trả lời lại bằng thông điệp Resv. Resv đóng vai trò như là một ACK báo về cho LSR ngược dòng. Resv chứa một thông báo rằng thỏa mãn sự dành riêng đến cuối đường hầm và thông tin nhãn đến (incoming label) cho LSR ngược dòng sử dụng để gửi các gói dọc theo TE LSP đến đích. Hình 3.3 cho thấy sự trao đổi các thông điệp RSVP Path và Resv trong suốt quá trình thiết lập LSP.
    - Hình 3.3 có 10 bước. Giả sử rằng R1 thực hiện CSPF xong và biết rằng nó muốn dành riêng băng thông dọc theo đường R1 → R2 → R3 → R5 → R6 → R7:
    1. R1 gửi một thông điệp Path đến R2. R2 nhận thông điệp Path , kiểm tra cú pháp thông điệp và kiểm ra bằng bộ quản lý kết nối TE (TE Link Manager) để chắc rằng băng thông mà R1 yêu cầu hiện đang có sẵn. Nếu xảy ra lỗi R2 gửi thông điệp Error lại cho R1. Giả sử mọi thứ đều tốt thì chuyển sang bước 2.
    2. R2 gửi thông điệp Path đến R3. R3 thực hiện kiểm tra giống R2.
    3. R3 gửi thông điệp Path đến R4. R4 thực hiện kiểm tra giống R3.
    4. R4 gửi thông điệp Path đến R5. R5 thực hiện kiểm tra giống R4.
    5. R5 gửi thông điệp Path đến R6. R6 thực hiện kiểm tra giống R5.
    6. R7, đuôi của đường hầm, gửi một thông điệp Resv đến R6. Resv chỉ định nhãn R7 muốn thấy trên gói đến; vì R7 là đuôi nên nó gửi implicit-null.
    7. R6 gửi một thông điệp Resv cho R5 và chỉ định nó muốn thấy nhãn đến là 42 cho đường hầm này. Nghĩa là khi R6 nhận nhãn 42, nó thực hiện hủy nhãn (vì implicit-null) và gửi thông điệp về cho R7.
    8. R5 gửi thông điệp Resv cho R3, báo hiệu nhãn 10921. Khi R5 nhận một gói với nhãn 10921, nó đổi (swap) nhãn đó thành nhãn 42 và gửi gói đến R6.
    9. R3 gửi một thông điệp Resv cho R2, báo hiệu nhãn 21.
    10. R2 gửi một thông điệp Resv cho R1, báo hiệu nhãn 18.
    - Lúc này, R1 nhận một thông điệp Resv cho đường hầm đến R7 và nó biết nhãn ra (outgoing label) nào được sử dụng. Giao tiếp đường hầm trên R1 trở thành up/up (trước thời điểm này là up/down).
    Duy trì đường đi (Path Maintenance):
    - Thoạt nhìn, việc duy trì đường đi giống như thiết lập đường đi. Mỗi 30 giây đầu đường hầm gửi một thông điệp Path đến láng giềng xuôi dòng của nó. Nếu một LSR gửi đi một dãy 4 thông điệp Path và không thấy Resv, nó nghĩ rằng sự dành riêng bị mất và gửi một thông điệp ngược dòng (message upstream) báo rằng sự dành riêng bị mất.
    - Các thông điệp Path và Resv được gửi độc lập và bất đồng bộ giữa các láng giềng với nhau. Mỗi 30 giây, R1 gửi thông điệp Path cho một sự dành riêng của nó tới R2. Và mỗi 30 s, R2 gửi một thông điệp Resv đến R1 với cùng sự dành riêng đó. Tuy nhiên hai thông điệp này không liên hệ nhau. Thông điệp Resv được dùng để làm tươi (refresh) một sự dành riêng đang tồn tại chứ không phải trả lời cho thông điệp Path.
    1.2. Hủy đường đi:
    -Nếu một nút (thường là đầu đường hầm) quyết định một sự dành riêng không còn cần thiết trong mạng, nó gửi một thông điệp PathTear dọc theo đường thông điệp Path đã đi và một ResvTear dọc theo đường của Resv.
    - Thông điệp ResvTear được gửi để hồi đáp cho PathTear báo hiệu đuôi đường hầm. PathTear và ResvTear cũng được gửi để trả lời một điều kiện lỗi trong mạng.
    -Không giống thông điệp làm tươi, PathTear không cần đi đến hết downstream trước khi nhận được kết quả. Trong hình 3.3, nếu R1 gửi PathTear đến R2, ngay lập tức R2 trả lời bằng một ResvTear, sau đó gửi PathTear xuôi dòng của nó
    1.3. Báo lỗi:
    - Thỉnh thoảng, tín hiệu RSVP có thể bị lỗi. Các lỗi này được báo hiệu bằng thông điệp PathErr hay ResvErr. Thông điệp lỗi được gửi ngược dòng về phía nguồn của lỗi; một PathErr được gửi ngược dòng từ một nút xuôi dòng và một ResvErr được gửi xuôi dòng từ một nút ngược dòng.

    (còn tiếp)
    Last edited by thanhsang_truong; 10-11-2006, 04:53 AM.
    Tags: None
  • #2
    2. Các gói RSPV:
    - Định dạng gói RSVP khá đơn giản. Mỗi thông điệp RSVP gồm có một tiêu đề chung (common header), theo sau là một hoặc nhiều đối tượng. Số lượng đối tượng phụ thuộc vào thông điệp đang cố hoàn thành.
    Tiêu đề chung RSVP:


    Định dạng lớp đối tượng RSVP:
    - Các đối tượng RSVP có cùng định dạng cơ bản, như trong hình 3.5
    - Mỗi lớp có không gian chỉ số C-Type của riêng nó. Các chỉ số C-Type là duy nhất trong một lớp.
    - Ví dụ: lớp SESSION có 4 loại C-Types: IPv4, IPv6, LSP_TUNNEL_IPv4, và LSP_TUNNEL_IPv6. Các chỉ số được gán cho C-Types này là 1, 2, 7, and 8. LABEL_REQUEST có 3 C-Types: Without Label Range, With ATM Label Range, và With Frame Relay Label Range. Các số được gán là 1, 2, và 3. Nếu chỉ có C-Type = 1 thì không đủ để xác định duy nhất nội dung một thông điệp; Bạn cần phải xem xét cả lớp và chỉ số C-Type.
    - Một thông điệp RSVP chứa một hoặc nhiều đối tượng. Số đối tượng trong thông điệp phụ thuộc vào định nghĩa của thông điệp.

    Comment

    • #3
      - Bảng 3.5: Các lớp và C-Types được dùng trong RSVP-TE của Cisco

      Comment

      • #4
        sao ko thấy hình , thấy bản đâu hết

        Comment

        Previous template Next
        Working...
        X