Tiêu chuẩn TCVN 13599-2:2022 Hệ thống giao thông thông minh (ITS)

TIÊU CHUẨN QUỐC GIA

TCVN 13599-2:2022

ISO 15784-2:2015

HỆ THỐNG GIAO THÔNG THÔNG MINH (ITS) - TRAO ĐỔI DỮ LIỆU VỚI CÁC MÔ ĐUN GIAO TIẾP BÊN ĐƯỜNG - PHẦN 2: GIAO TIẾP GIỮA TRUNG TÂM VÀ CÁC THIẾT BỊ LIÊN QUAN BẰNG GIAO THỨC SNMP

Intelligent transport systems (ITS) - Data exchange involving roadside modules communication - Part 2: Traffic Management Centre to field device communications using SNMP

Lời nói dầu

TCVN 13599-2:2022 hoàn toàn tương đương với ISO 15784- 2:2015 “Intelligent transport systems (ITS) - Data exchange involving roadside modules communication - Part 2: Centre to field device communications using SNMP” của Tổ chức tiêu chuẩn hóa quốc tế ISO.

TCVN 13599-2:2022 do Bộ Giao thông Vận tải biên soạn và đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

HỆ THỐNG GIAO THÔNG THÔNG MINH (ITS) - TRAO ĐỔI DỮ LIỆU VỚI CÁC MÔ ĐUN GIAO TIẾP BÊN ĐƯỜNG - PHẦN 2: GIAO TIẾP GIỮA TRUNG TÂM VÀ CÁC THIẾT BỊ LIÊN QUAN BẰNG GIAO THỨC SNMP

Intelligent transport systems (ITS) - Data exchange involving roadside modules communication - Part 2: Traffic Management Centre to field device communications using SNMP

1  Phạm vi áp dụng

1.1  Tổng quát

Tiêu chuẩn này quy định cơ chế trao đổi dữ liệu và thông điệp trong các trường hợp sau:

a) Giữa (các) trung tâm quản lý giao thông và các mô đun giao tiếp bên đường để quản lý giao thông;

b) Giữa các mô đun giao tiếp bên đường được sử dụng để quản lý giao thông.

Phạm vi của tiêu chuẩn này không bao gồm việc trao đổi thông tin giữa trung tâm quản lý giao thông và các thiết bị trong xe, giữa các mô đun giao tiếp bên đường và các thiết bị trong xe, truyền thông trong xe, hoặc truyền thông trong tủ thiết bị, hoặc truyền video chuyển động từ camera hoặc phương tiện có ghi.

Tiêu chuẩn này là phần bổ sung cho TCVN 13599-3:2022, nhưng sử dụng một tầng ứng dụng khác cho trao đổi thông tin để cấu hình, điều khiển và giám sát các mô đun giao tiếp bên đường điều khiển giao thông tại hiện trường. Trong khi TCVN 13599-3:2022 dựa trên các tiêu chuẩn DATEX, tiêu chuẩn này là một giải pháp thay thế dựa trên SNMP với phần mở rộng tùy chọn để truyền thông hiệu quả hơn trên môi trường băng thông thấp.

Cả hai tiêu chuẩn đều phù hợp với bộ các yêu cầu về hồ sơ ứng dụng được quy định trong TCVN 13599-1:2022.

1.2  Mô tả chung

Hồ sơ ứng dụng này phù hợp để sử dụng khi áp dụng các điều kiện sau:

a) Khi dữ liệu được trao đổi có thể được xác định như là một hoặc nhiều phần tử có thể được truy xuất hoặc được lưu trữ. Giao thức có thể hỗ trợ nhiều loại thiết bị và đã chấp nhận khái niệm cơ sở thông tin quản lý (MIB) xác định cấu hình, kiểm soát và giám sát tham số cho mô đun giao tiếp bên đường. Cách tiếp cận chuẩn hóa này thường được sử dụng cho các ứng dụng quản lý mạng đối với các thiết bị như bộ định tuyến, thiết bị chuyển mạch, cầu nối và tường lửa. Nó cũng được sử dụng ở nhiều nước để điều khiển các thiết bị như các biển báo linh động.

b) Khi yêu cầu trao đổi dữ liệu được đảm bảo, xác định và thời gian thực là không quá quan trọng. Hoạt động SNMP thường khá nhanh, nhưng hạ tầng mạng có thể gây ra sự chậm trễ trong việc gửi thông điệp hoặc thậm chí làm mát thông điệp; do đó, giao thức này không thích hợp cho các ứng dụng yêu cầu truyền thông tin cậy có thời gian trễ dưới 1 giây;

c) Để trao đổi không liên tục bất kỳ dữ liệu xác định nào. Các hoạt động SNMP thông thường cho phép các thông điệp được cấu trúc bằng cách kết hợp bất kỳ nhóm phần tử nào thành một yêu cầu truy xuất hoặc lưu trữ;

d) Để trao đổi lặp đi lặp lại, thường xuyên của cùng một cấu trúc thông điệp (với các giá trị có thể khác nhau) trên các đường truyền băng thông thấp, cấu hình này hỗ trợ một biến thể hiệu quả của SNMP được gọi là STMP cho phép xác định thời gian chạy của 13 thông điệp có thể được trao đổi lặp lại khi càn với tiêu đề tối thiểu;

e) Đề cho phép một mô đun giao tiếp bên đường đưa ra các báo cáo ngoại lệ khi phát sinh các điều kiện đặc biệt. Hồ sơ này bao gồm khái niệm về một thông điệp thông báo cho phép một đại lý báo cho thiết bị quản lý các điều kiện đặc biệt, mặc dù thiết bị quản lý không yêu cầu cụ thể thông tin vào thời điểm đó.

Lưu ý rằng tiêu chuẩn này không đề cập đến dữ liệu cần thiết cho từng loại thiết bị ITS cụ thể. Các tiêu chuẩn giao tiếp thiết bị tiếp theo sẽ được phát triển để xác định chức năng của thiết bị và các đối tượng để quản lý và giám sát chức năng đó. Tiêu chuẩn này cũng tương tự như NTCIP 2301 xác định các giao thức cùng với các đối tượng cần thiết để điều khiển, vận hành, giám sát và chẩn đoán các giao thức đó. Các tiêu chuẩn khác xác định các đối tượng dành riêng cho thiết bị. Nó dự đoán các lĩnh vực sẽ phát triển MIB thiết bị để đáp ứng nhu cầu cụ thể của chúng.

Tiêu chuẩn này sẽ cho phép triển khai hệ thống mở sử dụng các thiết bị của nhiều nhà sản xuất cung cấp nhiều loại dịch vụ khác nhau trên môi trường mạng dùng chung. Với các giao thức mở như vậy, MIB công cộng, và sự tuân thủ đối với các tiêu chuẩn, các mô đun giao tiếp bên đường có thể tương tác giữa các nhà cung cấp và nhiều nhà cung cấp có thể cung cấp sản phẩm trong môi trường hệ thống.

2  Sự phù hợp

Sự phù hợp với tiêu chuẩn này được định nghĩa trong Phụ lục A thông qua xác định từng tính năng là bắt buộc, tùy chọn hoặc có điều kiện. Các nỗ lực đã được thực hiện để làm cho các bảng tuân thủ này phù hợp với phần nội dung chính của tiêu chuẩn, nhưng trong trường hợp có mâu thuẫn giữa Phụ lục và nội dung chính của tiêu chuẩn này, thì Phụ lục A sẽ được ưu tiên. Tiêu chuẩn này xác định rõ ràng một số tùy chọn mà việc triển khai có thể hỗ trợ. Đây là những tùy chọn có khả năng gặp phải khi triển khai và được liệt kê trong tiêu chuẩn này để tiện theo dõi. Việc bỏ qua một tính năng trong tiêu chuẩn này không nên được hiểu là một tính năng bị cấm sử dụng.

3  Tài liệu viện dẫn

Các tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi bổ sung (nếu có).

TCVN 13599-1:2022, Hệ thống giao thông thông minh (ITS) - Trao đổi dữ liệu với các mô đun giao tiếp bên đường - Phần 1: Nguyên tắc chung và khung tài liệu cho các hồ sơ ứng dụng (ISO 15784-1:2008 Intelligent transport systems (ITS) - Data exchange involving roadside modules communication - Part 1: General principles and documentation framework of application profiles).

ISO/IEC 8825-7, Information technology - ASN.1 encoding rules - Part 7: Specification of Octet Encoding Rules (OER) (Công nghệ thông tin - Quy tắc mã hóa ASN.1 - Phần 7: Đặc điểm kỹ thuật của Quy tắc mã hóa octet).

IETF RFC 1157, A Simple Network Management Protocol (SNMP) (Giao thức quản [ý mạng đơn giản SNMP).

IETF RFC 1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) (Hoạt động giao thức cho phiên bản 2 của Giao thức quản lý mạng đơn giản SNMPv2).

IETF RFC 1910, User Based Security Model for SNMPv2 (Mô hình an toàn dựa trên người dùng cho SNMPv2).

IETF RFC 2578, structure of Management Information Version 2 (SMIv2) (Cấu trúc Thông tin Quản lý Phiên bản 2 (SMIv2)).

IETF RFC 3411:2002, An Architecture for Describing SNMP Management Frameworks (Kiến trúc mô tả các khung quản lý SNMP).

IETF RFC 3412:2002, Message Processing and Dispatching (Xử lý và Gửi thông điệp).

IETF RFC 3413:2002, SNMP Applications (Các ứng dụng SNMP).

IETF RFC 3414:2002, User-based Security Model (Mô hình an toàn dựa trên người dùng).

IETF RFC 3415:2002, View-based Access Control Model (Mô hình điều khiển truy cập dựa trên chế độ hiển thị).

IETF RFC 3416, Version 2 of SNMP Protocol Operations (Phiên bản 2 của Hoạt động Giao thức SNMP).

IETF RFC 3417:2002, Transport Mappings (Ánh xạ vận tải).

IETF RFC 3418:2002, Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) (Cơ sở thông tin quản lý (MIB) cho Giao thức quản lý mạng đơn giản SNMP).

IETF RFC 3584, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework (Cùng tồn tại giữa Phiên bản 1, Phiên bản 2 và Phiên bản 3 của Khung quản lý mạng Internet chuẩn).

IETF RFC 3826:2004, The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User- based Security Model (Giải thuật mật mã tiêu chuẩn mã hóa nâng cao (AES) trong Mô hình an toàn dựa trên người dùng SNMP).

IETF RFC 5590:2009, Transport Subsystem for the Simple Network Management Protocol (SNMP) (Phân hệ truyền tải cho Giao thức quản lý mạng đơn giản SNMP).

IETF RFC 5591:2009, Transport Security Model for the Simple Network Management Protocol (SNMP) (Mô hình an toàn truyền tải cho Giao thức quản lý mạng đơn giản SNMP).

IETF RFC 6353, Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) (Mô hình truyền tải an toàn tầng truyền tải (TLS) cho Giao thức quản lý mạng đơn giản SNMP).

4  Thuật ngữ và định nghĩa

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau:

4.1

Đại lý (agent)

Thực thể SNMP có thể đáp ứng các yêu cầu lấy (get) và lập (set) tới SNMP.

CHÚ THÍCH: Một đại lý cũng có thể đưa ra báo cáo (report), bẫy (trap) và /hoặc thông điệp (message).

4.2

Bộ phận (component)

Bất kỳ thiết bị nào được kết nối với cơ sở hạ tầng ITS

CHÚ THÍCH: Các bộ phận có thể lá bộ phận trung tâm quản lý hoặc bộ phận ở hiện trường. Các bộ phận trong một hệ thống ITS có thể được cung cấp bởi nhiều nhà sản xuất.

4.3

Gói dữ liệu (datagram)

Một đơn vị chứa dữ liệu được truyền độc lập với các đơn vị dữ liệu khác.

4.4

Không dùng nữa (deprecated)

Vẫn có giá trị, nhưng không được sử dụng cho các thiết kế mới.

CHÚ THÍCH: Đây là một thuật ngữ được sử dụng trong trường trạng thái (STATUS) của MIB để chỉ ra rằng đối tượng được liên kết không còn đại diện cho thiết kế xem xét, nhưng đối tượng vẫn có thể hữu ích để tương thích trở lại với triển khai truyền thống. Một đối tượng không dùng nữa có thể trở nên lỗi thời với bản phát hành tiếp theo của tiêu chuẩn.

4.5

Mã hóa (encoding)

Chuỗi byte hoàn chỉnh được sử dụng để biểu thị một giá trị dữ liệu.

4.6

Thực thể (entity)

Thiết bị hoặc “thứ” sẽ trở thành một phần của hệ thống giao thông thông minh.

4.7

Trường hợp (instance)

Việc thực hiện đối tượng cụ thể dựa trên định nghĩa trong thành phần của MIB.

4.8

Có thể tương tác (interoperable)

Khả năng của hai hoặc nhiều hệ thống hoặc thành phần để trao đổi thông tin và sau đó có thể sử dụng thông tin đã được trao đổi.

4.9

Thiết bị quản lý (manager)

Thực thể SNMP có thể tạo các yêu cầu lấy (get) và lập (set) SNMP và/hoặc có thể nhận báo cáo (report), bẫy (trap), và/hoặc các thông báo thông điệp (message).

4.10

Thông điệp (message)

Nhóm các phần tử dữ liệu có cấu trúc hoặc các khung dữ liệu thành một gói thông tin đã được tạo ra với mục đích truyền tin giữa các giữa các thành phần hoặc ứng dụng.

4.11

Dạng MIB (MIB view)

Tập con của tập đầy đủ các trường hợp đối tượng trong MIB thiết bị.

CHÚ THÍCH: Mỗi tập hợp con đối tượng được liên kết với một tên chung SNMP.

4.12

Đối tượng (object)

Phần dữ liệu cụ thể, xác định được đăng ký để sử dụng công khai trên cây định danh đối tượng quốc tế.

CHÚ THÍCH: Các đối tượng có thể được xác định theo một số tiêu chuẩn khác nhau để các hệ thống công nghệ khác nhau sử dụng.

4.13

Định danh đối tượng (object identifier)

Danh sách thứ tự có các giá trị số nguyên từ gốc của cây định danh đối tượng quốc tế đến một nút, xác định rõ ràng nút đỏ.

CHÚ THÍCH: Nguồn TCVN 10583-1:2014, 3.5.11.

4.14

Lỗi thời (obsolete)

Không còn giá trị.

CHÚ THÍCH: Đây là một thuật ngữ được sử dụng trong trường trạng thái (STATUS) của MIB để chỉ ra rằng đối tượng liên quan không còn đại diện cho thiết kế xem xét và không nên sử dụng. Một đối tượng lỗi thời có thể bị xóa khỏi tiêu chuẩn phát hành tiếp theo.

