Internet Draft Seok Joo Koh, ETRI/KOREA Document: draft-koh-rmt-bb-tsm-00.txt Shin Gak Kang, ETRI/KOREA February 2001 Juyoung Park, ETRI/KOREA Expires August 2001 Eunsook Kim, ETRI/KOREA Reliable Multicast Transport Building Blocks: Transport Session Management <draft-koh-rmt-bb-tsm-00.txt> 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. This document is the result of the joint development work on Enhanced Communications Transport Protocol (ECTP) which is being undertaken by ISO/IEC JTC 1/SC 6 and ITU-T/SG 7. Transmission to the IETF was endorsed at the joint ITU-T/SG 7 and by ISO/IEC JTC 1/SC 6 meeting on 31th Jan. 2001. Abstract This document provides a framework of Transport Session Management (TSM) mechanisms, which has been designed to support desirable management of end-to-end multicast sessions, according to the application's requirements that are represented as a set of TSM parameters including throughput and packet loss rate. TSM operations Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 1]
INTERNET-DRAFT Expires: August 2001 February 2001 include Session Join, Session Monitoring and Session Maintenance. In Session Join, the sender informs authorized receivers about the target values of TSM parameters. In Session Monitoring, each receiver continues to measure the parameter values that have been experienced and to report the status of each parameter value to the sender. Based on the status information monitored and the target values of TSM parameters, the sender takes Session Maintenance actions necessary to maintain the session status desirable. Those actions include adjustment of data transmission rate, troublemaker ejection, session pause/resume, and session termination. TSM mechanisms can be implemented into an API and easily adopted by any RMT PIs that wish to tightly control multicast sessions. 1. Introduction A multicast transport protocol instantiation may include various protocol components such as error recovery, flow and congestion control, membership management, and session management [RMT-DS, RMT- BB]. This document provides a framework of Transport Session Management (TSM) mechanisms, which has been designed to support desirable management of end-to-end multicast sessions, according to the application's requirements that are represented as a set of TSM parameters including throughput and packet loss rate. TSM operations include Session Join, Session Monitoring and Session Maintenance. In Session Join, the sender informs authorized receivers about the target values of TSM parameters. In Session Monitoring, each receiver continues to measure the parameter values that have been experienced and to report the status of each parameter value to the sender. Based on the status information monitored and the target values of TSM parameters, the sender takes Session Maintenance actions necessary to maintain the session status desirable. Those actions include adjustment of data transmission rate, troublemaker ejection, session pause/resume, and session termination. The key feature of TSM is to provide the senders with information on membership tracking and current session status in terms of TSM parameters. Membership information is crucial for design of billing/charging model. Session status needs to be monitored to maintain the session desirable. TSM is a coarsely grained functionality for end-to-end multicast transport, and thus can be considered as a Building Block of RMT. TSM mechanisms can be implemented into an API and easily adopted by any RMT PIs that wish to tightly control multicast sessions. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 2]
INTERNET-DRAFT Expires: August 2001 February 2001 1.1 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]. Transport Session Transport Session refers to a session for multicast data delivery. In a one-to-many multicast session, there are a single sender and many receivers. Transport Session Management (TSM) TSM functionality is provided to maintain a multicast session desirable, according to application's requirements. TSM mechanisms can be implemented into an API that a multicast transport protocol adopts easily. TSM Parameters A TSM parameter is a performance metric that represents session status and Quality of Services for the multicast data delivery. Typical examples of TSM parameters include throughput and packet loss rate. According to application's requirements, the sender may configure a set of target values of each TSM parameter for desirable display of application data. For Session Monitoring, each receiver reports the experienced status for each TSM parameter to the sender. 1.2 Motivations for TSM Some multicast applications have a crucial need to guarantee a desired Quality of Service (QoS) in the delivery of multicast data. In principal, the QoS for data delivery can be supported with help of network-layer resource reservation mechanisms such as RSVP or Diffserv. However, in the end-to-end transport level, the sender needs to monitor and manage how much desirably the QoS for a multicast session is being supported [ECTS, ECTP]. TSM functionality is designed to support a tight control of multicast sessions. TSM mechanisms can be used to maintain the transport session desirable according to the application's requirements, and also to protect the session status from being degraded more severely. 1.3 Rationale of TSM BB Per the guidelines of RMT BB draft [RMT-Author], this section will be filled. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 3]
INTERNET-DRAFT Expires: August 2001 February 2001 TBD 1.4 Applicability Statement Per the guidelines of RMT BB draft [RMT-Author], this section will be filled. TBD 1.5 Relationship with the other BBs and PIs TSM BB does not impose any requirements and modifications on existing RMT BBs and PIs. The TSM functionality and its mechanisms can be easily adopted by any RMT PIs that wish a tight control of multicast session. We note that TSM BB is a good-match with TRACK BB and PI, in the viewpoint of scalability enhancement of feedback messages from receivers to sender. For the sessions concerned with the scalability, it is likely that TSM BB is employed along with TRACK BB or its underlying mechanisms. For the other PIs such as NORM and ALC, TSM can also be employed with provisioning of a suitable feedback mechanism. 2. TSM Overview Transport Session Management (TSM) is designed to support a tight control of multicast sessions. TSM functionality is accomplished by interactions between the sender and receivers. In TSM, the sender is responsible for overall TSM operations. Figure 1 illustrates an overall TSM functionality during a multicast session. TSM functionality is achieved by the following operations: (a) Session Join (b) Session Monitoring (c) Session Maintenance In Session Join, the following two events occur: - Join Request by a receiver - Join Confirm by the sender Each receiver who wants to participate in the session sends a Join Request message to the sender. The sender may make a decision whether the join request should be accepted or not, possibly along Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 4]
INTERNET-DRAFT Expires: August 2001 February 2001 with an authentication process. When the join request is accepted, the sender will sends a Join Confirm message that contains information on the target values of TSM parameters such as throughput and packet loss rate. +--------------------------------------------------------------+ | | | +-------------+ +--------------+ | | | Data Rate | +-------------+ | Session | | | | Adjustment |<--- | Session | ---> | Pause/Resume | | | +-------------+ | Monitoring | +--------------+ | | | with | | | +-------------+ | Membership | +--------------+ | | |Troublemaker |<--- | Tracking | ---> | Session | | | | Ejection | +-------------+ | Termination | | | +-------------+ ^ +--------------+ | | | | +------------------------------+-------------------------------+ ^ | ^ | | | -----------+---------------------+-------------------+-------------- | | | TSM API v | v +---------+ | +-----------+ | | | | | | Sender |============================>| Receivers | | | Multicast Data | | +---------+ +-----------+ Figure 1. TSM Overview Session Monitoring is used for sender to diagnose current session status for multicast data delivery. Session Monitoring also performs 'Membership Tracking', by which the sender keeps track of the list of active receivers. For Session Monitoring, each receiver is required to measure a status value for each TSM parameter that has been experienced for the received multicast data streams. If a status value indicates an abnormal status, the receiver reports the status value to the sender via a TSM Response message. TSM Response messages are also generated in response to the periodic TSM Request messages of the sender. Through these interactions with receivers, the sender can perform the membership tracking. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 5]
INTERNET-DRAFT Expires: August 2001 February 2001 Session Maintenance is performed based on the reported status values and the target values for TSM parameters. Sender continues to aggregate the status values that have been reported from the receivers. Based on the aggregated information, the sender will take one or more of the following Session Maintenance actions: - Adjustment of data transmission rate - Troublemaker ejection - Session pause/resume - Session termination TSM Request messages are also used to indicate a current session status, which is classified into one of the following: - Session Creation - Data Transmission - Session Pause - Session Termination 3. TSM Components 3.1 Sender Sender transmits multicast data to the receivers in the session. It is responsible for the overall TSM operations. 3.2 Receiver A receiver receives multicast data from the sender. TSM is based on interaction between sender and receivers. 3.3 TSM Parameters TSM parameters are used to diagnose a current session status. This document specifies two TSM parameters: throughput and packet loss rate. In the future, more TSM parameters may be added, if necessary. Throughput (THRUPUT) can be represented in units of bytes per second. THRUPUT can be interpreted as data transmission rate at the sender side and also data reception rate at receiver side. Packet loss rate (PLR) is defined as the ratio of lost packets over totally transmitted packets. PLR may be represented as an integer number ranged from 0 to 100. The sequence numbers of data packets can be used to measure the packet loss rate. In Session Join, the sender announces the authorized receiver about the pre-configured target values for each TSM parameter such as - MIN: a minimum value - ALLOWED_LOW: an allowed low value Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 6]
INTERNET-DRAFT Expires: August 2001 February 2001 - ALLOWED_HIGH: an allowed high value - MAX: a maximum value These target values MAY be determined by considering application's requirements. Among those values, the following inequalities are enforced: MIN <= ALLOWED_LOW <= ALLOWED_HIGH <= MAX For THRUPUT parameter, the following variables can be defined: - MIN_THRUPUT - ALLOWED_LOW_THRUPUT - ALLOWED_HIGH_THRUPUT - MAX_THRUPUT For PLR parameter, the following variables can be defined: - MIN_PLR - ALLOWED_LOW_PLR - ALLOWED_HIGH_PLR - MAX_PLR In Session Monitoring, each receiver is required to measure the parameter values experienced for the received multicast data. By comparing the measured values and the target values, the receiver sets each of THRUPUT_STATUS and PLR_STATUS to an integer of '0 through 4' as follows: 0, if ALLOWED_LOW <= measured value <= ALLOWED_HIGH 1, if MIN <= measured value <= ALLOWED_LOW 2, if ALLOWED_HIGH <= measured value <= MAX 3, if measured value <= MIN 4, if MAX <= measured value The STATUS value of '0' represents a normal status, while the non- zero values mean that the session possibly goes into abnormal status (1 or 2), or is currently being in an abnormal status (3 or 4). In Session Monitoring, receivers report those STATUS values to the sender via TSM Response messages. 3.4 TSM Messages The following control messages are used for TSM: - Join Request - Join Confirm - Ejection - TSM Request - TSM Response Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 7]
INTERNET-DRAFT Expires: August 2001 February 2001 Table 1 summarizes the detailed use of those TSM messages. Table 1. TSM messages +--------------+------+-----+-----------+---------------------+ | Message | From | To | Unicast/ | TSM Operation | | Types | | | Multicast | Concerned | +--------------+------+-----+-----------+---------------------+ | Join Request | R | S | Unicast | Session Join | +--------------+------+-----+-----------+---------------------+ | Join Confirm | S | R | Unicast | Session Join | +--------------+------+-----+-----------+---------------------+ | Ejection | S | R | Unicast | Session Maintenance | +--------------+------+-----+-----------+---------------------+ | TSM Request | S | Rs | Multicast | Session Monitoring | +--------------+------+-----+-----------+---------------------+ | TSM Response | R | S | Unicast | Session Monitoring | +--------------+------+-----+-----------+---------------------+ S: Sender, R : Receiver 3.4.1 Join Request A receiver that wishes to join the session sends a Join Request to the sender. 3.4.2 Join Confirm The sender responds with a Join Confirm message to the Join Request. The Join Confirm message contains the following information: - Whether a Join Request is accepted or not - Target values for TSM parameters: MIN, ALLOWED_LOW, ALLOWED_MAX, MAX - Receiver ID for the corresponding receiver The receiver ID can be used for membership tracking, and also used in generation of a TSM Response message (see Section 5). 3.4.3 Ejection In Session Maintenance, the sender MAY eject the trouble-making receiver by sending an Ejection message. 3.4.4 TSM Request The sender transmits periodic TSM Request messages to the receivers. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 8]
INTERNET-DRAFT Expires: August 2001 February 2001 The length of periodic time interval MAY vary depending on implementations. Each TSM Request message triggers the corresponding TSM Response messages from some or all of the receivers. The TSM Request message contains an integer value to indicate the current session status. To do this, the current session status is classified into one of the following phases, with an integer value: - Session Creation (0) - Data Transmission (1) - Session Pause (2) - Session Termination (3) When a session starts, the sender indicates 'Session Creation'. If TSM BB is used in TRACK PI, 'Session Creation' state can be used as an indication signal for an initial tree configuration [TREE]. After a session is created, the TSM Request messages will indicate 'Data Transmission'. 'Session Pause' will be indicated if a sender realizes that the session potentially goes into an abnormal status. In Session Pause period, the sender is not allowed to send any new multicast data. When the session status is perceived to go back to a normal status, the sender will again indicate 'Data Transmission', and then resumes the multicast data transmission. 'Session Termination' is indicated after the sender transmits all the multicast data, or if the session is detected to be in the severe abnormal status. 3.4.5 TSM Response A TSM Response messages contain the following information: - Receiver ID - THRUPUT_STATUS (ranged from 0 - 4) - PLR_STATUS (ranged from 0 - 4) Each receiver generates a TSM message if its measured THRUPUT_STATUS or PLR_STATUS is a non-zero value. TSM messages can also be generated in response to a periodic TSM Request message. 4. TSM Procedures 4.1 Session Join A receiver who wants to join a session sends a Join Request message to the sender. When the sender receives a Join Request message, it MAY check whether the receiver is an authorized user or not. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 9]
INTERNET-DRAFT Expires: August 2001 February 2001 In response to a Join Request, the sender transmits a Join Confirm message to the receiver. The Join Confirm message contains information on Receiver ID and whether the Join Request is accepted or not. The Join Confirm message also contains the pre-configured target values of TSM parameters: MIN, ALLOWED_LOW, ALLOWED_HIGH, and MAX (see 3.3). In the networks that support resource reservation mechanisms such as RSVP and Diffserv, the receiver SHALL initiate the reservation of the required network resources. Then the target parameter values MAY be referred to in the reservation process. 4.2 Session Monitoring In Session Monitoring, the sender monitors how well the session operates and also which receivers are participating in the session. To do this, each receiver is required to measure the THRUPUT and PLR values experienced for the received multicast data. Those measured THRUPUT and PLR values are compared with the target values for THRUPUT and PLR announced in Session Join, and then the receiver determines THRUPUT_STATUS and PLR_STATUS values as 0, 1, 2, 3 or 4 (see 3.3). If the STATUS value is a non-zero value, the receiver generates a TSM Response message. For the STATUS value of '0', the receiver does not need to generate a TSM Response message. In other words, the sender will realize that a receiver is in the normal status, if it does not send any TSM Response messages indicating an abnormal status, where an abnormal status indicates that the STATUS value is non-zero. TSM Response message is also generated responsively to a periodic TSM Request message. This feedback mechanism is designed to support Membership Tracking and an overall identification of the current session status. In response to the periodic TSM Request message, some or all of receivers send TSM Response messages to the sender. To reduce the number of simultaneous TSM Response messages from the receivers, a specific rule MAY be employed. An example is given in Section 5. During a session, the sender aggregates the reported THRUPUT_STATUS and PLR_STATUS values from the receivers. In the aggregation, the following considerations will be taken: - Which receivers are in the abnormal status ? - How many receivers in a given session are in the abnormal status ? Based on this aggregated information, the sender takes one or more Session Maintenance actions. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 10]
INTERNET-DRAFT Expires: August 2001 February 2001 4.3. Session Maintenance Session Maintenance is purposed to maintain the session status desirable, and to prevent the session status from being degraded more severely. Based on the THRUPUT_STATUS and PLR_STATUS values reported from the receivers, the sender takes one or more of the following Session Maintenance actions: - Adjustment of data transmission rate - Ejection of Troublemaker - Session Pause and Resume - Session Termination Depending on application services, some of the actions described above MAY NOT be enabled. For example, for a certain multicast session, the sender MAY NOT perform Troublemaker Ejection. 4.3.1 Adjustment of data transmission rate If this option is enabled, the sender will adjust data transmission rate based on the monitored STATUS values of the TSM parameters. The data transmission rate is bounded as follows: MIN_THRUPUT <= Data Transmission Rate <= MAX_THRUPUT Specific rules to increase or decrease the data transmission rate are for further study, which MAY depend on the Congestion Control algorithm that will be developed in the RMT WG. 4.3.2 Ejection of Troublemaker To determine whether a receiver is a troublemaker or not, the sender MUST configure a rule to trigger a Troublemaker Ejection. The specific rule is an implementation issue. For an example, a receiver can be regarded as a troublemaker if the STATUS values for TSM parameters have been consecutively in abnormal status more than the pre-configured threshold times. Once a troublemaker is detected, the sender sends an Ejection message to the concerned receiver. 4.3.3 Session Pause and Resume Session Pause is used to suspend the data transmission of the sender temporarily and thus to prevent the session from being more severely degraded. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 11]
INTERNET-DRAFT Expires: August 2001 February 2001 The sender announces 'Session Pause' to all the receivers via TSM Request message, which has the session status value of '2' (see 3.4.4). In the Session Pause period, the sender SHALL NOT send any new multicast data. The specific rule to trigger Session Pause can be configured based on the STATUS values reported from the receivers. For an example, if the number of receivers reporting an abnormal status is greater than a pre-configured number, then the sender MAY trigger Session Pause. After Session Pause is indicated, Session Resume will be activated if the session status is perceived to come back into the normal state. The specific rule to trigger Session Resume is an implementation issue. A simple rule to trigger the Session Resume is to use a timer. In this case, if the timer expires after Session Pause is indicated, then the sender will automatically resume the session by sending a TSM Request message with an indication of 'Data Transmission' (see 3.4.4). 4.3.4 Session Termination The natural option for Session Termination is to terminate a session when all the multicast data have been transmitted. Session Termination is also triggered if the session is detected to be in the severe abnormal state. When Session Termination is indicated, the sender terminates the session and sends a TSM Request message with indication of Session Termination. The activation of Session Termination can be performed in various ways. One simple way is to trigger Session Termination if the Session Pause/Resume operations have been consecutively repeated more than a pre-configured times. 5. Scalability Enhancement for Feedback Implosions of TSM Response Messages Session Monitoring is based on the 'TSM Response' feedback messages from the receivers. For the session that consists of a large number of receivers, simultaneous responses of TSM Response messages may induce an implosion of feedback messages. This is referred to as the scalability problem. If a hierarchical control tree [TREE] is employed along with TSM BB, it is clear that we reduce the number of simultaneously generated TSM Response messages. We also propose an alternate scheme to improve the feedback implosion, which has benefited from TRACK BB [TRACK]. Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 12]
INTERNET-DRAFT Expires: August 2001 February 2001 For this purpose, we define the following two new variables: - TSM Sequence Number (TSN) - Response Generation Number (RGN) TSN is an integer number sequentially assigned to each periodic TSM Request massage. RGN is a scaling factor used to limit the number of the simultaneously responding receivers. These variables will be contained in the periodic TSM Request message, if they are enabled for scalability enhancement. For a TSM Request message, each receiver responds with a TSM Response message, if the following condition holds true: (TSN % RGN) == (Receiver ID % RGN), where % represents "modulo" operator. For an example, suppose there are receivers with Receiver ID = 1,..,20. In response to a TSM Request message with TSN = 3 and RGN = 5, the receivers with Receiver ID = 3, 8, 13, 18 will transmit the corresponding TSM Response message. 6. Security Considerations The Join Confirm messages MAY be used to deliver the group key information to the receivers for security purposes, if necessary. In this case, an initial group key will be distributed via the Join Confirm message, and the changed group key information via the subsequent TSM Request messages. 7. References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RMT-DS] M. Handley, et al., "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000. [RMT-BB] B. Whetton, et al., "Reliable Multicast Transport Building Blocks for One-to-Many Bulk Data Transfer", RFC 3048, January 2001. [RMT-Author] R. Kermode and L. Vicisano, "Author Guidelines for RMT Building Blocks and Protocol Instantiation documents", draft-ietf- Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 13]
INTERNET-DRAFT Expires: August 2001 February 2001 rmt-author-guidelines-00.txt, June 2000. [SAP] M. Handley, et al., "Session Announcement Protocol", RFC 2974, October 2000. [TRACK] B. Whetton, et al., "Reliable Multicast Transport Building Block for TRACK", Feb. 2001. [TREE] M. Kadansky, et al.,"Reliable Multicast Transport Building Block: Tree Auto-Configuration", November 2000. [ECTS] ITU-T Recommendation X.605 and ISO/IEC 13252, "Enhanced Communication Transport Services", 1999. [ECTP] ITU-T Draft Recommendation X.ectp and ISO/IEC JTC1/SC6 CD 14476, "Enhanced Communications Transport Protocol", Work in Progress, Feb. 2001. 8. Acknowledgments We would like to give special thanks to the following individuals. Jim Long, UK Jack Houldsworth, UK Dae Young Kim, KOREA Hyun Kook Kahng, KOREA 9. Author's Addresses Seok Joo Koh sjkoh@pec.etri.re.kr Shin Gak Kang sgkang@etri.re.kr Juyoung Park jypark@ccl.cnu.ac.kr Eun Sook Kim eunsook@cs.sookmyung.ac.kr Protocol Engineering Center Electronics Telecommunications Research Institute Kajong-Dong, Yusung-Gu, Taejon, 305-350, Korea 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 Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 14]
INTERNET-DRAFT Expires: August 2001 February 2001 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." Koh, et al. draft-koh-rmt-bb-tsm-00.txt [Page 15]