idnits 2.17.1 draft-bai-ccamp-mmssms-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2, 2012) is 4278 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 145 -- Looks like a reference, but probably isn't: 'RFC2326' on line 149 -- Looks like a reference, but probably isn't: 'RFC4567' on line 149 -- Looks like a reference, but probably isn't: 'RFC5694' on line 149 == Unused Reference: '1' is defined on line 384, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 387, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 391, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 395, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2326 (ref. '1') (Obsoleted by RFC 7826) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Bai Bo 3 Internet Draft Xi'an Jiaotong University 4 Intended status: Informational Zhao Jihong 5 Expires: February 2013 Xi'an Jiaotong University 6 August 2, 2012 8 A Mechanism for Maintaining the Survivability of Streaming Media 9 Services 10 draft-bai-ccamp-mmssms-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may not be modified, 16 and derivative works of it may not be created, and it may not be 17 published except as an Internet-Draft. 19 This document may contain material from IETF Documents or IETF 20 Contributions published or made publicly available before November 21 10, 2008. The person(s) controlling the copyright in some of this 22 material may not have granted the IETF Trust the right to allow 23 modifications of such material outside the IETF Standards Process. 24 Without obtaining an adequate license from the person(s) controlling 25 the copyright in such materials, this document may not be modified 26 outside the IETF Standards Process, and derivative works of it may 27 not be created outside the IETF Standards Process, except to format 28 it for publication as an RFC or to translate it into languages other 29 than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on February 2, 2013. 48 Copyright Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Abstract 65 This document describes a mechanism for maintaining the 66 survivability of streaming media services in the circumstances of 67 the IP network (MSSMS). This service-oriented mechanism can 68 calculate the health value(HV) of each service and judged their 69 survivability in order to control the routing and the decision- 70 making of each service. 72 Table of Contents 74 1. Introduction ................................................ 3 75 1.1. Overview ............................................... 3 76 1.2. Application ............................................ 3 77 2. Conventions used in this document 78 ........................... 4 79 3. Terminology and Definition ................................. 4 80 4. Path/Traffic Info ........................................... 4 81 4.1. Statistic of Routing ................................... 4 82 4.2. Statistic of Traffic ................................... 5 83 4.3. Path/Traffic Info ...................................... 5 84 5. Normalized Evaluations 85 ...................................... 5 86 5.1. Normalized Evaluations of Bandwidth and Delay .......... 5 87 5.2. Setting Loss Rate 88 ...................................... 6 89 6. Health value ................................................ 6 90 6.1. Path's Health Value 91 ................................... 6 92 6.2. Service's Health Value 93 ................................ 6 94 7. Working Process of the Mechanism ............................ 7 95 7.1. Pseudo code of General Process ......................... 7 96 7.2. Working Process of Control Mechanism(MSSMS) ............ 7 97 8. Security Considerations 98 ..................................... 9 99 9. IANA Considerations ......................................... 9 100 10. References ................................................. 9 101 11. Acknowledgments ............................................ 9 103 1. Introduction 105 1.1. Overview 107 The main trend of future network is to become more controllable and 108 has multiple overlays which are service-oriented. With the 109 development of the high-speed broad-band internet, the need of 110 massive streaming media service(SMS) has become larger. Thus, the 111 quality of this kind of businesses is becoming more and more 112 important in current and future networks. 114 In multi-layer networks, the routing strategies and resource 115 allocation are depending on the instant quality of current SMS. But 116 most methods of current quality control of streaming media service 117 are only mainly based either on the protection of multicast 118 tree(such as reserve route) or on the cache technology. There is no 119 a comprehensive mechanism which can be used precisely despite the 120 different structures of networks. 122 As a solution, the health value(HV) is proposed to measure the 123 survivability of streaming media service. This design is to provide 124 a universal service-oriented standard for assuring the survivability 125 of streaming media service. 127 With the mechanism proposed in this document, the control center of 128 the service-oriented multi-layer network can get the calculated 129 health value of the goal service. Then the center can adjust the 130 routing strategy and the resource allocation for this service 131 through comparing the health value with the QoS requirements which 132 are preset by the administration of the network or business. By all 133 the processes before, the mechanism can judge whether the goal 134 service need to be rerouted. 136 1.2. Application 138 This mechanism can be used in the environment of IP networks with 139 sustentation of OSPF-TE/ISIS-TE. 141 2. Conventions used in this document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC-2119 [RFC2119]. 146 3. Terminology and Definition 148 The following definitions are used in this document; they follow the 149 terms in [RFC2326], [RFC4567] and [RFC5694]. 151 MSSMS: maintaining the survivability of streaming media service 153 Path/Traffic Info: this info refers to the statistical information 154 about a path's delay, bandwidth and packet loss rate. 156 Health Value(HV): this value refers to the quantized state of a path 157 or a service. It has two applications. One of them is the HV of one 158 path, the other one is the HV of one whole kind of streaming media 159 services. The specific definition of two kind of health values are 160 given in the following contents. 162 4. Path/Traffic Info 164 The control center is laid on an independent overlay which can 165 provide the function of centralized control. Basically the control 166 center is consisted of an algorithm center, a topology information 167 database and a service-categories database. Though the practical 168 constitution may be more complex than above, the fundamental 169 functions will remain the same. 171 4.1. Statistic of Routing 173 To calculate the health value of one specific service, the system 174 must know both the paths that the packets of this particular service 175 are going through and the traffic in these paths. In the OSPF 176 networks with traffic engineering, the routing information can be 177 acquired by inquiring the routing table from OSPF routers. By this 178 means, control center can get all the paths in which the 179 correspondent packets( of one specific service) are traveling trough. 180 Another way to get all those paths between source and destination is 181 to use the command of Tracert. At the meanwhile, all the paths need 182 to be saved to topology database for next process. 184 4.2. Statistic of Traffic 186 The traffic of each path is needed when it comes to calculation of 187 the path's weight. Each path's traffic can be acquired from the 188 information given by the last hop of each path. Another way to get 189 traffic's statistical data is to run the tool of Tracert at the 190 destination node of the service. 192 4.3. Path/Traffic Info 194 According to the information given above, control center can 195 calculate the weight of each path in influence on the service's 196 health condition through the expression given here. If kn is the 197 weight of the path, then kn=mn/M, in which M is the total traffic of 198 one service in the destination node, n=0,1,2,...,N-1,N. 200 5. Normalized Evaluations 202 Usually in the environment of OSPF network, the link state can be 203 sensed and saved in the link state database(LSDB) in OSPF router. 204 This LSDB can provide the most elementary assessment about the 205 link's state. However, the assessment of health value needs a more 206 detailed link state. The parameter of bandwidth, delay and loss rate 207 are indispensable when calculating the health values. 209 5.1. Normalized Evaluations of Bandwidth and Delay 211 In the environment of ISIS-TE network, the information of currently 212 available bandwidth can be offered by the ISIS-TE protocol. Thus the 213 normalized evaluation of bandwidth would be: 215 bandwidthEV=b2/B=(B-b1)/B=1-b1/B 217 In the equation above B is the total bandwidth of one path, b1 is 218 the bandwidth which has been used already by current service, b2 is 219 the currently available bandwidth. The bandwidthEV is proportional 220 to the health value of path. The bigger the bandwidthEV is, the 221 better the condition of the path is. 223 The delayEV is the normalized evaluation of delay condition of one 224 path. Its value can be calculated from this equation: 226 delayEV=1-d/Dm 228 In the equation above, delayEV is proportional to the health value 229 of path; Dm is the maximum of the delay values of all paths. The 230 bigger the delayEV is, the better the condition of the path is. 232 5.2. Setting Loss Rate 234 Loss rate is set according to the specific requirement of each 235 service. At each destination node, loss rate will be calculated. 236 Different services have different loss rate. Furthermore, the 237 weights of loss rate are different in health values of different 238 services, because the services' requirements of QoS are varied. 240 6. Health value 242 Health value is a quantitive parameter which can indicate the 243 current condition of service. It can provide a synthesized standard 244 to judge whether the present health condition of service is good 245 enough to meet the requirements of QoS. 247 6.1. Path's Health Value 249 In IP network especially in P2P network, packets of same service may 250 go through multiple paths to arrive at the destination node. Thus 251 each path's health value is relevant to the health condition of the 252 service. The equation of path's health value is give below: 254 PHVn= i*bandwidthEV+j*delayEV, (i+j=1) 256 i is the weight of path's bandwidth condition and j is the weight of 257 path's delay condition. The values of i and j depend on the specific 258 requirements of service. For example, if the service needs high 259 level of instant respond, j should be larger than i because in this 260 case high level of instant respond means very short delay. On the 261 contrary, if the service causes massive transportation, i should be 262 larger because bandwidth is more important than delay in this case. 264 6.2. Service's Health Value 266 After path's health value is acquired, service's health value can be 267 got by the equation below: 269 SHV = -ql+k1*PHV1+k2*PHV2+...+kn*PHVn, k1+k2+k3+...+kn=1, 271 l stands for loss rate at the destination node, q is the weight of l. 273 7. Working Process of the Mechanism 275 7.1. Pseudo code of General Process 277 if control center didn't receive alarm datagram: 279 judge whether current network situation is good enough for service 280 according to the topology information database and the function of 281 health value 283 if situation is good enough: output the judgment that the service is 284 healthy enough 286 else: tell routing module that the service is not healthy enough 288 else: tell routing module directly that the path is malfunctioning 290 7.2. Working Process of Control Mechanism(MSSMS) 292 The working process of MSSMS is listed as below: 294 a. 295 Gathering topology information 296 Centralized control module are respondent for monitoring the 297 environment of network. It collects the link state information and 298 stores them into topology information database, such as delay and 299 bandwidth. The database is refreshed at a fixed rate. 301 b. 302 Recognizing services 303 Category information of varies services is prestored in 304 database(service-categories database) which is set in control center. 305 Different services have different threshold of QoS, thus the 306 information about categories is different from one to another. After 307 getting topology information, the control center can classify 308 different services according to their QoS threshold. 310 c. 311 Calculating path's weights 312 The counter set in the destination node must supervise the traffic 313 into this node. M stands for the total incoming traffic. At this 314 point, control center counts each path's traffic according to the 315 topology information database. If there are N paths in total and each 316 path's traffic is mn then the weight of each path is kn=mn/M, in 317 which n=0,1,2,...,N-1,N. Because in real P2P network circumstances 318 every path's traffic is changing instantly, a refresh rate r is set 319 in the control center of this mechanism in order to make the weights 320 of those paths change instantly as the traffic changes. 322 d. 323 Calculating health values 324 After weights of all paths have been acquired, health values of these 325 paths can be calculated by the equation below: 327 bandwidthEV=b2/B=(B-b1)/B=1-b1/B 329 delayEV=1-d/Dm 331 PHVn= i*bandwidthEV+j*delayEV, (i+j=1) 333 In the equations above, B is the total bandwidth of one path, b1is 335 the bandwidth which has been occupied; b2 is the free bandwidth which 336 has been remained. Dm is the maximum of the delay values of all paths. 337 In the third equation, i is the weight of path's bandwidth condition 338 and j is the weight of path's delay condition. 340 After path's health value is acquired, service's health value can be 341 got by the equation below: 343 SHV = -ql+k1*PHV1+k2*PHV2+...+kn*PHVn, k1+k2+k3+...+kn=1 345 l stands for loss rate at the destination node, q is the weight of l. 347 e. 348 Judging the health level 349 Once service's health value has been acquired by the way described in 350 process b, the judge function in the control center will decide 351 whether the current service is healthy enough. The standard of health 352 is preset according different thresholds of service QoS parameters. 354 If current service's health value is larger than the threshold, 355 control center will consider this service as healthy enough to 356 continuing current routing strategies. Otherwise, if current 357 service's health value can't reach the threshold, control center will 358 consider it's not healthy anymore and output the judging result to 359 the routing module to adjust the routing strategies such as Fast Re- 360 Route(FRR) and so on. 362 If centralized control center has detected the warning packets from 363 the lower network, control center shall escape the process of 364 calculating health values and output the judgment of ill 365 survivability to routing model to activate FRR. 367 8. Security Considerations 369 As MSSMS can be used in IP-based networks, especially in P2P 370 networks, it might be related with the stability of the network 371 infrastructure (such as routing protocols). At the same time, the 372 quality of service will be more stable under the control of MSSMS, 373 because the MSSMS can adjust routing strategies instantly. However, 374 the premises of this mechanism are that the threshold of QoS must be 375 preset properly; otherwise there will be a jitter in system's 376 routing strategies. 378 9. IANA Considerations 380 This document does not request any action from IANA. 382 10. References 384 [1] H.Schulzrinne, "Real Time Streaming Protocol(RTSP)", RFC 2326, 385 April 1998. 387 [2] J.Arkko, F.Lindholm, M.Naslund, "Key Management Extensions for 388 Session Description Protocol(SDP) and Real Time Streaming 389 Protocol(RSTP)", RFC 4567, July 2006. 391 [3] G.Camarillo, Ed., "Peer-to-Peer(P2P) Architecture: Definition, 392 Taxonomies, Examples, and Applicability", RFC 5694, November 393 2009. 395 [4] N.Cook, "Streaming Internet Messaging Attachments", RFC 5616, 396 August 2009. 398 11. Acknowledgments 400 This context is written to provide a service-oriented mechanism for 401 maintaining the survivability of streaming media service in the 402 circumstances of the IP network. 404 Copyright (c) 2012 IETF Trust and the persons identified as authors 405 of the code. All rights reserved. 407 Redistribution and use in source and binary forms, with or without 408 modification, are permitted provided that the following conditions 409 are met: 411 o Redistributions of source code must retain the above copyright 412 notice, this list of conditions and the following disclaimer. 414 o Redistributions in binary form must reproduce the above copyright 415 notice, this list of conditions and the following disclaimer in 416 the documentation and/or other materials provided with the 417 distribution. 419 o Neither the name of Internet Society, IETF or IETF Trust, nor the 420 names of specific contributors, may be used to endorse or promote 421 products derived from this software without specific prior 422 written permission. 424 Authors' Addresses 426 Bo Bai 427 Xi'an Jiaotong University 428 Box1761 Xi'an Jiaotong University 429 No.28 Xianning West Road, People's Republic of China 430 Email: rastlin108@gmail.com 432 Jihong Zhao 433 Xi'an Jiaotong University 434 Box1761 Xi'an Jiaotong University 435 No.28 Xianning West Road, People's Republic of China 436 Email: eeleeg@gmail.com