Việc chuyển từ bảng luồng đơn của OpenFlow 1.0 sang nhiều bảng luồng, được chỉ định trong OpenFlow 1.1 và được hầu hết các nhà cung cấp triển khai trong OpenFlow 1.3 đã được kích động để mở ra tiềm năng phong phú của SDN cho một phổ ứng dụng ngày càng tăng. Bảng lưu lượng đơn, rất linh hoạt không liên kết tốt với các đường ống phần cứng có sẵn trong silicon chuyển mạch tiên tiến . Mặc dù việc xâu chuỗi nhiều bảng luồng vào một đường ống thực sự gần đúng hơn với các triển khai phần cứng thực, nhưng sự khác biệt giữa các triển khai này đòi hỏi bất kỳ ứng dụng nào muốn sử dụng các tính năng chi tiết này cần phải được phát triển với kiến thức sâu sắc về các chi tiết phần cứng đó. Một lý do cho sự khác biệt trong các triển khai này là hỗ trợ cho nhiều tính năng OpenFlow 1.3 được coi là tùy chọn, gây nhầm lẫn thêm cho nhiệm vụ của nhà phát triển ứng dụng. Tình hình là các ứng dụng được thiết kế để sử dụng trên các thiết bị chuyển mạch phần cứng cần phải được phát triển đặc biệt cho các thiết bị chuyển mạch đó. Mặc dù có thể triển khai hỗ trợ OpenFlow thống nhất trên các thiết bị chuyển mạch dựa trên phần mềm. Việc giới hạn một ứng dụng đối với các công tắc như vậy thường làm giảm tính hữu dụng của nó.
Để giải quyết vấn đề về khả năng tương tác này, ONF đã tán thành hai bản tóm tắt mới nhằm tạo điều kiện thuận lợi cho việc tương tác giữa các công tắc OpenFlow 1.3. Hai phần trừu tượng này là Bảng. Mẫu Loại (TTP) và Mục tiêu Luồng.
1. Các mẫu loại bảng
Vào năm 2014, ONF đã xuất bản đặc điểm kỹ thuật TTP đầu tiên. TTP là một mô tả chính thức và chi tiết của một tập hợp đầy đủ các hành vi chuyển đổi logic. Nhiều công tắc logic OpenFlow (OFLS) có thể cùng tồn tại bên trong một công tắc vật lý nhất định. Từ quan điểm của nhà phát triển ứng dụng, OFLS sở hữu các khả năng chuyển đổi được yêu cầu bởi một ứng dụng cụ thể. Từ quan điểm của nhà cung cấp công tắc, hành vi của một OFLS được mô tả ngắn gọn trong thuật ngữ đặc tả OpenFlow của TTP. Thực tế là một TTP cụ thể ngắn gọn và bị giới hạn trong một ứng dụng hoặc lớp ứng dụng làm cho nó khả thi để nhà cung cấp thiết bị chuyển mạch xác nhận hỗ trợ hoặc không hỗ trợ cho OFLS cụ thể đó. Là OFLS được mô tả bởi TTP, TTP trở thành ngôn ngữ mà bộ điều khiển và công tắc có thể sử dụng để xác nhận hoặc phủ nhận sự tồn tại của một tập hợp các khả năng cần thiết.
Ngôn ngữ chính thức để mô tả TTP được mô tả và dựa trên Đối tượng JavaScript Ký hiệu (JSON). Một TTP mẫu rất hữu ích mô tả một OFLS triển khai L2 và L3 đơn giản chuyển tiếp chuyển tiếp được cung cấp trong.
2. Mục tiêu lưu lượng
Mặc dù TTP cung cấp một cách thống nhất để mô tả một đường dẫn cụ thể cần thiết trong một bảng nhiều Công tắc hỗ trợ OpenFlow, ngôn ngữ của TTP vẫn yêu cầu kiến thức chi tiết về OpenFlow chi tiết thực hiện đường ống đó. Mục tiêu luồng nhằm trừu tượng hóa cấp độ OpenFlow nhiều bảng
hành động vào các mục tiêu ứng dụng chung. Các mục tiêu định hướng dịch vụ này mô tả tương đối các chức năng chuyển mạch cấp cao cần thiết của một ứng dụng nhưng được thực hiện thông qua các đường ống khác nhau trên các công tắc vật lý khác nhau. Trong hình 18, chúng tôi chỉ ra nơi các mục tiêu luồng được xác định trong Open Hệ điều hành mạng (ONOS) được nhúng trong giải pháp nguồn mở Atrium được cung cấp bởi ONF. Ví dụ về các mục tiêu hướng dịch vụ này sẽ bao gồm mục tiêu lọc, mục tiêu chuyển tiếp và mục tiêu bước tiếp theo.
Mục tiêu của việc thể hiện tính trừu tượng của mục tiêu luồng là cho phép các nhà phát triển ứng dụng xây dựng các ứng dụng được hưởng lợi từ các nền tảng chuyển đổi dựa trên OpenFlow có thể mở rộng, nhiều khả năng biết các chi tiết của đường ống OpenFlow sẽ triển khai các dịch vụ cần thiết. Như hình trong Hình 18, các trình điều khiển đường ống cụ thể về mặt kiến trúc bên dưới các mục tiêu dòng chảy che dấu sự khác biệt giữa các đường ống khác nhau cho phép nhà phát triển ứng dụng chỉ định các dịch vụ trừu tượng hơn cấp hơn so với việc sử dụng thuật ngữ OpenFlow. VI. Các mở rộng giao thức vận tải mạng quang
Phần mở rộng Giao thức Truyền tải Quang học OpenFlow được phát hành vào ngày 15 tháng 3 năm 2015. Điều này đặc điểm kỹ thuật xây dựng dựa trên khả năng mở rộng thuộc tính cổng được xác định trong OpenFlow 1.4. Trong khi V.1.4 đó phần mở rộng tạo điều kiện thuận lợi cho việc cấu hình và báo cáo các thông số cổng quang cụ thể, có một số lượng các khu vực vẫn cần được giải quyết để cung cấp cho OpenFlow hỗ trợ mạnh mẽ của quang học thực tế kết nối mạng.
Hình 18: Flow objectives abstraction.
1. MATCH/ACTION SUPPORT
Trong chuyển mạch gói, nhiều chức năng điều khiển có thể đạt được bằng cách tiêm mặt phẳng điều khiển điều khiển các gói vào mặt phẳng dữ liệu. Ví dụ, kiến thức về các cụm từ cùng nhau tạo thành cấu trúc liên kết của mạng có thể được thu thập bằng cách trao đổi các gói điều khiển như vậy giữa các máy bay điều khiển. Phương pháp này không hoạt động với chuyển mạch quang, nơi các bộ chuyển mạch không thể đơn giản tiêm các gói trong dòng.
Tương tự, chuyển mạch quang không phải là chuyển mạch gói, chúng là chuyển mạch mạch. Ngụ ý trong này sự khác biệt, một công tắc mạch hỗ trợ OpenFlow thường sẽ không kiểm tra các tiêu đề gói để sử dụng làm phù hợp với tiêu chí cho các bảng quy trình và do đó không sử dụng thông tin
đó để thực hiện các hành động như chuyển tiếp hoặc rơi vãi. Thay vào đó, công tắc mạch sẽ dựa trên các quyết định hành động và khớp này cho một tín hiệu trên cơ sở của đặc tính Kênh quang (OCh) chẳng hạn như bước sóng để chuyển mạch L0 hoặc trên cơ sở Đặc tính Đơn vị Dữ liệu Quang (ODU) giống như khe cắm nhánh ODU cho chuyển mạch L1. Phụ lưu ODU khe cắm sẽ xác định mạch theo vị trí của nó trong thời gian trong khi các kênh quang vật lý riêng lẻ được phân biệt bằng cách truyền trên các bước sóng khác nhau. Trong cả hai trường hợp, việc xác định mạch cho phép một bộ quy tắc dựa trên bảng dòng để quy định hành động mà công tắc sẽ thực hiện đối với mạch này.
Lưu ý: Trong ngữ cảnh Mạng truyền tải quang (OTN) này, chúng tôi sử dụng các thuật ngữ tín hiệu, kênh và mạch thay thế cho nhau.
2. OPTICAL PORT ATTRIBUTE SUPPORT
Trong OTWG định nghĩa các phần mở rộng mô tả cổng OTN. Các phần mở rộng này được sử dụng để xác định và xác định các loại cổng cho điều khiển chuyển mạch kênh L0 và L1. Cụ thể hơn, các tiện ích mở rộng được sử dụng để xác định và báo cáo về các đặc tính của Phần truyền quang (OTS), Vật lý quang, Các cổng Phần (OPS) và Đơn vị Truyền tải Kênh Quang (OTU). Ví dụ về đặc điểm sẽ được chỉ định sẽ là lớp lớp cụ thể của tín hiệu OTN. Ví dụ về các lớp lớp này là:
• OCH (loại tín hiệu lớp OCh) • ODU (loại tín hiệu lớp ODU)
• ODUCLT (ODU Loại tín hiệu lớp Máy khách).
Trong mỗi lớp lớp này, có nhiều khả năng cho loại tín hiệu cụ thể. Cái này loại tín hiệu cụ thể cũng được chỉ định trong các phần mở rộng OTN. Có rất nhiều OTN khác dành riêng cho các trường được xác định trong các phần mở rộng này và việc đi sâu vào chi tiết của cuốn sách này nằm ngoài phạm vi của cuốn sách mạng quang học. Chúng tôi giới thiệu người đọc đến để biết thêm chi tiết. Trong có hai phương pháp được cung cấp mà các phần mở rộng mô tả cổng OTN này có thể được thông qua giữa bộ điều khiển và công tắc, một dựa trên OpenFlow 1.3 và một dựa trên OpenFlow 1.4. Một trong những thay đổi trong OpenFlow 1.4 là mở rộng bộ mô tả cổng cơ bản để cung cấp hỗ trợ cho nhiều loại cổng hơn. Mặc dù bộ mô tả cổng mở rộng này cung cấp một bộ thông số phong phú hơn để mô tả một cổng, nó vẫn thiếu sự phong phú đầy đủ cần thiết để mô tả đầy đủ một cổng OTN. Do đó trong OpenFlow 1.4 và hơn thế nữa, các phần mở rộng OTN được ghi lại bằng sự kết hợp của cổng mở rộng bộ mô tả cộng với một tập hợp các phần mở rộng OTN được định nghĩa trong. Đối với OpenFlow 1.3, Tham khảo chỉ định một thông báo nhiều phần của người thử nghiệm có nội dung sẽ chứa bộ mô tả cổng OpenFlow 1.4 theo sau bởi các phần mở rộng OTN đó. (Lưu ý rằng các phần mở rộng OTN này đôi khi được gọi là OTWG OpenFlow 1.5 OTN mở rộng.)
3. Thảo luận
Vì công tắc quang học không thể đưa các gói điều khiển vào dòng dữ liệu để vượt qua kiểm soát và thông tin cấu trúc liên kết thông qua mạng như các chuyển mạch gói hiện đang làm, các cơ chế khác cần thiết để cung cấp các tính năng cơ bản quan trọng như khám phá kề. Một cơ chế được đề xuất dựa trên việc sử dụng thông tin kiểm soát được gọi là Số nhận dạng dấu vết (TTI). Các tiêu chuẩn hiện tại của ITU đáp ứng quy định rằng TTI được truyền trực tiếp trong mặt phẳng dữ liệu. Trong thế giới quang học, điều này thông tin có sẵn cho máy bay điều khiển. Các phần mở rộng được đề cập trong [19] cho phép TTI này thông tin được cung cấp thông qua OpenFlow cho bộ điều khiển. Đến lượt mình, bộ điều khiển có thể sử dụng. Thông tin TTI được báo cáo từ các thiết bị chuyển mạch khác nhau để tổng hợp các khối bổ trợ và do đó cấu trúc liên kết mạng theo cách mà nó thực hiện đối với chuyển mạch gói. Điều này thể hiện một cơ chế khả thi cho sự gần kề khám phá cho các công tắc mạch quang hỗ trợ OpenFlow.
4. Công việc tương lai cần
Một số lĩnh vực được xác định là quan trọng đối với hỗ trợ OpenFlow của OTN yêu cầu thêm đặc điểm kỹ thuật hơn được cung cấp trong [19]. Bao gồm các:
• Hỗ trợ các cơ chế độ tin cậy của nhà cung cấp dịch vụ cho mặt phẳng dữ liệu, đặc biệt là hỗ trợ cho OAM giám sát các liên kết mạng OTN cũng như hỗ trợ các chức năng chuyển đổi bảo vệ nhanh chóng Đảm bảo khôi phục từ lỗi liên kết.134 CHƯƠNG 5 ĐẶC ĐIỂM KỸ THUẬT OpenFlow • Hỗ trợ các phần tử mạng xử lý nhiều lớp công nghệ theo phân lớp vận chuyển các mô hình.
• Hỗ trợ hệ thống phân cấp của bộ điều khiển. Trong một hệ thống phân cấp như vậy, các thông điệp OpenFlow được trao đổi giữa bộ điều khiển cha và con trong ngữ cảnh Control Virtual Network Interface (CVNI). Cái này rất quan trọng vì quy mô cần thiết để hỗ trợ mạng quang cấp sóng mang sẽ yêu cầu lớn số lượng bộ điều khiển OpenFlow được sắp xếp theo thứ bậc như vậy.
Cũng như công việc trong tương lai được xác định trong , tập đoàn Calient đã xác định các lĩnh vực cần khẩn cấp để thúc đẩy việc sử dụng OpenFlow trong các công tắc mạch quang.
VII. Giới hạn OpenFlow
Vì OpenFlow vẫn ở trạng thái phát triển nhanh chóng, rất khó để xác định các giới hạn chính xác như những điều này có thể được giải quyết trong các bản phát hành tiếp theo. Một hạn chế là các trường đối sánh hiện được xác định bị giới hạn ở tiêu đề gói tin. Do đó, Kiểm tra gói sâu, (DPI) trong đó các trường trong gói payload có thể được sử dụng để phân biệt các luồng, không được hỗ trợ trong OpenFlow tiêu chuẩn. Tuy nhiên, Các chế độ EXPERIMENTER được phép trong OpenFlow sẽ mở đường cho định nghĩa luồng lớp ứng dụng như vậy trong tương lai. Thứ hai, một số bản tóm tắt của OpenFlow có thể quá phức tạp để triển khai trực tiếp bằng silicon ngày nay. Đây không phải là một trở ngại không thể vượt qua trong thời gian dài, tuy nhiên, vì động lực to lớn đằng sau SDN có khả năng sinh ra các chip chuyển đổi được thiết kế rõ ràng để triển khai ngay cả những tính năng phức tạp nhất của OpenFlow. Một hạn chế khác là có thể có độ trễ xử lý nếu không có mục nhập phù hợp trong bảng luồng của công tắc OpenFlow, trong đó xử lý trường hợp yêu cầu gói tin được gửi đến bộ điều khiển. Mặc dù đây chỉ là một hành vi mặc định và bộ chuyển mạch có thể được lập trình dễ dàng để xử lý gói tin một cách rõ ràng, độ trễ tiềm ẩn này là cố hữu vào mô hình OpenFlow. Ngoài ra còn có một số lỗ hổng bảo mật có thể xảy ra bởi OpenFlow, chẳng hạn như (1) Các rủi ro từ chối dịch vụ phân tán (DDoS) có thể khiến người kiểm soát không khả dụng và (2) không triển khai xác thực chuyển mạch trong bộ điều khiển.
VIII. Kết luận
Qua những mục trên cấp cho người đọc sự hiểu biết ở mức độ cao về OpenFlow framework. Điều này bao gồm giao thức mà bộ điều khiển OpenFlow sử dụng để cấu hình và điều khiển một OpenFlow switch. Chúng tôi đã trình bày các bản tóm tắt OpenFlow dựa trên switch phải được triển khai trên một công tắc vật lý như một giao diện với các bảng phần cứng thực tế và chuyển tiếp động cơ của công tắc để nó hoạt động như OpenFlow switch.