Van Hanh Va Bao Duong Trong Mpls

TRƯỜNG …………………. KHOA……………………….

----- -----

BÁO CÁO TỐT NGHIỆP

Đề tài:

Vận hành và bảo dưỡng trong MPLS

Khóa luận tốt nghiệp Nhâm Đức Long – K49ĐA

Vận hành và bảo dưỡng trong MPLS 1 Trường ĐH Công Nghệ

MỞ ĐẦU

Xu hướng hội tụ các công nghệ mạng viễn thông và công nghệ thông tin tác động nhiều đến sự phát triển của mạng viễn thông, đòi hỏi mạng viễn thông phải có cấu trúc mở, linh hoạt, cung cấp nhiều loại dịch vụ khác nhau cho người sử dụng cũng như nâng cao hiệu quả khai thác.

Internet đã phát triển rất nhanh và trở nên rất phổ biến trong thời gian qua. Hiện nay nó đã trở thành phương tiện thông tin rất hiệu quả và tiện lợi phục vụ cho mục đích giáo dục, thương mại, giải trí, thông tin giữa các cộng đồng.. Khi mạng Internet ngày càng phát triển nhu cầu về lưu lượng mạng cũng như chất lượng dịch vụ, tính bảo mật, độ tin cậy ngày càng cao. Để đáp ứng được đòi hỏi này các nhà cung cấp dịch vụ Internet cần phải quan tâm đến 3 vấn đề kĩ thuật sau: đó là kiến trục mạng, khả năng mở rộng mạng và kĩ thuật điều khiển lưu lượng.

Chuyển mạch nhãn đa giao thức (Multi Protocol Label Switching-MPLS) là công nghệ xuất phát từ ý tưởng hợp nhất tốc độ chuyển mạch của ATM và tính năng kiểm soát của mạng dựa trên IP. MPLS cung cấp một nền tảng công nghệ mới cho quá trình tạo các mạng đa người dùng, đa dịch vụ với hiệu năng được cải tiến và đáp ứng được yêu cầu về chất lượng dịch vụ. MPLS là một trong những công nghệ nền tảng của mạng viễn thông thế hệ sau, nó cung cấp những ứng dụng quan trọng trong xử lý chuyển tiếp gói bằng cách đơn giản hóa quá trình xử lý đồng thời tích hợp với khả năng quản lý lưu lượng tạo ra môi trường đáp ứng cho yêu cầu của người sử dụng. Khi MPLS, với những ưu điểm của nó sẽ là một trong những giải pháp cho mạng đường trục thế hệ mới, hiện nay xu thế phát triển của MPLS là mọi lưu lượng trên MPLS (Any Traffic Over MPLS - ATOM) có khả năng đáp ứng bất kì loại dịch vụ nào : thoại, video. Fax, data…Chính vì vậy đề tài vận hành và bảo dưỡng mạng MPLS làm đề tài khóa luận tốt nghiệp cung cấp một một nền tảng mạng ổn định, có thể khai thác tối đa các lợi điểm của MPLS, nâng cao chất lượng dịch vụ.



LỜI CẢM ƠN

Em xin gửi lời cảm ơn chân thành tới Th.S Nguyễn Quốc Tuấn – Phó chủ nhiệm khoa Điện tử viễn thông kiêm Chủ nhiệm bộ môn Hệ thống viễn thông, khoa Điện tử viễn thông – Trường ĐH Công nghệ - ĐH Quốc Gia Hà Nội, người thầy đã tận tình chỉ bảo, hướng dẫn em thực hiện bài khóa luận này.

Em cũng xin chân thành cảm ơn các thầy giáo, cô giáo trong trường ĐH Công nghệ, đến tất cả những người thân trong gia đình và toàn thể bạn bè đã động viên giúp đỡ em trong quá trình thực hiện bài khóa luận.

Cuối cùng em xin gửi lời chúc tới thầy Nguyễn Quốc Tuấn, các thầy cô giáo trong khoa Điện tử viễn thông nói riêng và tòan thể các thầy cô trong trường luôn luôn mạnh khỏe, công tác tốt.

Hà nội, ngày 28/05/2008

Sinh viên Nhâm Đức Long



MỤC LỤC

Lời mở đầu 1

Lời cảm ơn 2

Các thuật ngữ viết tắt 7

Chương 1: Cơ sở hình thành của công nghệ MPLS 9

1.1 Xu hướng hội tụ của mạng viễn thông 9

1.2 Thực trạng của mạng IP truyền thống 10

1.3 Công nghệ ATM-mô hình hướng kết nối 11

1.4 Sự hình thành công nghệ MPLS 12

Chương 2: Tổng quan về công nghệ MPLS 14

2.1 Tổng quan 14

2.1.1 Tính thông minh phân tán 14

2.1.2 MPLS và mô hình OSI 14

2.2 Các khái niệm cơ bản trong MPLS 15

2.2.1 Miền MPLS (MPLS domain) 15

2.2.2 Lớp chuyển tiếp tương đương (FEC) 15

2.2.3 Nhãn và stack nhãn 16

2.2.4 Hoán đổi nhãn (Label Swapping) 16

2.2.5 Đường chuyển mạch nhãn LSP (Label Switched Path) 17

2.3 Mã hóa nhãn và các chế độ đóng gói nhãn MPLS 17

2.3.1 Mã hóa stack nhãn 17

2.3.2 Chế độ Frame 18

2.3.3 Chế độ Cell 19

2.4 Cấu trúc chức năng của MPLS 20



2.4.1 Kiến trúc một nút MPLS (LER và LSR) 20

2.4.2 Mặt phẳng chuyển tiếp (mặt phẳng dữ liệu) 21

2.4.3 Mặt phẳng điều khiển 23

2.5 Hoạt động chuyển tiếp MPLS 24

2.5.1 Hoạt động trong mặt phẳng chuyển tiếp 24

2.5.2 Gỡ nhãn ở hop áp cuối PHP (Penultimate Hop Popping) 25

2.6 Ưu điểm và ứng dụng của MPLS 25

2.6.1 Đơn giản hóa chức năng chuyển tiếp 25

2.6.2 Kỹ thuật lưu lượng 25

2.6.3 Định tuyến QoS từ nguồn 25

2.6.4 Mạng riêng ảo VPN 26

2.6.5 Chuyển tiếp có phân cấp (Hierachical Forwarding) 26

2.6.6 Khả năng mở rộng (Scalability) 26

Chương 3: Định tuyến và báo hiệu trong MPLS 27

3.1 Định tuyến trong MPLS 27

3.1.1 Định tuyến ràng buộc (Constrain based Routing) 27

3.1.2 Định tuyến tường minh (Explicit Routing) 28

3.2 Các chế độ báo hiệu trong MPLS 28

3.2.1 Chế độ phân phối nhãn 28

3.2.2 Chế độ duy trì nhãn 29

3.2.3 Chế độ điều khiển LSP 30

3.2.4 Các giao thức phân phối nhãn MPLS 31

3.3 Giao thức LDP (Label Distribution Protocol) 32

3.3.1 Hoạt động của LDP 32

3.3.2 Cấu trúc thông điệp LDP 34



3.3.3 Các bản tin LDP 35

3.3.4 LDP điều khiển độc lập và phân phối theo yêu cầu 36

3.4 Giao thức CR-LDP (Constrain based Routing LDP) 37

3.4.1 Mở rộng cho định tuyến ràng buộc 38

3.4.2 Thiết lập một CR- LSP (Constrain based routing LSP) 38

3.4.3 Tiến trình dự trữ tài nguyên 39

3.5 Giao thức RSVP-TE (RSVP Traffic Engineering) 40

3.5.1 Các bản tin thiết lập dự trữ RSVP 40

3.5.2 Các bản tin Tear Down, Error và Hello của RSVP-TE 41

3.5.3 Thiết lập tuyến tường minh điều khiển tuận tự theo yêu cầu 42

3.5.4 Giảm lượng overhead làm tươi RSVP 43

3.6 Giao thức BGP 44

3.6.1 BGPv4 và mở rộng cho MPLS 44

3.6.2 Kết nối MPLS qua nhiều nhà cung cấp dịch vụ. 45

Chương 4: Vận hành và bảo dưỡng trong MPLS 47

4.1 Giới thiệu 47

4.2 Các yêu cầu của OAM MPLS 47

4.2.1 Phát hiện và chẩn đóan các lỗi của mặt phẳng dữ liệu và mặt phẳng điểu khiển. 48

4.2.2 Phát hiện lỗi trong một đường chuyển mạch nhãn (LSP) 48

4.2.3 Các gói OAM di chuyển trên cùng một tuyến như là lưu lượng dữ liệu MPLS 49

4.2.4 Mô tả đặc điểm của tuyến. 49

4.2.5 Đo đạc các SLA 50

4.2.6 Sự ảnh hưởng lẫn nhau của OAM 50

4.2.7 Các MIB 50

4.2.8 Việc tính toán. 51



4.3 Vận hành và bảo dưỡng trên MPLS 51

4.3.1 LSP connectivity 51

4.3.1.1 Connectivity Verification (CV) 53

4.3.1.2 Chỉ thị lỗi chuyển tiếp gói tin (FDI) 54

4.3.1.3 Chỉ thị lỗi ngược (BDI) 55

4.3.2 Defect type codepoint 57

4.3.3 Tùy chọn cảnh báo router và nhãn cảnh báo router 61

4.3.3.1 Tùy chọn cảnh báo router 61

4.3.3.2 Nhãn cảnh báo router 62

4.3.4 Ping LSP MPLS 64

4.3.4.1 Các chi tiết Ping LSP 64

4.3.4.2 Điều hành Ping MPLS 69

4.3.4.3 Ping MPLS trong IOS Cisco. 70

4.3.5 Traceroute LSP MPLS 71

4.3.6 VCCV 72

4.3.7 IP Service Level Agreement 74

VRF – aware IP SLA 75

4.3.8 Netflow Accounting 76

4.3.9 SNMP/MIBs 78

4.3.9.1 Context – Based Access for SNMP over MPLS VPN 81

4.3.9.2 Các MIB VPN MPLS. 82

4.3.10 Syslog 82

* Ánh xạ thông điệp OAM (OAM Message Mapping) 83

4.3.11 Chuyển mạch bảo vệ (protection switching) 85

4.3.12 Định tuyến lại nhanh (Fast rerouting) 87

4.3.13 MPLS và kĩ thuật lưu lượng 88

Kết luận 91



CÁC THUẬT NGỮ VIẾT TẮT AS Automonuos System – Hệ tự trị ATM Asynchronous Transfer Mode – Chế độ truyền dẫn bất đồng bộ BGP Border Gateway Protocol – Giao thức cổng biên CAC Connection Admission Cotrol – Chức năng điều khiển chấp nhận kết nối CBR Constraint Based Routing – Định tuyến ràng buộc CR-LDP Constraint Routing Label Distribution Protocol – Định tuyến ràng buộc

với giao thức phân phối nhãn. CoS Class of Service – Lớp dịch vụ CSPF Constraint Shortest Path First – Định tuyến ràng buộc với đường ngắn

nhất. EGP Exterior Gateway Protocol – Giao thức cổng ngoài Egress LSR Egress Label Switching Router – Bộ định tuyến chuyển mạch nhãn lối vào ER Explicit Routing – Định tuyến tường minh FEC Forwarding Equivalence Class – Lớp chuyển tiếp tương đương. FR Frame Relay – Một giao thức truyền tin FTN FEC to NHLFE IETF Internet Engineering Task Force – Nhóm làm việc về các cơ cấu trên

Internet IGP Interior Gateway Protocol – Giao thức cổng nội Igress LSR Igress Label Switching Router – Bộ định tuyến chuyển mạch nhãn lối ra ILM Incoming Label Map – Bảng ánh xạ nhãn đến. IP Internet Protocol – Giao thức Internet ISP Internet Service Provider – Nhà cung cấp dịch vụ Internet LDP Label Distribution Protocol – Giao thức phân phối nhãn. LER Label Edge Router – Bộ định tuyến chuyển mạch nhãn biên LFIB Label Forwarding Information Base – Cơ sở thông tin chuyển tiếp nhãn LSP Label Switching Path – Đường chuyển mạch nhãn LSR Label Switching Router – Bộ định tuyến chuyển mạch nhãn NHLFE Next Hop Label Forwarding Switching Entry – Entry chuyển tiếp nhãn

Hop tiếp theo. MPLS Multi Protocol Label Switching – Chuyển mạch nhãn đa giao thức.



OSPF Open Shortest Path First – giao thức mở định tuyến theo đường ngắn nhất PHB Per Hop Behavior - Ứng xử theo từng chặng. PHP Penuntimate Hop Popping – Gỡ nhãn ở hop áp chót QoS Quality of Service – Chất lượng dịch vụ RIP Routing Information Protocol – Giao thức thông tin định tuyến RSPV Rersource Rersevation Protocol – Giao thức yêu cầu đặt trước các tài

nguyên SE Shared Explicit – Chia sẻ tường minh TE Traffic Engineering – Kĩ thuật lưu lượng ToS Type of Service – Kiểu của dịch vụ TTL Time To Live – Thời gian sống của gói tin UDP User Datagram Protocol – Giao thức dữ liệu người dùng VC Virtual Circuit – Mạch ảo VCI Virtual Circuit Identifier – Nhận dạng kênh ảo VP Virtual Path – Tuyến ảo VPI Virtual Path Identifier – Nhận dạng tuyến ảo VPN Virtual Private Network – Mạng riêng ảo



Chương 1

CÔNG NGHỆ MPLS

Mô hình TCP/IP là nền tảng của mạng truyền thông Internet ngày nay,. Với TCP/IP cho phép hoạt động thông tin diễn ra trong bất kì một mạng nào trong liên mạng phù hợp tốt như trong hoạt động truyền tin cả ở WAN và LAN. Mô hình TCP/IP hướng đến tối đa độ linh hoạt tại lớp ứng dụng cho người phát triển phần mềm, với mô hình này sẽ không cần quan tâm đến ứng dụngnào yêu cầu dịch vụ mạng và không quan tâm đến giao thức vận chuyển nào đang được dùng, chỉ có một giao thức mạng là IP. TCP/IP sử dụng kĩ thuật chuyển tiếp gói IP cho phép phục vụ như một giao thức đa năng cho phép bất kì máy tính nào ở bất cứ đâu truyền dữ liệu vào bất cứ thời điểm nào.

1.1 Xu hướng hội tụ của mạng viễn thông

Trong mạng điện thoại, các điện thoại thông thường chỉ được sử dụng để kết nối với một phía đối diện tương ứng nhằm thiết lập một cuộc gọi. Trong truyền số liệu, các đường dây chuyên dụng dùng cho một lượng hạn chế các thuê bao cũng được sử dụng. Ngoài ra các mạng lưới điện tín hiện nay cũng đang hoạt động như các mạng độc lập với các hệ thống thông tin khác. Mạt khác tầm quan trọng của việc đảm bảo các phương tiện thích hợp để trao đổi thông tin ngày càng tăng khi xã hội hiện đại ngày càng tiến gần đến thời đại thông tin. Để đương đầu với những thay đổi này các hệ thống chuyển mạch điện tử đang được tích hợp với những đặc điểm mới đang đươc phát triển. Thêm nữa việc nghiên cứu các dịch vụ mới hoàn toàn đáp ứng các yêu cầu của người sử dụng cũng đang được tiến hành. Gần đây các cố gắng nhằm kết hợp các hình thức khác nhau của các hệ thống thông tin đang được thực thi nhằm tạo được hiệu quả cao khác nhau của các hệ thống thông tin đang được thực thi nhằm tạo được hiệu quả cao hơn, chi phí thấp hơn. Nói chung mục tiêu cơ bản của truyền thông có thể coi như là quá trình gửi và nhận các thông tin cần thiết qua các lọai phương tiện truyền thông khác nhau. Đồng thời sự giao tiếp máy – máy được sử dụng để xử lý các số liệu cũng như điều khiển các tín hiệu.



Những dịch vụ kể trên có thể phân lọai theo chức năng thành các dịch vụ chuyển mạhc điện thoại, video và thông tin số liệu. Tùy theo dạng thông tin được xử lý mà các phương pháp phục vụ, các đặc tính lưu lượng, độ rộng các dải tần tryền dẫn và các đặc tính của các thiết bị đầu cuối sẽ được xắc định. Do vậy, để thỏa mãn nhu cầu ngày càng tăng, mạng viễn thông đòi hỏi có cấu trúc hiện đại, linh hoạt, cho phép kêt hợp các phưong tiện và nhất là phải thỏa mãn nhu cầu về truyền tải đa dịch vụ, đa phương tiện nhưng đồng thời cũng phải tận dụng được cơ sở hạ tầng của mạng viễn thông truyền thống và phải được chuẩn hóa trên toàn cầu để phá vỡ tính độc quyền.

Nếu một mạng lưới thông tin với mục đích đặc biệt và dễ thiết kế đứợc thiết lập nó có thể sẽ không đủ linh hoạt để đáp ứng những đòi hỏi mới một cách có hiệu quả. Ngược lại nếu nhiều loại dịch vụ thông tin được két hợp lại thành một mạng lưới duy nhất để hoạt động thì mạng lưới đó cho dù hơi kém nhiệu quả đôi chút nhưgn nó vẫn có thể dễ dàng vận hành, thay đổi và mở rộng. Ngoài ra các tổng đài như vậy sẽ dễ dàng điều khiển. Điều này đồng nghĩa với xu thế phát triển của các hệ thống viễn thông là hội tụ về một mạng viễn thôgn duy nhất đáp ứng được các đặc điểm kể trên đó chính là mạng IP. 1.2 Thực trạng của mạng IP truyền thống.

Mô hình TCP/IP vẫn có một số hạn chế nhất định đó là trong vấn đề định tuyến

IP từ khả năng mở rộng cho đến việc quản lý lưu lượng của mạng. Với việc xét các trường địa chỉ cho mỗi lần định tuyến, nếu mạng mở rộng càng lớn thì việc định tuyến sẽ hết sức khó khăn.

- Thứ nhất là vấn đề tốc độ và độ trễ, chuyển tiếp dựa trên IP cổ điển quá chậm để có thể điều khiển các đường truyền có lưu lượng lớn trên Internet. Tuy đã xuất hiện các phương pháp để nâng cao tốc độ như sử dụng bảng định tuyến nhanh cho các gói tin quan trọng, tuy nhiên các gói đến router vẫn lớn hơn so với khả năng xử lý của router do các giao thức đinh tuyến thường hướng lưu lượng vào cùng một số các kết nối nhất định vì vậy dẫn đến tình trạng mất gói, mất kết nối…

- Thứ hai là khả năng mở rộng của mạng. Với mạng internet hiện nay, số lượng người dùng ngày càng tăng, thiết bị thêm vào mạng ngày càng nhiều



đồng nghĩa với việc các router core phải hoạt động nhiều hơn và việc mở rộng mạng là khó khăn.

- Thứ ba là khả năng tích hợp các kĩ thuật của các lớp với nhau. Như ta đã biết trong mô hình TCP/IP các lớp được phân ra khá cụ thể và rõ ràng về các chức năng vì vậy mà việc tích hợp kĩ thuật mạng lớp 2 và lớp 3 là tương đối khó khăn.

1.3 Công nghệ ATM – Mô hình hướng kết nối.

ATM là công nghệ chuyển mạch hướng kết nối, tức là kết nối từ điểm đầu đến

điểm cuối phải được thiết lập trước khi thông tin được gởi đi. Việc tạo kết nối mạch ảo có thể đạt hiệu quả trong mạng nhỏ, nhưng đối với mạng lớn thì những vấn đề có thể xảy ra: Mỗi khi một router mới đưa vào mạng lõi WAN thì mạch ảo phải được thiết lập giữa router này với các router còn lại để đảm bảo việc định tuyến tối ưu. Điều này lưu lượng định tuyến trong mạng tăng.

Thông thường việc thiết lập kết nối này được thực hiện bởi giao thức báo hiệu. Giao thức này cung cấp các thông tin trạng thái liên quan đến kết nối cho các chuyển mạch nằm trên đường đã định tuyến. Chức năng điều khiển chấp nhận kết nối CAC (Connection Admission Control) đảm bảo rằng các tài nguyên liên quan đến kết nối hiện tại sẽ không được đưa vào để sử dụng cho các kết nối mới. Điều này buộc mạng phải duy trì trạng thái của từng kết nối (bao gồm thông tin về sự tồn tại của kết nối và tài nguyên mà kết nối đó sử dụng) tại các node có dữ liệu đi qua. Việc lựa chọn tuyến được thực hiện dựa trên các yêu cầu về QoS đối với kết nối và dựa trên khả năng của thuật toán định tuyến trong việc tính toán các tuyến có khả năng đáp ứng các yêu cầu QoS đó.

Do khả năng nhận dạng mạng, khả năng cô lập từng kết nối với các tài nguyên liên quan đến kết nối trong suốt thời gian tồn tại của kết nối mà môi trường hướng kết nối có thể đảm bảo chất lượng cho từng luồng thông tin. Mạng sẽ giám sát từng kết nối, thực hiện định tuyến lại trong trường hợp có sự cố và việc thực hiện định tuyến lại này cũng phải thông qua báo hiệu.



Từ cơ chế truyền tin ta thấy mạng hướng kết nối thích hợp với : - Các ứng dụng yêu cầu phải đảm bảo QoS một cách nghiêm ngặt. - Các ứng dụng có thời gian kết nối lớn.

Đối với các ứng dụng có thời gian kết nối ngắn thì môi trường hướng kết nối

dường như lại không thích hợp do thời gian để thiết lập kết nối cũng như tỉ lệ phần thông tin header lại quá lớn. Với các loại lưu lượng như vậy thì môi trường phi kết nối với phương thức định tuyến đơn giản, tránh phải sử dụng các giao thức báo hiệu phức tạp sẽ phù hợp hơn.

1.4 Sự hình thành công nghệ MPLS