4.15

Giao thức (protocol)

Tập hợp các định dạng thông điệp (quy tắc ngữ nghĩa, cú pháp và ký hiệu) và các quy tắc trao đổi thông điệp giữa các thực thể tầng ngang hàng (thông điệp nào hợp lệ).

CHÚ THÍCH: Nguồn ISO/IEC 16500-1:1999, 3.56.

4.16

Đơn vị dữ liệu giao thức (protocol data unit)

Đơn vị thông tin được truyền thông giữa các thiết bị mạng.

CHÚ THÍCH: Nguồn ISO/IEC 24791-5:2012, 4.10.

4.17

Đại lý ủy quyền (proxy agent)

Đại lý hoạt động thay mặt cho một thực thể mục tiêu.

CHÚ THÍCH: Đại lý ủy quyền thường được sử dụng làm bộ dịch để cho phép thiết bị không phù hợp với giao thức mạng có thể tham gia vào mạng.

4.18

Mô đun giao tiếp bên đường (roadside module)

Nhóm các bộ phận hoặc các ứng dụng được cài đặt trong một mô đun giao tiếp bên đường và có thể được kiểm soát và/hoặc giám sát bởi một thực thể từ xa.

CHÚ THÍCH: Mỗi mô đun giao tiếp bên đường có thể là chủ thể riêng biệt theo các thông số kỹ thuật xác định các chức năng và giao diện yêu cầu.

4.19

Ứng dụng SNMP (SNMP application)

Thành phần kiến trúc bên trong của kiến trúc SNMP như được định nghĩa trong IETF RFC 3411.

CHÚ THÍCH: Các ứng dụng SNMP đã xác định bao gồm bộ tạo lệnh, bộ phản hồi lệnh, bộ khởi tạo thông báo, bộ nhận thông báo và bộ chuyển tiếp proxy.

4.20

Thực thể SNMP (SNMP entity)

Triển khai SNMP nằm trong một thực thể.

4.21

Nhãn (tag)

Phương tiện biểu thị loại của mỗi loại ASN.1.

5  Ký hiệu và thuật ngữ viết tắt

6  Tổng quan

6.1  Quy ước

6.1.1  ASN.1

Tiêu chuẩn này bao gồm các mô đun ASN.1, MIB (được viết dưới dạng ASN.1), các tham khảo và giải thích các khái niệm dữ liệu ASN.1 trong nội dung của nó. Trong mọi trường hợp, các thuật ngữ ASN.1 được biểu diễn bằng các thuật ngữ tiếng Anh.

6.1.2  Thuật ngữ SNMP

Thuật ngữ giữa các phiên bản SNMP hơi khác nhau. Với các mục tiêu trong tiêu chuẩn này, áp dụng thuật ngữ SNMPv3.

6.1.3  Định dạng

Hồ sơ ứng dụng này tuân theo TCVN 13599-1:2022.

6.2  Mô đun ASN.1 và MIB

Tất cả các mô đun ASN.1 cho tiêu chuẩn này đã được nhóm vào Phụ lục B để dễ dàng tham khảo. Tất cả các mô đun MIB đã được nhóm vào Phụ lục C để dễ dàng tham khảo.

6.3  Kiến trúc logic

Hình 1 - Ví dụ về kịch bản AP này

Hồ sơ ứng dụng này phù hợp để sử dụng trong các kiến trúc được mô tả trong Hình 1:

1) Truyền thông giữa trung tâm quản lý giao thông (TMC) và các mô đun giao tiếp bên đường;

2) Truyền thông giữa một trung tâm khác (không quản lý giao thông) và các mô đun giao tiếp bên đường;

3) Truyền thông giữa hai mô đun giao tiếp bên đường. Lưu ý rằng tiêu chuẩn này dựa trên việc sử dụng SNMP triển khai mô hình SET/GET trong đó có một thiết bị quản lý và một đại lý. Tuy nhiên, một mô đun giao tiếp bên đường có thể hoạt động như thiết bị quản lý (ví dụ: gửi yêu cầu đến các mô đun giao tiếp bên đường khác) và đồng thời với tư cách là một đại lý (ví dụ: phản hồi các yêu cầu từ TMC).

6.4  Mối quan hệ với mô hình OSI

Mô hình tham chiếu liên kết các hệ thống mở (Open Systems Interconnect - OSI) định nghĩa bảy tầng, mỗi tầng thực hiện một vai trò cụ thể trong việc truyền dữ liệu qua một phương tiện. Tiêu chuẩn này định nghĩa sự kết hợp của các tiêu chuẩn cho ba tầng cao trong mô hình.

Tầng trên cùng của mô hình bảy tầng OSI, tầng ứng dụng, xử lý các vấn đề như tính trong suốt của mạng, phân bổ tài nguyên và các vấn đề liên quan tới phân vùng. Tầng ứng dụng liên quan đến cách nhìn của người dùng về mạng.

Tầng cao thứ hai trong mô hình bảy tầng OSI, còn được gọi là tầng 6 hoặc tầng trình diễn, thực hiện các chức năng như nén văn bản, chuyển đổi mã hoặc chuyển đổi định dạng để cố gắng giải quyết sự khác biệt giữa các máy trạm.

Tầng 5, tầng phiên, xử lý an toàn và tạo phiên.

Các giao thức cụ thể được xác định bởi tiêu chuẩn này cho mỗi tầng được biểu diễn trong Bảng 1.

Bảng 1 - Giao thức cho các tầng OSI

7  Yêu cầu

7.1  Tổng quan

Các yêu cầu và lựa chọn mức cao được trình bày trong tiêu chuẩn này được trình bày theo kiến trúc mô đun của SNMPv3. Như vậy, Điều này bao gồm các điều nhỏ về cơ bản tương ứng với IETF RFC 3411 đến IETF RFC 3418:

a) Thuật ngữ và kiến trúc;

b) Xử lý và gửi thông điệp;

c) Các ứng dụng;

d) Các mô hình an toàn;

e) Kiểm soát truy nhập dựa trên chế độ hiển thị;

f) Các hoạt động của giao thức;

g) Ánh xạ vận tải;

h) Các cơ sở thông tin quản lý.

7.2  Thuật ngữ và kiến trúc

Thuật ngữ và kiến trúc được sử dụng cho các thảo luận SNMP sẽ được định nghĩa trong IETF RFC 3411 và IETF RFC 5590.

CHÚ THÍCH: Kiến trúc bao gồm định nghĩa về các thành phần khác nhau và các giao diện dịch vụ trừu tượng có thể tồn tại trong một thực thể SNMP. Việc triển khai được khuyến khích áp dụng kiều kiến trúc này cho thiết kế bên trong song không bắt buộc phải làm như vậy. Tiêu chuẩn này chỉ yêu cầu sự phù hợp ở giao diện bên ngoài của công cụ SNMP và không đặt ra bất kỳ yêu cầu nào đối với thiết kế bên trong. Tuy nhiên, các thuật ngữ được định nghĩa trong kiến trúc này rất quan trọng trong việc hiểu hoạt động dự kiến của giao thức tổng thể và do đó, IETF RFC này là một tham chiếu quy chuẩn.

7.3  Xử lý và gửi thông điệp

7.3.1  Yêu cầu chung

Các quy tắc xử lý và gửi thông điệp phải tuân theo IETF RFC 3412.

Việc thực hiện tiêu chuẩn này phải hỗ trợ ít nhất một trong các mô hình xử lý thông điệp SNMP sau:

a) Xử lý Thông điệp Phiên bản 1 như định nghĩa trong 7.3.2;

b) Xử lý Thông điệp Phiên bản 2 như định nghĩa trong 7.3.3;

c) Xử lý Thông điệp Phiên bản 3 như định nghĩa trong 7.3.4 .

Việc thực hiện tiêu chuẩn này có thể hỗ trợ phần mở rộng STMP như được định nghĩa trong 7.3.5.

CHÚ THÍCH: Chúng bao gồm các quy tắc gửi và nhận thông điệp, xử lý thông điệp theo phiên bản cụ thể, tương tác với phân hệ an toàn và điều phối các PDU tới các ứng dụng SNMP thích hợp.

7.3.2  Mô hình xử lý thông điệp phiên bản 1

Việc thực hiện tiêu chuẩn này có thể hỗ trợ xử lý thông điệp SNMPv1. IETF RFC 1157 sẽ cung cấp định nghĩa chuẩn về giao diện bên ngoài cho phiên bản giao thức này.

CHÚ THÍCH: Mặc dù IETF RFC 1157 không được viết bằng thuật ngữ và cấu trúc được xác định bởi kiến trúc SNMPv3, nhưng nó xác định đầy đủ các đầu vào và đầu ra như được chứng minh bằng số lượng lớn các triển khai có thể tương tác trên toàn thế giới.

Nếu được hỗ trợ, SNMPv1 sẽ được yêu cầu để có thể hoạt động đồng thời với tất cả các mô hình xử lý thông điệp được hỗ trợ khác. Một triển khai hỗ trợ phiên bản này có thể được cấu hình để vô hiệu hóa việc sử dụng nó. Hoạt động đồng thời của các phiên bản sẽ được mô tả trong IETF RFC 3584.

SNMPv1 không cung cấp bất kỳ cơ chế an toàn đáng kể nào. Nó chỉ được cho phép khi kết nối giữa thiết bị quản lý và đại lý khi biết là an toàn.

7.3.3  Mô hình xử lý thông điệp phiên bản 2

Việc thực hiện tiêu chuẩn này có thể hỗ trợ xử lý thông báo SNMPv2. IETF RFC 1905 sẽ cung cấp định nghĩa chuẩn về giao diện bên ngoài cho phiên bản giao thức này. Nếu được hỗ trợ, SNMPv2 sẽ được yêu cầu để có thể hoạt động đồng thời với tất cả các mô hình xử lý thông điệp được hỗ trợ khác. Thực hiện hỗ trợ phiên bản này có thể được cấu hình để vô hiệu hóa việc sử dụng nó. Hoạt động đồng thời của các phiên bản sẽ được mô tả trong IETF RFC 3584.

7.3.4  Mô hình xử lý thông điệp phiên bản 3

Cần đặc biệt khuyến nghị rằng mỗi thực hiện tiêu chuẩn này đều hỗ trợ mô hình xử lý thông điệp SNMPv3 được xác định trong Điều 6 của IETF RFC 3412:2002.

CHÚ Ý: Đây là phiên bản SNMP mới nhất và cung cấp truyền thông an toàn và cải thiện báo cáo ngoại lệ.

Nếu được hỗ trợ, SNMPv3 sẽ được yêu cầu để có thể hoạt động đồng thời với tất cả các mô hình xử lý thông điệp được hỗ trợ khác. Thực hiện hỗ trợ phiên bản này có thể được cấu hình để vô hiệu hóa việc sử dụng nó. Hoạt động đồng thời của các phiên bản sẽ được mô tả trong IETF RFC 3584.

7.3.5  Mô hình xử lý thông điệp STMP

Việc thực hiện tiêu chuẩn này có thể hỗ trợ Mô hình xử lý thông điệp STMP ngoài (các) Mô hình xử lý thông điệp SNMP đã chọn. Điều 6.2 cung cấp định nghĩa về Mô hình xử lý thông điệp STMP.

Nếu được hỗ trợ, STMP sẽ được yêu cầu để có thể hoạt động đồng thời với tất cả các mô hình xử lý thông điệp được hỗ trợ khác. Thực hiện hỗ trợ phiên bản này có thể được cấu hình để vô hiệu hóa việc sử dụng nó. STMP sẽ có thể hoạt động đồng thời với tất cả các phiên bản SNMP được hỗ trợ.

7.4  Ứng dụng

7.4.1  Loại thực thể

Việc thực hiện tiêu chuẩn này phải là đại lý, thiết bị quản lý hoặc cả hai. Việc thực hiện sẽ hỗ trợ (các) chế độ hoạt động giống nhau cho tất cả các giao thức được hỗ trợ.

7.4.2  Bộ tạo lệnh

Thiết bị quản lý phải hỗ trợ ứng dụng tạo lệnh như định nghĩa trong IETF RFC 3413.

Đại lý có thể hỗ trợ ứng dụng tạo lệnh như định nghĩa trong IETF RFC 3413.

7.4.3  Bộ phản hồi lệnh

Thiết bị quản lý có thể hỗ trợ ứng dụng phản hồi lệnh như định nghĩa trong IETF RFC 3413.

Đại lý sẽ hỗ trợ một ứng dụng phản hồi lệnh như định nghĩa trong IETF RFC 3413.

7.4.4  Bộ khởi tạo thông báo

Thiết bị quản lý có thể hỗ trợ ứng dụng tạo thông báo như định nghĩa trong IETF RFC 3413.

Đại lý có thể hỗ trợ một ứng dụng khởi tạo thông báo như định nghĩa trong IETF RFC 3413.

7.4.5  Bộ nhận thông báo

Thiết bị quản lý có thể hỗ trợ ứng dụng nhận thông báo như định nghĩa trong IETF RFC 3413.

Đại lý có thể hỗ trợ ứng dụng nhận thông báo như định nghĩa trong IETF RFC 3413.

7.4.6  Bộ chuyển tiếp proxy

Thiết bị quản lý có thể hỗ trợ ứng dụng chuyển tiếp proxy như định nghĩa trong IETF RFC 3413.

Đại lý có thể hỗ trợ ứng dụng chuyển tiếp proxy như định nghĩa trong IETF RFC 3413.

7.5  Các mô hình an toàn

7.5.1  Mô hình an toàn dựa trên người dùng cho SNMP phiên bản 2

Việc thực hiện tiêu chuẩn này hỗ trợ SNMPv2 sẽ hỗ trợ Mô hình an toàn dựa trên Người dùng định nghĩa trong IETF RFC 1910 cho các thông điệp SNMPv2.

7.5.2  Mô hình an toàn dựa trên người dùng cho SNMP phiên bản 3

Việc thực hiện tiêu chuẩn này hỗ trợ SNMPv3 sẽ hỗ trợ Mô hình an toàn dựa trên Người dùng định nghĩa trong IETF RFC 3414 cho cả SNMPv3 và STMP.

7.5.2.1 Xác thực MD5

Việc thực hiện tiêu chuẩn này hỗ trợ SNMPv3 có thể hỗ trợ xác thực HMAC-MD5-96 (MD5) như định nghĩa trong IETF RFC 3414:2002, Điều 6.

CHÚ Ý: Tùy chọn này không được an toàn như lược đồ xác thực SHA1.

7.5.2.2  Xác thực SHA1

