Đồ án Nghiên cứu và phát triển chức năng HSS và SLF cho kiến trúc IMS

tin nhắn. Nó là thành phần cơ bản nhất trong các thiết bị đầu cuối để chúng có thể hòa mạng. Mặc dù khái niệm UICC và SIM là có thể thay đổi cho nhau, UICC ám chỉ đến thẻ vật lý trong khi đó SIM nói đến một ứng dụng đơn lẻ nằm trong UICC .SIM được sử dụng rộng rãi trong mạng GSM. USIM USIM là một ứng dụng khác nằm trong UICC. USIM cung cấp một tập hợp các tham số bao gồm thông tin đăng ký thuê bao, thông tin nhận thực, phương pháp thanh toán và lưu trữ tin nhắn.USIM được sử dụng để truy nhập mạng UMTS. Các thiết bị đầu cuối trong mạng chuyển mạch gói và chuyển mạch kênh cần phải có USIM để hoạt động được trong mạng 3G. Rõ ràng, cả SIM và USIM có thể cùng tồn tại đồng thời trong UICC để thiết bị đầu cuối có thể sử dụng đồng thời mạng GSM và UMTS. Cấu trúc đơn giản hóa của USIM USIM lưu giữ các thông số sau đây: IMSI: IMSI là một nhận dạng mà được phân bố đến mỗi người dùng. IMSI chỉ được sử dụng để nhận dạng người dùng cho mục đích nhận thực. Nhận dạng người dùng cá nhân tương đương với IMSI. MSISDN: Trường này lưu trữ một hoặc nhiều số điện thoại được cấp cho người dùng. Nhận dạng người dùng công cộng tương đương với MSISDN. CK(Ciphering Key) và IK( Integrity Key): Đó là những chìa khóa được sử dụng cho mục đích mã hóa và bảo vệ sự toàn vẹn thực thể qua giao diện vô tuyến. USIM lưu trữ riêng biệt chìa khóa được sử dụng trong mạng chuyển mạch kênh và chìa khóa trong mạng chuyển mạch gói. Bí mật dài hạn: USIM lưu trữ bí mật dài hạn được sử dụng cho mực đích nhận thực và cho việc tính toán chìa khóa toàn vẹn và chìa khóa mã được sử dụng giữa thiết bị đầu cuối và mạng. SMS( Short Message Service): USIM lưu trữ các bản tin ngắn và các thông tin liên quan như người gửi, người nhận và trạng thái. Các tham số SMS: Trường này trong USIM lưu giữ thông tin cấu hình liên quan tới dịch vụ SMS, như địa chỉ của trung tâm tin nhắn hoặc các giao thức được hỗ trợ. Các thông số MMS: Trường này lưu trữ dữ liệu cấu hình liên quan đến dịch vụ MMS, như địa chỉ của MMS server và địa chỉ của MMS gateway. ISIM Một ứng dụng thứ ba có thể hiện diện trong UICC là ISIM. ISIM có vai trò đặc biệt quan trọng trong IMS, bởi vì nó chứa một tập hợp các thông số được sử dụng làm chứng thực người dùng, nhận dạng người dùng, cấu hình thiết bị đầu cuối khi thiết bị đầu cuối hoạt động trong mạng IMS. ISIM có thể tồn tại cùng SIM, USIM hoặc cả hai. Cấu trúc của ứng dụng ISIM. Các tham số thích hợp được lưu trữ trong ISIM bao gồm: Nhận dạng người dùng cá nhân: ISIM lưu trữ nhận dạng người dùng cá nhân phân bố cho người dùng. Chỉ có một nhận dạng người dùng cá nhân được lưu trữ trong ISIM. Nhận dạng người dùng công cộng: ISIM lưu trữ một hoặc nhiều SIP URI của nhận dạng người dùng công cộng phân bổ tới người dùng. URI của miền mạng chủ: ISIM lưu trữ SIP URI mà chứa tên miền mạng chủ. Thông tin này được sử dụng trong suốt thủ tục đăng ký. Có thể chỉ có một URI tên miền của mạng chủ được lưu trong ISIM. Bí mật dài hạn: ISIM lưu trữ một bí mật dài hạn được sử dụng cho mục đích nhận thực và tính toán mã toàn vẹn và mã mã hóa sử dụng giữa mạng và thiết bị đầu cuối. Thiết bị đầu cuối sử dụng mã toàn vẹn để bảo vệ sự toàn vẹn báo hiệu SIP mà thiết bị đầu cuối gửi và nhận từ P-CSCF. Nếu báo hiệu được mã hóa, thiết bị đầu cuối IMS sử dụng mã mã hóa để mã hóa và giải mã báo hiệu SIP mà thiết bị đầu cuối gửi và nhận từ P-CSCF. Tất cả những thông tin trên chỉ có thể đọc, có nghĩa là người dùng không thể thay đổi giá trị của chúng. Như vậy truy nhập tới mạng IMS dựa trên ISIM hoặc USIM.Mặc dù USIM cũng có thể nhưng sử dụng ISIM vẫn tốt hơn vì nó được thiết kế dành riêng cho IMS. Bởi vì tính bảo mật thấp của SIM, nó không được sử dụng để sử dụng để truy nhập tới mạng IMS. GIAO THỨC HỖ TRỢ CHỨNG THỰC, CẤP QUYỀN, TÍNH CƯỚC TRONG IMS Giao thức AAA được hiểu là Authentication (chứng thực), Authorization (cấp quyền), Accouting (tính cước). Xác thực và cấp quyền có một mối liên hệ tổng quát trong IMS. Trong khi tính cước lại là một chức năng riêng biệt được thực hiện từng nút khác nhau trong mạng. Đó cũng chính là lý do để ta nghiên cứu tách bạch hai nhóm đối tượng này. Chứng thực và cấp quyền trong IMS Hình 2.1 thể hiện sơ đồ của chức năng xác thực và cấp quyền trong IMS. Có ba giao diện triển khai xác thực và cấp quyền đó là các giao diện Cx, Dx, Sh. Giao diện Cx nối giữa HSS và I-CSCF hay S-CSCF. Khi có nhiều hơn một HSS trong mạng thì cần phải có SLF (Subscription Locator Funtion) để giúp I-CSCF hay S-CSCF xác định chính xác HSS nào đang lưu trữ thông tin người dùng. Giao diện Dx nối một I-CSCF hay S-CSCF tới một SLF. Giao diện Sh nối giữa một HSS và một SIP Application Server hay một OSA Service Capability Server ( để hoàn thành mô tả về các loại Application Server trong IMS). Trong tất cả các giao diện này, giao thức sử dụng để liên lạc giữa các nút là giao thức Diameter (được chuẩn hóa trong RFC 3588). Sơ đồ xác thực và cấp quyền trong IMS Giao thức Diameter Diameter là một giao thức tầng ứng dụng dựa trên RFC 3588 được chọn là giao thức AAA trong mạng IMS. + Authentication: Chứng thực + Authorization: Cấp quyền + Accounting: Tính cước Diameter được phát triển từ giao thức RADIUS (RFC 2865) là một giao thức được sử dụng phổ biến trong Internet để thực hiện chứng thực, cấp quyền và tính cước. Ví dụ khi một người dùng quay số đến một nhà cung cấp dịch vụ Internet, máy chủ truy nhập mạng sử dụng RADIUS để chứng thực cấp quyền cho user. Giao thức Diameter được chia thành 2 phần là giao thức Diameter cơ bản và Diameter ứng dụng. Giao thức Diameter cơ bản bao gồm những chức năng chính và triển khai ở mọi điểm sử dụng Diameter, không phụ thuộc vào những ứng dụng cụ thể. Giao thức Diameter cơ bản cần thiết cho việc khởi tạo các đơn vị dữ liệu Diameter, điều chỉnh khả năng, bắt lỗi và cung cấp khả năng mở rộng. Một Diameter ứng dụng định nghĩa một chức năng ứng dụng cụ thể và đơn vị dữ liệu. Mỗi một Diameter ứng dụng được tách rời độc lập nhau Nhiều ứng dụng là mở rộng của các chức năng cơ bản trong giao thức Diameter. Ví dụ như ứng dụng cho Network Access Server, Server Configurations, Mobile Ipv4, Credit Control hay SIP applications. Những ứng dụng này có thể phát triển thêm khi cần thiết. Hình 2.2 thể hiện mối quan hệ giữa giao thức Diameter cơ bản và một vài ứng dụng. Giao thức Diameter cơ bản và các ứng dụng Giao thức Diameter cơ bản sử dụng cả TCP và STCP để truyền tải, trong đó STCP được ưu tiên hơn. IMS sử dụng Diameter trong nhiều giao diện , mặc dù vậy các giao diện này có thể sử dụng các ứng dụng Diameter khác nhau.Ví dụ IMS sử dụng một ứng dụng Diameter trong quá trình thiết lập cuộc gọi nhưng lại sử dụng một ứng dụng Diameter khác trong tính cước. Giao thức Diameter cơ bản định nghĩa ra một vài thực thể chức năng để thực hiện các thao tác AAA: Diameter client: Thực thể chức năng, nằm ở bên rìa của mạng, thực hiện các công việc truy nhập điều khiển ( ví dụ như Network Access Servers ). Diameter Server: Thực thể chức năng thực hiện công việc xử lý các yêu cầu về chứng thực, cấp quyền và tính cước cho các vùng miền. Proxy: Thực thể chức năng thực hiện nhiệm vụ chuyển tiếp các bản tin Diameter, thiết lập các chính sách để giải quyết mối quan hệ về sử dụng và phân phát tài nguyên. Relay: Thực thể chức năng thực hiện chuyển tiếp bản tin Diameter dựa trên các thông tin quan hệ định tuyến và bảng định tuyến vùng. Một Relay tiêu biểu cho tính trong suốt. Nó chỉ có thể sửa đổi (chèn hoặc xóa đi) các thông tin về quan hệ định tuyến trong bản tin Diameter chứ không thể sửa đổi các dữ liệu khác. Redirect agent: Thực thể chức năng dùng để chỉ dẫn client liên lạc một cách với server. Translation agent: Thực thể chức năng thực hiện giao thức vận chuyển giữa giao thức Dameter và các giao thức AAA khác ví dụ như RADIUS. Diameter node: Thực thể chức năng nói chung triển khai giao thức Diameter và hoạt động như một Diameter client, Diameter server, relay, redirect agent, hay translation agent. Diameter là giao thức ngang hàng ( peer-to-peer ) chứ không phải giao thức dạng chủ / tớ. Có nghĩa là từ mọi nút Diameter đều có thể gửi yêu cầu tới các nút khác. Một Diameter client không phải là thực thể chức năng chỉ gửi yêu cầu cũng như một Diameter server không phải là thực thể chức năng chỉ gửi trả lời khi có yêu cầu. Thay vì thế một Diameter client là thực thể chức năng có tính chất điều khiển truy nhập, trong khi Diameter server là thực thể chức năng thực hiện việc chứng thực và cấp quyền. Trong Diameter, cả Diameter client và Diameter server đều có thể gửi hoặc nhận các yêu cầu cũng như hồi đáp. Bản tin Diameter ở một trong hai dạng yêu cầu và hồi đáp. Một yêu cầu được trả lời bởi một hồi đáp. Ngoại trừ một vài trường hợp đặc biệt, nói chung yêu cầu Diameter luôn luôn được trả lời, vì vậy bên gửi yêu cầu luôn nhận được thông tin chính xác về kết quả của yêu cầu đó. Trong trường hợp có lỗi, bên gửi có thể dễ dàng phát hiện và gửi lại. Diameter là một giao thức mã hóa nhị phân (binary encoded protocol). Cấu trúc bản tin Diameter Hình 2.3 thể hiện cấu trúc bản tin Diameter. Một bản tin Diameter bao gồm 20 octet tiêu đề và một số các cặp giá trị thuộc tính (Atribute Value Pairs - AVPs). Chiều dài của phần tiêu đề là cố định trong mọi bản tin Diameter. Còn số lượng các AVPs thì thay đổi phụ thuộc vào từng bản tin Diameter, mỗi một AVPs sẽ chứa dữ liệu về chứng thực, cấp quyền hay tính cước. Cấu trúc bản tin Diameter + Trường version cho biết phiên bản của Diameter + Trường Message length cho biết chiều dài của bản tin Diameter bao gồm cả phần tiêu đề ( header ) + Trường tiếp theo là Command Flags bao gồm 8 bits cho biết loại bản tin Diameter : Nếu bit R ( Request ) được bật thì loại bản tin là yêu cầu, ngược lại là bản tin trả lời. Nếu bit P ( Proxiable ) được bật thì bản tin sẽ được chuyển qua proxy server hoặc relay server hoặc redirect server, ngược lại bản tin sẽ chỉ chuyển trong nội bộ Nếu bit E ( Error ) được bật thì chứng tỏ bản tin có chứa lỗi Nếu bit T được bật thì bản tin này là bản tin truyền lại 4 bit còn lại chưa được sử dụng và thường được đặt về 0 + Trường Command-Code: độ dài 24 bit cho biết lệnh nào sẽ được thực hiện trong bản tin Diameter, Mã số các lệnh này được quản lý bởi Internet Assigned Numbers Authority ( IANA ) bao gồm các lệnh cho giao thức Diameter cơ bản và cho Diameter ứng dụng. + Trường Application – ID xác định loại ứng dụng Diameter nào mà bản tin sẽ được gửi đi, có thể là giao thức Diameter cơ bản hay 1 Diameter ứng dụng nào khác. + Trường Hop-by-Hop identifier chứa giá trị được đặt vào của từng chặng trong bản tin yêu cầu. Bản tin trả lời sẽ có cùng 1 số Hop-by-Hop identifier với bản tin yêu cầu, do vậy một nút Diameter sẽ dễ dàng so sánh bản tin yêu cầu với bản tin trả lời tương ứng. + Trường End-to-End identifier sẽ mang một giá trị cố định không thay đổi khi các bản tin yêu cầu được truyền đi, điều này nhằm xác định các bản tin yêu cầu giống nhau, nút Diameter sẽ gửi lại bản tin trả lời với giá trị End-to-End identifier giống như giá trị nhận được trong bản tin yêu cầu. Cặp giá trị thuộc tính Cũng giống như bản tin RADIUS, bản tin Diameter chứa các cặp giá trị thuộc tính (Atribute Value Pairs - AVPs). AVP sẽ chứa dữ liệu trong đó. Hình 2.4 mô tả cấu trúc của AVP. Mỗi AVP bao gồm các trường : + AVP Code + Flags + AVP Length + Vendor-ID + Data Cấu trúc của AVP AVP Code kết hợp với trường Vendor-ID sẽ xác định duy nhất một thuộc tính. Sự thiếu vắng của trường Vendor-ID hoặc giá trị trường này được đặt về 0 biểu thị đây AVP chuẩn theo lý thuyết được định nghĩa trong IETF. Số AVP Code 1 đến 255 xác định các thuộc tính đã được định nghĩa trong RADIUS, AVP Code từ 256 trở lên xác định các thuộc tính được định nghĩa riêng trong Diameter Trường Flags biểu thị : + Sự cần thiết mã hóa để bảo đảm an ninh trong quá trình truyền điểm-điểm + Hỗ trợ AVP có tính chất bắt buộc hay là tùy chọn. Nếu bên gửi thông báo rằng có hỗ trợ AVP là bắt buộc và bên thu không hiểu AVP đó thì yêu cầu Diameter sẽ bị từ chối + Tùy chọn trường Vendor-ID có hiển thị hay không Trường AVP Length biểu thị độ dài của AVP, bao gồm AVP Code, AVP Length, Flags, Vendor-ID (nếu có) và trường Data Trường Data chứa một vài loại dữ liệu đặc biệt về thuộc tính. Độ dài của trường Data có thể là không hoặc nhiều byte. Độ dài của dữ liệu có thể biết được nhờ trường AVP Length. Giao thức Diameter cơ bản chỉ rõ một vài định dạng dữ liệu của trường Data : OctetString, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64, và Grouped. Hầu hết trong số đó là cùng một loại. Kiểu Grouped AVP là một AVP có trường dữ liệu là một chuỗi các AVP khác. Những AVP có Code từ 1 đến 255 xác định các thuộc tính đã được định nghĩa trong RADIUS, AVP có Code từ 256 trở lên là AVP được định nghĩa trong Diameter. AVP-Code được quản lý bởi IANA Giao thức Diameter cho phép các ứng dụng có thể xác định định dạng dữ liệu AVP. Giao thức cơ bản đã định nghĩa sẵn một vài dữ liệu AVP, những loại quan trọng nhất như: Địa chỉ để vận chuyển một địa chỉ IPv4 hay một địa chỉ IPv6 Thời gian để miêu tả ngày giờ UTF8String để trình bày xâu, chuỗi theo bảng mã Unicode : UTF-8 DiameterIdentity để vận chuyển đầy đủ tên miền của nút Diameter DiameterURI để vận chuyển các AAA URI hay AAAS URI Enumerated, một bảng số để miêu tả một vài ngữ nghĩa nào đó Địa chỉ AAA và AAAS Giao thức AAA có thể sử dụng một aaa URI hay một aaas URI để xác định tài nguyên AAA. Aaas URI biểu thị rằng việc vận chuyển tin cậy phải được sử dụng. Cú pháp của những URI này như sau : "aaa://" FQDN [ port ] [ transport ] [ protocol ] "aaas://" FQDN [ port ] [ transport ] [ protocol ] port = ":" 1*DIGIT transport = ";transport=" transport-protocol protocol = ";protocol=" aaa-protocol transport-protocol = ( "tcp" / "sctp" / "udp" ) aaa-protocol = ( "diameter" / "radius" / "tacacs+" ) Trong đó FQDN là Fully Qualified Domain Name. Những URI có thể được chèn vào bằng tùy chọn số cổng, một tùy chọn về giao thức vận chuyển hoặc một tùy chọn giao thức để truy cập tài nguyên AAA. Nếu như số cổng không khớp với số cổng mặc định của giao thức Diameter (3868) thì nó sẽ lờ đi. Nếu như thông số về vận chuyển không xuất hiện, giao thức Diameter cũng lờ đi. Phải chú ý rằng aaa URI và aaas URI có thể điều chỉnh thích hợp với Diameter, RADIUS và các giao thức khác. Ví dụ về các aaa URI và aaas URI : aaa://server.home1.net aaas://server.home1.net aaa://server.home1.net:8868 aaa://server.home1.net;transport=tcp;protocol=diameter Giao thức Diameter cơ bản Chúng ta đã thấy bản tin Diameter là một trong hai loại yêu cầu hoặc hồi đáp. Một yêu cầu và hồi đáp tương ứng của nó được xác định bởi trường Command-Code trong tiêu đề bản tin. Trường Command-Code là một số biểu thị phương thức mà Diameter server muốn tiến hành. Một yêu cầu và hồi đáp tương ứng của nó đều có cùng số Command-Code, do vậy cần có cờ Command-Flags để phân biệt yêu cầu và hồi đáp. Giao thức Diameter cơ bản (RFC 3588 [60]) đã chỉ rõ các Command-Code đầu tiên. Một ứng dụng có thể được mở rộng từ những lệnh cơ bản và thêm vào đó những ứng dụng mới. Hình 2.5 liệt kê các các yêu cầu và hồi đáp được định nghĩa trong giao thức Diameter cơ bản. Command-Name Abbreviation Command-Code Abort-Session-Request ASR 274 Abort-Session-Answer ASA 274 Accounting-Request ACR 271 Accounting-Answer ACA 271 Capabilities-Exchange-Request CER 257 Capabilities-Exchange-Answer CEA 257 Device-Watchdog-Request DWR 280 Device-Watchdog-Answer DWA 280 Disconnect-Peer-Request DPR 282 Disconnect-Peer-Answer DPA 282 Re-Auth-Request RAR 258 Re-Auth-Answer RAA 258 Session-Termination-Request STR 275 Session-Termination-Answer STA 275 Các lệnh cơ bản của Diameter Bản tin ASR và ASA ASR (Abort Session Request) ASA (Abort-Session Answer) Đây là lệnh cần thiết cho Diameter server khi muốn ngừng cung cấp dịch vụ tới người dùng. Bởi vì có những nguyên do mới sẽ xuất hiện không thể biết trước được khi phiên đã được cấp quyền. Đó có thể là hết tài khoản, lý do an ninh, bảo mật, hoặc một lý do nào khác. Khi một Diameter server quyết định thông báo tới Diameter client về việc ngừng cung cấp dịch vụ, Diameter server sẽ gửi bản tin Abort-Session-Request (ASR) tới Diameter client. Diameter client sẽ trả lời bằng bản tin Abort-Session-Answer (ASA). Bản tin ACR và ACA ACR (Accounting Request) ACA (Accounting Answer) Một nút Diameter có thể cần thiết phải thông báo về tình trạng tài khoản cho Diameter server cung cấp dịnh vụ tính cước. Giao thức Diameter cung cấp lệnh Accouting-Request (ACR), nhờ đó Diameter client có thể thông báo tình trạng sử dụng dịch vụ cho Diameter server. Lệnh này sẽ chứa các thông tin giúp cho Diameter server có thể ghi lại các sự kiện trước khi đưa ra các lệnh hoặc chuẩn bị chấm dứt dịch vụ. Bản tin CER và CEA CFR (Capabilities Exchange Request) CFA (Capabilities Exchange Answer) Là bản tin trao đổi đầu tiên giữa hai nút Diameter, khi kết nối vận chuyển chỉ được khởi tạo một đầu. Hai bản tin này mang các thông tin về nhận dạng của nút và các thông số về lưu trữ của nó ( phiên bản của giao thức, sự hỗ trợ Diameter ứng dụng, cơ cấu hỗ trợ bảo mật…) Bản tin DWR và DWA DWR (Device Watchdog Request) DWA (Device Watchdog Answer) Nó cần thiết cho giao thức Diameter để tìm được các lỗi của tầng vận chuyển và tầng ứng dụng ngay khi có thể, do đó sẽ đưa ra được phản ứng thích hợp. Diameter có thể cung cấp việc xác định các lỗi này là dựa trên cơ chế watchdog của tầng ứng dụng. Trong suốt chu kỳ vận chuyển lưu lượng giữa hai nút Diameter, nếu như một nút gửi yêu cầu mà không nhận được hồi đáp trong một khoảng thời gian nào đó, khi ấy vẫn đủ để tìm ra lỗi ở tầng vận chuyển hay tầng ứng dụng. Tuy nhiên trong trường hợp bị thất lạc nhiều gói qui định thì không thể tìm ra lỗi được. Diameter giải quyết vấn đề này qua việc điều tra tầng vận chuyển và tầng ứng dụng của các nút Diameter trung gian bằng cách gửi bản tin DWR. Sự thiếu vắng của bản tin phản hồi DWA sẽ là cơ sở để xác định nguyên nhân gây lỗi. Bản tin DPR và DPA DPR (Disconnect Peer Request) DPA (Disconnect Peer Answer) Một nút Diameter có thể khởi tạo kết nối với nút Diameter ngang hàng khác, trong khi nút đó có thể lại muốn chấm dứt kết nối. Trong trường hợp này nút Diameter gửi bản tin Disconect-Peer-Request (DPR) tới nút nối với nó để báo rằng chuẩn bị chấm dứt kết nối. Bản tin DPR cũng mang ý nghĩa yêu cầu nút ngang hàng kia không khởi tạo lại kết nối trừ khi cần thiết ( ví dụ trong trường hợp chuyển tiếp bản tin). Bản tin RAR và RAA RAR (Re-Authentication-Request) RAA (Re-Authentication-Answer) Đôi lúc, đặc biệt là khi một phiên đã chấm dứt từ rất lâu, Diameter server có thể yêu cầu người dùng chứng thực lại để đảm bảo tính an ninh, bảo mật. Một Diameter server muốn chứng thực lại người dùng sẽ gửi bản tin Re-Auth-Request tới Diameter client. Diameter client sẽ hồi đáp bằng bản tin Re-Auth-Answer. Bản tin STR và STA STR (Session Termination Request) STA (Session Termination Answer) Một Diameter client gửi thông cáo về Diameter server biết rằng có một người dùng đã rất lâu không sử dụng dịch vụ, để thực hiện như vậy, Diameter client gửi bản tin Session-Termination-Request (STR). Diameter server trả lời bằng bản tin Session-Termination-Answer (STA). Ví dụ nếu server quay số thông báo rằng thông báo rằng kết nối quay số đã bị ngưng sử dụng thì Diameter client sẽ gửi bản tin STR tới Diameter server. Các AVP trong giao thức Diameter cơ bản Mỗi một yêu cầu và hồi đáp định nghĩa những cặp giá trị thuộc tính (AVPs) được trình bày trong bản tin. Một vài AVP có thể là tùy trọn riêng trong yêu cầu hay hồi đáp, số khác là bắt buộc. Sự có mặt hoặc không của những AVP định nghĩa chuẩn phụ thuộc vào những yêu cầu và hồi đấp thực tế. Ví dụ AVP tên là Authorization-Lifetime như trong bảng dưới thể hiện thời gian mà trong đó sự chứng thực một người dùng còn hiệu lực. Danh sách đầy đủ của các AVP trong giao thức Diameter cơ bản rất dài. Danh sách đầy đủ có trong RFC 3588. Chúng ta sẽ tìm hiểu một vài AVP quan trọng, thường xuyên xuất hiện trong các bản tin Diameter AVP chứa các thông tin về chứng thực, cấp quyền và tính cước. Trường AVP-Code gồm 32 bit xác định các thuộc tính Attribute-Name Code Data-Type User-Name 1 UTF8String Session-Id 263 UTF8String Redirect-Host 292 DiamURI Host-IP-Address 257 Address Class 25 OctetString Accounting-Record-Number 485 Unsigned32 Auth-Application-Id 258 Unsigned32 Authorization-Lifetime 291 Unsigned32 Vendor-Id 266 Unsigned32 … … … Một số AVP AVP có tên User-Name biểu thị tên của người dùng trong một miền. AVP này có cấu trúc dựa trên Nhận Dạng Truy cập Mạng (Network Access Identifier – NAI) được định nghĩa trong RFC 2486 [45]. Một NAI có định dạng theo kiểu username hoặc username@realm. Trong IMS AVP User-Name chứa nhận dạng người dùng cá nhân (Private User Identity). Mọi bản tin hồi đáp Diameter đều chứa một AVP có tên Result-Code. Giá trị của AVP Result-Code biểu thị yêu cầu vừa gửi có thành công hay không và nó trả lại một danh sách các giá trị có thể của AVP tùy thuộc vào từng yêu cầu và hồi đáp thực tế. AVP có tên Origin-Host, mang đầy đủ thông tin về tên miền đủ điều kiện của nút Diameter phát sinh ra yêu cầu. AVP có tên Destination-Host biểu thị thông tin về tên miền đủ điều kiện của Diameter server nơi tên người dùng được định nghĩa. Thỉnh thoảng người dùng không biết được tên hiện tại của server, nhưng biết về miền quản lý nơi tên người dùng là hợp lệ. Trong trường hợp này AVP Destination-Realm được sử dụng. Bản tin yêu cầu Diameter có thể đi qua proxy hoặc không. Có một cờ trong phần tiêu đề của bản tin biểu thị bản tin đó có phải đi qua proxy hay không. Những bản tin có thể đi qua proxy sẽ được những proxy định tuyến tới mạng đích. Bởi vậy một yêu cầu có thể đi qua proxy thì luôn luôn chứa AVP Destination-Realm. Những bản tin không thể qua proxy sẽ được định tuyến ngay đến chặng tiếp theo và nó không bao giờ được chuyển tiếp. Môt AVP quan trọng khác có tên Session-ID. Nó chứa một nhận dạng bao trùm cho một phiên. Tất cả các bản tin trong cùng một phiên sẽ đều có cùng một giá trị AVP Session-ID giống nhau. Một nhóm AVP có tên Vendor-Specific-Application-Id chứa xác nhận về một ứng dụng Diameter được định nghĩa cụ thể. Vendor-Specific-Application-Id chứa một AVP Auth-Application-Id hoặc một Acct-Application-Id, mặc dù vậy chỉ một trong hai số chúng có mặt tại một thời điểm. AVP có tên Auth-Application-Id sẽ mang thông số về chứng thực và cấp quyền của ứng dụng. AVP có tên Acct-Application-Id sẽ mang thông tin về tính cước của ứng dụng. Vendor-Specific-Application-Id cũng chứa một AVP có tên Vendor-Id. AVP có tên Auth-Session-State biểu thị Diameter client có muốn xác nhận trạng thái của một phiên Diameter đặc biệt, liên quan hay không. Diameter client sử dụng AVP này như là một yêu cầu, và Diameter server sẽ trả lời cũng bằng AVP đó trong bản tin hồi đáp. Một nhóm các AVP khác có tên Proxy-Info chứa các AVP : Proxy-Host và Proxy-State, nó cũng có thể chứa một vài AVP khác. Nó cho phép một agent chưa được công nhận vẫn có một trạng thái trong yêu cầu. Hồi đáp tương ứng cũng sẽ có cùng AVP đó, bởi vậy một agent chưa được công nhận vẫn có thể lấy được thông tin trạng thái và tiếp tục quá trình trong phiên Diameter. AVP có tên Proxy-Host chứa tên của chính proxy chèn thông tin. AVP có tên Proxy-State chứa một dữ liệu ẩn được viết ra mà chỉ có chính proxy đó mới đọc được. Một relay hay một proxy agent gắn thêm vào một AVP có tên Route-Record tới tất cả các yêu cầu. AVP Route-Record chứa nhận dạng của nút Diameter gửi yêu cầu. Điều này cho phép phát hiện vòng lập. Nó cũng cho phép Diameter server kiểm tra và cấp quyền đường đi cho một yêu cầu. Giao diện Cx và Dx Giao diện Cx được xây dựng để kết nối một I-CSCF hoặc một S-CSCF tới một HSS. Tương tự như vậy giao diện Dx cũng được xây dựng để kết nối một I-CSCF hoặc một S-CSCF tới một HSS hoặc một SLF. Điểm khác biệt duy nhất giữa hai giao diện này là việc triển khai SLF như một Diameter redirect agent, ngược lại HSS như một Diameter server. Trong trường hợp này cả I-CSCF và S-CSCF đề hoạt động như Diameter client. Trong mạng nếu có nhiều hơn một HSS, những Diameter client (S-CSCF, I-CSCF ) cần phải liên hệ với SLF để tìm xem HSS nào trong mạng lưu trữ thông tin về người dùng ứng với nhận dạng công cộng của người dùng đó (Public User Identity). Các lệnh của Diameter từ S-CSCF hay I-CSCF gửi tới HSS và SLF là như nhau. SLF hoạt động như một Diameter redirect agent và chứa bảng tham chiếu các nhận dạng người dùng công cộng với HSS tương ứng lưu trữ thông tin người dùng đó. Khi nhận được yêu cầu SLF sẽ trả lời bằng bản tin có chứa AVP : Redirect-Host. AVP này chứa địa chỉ của HSS mà S-CSCF hay I-CSCF cần liên hệ. I-CSCF và S-CSCF sau đó sẽ chuyển tiếp bản tin Diameter tới HSS đó. Bởi vì bản tin Diameter đi qua giao diện Cx và Dx là như nhau, giao diện Dx có thể coi như trong suốt để mô tả sự tương tác với giao diện Cx. Trong phần này ta chỉ nói đến giao diện Cx với HSS, nhưn