Định tuyến IP truyền thống có nhiều giới hạn, từ vấn đề khả năng mở rông cho đến việc quản lý lưu lượng và tích hợp mạng lớp 2 đã tồn tại trong mạng của các nhà cung cấp dịnh vụ lớn. đã họat động từ lâu. Nhưng với sự phát triển nahnh chóng của mạng internet và hầu hết trong các môi trường đều chọn IP là giao thức lớp 3 thì những nhược điểm của IP truyền thống ngày càng bộc lộ rõ, trong khi đó công nghệ ATM có tốc độ truyền tin cao, đảm bảo thời jan thực và chất lượng dịch vụ theo yêu cầu định trước. Hơn nữa các dịch vụ thông tin thế hệ sau được chia thành hai xu hướng phát triển chính là: hoạt động kết nối định hướng và hoạt động không kết nối. Hai xu hướng páht triển này dần tiệm cận và hội tụ nhau tiến tới ra đời công nghệ IP over ATM. Sự kết hợp IP với ATM có thể là giải pháp kì vọng cho mạng viễn thông trong tương lai.

Tuy nhiên, IP và ATM là hai công nghệ hoàn toàn khác nhau, được thiết kế cho

những môi trường mạng khác nhau về giao thức, cách đánh địa chỉ, định tuyến , báo hiệu, phân bổ tài nguyên…khi các ISP càng mở rộng mạng theo hướng IP/MLPS/ATM (IP over ATM), họ càng nhận rõ nhược điểm của mô hình này, đó là sự phức tạp của mạng lưới do phải duy trì hoạt động của hai hệ thống thiết bị. Sự bùng nổ của mạng Internet dẫn tới xu hướng hội tụ của mạng viễn thông khác như mạng thoại, truyền hình dựa trên Internet, giao thức IP trở thành giao thức chủ đạo trong lĩnh vực mạng.

Xu hướng của các ISP là thiết kế và sử dụng các router chuyên dụng, dung lượng

chuyên tải lớn, hỗ trợ các giải pháp tích hợp, chuyển mạch đa lớp cho mạng đường trục



Internet. Nhu cầu cấp thiết trong bối cảnh này là phải ra đời một công nghệ lai có khả năng kết hợp các những đặc điểm tốt của chuyển mạch kênh ATM và chuyển mạhc gói IP. Công nghệ chuyển mạch nhãn đa giao thức MPLS ra đời đã đáp ứng được những nhu cầu của thị trường đúng theo tiêu chí páht triển của Internet đã mang lại những lợi ích thiết thực, đánh giấu một bước phát triển mới của mạng Internet trước xu thế tích hợp công nghệ thông tin và viễn thông. MPLS liên kết các ưu điểm của định tuyến lớp 3 connectionless và chuyển mạch lớp 2 connection-oriented. MPLS là một phương thức được cải tiến cho việc chuyển tiếp các gói tin trong bằng cách sử dụng các nhãn được gán thêm vào trong các gói tin IP. Mục tiêu chính của MPLS là tạo ra một cấu trúc mạng mềm dẻo để cung cấp cho đặc tính mở rộng và ổn định mạng. Điều này bao gồm kĩ thuật điều khiển lưu lượng và khả năng hoạt động của VPN và có liên quan đến chất lượng dịch vụ (QoS) và nhiều lớp dịch vụ (CoS).



Chương 2

CÁC ĐẶC TÍNH MẠNG MPLS 2.1 TỔNG QUAN 2.1.1 Tính thông minh phân tán

Trong mạng chuyển mạch kênh, tính thông minh chủ yếu tập trung ở mạng lõi

(core). Tất cả những thiết bị thông minh nhất đều đặt trong mạng lõi như các tổng đài toll, transit, MSC…Các thiết bị kém thông minh hơn thì đặt ở mạng biên (edge), ví dụ như các tổng đài nội hạt, truy nhập…

Trong mạng gói IP, tính thông minh phân tán gần như chia đều cho các thiết bị

trong mạng. Tất cả các router đều phải làm hai nhiệm vụ đó là định tuyến và chuyển mạch. Đấy là ưu điểm nhưng cũng là nhược điểm của mạng IP. Quan điểm của MPLS là tính thông minh càng đưa ra mạng biên thì mạng càng hoạt động tốt. Lý do là những thành phần ở mạng lõi phải chịu tải rất cao. Thành phần mạng lõi nên có độ thông minh thấp và năng lực chuyển tải cao. MPLS phân tách hai chức năng định tuyến và chuyển mạch: các router ở biên thực hiện định tuyến và gắn nhãn (label) cho gói. Còn các router ở mạng lõi chỉ tập trung làm nhiệm vụ chuyển tiếp gói tin với tốc độ cao dựa vào các nhãn. Tính thông minh được đẩy ra ngòai biên là một trong những ưu điểm lớn nhất của MPLS. 2.1.2 MPLS và mô hình tham chiếu OSI

Nguyên lý của MPLS là tất cả các gói IP sẽ được gắn nhãn và chuyển tiếp theo

một đường dẫn LSP (Label Switched Path). Các router trên đường dẫn chỉ căn cứ vào nội dung của nhãn để thực hiện quyết định chuyển tiếp gói tin mà không cần phải kiểm tra IP.



2.2 CÁC KHÁI NIỆM CƠ BẢN TRONG MPLS 2.2.1 Miền MPLS (MPLS domain)

Chuẩn RFC3031 mô tả miền MPLS là “một tập hợp các nút mạng thực hiện

hoạt động định tuyến và chuyển tiếp MPLS”. Một miền MPLS thường được quản lý và điều khiển bởi một nhà quản trị.

Miền MPLS được chia thành 2 phần: phần mạng lõi (core) và phần mạng biên (edge). Các nút thuộc miền MPLS được gọi là router chuyển mạch nhãn LSR (Label Switch Router). Các nút ở phần mạng lõi được gọi là transit- LSR hay core-LSR, thường được gọi tắt là LSR. Các nút ở biên được gọi là router biên nhãn LER (Label Edge Router).

Nếu một LER là nút đầu tiên trên đường đi của một gói xuyên qua miền MPLS thì nó được gọi là LER lối vào (ingress-LER), còn nếu là nút cuối cùng thì nó được gọi là LER lối ra(egress-LER).

2.2.2 Lớp chuyển tiếp tương đương (FEC)

Lớp chuyển tiếp tương đương FEC (Forwarding Equivalence Class) là một tập

hợp các gói được đối xử như nhau bởi một LSR, như vậy FEC là một nhóm các gói IP được chuyển tiếp trên cùng một đường chủyển mạch nhẵn LSR cho dù chúng có thể khác nhau về thông tin header lớp mạng. Hình dưới cho thấy cách xử lý này:

Hình 2.1. Lớp chuyển tiếp tương đương



2.2.3 Nhãn và stack nhãn RFC 3031 định nghĩa nhãn là “một bộ phận nhận dạng có độ dài ngắn và cố định

mang ý nghĩa cục bộ dùng để nhận biết một FEC”. Nhãn được dán lên một gói để báo cho LSR biết gói này cần đi đến đâu. Phần nội dung nhãn có độ dài 20bit không cấu trúc, như vậy số giá trị nhãn có thể có là 2. Giá trị nhãn định nghĩa chỉ số (index) để dùng trong bảng chuyển tiếp.

Một gói lại có thể được “dán chồng” nhìều nhãn, các nhãn này chứa trong một nơi gọi là stack nhãn (Label Stack). Stack nhãn là một tập hợp gồm một hoặc nhiều lối vào nhãn tổ chức theo nguyên tác LIFO. Tại mỗi hop trong mạng chỉ xử lý nhãn hiện hành trên đỉnh stack. Chính nhãn này sẽ được LSR sử dụng để chuyển tiếp gói tin.

Hình 2.2: Stack nhãn

Nếu gói tin chưa có nhãn thì stack nhãn là rỗng (độ sâu của stack nhãn bằng 0). Nếu stack có chiều sâu là d thì mức 1 sẽ ở đáy stack (bit S trong entry nhãn đặt lên là 1) và mức d sẽ ở đỉnh của stack. Một entry nhãn có thể được cất vào (push) hoặc lấy ra (pop) khỏi stack.

2.2.4 Hoán đổi nhãn (Label Swapping)

Hoán đổi nhãn là cách dùng các thủ tục để chuỷên tiếp gói tin. Để chuyển tiếp

gói có nhãn, LSR kiểm tra nhãn trên đỉnh stack và dùng ánh xạ ILM (Incoming Label Map) để ánh xạ nhãn này tới một entry chuyển tiếp nhãn NHLFE (Next Hop Label Forwarding Entry). Sử dụng thông tin trong NHLFE, LSR xác định ra nơi để chuyển tiếp gói tin và thực hiện một tác vụ trên stack nhãn. Rồi nó mã hóa stack nhãn mới vào gói và chuyển gói đi.



Chuyển tiếp gói chưa có nhãn cũng tương tự nhưng xảy ra ở ingress-LER. LER phải phân tích header lớp mạng để xắc định FEC rồi sử dụng ánh xạ FTN (FEC to NHLFE) để ánh xạ FEC vào một NHLFE.

2.2.5 Đường chuyển mạch nhãn LSP (Label Switched Path)

Đường chuyển mạch nhãn LSP là một đường nối giữa router ngõ vào và router

ngõ ra, được thiết lập bởi các nút MPLS để chuyển các gói đi xuyên qua mạng. Đường dẫn của một LSP qua mạng được định nghĩa bởi sự chuyển đổi các giá trị nhãn ở các LSR dọc theo LSP bằng cách dùng thủ tục hoán đổi nhãn. Khái niệm LSP tương tự như khái niệm mạch ảo (VC) trong ATM.

Hình 2.3: Đường chuyển mạch nhãn LSP

2.3 Mã hóa nhãn và chế độ đóng gói nhãn

2.3.1 Mã hóa stack nhãn

Khi nhãn được gắn lên gói, bản thân giá trị nhãn là 20 bit sẽ được mã hóa cùng với một thông tin cộng thêm để phụ trợ trong quá trình chuyển tiếp gói để hình thành một entry nhãn. Hình minh họa một dịnh dạng một entry nhãn trong stack nhãn.

Hình 2.4: Định dạng một entry trong stack nhãn



Một chồng nhãn 32 bit bao gồm các trường sau: Nhãn: là nhãn thực sự, có chiều dài là 20 bit. Do đó ta có thể tạo ra

được 220 giá trị nhãn khác nhau. Exp: trường Experimental có 3 bit, được dùng để định nghĩa lớp dịch

vụ. S: bit S là bit bottom-of-stack (dưới cùng của chồng nhãn). Một gói tin

có thể có nhiều nhãn, nếu nhãn thêm vào chồng nhãn là cuối cùng thì bit này được thiết lập lên 1.

TTL: trường Time to live có 8 bit, trường này mang ý nghĩa giống như bên IP. Tức là nó sẽ giảm đi 1 khi qua mỗi hop để ngăn chặn routing loop

Công thức để dán nhãn gói tin là:

Network Layer Packet + MPLS Label Stack

Label Spaces: chia làm 2 loại Per-Platform Label Space: các interface dùng chung giá trị nhãn. Per-Interface Label Space: mỗi interface mang giá trị nhãn riêng 2.3.2 Chế độ Frame

Các kĩ thuật lớp 2 như Ethernet, Token Ring, FDDI, PPP không có trường nào phù hợp trong header của frame có thể mang nhãn. Vì vậy stack nhãn sẽ được chứa trong header chêm (shim header). Shim header được chêm vào giữa header lớp liên kết và header lớp mạng, như trong hình 11. Đỉnh stack nằm liền sau header lớp 2 và đáy stack nằm liền trước header lớp mạng.

Hình 2.5 : Shim header được chêm vào giữa header lớp 2 và lớp 3



Roưter gửi frame phải có cách để báo cho router nhận biết rằng frame này có chứa shim header, cách thức này khác nhau giữa các kĩ thuật lớp 2. Ethernet sử dụng cặp giá trị ethertype 0x8847 và 0x8848 để chỉ thị frame đang mang gói MPLS unicast và multicast tương ứng. PPP sử dụng NCP (Network Control Program) sửa đổi gọi là MPLSCP (MPLS Control Protocol) và đánh dấu tất cả các gói có chứa shim header bằng giá trị 0x8281 trong trường PPP protocol

2.3.3 Chế độ cell

Chế độ cell được dùng khi ta có một mạng gồm cá ATM-LSR (là các chuyển

mạch ATM có hỗ trợ MPLS), trong đó nó sử dụng các giao thức phân phối nhãn MPLS để trao đổi thông tin VPI/VCI, trong VPI hoặc VCI của header cell ATM.

Hình 2.6 : Nhãn trong chế độ Cell ATM

Cell ATM gồm có 5 byte header và 48 byte payload. Để chuyển tải gói tin có kích thước lớn hơn 48 byte từ lớp trên đưa xuống, ATM phải gói tin thành nhiều phần nhỏ hơn, việc này gọi là phân đoạn (fragmentation) [4]. Quá trình phân đoạn do lớp AAL (ATM Adaptation Layer) đảm trách. Cụ thể AAL 5 PDU sẽ đựợc chia thành nhiều đoạn 48byte, mỗi đoạn 48byte này được thêm header 5byte để tạo ra một cell ATM.

Hình 2.7 : Đóng gói (encapsulation) gói có nhãn trên link ATM

Khi đóng gói có nhãn MPLS trên ATM, toàn bộ stack nhãn được đặt trong AAL

5 PDU. Giá trị thực sự của nhãn đỉnh được đặt trong trường VPI/VCI, hoặc đặt trong



trường VCI nếu 2 ATM-LSR kết nối nhau qua một đường ảo ATM (VP). Entry đỉnh stack nhãn phải chứa giá trị 0 (coi như entry giữ chỗ) và được bỏ qua khi nhận. Lý do các nhãn phải chứa ở cả trong AAL5 PDU và header ATM là để mở rộng độ sâu stack nhãn. Khi các cell ATM đi đến cuối LSP, nó sẽ được tái hợp lại. Nếu có nhiều nhãn trong stack nhãn, AAL5 PDU sẽ bị phân đoạn lần nữa và nhãn hiện hành trên đỉnh stack sẽ được đặt vào trường VPI/VCI.

2.4 CHỨC NĂNG MPLS

2.4.1 Kiến trúc một nút MPLS (LER và LSR) Hình dưới minh họa mặt phẳng điều khiển và chuyển tiếp của LSR và LER. Mặt

phẳng điều khiển có chức năng định tuyến IP dùng để giao tiếp với các LSR, LER khác họăc các router IP thông thường bằng các giao thức định tuyyến IP. Kết quả là một cơ sở thông tin định tuyến RIB (Routing Information Base) được tạo lập gồm các thông tin miêu tả các route khả thi để tìm các prefix địa chỉ IP. LER sẽ sử dụng các thông tin này để xây dựng cơ sở thông tin chuyển tiếp FIB (Fơrwarding Information Base) trong mặt phẳng chuyển tiếp.

Hình 2.8 : Cấu trúc của LER và transit LSR



Mặt phẳng điều khiển còn có chức năng báo hiệu MPLS dùng để giao tiếp với các LSR khác bằng một giao thức phân phối nhãn. Kết quả là một cơ sở thông tin nhãn LIB (Label Information Base) gồm các thông tin liên quan đến các gán kết nhãn đã được thương lượng với các router MPLS khác. Thành phần báo hiệu MPLS nhận thông tin từ chức năng định tuyến IP và LIB để xây dựng cơ sở thông tin chuyển tiếp nhãn LFIB (Label Forwarding Information Base) trong mặt phẳng chuyển tiếp. Một LER có thể chuyển tiếp các gói IP, gắn nhẵn vào gói (Label Push), hoặc gỡ nhãn ra khỏi gói (Label pop) trong khi đó một transit –LSR chỉ có khả năng chuyển tiếp gói có nhãn thêm hoặc bỏ bớt nhãn.

2.4.2 Mặt phẳng chuyển tiếp (mặt phẳng dữ liệu)

Mặt phẳng chuyển tiếp MPLS chịu trách nhiệm chuyển tiếp dữ liệu của người

dùng. Nó sử dụng LFIB để thực hiện chuyển tiếp các gói có gắn nhãn căn cứ vào giá trị của nhãn nằm trên đỉnh stack nhãn.

2.4.2.1. Cơ sở thông tin chuyển tiếp nhãn LFIB

Trong mạng IP, quyết định chuyển tiếp gói được xắc lập bằng cách thực hiện tra cứu địa chỉ đích trong bảng FIB để xắc định hop kế tiếp và giao diện ra. Trong mạng MPLS mỗi LSR duy trì một bảng LFIB riêng rẽ và tách biệt với FIB. Bảng LFIB có hai loại entry là ILM và FTN (FEC to NHLFE). NHLFE (Next Hop Label Forwarding Entry) là subentry chứa các trường như địa chỉ hop kế, các tác vụ stack nhãn, giao diện ra và thông tin header lớp 2, ILM ánh xạ một nhãn đến một hoặc nhiều NHLFE. Nhãn trong gói đến sẽ dùng để chọn ra một entry ILM cụ thể nhằm xắc định NHLFE. Còn FTN ánh xạ mỗi FEC vào một hoặc nhiều NHLFE. Nhờ các entry FTN, gói chưa có nhãn được chuyển thành gói có nhãn FTN, ILM và NHLFE



Hình 2.9 : NHLFE

Như vậy khi một gói không nhãn thuộc một FEC đi vào miền MPLS, ingress-LER sẽ sử dụng một entry LFIB loại FTN để chuyển gói không nhãn thành gói có nhãn. Sau đó tại các transit-LSR sử dụng một entry LFIB loại ILM để hoán đổi nhãn vào bằng nhãn ra. Cuối cùng, tại egress-LER sử dụng một entry LFIB loại ILM để gỡ bỏ nhãn đến và chuyển tiếp gói không có nhãn đến router kế tiếp.

2.4.2.2. Thuật toán chuyển tiếp nhãn

Các nút MPLS sử dụng giá trị nhãn trong các gói đến là chỉ mục để tra bảng LFIB. Khi tìm thấy entry tương ứng với nhãn đến, nút MPLS thay thế nhãn trong gói bằng nhãn ra và gởi gói đi qua giao diện ra để đến hop kế được đặc tả trong subentry NHLFE. Nếu subentry có chỉ định hàng đợi ra, nút MPLS sẽ đặt gói trên hàng đợi đã chỉ định. Trường hợp nút MPLS duy trì một LFIB riêng cho mỗi giao diện nõ sẽ dùng LFIB của giao diện mà gói đến để tra cứu chuyển tiếp gói tin.



Hình 2.10 : Qúa trình chuyển tiếp một gói đên next hop

Nút MPLS có thể lấy định vị được các thông tin chuyển tiếp cần thiết trong LFIB chỉ trong một lần truy xuất bộ nhớ, tốc độ thực thi rất cao nhờ các chip ASIC.

2.4.2.3. NHLFE (Next Hop Label Fơrwarding Entry)

NHLFE là lối vào phụ của ILM hoặc FTN, nó chứa các thông tin sau: - Hop kế của gói - Tác vụ sẽ được tiến hành trên stack nhãn của gói như sau: - Swap : thay nhãn ở đỉnh stack nhãn bằng một nhãn mới được chỉ định - Pop : bóc một nhãn ra khỏi stack. - Pusch: chồng thêm một nhãn vào trong stack nhãn.

Một ví dụ NHLFE cũng có thể chứa những thông tin sau:

- Đóng gói lớp datalink để sủ dụng khi truyền gói - Cách thức mã hóa stack nhãn khi truyền gói - Bất kì các thông tin khác cần thiết để xử lý gói một cách chính xác.

2.4.3 Mặt phẳng điều khiển

Nhiệm vụ của các giao thức trong mặt phẳng điều khiển là phân phối cac thông tin cần thiết cho mỗi LER và LSR để cấu hình bảng FIB và LFIB. Trong hình 14 một giao thức định tuyến sử dụng bảng thông tin định tuyến RIB hoạt động kết hợp với một giao thức báo hiệu MPLS sử dụng bảng thông tin nhãn LIB để phân phối các nhãn. Việc phân tách mặt phẳng điều khiển và mặt phẳng chuyển tiếp cho phép cài đặt một giao thức điều khiển MPLS trên một ATM switch.

Có vấn đề đặt ra là : Tại sao MPLS cần giao thức báo hiệu, trong khi router IP cổ điển chỉ cần định tuyến IP. Một lý do quan trọng phải dùng giao thức báo hiệu MPLS kêt hợp với một giao thức định tuyến xuất phát từ sự cần thiết phải thực hiện định tuyến ràng buộc của đường chuyển mạch nhãn MPLS.



2.5 CHUYỂN TIẾP MPLS

2.5.1 Hoạt động trong mặt phẳng chuyển tiếp

FEC là một tập con các gói căn cứ theo một số thông tin trong header IP được dùng bởi FIB. Một FEC được dùng thường dựa theo luật “longest prefix mạtch” trên địa chỉ IP đích. Ví dụ: các địa chỉ IP so trùng 16bit đầu có dạng “a.b.*.*” đựoc biểu diễn là a.b/16” cho entry FEC đầu tiên trong bảng FIB. FEC còn có thể căn cứ bổ sung theo các trường khác trong header IP như ToS hay Diffserv, FIB sử dụng FEC để xác định ra giao tiếp đi đến hop kế cho các gói tin IP, cách thực hiện giống các router cổ điển.

Hình 2.11: Bên trong mặt phẳng chuyển tiếp MPLS

Với các ví dụ về hoạt động LFIB ở hình trên, phần ILM của LFIB thao tác trên một gói có nhãn và ánh xạ một nhãn vào (incoming label) tới một tập các entry NHLFE. ILM được thể hiện trong hình bởi các cột IN-IF và IN-LBL, nhưng cũng có thể là một bảng riêng rẽ cho một giao tiếp. FTN (FEC to NHLFE) của FIB ánh xạ một FEC tới một tập hợp gồm môt hoặc nhiều NHLFE. Như ví dụ trong hình, nhãn A được đẩy (push) lên các gói IP thưộc FEC “d.e/16”. Lưu ý ILM hoặc FTN có thể ánh xạ tới nhiều NHLFE, chẳng hạn để dùng trong cân bằng tải.



2.5.2 Gỡ nhãn ở hop áp cuối PHP (Penultimate Hop Popping)

