AVP Header

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

 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 (adsbygoogle = window.adsbygoogle || []).push({});

4.3 COPS Giao thức COPS

4.3.1 Tổng quan về giao thức COPS

COPS là giao thức được IETF chuẩn hóa nhằm thực hiện việc quản lý, cấu hình và áp đặt chính sách. Giao thức này hoạt động theo mô hình Client-Server. Nó định nghĩa một giao thức yêu cầu và đáp ứng một cách đơn giản trong việc trao đổi thông tin chính sách và

được xem là Client và server là điểm quyết định chính sách PDP. Và một thành phần đặc biệt là điểm quyết định chính sách cục bộ LPDP, nó thay thế cho PDP trong việc liên lạc với PEP khi PDP không được tìm thấy. COPS điều khiển chính sách theo 2 mô hình chính:

 Outsourcing

PEP chỉ định một PDP bên ngoài chịu trách nhiệm xử lý những sự kiện gởi ra từ PEP. Mô hình này cho thấy sự tương quan one-to-one giữa những sự kiện ở PEP và những quyết định từ một PDP.

 Configuration

Không giống như mô hình trước, là không có sự ánh xạ trực tiếp những sự kiện tại PEP và những quyết định từ PDP. PDP có thể cấu hình những sự kiện bên ngoài được khởi tạo bởi một PEP bất kỳ và sự kiện gởi từ PEP có thể được xử lý bởi PDP cùng khối với nó hoặc PDP thuộc khối khác. Xét về mặt thời gian thì mô hình này linh động hơn mô hình outsourcing.

Cops sử dụng phương thức truyền TCP để truyền những bản tin đáng tin cậy giữa PEP và PDP. Không giống như giao thức client - server khác, cặp bản tin yêu cầu - đáp ứng này phải phù hợp với cặp bản tin yêu cầu - đáp ứng khác. Ở đây, server có thể áp áp đặt chính sách cho client và xóa những chính sách trên client nếu chính sách đó không còn phù hợp nữa. PEP khởi tạo kết nối TCP đến PDP, PEP gởi yêu cầu và nhận những quyết định chính sách từ PDP và sự liên lạc giữa PEP và PDP là sự trao đổi yêu cầu, đáp ứng. Tuy nhiên PDP hoặc PEP có thể gởi đi những bản tin độc lập, ví dụ như PDP gởi những quyết định tới PEP bắt buộc PEP thay đổi những chính sách được PDP chấp nhận trước đó (không phải bản tin đáp ứng cho những yêu cầu của PEP) và PEP có thể gởi những bản tin báo cáo về trạng thái cho PDP. Sự mở rộng có thể được mô tả trong phần định dạng bản tin và những phần tử mang dữ liệu về chính sách không cần yêu cầu bất kỳ thay đổi nào trong giao thức.

COPS được sử dụng trong liên lạc giữa khối PDF và GGSN, tạo sự kết nối giữa mạng IMS và mạng GPRS nhằm cung cấp mức độ bảo mật các bản tin cho việc xác thực, bảo vệ toàn vẹn bản tin. COPS cũng có thể tái sử dụng giao thức về bảo mật như IPSEC hoặc TLS để xác thực và bảo vệ kênh truyền giữa PEP và PDP.

Hình 4.11: Mô hình COPS 4.3.2 Chức năng chính của COPS

Giao thức này giao việc cho Client hỗ trợ cho mô hình Client/Server. Trong đó Client sẽ gởi những bản tin: yêu cầu, cập nhật, và xóa tới PDP và PDP gởi trả những quyết định cho PEP.

COPS sử dụng phương thức TCP để trao đổi bản tin giữa Server và Client nên ta không cần bổ sung thêm chức năng hỗ trợ việc liên lạc có đảm bảo giữa Server và Clients.

COPS thực hiện việc quản lý, cấu hình, và thực thi các chính sách

COPS cung cấp mức độ bảo mật các bản tin cho việc xác thực, phát lại bảo vệ, và toàn vẹn bản tin.COPS cũng có thể tái sử dụng giao thức về bảo mật như IPSEC hoặc TLS để xác thực và bảo vệ kênh truyền giữa PEP và PDP.

COPS cho phép Server áp dụng chính sách cho Client hoặc xóa chính sách đang thực thi trên Client nếu nó không còn được sử dụng nữa.

4.3.2.1 Bản tin COPS

Bản tin của giao thức COPS gồm COPS Header và Object format

4.3.2.1.1 COPS Header

Hình 4.12: COPS header

 Version (4bits): chỉ phiên bản của giao thức COPS đang được dùng, hiện nay đang sử dụng COPS version 1

 Flags (4bits): mặc định là 0, cờ flag đặt lên 1 khi bản tin gởi đi là bản tin DEC, khi đó PDP gởi bản tin DEC đáp ứng lại yêu cầu của bản tin REQ do PEP gởi ra.

 Op Code (8 bits): cho biết hoạt động của COPS.

Bảng 4.4: Các loại Op code trong COPS header Giá trị Loại Nơi chốn Tên Mô tả

