INTERNET-DRAFT C. Reichert draft-reichert-mmusic-scp-00.txt GMD FOKUS Expires: August 2001 February, 2001 SCP: Session Control Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The Session Control Protocol (SCP) is a scalable application-layer control (signaling) protocol for ongoing course control of Internet multimedia conferences. Other signaling protocols like SIP/SDP or SAP/SDP are required to create SCP control sessions. SCP provides membership control, application session control, floor control and capability exchange. SCP assumes an unreliable group communication service such as IP-multicast and can be extended with additional policies. Table of Contents 1 Introduction...................................... 2 2 Terminology....................................... 2 3 Motivation and Requirements....................... 4 4 Architecture...................................... 6 5 Conference Context................................ 7 6 SDP m= line for SCP............................... 7 7 Membership Control................................ 8 7.1 Open Conferences.................................. 9 7.2 Closed Conferences................................ 9 C. Reichert draft-reichert-mmusic-scp-00.txt [Page 1] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 7.3 Locked Conferences................................ 9 8 Application Sessions Control...................... 10 9 Floor Control..................................... 11 9.1 Automatic Floor Control........................... 12 9.2 Floor Control with a Chair........................ 13 10 Capability Exchange............................... 13 11 Protocol Operation................................ 14 11.1 Reliability....................................... 14 11.2 Application Time.................................. 15 11.3 Concurrency Control............................... 16 11.4 Summary of Operational State...................... 18 11.5 Sending an Operation.............................. 18 11.6 Receiving an Operation............................ 19 11.7 Congestion Control................................ 20 12 Message Syntax.................................... 20 12.1 Common Headers.................................... 22 12.2 Headers for Conference Objects.................... 22 12.3 Headers for Member Objects........................ 23 12.4 Headers for Session Objects....................... 23 12.5 Headers for Floor Objects......................... 23 12.6 Headers for ACL Objects........................... 23 13 Open Issues....................................... 23 14 Security Considerations........................... 24 15 References........................................ 24 16 Acknowledgements.................................. 25 17 Author's Address.................................. 26 1 Introduction SCP is a protocol for ongoing course control, especially a floor control mechanism. A protocol like SCP is needed to decouple mechanims for session initiation/advertising from mechanisms used to perform the ongoing course control. A SCP session is just another "media" session. SDP descriptions, carried in SIP or SAP payloads, may contain a SCP "media" type specification. SCP maintains replicated copies of a conference's state and provides a mechanism for state convergence. As an example, members know from the current conference state whether their audio tools should be muted. The conference state is decomposed into a set of objects, and these objects are updated by two operations, ASSIGN and DELETE. 2 Terminology Application: A running program implementing one or more capabilities. An application sends messages to, and receives messages from, the application session it is participating in. Each application belongs to a particular member, and is controlled by that member. Application Session: A set of applications communicating with each other using a a single capability. Application C. Reichert draft-reichert-mmusic-scp-00.txt [Page 2] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 sessions may be floor controlled or not. This mode can be changed during the lifetime of an application session. Application sessions may be encrypted with shared keys. Application sessions have a certain amount of bandwidth available. Application Capability Set: The set of capabilities supported by an application. Capability: A tuple . Example: Capability Class: Capability classes are Video, Audio, Data, Control and Application. Conference: The entirety of one SCP control session, the members of this control session, and those application sessions for which a SCP session object exists. Each conference has a unique name. Conferences are sometimes called session, but this term is used for single application sessions in this document. Conference Context: The current set of members, application sessions, and other information. The conference context is decomposed into a set of objects. Conference Policy: A set of rules identified by name which constrain the behaviour of members. For example, a conference policy might specify that only a priviledged member is allowed to open application sessions. Floor: An object used to determine the state of an application's outgoing data stream (muted or unmuted) if the application participates in a floor controlled application session. There may be zero or more floors within a conference. Floor Control: A dynamic relationship between members, applications, application sessions and floors. Floor Policy: A set of rules identified by a single name and possibly one or more parameters. Among other things, a floor policy specifies the floor controlling entity. Floor controlling entities may be members or distributed algorithms. Host: A multicast-capable IP-Host able to run a set of applications, including a SCP agent, and a mechanism for local coordination between the SCP agent and its local applications. Member: A SCP agent representing a specific human user within a C. Reichert draft-reichert-mmusic-scp-00.txt [Page 3] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 specific SCP control session. A member and its associated applications, called local applications, typically run on the same host. A member is identified by the host's IP-source address (and port) and the human user's identifier (eg. joe@foo.com). Member Capability Set: The unification of all application capability sets of a member's local applications. Message: A one-line header followed by one or more ADUs. Object: A peace of conference context, identified with a name unique within the conference. Objects have a type, which also denotes a name space, and a value. Additionally, each object has some operational state associated with it. There a five types of objects: members, sessions, floors, access control list (ACL) and conference. Operation: ADUs contain operations. An operation refers to the object it is to be applied to. There are two operations: ASSIGN and DELETE. SCP: Session Control Protocol. SCP is really a Conference Control Protocol, but the name was choosen to fit into the SIP/SAP/SDP convention of protocol names. SCP agent: An application which uses SCP as its application protocol and an interface for local coordination to control other local applications. SCP control session: A special application session which uses SCP as its application protocol. A SCP control session is never floor controlled. 3 Motivation and Requirements A protocol like SCP is needed to decouple the mechanims used to inform particular participants about the existence of a conference from those mechanims used to perform the ongoing course control. SIP/SDP allows to (re-)initiate calls with one or more members. Some SIP messages carry SDP descriptions from which the receiver knows "about a conference", ie. the media descriptions. The "signalling along a line" approach of SIP, however, is unlikely to scale when the number of participants grows. Session directories based on SAP/SDP are used to announce the existence of conferences to an unlimited and anonymous group of potential receivers. The fact that such announcements contain a SDP specification of the application sessions being used implies that conferences are more or less static. Session directory tools like SDR allow to update these announcements, allowing application sessions to be added, updated and removed, C. Reichert draft-reichert-mmusic-scp-00.txt [Page 4] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 encryption key's and application specific attributes to be changed and so on. This approach means that 1. the current state of a conference can be described by a single SDP record 2. a world wide announcement channel is used as the conference control channel for all announced conferences. Architectures centered around conference bridges, also called Multipoint Communication Units (MCUs) do not scale when only a single bridge is used, or become complicated and expensive when (rooted) hierarchies of bridges are setup [GCC], [H.323]. A fully distributed session control protocol should meet the following requirements, listed without special priorities: - Late joining Members may join and leave a conference at any time, and changes in membership may be frequent. - Flexibility In some scenarios, an automatic floor control mechanism to limit bandwidth usage is enough. In others, like tele-teaching or IETF meetings, a chair is required. In such scenarious, it must be clear what it means "to be chair", ie. what priviledges the chair has. This might include ejecting members, restricting who is allowed to open application sessions and so on. - Scalability MBone transmissions of IETF Meetings are examples of large conferences with a few thousands of participants. - State convergence For larger conferences, it is not necessary that all members are absolutly consistent all the time. However, state convergence is required. Also, when network partitions heal, a common state must be reestablished. - ALF based. SCP should be able to handle large groups under dynamic network conditions. This requires not to rely on per message reliability, as protocols which try to give such guarantees are expected to fail. Instead, SCP is based on Application Layer Framing to provide its own mechanisms for reliability and state convergence. - Congestion Control SCP traffic must be subject to congestion control. SCP should also allow the available session bandwidth for application sessions to be changed. - Security C. Reichert draft-reichert-mmusic-scp-00.txt [Page 5] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 In secure conferences, the SCP control session must use encryption, and the architecture must allow to use key- and authentication servers. If the SCP control session is secure, key management for all other application sessions is easy, as symmetric keys can be transmitted over the secure control channel. 4 Architecture SCP agents use an unreliable many-to-many communication service such as IP-multicast to transmit Application Data Units (ADUs) to all other SCP agents. The communication is symmetric and follows the "announce and listen" paradigm, see also [RTP], [SAP], [SRM], [NTE]. The current conference context is updated by sending ADUs and reconstructed from information carried in ADUs. SCP uses application redundancy and periodic, rate limited retransmission to keep members up to date. NOTE: Reliable transport protocols such as Pragmatic General Multicast [PGM] or Scalable Reliable Multicast [SRM] can be used to save bandwidth and to increase responsiveness. Certain objects may be updated by more than one member. A mechanism for concurrency control has to be used to keep the replicated copies of the conference context consistent among all members. For scalability reasons, SCP uses only a weak consistency mechanism based on timestamps (for a definition of weak consistency, see [AGREE]). Short periods of inconsistency may occur, but are assumed to be acceptable. However, the algorithm converges over time. The concurrency control scheme is described in section 8.3. A SCP agent is expected to control its local applications. Besides launching and terminating applications, to be able to react on changes in floor control state, and to react on changes in the capability intersection, a SCP agent communicates with its applications via a local IPC mechanism such as [MBUS]. A SCP agent has to know which conferencing applications are available, and which capabilities these applications support. Applications should accept the following requests made by the local SCP agent: - mute/unmute the applications outgoing data stream (ie. from the application to the network) - change the actually used capability used for the outgoing data stream - change the encryption key used by an application. - react on updates of the bandwidth available for the application session. C. Reichert draft-reichert-mmusic-scp-00.txt [Page 6] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 These are conceptual requirements only. The details on local coordination between an SCP agent and its applications are beyond the scope of this document. 5 Conference Context Conference context is decomposed into the following objects: - Members: the set of member objects, where each member object describes a member being present "in the conference room" - Sessions: the set of application session objects, which describe active media sessions - Conference: the conference object, including available SCP bandwidth and optional policy information - Floor: the floor object, including the floor policy - ACL: an optional access control list The next sections describe these object types in more detail. Each object has a type, which also denotes a namespace, an identifier unique within the objects namespace, and a value. Type and object identifier follow the following syntax: uri ::= type ":" identifier type ::= "member" | "session" | "floor" | "conf" | "acl" identifier ::= Examples: member:john@company.com denotes a member object. session:audio0 denotes a session object member:audio0 denotes a member object different from "session:audio0" floor:default denotes the default floor conf:xyz123@machine.company.com denotes the conference object An object also maintains some operational state, which does not contribute to its semantical value. This information is used for the consistency algorithm described in section 8.3. All signalling within an SCP control session is only done by assignments to and deletions of objects. An object is created by an initial assignment to the (not yet existing) object. SCP uses therefor only two operations: ASSIGN and DELETE. 6 SDP m= line for SCP C. Reichert draft-reichert-mmusic-scp-00.txt [Page 7] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 An SCP control session is simply another "media" session as defined in [SDP]. SDP records may therefor include a media stream of type control, of the form: m=control SCP/0.1 a=fmtp:SCP/0.1 conf= An example of a SDP record describing a control session may look like this: v=0 o=chr 2890844526 2890842807 IN IP4 193.175.133.195 s=SCP Seminar i=A Seminar on the Session Control Protocol e=reichert@fokus.gmd.de (Christoph Reichert) c=IN IP4 224.2.2.2/127 t=0 0 m=control 8000 udp SCP/0.1 a=fmtp:conf=xyz123@193.175.133.195 An SCP control session has an explicit representation within the control session, the SCP conference object. The fmtp:conf attribute denotes the globally unique identifier for this object. This identifier is also part of the message header. Basically, this identifier should be communicated outside of SCP, as SCP messages must include the conference identifier. This is the rational behind the fmtp attribute in the last line of the example above. If only IP multicast address and port number are known, an SCP agent may join the multicast group and listen for a while to learn the conference id. 7 Membership Control Membership control means the following operations: - to join a conference - to leave a conference - to eject a member from a conference Invitation is done via SIP. A member joins the conference by creating its member object. The member also starts to retransmit the initial assignment or any followup of this assignment. Example: SCP/0.1 example joe@foo.com ASSIGN member:joe@foo.com 83456 C. Reichert draft-reichert-mmusic-scp-00.txt [Page 8] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 Ref: 0 // initial assignment Name: Joe Smith // optional Email: smith@foo.com // optional Phone: +12 +34 56789 // optional Caps: audio/PCMU, video/H261, // see [RTP-MIME] text/X-UCLNT . // end of ADU The creation of a member object is not subject to any kind of admission control. The purpose is simply to make other members aware of John's presence "in the conference room". When members receive an initial assigment for a member object, they also store the senders IP address as part of this object's operational state. Member objects MUST only be updated by the member which is represented by the member object. An assignment to a member object from another member or the (apparently) same member but with a different IP address MUST be ignored. 7.1 Open Conferences In open conferences, everybody is welcome, and nobody can be ejected. Therefor, there is no need for an access control list. A member leaves "the conference room" by deleting its member object. In open conferences, only the member itself my delete its member object. Delete messages from other members or (apparently) the same member but with a different IP address MUST be ignored. 7.2 Closed Conferences Every conference starts as an open conference. A conference becomes closed when a member creates a complementary access control list (CACL). The CACL contains ids of members which are ejected from the conference. Every member MUST ignore messages sent from members listed in the CACL. Only the initial creator of the CACL is allowed to update the CACL. Updates of the CACL sent by other members or (apparently) the initial creator but with a different IP source address MUST be ignored. Members MAY mute ejected members of all application sessions locally and MAY setup IGMPv3 [IGMP3] exclude source filters. 7.3 Locked Conferences A closed conference becomes locked, when a key server is invited, for example via SIP, to an ongoing closed conference, and all SCP messages are encrypted. The key server is expected to have a SCP interface, and joins the control session like other members. The key server begins an initial rekey procedure, exluding the members listed in the CACL. C. Reichert draft-reichert-mmusic-scp-00.txt [Page 9] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 The rekey protocol is outside the scope of this document, but may be based on key graphs, as described in section 5.4 of [MCSEC]. Only the CACL creator is allowed to eject members. To do this, the CACL creator deletes the member object of the member to be ejected. (This is the only exception of the rule that only the member represented by a member object may modify this member object). The CACL creator also updates the CACL, and puts the member to be ejected on the CACL. Whenever the keyserver notices a change in the CACL, a rekey procedure is triggered. The CACL owner MAY put more than one member on the CACL in one step. The secured session control channel can be used to carry shared keys for encrypting application session data streams. This can be done easily by including the shared key for an application session within the SDP value of a session object on session creation/modification. 8 Application Session Control Application (or Media) Session Control means the following operations: - to open a new application session - to update an existing application session - to close an existing application session Every member may open/update/close an application session. To open an application session, a member creates a session object with an SDP record as the value. The used capability SHOULD be one out of the common capability intersection (see section 3.4) To update an application session, a new value is assigned to the session object. A session may be updated to change the capability in use, to change the floor control flag, or any other parameters except the id. To close an application session, the session object is deleted. When a SCP agent receives an initial assigment for a session object, its user SHOULD be informed of the new session. The user MAY launch a local application process to participate in the application session. When a SCP agent receives an assigment for an existing session object, its user SHOULD be informed of the new session value. C. Reichert draft-reichert-mmusic-scp-00.txt [Page 10] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 The SCP agent MAY change the capability used by the application. When a SCP agent receives a deletion for an existing session object, it MAY terminate the local application. 9 Floor Control The purpose of floor control is twofold: First, the social context may require floor control; Parliaments and schools are examples for such social contexts. Second, for conferences with many members, the available bandwidth cannot be divided easily in a fair way. Floor control is therefor a mechanism to divide the available bandwith and "to pass the peaces around". Floor control is not intended to be used as a mechanism for distributed process synchronisation like tokens in a multipoint communication service. A token passing service must guarantee that at most one member holds a token. Since SCP does not guarantee consistency, only state convergence, such a service cannot be build from algorithms used in SCP. From the perspective of a single SCP agent, floor control means the following operations: - to request a floor - to release a floor - to grant a floor - to revoke a floor A member is always in one of three states with respect to a floor. The states are named like the colors of a traffic light: red, yellow and green. For simplicity, we simply say "a green member" or "a red member". Since floor control has to be understood also by technically inexperienced end users, this might be a good choice. Throughout the document, at most one floor is assumed, the default floor, or simply, _the_ floor. The use of more than one floors is left for future extensions. If a red member requests the floor, the member changes its color to yellow. When a green or yellow member releases the floor, the member changes its color to red. The latter transition means to withdraw the floor request befor it has been granted. C. Reichert draft-reichert-mmusic-scp-00.txt [Page 11] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 A floor controlling entity may change the color of yellow members either to green, thus granting the request, or to red, thus rejecting the request. This decision may be made an arbitrary amount of time in the future, ie. there is no acknowledgement for the reception of the floor request. A floor controlling entity MUST never change the color of a red member, ie. a member cannot be forced to speak. Floor controlling entities may be members (presidents of parliaments, teachers) or distributed algorithms. According to their color, members can be grouped in three disjoint subsets. Especially the set of yellow members, however, should be treated as a queue, ie. it is a sequence. This allows floor requests to be served on a first come first served basis automatically. So, the state of a floor can be described as three lists of member ids. As the union of the three lists yields the known set of members, one of the lists is redundant. The red set is therefor never explicitly transmitted for floors in SCP. Session objects are marked as floor controlled or not. This distinction is useful for scenarios where, for example, the audio and video session are floor controlled, but a chat tool or a whiteboard, intended to be used as an always available background channel, should not be floor controlled. A green member MAY unmute those local application processes which participate in application sessions marked as being floor controlled. A red or yellow member MUST mute applications participating in these sessions. All members MAY mute incoming data streams sent by red or yellow members, and MAY setup IGMPv3 exlude source filters for their IP source addresses. Floor policies specify when and by whom floor requests are granted and/or revoked. Each floor object contains policy information as part of its value. Policies are uniquely identified and may use additional policy specific parameters. The next two subsections describe two floor policies. 9.1 Automatic Floor Control Automatic floor control is the simplest policy to handle the available bandwidth. Requests for automatically controlled floors cannot be granted or revoked by members. The floor controlling entity is an algorithm. The algorithm expects a non negative integer as input: the maximum number of simultaneous speakers. This maximum resembles the number of microphones in a conference room. C. Reichert draft-reichert-mmusic-scp-00.txt [Page 12] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 As long as the maximum is not reached, floor requests are implicitly granted, ie. the requesting member checks the maximum and puts itself onto the green list. If the maximum is already reached, the member enqueues itself into the yellow list. When a member releases the floor, the member removes itself from the green or yellow list. In the former case, the member also moves the first member id of the yellow list to the green list. A maximum value of zero has the meaning of infinite, ie. every floor request is granted immediatly. This results in simple "push to talk" behaviour. If the maximum is set to one, the floor resembles a token. As already said, SCP floors cannot be used reliably as a multipoint synchronisation mechanism. 9.2 Floor Control with a Chair Extending the policy described in the previous subsection with an additional parameter, the member id of the chair, yields another floor policy. Independent of the current state of the floor, requests made by the chair itself are always granted immediately, ie. the chair puts itself onto the green list. The chair may also grant and revoke the floor, ie. put yellow members on the green list and remove green or yellow members from the corresponding list. As long as the chair does not intervene, and the maximum value is nonzero, chair controlled floors behave like automatically controlled floors. If the maximum value is set to zero, nobody gets the floor automatically. In this case, the chair has to grant all floor requests manually. 10 Capability Exchange The purpose of capability exchange is to figure out a common set of application protocols and codecs. It is assumed that some codecs and application protocols are widely deployed, such as PCM and RTP/AVP. A capability is denoted as described in [RTP-MIME] with an additional transport attribute "transp=", for example: audio/PCMU;transp=RTP/AVP text/X-LBNL-WHITEBOARD;transp=UDP This makes it easy to generate SDP records from capabilities. The capability set of a single application is called an application's capability set (ACS). C. Reichert draft-reichert-mmusic-scp-00.txt [Page 13] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 Every SCP agent collects all of these local ACS. The unification of all local ACS is called the member's capability set (MCS). A member's MCS is part of the its member object value. Every member collects the MCSs of all other members and intersects these MCSs. Members which announce an empty capability set or no capability set at all MUST be ignored during the capability intersection procedure. Only capabilities from the resulting capability intersection SHOULD be used to start application sessions. Other capabilities MAY be used, for example when only a small subset of members lacks a whiteboard capability, then the application session creator may decide to create such a session because most of the participants can handle it. On the other hand, if everybody has capability A, and a potential application session creator has also capability B, then the application session creator knows about this situation through the capability exchange and intersection procedure, and SHOULD use only capability A. Media such as audio and video can be transcoded from one format into another format relativly easily. In case there is no common capability for essential media like audio, a member which has a transcoder available may launch an appropriate transcoder. The member running the transcoder joins the existing audio session and also opens another audio session with the target format as the capability for the second session. All other members typically participate in only one of these application sessions, the member running the transcoder participates in both application sessions. A more detailed analysis of the MCS set is necessary to figure out which capability to use as the target capability. The goal is to find a minimal capability set for a given capability type (ie. audio/*, video/*), so that every member has at least one of those capabilities available. 11 Protocol Operation This section does not yet contain a detailed specification. However, the conceptional building blocks are presented and described. 11.1 Reliablity Essentially, application redundancy seems to result from using only assignment operations to update the state of an replicated object. An assignment contains the complete new value of the object, thus overriding all previous assignments. Therefor, previously sent assignments need not to be retransmitted in case C. Reichert draft-reichert-mmusic-scp-00.txt [Page 14] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 they have been lost. Like other redundancy schemes, such an approach "waists" bandwidth, as complete object values are often larger than incremental operations. For further information on application redundancy, see [HANDLEY], [NTE]. On the other hand, objects have to be retransmitted in case their value does not change for a longer period of time and the last update has been missed by one or more members. In SCP, each object has a current retransmitter. The identifier of the current retransmitter for an object is part of the object's operational state. For member objects, the SCP agent representing a member is always the retransmitter for this member object. When objects of another type than "member:" are created or updated by a member, this member becomes the retransmitter for this object. Member identifiers can be sorted lexicographically. When a member leaves a conference, the member with the id alphabetically next to the leaving member scans the conference context for objects marked as being retransmitted by the member which has left the conference, and becomes the new retransmiter for these objects. If the leaving member is the last member in the sorted list, the first member in the list becomes the retransmitter. The available bandwidth for the SCP control session is given within the conference object. The calculation of the retransmit interval is done as for sender/receiver reports in RTCP [RTP]. 11.2 Application Time The consistency algorithm described in the next section relies on roughly synchronized clocks in SCP agents. Clock synchronisation is done as in the protocol used by NTE, with a clock resolution of milliseconds. Every SCP message contains a timestamp. If and only if a message is received with a timestamp higher than the current value of the local clock, the local clock is set to the value of the timestamp of the received message. Application time advances therefor not necessarily linearly, but strictly monotonically. It has been stated that audio delay must not exceed 250 milliseconds to avoid nuisance of end users. If the same upper bound holds also for SCP messages, clock variation will be never worse, and likely to be much better, than this upper bound. See [NTE] for more information on this scheme. Timestamps are denoted as non-negative integers, denoting milliseconds, counted from midnight of the current day according to UTC. If the duration of a conference crosses a day boundary, the application clock continues, ie. it is not reset to zero. C. Reichert draft-reichert-mmusic-scp-00.txt [Page 15] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 Implementations using 32 bit unsigned integers may therefor participate in a single conference for about 49 days, which is considered long enough. If permanent conferences should become necessary, another approach to express timestamps has to be taken. Example: A message sent at 00:01:23:456 UTC carries the timestamp value 83456. 11.3 Concurrency Control This section describes the concurrency control algorithm with respect to a single object only. A SCP session can be viewed as many per object sessions, multiplexed to a common conference control channel. The algorithm is described in more detail in [STACOV]. Through one timestamp per operation only, a global order is defined on operations. An operation is only applied to an object if the timestamp of the operation is more recent than the timestamp of the corresponding object. Iff an operation is applied to an object, the timestamp of the object is set to the timestamp of the operation. This results only in short periods of inconsistency when operations are received in different order at different receivers, but short periods of inconsistency are believed to be tolerable. To deal with the more difficult problem of two or more operations being sent concurrently for the same object, another timestamp is introduced, the reference timestamp (or ref-time, for short). The first mentioned timestamp is called at-time. Both timestamps are sent in operations and within an object as part of its operational state. When an object is first assigned to (ie. created), the ref-time is set to zero and the at-time is set to the current application time. To send a follow up, the object's current at-time is stored as its new ref-time, and its at-time again is set to the current application time. A causal ordered sequence of states, ie. a sequence where every state Xi+1 is a direct successor of Xi, is therefor represented by a sequence of pairs (P1, P2, P3, ...) of timestamps, where each pair Pi = (Ri, Ai) denotes the ref-time Ri and at-time Ai of the object. For all pairs Pi the condition Ai = Ri+1 holds. Assume two members are consistent and each of them sends an operation concurrently. Both operations refer to the same state and therefor the ref-times Ri of both operations are equal, but the at-times differ. NOTE: This allows messages to be sent *concurrently*, but does not allow messages to be sent *simultaneously*. If two messages carry the same at-time, they must C. Reichert draft-reichert-mmusic-scp-00.txt [Page 16] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 have been sent by different senders. In such a case, the lexicographical order on member identifiers determines which of both at-time values is less. In such a case, the operation with the lower at-time is applied, and the operation with the higher at-time is ignored. The human user sending the operation with the higher at-time will experience that its operation is implicitly undone when its SCP agent eventually receives and applies the operation with the smaller at-time. Such an event may always happen in a communication szenario where more than one member can modify the same particular object, with or without collisions. This behaviour is therefor believed to be acceptable. To avoid propagation of conflicts in case of message loss and short periods of network partition, consider again a SCP session with two concurrently sent operations. The set of members can now be split into four disjoint subsets: A) The set of members which received both operations. B) The set of members which received the "right" operation only, ie. the operation with the lower at-time. C) The set of members which received the "wrong" operation only, ie. the operation with the higher at-time. D) The set of members which received none of both operations. The members from sets A and B are "consistent", where members from set C are "inconsistent" and members of set D are "aged". Only members from set A know that a conflict has occurred. They save the higher at-time in the set of masked timestamps for the object in question. The set of masked timestamps is part of the object's operational state. A masked timestamp is removed when the ref-time becomes higher than the masked timestamp. All members of set A schedule a randomized timer from distribution [TBD] and interval [TBD]. When the timer expires, a retransmission is sent with an additional Mask: header. The Mask header carries the higher at-time. If a retransmission with the masked timestamp is received befor the timer expires, the timer is cancelled. The retransmission (with or without masked timestamps) has good chances to bring "aged" members from set D and "wrong" members from set C up to date. The masked timestamps come into play when a member from set C sends a follow up operation, which is a successor of a "wrong" state and also considered to be "wrong". The ref-time of this follow up is higher than the at-time of members of set A. C. Reichert draft-reichert-mmusic-scp-00.txt [Page 17] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 Members of set A know to ignore the wrong follow up because the ref-time of the wrong follow up is equal to the masked timestamp. But they do not only ignore the wrong follow up, they also add the at-time of the wrong follow up to the set of masked timestamps, which will mask the next follow up of the wrong follow up, and so on. In our example, "aged" members from set D will not only be brought up to date by the retransmission, they will also become "immune" when they receive the masked timestamp. The retransmission with masked timestamps also "immunizes" other members. It should be noted that an object may be reassigned, that is assigning an object's current value as its new value. This will increase the object's ref-time and therefor decrease the number of its masked timestamps. 11.4 Summary of Operational State Each SCP Object has a type, a name and a value. Additionally, for each object, the following opeartinal state information is associated which each object: o member id of current retransmitter o at-time o ref-time o set of masked timestamps. For member objects, the operational state also contains o the member's IP address. The id of the current retransmitter is never transmitted. The other information elements are either carried in an operation's "request"-line (at-time), or in dedicated headers (ref-time, masked timestamps). 11.5 Sending an Operation Let X = (V, R, A, M) be an object with current value V, ref-time R, at-time A, and a set of masked timestamps M = { m1, m2, ..., mm }. An object's invariant has two components: 1. R < A 2. for all mi in M: mi > R A member assigns the new value V' and a new at-time A', where A' is the current application time. The new state is then X' = (V', R', A', M') where C. Reichert draft-reichert-mmusic-scp-00.txt [Page 18] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 o R' = A o M' is a subset of M, and all mi <= R' are removed from M' This state is now encoded in an SCP ADU (application data unit) and send to the network. For initial assignments (creation of objects), R' is zero, and M' is empty. For DELETE operations, V' is empty. A DELETE operation should be retransmit [TBD] times with the regular retransmission interval. 11.6 Receiving an Operation The complexity of the receive procedure comes from the consistency algorithm. When an ADU is received, the invariant given in the previous section is checked. If the invariant does not hold, the ADU is ignored. The objects current state at a receiver is denoted as X = (V, R, A, M). The state contained in the ASSIGN operation is denoted as Xm = (Vm, Rm, Am, Mm). The actions taken by the receiver are given as pseudo code as follows: void receive() { if (R == Rm and A == Am) { // retransmission M = set_unify(Mm, M) // collect masked timestamps return; } if (R > Rm) { // message state is older if (R is element of Mm) // masks our current state goto assign; // we were "wrong" return; } if (R == Rm) { // collision if (A > Am) { // we were "wrong" M = set_insert(A, M); // add A as a masked timestamp goto assign; } else { // other member is wrong assert(A < Am); M = set_insert(Am, M); // add Am as masked timestamp start_randomized_timer(); } return; } assert(R < Rm); C. Reichert draft-reichert-mmusic-scp-00.txt [Page 19] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 if (Rm is element of M) { // we have a mask against this M = set_insert(Am, M); // add Am as a "wrong" follow up return; } if (A < Rm) { // we lost an update } assign: V = Vm; R = Rm; A = Am; } If the operation is a DELETE operation, no value is assigned, of course. In this case, the object is marked as deleted. In case the retransmitter of a deleted object (ie. the retransmitter of the DELETE operation) leaves the session, a potential "lexicographical" neighbour should prepare to continue the retransmissions for the deleted objects it may inherit. 11.7 Congestion Control SCP traffic can be split into two components: traffic from messages actually updating the conference context, and traffic from retransmissions. SCP agents must mesure these rates. Traffic from update messages is caused by human activity. These messages should never be delayed, if possible. Updating messages, however, must be delayed if the currently available session bandwidth, as given in the conference object, is already used up by update traffic. Retransmit traffic must use only the amount of bandwidth not used by update traffic. This can be achieved by periodic recalculation of the retransmit interval, based on the last messurement of update traffic and current value of session bandwidth. Congestion Control is done by changing the available session bandwidth, which causes retransmit intervals to change, changing first the retransmit traffic rate and eventually also the update traffic rate. It is still unclear how congestion is detected and which member changes the session bandwidth. 12 Message Syntax A SCP message carries one or more Application Data Units (ADUs), each of which may or may not carry a payload. Messages and ADUs are text based. Payloads are encoded as MIME-objects or as a C. Reichert draft-reichert-mmusic-scp-00.txt [Page 20] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 sequence of headers. Header lines may folded as in RFC822, HTTP or SIP. Each ADU is either a ASSIGN or a DELETE operation. An example for an SCP message containing a single assignment sent in conference "example" by member "joe@foo.com" for session object "audio0" might look like this: SCP/0.1 example joe@foo.com // message header ASSIGN session:audio0 83456 // operation, obj-uri, at-time Ref: 0 // ref-time Mask: 83457, 83458 // masked timestamps Content-Type: application/sdp Content-Length: 125 v=0 o=- 0 0 IN IP4 0.0.0.0 // o= line not needed s=Default audio session t=0 0 // t= line not needed c=IN IP4 224.2.69.202 m=audio 43258 RTP/AVP 96 a=rtpmap:96 PCMU . // end of ADU indicator A DELETE message which deletes the conference object and therefor terminates the whole conference, might look like: SCP/0.1 example joe DELETE conf:example 87654 Ref: 83456 . Delete operations MUST not carry any payloads. A message carrying two ADUs might be: SCP/0.1 example joe@foo.com // message header ASSIGN session:audio0 10000 // operation, obj-uri, at-time at-time Ref: 83456 // ref-time Content-Type: application/sdp Content-Length: 125 v=0 o=- 0 0 IN IP4 0.0.0.0 // o= line not needed s=Default audio session // just to use s= line t=0 0 // t= line not needed c=IN IP4 224.2.69.202 m=audio 43258 RTP/AVP 96 a=rtpmap:96 PCMU a=type:moderated // audio0 is floor controlled . // end of first ADU ASSIGN floor:default 10000 // second ADU, also ASSIGN Ref: 90000 Policy: auto;max=2 // automatic floor control C. Reichert draft-reichert-mmusic-scp-00.txt [Page 21] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 Yellow: joe@foo.com // Joe has requested the floor Green: jim@bar.com, // Jim and Jack are currently jack@bla.com // talking . // end of second ADU 12.1 Common Headers The following headers are used for all object types. 12.1.1 Content-Type: The value "application/sdp" MUST be implemented. Other MIME types MAY be implemented, for example "application/v-card" for additional member information in a member object. 12.1.2 Content-Length: Like the SIP-Header. 12.1.3 Ref: This header MUST be present for every object type and every operation. The value is a timestamp as defined in section 8.2. The timestamp denotes the operation for which the operation carrying this header is a follow up. 12.1.4 Mask: This header MUST be present if masked timestamps are known for the object. If masked timestamps are known, all of them MUST be given. Otherwise, it MAY be present. In the latter case, it MUST be empty. 12.2 Headers for Conference Objects The type prefix for conference objects is "conf" or "C". The optional header "Subject:" carries a short string describing the purpose of the session. The optional header "Description:" carries an longer string describing the purpose of the session. This can contain URLs. The required header "Bandwidth:" gives the bandwidth for a SCP session in kbit/s. The optional header "Policy:" contains a sequence of tokens, where each token has clear specified semantics. For example, Policy: owned-sessions might denote a policy where only the creator of a session may C. Reichert draft-reichert-mmusic-scp-00.txt [Page 22] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 update and close its sessions. An example for a token with parameters might be Policy: owned-sessions;chair=joe@foo.com would introduce a "session-chair", that is, only joe@foo.com is allowed to open/update/close sessions. There are a lot of possibilities to change the default policy of SCP [TBD]. 12.3 Headers for Member Objects The type prefix for member objects is "member". For each RTCP SDES item, there is a corresponding header with the same meaning: Name, Phone, Loc, Email, Note, ... The optional header "Caps:" carries a set of capabilities. If the set is empty or the header is not present at all, the member has to ignored during the capability intersection procedure. 12.4 Headers for Session Objects The type prefix for session objects is "session". No special headers. Contains always a SDP record as a MIME object. The SDP attribute "a=type:moderated" indiactes the session is floor controlled. The SDP in a session object MUST include exactly one m= line. The m= line MUST include exactly one format. 12.5 Headers for Floor Objects The type prefix for floor objects is "floor". The required header "Policy:" carries an floor policy identifier and any necessary paramters. Example: Policy: auto;max=3;chair=joe@foo.com The required headers "Yellow:" and "Green:" carry a *sequence* of member ids, that is, the order is significant. 12.6 Headers for ACL objects. The type prefix for ACL objects is "acl". 13 Open Issues C. Reichert draft-reichert-mmusic-scp-00.txt [Page 23] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 A lot. Among them: o Who ownes the conference object ? o Who determines when a member has timed out ? Someone should officially eject such a member so all members are consistent. o If a member left, and its "lexicographical neighbour" leaves also befor having sent at least one rxmit, we have "dangling" objects... o A compression scheme for larger SCP messages. Such a scheme would also be useful for Protocols like SIP. o Think about coordination with RSVP, especially when floor control is used. Help from RSVP experts is needed here. o Is the key server approach feasable ? Help from SMUG is needed here. o How is congestion detected ? 14 Security Considerations TBD (by SMUG ?) 15 References [CONFARCH] M. Handley, J. Crowcroft, C. Bormann, J. Ott, "The Internet Multimedia Conferencing Architecture", Internet-Draft draft-ietf-mmusic-confarch-03.txt, July 2000 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999 [SIP-INFO] S. Donovan, "The SIP INFO METHOD", RFC 2976, October 2000 [SIP-CONF] J. Rosenberg, H. Schulzrinne, "Models for Multi Party Conferencing in SIP", Internet-Draft draft-rosenberg-sip-conferencing-models-00.txt, November 2000 [SAP] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000 C. Reichert draft-reichert-mmusic-scp-00.txt [Page 24] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 [SDP] M. Handley, V. Jacobson, "SDP: The Session Description Protocol", RFC 2327, April 1998 [IGMP3] B. Cain, S. Deering, B. Fenner, I. Kouvelas, "Internet Group Management Protocol, Version 3", Internet-Draft draft-ietf-idmr-igmp-v3-06.txt, January 2001 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996 [RTP-MIME] S. Casner, P. Hoschka, "MIME Type Registration of RTP Payload Formats", Internet-Draft draft-ietf-avt-rtp-mime-03.txt, July 2000 [SRM] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework for Light-weight Sessions and Application Layer Framing", Proc ACM SIGCOMM 1995, August 1995 [NTE] M. Handley, J. Crowcroft, "Network Text Editor (NTE) A scalable shared text editor for the MBone", Proc ACM SIGCOMM 97, 1997 [HANDLEY] M. Handley, "On Scalable Internet Multimedia Conferencing Systems", PhD. Thesis, November 1997 [STACOV] C. Reichert, "A Scalable, Distributed Algorithm for State Convergence over Unreliable Group Communication Services", Technical Report, February 2001 [PGM] T. Speakman, D. Farinacci, S. Lin, A. Tweedly et.al., "PGM Reliable Transport Protocol Specification", Internet-Draft draft-speakman-pgm-spec-05.txt, November 2000 [AGREE] S. Shenker, A. Weinrib, E. Schooler, "Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism", Expired Internet-Draft draft-ietf-mmusic-agree-00.ps, July 1995 [MBUS] J. Ott, C. Perkins, D. Kutscher, "A Message Bus for Local Coordination", Internet-Draft draft-ietf-mmusic-mbus-transport-03.txt, November 2000 16 Acknowledgements C. Reichert draft-reichert-mmusic-scp-00.txt [Page 25] INTERNET-DRAFT SCP: Session Control Protocol February, 2001 Thanks to Mikhail Smirnow for the review of this document. 17 Author's Address Christoph Reichert GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Email: reichert@fokus.gmd.de draft-reichert-mmusic-scp-00.txt Expires: August, 2001