Một tối ưu hóa quan trọng mà MPLS hỗ trợ là tránh việc tra cứu nhãn (label lookup) phải xứ lý o ử egress-LER trong trường hợp một gói đi trên một LSP mà yêu cầu tra cứu IP (IP lookup) tiếp ngay sau đó. Trong hình 2.11 một gói đến có nhãn A được gỡ nhãn và chuyển sang FIB để tra cứu tiếp trên header IP. Để tránh việc xử lý phát sinh thêm này, MPLS định nghĩa một tiến trình gọi là gỡ nhãn ở hop áp cuối PHP, trong đó router áp cuối trên LSP sẽ gỡ nhãn thay vì egress-LER phải làm việc này. Nhờ vậy cắt giảm được việc xử lý ở router cuối cùng trên LSP.

2.6 ƯU ĐIỂM VÀ ỨNG DỤNG CỦA MPLS

2.6.1 Đơn giản hóa chức năng chuyển tiếp

MPLS sử dụng cơ chế chuyển tiếp căn cứ vào nhãn có độ dài cố định nên quyết định chuyển tiếp có thể xắc định ngay chỉ với một lần tra cứu chỉ mục trong LFIB. Cơ chế này đơn giản và nhanh hơn nhiều so với giải thuật “longest prefix match” dùng trong chuyển tiếp gói datagram thông thường.

2.6.2 Kỹ thuật lưu lượng

Ưu điểm lớn nhất cua MPLS là khả năng thực hiện kỹ thuât lưu lượng (TE- Traffic Engineering), nó đảm bảo lưu lượng được định tuyến đi qua một mạng theo một cách thức tin cậy và hiệu quả nhất. Kỹ thuật lưu lượng cho phép các ISP định tuyến lưu lượng theo cách họ có thể cung cấp dịch vụ tốt nhất cho khách hàng ở khía cạnh thông lượng và độ trễ. MPLS – TE cho phép lưu lượng đựoc phân bố hợp lý qua toàn bộ hạ tầng mạng. Tối ưu hóa hiệu suất sử dụng mạng.

2.6.3 Định tuyến QoS từ nguồn

Định tuyến QoS từ nguồn là một cơ chế trong đó các LSR được xác định trước ở nút nguồn (LSR lối vào) dựa vào một thông tin về độ khả dụng tài nguyên trhogn mạng cũng như yêu cầu QoS của luồng lưu lượng. Nói cách khác, nó là một giao thức định tuyến có mở rộng chỉ tiêu chọn dường để bao gồm các tham số như băng thông khả



dụng, việc sử dụng link và đường dẫn end to end, độ chiếm dụng tài nguyên của nút, độ trễ và biến động trễ.

2.6.4 Mạng riênng ảo VPN

VPN là cho phép khách hàng thiết lập mạng riêng giống như thuê kênh riêng nhưng với chi phí thấp hơn bằng cách sử dụng mạng hạ tầng công cộng dùng chung. Kiến trúc MPLS đáp ứng tất cả các yêu cầu cần thiết để hỗ trợ VPN bằng cách thiết lập các đường hầm LSP sử dụng định tuyến tường minh. Do đó, MPLS sử dụng các đường hầm LSP cho phép nhà khai thác cung cấp dịch vụ VPN théo cách tích hợp trên cùng hạ tầng mà họ cung cấp dịch vụ Internet. Hơn nữa, cơ chế xếp chồng nhãn cho phép cấu hình nhiều VPN lồng nhau trên cùng hạ tầng mạng.

2.6.5 Chuyển tiếp có phân cấp (Hiearchical Forwarding)

Thay đổi đáng kể nhất được MPLS đưa ra không phải ở kiến trúc định tuyến mà là kiến trúc chuyển tiếp. Sự cải tiến trong kiến trúc chuyển tiếp có tác độngđáng kể đến khả năng cung cấp chuyển tiếp phân cấp. Chuyển tiếp phân cấp cho phép lông một LSP vào trong một LSP khác (xếp chồng nhãn hay còn gọi là điều khiển gói đa cấp). Thực ra chuyển tiếp phân cấp không phải là kĩ thuật mới; ATM đã cung cấp cơ chế chuyển tiếp 2 mức với khái niệm đường ảo (VP) và kênh ảo (VC). Tuy nhiên MPLS cho phép các LSP được lồng nhau một cách tùy ý, cung cấp điều khiển gói đa cấp cho việc chuyển tiếp.

2.6.6 Khả năng mở rộng Scalability

Chuyển mạch nhãn cung cấp một sự tách biệt tòan diện hơn giữa định tuyến liên miền (inter domain) và định tuyến nội miền (intra domain) điều này cải thiện đáng kể khả năng mở rộng của các tiến trình định tuyến. Hơn nữa khả năng mở rông của MPLS còn nhờ vào FEC (thu gom luồng) và xếp chồng nhãn để hợp nhất (merging) hoặc lồng nhau (nesting) các LSP. Ngòai ra nhiều LSP liên kết với các FEC khác nhau có thể được trộn vào cùng một LSP. Sử dụng các LSP lồnhg nhau cũng cải thiện khả năng mở rộng của MPLS.



Chương 3:

ĐỊNH TUYẾN VÀ BÁO HIỆU TRONG MPLS 3.1 ĐỊNH TUYẾN TRONG MPLS

MPLS hỗ trợ cả hai kĩ thuật định tuyến: định tuyến từng chặng hop by hop và định tuyến ràng buộc (constrain based routing). Định tuyến từng chặng cho phép mỗi nút nhận dạng các FEC và chọn hop kế cho mỗi FEC một cách độc lập, giống như định tuyến trong mạng IP. Tuy nhiên nếu muốn triển khai kĩ thuật lưu lượng vói MPLS bắt buộc phải sử dụng kiểu định tuyến ràng buộc

. 3.1.1 Định tuyến ràng buộc

Định tuyến ràng buộc là một phương tiện để thực hiện xử lý tự động hóa kĩ thuật lưu lượng, khắc phục đựoc các hạn chế của định tuyến theo đích (destination based routing). Khắc phục được các hạn chế của định tuyến theo đích (thuật toán chọn đường ngắn nhất OSPF) mà còn sử dụng các metric đặc thù khác như băng thông, trễ, cost và biến động trễ. Giải thuật chọn đường có khả năng tối ưu hóa theo một hoặc nhiều metric này, thông thường người ta sử dụng metric dựa trên số lượng hop và băng thông.

Để đường được chọn có số lượng hop nhỏ nhất nhưng phải đảm bảo băng thông khả dụng trên tất cả các chặng liên kết, quyết định cơ bản như sau: chọn đượng ngắn nhất trong số tất cả các đường có băng thông khả dụng thỏa mãn yêu cầu.

Hình 3. 1 : Một ví dụ về định tuyến ràng buộc

Định tuyến ràng buộc có 2 kiểu online và offline. Kiểu online cho phép các router tính đường cho các LSP bất kì lúc nào. Trong kiểu offline, một server tính đường



cho các LSP theo định kì (chu kì có thể đựoc chọn bởi nhà quản trị, thừờng là vài giờ hoặc vài ngày). Các LSP được báo hiệu thiết lập theo các đường đã chọn.

3.1.2 Định tuyến tường minh

Định tuyến tường minh (Explicit Routing) là một tập con của định tuyến ràng buộc, trong đó sự ràng buộc là đối tượng tuyên tường minh ER.

Tuyến tường minh là một danh sách các nút trừu tượng (abstract node) mà một đường chuyển mạch nhãn ràng buộc CR-LSP phải đi qua. Nút trừu tượng có thể là một nút địa chỉ IP hoặc một nhóm nút (như IP prefix hoặc một AS). Nếu ER chỉ quy định một nhóm trong số các nút mà CR-LSP đi qua thì nó được gọi là tuyến tường minh thả lỏng (loose ER). Ngược lại nếu ER quy định toàn bộ các nute trên CR-LSP thì được gọi là tuyến tường minh ngiêm ngặt (strict ER).

CR-LSP được mã hóa như là một chuỗi các ER-hop (chặng tường minh) chứa trong một cấu trúc Type-Length-Value ràng buộc (contraint based route TLV). Mỗi ER-hop có thể xắc định một nhóm các nút. CR-LSP khi đó bao gồm tất cả các nhóm nút đã được xắc định theo thứ tự xuất hiện trong cấu trúc TLV.

3.2 CÁC CHẾ ĐỘ BÁO HIỆU MPLS

3.2.1 Chế độ phân phối nhãn

MPLS cho phép hai chế độ hoạt động của các LSR để phân phối các ánh xạ nhãn, đó là phân phối không cần yêu cầu (downstream unsolicited) và phân phối theo yêu cầu (downstream on demand). Thuật ngữ downstream ở đây ngụ ý rẳng phía downstream sẽ thực hiện gán kết nhãn và thông báo gán kết đó cho phía upstream.

3.2.1.a Phân phối nhãn không cần yêu cầu (downstream unsolicited)

Downstream-LSR phân phối các gán kết nhãn đến upstream-LSR mà không cần

có yêu cầu thực hiện việc kết nhãn.Nếu downstream-LSR chính là hop kế đối với định tuyến IP cho một FEC cụ thể thì upstream-LSR có thể sử dụng kiểu kết nhãn này để chuyển tiếp các gói trong FEC đó đến downstream-LSR.



Hình 3.2 : Phân phối nhãn không theo yêu cầu

3.2.1.b Phân phối nhãn theo yêu cầu

Upstream-LSR phải yêu cầu rõ ràng một gán kết cho một FEC cụ thể thì downstream-LSR mới phân phối. Trong phương thức này, downstream-router không nhất thiết phải là hop kế đối với định tuyến IP co FEC đó, điều này rất quan trọng đối với các LSP định tuyến tường minh.

Hình 3.3 : Phân phối nhãn theo yêu cầu

3.2.2 Chế độ duy trì nhãn

Một upstream-LSR có thể nhận các gán kết nhãn cho cùng một FEC X từ nhiều downstream-LSR. Có hai chế độ duy trì các gán kết nhãn nhận được là duy trì nhãn tự do (liberal label retention) và duy trì nhãn bảo thủ (conservative label retention).

3.2.2.a Duy trì nhãn tự do

Phía upstream (LSR1) lưư trữ tất cả các gán kết nhãn nhận được, bất chấp việc downstream-LSR có phải là hop kế đối với định tuyến IP hay không. Ưu điểm chính của duy trì nhãn tự do là hop kế đối với định tuyến Ip hay không. Ưu điểm chính của duy trì nhãn tự do là có thể phản ứng nhanh với sự thay đổi định tuyến vì các gán kết nhãn đã có sẵn. Nhược điểm là LSR phải duy trì nhiều gán kết nhãn không dùng và có thể gây ra loop định tuyến tạm thời khi thay đổi định tuyến.



Hình 3.4 : Duy trì nhãn tự do

3.2.2.b Duy trì nhãn bảo thủ

Upstream-LSR hủy tất cả các gán kết nhãn khác, chỉ giữ lại gán kết nhãn gởi từ downstream-LSR đang là hop kế hiện hành. Chế độ này có ưu điểm là LSR chỉ cần duy trì số gán kết FEC nhãn ít hơn, nhưng đáp ứng chậm khi thay đổi định tuyến vì gán kết nhãn mới phải được yêu cầu và phân phối lai. Đây là chế độ thích hợp cho các LSR chỉ hỗ trợ một số lượng nhãn hạn chế (như các chuyển mạch ATM).

Hình 3.5 : Duy trì nhãn bảo thủ.

3.2.3 Chế độ điều khiển LSP Khi một FEC ứng với một prefix địa chỉ được phân phối định tuyến IP, việc thiếp lập mối kết hợp giữa các gán kết nhãn tại một LSR có thể thực hiện theo hai cách sau:

3.2.3.a Điều khiển độc lập Khi mỗi LSR nhận dạng ra một FEC thì nó quyết định gán kết ngay một nhãn

cho FEC đó và công bố luôn gán kết đó cho các đối tác phân phối nhãn (label distribution peers). Điều này tương tự như định tuyến IP thông thường, ở đó mỗi router ra quyết định độc lập về nơi cần chuyển gói tin đi. Điều khiển độc lập có ưu điểm là thiết lập LSP nhanh vì việc kết nhãn diễn ra song song giữa nhiều cặp LSR và dòng lưu



lượng có thể bắt đầu truyền mà không cần đợi cho tất cả các gán kết nhãn thiết lập xong.

Hình 3.6 : Điều khiển độc lập.

3.2.3.b Điều khiển tuần tự

Một downstream-LSR thực hiện kết nhãn cho một FEC và thông báo gán kết đó chỉ nếu nó là LSR lối ra hoặc nếu nó đã nhận được một gán kết nhãn cho FEC đó từ router hướng downstream của nó. Việc thiết lập LSP tuần tự bắt đầu ở LSR lối ra và diễn ra nối tiếp theo hướng ngược về LSR lối vào. Các LSP định tuyến tường minh bắt buộc phải sử dụng kiểu điền khiển tuần tự và quá trình phân phối nhãn theo chuỗi có thứ tự sẽ tạo ra thời gian trễ trước khi dòng lưu lượng đi trên LSP có thể bắt đầu. Tuy nhiên điều khiển tuần tự cung cấp phương tiện tránh loop và đạt được mức độ thu gom chắc chắn hơn.

Hình 3.7 : Điều khiển tuần tự.

3.2.4 Các giao thức phân phối nhãn MPLS Giao thức phân phối nhãn là một tập hợp các thủ tục mà nhờ nó một LSR có thể

thông báo cho một LSR khác biết về các mối gán kết nhãn FEC mà nó đã tiến hành. Kiến trúc MPLS không chỉ định một giao thức phân phối nhãn duy nhất nào, do đó có thể có nhiều lựa chọn, mỗi giao thức có ưu điểm và nhược điểm riêng.



3.3 Giao thức LDP (Label Distribution Protocol)

LDP được chuẩn hóa trong RFC 3036, nó được thiết kế để thiết lập và duy trì

các LSP định tuyến không ràng buộc (unconstraint routing). Vùng hoạt động của LDP có thể là giữa các LSR láng giềng trực tiếp hoặc gián tiếp.

Hình 3.8 : Vùng hoạt động của LDP.

3.3.1 Hoạt động của LDP

LDP có 4 chức năng chính là phát hiện LSR láng giềng (neighbor discovery), thiết lập và duy trì phiên, quảng bá nhãn (label advertisement) và thông báo (notification), tương ứng với các chức năng trên, có 4 lớp thông điệp LDP sau đây:

- Discoverry: Để trao đổi định kì bản tin hello nhằm loan báo và kiểm tra một LSR kết nối gián tiếp hoặc trực tiếp.

- Session: Để thiết lập thương lượng các thông số cho việc khởi tạo, duy trì và chấm dứt các phiên ngang hàng LDP. Nhóm này bao gồm bản tin Initialization, keepalive.



- Advertisement: Để tạo ra , thay đổi hoặc xóa các ánh xạ FEC tới nhãn. Nhóm này bao gồm bản tin Label Mapping, Label Withdrawal, Label Release, Label Request, Label Request Abort.

- Notification: Để truyền đạt các thông tin trạng thái, lỗi hoặc cảnh báo. Các thông điệp discovery được trao đổi trên UDP. Các kiểu thông điệp còn lại

đòi hỏi phát tin cậy nên dùng TCP. Trường hợp hai LSR có kết nối lớp 2 trực tiếp thì thủ tục phát hiện neighbor trực tiếp như sau:

- Một LSR định kì gửi đi bản tin hello tới các cổng UDP 646 địa chỉ multicast (tất cả các router trong subnet)

- Tất cả các LSR tiếp nhận bản tin hello này trên cổng UDP. Đến một thời điểm nào đó LSR sẽ biết được tất cả các LSR khác mà nó có kết nối trực tiếp.

- Khi LSR nhận biết đựoc địa chỉ của LSR khác bằng cơ chế này thì nó sẽ thiết lập kết nối TCP đến LSR đó. Khi đó phiên LDP được thiết lập giữa 2 LSR.

Phiên LDP là phiên song hướng nên mỗi LSR ở hai đầu kết nối đều có thể yêu cầu và gửi liên kết nhãn.

Hình 3.9 : Trao đổi thông điệp LDP.

Trong trường hợp hai LSR không có kết nối lớp 2 trực tiếp (neighbor gián tiếp) thì LSR định kì gửi bản tin hello đến cổng UDP đã biết tại địa chỉ IP xắc định được khai báo khi lập cấu hình. Đầu nhận bản tin này có thể trả lời lại bằng bản tin hello khác và việc thiết lập các phiên LDP được thực hiện như trên.



3.3.2 Cấu trúc thông điệp LDP Trao đổi thông điệp LDP thực hiện bằng cách gửi các LDP-PDU thông qua các

phiên LDP trên kết nối TCP. Mỗi LDP-PDU có thể mang một hoặc nhiều thông điệp và các thông điệp này không nhất thiết phải có liên quan với nhau.

3.3.2.a LDP PDU

Mỗi PDU của LDP bao gồm một header LDP và theo sau là một hoặc nhiều

thông điệp LDP. Phần header LDP có dạng như sau:

LDP header. - PDU Length (2octet): số nguyên chỉ chiều dài của PDU theo octet, không

tính trường - Version và PDU Length. - LDP Identifier (6octet): xác định không gian nhãn được cấp phát. Bốn octet

đầu là giá trị duy nhất toàn cục nhận dạng LSR, như địa chỉ IP (router ID) được gán cho LSR. Hai octets sau xắc định một không gian nhãn bên trong LSR. Hai octets này được set vè 0 cho không gian nhãn “ per platform”.

3.3.2.b Định dạng thông điệp LDP Tất cả các thông điệp LDP có cùng format như sau:

Format thông điệp LDP.



Bít U: bít “unknown”, luôn là 0 vì đặc tả LDP không có kiểu bản tin unknown. Bảng sau là các giá trị định nghĩa trường message type:

Message Length: Chiều dài của các trường sau Message Length tính theo octet

(gồm Message ID, các tham số bắt buộc và tùy chọn). Message ID đôi khi được dùng để liên kết một số bản tin với các bản tin khác, ví

dụ như một bản tin đáp ứng sẽ có cùng Message ID với bản tin yêu cầu tương ứng. Các tham số bắt buộc và tùy chọn phụ thuộc vào các loại bản tin được gửi, chúng thường dùng kiểu mã hóa TLV (Type Length Value). Nói chung mọi thứ xuất hiện trong một thông điệp LDP có thể được mã hóa kiểu TLV, tuy nhiên đặc tả LDP không phải lúc nào cũng sử dụng lươc đồ TLV.

3.3.3 Các bản tin LDP

- Hello: được trao đổi trong suốt quá trình hoạt động LDP như trình bày trên hình.

- Initialization: được gửi đi khi bắt đầu một phiên LDP giữa 2 LSR để trao đổi các tham số, các tùy chọn cho phiên. Các tham số này bao gồm: + Chế độ phân bổ nhãn. + Các gía trị bộ định thời. + Phạm vi các nhãn sử dụng trong kênh giữa 2 LSR đó.



Cả 2 LSR đều có thể gửi các bản tin Initialization và LSR nhận được sẽ trả lời bằng Keepalive nếu các tham số được chấp nhận. Nếu có một tham số nào đó không được chấp nhận thì LSR trả lời thông báo có lỗi và phiên kết thúc.

- Keepalive: Được gửi định kì khi không còn bản tin nào cần gửi để đảm bảo cho mỗi thành phần LDP biết rằng thành phần LDP khác đang họat động tốt. trường hợp không xuất hiện bản tin Keepalive hay một số bản tin LDP khác trong khoảng thời gian nhất định thì LSR sẽ xắc định đối tác LDP hỏng hoặc kết nối có sự cố và phiên LDP chấm dứt.

- Label Mapping: được sử dụng để quảng bá gán kết giữa FEC và nhãn. - Label Withdrawal: Thực hiện quá trình ngược lại với bản tin Label Mapping,

nó được sử dụng để xóa bỏ gán kết đã thực hiện trong label mapping. Bản tin này được sử dụng trong trường hợp:

+ Khi có sự thay đổi trong bảng định tuyến (thay đổi Prefix địa chỉ), lúc đó LSR không còn nhận ra FEC này nữa.

+ Thay đổi trong cấu hình LSR làm tạm dừng việc chuyển nhãn các gói trong FEC đó.

- Label Release: đượ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ừong 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 đó.

- Label Request: Sử dụng trong chế độ hoạt động gán nhãn theo yêu cầu, LSR sẽ yêu cầu gán nhãn từ LSR kế cận phía downstream bằng bản tin này.

- Label Request Abort: Nếu bản tin Label Request cần phải hủy bỏ trước khi được chấp nhận (do nút kế tiếp trong FEC yêu cầu đã thay đổi), thì LSR yêu cầu sẽ loại bỏ yêu cầu trước đó bằng bản tin Label Request Abort.

3.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 FEC “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 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ề 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 R1 và LFIB của R2 và 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.

Hình 3.10 : 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 0, 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 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

3.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 họat độgn dự trữ tài nguyên. Các khả năng cảu 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..



3.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 (routing Pinning) + Lớp tài nguyên (resource class) + CR – LSP FEC

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ị,…)

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-LSP đến egress-LSR, và nếu đường được yêu cầu thỏa mãn các ràng bụộ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ề igress-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 Notification.

3.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.



Hình 3.11 : Thiết lập LSP với CR-LDP.

3.4.3 Tiến trình dự trữ tài nguyên

Hình 3.12 : Tiến trình dự trữ tài nguyên.

Tiến trình dự trữ tài nguyên như trong hình . Khi một nút CD-LDP nhận được một bản tin Label Request, nó gọi Admission Control để kiểm tra xem nút này có các tài nguyên được yêu cầu không. Nếu có đủ tài nguyên khả dụng, Admission Cotrol dự trữ nó bằng cách cập nhật bảng định Resource. Sau đó bản tin Label Request được chuyển tiếp đến nút MPLS kề sau.

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ôgn 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ưư Service ID 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.



3.5 GIAO THỨC RSVP-TE

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. IETF đã 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 dõ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. 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 ngĩ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.