Việc thực hiện tiêu chuẩn này hỗ trợ SNMPv3 sẽ hỗ trợ xác thực HMAC-SHA-96 (SHA-1) như định nghĩa trong IETF RFC 3414:2002, Điều 7.

GHI CHÚ: Đặc biệt khuyến nghị xác thực tất cả các yêu cầu đã thiết lập.

Khi tốc độ bộ xử lý máy tính tăng lên, các sơ đồ xác thực sẽ được cải thiện để cung cấp bảo vệ đầy đủ chống lại các cuộc tấn công tự động. Mức độ xác thực như SHA-1 được đề xuất để bảo vệ khỏi các cuộc tấn công tự động.

7.5.2.3  Mã hóa DES

Việc thực hiện tiêu chuẩn này hỗ trợ SNMPv3 có thể hỗ trợ Chuỗi khối mật mã (CBC)/ Tiêu chuẩn mã hóa dữ liệu (DES) như định nghĩa trong IETF RFC 3414:2002, Điều 8.

GHI CHÚ: Đây là một sơ đồ mã hóa có tính lịch sử không còn được khuyến khích sử dụng do khả năng máy tính hiện đại mạnh sẽ giải được mã hóa.

7.5.2.4  Mã hóa AES

Việc thực hiện tiêu chuẩn này hỗ trợ SNMPv3 sẽ hỗ trợ chuẩn mã hóa nâng cao (AES) như định nghĩa trong IETF RFC 3826.

Mặc dù nhiều thiết bị hiện trường sẽ không nhất thiết yêu cầu trao đổi dữ liệu riêng cho các hoạt động bình thường, song tất cả các thiết bị phải sử dụng xác thực càng nhiều càng tốt và các khóa an toàn để xác thực và mã hóa nên được cập nhật định kỳ. Các bản cập nhật cho các khóa này chỉ được thực hiện trên cơ sở trao đổi dữ liệu riêng.

Khi tốc độ bộ xử lý máy tính tăng lên, các lược đồ mã hóa nên được cải thiện để cung cấp bảo vệ đầy đủ chống lại các cuộc tấn công tự động. Hiện nay AES là mã hóa khuyến nghị để bảo vệ khỏi các cuộc tấn công tự động.

7.5.3  Mô hình an toàn truyền tải

Việc thực hiện tiêu chuẩn này có thể hỗ trợ Mô hình An toàn Truyền tải (TSM) định nghĩa trong IETF RFC 5591.

7.6  Kiểm soát truy cập dựa trên chế độ hiển thị

Việc thực hiện tiêu chuẩn này phải tuân theo các quy tắc Kiểm soát truy cập dựa trên chế độ hiển thị được định nghĩa trong IETF RFC 3415 cho tất cả các giao thức và phiên bản giao thức được định nghĩa hoặc tham chiếu trong tiêu chuẩn này.

Đối với tất cả các thông điệp SNMPv1, hiển thị sẽ được xác định bằng cách sử dụng securityModel chế độ hiển thị “noAuthNoPriv”, contextEngineID mặc định và một contextName bằng với communityName có trong thông điệp.

Đối với tất cả các yêu cầu STMP, chế độ hiển thị sẽ được xác định như định nghĩa trong Điều 6.

7.7  Hoạt động giao thức

7.7.1  SNMPv1

Việc thực hiện tiêu chuẩn này yêu cầu hỗ trợ cho Xử lý thông điệp Phiên bản 1 (7.3.2) sẽ hỗ trợ các hoạt động giao thức được xác định trong IETF RFC 1157 cho các thông điệp phiên bản 1.

7.7.2  SNMPv2

Việc thực hiện tiêu chuẩn này yêu cầu hỗ trợ Xử lý thông điệp Phiên bản 2 (7.3.3) sẽ hỗ trợ các hoạt động giao thức định nghĩa trong IETF RFC 1905 cho các thông điệp phiên bản 2.

7.7.3  SNMPv3

Việc thực hiện tiêu chuẩn này yêu cầu hỗ trợ Mô hình Xử lý thông điệp Phiên bản 3 (7.3.4) sẽ hỗ trợ các hoạt động giao thức định nghĩa trong IETF RFC 3416.

7.7.4  STMP

Việc thực hiện tiêu chuẩn này yêu cầu hỗ trợ Xử lý thông điệp STMP (7.3.5) sẽ hỗ trợ các hoạt động giao thức định nghĩa trong 8.2.

7.7.5  Biến thể ID yêu cầu

Khi đưa ra các yêu cầu SNMP, thiết bị quản lý sẽ thay đổi giá trị của id yêu cầu.

GHI CHÚ: Một cách tiếp cận phổ biến là tăng id yêu cầu cho mỗi yêu cầu được đưa ra, nhưng điều này không phải là bắt buộc.

7.8  Ánh xạ vận tải

Thực thể SNMP nên sử dụng số cổng được gán đã biết được chỉ định bởi Cơ quan thẩm quyền cấp số Internet hoặc số cổng riêng.

CHÚ THÍCH 1: UDP và TCP sử dụng một tập hợp chung các số cổng đã biết áp dụng cho cả IPv4 và IPv6, số cổng đã biết cho SNMP là 161. Số cổng đã biết cho thông báo SNMP là 162

CHÚ THÍCH 2: Số cổng riêng là dải số trong phạm vi từ 49152 đến 65535.

7.8.1  UDP trên IPv4

Việc thực hiện tiêu chuẩn này sẽ hỗ trợ SNMP trên UDP qua ánh xạ vận tải IPv4 định nghĩa trong IETF RFC 3417: 2002, Điều 3. Nếu việc thực hiện hỗ trợ ánh xạ vận tải này, thì sẽ hỗ trợ nó cho tất cả các mô hình xử lý thông điệp được hỗ trợ.

CHÚ THÍCH 1: Đây là môi trường triển khai điển hình cho tiêu chuẩn này.

CHÚ THÍCH 2: RFC yêu cầu mã hóa BER và hỗ trợ các gói có ít nhất 484 octet.

7.8.2  UDP trên IPv6

Việc thực hiện tiêu chuẩn này có thể hỗ trợ SNMP trên UDP qua ánh xạ vận tải IPv6 định nghĩa trong các điều sau đây. Nếu việc thực hiện hỗ trợ việc ánh xạ vận tải này, thì sẽ hỗ trợ nó cho tất cả các mô hình xử lý thông điệp được hỗ trợ.

7.8.2.1  Tuần tự hóa

Mỗi thực thể của một thông điệp sẽ được tuần tự hóa (tức là được mã hóa) theo các quy tắc của BER bằng cách sử dụng thuật toán được chỉ định trong IETF RFC 3417: 2002, Điều 8. Thông điệp được mã hóa BER này sẽ được đặt vào một gói dữ liệu UDP duy nhất và được gửi bàng một gói tin IPv6.

7.8.2.2  Kích thước thông điệp

Việc thực hiện yêu cầu tuân thủ với ánh xạ vận tải này sẽ chấp nhận các thông điệp có kích thước lên đến 484 octet. Khuyến nghị rằng thực hiện chấp nhận các thông điệp có kích thước lên đến 1472 octet. Việc thực hiện với các giá trị lớn hơn được khuyến khích khi có thể.

7.8.3  TCP trên IPv4

Việc thực hiện tiêu chuẩn này có thể hỗ trợ SNMP trên TCP qua ánh xạ vận tải IPv4 định nghĩa trong IETF RFC 3430. Nếu việc thực hiện hỗ trợ ánh xạ vận tải này, thì sẽ hỗ trợ tất cả các mô hình xử lý thông điệp được hỗ trợ.

CHÚ THÍCH 1: Cho đến nay, môi trường triển khai này thướng được chọn như một phần của giải pháp tăng cường an toàn cho truyền thông SNMP. Tuy nhiên, SNMPv3 trên UDP dã được chứng minh là một giải pháp ưu việt do kích thước gói tin nhỏ và linh hoạt trong việc xử lý các lỗi truyền thông. Khi mạng gặp sự cố (ví dụ: mát gói trên 5%), kết nối TCP bắt đầu gặp sự cố nghiêm trọng do cần trao đổi xác nhận, trong khi đó sự đơn giản của gói tin UDP cho phép đạt hiệu năng tổng thể tốt hơn. Về vấn đề này, nếu môi trường triển khai chủ yếu là lưu lượng SNMP, thì hiệu năng tốt hơn trong khoảng thời gian hiệu năng mạng kém có thể tạo ra sự khác biệt đáng kể trong hoạt động mạng.

CHÚ THÍCH 2: SNMP trên TCP có thể cung cấp khả năng truyền dữ liệu kích thước lớn hiệu quả hơn SNMP trên UDP.

7.8.4  TCP trên IPv6

Việc thực hiện tiêu chuẩn này có thể hỗ trợ SNMP trên TCP qua ánh xạ vận tải IPv6 định nghĩa trong IETF RFC 3430. Nếu việc thực hiện hỗ trợ ánh xạ vận tải này, thì sẽ hỗ trợ tất cả các mô hình xử lý thông điệp được hỗ trợ.

7.8.5  Mô hình truyền tải an toàn

Việc thực hiện hỗ trợ TSM (7.5.3) sẽ hỗ trợ An toàn tầng truyền tải (TLS) như định nghĩa trong IETF RFC 6353.

7.8.5.1 Hỗ trợ TLS

Việc thực hiện hỗ trợ TSM có thể hỗ trợ Giao thức An toàn tầng truyền tải (TLS) Phiên bản 1.2 như định nghĩa trong IETF RFC 5246.

7.8.5.2  Hỗ trợ DTLS

Việc thực hiện hỗ trợ TSM có thể hỗ trợ An toàn tầng truyền tải dữ liệu (DTLS) như định nghĩa trong IETF RFC 4347.

7.9  Cơ sở thông tin quản lý (MIB)

7.9.1  Đại lý MIB

Một đại lý yêu cầu tuân thủ với tiêu chuẩn này phải hỗ trợ các MIB sau:

a) SNMP-FRAMEWORK-MIB, như định nghĩa trong IETF RFC 3411:2002, Điều 5;

b) SNMP-MPD-MIB, như định nghĩa trong IETF RFC 3412:2002, Điều 5;

c) SNMP-USER-BASED-SM-MIB, như định nghĩa trong IETF RFC 3414:2002, Điều 5;

d) SNMP-USM-AES-MIB, như định nghĩa trong IETF RFC 3826:2004, Điều 2;

e) SNMP-VIEW-BASED-ACM-MIB, như định nghĩa trong IETF RFC 3415:2002, Điều 4;

f) SNMPV2-MIB, như định nghĩa trong IETF RFC 3418:2002, Điều 2.

7.9.2  MIB của bộ khởi tạo thông báo

Một đại lý yêu cầu hỗ trợ cho ứng dụng của bộ khởi tạo thông báo sẽ hỗ trợ các MIB sau:

a) SNMP-TARGET-MIB, như định nghĩa trong IETF RFC 3413:2002, 4.1;

b) SNMP-NOTIFICATION-MIB, như định nghĩa trong IETF RFC 3413:2002, 4.2.

7.9.3  MIB của bộ chuyển tiếp proxy

Một đại lý yêu cầu hỗ trợ cho ứng dụng chuyển tiếp proxy sẽ hỗ trợ các MIB sau:

a) SNMP-TARGET-MIB, như định nghĩa trong IETF RFC 3413:2002, 4.1;

b) SNMP-PROXY-MIB, như định nghĩa trong IETF RFC 3413:2002, 4.3.

7.9.4  STMP MIB

Một thực thể yêu cầu hỗ trợ cho STMP sẽ hỗ trợ MIB sau:

a) STMP-MIB, như được định nghĩa trong 6.4.

7.9.5  Mô hình an toàn truyền tải MIB

Một thực thể yêu cầu hỗ trợ cho mô hình an toàn truyền tải sẽ hỗ trợ MIB sau:

a) SNMP-TSM-MIB, như định nghĩa trong IETF RFC 5591:2009, Điều 7.

7.9.6  Dữ liệu được hỗ trợ khác

Tất cả các đối tượng dữ liệu mà đại lý SNMP có thể truy cập phải được xác định trong một thiết bị MIB theo các quy tắc định nghĩa trong IETF RFC 2578.

7.10  Khả năng tương tác

Tầng dưới tiếp theo của ngăn xếp truyền thông sẽ sử dụng một số cổng duy nhất để xác định mọi gói dữ liệu bằng cách sử dụng hồ sơ này để cung cấp khả năng tương tác giữa các hồ sơ ứng dụng khác nhau.

8  Giao thức quản lý truyền tải đơn giản (STMP)

8.1  Yêu cầu chung

Điều này cung cấp định nghĩa chính tắc về Giao thức quản lý truyền tải đơn giản (STMP), một tính năng tùy chọn của tiêu chuẩn này. Giải thích mô tả kỹ hơn về giao thức được cung cấp trong Phụ lục D. Mặt khác, các mã hóa mẫu được cung cấp trong Phụ lục E.

STMP là một phần mở rộng của SNMP cung cấp khả năng trao đổi dữ liệu hiệu quả theo byte, nhỏ gọn để sử dụng ở những nơi băng thông vật lý bị hạn chế. Giao thức này cho phép, ví dụ, thăm dò ý kiến theo mỗi giây của bộ điều khiển tín hiệu giao thông qua các đường truyền tốc độ thấp, nhiều lỗi mất gói và nối tiếp. Nó sử dụng SNMP đề xác định “các đối tượng động” tại thời điểm chạy. Mỗi đối tượng động là một chuỗi các đối tượng thành phần được xác định (tức là một đối tượng được xác định trong MIB). Sau khi được xác định, một thao tác GET trên một đối tượng động sẽ truy xuất toàn bộ chuỗi các đối tượng thành phần không cần thủ tục bổ sung thường được liên kết với SNMP. Tương tự như vậy, một SET có thể cấu hình từng điều này theo cách tương tự.

Mỗi đại lý STMP hỗ trợ 13 đối tượng động. Mỗi đối tượng động có thể chứa tối đa 255 đối tượng thành phần. Số lượng thực tế của các đối tượng thành phần được sử dụng sẽ được xác định bởi thiết bị quản lý cấu hình đối tượng động. Vì chỉ có một số lượng nhỏ các đối tượng động được xác định bởi giao thức, bộ nhận dạng đối tượng động chỉ yêu cầu bốn bit thay vì nhiều byte mà SNMP yêu cầu để xác định từng đối tượng thành phần. Điều này thúc đẩy hiệu quả cao hơn trong bất kỳ môi trường nào.