1 REQ PEP→PDP Request Yêu cầu quyết định từ PDP và

thiết lập một client handle nhằm xác định tình trạng phù hợp cho PEP

2 DEC PDP→PEP Decision Trả lại một hoặc nhiều quyết định

(đáp ứng) cho một yêu cầu

3 RPT PEP→PDP Report state Báo cáo lại cho PDP biết là PEP

đã nhận được đáp ứng của PEP hay chưa và thông báo sự thay đổi trạng thái của PEP (adsbygoogle = window.adsbygoogle || []).push({});

4 DRQ PEP→PDP Delete request state

Thông báo cho PDP biết là

5 SSQ PDP→PEP Synchronize

state request

PDP gởi cho PEP để đồng bộ dữ liệu

6 OPN PEP→PDP Client-Open

7 CAT PDP→PEP Client-

Accept

8 CC PEP→PDP

PDP→PEP

Client-Close Cho biết phần tử Client-type không được hỗ trợ

9 KA PEP→PDP

PDP→PEP

Keep-Alive Kiểm tra sự tồn tại của PDP/PEP

10 SSC PEP→PDP Synchronize

complete

Thông báo sự đồng bộ thành công

 Client-type (16 bits): cho biết chính sách áp dụng cho Client và xác định những thực thể liên quan. 16 bit s có giá trị trong khoảng 0x8000 - 0xFFFF. Đối với bản tin KA thì Client-type phải đặt là 0.

 Message Length (32 bits): bao gồm header chuẩn và phần tử rút gọn và độ dài chỉ trong 4bytes.

Hình 4.13: Object format của bản tin COPS

 Length: chiều dài của Object format

 C-num (8 bits): cho biết lớp thông tin chứa đựng trong object

Bảng 4.5: Trường C-Num trong Object format của bản tin COPS C-num Tên Nơi chốn Mô tả

1 Handle Most Giá trị duy nhất để xác định trạng

thái được cài đặt

2 Context REQ, DEC Cho biết phần tử nào tạo ra những

truy vấn

3 In interface REQ Địa chỉ và giao tiếp bên trong của

PEP

4 Out interface REQ Địa chỉ và giao tiếp bên bên ngoài (adsbygoogle = window.adsbygoogle || []).push({});

của PEP

5 Reason code DRQ Cho biết lý do các yêu cầu bị xóa

6 Decision DEC Quyết định do PDP tạo ra

7 LPDP decision DEC Quyết định do LPDP tạo ra

8 Error CC Xác định giao thức bị lỗi

9 Client-specific

info

REQ, DEC, RPT, OPN

Thông tin về Client

10 Keep-Alive timer CAT Giá trị bộ đếm thời gian

11 PEP

identification

OPN Xác định PEP cho PDP

12 Report type RPT Loại báo cáo về trạng thái yêu cầu,

nó phải tương ứng với handle cụ thể

address PEP đến PDP khác

14 Last PDP address OPN Địa chỉ của PDP mà PEP kết nối

lần cuối

15 Accounting timer CAT Xác định thời gian cho việc tính phí

16 Message

integrity

Any Chuỗi số và sự kiểm bản tin chứng

thực nhằm đảm bảo sự bảo mật cho những yêu cầu

4.4 Giao thức MEGACO/H. 248

4.4.1 Tổng quan về giao thức MEGACO/H.248

Megaco được phát triển bởi IETF (đưa ra vào cuối năm 1998), còn H. 248 được đưa ra vào tháng 5/1999 bởi ITU-T. Sau đó cả IETF và ITU-T cùng hợp tác thống nhất giao thức điều khiển MG, kết quả là vào tháng 6/2000 chuẩn Megaco/H. 248 ra đời.

MEGACO/H248 cung cấp một giải pháp toàn diện cho việc điều khiển các MG. Giao thức này hỗ trợ đa phương tiện và các dịch vụ hội thoại nâng cao đa điểm các cú pháp lập trình được nâng cao nhằm tăng hiệu quả cho các tiến trình đàm thoại, hỗ trợ cả việc mã hoá text và binary và thêm vào việc mở rộng các định nghĩa cho các gói tin.

Megaco/H. 248 là giao thức báo hiệu giữa Softswitch hoặc MGC với MG (Trunking Media Gateway, Lines Media Gateway hoặc IP Phone Media Gateway). Megaco/H. 248 điều khiển MG để kết nối các luồng từ ngoài.

Megaco/H. 248 tương tự với MGCP về mặt cấu trúc và mối liên hệ giữa bộ điều khiển và cổng gateway, tuy nhiên Megaco/H248 hỗ trợ đa dạng hơn các loại mạng (ví dụ ATM).

Hình 4.14: MEGACO/H.248 kết nối điều khiển Gateway (adsbygoogle = window.adsbygoogle || []).push({});

Trong phân hệ IMS, giao thức này hoạt động trên điểm tham chiếu Mn, Mp giao tiếp MRFC với MRFP và MGCF với IMS-MGW