3.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íh lưư lượng của nó. Bản tin Path chứa 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), session 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 label request hỗ trợ chế độ công bố nhãn theo yêu cầu. sender template chứa địa chỉ IP 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ụgn tốc độ đỉnh (peak rate), thùgn 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 (route 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.

3.5.2 Các bản tin 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 họat độ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 Confirmation 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ếp 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 neigbor bị lỗi nhanh hơn khi so với RSVP làm tươi tình trạng 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.



3.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 trên ví dụ việc trao đổi bản tin RSVP-TE sử dụng đối tượng tuyến tường

miinh ERO (explicit route object) để cài đặt một LSP đi qua một con đường không phải là ngắn nhất. router R1 xắc định rằng nó sẽ ấn định FEC “a.b/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 R1 để 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”a.b/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 egress router (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 LFIB của nhãn 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ầum ấ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 tin có nhãn cho FEC “a.b/16” được chuyển tiếp qua đường hầm.



Hình 3.13 : 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 FEC vì chỉ duy nhất có R1 cần biết về ánh xạ giữa FEC và đường hầm LSP.

2.1.1 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. RFE 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.

3.6 GIAO THỨC BGP

3.6.1 BGPv4 và mở rộng cho MPLS

BGPv4 (Border Gateway Protocol) là một giao thức định tuyến để gắn kết tập hợp các mạng cung cấp dịch vụ trên internet. Vì nó chỉ là giao thức sử dụng giữa các nhà cung cấp, RFC 2107 đã mở rộng BGP hỗ trợ phân phối nhãn MPLS để có thể thiết lập các LSP riêng.

BGP có một tập thuật ngữ riêng. Một khái niệm quan trọng là số AS duy nhất (Autonomous System), được định nghĩa là một tập hợp các router thực hiện một chính sách định tuyến ngoại thống nhất có thể nhận thấy đối với router của AS khác. BGP không truyền các thôgn tin topology nội giữa các AS, nó chỉ cung cấp các thông tin về các prefix địa chỉ mà có thể tìm đến hoặc đi quá giang qua đó. Sử dụng BGP giữa các router biên (border) nộ trong một AS được gọi là BGP nội (iBGP), còn sử dụng BGP giữa các router trong các AS khác nhau được gọi là BGP ngọai (eBGP).

BGP chạy trên một phiên TCP vì nó cần độ tin cậy, phân phát đúng thứ tự. Nó có 3 phase hoạt động: thiết lập phiên, trao đổi bản tin cập nhật, và chấm dứt phiên. Trong thiết lập phiên, các đối tác BGP (BGP peer) trong các AS lân cận trao đổi các bản tin OPEN có chứa AS number, một giá trị keep-alive timeout, và các tham số tùy chọn như nhận thực. các BGP peer định kì trao đổi bản tin keep alive, nếu phát hiện timeout sẽ chấm dứt phiên. Sau khi thiết lập phiên, các BGP peer trao đổi các bản tin UPDATE có chứa các prefix địa chỉ có thể đến được hiện hành (reachability), được gọi là NLRI (Network Layer Reachability Information). Sau khi trao đổi đồng bộ khởi tạo, các thay đổi định tuyến gia tăng được liên lạc bằng bản tin UPDATE.

Nội dung bản tin BGP UPDATE gồm 3 phần: các tuyến thu hồi (withdrawn route), một danh sách các prefix địa chỉ NLRI, và một danh sách tùy chọn các thuộc tính liên quan. Các BGP ngang hàng tạo quyết định chính sách cục bộ khi xem xét công bố một NLRI với các thuộc tính đường được chọn hay thu hồi thông cáo trước đó.



Chính sách thường dùng là chọn NLRI có Prefix địa chỉ đặc tả so trùng nhất, chọn một đường có số hop AS ít nhất.

Hình 3.14 : Nội dung bản tin BGP update.

Khi bản tin UPDATE chứa thông tin NLRI, một số thưộc tính đường là bắt buộc trong khi một số khác là tùy chọn. các thuộc tính đường bắt buộc là : ORIGIN, AS-PATH, và NEXT-HOP. ORIGIN nhận diện nguồn gốc của NLRI, thí dụ nó được học qua giao thức định tuyến nội hay ngoại. AS-PATH liệt kê một path-vector gồm một tập AS-PATH thường là yếu tố quyết định chọn một tuyến, nên BGP được gọi là giao thức định tuyến path-vector. Các router sử dụng AS-PATH để tránh loop bằng cách không chuyển tiếp các thông cáo tuyến có chứa số AS của chúng. NEXT-HOP nhận diện địa chỉ IP của router biên cần dùng để tìm đến NLRI. BGP có một số tham số tùy chọn có thể thực hiện một dạng cân bằng tải: LOCALPREF và MED. LOCALPREF cho phép AS đầu gửi chỉ định một sự ưu tiên (preference) định tuyến lưu lượng đi ra trên nhiều liên kết đến AS khác; trong khi MED (multiple exit discriminator) cho phép một AS phía nhận chỉ định một ưu tiên cho lưu lượng đến từ một AS khác.

RFC 2283 định nghĩa các mở rộng đa giao thức cho BGP để phân phối nhãn MPLS nằm trong một phần của NLRI. Các BGP thương lượng hỗ trợ cho khả năng tùy chọn này vào lúc thiết lập phiên. Thủ tục cơ bản là “kí sinh” việc phân phối nhãn theo kiểu không cần yêu cầu song song khi thực hiện phân phối tuyên BGP.

3.6.2 Kết nối MPLS qua nhiều nhà cung cấp dịch vụ.

BGP có thể dùng để thiết lập phân phối nhãn cho các LSP đi xuyên qua các mạng của nhiều nhà cung cấp khác nhau. Hìh 3 trên gồm 3 hệ tự trị là A,B,C. AS A cấp phát cho khách hàng Prefix địa chỉ (FEC)”a.b/16”. Router C3 quảng bá nó như một NLRI cho AS-A và AS-B bằng bản tin BGP UPDATE có chứa Next-hop và ASPATH. Bản tin update được gủi bởi C3 đến A3 còn mang một ánh xạ từ FEC “route reflector”. Nhằm



tìm cách tốt nhất để chuyền tiếp các gói đến prefix “a.b/16”, A1 có thể xác định rằng đường AS ngắn nhất là qua hop kế A3 sử dụng nhãn L. nhờ định tuyến nội và giao thức phân phối nhãn của mình, router A1 cungc biết rằng tuyến tốt nhất để đến A3 là đi qua A2 sử dụng nhãn M. Kết quả là khi chuyển gói đến prefix “a.b/16”, router A1 push nhãn L lên gói rồi push tiếp nhãn M trên đỉnh stack . như vậy, một LSP được chui bên trong một đường hầm LSP khác. LSP1 bên ngòai kéo dài từ A1 đến A3. Trong khi đó, LSP 2 kéo dài từ AS A đến AS C và có một đoạn chui bên trong LSP1.

Hình 3.15 : BGP phân phối nhãn qua nhiều Autonomous System.



Chương 4:

VẬN HÀNH VÀ BẢO DƯỠNG TRONG MPLS 4.1 GIỚI THIỆU

Chúng ta có thể sử dụng vận hành và bảo dưỡng MPLS (MPLS Operation and Maintenance – OAM) để phát hiện các lỗi vận hành, cho việc tính toán và đo đạc hiệu suất trong mạng MPLS. Các vấn đề trên mặt phẳng điều khiển có thể được báo cáo bởi các bẫy (traps) hoặc thấy được bởi sự lựa chọn (polling) cơ sở thông tin quản trị (Management Information Base – MIB). Điều này có thể đáp ứng nhu cầu cho các mạng IP, nhưng là khó khăn hơn để phát hiện các vấn đề ở trong mằt phẳng dữ liệu khi mạng chạy MPLS. OAM MPLS là một tập hợp các giao thức được dùng để phát hiện các vấn đề trong mạng MPLS một cách dễ dàng, nhanh chóng hơn và giữ lại dấu vết (keeps track) của kết quả đo đạc là quan trọng trong các mạng mà có những thỏa thuận (aggreements) ở mức dịch vụ (SLAs) với các khách hàng hoặc các công ty khác. Mục tiêu của OAM MPLS là để phát hiện, báo cáo, và vá lại vấn đề trước khi một người dùng gọi nó lên (user calls it in). 4.2 Các yêu cầu của OAM - MPLS

Các yêu cầu của OAM MPLS được liệt kê dưới đây: - Phát hiện và chẩn đoán (diagnosis) các lỗi của mặt phẳng điều khiển cũng như mặt phẳng dữ liệu. - Phát hiện lỗi trong một đường chuyển mạch nhãn (LSP). - Các gói OAM di chuyển trên cùng một tuyến như là lưu lượng dữ liệu MPLS. - Mô tả đặc điểm của tuyến (path characterization). - Đo đạc các SLA - Sự ảnh hưởng lẫn nhau của OAM. - Các MIB - Tính toán.



4.2.1 Phát hiện và chẩn đoán các lỗi của mặt phẳng dữ liệu và điều khiển

Các vấn đề thông thường trong các mạng MPLS là việc nhận các gói tại một router chuyển mạch nhãn (label switching router – LSR) với một đỉnh nhãn đặc trưng cho nơi mà LSR không có thông tin chuyển tiếp hoặc thông tin chuyển tiếp không chính xác.Vấn đề này có thể được phát hiện bởi thông tin điều khiển mà giao thức phân bố nhãn (Label Distribution Protocol-LDP), giao thức ReserVation tài nguyên (RSVP), giao thức định tuyến IP, bảng định tuyến, cơ sở thông tin nhãn (LIB), và cở sở thông tin chuyển tiếp nhãn (LFIB) cung cấp.

Tuy nhiên, vấn đề chỉ trở nên rõ ràng nếu lưu lượng thực tế là đang lưu chuyển và bị lỗi tại LSR nào đó. Tinh vi hơn và khó khăn để phát hiện là một LSR nào đó, nơi mà thông tin mặt phẳng điều khiển là chính xác nhưng thông tin mặt phẳng dữ liệu lại bị lỗi. Phần mêm mặt phẳng điều khiển có thể cho phép sửa lại cho đúng, với các vấn đề mà không được phát hiện ra bởi các câu lệnh SHOW trên router, trong khi mạt phẳng dữ liệu làm rơi (drops) hoặc ngược đãi (mistreats) các gói, nơi mà kết quả có thể trong một lỗi chuyển tiếp. 4.2.2 Sự phát hiện ra lỗi trong một tuyến chuyển mạch nhãn (LSP).

Một vấn đề thông thường là lỗi hoặc một quảng bá nhãn giữa hai LSR. Ví dụ, LDP hàng xóm ngang hàng có thể bị down giữa hai LSR, nơi gây ra cho các gói bị rớt hoặc chuyển tiếp đi không có nhãn. Nếu MPLS vận chuyển lưu lượng lớp 2 mà trở nên không có nhãn trên một router nhà cung cấp, nó sẽ bị rớt. Tương tự, nêu lưu lượng Ipv4 trở nên không có nhãn, nó có thể bị chuyển tiếp đi đến bảng định tuyến toàn cầu. Nếu không tồn tại tuyến nào cho địa chỉ IP đích, gói sẽ bị bỏ đi. Nếu một entry định tuyến tồn tại, gói được chuyển tiếp đi. Trong trường hợp này, hai vấn đề có thể xảy ra là: gói có thể được chuyển tiếp tới đúng đích, hoặc nó có thể được chuyển đi đến đích không đúng.

Một vấn đề thông thường khác có thể thấy trong các mạng MPLS là các vấn đề về MTU. Bởi vì chồng nhãn được thêm vào, kích thước của gói sẽ giảm đi n lần trong 4 bytes với n là số nhãn trong chồng nhãn. Nếu từ điều khiển xuất hiện giữa stack nhãn và



tải trọng MPLS, 4 bytes khác được thêm vào. Điều này có thể gây nên vấn đề về MTU trên một router nào đó, bởi vì chúng không hỗ trợ kích thước lớn hơn của MTU hoặc bởi vì lỗi trong cấu hình. Trong trường hợp khác, miễn là các gói nhỏ hơn được chuyển đi, sẽ không phát hiện được vấn đề xảy ra. Vấn đề chỉ được phát hiện lần đầu khi các gói lớn hơn đựơc phát đi.

Trong các mạng mà có nhiều tuyến có cost là như nhau (Equal Cost Multi Paths-ECMP), một vài vấn đề không ai để ý có thể đến một tuyến của các tuyến ECMP không được sử dụng. Tuy nhiên, ngay lập tức lưu lượng lưu chuyển ngang qua một tuyến bị lỗi. Sẽ là tốt nhất nếu phát hiện các vấn đề trước khi một khách hàng thông báo về chúng. OAM MPLS được phát triển với ý định này.

4.2.3 Các gói OAM lưu chuyển dữ liệu MPLS.

Đó là điều quan trọng vì các gói OAM di chuyển trên cùng một tuyến như là dữ liệu người dùng để phát hiện các lỗi trong mặt phẳng dữ liệu của LSR. Bởi vậy, lưu lượng OAM MPLS là lưu lượng giao thức đơn vị dữ liệu người dùng (User Datagram Protocol – UDP) và không phải là một kiểu dữ liệu mà các router có thể đối xử khác. Để lấy ví dụ, lưu lượng giao thức thông điệp điều khiển internet (Internet Control Message Protocol – ICMP) sẽ được chuyển đi theo một cách khác trên các router so với lưu lượng TCP hay UDP thông thường. Một vài phần cứng chuyển tiếp gói phụ thuộc vào kiểu của lưu lượng.

4.2.4 Path Characterization.

Lưu lượng OAM có thể chỉ ra các đặc trưng tuyến của lưu lượng MPLS. Các đặc trưng này có thể bao gồm các vấn đề sau:

- Xử lý chất lượng của dịch vụ (Quality of Service – QoS). - Xử lý thời gian sống của gói (Time To Live – TTL) - Sự âm ỷ (latency) - Hiệu ứng jitter - Trạng thái ECMP (ECMP behavior) - Đơn vị phát tối đa (Maximum transmission unit – MTU) dọc theo tuyến. - Mất mát gói.



Điều này là quan trọng khi nhìn vào sự xử lý lưu lượng dọc theo một LSP hoặc lưu lượng thuộc về một lớp chuyển tiếp tương đương (Forwarding Equivalence Class – FEC) mà bạn đo đạc các đặc tính chính xác. Để lấy ví dụ, lưu lượng tiếng nói có một sự âm ỷ nhỏ (latency) và giá trị jitter dọc theo tuyến, nhưng trái lại, thông số này là không quan trọng trong lưu lượng dữ liệu Internet. Một công cụ tuyệt vời để đăc trưng hóa tuyến dữ liệu là SLA IP, sẽ đựợc thảo luận sau đây.

4.2.5 Sự đo đạc các SLA

Nếu các SLA áp dụng cho mạng MPLS, các đặc trưng của các LSP sẽ phủ hợp (correspond) với các SLA tiền định nghiã (predefined). Ví dụ, OAM MPLS sẽ cung cấp các kĩ thuật để đo đạc các đăc trưng của các LSP. Cho các SLA, latency, jitter, round trip time (RTT), và mất gói là các đặc trưng quan trọng để đo đạc cho mỗi LSP. Bạn có thể thấy trong thông tin MIB để thu đựợc điều này, hoặc có thể tiến hành đo đạc nó bằng cách gửi đi các thăm dò vào trong các LSP. SLA IP có thể gửi đi các gói thăm dò (probes) để đo đạc hiệu suất của mạng đặc biệt hoặc gửi đi theo các khoảng thường xuyên (regular).

4.2.6 OAM Interworking

Khi bạn chuyển phát các frames lớp 2 qua đám mây MPLS (AtoM), mỗi router biên của nhà cung cấp biên (PE) có các mạch gắn thêm vào (AC). Các AC này có thể có các giao thức lớp 2 với các thông điệp OAM của chúng và các gói lỗi. OAM MPLS phải hỗ trợ việc chuyển sang hoặc ánh xạ của giao thức lớp 2, nơi sinh ra các thông điệp OAM (hoặc một tập hợp con tối thiểu của chúng) vào trong các thông điệp OAM MPLS được định nghiã mới. Trong cách ngược lại, các trạng thái lỗi đặc trưng MPLS mà áp dụng pseudowires phải được ánh xạ đến nơi sinh ra các thông điệp OAM của các giao thức AC trên các router PE.

4.2.7 Các MIB

Việc quản trị luôn luôn đóng một vai trò hết sức quan trọng trong networking. Điều này là không khác cho các mạng MPLS. Quản trị và các MIB đóng một vai trò quan trọng trong việc ghi lại dấu vết trạng thái của một mạng và cung cấp một cảch báo



sớm khi có một vài sự kiện không đúng xảy ra. Các MIB đặc trưng cho MPLS đã và đang được phát triển.

4.2.8 Việc tính toán (accounting)

Việc tính toán là quan trọng cho các công việc đo đạc mạng và các mục đích tính cước (billing purposes). Lưu lượng (netflow) mạng có thể cung cấp việc tính toán trong IOS Cisco. Netflow tạo ra cho MPLS aware để tính toán lưu lượng đã được đóng gói trên LSP và (and even finer than that) bởi vì nhiều nhãn trong stack nhãn có thể để lại dấu vết. Netflow sẽ được giải thích sau.

4.3 VẬN HÀNH VÀ BẢO DƯỠNG MPLS.

4.3.1 LSP connetivity (liên kết LSP)

Các công cụ OAM của mặt phẳng người dùng yêu cầu xắc minh rằng các LSP được kết nối chính xác, và vì vậy có năng lực để phân phối dữ liệu khách hàng đến đích theo yêu cầu, có giá trị và bảo đảm chất lượng của dịch vụ QoS (Quality of Service), đem lại trong các SLA (Service Level Agreements).

Một số các yêu cầu mà chúng phải được hỗ trợ bởi các chức năng OAM MPLS là: - Cả hai, theo yêu cầu và sự xắc minh kết nối liên tục của LSP để chắc chắn

rằng các sai sót không tồn tại trên các LSP đến đích. - Một sai sót xuất hiện trong một tầng đã cho không nên gây ra các báo động

nhiều lần (to be raised simultaneously), hoặc là gây nên các hành động thiếu chính xác không cần thiết được thực hiện trong các tầng client. Tầng client là tầng ở trên hệ thống cấp bậc nhãn (label hierarchy) sử dùng tầng hiện hành như là một tầng server.

- Khả năng để đo đạc tính sẵn sàng và sự thực hiện (hay kết quả) chất lượng dịch vụ (QoS) của một LSP.

- Các lỗi tối thiểu sau đây của mặt phẳng người dùng MPLS phải được phát hiện :

+ Mất kết nối của LSP đến một tầng server bị mất hoặc một sự mất kết nối bên trong tầng MPLS.



+ Swapped LSP trails. + Sự tái tạo lại LSP không được định trước của một lưu lượng của LSP vào

lưu lượng của một LSP khác. + Sự tái tạo lại bản thân nó không định trước (unintended self-replication)

16 giá trị của 20 bít của trường Label được dự trữ trong tiêu đề của nhãn cho các

chức năng đặc biệt, nhưng không phải tất cả đều được chỉ rõ. Một trong các chức năng này được đưa ra là nhãn cảnh báo OAM (OAM Alert Label) và được mang đến giá trị số của 14.

Hình 4.1 : gói OAM MPLS.

Có các loại tải trọng khác nhau phụ thuộc vào chức năng của OAM chứa trong các gói, nhưng vẫn có một cấu trúc chung cho các kiểu tải trọng. Từ lúc bắt đầu, một gói có một trường kiểu chức năng OAM để chỉ rõ loại chức năng nào của tải trọng . Trong mỗi một gói cũng chỉ rõ dữ liệu loại chức năng của OAM và ở cuối của mỗi gói chứa một bit (Bit Interleaved Parity – BIP16) kĩ thuật phát hiện lỗi. Số dư BIP16 được tính toán qua tất cả các trường của tải trọng OAM bao gồm cả kiểu chức năng OAM và các vị trí BIP16 mà nó được đặt trước tới giá trị zero. Tải trọng phải có độ dài tối thiểu là 44 octet bởi vì sẽ trở nên dễ dàng trong quá trình xử lý cũng như để hỗ trợ yêu cầu gói có kích thước nhỏ nhất trên các công ngệ lớp 2. Điều này đạt được bằng cách đệm các trường dữ liệu kiểu OAM chỉ định rõ với tất cả các bít là 0 khi cần thiết.

Các gói OAM được làm cho trở nên khác nhau từ lưu lượng mặt phẳng người dùng thông thường bằng việc giảm một đi trong độ sâu của chồng nhãn tại một mức LSP đã cho tại vị trí mà chúng được chèn vào [21]. Để chắc chắn rằng các gói OAM có một Per Hop Behavior (PHB), phải chắc chắn rằng xắc suất mất gói là thấp nhất, ta mã hóa trường EXP theo một cách chắc chắn. Trường EXP nên được đặt tất cả là 0 trong tiêu đề OAM Alert Labeled và dù thể nào thì xắc suất mất gói thấp nhất PHB là ở trước tiêu đề chuyển tiếp mặt phẳng người dùng thông thường cho các LSP này [21]..

Label Header Layer 2 Header OAM Payload (44 octets →)



Trường TTL nên được đặt hòan toàn là 1 trong tiêu đề OAM Alert Labeled. Một lí do cho điều này là các gói OAM đó sẽ không bao giờ di chuyển vượt xa hơn (the LSP trail termination sink point at the LSP level they were originally generate). Điều này là có thể bởi vì các tiêu đề không được xem xét bởi các LSR tráo đổi nhãn trung gian, và chỉ được quan sát tại các điểm chìm LSP (at LSP sink – points).

Vào tháng 5 năm 2002, được đề ngị 6 kiểu khác nhau của các chức năng OAM và (these have the codepoints) được chỉ ra trên hình 4.2 và xa hơn trong các giới thiệu là có sự hỗ trợ cho các LSP đa điểm đến điểm, các LSP đơn hop (single-hop) và lấy nhãn ra ở hop áp chót.

Hình 4.2 : OAM Function Type Codepoints

Ta có thể chắc chắn rằng các gói CV OAM được phát ra trên tất cả các LSP theo thứ tự để phát hiện ra tất cả các sai sót và cung cấp khả năng bảo vệ để chống lại sự rò ri lưu lượng ở cả trong và ngòai các LSP. Nó cũng được giới thiệu các gói FDI OAM được sử dụng để chặn các báo động một cách ồ ạt. Các gói BDI là một công cụ hữu ích cho việc định lượng đơn điểm cuối (single-ended) của tất cả các hướng và trong cả một số trường hợp chuyển mạch bảo vệ. Tuy nhiên, chỉ các giới thiệu (recommendations) và các nhà quản trị (điều hành mạng- operators) mới có thể chọn để sử dụng một vài hoặc tất cả các gói OAM khi họ cảm thấy đó là hợp lý.

4.3.1.1 Connectivity Verification (CV) thẩm tra tính liên kết

Chức năng xác minh tính kết nối (CV) được sử dụng để phát hiện và chẩn đoán tất cả các loại lỗi kết nối của LSP có nguồn gốc dưới đây hoặc bên trong các mạng lớp



MPLS. Dòng CV được phát ra tại các ingress LSR của LSP với một tần số quy định của một gói trên một giây và phát tới các egress LSR của LSP. Các gói CV OAM là trong suốt (transparent) đối với các transit LSR, có nghiã là các gói là không bị nhận thấy bởi các LSR này. Gói CV bao gồm đối tượng nhận dạng mạng duy nhất (network-unique identifier) Trail Termination Source Identifier – TTSI và đối tượng nhận dạng này được sử dụng để phát hiện tất cả các kiểu lỗi đã được giải thích trong chương 0. Điều này đạt được bằng việc egress LSR kiểm tra các gói CV đến trên LSP. Một LSP đi vào một trạng thái lỗi khi mà một trong các lỗi được miêu tả trong hình 4.2 .

Kiến trúc của LSP TTSI được định nghiã bằng cách sử dụng một địa chỉ 16 octet LSR ID Ipv6 theo sau bởi một ID LSP Tunel dài 4 octet. ID LSP Tunel này được xây dựng lên bởi Local LSP_ID cho các đường hầm CR-LDP hoặc ID đường hầm (Tunel ID) cho các đường hầm RSVP. Nó cũng có thể được cấu hình bằng tay. 16 bit đâu tiên (2 octets) là các bit quan trọng nhất của ID LSP Tunel được độn vào với tất cả các bit là 0 để cho phép tăng một số đặc tính trong trường ID Tunel. Để cho LSR không hỗ trợ việc đánh địa chỉ Ipv6, một địa chỉ Ipv4 có thể được sử dụng cho ID LSR sử dụng định dạng được miêu ta trong, kiến trúc việc đánh địa chỉ IP phiên bản 6 :

Hình 4.3 : Kiến trúc của tải trọng CV (CV payload)

4.3.1.2 Dấu hiệu lỗi chuyển tiếp gói tin (Forward Deflect Indication – FDI)

Dấu hiệu lỗi chuyển tiếp (FDI) được phát ra bởi một egress LSR phát hiện lỗi. Khi egress LSR phát hiện ra một lỗi, nó tạo ra một gói FDI và trace nó theo và hướng lên theo suốt một chồng LSP được đặt vào, chúng ta cũng biết rằng theo hệ thống thứ tự nhãn thì các gói FDI OAM được phát ra trên một danh nghĩa.

Mục đích ban đầu của các gói FDI là để chặn các báo động trong các mạng theo lớp ở trên của lớp xuất hiện các lỗi. Để có thể gửi các gói FDI đi lên, điều này là quan trọng rằng điểm lún LSP (the LSP sink point) ghi nhớ một vài ánh xạ nhãn LSP server-client mà trong sự tồn tại trước sự xuất hiện của lỗi. Theo cách này, khi các LSP mức cao hơn phát hiện sự mất của luồng CV nguyên nhân do các lỗi trên các LSP mức thấp

Function Type Reserved LSP TTSI Padding BIP16

1 octet 3 octets 20 octets 18 octets 2 octets



hơn, chúng ta thu được sự nhận dạng chính xác của nguồn mà thực sự có các lỗi xảy ra. Các client ở các lớp cao hơn có thể không trong cùng một vùng quản trị như là nguồn lỗi ban đầu. Nó bao gồm các trường để chỉ ra bản chất của các lỗi và vị trí của chúng.

Khi một FDI không đi qua được từ một LSP lớp server đến các LSP lớp client của chúng, thì vị trí của lỗi (Defect Location) và trường kiểu lỗi (Deflect Type field) sẽ được copy từ FDI LSP lớp server vào trong FDI LSP lớp client.

Hình 4.4 (31): FDI và kiến trúc tải trọng của BDI

Trong hình 31, trường kiểu lỗi (Defect Type field) rộng 2 bytes và giá trị của trường này có thể được liệt kê ra. Vị trí của lỗi (Defect Location) sẽ chứa nhận dạng của mạng mà tại đó lỗi được phát hiện thấy. Nhận dạng sẽ ở trong hình thái của một số của hệ tự trị (Autonomuos System – AS).

4.3.1.3 Chỉ thị lỗi ngược (Backward Deflect Indication – BDI)

Mục đích của chức năng OAM BDI là thông tin tới upstream end của một LSP một lỗi downstream. BDI được phát ra tạ một điểm nguồn giới hạn của lối trở lại (at a return path’s trail termination source point) trong sự đáp lại của một lỗi được phát hiện tại một điểm chìm giới hạn đuôi của một LSP (at a LSP trail termination sink point) trong hướng chuyển tiếp.

Để có thể gửi BDI (cũng là LB-Rsp) upstream, nó yêu cầu có một tuyến trở lại. Một tuyến trở lại có thể là: a. Một LSP dành cho sự trở lại (a dedicated return LSP). b. Một LSP trở lại chia sẻ, nói chia sẻ là ở giữa nhiều LSP chuyển tiếp. c. Một tuyến trở lại không MPLS, ví dụ như một đường ngòai dải IP. Tùy chọn này có (has potential security issues). Ví dụ đường trở lại có thể được giới hạn trên một giao diện LSR khác, và một người dùng hiểm độc tiềm năng có thể phát ra một BDI và gứi nó đến ingress LSR. Bởi vậy khả năng từ chối tấn công từ dịch vụ (DoS attack), các tiêu chuẩn về bảo mật phải được tăng thêm vào.

Function Type Reserved

1 octet 1 octet

LSP TTSI

20 octets 2 octets

Defect Type Padding BIP16

14 octets 2 octets

Defect Location 4 octets



Gói BDI được gửi một cách tuần hoàn bởi một gói trên giây trở lại theo (LSP trail termination sink point) mức ngang hàng của nó trong hướng ngược lại và xa hơn là đi lên qua một vài (nested LSP stack). BDI được gửi như một hình ảnh trung thực (phản ảnh – mirror) của FDI thích hợp (dành riêng – appropriate). Appropriate FDI là FDI được phát ra trên lớp thấp nhất nơi mà lỗi được phát hiện. Vị trí của lỗi (Defect Location) và các trường kiểu lỗi (Defect Type fields) là một ánh xạ trực tiếp của những kết quả này từ FDI appropriate và có các định dạng đồng nhất như được mô tả trước cho gói OAM FDI.

Hình 4.5 minh họa 2 điều mà kết nối LSP quan tâm. Hai vùng màu xám trong phần A0 mô tả cách mà các gói OAM CV được phân bổ từ ingress đến egress trên các LSP khác nhau và độ sâu của chồng nhãn. A) miêu tả làm thế nào các gói CV được gửi đi bằng cách sử dụng mức độ sâu 1 và 2 trong hệ thống thứ bậc nhãn (label hierachy). B) miêu tả điều gì xảy ra khi mà một lỗi được phát hiện ra, nói mà LSR phát hiện ra lỗi và nó thông báo như thế nào đến các LSR về các lỗi được phát hiện. Các LSR là họ hàng (belongings to) với các LSP khác và sử dụng một hệ thống thứ bậc nhãn (label hiararchy) để hướng từ ingress đến egress LSR.