Tuy nhiên, lợi ích của STMP đi cùng một sự đánh đổi về chi phí. Quan trọng nhất là độ phức tạp của phần mềm đại lý bị tăng lên đáng kể. Ngoài ra, thêm thủ tục bổ sung trong việc định cấu hình các đối tượng động. Kỳ vọng là các bộ quản lý sẽ cấu hình các đối tượng động khi khởi tạo thiết bị và hiếm khi thay đổi chúng. Do đó, lợi ích thực sự của bản chất động của các đối tượng này là một cơ sở mã duy nhất có thể được triển khai trong nhiều môi trường nơi các bộ quản lý khác nhau cấu hình các đối tượng động khác nhau. STMP tuân theo kiến trúc chung của SNMPv3 như được định nghĩa trong IETF RFC 3411 với các đặc tả kỹ thuật sau cho các thành phần chính của kiến trúc này:

a) Mỗi thực hiện STMP sẽ hỗ trợ các quy tắc xử lý và gửi thông điệp như định nghĩa trong 6.2;

b) Mỗi thực hiện STMP sẽ hỗ trợ các yêu cầu ứng dụng xác định trong 7.4.1;

c) Mỗi thực hiện STMP sẽ hỗ trợ các thông điệp STMP không an toàn. Những thông điệp như vậy sẽ sử dụng ngầm noAuthNoPriv securityLevel, như định nghĩa bởi IETF RFC 3411;

d) Mỗi thực hiện STMP sẽ hỗ trợ các thông điệp STMP an toàn (tức là secure-pdu). Những bản tin này phải phù hợp với 8.2.3.2.1;

e) Mỗi thực hiện STMP sẽ hỗ trợ kiểm soát truy cập dựa trên chế độ hiển thị như định nghĩa trong IETF RFC 3415 sử dụng ngầm định contextEngineID bằng mặc định contextEngineID và một ngầm định contextName bằng giá trị của dynObjectOwner cho đối tượng động mà thao tác đang được thực hiện trên đó;

f) Mỗi thực hiện STMP sẽ hỗ trợ các hoạt động giao thức như định nghĩa trong 6.2;

g) Mỗi thực hiện STMP sẽ hỗ trợ các ánh xạ vận tải như định nghĩa trong 6.3;

h) Mỗi thực hiện STMP sẽ hỗ trợ các đối tượng quản lý như định nghĩa trong 6.4.

Đối với các mục đích của tiêu chuẩn này và diễn dịch các RFC, STMP sẽ được coi là một phiên bản khác của SNMP.

8.2  Hoạt động gửi thông điệp, xử lý và giao thức

8.2.1  Thiết bị điều phối

Một thực thể STMP sẽ tuân theo các yếu tố điều phối giống như của các thủ tục định nghĩa trong IETF RFC 3412:2002, Điều 4 và IETF RFC 5590, ngoại trừ tất cả các tham chiếu đến các đối tượng “snmp” (tức là các đối tượng được xác định trong IETF RFC 3418) trong IETF RFC 3412:2002, Điều 4 sẽ được hiểu tương đương với các đối tượng “stmp” được xác định trong 6.4.

8.2.2  Các thành phần thông điệp của thủ tục

Điều này mô tả các thủ tục được tuân theo bởi một phương tiện STMP khi tạo và xử lý các thông điệp STMP.

Các thành phần của thủ tục cho các thông điệp STMP giống với các thành phần của thủ tục được định nghĩa cho SNMPv3 như định nghĩa trong IETF RFC 3412:2002, Điều 7 với các ngoại lệ sau.

8.2.2.1  prepareOutgoingMessage (Chuẩn bị bản tin đầu ra)

Các quy tắc bổ sung sau đây sẽ áp dụng cho nguyên gốc dịch vụ prepareOutgoingMessage:

a) Nếu pduType nằm trong lớp phản hồi, một errorIndication (đặc trưng thực hiện) sẽ được gửi trả lại ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

b) Nếu securityLevel là “noAuthNoPriv”, bản tin sẽ chỉ chứa pdu, nếu không, bản tin sẽ chứa secure-pdu;

c) Nếu danh sách các đối tượng trong cấu trúc PDU không tham chiếu chính xác đến một đối tượng, errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

d) Nếu đối tượng được tham chiếu trong cấu trúc PDU không phải là dynObjectValue với chỉ số giữa 1 và 13, errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

e) Nếu contextEngine không bằng contextEngine mặc định, errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

f) Nếu contextName không bằng giá trị của dynObjectOwner có cùng chỉ số với chỉ số trong dynObjectValue, errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

g) Nếu giá trị của expectResponse là “true” và giá trị của pduType là setNoReplyDynObj, errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

h) Nếu giá trị của expectResponse là “false” và giá trị của pduType là getDynObj, setDynObj, hoặc getNextDynObj, errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

i) Thông tin được lưu trong bộ nhớ cache cho các PDU lớp đã được xác nhận sẽ bao gồm pduType.

8.2.2.2  prepareResponseMessage (Chuẩn bị thông điệp phản hồi)

Các quy tắc bổ sung sau đây sẽ áp dụng cho nguyên gốc dịch vụ prepareResponseMessage:

a) Nếu pduType không nằm trong lớp phản hồi, một errorIndication (đặc trưng thực hiện) sẽ được gửi trở lại ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

b) Nếu securityLevel là “noAuthNoPriv”, bản tin sẽ chỉ chứa pdu, nếu không, bản tin sẽ chứa secure-pdu;

c) Nếu danh sách các đối tượng trong cấu trúc PDU không tham chiếu chính xác đến một đối tượng, một errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

d) Nếu đối tượng được tham chiếu trong cấu trúc PDU không phải là dynObjectValue với chỉ số từ 1 đến 13, một errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

e) Nếu contextEngine không bằng contextEngine mặc định, một errorIndication (đặc trưng thực hiện) sẽ được trả về ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp;

f) Nếu contextName không bằng giá trị của dynObjectOwner có cùng chỉ số chứa trong dynObjectValue, một errorIndication (đặc trưng thực hiện) sẽ được trả về vào ứng dụng gọi. Không có quá trình xử lý nào được thực hiện tiếp.

8.2.2.3  prepareDataElements (Chuẩn bị thành phần dữ liệu)

Các quy tắc bổ sung sau đây sẽ áp dụng cho nguyên gốc dịch vụ prepareDataElements:

a) Danh sách các đối tượng trong cấu trúc PDU phải được thiết lập để tham chiếu đến đối tượng động được chỉ định;

b) contextEngine sẽ được đặt thành contextEngine mặc định;

c) contextName sẽ được đặt thành giá trị của dynObjectOwner với cùng chỉ số với đối tượng động được chỉ định.

8.2.3  Định nghĩa trường thông điệp STMP

8.2.3.1  Thông điệp STMP

Thông điệp STMP sẽ là một secure-pdu như định nghĩa trong 8.2.3.2 hoặc pdu như định nghĩa trong 8.2.3.3.

8.2.3.2  PDU an toàn

8.2.3.2.1  Cờ

Trường cờ của cấu trúc Secure-Pdu sẽ được xác định như sau:

a) Bit vị trí cao nhất sẽ chỉ ra giá trị của cờ báo cáo reportableFlag như được định nghĩa trong IETF RFC 3412;

b) Bit vị trí cao nhất tiếp theo sẽ chỉ ra giá trị của privFlag như được định nghĩa trong IETF RFC 3412;

c) Bit vị trí cao nhất tiếp theo sẽ chỉ ra giá trị của authFlag như được định nghĩa trong IETF RFC 3412;

d) Năm bit vị trí thấp nhất sẽ chỉ ra msgSecurityModel là INTEGER (0..31). Các các giá trị không (0) đến 15 sẽ được xác định bởi Tổ chức thẩm quyền cấp phát số Internet trong không gian số SNMP. Ý nghĩa của các giá trị từ 16 đến 31 dành cho đặc trưng thực hiện.

CHÚ THÍCH 1: Khi sử dụng USM trên IETF RFC 3414, các tham số an toàn OCTET STRING sẽ chứa thông tin được mã hóa sử dụng BER. Điều này cho phép sử dụng lại mã được thiết kế để sử dụng với SNMPv3.

CHÚ THÍCH 2: Giá trị được gán cho mô hình an toàn dựa trên người dùng là 3.

8.2.3.2.2  Các tham số an toàn

Trường tham số an toàn phải chứa thông tin an toàn cho mô hình an toàn đã chọn sử dụng các quy tắc mã hóa được xác định bởi mô hình an toàn. Kết quả mã hóa sẽ được bao bọc vào giá trị của trường securityParameters được biểu diễn dưới dạng OCTET STRING.

CHÚ THÍCH: Trường STMPMessage, bao gồm trường securityParameters OCTET STRING được mã hóa theo quy tắc lập ánh xạ vận tải. Khi triển khai các ánh xạ vận tải định nghĩa trong điều 6.3, có nghĩa là các tham số mã hóa BER được bao bọc trong một thông điệp được mã hóa OER. Một ví dụ về điều này là mã hóa được cung cấp trong Phụ lục E.

8.2.3.2.3  Dữ liệu PDU

STMP-Pdu sẽ được mã hóa theo các quy tắc của OER để có được mã hóa thô. Nếu trường securityParameters chỉ thị không mật mã hóa, trường pduData sẽ chứa mã hóa thô dưới dạng OCTET STRING. Nếu không, trường pduData sẽ chứa giá trị mật mã hóa của mã hóa thô dưới dạng OCTET STRING.

8.2.3.3  STMP PDU

Mỗi thông điệp đều chứa câu lệnh STMP-Pdu CHOICE xác định

- pduType và

- đối tượng động mà bản tin liên quan.

CHÚ THÍCH 1: STMPMessage được định nghĩa là CHOICE giữa pdu là STMP-Pdu hoặc secure-pdu chứa một STMP-Pdu được mật mã hóa làm trường pduData.

CHÚ THÍCH 2: STMPMessage cho biết cả số đối tượng động pduType trong một CHOICE ASN.1 duy nhất để cung cấp mã hóa hiệu quả. Một khi các quy tắc mã hóa được áp dụng, các tùy chọn khác nhau trong kết quả câu lệnh CHOICE là bốn bit bậc cao mã hóa pduType trong khi bốn bit bậc thấp mã hóa số đối tượng động. Mặc dù cấu trúc ASN.1 có vẻ dài dòng, nhưng mã hóa thực tế sẽ trở thành khá hiệu quả.

Giao thức xác định pduTypes được hiển thị bên dưới cùng với “Type” cho biết giá trị được mã hóa của pduType trong bốn bit trọng số cao khi sử dụng OER.

a) getDynObj (Kiểu 0x8): Sẽ là một lớp đọc và lớp được xác nhận pduType biểu diễn một yêu cầu lấy (get) đối tượng dynObjectValue được chỉ định như định nghĩa trong 8.2.4.1.

b) setDynObj (Kiểu 0x9): Sẽ là một lớp ghi và lớp được xác nhận pduType biểu diễn một yêu cầu thiết lập (set) đối tượng dynObjectValue được chỉ định như định nghĩa trong 8.2.4.2 .

c) setNoReplyDynObj (Kiểu 0xA): Sẽ là một lớp ghi lớp và chưa được xác nhận pduType biểu diễn một yêu cầu thiết lập (set) cho đối tượng dynObjectValue được chỉ định mà không có bất kỳ thông điệp phản hồi nào. về mặt ngữ nghĩa tương đương với setDynObj pduType, nhưng sẽ không tạo thông điệp phản hồi từ đại lý như định nghĩa trong 8.2.4.2.

d) getNextDynObj (Kiểu OxB): Sẽ là một lớp đọc và lớp đã xác nhận pduType biểu diễn một yêu cầu lấy (get) cho đối tượng dynObjectValue “hoạt động” và được sắp xếp theo thứ tự từ vựng tiếp theo được định nghĩa trong 8.2.4.3 .

e) getRespDynObj (Loại OxC): Sẽ là một lớp phản hồi và lớp chưa được xác nhận pduType biểu diễn một phản hồi nhận (get) cho đối tượng dynObjectValue được chỉ định như được định nghĩa trong điều 8.2.4.1 và 8.2.4.3.

f) setRespDynObj (Kiểu OxD): Sẽ là một lớp phản hồi và lớp chưa được xác nhận pduType biểu diễn một phản hồi thiết lập (set) cho đối tượng dynObjectValue được chỉ định như định nghĩa trong điều 8.2.4.2.

g) errorRespDynObj (Loại OxE): Sẽ là một lớp phản hồi và lớp chưa được xác nhận pduType biểu diễn phản hồi lỗi cho đối tượng dynObjectValue được chỉ định như định nghĩa trong điều 8.2.4.1 đến 8.2.4.3.

CHÚ THÍCH: Loại 0xF được sử dụng để chỉ một thông điệp STMP an toàn và bản thân nó không phải là một pduType.

8.2.3.4  DynamicObject-PDU

Định nghĩa của cấu trúc DynamicObject-PDU sẽ được xác định tại thời điểm chạy dựa trên cấu hình hiện tại của đối tượng động được chỉ định. Cụ thể, định nghĩa DynamicObject-PDU đối với một đối tượng động cụ thể sẽ là một ASN.1 SEQUENCE của các đối tượng được tham chiếu bởi dynObjectVariables được định nghĩa cho đối tượng động cụ thể, theo thứ tự các giá trị chỉ số của chúng và kết thúc tại (và loại trừ) dynObjectVariable đầu tiên được đặt thành null (tức là 0.0).

VÍ DỤ: Nếu biến đầu tiên của một đối tượng động được xác định để tham chiếu đến một đối tượng của SYNTAX INTEGER (0..255), biến thứ hai của cùng một đối tượng động được xác định để tham chiếu đến một đối tượng của SYNTAX OCTET STRING (SIZE (0..127)) và biến thứ ba của cùng một đối tượng động được xác định để tham chiếu nút null; trường DynamicObject-PDU sẽ được định nghĩa là

8.2.3.5  ErrorInformation-PDU

Các trường trạng thái lỗi error-status và chỉ số lỗi error-index sẽ chỉ các giá trị được định nghĩa trong ISO/IEC 9834-1: 2012, 8.2.4.

8.2.4  Các thành phần PDU của thủ tục

8.2.4.1  GetDynObjX

Mỗi loại trong số 13 loại GetDynObjX đại diện cho một yêu cầu lấy (get) đối với đối tượng động được chỉ định (tức là GetDynObjl biểu diễn cho một yêu cầu lấy đối với đối tượng động 1). Một PDU GetDynObjX được tạo và được truyền theo yêu cầu của một ứng dụng. Khi nhận được PDU GetDynObjX, thực thể STMP nhận sẽ xử lý yêu cầu như sau:

a) Nếu PDU chứa bất kỳ thông tin nào, thực thể sẽ tăng giá trị của stmpInASNParseErrs. Thông điệp sẽ bị loại bỏ và quá trình xử lý sẽ hoàn tất;

