›

Giáo trình Mạng máy tính - Chương 7: Mạng đa phương tiện

pdf 89 trang huongle 4380
Download
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Mạng máy tính - Chương 7: Mạng đa phương tiện", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pdfgiao_trinh_mang_may_tinh_chuong_7_mang_da_phuong_tien.pdf

Nội dung text: Giáo trình Mạng máy tính - Chương 7: Mạng đa phương tiện

  1. Chương 7 Mạng đa phương tiện A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). Computer They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. Networking: A Top They obviously represent a lot of work on our part. In return for use, we only ask the following: Down Approach  If you use these slides (e.g., in a class) that you mention their source th (after all, we’d like people to use our book!) 6 edition  If you post any slides on a www site, that you note that they are adapted Jim Kurose, Keith Ross from (or perhaps identical to) our slides, and note our copyright of this Addison-Wesley material. March 2012 Thanks and enjoy! JFK/KWR All material copyright 1996-2012 J.F Kurose and K.W. Ross, All Rights Reserved Mạng đa phương tiện 7-1
  2. Mạng đa phương tiện: Nội dung 7.1 các ứng dụng mạng đa phương tiện 7.2 video được lưu trữ theo luồng (streaming stored video) 7.3 voice-over-IP 7.4 các giao thức cho các ứng dụng đàm thoại thời gian thực 7.5 hỗ trợ của mạng cho đa phương tiện Mạng đa phương tiện 7-2
  3. Mạng đa phương tiện: Nội dung 7.1 các ứng dụng mạng đa phương tiện 7.2 video được lưu trữ theo luồng (streaming stored video) 7.3 voice-over-IP 7.4 các giao thức cho các ứng dụng đàm thoại thời gian thực 7.5 hỗ trợ của mạng cho đa phương tiện Mạng đa phương tiện 7-3
  4. Đa phương tiện: âm thanh  Tín hiệu âm thanh analog được lấy mẫu với tốc độ Lỗi lượng tử Lượng giá trị không đổi hóa của giá trị . telephone: 8,000 analog mẫu/giây Tín hiệu . CD music: 44,100 analog mẫu/giây  Mỗi mẫu được lượng tự hóa, amplitudesignalaudio có nghĩa là được làm tròn time . Ví dụ: 28=256 quantized Tốc độ lấy mẫu values (giá trị lượng tử (N mẫu/giây) hóa) có thể . Mỗi lượng giá trị được biểu diễn bằng các bit, ví dụ 8 bit cho 256 giá trị Mạng đa phương tiện 7-4
  5. Đa phương tiện: âm thanh  Ví dụ: 8,000 mẫu/giây, 256 quantized values (giá trị ượ ử Lỗi lượng tử Lượng giá trị l ng t hóa): 64,000 bps hóa của giá trị  Bên nhận chuyển đổi các analog bit trở lại tín hiệu analog: Tín hiệu . Một số suy giảm chất analog lượng audio signal amplitudesignalaudio example tốc độ time  CD: 1.411 Mbps Tốc độ lấy mẫu (N mẫu/giây)  MP3: 96, 128, 160 kbps  Thoại Internet: 5.3 kbps Mạng đa phương tiện 7-5
  6. Ví dụ mã hóa không gian: thay vì Đa phương tiện: video gửi N giá trị cùng màu (tất cả đều màu tím), chỉ gửi 2 giá trị:  video: chuỗi các hình ảnh giá trị màu(tím) và số giá trị lặp được hiển thị với tốc độ lại (N) không đổi . Ví dụ 24 hình/giây  Hình ảnh kỹ thuật số: mảng của các điểm ảnh (array of pixels) . Mỗi pixel được diễn tả bởi bit frame i  Mã hóa: sử dụng sự dư thừa bên trong và giữa các ảnh để giảm số lượng bit được Ví dụ mã hóa thời gian: sử dụng để mã hóa hình ảnh thay vì gửi toàn bộ frame tại i+1, chỉ cần gửi sự . Không gian (trong ảnh) khác nhau so với frame i . Thời gian (từ ảnh này sang ảnh kế tiếp) frame i+1 Mạng đa phương tiện 7-6
  7. Ví dụ mã hóa không gian: thay vì gửi N giá trị cùng màu (tất cả Đa phương tiện: video đều màu tím), chỉ gửi 2 giá trị: giá trị màu(tím) và số giá trị lặp lại (N)  CBR: (constant bit rate): tốc độ mã hóa video được cố định  VBR: (variable bit rate): tốc độ mã hóa video thay đổi khi số lượng mã hóa không gian và thời gian thay đổi  Ví dụ: frame i . MPEG 1 (CD-ROM) 1.5 Mbps Ví dụ mã hóa thời gian: . MPEG2 (DVD) 3-6 thay vì gửi toàn bộ frame Mbps tại i+1, chỉ cần gửi sự khác nhau so với frame i . MPEG4 (thường được sử dụng trên Internet, < 1 Mbps) frame i+1 Mạng đa phương tiện 7-7
  8. Mạng đa phương tiện: 3 loại ứng dụng  Streaming (liên tục), stored (lưu) audio, video . streaming: có thể bắt đầu trình chiếu trước khi tải về toàn bộ tập tin . stored (tại máy chủ): có thể truyền nhanh hơn audio/video sẽ được trình chiếu (lưu/đệm tại client) . Ví dụ: YouTube, Netflix, Hulu  Đàm thoại voice/video trên nền IP . Bản chất tự nhiên của cuộc đối thoại giữa người và người giới hạn giải ổn định độ trễ (delay tolerance) . Ví du: Skype  streaming live (trực tiếp) audio, video . Ví dụ: sự kiên thể thao trực tiếp (bóng đá) Mạng đa phương tiện 7-8
  9. Mạng đa phương tiện: Nội dung 7.1 các ứng dụng mạng đa phương tiện 7.2 video được lưu trữ theo luồng (streaming stored video) 7.3 voice-over-IP 7.4 các giao thức cho các ứng dụng đàm thoại thời gian thực 7.5 hỗ trợ của mạng cho đa phương tiện Mạng đa phương tiện 7-9
  10. Video được lưu trữ theo dòng (Streaming stored video): 2. Video được gửi 1. Video 3. video được nhận, được ghi lại Độ trễ mạng được trình chiếu tại client (ví dụ 30 (cố định trong (30 frames/sec) time frames/sec) ví dụ này) streaming: tại thời điểm này, client đang trình diễn phần đầu của video, trong khi server vẫn đang tiếp tục gửi phần sau của video Mạng đa phương tiện 7-10
  11. Video được lưu trữ theo dòng : thách thức  Sự hạn chế trình diễn liên tục: khi bắt đầu trình diễn, phát lại phải phù hợp với sự định giờ ban đầu (original timing) . tuy nhiên độ trễ của mạng là thay đổi (biến đổi đột ngột), do đó sẽ cần bộ đệm bên phía client (client-side buffer) để phù hợp với yêu cầu của việc phát lại  Các thách thức khác: . Sự tương tác của client: tạm dừng, qua nhanh, xem lại, qua một video khác . Các packet của video có thể bị mất hoặc được truyền lại Mạng đa phương tiện 7-11
  12. Video được lưu trữ theo dòng : xem lại truyền video tốc độ Nhận video client trình diễn bit không đổi phía khách hàng video với tốt độ bit không đổi Độ trễ mạng có khả năng thay đổi Video được đệm độ trễ trình time diễn tại phía client  Đệm tại phía client và độ trễ trình chiếu: bù lại cho độ trễ mạng, biến đổi đột ngột của độ trễ Mạng đa phương tiện 7-12
  13. Trình diễn và đệm tại phía client buffer fill level, (mức độ làm đầy bộ đệm) Q(t) variable fill Tốc độ trình diễn, rate, x(t) Ví dụ: CBR r (tốc độ làm đầy biến thiên) ứng dụng client video server buffer, size B client Mạng đa phương tiện 7-13
  14. Trình diễn và đệm tại phía client buffer fill level, (mức độ làm đầy bộ đệm) Q(t) variable fill Tốc độ trình diễn, rate, x(t) Ví dụ: CBR r (tốc độ làm đầy biến thiên) ứng dụng client video server buffer, size B client 1. Khởi tạo làm đầy bộ đệm cho tới khi trình diễn bắt đầu tại tp 2. Trình diễn bắt đầu tại tp, 3. Mức độ làm đầy bộ đệm (buffer fill level) biến thiên theo thời gian khi tốc độ làm đầy (fill rate) x(t) biến thiên và tốc độ trình diễn (playout rate) r là không đổi Mạng đa phương tiện 7-14
  15. Trình diễn và đệm tại phía client buffer fill level, (mức độ làm đầy bộ đệm) Q(t) variable fill Tốc độ trình diễn, rate, x(t) e.g., CBR r (tốc độ làm đầy biến thiên) ứng dụng client video server buffer, size B Đệm trình diễn: tốc độ làm đầy trung bình (average fill rate) (x), tốc độ trình diễn (playout rate) (r):  x r: bộ đệm sẽ không bị cạn, độ trễ trình diễn được ước lượng ban đầu là đủ lớn để đáp ứng sự biến đổi trong x(t) . Sự cân bằng độ trễ trình diễn khởi đầu (initial playout delay tradeoff): sự cạn kiện bộ đệm ít có khả năng với độ trễ lớn hơn, nhưng độ trễ lớn hơn cho đến khi người7-15 dùng bắt đầu trình diễn video Mạng đa phương tiện
  16. Đa phương tiện Streaming: UDP  server gửi với tốc độ thích hợp cho client . Thông thường: tốc độ gửi = tốc độ mã hóa (encoding rate) = tốc độ không đổi (constant rate) . Tốc độ truyền có thể không biết gì về mức độ tắc nghẽn  Độ trễ trình diễn ngắn (2-5 giây) để loại bỏ sự biến đổi đột ngột của mạng (network jitter)  Phục hồi lỗi: tầng ứng dụng, thời gian cho phép  RTP [RFC 2326]: các loại payload đa phương tiện  UDP có thể sẽ không đi qua tường lửa Mạng đa phương tiện 7-16
  17. Đa phương tiện Streaming: HTTP  Tập tin đa phương tiện được lấy thông qua HTTP GET  Gửi với tốc độ cao nhất có thể dưới TCP variable rate, x(t) video TCP send TCP receive application file buffer buffer playout buffer server client  Tốc độ làm đầy (fill rate) biến độ do điều khiển tắc nghẽn TCP (TCP congestion control), truyền lại (vận chuyển theo thứ tự)  Độ trễ trình diễn lớn hơn: tốc độ vận chuyển TCP mượt mà hơn  HTTP/TCP đi qua tường lửa dễ dàng hơnMạng đa phương tiện 7-17
  18. Đa phương tiện Streaming: DASH  DASH: Dynamic, Adaptive Streaming over HTTP  server: . Chia tập tin video thành nhiều khối nhỏ (chunk) . Mỗi khối được lưu, mã hóa với các tốc độ khác nhau . Tập tin biểu hiện (manifest file): cung cấp URL cho các khối khác nhau  client: . Định kỳ đo băng thông từ server tới client . Tư vấn biểu hiện (consulting manifest), yêu cầu 1 khối nhỏ (chunk) tại 1 thời điểm • Chọn tốc độ mã hóa lớn nhất phù hợp với băng thông hiện tại được cho • Có thể chọn các tốc độ mã hóa khác nhau tại các thời điểm khác nhau (phụ thuộc vào băng thông có thể dùng tại thời điểm đó) Mạng đa phương tiện 7-18
  19. Đa phương tiện Streaming: DASH  DASH: Dynamic, Adaptive Streaming over HTTP  “thông minh” tại client: client xác định . Khi nào (when ) yêu cầu chunk (khối nhỏ) (để mà cạn kiệt tràn bộ đệm không xảy ra) . Yêu cầu Bao nhiêu tốc độ mã hóa (what encoding rate) (chất lượng tốt hơn khi nhiều băng thông hơn) . Khi nào (where ) yêu cầu chunk (có thể yêu cầu từ URL server “gần” client hoặc có băng thông sẵn dùng cao) Mạng đa phương tiện 7-19
  20. Mạng phân phối nội dung  Thách thức: làm thế nào để truyền tải nội dung (được lựa chọn từ hàng triệu video) đến hàng trăm ngàn khách hàng đồng thời?  Lựa chọn 1: 1 “mega-server” lớn . 1 điểm chịu lỗi . Điểm tắt nghẽn mạng . Đường đi dài đến các khách hàng ở xa . Nhiều bản sao của video được gửi qua đường liên kết đi .khá đơn giản: giải pháp này không thể phát triển được Mạng đa phương tiện 7-20
  21. Mạng phân phối nội dung  Thách thức: làm thế nào để truyền tải nội dung (được lựa chọn từ hàng triệu video) đến hàng trăm ngàn khách hàng đồng thời?  Lựa chọn 2: lưu trữ/phục vụ nhiều bản sao của video tại nhiều site được phân tán theo địa lý (multiple geographically distributed sites) (CDN) . enter deep: đẩy các server CDN vào sâu bên trong nhiều mạng truy cập • Gần với người dùng • Được sử dụng bởi Akamai, 1700 địa điểm . bring home: số lượng nhỏ hơn (10’s) của các cụm (cluster) lớn hơn trong các POPs gần (nhưng không bên trong) các mạng truy cập • Được sử dụng bởi Limelight Mạng đa phương tiện 7-21
  22. CDN: tình huống truy cập nội dung “đơn giản” Bob (client) yêu cầu video . video được lưu trữ tại CDN tại 1. Bob lấy URL cho video từ trang web netcinema.com 2. Phân giải 2 thông qua DNS nội bộ của Bob 1 6. Yêu cầu video từ 5 KINGCDN server, được 4&5. phân giải truyền thông qua HTTP thông qua DNS có thẩm quyền của 3. DNS của netcinema trả về URL netcinema.com 4 KingCDN, cái mà sẽ trả về địa chỉ IP của KIingCDN server với video 3 netcinema’s authorative DNS KingCDN.com KingCDN authoritative DNS Mạng đa phương tiện 7-22
  23. CDN chiến lược lựa chọn cluster  Thách thức: làm thế nào để CDN DNS lựa chọn CDN node “tốt” để truyền tới client . Chọn CDN node có vị trí địa lý gần với client . Chọn CDN node với độ trễ ít nhất (hoặc với số lượng hop nhỏ nhất) tới client (các CDN node định kỳ ping tới nhà cung cấp dịch vụ Internet truy cập, báo cáo kết quả tới CDN DNS) . IP anycast  Cách khác: choclient quyết định- cho client 1 danh sách chứa 1 vài CDN server . client ping đến các servers, chọn cái “tốt nhất” . Cách tiếp cận Netflix Mạng đa phương tiện 7-23
  24. Case study: Netflix  30% lưu lượng US tải xuống trong năm 2011  Sở hữu rất ít cơ sở hạ tầng, dùng dịch vụ bên thứ 3: . Đăng ký riêng (own registration), các server thanh toán (payment servers) . Dịch vụ đám mây Amazon (bên thứ 3) : • Netflix tải lên studio master tới đám mấy (clound) Amazon • Tạo nhiều phiên bản của phim (mã hóa khác nhau) trong đám mây (cloud) • Tải lên các phiên bản từ đám mây (cloud) tới các CDN • Đám mây (clound) lưu trữ các trang web của Netflix cho người sử dụng duyệt . 3 CDN của bên thứ ba lưu trữ/truyền (host/stream) nội dung Netflix: Akamai, Limelight, Level-3 Mạng đa phương tiện 7-24
  25. Case study: Netflix Tải lên các bản sao của Đám mây nhiều phiên bản của Amazon video tới các CDN Akamai CDN Đăng ký Netflix , accounting servers 3. Tập tin Manifest 2. Bob duyệt được trả về cho video được yêu cầu Limelight CDN Netflix video 2 3 1 1. Bob quản lý tài khoản Netflix Level-3 CDN 4. DASH streaming Mạng đa phương tiện 7-25
  26. Mạng đa phương tiện: Nội dung 7.1 các ứng dụng mạng đa phương tiện 7.2 video được lưu trữ theo luồng (streaming stored video) 7.3 voice-over-IP 7.4 các giao thức cho các ứng dụng đàm thoại thời gian thực 7.5 hỗ trợ của mạng cho đa phương tiện Mạng đa phương tiện 7-26
  27. Voice-over-IP (VoIP)  Yêu cầu về độ trễ giữa 2 đầu cuối VoIP: cần thiết để duy trì “cuộc gọi” . Độ trễ cao hơn sẽ làm giảm sự tương tác . 400 mili giây xấu . Bao gồm tầng application (gói thoại,trình diễn), độ trễ mạng  Khởi tạo phiên (session initialization): làm cách nào người được gọi (callee) quảng cáo địa chỉ IP, số hiệu port, thuật toán mã hóa?  Các dịch vụ giá trị gia tăng (value-added ): chuyển tiếp , sàn lọc, ghi âm  Dịch vụ khẩn cấp: 911 Mạng đa phương tiện 7-27
  28. Các đặc điểm VoIP  Âm thanh của người nói: luân phiên các talk spurt, khoảng thời gian im lặng. . 64 kbps trong suốt talk spurt . Các packet chỉ được tạo ra trong talk spurts . Các khối nhỏ (chunk) 20 mili giây tại tốc độ 8 Kbytes/giây: 160 byte dữ liệu  Header của tầng application được thêm vào mỗi chunk  Chunk và header được đóng gói vào trong segment UDP hoặc TCP  Ứng dụng gửi segment vào trong socket mỗi 20 giây trong khoảng thời gian talkspurt Mạng đa phương tiện 7-28
  29. VoIP: trễ và mất gói  Mất gói do mạng (network loss): IP datagram bị mất do tắt nghẽn mạng (router buffer overflow)  Mất gói do độ trễ (delay loss): IP datagram đến quá trễ cho trình diễn tại nơi nhận . Trễ: xử lý, xếp hàng trong mạng; trễ ở hệ thống đầu cuối (bên gửi và nhận) . Độ trễ có thể chấp nhận được tối đa thông thường: 400 mili giây  Khả năng chịu mất gói (Loss tolerance): phụ thuộc vào mã hóa âm thanh, sự che đậy mất mát (loss concealment), tỷ lệ mất gói giữa 1% và 10% có thể chịu đựng được Mạng đa phương tiện 7-29
  30. Biến động sự chậm trễ (Delay jitter) truyền video tốc độ Nhận phía client trình diễn bit không đổi khách hàng video với tốt độ bit không đổi Độ trễ mạng hay thay đổi (jitter) data buffered độ trễ trình time diễn tại phía client  Sự chậm trễ giữa 2 đầu cuối của 2 packet liên tục: sự khác biệt có thể nhiều hơn hoặc ít hơn 20 giây (sự khác biệt thời gian truyền) Mạng đa phương tiện 7-30
  31. VoIP: sự chậm trễ trình diễn cố định  Bên nhận cố gắng trình diễn mỗi chunk chính xác thời gian q mili second sau khi chunk đó được tạo ra. . chunk có time stamp t: trình diễn chunk tại t+q . chunk đến sau khi dữ liệu t+q: đến quá trễ để trình diễn: dữ liệu “bị mất”  Sự cân bằng trong việc chọn q: . q lớn: ít mất gói . q nhỏ: trải qua tương tác tốt Mạng đa phương tiện 7-31
  32. VoIP: sự chậm trễ trình diễn cố định . bên gửi tạo ra các packet mỗi 20 mili giây trong suốt thời gian talk spurt. . packet đầu tiên được nhận tại thời gian r . Lịch trình biểu diễn đầu tiên: bắt đầu tại p . Lịch trình biểu diễn thứ 2: bắt đầu tại p’ packets packets loss generated packets playout schedule received p' - r playout schedule p - r time r Mạng đa phương tiện 5-32 p p'
  33. Sự chậm trễ trình diễn thích nghi (Adaptive playout delay) (1)  Mục tiêu: sự chậm trễ trình diễn thấp, tỷ lệ mất gói do chậm trễ thấp  Hướng tiếp cận: Điều chỉnh sự chậm trễ trình diễn thích nghi (adaptive playout delay adjustment): . Ước lượng độ trễ mạng, điều chỉnh độ trễ trình diễn tại lúc bắt đầu của mỗi talk spurt . Khoảng thời gian im lặng được nén và được kéo dài . Các chunk vẫn được trình diễn mỗi 20 mili giây trong khoảng thời gian talk spurt  Ước lượng một cách thích nghi độ trễ packet: (EWMA - exponentially weighted moving average, xem lại ước lượng TCP RTT): di = (1-a)di-1 + a (ri – ti) Ước lượng độ small constant, time received - time sent trễ sau packet ví dụ. 0.1 (timestamp) thứ i Độ trễ được đó của gói thứ i Mạng đa phương tiện 7-33
  34. Sự chậm trễ trình diễn thích nghi (Adaptive playout delay) (2)  cũng hữu dụng để ước tính độ lệch trung bình của sự chậm trễ, vi : vi = (1-b)vi-1 + b |ri – ti – di|  Ước lượng di, vi được tính toán cho tất cả các packet nhận được, nhưng chỉ được sử dụng lúc bắt đầu talk spurt  Với packet đầu tiên trong talk spurt, thời gian trình diến là : playout-timei = ti + di + Kvi Các packet còn lại trong talkspurt được trình diễn theo định kỳ Mạng đa phương tiện 5-34
  35. Sự chậm trễ trình diễn thích nghi (Adaptive playout delay) (3) Q: làm thế nào để bên nhận xác định xem packet là packet đầu tiên hay không trong 1 talkspurt?  Nếu không có mất mát, bên nhận xem xét các timestamp kế tiếp . Sự khác biệt của các stamp kế tiếp > 20 msec >talk spurt bắt đầu.  Với mất gói có khả năng xảy ra, bên nhận phải xem xét ở cả time stamp và số thứ tự . Sự khác biệt của stamp kế tiếp > 20 msec và số thứ tự không có khoảng cách > talk spurt bắt đầu. Mạng đa phương tiện 7-35
  36. VoiP: phục hồi mất gói (1) Thách thức: khôi phục từ việc mất gói với độ trễ có thể chịu đựng nhỏ giữa việc truyền ban đầu và trình chiếu  Mỗi ACK/NAK mất khoảng 1 RTT  Cách khác: Forward Error Correction (FEC) . Gửi vừa đủ có bit để cho phép khôi phục mà không cần phải truyền lại (xem lại two-dimensional parity ở chương 5) FEC đơn giản  Với mỗi nhóm của n chunk, tạo chunk dự phòng bằng cách XOR n chunk gốc  Gửi n+1 chunk, băng thông tăng 1/n  Có thể tái tạo lại n chunk gốc nếu nhiều nhất 1 chunk bị mất từ n+1 chunk, với sự chậm trễ trình diễn Mạng đa phương tiện 7-36
  37. VoiP: phục hồi mất gói (2) Một FEC scheme khác: “mang thêm dòng âm thanh có chất lượng thấp hơn” Gửi một dòng âm thanh có chất lượng thấp hơn như là các thông tin dư thừa Ví dụ: dòng âm thanh danh nghĩa (nominal stream) là một PCM mã hóa 64 kbps và Dòng dư thừa là mã GSM mã hóa 13 kbps Mất gói không liên tiếp: bên nhận có thể che giấu sự mất mát generalization: có thể phụ thêm chunk low-bit rate thứ (n-1) và (n-2) Mạng đa phương tiện 7-37
  38. VoiP: phục hồi mất gói (3) Đan xen để che giấu sự mất mát  Nếu packet bị mất mát, thì vẫn còn có hầu hết  Các khối (chunk) audio được tất cả chunk ban đầu chia thành các khối nhỏ hơn, ví dụ: 4 khối nhỏ 5 mili giây cho  Không có dư thừa, tuy mỗi khối audio 20 mili giây nhiên độ trễ trình diễn sẽ tăng  packet chứa các khối nhỏ (small units) khác với các khối (chunk) Mạng đa phương tiện 7-38
  39. Voice-over-IP: Skype  Giao thức tầng application độc quyền (được suy ra thông qua kỹ Skype clients (SC) thuật đảo ngược (reverse engineering)) . Thông điệp được mã hóa Skype  ầ Các thành ph n P2P: login server supernode (SN) . clients: các peer skype kết nối trực supernode overlay tiếp với nhau cho network cuộc gọi VoIP . super nodes (SN): các peer skype với các chức năng đặc biệt . overlay network: giữa các SN để xác định vị trí SCs . login server Tầng Application 2-39
  40. P2P voice-over-IP: skype Hoạt động của skype client: 1. Tham gia mạng skype bằng cách liên lạc với SN (địa chỉ IP được cache lại) Skype dùng TCP login server 2. Đăng nhập (usename, password) vào máy chủ tập trung đăng nhập skype (centralized skype login server) 3. Lấy được địa chỉ IP cho người được gọi (callee) từ SN, SN overlay . Hoặc danh sách bạn của client 4. Khởi tạo cuộc gọi trực tiếp đến người được gọi (callee) Tầng Application 2-40
  41. Skype: các peer hành động như chuyển tiếp (peers as relays)  Vấn đề: cả Alice và Bob đều ở đằng sau “NAT” . NAT ngăn chặn peer bên ngoài khởi tạo kết nối tới peer bên trong . peer bên trong có thể khởi tạo kết nối ra bên ngoài  Giải pháp chuyển tiếp : Alice và Bob duy trì kết nối mở tới các SN của họ . Alice gửi tín hiệu tới SN của cô ta để kết nối tới Bob . SN của Alice kết nối tới SN Bob . SN Bob kết nối tới Bob thông qua kết nối đã mở mà Bob ban đầu đã khởi tạo tới SN của anh ta Tầng Application 2-41
  42. Mạng đa phương tiện: Nội dung 7.1 các ứng dụng mạng đa phương tiện 7.2 video được lưu trữ theo luồng (streaming stored video) 7.3 voice-over-IP 7.4 các giao thức cho các ứng dụng đàm thoại thời gian thực 7.5 hỗ trợ của mạng cho đa phương tiện Mạng đa phương tiện 7-42
  43. Real-Time Protocol (RTP)  RTP quy định cụ thể  RTP chạy ở các hệ cấu trúc của packet thống đầu cuối cho các packet  Các packet RTP được mang dữ liệu audio đóng gói trong và video segment UDP  RFC 3550  Khả năng tương tác:  RTP packet cung nếu 2 ứng dụng VoIP cấp chạy RTP, chúng có . Xác định loại thể làm việc cùng payload nhau . Đánh số thứ tự packet . time stamping Mạng đa phương tiện 7-43
  44. RTP chay phía trên UDP Thư viện RTP cung cấp Interface tầng transport, cái mà mở rộng UDP: • số hiệu port, địa chỉ IP • xác định loại payload • đánh số thứ tự packet • time-stamping Mạng đa phương tiện 5-44
  45. RTP ví dụ Ví dụ: gửi 64 kbps PCM-  RTP header chỉ ra giọng nói được mã hóa loại mã hóa audio trên RTP trong mỗi packet  ứng dụng thu thập dữ . Bên gửi có thể thay liệu được mã hóa đổi mã hóa trong trong các chunks, ví cuộc đàm thoại dụ: mỗi 20 mili giây =  RTP header cũng 160 bytes trong 1 chưa số thứ tự và chunk timestamps  audio chunk + RTP header từ RTP packet, cái mà được mã hóa trong segment UDP Mạng đa phương tiện 7-45
  46. RTP và QoS  RTP không cung cấp bất kỳ cơ chế nào để bảo đảm phân phát dữ liệu kịp thời hoặc các bảo đảm QoS khác  Sự đóng gói của RTP chỉ được thấy tại các hệ thống đầu cuối (không thấy tại các router trung gian) . Các router cung cấp dịch vụ best-effort, không có nổ lực đặc biệt nào (special effort) để đảm bảo rằng các packet RTP đến đích kịp thời Mạng đa phương tiện 7-46
  47. RTP header payload Miscellaneous sequence time stamp Synchronization type number Source ID fields type Loại payload (7 bits): cho biết loại mã hóa hiện tại đang được sử dụng. Nếu bên gửi thay đổi mã hóa trong quá trình cuộc gọi, thì bên gửi sẽ thông báo bên nhận thông qua trường payload type Payload type 0: PCM mu-law, 64 kbps Payload type 3: GSM, 13 kbps Payload type 7: LPC, 2.4 kbps Payload type 26: Motion JPEG Payload type 31: H.261 Payload type 33: MPEG2 video sequence # (16 bits): tăng 1 cho mỗi packet RTP được gửi  Phát hiện mất packet, khôi phục chuỗi packet Mạng đa phương tiện 5-47
  48. RTP header payload Miscellaneous sequence time stamp Synchronization type number Source ID fields type  timestamp field (dài 32 bit): lấy mẫu byte đầu tiên trong packet dữ liệu RTP . Với audio, đồng hồ timestamp tăng 1 cho mỗi thời kỳ lấy mẫu (ví du: mỗi 125 usecs cho 8 KHz sampling clock) . Nếu ứng dụng tạo các chunk của 160 mẫu được mã hóa, thì timestamp sẽ tăng 160 cho mỗi RTP packet khi nguồn hoạt động. Đồng hồ Timestamp tiếp tục tăng với tốc độ không đổi khi nguồn hoạt động.  SSRC field (dài 32 bits): xác định nguồn của một luồng RTP. Mỗi luồng trong phiên RTP có SSRC riêng biệt Mạng đa phương tiện 7-48
  49. RTSP/RTP programming assignment  Xây dựng server đóng gói các frame video được lưu trữ vào trong packet RTP . Chụp lấy frame video, thêm vào RTP header, tạo UDP segments, và gửi segments tới UDP socket . Bao gồm số thứ tự và time stamps . client RTP được cung cấp cho bạn  Đồng thời cũng viết phía client của RTSP . Các lệnh play/pause . server RTSP được cung cấp cho bạn Mạng đa phương tiện 7-49
  50. Real-Time Control Protocol (RTCP)  Hoạt động kết hợp  Mỗi packet RTCP chứa với RTP các báo cáo của bên gửi ặ ậ  Mỗi bên tham gia và/ho c bên nh n trong phiên RTP định . Các thông kê báo cáo là ử hữu ích cho ứng dụng: số kỳ g i các packet lượng packet được gửi, RTCP điều khiển tới số lượng packet bị mất, các bên tham gia interarrival jitter khác  Thông tin phản hồi được sử dụng để kiểm soát hiệu suất . Bên gửi có thể thay đổi việc truyền của nó dựa trên thông tin phản hồi Mạng đa phương tiện 7-50
  51. RTCP: nhiều bên gửi multicast sender RTP RTCP RTCP RTCP receivers Mỗi phiên RTP: thường là 1 địa chỉ multicast duy nhất; tất cả các packet RTP /RTCP mà thuộc về phiên này dùng địa chỉ multicast Các packet RTP, RTCP được phân biệt với nhau thông qua các số hiệu port riêng biệt Giới hạn lưu lượng, mỗi bên tham gia giảm lưu lượng RTCP khi số lượng các bên tham gia cuộc gọi tăng lên. Mạng đa phương tiện 5-51
  52. RTCP: các loại packet Packet báo cáo bên Packet mô tả nguồn nhận (receiver (source description report packets): packets):  Phần nhỏ của packet bị  Địa chỉ e-mail của bên gửi, mất, số thứ tự cuối cùng, tên của bên gửi, SSRC interarrival jitter trung của RTP stream liên quan bình  Cung cấp ánh xạ giữa Packet báo cáo bên gửi SSRC này và tên của (sender report user/host này packets):  SSRC của RTP stream, thời gian hiện tại, số lượng các packet được gửi, số lượng byte được gửi Mạng đa phương tiện 7-52
  53. RTCP: đồng bộ hóa stream  RTCP có thể đồng bộ hóa  Mỗi RTCP sender-report các stream phương tiện packet bao gồm (các packet truyền thông (different được tạo ra gần đây nhất media streams ) khác trong các RTP stream kết nhau trong 1 phiên làm hợp): việc RTP . timestamp của RTP  Ví dụ: ứng dụng hội nghị packet qua video: mỗi bên gửi tạo . wall-clock time khi các ra RTP stream độc lập, 1 packet được tạo ra dành cho video và 1 cho  Bên nhận sẽ dùng sự kết hợp audio. này để đồng bộ hóa trình  Các video và audio lấy diễn của audio, video mẫu có gắn timestamp nhưng không gắn wall- clock time Mạng đa phương tiện 7-53
  54. RTCP: mở rộng băng thông (bandwidth scaling) RTCP cố gắng giới hạn  75 kbps được chia đều cho lưu lượng của nó tới 5% các bên nhận: băng thông của phiên . Với R bên nhận, mỗi bên nhận ệ sẽ gửi lưu lượng RTCP với tốc làm vi c độ 75/R kbps.  Bên gửi gửi lưu lượng RTCP ụ ử ử ớ Ví d : bên g i g i video v i ớ ố ộ tốc độ 2 Mbps v i t c đ 25 kbps.  Bên tham gia xác định thời  RTCP sẽ cố gắng giới hạn ư ượ ớ gian truyền dẫn các packet l u l ng RTCP t i 100 ộ ị ằ Kbps RTCP m t cách đ nh kỳ b ng cách tính kích thước packet  RTCP đưa ra 75% tốc độ RTCP trung bình (trên toàn cho bên nhận; còn lại bộ phiên làm việc) và chia 25% cho bên gửi cho tốc độ được cấp phát Mạng đa phương tiện 7-54
  55. SIP: Session Initiation Protocol [RFC 3261] Tầm nhìn xa:  Tất cả các cuộc gọi điện thoại, cuộc gọi hội nghị qua video diễn ra trên Internet  Con người được xác định bởi tên hoặc địa chỉ emila, chứ không phải bằng số điện thoại  Có thể liên lạc được (gọi được) với người được gọi (callee) (nếu người được gọi muốn), không có vấn đề về nơi mà người được gọi đang ở trong đó, hoặc thiết bị IP của người được gọi đang được sử dụng Mạng đa phương tiện 7-55
  56. Các dịch vụ SIP  SIP cung cấp các cơ  Xác định địa chỉ IP chế thiếp lập cuộc gọi: hiện thời của người . Người gọi (caller) được gọi (callee): muốn người được gọi . Ánh xạ định danh dễ nhớ (callee) biết là cô ta tới địa chỉ IP hiện tại đang muốn thiết lập  Quản lý cuộc gọi: 1 cuộc gọi . Thêm các stream truyền . ườ ọ thông mới trong suốt Do đó, ng i g i và ộ ọ người được gọi có cu c g i ể ồ ề ạ . Thay đổi mã hóa trong th đ ng ý v lo i suốt cuộc gọi phương tiện truyền, . Mời các người khác tham mã hóa. gia . Kết thúc cuộc gọi . Chuyển hoặc giữ cuộc gọi Mạng đa phương tiện 7-56
  57. Ví dụ: thiết lập một cuộc gọi tới địa chỉ IP đã biết Bob Alice  thông điệp mời SIP của Alice (SIP invite message) 167.180.112.24 193.64.210.89 cho biết số hiệu cổng, địa chỉ INVITE bo b@193.64. IP của cô ta và mã hóa mà cô c=IN IP 210.89 4 167.180. m= 112.24 audio 38060 ố ượ ậ RTP/AVP 0 ta mu n đ c nh n (PCM port 5060 Bob's terminal rings mlaw) 200 OK  10.89 thông điệp OK 200 của Bob c=IN IP4 193.64.2 TP/AVP 3 m=audio 48753 R (200 OK message) cho biết port 5060 số hiệu cổng, địa chỉ IP và mã ACK port 5060 hóa ưa thích của anh ta (GSM)  Law audio port 38060  các thông điệp SIP có thể được gửi trên TCP hoặc UDP; GSM ở đây được gửi qua RTP/UDP port 48753  số hiệu port SIP mặc định là 5060 time time Mạng đa phương tiện 5-57
  58. Thiết lập cuộc gọi (tt)  Đàm phán codec:  Từ chối cuộc gọi . Giả sử Bob không có bộ . Bob có thể từ chối mã hóa PCM mlaw với các trả lời . Bob sẽ thay vào đó sẽ “busy,” “gone,” trả lời với thông điệp “payment required,” 606 Not Acceptable “forbidden” Reply, liệt kê danh sách  Phương tiện truyền các bộ mã hóa của anh thông (media) có ta. Sau đó, Alice có thể thể được gửi thông gửi lại thông điệp INVITE mới, quảng cáo qua RTP hoặc một bộ mã hóa mới số giao thức khác Mạng đa phương tiện 7-58
  59. Ví dụ: thông điệp SIP INVITE sip:bob@domain.com SIP/2.0  ở đây chúng ta Via: SIP/2.0/UDP 167.180.112.24 không biết địa chỉ IP From: sip:alice@hereway.com của Bob To: sip:bob@domain.com . Cần có các máy chủ Call-ID: a2e3a@pigeon.hereway.com Content-Type: application/sdp SIP trung gian Content-Length: 885  Alice gửi, nhận các thông điệp SIP dùng c=IN IP4 167.180.112.24 số hiệu port mặc định m=audio 38060 RTP/AVP 0 506  Alice chỉ định cụ Ghi chú: thể trong header  HTTP message syntax rằng SIP client gửi  sdp = session description protocol và nhận các thông  Call-ID is unique for every call điệp SIP trên UDP Mạng đa phương tiện 7-59
  60. Chuyển đổi tên, vị trí user  Người gọi muốn gọi cho  Kết quả có thể được người được gọi (callee), dựa trên: nhưng chỉ có tên hoặc . thời gian trong ngày địa chỉ email của người (work, home) được gọi . Người gọi (không muốn người chủ gọi cho bạn  ầ ượ ị ỉ C n có đ c đ a ch IP khi bạn ở nhà) của host hiện tại của . Tình trạng của người người được gọi: nhận cuộc gọi (cuộc gọi . user di chuyển vòng được gửi tới thư thoại quanh khi người nhận cuộc . Giao thức DHCP gọi đang nói chuyện . user có các thiết bị IP với người khác) khác (PC, smartphone, thiết bị xe hơi) Mạng đa phương tiện 7-60
  61. SIP registrar  1 chức năng của SIP server: registrar  Khi Bob khởi động SIP client, client sẽ gửi thông điệp SIP REGISTER tới registrar server của Bob Thông điệp register: REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600 Mạng đa phương tiện 7-61
  62. SIP proxy  Một chức năng khác của SIP server: proxy  Alice gửi thông điệp invite tới proxy server của cô ta . Chứa địa chỉ sip:bob@domain.com . proxy chịu trách nhiệm cho việc định tuyến các thông điệp SIP tới người nhận cuộc gọi (callee), có thể qua nhiều proxy  Bob gửi lại phản hồi thông qua cùng một tập hợp các SIP proxy  proxy trả về thông điệp phản hồi SIP (SIP response) tới Alice . Chứa địa chỉ IP của Bob  SIP proxy tương tự như DNS server cục bộ cùng với thiết lập TCP Mạng đa phương tiện 7-62
  63. Ví dụ SIP: jim@umass.edu calls keith@poly.edu Poly SIP 2. UMass proxy chuyển tiếp yêu registrar cầu tới Poly registrar server 2 3 3. Poly server trả lại sự trả lời chuyển hướng, chỉ ra rằng Umass proxy nên cố gắng thử với keith@eurecom.fr UMass 4. Umass proxy chuyển yêu cầu Eurecom SIP SIP proxy tới Eurecom registrar server 4 registrar 7 1. Jim gửi thông điệp 6-8. SIP response được trả về 5. eurecom INVITE tới UMass SIP 8 5 registrar chuyển cho Jim 6 proxy. 1 tiếp INVITE tới 197.87.54.21, cái mà đang chạy SIP client 9 của keith 128.119.40.186 9. Luồng dữ liệu giữa các client 197.87.54.21 Mạng đa phương tiện 7-63
  64. So sánh với H.323  H.323: một giao thức  H.323 đến từ ITU (hệ truyền tín hiệu khác cho đa thống điện thoại) phương tiện tương tác, thời  SIP đến từ IETF: mượn gian thực nhiều khái niệm từ  H.323: một bộ các giao HTTP thức hoàn chỉnh, được tích . SIP có “hương vị” hợp theo chiều dọc cho hội Web; H.323 có nghị đa phương tiện: truyền “hương vị” hệ thống tín hiệu, đăng ký, điều khiển điện thoại vào (admission control), vận  SIP dùng nguyên lý chuyển, bộ mã hóa-giải mã KISS: Keep It Simple (codecs) Stupid  SIP: thành phần duy nhất. Hoạt động với RTP, nhưng không ủy quyền. Có thể được kết hợp với các giao thức và dịch vụ khác Mạng đa phương tiện 7-64
  65. Mạng đa phương tiện: Nội dung 7.1 các ứng dụng mạng đa phương tiện 7.2 video được lưu trữ theo luồng (streaming stored video) 7.3 voice-over-IP 7.4 các giao thức cho các ứng dụng đàm thoại thời gian thực 7.5 hỗ trợ của mạng cho đa phương tiện Mạng đa phương tiện 7-65
  66. Hỗ trợ mạng cho đa phương tiện Mạng đa phương tiện 7-66
  67. Định kích thước mạng nổ lực tốt nhất (Dimensioning best effort networks)  Hướng tiếp cận: triển khai đủ dung lượng của đường liên kết để mà tắt nghẽn không xảy ra, lưu lượng đa phương tiện không bị trễ hoặc mất gói . Ít độ phức tạp của các cơ chế mạng (dùng mạng “nổ lực tốt nhất” (“best effort”) hiện tại) . Chi phí băng thông cao (high bandwidth costs)  Thách thức: . Định kích thước mạng: . Băng thông bao nhiêu là “đủ”? . Ước lượng nhu cầu lưu lượng mạng: cần thiết để xác định bao nhiêu băng thông là “đủ” (cho lưu lượng đó) Mạng đa phương tiện 7-67
  68. Cung cấp nhiều lớp dịch vụ  Cho đến nay: làm cho tốt nhất của dịch vụ nổ lực tốt nhất (best effort service) . Một kích thước phù hợp với tất cả các mô hình dịch vụ  Cách khác: nhiều lớp dịch vụ . Phân chia lưu lượng vào trong các lớp . Mạng sẽ xử lý các lớp khác nhau của các lưu lượng một cách khác nhau (tương tự: dịch vụ VIP so với dịch vụ thường xuyên)  Sự phân chia: dịch vụ khác nhau giữa nhiều 0111 lớp, không nằm trong các kết nối riêng biệt  Lịch sử: các bit ToS Mạng đa phương tiện 7-68
  69. Nhiều lớp dịch vụ: tình huống H3 H1 R1 R2 H4 H2 R1 output 1.5 Mbps link interface queue Mạng đa phương tiện 7-69
  70. Tình huống 1: hỗn hợp HTTP và VoIP  Ví dụ: 1Mbps VoIP, HTTP chia sẽ đường liên kết 1.5 Mbps. . Truyền từng khối HTTP có thể gây tắt nghẽn router, làm mất gói audio . Muốn cho sự ưu tiên cho audio hơn HTTP R1 R2 Nguyên tắc 1 Đánh dấu packet là cần thiết cho router để phân biệt giữa các lớp khác nhau; và chính sách router mới để xử lý các packet một cách phù hợp Mạng đa phương tiện 7-70
  71. Các nguyên tắc bảo đảm QOS (tt)  Điều gì sẽ xảy ra nếu các ứng dụng hoạt động không đúng (VoIP gửi cao hơn so với tốc độ đã khai báo) . Lập Chính sách: bắt buộc tập hợp nguồn cho sự phân bổ băng thông  Đánh dấu, lập chính sách tại mạng cạnh (network edge) 1 Mbps phone R1 R2 1.5 Mbps link Đánh dấu packet và lập chính sách Nguyên tắc 2 Cung cấp sự bảo vệ (cô lập) cho 1 lớp với các lớp khác Mạng đa phương tiện 7-71
  72. Các nguyên tắc bảo đảm QOS (tt)  Phân bổ băng thông cố định (không thể chia sẽ) cho luồng lưu lượng: sử dụng không hiêu quả băng thông nếu luồng lưu lượng không sử dụng sự phân bổ của nó 1 Mbps 1 Mbps logical link phone R1 R2 1.5 Mbps link 0.5 Mbps logical link Nguyên tắc 3 Trong khi cung cấp sự cô lập, đó là mong muốn sử dụng tài nguyên một cách hiệu quả có thể nhất Mạng đa phương tiện 7-72
  73. Cơ chế lập lịch và lập chính sách (Scheduling and policing mechanisms)  Lập lịch: chọn packet kế tiếp để gửi ra đường liên kết  Vào trước ra trước (FIFO (first in first out)) scheduling: gửi theo thứ tự đến hàng đợi . Ví dụ trong thực tế? . Chính sách loại bỏ (discard policy): nếu đến hàng đợi bị đầy: ai sẽ bị loại bỏ? • Bỏ đuôi (tail drop): bỏ packet vừa đến • Độ ưu tiên (priority): bỏ/loại bỏ dựa trên độ ưu tiên • Ngẫu nhiên (random): loại bỏ ngẫu nhiên Packet Packet đến Hàng đợi link rời khỏi hàng đợi (khu vực đợi) (server) Mạng đa phương tiện 7-73
  74. Chính sách lập lịch: độ ưu tiên Hàng đợi độ ưu tiên cao Lập lịch độ ưu tiên (khu vực đợi) (priority scheduling): Đến đi gửi packet được xếp ớ ộ ư hàng v i đ u tiên cao classify link (server) nhất Hàng đợi ưu tiên thấp  Nhiều lớp, với các độ ưu (khu vực đợi) tiên khác nhau 2 1 3 4 5 . Lớp có thể phụ thuộc vào Đến sự đánh dấu hoặc thông packet tin header khác, ví dụ: in 1 3 2 4 5 nguồn/đích IP, số hiệu service port đi . Ví dụ trong thực tế? 1 3 2 4 5 Mạng đa phương tiện 7-74
  75. Chính sách lập lịch: tiếp theo Lập lịch luân phiên (Round Robin (RR) scheduling):  Nhiều lớp  Quét theo chu kỳ các hàng đợi của lớp, gửi 1 packet hoàn chỉnh từ mỗi lớp (nếu có)  Ví dụ trong thực tế? 2 1 3 4 5 Đến packet in 1 3 2 4 5 service đi 1 3 3 4 5 Mạng đa phương tiện 7-75
  76. Chính sách lập lịch: tiếp theo Hàng đợi cân bằng trọng số (Weighted Fair Queuing (WFQ)):  Round Robin mở rộng  Mỗi lớp sẽ nhận lượng trọng số của dịch vụ (weighted amount of service) trong mỗi chu kỳ  Ví dụ trong thực tế? Mạng đa phương tiện 7-76
  77. Cơ chế lập chính sách Mục tiêu: giới hạn lưu lượng để không vượt quá các thông số đã khai báo 3 tiêu chí được sử dụng phổ biến:  (dài hạn) tốc độ trung bình: bao nhiêu packet có thể được gửi trong mỗi đơn vị thời gian (trong thời gian dài) . Câu hỏi quan trọng: độ dài khoảng thời gian là gì: 100 packet mỗi giây hoặc 6000 packet mỗi phút có trung bình như nhau  Tốc độ cao nhất (peak rate): ví dụ 6000 packet trung bình mỗi phút (ppm); tốc độ cao nhất (peak rate) 1500 ppm  (max.) kích thước lớn nhất (burst size): số lượng lớn nhất của packet được gửi liên tiếp (không có ỗ ệ nhàn r i can thi p) Mạng đa phương tiện 7-77
  78. Cơ chế lập chính sách: thực hiện token bucket: hạn chế đầu vào tới kích thước lớn nhất (burst size ) và tốc độ trung bình (average rate ) được quy định  bucket có thể giữ b token  Các token được tạo ra với tốc độ r token/giây trừ bucket đầy  Vượt quá khoảng thời gian chiều dài t (interval of length t): số lượng các packet được thừa nhận ít hơn hoặc bằng (r t + b) Mạng đa phương tiện 7-78
  79. Lập chính sách và bảo đảm QoS  Sự kết hợp token bucket và WFQ để cung cấp bảo đảm ràng buộc trên độ trễ. Ví du: QoS guarantee! lưu lượng token rate, r đến bucket size, b per-flow rate, R WFQ D = b/R lưu lượng max đến Mạng đa phương tiện 7-79
  80. Các dịch vụ phân biệt (Differentiated services)  Muốn các lớp dịch vụ “chất lượng” . “hoạt động đồng bộ” . Sự phân biệt dịch vụ liên quan: Platinum, Gold, Silver  Khả năng mở rộng: các chức năng đơn giản trong mạng lõi, các chức năng tương đối phức tạp tại các router biên (hoặc host) . Truyền tín hiệu, duy trì mỗi tình trạng router luồng là khó khăn với số lượng lớn các luồng  Không định nghĩa các lớp dịch vụ, cung cấp các thành phần chức năng để xây dựng các lớp dịch vụ Mạng đa phương tiện 7-80
  81. Kiến trúc Diffserv marking r Router biên: b scheduling  quản lý lưu lượng Từng luồng (per-flow)  Đánh dấu các packet như in- . profile và out-profile . Router biên:  Quản lý lưu lượng từng lớp (per class traffic management)  Đệm và lập lịch dựa trên sự đánh dấu tại biên (marking at edge)  Sự ưu tiên được dành cho các packet in-profile hơn là các packet out-of-profile Mạng đa phương tiện 7-81
  82. Đánh dấu packet tại router biên (Edge-router packet marking)  Hồ sơ: tốc độ được thương lượng trước r, kích thước bucket b  Đánh dấu packet tại biên dựa trên hồ sơ của mỗi luồng (per- flow profile) rate r b user packets Sự sử dụng có thể của đánh dấu  Đánh dấu dựa trên loại(class-based marking): các packet của các loại khác nhau được đánh dấu khác nhau  Đánh dấu bên trong loại(intra-class marking): phần thích hợp của luồng (conforming portion of flow) được đánh dấu khác hơn là những phần không thích hợp Mạng đa phương tiện 5-82
  83. Đánh dấu packet Diffserv: chi tiết  packet được đánh dấu trong Type of Service (TOS) trong IPv4, và Traffic Class trong IPv6  6 bit được sử dụng cho Differentiated Service Code Point (DSCP) . Xác định PHB mà packet sẽ nhận được . 2 bit hiện tại chưa được sử dụng DSCP unused Mạng đa phương tiện 7-83
  84. Phân loại và điều hòa lưu lượng Classification, conditioning Với mong muốn là giới hạn tốc độ bơm lưu lượng (traffic injection rate ) của một số lớp :  Người dung khai báo profile của lưu lượng (ví du: tốc độ, kích thước burst)  Lưu lượng được đo và được định hình nếu không phù hợp Mạng đa phương tiện 7-84
  85. Chuyển tiếp Per-hop Behavior (PHB)  PHB dẫn tới hành vi hiệu suất chuyển tiếp được quan sát khác nhau (a different observable (measurable) forwarding performance behavior)  PHB không xác định các kỹ thuật sử dụng để bảo đảm hành vi hiệu suất được PHB được yêu cầu (required PHB performance behavior)  Ví dụ: . Lớp A được x% của băng thông liên kết đi trong khoảng thời gian của 1 chiều dài được quy định (time intervals of a specified length) . Các packet của lớp A rời khỏi đầu tiên trước khi các packet từ lớp B Mạng đa phương tiện 7-85
  86. Chuyển tiếp PHB Các PHB được đề suất:  Chuyển tiếp được giải quyết nhanh (expedited forwarding): tốc độ “khởi hành” của packet của một lớp bằng hoặc vượt quá tốc độ được quy định . Đường liên kết logic (logical link) với một tốc độ được bảo đảm tối thiểu  Chuyển tiếp được bảo đảm (assured forwarding): 4 loại lưu lượng . Từng loại AF được đảm bảo số lượng tối thiểu của băng thông . Mỗi loại được phân vùng vào 1 trong 3 loại “drop preference” Mạng đa phương tiện 7-86
  87. Bảo đảm QOS mỗi kết nối (Per-connection QOS guarantees)  Thực tế: không thể hỗ trợ nhu cầu lưu lượng vượt quá khả năng của đường liên kết 1 Mbps phone R1 R2 1 Mbps 1.5 Mbps link phone Nguyên tắc 4 Việc nhận cuộc gọi (call admission): luồng (flow) khai báo nhu cầu của nó, mạng lưới có thể chặn cuộc gọi (như là tín hiệu bận) nếu nó không thể đám ứng được nhu cầu Mạng đa phương tiện 7-87
  88. Tình huống bảo đảm QoS  resource reservation . Thiết lập cuộc gọi, truyền tín hiệu (RSVP) . Lưu lượng, khai báo QoS . Điều khiển sự cho vào mỗi thành phần (per-element admission control) request/ reply . QoS-sensitive scheduling (ví dụ: WFQ) Mạng đa phương tiện 7-88
  89. Mạng đa phương tiện: Nội dung 7.1 các ứng dụng mạng đa phương tiện 7.2 video được lưu trữ theo luồng (streaming stored video) 7.3 voice-over-IP 7.4 các giao thức cho các ứng dụng đàm thoại thời gian thực 7.5 hỗ trợ của mạng cho đa phương tiện Mạng đa phương tiện 7-89