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 .
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) (adsbygoogle = window.adsbygoogle || []).push({});
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
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 ~* & ệ (adsbygoogle = window.adsbygoogle || []).push({});
Ư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)
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 (adsbygoogle = window.adsbygoogle || []).push({});
+. 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
đó. Khi LSR B nhận bản tin Label Request, LSR B nhận thấy nó là nút trừu tượng
đầu tiên trong đối tượng ER. LSR B sau đó tìm kiếm nút trừu tượng kế tiếp là LSR C và tìm kết nối đến LSR C. Sau đó LSR B thay đổi đối tượng ER và gởi bản tin Label.
Request đến LSR C, lúc này đối tượng ER chỉ gồm LSR C và LSR D. Việc điều khiển bản tin này tại LSR C cũng tương tự như ở LSR B.
Khi bản tin đến LSR D, LSR D nhận thấy rằng nó là nút cuối cùng trong đối
tượng ER. Vì vậy, LSR D tạo một bản tin Label Mapping và gởi nó đến LSR C. Bản tin này bao gồm đối tượng nhãn. Khi nhận bản tin này, LSR C dùng nhãn chứa trong bản tin để cập nhật LFIB. Sau đó, LSR C gởi bản tin Label Mapping đến LSR B. Bản tin này cũng chứa nhãn mà LSR C đã quảng bá. Việc điều khiển bản tin Label Mapping ở LSR B hoàn toàn tương tự như ở LSR C. Cuối cùng, LSR A nhận được
bản tin và LSP được thiết lập theo con đường định tuyến tường minh cho trước để |
mang thông tin về tài nguyên cần phải dự trữ.
Chương 2 Định tuyến báo hiệu
.4.3. Tiến trình dự trữ tài nguyên
(An An TH. Ở, ỘX CR.LDPFP Regitest Xỳe@ssage Lpb; ` -..'.'' (adsbygoogle = window.adsbygoogle || []).push({});
Ty ỞỞmEỢ CR-LDP Mapping Xessage
LIB Table L ị
Admission Comtrol 1 T6 teesrmmnrrmesmmih Resource
4811 siết rắ L1 t8 xế tr ẤP Table |
"` Ị ị itesource Mian aựer
Ạtutgooag-Labelaadi ) Í , biet Ạ¡
Ơutgutn-bdtorface | | Create/eleee BỌ
ị H [>> Tắn 1 ì
Ì Paeckel Ở.
ERB Table Tabl 1 Scheduler Ư -fm-+>Ở* -HI*ẹỞ~*
| Ở `
[S222 ch S4 H2 Xz c1 Tre TT che meeEU CS. t.~..= ị
+ CR-1.SE Lnfu,
* Servicet r =]_<_:.ỳ}.1Ở=ỘFỘỞ.. Hới ni] ng nem Ở ể
MPLS Node H Admission Contrel | Resource Ảfanager ử ị Tin n _t?
Hình 2.43: Tiến trình dự trữ tài nguyên
Khi nút CR-LDP nhận bản tin Label Mapping, nó lưu thông tin nhãn và giao diện vào bắng LIB, lưu thông tin CR-LSP được yêu cầu vào bảng cơ sở thông tin tuyến tường minh ERB (Explicit Route information Base). Rồi nó gọi Resource Manager
để tạo một hàng đợi phục vụ cho CR-LSP được yêu cầu, và lưu ServicelID của nó
vào bảng ERB. Cuối cùng, nó chuyển tiếp bản tin LSP Mapping tới nút MPLS kể
trước.
2.5 Giao thức RSVP-TE (RSVP Traffic Engineering)
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 (adsbygoogle = window.adsbygoogle || []).push({});
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 (adsbygoogle = window.adsbygoogle || []).push({});
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