Hình 4.15: Cấu trúc Gateway trong Megaco/H.248

 MGC: cung cấp báo hiệu SIP hoặc H.323 và thực hiện ánh xạ giữa các giao thức báo hiệu mạng chuyển mạch kênh truyền thống và giao thức báo hiệu IP.

 MG: cung cấp sự ánh xạ media và chức năng chuyển mã. Nó kết thúc tín hiệu

chuyển mạch kênh và tín hiệu media gói và thực hiện chuyển địa chỉ

 SG: cung cấp môi trường báo hiệu giữa miền IP và miền chuyển mạch kênh truyền thống.

4.4.3 Termination và Context

Megaco có hai khái niệm mang tính trừu tượng là: Termination và Context

4.4.3.1 Termination

Termination là một thực thể luận lý trên MG như là các nguồn hoặc các luồng điều khiển, … Termination có duy nhất một số nhận dạng (Termination ID) được phân phối bởi MG ở thời điểm chúng được tạo ra.

Termication còn biểu hiện cho các thực thể vật lý có thời gian tồn tại bán thường trú như một kênh TDM

Các tín hiệu có thể áp dụng lên các Termination, các tín hiệu này như là các thông báo. Các Termination cũng có thể được lập trình để phát hiện các sự kiện.

4.4.3.2 Context

Context là một sự kết hợp giữa một số Termination. Có một Context đặc biệt được gọi là Context rỗng. Nó chứa các Termination không kết hợp với các Termination khác. Các Termination rỗng có thể có các tham số được khảo sát hoặc sửa đổi và có thể có các sự kiện xảy ra trên chúng.

Số lượng Termination lớn nhất trong một Context phụ thuộc vào MG. Chẳng hạn, MG chỉ đưa ra kết nối điểm điểm thì có thể chỉ cho phép hai Termination trên một Context. Các MG hổ trợ các cuộc hội nghị đa điểm có thể cho phép 3 hoặc nhiều Termination trên một Context.

4.4.3.2.1 Thuộc tính của context

-contextID

-Mô hình (topology):Mô hình của context mô tả luồng media giữa các Termination trong một context.Ngược lại ,chế độ của Termination (nhận/ gữi) mô tả luồng media ở ngõ vào/ra của MG

-Sự ưu tiên được sử dụng cho một context để cung cấp cho MG thông tin về việc điều khiển ưu tiên .MGC cũng có thể điều khiển sự ưu tiên lưu lượng trong MG khi nhiều context phải được điều khiển đồng thời.

-Bộ chỉ thị (indicator) cho cuộc goi khẩn cấp cũng được cung cấp để cho phép việc điều khiển ưu tiên trong MG.

4.4.3.2.2 Tạo,Xóa và sửa đổi context

Megaco có thể được dùng để tạo context và sửa đổi các giá tri tham số của context đang tồn tại.Megaco có các lệnh để thêm Termination vào context,bỏ Termination ra khỏi context và di chuyển termination giữa các context.context bị xóa hoàn toàn khi Termination còn lại sau cùng bị xóa bỏ hoặc di chuyển khỏi Context.

4.4.4 Một số lệnh của Megaco

Add:lệnh add dùng để thêm một termination vào một context.lệnh Add trên Termination đầu tiên trong context được dùng để tạo context.

Modify:dùng để sửa đổi các thuộc tính,các sự kiện và các tín hiểu của termination

Subtract:dùng để ngắt một Termination từ một Context.lệnh này trên Termination sau cùng trong một Context dùng để xóa Context đó.

Move:dùng để chuyển Termination trong Context này đến Context khác.

Auditvalue:trả lại trạng thái hiện tại của các đặc tính,các sự kiện,các tín hiệu thống kê của Terminination.

Auditcapabilities:trả lại tất cả các giá trị đối với tính chất của Termination,các sự kiện và các tính hiệu được cho phép bởi MG

Notify:cho phép MG thông báo cho MGC biết các sự kiên xảy ra trong MG (adsbygoogle = window.adsbygoogle || []).push({});

ServiceChange:cho phép MG thông báp cho MGC rằng một Termination hoặc một nhóm Termination chuẩn bị rời khỏi hoặc trả lại dịch vụ.lệnh này cũng được dùng bởi MG để thông báo cho MGC sự sẵn sàng của nó.MGC cũng có thể thông báo chuyển giao tới MG bằng các lệnh gởi ServiceChange

4.4.5 hoạt động của MEGACO/H.248

Quá trình hoạt động của luồng giao thức MEGACO/H.248 như sau:

 Bước 1: MGC gửi bản tin Modify đến MG A và MG B để yêu cầu Termination phát hiện nhấc máy.

 Bước 2: Lệnh Modify được công nhận

 Bước 3: GW A phát hiện sự nhấc máy và gửi cho MGC.

 Bước 4: Xác nhận việc nhấc máy

 Bước 6, 7: GW A tích lũy các chữ số được quay từ người dùng và gởi các số này đến MGC trong lệnh Notify.

 Bước 8: MGC công nhận việc nhận các chữ số.

 Bước 9: MGC quyết định chuỗi số đúng và tạo cuộc gọi. Nó gởi lệnh Add đến