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]