b) Nếu không, nếu dynObjectStatus của đối tượng động được chỉ định không “hoạt động”, thực thể sẽ tạo ra một ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “NoSuchName” và trường errorIndex sẽ được đặt thành không (0);

c) Nếu không, nếu đối tượng động chứa một tham chiếu đến một đối tượng trong một trong các dynObjectVariable của nó mà các giá trị không có trong chế độ hiển thị MIB hiện tại (tức là hiện không được khởi tạo, không hiển thị, V.V.), thực thể sẽ tạo ra ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “noSuchName” và trường errorIndex sẽ được đặt thành chỉ số của dynObjectVariable đầu tiên của đối tượng động không hợp lệ;

d) Nếu không, nếu đối tượng động không thể được truy xuất vì bất kỳ lý do nào khác, thực thể sẽ tạo ra một ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “genErr” và trường errorIndex sẽ được đặt thành chỉ số của dynObjectVariable gây ra vấn đề lỗi nếu biết, và đặt là không (0) trong trường hợp ngược lại;

e) Nếu không, thực thể sẽ tạo ra một DynamicObject-PDU cho đối tượng động được yêu cầu chứa giá trị của dynObjectValue.X;

f) PDU phản hồi sau đó được đóng gói thành một thông điệp. Nếu kích thước của thông điệp kết quả nhỏ hơn hoặc bằng cả giới hạn cục bộ và kích thước thông điệp tối đa của bộ khởi tạo, nó được truyền tới bộ khởi tạo GetNextDynObjX;

g) Nếu không, một ErrorInformation-PDU được tạo cho đối tượng động chủ thể. Giá trị của trường errorStatus sẽ là “tooBig” và giá trị của trường error-index sẽ là số không. ErrorInformation-PDU này sau đó được đóng gói thành một thông điệp và truyền đến thiết bị khởi tạo GetDynObjX.

8.2.4.2  SetDynObjX và SetNoReplyDynObjX

Mỗi loại trong số 13 loại SetDynObjX và 13 loại SetNoReplyDynObjX biểu diễn một yêu cầu thiết lập cho đối tượng động được chỉ định. Các PDU này được tạo và truyền theo yêu cầu của một ứng dụng. Khi nhận được một PDU như vậy, thực thể tiếp nhận STMP sẽ xử lý yêu cầu như sau:

a) Nếu dynObjectStatus của đối tượng động được chỉ định không “hoạt động”, thực thể sẽ tạo ra một ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “noSuchName” và trường errorIndex sẽ được đặt thành không (0);

b) Nếu không, nếu đối tượng động chứa một tham chiếu đến đối tượng trong một trong các giá trị dynObjectVariable của nó mà các giá trị không có trong chế độ hiển thị MIB hiện tại (tức là hiện không được khởi tạo, không hiển thị, v.v.), thực thể sẽ tạo ra ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “noSuchName” và trường errorIndex sẽ được đặt thành chỉ số của dynObjectVariable đầu tiên của đối tượng động không hợp lệ;

c) Nếu không, nếu đối tượng động chứa tham chiếu đến một đối tượng không có sẵn cho việc thiết lập hoạt động với chế độ hiển thị MIB hiện tại, thực thể sẽ tạo ra ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “readOnly” và trường errorIndex sẽ được đặt thành chỉ số của dynObjectVariable không thể thiết lập được;

d) Nếu không, nếu có bất kỳ lỗi phân tích cú pháp nào xảy ra khi giải mã nội dung của DynamicObject- PDU, thực thể sẽ tăng giá trị của stmpInASNParseErrs và sẽ tạo ra một ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “badValue” và trường errorIndex sẽ chỉ ra chỉ số của dynObjectVariable nơi phân tích cú pháp không thành công;

e) Nếu không, nếu bất kỳ đối tượng nào được tham chiếu bởi đối tượng động không thể được thay đối với bất kỳ lý do nào khác thì thực thể sẽ tạo ra ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “genErr” và trường errorIndex sẽ chỉ ra chỉ số của dynObjectVariable gây ra vấn đề lỗi;

f) Nếu không, đối với mỗi đối tượng được tham chiếu trong yêu cầu đối tượng động, thực thể sẽ tạo đối tượng, nếu cần, và sẽ gán giá trị được yêu cầu cho nó. Mỗi phép gán trong số này xảy ra như thể đồng thời, đối với tất cả các phép gán khác được chỉ định trong cùng một yêu cầu:

1) Nếu bất kỳ phép gán nào không thành công (ngay cả sau tất cả các lần xác nhận trước đó), thì thực thể sẽ hoàn tác tất cả các phép gán khác và tạo ErrorInformation-PDU. Trường errorStatus sẽ được đặt thành “commitFailed” và trường errorIndex sẽ được đặt thành chỉ số của dynObjectVariable không thể được thiết lập;

2) Nếu không thể hoàn tác tất cả các phép gán, thì thực thể sẽ tạo ra một ErrorInformation- PDU. Trường errorStatus sẽ được đặt thành “undoFailed” và trường errorIndex sẽ được đặt thành 0;

CHÚ THÍCH: Khuyến khích thực hiện tất cả các biện pháp có thể để tránh sử dụng “commitFailed” hoặc “undoFailed”. Hai mã trạng thái lỗi này không được coi là cấp quyền để giải quyết dễ dàng cho việc thực hiện.

3) Nếu không, thực thể sẽ tạo ra một PDU SetRespDynObjX làm PDU phản hồi;

g) Nếu yêu cầu là SetNoReplyDynObjX PDU, quá trình xử lý sẽ hoàn tất và không gửi phản hồi nào đi;

h) PDU phản hồi sau đó được đóng gói thành một bản tin và được truyền đến bộ khởi tạo SetDynObjX PDU.

8.2.4.3  GetNextDynObjX

Mỗi loại trong số 13 loại GetNextDynObjX biểu diễn một yêu cầu lấy đối với đối tượng động “hoạt động” tiếp theo. GetNextDynObjX PDU được tạo và truyền theo yêu cầu của ứng dụng. Khi nhận được một GetNextDynObjX PDU, thực thể STMP nhận xử lý yêu cầu như sau:

a) Nếu PDU chứa bất kỳ thông tin nào, thực thể sẽ tăng giá trị của stmpInASNParseErrs. Thông điệp sẽ bị loại bỏ và quá trình xử lý sẽ hoàn tất;

b) Đối tượng động được định vị là đối tượng kế tiếp từ điển tiếp theo của đối tượng động được chỉ định mà dynObjectStatus có giá trị là “active”;

c) Nếu không có kế tiếp từ điển là một đối tượng động có trạng thái “active”, thì thực thể sẽ tạo ra ErrorInformation-PDU. Đối tượng động phản hồi sẽ là đối tượng động có trong yêu cầu. Trường errorStatus sẽ được đặt thành “noSuchName” và trường errorIndex sẽ được đặt thành không (0);

d) Nếu không, nếu đối tượng động kế tiếp từ điển có chứa tham chiếu đến một đối tượng là một trong các giá trị dynObjectVariable của nó không có trong chế độ hiển thị MIB hiện tại (tức là không hiện ngay lập tức, không hiển thị, v.v.), thực thể sẽ tạo ra ErrorInformation-PDU. Phản hồi đối tượng động sẽ là đối tượng động kế tiếp từ điển. Trường errorStatus sẽ được đặt thành “noSuchName” và trường errorIndex sẽ được đặt thành chỉ số của dynObjectVariable của đối tượng động không hợp lệ;

e) Nếu không, nếu đối tượng động kế tiếp từ điển không thể được truy xuất vì bất kỳ lý do nào khác, thực thể sẽ tạo ra ErrorInformation-PDU. Đối tượng động phản hồi sẽ là đối tượng động kế tiếp từ điển. Trường errorStatus sẽ được đặt thành “genErr” và trường errorIndex sẽ được đặt thành chỉ số của dynObjectVariable gây ra vấn đề lỗi nếu được biết, và bằng không (0) trong trường hợp ngược lại;

f) Nếu không, thực thể sẽ tạo ra một DynamicObject-PDU chứa giá trị dynObjectValue cho đối tượng động kế tiếp từ điển;

g) PDU phản hồi sau đó được đóng gói thành một bản tin. Nếu kích thước của thông điệp kết quả nhỏ hơn hoặc bằng giới hạn cục bộ và kích thước thông điệp tối đa của bộ khởi tạo, nó được truyền tới bộ khởi tạo GetNextDynObjX;

h) Nếu không, một ErrorRespDynObjX được tạo cho đối tượng động chủ thể. Giá trị của trường errorStatus sẽ là “tooBig” và giá trị của trường error-index sẽ bằng 0. ErrorRespDynObj sau đó được đóng gói thành một bản tin và được truyền đến bộ khởi tạo GetNextDynObjX.

8.2.4.4  GetRespDynObjX, SetRespDynObjX và ErrorRespDynObjX

Mỗi loại trong số 13 loại GetRespDynObjX và 13 loại SetRespDynObjX biểu diễn một phản hồi cho một đối tượng động với chỉ số đối tượng động được chỉ định. Các PDU này được tạo bởi một thực thể STMP theo các quy tắc được xác định ở trong tiêu chuẩn này. Khi nhận được PDU như vậy, thực thể nhận STMP đưa ra nội dung của nó cho ứng dụng đã tạo ra PDU yêu cầu gần đây nhất cho đối tượng động được chỉ định.

8.3  Ánh xạ vận tải

8.3.1  Yêu cầu chung

Các quy tắc sau đây sẽ áp dụng cho tất cả các ánh xạ vận tải STMP được xác định trong tiêu chuẩn này.

8.3.1.1  Tuần tự hóa

Mỗi trường hợp của thông điệp STMP sẽ được tuần tự hóa (tức là được mã hóa) theo các quy tắc của OER.

CHÚ THÍCH: Khi sử dụng USM, trường securityParameters là một hỗn hợp các kiểu mã hóa. IETF RFC 3414 định nghĩa các tham số dưới dạng ASN.1 SEQUENCE được mã hóa bằng BER. Kết quả mã hóa BER sau đó được nhúng vào STMP dưới dạng OCTET STRING. Trình tự đóng gói sau đó được mã hóa theo các quy tắc của điều này dựa trên OER. Phụ lục E cung cấp ví dụ về mã hóa này.

8.3.1.2  Số cổng

Thực thể STMP nên sử dụng số cổng đã biết được chỉ định như được gán bởi Tổ chức thẩm quyền cấp phát số Internet (IANA) hoặc số cổng riêng.

CHÚ THÍCH 1: UDP và TCP sử dụng một tập hợp chung các số cổng đã biết áp dụng cho cả IPv4 và IPv6. Các số cổng đã biết cho STMP là 501.

CHÚ THÍCH 2: Số cổng riêng trải trong phạm vi từ 49152 đến 65535.

8.3.2  UDP trên IPv4

Việc thực hiện tiêu chuẩn này có thể hỗ trợ STMP trên nền UDP của IPv4. Nếu việc thực hiện hỗ trợ ánh xạ vận tải này, nó sẽ hỗ trợ nó cho tất cả các mô hình xử lý thông điệp được hỗ trợ.

CHÚ THÍCH: Đây là môi trường triển khai được tiêu chuẩn hóa quốc tế phổ biến nhất cho giao thức này. Tuy nhiên, nhiều triển khai dựa trên các tiêu chuẩn quốc gia không dựa trên IP.

8.3.2.1  Đóng gói

Việc thực hiện yêu cầu phù hợp với ánh xạ vận tải này phải đặt thông điệp mã hóa OER (xem 8.3.1.1) vào gói dữ liệu UDP đơn và gửi nó bằng cách sử dụng gói IPv4 đơn.

8.3.2.2  Kích thước bản tin

Việc thực hiện yêu cầu tuân thủ với ánh xạ vận tải này sẽ chấp nhận các thông điệp có kích thước lên đến và bao gồm 484 octet. Khuyến nghị rằng việc thực hiện chấp nhận các thông điệp có kích thước lên đến 1472 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

Một đại lý yêu cầu tuân thủ với ánh xạ vận tải này sẽ có thể tạo ra các thông điệp phản hồi có kích thước lên đến và bao gồm 484 octet. Khuyến nghị rằng một đại lý có thể tạo các thông điệp phản hồi có kích thước lên đến 1472 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

8.3.3  UDP trên IPv6

Việc thực hiện tiêu chuẩn này có thể hỗ trợ STMP trên UDP của IPv6. Nếu một thực hiện hỗ trợ ánh xạ vận tải này, nó sẽ hỗ trợ nó cho tất cả các mô hình xử lý thông điệp được hỗ trợ.

8.3.3.1  Đóng gói

Việc thực hiện yêu cầu tuân thủ với ánh xạ vận tải này sẽ đặt thông điệp mã hóa OER (xem 8.3.1.1) vào một gói dữ liệu UDP duy nhất và gửi nó bằng một gói IPv6.

8.3.3.2  Kích thước bản tin

Một thực hiện yêu cầu tuân thủ với ánh xạ vận tải này sẽ chấp nhận các thông điệp có kích thước lên đến và bao gồm 484 octet. Khuyến nghị rằng việc thực hiện chấp nhận các thông điệp có kích thước lên đến 1 472 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

Một đại lý yêu cầu tuân thủ với ánh xạ vận tải này sẽ có thể tạo ra các thông điệp phản hồi có kích thước lên đến và bao gồm 484 octet. Khuyến nghị rằng một đại lý có thể tạo các thông điệp phản hồi có kích thước lên đến 1 472 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

8.3.4  TCP trên IPv4

Việc thực hiện tiêu chuẩn này có thể hỗ trợ STMP sử dụng TCP trên nền IPv4. Nếu việc thực hiện hỗ trợ ánh xạ vận tải này, nó sẽ hỗ trợ nó cho tất cả các mô hình xử lý thông điệp được hỗ trợ.

CHÚ THÍCH 1: Cho đến nay, môi trường triển khai này thường được chọn làm một phần của giải pháp để tăng an toàn cho truyền thông SNMP. Tuy nhiên, SNMPv3 trên UDP đã được chứng minh là một giải pháp vượt trội với kích thước gói nhỏ và tính linh hoạt trong việc xử lý các lỗi truyền thông. Khi mạng có sự cố (ví dụ: tỷ lệ mất gói trên 5%), kết nối TCP bắt đầu gặp sự cố nghiêm trọng do cần trao đổi các xác minh, trong khi sự đơn giản truyền dẫn dựa trên UDP cho phép hiệu năng tổng thể tốt hơn. Về vấn đề này, nếu môi trường triển khai chủ yếu là lưu lượng SNMP, thì hiệu năng truyền thông tốt hơn trong một điều kiện mạng kém có thể tạo ra sự khác biệt đáng kể trong hoạt động của mạng.

