Internet DRAFT - draft-bai-ccamp-mmssms
draft-bai-ccamp-mmssms
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]