AVP Header

Một phần của tài liệu đề tài: ims over ngn (Trang 63 - 66)

 Trường AVP Code: dài 32 bit, được quản lý bởi IANA, dùng để xác nhận các thuộc tính với trường Vendor-ID. Giá trị từ 0-255 dùng để tương thích vói RADIUS, các giá trị còn lại dùng trong DIAMETER

 Trường AVP Flag dài 8 bit, có dạng VMPrrrrr, mỗi bit có ý nghĩa như sau:

 Bit V (vendor -ID): nếu bằng một thì thông tin sẽ được đề cập trong trường Vendor-ID, ngược lại trường Vendor-ID rỗng.

 Bit M (Mandatory): UE sẽ không nhận bản tin này nếu bit này bằng 0.

 Bit P (Protect): nếu bằng 1 thì bản tin được yêu cầu mã hóa end-to-end.

 Bit r: dự trữ

 Trường AVP length: chiều dài AVP data

4.2.3.2.2 AVP Data

Trường AVP data có thể là rỗng hoặc nhiều octet chứa thông tin về thuộc tính cụ thể.Định dạng và chiều dài của trường này được xác định bởi trường AVP Code và AVP Length. Định dạng của trường này là một trong những dạng dữ liệu chuẩn sau đây: OctetString,Interger32,Interger64,Unsigned32,Unsigned64,Float32,Float64,Grouped...Để tìm hiểu kỹ về các dạng dữ liệu này, người xem có thể tham khảo [RFC 3588]. Trong trường hợp cần có một dạng dữ liệu cơ bản mới cho AVP Data thì một phiên bản RFC mới hơn phải được tạo ra.

Ngoài việc sử dụng các dạng dữ liệu cơ bản, trường này còn có thể sử dụng các định dạng dữ liệu khác nhau theo ứng dụng. Có một số dạng dữ liệu theo ứng dụng như sau:

 Address: dạng dữ liệu này được tạo ra từ dạng OctetString ( dạng dữ liệu cơ bản). Nó có thể là dạng địa chỉ 32 bit (Ipv4) hoặc 128 bit (IPv6).

 Time: dạng dữ liệu này được tạo ra từ OctetString. Chuỗi (string) phải dài bốn octet. Dạng dữ liệu này giống định dạng của SNTP [RFC 2030]

 Diameter Identity: dạng dữ liệu này được tạo ra từ OctetString, dùng để xác định sự duy nhất của một nút trong mạng, tránh trường hợp có nhiều đường kết nối đến một nút dẫn đến trình trạng bị lặp trong định tuyến. Nội dung chuỗi dữ liệu trong kiểu này là FQDN của một nút Diameter.

Ngoài ra còn có các dạng dữ liệu khác như: UTF8String, DiameterURI, Enumerated, IPFilterRule, QoSFilterRule, … [RFC 3588]

4.2.4 Bảo mật trong bản tin Diameter

Client trong giao thức Diameter phải hổ trợ chuẩn IPSec và có thể hổ trợ TLS.Server phải hổ trợ cả 2 chuẩn trên.Để bảo mật, khuyến nghị rằng nên sử dụng IPSec ở các nút trong

cùng một miền như giữa Client và Proxy và sử dụng TSL để bảo mật khi có giao dịch giữa các miền với nhau. Khi sử dụng TSL, hai phía phải thương lượng một Cipher key theo một trong các thuật toán sau:

 RC4_128_MD5

 RC4_128_SHA

 3DES_EDE_CBC_SHA

 AES_128_CBC_SHA

4.2.5 Khả năng kiểm soát lỗi của giao thức Diameter

Lỗi trong giao thức Diameter chia thành 2 loại: lỗi giao thức và lỗi ứng dụng

 Lỗi giao thức

Xảy ra ở cấp độ giao thức cơ bản như lỗi định tuyến. Khi xuất hiện lỗi, bit E trong trường Command Flag của Diameter Header trong bản tin đáp ứng sẽ được bật lên 1 và gởi trở lại theo đường đến.

Hình 4.9: Lỗi giao thức trong Diameter

 Lỗi ứng dụng

Xảy ra ở các ứng dụng của Diameter như chứng thực User, mất gói AVP. Khi xuất hiện lỗi, bit R trong Command Flag trong bản tin đáp ứng được bật lên 1 và gởi lại cho User khởi tạo không thông qua Agent

Hình 4.10: Lỗi ứng dụng trong giao thức Diameter

Các bản tin đáp ứng lại trong trường hợp có lỗi:

Bảng 4.3: Bản tin đáp ứng trong trường hợp có lỗi xảy ra

4.3 COPS Giao thức COPS

Một phần của tài liệu đề tài: ims over ngn (Trang 63 - 66)

Tải bản đầy đủ (DOC)

(104 trang)
w