CHÚ THÍCH 2: SNMP trên TCP có thể cung cấp khả năng truyền dữ liệu kích thước lớn hiệu quả hơn SNMP trên UDP.

8.3.4.1  Đóng gói

Việc thực hiện yêu cầu tuân thủ với ánh xạ vận tải này sẽ gửi thông điệp được mã hóa OER (xem 8.3.1.1) qua kết nối TCP.

Phương tiện STMP sẽ không xen kẽ các thông điệp STMP hoặc SNMP trong luồng byte TCP. Toàn bộ byte của một thông điệp STMP sẽ được gửi trước bất kỳ byte nào của một bản tin STMP hoặc SNMP khác.

8.3.4.2  Kích thước bản tin

Việc thực hiện yêu cầu tuân thủ với ánh xạ vận tải này sẽ chấp nhận các thông điệp có kích thước lên đến và bao gồm 8192 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

Một đại lý yêu cầu tuân thủ với ánh xạ vận tải này sẽ có thể tạo ra các tin nhắn phản hồi có kích thước lên đến và bao gồm 8 192 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

8.3.5  TCP trên IPv6

Việc thực hiện tiêu chuẩn này có thể hỗ trợ STMP trên TCP trên IPv6. Nếu thực hiện hỗ trợ ánh xạ vận tải này, nó sẽ hỗ trợ nó cho tất cả các mô hình xử lý thông điệp được hỗ trợ.

8.3.5.1  Đóng gói

Việc thực hiện tuân thủ với ánh xạ vận tải này sẽ gửi thông điệp được mã hóa OER (xem 8.3.1.1) trên kết nối TCP.

Phương tiện STMP sẽ không xen kẽ các thông điệp STMP hoặc SNMP trong luồng byte TCP. Toàn bộ byte của một thông điệp STMP sẽ được gửi trước bất kỳ byte nào của một thông điệp STMP hoặc SNMP khác.

8.3.5.2  Kích thước bản tin

Việc thực hiện yêu cầu tuân thủ với ánh xạ vận tải này sẽ chấp nhận các thông điệp có kích thước lên đến và bao gồm 8 192 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

Một đại lý yêu cầu tuân thủ với ánh xạ vận tải này sẽ có thể tạo ra các thông điệp phản hồi có kích thước lên đến và bao gồm 8 192 octet. Việc thực hiện các giá trị lớn hơn được khuyến khích, khi có thể.

9  Hiệu năng

9.1  Tổng quan

Việc sử dụng SNMP để truy xuất các đối tượng bao hàm khoảng thời gian phản hồi cần thiết để thiết bị hiện trường bắt đầu truyền đến trạm chủ (quản lý). Các yêu cầu về hiệu năng sẽ phụ thuộc vào độ phức tạp của thiết bị và dữ liệu cụ thể đang được truy xuất cũng phụ thuộc vào loại thiết bị ITS cụ thể. Khi sử dụng STMP, điều này thậm chí có thể trở nên phức tạp hơn vì đại lý cần thời gian để thu thập nội dung của các đối tượng, định dạng khối để truyền và lập lịch truyền.

Đại lý phải xác định các yêu cầu thực hiện cụ thể cần thiết để đảm bảo một hệ thống đáng tin cậy. Ví dụ: trong cấu hình bán song công, tốc độ chậm, hai dây dẫn, thời gian “quay vòng” này có thể được chỉ định theo bậc từng 40 miligiây. Trong môi trường IP, giá trị này có thể được chỉ định là 100 miligiây.

Các khung thời gian này dựa trên dữ liệu thử nghiệm từ việc triển khai các hệ thống hiện có. Người dùng có thể chọn thay đổi các thời gian phản hồi này, nhưng người dùng nên lưu ý rằng việc tăng thời gian phản hồi sẽ dẫn đến thời gian chờ lâu hơn có thể làm giảm hiệu năng của hệ thống thời gian thực.

9.2  Thời gian phản hồi mặc định

Trong trường hợp không có bất kỳ đặc tả kỹ thuật nào khác, thời gian phản hồi được xác định là thời gian từ khi nhận byte cuối cùng của lớp đã xác nhận pruType đến khi bắt đầu truyền byte đầu tiên của thông điệp phản hồi (khi quyền truy cập được cho phép bởi các lớp thấp hơn) không được vượt quá 100 miligiây, trừ khi được phép rõ ràng trong định nghĩa MIB về một trong các đối tượng có trong phản hồi.

CHÚ THÍCH: Thời gian đáp ứng 100 ms mặc định có thể được thay đổi bởi các tiêu chuẩn khác (ví dụ: tiêu chuẩn MIB cho các loại thiết bị cụ thể) hoặc đặc tả kỹ thuật (ví dụ như được sử dụng trong mua sắm hoặc ghi lại những gi được cung cấp) mà không làm cho thiết bị không tuân thủ tiêu chuẩn này. Điều này bao gồm những thay đổi làm tăng thời gian phản hồi cũng như những thay đổi làm giảm thời gian phản hồi. Dự kiến là hầu hết các trường hợp ngoại lệ đối với thời gian phản hồi mặc định sẽ liên quan đến một số lượng nhỏ các đối tượng được xác định. Việc thực hiện có thể luôn phản hồi trước khi hết hạn thời gian đáp ứng.

VÍ DỤ 1: Một hệ thống nhất định cần thường xuyên thăm dò một số lượng lớn các thiết bị cho một tập hợp thông tin cụ thể. Cung ứng từ hệ thống đó có thể yêu cầu thời gian phản hồi cho thông tin cụ thể đó là 70 ms thay vì 100 ms mặc định.

VÍ DỤ 2: Một tiêu chuẩn định nghĩa một đối tượng yêu cầu đại lý thực hiện một số phép tính trước khi phản hồi. Trong trường hợp này, định nghĩa đối tượng có thể chỉ ra rằng bất kỳ yêu cầu nào đối với đối tượng sẽ có thời gian phản hồi tối đa là 200 ms.

VÍ DỤ 3: Một tiêu chuẩn giới hạn số lượng đối tượng có thể được truy xuất trong một yêu cầu duy nhất trong khi vẫn đáp ứng thời gian phản hồi 100 ms.

PHỤ LỤC A

(Quy định)

Danh sách yêu cầu hồ sơ

A.1  Tổng quan

Phụ lục này cung cấp danh sách yêu cầu hồ sơ (PRL) để thực hiện tiêu chuẩn này. Người thực hiện được khuyến khích điền vào các bảng trong Phụ lục này để chỉ ra khả năng của việc thực hiện và để đảm bảo rằng chúng hoàn toàn tuân thủ tiêu chuẩn.

Người dùng có thể sử dụng PRL đã điền đầy đủ thông tin để so sánh các thiết bị về khả năng tương tác và cũng có thể sử dụng thêm khuôn dạng như một phần các kiểm tra lập kế hoạch và trong các đặc tả kỹ thuật mua sắm.

A.1.1  Ký hiệu

Các chú thích và ký hiệu sau được sử dụng để biểu thị trạng thái và trạng thái điều kiện trong PRL.

A.1.1.1  Trạng thái

Bảng A.1 định nghĩa ý nghĩa của các ký hiệu được sử dụng để biểu thị trạng thái của một đặc tính trong tiêu chuẩn này.

Bảng A.1 - Ý nghĩa của các ký hiệu

A.2  Nhận dạng thực hiện

Mỗi thực hiện tiêu chuẩn này phải cung cấp thông tin được định danh trong Bảng A.2.

Bảng A.2 - Nhận dạng thực hiện

A.3  Tuyên bố toàn cầu về sự phù hợp

Bảng A.3 cung cấp tuyên bố toàn cầu về sự phù hợp.

Bảng A.3 - Tuyên bố toàn cầu về sự phù hợp

A.4  Yêu cầu cơ bản

Bảng A.4 liệt kê các yêu cầu và tùy chọn chính để thực hiện tiêu chuẩn này với vai trò là thiết bị quản lý hoặc đại lý. Các yêu cầu và tùy chọn bổ sung áp dụng cho thiết bị quản lý như được định nghĩa trong A.5. Mặt khác, các yêu cầu và tùy chọn bổ sung đối với đại lý được định nghĩa trong A.6. Để yêu cầu sự tuân thủ, việc thực hiện phải đáp ứng các yêu cầu bắt buộc về sự phù hợp của hồ sơ này. Người thực hiện nên sử dụng bảng này để cho biết liệu từng tính năng được xác định có được hỗ trợ hay không.

Bảng A.4 - Danh sách yêu cầu giao thức

A.5  Yêu cầu bổ sung đối với thiết bị quản lý

Bảng A.5 liệt kê các yêu cầu và tùy chọn chính bổ sung để thực hiện tiêu chuẩn này với thiết bị quản lý. Để yêu cầu sự tuân thủ với vai trò là thiết bị quản lý, việc thực hiện phải đáp ứng các yêu cầu phù hợp bắt buộc của hồ sơ này. Việc thực hiện nên sử dụng bảng này để biết mỗi tính năng được xác định có được hỗ trợ hay không.

Bảng A.5 - Danh sách yêu cầu giao thức đối với thiết bị quản lý

A.6  Yêu cầu bổ sung đối với đại lý

Bảng A.6 liệt kê các yêu cầu và tùy chọn chính bổ sung để thực hiện tiêu chuẩn này do đại lý yêu cầu. Để yêu cầu tuân thủ với vai trò là một đại lý, việc thực hiện phải đáp ứng các yêu cầu phù hợp bắt buộc của hồ sơ này. Việc thực hiện nên sử dụng bảng này để chỉ ra liệu mỗi tính năng được xác định có được hỗ trợ hay không.

Bảng A.6 - Danh sách yêu cầu giao thức đối với một đại lý

PHỤ LỤC B

(Quy định)

Mô đun STMP ASN.1

B.1  STMPMessage (bản tin STMP)

Các cấu trúc ASN.1 sau đây cung cấp một định nghĩa chính thức về cấu trúc bản tin STMP. D.5.3 cung cấp mô tả thực tế hơn về cách các cấu trúc dữ liệu này xuất hiện sau khi chúng được mã hóa theo các quy tắc của tiêu chuẩn này.

‒ASN1START

STMPMessageSyntax {iso (1) std (0) 15784 iso15784-2 (2) stmp (1) stmpModules (0) stmpMessage (0) version2015 (1)} DEFINITIONS IMPLICIT TAGS:: = BEGIN

STMP-Pdu:: = CHOICE {

‒ Định nghĩa cho DynamicObject-PDU là một phần giữ chỗ

‒ Xem 6.2.4.4 để có định nghĩa đầy đủ

PHỤ LỤC C

(Quy định)

Cơ sở thông tin quản lý STMP

C.1  STMP MIB

Nội dung sau cung cấp định nghĩa về các đối tượng để quản lý STMP.

Phụ lục D

(Tham khảo)

Khái niệm cơ bản cho giao thức

D.1  Tổng quan

Phụ lục này bao gồm thông tin hỗ trợ hiểu một số khái niệm được trình bày trong phần còn lại của tiêu chuẩn này.

Tiêu chuẩn này dựa trên mô hình SNMP “get-set” tiêu chuẩn Internet. Nói cách khác, giao thức cho phép hệ thống quản lý (tức là “thiết bị quản lý”) đưa ra các thông điệp để giám sát (tức là “lấy/get”) và thay đổi (tức là “thiết lập/set”) một hoặc nhiều phần dữ liệu cụ thể (tức là “đối tượng”) trong một thiết bị mục tiêu (tức là “đại lý”).

D.2  Các loại đối tượng

Tất cả thông tin bên trong một đại lý có thể truy cập được qua SNMP (và các giao thức tương tự) được xác định trong tệp có thể đọc được trên máy tính được gọi là Cơ sở Thông tin Quản lý (MIB). Trong tệp này, một đối tượng riêng biệt được định nghĩa cho mỗi loại thông tin thành phần được gọi là đối tượng. Một định nghĩa đối tượng ví dụ được cung cấp dưới đây.

Tên mà con người có thể đọc được của đối tượng là “dynObjectMaxVariables”. Trường “SYNTAX” cho biết những loại giá trị nào mà đối tượrg có thể lưu trữ và là yểu tố chính xác định nó sẽ được mã hóa như thế nào. Trường “MAX-ACCESS” cho biết quyền truy cập tối đa được phép bằng bất kỳ thao tác nào. Một đối tượng có thể được viết sẽ có MAX-ACCESS “đọc-ghi”, nhưng vì một số nhóm người dùng có thể có quyền hạn chế nên một đối tượng có thể đọc-ghi có thể xuất hiện dưới dạng chỉ đọc đối với một số người dùng.

Trường “STATUS” cho biết nếu đối tượng này vẫn còn được sử dụng thực tế hoặc nếu đối tượng này đã không còn được chấp nhận trong một số tình huống hiện thời. Trường “DESCRIPTION” cung cấp định nghĩa chính xác của đối tượng. Cuối cùng, dòng cuối cùng cho biết tên đối tượng có thể đọc được trên máy tính. Tên máy tính có thể đọc được này dựa trên một mã định danh được đăng ký trên cây đặt tên quốc tế.

Cây đặt tên do ISO và ITU-T cùng tạo ra để cung cấp một tham chiếu duy nhất đến bất kỳ đối tượng nào thông qua cơ chế sử dụng tập hợp các cơ quan đăng ký phân tán. Số nhận dạng này bao gồm một tập các số nhận dạng tích hợp, mỗi số có thể được liên kết với một tên.

Có ba cung gốc được định danh trong cây đặt tên quốc tế: iso, itu-t và joint-iso-itu-t. Mỗi tiêu chuẩn ISO được chỉ định cung riêng của nó dưới cung iso std để xác định bất kỳ dữ liệu nào có thể cần thiết.

Cây hoàn chỉnh cho “dynObjectMaxVariables” được trình bày trong Hình D.1.

Hình D.1 - Cây đặt tên quốc tế cho dynObjectMaxVariables

Bằng cách xác định một số định dạnh duy nhất trên toàn cầu cho mọi đối tượng, bất kỳ đại lý nào cũng có thể trao đổi bất kỳ thông tin nào mà không có bất kỳ nguy cơ mơ hồ nào về ý nghĩa của dữ liệu.

D.3  Đối tượng

Đối tượng là trường hợp của các loại đối tượng. Một số loại đối tượng chỉ có một trường hợp được chỉ định bằng cách gắn một số định danh cá thể không vào cuối định danh đối tượng. Các loại đối tượng khác trình bày ở dạng bảng. Mỗi cột trong bảng được đại diện bởi một loại đối tượng và mỗi hàng đại diện cho một phiên bản khác nhau của từng loại đối tượng trong hàng đó. Một phiên bản cụ thể của đối tượng cột được đưa ra bằng cách thêm giá trị của (các) chỉ số vào cuối mã định danh đối tượng.

D.4  Thông điệp SNMP

SNMP cho phép trao đổi thông tin thông qua việc sử dụng các hoạt động khác nhau trên các đối tượng cụ thể. Các các hoạt động cụ thể được SNMP xác định như sau:

a) get - thiết bị quản lý có thể đưa ra yêu cầu get để truy xuất (các) giá trị của một hoặc nhiều đối tượng từ một đại lý. Một yêu cầu nhận thường dẫn đến việc đại lý trả lời bằng một thông điệp phản hồi;

