Internet Engineering Task Force Eunsook Kim Internet Draft Seok Joo Koh draft-ekim-mmusic-sdp-membership-00.txt Shin Gak Kang Juyoung Park Expires: April 2002 ETRI November 2001 Tight membership support in SDP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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. Abstract This document defines a set of Session Description Protocol (SDP) attributes that allow SDP to provides tightly controlled membership information. Some multimedia conferencing applications may require strict membership control policies and an application user may want to know the membership characteristics such as who are listening to the conference or who has an authority to own the session and to speak in the session. Reliable multicast protocols also need the precise group information for reliability control. This document describes the membership management models and defines extending attributes of SDP for supporting the tight coordination of group membership control. ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 1] INTERNET-DRAFT Expires: April 2002 November 2001 Table of Contents 1. Introduction................................................2 2. Definition of Terms.........................................2 3. Considerations of membership information ..................3 4. New attributes for membership description in SDP............4 4.1 Extension of Session-level attributes...................4 4.2 Extension of Media-level attributes.....................5 4.3 Attributes for Membership Information...................6 5. Examples....................................................8 6. Interoperability with other protocols......................10 7. Security Considerations....................................10 8. Acknowledgements...........................................10 9. References.................................................10 1. Introduction Session Description Protocol (SDP) [SDP] is designed to convey multimedia conference relevant information to recipients. It provides general description for all multimedia sessions. However, it still does not provide specific membership information which is necessary for some multicast sessions. Many scenarios can be examples requiring membership information. In a multicast conference, group organizer may want to designate who should be mandatory participants and how many number of participants are able to be handled when it create a session. In a closed group where only specific member are invited, a prospective group participant may want to know specific group information as well as general information before session joining. Another case is that a contents provider in a cyber education session wants to open the class when it satisfies the minimum required number of participants or to know who is registering the class. These information can carry in a session description when a session creates. This document is based upon a set of requirements to deliver tight controlled membership information. We describe membership model and the corresponding features in SDP by defining a set of new SDP attributes that satisfy the requirements of tight membership control. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 2] INTERNET-DRAFT Expires: April 2002 November 2001 3. Considerations of membership information This section informally outlines categories for membership model of multiparty multimedia session. A certain model assumed for the membership of a session. In terms of membership management, multiparty multimedia session can be classified as following: * open model: everyone can join a session without restriction * closed model: only pre-determined, pre-announced, or end systems determined during runtime can join a session * static model: the group of participants does not change during runtime of the session. * dynamic model: the group of participants might change during runtime of the session. * loose model: a loose group is one for which it is not possible to determine the group membership * tight model: a tight group can provide individual information of member, which can be fully controlled. There may be two sub-categories by participants' knowledge of the membership information: + completely-tight: every member may know the individual name or email address, or et al. + partially-tight: a subset of members may know the individual name or address of every member (e.g. in a conference, a chairman and one or more speakers can acquire the individual details) In the remaining part of this document, the following combinations can be described for group communications: - open and loose - open and tight - closed, static and tight - closed, dynamic, and tight Every multicast application may be classified into one of the above membership classes. The traditional IP Multicast sessions have the open and loose properties, while disseminating applications such as multicast FTP service or a push service may have the closed, dynamic and tight properties. ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 3] INTERNET-DRAFT Expires: April 2002 November 2001 When a software vendor wants to upgrade its product automatically, the product may be defined in having the closed, static and tight ones. Since system and network resources are required for a reliable data transport service, the closed and tight characteristics fit for the service. The open and tight or loose properties may fit for the unreliable transport service only. For those closed and tight membership applications, tight membership control MUST be performed and a management framework can be developed for appropriate functions. We can especially concentrate on "open and tight", "closed, static and tight", and "closed, dynamic, and tight" groups for membership management. 4. New attributes for membership description in SDP For tight controlled membership, SDP MUST be extended to specify additional featuers: registration, retrieval and membership characteristics. These may be operation factors for tight management of membership. 4.1 Extension of Session level attribute * o=
"o=" field structure is identical with that of RFC2327. But the semantic definition may be different according to the message types: We define "create", "query", and "enroll" types, and for "create" smtype, the definition is exactly same with RFC2327, while for "query" and "enroll" types, it contains message sender's username and address in and
. * a=sowner:/// This attibute specifies the contact information of owner in addition to origin field. will be the same with in the origin field. The other conventional formats are identical with RFC2327. * a=sname:/ and identifies a unique session described in [SDP]. A "create" message MUST specify both fields, but a "query" or "enroll" can specify either one or both. ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 4] INTERNET-DRAFT Expires: April 2002 November 2001 * a=smtype: a=smtype:/ This attribute specifies the message types for membership management. holds "create", "query", "enroll", "okcreate", "okquery", and "okenroll". "create"is used for registration of a session description. "okcreate" is used for response of "create". When smtype is "create", it can specify detail membership policy with extending attributes like "a=agipolicy", "a=max/min", and "a=mandatory"(see section 4.3). "query" is used for retrieval of a session description, and "okquery" is used for corresponding response of it. When smtype is "query", "a=sname" attributes might be followed in order to clarify which session information is needed. In a "closed and tight" model anyone interested in a session MUST enroll by "enroll" message and SHOULD get corresponding "okenroll" message for a successful response. can report an unsuccessful result. The possible codes defined are described below: - Client error 1xx "100" - Bad request The request cannot be understood due to malformed syntax. "101" - Unauthorized It will be used for user authentication. An example of this is when the session convey "k=" field with encryption key[SDP], any request by a client can be checked with the key field, and be verified. "102" - Forbidden If a sender holds a "forbidden" list of clients, it can be used. "103" - Not found There is no requested session. "104" - Request Timeout When the requested session is no longer available, or if a session does not provide "late join", late joiner will get this error code. - Sever error 2xx "200" - Service unavailable Server is unable to handle any request of session creation or session requests due to a temporary overloading. This is a temporary condition which will get better after some delay. "201" - Internal server error Server encounters an unexpected error. This will not ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 5] INTERNET-DRAFT Expires: April 2002 November 2001 be overcome for a short period of delay. 4.2 Media-level attributes * m= The definition of "m=" field is the same with that of RFC2327. However, sub-field MUST be extended for various multicast transport protocols, especially for reliable multicast. Currently, RTP/AVP and UDP are supported, and additional values are below: "rmtp" for RMTP/RMTP-II [RMTP_II]; "tram" for TRAM[TRAM]; "lct" for LCT[LCT]; "srm" for SRM [SRM]; "ectp" for ECTP [ECTP]; "a=:/..." attribute MAY follow this filed to specify each characteristics for the above transport protocols. * a=:/... can be defined by each protocols. 4.3 Attributes for membership information * a=agipolicy: a=agipolicy:/ A session owner can define this attribute when it creates a session. Active Group Integrity(AGI) means a set of conditions concerning an active group. filed holds "hard" or "soft". In "hard" policy, the transport connection MUST be terminated when the AGI is violated. In "soft" policy, it MUST be suspended when the AGI is violated and it will be restored if the AGI is recovered. defines "unity" or "quorum", and "complete" or "partial". "unity" specifies that all of enrolled group members are required to be present in the active group. "quorum" implies that the majority of group members are required to be present. In "unity", every other AGI condition such as "a=max", "a=min", and "a=mandatory" is invalid. "complete" implies that all of active member can know the whole session information including membership information (completely tight model), whereas "partial" implies that only authorized users ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 6] INTERNET-DRAFT Expires: April 2002 November 2001 can do it (partially tight model). In "partial" case, only users mentioned in "a=mandatory" attributes can request the information. * a=max: This attributes specifies maximum number of participants that can be allowed in an active group. The value of is represented as a numeric number like "a=max:100". * a=min: This attributes specifies minimum number of participants that can be allowed in an active group. The value of is represented as a numeric number like "a=min:3". * a=token: This attribute specifies maximum number of participants that can be allowed to concurrently transmit data. The value of is represented as a numeric number like "a=token number:3". * a=mandatory:/// This attribute specifies the selected group members required to be present in an active group. The sub-field is identical with "a=sowner" attribute. A series of "a=mandatory" can be specified as following examples. is the same with in origin field of RFC2327. a=mandatory:eunah/Eunsook Kim / +82-42-860-6124/ / a=mandatory:sgkang/Shin Gak Kang / +82-42-860-6117/+82-42-861-5404 In order to identify mandatory users, a key should be exchanged in an out-of-band mechanism. 5. Examples This section provides some examples of use of membership attributes. First, when a conference registrar or conference initiator create a ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 7] INTERNET-DRAFT Expires: April 2002 November 2001 session at a well-known management server, it uses smtype of "create" and the server may response with "okcreate". In this case, it MAY contain ownership and session characteristics. An example is as following: v=0 o=eunah 2890844526 2890842807 IN IP4 129.254.165.100 s=SDP extensions i= Extensions of SDP for tight membership management e=eunah@etri.re.kr p=+82-42-860-6124 t=2873397496 2873404696 a=charset:ISO-8859-1 a=smtype:create a= sname:sdp-extensions/2890844526 a=sowner:eunah/eunah@etri.re.kr (Eunsook Kim)/ / a=agipolicy:hard/quorum a=max:100 a=min:3 a=token:2 a=mandatory:eunah/Eunsook Kim / / a=mandatory:sgkang/Shin Gak Kang / / m=audio 49170 rtp 0 m=video 51372 lct 31 m=application 32416 srm wb a=orient:portrait a=precedence:3 When the server get this messages it can response with "okcreate" as following: v=0 a=smtype:okcreate a=sname:sdp-extensions/2890844526 c= IN IP4 224.2.1.1/127 m=audio 50000 rtp 0 m=video 50001 lct 31 m=application 50002 srm wb In a closed group, when a brief information including session name or group key is announced by out-of-band method such as email, a prospective user can request detail session description. It is notified by smtype, "query". For example, v=0 o=sjkoh * 2846923847 IN IP4 203.251.192.125 a=smtype:query ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 8] INTERNET-DRAFT Expires: April 2002 November 2001 a=sname:sdp-extensions The responding "okquery" gives the whole session description. An example is as following: v=0 o=eunah 2890844526 2890842807 IN IP4 129.254.165.100 s=SDP extensions i= Extensions of SDP for tight membership management e=eunah@etri.re.kr p=+82-42-860-6124 c=IN IP4 224.2.1.1/127 a=charset:ISO-8859-1 a=smtype:okquery a= sname:sdp-extensions/2890844526 a=sowner:eunah/eunah@etri.re.kr (Eunsook Kim)/ / a=agipolicy:hard/quorum a=max:100 a=min:3 a=token:2 a=mandatory:eunah/Eunsook Kim / / a=mandatory:sgkang/Shin Gak Kang / / m=audio 50000 rtp 0 m=video 50001 lct 31 m=application 50002 srm wb a=orient:portrait a=precedence:3 Another example is that a prospective user sends "enroll" message to the server for registration. In a completely tight session, a server should maintain user information of every user from this message. An example of "enroll" can hold following attributes: v=0 o=sjkoh 2890844526 2890832208 IN IP4 134.188.40.100 a=smtype:enroll a=sname:sdp-extensions/2890844526 a=sowner:eunah/eunah@etri.re.kr (Eunsook Kim) / / m=audio 50000 rtp 0 m=video 50001 lct 31 m=application 50002 srm wb The corresponding "okenroll" can be used as following: v=0 o=sjkoh 2890844526 2890832208 IN IP4 134.188.40.100 a=smtype:okenroll a=sname:sdp-extensions/2890844526 ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 9] INTERNET-DRAFT Expires: April 2002 November 2001 a=sowner:eunah/eunah@etri.re.kr (Eunsook Kim) / / m=audio 50000 rtp 0 m=video 50001 lct 31 m=application 50002 srm wb 6. Interoperability with the other protocols [TBD] 7. Security Considerations This section has the same position with SDP[SDP], but it may need stronger security concerns because it is focused on closed or tight sessions. The detail considerations for these sessions will be provided later. [TBD] 8. Acknowledgements 9. References [ECTP] ITU-T Recommendation, X.606 | ISO/IEC 14476-1, "ECTP: Enhanced Communications Transport Protocol, Specification of simplex multicast transmission", Approved on November 2001. [LCT] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley and J. Crowcroft, "Layered Coding Transport: Massively scalable mulitcast protocol," Internet Draft, draft-ietf-rmt-bb-lct- 02.txt, November 2000. [RMTP-II] B. Whetten and G. Taskale, "The Overview of Reliable Multicast Transport Protocol II," IEEE Network, January- February 2000. [RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [SAP] M. Handley, C. Perkins, E. Whelan, "Session announcement protocol", RFC 2974, October 2000 [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 10] INTERNET-DRAFT Expires: April 2002 November 2001 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999 [SRM] S. Floyd, V. Jacobson and S. McCanne, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing," In Proceeding of ACM SIGCOMM '95, Auguest 1995. [TRAM] D. M. Chiu, S. Hurst, M. Kadansky and J. Wesley, "TRAM: A Tree-based Reliable Multicast Protocol," Technical Report of SUN Microsystems, SML TR-98-66, July 1998. Author's Address Eunsook Kim Electronics and Telecommunication Research Institute Protocol Engineering Center 161 Kajeong-Dong, Yuseong-Gu Daejeon, 305-350, Republic of KOREA Phone: 82-42-860-6124 Email: eunah@etri.or.kr Seok Joo Koh ETRI Phone: 82-42-860-6124 Email: sjkoh@etri.or.kr Shin Gak Kang ETRI Phone: 82-42-860-6117 Email: sgkang@etri.re.kr Juyoung Park ETRI Phone: 82-42-860-6124 Email: juyoung@etri.or.kr ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 11] INTERNET-DRAFT Expires: April 2002 November 2001 Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." ekim draft-ekim-mmusic-sdp-membership-00.txt [Page 12]