Hình 4.5 :



Giả định tên của 3 LSP trong hình 4.5 là A, B, C. Ta có trong LSP A giữa LSR4 và LSR5 được chêm nhãn mức độ 1 (stack depth of one). LSP B từ LSR2 qua LSR3 và qua LSP A đến LSR6 chêm nhãn mức 2, và cuối cùng LSP C từ LSR1 qua LSP B qua LSR7 đến LSR8 chêm nhãn mức 3.

Xem xét một lỗi được phát hiện giữa LSR2 và LSR3. Điều này sẽ có các hệ quả (tầm quan trọng - consequences) cho cả LSP B và LSP C. Cả LSR6 và LSR8 sẽ phát hiện ra rằng một lỗi đã xuất hiện khi lỗi thực sự là tại LSP B. Để ngăn cản các báo động cho LSP C tại LSR8, LSR6 thông báo cho router này bằng cách gửi các gói FDI theo cùng một đường như là LSP C sẽ sử dụng trước khi lỗi xuất hiện. Nó không chỉ cần thiết (to inform the downstream egress LSRs, LSR6 have to inform LSR2), các ingress LSR của LSP B, nơi mà trong sự quay về của nó sẽ cung cấp tin tức cho LSR1 về lỗi tốt như việc sử dụng các gói BDI. Cách mà các gói BDI được gửi đi, ví dụ như tìm kiếm một tuyến về thay đổi, sẽ được thảo luận ở dưới. 4.3.2 Defect type codepoint

Mã của kiểu lỗi (Defect type code) được mã hóa trong 2 octets. Octet đầu tiên chỉ ra lớp và octet thứ 2 chỉ ra bản chất của lỗi (nature of the defect). Để có thể phát hiện được các lỗi này chúng ta cần một thiết bị trạng thái sãn sàng trên LSP (LSP availability state machine – ASM) trên cả các ingress LSR và egress LSR của LSP. Tại ingress LSR (do we have the LSP Trail Far – End Defect State and for the egress LSR the LSP Trail Sink Near-End Defect State).[21].



Defect Type (DT)

DT code (Hex)

Description

dServer 01 01 Any server layer defect arising below the MPLS layer network

dLOCV 02 01 Simple Loss of Connectivity Verification.

dTTSI_Mismatch 02 02 Trail Termination Source Identifier Mismatch

defect.

dTTSI_Mismerge 02 03 Trail Termination Source Identifier Mismerge

defect.

dExcess

02 04 Increased rate of CV OAM packets with the expected TTSI above the nominal rate of one per second.

dUnknown 02 FF Unknown defect detected in the MPLS layer. None 00 00 Reserved None FF FF Reserved

Hình 4.6 : các codepoint của kiểu lỗi trong các gói OAM FDI./BDI [21a]

Trong hình 33 có 4 lỗi trên mặt phẳng người dùng MPLS: dLOCV, dTTSI_Mismatch, dTTSI_Mismerge and dExcess. Khi một trong số các lỗi này xuất hiện, thì ASM đi vào trong LSP Trail Sink Near-End Defect State nơi mà trong sự quay trở lại của nó, khi các gói BDI đi đến được ingress LSR, nó sẽ làm cho ingress LSR đi vào Trail Far-End Defect State. 2 kiểu lỗi khác phân phối (deals) với các lỗi từ bên ngoài của lớp MPLS và không nhận biết được các lỗi. Mội hành động mà được cầu khẩn sử dụng khi quá trình đi vào LSP Trail Sink Near-End Defect State bị ngừng lại khi LSP Sink Near- End Defect State được thoát ra .

Mô tả ý nghiã của một số loại lỗi: - dServer : một vài lỗi xuất hiện ở lớp server bên dưới mạng của lớp MPLS là

một lỗi dServer. Chức năng này chỉ ra rằng chỉ có một lỗi trên các lớp bên dưới MPLS, nhưng không có thông tin gì về loại của lỗi được tìm thấy. Lỗi



này không được phát ra bởi các kĩ thuật OAM MPLS, nó là đầu ra cho OAM MPLS từ lớp server.

- dLOCV : sự mất mát đơn (Simple Loss) của lỗi xắc minh kết nối xuất hiện khi không có các gói OAM CV được mong đợi với đối tượng xem xét TTSI được mong đợi (expected TTSI observed) trong một vài chu kĩ của 3 giây liên tiếp nhau (period of three consecutive seconds). Nếu nguyên nhân của dLOCV là tại lớp server và cũng có một tín hiệu FDI đến từ lớp server, sau đó codepoint DT cho dServer được sử dụng. Codepoint của dLOCV chỉ được sử dụng khi các lỗi kết nối đơn giản lớp MPLS xuất hiện trong các LSP của bản thân nó.

