CCAMP Bai Bo Internet Draft Xi'an Jiaotong University Intended status: Informational Zhao Jihong Expires: February 2013 Xi'an Jiaotong University August 2, 2012 A Mechanism for Maintaining the Survivability of Streaming Media Services draft-bai-ccamp-mmssms-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Bai, Zhao Expires February 2, 2013 [Page 1] Internet-Draft MMSSMS August 2012 This Internet-Draft will expire on February 2, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes a mechanism for maintaining the survivability of streaming media services in the circumstances of the IP network (MSSMS). This service-oriented mechanism can calculate the health value(HV) of each service and judged their survivability in order to control the routing and the decision- making of each service. Table of Contents 1. Introduction ................................................ 3 1.1. Overview ............................................... 3 1.2. Application ............................................ 3 2. Conventions used in this document ........................... 4 3. Terminology and Definition ................................. 4 4. Path/Traffic Info ........................................... 4 4.1. Statistic of Routing ................................... 4 4.2. Statistic of Traffic ................................... 5 4.3. Path/Traffic Info ...................................... 5 5. Normalized Evaluations ...................................... 5 5.1. Normalized Evaluations of Bandwidth and Delay .......... 5 5.2. Setting Loss Rate ...................................... 6 6. Health value ................................................ 6 6.1. Path's Health Value ................................... 6 6.2. Service's Health Value ................................ 6 7. Working Process of the Mechanism ............................ 7 Bai, Zhao Expires February 2, 2013 [Page 2] Internet-Draft MMSSMS August 2012 7.1. Pseudo code of General Process ......................... 7 7.2. Working Process of Control Mechanism(MSSMS) ............ 7 8. Security Considerations ..................................... 9 9. IANA Considerations ......................................... 9 10. References ................................................. 9 11. Acknowledgments ............................................ 9 1. Introduction 1.1. Overview The main trend of future network is to become more controllable and has multiple overlays which are service-oriented. With the development of the high-speed broad-band internet, the need of massive streaming media service(SMS) has become larger. Thus, the quality of this kind of businesses is becoming more and more important in current and future networks. In multi-layer networks, the routing strategies and resource allocation are depending on the instant quality of current SMS. But most methods of current quality control of streaming media service are only mainly based either on the protection of multicast tree(such as reserve route) or on the cache technology. There is no a comprehensive mechanism which can be used precisely despite the different structures of networks. As a solution, the health value(HV) is proposed to measure the survivability of streaming media service. This design is to provide a universal service-oriented standard for assuring the survivability of streaming media service. With the mechanism proposed in this document, the control center of the service-oriented multi-layer network can get the calculated health value of the goal service. Then the center can adjust the routing strategy and the resource allocation for this service through comparing the health value with the QoS requirements which are preset by the administration of the network or business. By all the processes before, the mechanism can judge whether the goal service need to be rerouted. 1.2. Application This mechanism can be used in the environment of IP networks with sustentation of OSPF-TE/ISIS-TE. Bai, Zhao Expires February 2, 2013 [Page 3] Internet-Draft MMSSMS August 2012 2. Conventions used in this document 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]. 3. Terminology and Definition The following definitions are used in this document; they follow the terms in [RFC2326], [RFC4567] and [RFC5694]. MSSMS: maintaining the survivability of streaming media service Path/Traffic Info: this info refers to the statistical information about a path's delay, bandwidth and packet loss rate. Health Value(HV): this value refers to the quantized state of a path or a service. It has two applications. One of them is the HV of one path, the other one is the HV of one whole kind of streaming media services. The specific definition of two kind of health values are given in the following contents. 4. Path/Traffic Info The control center is laid on an independent overlay which can provide the function of centralized control. Basically the control center is consisted of an algorithm center, a topology information database and a service-categories database. Though the practical constitution may be more complex than above, the fundamental functions will remain the same. 4.1. Statistic of Routing To calculate the health value of one specific service, the system must know both the paths that the packets of this particular service are going through and the traffic in these paths. In the OSPF networks with traffic engineering, the routing information can be acquired by inquiring the routing table from OSPF routers. By this means, control center can get all the paths in which the correspondent packets( of one specific service) are traveling trough. Another way to get all those paths between source and destination is to use the command of Tracert. At the meanwhile, all the paths need to be saved to topology database for next process. Bai, Zhao Expires February 2, 2013 [Page 4] Internet-Draft MMSSMS August 2012 4.2. Statistic of Traffic The traffic of each path is needed when it comes to calculation of the path's weight. Each path's traffic can be acquired from the information given by the last hop of each path. Another way to get traffic's statistical data is to run the tool of Tracert at the destination node of the service. 4.3. Path/Traffic Info According to the information given above, control center can calculate the weight of each path in influence on the service's health condition through the expression given here. If kn is the weight of the path, then kn=mn/M, in which M is the total traffic of one service in the destination node, n=0,1,2,...,N-1,N. 5. Normalized Evaluations Usually in the environment of OSPF network, the link state can be sensed and saved in the link state database(LSDB) in OSPF router. This LSDB can provide the most elementary assessment about the link's state. However, the assessment of health value needs a more detailed link state. The parameter of bandwidth, delay and loss rate are indispensable when calculating the health values. 5.1. Normalized Evaluations of Bandwidth and Delay In the environment of ISIS-TE network, the information of currently available bandwidth can be offered by the ISIS-TE protocol. Thus the normalized evaluation of bandwidth would be: bandwidthEV=b2/B=(B-b1)/B=1-b1/B In the equation above B is the total bandwidth of one path, b1 is the bandwidth which has been used already by current service, b2 is the currently available bandwidth. The bandwidthEV is proportional to the health value of path. The bigger the bandwidthEV is, the better the condition of the path is. The delayEV is the normalized evaluation of delay condition of one path. Its value can be calculated from this equation: delayEV=1-d/Dm Bai, Zhao Expires February 2, 2013 [Page 5] Internet-Draft MMSSMS August 2012 In the equation above, delayEV is proportional to the health value of path; Dm is the maximum of the delay values of all paths. The bigger the delayEV is, the better the condition of the path is. 5.2. Setting Loss Rate Loss rate is set according to the specific requirement of each service. At each destination node, loss rate will be calculated. Different services have different loss rate. Furthermore, the weights of loss rate are different in health values of different services, because the services' requirements of QoS are varied. 6. Health value Health value is a quantitive parameter which can indicate the current condition of service. It can provide a synthesized standard to judge whether the present health condition of service is good enough to meet the requirements of QoS. 6.1. Path's Health Value In IP network especially in P2P network, packets of same service may go through multiple paths to arrive at the destination node. Thus each path's health value is relevant to the health condition of the service. The equation of path's health value is give below: PHVn= i*bandwidthEV+j*delayEV, (i+j=1) i is the weight of path's bandwidth condition and j is the weight of path's delay condition. The values of i and j depend on the specific requirements of service. For example, if the service needs high level of instant respond, j should be larger than i because in this case high level of instant respond means very short delay. On the contrary, if the service causes massive transportation, i should be larger because bandwidth is more important than delay in this case. 6.2. Service's Health Value After path's health value is acquired, service's health value can be got by the equation below: SHV = -ql+k1*PHV1+k2*PHV2+...+kn*PHVn, k1+k2+k3+...+kn=1, l stands for loss rate at the destination node, q is the weight of l. Bai, Zhao Expires February 2, 2013 [Page 6] Internet-Draft MMSSMS August 2012 7. Working Process of the Mechanism 7.1. Pseudo code of General Process if control center didn't receive alarm datagram: judge whether current network situation is good enough for service according to the topology information database and the function of health value if situation is good enough: output the judgment that the service is healthy enough else: tell routing module that the service is not healthy enough else: tell routing module directly that the path is malfunctioning 7.2. Working Process of Control Mechanism(MSSMS) The working process of MSSMS is listed as below: a. Gathering topology information Centralized control module are respondent for monitoring the environment of network. It collects the link state information and stores them into topology information database, such as delay and bandwidth. The database is refreshed at a fixed rate. b. Recognizing services Category information of varies services is prestored in database(service-categories database) which is set in control center. Different services have different threshold of QoS, thus the information about categories is different from one to another. After getting topology information, the control center can classify different services according to their QoS threshold. c. Calculating path's weights The counter set in the destination node must supervise the traffic into this node. M stands for the total incoming traffic. At this point, control center counts each path's traffic according to the topology information database. If there are N paths in total and each path's traffic is mn then the weight of each path is kn=mn/M, in which n=0,1,2,...,N-1,N. Because in real P2P network circumstances every path's traffic is changing instantly, a refresh rate r is set in the control center of this mechanism in order to make the weights of those paths change instantly as the traffic changes. Bai, Zhao Expires February 2, 2013 [Page 7] Internet-Draft MMSSMS August 2012 d. Calculating health values After weights of all paths have been acquired, health values of these paths can be calculated by the equation below: bandwidthEV=b2/B=(B-b1)/B=1-b1/B delayEV=1-d/Dm PHVn= i*bandwidthEV+j*delayEV, (i+j=1) In the equations above, B is the total bandwidth of one path, b1is the bandwidth which has been occupied; b2 is the free bandwidth which has been remained. Dm is the maximum of the delay values of all paths. In the third equation, i is the weight of path's bandwidth condition and j is the weight of path's delay condition. After path's health value is acquired, service's health value can be got by the equation below: SHV = -ql+k1*PHV1+k2*PHV2+...+kn*PHVn, k1+k2+k3+...+kn=1 l stands for loss rate at the destination node, q is the weight of l. e. Judging the health level Once service's health value has been acquired by the way described in process b, the judge function in the control center will decide whether the current service is healthy enough. The standard of health is preset according different thresholds of service QoS parameters. If current service's health value is larger than the threshold, control center will consider this service as healthy enough to continuing current routing strategies. Otherwise, if current service's health value can't reach the threshold, control center will consider it's not healthy anymore and output the judging result to the routing module to adjust the routing strategies such as Fast Re- Route(FRR) and so on. If centralized control center has detected the warning packets from the lower network, control center shall escape the process of calculating health values and output the judgment of ill survivability to routing model to activate FRR. Bai, Zhao Expires February 2, 2013 [Page 8] Internet-Draft MMSSMS August 2012 8. Security Considerations As MSSMS can be used in IP-based networks, especially in P2P networks, it might be related with the stability of the network infrastructure (such as routing protocols). At the same time, the quality of service will be more stable under the control of MSSMS, because the MSSMS can adjust routing strategies instantly. However, the premises of this mechanism are that the threshold of QoS must be preset properly; otherwise there will be a jitter in system's routing strategies. 9. IANA Considerations This document does not request any action from IANA. 10. References [1] H.Schulzrinne, "Real Time Streaming Protocol(RTSP)", RFC 2326, April 1998. [2] J.Arkko, F.Lindholm, M.Naslund, "Key Management Extensions for Session Description Protocol(SDP) and Real Time Streaming Protocol(RSTP)", RFC 4567, July 2006. [3] G.Camarillo, Ed., "Peer-to-Peer(P2P) Architecture: Definition, Taxonomies, Examples, and Applicability", RFC 5694, November 2009. [4] N.Cook, "Streaming Internet Messaging Attachments", RFC 5616, August 2009. 11. Acknowledgments This context is written to provide a service-oriented mechanism for maintaining the survivability of streaming media service in the circumstances of the IP network. Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Bai, Zhao Expires February 2, 2013 [Page 9] Internet-Draft MMSSMS August 2012 o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. Bai, Zhao Expires February 2, 2013 [Page 10] Internet-Draft MMSSMS August 2012 Authors' Addresses Bo Bai Xi'an Jiaotong University Box1761 Xi'an Jiaotong University No.28 Xianning West Road, People's Republic of China Email: rastlin108@gmail.com Jihong Zhao Xi'an Jiaotong University Box1761 Xi'an Jiaotong University No.28 Xianning West Road, People's Republic of China Email: eeleeg@gmail.com Bai, Zhao Expires February 2, 2013 [Page 11]