Chương 2_ Định tuyến báo hiệu
Một LSR gởi Ộthông điệp yêu cầu nhãnỢ (Label Request message) đến một ngang hàng LDP để yêu cầu một sự kết nối (sự ánh xạ) cho một FEC. Sự mã hóa cho
thông điệp yêu cầu nhãn có đạng như sau:
Hình 2.34: Mã hóa thông điệp yêu cầu nhãn
Trong đó:
FEC TLV chứa FEC yêu cầu nhãn. Trường này được mã hóa như trong mục ỘFEC TLVỢ Các trường ỘID thông điệpỢ, ỘCác thông số không bắt buộcỢ tương tự
như ở các phần trước.
Các qui trình thông điệp yêu cầu nhãn:
ỘThông điệp yêu cầu Ộ ( Request message) được sử dụng bởi ỘLSR dòng lênỢ để yêu cầu tường minh một ỘLSR đòng xuốngỢ ấn định và quảng bá một nhãn cho một
FEC.Một LSR có thể gởi một thông điệp yêu cầu nhãn trong các điều kiện sau: * LSR nhận ra một FEC mới thông qua bảng chuyển tiếp , hop kế. của nó là
một ngang hàng LDP và LSR chưa có một sự ánh xạ nhãn từ hop kế cho FEC
đó.
+ Hop kế cho FEC thay đổi và LSR chưa có một sự ánh xạ nhãn từ hop kế đó
cho FEC.
* LSR nhận được một Ộthông điệp yêu cầu nhãnỢ cho một FEC từ ngang hàng LDP dòng lên, hop kế cho FEC là một ngang hàng LDP và LSR chưa có một
sự ánh xạ nhãn từ hop kế.
2.3.3 ụ) Thông điệp yêu cầu bãi bỏ nhãn (Label Abort Request Message)
Chương 2 Định tuyến báo hiệu
ỘLSR nhậnỢ nên đáp lại thông điệp yêu cầu nhãn bằng một Ộthông điệp ánh xạ
nhãnỢ (Label Mapping message) hay bằng một Ộthông điệp thông báoỢ (Nodification
message) chỉ rõ vì sao không thể đáp ứng yêu cầu.
Thông điệp này được sử dụng để Ộbãi bỏỢ (abort) một Ộthông điệp yêu cầu
nhãnỢ chưa được giải quyết.
Sự mã hóa cho Ộthông điệp yêu cầu bãi bỏ nhãnỢ (Label Abort Request message) có
đạng như sau:
Hình 2.35: Mã hóa thông điệp yêu cầu bãi bỏ nhãn ID thông điệp: (adsbygoogle = window.adsbygoogle || []).push({});
* Giá trị 32 bit được sử dụng để nhận dạng thông điệp này
FEC TLV chỉ ra EFEC mà Ộthông điệp yêu cầu nhãnỢ cho nó sẽ được bãi bỏ.
TLV ID thông điệp yêu cầu nhãn (Label Request Message ID TLV)
+ Chỉ rõ ID thông điệp của Ộthông điệp yêu cầu nhãnỢ được bãi bỏ.
Các thông số không bắt buộc
* Không có thông số không bắt buộc nào được định nghĩa cho Ộthông điệp yêu
cầu bãi bỏ nhãnỢ.
Các qui trình thông điệp yêu cầu bãi bỏ nhãn:
Chương 2 Định tuyến báo hiệu
Một LSR Ru (LSR dòng lên) gởi mộtỢ thông điệp yêu cầu bãi bỏ nhãnỢ (Label Abort Request message) để bãi bỏ một Ộthông điệp yêu cầu nhãnỢ chưa được giải quyết trong những trường hợp sau :
Một LSR Ru (LSR dòng lên) gởi mộtỢ thông điệp yêu cầu bãi bỏ nhãnỢ (Label
Abort Request message) để bãi bỏ một Ộthông điệp yêu cầu nhãnỢ chưa được giải quyết trong những trường hợp sau :
" Hop kế của Ru cho FEC thay đổi từ LSR Rd (LSR dòng xuống) tới LSR X nào khác
" Ru không là ỘLSR hợp nhấtỢ, không là ỘLSR lối vàoỢ và nó đã nhận
được một Ộthông điệp yêu cầu bãi bỏ nhãnỢ từ một ngang hàng dòng lên
Y,
Ộ=_ Ru là một ỘLSR hợp nhấtỢ nhưng không là ỘLSR lối vàoỢ và nó đã nhận được một thông điệp yêu cầu bãi bỏ nhãn cho FEC từ ngang hàng dòng lên Y và Y là LSR dòng lên duy nhất yêu cầu một nhãn cho FEC.
Khi một LSR nhận được một Ộthông điệp yêu cầu bãi bổ nhãnỢ (Label Abort Request message), nếu nó chưa đáp lại Ộthông điệp yêu cầu nhãnỢ trước đó bằng
một Ộthông điệp ánh xạ nhãnỢ hay bằng một Ộthông điệp thông báo khácỢ thì nó sẽ Ộbãi bổỢ sự đáp lại này mà thay vào đó là sự xác nhận bãi bỏ bằng một thông điệp
Label Request Aborted Notification (thông điệp thông báo đã bãi bỏ yêu cầu nhãn).
Thông điệp thông báo phải bao gồm ỘTLV ID thông điệp yêu cầu nhãnỢ mang ID
của Ộthông điệp yêu cầu nhãnỢ (Label Request message) đã được bãi bỏ.
Nếu một LSR nhận được một Ộthông điệp yêu cầu bãi bổ nhãnỢ sau khi nó đã
đáp lại Ộthông điệp yêu cầu nhãnỢ bằng một thông điệp ánh xạ nhãn hay bằng một
thông điệp thông báo khác, nó sẽ bỏ qua (gnore) yêu cầu bãi bỏ.
Nếu một LSR nhận được một Ộthông điệp ánh xạ nhãnỢ trong sự đáp lại cho (adsbygoogle = window.adsbygoogle || []).push({});
Ộthông điệp yêu cầu nhãnỢ sau khi nó đã gởi Ộthông điệp yêu cầu bãi bổ nhãnỢ để bãi bỏ Ộthông điệp yêu cầu nhãnỢ thì nhãn trong thông điệp ánh xạ nhãn có giá trị.
LSR có thể lựa chọn sử dụng nhãn hay Ộtừ bỏỢ (release) nó bằng một Ộthông điệp từ
bỏ nhãnỢ (Label Release message).
Một LSR bãi bỏ một Ộthông điệp yêu cầu nhãnỢ có thể không sử dụng lại ỘID thông điệpỢ của Ộ thông điệp yêu cầu nhãnỢ đó cho đến khi nó nhận được một trong số các thông điệp sau từ ngang hàng của nó:
Chương 2 Định tuyến báo hiệu
" Một Ộthông điệp thông báo đã bãi bỏ yêu cầu nhãnỢ (Label Request Aborted Notification message) xác nhận sự bãi bỏ.
=. Một Ộthông điệp ánh xạ nhãnỢ cho sự đáp lại Ộthông điệp yêu cầu nhãnỢ
(thông điệp này được yêu cầu bãi bỏ).
+
s Một Ộthông điệp thông báoỢ cho sự đáp lại Ộthông điệp yêu cầu nhãnỢ
(thông điệp này được yêu cầu bãi bỏ).
LSR duy trì một thời gian Timeout cho việc nhận các thông điệp trên. Nếu thời gian Timeout đã hết mà LSR chưa nhận được một trong số các thông điệp trên thì nó có thể sử dụng lại ID thông điệp của Ộthông điệp yêu cầu nhãnỢ.
~
Ở đây cần chú ý rằng sự đáp lại cho một Ộthông điệp yêu câu bãi bỏ nhãnỢ thì
không bao giờ theo trật tự. Một LSR khi nhận được một Ộthông điệp yêu cầu bãi bỏ
nhãnỢ phải xử lý nó ngay lập tức (đáp lại bằng một Ộthông báo đã bãi bỏ yêu cầu nhãnỢ hay bỏ qua nó).
2.3.3h) Thông điệp Ộrút lạiỢ nhấn (Label Withdraw Message)
Một LSR gởi một Ộthông điệp rút lại nhãnỢ (Label Withdraw message) tới một
ngang hàng LDP để báo cho ngang hàng rằng nó (ngang hàng) không thể tiếp tục sử
dụng một sự ánh xạ FEC-nhãn mà LSR đã quảng bá trước đây. Điều này bẻ gãy sự ánh xạ giữa các FEC và các nhãn
Sự mã hóa cho Ộthông điệp rút lại nhãnỢ có dạng :
Đồ án tốt nghiệp Trang 43
Chương 2 Định tuyến báo hiệu
Hình 2.36: Mã hóa thông điệp rút lại nhãn FEC TLV chỉ rõ FEC mà sự ánh xạ FEC-nhãn của nó được rút lại. (adsbygoogle = window.adsbygoogle || []).push({});
Các trường khác tương tự như các phần đã xét trước đây.
Các qui trình Ộthông điệp rút lai nhãnỢ
Một LSR gởi một Ộthông điệp rút lại nhãnỢ trong những điều kiện sau:
s=_ LSR không còn nhận ra một FEC đã biết trước đây mà nó đã được quảng bá
một nhãn.
" LSR đơn phương quyết định (có thể thông qua sự cấu hình ) không chuyển
mạch nhãn một FEC với sự ánh xạ nhãn sẽ được rút lại (withdraw) .
TLV FEC chỉ rõ EEC mà các nhãn liên kết với nó được rút lại . Nếu không có
TLV nhãn theo sau FEC đó, tất cả nhãn được liên kết với FEC đó được rút lại. Nếu
có TLV nhãn, chỉ nhãn được chỉ rõ trong TLV nhãn mới được rút lại.
TLV FEC có thể chứa Ộyếu tố FEC đại diệnỢ (Wildcard FEC element). Khi đó
nó có thể không chứa các yếu tố FEC khác . Trong trường hợp này , nếu Ộthông điệp
rút lại nhãnỢ có chứa một TLV nhãn thì nhãn (chứa trong TLV nhãn) sẽ được rút lại
từ tất cả các FEC mà nó kết nối . Nếu không có một TLV nhãn nào trong Ộthông
điệp rút lại nhãnỢ thì ỘLSR gởiỢ (sending LSR) sẽ rút lại tất cả sự ánh xạ nhãn trước
đây được quảng bá tới ỘLSR nhậnỢ (receiving LSR).
Một LSR khi nhận được Ộthông điệp rút lại nhãnỢ phải đáp lại bằng một Ộthông điệp từ bỏ nhãnỢ (Label Release message).
2.3.3i) Thông điệp từ bỏ nhấn (Label Release Message)
Được sử dụng bởi LSR khi nhận được chuyển đổi nhãn mà nó không cần thiết nữa. Điều đó thường xảy ra khi LSR giải phóng nhận thấy nút tiếp theo cho FEC không phải
là LSR quảng bá liên kết nhãn/FEC đó. Sự mã hóa cho Ộthông điệp từ bỏ nhãnỢ
Chương 2 Định tuyến báo hiệu
0 1 2 3 011|213)4|5161718191011/213/451617181910111213|44516171819|011
Hình 2.37: Mã hóa thông điệp từ bỏ nhãn
Các thông số cho sự mã hóa đã được tìm hiểu ở các phần trên.
Các qui trình Ộthông điệp từ bổ nhãnỢ
Một LSR gởi một Ộthông điệp từ bổ nhãnỢ trong những điều kiện sau:
eẹ LSR, mà nó đã gởi đi sự ánh xạ nhãn, bây giờ không còn là hop kế cho EEC được ánh xạ và nó (LSR đang xét) được cấu hình cho sự hoạt
động thận trọng (chỉ giữ lại nhãn cho hop kế). (adsbygoogle = window.adsbygoogle || []).push({});
ẹ LSR nhận được một sự ánh xạ nhãn từ một LSR không là hop kế của nó cho FEC được ánh xạ và nó (LSR đang xét) được cấu hình cho sự hoạt động thận trọng.
se LSR nhận được một Ộthông điệp rút lại nhãnỢ.
2.3.3 k) Thông điệp thông báo (Notification Message)
Một LSR gởi một Ộthông điệp thông báoỢ để báo cho ngang hàng biết về một sự
kiện quan trọng . Một Ộthông điệp thông báoỢ báo hiệu một lỗi không thể tránh được
hoặc cung cấp thông tin cố vấn. Sự mã hóa cho Ộthông điệp thông báoỢ có dạng:
0 1 2 3 Đồ án tốt nghiệp Trang 45
Chương 2 Định tuyến báo hiệu
Hình 2.38: Mã hóa thông điệp thông báo
TLV trạng thái (Status TLV): Chỉ ra sự kiện được báo hiệu . Sự mã hóa cho
'ỘT[LV trạng tháiỢ có dạng :
Hình 2.39: Mã hóa TLV trang thái
U bii: Nên bằng 0 khi ỘTL`V trạng tháiỢ được gởi trong Ộthông điệp thông báoỢ.
Nên bằng I1 khi ỘTLV trạng tháiỢ được gởi trong một thông điệp khác.
F bi: Nên giống như giá trị của F Ở bit trong trường Ộ mã trạng tháiỢ (Status
Code) .
Mã trạng thái (Status Code): Số nguyên không đấu dài 32 bit, mã hóa cho sự
kiện được báo hiệu. Cấu trúc của một Ộmã trạng tháiỢ :
Đồ án tốt nghiệp Trang 46
Chương 2 Định tuyến báo hiệu
Hình 2.40: Cấu trúc của một mã trạng thái
Ebu
se. Nếu sét lên 1, đây là một thông báo lỗi không tránh được . (adsbygoogle = window.adsbygoogle || []).push({});
e_ Nếu set xuống 0, đây là một thông báo cố vấn .
Fbi
e Bii chuyển tiếp. Nếu set lên 1, thông báo sẽ được chuyển tới LSR cho hop kế. Nếu sét xuống 0, thông báo sẽ không được chuyển.
Sfatus Data (dữ liệu trạng thái)
Số nguyên không dấu dài 30 bit, chỉ thông tin trạng thái.
Mã trạng thái giá trị 0 báo hiệu Ộthành côngỢ
TD thông điệp
e_ Có chiều dài 32 bit.
. Nếu giá trị khác 0, nó dùng để chỉ thông điệp ngang hàng mà ỘTLV trạng tháiỢ
ám chỉ. Nếu bằng 0, không có thông điệp ngang hàng nào được chỉ ra.
Loại thông điệp (message type): Nếu khác 0, trường này dùng để chỉ loại của
thông điệp ngang hàng mà ỘTLV trạng tháiỢ ám chỉ. Nếu bằng 0, ỘTLV trạng tháiỢ
không ám chỉ một loại thông điệp nào.
Ở đây cần chú ý, việc sử dụng ỘTLV trạng tháiỢ không giới hạn ở những Ộthông
4 ẤỢ
điệp thông báoỢ. Một thông điệp không phải loại Ộthông điệp thông báoỢ cũng có
thể mang ỘTLV trạng tháiỢ dưới dạng một thông số không bắt buộc, khi đó bit U của
ỘTLV trạng tháiỢ trong thông điệp này nên được set lên 1 để chỉ rằng nơi nhận nên Ộim lặngỢ (silently) loại bỏ TLUV nếu nó chưa chuẩn bị để giữ lại TLV.
Trên đây là vài dạng thông điệp thường thấy trong các thủ tục (qui trình). Bên
cạnh đó còn vài dạng thông điệp khác, những thông điệp này dùng để chuyên chở
Chương 2 Định tuyến báo hiệu
thông tin riêng của hãng hoặc dùng để thử nghiệm ..., tuy nhiên chúng không được xem xét ở đây.
2.3.4 LDP điêu khiển độc lập và phân phối theo yêu cầu
Vắ dụ dưới đây minh họa việc sử dụng bản tin Label Request và Label Mapping
trong chế độ công bố nhãn theo yêu cầu và điều khiển LSP độc lập. Trình tự thời
gian trao đổi các bản tin LDP giữa các đối tác (peer) thiết lập một LSP từ router lối
vào R1 qua R2 rồi đến router lối ra R3 cho một FEC có prefix Ộa.b/⁄16Ợ. R1 khởi tạo tiến trình bằng cách yêu cầu một nhãn cho EEC Ộa.b/⁄16Ợ từ hop kế của nó là R2. Vì sử dụng điều khiển độc lập nên R2 trả ngay một ánh xạ nhãn về cho R1 trước khi R2 (adsbygoogle = window.adsbygoogle || []).push({});
nhận được ánh xạ nhãn từ phắa downstream là R3. Cả R2 và R3 đáp ứng bằng bản tin Label Mapping, kết quả là trong FIB của RI và LFIB của R2, R3 có các entry gán kết nhãn hình thành nên đường chuyển mạch nhãn LSP.
Label Swiftched Path (LSP! ĐIY NSLS80000/001 0E 224000" trinh
-_abei Request ỘEC:a bi56
Label Manslng FEC:ab16 ~* & ệ
Ưab#: Mãpping FEC:a 1ã Ở B
tin
GỤT Ẩ QUY Ix TIM |OLT | ĐÓT IN[ 13 |GUT | GUT
PC | FC |xnLFE IF [LÊt| TẾ |xesrz [F EBL| F baakre
ab/16] 2 |PushA TA 5 2Z|8 | 3 |Pop
RIFiB R2 LFID R3 LFIE
Hình 2.41: Vắ dụ LDP chế độ điều khiển độc lập theo yêu cầu
LDP còn hỗ trợ các chế độ phân phối nhãn khác. Khi cấu hình ở chế độ công bố không cần yêu cầu (downstream unsolicited), các router sẽ không dùng bản tin Label Request. Nếu điều khiển tuân tự (ordered control) được cấu hình trên mỗi
giao diện, các yêu cầu nhãn sẽ làm cho các bản tin Label Mapping được trả về theo
thứ tự từ R3 đến R2, rồi mới từ R2 về R1. Tổng quát, trong chế độ phân phối theo yêu câu điều khiển tuần tự, ánh xạ nhãn diễn ra đầu tiên ở router lối ra, rồi sau đó lần lượt ngược về đến router lối vào.
2.4 Giao thức CR-LDP (Constrain-based routing LDP)
CR-LDP là giao thức mở rộng từ LDP (RFC 3212) nhằm hỗ trợ đặc biệt cho định
tuyến ràng buộc, kỹ thuật lưu lượng (TE) và các hoạt động dự trữ tài nguyên. Các
Chương 2 Định tuyến báo hiệu
khả năng của CR-LDP tùy chọn bao gồm thương lượng các tham số lưu lượng như
cấp phát băng thông, thiết lập và cầm giữ quyển ưu tiên.
2.4.1 Mở rộng cho định tuyến ràng buộc
CR-LDP bổ sung thêm các đối tượng Type-Length-Value mới sau đây (RFC 3212):
*. Tuyến tường minh ER (Explicit Route)
Chặng tường minh ER-Hop (Explicit Route Hop)
Các tham số lưu lượng
Sự lấn chiếm (Preemptions)
Nhận diện LSP (LSPID)
Ghim tuyến (Route Pinning) (adsbygoogle = window.adsbygoogle || []).push({});
Lớp tài nguyên (Resource Class)
CR-LSP FEC * * * x x%x %x *%x
Một số thủ tục mới cũng được bổ sung để hỗ trợ các chức năng cần thiết như:
*.. Báo hiệu đường (Path signalling) * Định nghĩa các tham số lưu lượng
+. Quản lý LSP (quyền ưu tiên, cam kết quần trị, v.v)
CR-LDP sử dụng cơ chế gán nhãn theo yêu cầu và điều khiển tuần tự. Một LSP
được thiết lập khi một chuỗi các bản tin Label Request lan truyền từ ingress-LSR đến egress-LSR, và nếu đường được yêu cầu thỏa mãn các ràng buộc (vắ dụ đủ băng thông khả dụng), thì các nhãn mới được cấp phát và phân phối bởi một chuỗi các bản tin Label Mapping lan truyền ngược về ingress-LSR. Việc thiết lập một CR-LSP có
thể thất bại vì nhiều lý do khác nhau và các lỗi sẽ được báo hiệu bằng bản tin Notilication.
2.4.2 Thiết lập một CR-LSP (Constrain-based routing LSP)
Để thiết lập một LSP theo một con đường định trước, CR-LDP sử dụng đối tượng tuyến tường minh ER (Explicit Route). ER được chứa trong các bản tin LABEL.
Chương 2 Định tuyến báo hiệu
~~-ệ< Label Requeszr ta .Ở ( ab@i Afapping
Hình 2.42: Thiết lập LSP với CR-LDP
Xét vắ dụ trong hình 32. Giả sử LSR A muốn thiết lập một con đường tường minh là B-C-D. Để thực hiện việc này, LSR A xây dựng đối tượng ER chứa tuần tự 3 nút
trừu tượng là LSR B, LSR C, LSR D. Mỗi nút được đại diện bằng một địa chỉ IP
prefix. LSR A sau đó xây dựng một bản tin Label Request có chứa đối tượng ER mới tạo. Khi bản tin được tạo xong, LSR A sẽ xem xét nút trừu tượng đầu tiên trong đối
tượng ER là LSR B, m kết nối đến LSR B và gởi bản tin Label Request trên kết nối