- dTTSI_Mismatch : lỗi Trail Termination Source Identifier Mismatch xuất hiện khi có một vài gói OAM được xem xét trong một vài chu kĩ của 3 giây liên tiếp (period of three consecutive seconds) với một TTSI không được mong đợi và không có gói OAM CV (observed 0 với một TTSI được mong chờ trong cũng một chu kì. Các lỗi này làm mất cấu hình kết nối. Điều kiện của lỗi này mang đến quyền được ưu tiên cả trên lỗi dLOCV và điều kiện dTTSI-Mismerge trong những trường hợp khi mà chúng cũng xuất hiện.

Điều này xuất hiện khi mà các LSP A và B trao đổi nhãn, nó thay thế cho quá trình của A1->A2 và B1->B2, chúgn ta chuyển A1->B2 và B1->A2. (Đó là thay vì A1->A2 và B1->B2, chúng ta có A1->B2 và B1->A2). Trong trường hợp này chúng ta lấy một TTSI không được mong đợi tại sink point LSP và không có TTSI được mong đợi tại sink point.

- dTTSI_Mismerge : lỗi Trail Termination Source Identifier Mismerge xuất hiện khi có một vài các gói OAM CV với một TTSI không được mong đợi và không có một gói OAM CV nào mà có một TTSI được mong đợi xem xét (an expected TTSI observed) trong một vài chu kì của 3 giây liên tiếp. Các lỗi này bao gồm cả lỗi nhánh (misbranching) và thay thế các lỗi không dự tính trước. Theo Neil Harrison từ British Telecom lỗi mất nhánh là sự thay thế không dự tính trước của một vệt đuôi (of a trail) và trường hợp nơi một vệt đuôi đơn (single trail) có thể không dự tính trước lỗi nhánh trở lại trên bản thân nó (ví dụ như bị vòng lặp – looping).



Các lỗi thay thế không dự tính trước xuất hiện khi nói LSP B (gets unintentionlly replicated, or let say duplicated, into say LSP A). trong cách này cả LSP A và B sẽ vận chuyển lưu lượng trên LSP B. Misbranching được hiểu như là LSP B bị mất tuyến và trộn vào trong LSP A và không bao giờ đến được sink point trên LSP B. Neil Harrison nói rằng các lỗi mất trộn (mismerge) này xuất hiện trong 2 trường hợp

+ Khi LSP B không bao giờ đi đến tại B2, nhưng đến một cách không dự tính trước tại A2. Điều này có thể được minh họa bởi A1+B1->A2, và 0->B2. Ở đây A2 sẽ lấy cả TTSI được mong đợi cho LSP A và một TTSI không được mong đợi cho LSP B tại sink point của LSP A. Trong các giới hạn của các lỗi, LSP A chỉ ra một lỗi mất trộn và ở đây LSP B chỉ ra một lỗi dLOCV từ B2 không bao giờ lấy một vài TTSI (never gets some TTSIs).

+ Khi LSP B vẫn đến tại B2, nhưng đến A2 một cách không dự tính trước được. Điều này có thể được hiểu như là A1+B1->A2, và B1->B2. Ở đây A2 sẽ lấy cả một TTSI được mong đợi cho LSP A và lấy một TTSI không được mong đợi cho LSP B tại sink point của LSP A. Điều này là tương tự như kịch bản được nêu ra ở trên, Trong các giới hạn của các lỗi, LSP A chỉ ra một lỗi mismerge nhưng LSP B không chỉ ra lỗi.

- dExcess : một lỗi dExcess xuất hiện khi có một sự tăng về tốc độ, 5 gói hoặc nhiều hơn của các gói OAM CV với TTSI được mong đợi bên trong một chu kì của 3 giây liên tiếp. Điều này có thể mang lại một ví dụ cho cho bản thân lỗi mismerging, một nguồn LSR có lỗi, tấn công từ chối dịch vụ (DoS attack).

- dUnknown: không nhận biết được lỗi phát hiện trong lớp MPLS. Điều này được mong đợi để sử dụng cho các lỗi trên nút MPLS mà được phát hiện bên trong node (hầu như chắc chắn bởi người chủ) và tác động đến lưu lượng mặt phẳng người dùng. Chú ý rằng lỗi này không được phát hiện bởi các OAM MPLS, xa hơn nó là một đầu ra đến OAM MPLS.



4.3.3 Tuỳ chọn cảnh báo router và nhãn cảnh báo router.

4.3.3.1 Tùy chọn cảnh báo router

Các gói IP có thể có một tùy chọn cảnh báo router được thêm vào header IP. Tùy chọn này là một tùy chọn IP cho phép router có thể kiểm tra gói xa hơn khi quá trình chuyển tiếp gói, dù là gói không có địa chỉ trực tiếp đến router. Router không nên chỉ chuyển gói bằng cách kiểm duyệt qua IP, nhưng router sẽ kiểm tra kỹ hơn trước khi chuyển nó đi. Sự kiểm tra này không được định nghĩa, và phụ thuộc vào sự bổ sung phần mềm trong router. Tùy chọn cảnh báo router là một tùy chọn IP như là các tùy chọn Timestanp, Loose Source Route, và Strict Source Route. Mỗi tùy chọn IP được mã hóa như là một giá trị trường kiểu (Type Length Value – TLV). Nhìn vào hình 4.7 để thấy định nghiã kiểu của một tùy chọn IP.

Hình 4.7 : định nghiã kiểu tùy chọn IP

Hình 4.8 chỉ ra tùy chọn IP với các giá trị cho tùy chọn cảnh báo router IP.



Tùy chọn cảnh báo router làm việc chỉ khi gói là một gói IP. Nếu gói được đóng nhãn và như là toàn bộ được chuyển đi bởi LFIB trên LSR, LSR sẽ không biết rằng gói có trình diện tùy chọn cảnh báo router. Tất nhiên, bạn có thể lập trình cho LSR để thi hành kiểm tra gói sâu (deep packet inspection) và luôn luôn nhìn vào thông tin tiêu đề IP của các gói đã được đóng nhãn để chỉ ra dù không biết tùy chọn cảnh báo router được trình bày. Tuy nhiên, điều này có thể dẫn đầu tới một hiệu suất chuyển tiếp đông đặc ngiêm trọng (a serious forwarding performance impact) trên LSR, vì vậy nó không phải là giải pháp tốt nhất. Nó có thể không khả thi để thực hiện việc này trong các phương tiện phần cứng chuyển tiếp gói, hoặc nó có thể là quá đắt. Một giải pháp tốt hơn để sử dụng một nhãn MPLS đặc biệt như đỉnh nhãn trong stack nhãn của các gói mà các LSR cần để ngiên cứu. Nhãn đặc biệt này là một nhãn MPLS, được gọi là nhãn cảnh báo Router.

4.3.3.2 Nhãn cảnh báo router.

Nhãn cảnh báo router có một giá trị của 1 (has a value of 1), và nó có thể xuất iện tại một nơi nào đó trong stack nhãn trừ tại vị trí bottom. Khi một LSR nhận một gói với nhãn l như là đỉnh nhãn, nó biết rằng nó phải thực thi xa hơn gói. Bởi vậy, LSR tháo gỡ nhãn l và thực thi gói. LSR sau đó nhìn vào đỉnh nhãn mới trong stack nhãn và thực hiện một quyết định chuyển tiếp gói bằng việc nhìn vào nhãn đó trong LFIB. Quyết định chuyển tiếp gói này làm cho LSR thực hiện một cuộc tráo đổi, lấy ra hoặc điều hành thêm vào trên stack nhãn và trởi lại giao diện ra và hop kế tiếp cho gói. Trước khi chuyển mạch gói ra ngòai khỏi LSR, LSR đặt nhãn l trở lại như là đỉnh nhãn trong stack nhãn và chuyển các gói đi. Vì vậy, có nhãn cảnh báo router như là đỉnh nhãn không ảnh hưởng đến quyết định chuyển tiếp gói được tạo nên trên gói; nó chỉ ra một cách duy nhất rằng LSR phải kiểm tra gói. Trên các router chạy hệ điều hành của Cisco, các gói có nhãn cảnh báo router được chuyển đi trong phần mềm, điều đó có nghiã là các máy chuyển tiếp phần cứng là đi đường vòng (bypassed). Sự sử dụng của nhãn cảnh báo router cho các gói đã được đóng gói là tương tự như sự sử dụng của tùy chọn cảnh báo router cho các gói IP.

Bởi vì nhãn cảnh báo router bắt buộc (forces) LSR đối xử với một gói đã được đóng nhãn trong một cách khác hơn là khi gói đã được đóng nhãn không có nhãn cảnh báo router như là đỉnh nhãn khi chuyển tiếp gói tin, sự sử dụng của nó không có tác



dụng trực tiếp cho OAM MPLS. Nhớ rằng một trong các yêu cầu là cho lưu lượng dữ liệu người dùng MPLS và lưu lượng OAM MPLS được chuyên đi trong cùng một đường . Điều này rõ ràng không là trường hợp cho lưu lượng của đỉnh nhãn là nhãn l đặc biệt. Vì vậy, nhãn cảnh báo router không đước sử dụng để gửi đi các gói OAM MPLS khi kiểm tra một LSP. Nó có thể, tuy nhiên, được sử dụng cho lưu lượng OAM trở lại. Bởi vì một LSP là không theo một hướng duy nhất (unidirectional), lưu lượng OAM MPLS kiểm tra LSP trong chỉ một hướng duy nhất. Điều này có nghiã là lưu lượng trở lại không kiểm tra cái gì cả; nó chỉ cần được quay trở về nguồn. Lưu lượng trở lại có thể được gửi đi với tùy chọn cảnh báo router vì vậy nó đi đường vòng (bypasses) qua các máy móc phần cứng chuyển tiếp và có một cơ hộ lớn hơn của việc trở lại đến nguồn (chance of getting back to the source). Nếu lưu lượng trở lại được đóng nhãn, nó cũng có nhãn cảnh báo router, vì vậy các máy phần cứng chuyển tiếp gói là đi theo đường vòng.

Các gói chuyển tiếp được đóng nhãn (Forwarding Labeled Packets), bạn đã nhìn thấy một nhãn đặc trưng MPLS được gọi là nhãn cảnh báo vận hành và bảo dưỡng (Operation and Maintenance Alert Label) mà có một giá trị của 14 (has a value of 14). Bạn chèn thêm nhãn cảnh báo OAM vào stack nhãn bên dưới nhãn của LSP dưới sự kiểm tra. Hệ điều hành của Cisco không sử dụng nhãn MPLS đặc biệt này ở bất cứ đâu cả. Có điều này là bởi vì sự giới thiệu của một nhãn đặc biệt trong stack nhãn có thể ảnh hưởng tới sự đối xử đối với gói khi nó đang được chuyển đi. Một ví dụ đó là trường hợp của các gói được đóng nhãn load balancing, nơi mà trao đổi trong stack nhãn có thể giới thiệu một cách đối xử chuyển tiếp khác.

Cũng giống như vậy, lưu lượng dữ liệu người dùng thực sự và lưu lượng OAM

có thể được chuyển tiếp đi trong cùng một tuyến, trả lại kiểm tra OAM trừ khi trong một vài trường hợp. Một ví dụ thứ hai là sự sử dụng của lấy nhãn ra ở Hop áp chót (penultimate) (PHP) trong một mạng MPLS trên IP rõ ràng. Trong trường hợp này, gói đến trên egress LSR với hòan tòan nhãn cảnh báo OAM trong stack nhãn nơi nếu không thì nó sẽ nhận không có một stack nhãn. Không cái nào của các kĩ thuật OAM đã thảo luận trong chương này và được sử dụng bởi Cisco IOS sử dụng nhãn cảnh báo OAM.



4.3.4 Ping LSP MPLS. Ping LSP MPLS là tên gọi cho một yêu cầu echo MPLS và đáp trả echo MPLS. Ping là một công cụ giải quyết sự cố tốt đã được biết đến cho các mạng IP. Nó giống như sử dụng SONAR trên tàu ngầm. Ping sử dụng ICMP, được thiết kế để tăng lên (augument) giao thức IP bởi vì nó có thể báo hiệu các điều kiện lỗi (không đến được đích…) và gửi thông tin quảng bá (redirect, address mask…). Ping sử dụng ICMP để mang thông điệp yêu cầu và các gói đáp trả. Gói yêu cầu echo được gửi thẳng đến đích, nơi mà sẽ gửi lại đáp trả với một gói echo đáp trả. Nguồn nhận echo đáp trả chỉ ra rằng 2 host có thể nhìn thấy mỗi host còn lại trên mức mạng (lớp 3).

Bởi vì MPLS không thể làm việc mà không có Ip trên mức mạng, bạn có thể vẫn sử dụng Ping IP khi mạng đang chạy MPLS. Các gói Ping được gán nhãn và chuyển nhãn thông qua mạng. Tại sao lại phải tạo ra Ping LSP MPLS? Ping IP là không đủ hiệu lực cho việc thẩm tra sự chính xác của LSP MPLS. Mặc dù nó có thể thẩm tra một trong hai kết nối có hiện diện trên mức IP, nó không thẩm tra cả hai LSP đã bị gãy. Nếu bạn có một mạng MPLS trên nền IP rõ ràng (plain) và LDP bị gãy giữa hai LSR, Ping chỉ ra rằng không có vấn đề gì như là echo yêu cầu tạo nên cho chúng đến đích và echo trả lời làm nó trở lại nguồn. Giữa 2 LSR nơi mà phiên LDP bị gãy, các gói lúc này không còn được dán nhãn. Ping chỉ ra một cách giả dối rằng mọi thứ đều tốt, khi trong sự tin tưởng LSP là bị gãy.

Hình 4.9 : LSP bị gãy trong mạng AtoM



Để thấy rằng điều này có thể hướng dẫn để sử dụng việc xử lý sự cố, thử tưởng tượng rằng bạn đang chuyển một vài một lưu lượng vài phương tiện trên MPLS (AtoM) qua LSP này (imagine that you are switching Any Transport over MPLS (AtoM) traffic across that LSP), và 2 LSR với phiên LDP bị gãy (vỡ - broken) là các router P trong một mạng AtoM. Hình 4.9 đưa ra một mạng.

Nếu LSP bị gãy, lưu lượng AtoM trở nên không có nhãn giữa các LSR P2 và P3. Bởi vì 2 LSR đó không biết rằng làm thế nào để chuyển các frames này đi, khi chúng đã bì rớt. Một Ping từ PE router đến PE khác qua LSP sẽ thành công, nhưng lưu lượng AtoM sẽ bị lỗi. Để có một giao thức tương tự như giao thức Ping IP chỉ ra các vấn đề đặc trưng với các LSP MPLS, Ping LSP MPLS được phát minh.

Các LSP có thể làm vỡ (break) bởi một vài lí do, trong khi kết nối IP lưu lại trạng thái bình thường. Sau đây là một vài lý do một LSP có thể bị gãy:

- Phiên LDP bị down. - MPLS không cho phép trên một LSR (hoặc một giao diện). - LFIB có một entry không đúng cho LSP này (nhãn vào/ra sai hoặc sai thông

tin đến trạm kế tiếp). - Phần mềm và phần cứng LFIB có sự không thống nhất (discrepancy).

Trong những trường hợp như trên, các gói mất nhãn, các nhãn khác có là do chuyển mạch nhãn, nhưng không đúng cách. Đó là lý do tại sao bạn cần một kĩ thuật để kiểm tra đầu cuối LSP và mang đến một vài sự trợ giúp phản hồi khi LSP bị gãy. Khi bạn đang giải quyết vấn đề của LSP, ta cần biết nơi LSP bị gãy và lỗi đó là gì. Ping LSP MPLS phát hiện các vấn đề trong mặt phẳng chuyển tiếp, nhưng nó cũng kiểm tra mặt phẳng điều khiển ngược lại thông tin trong mặt phẳng dữ liệu.

4.3.4.1 . Các chi tiết giao thức Ping LSP.

Ping LSP tương tự như Ping IP trong đó nó cũng sử dụng một echo yêu cầu và echo đáp trả. Ping LSP MPLS có định dạng gói khác hoàn toàn và có nhiều thông tin giải quyết vấn đề hơn các gói trở lại. Một echo yêu cầu MPLS được gửi đi bởi nơi gửi và kiểm tra một FEC riêng biệt. Echo yêu cầu giữ stack FEC chỉ thị, cái mà FEC đang



được kiểm tra .Stack FEC có thể giữ một hoặc nhiều hơn các nhãn mà nơi nhận được dùng để xắc minh. Nơi nhận sau đó sẽ xắc minh rằng stack FEC trên echo yêu cầu là chính xác cho FEC. Cũng theo cách này, thông tin mặt phẳng dữ liệu cho FEC được xác minh với thông tin mặt phẳng điều khiển.

Một echo yêu cầu MPLS là một gói UDP với một cổng đích của 3503 và một cổng nguồn được chọn bởi nơi gửi. Nó có một tùy chọn cảnh báo router. Để ngăn cản gói từ một vài chuyển mạch xa hơn như là một gói IP nêu LSP bị gãy nhưng tuyến IP vẫn tốt, TTL IP của gói được đặt lên 1 và địa chỉ IP đích của gói là từ khoảng 127.0.0.0/8. Khoảng địa chỉ 127.0.0.0/8 là cho địa chỉ IP cục bộ cho host; bởi vậy, các gói mà có một địa chỉ IP đích từ khoảng này sẽ không bao giờ thấy trên wires mạng. Một LSR không bao giờ chuyển tiếp toàn bộ gói IP nếu LSP bị gãy, và không một cái nào làm egress LSR của LSP. Egress LSR gửi gói đến module phần mềm UDP đang chạy trên router nge ngóng UDP ở cổng 3503. Địa chỉ IP nguồn là một sự lựa chọn hợp lý địa chỉ IP của nơi gửi. Hình 4.10 chỉ ra định dạng của một echo MPLS yêu cầu:

Hình 4.10 : Định dạng gói echo MPLS

Chỉ có một phiên bản duy nhất. Trường Global Flags hiện hành chỉ có một bít được định nghiã. LSB là cờ V (Validate FEC stack). Nếu cờ V được đặt, nơi gửi muốn nơi nhận phê chuẩn (validate) stack FEC. Message Type là 1 cho một echo MPLS yêu



cầu hoặc là 2 cho một echo MPLS đáp trả. Mode Reply chỉ ra có bao nhiêu echo MPLS đáp trả sẽ được trở lại. Có 4 khả năng tồn tại, nha ta có thể nhìn thấy trên bảng 4.1 .

Bảng 4.1 : mode reply

Mode Reply 1 được sử dụng chỉ nếu các đáp trả echo không cần quay trởi lại. Nó có thể được ai đó định lượng đích bằng ý nghiã của một thiết bị phần mềm để thấy được nếu các yêu cầu echo MPLS tạo ra nó, vì vậy sự trở lại của các đáp trả echo là không cần thiết. Đáp trả mode 2 là mode đáp trả không thay đổi (regular reply mode).

Reply Mode 3 là tương tự như Reply Mode 2, nhưng các gói echo đáp trả được trở lại với tùy chọn cảnh báo router. Như đã giải thích trong các phần trước, bạn có thể sử dụng điều này để chắc chắn rằng gói có sự đồng ý cao nhất một cách chắc chắn để trở lại, trong trường hợp của vấn đề chuyển tiếp dọc theo tuyến trở lại. Reply Mode 4 là một mode đáp trả nằm ngòai band. Chú ý rằng Ping LSP MPLS kiểm tra một LSP. Bởi vì các LSP là theo một phương duy nhất, chỉ các yêu cầu echo là kiểm tra LSP MPLS. Các gói echo đáp trả không kiểm tra một cái gì nữa; chúng được yêu cầu đơn giản để lấy thông tin trở lại nơi gửi. Cũng như vậy, mạng không cần trở lại các gói đáp trả echo dọc theo cùng một tuyến trong hướng ngược lại. Mạng có thể gửi trở lại chúng như các gói IP.

Một handle hoặc sos chỉ định ai gửi chúng. Sequence Number nhận dang các yêu cầu echo đến sau và các đáp trả echo được gửi bởi cùng một LSR. Timestamp được đưa ra (compose) của 2 trường: một trong vài giây và một trong khoảng vài micro giây. Timestamp Sent chỉ định thời gian của ngày mà nơi gửi gửi các yêu cầu echo, và Timestamp Received chỉ ra thời gian của ngày mà nơi nhận nhận được yêu cầu echo. Để Timestamp là có hiệu lực sử dụng, bạn cần đồng bộ hóa đồng hồ của nơi gửi và nơi nhận. Các trường cuối cùng vận chuyển các TLV.



Ta có thể thấy các giá trị có thể của mã trở lại trong bảng 4.2. RSC quy cho (refer) đến các mã con (subcode) trở lại. Mã con trở lại chỉ ra độ sâu của nhãn cho trở lại thích hợp. Độ sâu của nhãn là 1 cho đáy của nhãn và là 2 cho nhãn ở trên và…and so on.

Bảng 4.2 : các mã trở lại

Nơi gửi luôn luôn đặt mã trở lại là 0. Nơi nhận có thể đặt mã trở lại như là phản hồi đến nơi gửi của yêu cầu echo. Nếu nơi nhận quả thực là egress LSR thích hợp cho FEC dưới sự kiểm tra, nó sẽ trở lại gói đáp trả echo với một mã trở lại của 3. Đó là mã trở lại bạn sẽ nhìn thấy nếu Ping MPLS làm việc tốt. Một bộ nhận sẽ biết nếu nó là egress LSR thích hợp (proper) bằng cách so sánh thông tin trong stack FEC của yêu cầu echo với thông tin thực tế trên LSR. Code trở lại 8 có nghiã là gói có một stack nhãn chỉ ra rằng một sụ điều hành lấy nhãn ra hay tráo đổi nhãn được thực hiện và nó là tốt cho chuyển tiếp đi một gói đã được đóng nhãn. Một mã trở lại của 9 chỉ ra một sự điều hành nhãn, nhưng đó là các gói đã được đóng nhãn không được chuyển mạch ra ngòai. Một mã trỏ lại của 4 có nghiã là nhãn trong stack là không biết LSR (a return code of 4 means that the label in the stack is unknown to the LSR). Một mã trở lại của 5 có nghiã là đối tượng ánh xạ downstream được cung cấp bởi LSR upstream không phải là cái mà LSR downstream mong đợi.

Chú ý rằng Ping LSP MPLS được chỉ rõ trong RFC 4379, “phát hiện lỗi mặt phẳng dữ liệu của chuyển mạch nhãn đa giao thức” (detecting Multi-Protocol Label



Switched Data Plane Failures). Các giá trị mã trở lại của 6 và 7 có một ý nghiã khác trong các phiên bản trước đó của phác thảo được được đề xuất bởi RFC. Mã trở lại 6 có nghiã “router đáp trả là một trong các router downstream, và ánh xạ của nó cho FEC này trên giao diện nhận là do nhãn mang lại”. Mã trở lại 7 có nghiã “router đáp trả là một trong các router downstream nhưng ánh xạ của nó cho FEC này không được mang lại bởi nhãn.”

Cuối cùng, gói echo MPLS có các TLV. Bảng 4.3 liệt kê các TLV khác nhau có thể được mang bởi các gói echo MPLS.

Bảng 4.3 : các TLV

4.3.4.2. Điều hành Ping LSP.

Yêu cầu echo MPLS cho một Ping MPLS giữ các thông tin sau đây: - Tiêu đề Echo MPLS - Target FEC Stack TLV - A PAD TLV (optional)

Đáp trả echo giữ các thông tin sau đây: - Tiêu đề Echo MPLS - Một Error Code TLV (optional) - A PAD TLV (optional) - Target FEC Stack TLV từ yêu cầu echo (optional)

Yêu cầu echo MPLS cho một Ping MPLS bị ép buộc vào trong FEC tại nơi gửi. LSR không thực hiện việc này qua một quá trình tìm kiếm địa chỉ IP đơn giản trong



bảng CEF. Địa chỉ IP đích là từ khoảng địa chỉ 127.0.0.0/8 (anyway), vì vậy (this is not even possible). Đích đến của gói được chuyển phát từ địa chỉ IP mà câu lệnh người dùng hoặc một thiết bị phần mềm cung cấp. Điều này xem xét nơi stack nhãn được đẩy lên gói. Gói được chuyển ra ngòai của LSR theo thông tin này. Tại một mức tối thiểu, TTL của đỉnh nhãn được đăt tới 255. khi nơi nhận nhận yêu cầu echo MPLS, nó phải thực hiện các tác vụ sau đây:

- Kiểm tra các lỗi định dạng trên yêu cầu echo. - Chú ý giao diện mà gói nhận được. - Chú ý stack nhãn của gói như lối vào của LSR. - Kiểm tra (whether) stack nhãn trên gói là cùng như một (check whether the

label stack on the packet is the same as the one in the Target FEC Stack TLV - Kiểm tra LSR egress LSR quả thực cho FEC này. - Kiểm tra (whether) giao thức phân bố FEC được chỉ định với giao diện đến. - Gửi một đáp trả echo , trừ khi Reply Mode là 1.

Nếu Reply Mode là Reply thông qua một gói UDP Ipv4/Ipv6 với cảnh báo router, tùy chọn cảnh báo router phải được xuất hiện. Điều này có nghiã là nếu đáp trả echo được đóng nhãn, gói có nhãn cảnh báo router như là đỉnh của nhãn. Địa chỉ IP đích của gói đáp trả echo là địa chỉ IP nguồn của gói yêu cầu echo. TTL IP được đặt tới 255, và các cổng UDP là 3503.

4.3.4.3 . Ping MPLS trong IOS Cisco

Trong IOS Cisco, bạn có thể gửi một Ping LSP MPLS với lệnh “Ping mpls”, Có thể thấy rằng có 3 tùy chọn tồn tại: Ipv4, traffic – eng, và pseudowire. Tùy chọn pseudowire là cho thẩm tra kết nối mạch ảo (Virtual Circuit Connection Verification – VCCV), sẽ được giải thích sau. Tùy chọn Ipv4 là cho việc gửi đi một yêu cầu echo cho một LSP mà được giới hạn với một tiền tố Ipv4 (that is bound to an Ipv4 prefix). FEC được lựa chọn bởi việc chỉ rõ tiền tố Ipv4 (mạng và mặt nạ mạng). Cũng như vậy, tương ứng với stack nhãn cho tiền tố Ipv4 này là đặt trên yêu cầu echo. Địa chỉ IP đích của yêu cầu là mặc định bởi 127.0.0.1. Vì vậy, router sử dụng địa chỉ FEC mục tiêu (Target FEC Address) bạn gõ trong vào hình dáng mà stach nhãn đặt lên trên gói và trên LSP nào mà để chuyển gói đi; nó không được sử dụng như là địa chỉ IP đích thật sự trong tiêu đề IP.



4.3.5 Dấu vết tuyến LSP MPLS

Mục tiêu của traceroute là để kiểm tra tuyến, nhưng trái lại mục tiêu của ping là để kiểm tra kết nối. Mục tiêu của traceroute LSP MPLS là kiểm tra tuyến của LSP và xắc minh mặt phẳng điều khiển và mặt phẳng dữ liệu trên mọi LDR dọc theo tuyến của LSP.

Một traceroute LSP MPLS không là gì nhiều hơn một yêu cầu echo MPLS. Sự khác nhau với Ping LSP MPLS là traceroute LSP MPLS gửi một vài gói yêu cầu echo MPLS với sự giảm dần TTL MPLS. Đầu tiên sự điều tra traceroute LSP MPLS có TTL MPLS là 1 và cho mọi điều tra sau đó, TTL giảm đi 1. Một TLV bổ sung là bao gồm với yêu cầu echo cho traceroute LSP MPLS là TLV ánh xạ Downtream. Nếu một LSR nhận yêu cầu echo MPLS với TTL 1, nó đáp trả tới nó (? It replies to it). Nếu LSR không là egress LSR cho FEC và mọi kiểm tra đều tốt, các đáp trả LSR như là một trong các router downstream. Bởi vậy, nó đáp trả với một mã trở lại của 8 và thông tin TLV downstream thích hợp (MTU, Address Type, Downstream IP Address, Downstream Interface Address, Multipath Information, Downstream Label, và Protocol) lấp đầy trong đó. Nếu LSR là egress LSR cho FEC, nó không cần lấp đầy thông tin ánh xạ Downstream nhưng sẽ đáp trả với một mã trở lại của 3.

Yêu cầu echo MPLS cho một Traceroute MPLS giữ các thông tin sau: - Tiêu đề echo MPLS - Target FEC Stack TLV - Downstream Mapping TLV - A PAD TLV (optional)

Đáp trả echo sẽ giữ các thông tin sau: - Tiêu đề echo MPLS - An Error Code TLV (optional) - A PAD TLV (optional) - Downstream Mapping TLV



Nơi gửi của các gói Traceroute LSP MPLS copy TLV ánh xạ Downstream (Downstream Mapping TLV) nhận được vào trong yêu cầu echo tiếp theo để gửi đi. Như vậy, tại mỗi hop, các nhãn được hi vọng đã báo cáo bởi LSR một hop upstream được kiểm tra với nhãn trên gói nhận được trên LSR downstream.

4.3.6 VCCV

VCCV được chỉ định để kiểm tra và xắc minh mặt phẳng dữ liệu của pseudowires. VCCV đòi hỏi các thủ tục để tạo nên một kênh điều khiển giữa các router PE mà cung cấp dịch vụ AtoM. Lớp mạng có thể thực tế là MPLS, L2TPv3, hoặc là IP. Bởi vì sách này bao phủ chỉ MPLS, nó chỉ (deals) sau đó với MPLS như là lớp mạng khi nhìn vào VCCV. Nếu MPLS là lớp mạng, VCCV sử dụng lại Ping LSP MPLS để thẩm tra kết nối của các pseudowire. VCCV tạo ra một kênh điều khiển giữa các router PE nhờ đó các gói VCCV được gửi đi qua như các gói IP. Bạn có thể sử dụng 3 lọai kênh điều khiển sau:

- VCCV Inband - VCCV Out – of – band - TTL expiry VCCV

Phương thức đầu tiên sử dụng VCCV Inband. Các gói trên VCCV Inband mang một từ điều khiển. Dữ liệu AtoM có thể mang một từ điều khiển giữa stack nhãn và tải trọng MPLS. Nibble đầu tiên của từ điều khiển này là (then) 0000. Để cho các gói trên kênh điều khiển, tuy nhiên, nibble đầu tiên của từ điều khiển là 0001. Từ điều khiển sau đó đóng vai trò như đối tượng nhận dạng tải trọng (hoặc giao thức trường ID). Đối tượng giao thức là 0x21 cho các gói Ipv4 hoặc 0x57 cho các gói Ipv6. Tuy nhiên, sự có mặt của từ điều khiển là không bị áp đặt, vì vậy tùy chọn này là không phải luôn luôn khả dĩ (sẵn dùng – possible).

Phương thức thứ 2 sử dụng VCCV Out – of – band. VCCV out – of – band không dựa trên xự xuất hiện của từ điều khiển nhưng xa hơn trên sự xuất hiện một cách ngay lập tức của nhãn cảnh báo router trên nhãn VC. Vấn đề với sự gần đến này là những sự bổ sung đó xắc định quyết định load balancing dựa trên một nhãn tại một vài độ sâu trong stack nhãn có thể sửa đổi quyết định này bởi vì sự xuất hiện của nhãn với



giá trị bằng 1. Nếu lưu lượng dữ liệu AtoM và lưu lượng OAM AtoM – lưu lượng VCCV – lấy một tuyến khác, sự kiểm tra là không thật sự có hiệu lực .

Phương pháp thứ 3 và phương pháp cuối cùng sử dụng sự hết hạn của TTL (TTL expiry). Về bản chất, giá trị TTL của nhãn VC được đặt đến 1 vì vậy TTL của gói được gán nhãn hết hạn tại egress PE router, và LSR sẽ kiểm tra gói bởi vì chuyển tiếp xa hơn. Tuy nhiên, TTL của nhãn VC có thể được viết đề lên khi nhãn đường hầm được gỡ ra. Bởi vậy, phương pháp thứ 3 là không thích hợp. Phương pháp thứ nhất là số một mà IOS Cisco sử dụng.

Chú ý: IOS Cisco không ghi đè lên giá trị TTL của 1 trong nhãn VC khi nhãn

đường hầm được lấy ra tại LSR hop áp chót.

VCCV sử dụng tiêu đề gói Ping LSP MPLS và các TLV. Target FEC Stack TLV được sử dụngl nó chỉ ra một Pseudowire. FEC 128 Pseudowire (new) được sử dụng cho VCCV trong IOS Cisco.

Khả năng để hỗ trợ một kênh điều khiển và kiểu của kênh này là báo hiệu giữa (tín hiệu – signaled) các router PE. Điều này được thực hiện bởi một thông số VCCV TLV (VCCV parameter TLV) trong một TLV giao điện VC FEC cho LDP. LDP là giao thức báo hiệu giữa các router PE cho AtoM. VCCV parameter TLV giữ một kiểu kênh điều khiển (CC) và một kiểu xắc minh điều khiển (control verification – CV). CC chỉ ra một vài lọai sau đây:

- Một từ điều khiển với nibble đầu tiên là 0001 và một đối tượng nhận dạng tải trọng.

- Nhãn cảnh báo router MPLS. - Một nhãn VC với TTl được đặt lên 1.

Kiểu CV chỉ ra một số điều sau đây: - Ping ICMP - Ping LSP - Bảo vệ chuyển tiếp gói hai hướng (bidirectional Forwarding Detection) - VCCV sử dụng Ping ICMP khi giao thức mạng là IP hoặc L2TPv3.VCCV sử

dụng Ping LSP khi giao thức mạng là MPLS, như nó là cho AtoM. Cuối cùng,



VCCV có thể sử dụng hai hướng giữa hai nền (platform) – để xắc minh phiên giữa hai router PE. BFD có thể được sử dụng cho một vài của ba giao thức mạng (any of the three network protocols)

IOS Cisco sử dụng phương thức đầu tiên khi gửi đi các gói VCCV AtoM, gói đầu tiên (the one with) với từ điều khiển với nibble đầu tiên là 0001 và một đơn vị nhận dạng tải trọng.

4.3.7 IP Service Level Agreement

Cisco IP Service Level Agreement (IPSLA) là một công cụ đo đạc hiểu suất mạng mà được nhúng trong IOS Cisco. IP SLA cho phép người điều hành mạng định lượng hiệu suất mạng một cách thông thạo và có thể nhìn thấy được nếu các SLA được tham gia vào. Các đặc tính mạng mà bạn có thể đo đạc bao gồm hiệu ứng jitter, trên trên một tuyến, RTT, và sự mất mát các gói. Những sự đo đạc này có thể được hoàn thành trên lớp của dịch vụ (class – of – service). IP SLA đo đạc mạng bằng cách gửi đi những thăm dò một cách tuần hòan. Các thăm dò có thể là các gói giao thức khác nhau, ví dụ như ICMP, UDP, HTTP, Domain Name System (DNS), FTP, DHCP, và nhiều hơn nữa. Sự đo đạc hiệu ứng jitter và RTT có thể là quan trọng đặc biệt nếu mạng có lưu lượng Voice – over – IP (VoIP), bởi vì loại lưu lượng này yêu cầu một giá trị jitter nhỏ. Bạn cũng có thể sử dụng IP SLA như là một công cụ gỡ rối, bởi vì nó có thể thu thập thông tin đo đạc từ mạng trong thời gian thực trên toàn bộ mạng. Cũng như vậy, người quản trị mạng có thể xắc định vấn đề với tốc độ tốt hơn khi không có IP SLA được xuất hiện.

IP SLA yêu cầu một nguồn IP SLA và một thiết bị đích để làm việc. Thiết bị nguồn luôn luôn là một router Cisco, nhưng thiết bị đích không cần là một router nó có thể là một host IP. Tuy nhiên, bạn có thể thu thập hầu hết thông tin hữu ích nêu thiết bị đích là một router Cisco mà đóng vai trò như một đáp ứng SLA IP. IP SLA được bật trên 2 router biên khách hàng (customer edge – CE): newyork CE và sydney CE. Hai kiểu của các IP SLA được điểu khiển (monitor) bằng cách cấu hình hai loại điểu tra rtr1 và rtr2. Router newyork CE là router nguồn, và sydney CE là router đích. Rtr1 và rtr2 được cấu hình trên router newyork CE. Rtr1 là một lưu lượng ICMP đơn giản, vì vậy router đích không cần phải là một bộ đáp ứng (responder). Tuy nhiên, rtr2 đo đạc jitter với các gói UDP. Để cho điều này, router đích phải là một bộ đáp ứng (responder).



* VRF – Aware IP SLA.

IP SLA tạo ra VRF aware. Điều này có nghiã là nó có thể chạy bên trong một VRF trên các router PE. Bởi vậy, bạn có thể sử dụng IP SLA để đo đạc hiệu suất của mạng bên trong VPN từ các router PE. IP SLA có thể, cho ví dụ, đo đạc RTT giữa các router PE bên trong VRF khách hàng. Từ router PE, các gói điều tra IP SLA được chuyển tiếp đi sử dụng bảng định tuyến VRF. (equally), IP SLA có thể chạy trên các router đa VRF CE (multi – VRF CE). Để tạo ra IP SLA chạy trên VPN MPLS, bạn phải đặt điều tra rtr vào trong VRF chính xác. Nhìn vào hình 4.11 để thấy một mạng bên trong cái mà nguồn IP SLA đặt lên router PE. Bạn có thể đặt IP SLA trong các trường hợp (ví dụ - instance) đa VRF và đo đạc hiệu suất mạng thẳng đến các router CE từ xa hoặc các router PE nêu bạn đặt đáp ứng IP SLA trong VRF thích hợp (appropriate).

Hình 4.11 : IP SLA cho VPN MPLS

Cho sự chính xác của các đo đạc, nó là thích hợp rằng bạn sử dụng các router được dành cho IP SLA. Các router này thường được đưa ra để đóng vai trò như các router vô hình (as shadow routers). Bởi vì các router này được dành cho IP SLA, chúng không được bao gồm trong chuyển tiếp gói và có thể tiêu tốn tất cả quá trình xử lý của CPU của chúng trên IP SLA. Nếu các router shadow được gắn vào trong các router PE như là các router CE và bạn có một router shadow trên điểm của sự xuất hiện (POP), bạn có thể đo đạc hiệu suất của mạng backbone VPN MPLS từ mọi POP đển mọi POP



khác. Nếu các router này được gắn vào các router PE như là các router multi – VRF CE, chúng có thể thực sự thực hiện các đo đạc CE – to – CE qua mạng VPN MPLS cho một vài các VPN. Sau đó nó đáp ứng nhu cầu để có một router shadow trên POP trong mạng. Nhìn vào hình 4.12 cho một mạng VPN MPLS với các router CE IP SLA shadow đo đạc hiệu suất của POP đến POP.

Hình 4.12: Các router CE IP SLA vô hình (shadow)

4.3.8 Net flow Accounting. Netflow cung cấp một ý nghiã để tính toán trong các mạng IP, nơi mà có thể sử dụng cho việc quản trị mạng, lập kế hoạch và tính cước. Dữ liệu thu thập được là một tập hợp của các thống kê về lưu lượng, như là giao thức, cổng, thông tin về chất lượng của dịch vụ (QoS). Bạn có thể lấy thông tin mà bạn thu thập được vào trong lưu lượng mạng đến một bộ collector Netfow để phần tích và tiến hành các quá trình khác. Một lưu lượng (dòng – flow) là theo một hướng duy nhất và được định nghiã như là một tập hợp của địa chỉ IP nguồn, địa chỉ IP đích, cổng nguồn, cồng đích, giao thức, byte ToS, và giao diện lối vào. Netfow cung cấp việc tính toán trong các mạng IP, nhưng nó cũng có thể cung cấp việc tính toán trong các mạng MPLS. Nhìn vào hình 4.13 cho một cái nhìn về nơi mà Netfow có thể điều hành các mạng MPLS.



Hình 4.13 : Netflow trong các mạng MPLS.

Netflow cũng có thể theo dõi (track) các dòng IP – to – label trên ingress LSR. Nó không có ý ngĩa quan trọng (matter) dù là giao diện cuộc gọi đến (incoming) là một IP tòan cầu thường lệ hay là một giao diện VRF. Tại egress LSR, Netflow có thể cung cấp việc tính toán egress Netflow cho các gói mà đi vào LSR như là các gói đã được gán nhãn và đi ra LSR như là các gói IP; đó là tuyến nhãn đến IP (label – to – IP). Nó được gọi là Netflow egress bởi vì các gói được sắp đặt của stack nhãn trên đường ra ngòai của router của chúng. Giao diện egress trên LSR có thể là giao diện IP tòan cầu thường lệ hoặc là giao diện VRF. Bởi vậy, bạn có thể tìm thấy Netflow egress trên các router PE egress trong các mạng VPN MPLS. Cuối cùng, Netflow có thể thực hiện việc tính toán trong tuyến nhãn tới nhãn (label – to – label). Trong các từ khác, nó có thể thực hiện việc tính toán cho các gói đã được gán nhãn trên router P trong các mạng MPLS. Dữ liệu có thể được xuất trong định dạng xuất phiên bản 9 của Netflow. Trong việc bổ sung cho dữ liệu thông dụng mà bạn có thể thu thập, bạn có thể (track up) đến 3 nhãn MPLS trong stack nhãn. Các thông tin theo dõi được là giá trị của các nhãn, giá trị các bit experimental, ứng dụng MPLS (VPN MPLS, AtoM, TE MPLS, and so on) này được kết hợp với đỉnh nhãn, và tiền tố mà được kết hợp với đỉnh của nhãn. Nó là quan trọng mà tải trọng MPLS không có (không phải là IP). Netflow MPLS – aware có thể theo dõi các gói đã được đóng nhãn mà mang tải trọng không phải IP, ví dụ như các gói AtoM.

Để cho phép việc tính toán Netflow trên một router, bạn phải cấu hình câu lệnh “ip route-cache flow” trên giao diện ra. Bạn có thể nhìn thấy các thống kê Netflow trên router với câu lệnh “show ip cache [verbose] flow”. Trên ingress LSR của một mạng



MPLS, bạn có thể cấu hình “ip route-cache flow” trên giao diện ingress, ngay cả nếu nó là một giao diện VRF.

Để cấu hình việc tính tóan egress Netflow, bạn phải cấu hình câu lệnh giao diện “mpls netflow egress” trên giao diện egress của egress LSR.

Để cấu hình Netflow MPLS – aware, cấu hình câu lệnh global “ip flow-cache mpls label-positions [label-position-1 [label-position-2 [label-postion-3]]] [mpls-length] [no-ip-fields]”. Bạn có thể chỉ rõ vị trí của nhãn như là là đang lên đến nhãn thứ 6 trong stack nhãn. Một yêu cầu tiên quyết cho đặc tính này là để cho phép Netflow trên giao diện với dòng lệnh “ip route-cache flow [input]”. Để thấy một ảnh chụp nhanh của cache Netflow MPLS-aware trên router, bạn phải sử dụng lệnh “show ip cache verbose flow”.

4.3.9 SNMP/MIBs

SNMP là một giao thức mà cung cấp giao tiếp giữa một nhà quản trị SNMP (thông thường là vậy) và tác nhân SNMP trong các mạng IP. Tác nhân SNMP là một phương tiện phần mềm mà chạy trên một thiết bị được quản trị. SNMP cung cấp một framework được chuẩn hóa cho việc quản trị các thiết bị trong mạng. Một phần của framework là các MIB và kiến trúc của thông tin quản trị (Structure of Management Information – SMI). SMI cung cấp các kĩ thuật để định ngĩa MIB. Sự phong phú của các MIB là sẵn dùng, và những cái mới vẫn luôn luôn đang được định nghiã. Hầu hết các giao thức có sở hữu các MIB của chúng. Tuy nhiên, các MIB khác không được ràng buộc cho một giao thức nào đó, nhưng xa hơn để một công cụ phần mềm nào đó trên tác nhân SNMP. Bạn có thể truy cập các MIB SNMP bằng cách sử dụng một lệnh đơn giản trên môt trạm quản trị (management station) hoặc bởi một bộ phận phức tạp của phần mềm với một giao diện người dùng đồ họa đang chạy trên trạm quản trị đang quản lên đến hàng ngàn các thiết bị trong mạng. MIB quả thật được bao gồm của một tập hợp các đối tượng mà tham khảo (refer) cho một thực thể được quản trị trên thiết bị. Giá trị của các đối tượng có thể được đọc bởi một lệnh GET hoặc GETNEXT được phát ra từ trạm quản trị. Trong một vài trường hợp, bạn có thể đặt đối tượng được quản trị với một lệnh SET từ trạm quản trị. Nhìn vào hình 4.14 cho một cái nhìn tổng quan về giao thức SNMP.



Hình 4.14 : Tổng quan về giao thức SNMP

SNMP có thể quản trị các node trong mạng trong hai kiểu: một kiểu polling và một kiểu điều khiển ngắt (interrupt-driven). Trong kiểu (polling), một trạm quản trị lựa chọn một cách tuần hòan hoặc chất vấn các thiết bị trong mạng. Một vấn đề là tần số của việc bầu chọn các thiết bị khi định lượng trạng thái cảu các thiết bị mạng – ví dụ như các router. Nếu một sự kiện không rõ ràng xuất hiện, ví dụ như một giao diện bị down, nó có thể lấy một giao diện khác trong khi trước khi trạm bầu chú ý tới sự kiện xuất hiện Bởi vậy, kiểu thứ hai (second fashion) là điểu khiển ngăt. Ngay khi một sự kiện xuất hiện trên thiết bị được điều khiển, SNMP gửi đi một bẫy đến trạm quản trị báo cho nó biết về sự thay đổi.

Một MIB là một tập hợp của các đối tượng được quản trị, mỗi một đối tượng với một tên (giá trị), trạng thái, truy cập, và cú pháp. Nhiều MIB là sắn dùng, môt vài trong số đó được định nghiã bởi các body chuẩn và một vài thuộc quyển sở hữu (propietary) hoặc được nâng cao với các thông tin quyền sở hữu. Dưới đây chỉ liệt kê chỉ các MIB mà có liên quan tới MPLS và chúng được hỗ trợ trong IOS Cisco. Sau đây là các MIB mà phù hợp với điều này:

- MPLS – LDP – MIB - MPLS – TE – MIB - MPLS – VPN – MIB



- CISCO – IETF – PW – MIB - CISCO – IETF – PW – MPLS – MIB - CISCO – IETF – PW – TC – MIB

Nó nên là rành mạch mà hầu hết các MIB trình bày bởi nhìn vào tên của chúng. MPLS – LDP – MIB là MIB mà có các đối tượng liên quan tới LDP. Nó giữ các đối tượng mà liên quan tới ID router LDP, thông tin ngang hàng LDP, và các phiên. MPLS – LSR – MIB giữ các đối tượng mà liên quan tới các bộ đếm, LFIB, các nhãn chuẩn bị tới và chuẩn bị đi ra ngoài, and so on. Nói ngắn gọn, MPLS – LSR – MIB có thể mang đến cùng một thông tin như đã nhìn thấy với câu lệnh “show mpls forwarding-table”. MPLS – TE – MIB là MIB mà giữ các đối tượng liên quan tới TE. MPLS – VPN – MIB là MIB mà chia với các đối tượng VRF – specific.

PW trong một vài MIB (stand for) pseudowrie; các MIB đó liên quan tới AtoM nếu được đặt dưới giao thức mạng là MPLS. IF – MIB là tên của MIB giao diện. Nó đã được nâng cao trong IOS Cisco để hỗ trợ lớp MPLS. Như ví dụ, các thống kê có thể thực hiện việc bầu cho lưu lượng nhãn mà đang được chuyển qua router. Ta có thể kiểm tra trạng thái điều hành của MPLS trên một giao diện và MTU MPLS của một giao diện bằng cách sử dụng MIB này.

Một vài MIB mà liên quan tới việc định tuyến là không thực sự liên quan tới MPLS một cách trực tiếp. Tuy nhiên, không có định tuyến, MPLS là không khả thi; bởi vậy, khi nói về việc quản lý các mạng MPLS, là cần thiết để quản lý việc định tuyến IP. Đó là lý do tại sao nêu bạn đang chạy OSPF trong mạng của bạn, bạn sẽ thấy thú vị với OSPF – MIB. Nếu bạn đang chạy VPN MPLS, các MPLS BGP4 – MIB và CISCO – BGP4 – MIB sẽ là hấp dẫn. Khi bạn đang chạy MPLS TE, RSVP – MIB sẽ làm bạn hài lòng.

Bây giờ là thời điểm tốt để nhìn vào môt ví dụ từ MIB MPLS – TE. Một đối tượng giữ lại các sự chuyển đổi trạng thái của đường hầm TE. Tên đối tượng là mpls Tunel State Transitions, và nhận dạng đối tượng (Object Identifier – OID) là 1.3.6.1.3.95.2.2.1.26. OID này định nghĩa duy nhất đối tượng. Nó định nghiã tổ chức nào ấn định MIB, phân loại MIB, và chỉ ra đối tượng nào là từ MIB đó. OID là một danh sách của các số nguyên, đọc từ trái qua phải, nó chỉ ra một cách duy nhất đối tượng được quản trị. Hình 4.15 chỉ ra cây OID của đối tượng mpls Tunel State Transitons.



Hình 4.15 : OID của MPLS Tunel State Transitions

Tất cả các OID của tất cả các MIB có thể được trình bày trong toàn bộ cây OID. Trong ví dụ này, 1.3.6.1.3.95.2.2.1.26 biên dịch tới iso (1).org (3).dod (6).internet(1).experimental(3).mplsTeMIB (95).mpls TeObjects(2);mplsTunelTable(2); mplsTunelEntry (1); mplsTunelStateTransitions(26).

4.3.9.1 Context – Based Access for SNMP over MPLS VPN

Hơn nữa, SNMP truy cập đến các thiết bị một cách toàn cầu, có nghiã là SNMP truy cập cho tòan bộ thiết bị. Tuy nhiên, với sự giới thiệu của VPN MPLS, bạn thấy khái niệm của các VPN và các VRF trên các router PE. VPN cung cấp một bảng định tuyến VRF, bảng VRF CEF, và các giao diện VRF trên các router PE. VRF không phải là một phần của phạm vi tòan cầu của router PE, nhưng xa hơn phạm vi VRF. Vấn đề là khi lưu lượng SNMP đi vào trong router PE thông qua các giao diện VRF hoặc khi các bẫy rời router PE thông qua các giao diện VRF. Các trạm quản trị bên trong các VPN khách hàng có thể truy cập phạm vi quản trị toàn bộ của router PE, ngay cả nếu SNMP yêu cầu vào trong router PE thông qua một giao diện VRF. Các trạm quản trị khách hàng trong



VPN sẽ không cho phép thấy được toàn bộ router PE hoặc phạm vi toàn bộ (toàn cầu) của router thông qua các giao thức quản trị. Để cho phép khách hàng VPN truy cập chỉ dữ liệu MIB mà có liên quan (pertain) tới VRF của khách hàng này, nhà cung cấp dịch vụ có thể cấu hình một phạm vi SNMP cho VRF này. Bởi thế (consequently), khách hàng chỉ có thể truy cập dữ liệu SNMP trong phạm vi đó và không thể truy cập dữ liệu MIB từ các khách hàng VPN khác trên cùng một router PE. Từ khóa phạm vi dưới sự cấu hình IP VRF được sử dụng để kết hợp đọc viết hoặc thông báo cái nhìn SNMP (notify SNMP view) vào trong một phạm vi SNMP. Bạn cũng có thể ngăn cản truy cập tới một số cây MIB nào đó. Điều đó là quan trọng để chú ý rằng cho sự truy cập dựa trên phạm vi (context – based access) cho SNMP trên VPN MPLS để làm việc cho một MIB nào đó, MIB này cần tạo ra (context – aware). 4.3.9.2 Các MIB VPN MPLS. MIB này được sử dụng một cách đặc biệt để thiết lập hoặc lấy các đối tượng liên quan tới VPN MPLS là MIB VPN MPLS. MIB VPN MPLS có các đối tượng liên quan tới các VRF trên router PE. Tòan bộ các đối tượng liên quan tới VRF, các giao diện VRF, bảng định tuyến VRF, và thông tin BGP. Để ví dụ, đối tượng “ mplsVpnVrfRouteTable” với OID 1.3.6.1.3.118.1.4.1 cho phép trạm quản lý mạng từ nhà cung cấp dịch vụ để lấy các bảng định tuyến VRF từ các router PE. Thông tin này bao gồm tiền tố, metric tuyến, thông tin hop kế tiếp, giao thức, và một số khác từ các bảng định tuyến VRF. Ví dụ khác là miêu tả của VRF trên router PE. Nếu bạn cấu hình một mô tả cho các VRF trên các router PE, bạn có thể lấy lại nó với đối tượng “mplsVpnVrfDescription”. Đối tượng này được định nghiã trong ví dụ 4.1

Ví dụ 4.1: đối tượng mplsVpnVrfDescription 4.3.10 Syslog Syslog là một phương thức để gửi đi các thông điệp từ router đến host mà đang chạy một deamon syslog. Tuy nhiên, bạn cũng có thể lưu trữ các thông điệp syslog cục



bộ trên router. Nếu bạn gửi đi các thông điệp syslog đến một host thu thập các thông điệp từ tất cả các thiết bị trong mạng, bạn thấy một khung cảnh toàn bộ và bạn có thể lưu trữ các thông điệp một cách bảo mật và quản lý chúng tốt hơn. Bạn có thể nhìn vào và thao tác file syslog vì vậy nó cung cấp sự quản lý và gỡ rối tốt hơn. Các thông điệp syslog có một số thứ tự giữa 0 và 7, trình diễn sự ngiêm ngặt (severity) của thông điệp. Bạn có thể sử dụng số thứ tự này để giới hạn số thông điệp gửi đến server syslog tùy theo mức độ quan trọng của thông điệp. Bảng 4.4 mang đến một cái nhìn tổng quan của các mức độ ngiêm ngặt của các thông điệp syslog.

Bảng 4.4 : Logging Priorities.

Mức ưu tiên cao nhất là mức 0, và mức thấp nhất là mức 7. Nếu bạn chỉ định rõ

mức độ của ngiêm ngặt (severity), các thông điệp với số chỉ mức độ ngiêm ngặt này và các mức thấp hơn được gửi đến server syslog hoặc lưu trữ một cách cục bộ. Nếu, ví dụ, bạn chỉ rõ mức độ 3 cho các thông điệp được gửi đi đến server syslog, tất cả các thông điệp mà có mức độ ngiêm ngặt 3,2,1,0 được gửi đi. Định dạng của thông điệp syslog như sau:

* Ánh xạ thông điệp OAM (OAM Message Mapping)

Ánh xạ thông điệp OAM là quan trọng trong trường hợp của AtoM. Trong các mạng AtoM, pseudowires hoặc các VC vận chuyển các frame lớp 2 qua đám mây



MPLS. Hướng về các đám mây lớp 2 tự nhiên (toward the native Layer 2 clouds) trên mỗi mạng MPLS là các AC với sự đóng gói lớp 2 riêng biệt. Một khía cạnh quan trọng khi quản trị dịch vụ này là việc ánh xạ của các thông điệp OAM của các AC lên trên các thông điệp OAM pseudowire được định nghiã mới nhất trên các pseudowire và (vice versa). Các chỉ thị cảnh báo đặc trưng có thể được chuyển vận giữa các router PE, chỉ ra trạng thái của các pseudowire và các AC. Mỗi giao thức lớp 2 trên AC có thể có tập hợp các cảnh báo và thông điệp báo lỗi. Ví dụ, ATM có nhiều các chỉ thị quản lý lỗi hơn Frame Relay. Mỗi một thông điệp tự nhiên – như đã được định nghiã bằng giao thức lớp 2 – sẽ được ánh xạ lên trên các thông điệp OAM pseudowire được định nghiã mới nhất. Các thông điệp OAM pseudowire này được chuyển vận qua các pseudowire giữa các router PE và có thể chỉ ra trạng thái của các AC hoặc các pseudowire. Ánh xạ này là cần thiết để cung cấp một dịch vụ cạnh tranh (emulate) của các giao thức lớp 2 tự nhiên đầu cuối qua mạng MPLS. Ánh xạ này là quan trọng khi các mạch lớp 2 tự nhiên được hoàn thành (giới hạn – terminate) trên các router PE. Khi các mạch lớp 2 là không được hoàn thành trên các router PE – ví dụ, Frame Relay tỏng mode port trên MPLS – các thông điệp OAM tự nhiên được chuyển vận qua các pseudowire một cách trong suốt (transparently). Trong trường hợp này, nó là không cần thiết để ánh xạ các thông điệp tại các router PE.

Router PE có thể nhận được các cảnh báo từ các AC chỉ thị các vấn đề hoặc trạng thái của mạch hoặc liên kết có thể đơn giản là bị down. Router cần phải chuyển vận trạng thái này qua pseudowire. Pseudowire co thể bị down hoặc bị lỗi vì một số lí do khác nhau. Router sau đó phải biên dịch trạng thái này trong các thông điệp OAM mà được gửi lên trên các AC. Router PE có thể phát hiện một cách trực tiếp một vấn đề với pseudowire nếu giao diện nằm bên dưới bị down hoặc nếu nhãn VC có một vấn đề. Tuy nhiên, nó có thể cũng phát hiện qua một giao thức khác nào đó, ví dụ như Ping LSP. Mục tiêu là đảm bảo được việc định lượng kiểm tra đầu cuối của mạng. Lấy ví dụ, nếu một router PE phát hiện rằng PVC Frame Relay cục bộ là không hoạt động, nó có thể ánh xạ vào một thông điệp trạng thái pseudowire, cái mà được gửi đến router PE từ xa. Router PE từ xa sau đó sẽ thông dịch thông điệp trạng thái pseudowire này vào các cảnh báo Frame Relay tương ứng mà được gửi ra ngòai lên trên đến egress PVC Frame Relay.



ATM sử dụng các cell OAM sau đây: - Các cell Loopback - Các cell kiểm tra sự liên tục (continuity check – CC) - Các cell tín hiệu chỉ thị cảnh báo (Alarm Indication Signal – AIS) - Các cell chỉ thị phát hiện từ xa (Remote Detection Indication – RDI)

Các cel AIS được gửi (downstream) của lỗi, và các cell RDI được gửi upstream. Các router PE phải nhìn vào các cảnh báo đó và ánh xạ chúng vào các thông điệp trạng thái pseudowire và (vice versa). Trong IOS Cisco các router PE có thể đáp ứng tới các cell OAM cuối cùng (the PE router cann respond to End OAM cells) nếu “oam-ac emulation-enable” được bật lên; trường hợp ngược lại, chúng được gửi đi một cách tron suốt qua pseudowire. Các router PE có thể đáp ứng để (to the segment OAM cells if the OAM segment Endpoint feature is configured) . Câu lệnh cấu hình cần thiết cho điều này là “oam-ac segment endpoint”.

4.3.11 Chuyển mạch bảo vệ (protection switching)

Chuyển mạch bảo vệ là một thuật ngữ mà ITU-T đang sử dụng. Họ công nhận rằng chức năng chuyển mạch bảo vệ là quan trọng để nâng cao hiệu lực và tính tin cậy của các mạng MPLS. Chuyển mạch bảo vệ ngụ ý (imply) rằng cả định tuyến và tài nguyên được tính toán và ấn định (allcate) để bắt đầu bảo vệ LSP trước các lỗi xuất hiện. Chuyển mạch bảo vệ vì vậy đưa ra một sự đảm bảo mạnh mẽ của (of being able to re-obtain the required network resources post-failure). Tại thời điểm xuất hiện chức năng cho chuyển mạch bảo vệ là giới hạn cho các đường hầm LSP điểm đến điểm (point to point) và có hai loại kiến trúc được đề xuất đó là: kiểu 1+1 và kiểu 1:1. Các chức năng khác và kiểu kiến trúc khác là cho việc ngiên cứu sau này. Kiểu kiến trúc 1+1 sử dụng một LSP bảo vệ được giành cho cho mỗi LSP đang làm việc. Tại ingress LSP của vùng được bảo vệ, LSP làm việc được nối lên LSP bảo vệ. Lưu lượng trên các LSP làm việc và các LSP bảo vệ được phát cùng một lúc đến egress LSR của vùng được bảo vệ. Khi lưu lượng đến egress LSR của vùng được bảo vệ việc lựa chọn giữa LSP làm việc và LSP bảo vệ là dựa trên một vài tiêu chuẩn được xắc định trước, ví dụ như dấu hiệu của lỗi cụ thể nào đó.



Trong kiểu kiến trúc 1:1, một LSP bảo vệ được cho mỗi một LSP làm việc. Lưu lượng làm việc được phát đến mỗi LSP hoặc là LSP làm việc hoặc là LSP bảo vệ. Phương thức cho sự lựa chọn giữa các LSP bảo vệ và LSP làm việc phụ thuộc vào kĩ thuật và được thực hiện bởi ingress LSR của vùng được bảo vệ. LSP bảo vệ có thể được sử dụng để mang lưu lượng mở rộng khi nó không được sử dụng để truyền phát lưu lượng làm việc.

Chuyển mạch bảo vệ sẽ được xây dựng khi:

- Được khởi tạo bởi người quản trị điều khiển. - Lỗi tín hiệu được trình bày (declared) trên LSP kết nối, LSP làm việc hoặc

LSP bảo vệ và không được thể hiện trên các LSP khác. Lỗi này có thể được phát hiện bằng cách sử dụng các gói CV.

- Thời gian đợi để phục hồi hết hiệu lực và lỗi tín hiệu không được thể hiện trên LSP làm việc.

Hai kiến loại kiến trúc bảo vệ được giải thích ở trên là chuyển mạch bảo vệ LSP nơi một chuyển mạch từ thực thể làm việc đến thực thể bảo vệ phải được thực hiện khi một lỗi được phát hiện và tín hiệu hoá. Cũng có một đề nghị khác từ một kế hoạch bảo vệ chuyển mạch của ITU-T. Đó là một kế hoạch bảo vệ tuyến 1+1 mức gói, được đề xuất bởi Lucent Technologies. Nó cung cấp một sự khôi phục một cách tức thời từ các lỗi mà không có sự mất gói in-transit trên LSP bị lỗi. Các lỗi được gộp vào bao gồm một vài các lỗi đơn trong lớp vật lý, lớp liên kết và lớp MPLS.

Để cung cấp dịch vụ bảo vệ 1+1 mức gói giữa hai edge LSR mạng MPLS, đó là ingress LSR và egress LSR, một cặp của LSP MPLS được thành lập dọc theo các đường tháo rời ra. Các gói được cung cấp 2 lần tại ingress node vào trong 2 LSP và đính kèm thêm số thứ tự hàng đợi vào nó. Khi gói đến ingress node, một trong hai bản copy được lựa chọn. Trong cách này sẽ không có sự mất mát các gói in-transit trên LSP bị lỗi.

Sự phân biệt giữa bảo vệ 1+1 mức gói và 2 kế hoạch bảo vệ chuyển mạch truyền thống được đưa ra bởi ITU-T là không cần thiết cho sự phát hiện lỗi một cách tường minh, báo hiệu và chuyển mạch bảo vệ giữa 2 LSP và kế hoạch coi mỗi LSP như là các LSP làm việc.



4.3.12 Định tuyến lại nhanh (Fast rerouting)

Trong thứ tự để thấy được sự cần thiết của các ứng dụng thời gian thực như là hội ngị video và các dịch vụ khác, IETF Network Working Group đã tìm kiếm (finds it highly desirable) để cho phép gửi lại lưu lượng người dùng vào trong các đường hầm LSP dự phòng trong khoảng chục mili giây. Trong chương nhỏ này chúng ra đang viết về các LSP định tuyến tường minh. Các LSP dự phải được đặt càng gần điểm lỗi càng tốt, khi báo cáo lỗi giữa các node có thể phải trả giá đáng kể về trễ. Có một đoạn dự phòng cho mỗi liên kết và chúng được tính toán và phân bố trước khi xảy ra lỗi. Khi một lỗi xuất hiện trên một liên kết hoặc một node thì lưu lượng trên liên kết sẽ nhanh chóng chuyển qua đoạn dự phòng và cùng một thời điểm ingress LSR sẽ được thông báo. Nó sẽ tính toán một tuyến thay đổi cho LSP thứ cấp. Lưu lượng sẽ ngay lập tức được chuyển vào đường LSP mới để thay thế cho lưu lượng trên đoạn dự phòng. Ta sử dụng thuật ngữ sửa chữa cục bộ khi đưa đến các công ngệ thực hiện điều này, và đưa đến LSP rằng kết hợp đường hầm dự phòng như là một LSP được bảo vệ. Nó hỗ trợ cho cho kiểu điểm đến điểm theo một phương duy nhất (unidirection), nhưng điểm đến đa điểm và đa điểm đến điểm là cho các mục đích ngiên cứu cho CR-LDP.

Có 2 cách cài đặt các đường hầm dự phòng. Đó là one-to-one backup và facility backup cho RSVP-TE [35] và cho CR-LDP [7] độc quyền (exclusive) và chia sẻ bảo vệ băng thông tương ứng (shared bandwidth protection respectively). Lưu lượng sẽ được chuyển vào đoạn dự phòng khi lỗi xuất hiện tại LSP được bảo vệ và sẽ được chuyển trở lại về LSP được bảo vệ khi mà tuyến đã được sửa chữa.

Chiến lược đầu tiên điều hành trên cơ sở của LSP dự phòng cho mỗi LSP được bảo vệ. Một tuyến chuyển mạch nhãn được thiết lập cắt ngang đường hầm đầu tiên một vài nơi downstream của điểm của liên kết hoặc lỗi node. Cho rằng mỗi LSP được được sao lưu, tuyến LSP dự phòng được thành lập. Cho ý nghĩa thứ hai của các LSP dự phòng, một LSP đơn được tạo ra để cung cấp cho tuyến dự phòng một tập hợp các LSP, thay thể cho sự tạo ra một LSP tách biệt cho một LSP dự phòng.Chúng ta gọi mỗi một đường hầm LSP là một đường hầm thông giải.



Có thể phát hiện ra lỗi liên kết thông qua một kĩ thuật phát hiện lỗi lớp 2. Dò lỗi node được hoàn thành thông qua sự mất IGP của node liền kết hoặc các thông điệp RSVP hello mở rộng như đã được định nghiã.

4.3.13 MPLS và kĩ thuật lưu lượng

Điều hành hoặc quản trị, như ta vẫn thường thấy, các từ đó mô tả cùng một chức năng. Rất nhiều những tác vụ mà kĩ thuật lưu lượng có, giải quyết một cách chính xác vùng điều hành này. Khía cạnh của MPLS đang quan tâm là đo đạc và điều khiển. Điều này mang đến cho các nhà điều hành mạng một sự mềm dẻo quan trọng trong việc điều khiển các tuyến của dòng lưu lượng qua mạng của họ và cho phép các điều khoản (policies) được bổ sung mà có thể kết quả trong việc tối ưu hoá hiệu năng của các mạng. Nhưng tất nhiên rằng có một sự giới hạn việc điều hành của bao nhiêu các LSP trong thực tế cần thiết. Một số lớn của các đường hầm LSP cho phép điều khiển tốt hơn qua sự phân bố của lưu lượng qua mạng, nhưng làm tăng sự phức tạp của việc điều hành mạng. Một đường từ một node này đến node khác phải được tính toán, ví dụ như tuyến có thể cung cấp QoS cho lưu lượng IP và lấp đầy các yêu cầu khác vể lưu lượng có thể có. Mỗi một tuyến được tính toán, kĩ thuật lưu lượng, nơi là một subnet của sự ràng buộc dựa trên định tuyến, là có thể đáp ứng cho việc thành lập và bảo dưỡng cho trạng thái chuyển tiếp gói tin dọc theo tuyến.

Trong thứ tự để làm thấp hơn sự sử dụng của các kết nối bị tắc ngẽn và trợ giúp những nguồn tắc ngẽn, một người quản trị có thể sử dụng phương pháp TE để định tuyến một subnet của lưu lượng từ các liên kết đó lên trên rất nhỏ các yếu tố topo mạng tắc ngẽn. Đây có thể là ví dụ cho việc tạo các đường hầm LSP mới xung quanh vùng bị tắc ngẽn riêng biệt.

Phương pháp TE có thể được áp dụng để phân bố một cách hiệu quả tập hợp lưu lượng tải trọng làm việc thông qua các liên kết song song giữa các nodes. Trong cách này nó có thể khai thác tài nguyên mạng triệt để hơn. Người ta có thể sử dụng các thông số băng thông LSP để điều khiển tỉ lệ của yêu cầy đi qua mỗi liên kết. Nó cũng có thể dùng để cấu hình tường minh các tuyến cho các đường hầm LSP để phân bố các tuyến



thông qua các liên kết song song, và sử dụng những điểm tương đồng (similarities) để ánh xạ các LSP khác lên trên những liên kết khác. [3].

Đôi khi người ta để ngăn cản các loại nào đó của lưu lượng để chắc chắn các kiểu của các liên kết, hoặc ngăn chặn các kiểu nào đó tường minh của các liên kết cho các tuyến cho một vài loại của lưu lượng. Điều này là có ích khi ngăn cản cho trường hợp lưu lượng lục địa đi ngang qua đại dương. Trong một ví dụ khác, có thể chắc chắn ngăn chặn lưu lượng từ một subnet của các mạch để giữ các LSP liên vùng, luôn luôn từ các mạch mà chúng bị đảo ngược cho lưu lượng.

Hình 4.16 ví dụ về kĩ thuật lưu lượng

Ví dụ, trong ví dụ về kĩ thuật lưu lượng đưa ra trên hình 4.16, có 2 tuyến từ router C đến router G. Nếu router chọn 1 trong số các tuyến như là tuyến ngắn nhất, nó sẽ mang toàn bộ lưu lượng dự định đến cho router G thông qua tuyến này. Khối lưu lượng kết quả thu được trên tuyến đó có thể gây nên tắc nghẽn, trong khi tuyến khác thì lại không sử dụng hết tải (under- loaded). Để tối đa hoá hiệu suất của toàn bộ mạng, ta có thể dịch một vài phần của lưu lượng từ một kết nối đến một kết nối khác.

Hình 4.17 : BGP phân phối nhãn qua nhiều Autonomous System.



Trong ví dụ đơn giản này ta có thể đặt cost của tuyến từ C-D-G cân bằng với cost của tuyến C-E-F-G. Vì vậy một sự gần tiến đến cân bằng tải trở nên khó khăn, nếu có thể, trong các mạng với một topology phức tạp. Các tuyến được định tuyến tường minh, thực hiện bằng cách sử dụng MPLS, có thể được sử dụng như là một cách đơn giản hơn và mềm dẻo của vấn đề đánh địa chỉ này, cho phép một vài phần của lưu lượng trên một tuyến tắc ngẽn được rời đi đến một tuyến ít tắc nghẽn nhất.

BGP có thể dùng để thiết lập phân phối nhãn cho các LSP đi xuyên qua các mạng của nhiều nhà cung cấp khác nhau. Hình 4.17 trên gồm 3 hệ tự trị là A,B,C. AS A cấp phát cho khách hàng Prefix địa chỉ (FEC) “a.b/16”. Router C3 quảng bá nó như một NLRI cho AS-A và AS-B bằng bản tin BGP UPDATE có chứa Next-hop và ASPATH. Bản tin update được gủi bởi C3 đến A3 còn mang một ánh xạ từ FEC “route reflector”. Nhằm tìm cách tốt nhất để chuyền tiếp các gói đến prefix “a.b/16”, A1 có thể xác định rằng đường AS ngắn nhất là qua hop kế A3 sử dụng nhãn L. nhờ định tuyến nội và giao thức phân phối nhãn của mình, router A1 cũng biết rằng tuyến tốt nhất để đến A3 là đi qua A2 sử dụng nhãn M. Kết quả là khi chuyển gói đến prefix “a.b/16”, router A1 push nhãn L lên gói rồi push tiếp nhãn M trên đỉnh stack . Như vậy, một LSP được chui bên trong một đường hầm LSP khác. LSP1 bên ngòai kéo dài từ A1 đến A3. Trong khi đó, LSP 2 kéo dài từ AS A đến AS C và có một đoạn chui bên trong LSP1.



KẾT LUẬN

Bài khóa luận đã trình bày một cách tổng quan về công nghệ MPLS và các kĩ thuật vận hành và bảo dưỡng cho mạng MPLS. Mục tiêu cơ bản của công nghệ này là tích hợp kĩ thuật định tuyến IP và chuyển mạch ATM vào thành một kĩ thuật đơn nhất. MPLS giải quyết tốt vấn đề tắc nghẽn, tận dụng tối đa tài nguyên mạng, góp phần nâng cao QoS trên mạng, cho phép các nhà khai thác viễn thông giảm bớt chi phí vận hành, đơn giản hóa việc quản lí lưu lượng và hỗ trợ các dịch vụ IP liên kết với nhau. Nội dung chính của bài khóa luận là trình bày về công việc vận hành và bảo dưỡng (OAM) trên các mạng MPLS. Nêu ra được các yêu cầu của OAM cho mạng MPLS. Đồng thời đưa ra các công cụ để thực hiện các kĩ thuật OAM. Thấy được kĩ thuật Ping LSP và Traceroute LSP MPLS cũng như những đặc trưng của chúng được sử dụng trong IOS Cisco. Thấy được công cụ VCCV được sử dụng như thế nào để kiểm tra mặt phẳng dữ liệu của các mạng AtoM. Bài khóa luận đã nêu ra được một số công cụ cho việc đo đạc IP SLA, tính toán cho các mạng MPLS. Sử dụng các công cụ như MIB, SNMP, traps, syslog trong việc quản trị các mạng VPN MPLS đặc trưng. Cuối cùng, giành một phần ngắn cho việc trình bày về ánh xạ các thông điệp OAM, cái mà ánh xạ các thông điệp giao thức lớp 2 tự nhiên lên các thông điệp OAM pseudowire. Qua quá trình tìm hiểu thực hiện nội dung của bài khóa luận, em hiểu thêm được tầm quan trọng của việc vận hành và bảo dưỡng các mạng MPLS, để duy trì sự họat động một cách ổn định và hiệu quả của mạng, nâng cao chất lượng dịch vụ, khai thác tốt lợi thế vượt trội mà công nghệ MPLS này mang lại. Do điều kiện về thời gian hạn hẹp, em chưa thể thực hành được trên các dòng router có hỗ trợ MPLS, cũng như chưa thể thực hiện mô phỏng được, vì vậy nội dung bài khóa luận vẫn là tìm hiểu trên lý thuyết. Đặc biệt là với đề tài “vận hành và bảo dưỡng trong MPLS”, từ trước chưa có sinh viên nào thực hiện, nên tài liệu tiếng Việt là chưa có, em đã tổng hợp và dịch từ một số tài liệu tiếng Anh. Mặc dù đã nỗ lực rất nhiều để khắc phục khó khăn này nhưng cũng không thể tránh khỏi những sai sót. Em rất mong nhận được những đóng góp của các thầy cô giáo cũng như các bạn sinh viên để em hoàn thiện kiến thức, nắm chắc được về công nghệ này.



TÀI LIỆU THAM KHẢO

Các sách tham khảo

[1]. Dini, P.; Hasan, M.Z.; Morrow, M.; Parr, G.; Rolin, P.. (2002). Mechanisms for OAM on MPLS in Large IP Backbone Networks, Master thesis – Information and Communication Technology, Agder University College

[2]. Đỗ Mạnh Quyết, Phùng Văn Vận, Nguyễn Tất Đắc. (2003). Công nghệ chuyển mạch nhãn đa giao thức

[3]. Leone, L. (GARR) & Suin, S. (SERRA) Deployment of a Virtual Private LAN Service using Ethernet over MPLS technology

[4]. Medhi, D. & Ramasami, K. Network routing algorithms protocols and architects

[5]. Mitchel, S. (2006) MPLS Fundamentals Cisco Press Nev

[6]. Nguyễn Thị Tố Uyên. (2006). Chuyển mạch nhãn đa giao thức

Tổng hợp thông tin từ một số trang Web: (Không rõ ngày xuất bản)

[7]. Tạp chí bưu chính viễn thông trực tuyến http://www.tapchibcvt.gov.vn

[8]. Trang web chuyên ngành công nghệ điện tử viễn thông của http://vnexperts.net

[9]. Trang web về công nghệ Việt Nam http://vnpro.org

Documents

Van Hanh Va Bao Duong Trong Mpls