Không cần thiết phải thực hiện các tuỳ chọn DHCP Relay Agent (RFC 3046 [55]) trong HNED.
2.11.1.1 Các máy chủ DHCP không sử dụng
Nếu điều khiển từ xa của máy chủ DHCP không hoạt động vì một vài lý do, thì các dịch vụ trên mạng con vẫn sẽ được thực hiện, nhờ việc sử dụng địa chỉ cục bộ kết nối IETF Zero Configuration, tuy nhiên đây mới chỉ là phác thảo cho tháng 1 năm 2004.
2.11.1.2 Các máy chủ DHCP
Với tình trạng hiện tại, không cho phép nhiều máy chủ DHCP trên cùng một mạng mặc dù là có tác động tới bên trong hay bên ngoài DNG.
2.11.1.3 Định vị máy chủ DNS và cổng mặc định
Máy chủ DNS sẽ được định vị trên DHCP. Một cổng mặc định sẽ được nhận diện bởi DHCP
2.11.1.4 Chuẩn Plug and Play phổ biến
Hiện nay k hông có bất kỳ một yêu cầu nào về chuẩn Plug and Play trong HNED tuy nhiên nó vẫn được thêm vào như là một tuỳ chọn.
Dịch vụ thời gian mạng
HNED sẽ yêu cầu dịch vụ thời gian mạng là đồng hồ thực, đăng nhập và tuỳ chọn cho các luồng trung chuyển. Các dịch vụ này được chia làm 2 loại:
Dịch vụ thời gian mạng cho các ứng dụng như là đồng hồ thời gian thực chính xác tới 100ms
Dịch vụ thời gian mạng cho luồng trung chuyển với độ chính xác hơn 50ms. Cần lưu ý rằng cả hai dịch vụ có thể đồng thời tồn tại, tuy nhiên chỉ có một dịch vụ cần được thực hiện bởi HNED.
Đồng hồ thời gian thực hay các ứng dụng với độ chính xác là 100ms
Trong thời gian thực, đồng hồ được đưa vào triển khai bằng cách sử dụng RFC 2030[27], giao thức thời gian mạng đơn giản (SNTP) phiên bản 4 cho Ipv4, Ipv6, và OSI. địa chỉ cua rmáy chủ SNTP được tới từ tuỳ chọn thời gian của máy chủ DHCP.
Như một tuỳ chọn, mạng thời gian thực phiên bản 3 (chi tiết trong RFC 1305[20]) sẽ được triển khai thực hiện khi thời gian của các dịch vụ có độ chính xác từ 1ms tới 50ms là cần thiết. Địa chỉ IP máy chủ thời gian sẽ được lấy từ tuỳ chọn của thời gian mạng của máy chủ DHCP.
Xác thực các tác nhân cho truyền dịch vụ DVB trên mạng IP
Quá trình này là việc xác thực bắt buộc cho phép nhà cung cấp dịch vụ đưa ra dịch vụ xác thực để công nhận thiết bị đầu cuối của Home Network (HNED)
Dữ liệu gửi thời điểm bắt đầu và thời điểm thiết lập lại
Trong quá trình bắt đầu dịch vụ, thiết bị sẽ kiểm tra trường “siaddr” của máy chủ DHCP tiếp theo. Nếu trường “siaddr” được khởi tạo từ 0 hoặc là một địa chỉ IP không hợp lệ thì sẽ không có sự cho phép nào và cũng không có dữ liệu nào được gửi đi.
Nếu có một địa chỉ IP hợp lệ thì dữ liệu sẽ được gửi theo cơ chế chặn và theo yêu cầu kỹ thuật của HTTP phiên bản 1.1 :
'GET /dvb/boot?DeviceID=' deviceId '&Version=' version '&RAM=' ram '&Flash=' flash ' HTTP/1.1' CRLF
'Host: ' HOST CRLF
deviceID = manufacturer "/" [model] "/" clientID
ram = 1*(DIGIT) ; in KBytes e.g.: 262144 (256 MBytes) flash = 1*(DIGIT) ; in KBytes e.g.: 8192
Trong đó:
<deviceId> được sử dụng để xác định khi có yêu cầu của HNED về các thông tin:
<manufacturer> là tên duy nhất của nhà sản xuất. Nếu nhà sản xuất không muốn sử dụng thì “DVB-IPI Generic” sẽ được dùng theo mặc định, hoặc cũng có thể sử dụng theo tên của của các model khác nhau được sản xuất của nhà cung cấp đó.
<model> là tên mô hình duy nhất của riêng HNED
<clientId> là địa chỉ MAC của giao diện Ethernet, hoặc Eui-64 (là tên của giao diện IEEE 1394) kết nối với hệ thống quản lý mạng.
<version> được xác định là một chuỗi các phần mềm chạy trọng HNED
<ram> là dung lượng bộ nhớ RAM cài đặt trong thiết bị. Nếu dung lượng là 0 thì HNED chứa các model mặc định dung lượng RAM. Đơn vị này tính theo Kilobyte.
<flash> là dung lượng của bộ nhớ flash hoặc bộ nhớ read-only được cài đặt trong thiết b. Nếu Flash là 0 thì HNED sẽ chứa model mặc định dung lượng của Flash hay bộ nhớ trong. Đơn vị này tính theo Kilobytes.
HNED đánh giá dựa trên bản tin trả về từ các Event Gateway đơn giản để đảm bảo rằng nó chứa chuỗi 200 trạng thái thành công. Nếu chuỗi này không được trả về thì việc gửi lại sẽ được tiến hành theo cơ chế phát tránh.
Sau khi nhận được chuỗi báo trạng thái thành công này, các kết nối TCP sẽ bị đóng (dữ liệu không được trả về). Tín hiệu sẽ được phát ra để cho phép máy chủ và các hệ thống khác chuẩn bị thực hiện các bước tiếp theo, ví dụ như nâng cấp phần mềm trong HNED thành một phần mềm tải Provisioned Profile.
Cơ chế phá tránh
Một cơ chế phát tránh sẽ là bắt buộc trong trường hợp nguồn bị cắt, hay các nguyên nhân khách quan khác làm một lượng lớn các HNED gửi dữ liệu không thành công tại thời điểm khởi phát làm quá tải máy chủ cung cấp dịch vụ mạng.
Lúc đó HNED đều cố gắng bắt tín hiệu tới máy chủ, một bộ đếm Backoff được khởi động với giá trị là 2s. Ngay khi cố gắng thiết lập kết nối, một giá trị ngẫu nhiên giữa Backoff và 2*Backoff giây sẽ được áp dụng. Sau khi thiết lập kết nối bị thất bại, thời gian Backoff sẽ được tăng gấp đôi và kết nối sẽ được thử lại. Khi gấp đôi của Backoff trong thời gian quá tải thì việc cố gắng thiết lập được huỷ bỏ.
Mạng cung cấp (tuỳ chọn)
Quản lý mạng và cung cấp các tác nhân
Quản lý mạng và cung cấp tài liệu về cách cấu hình mạng HNED sẽ được đưa ra và HNED sẽ quản lý trên mạng IP nếu tuỳ chọn này được thực thi. Việc này sẽ chỉ định các giao thức và các định dạng XML DTD. Các DTD thông thường được cung cấp như file đính kèm.
Các giao thức HTTP và HTTPS
Có hai tuỳ chọn dựa theo sự cần thiết cho một kết nối mã hoá:
Giao thức HTTP [44] sẽ sử dụng cho tất cả các giao tiếp giữa HNED và hệ thống ở xa
Giao thức HTTPS [47] với TLS [33] sẽ được sử dụng cho tất cả các kết nối mã hoá giữa các HNED và hệ thống ở xa. Đây chính là sự ràng buộc đối với dữ liệu có liên quan tới bảo mật ví dụ như mất khẩu trong câu lệnh yêu cầu.
Chỉ có hai HTTP được sử dụng lệnh GET và POST theo định dạng chuẩn (sẽ được định nghĩa trong phần tiếp theo).
Cổng của địa chỉ IP và cơ chế tắt mạng cung cấp
Địa chỉ IP cổng của hệ thống quản lý mạng được phát hiện thông qua trường “siaddr” của DHCP [28] trả về từ máy chủ DHCP. Nếu máy chủ DHCP tiếp theo có trường siaddr là 0 thì mạng cung cấp/quản lý các sự kiện sẽ không cần phải thực thi
Định dạng HTTP GET
'GET /dvb/' request '?deviceID=' deviceID '&Password=' [password] ' HTTP/1.1' CRLF 'Host: ' host CRLF
request = 'configure' | 'event' | 'boot' password = 1*24(VCHAR)
<request> được sử dụng xác định cụ thể loại yêu cầu cụ thể: Xác định cấu hình cho yêu cầu về thông tin cấu hình.
Xác định sự kiện cho một yêu cầu về sự kiện.
Khởi động sự kiện theo định dạng khi bắt đầu hoặc khi khởi động lại. <deviceId> được sử dụng để xác định khi HNED có yêu cầu về thông tin:
<manufacturer> là tên duy nhất của nhà sản xuất. Nếu nhà sản xuất không muốn sử dụng tên thì “DVB-IPI Generic” sẽ được sử dụng theo mặc định. Nếu các nhà sản xuất không sử dụng tên riêng thì nó sẽ sử dụng tên của các model khác nhau của nhà nhà sản xuất đó.
<model> là tên model duy nhất của riêng mỗi HNED
<clientId> mà địa chỉ MAC của giao diện Ethernet hoặc Eui-64 định nghĩa bởi giao diện IEEE 1394 kết nối với các hệ thống quản lý mạng.
<password> được sử dụng để xác thực các HNED. Nếu không có có mật khẩu trong phần cấu hình, thì nó thể được bỏ qua
Chú ý: Các deviceId sẽ chứa các ký tự “/”; tiến trình của những yêu cầu này sẽ được đưa vào tài khoản người dùng.
Các lết quỉa sẽ được phân phát trên XML DTD phù hợp với yêu cầu: một yêu cầu cấu hình sẽ trả về một định dạng XML cấu hình, một yêu cầu khởi động sẽ được trả về một thành phần định dạng XML.
Yêu cầu GET có thể được chứa trong tiêu đề khác như định dạng trong RFC 2616[44] Ví dụ : GET /dvb/boot?DeviceID=Cisco/IP100/010203040506&Password=SomeSecret HTTP/1.1 Host: provisioneer.sp.net Content-type: text/xml
CHƢƠNG 3: CẤU TRÚC HỆ THỐNG IPTV ÁP DỤNG TRONG TẬP ĐOÀN ĐIỆN LỰC VIỆT NAM