b) getnext - thiết bị quản lý có thể đưa ra yêu cầu getnext để truy xuất (các) giá trị của một hoặc nhiều đối tượng theo logic (các) đối tượng được chỉ định trong yêu cầu này. Điều này cung cấp một cơ chế để thiết bị quản lý xâm nhập các đối tượng trong thiết bị. Điều này có thể hữu ích khi thiết bị quản lý muốn truy xuất một bảng thông tin, nhưng không biết có bao nhiêu hàng hiện đang được lưu trữ trong bảng. Một yêu cầu getnext thường dẫn đến việc đại lý trả lời bằng một thông điệp phản hồi;

c) getbulk (chỉ SNMPv3) - thiết bị quản lý có thể đưa ra yêu cầu getbulk để truy xuất các giá trị của một tập hợp của các đối tượng bắt đầu từ một đối tượng xác định. Điều này cung cấp cho việc mã hóa hiệu quả hơn một chút so với yêu cầu truy xuất riêng lẻ. Một getbulkrequest thường dẫn đến việc đại lý trả lời bằng một thông điệp phản hồi;

d) set - thiết bị quản lý có thể đưa ra một yêu cầu thiết lập cho một đại lý để định cấu hình (các) đối tượng được chỉ định cho (các) giá trị được chỉ định. Một yêu cầu nhận thường dẫn đến việc đại lý trả lời bằng một thông điệp phản hồi;

e) trap - một đại lý có thể đưa ra một thông báo chưa được xác nhận cho thiết bị quản lý để chỉ ra sự xuất hiện của một số sự kiện. Thông báo trap có thể chứa các chi tiết bổ sung về sự kiện. Ví dụ, có thể sử dụng để báo cáo khi thiết bị khởi động lại. Trap không dẫn đến bất kỳ phản hồi nào và không được xác nhận, cần cẩn thận để tránh các tình huống có thể làm quá tài hệ thống (ví dụ: số lượng thiết bị báo cáo khởi động lại tất cả cùng một lúc trong một khu vực phục hồi sau khi mất điện);

f) inform (chỉ SNMPv3) - một đại lý có thể đưa ra một thông báo đã xác nhận cho thiết bị quản lý để chỉ ra sự xuất hiện của một số sự kiện. Điều này tương tự như một cái bẫy/trap, ngoại trừ việc thiết bị quản lý sẽ thừa nhận việc nhận được một thông điệp thông báo bằng cách gửi cho đại lý một thông điệp phản hồi.

Ngoài danh sách các đối tượng và thao tác được yêu cầu, mọi thông điệp SNMP đều chứa thông tin tiêu đề nhất định như sau:

a) thông tin an toàn (chỉ SNMPv3) - xử lý xác thực và mật mã hóa thông điệp bằng một cơ chế có thể được cập nhật với các công nghệ mới khi cần thiết;

b) request id- cho phép đối chiếu các phản hồi với yêu cầu còn tồn đọng tương ứng;

c) thông tin lỗi - được sử dụng trong các phản hồi để báo cáo lỗi khi có yêu cầu.

D.5  STMP

STMP tương tự về mặt khái niệm và là một phần mở rộng của SNMP cung cấp thông điệp hiệu quả với số byte nhỏ để sử dụng ở những nơi băng thông vật lý bị hạn chế. Giao thức này cho phép, ví dụ, thăm dò ý kiến theo từng giây của bộ điều khiển tín hiệu giao thông qua các đường nối tiếp.

STMP dựa vào SNMP để cấu hình tối đa 13 “đối tượng động”, mỗi đối tượng trong số đó có thể tham chiếu đến nhiều đối tượng SNMP. Sau khi một đối tượng động được cấu hình, STMP có thể được sử dụng để truy xuất toàn bộ tập hợp các đối tượng SNMP bằng cách sử dụng một biểu mẫu rất nhỏ gọn, cải thiện hiệu quả mã hóa tổng thể lên 90% hoặc hơn. Nhược điểm của STMP là độ phức tạp của phần mềm bên trong đại lý được tăng lên đáng kể.

D.5.1  Cấu hình đối tượng động

Đối tượng động là một chuỗi đơn giản của các đối tượng cụ thể tương tự như đối tượng khối, nhưng các đối tượng thành phần bên trong đối tượng động được trạm quản lý xác định tại thời điểm chạy thay vì được định nghĩa là một phần của MIB.

STMP hỗ trợ 13 đối tượng động cho mỗi thực thể ứng dụng. Mỗi đối tượng động có thể chứa tối đa 255 biến. Số lượng biến thực tế được sử dụng sẽ được xác định bởi từng ứng dụng cụ thể.

Một trung tâm quản lý sẽ cấu hình mỗi thiết bị với một tập hợp các đối tượng động cụ thể.

Vì chỉ có một số lượng nhỏ các đối tượng động được xác định bởi giao thức, định danh thông điệp chỉ yêu cầu bốn bit chứ không phải nhiều byte như SNMP yêu cầu. Ngoài ra, các giá trị đối tượng được mã hóa bằng Quy tắc mã hóa ASN.1 Octet thay vì Quy tắc mã hóa cơ bản ASN.1 dài dòng hơn. Các đối tượng động được định nghĩa trong một cặp bảng (dynObjectTable và dynObjectVarTable) hoạt động như một đơn vị. Cả hai bảng đều sử dụng dynObjectNumber làm chỉ số và dynObjectVarTable sử dụng dynObjectVarIndex làm chỉ số phụ. Để thuận tiện trực quan, hai bảng có thể được nhìn thấy cùng nhau, như sau.

Bảng D.1 - Bảng đối tượng động

Mỗi hàng của bảng đối tượng động bao gồm tên chủ sở hữu đã xác định, trường khởi tạo lại (reset) và trạng thái (status). Tên chủ sở hữu xác định ngữ cảnh (còn được biết là “cộng đồng”) sẽ được sử dụng để truy cập thông tin. Cấu hình thích hợp của giá trị này có thể đảm bảo rằng một đối tượng động chỉ có thể được sử dụng cho quyền truy cập chỉ đọc. Khởi tạo lại có thể được sử dụng để nhanh chóng xóa định nghĩa của đối tượng động khi ở chế độ chỉnh sửa. Ví dụ: trạng thái quản lý quyền truy cập vào đối tượng động sẽ ngăn quyền truy cập vào đối tượng động khi thiết bị quản lý đang trong quá trình thay đổi cấu hình. Bạn có thể tìm thấy mô tả đầy đủ về cách trường trạng thái hoạt động trong bất kỳ sách giáo khoa SNMP nào thảo luận về cú pháp RowStatus.

Bảng biến đối tượng động mở rộng bảng đối tượng động bằng cách thêm chỉ số thứ hai: dynObjectVarIndex. Do đó, đối với mỗi hàng trong bảng đối tượng động sẽ có nhiều hàng trong bảng biến đối tượng động cho phép thiết bị quản lý xác định các đối tượng được tham chiếu theo thứ tự mà chúng sẽ xuất hiện trong bảng mã. Ví dụ: một yêu cầu nhận đối với đối tượng động # 1 sẽ truy xuất giá trị của đối tượng được tham chiếu bởi dynObjectVariable.1.1 (tức là dynamicObjectVariable đối với đối tượng động 1 đối với chỉ số biến 1) theo sau là giá trị của đối tượng được tham chiếu bởi dynObjectVariable.1.2, theo sau là giá trị của đốj tượng được tham chiếu bởi dynObjectVariable.1.3, v.v. cho đến khi dynObjectVariable.1.x được đặt thành “null”.

D.5.2  Hoạt động STMP

Các đối tượng động chỉ có thể được truy xuất bằng cách sử dụng STMP. STMP xác định các hoạt động tương tự như SNMP với các biến thể nhỏ như sau:

a) get - thiết bị quản lý có thể yêu cầu một đối tượng động bằng cách sử dụng một byte duy nhất. Điều này thường dẫn đến việc đại lý gửi một phản hồi có chứa dữ liệu được yêu cầu;

b) getNext - thiết bị quản lý có thể yêu cầu láy đối tượng động hoạt động tiếp theo bằng cách sử dụng một byte duy nhất. Điều này thường dẫn đến việc đại lý gửi một phản hồi có chứa dữ liệu được yêu cầu;

c) set - thiết bị quản lý có thể yêu cầu cấu hình của các đối tượng được tham chiếu bởi một đối tượng động. Các thiết bị quản lý gửi các giá trị được định cấu hình trong yêu cầu và đại lý thường phản hồi bằng một byte xác nhận hành động;

d) setNoReply - thiết bị quản lý có thể yêu cầu cấu hình của các đối tượng được tham chiếu bởi đối tượng động mà không có bất kỳ xác nhận nào. Sau đó, thiết bị quản lý có thể gửi một quyền cho đối tượng động để xác nhận rằng các giá trị đã được thiết lập.

Ngoài ra, thay vì có một cấu trúc phản hồi duy nhất, STMP sử dụng ba phản hồi khác nhau như sau:

a) getResponse - chứa dữ liệu được yêu cầu;

b) setResponse - xác nhận lệnh với một byte duy nhất;

c) errorResponse - báo cáo tình trạng lỗi từ yêu cầu.

Trong khi STMP loại bỏ hầu hết thủ tục để đơn giản hóa hoạt động thì nó vẫn cung cấp một tùy chọn cho thông tin an toàn.

D.5.3  Cấu trúc gói dữ liệu STMP

Gói dữ liệu STMP phải có trường tiêu đề và trường thông tin PDU.

D.5.3.1  Trường tiêu đề

Trường tiêu đề một byte sẽ được chia thành một bit định dạng PDU, ba bit trường loại thông điệp và bốn bit trường định danh đối tượng động như sau.

Bảng D.2 - Giải thích trường tiêu đề STMP

Nếu giá trị của trường Loại bản tin (Message Type) và trường ID đối tượng (Object ID) cho biết “được dự phòng/reserved”, thì gói tin sẽ bị bỏ qua.

D.5.3.2  Trường thông tin PDU

Trường thông tin PDU phải chứa một Secure-PDU (nếu Loại bản tin là 111) hoặc một trong các cấu trúc sau:

a) STMP lấy đối tượng động;

b) STMP lấy đối tượng động tiếp theo;

c) STMP thiết lập yêu cầu đối tượng động;

d) STMP thiết lập yêu cầu không trả lời đối tượng động;

e) STMP thiết lập yêu cầu nhận phản hồi đối tượng động;

f) STMP thiết lập phản hồi đối tượng động;

g) STMP phản hồi lỗi đối tượng động.

Mỗi cấu trúc trong số bảy cấu trúc này sẽ có một tiêu đề cụ thể cho từng đối tượng trong số 13 đối tượng động.

D.5.3.2.1  Lấy cấu trúc đối tượng động yêu cầu

Byte tiêu đề sẽ chứa 0x81 - 0x8D cho mỗi một trong số 13 thông điệp STMP lấy đối tượng động yêu cầu.

Sẽ không có thông tin PDU trong thông điệp này.

D.5.3.2.2  Lấy cấu trúc đối tượng động yêu cầu tiếp theo

Byte tiêu đề sẽ chứa 0xB1 - 0xBD cho mỗi một trong số 13 thông điệp STMP lấy đối tượng động yêu cầu tiếp theo.

Sẽ không có thông tin PDU trong bản tin này.

D.5.3.2.3  Thiết lập cấu trúc đối tượng động yêu cầu

Byte tiêu đề sẽ chứa 0x91 - 0x9D cho mỗi một trong số 13 thông điệp STMP thiết lập đối tượng động yêu cầu.

Dạng của PDU này sẽ là ASN.1 SEQUENCE của các đối tượng được tham chiếu bởi dynObjectVariables xác định theo thứ tự mà chúng đã được định nghĩa.

VÍ DỤ: Nếu đối tượng động được xác định có hai biến được lập chỉ số, thì biến đầu tiên tham chiếu đến một đối tượng của SYNTAX INTEGER (0..255) và đối tượng thứ hai tham chiếu đến một đối tượng của SYNTAX OCTET STRING (SIZE (0..127)), trường thông tin STMP PDU sẽ được định nghĩa là mã hóa OER của cấu trúc sau:

SEQUENCE {

}

D.5.3.2.4  Thiết lập cấu trúc đối tượng động yêu cầu không trả lời

Byte tiêu đề sẽ chứa 0xA1 - 0xAD cho mỗi một yêu cầu trong số 13 thông điệp STMP thiết lập đối tượng động yêu cầu không trả lời.

Dạng của PDU này sẽ là ASN.1 SEQUENCE của các đối tượng được tham chiếu bởi dynObjectVariables đã định nghĩa theo thứ tự mà chúng đã được xác định.

Đại lý nhận thông điệp STMP thiết lập yêu cầu không trả lời sẽ không phản hồi trong bất kỳ trường hợp nào.

D.5.3.2.5  Lấy cấu trúc đối tượng động phản hồi

Byte tiêu đề sẽ chứa 0xC1 - 0xCD cho mỗi một trong số 13 thông điệp STMP lấy đối tượng động phản hồi.

Dạng của PDU này sẽ là ASN.1 SEQUENCE của các đối tượng được tham chiếu bởi dynObjectVariables được xác định đã định nghĩa theo thứ tự mà chúng đã được xác định.

D.5.3.2.6  Thiết lập cấu trúc đối tượng động phản hồi

Byte tiêu đề sẽ chứa 0xD1 - 0xDD cho mỗi một trong số 13 thông điệp STMP thiết lập đối tượng động phản hồi.

Sẽ không có thông tin PDU trong thông báo này.

D.5.3.2.7  Cấu trúc đối tượng động phản hồi lỗi

Byte tiêu đề sẽ chứa 0xE1 - 0xED cho mỗi một trong số 13 thông điệp STMP đối tượng động phản hồi lỗi.

STMP sẽ không trả lại thông tin có trong gói yêu cầu khi trả về lỗi.

