130 likes | 265 Vues
This document provides insights into the draft-ietf-mmusic-mbus-transport-02 updates, highlighting key changes such as bug fixes, enhancements in message syntax, and the introduction of an entity awareness mechanism through periodic heartbeat messages (mbus.hello). It outlines the transport protocol's requirements and message semantics for effective call control and media tool commands. Key features include dynamic timer intervals for entity communication and a new mbus.ping command to facilitate rapid entity discovery. The MBus transport is nearing stability, with suggestions for future semantical specifications.
E N D
Mbus Update draft-ietf-mmusic-mbus-transport-02.txt Jörg Ott jo@tzi.uni-bremen.de Colin Perkins csp@east.isi.edu Dirk Kutscher dku@tzi.uni-bremen.de 48. IETF, Pittsburgh Ott/Perkins/Kutscher
http://www.dmn.tzi.org/ietf/mmusic/mbus/ 48. IETF, Pittsburgh Ott/Perkins/Kutscher
Quick Reminder • Local coordination mechanism • Specification split into three pieces • Requirements overview • Definition of the “transport protocol” • message syntax, addressing, local multicast, reliability, authentication, ... • Definition of the message semantics • call-control, media tools related commands 48. IETF, Pittsburgh Ott/Perkins/Kutscher
Overview of Changes indraft-ietf-mmusic-mbus-transport-02 • Bug-fixes • message syntax ABNF • minor corrections and clarifications • new section „Awareness of other Entities“ • explicit specification of requirements for implementations • new algorithm for mbus.hello timer calculation deploying timer reconsideration 48. IETF, Pittsburgh Ott/Perkins/Kutscher
Mbus Entity Awareness • General idea: • Each Mbus entity sends periodic heartbeat messages (mbus.hello) • Received hello-messages are used • to learn of the existence of other entities on startup (bootstrapping) • to track the aliveness of entities 48. IETF, Pittsburgh Ott/Perkins/Kutscher
mbus.hello • Fixed timer interval changed to dynamically adapted intervals • Scales according to number of entities • Number of mbus.hello received by an entity per time unit remains ~constant. • Deploys RTCP-like timer reconsideration mechanism to adapt to rapidly changing group size • Simpler than RTCP’s interval calculation because bandwidth fraction and sender vs. receiver is less important. • Uses randomization in order to avoid synchronization. 48. IETF, Pittsburgh Ott/Perkins/Kutscher
mbus.ping • Problem: • Increased timer intervals in larger groups can prolong bootstrapping phase. • Solution: • New command mbus.ping • query for the existence of other entities • learn their fully qualified Mbus addresses. • Example: • “Where’s the audio engine (if any)?”: • Send a mbus.ping to (media:audio). • Entities with matching addresses respond with mbus.hello. • Entity learns requested Mbus addresses 48. IETF, Pittsburgh Ott/Perkins/Kutscher
Next steps • Mbus-transport considered virtually stable • No further features/changes planned • Specification of behavior in the absence of Multicast could be useful. • Support for simple devices • One more draft submission before WG-last-call? 48. IETF, Pittsburgh Ott/Perkins/Kutscher
Semantic specifications • Specify the usage of Mbus transport services in specific application areas • Definition of address classes, commands and semantics • Intended as Informational RFCs • Currently: • draft-ott-mmusic-mbus-semantics-00.txt • Commands for media engines and call-control • Has not been re-submitted yet 48. IETF, Pittsburgh Ott/Perkins/Kutscher
Semantic specifications • Plan: • Split-up specification into individual parts • Provide informational guidelines document for writing semantic specifications (work in progress) • Issue: • Which other command classes to go for? 48. IETF, Pittsburgh Ott/Perkins/Kutscher
Other Issues • Connecting physically separated Mbus domains • Independent of base spec.? • Simple devices • Mbus bootstrapping • How to obtain Mbus configuration parameters? • Allowing for Broadcast instead of Multicast? 48. IETF, Pittsburgh Ott/Perkins/Kutscher
http://www.dmn.tzi.org/ietf/mmusic/mbus/ 48. IETF, Pittsburgh Ott/Perkins/Kutscher