idnits 2.17.1 draft-ietf-mmusic-mbus-transport-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 109 instances of lines with control characters in the document. == There are 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2001) is 8479 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'MBUS' on line 1473 == Unused Reference: '5' is defined on line 1561, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1569, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1573, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1576, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1610, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1615, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1623, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1521 (ref. '6') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1889 (ref. '7') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2543 (ref. '8') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2327 (ref. '9') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Historic RFC: RFC 1423 (ref. '11') ** Obsolete normative reference: RFC 2234 (ref. '12') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2554 (ref. '13') (Obsoleted by RFC 4954) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '14') -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Duplicate reference: RFC2373, mentioned in '18', was also mentioned in '3'. ** Obsolete normative reference: RFC 2373 (ref. '18') (Obsoleted by RFC 3513) -- Possible downref: Normative reference to a draft: ref. '19' -- Possible downref: Normative reference to a draft: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ott 3 Internet-Draft TZI, Universitaet Bremen 4 Expires: August 8, 2001 Perkins 5 USC Information Sciences Institute 6 Kutscher 7 TZI, Universitaet Bremen 8 February 7, 2001 10 A Message Bus for Local Coordination 11 draft-ietf-mmusic-mbus-transport-04.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 8, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 The local Message Bus (Mbus) is a simple message-oriented 40 coordination infrastructure for group communication within groups of 41 co-located application entities. The Message Bus comprises three 42 logically distinct parts: a message transport infrastructure, a 43 structured message hierarchy, and a general purpose addressing 44 scheme. This document specifies message addressing, transport, and 45 security procedures and defines the message syntax for the Mbus. It 46 does not define application oriented semantics and procedures for 47 using the message bus. 49 This document is a product of the Multiparty Multimedia Session 50 Control (MMUSIC) working group of the Internet Engineering Task 51 Force. Comments are solicited and should be addressed to the working 52 group's mailing list at confctrl@isi.edu and/or the authors. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Application Scenarios . . . . . . . . . . . . . . . . . . . 4 58 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3 Terminology for requirement specifications . . . . . . . . . 4 60 2. General Outline . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 8 62 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 12 65 6. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 13 67 6.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 69 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 7.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 16 71 7.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 17 72 7.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 17 73 7.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 18 74 7.1.4 Mbus Port Number . . . . . . . . . . . . . . . . . . . . . . 18 75 7.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 18 76 8. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 21 77 9. Awareness of other Entities . . . . . . . . . . . . . . . . 23 78 9.1 Hello Message Transmission Interval . . . . . . . . . . . . 23 79 9.1.1 Calculating the Interval for Hello Messages . . . . . . . . 24 80 9.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 25 81 9.1.3 Adjusting the Hello Message Interval when the Number of 82 Entities increases . . . . . . . . . . . . . . . . . . . . . 25 83 9.1.4 Adjusting the Hello Message Interval when the Number of 84 Entities decreases . . . . . . . . . . . . . . . . . . . . . 25 85 9.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 26 86 9.2 Calculating the Timeout for Hello Messages . . . . . . . . . 26 87 10. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 10.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 10.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 10.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 10.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 10.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 28 93 10.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 11. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 12. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 31 96 12.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 31 97 12.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 12.3 Message Authentication . . . . . . . . . . . . . . . . . . . 32 99 12.4 Procedures for Senders and Receivers . . . . . . . . . . . . 32 100 13. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 34 101 13.1 File based parameter storage . . . . . . . . . . . . . . . . 36 102 13.2 Registry based parameter storage . . . . . . . . . . . . . . 37 103 14. Security Considerations . . . . . . . . . . . . . . . . . . 38 104 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 105 References . . . . . . . . . . . . . . . . . . . . . . . . . 40 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 107 A. About References . . . . . . . . . . . . . . . . . . . . . . 43 108 B. Limitations and Future Work . . . . . . . . . . . . . . . . 44 109 Full Copyright Statement . . . . . . . . . . . . . . . . . . 45 111 1. Introduction 113 1.1 Application Scenarios 115 The implementation of multiparty multimedia conferencing systems is 116 one example where a simple coordination infrastructure can be 117 useful: In a variety of conferencing scenarios, a local 118 communication channel can provide conference-related information 119 exchange between co-located but otherwise independent application 120 entities, for example those taking part in application sessions that 121 belong to the same conference. In loosely coupled conferences such a 122 mechanism allows for coordination of applications entities to e.g. 123 implement synchronization between media streams or to configure 124 entities without user interaction. It can also be used to implement 125 tightly coupled conferences enabling a conference controller to 126 enforce conference wide control within an end system. 128 1.2 Purpose 130 Three components constitute the message bus: the low level message 131 passing mechanisms, a command syntax and naming hierarchy, and the 132 addressing scheme. 134 The purpose of this document is to define the characteristics of the 135 lower level Mbus message passing mechanism which is common to all 136 Mbus implementations. This includes the specification of 138 o the generic Mbus message format; 140 o the addressing concept for application entities (note that 141 concrete addressing schemes are to be defined by application 142 specific profiles); 144 o the transport mechanisms to be employed for conveying messages 145 between (co-located) application entities; 147 o the security concept to prevent misuse of the Message Bus (as 148 taking control of another user's conferencing environment); 150 o the details of the Mbus message syntax; and 152 o a set of mandatory application independent commands that are used 153 for bootstrapping Mbus sessions. 155 1.3 Terminology for requirement specifications 157 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 158 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 159 and "OPTIONAL" are to be interpreted as described in RFC 2119[1] and 160 indicate requirement levels for compliant Mbus implementations. 162 2. General Outline 164 Local coordination involves a widely varying number of entities: 165 some messages (such as membership information, floor control 166 notifications, dissemination of conference state changes, etc.) may 167 need to be destined for all local application entities. Messages may 168 also be targeted at a certain application class (e.g. all 169 whiteboards or all audio tools) or agent type (e.g. all user 170 interfaces rather than all media engines). Or there may be any 171 (application- or message- specific) subgrouping defining the 172 intended recipients, e.g. messages related to media synchronization. 173 Finally, there will be messages that are directed to a single 174 entity, for example, specific configuration settings that a 175 conference controller sends to a application entity or 176 query-response exchanges between any local server and its clients. 178 The Mbus concept as presented here satisfies these different 179 communication models by defining different message transport 180 mechanisms (defined in Section 7) and by providing a flexible 181 addressing scheme (defined in Section 5). 183 Furthermore, Mbus messages exchanged between application entities 184 may have different reliability requirements (which are typically 185 derived from their semantics). Some messages will have a rather 186 informational character conveying ephemeral state information (which 187 is refreshed/updated periodically), such as the volume meter level 188 of an audio receiver entity to be displayed by its user interface 189 agent. Certain Mbus messages (such as queries for parameters or 190 queries to local servers) may require a response from the peer(s) 191 thereby providing an explicit acknowledgment at the semantic level 192 on top of the Mbus. Other messages will modify the application or 193 conference state and hence it is crucial that they do not get lost. 194 The latter type of message has to be delivered reliably to the 195 recipient, whereas message of the first type do not require 196 reliability mechanisms at the Mbus transport layer. For messages 197 confirmed at the application layer it is up to the discretion of the 198 application whether or not to use a reliable transport underneath. 200 In some cases, application entities will want to tailor the degree 201 of reliability to their needs, others will want to rely on the 202 underlying transport to ensure delivery of the messages -- and this 203 may be different for each Mbus message. The Mbus message passing 204 mechanism specified in this document provides a maximum of 205 flexibility by providing reliable transmission achieved through 206 transport-layer acknowledgments (in case of point-to-point 207 communications only) as well as unreliable message passing (for 208 unicast, local multicast, and local broadcast). We address this 209 topic in Section 5. 211 Finally, accidental or malicious disturbance of Mbus communications 212 through messages originated by applications from other users needs 213 to be prevented. Accidental reception of Mbus messages from other 214 users may occur if either two users share the same host for 215 conferencing or are using end systems spread across the same network 216 link: in either case, the used Mbus multicast address and the port 217 number may be identical leading to reception of the other party's 218 Mbus messages in addition to a user's own ones. Malicious 219 disturbance may happen because of applications multicasting (e.g. at 220 a global scope) or unicasting Mbus messages. To eliminate the 221 possibility of receiving unwanted Mbus messages, the Mbus protocol 222 contains message digests for authentication. Furthermore, the Mbus 223 allows for encryption to ensure privacy and thus enable using the 224 Mbus for local key distribution and other functions potentially 225 sensitive to eavesdropping. This document defines the framework for 226 configuring Mbus applications with regard to security parameters in 227 Section 13. 229 3. Common Formal Syntax Rules 231 This section contains some definitions of common ABNF [12] syntax 232 elements that are later referenced by other definitions in this 233 document: 235 base64 = base64_terminal / 236 ( 1*(4base64_CHAR) [base64_terminal] ) 238 base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" 239 ;; Case-sensitive 241 base64_terminal = (2base64_char "==") / (3base64_char "=") 243 UPALPHA = %x41-5A ;; Uppercase: A-Z 245 LOALPHA = %x61-7A ;; Lowercase: a-z 247 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 249 CHAR = %x01-7F 250 ; any 7-bit US-ASCII character, 251 excluding NUL 253 OCTET = %x00-FF 254 ; 8 bits of data 256 CR = %x0D 257 ; carriage return 259 CRLF = CR LF 260 ; Internet standard newline 262 DIGIT = %x30-39 263 ; 0-9 265 DQUOTE = %x22 266 ; " (Double Quote) 268 HTAB = %x09 269 ; horizontal tab 271 LF = %x0A 272 ; linefeed 274 LWSP = *(WSP / CRLF WSP) 275 ; linear white space (past newline) 277 SP = %x20 278 ; space 280 WSP = SP / HTAB 281 ; white space 283 Taken from RFC 2234 [12] and RFC 2554 [13]. 285 4. Message Format 287 A Mbus message comprises a header and a body. The header is used to 288 indicate how and where a message should be delivered, the body 289 provides information and commands to the destination entity. The 290 following information is included in the header: 292 A fixed ProtocolID field identifies the version of the message 293 bus protocol used. The protocol defined in this document is 294 "mbus/1.0" (case-sensitive). 296 A sequence number (SeqNum) is contained in each message. The 297 first message sent by a source SHOULD have SeqNum equal to zero, 298 and it MUST increment by one for each message sent by that 299 source. A single sequence number is used for all messages from a 300 source, irrespective of the intended recipients and the 301 reliability mode selected. SeqNums are decimal numbers in ASCII 302 representation. 304 The TimeStamp field is also contained in each message and SHOULD 305 contain a decimal number representing the time at message 306 construction in milliseconds since 00:00:00, UTC, January 1, 307 1970. 309 A MessageType field indicates the kind of message being sent. The 310 value "R" indicates that the message is to be transmitted 311 reliably and MUST be acknowledged by the recipient, "U" indicates 312 an unreliable message which MUST NOT be acknowledged. 314 The SrcAddr field identifies the sender of a message. This MUST 315 be a complete address, with all address elements specified. The 316 addressing scheme is described in Section 5. 318 The DestAddr field identifies the intended recipient(s) of the 319 message. This field MAY contain wildcards by omitting address 320 element and hence address any number (including zero) of 321 application entities. The addressing scheme is described in 322 Section 5. 324 The AckList field comprises a list of SeqNums for which this 325 message is an acknowledgment. See Section 8 for details. 327 The header is followed by the message body which contains zero or 328 more commands to be delivered to the destination entity. The syntax 329 for a complete message is given in Section 6. 331 If multiple commands are contained within the same Mbus message 332 payload, they MUST to be delivered to the Mbus application in the 333 same sequence in which they appear in the message payload. 335 5. Addressing 337 Each entity on the message has a unique Mbus address that is used to 338 identify the entity. Senders and receivers of messages are 339 identified by their Mbus addresses. Mbus addresses are sequences of 340 address elements that are tag/value pairs. The tag and the value are 341 separated by a colon and tag/value pairs are separated by 342 whitespace, like this: 344 (tag:value tag:value ...) 346 The formal ABNF syntax definition for Mbus addresses and their 347 elements is as follows: 349 mbus_address = "(" *address_element ")" 351 address_element = *WSP address_tag ":" address_value *WSP 353 address_tag = 1*32(ALPHA) 355 address_value = 1*64(%x21-7F) 356 ; any 7-bit US-ASCII character 357 ; excluding white space 358 ; and control characters 360 Note that this and other ABNF definitions in this document use the 361 core rules defined in Section 3. 363 Each entity has a fixed sequence of address elements constituting 364 its address and MUST only process messages sent to addresses that 365 either match all elements or consist of a subset of its own address 366 elements. Each element value in this subset must match the 367 correspoding value of the receiver's address element value. The 368 order of address elements in an address sequence is not relevant. 369 For example, an entity with an address of: 371 (conf:test media:audio module:engine app:rat id:4711-1@134.102.218.45) 373 will process messages sent to 375 (media:audio module:engine) 377 and 379 (module:engine) 381 but must ignore messages sent to 383 (conf:test media:audio module:engine app:rat id:123-4@134.102.218.45 foo:bar) 384 and 386 (foo:bar) 388 A message that should be processed by all entities requires an empty 389 set of address elements. 391 5.1 Mandatory Address Elements 393 Each Mbus entity MUST provide one mandatory address element that 394 allows to identify the entity. The element name is "id" and the 395 value MUST be be composed of the following components: 397 o The IP address of the interface that is used for sending messages 398 to the Mbus. For IPv4 this the address in decimal dotted 399 notation. For IPv6 the interface-ID-part of an address in textual 400 representation as specified in RFC 2373[3] MUST be used. In this 401 specification, this part is called the "host-ID". 403 o An identifier ("entity-ID") that is unique within the scope of a 404 single host-ID. The entity comprises two parts. For systems where 405 the concept of a process ID is applicable it is RECOMMENDED this 406 identifier be composed using a process-ID and a per-process 407 disambiguator for different Mbus entities of a process. If a 408 process ID is not available, this part of the entity-ID may be 409 randomly chosen (it is recommended that at least a 32 bit random 410 number is chosen). Both numbers are represented in decimal 411 textual form and MUST be separated by a '-' character. 413 Note that the entity-ID cannot be the port number of the endpoint 414 used for sending messages to the Mbus because implementations MAY 415 use the common Mbus port number for sending to and receiving from 416 the multicast group (as specified in Section 7). The total 417 identifier has the following structure: 419 id-element = "id:" id-value 421 id-value = entity-id "@" host-id 423 entity-id = 1*10DIGIT "-" 1*5DIGIT 425 host-id = (IPv4address / IPv6address) 427 Please refer to [3] for productions of IPv4address and IPv6address. 429 An example for an id element: 431 id:4711-99@134.102.218.45 433 6. Message Syntax 435 6.1 Message Encoding 437 All messages MUST use the UTF-8 character encoding. Note that US 438 ASCII is a subset of UTF-8 and requires no additional encoding, and 439 that a message encoded with UTF-8 will not contain zero bytes. 441 Each Message MAY be encrypted using a secret key algorithm as 442 defined in Section 12. 444 6.2 Message Header 446 The fields in the header are separated by white space characters, 447 and followed by CRLF. The format of the header is as follows: 449 msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP 450 MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList 452 The header fields are explained in Message Format (Section 4). Here 453 are the ABNF syntax definitions for the header fields: 455 SeqNum = 1*10DIGIT 457 TimeStamp = 1*10DIGIT 459 MessageType = "R" / "U" 461 ScrAddr = mbus_address 463 DestAddr = mbus_address 465 AckList = "(" *(1*DIGIT)) ")" 467 See Section 5 for a definition of "mbus_address". 469 The syntax definition of a complete message is as follows: 471 mbus_message = msg_header *1(CRLF msg_payload) 473 msg_payload = mbus_command *(CRLF mbus_command) 475 The definition of production rules for Mbus command is given below. 477 6.3 Command Syntax 479 The header is followed by zero, or more, commands to be delivered to 480 the application(s) indicated by the DestAddr field. Each message 481 comprises a command followed by a list of zero, or more, parameters, 482 and is followed by a newline. 484 command ( parameter parameter ... ) 486 Syntactically, the command name MUST be a `symbol' as defined in the 487 following table. The parameters MAY be any data type drawn from the 488 following table: 490 val = Integer / Float / String / List / Symbol / Data 492 Integer = *1"-" 1*DIGIT 494 Float = *1"-" 1*DIGIT "." 1*DIGIT 496 String = DQUOTE *CHAR DQUOTE 497 ; see below for escape characters 499 List = "(" *(val *(1*WSP val)) ")" 501 Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" / ".") 503 Data = "<" *base64 ">" 505 Boolean values are encoded as an integer, with the value of zero 506 representing false, and non-zero representing true. 508 String parameters in the payload MUST be enclosed in the double 509 quote (") character. Within strings, the escape character is the 510 backslash (\), and the following escape sequences are defined: 512 +----------------+-----------+ 513 |Escape Sequence | Meaning | 514 +----------------+-----------+ 515 | \\ | \ | 516 | \" | " | 517 | \n | newline | 518 +----------------+-----------+ 520 List parameters do not have to be homogeneous lists, i.e. they can 521 contain parameters of varying types. 523 Opaque data is represented as Base64-encoded (see RFC1521[6]) 524 character strings surrounded by "< " and "> " 526 The ABNF syntax definition for Mbus commands is as follows: 528 mbus_command = command_name arglist 530 command_name = ALPHA *(ALPHA / DIGIT / "_" / ".") 532 arglist = "(" *(*WSP parameter *WSP) ")" 534 parameter = Integer / Float / String / List 535 Symbol / Data 537 Command names SHOULD be constructed using hierarchical names to 538 group conceptually related commands under a common hierarchy. The 539 delimiter between names in the hierarchy is "." (dot). Application 540 profiles MUST NOT define commands starting with "mbus.". 542 The Mbus addressing scheme defined in Section 5 provides for 543 specifying incomplete addresses by omitting certain elements of an 544 address element list, enabling entities to send commands to a group 545 of Mbus entities. Therefore all command names SHOULD be unambiguous 546 in a way that it is possible to interpret or ignore them without 547 considering the message's address. 549 A set of commands within a certain hierarchy that MUST be understood 550 by every entity is defined in Messages (Section 10). 552 7. Transport 554 All messages are transmitted as UDP messages, with two possible 555 alternatives: 557 1. Local multicast/broadcast: 558 This transport class MUST be used for all messages that are not 559 sent to a fully qualified target address. It MAY also be used 560 for messages that are sent to a fully qualified target address. 561 It MUST be provided by conforming implementations. See Section 562 7.1 for details. 564 2. Directed unicast: 565 This transport class MAY be used for messages that are sent to a 566 fully qualified destination address. It is OPTIONAL and does not 567 have to be provided by conforming implementations. 569 Messages are transmitted in UDP datagrams, a maximum message size of 570 64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications 571 using a non host-local scope do not exceed a message size of the 572 network's MTU. 574 Note that "unicast", "multicast" and "broadcast" mean IP-Unicast, 575 IP-Multicast and IP-Broadcast respectively. It is possible to send 576 an Mbus message that is addressed to a single entity using 577 IP-multicast. This specification deals with both Mbus over UDP/IPv4 578 and Mbus over UDP/IPv6. 580 7.1 Local Multicast/Broadcast 582 In general, the Mbus uses multicast with a limited scope for message 583 transport. Two different Mbus multicast scopes are defined: 585 1. host-local 587 2. link-local 589 Participants of an Mbus session have to know the multicast address 590 in advance -- it cannot be negotiated during the session since it is 591 already needed for any communication between the participants. I can 592 also not be allocated prior to an Mbus session because there would 593 be no mechanism to announce the allocated address to all potential 594 Mbus participants. Therefore the multicast address cannot be 595 allocated dynamically, e.g. using multicast address allocation 596 protocols, but has to be assigned statically. This document defines 597 the use of statically assigned addresses and also provides a 598 specification of how an Mbus session can be configured to use 599 non-standard addresses (see Section 13). 601 An Mbus session can be configured to use either one of the mentioned 602 scopes. The following sections specify the use of multicast 603 addresses for IPv4 and IPv6. 605 7.1.1 Mbus multicast groups for IPv4 607 For IPv4, there are two address ranges for "local scope" multicast: 609 The IPv4 Local Scope -- 239.255.0.0/16 239.255.0.0/16 is the minimal 610 enclosing scope for administratively scoped multicast (as defined 611 by RFC 2365[10]) and not further divisible -- its exact extent is 612 site dependent. Allocating a statically assigned address in this 613 scope would require to allocate a scope relative multicast 614 address (the high order /24 in every scoped region is reserved 615 for relative assignments), because the main address space is to 616 be assigned dynamically, e.g. by using address allocation 617 protocols. 619 The IPv4 statically assigned link-local scope -- 224.0.0.0/24 620 224.0.0.0/24 is the address range for statically assigned 621 multicast address for link-local multicast. Multicast routers 622 should not forward any multicast datagram with destination 623 addresses in this range, regardless of its TTL. 625 Because of the unexact extent of 239.255.0.0/16 scopes and the fact 626 that the only way to allocate a static address is the use of an 627 assigned scope relative address the Mbus uses an multicast address 628 from the statically assigned link-local scope (224.0.0.0/24). 630 Host-local Mbus scope in an IPv4 environment MUST be implemented by 631 using an IPv4 link-local address and an IP-Multicast-TTL of zero. 632 Link-local Mbus scope in an IPv4 environment MUST be implemented by 633 using an IPv4 link-ocal Scope address and an IP-Multicast-TTL 634 greater than zero. 636 The IPv4 link-local multicast address has yet to be assigned (see 637 Section 15). 639 7.1.2 Mbus multicast groups for IPv6 641 IPv6 has different address ranges for different multicast scopes and 642 distinguishes node local and link local scopes, that are implemented 643 as a set of address prefixes for the different address ranges (RFC 644 2373[18]). The link-local prefix is FF02, the node-local prefix is 645 FF01. A permanently assigned multicast address will be used for Mbus 646 multicast communication, i.e. an address that is independent of the 647 scope value and that can be used for all scopes. Implementations for 648 IPv6 MUST use the scope independent address and the appropriate 649 prefix for the selected scope. For host-local Mbus communication the 650 IPv6 node-local scope prefix MUST be used, for link-local Mbus 651 communication the IPv6 link-local scope prefix MUST be used. 653 The permanent IPv6 multicast addresses has yet to be assigned (see 654 Section 15). 656 If a single application system is distributed across several 657 co-located hosts, link local scope SHOULD be used for multicasting 658 Mbus messages that potentially have recipients on the other hosts. 659 The Mbus protocol is not intended (and hence deliberately not 660 designed) for communication between hosts not on the same link. See 661 Section 13 for specifications of Mbus configuration mechanisms. 663 7.1.3 Use of Broadcast 665 In situations where multicast is not available, broadcast MAY be 666 used instead. In these cases an IP broadcast address for the 667 connected network SHOULD be used for sending. The node-local 668 broadcast address for IPv6 is FF01:0:0:0:0:0:0:1, the link-local 669 broadcast address for IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the 670 generic broadcast address (for link-local broadcast) is 671 255.255.255.255. It is RECOMMENDED that IPv4-implementations use the 672 generic broadcast address and a TTL of zero for host-local 673 broadcast. 675 Broadcast MUST NOT be used in situations where multicast is 676 available and supported by all systems participating in an Mbus 677 session. 679 See Section 13 for specifications of how to configure the use of 680 broadcast. 682 7.1.4 Mbus Port Number 684 There will also be a fixed, registered port number that all Mbus 685 entities MUST use. Until the address and port number are assigned 686 the values given in Section 15 SHOULD be used. 688 7.2 Directed Unicast 690 Directed unicast (via UDP) to the port of a specific application is 691 an alternative transport class. Directed unicast is an OPTIONAL 692 optimization and MAY be used by Mbus implementations for delivering 693 messages addressed at a single application entity only -- the 694 address of which the Mbus implementation has learned from other 695 message exchanges before. Note that the DestAddr field of such 696 messages MUST still be filled in properly. Every Mbus entity SHOULD 697 use a unique endpoint address for every message it sends to the Mbus 698 multicast group or to individual receiving entities. A unique 699 endpoint address is a tuple consisting of the entity's IP address 700 and a port number, where the port number is different from the 701 standard Mbus port number (yet to be assigned, see Section 15). 703 Messages MUST only be sent via unicast if the Mbus target address is 704 unique and if the sending entity can verify that the receiving 705 entity uses a unique endpoint address. The latter can be verified by 706 considering the last message received from that entity. (Note that 707 several Mbus entities, say within the same process, may share a 708 common transport address; in this case, the contents of the 709 destination address field is used to further dispatch the message. 710 Given the definition of "unique endpoint address" above the use of a 711 shared endpoint address and a dispatcher still allows other Mbus 712 entities to send unicast messages to one of the entities that share 713 the endpoint address. So this can be considered an implementation 714 detail.) 716 Messages with an empty target address list MUST always be sent to 717 all Mbus entities (via multicast if available). 719 The following algorithm can be used by sending entities to determine 720 whether an Mbus address is unique considering the current set of 721 Mbus entities: 723 let ta=the target address; 724 iterate through the set of all 725 currently known Mbus addresses { 726 let ti=the address in each iteration; 727 count the addresses for which 728 the predicate isSubsetOf(ta,ti) yields true; 729 } 731 If the count of matching addresses is exactly 1 the address is 732 unique. The following algorithm can be used for the predicate 733 isSubsetOf, that checks whether the second message matches the 734 first according to the rules specified in Section 5. (A match 735 means that a receiving entity that uses the second Mbus address 736 must also process received messages with the first address as a 737 target address.) 739 isSubsetOf(addr a1,a2) yields true, iff 740 every address element of a1 is contained 741 in a2's address element list 743 An address element is contained in an address element list if the 744 list contains an element that is equal to the first address 745 element. An address element is considered equal to another 746 address element if it provides the same values for both of the 747 two address element fields (key and value). 749 8. Reliability 751 While most messages are expected to be sent using unreliable 752 transport, it may be necessary to deliver some messages reliably. 753 Reliability can be selected on a per message basis by means of the 754 MessageType field. Reliable delivery is supported for messages with 755 a single recipient only; i.e., all components of the DestAddr field 756 have to be specified. An entity can thus only send reliable messages 757 to known addresses, i.e. it can only send reliable messages to 758 entities that have announced their existence on the Mbus (e.g. by 759 means of mbus.hello() messages (Section 10.1)). A sending entity 760 MUST NOT send a message reliably if the target address is not 761 unique. (See Transport (Section 7) for the specification of an 762 algorithm to determine whether an address is unique.) A receiving 763 entity MUST only process and acknowledge a reliable message if the 764 destination address exactly matches its own source address (the 765 destination address MUST NOT be a subset of the source address). 767 Disallowing reliable message delivery for messages sent to multi- 768 ple destinations is motivated by simplicity of the implementation as 769 well as the protocol. Although ACK implosions are not really an 770 issue and losses are exptected to be rare, achieving reliability for 771 such messages would require full knowledge of the membership for 772 each subgroup which is deemed too much effort. The desired effect 773 can be achieved by application layers by sending individual reliable 774 messages to each fully qualified destination address, if the 775 membership information for the Mbus session is available. 777 Each message is tagged with a message sequence number. If the 778 MessageType is "R", the sender expects an acknowledgment from the 779 recipient within a short period of time. If the acknowledgment is 780 not received within this interval, the sender SHOULD retransmit the 781 message (with the same message sequence number), increase the 782 timeout, and restart the timer. Messages MUST be retransmitted a 783 small number of times (see below) before the transmission or the 784 recipient is considered to have failed. If the message is not 785 delivered successfully, the sending application is notified. In this 786 case, it is up to this application to determine the specific actions 787 (if any) to be taken. 789 Reliable messages are acknowledged by adding their SeqNum to the 790 AckList field of a message sent to the originator of the reliable 791 message. Multiple acknowledgments MAY be sent in a single message. 792 It is possible to either piggy-back the AckList onto another message 793 sent to the same destination, or to send a dedicated acknowledgment 794 message, with no commands in the message payload part. 796 The precise procedures are as follows: 798 Sender: A sender A of a reliable message M to receiver B SHOULD 799 transmit the message via IP-multicast or via IP-unicast, keep a 800 copy of M, initialize a retransmission counter N to '1', and 801 start a retransmission timer T (initialized to T_r). If an 802 acknowledgment is received from B, timer T MUST be cancelled and 803 the copy of M is discarded. If T expires, the message M SHOULD be 804 retransmitted, the counter N SHOULD be incremented by one, and 805 the timer SHOULD be restarted (set to N*T_r). If N exceeds the 806 retransmission threshold N_r, the transmission is assumed to have 807 failed, further retransmission attempts MUST NOT be undertaken, 808 the copy of M SHOULD be discarded, and the sending application 809 SHOULD be notified. 811 Receiver: A receiver B of a reliable message from a sender A SHOULD 812 acknowledge reception of the message within a time period T_c < 813 T_r. This MAY be done by means of a dedicated acknowledgment 814 message or by piggy-backing the acknowledgment on another message 815 addressed only to A. 817 Receiver optimization: In a simple implementation, B may choose to 818 immediately send a dedicated acknowledgment message. However, for 819 efficiency, it could add the SeqNum of the received message to a 820 sender-specific list of acknowledgments; if the added SeqNum is 821 the first acknowledgment in the list, B SHOULD start an 822 acknowledgment timer TA (initialized to T_c). When the timer 823 expires, B SHOULD create a dedicated acknowledgment message and 824 send it to A. If B is to transmit another Mbus message addressed 825 only to A, it should piggy-back the acknowledgments onto this 826 message and cancel TA. In either case, B should store a copy of 827 the acknowledgment list as a single entry in the per- sender copy 828 list, keep this entry for a period T_k, and empty the 829 acknowledgment list. In case any of the messages kept in an entry 830 of the copy list is received again from A, the entire 831 acknowledgment list stored in this entry is scheduled for 832 (re-)transmission following the above rules. 834 Constants and Algorithms: The following constants and algorithms 835 SHOULD be used by implementations: 837 T_r=100ms 839 N_r=3 841 T_c=70ms 843 T_k=((N_r)*(N_r+1)/2)*T_r 845 9. Awareness of other Entities 847 Before Mbus entities can communicate with one another, they need to 848 mutually find out about their existence. After this bootstrap 849 procedure that each Mbus entity goes through all other entities 850 listening to the same Mbus know about the newcomer and the newcomer 851 has learned about all the other entities. Furthermore entities need 852 to be able to to notice the failure (or leaving) of other entities. 854 Any Mbus entity MUST announce its presence (on the Mbus) after 855 starting up. This is to be done repeatedly throughout its lifetime 856 to address the issues of startup sequence: Entities should always 857 become aware of other entities independent of the order of starting. 859 Each Mbus entity MUST maintain the number of Mbus session members 860 and continously update this number according to any observed 861 changes. The mechanisms of how the existence and the leaving of 862 other entities can be detected are dedicated Mbus messages for 863 entity awareness: mbus.hello (Section 10.1) and mbus.bye (Section 864 10.2). Each Mbus protocol implementation MUST periodically send 865 mbus.hello messages that are used by other entities to monitor the 866 existence of that entity. If an entity has not received mbus.hello 867 messages for a certain time (see Section 9.2) from an entity the 868 respective entity is considered to have left the Mbus and MUST be 869 excluded from the set of currently known entities. Upon the 870 reception of a mbus.bye messages the respective entity is considered 871 to have left the Mbus as well and MUST be excluded from the set of 872 currently known entities immediately. 874 Each Mbus entity MUST send hello messages after startup to the Mbus. 875 After transmission of the hello message, it shall start a timer 876 after the expiration of which the next hello message is to be 877 transmitted. Transmission of hello messages MUST NOT be stopped 878 unless the entity detaches from the Mbus. The interval for sending 879 hello messages is depending on the current number of entities in an 880 Mbus group and can thus change dynamically in order to avoid 881 congestion due to many entities sending hello messages at a constant 882 high rate. 884 Section 9.1 specifies the calculation of hello message intervals 885 that MUST be used by protocol implementations. Using the values that 886 are calculated for obtaining the current hello message timer, the 887 timeout for received hello messages is calculated in Section 9.2. 888 Section 10 specifies the command synopsis for the corresponding Mbus 889 messages. 891 9.1 Hello Message Transmission Interval 893 Since Mbus sessions may vary in size concerning the number of 894 entities care must be taken to allow the Mbus protocol to scale well 895 over different numbers of entities automatically. The average rate 896 at which hello messages are received would increase linearly to the 897 number of entities in a session if the sending interval was set to a 898 fixed value. Given a interval of 1 second this would mean that an 899 entity taking part in an Mbus session with n entities would receive 900 n hello messages per second. Assuming all entities resided on one 901 host this would lead to n*n messages that have to be processed per 902 second -- which is obviously not a viable solution for larger 903 groups. It is therefore necessary to deploy dynamically adapted 904 hello message intervals taking varying numbers of entities into 905 account. In the following we specify an algorithm that MUST be used 906 by implementations to calculate the interval for hello messages 907 considering the observed number of Mbus entities. 909 The algorithm features the following characteristics: 911 o The number of hello messages that are received by a single entity 912 in a certain time unit remains approximately constant as the 913 number of entities changes. 915 o The effective interval that is used by a specific Mbus entity is 916 randomized in order to avoid unintentional synchronization of 917 hello messages within an Mbus session. The first hello message of 918 an entity is also delayed by a certain random amount of time. 920 o A timer reconsideration mechanism is deployed in order to adapt 921 the interval more appropriately in situations where a rapid 922 change of the number of entities is observed. This is useful when 923 an entity joins an Mbus sessions and is still learning of the 924 existence of other entities or when a larger number of entities 925 leaves the Mbus at once. 927 9.1.1 Calculating the Interval for Hello Messages 929 The following names for values are used in the calculation specified 930 below (all time values in milliseconds): 932 hello_p: The last time a hello message has been sent by a Mbus 933 entity. 935 hello_now: The current time 937 hello_d: The deterministic calculated interval between hello 938 messages. 940 hello_e: The effective (randomized) interval between hello messages. 942 hello_n: The time for the next scheduled transmission of a hello 943 message. 945 entities_p: The numbers of entities at the time hello_n has been 946 last recomputed. 948 entities: The number of currently known entities. 950 The interval between hello messages MUST be calculated as follows: 952 The number of currently known entities is multiplied by 953 c_hello_factor, yielding the interval between hello messages in 954 milliseconds. This is the deterministic calculated interval, 955 denominated hello_d. The minimum value for hello_d is c_hello_min. 956 Thus hello_d=max(c_hello_min,c_hello_factor * entities). Section 9 957 provides a specification of how to obtain the number of currently 958 known entities. Section 11 provides values for the constants 959 c_hello_factor and c_hello_min. 961 The effective interval hello_e that is to be used by individual 962 entities is calculated by multiplying hello_d with a randomly chosen 963 number between c_hello_dither_min and c_hello_dither_max (see 964 Section 11). 966 hello_n, the time for the next hello message in milliseconds is set 967 to hello_e + hello_now. 969 9.1.2 Initialization of Values 971 Upon joining a session a protocol implementation sets hello_p, 972 hello_now to 0 and entities, entities_p to 1 (the current Mbus 973 entity itself) and then calculates the time for the next hello 974 message as specified in Section 9.1.1. The next hello message is 975 scheduled for transmission at hello_n. 977 9.1.3 Adjusting the Hello Message Interval when the Number of Entities 978 increases 980 When the existence of a new entity is observed by a protocol 981 implementation the number of currently known entities is updated. No 982 further action concerning the calculation of the hello message 983 interval is required. The reconsideration of the timer interval 984 takes place when the current timer for the next hello message 985 expires (see Section 9.1.5). 987 9.1.4 Adjusting the Hello Message Interval when the Number of Entities 988 decreases 990 Upon realizing that an entity has left the Mbus the number of 991 currently known entities is updated and the following algorithm 992 should be used to reconsider the timer interval for hello messages: 994 1. The value for hello_n is updated by setting hello_n to 995 hello_now + (entities/entities_p)*(hello_n - hello_now) 997 2. The value for hello_p is updated by setting hello_p to 998 hello_now - (entities/entities_p)*(hello_now - hello_p) 1000 3. The currently active timer for the next hello messages is 1001 cancelled and a new timer is started for hello_n. 1003 4. entities_p is set to entities. 1005 9.1.5 Expiration of hello timers 1007 When the hello message timer expires, the protocol implementation 1008 MUST perform the following operations: 1010 The hello interval hello_e is computed as specified in Section 1011 9.1.1. 1013 If 1015 1. hello_e + hello_p is less than or equal to hello_now, a hello 1016 message is transmitted. hello_p is set to hello_now, hello_e 1017 is calculated again as specified in Section 9.1.1 and hello_n 1018 is set to hello_e + hello_now. 1020 2. else if hello_e + hello_p is greater than hello_now, hello_n 1021 is set to hello_e + hello_p. A new timer for the next hello 1022 message is started to expire at hello_n. No hello message is 1023 transmitted. 1025 entities_p is set to entities. 1027 9.2 Calculating the Timeout for Hello Messages 1029 Whenever an Mbus entity has not heard for a time span of 1030 c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from another 1031 Mbus entity it may consider this entity to have failed (or have quit 1032 silently). The number of the currently known entities MUST be 1033 updated accordingly. Note that no need for any further action is 1034 necessarily implied from this observation. 1036 Section 9.1.1 specifies how to obtain hello_d. Section 11 defines 1037 values for the constants c_hello_dead and c_hello_dither_max. 1039 10. Messages 1041 This section defines some basic application independent messages 1042 that MUST be understood by all implementations. This specification 1043 does not contain application specific messages which are to be 1044 defined outside of the basic Mbus protocol specification. 1046 An Mbus entity should be able to indicate that it is waiting for a 1047 certain event to happen (similar to a P() operation on a semaphore 1048 but without creating external state somewhere). In conjunction with 1049 this, an Mbus entity should be capable of indicating to another 1050 entity that this condition is now satisfied (similar to a 1051 semaphore's V() operation). 1053 An appropriate commend set to implement the aforementioned concepts 1054 is presented in the following sections. 1056 10.1 mbus.hello 1058 Syntax: 1059 mbus.hello(parameters...) 1061 Parameters: see below 1063 HELLO messages MUST be sent unreliably to all Mbus entities. 1065 Each Mbus entity learns about other Mbus entities by observing their 1066 HELLO messages and tracking the sender address of each message and 1067 can thus calculate the current number of entities. 1069 HELLO messages MUST be sent periodically in dynamically calculated 1070 intervals as specified in Section 9. 1072 Upon startup the first HELLO message MUST be sent after a delay 1073 hello_delay, where hello_delay be a randomly chosen number between 0 1074 and c_hello_min (see Section 11). 1076 10.2 mbus.bye 1078 Syntax: 1080 Parameters: - none - 1082 An Mbus entity that is about to terminate (or "detach" from the 1083 Mbus) SHOULD announce this by transmitting a BYE message. 1085 The BYE message MUST be sent unreliably to all entities. 1087 10.3 mbus.ping 1089 Syntax: 1091 Parameters: - none - 1093 mbus.ping can be used to solicit other entities to signal their 1094 existence by replying with a mbus.hello message. Each protocol 1095 implementation MUST understand mbus.ping and reply with a mbus.hello 1096 message. The reply hello message MUST be delayed for hello_delay 1097 milliseconds, where hello_delay be a randomly chosen number between 1098 0 and c_hello_min (see Section 11). 1100 As specified in Section 10.1 hello messages MUST be sent unreliably 1101 to all Mbus entities. This is also the case for replies to ping 1102 messages. An entity that replies to mbus.ping with mbus.hello should 1103 stop any outstanding timers for hello messages after sending the 1104 hello message and schedule a new timer event for the subsequent 1105 hello message. (Note that using the variables and the algorithms of 1106 Section 9.1.1 this can be achieved by setting hello_p to hello_now.) 1108 mbus.ping allows a new entity to quickly check for other entities 1109 without having to wait for the regular individual hello messages. By 1110 specifying a target address the new entity can restrict the 1111 solicitation for hello messages to a subset of entities it is 1112 interested in. 1114 10.4 mbus.quit 1116 Syntax: 1117 mbus.quit() 1119 Parameters: - none - 1121 The QUIT message is used to request other entities to terminate 1122 themselves (and detach from the Mbus). Whether this request is 1123 honoured by receiving entities or not is up to the discretion of the 1124 application. 1126 The QUIT message can be multicast or sent reliably via unicast to a 1127 single Mbus entity or a group of entities. 1129 10.5 mbus.waiting 1131 Syntax: 1132 mbus.waiting(condition) 1134 Parameters: 1136 symbol condition 1137 The condition parameter is used to indicate that the entity 1138 transmitting this message is waiting for a particular event to 1139 occur. 1141 The WAITING messages may be broadcast to all Mbus entities, 1142 multicast to an arbitrary subgroup, or unicast to a particular peer. 1143 Transmission of the WAITING message MUST be unreliable and hence has 1144 to be repeated at an application-defined interval (until the 1145 condition is satisfied). 1147 If an application wants to indicate that it is waiting for several 1148 conditions to be met, several WAITING messages are sent (possibly 1149 included in the same Mbus payload). Note that HELLO and WAITING 1150 messages may also be transmitted in a single Mbus payload. 1152 10.6 mbus.go 1154 Syntax: 1155 mbus.go(condition) 1157 Parameters: 1159 symbol condition 1160 This parameter specifies which condition is met. 1162 The GO message is sent by an Mbus entity to "unblock" another Mbus 1163 entity -- the latter of which has indicated that it is waiting for a 1164 certain condition to be met. Only a single condition can be 1165 specified per GO message. If several conditions are satisfied 1166 simultaneously multiple GO messages MAY be combined in a single Mbus 1167 payload. 1169 The GO message MUST be sent reliably via unicast to the Mbus entity 1170 to unblock. 1172 11. Constants 1174 The following values for timers and counters mentioned in this 1175 document SHOULD be used by implementations: 1177 +-------------------+------------------------+--------------+ 1178 |Timer / Counter | Value | Unit | 1179 +-------------------+------------------------+--------------+ 1180 |c_hello_factor | 200 | - | 1181 |c_hello_min | 1000 | milliseconds | 1182 |c_hello_dither_min | 0.9 | - | 1183 |c_hello_dither_max | 1.1 | - | 1184 |c_hello_dead | 5 | - | 1185 +-------------------+------------------------+--------------+ 1187 12. Mbus Security 1189 12.1 Security Model 1191 In order to prevent accidental or malicious disturbance of Mbus 1192 communications through messages originated by applications from 1193 other users, message authentication is deployed (Section 12.3). For 1194 each message a digest is calculated based on the value of a shared 1195 secret key value. Receivers of messages can check if the sender 1196 belongs to the same Mbus security domain by re-calculating the 1197 digest and comparing it to the received value. Only if both values 1198 are equal the messages must be processed further. In order to allow 1199 different simultaneous Mbus sessions at a given scope and to 1200 compensate defective implementations of host local multicast message 1201 authentication MUST be provided by conforming implementations. 1203 Privacy of Mbus message transport can be achieved by optionally 1204 using symmetric encryption methods (Section 12.2). Each message can 1205 be encrypted using an additional shared secret key and a symmetric 1206 encryption algorithm. Encryption is OPTIONAL for applications, i.e. 1207 it is allowed to configure an Mbus domain not to use encryption. But 1208 conforming implementations MUST provide the possibility to use 1209 message encryption (see below). 1211 Message authentication and encryption can be parameterized by 1212 certain values, e.g. by the algorithms to apply or by the keys to 1213 use. These parameters (amongst others) are defined in an Mbus 1214 configuration entity that is accessible to all Mbus entities that 1215 participate in an Mbus session. In order to achieve interoperability 1216 conforming implementations SHOULD consider the given Mbus 1217 configuration entity. Section 13 defines the mandatory and optional 1218 parameters as well as storage procedures for different platforms. 1219 Only in cases where none of the options for configuration entities 1220 mentioned in Section 13 is applicable alternative methods of 1221 configuring Mbus protocol entities MAY be deployed. 1223 The algorithms and procedures for applying encryption and 1224 authentication techniques are specified in the following sections. 1226 12.2 Encryption 1228 Encryption of messages is OPTIONAL, that means, an Mbus MAY be 1229 configured not to use encryption. 1231 Implementations can choose between different encryption algorithms. 1232 Either AES [17], DES [15], 3DES (triple DES) [15] or IDEA [21] 1233 SHOULD be used for encryption. Implementations MUST at least provide 1234 AES and it is RECOMMENDED that they support the other algorithms as 1235 well. 1237 For algorithms requiring en/decryption data to be padded to certain 1238 boundaries octets with a value of 0 SHOULD be used for padding 1239 characters. The padding characters MUST be appended after 1240 calculating the message digest when encoding and MUST be erased 1241 before recalculating the message digest when decoding. 1243 The length of the encryption keys is determined by the currently 1244 used encryption algorithm. This means, the configured encryption key 1245 MUST NOT be shorter than the native key length for the currently 1246 configured algorithm. 1248 DES implementations MUST use the DES Cipher Block Chaining (CBC) 1249 mode. DES keys (56 bits) MUST be encoded as 8 octets as described in 1250 RFC1423[11], resulting in 12 Base64-encoded characters. IDEA uses 1251 128-bit keys (24 Base64-encoded characters). AES can use either 1252 128-bit, 192-bit or 256-bit keys. For Mbus encryption only 128-bit 1253 keys (24 Base64-encoded characters) MUST be used. 1255 12.3 Message Authentication 1257 For authentication of messages, hashed message authentication codes 1258 (HMACs) as described in RFC2104[4] are deployed. In general, 1259 implementations can choose between a number of digest algorithms. 1260 For Mbus authentication, the HMAC algorithm MUST be applied in the 1261 following way: 1263 The keyed hash value is calculated using the HMAC algorithm 1264 specified in RFC2104[4]. The concrete hash algorithm and the 1265 secret hash key MUST be obtained from the Mbus configuration (see 1266 Section 13). 1268 The keyed hash values (see RFC2104[4]) MUST be truncated to 96 1269 bits (12 octets). 1271 Subsequently, the resulting 12 octets MUST be Base64-encoded, 1272 resulting in 16 Base64-encoded characters (see RFC1521[6]). 1274 Either MD5 [14] or SHA-1 [16] SHOULD be used for message 1275 authentication codes (MACs). An implementation MAY provide MD5, 1276 whereas SHA-1 MUST be implemented. 1278 The length of the hash keys is determined by the selected hashing 1279 algorithm. This means, the configured hash key MUST NOT be shorter 1280 than the native key length for the currently configured algorithm. 1282 12.4 Procedures for Senders and Receivers 1284 The mandatory subset of algorithms that MUST be provided by 1285 implementations is AES and SHA-1. 1287 See Section 13 for a specification of notations for Base64-strings. 1289 A sender MUST apply the following operations to a message that is to 1290 be sent: 1292 1. If encryption is enabled, the message MUST be encrypted using 1293 the configured algorithm and the configured encryption key. 1294 Padding (adding extra-characters) for block-ciphers MUST be 1295 applied as specified in Section 12.2. If encryption is not 1296 enabled, the message is left unchanged. 1298 2. Subsequently, a message authentication code (MAC) for the 1299 encrypted message MUST be calculated using the configured 1300 HMAC-algorithm and the configured hash key. 1302 3. The MAC MUST then be converted to Base64 encoding, resulting in 1303 12 Base64-charcters as specified in Section 12.3. 1305 4. At last, the sender MUST construct the final message by placing 1306 the encrypted message after the base64-encoded MAC and a CRLF. 1307 The ABNF definition for the final message is as follows: 1309 final_msg = MsgDigest CRLF encr_msg 1311 MsgDigest = base64 1313 encr_msg = *OCTET 1315 A receiver MUST apply the following operations to a message that it 1316 has received: 1318 1. Separate the base64-encoded MAC from the encypted message and 1319 decode the MAC. 1321 2. Re-calculate the MAC for the message using the configured 1322 HMAC-algorithm and the configured hash key. 1324 3. Compare the original MAC with re-calculated MAC. If they differ, 1325 the message MUST NOT be decrypted and parsed further. 1327 4. If encryption is enabled, the message MUST be decrypted using 1328 the confiured algorithm and the configured encryption key. 1329 Trailing octets with a value of 0 MUST be deleted. 1331 13. Mbus Configuration 1333 An implementation MUST be configurable by the following parameters: 1335 Configuration version 1337 The version number of the given configuration entity. Version 1338 numbers allow implementations to check if they can process the 1339 entries of a given configuration entity. Version number are 1340 integer values. The version number for the version specified 1341 here is 1. 1343 Encryption key 1345 The secret key used for message encryption. 1347 Hash key 1349 The hash key used for message authentication. 1351 Scope 1353 The multicast scope to be used for sent messages. 1355 The upper parameters are mandatory and MUST be present in every Mbus 1356 configuration entity. 1358 The following parameters are optional. When they are present they 1359 MUST be honoured but when they are not present implementations 1360 SHOULD fall back to the predefined default values (as defined in 1361 Transport (Section 7)): 1363 Address 1365 The non-standard multicast address to use for message 1366 transport. 1368 Use of Broadcast 1370 It can be specified whether broadcast should be used. If 1371 broadcast has been configured implementations SHOULD use the 1372 network broadcast address (as specified in Section 7.1.3) 1373 instead of the standard multicast address. 1375 Port Number 1377 The non-standard port number to use for message transport. 1379 Two distinct facilities for parameter storage are considered: For 1380 Unix-like systems a configuration file SHOULD be used and for 1381 Windows-95/98/NT/2000 systems a set of registry entries is defined 1382 that SHOULD be used. For other systems it is RECOMMENDED that the 1383 file-based configuration mechanism is used. 1385 The syntax of the values for the respective parameter entries 1386 remains the same for both configuration facilities. The following 1387 defines a set of ABNF (see RFC2234[12]) productions that are later 1388 referenced for the definitions for the configuration file syntax and 1389 registry entries: 1391 algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" / 1392 "HMAC-MD5-96" / "HMAC-SHA1-96" 1394 scope = "HOSTLOCAL" / "LINKLOCAL" 1396 key = base64 1398 version_number = 1*10DIGIT 1400 key_value = "(" algo-id "," key ")" 1402 address = IPv4address / IPv6address / "BROADCAST" 1404 port = 1*5DIGIT 1406 Given the definition above, a key entry MUST be specified using this 1407 notation: 1409 "("algo-id","base64string")" 1411 algo-id is one of the character strings specified above. For 1412 algo-id==``NOENCR'' the other fields are ignored. The delimiting 1413 commas MUST always be present though. 1415 A Base64 string consists of the characters defined in the Base64 1416 char-set (see RFC1521[6]) including all eventual padding characters, 1417 i.e. the length of a Base64-string is always a multiple of 4. 1419 The scope parameter is used to configure an IP-Multicast scope and 1420 may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations 1421 SHOULD choose an appropriate IP-Multicast scope depending on the 1422 value of this parameter and construct an effective IP-Address 1423 considering the specifications of Section 7.1. 1425 The use of broadcast is configured by providing the value 1426 "BROADCAST" for the address field. If broadcast has been configured, 1427 implementations SHOULD use the network broadcast address for the 1428 used IP version instead of the standard multicast address. 1430 The version_number parameter specifies a version number for the used 1431 configuration entity. 1433 13.1 File based parameter storage 1435 The file name for an Mbus configuration file is ".mbus" in the 1436 user's home-directory. If an environment variable called MBUS is 1437 defined implementations SHOULD interpret the value of this variable 1438 as a fully qualified file name that is to be used for the 1439 configuration file. Implementations MUST ensure that this file has 1440 appropriate file permissions that prevent other users to read or 1441 write it. The file MUST exist before a conference is initiated. Its 1442 contents MUST be UTF-8 encoded and MUST be structured as follows: 1444 mbus-file = mbus-topic LF *(entry LF) 1446 mbus-topic = "[MBUS]" 1448 entry = 1*(version_info / hashkey_info 1449 / encryptionkey_info / scope_info 1450 / port_info / address_info) 1452 version_info = "CONFIG_VERSION=" version_number 1454 hashkey_info = "HASHKEY=" key_value 1456 encrkey_info = "ENCRYPTIONKEY=" key_value 1458 scope_info = "SCOPE=" scope 1460 port_info = "PORT=" port 1462 address_info = "ADDRESS=" address 1464 The following entries are defined: CONFIG_VERSION, HASHKEY, 1465 ENCRYPTIONKEY, SCOPE, PORT, ADDRESS. 1467 The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory, 1468 they MUST be present in every Mbus configuration file. The order of 1469 entries is not significant. 1471 An example Mbus configuration file: 1473 [MBUS] 1474 CONFIG_VERSION=1 1475 HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy) 1476 ENCRYPTIONKEY=(DES,MTIzMTU2MQ==) 1477 SCOPE=HOSTLOCAL 1478 ADDRESS=224.255.222.239 1479 PORT=47000 1481 13.2 Registry based parameter storage 1483 For systems lacking the concept of a user's home-directory as a 1484 place for configuration files the suggested database for 1485 configuration settings (e.g. the Windows9x-, Windows NT-, Windows 1486 2000-registry) SHOULD be used. The hierarchy for Mbus related 1487 registry entries is as follows: 1489 HKEY_CURRENT_USER\Software\Mbone Applications\Mbus 1491 The entries in this hierarchy section are: 1493 +---------------+--------+----------------+ 1494 |Name | Type | ABNF production| 1495 +---------------+--------+----------------| 1496 |CONFIG_VERSION | DWORD | version_number | 1497 |HASHKEY | String | key_value | 1498 |ENCRYPTIONKEY | String | key_value | 1499 |SCOPE | String | scope | 1500 |ADDRESS | String | address | 1501 |PORT | DWORD | port | 1502 +---------------+--------+----------------+ 1504 The same syntax for key values as for the file based configuration 1505 facility MUST be used. 1507 14. Security Considerations 1509 The Mbus security mechanisms are specified in Section 12.1. 1511 It should be noted that the Mbus transport specification defines a 1512 mandatory baseline set of algorithms that have to be supported by 1513 implementations. This baseline set is intended to provide reasonable 1514 security by mandating algorithms and key lengths that are currently 1515 considered to be cryptographically strong enough. 1517 However, in order to allow for efficiency it is allowable to use 1518 cryptographically weaker algorithms, for example HMAC-MD5 instead of 1519 HMAC-SHA1. Furthermore, encryption can be turned off completely if 1520 privacy is provided by other means or not considered important for a 1521 certain application. 1523 Users of the Mbus should therefore be aware of the selected security 1524 configuration and should check if it meets the security demands for 1525 a given application. Since every implementation MUST provide the 1526 cryptographically strong algorithm it should always be possible to 1527 configure an Mbus in a way that secure communication with 1528 authentication and privacy is ensured. 1530 In any way, application developers should be aware of incorrect IP 1531 implementations that do not conform to RFC 1122[2] and do send 1532 datagrams with TTL values of zero, resulting in Mbus messages sent 1533 to the local network link although a user might have selected host 1534 local scope in the Mbus configuration. When using of 1535 administratively scoped multicast users cannot always assume the 1536 presence of correctly configured boundary routers. In these cases 1537 the use of encryption SHOULD be considered if privacy is desired. 1539 15. IANA Considerations 1541 The IANA is requested to assign a link-local IPv4 multicast address 1542 from the address space 224.0.0.0/24, an IPv6 permanent multicast 1543 address and a port number. For the time being the tentative IPv4 1544 multicast address 239.255.255.247 and the port number 47000 1545 (decimal) SHOULD be used. 1547 References 1549 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1550 Levels", RFC 2119, BCP 14, March 1997. 1552 [2] Braden, R., "Requirements for Internet Hosts -- Communication 1553 Layers", RFC 1122, October 1989. 1555 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 1556 Architecture", RFC 2373, July 1998. 1558 [4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1559 for Message Authentication", RFC 2104, February 1997. 1561 [5] Crocker, D.H., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 1562 MESSAGES", August 1982. 1564 [6] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 1565 Extensions) Part One: Mechanisms for Specifying and Describing 1566 the Format of Internet Message Bodies", RFC 1521, September 1567 1993. 1569 [7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, 1570 "RTP: A Transport Protocol for Real-Time Applications", RFC 1571 1889, January 1996. 1573 [8] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 1574 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 1576 [9] Handley, M. and V. Jacobsen, "SDP: Session Description 1577 Protocol", RFC 2327, April 1998. 1579 [10] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 1580 July 1998. 1582 [11] Balenson, D., "Privacy Enhancement for Internet Electronic 1583 Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, 1584 February 1993. 1586 [12] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1587 Specifications: ABNF", RFC 2234, November 1997. 1589 [13] Myers, J., "SMTP Service Extension for Authentication", RFC 1590 2554, March 1999. 1592 [14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1593 April 1992. 1595 [15] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards 1596 and Technology, "Data Encryption Standard (DES)", FIPS PUB 1597 46-3, Category Computer Security, Subcategory Cryptography, 1598 October 1999. 1600 [16] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards 1601 and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1602 1995. 1604 [17] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March 1605 1999. 1607 [18] Hinden, R.M. and S.E. Deering, "IP Version 6 Addressing 1608 Architecture", RFC 2373, July 1998. 1610 [19] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The 1611 Internet Multimedia Conferencing Architecture", Internet Draft 1612 draft-ietf-mmusic-confarch-03.txt, status: non-normative, July 1613 2000. 1615 [20] Ott, J., Perkins, C. and D. Kutscher, "Requirements for Local 1616 Conference Control", Internet Draft 1617 draft-ietf-mmusic-mbus-req-00.txt, status: non-normative, 1618 December 1999. 1620 [21] Schneier, B., "Applied Cryptography", Edition 2, Publisher 1621 John Wiley & Sons, Inc., status: non-normative, 1996. 1623 [22] distributed.net, "Project DES", WWW 1624 http://www.distributed.net/des/, status: non-normative, 1999. 1626 Authors' Addresses 1628 Joerg Ott 1629 TZI, Universitaet Bremen 1630 Bibliothekstr. 1 1631 Bremen 28359 1632 Germany 1634 Phone: +49.421.201-7028 1635 Fax: +49.421.218-7000 1636 EMail: jo@tzi.uni-bremen.de 1637 Colin Perkins 1638 USC Information Sciences Institute 1639 4350 N. Fairfax Drive #620 1640 Arlington VA 22203 1641 USA 1643 EMail: csp@isi.edu 1645 Dirk Kutscher 1646 TZI, Universitaet Bremen 1647 Bibliothekstr. 1 1648 Bremen 28359 1649 Germany 1651 Phone: +49.421.218-7595 1652 Fax: +49.421.218-7000 1653 EMail: dku@tzi.uni-bremen.de 1655 Appendix A. About References 1657 Please note that the list of references contains normative as well 1658 as non-normative references. Each Non-normative references is marked 1659 as "status: non-normative". All unmarked references are normative. 1661 Appendix B. Limitations and Future Work 1663 The Mbus is a light-weight local coordination mechanism and 1664 deliberately not designed for larger scope coordination. It is 1665 expected to be used on a single node or -- at most -- on a single 1666 network link. 1668 Therefore the Mbus protocol does not contain features that would be 1669 required to qualify it for the use over the global Internet: 1671 There are no mechanisms to provide congestion control. The issue 1672 of congestion control is a general problem for multicast 1673 protocols. The Mbus allows for un-acknowledged messages that are 1674 sent unreliably, for example as event notifications, from one 1675 entity to another. Since negative acknowledgements are not 1676 defined there is no way the sender could realize that it is 1677 flooding another entity or congesting a low bandwidth network 1678 segment. 1680 The reliability mechanism, i.e. the retransmission timers, are 1681 designed to provide effective, responsive message transport on 1682 local links but are not suited to cope with larger delays that 1683 could be introduced from router queues etc. 1685 Some experiments are currently underway to test the applicability of 1686 bridges between different distributed Mbus domains without changing 1687 the basic protocol semantics. Since the use of such bridges should 1688 be orthogonal to the basic Mbus protocol definitions and since these 1689 experiments are still work in progress there is no mention of this 1690 concept in this specification. 1692 Full Copyright Statement 1694 Copyright (C) The Internet Society (2001). All Rights Reserved. 1696 This document and translations of it may be copied and furnished to 1697 others, and derivative works that comment on or otherwise explain it 1698 or assist in its implmentation may be prepared, copied, published 1699 and distributed, in whole or in part, without restriction of any 1700 kind, provided that the above copyright notice and this paragraph 1701 are included on all such copies and derivative works. However, this 1702 document itself may not be modified in any way, such as by removing 1703 the copyright notice or references to the Internet Society or other 1704 Internet organizations, except as needed for the purpose of 1705 developing Internet standards in which case the procedures for 1706 copyrights defined in the Internet Standards process must be 1707 followed, or as required to translate it into languages other than 1708 English. 1710 The limited permissions granted above are perpetual and will not be 1711 revoked by the Internet Society or its successors or assigns. 1713 This document and the information contained herein is provided on an 1714 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1715 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1716 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1717 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1718 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1720 Acknowledgement 1722 Funding for the RFC editor function is currently provided by the 1723 Internet Society.