Thông tin PDU sẽ chỉ chứa một byte trạng thái lỗi, theo sau là một byte chỉ số lỗi. Thiết bị quản lý nên giữ lại yêu cầu cuối cùng được chuyển đến một đại lý để xác định phần nào của yêu cầu gây ra lỗi.

Trường trạng thái lỗi xác định loại lỗi mà đại lý gặp phải khi xử lý yêu cầu liên quan từ trung tâm.

Các mã lỗi này phù hợp với các số được chỉ định bởi SNMPv1. Giá trị của “noError (0)" như được định nghĩa trong SNMP không bao giờ hợp lệ trong thiết kế của STMP và do đó đã bị bỏ khỏi danh sách này. Nếu một trạm quản lý nhận được bất kỳ giá trị nào không được định nghĩa trong danh sách này, nó sẽ coi nó như một genErr.

Các giá trị lỗi như sau:

a) tooBig (1): Lỗi này được trả về nếu PDU lớn hơn mong đợi. Số chỉ số sẽ được đặt thành không;

b) noSuchName (2): Định danh đối tượng được chỉ ra bởi số chỉ số không được đại lý hỗ trợ;

c) badValue (3): Lỗi này chỉ có thể xảy ra trong hoạt động thiết lập. Trường lồng nhau (hoặc đối tượng trong trường hợp STMP) được chỉ ra bởi giá trị số chỉ số sẽ là giá trị đầu tiên không hợp lệ (nằm ngoài phạm vi);

d) readOnly (4): Lỗi này chỉ có thể xảy ra trong một hoạt động đã thiết lập. Số chỉ số cho biết đối tượng nào không thể ghi lại được;

e) genErr (5): Lỗi này chỉ ra rằng một số lỗi khác đã xảy ra và chúng không tương đồng với một trong các lỗi được chỉ định ở trên. Nó là đặc trưng ứng dụng và yêu cầu tham khảo các tài liệu đại lý để xác định lỗi có thể là gì;

f) commitFailed (14): Chỉ ra việc nỗ lực thực hiện các thay đổi có trong yêu cầu đã vượt qua kiểm tra xác nhận ban đầu, nhưng không thể được thực hiện đầy đủ và thiết bị đã được khôi phục về trạng thái của nó trước khi bát kỳ sửa đổi nào được thực hiện;

g) undoFailed (15): Chỉ ra việc nỗ lực thực hiện các thay đổi có trong một yêu cầu đã vượt qua kiểm tra xác nhận ban đầu, nhưng không thể được thực hiện đầy đủ và thiết bị không thể khôi phục lại trạng thái trước đó của nó.

Trường chỉ số lỗi STMP phải chứa giá trị dynObjIndex của mục nhập vi phạm để chỉ ra vị trí chính xác của dữ liệu dẫn đến trạng thái lỗi được báo cáo. Trong một số trường hợp, giá trị này có thể bằng 0 cho biết lỗi là do nguyên nhân khác với giá trị của trường dữ liệu.

D.5.3.2.8  Secure PDU

Thông tin PDU cho một secure PDU chứa cờ và dữân toàn có dạng tương tự như được sử dụng trong SNMPv2 (nhưng được nén và mã hóa bằng OER) theo sau là STMP-Pdu đã có thể mã hóa (tức là bắt đầu bằng bit định dạng PDU của dữ liệu được chứa).

D.6  Các tầng truyền thông

SNMP thường được triển khai trên UDP/IP, nhưng nó có thể được triển khai trên hầu như bất kỳ tầng truyền tải nào. Ví dụ, NTCIP 2202 xác định tầng truyền tải thường xuất hiện dưới dạng tầng rỗng để giảm thiểu tiêu thụ băng thông trên các liên kết tốc độ thấp với các kết nốl vật lý trực tiếp giữa thiết bị quản lý và các đại lý khác nhau của nó (ví dụ như có thể tồn tại trên mạng tín hiệu giao thông trong đó một thiết bị quản lý được kết nối với nhiều bộ điều khiển tín hiệu giao thông chia sẻ kết nối nổi tiếp dây đồng chạy vài kilomet). Nó cũng đôi khi được triển khai trên TCP/IP, đôi khi với mật mã hóa SSL, để đáp ứng nhu cầu của bộ phận CNTT về an toàn. Nói tóm lại, thiết kế giao thức có thể mở rộng để hoạt động trong nhiều môi trường từ liên kết tốc độ thấp (triển khai đã biết ở tốc độ 1200 b/s) đến liên kết cấp quang tốc độ cao với bất kỳ phương tiện truyền thông nào có sẵn.

PHỤ LỤC E

(Tham khảo)

Các ví dụ mã hóa

E.1  Tổng quan

Các điều sau đây cung cấp các ví dụ về các thông điệp mã hóa được tiêu chuẩn này cho phép.

E.2  SNMPv3 lấy yêu cầu không an toàn

Đây là một GetRequest mẫu có thể được gửi trong môi trường an toàn được cung cấp bởi các phương tiện khác (ví dụ: vật lý hoặc bởi các tầng thấp hơn) và quyền truy cập cấp mặc định vào thiết bị là phù hợp.

GHI CHÚ: Cả hai SNMPv1 và SNMPv3 đều sử dụng các quy tắc mã hóa cơ bản mã hóa từng trường như loại của nó, theo sau là độ dài và giá trị được mã hóa thực tế.

E.3  SNMPv3 lấy phản hồi mà không an toàn

Đây là một mẫu nhận phản hồi yêu cầu từ B.1.

E.4  SNMPv3 thiết lập yêu cầu với xác thực

Đây là một SetRequest mẫu có xác thực. Giả định rằng đối tượng động nằm “notlnService” và nó được thay đổi thành trạng thái “hoạt động” trước khi sử dụng.

E.5  STMP lấy đối tượng động mà không an toàn

Phần sau cung cấp một yêu cầu ví dụ cho đối tượng động đầu tiên mà không áp dụng bất kỳ an toàn nào.

E.6  STMP lấy phản hồi đối tượng động không an toàn

Phần sau cung cấp phản hồi ví dụ cho yêu cầu trong D.4.

byte = ‘A’ CHÚ THÍCH: Giả sử định nghĩa theo từng ví dụ được đưa ra trong 8.2.3.4 trong đó biến đầu tiên của đối tượng động được định nghĩa để tham chiếu đến một đối tượng của SYNTAX INTEGER (0..255), biến thứ hai được định nghĩa để tham chiếu một đối tượng của SYNTAX OCTET STRING [SIZE (0..127)] và biến thứ ba được xác định để tham chiếu đến nút “null”.

E.7  STMP lấy đối tượng động với an toàn

Điều này sao chép ví dụ trong D.4, nhưng thêm xác thực USM. Các byte được gạch dưới cho biết phần giá trị được mã hóa BER của msgSecurityParameters. Trường này được bao bọc trong một thông điệp được mã hóa OER.

Thư mục tài liệu tham khảo

[1] ISO 14817-1, Intelligent transport systems - Data dictionaries - Part 1: Definition of data concepts (Hệ thống giao thông thông minh - Từ điển dữ liệu - Phần 1: Định nghĩa khái niệm dữ liệu).

[2] ISO 14817-3, Intelligent transport systems ‒ ITS data dictionaries ‒ Part 3: Object identifier assignments for ITS data concepts (Hệ thống giao thông thông minh - Từ điển dữ liệu - Phần 3: Gán định danh đối tượng cho các khái niệm dữ liệu ITS).

[3] ISO/IEC 8824-1:2008, Information technology ‒ Abstract Syntax Notation One (ASN.1): Specification of basic notation ‒ Part 1. (Công nghệ thông tin - ASN.1: Đặc tả kỹ thuật của ký hiệu cơ bản - Phần 1).

[4] ISO/IEC 8825-1:2008, Information technology ‒ ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ‒ Part 1 (Công nghệ thông tin - Quy tắc mã hóa ASN. 1: Đặc điểm kỹ thuật của Cơ bản Quy tắc mã hóa (BER), Quy tắc mã hóa hợp quy (CER) và Quy tắc mã hóa phân biệt (DER) - Phần 1).

[5] TCVN 10583-1:2014 (ISO/IEC 9834-1:2012), Công nghệ thông tin - Thủ Tục Điều Hành Của Cơ Quan Đăng Ký Định Danh.

[6] IETF RFC 3430, Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping (Giao thức quản lý mạng đơn giản (SNMP) qua Giao thức điều khiển truyền tải (TCP) Ánh xạ vận tải).

[7] NTCIP 1103v02-6b National Transportation Communication for ITS Protocol Transportation Management Protocols (TMP) (Truyền thông Vận tải Quốc gia cho Giao thức ITS - Giao thức quản lý Truyền tải TMP).

[8] RFC 1155 (STD 16) structure and Identification of Management Information for TCP/IP-based Internets (May 1990) (Cấu trúc và Nhận dạng Thông tin Quản lý cho các mạng Internet nền TCP/IP).

[9] RFC 1212 (STD 16) Concise MIB definitions. (March 1991) (Định nghĩa MIB ngắn gọn).

[10] RFC 1213 (STD 17) Management Information Base for Network Management of TCP/IP-based internets: MIB-II (March 1991) (Cơ sở thông tin quản lý để quản lý các mạng Internet nền TCP/IP).

[11] RFC 2579 (STD 58) Textual Coneventions for SMIv2 (April 1999) (Công ước về văn bản cho SMIv2).

[12] RFC 2580 (STD 58) Conformance Statements for SMIv2 (April 1999) (Tuyên bố tuân thủ cho SMIv2).

[13] RFC 3410 Introduction and Applicability Statements for Internet standard Management Framework (December 2002) (Tuyên bố giới thiệu và khả năng áp dụng cho Khung quản lý tiêu chuẩn Internet).

[14] RFC 3419 Textual Conventions for Transport Addresses (December 2002) (Quy ước dạng văn bản cho địa chỉ truyền tải).

[15] UTMC TS003.003:2009 UTMC Framework Technical Specification (Đặc tả kỹ thuật khung UTMC).

Mục lục

Lời nói đầu

1  Phạm vi áp dụng

1.1  Tổng quát

1.2  Mô tả chung

2  Sự phù hợp

3  Tài liệu viện dẫn

4  Thuật ngữ và định nghĩa

5  Ký hiệu và thuật ngữ viết tắt

6  Tổng quan

6.1  Quy ước

6.1.1  ASN.1

6.1.2  Thuật ngữ SNMP

6.1.3  Định dạng

6.2  Mô đun ASN.1 và MIB

6.3  Kiến trúc logic

6.4  Mối quan hệ với mô hình OSI

7  Yêu cầu

7.1  Tổng quan

7.2  Thuật ngữ và kiến trúc

7.3  Xử lý và gửi thông điệp

7.3.1  Yêu cầu chung

7.3.2  Mô hình xử lý thông điệp phiên bản 1

7.3.3  Mô hình xử lý thông điệp phiên bản 2

7.3.4  Mô hình xử lý thông điệp phiên bản 3

7.3.5  Mô hình xử lý thông điệp STMP

7.4  Ứng dụng

7.4.1  Loại thực thể

7.4.2  Bộ tạo lệnh

7.4.3  Bộ phản hồi lệnh

7.4.4  Bộ khởi tạo thông báo

7.4.5  Bộ nhận thông báo

7.4.6  Bộ chuyển tiếp proxy

7.5  Các mô hình an toàn

7.5.1  Mô hình an toàn dựa trên người dùng cho SNMP phiên bản 2

7.5.2  Mô hình an toàn dựa trên người dùng cho SNMP phiên bản 3

7.5.3  Mô hình an toàn truyền tải

7.6  Kiểm soát truy cập dựa trên chế độ hiển thị

7.7  Hoạt động giao thức

7.7.1  SNMPv1

7.7.2  SNMPv2

7.7.3  SNMPv3

7.7.4  STMP

7.7.5  Biến thể ID yêu cầu

7.8  Ánh xạ vận tải

7.8.1  UDP trên IPv4

7.8.2  UDP trên IPv6

7.8.3  TCP trên IPv4

7.8.4  TCP trên IPv6

7.8.5  Mô hình truyền tải an toàn

7.9  Cơ sở thông tin quản lý (MIB)

7.9.1  Đại lý MIB

7.9.2  MIB của bộ khởi tạo thông báo

7.9.3  MIB của bộ chuyển tiếp proxy

7.9.4  STMP MIB

7.9.5  Mô hình an toàn truyền tải MIB

7.9.6  Dữ liệu được hỗ trợ khác

7.10  Khả năng tương tác

8  Giao thức quản lý truyền tải đơn giản (STMP)

8.1  Yêu cầu chung

8.2  Hoạt động gửi thông điệp, xử lý và giao thức

8.2.1  Thiết bị điều phối

8.2.2  Các thành phần thông điệp của thủ tục

8.2.3  Định nghĩa trường thông điệp STMP

8.2.4  Các thành phần PDU của thủ tục

8.3  Ánh xạ vận tải

8.3.1  Yêu cầu chung

8.3.2  UDP trên IPv4

8.3.3  UDP trên IPv6

8.3.4  TCP trên IPv4

8.3.5  TCP trên IPv6

9  Hiệu năng

9.1  Tổng quan

9.2  Thời gian phản hồi mặc định

Phụ lục A (Quy định) - Danh sách yêu cầu hồ sơ

A.1  Tổng quan

A.2  Nhận dạng thực hiện

A.3  Tuyên bố toàn cầu về sự phù hợp

A.4  Yêu cầu cơ bản

A.5  Yêu cầu bổ sung đối với thiết bị quản lý

Phụ lục B (Quy định) - Mô đun STMP ASN.1

B.1  STMPMessage (bản tin STMP)

Phụ lục C (Quy định) - Cơ sở thông tin quản lý STMP

C.1  STMPMIB

Phụ lục D (Tham khảo) - Khái niệm cơ bản cho giao thức

D.1  Tổng quan

D.2  Các loại đối tượng

D.3  Đối tượng

D.4  Thông điệp SNMP

D.5  STMP

D.5.2  Hoạt động STMP

D.5.3  Cấu trúc gói dữ liệu STMP

D.6  Các tầng truyền thông

Phụ lục E (Tham khảo) - Các ví dụ mã hóa

E.1 T ổng quan

E.2  SNMPv3 lấy yêu cầu không an toàn

E.3  SNMPv3 lấy phản hồi mà không an toàn

E.4  SNMPv3 thiết lập yêu cầu với xác thực

E.5  STMP lấy đối tượng động mà không an toàn

E.6  STMP lấy phản hồi đối tượng động không an toàn

E.7  STMP lấy đối tượng động với an toàn

Thư mục tài liệu tham khảo