- Định hình: Là cơ chế dùng để giới hạn tốc độ của luồng dữ liệu bằng cách sử dụng các hàng đợi, thường được sử dụng khi dữ liệu đi từ đường
3.3.1.2. Đàm phán dịch vụ trong mạng lõ
Theo kiến trúc mới của IPTV thì SLNP cho phép quản lý chặt chẽ của QoSvà bảo mật.Giao thức SLNP sử dụng công nghệ dịch vụ Web đểcung cấp khả năng tương tác giữa các bên đàm phán hoặc các bộ phận khác nhau. Để đáp ứng yêu cầu đàm phán, sáu loạithông điệp được sử dụng trong quá trình đàm phán SLNP:
- Bản tin REVISION đề xuất một thay thế cho các cấp độ dịch vụ được yêu cầu, - Bản tin RESPONSE cho phép chấp nhận hoặc từ chối yêu cầu hoặc đề nghị, - Bản tin MODIFY được sử dụng để yêu cầu thay đổi mức độ phục vụ đã được thành lập,
- Bản tin NOTIFY được sử dụng để thông báo về những thay đổi trong khả nguồn lực hay sự tôn trọng không của một cấp độ dịch vụ,
- Bản tin RELEASE phép kết thúc một cấp độ dịch vụ đã được thành lập. Các thông điệp chứa một phần tử SLS. Nó đặc trưng cho mức độ dịch vụ thương lượng. Từ SLNP sử dụng dịch vụ Web, cấu trúc của phần tử SLS cũng như trong các thông báo khác được mô tả bằng cách sử dụng lược đồ XML.
- Cơ cấu SLS
Các yếu tố SLS vận chuyển trong các tin nhắn SLNP đề nghị cấp dịch vụ đàm phán cho truyền thông khác nhau (ví dụ: ToIP,VoD, IPTV,...) và phù hợp với các lược đồ XML
Hình 3.20: Lược đồ XML cho đàm phán SLS
Các thông số này có thể được xếp vào ba loại: Các tham số QoS, các thông số bảo mật và các thông số chung cho QoS và bảo mật. Các thông số chung cho bảo mật và QoS bao gồm: Nhận dạng SLS, xác định truyền thông, thông số đàm phán và độ tin cậy (Mean Down Time, Mean Time để sửa chữa). Các thông số QoS gồm có phạm vi, kế hoạch dịch vụ, đảm bảo hiệu suất (băng thông, Jitter, Delay, tỷ lệ
mất), mô tả và truyền tải phù hợp (Token Bucket…). Thành phần bảo đảm hiệu suất có thể coi là tham số QoS quan trọng nhất vì nó thực sự mô tả QoS end-to-end sẽ được bảo đảm bởi SLS thành lập sau một cuộc đàm phán SLNP. Mức QoS được mô tả bởi yếu tố này là độc lập với các mô hình QoS (DiffServ, IntServ, 802.11e, vv.) Các thông số QoS là bắt buộc bởi vì việc đàm phán phải ít nhất là liên quan đến QoS sau đó tác động bảo mật trên QoS phải được thiết lập và xem xét trong quá trình đàm phán. Để kiểm soát các tác động bảo mật trên QoS, Khi SLS đàm phán với SLNP sẽ chứa một phần tử thông số bảo mật là bao gồm: Phạm vi và giao thức bảo mật. Phạm vi này có thể khác nhau theo những quy định tại các tham số QoS.
- Xử lý SLNP
Giao thức SLNP có thể được sử dụng để đàm phán cấp độ dịch vụ trên một hoặc nhiều lĩnh vực trong mạng lõi. Đàm phán này nhằm thiết lập một SLS mà cho phép đảm bảo end-to-end QoS và bảo mật cho toàn bộ một nhóm multicast. Quá trình đàm phán xem Hình.3.21. Trong ví dụ này, việc đàm phán SLS liên quan đến việc quản lý các lĩnh vực khác nhau (DM1, DM2 DM3 và), máy chủ dữ liệu (CS), và các cổng thích nghi khác nhau(AG1, AG2 và AG3).
QoS và mức độ bảo mật chỉ phụ thuộc vào các dịch vụ IPTV cung cấp. Như vậy, mỗi AG mà muốn tham gia một nhóm multicast nên liên hệ với CS để biết các thông số của SLS đàm phán với các lĩnh vực khác nhau liên quan đến việc vận chuyển của dịch vụ IPTV yêu cầu. Xem Hình.3.21, SLS tương ứng với dịch vụ IPTV, được truyền tải từ CS với các AG khác nhau, được xác định thông qua các SLS được nêu ở Bảng 3.1.
Bảng 3.1: Các thông số kỹ thuật cấp dịch vụ cho IPTV
Đàm phán SLS trong mạng lõi được thực hiện như sau (xem Hình 3.22): Đầu tiên, AG1 liên hệ với CS để biết các thông số SLS cần cung cấp cho các dịch vụ
Mức độ QoS Mức độ Bảo mật
Trễ = 1000ms Bảo mật = Có - Cao
Jitter = 500ms Tính toàn vẹn = Có - cao Tỷ lệ mất mát = 5% Chống phát lại= Có Băng thông = 2500kbit/s
IPTV.Sau đó, nó có thể bắt đầu đàm phán bằng cách gửi một tin nhắn đàm phán cho DM1.Để giải quyết yêu cầu này (thương lượng), các DM1 phải tương tác với RMF của nó (Chức năng quả lý tài nguyên) để có được thông tin về QoS (chậm trễ, băng thông, …) có thể được địa phương cung cấp cho các kênh IPTV, cũng như các đặc điểm (thuật toán hỗ trợ và các giao thức, biểu diễn, vv) của các đơn vị có thực hiện giải quyết bảo mật. Nếu SLS yêu cầu của AG1 không thể được đáp ứng trong lĩnh vực đầu tiên (D1), thì một đáp ứng tiêu cực (Nack) được trả lại cho AG1. Nếu không, một phản ứng tích cực được trả lại cho AG1 này. Điều này liên quan đến việc tạo ra một nhóm multicast (MG) và đánh dấu của SLS tương ứng trong SR (SLS đăng ký) của DM1. Cuối cùng bảo mật và QoS có thể được kích hoạt bằng cách cấu hình các đối tượng có liên quan. Bây giờ, nếu AG2 muốn gia nhập MG, nó cũng phải tương tác với CS để biết các đặc điểm của SLS để thương lượng. Sau đó, việc đàm phán được bắt đầu bằng cách gửi một yêu cầu đàm phán (Negotiate) cho DM2. Sau khi hỏi RMF, các DM2 có thể từ chối yêu cầu hoặc chuyển tiếp nó đến DM1 sau đó cập nhật nó theo đề nghị địa phương (QoS và bảo mật).
Hình 3.21: Đàm phán SLS cho 1 nhóm Multicast
Thật vậy, yêu cầu của AG2 có thể bị từ chối nếu, ví dụ: Băng thông cần thiết hoặc các dịch vụ bảo mật cần thiết cho dịch vụ IPTV không thể được đảm bảo trong
D2. Nếu không, theo yêu cầu của AG2 (đàm phán) được chuyển tiếp đến DM1. Cuối cùng điều này có thể quyết định cho phép hay không cho phép AG2 tham gia MG. Nếu chúng ta xem xét, ví dụ: Tham số trễ, sau đó các thực thể thương lượng DM2 có để tính toán tổng thời gian trễ truyền trên D1 và D2 và kết quả từ các hoạt động an ninh. Sau đó, nếu tổng thời gian trễ lớn hơn thời gian trễ đặc trưng của dịch vụ IPTV (1000 ms), thì DM1 có thể từ chối yêu cầu của AG2. Khi phục vụ dịch vụ end-to-end (từ CS để AG2) đáp ứng các yêu cầu của dịch vụ IPTV, yêu cầu AG2 được chấp nhận và phản ứng tích cực (đáp ứng-Ack) được trả lại cho AG2 qua DM2, do đó phải ghi lại các SLS trên đó được tham gia. Như vậy, AG2 được thêm vào nhóm multicast và SLS đã đăng ký tại DM1 phải được cập nhật để giới thiệu AG2 trong AGS nhận được kênh IPTV. Cuối cùng, QoS và bảo mật có thể được cấu hình ở miền thứ hai.
Khi AG3 (thuộc lĩnh vực thứ ba) có tham gia MG để nhận được dịch vụ IPTV, đàm phán sẽ được thực hiện theo cách tương tự như mô tả ở trên. Tuy nhiên, quyết định được thực hiện, thời gian này, tại DM3 hoặc DM2. Khi đàm phán thành công, SLS tương thích với MG phải được đăng ký trên RS của DM3, và cập nhật tại DM1 và DM2.
Hình 3.22: Bảng sắp xếp các tin nhắn của đàm phán SLS trong mạng lõi
Khi một AG muốn bỏ nhóm multicast, nó phải gửi một yêu cầu xử lý đối tượng quản lý của miền. Trong thực tế, nếu tên miền có liên quan đến việc vận
chuyển của dịch vụ IPTV cho duy nhất một AG này, sau đó SLS tương ứng bị xóa từ SR của tên miền này và các nguồn tài nguyên dành riêng trong lĩnh vực này có thể được loại bỏ. Ngoài ra các DM khác trong IPTV multicast phải được nhận được thông báo này để từ bỏ cập nhật hồ sơ của chúng trên SLS của MG. Từ ví dụ này, SLNP cho phép đảm bảo mức độ end-to-end dịch vụ bao gồm đồng thời QoS và bảo mật cho AG khác nhau thuộc nhóm multicast.
