STUDY OF QUALITY OF SERVICE IN NETWORK FOR WEB CONFERENCING
AVINASH KUMARSAURABH KISHORESHALINA VERMANAVANEET KUMAR
CERTIFICATE
This is to certify that Avinash Kumar, student of Jaipur Engineering College and Research Center, Jaipur
has successfully completed a project on
“Study of Quality of Service (QoS) in the network for Web Conferencing in Information Technology Services Department of Tata Steel”
Project Head: M.K. Pal
(Head of Department, ITS)
ACKNOWLEDGEMENT
Whenever a work is started from the grass root level, to make that piece of work a success there is involvement of many people whose encouragement works as strength to complete the new work.
Similarly I have started my project and many people played a vital role in its fulfillment. So I would like to thank all the people whose support made my project a success.
First of all I would like thank my guide, Mr. M.K. Pal of ITS Department, who gave me the opportunity to carry out this project and has been a constant source of inspiration. Without his support this project would have been an impossible task.
I am also very grateful to all the people who took time out from their hectic schedule and gave me important suggestions and information which enabled me to complete this project. A big thank you to all the people of Information Technology Services Department who have helped me, directly or indirectly in the course of this project.
Avinash Kumar
Computer Science and Engineering
JECRC, Jaipur
CONTENTS
S. No. Topic
1 Introduction to TATA STEEL
2 Overview of ITS
3 Web conferencing
4 H.323 protocol
5 Real-time transport protocol
6 Real-time transport control protocol
7 Real-time transport streaming protocol
8 Session initiation protocol
9 Jitter
10 Quality of service
11 Multi protocol label switching
12 MPLS Class of services in CISCO network
Bibliography
An Introduction to Tata Steel
Tata Steel was established by Indian entrepreneur Jamshetji Nusserwanji Tata in 1907.
Tata Steel, formerly known as TISCO and Tata Iron and Steel Company Limited, is the world's sixth largest steel company, with an annual crude steel capacity of 31 million tones. It is also Asia’s leading steel manufacturing company and is the largest private sector steel company in India in terms of domestic production. Ranked 258th on Fortune Global 500, it is based in Jamshedpur, Jharkhand, India. It is part of Tata Group of companies. Tata Steel is also India's second-largest and second-most profitable company in private sector with consolidated revenues of Rs 1,32,110 crore and net profit of over Rs 12,350 crore during the year ended March 31, 2008.
Its main plant is located in Jamshedpur, Jharkhand, with its recent acquisitions, the company has become a multinational with operations in various countries. The Jamshedpur plant contains the DCS supplied by Honeywell. The registered office of Tata Steel is in Mumbai. The company was also recognized as the world's best steel producer by World Steel Dynamics in 2005. The company is listed on Bombay Stock Exchange and National Stock Exchange of India, and employs about 92,700 people (as of 2009).
TISCO operates as India's largest integrated steel works in the private sector with a market share of nearly 17 percent and is the second largest steel company in the entire industry. Its
products and services include hot and cold rolled coils and sheets, tubes, construction bars, forging quality steel, rods, structural’s, strips and bearings, steel plant and material handling equipment, Ferro alloys and other minerals, software for process controls, and cargo handling services. Through its subsidiaries, TISCO also offers tinplate, wires, rolls, refractory’s, and project management services.
Capacity Expansion
Tata Steel has set an ambitious target to achieve a capacity of 100 million tones by 2015. The Managing Director of Tata Steel stated that of the 100 million tones, Tata Steel is planning a 50-50 balance between Greenfield facilities and acquisitions.Overseas acquisitions have already added up to 21.4 million tones, which include Corus production at 18.2 million tone, NatSteel production at 2 million tone and Millennium Steel production at 1.2 million tones. Tata is looking to add another 29 million tones through the acquisition routeTata Steel has lined up a series of Greenfield projects in India and outside which includes:
6 million tone plant in Orissa (India) 12 million tone in Jharkhand (India) 5 million tone in Chhattisgarh (India) 3-million tone plant in Iran 2.4-million tone plant in Bangladesh 5 million tone capacity expansion at Jamshedpur (India) 4.5 million tone plant in Vietnam (feasibility studies underway)
INFORMATION TECHNOLOGY SERVICES Information Technology Services (ITS) is an in-house IT service provider to all departments of Tata Steel. The department is entrusted with the responsibility of a assessing customer requirements, architecting IT Solutions, and delivering IT services to Tata Steel. ITS is also responsible for supporting the Information Management process which is one of Tata Steel’s key business processes. ITS has committed itself to create business value for its customers and aspires to take Tata Steel to new levels of excellence through e-transformation. Tata Steel has been an early adopter of IT. From the batch processing systems of the 1960s, custom-built solutions of 1990s on IBM mainframe platforms to the integrated ERP systems of the millennium, Tata Steel has shown how IT can be used to manage business. Acquisition of SAP R/3 competency, introduction of e-business, Data warehouse, Business intelligence and Advance Planning optimization solutions are some of the leading edge technologies that ITS has recently brought to Tata Steel. The reach and range of information technology have been significantly expanded, through the use of best communication practices ITS has designed a set of management processes and business processes (primary and support) as in Fig. , to enable the products and services to be targeted to the customer. members come together. The IT services are delivered through support groups, competency teams and helpdesks with appropriate service level targets. The details of these are presented
Web conferencing Web conferencing is used to conduct live meetings, training, or presentations via the internet. In a web conference, each participant sits at his or her own computer and is connected to other participants via the internet. This can be either a downloaded application on each of the attendees' computers or a web-based application where the attendees access the meeting by clicking on a link distributed by e-mail (meeting invitation) to enter the conference.
A webinar is a neologism to describe a specific type of web conference. It is typically one-way, from the speaker to the audience with limited audience interaction, such as in a webcast. A webinar can be collaborative and include polling and question & answer sessions to allow full participation between the audience and the presenter. In some cases, the presenter may speak over a standard telephone line, while pointing out information being presented onscreen, and the audience can respond over their own telephones, speaker phones allowing the greatest comfort and convenience. There are web conferencing technologies on the market that have incorporated the use of VoIP audio technology, to allow for a completely web-based communication. Depending upon the provider, webinars may provide hidden or anonymous participant functionality, making participants unaware of other participants in the same meeting.
For interactive online workshops web conferences are complemented by electronic meeting systems (EMS) which provide a range of online facilitation tools such as brainstorming and categorization, a range of voting methods or structured discussions, typically with optional anonymity. Typically, EMS do not provide core web conferencing functionality such as screen sharing or voice conferencing though some EMS can control web conferencing sessions.
In the early years of the Internet, the terms "web conferencing" was often used to describe a group discussions in a message board and therefore not live. The term has evolved to refer specifically to live or "synchronous" meetings.
How Does Web Conferencing Work?
Web conferencing is a service involving a virtual online meeting between two or more participants. These participants could either be within the same area or building or on the other side of the world, getting together on the Internet to discuss exchange and share resources. Through web conferences participants may be able to access a variety of features which include data and audio transfers, among other things.
Web conferencing enables several components for it to work in synergy. Below are tools and facilities that you may be able to make use of during a web meeting?
File sharing and application sharing of desktop
File sharing is the foremost feature of web conferencing. It is an effective tool that produces favorable results. When a participant shares his or her workstation to
everyone in the conference, the rest of the participants will able to view those files. By giving the control of the desktop to someone else, they can also access the files and take part in providing inputs even if they are in a remote location.
White Board
White boards are, to simply put, the virtual version of a boardroom white board used when there is brainstorming going on in the conference. Everyone in the virtual meeting will be able to see it. The feature comes very handy since it can be set up in such a way that everyone else can have access to add or contribute to it.
Polls and Surveys
This feature is very useful for feedback and responses. The surveys can be tabulated and archived for future reference.
Co-browsing of the internet
This feature is very useful as a tool for customer service, allowing clients to browse a corporate website, together with customer support personnel, for example. It is also a useful tool for sales presentations and product education, among other things.
SMS messaging
Apart from audio and video, web conferences may also allow for text messaging service. This is useful for documentation.
Slide presentations
This tool allows viewing visual demonstrations and presentations and may even be customized as a downloadable resource for future need or reference.
Playback
The playback feature contains the archive of meetings and may be especially useful for those who have missed joining the conference; or as reference for future discussion and brainstorming.
All of these can be combined to bring your participants together in one conference happening on real-time. Because virtual meetings take place on the Internet, security issues are not uncommon. That’s why a moderator or conference host is required when hosting conferences, to ensure that participants of the conference are given their privacy with the moderator providing their login name and passwords. The moderator or conference host can also monitor participants entering and leaving the virtual room or do roll calls every now and then.
A Simple Process
Depending on the software used, the service host and the conference moderator, a virtual meeting can successfully transpire among the participants. Below is a simple idea of how web conferencing works:
The conference host or moderator gathers all files and documents before the meeting and then distributes them to the participants later.
The conference host or moderator relays the date and time for the online meting, using invites via email.
The participants can either accept or reject the invitation. If they have accepted this, they can program their calendar to remind them of the meeting.
The conference host or moderator has to ensure that the application is working efficiently before the meeting begins.
Participants are then sent, via email, invites with the URL link and the security codes to be able to enter the virtual conference room.
When participants enter the virtual conference room, a buzz or a bell signifies their entry.
The meeting then takes place online, where participants can make use of various services like: audio, video, voice chat, messaging and desktop sharing, among others.
When the meeting is over, the participants can just log off the conference room.
Companies all over the world are now making use of web conferencing facilities because of the simplicity and efficiency of it. Moreover, a company is able to save from travel expenses and company resources because virtual meetings hosted online has eliminated the need to travel or bring employees to certain destinations. Even a small-scale business can make use of this and produce even better results that benefit its business.
Below are some video conferencing software reviews that you may refer to for choosing the one appropriate for your organization.
Windows Live MessengerMany people consider this application as the best video conferencing software. This software is most suitable if you want to chat with friends and work colleagues, or use any such online communication facility. It provides the user with superfluity personalization alternatives and numerous other communication features. You are able to communicate without any disturbances, be it video conferences, voice communication, or any other virtual method of communication. Moreover, it is absolutely free for download. There are many video conferencing software reviews that have rated this software as one of the best conferencing tools.
Yahoo! Messenger with VoiceThis software also falls under the best video conferencing software category. It has
awesome video chatting facilities and functions, instant messaging, file sharing, and voice communications. The main feature is the video conferencing ability which provides live video conference with an adjustable screen. It also provides an easy-to-use interface which contributes to convenient interface navigation. It is freely available for download on the Internet.
Sight SpeedThis is an application which has a simple interface, but high-quality video conferencing facilities. Its principal features include video mail and conference calling. It supports video conferencing for a maximum of four people. The application's interface is quite appealing and navigable. It mainly renders efficient video conferencing facilities, and has a quality screen size. There is also a function which enables you to pause the video if you want to protect your privacy.
GoToMeetingThis is a well-known web conferencing software used by many businesses around the world. It is mostly preferred by large companies to cater to their communication needs, and carry out decision-making processes or important discussions smoothly. This web conferencing tool allows you to connect to about 15 attendees per meeting.
WebEx MeetMeNowThis video conferencing tool is utilized by over 82% of the fortune 100 companies. It provides the facility of conducting unlimited video conference calls, initiating presentations and trainings, share applications, and other corporate needs. It also allows 15 members to communicate in a single web conference.
These are some of the video conferencing software which are widely used in the business world and also for informal communication. I hope the above video conferencing software reviews would have helped you in determining which is the appropriate web conferencing application for your use.
H.323 Introduction:-
H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols to provide audio-visual communication sessions on any packet network. The H.323 standard addresses call signaling and control, multimedia transport and control, and bandwidth control for point-to-point and multi-point conferences.
HISTORY:-
The first version of H.323 was published by the ITU in November 1996 with an emphasis of enabling videoconferencing capabilities over a Local area network (LAN), but was quickly adopted by the industry as a means of transmitting voice communication over a variety of IP networks, including WANs and the Internet.
Over the years, H.323 has been revised and re-published with enhancements necessary to better-enable both voice and video functionality over Packet switched network , with each version being backward-compatible with the previous version. Recognizing that H.323 was being used for communication, not only on LANs, but over WANs and within large carrier networks, the title of H.323 was changed when published in 1988.The title, which has since remained unchanged, is "Packet-Based Multimedia Communications Systems." The current version of H.323, commonly referred to as "H.323v6", was published in 2006.
PROTOCOLS:-
H.323 is a system specification that describes the use of several ITU-T and IETF protocols. The protocols that comprise the core of almost any H.323 system are:
H.225.0 Registration, Admission and Status (RAS), which is used between an H.323 endpoint and a Gatekeeper to provide address resolution and admission control services.
H.225.0 Call Signaling , which is used between any two H.323 entities in order to establish communication.
H.245 control protocol for multimedia communication, which describes the messages and procedures used for capability exchange, opening and closing logical channels for audio, video and data, control and indications.
Real-time Transport Protocol (RTP), which is used for sending or receiving multimedia information (voice, video, or text) between any two entities.
Many H.323 systems also implement other protocols that are defined in various ITU recommendations to provide supplementary services support or deliver other functionality to the user. In addition to those ITU-T Recommendations, H.323 utilizes various IETF Request for Comments (RFCs) for media transport and media packetization, including the Real-time Transport Protocol (RTP).
CODECS:-
H.323 utilizes both ITU-defined codecs and codecs defined outside the ITU. Codecs that are widely implemented by H.323 equipment include:
Audio codecs : G.711, G.729 (including G.729a), G.723.1, G.726, G.722, G.728, Speex Text codecs : T.140 Video codecs: H.261, H.263, H.264
H.323 ARCHITECTURE:-
The H.323 system defines several network elements that work together in order to deliver rich multimedia communication capabilities. Those elements are Terminals, Multipoint Control Units (MCUs), Gateways, Gatekeepers, and Border Elements. Collectively, terminals, multipoint control units and gateways are often referred to as endpoints.
H.323 Network Elements
1. Terminals
Figure 1 - A complete, sophisticated protocol stack
Terminals in an H.323 network are the most fundamental elements in any H.323 system, as those are the devices that users would normally encounter. They might exist in the form of a simple IP phone or a powerful high-definition videoconferencing system.
Inside an H.323 terminal is something referred to as a Protocol stack, which implements the functionality defined by the H.323 system. The protocol stack would include an implementation of the basic protocol defined in ITU-T Recommendation H.225.0 and H.245, as well as RTP or other protocols described above.
2. Multipoint Control Units
A Multipoint Control Unit (MCU) is responsible for managing multipoint conferences and is composed of two logical entities referred to as the Multipoint Controller (MC) and the Multipoint Processor (MP). In more practical terms, an MCU is a conference bridge not unlike the conference bridges used in the PSTN today. The most significant difference, however, is that H.323 MCUs might be capable of mixing or switching video, in addition to the normal audio mixing done by a traditional conference bridge. Some MCUs also provide multipoint data collaboration capabilities. What this means to the end user is that, by placing a video call into an H.323 MCU, the user might be able to see all of the other participants in the conference, not only hear their voices.
3. Gateways
Gateways are devices that enable communication between H.323 networks and other networks, such as PSTN or ISDN networks. If one party in a conversation is utilizing a terminal that is not an H.323 terminal, then the call must pass through a gateway in order to enable both parties to communicate.
4. Gatekeepers
A Gatekeeper is an optional component in the H.323 network that provides a number of services to terminals, gateways, and MCU devices. Those services include endpoint registration, address resolution, admission control, user authentication, and so forth. H.323 endpoints use the RAS protocol to communicate with a gatekeeper. Likewise, gatekeepers use RAS to communicate with other gatekeepers.A collection of endpoints that are registered to a single Gatekeeper in H.323 is referred to as a “zone”. This collection of devices does not necessarily have to have an associated physical topology. Rather, a zone may be entirely logical and is arbitrarily defined by the network administrator.
5. Border Elements and Peer Elements
Border Elements and Peer Elements are optional entities similar to a Gatekeeper. An administrative domain is the collection of all zones that are under the control of a single person or organization, such as a service provider. Within a service provider network there may be hundreds or thousands of gateway devices, telephones, video terminals, or other H.323 network elements. The service provider might arrange devices into "zones" that enable the service provider to best manage all of the devices under its control, such as logical arrangement by city. Taken together, all of the zones within the service provider network would appear to another service provider as an "administrative domain". The border element is a signaling entity that generally sits at the edge of the administrative domain and communicates with another administrative domain. This communication might include such things as access authorization information; call pricing information; or other important data necessary to enable communication between the two administrative domains.Peer elements are entities with the administrative domain that, more or less, help to propagate information learned from the border elements throughout the administrative domain. Such architecture is intended to enable large-scale deployments within carrier networks and to enable services such as clearinghouses.
H.323 Network Signaling
Below is an overview of the various communication flows in H.323 systems.
1. H.225.0 Call Signaling
Once the address of the remote endpoint is resolved, the endpoint will use H.225.0 Call Signaling in order to establish communication with the remote entity. H.225.0 messages are:
Setup and Setup acknowledge Call Proceeding Connect Alerting Information Release Complete Facility Progress Status and Status Inquiry Notify
2. RAS Signaling
Endpoints use the RAS protocol in order to communicate with a gatekeeper. Likewise, gatekeepers use RAS to communicate with peer gatekeepers. RAS is a fairly simple protocol composed of just a few messages
When an endpoint is powered on, it will generally send either a gatekeeper request (GRQ) message to "discover" gatekeepers that are willing to provide service or will send a registration request (RRQ) to a gatekeeper that is predefined in the system’s administrative setup. Gatekeepers will then respond with a gatekeeper confirm (GCF). If a GRQ has been sent the endpoint will then select a gatekeeper with which to register by sending a registration request (RRQ), to which the gatekeeper responds with a registration confirm (RCF). At this point, the endpoint is known to the network and can make and place calls.
When an endpoint wishes to place a call, it will send an admission request (ARQ) to the gatekeeper. The gatekeeper will then resolve the address (either locally, by consulting another gatekeeper, or by querying some other network service) and return the address of the remote endpoint in the admission confirm message (ACF). The endpoint can then place the call.Upon receiving a call, a remote endpoint will also send an ARQ and receive an ACF in order to get permission to accept the incoming call. This is necessary, for example, to authenticate the calling device or to ensure that there is available bandwidth for the call.
3. H.245 Call Control
Once a call has initiated (but not necessarily fully connected) endpoints may initiate H.245 call control signaling in order to provide more extensive control over the conference. H.245 is a rather voluminous specification with many procedures that fully enable multipoint communication, though in practice most implementations only implement the minimum necessary in order to enable point-to-point voice and video communication.H.245 provides capabilities such as capability negotiation, master/slave determination, opening and closing of "logical channels" (i.e., audio and video flows), flow control, and conference control. It has
support for both unicast and multicast communication, allowing the size of a conference to theoretically grow without bound.
Real Time Transport Protocol (RTP)
RTP provides the basic functionality for transferring real-time data over packet networks. Since RTP does not include mechanisms for reliable delivery or flow control, transport of RTP packets must rely on underlying protocols such as UDP and TCP. RTP typically runs over UDP, though TCP is sometimes used for reliable transport or to stream across firewalls that discard UDP packets. RTP provides source identification (randomly chosen SSRC identifier), payload type identification (to signal the appropriate decoding and playback information to the client), sequence numbering (for ordering packets and detecting losses), and time stamping (to control the playback time and measure jitter). Data packets contain a generic RTP header with these fields, as well as payload-specific information to improve the quality of delivery for specific media (e.g., MPEG). Interpretation of some header fields, such as the timestamp, is payload dependent. The RTP header may also identify contributing sources (CSRCs) for the payload carried in the packet; such a list is typically inserted by mixers or translators.
RTP uses UDP and defines format of additional information required by the application(Sequence number, time stamps). It uses a special set of messages (RTCP) to exchange periodic reports.In one RTP session there is one media flow.Mixer is an intermediate system that combines RTP streams from different sources into a single stream. It can change the data format of the RTP packets.
RTP provides standard packet format for real-time application. It Specifies header fields below:-Payload Type: 7 bits, providing 128 possible different types of encoding; e.g. PCM, MPEG2 video, etc. Different media are not multiplexedSequence Number: 16 bits; random number incremented by. One for each RTP data packet sent; used to detect packet lossTimestamp: 32 bytes; gives the sampling instant of the first audio/video byte in the packet; used to remove jitter introduced by the network
clock frequency depends on applications random initial value several packets may have equal timestamps (e.g. same video frame), or even in
disorder (e.g. interpolated frames in MPEG)Synchronization Source identifier (SSRC): 32 bits; an id for the source of a stream; assigned randomly by the source.Miscellaneous fields: Contributing Source identifier (CSRC)
RTP Control Protocol (RTCP)The RTP Control Protocol (RTCP) is a sister protocol of the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in the RTP specification RFC 3550, superseding its original standardization in 1996 (RFC 1889).
RTCP provides out-of-band statistics and control information for an RTP flow.
It partners RTP in the delivery and packaging of multimedia data, but does not transport any media streams itself. Typically RTP will be sent on an even-numbered UDP port, with RTCP messages being sent over the next highest odd-numbered port. The primary function of RTCP
is to provide feedback on the quality of service (QoS) in media distribution by periodically sending statistics information to participants in a streaming multimedia session.
RTCP gathers statistics for a media connection and information such as transmitted octet and packet counts, lost packet counts, jitter, and round-trip delay time. An application may use this information to control quality of service parameters, perhaps by limiting flow, or using a different codec.
Protocol functions
RTCP provides three basic functions expected to be implemented in all RTP sessions:
The primary function of RTCP is to gather statistics on quality aspects of the media distribution during a session and transmit this data to the session media source and other session participants..
RTCP provides canonical end-point identifiers (CNAME) to all session participants. Although a source identifier (SSRC) of an RTP stream is expected to be unique, the instantaneous binding of source identifiers to end-points may change during a session. The CNAME establishes unique identification of end-points across an application instance (multiple use of media tools) and for third-party monitoring.
RTCP reports are expected to be sent by all participants, even in a multicast session which may involve thousands of recipients. Such traffic will increase proportionally with the number of participants. Thus, to avoid network congestion, the protocol must include session bandwidth management. This is achieved by dynamically controlling the frequency of report transmissions. RTCP bandwidth usage should generally not exceed 5% of total session bandwidth. Furthermore, 25% of the RTCP bandwidth should be reserved to media sources at all times, so that in large conferences new participants can receive the CNAME identifiers of the senders without excessive delay.
Message types
RTCP distinguishes several types of packets: sender report, receiver report, source description, and bye. In addition, the protocol is extensible and allows application-specific RTCP packets. A standards-based extension of RTCP is the Extended Report packet type introduced by RFC 3611.
Sender report (SR) The sender report is sent periodically by the active senders in a conference to report transmission and reception statistics for all RTP packets sent during the interval. The sender report includes an absolute timestamp, which is the number of seconds elapsed since midnight on January 1, 1900. The absolute timestamp allows the receiver to synchronize RTP messages. It is particularly important when both audio and video are transmitted simultaneously, because audio and video streams use independent relative timestamps.
Receiver report (RR) The receiver report is for passive participants, those that do not send RTP packets. The report informs the sender and other receivers about the quality of service.
Source description (SDES) The Source Description message is used to send the CNAME item to session participants. It may also be used to provide additional information such as the name, e-mail address, telephone number, and address of the owner or controller of the source.
End of participation (BYE) A source sends a BYE message to shut down a stream. It allows an end-point to announce that it is leaving the conference. Although other sources can detect the absence of a source, this message is a direct announcement. It is also useful to a media mixer.
Application-specific message (APP) The application-specific message provides a mechanism to design application-specific extensions to the RTCP protocol.
Real Time Streaming ProtocolThe Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used to establish and control media sessions between end points. Clients of media servers issue VCR-like commands, such as play and pause, to facilitate real-time control of playback of media files from the server.
The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery; however some vendors implement proprietary transport protocols. The RTSP server from Real Networks, for example, also features Real Networks' proprietary RDT stream transport.
RTSP was developed by the Multiparty Multimedia Session Control Working Group (MMUSIC WG) of the Internet Engineering Task Force (IETF) and published as RFC 2326 in 1998.
Protocol directives
The RTSP protocol has similarities to HTTP, but RTSP adds new requests. While HTTP is stateless, RTSP is a stateful protocol. A session identifier is used to keep track of sessions when needed; thus, no permanent TCP connection is required. RTSP messages are sent from client to server, although some exceptions exist where the server will send to the client.
OPTIONS An OPTIONS request returns the request types the server will accept.
DESCRIBE A DESCRIBE request includes an RTSP URL, and the type of reply data that can be handled. The default port for the RTSP protocol is 554 for both UDP and TCP transports. This reply includes the presentation description, typically in Session description protocol (SDP) format.
SETUP A SETUP request specifies how a single media stream must be transported. This must be done before a PLAY request is sent. The request contains the media stream URL and a transport specifier. This specifies typically includes a local port for receiving
RTP data (audio or video), and another for RTCP data (Meta information). The server reply usually confirms the chosen parameters, and fills in the missing parts, such as the server's chosen ports. Each media stream must be configured using SETUP before an aggregate play request may be sent.
PLAY A PLAY request will cause one or all media streams to be played. Play requests can be stacked by sending multiple PLAY requests. The URL may be the aggregate URL (to play all media streams), or a single media stream URL (to play only that stream). A range can be specified. If no range is specified, the stream is played from the beginning and plays to the end, or, if the stream is paused, it is resumed at the point it was paused.
PAUSE A PAUSE request temporarily halts one or all media streams, so it can later be resumed with a PLAY request. The request contains an aggregate or media stream URL. When to pause can be specified with a range parameter. The range parameter can be left out to pause immediately.
RECORD The RECORD request can be used to send a stream to the server for storage.
TEARDOWN A TEARDOWN request is used to terminate the session. It stops all media streams and frees all session related data on the server.
SESSION INITIATION PROTOCOL
SIP FUNCTIONALITY• Establish , control and terminate sessions(conferences)
• Invite participants to multicast conferences
• Supports five facets of establishing and terminating conference namely: user location , user capability , session setup , session management
• Provide a suite of security services, which include denial-of-service prevention, authentication , integrity protection, and encryption and privacy services.
SIP REQUEST METHODS
CANCEL Cancels any pending request.
OPTIONS Queries the capabilities of servers.
REGISTER Registers the address listed in the To header field with a SIP server.
PRACK Provisional acknowledgement.
SUBSCRIBE Subscribes for an Event of Notification from the Notifier.
NOTIFY Notify the subscriber of a new Event.
PUBLISH publishes an event to the Server.
INFO Sends mid-session information that does not modify the session state.
REFER Asks recipient to issue SIP request (call transfer.)
MESSAGE Transports instant messages using SIP.
OVERVIEW OF SIP OPERATIONS• SIP is based on an HTTP-like request/response transaction model
• Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response
• A proxy server receives SIP requests and forwards them on behalf of the requestor
SIP RESPONSE CODES1XX Informational Responses
2XX Successful Responses
3XX Redirection Responses
4XX Client Failure Responses
5XX Server Failure Responses
6XX Global Failure Responses
SIP NETWORK ELEMENTS• User agent- logical network endpoint to create or receive sip messages
• User Agent Client(UAC)-to receive sip messages
• User Agent Client(UAC)- receives request and generate response
• SIP phone is a SIP user agent that provides the traditional call functions of a telephone, implemented by dedicated hardware controlled by the phone application directly or through an embedded operating system (hardware SIP phone) or as a soft phone.
Jitter ControlFor applications such as audio and video streaming, it does not matter much if the packets take 20 msec or 30 msec to be delivered, as long as the transit time is constant. The variation (i.e., standard deviation) in the packet arrival time is called jitter.
99 percent of the packets be delivered with a delay in the range of 24.5 msec to 25.5 msec might be acceptable.
The range chosen must be feasible, of course. It must take into account the speed-of-light transit time and the minimum delay through the routers and perhaps leave a little slack for some inevitable delays.
The jitter can be bounded by computing the expected transit time for each hop along the path. When a packet arrives at a router, the router checks to see how much the packet is behind or ahead of its schedule. This information is stored in the packet and updated at each hop. If the packet is ahead of schedule, it is held just long enough to get it back on schedule. If it is behind schedule, the router tries to get it out the door quickly.
In fact, the algorithm for determining which of several packets competing for an output line should go next can always choose the packet furthest behind in its schedule. In this way, packets that are ahead of schedule get slowed down and packets that are behind schedule get speeded up, in both cases reducing the amount of jitter.
In some applications, such as video on demand, jitter can be eliminated by buffering at the receiver and then fetching data for display from the buffer instead of from the network in real time. However, for other applications, especially those that require real-time interaction between people such as Internet telephony and videoconferencing, the delay inherent in buffering is not acceptable.
Quality OF ServiceRequirements
A stream of packets from a source to a destination is called a flow. In a connection-oriented network, all the packets belonging to a flow follow the same route; in a connectionless network, they may follow different routes. The needs of each flow can be characterized by four primary parameters: reliability, delay, jitter, and bandwidth. Together these determine the QoS (Quality of Service) the flow requires.
Application Reliability Delay Jitter Bandwidth
E mail Low Low Low low
File transfer Low low Low Medium
Web access Low Medium Low Medium
Remote login Low medium medium Low
Audio on demand High Low High Medium
Video on demand High Low High High
Telephony High High High Low
Video confrencing High high high High
The first four applications have stringent requirements on reliability. No bits may be delivered incorrectly. This goal is usually achieved by check summing each packet and verifying the checksum at the destination. If a packet is damaged in transit, it is not acknowledged and will be retransmitted eventually. This strategy gives high reliability. The four final (audio/video) applications can tolerate errors, so no checksums are computed or verified.
File transfer applications, including e-mail and video, are not delay sensitive. If all packets are delayed uniformly by a few seconds, no harm is done.
Interactive applications, such as Web surfing and remote login, are more delay sensitive.
Real-time applications, such as telephony and videoconferencing have strict delay requirements. If all the words in a telephone call are each delayed by exactly 2.000 seconds, the users will find the connection unacceptable.
On the other hand, playing audio or video files from a server does not require low delay.
The first three applications are not sensitive to the packets arriving with irregular time intervals between them.
Remote login is somewhat sensitive to that, since characters on the screen will appear in little bursts if the connection suffers much jitter.
Video and especially audio are extremely sensitive to jitter. If a user is watching a video over the network and the frames are all delayed by exactly 2.000 seconds, no harm is done. But if the transmission time varies randomly between 1 and 2 seconds, the result will be terrible.
For audio, a jitter of even a few milliseconds is clearly audible.
Finally, the applications differ in their bandwidth needs, with e-mail and remote login not needing much, but video in all forms needing a great deal.
Techniques for Achieving Good Quality of Service Over provisioning
An easy solution is to provide so much router capacity, buffer space, and bandwidth that the packets just fly through easily. The trouble with this solution is that it is expensive. As time goes on and designers have a better idea of how much is enough, this technique may even become practical. To some extent, the telephone system is over provisioned. It is rare to pick up a telephone and not get a dial tone instantly. There is simply so much capacity available there that demand can always be met.
Buffering
Flows can be buffered on the receiving side before being delivered. Buffering them does not affect the reliability or bandwidth, and increases the delay, but it smooth out the jitter. For audio and video on demand, jitter is the main problem, so this technique helps a lot.
Traffic Shaping
In the above example, the source outputs the packets with a uniform spacing between them, but in other cases, they may be emitted irregularly, which may cause congestion to occur in the network. Nonuniform output is common if the server is handling many streams at once, and it also allows other actions, such as fast forward and rewind, user authentication, and so on. Also, the approach we used here (buffering) is not always possible, for example, with videoconferencing. However, if something could be done to make the server (and hosts in general) transmit at a uniform rate, quality of service would be better. We will now examine a technique, traffic shaping, which smooths out the traffic on the server side, rather than on the client side.
Traffic shaping is about regulating the average rate (and burstiness) of data transmission. In contrast, the sliding window protocols we studied earlier limit the amount of data in transit at once, not the rate at which it is sent. When a connection is set up, the user and the subnet (i.e., the customer and the carrier) agree on a certain traffic pattern (i.e., shape) for that circuit. Sometimes this is called a service level agreement. As long as the customer fulfills her part of the bargain and only sends packets according to the agreed-on contract, the carrier promises to deliver them all in a timely fashion. Traffic shaping reduces congestion and thus helps the carrier live up to its promise. Such agreements are not so important for file transfers but are of great importance for real-time data, such as audio and video connections, which have stringent quality-of-service requirements.
Resource Reservation
Being able to regulate the shape of the offered traffic is a good start to guaranteeing the quality of service. However, effectively using this information implicitly means requiring all the packets of a flow to follow the same route. Spraying them over routers at random makes it hard to guarantee anything. As a consequence, something similar to a virtual circuit has to be set up from the source to the destination, and all the packets that belong to the flow must follow this route.
Once we have a specific route for a flow, it becomes possible to reserve resources along that route to make sure the needed capacity is available. Three different kinds of
resources can potentially be reserved: Bandwidth.
Buffer space.
CPU cycles
The first one, bandwidth, is the most obvious. If a flow requires 1 Mbps and the outgoing line has a capacity of 2 Mbps, trying to direct three flows through that line is not going to work. Thus, reserving bandwidth means not oversubscribing any output line.
A second resource that is often in short supply is buffer space. When a packet arrives, it is usually deposited on the network interface card by the hardware itself. The router software then has to copy it to a buffer in RAM and queue that buffer for transmission on the chosen outgoing line. If no buffer is available, the packet has to be discarded since there is no place to put it. For a good quality of service, some buffers can be reserved for a specific flow so that flow does not have to compete for buffers with other flows. There will always be a buffer available when the flow needs one, up to some maximum.
Finally, CPU cycles are also a scarce resource. It takes router CPU time to process a packet, so a router can process only a certain number of packets per second. Making sure that the CPU is not overloaded is needed to ensure timely processing of each packet.
Admission Control
Now we are at the point where the incoming traffic from some flow is well shaped and can potentially follow a single route in which capacity can be reserved in advance on the routers along the path. When such a flow is offered to a router, it has to decide, based on its capacity and how many commitments it has already made for other flows, whether to admit or reject the flow.
The decision to accept or reject a flow is not a simple matter of comparing the (bandwidth, buffers, cycles) requested by the flow with the router's excess capacity in those three dimensions. It is a little more complicated than that. To start with, although some applications may know about their bandwidth requirements, few know about buffers or CPU cycles, so at the minimum, a different way is needed to describe flows. Next, some applications are far more tolerant of an occasional missed deadline than others. Finally,
some applications may be willing to haggle about the flow parameters and others may not. For example, a movie viewer that normally runs at 30 frames/sec may be willing to drop back to 25 frames/sec if there is not enough free bandwidth to support 30 frames/sec. Similarly, the number of pixels per frame, audio bandwidth, and other properties may be adjustable.
Proportional Routing
Most routing algorithms try to find the best path for each destination and send all traffic to that destination over the best path. A different approach that has been proposed to provide a higher quality of service is to split the traffic for each destination over multiple paths. Since routers generally do not have a complete overview of network-wide traffic, the only feasible way to split traffic over multiple routes is to use locally-available information. A simple method is to divide the traffic equally or in proportion to the capacity of the outgoing links. However, more sophisticated algorithms are also available (Nelakuditi and Zhang, 2002).
Packet Scheduling
If a router is handling multiple flows, there is a danger that one flow will hog too much of its capacity and starve all the other flows. Processing packets in the order of their arrival means that an aggressive sender can capture most of the capacity of the routers its packets traverse, reducing the quality of service for others. To thwart such attempts, various packet scheduling algorithms have been devised (Bhatti and Crowcroft, 2000).
One of the first ones was the fair queueing algorithm (Nagle, 1987). The essence of the algorithm is that routers have separate queues for each output line, one for each flow. When a line becomes idle, the router scans the queues round robin, taking the first packet on the next queue. In this way, with n hosts competing for a given output line, each host gets to send one out of every n packets. Sending more packets will not improve this fraction.
Integrated Services
Between 1995 and 1997, IETF put a lot of effort into devising an architecture for streaming multimedia. This work resulted in over two dozen RFCs, starting with RFCs 2205–2210. The generic name for this work is flow-based algorithms or integrated services. It was aimed at both unicast and multicast applications. An example of the former is a single user streaming a video clip from a news site. An example of the latter is a collection of digital television stations broadcasting their programs as streams of IP packets to many receivers at various locations. Below we will concentrate on multicast, since unicast is a special case of multicast.
Label Switching and MPLS While IETF was working out integrated services and differentiated services, several router vendors were working on better forwarding methods. This work focused on adding a label in front of each packet and doing the routing based on the label rather than on the destination address. Making the label an index into an internal table makes finding the correct output line becomes just a matter of table lookup. Using this technique, routing can be done very quickly and any necessary resources can be reserved along the path.
Of course, labeling flows this way comes perilously close to virtual circuits. X.25, ATM, frame relay, and all other networks with a virtual-circuit subnet also put a label (i.e., virtual-circuit identifier) in each packet, look it up in a table, and route based on the table entry. Despite the fact that many people in the Internet community have an intense dislike for connection-oriented networking, the idea seems to keep coming back, this time to provide fast routing and quality of service. However, there are essential differences between the way the Internet handles route construction and the way connection-oriented networks do it, so the technique is certainly not traditional circuit switching.
This ''new'' switching idea goes by various (proprietary) names, including label switching and tag switching. Eventually, IETF began to standardize the idea under the name MPLS (MultiProtocol Label Switching). We will call it MPLS below. It is described in RFC 3031 and many other RFCs.
As an aside, some people make a distinction between routing and switching. Routing is the process of looking up a destination address in a table to find where to send it. In contrast, switching uses a label taken from the packet as an index into a forwarding table. These definitions are far from universal, however.
The first problem is where to put the label. Since IP packets were not designed for virtual circuits, there is no field available for virtual-circuit numbers within the IP header. For this reason, a new MPLS header had to be added in front of the IP header. On a router-to-router line using PPP as the framing protocol, the frame format, including the PPP, MPLS, IP, and TCP headers
The generic MPLS header has four fields, the most important of which is the Label field, which holds the index. The QoS field indicates the class of service. The S field relates to stacking multiple labels in hierarchical networks (discussed below). If it hits 0, the packet is discarded. This feature prevents infinite looping in the case of routing instability.
Because the MPLS headers are not part of the network layer packet or the data link layer frame, MPLS is to a large extent independent of both layers. Among other things, this property means it is possible to build MPLS switches that can forward both IP packets and
ATM cells, depending on what shows up. This feature is where the ''multiprotocol'' in the name MPLS came from.
When an MPLS-enhanced packet (or cell) arrives at an MPLS-capable router, the label is used as an index into a table to determine the outgoing line to use and also the new label to use. This label swapping is used in all virtual-circuit subnets because labels have only local significance and two different routers can feed unrelated packets with the same label into another router for transmission on the same outgoing line
One major difference between MPLS and conventional VC designs is how the forwarding table is constructed. In traditional virtual-circuit networks, when a user wants to establish a connection, a setup packet is launched into the network to create the path and make the forwarding table entries. MPLS does not work that way because there is no setup phase for each connection (because that would break too much existing Internet software).
Instead, there are two ways for the forwarding table entries to be created. In the data-driven approach, when a packet arrives, the first router it hits contacts the router downstream where the packet has to go and asks it to generate a label for the flow. This method is applied recursively. Effectively, this is on-demand virtual-circuit creation.
MPLS Class of Service
Feature Overview
The Class of Service (CoS) feature for Multiprotocol Label Switching (MPLS) enables network administrators to provide differentiated types of service across an MPLS network. Differentiated service satisfies a range of requirements by supplying for each packet transmitted the particular kind of service specified for that packet by its CoS. Service can be specified in different ways, for example, using the IP precedence bit settings in IP packets.
In supplying differentiated service, MPLS CoS offers packet classification, congestion avoidance, and congestion management lists these functions and their descriptions.
Service CoS Function Description
Packet classification
Committed access rate (CAR). Packets are classified at the edge of the network before labels are assigned.
CAR uses the type of service (TOS) bits in the IP header to classify packets according to input and output transmission rates. CAR is often configured on interfaces at the edge of a network in order to control traffic into or out of the network. You can use CAR classification commands to classify or reclassify a packet.
Congestion avoidance
Weighted random early detection (WRED). Packet classes are differentiated based on drop probability.
WRED monitors network traffic, trying to anticipate and prevent congestion at common network and internetwork bottlenecks. WRED can selectively discard lower priority traffic when an interface begins to get congested. It can also provide differentiated performance characteristics for different classes of service.
Congestion management
Weighted fair queuing (WFQ). Packet classes are differentiated based on bandwidth and bounded delay.
WFQ is an automated scheduling system that provides fair bandwidth allocation to all network traffic. WFQ uses weights (priorities) to determine how much bandwidth each class of traffic is allocated.
MPLS CoS
Several different methods exist for supporting CoS across an MPLS backbone, the choice depending on whether the core has label switch routers (LSRs) or ATM LSRs. In each case, however, the CoS building blocks are the same: CAR, WRED, and WFQ.
Three configurations are described below:
• LSRs used at the core of the network backbone
• ATM LSRs used at the core of the network backbone
• ATM switches without the MPLS feature enabled
LSRs
LSRs at the core of the MPLS backbone are usually either Cisco 7200 and Cisco 7500 series routers running MPLS software. Packets are processed as follows:
1 IP packets enter into the edge of the MPLS network.
2 The edge LSRs invoke CAR to classify the IP packets and possibly set IP precedence. Alternatively, IP packets can be received with their IP precedence already set.
3 For each packet, the router performs a lookup on the IP address to determine the next-hop LSR.
4 The appropriate label is placed on the packet with the IP precedence bits copied into every label entry in the MPLS header.
5 The labeled packet is then forwarded to the appropriate output interface for processing.
6 The packets are differentiated by class. This is done according to drop probability (WRED) or according to bandwidth and delay (WFQ). In either case, LSRs enforce the defined differentiation by continuing to employ WRED or WFQ on each hop.
ATM LSRs
ATM LSRs at the core implement the multiple label virtual circuit model (LVC). In the multiple LVC model, one label is assigned for each service class for each destination. The operation of the edge LSR is the same as that described previously for the LSR case, except that the output is an ATM interface. WRED is used to define service classes and determine discard policy during congestion.
In the multiple LVC model, however, class-based WFQ is used to define the amount of bandwidth available to each service class. Packets are scheduled by class during congestion. The ATM LSRs participate in the differentiation of classes with WFQ and intelligently drop packets when congestion occurs. The mechanism for this discard activity is weighted early packet discard (WEPD).
ATM Switches
When the core network uses ATM switches and the edge of the network uses MPLS-enabled edge LSRs, the edge LSRs are interconnected through a mesh of ATM Forum PVCs (CBR, VBR, or UBR) over the ATM core switches. The edge LSRs invoke WFQ on a per-VC basis to provide differentiation based on the delay of each MPLS CoS multiplexed onto the ATM Forum PVC. Optionally, WRED can also be used on a per-VC basis to manage drop priority between classes when congestion occurs on the edge LSR.
Prerequisites
To use the MPLS CoS feature, your network must be running the following Cisco IOS features:
• CEF switching in every MPLS-enabled router
• MPLS
• ATM functionality (If you are using packet interfaces only, you do not need ATM functionality)
Benefits
MPLS CoS provides the same benefits as IP CoS when implemented on a backbone built purely of routers. The following benefits are realized when implementing IP CoS on a backbone of ATM switches using MPLS:
Efficient resource allocation—WFQ is used to allocate bandwidth on a per-class and per-link basis. Classes of traffic are guaranteed a percentage of link bandwidth, thereby maximizing the transport of paid traffic.
No connections to configure—Implementing IP CoS with MPLS requires no configuration of end-to-end VCs for each class of service. This advantage is especially beneficial when integrating MPLS CoS support in conjunction with an MPLS VPN service. Traditional methods of configuring IP CoS with ATM would require configuring and provisioning a separate end-to-end VC for each class of service for each VPN.
Flexibility without added overhead—MPLS CoS promotes the efficient use of bandwidth, because unused bandwidth allocated to a class is available to all other classes if needed. Furthermore, MPLS CoS requires no call setup procedure, because reachability and resource allocation are established before the initiation of service.
Configuring Multi-VC Mode in a MPLS-Enabled Core
To configure multi-VC mode in an MPLS-enabled core, use the following commands in the order specified in configuration mode:
Step Command Purpose
1 Router(config)# interface type number tag-switching
Configures an ATM MPLS subinterface.
2 Router(config-subif)# ip unnumbered Loopback0
Assigns IP address to the subinterface.
3 Router(config-subif)# tag-switching atm multi-vc
Enables ATM multi-VC mode on the subinterface.
4 Router(config-subif)# tag-switching ip
Enables MPLS on the ATM subinterface.
Configuration Examples
BIBLIOGRAPHY
BOOKS: --- Andrew S. Tanenbaum.
Ross and kuross.
WEBSITES: ---- Www. tatasteel.com
Www. tatasteel100.com
Www. Google.co.in
Training and Development .Naukrihub.com
And intranet site of Tata Steel.
ARTICLES: ------- Tisco News, Web conferencing, Technical Training Program Directory and journals of Tata Steel.
