Project P847-GI
What is TINA and is it Useful for the TelCos?
Deliverable 2
A TelCo Assessment of TINA
Volume 2 of 4: Annex 1 - Assessment of TINA and the Internet
Suggested readers:
Managers in Strategy, Networks and Marketing Divisions, TINA
For full publication
February 1999
EURESCOM PARTICIPANTS in Project P847-GI are:
 France Télécom
 TELECOM ITALIA S.p.a.
 Telenor AS
 Telecom Eireann
This document contains material which is the copyright of certain EURESCOM
PARTICIPANTS, and may not be reproduced or copied without permission
All PARTICIPANTS have agreed to full publication of this document
The commercial use of any information contained in this document may require a
license from the proprietor of that information.
Neither the PARTICIPANTS nor EURESCOM warrant that the information
contained in the report is capable of use, or that use of the information is free from
risk, and accept no liability for loss or damage suffered by any person using this
information.
This document has been approved by EURESCOM Board of Governors for
distribution to all EURESCOM Shareholders.
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
List of Authors
David Muldowney
Telecom Eireann/Broadcom
Carlo Liccardi
Telecom Italia / CSELT
 1999 EURESCOM Participants in Project P847-GI
page i (iv)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
Table of Contents
List of Authors ................................................................................................................ i
Table of Contents ........................................................................................................... ii
Abbreviations ................................................................................................................ iii
1
Introduction ............................................................................................................ 1
2
Internet Overview ................................................................................................... 3
3
Internet Strengths ................................................................................................... 5
3.1 Internet Growth ............................................................................................ 5
3.2 Primary Internet Protocols ........................................................................... 5
3.2.1 Internet Protocol (IP) 1981 .............................................................. 5
3.2.2 Transmission Control Protocol (TCP) 1981 ................................... 5
3.2.3 User Datagram Protocol (UDP) 1980 ............................................. 6
3.2.4 Simple Network Management Protocol (SNMP) 1990 ................... 6
3.3 Early Applications........................................................................................ 6
3.4 Access technologies ..................................................................................... 6
3.5 Powerful Internet-based Applications .......................................................... 7
3.5.1 Voice over IP ................................................................................... 7
3.5.2 Virtual Private Networks................................................................. 7
3.5.3 Traffic Shapers ................................................................................ 8
3.6 Summary of Internet Strengths .................................................................... 8
4
Internet Weaknesses ............................................................................................... 9
4.1 Performance ................................................................................................. 9
4.2 Security ...................................................................................................... 10
4.3 Service Management .................................................................................. 10
4.4 Summary of Internet Weaknesses .............................................................. 11
5
Emerging Protocols for IP Multimedia Services .................................................. 13
5.1 SIP: Session Initiation Protocol ................................................................. 13
5.2 PINT: Phone IP iNTerworking services..................................................... 15
5.3 H.323 .......................................................................................................... 17
5.4 SGCP: Simple Gateway Control Protocol ................................................. 18
5.5 IPDC: IP Device Control............................................................................ 20
5.6 MGCP: Media Gateway Control Protocol ................................................. 21
5.7 MGCP vs. IPDC and SGCP ....................................................................... 22
5.8 Real Time Transfer Protocol, RTP ............................................................ 22
5.9 Resource Reservation Protocol (RSVP) .................................................... 23
6
Opportunities for TINA ........................................................................................ 25
References .................................................................................................................... 27
page ii (iv)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
Abbreviations
ATM
Asynchronous Transfer Mode
IAB
Internet Architecture Board
CBQ
Class Based Queueing
COM
Component Object Model
DoD
US Department of Defense
FDDI
Fibre Distributed Data Interface
FTP
File Transfer Protocol
IETF
Internet Engineering Task Force
IESG
Internet Engineering Steering Group
IRTF
Internet Research Task Force
IP
Internet Protocol
IPDC
IP Device Control
IPSEC
IP Security
ISP
Internet Service Provider
ITSP
Internet Telephony Service Providers
LDAP
Lightweight Directory Access Protocol
MCU
Multipoint Control Unit
MGCP
Media Gateway Control Protocol
PINT
Phone IP iNTerworking
PSTN
Public Switched Telephony Network
POTS
Plain Old Telephony Service
PVC
Permanent Virtual Circuit
QoS
Quality of Service
RFC
Request For Comment
RSVP
Resource Reservation Protocol
RTP
Real Time Protocol
SAP
Session Announcement Protocol
SDP
Session Description Protocol
SIP
Session Initiation Protocol
SGCP
Simple Gateway Control protocol
SMTP
Simple Mail Transfer Protocol
SNMP
Simple Network Management Protocol
TCP
Transmission Control Protocol
 1999 EURESCOM Participants in Project P847-GI
page iii (iv)
Volume 2: Annex 1 - Assessment of TINA and the Internet
UDP
User Datagram Protocol
VOIP
Voice Over IP
VPN
Virtual Private Network
WFQ
Weighted Fair Queueing
WWW
World Wide Web
XTP
Express Transfer Protocol
page iv (iv)
Deliverable 2
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
1
Volume 2: Annex 1 - Assessment of TINA and the Internet
Introduction
The objective of this document is to assess the Internet in order to determine its
strengths and weakness and identify where TINA may have a role in future Internet
evolution. Advances in Internet solutions could potentially make TINA redundant so
it is important to highlight areas where the Internet is particularly powerful for
consumers and providers. Much research has been invested in TINA and it shouldn’t
be a surprise that positive results from TINA can play a role in future Internet
developments. This document will give a brief overview of the working methodology
that the Internet adheres to. This will be followed by what we consider strengths and
weakness of the Internet. Once we identify Internet shortcomings we can propose
potential areas that TINA could provide a solution.
 1999 EURESCOM Participants in Project P847-GI
page 1 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
page 2 (27)
Deliverable 2
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
2
Volume 2: Annex 1 - Assessment of TINA and the Internet
Internet Overview
The Internet Engineering Task Force (IETF) is a self-organized group of people who
make technical and other contributions to the engineering and evolution of the
Internet and its technologies. It is the principal body engaged in the development of
new Internet standard specifications. Its mission includes:

Identifying, and proposing solutions to, pressing operational and technical
problems in the Internet;

Specifying the development or usage of protocols and the near-term architecture
to solve such technical problems for the Internet;

Making recommendations to the Internet Engineering Steering Group (IESG)
regarding the standardization of protocols and protocol usage in the Internet;

Facilitating technology transfer from the Internet Research Task Force (IRTF) to
the wider Internet community;

Providing a forum for the exchange of information within the Internet community
between vendors, users, researchers, agency contractors and network managers.
Work within the IETF is divided into different areas which are also subdivided into
more specific working groups:
 Applications Area
 General Area
 Internet Area
 Operations and Management Area
 Routing Area
 Security Area
 Transport Area
 User Services Area
The specification documents of the Internet protocol suite, as defined by the IETF and
its steering group (the IESG), are published as RFCs.
Internet-Drafts are the working documents of the IETF, its areas, and its working
groups. Internet-Drafts have a maximum life of six months. After that time, they must
be updated, or they will be deleted. Topics such as Audio/Video Transport,
Benchmarking Methodology, Distributed Management, Integrated Services, IP
Performance Metrics and more have many Internet Drafts.
In general, the working groups tend to focus on fine grained problem areas that
require near-term solutions whereas TINA tends to focus on the “big” picture.
Developments in Internet technologies can be used to develop more sophisticated
applications. The advent of the World Wide Web in the early 1990s was the “killer
app” that brought the Internet to the general public. The rapid development of new
product offerings on Internet competes with the same customer base which
traditionally was exclusive to the Telecom Operators. Internet Telephony and Virtual
Private Networks products are two products area where the Internet can offer services
that compete directly with the POTS and leased line services offered by the telcos.
 1999 EURESCOM Participants in Project P847-GI
page 3 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
page 4 (27)
Deliverable 2
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
3
Internet Strengths
3.1
Internet Growth
The Internet (or ARPANET as it was known then) was designed in the late 1960s as a
US Department of Defense (DoD) project and initially consisted of 4 nodes. One of
the design goals was to design a distributed communications network that could
withstand nuclear attack during the height of the cold war. By 1982 the DoD decided
that the Transmission Control Protocol / Internet Protocol (TCP/IP) suite was the
standard to be used within the DoD. This led to one of the first definitions of an
"internet" as a connected set of networks, specifically those using TCP/IP, and
"Internet" as connected TCP/IP internets. By 1984 the number of hosts connected to
the Internet breaks 1,000 growing over 10,000 in the next 3 years. The 100,000 barrier
was broken during 1989. The World Wide Web (WWW) first appeared in 1991 and
by 1992 there were 1,000,000 hosts with Internet connectivity. WWW surpasses ftpdata in March 1995 as the service with greatest traffic based on packet count, and in
April of the same year based on byte count. By July 1998 there were 36,739,000 hosts
and 2,215,195 Web sites connected to the Internet.
3.2
Primary Internet Protocols
This section describes some of the most commonly used transport protocols that are
in use in the Internet today. The Internet Protocol (IP), Transmission Control Protocol
(TCP), and User Datagram Protocol (UDP) are the main transport protocols in use in
the Internet. Simple Network Management Protocol (SNMP) was designed to manage
network elements that are in use within in the Internet. The early success of the
Internet can largely be attributed to these protocols.
3.2.1
Internet Protocol (IP) 1981
The Internet Protocol [RFC791] is designed for use in interconnected systems of
packet-switched computer communication networks. The internet protocol provides
for transmitting blocks of data called datagrams from sources to destinations, where
sources and destinations are hosts identified by fixed length addresses. The internet
protocol also provides for fragmentation and reassembly of long datagrams, if
necessary, for transmission through packet networks. The internet protocol is
specifically limited in scope to provide the functions necessary to deliver a package of
bits (an internet datagram) from a source to a destination over an interconnected
system of networks. There are no mechanisms to augment end-to-end data reliability,
flow control, sequencing, or other services commonly found in host-to-host protocols.
The internet protocol can capitalise on the services of its supporting networks to
provide various types and qualities of service.
3.2.2
Transmission Control Protocol (TCP) 1981
The Transmission Control Protocol (TCP) [RFC793] is intended for use as a highly
reliable host-to-host protocol between hosts in packet-switched computer
communication networks, and in interconnected systems of such networks. TCP is a
connection-oriented, end-to-end reliable protocol designed to fit into a layered
hierarchy of protocols which support multi-network applications. The TCP provides
 1999 EURESCOM Participants in Project P847-GI
page 5 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
for reliable inter-process communication between pairs of processes in host
computers attached to distinct but interconnected computer communication networks.
Very few assumptions are made as to the reliability of the communication protocols
below the TCP layer. TCP assumes it can obtain a simple, potentially unreliable
datagram service from the lower level protocols. In principle, the TCP should be able
to operate above a wide spectrum of communication systems ranging from hard-wired
connections to packet-switched or circuit-switched networks.
3.2.3
User Datagram Protocol (UDP) 1980
User Datagram Protocol (UDP) is defined to make available a datagram mode of
packet-switched computer communication in the environment of an interconnected set
of computer networks. This protocol assumes that the Internet Protocol (IP) is used as
the underlying protocol. This protocol provides a procedure for application programs
to send messages to other programs with a minimum of protocol mechanism. The
protocol is transaction oriented, and delivery and duplicate protection are not
guaranteed.
3.2.4
Simple Network Management Protocol (SNMP) 1990
The Simple Network Management Protocol (SNMP) [RFC1157] is used to
communicate management information between the network management stations and
the agents in the network elements. SNMP explicitly minimises the number and
complexity of management functions realised by the management agent itself. A
second goal of the protocol is that the functional paradigm for monitoring and control
be sufficiently extensible to accommodate additional, possibly unanticipated aspects
of network operation and management. A third goal is to make the architecture, as
much as possible, independent of the architecture and mechanisms of particular hosts
or particular gateways.
3.3
Early Applications
Early applications in use consisted of Email which is based on the Simple Mail
Transfer Protocol [RFC821], Telnet [RFC854] and the File transfer Protocol (FTP)
[RFC959]. These applications were basic, but easy to use.During the 1980s the
Internet was relatively small by today’s standards, the network transmission
technology was unreliable and offered very limited bandwidth. Congestion was often
caused in the network so the protocols themselves were not required to be very
efficient.
3.4
Access technologies
Digital technology and the appearance of the World Wide Web (WWW) was the
killer application that the brought the Internet to the general public’s attention.
Phrases such as “surfing the ‘Net” have crept into the English language. In fact, the
WWW has been so successful that many of the public consider the ‘Net and the
WWW as one and the same entity. The net affect of this growth has led to an
insatiable demand for bandwidth. The WWW has led to a demand for multimedia
applications which the Internet was not originally designed for. Nevertheless the IETF
have been active in ensuring that IP can embrace new network technologies so that IP
traffic can be transported effectively without modification over networks offering
page 6 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
high bandwidth such as ATM, FDDI, and Frame Relay. Faster transmission in the
network layer will ultimately lead to congestion at the transport layers i.e. IP and
TCP. Rather than redesigning these transport protocols which are adequate for most
applications in use today, the IETF has designed new protocols such as the Real Time
Protocol (RTP) and Resource Reservation Protocol (RSVP), which support
applications which have different requirements. RTP [RFC1889] provides end-to-end
network transport functions suitable for applications transmitting real-time data, such
as audio, video or simulation data, over multicast or unicast network services. RTP
does not address resource reservation and does not guarantee quality-of- service for
real-time services. RSVP [RFC2205] is a resource reservation setup protocol designed
for an integrated services Internet. RSVP provides receiver-initiated setup of resource
reservations for multicast or unicast data flows, with good scaling and robustness
properties.
3.5
Powerful Internet-based Applications
This section briefly describes 3 applications that are available on the Internet today
which enables it as a suitable medium for corporate use. They are many product
available on the market for Voice over IP, Virtual Private Networks and Traffic
Shapers.
3.5.1
Voice over IP
According to [DC3-98], companies large and small are running IP telephony trials,
and at least 15 ITSPs (Internet telephony service providers) are now offering VOIP
(voice-over-IP) services. Major long-distance carriers and ISPs (Internet service
providers) are taking a long, hard look at the technology as well. Who stands to gain
the most? Corporations doing a lot of business overseas and smaller companies that
don't have the clout to negotiate big domestic call discounts with carriers. Who stands
to suffer? Providers of circuit-switched voice: Consultancy Phillips Tarifica Ltd.
(London) estimates AT&T will lose $620 million to $950 million in international
calls by 2001 because of IP telephony1.
3.5.2
Virtual Private Networks
VPN devices with strong authentication and encryption, hardware with custom silicon
to boost performance offering privacy on the most public of networks, thus
eliminating the need for leased lines. According to [DC9-97] in September 1997 most
VPN products handled only encryption and authentication functions. In just one year
they've come a long way as five of the six devices tested by Data Communications
International lab tests [DC8-98] were also IP routers, three serve as firewalls, and
three offer certificate authorities. Internet VPN products offer the rock solid reliability
of private lines and the security that comes with them at a fraction of the cost.
Additionally, Internet connectivity has the added advantage of making it possible for
organisations to reach new business partners and customers.
1
This has many reasons, among which the facts that VoIP providers use less expensive
infrastructure, use a simple pre-paid fee structure (no collection for bad debts, no printing and
mailing of bills,) and have a favorable regulatory status of Enhanced Service Providers in the
US which exempts them from access fees, and international settlement payments.
 1999 EURESCOM Participants in Project P847-GI
page 7 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
3.5.3
Deliverable 2
Traffic Shapers
Traffic shapers or traffic tuners can be used to keep important data moving by
applying prioritisation policies and allocating guaranteed amounts of bandwidth.
Traffic shapers make use of queuing algorithms, rate control, or both to keep the
packets moving. With queuing, traffic is assorted by priority: High-priority packets
get the nod over low-priority packets, which are then sent out less frequently. With
TCP/IP rate control, the traffic shaper signals the source to send fewer packets if the
network is becoming congested. There are basically three types of queuing: priority,
weighted, and class-based. Products using priority queuing classify traffic and set
policies for high- and low-priority data. The high-priority queues have to be emptied
of packets before lower-priority traffic is transmitted. Weighted Fair Queuing (WFQ)
traffic is not only assigned to specific priority queues; it also is apportioned a share of
bandwidth. Class-Based Queuing (CBQ) is where the queue itself is guaranteed a
certain transmission rate. If the queue doesn't use all of its bandwidth, traffic from
other classes can borrow as needed
3.6
Summary of Internet Strengths
The main strengths of the Internet can be summarised as follows:

IP is well understood and importantly well supported.

The addressing scheme is simple and easy to administer.

Basic set of transport protocols that are well understood and importantly well
supported.

Simple management of network elements.

The Internet is transparently composed of heterogeneous network technologies.

Distributed communications infrastructure which enables addition and deletion
of nodes without disruption to the rest of the Internet.

Massive user base, applications information store.

Well defined APIs which allows anybody to build distributed Internet
applications.

Flexible evolving mechanism able to solve fine grained problems.

Suitable platform for electronic commerce, even if several problems need to be
solved.
page 8 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
4
Internet Weaknesses
4.1
Performance
The Internet could be described in some ways as a victim of its own success. Massive
growth in traffic has led to congestion in the network. Since most data is sent in either
TCP or UDP packets by IP. These protocols were not originally designed to cope with
the volume of traffic today. For example, TCP was designed on the assumption that
the underlying network was unreliable and packet were frequently lost. In most cases,
packet loss in the network occurs when the network is congested. TCP uses the GoBack-N algorithm for re-transmitting lost packets, which means that when the
transmitter fails to receive an acknowledgment from the receiver for packet N within a
certain time limit, packet N and every packet after N is re-transmitted to the receiver.
This obviously leads to even greater congestion on network. Other protocols such as
eXpress Transfer Protocol (XTP) were designed to overcome the shortcomings of
TCP, however, they never gained much support in the industry.
Quality of Service (QoS) within the Internet is difficult to attain. The following
example illustrates the difficulties in offering QoS on the Internet. Take the network
level. ATM networks can support certain levels of QoS. An ATM Provider could sell
a 2 Mb/s constant bit rate Permanent Virtual Circuit (PVC) between two Internet
Service Providers (ISPs). ATM cells are transmitted at a rate of 2 Mb/s or 39,568
packets a second:
2 x 1024 x 1024
= 39,568 cells per second
48 + 5
When an IP packet2 with a 20 byte header and 10000 byte payload arrive at the
transmitter, it is segmented into ATM cells which works out as 209 ATM cells are
required to carried this IP traffic from edge to edge of the providers network. For
1000 such IP packets it takes (1000*209/39,568=) 5.28 seconds to transmit, not taking
into account time into account for the segmentation and re-assembly by ATM. From
the IP level this is perceived as a transmission rate of (1000*10020/5.28=) 1,897,727
bytes per second or 1.81 Mb/s. Therefore IP traffic which carries TCP, UDP and
ICMP packets, acknowledgments, re-transmissions and so on is transmitted at this
rate. Furthermore IP has no mechanism to guarantee this throughput over any one
link. Taking a look at the big picture, a network provider can only guarantee network
traffic in its domain as applications compete for bandwidth at the IP level.
Protocols such as RTP and RSVP can help, routers and traffic shapers can also help,
but guaranteed end-to-end IP QoS is very difficult to achieve. The IETF has
recognised this as a problem. RFC 2386 “A Framework for QoS-based Routing in the
Internet”. QoS-based routing has been recognized as a missing piece in the evolution
of QoS-based service offerings in the Internet. This RFC describes some of the QoSbased routing issues and requirements, and proposes a framework for QoS-based
routing in the Internet. RFC2382 “A Framework for Integrated Services and RSVP
over ATM” outlines the issues and framework related to providing IP Integrated
Services with RSVP over ATM.
2
Note: IP packet are normally of variable length. A fixed length is chosen for this example.
 1999 EURESCOM Participants in Project P847-GI
page 9 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
4.2
Deliverable 2
Security
Security has long been criticised as a problem that needs to be solved. Much work has
been done in recent years to address this issue of security. Security in the Internet can
be handled at different levels. Depending on security features available on the
network technology employed is not a satisfactory solution as the Internet is
composed of many different types of network technologies such as ATM, FDDI,
Frame Relay etc. Next up on the stack is the IP layer. Firewalls on the edge of a
corporate network can be used to prevent unauthorised access from unknown IP hosts.
RFC 1825 “Security Architecture for the Internet Protocol” describes how security
can implemented in the Internet. IPSec is a collection of security protocols from the
IETF that adds authentication and encryption to all IP communications over any
network technologies. Security can also be built in the application layer. This would
be required on a service by service basis and would obviously be an extra overhead in
the development process.
Despite the fact that the tools are available security can be compromised in other
ways:
Incompetence: This occurs due to ignorance of the need for security or bad
management of security tools such as poorly configuring a firewall. This would also
include users using a poor choice of password, or leaving their user name and
passwords visible near their terminals, the equivalent of writing your PIN number on
a credit card.
Social Engineering: This a much devious form of attack where unscrupulous
individuals gain in underhand ways. This could involve posing as somebody from the
IT department and obtaining a valid user ID and password from a user over the phone.
It seems ridiculous but it does happen.
Political: International laws for exporting encrypted data vary from country to
country which should be taken into consideration.
In summary, security on the Internet is a weakness if it is not applied properly.
4.3
Service Management
Falling profit margins for connectivity services and a growing number of providers in
the open market has led to providers to search for alternative means to win new
business. This can be achieved by offering value-added services, i.e. services other
than pure connectivity. On the Internet today, anybody can be a service provider from
large multinationals to Joe Bloggs in his home office. Traditionally, management
functionality was built into the service in an ad hoc manner. Every time a new service
was developed, service management functionality was developed with it. There was a
need to use re-useable components. Object oriented computing was one step in this
direction. However, there still lacks a common platform where services can be
developed and managed in a common way. Telecommunications carriers require a
framework for operations support systems that moves away from rigid, monolithic,
fixed-function, vendor-specific implementations. Microsoft’s Active Operation
Support Systems Framework [MSFT] encourages architectural adherence to the
design principles outlined in the Microsoft Distributed interNet Applications (DNA)
architecture as they are applied to operations support systems models such as the
NMF’s Telecom Operations Map, the ITU’s multilayer TMN model, and other
telecom OSS-specific process models and methodologies. Microsoft’s DNA
page 10 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
architecture is a proprietary solution not necessarily endorsed by the IETF,
nevertheless, Microsoft identified that there is a need for such a framework. The IETF
tends to focus on much finer grained problems, however, service management of
commercial services in a competitive market is a very important area that needs to
addressed.
4.4
Summary of Internet Weaknesses
Internet weakness can be categorised into 3 main areas:

Guaranteed QoS: Not possible at the moment.

Security: Can be a major problem if not applied properly.

Service Management: Little in this area right now.
 1999 EURESCOM Participants in Project P847-GI
page 11 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
page 12 (27)
Deliverable 2
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
5
Volume 2: Annex 1 - Assessment of TINA and the Internet
Emerging Protocols for IP Multimedia Services
A lot of protocols are being specified both in ITU-T and in IETF to enable access,
control and streaming of multimedia services over IP. The following table categorises
them in different areas:
Network access, registration
H.323, RAS
Call signalling
H.225/Q.931/2
Special resources control - Media Gw
controllers
MGCP, SGCP, IPDC, RSGCP, GLP, RTSP
Multimedia-multiparty session control invitation
H.323, SAP, SIP, SDP, PINT
Negotiation of capabilities, logical channels
mgmt., etc.
H.245
Quality of service
RSVP, RTP
Directory services and address translation
LDAP, finger, rwhois
audio/video/data transport
IP multicast and RTP
Table 1 – Emerging protocols for multimedia services over IP
The following sections describe some of these protocols which are of particular
interest for TINA-C. In particular we will address:
 PINT, SIP and H323 protocols that handles session control and invitation
mechanisms in multiparty services
 SGCP, IPDC and MGCP protocols that deal with control of media gateways and
in particular of Voice gateways.
 RTP and RSVP protocols which deal with lower level transport issues.
5.1
SIP: Session Initiation Protocol
The Session Initiation Protocol (SIP) is an application- layer control (signaling)
protocol for creating, modifying and terminating sessions with one or more
participants. These sessions include Internet multimedia conferences, Internet
telephone calls and multimedia distribution. Members in a session can communicate
via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions which allow
participants to agree on a set of compatible media types. It supports user mobility by
proxying and redirecting requests to the user’s current location. Users can register
their current location. SIP is not tied to any particular conference control protocol.
SIP is designed to be independent of the lower-layer transport protocol and can be
extended with additional capabilities.
Overview of SIP Functionality
SIP is an application-layer control protocol that can establish, modify and terminate
multimedia sessions or calls. These multimedia sessions include multimedia
conferences, distance learning, Internet telephony and similar applications. SIP can
invite both persons and “robots”, such as a media storage service. SIP can invite
parties to both unicast and multicast sessions; the initiator does not necessarily have
 1999 EURESCOM Participants in Project P847-GI
page 13 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
to be a member of the session to which it is inviting. Media and participants can be
added to an existing session.
SIP can be used to initiate sessions as well as invite members to sessions that have
been advertised and established by other means. Sessions can be advertised using
multicast protocols such as Session Announcement Protocol (SAP), electronic mail,
news groups, web pages or directories (LDAP), among others.
SIP transparently supports name mapping and redirection services, allowing the
implementation of ISDN and Intelligent Network telephony subscriber services. These
facilities also enable personal mobility services, which is defined as: “Personal
mobility is the ability of end users to originate and receive calls and access subscribed
telecommunication services on any terminal in any location, and the ability of the
network to identify end users as they move. Personal mobility is based on the use of a
unique personal identity (i.e., personal mobility complements terminal mobility, i.e.,
the ability to maintain communications when moving a single end system from one
subnet to another.
SIP supports five facets of establishing and terminating multimedia communications:
 User location: determination of the end system to be used for communication;
 User capabilities: determination of the media and media parameters to be used;
 User availability: determination of the willingness of the called party to engage
in communications;
 Call setup: “ringing”, establishment of call parameters at both called and calling
party;
 Call handling: including transfer and termination of calls.
SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fullymeshed interconnection instead of multicast. Internet telephony gateways that connect
PSTN parties can also use SIP to set up calls between them.
SIP is designed as part of the overall IETF multimedia data and control architecture
currently incorporating protocols such as RSVP [RFC2205] for reserving network
resources, the real-time transport protocol (RTP) [RFC1889] for transporting realtime data and providing QoS feedback, the real-time streaming protocol (RTSP) (RFC
2326) for controlling delivery of streaming media, the session announcement protocol
(SAP) for advertising multimedia sessions via multicast and the session description
protocol (SDP) (RFC 2327) for describing multimedia sessions. However, the
functionality and operation of SIP does not depend on any of these protocols.
SIP can also be used in conjunction with other call setup and signaling protocols. In
that mode, an end system uses SIP exchanges to determine the appropriate end system
address and protocol from a given address that is protocol-independent. For example,
SIP could be used to determine that the party can be reached via H.323, obtain the
H.245 gateway and user address and then use H.225 to establish the call.
In another example, SIP might be used to determine that the callee is reachable via the
public switched telephone network (PSTN) and indicate the phone number to be
called, possibly suggesting an Internet-to-PSTN gateway to be used.
SIP does not offer conference control services such as floor control or voting and does
not prescribe how a conference is to be managed, but SIP can be used to introduce
conference control protocols. SIP does not allocate multicast addresses.
page 14 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
SIP can invite users to sessions with and without resource reservation. SIP does not
reserve resources, but can convey to the invited system the information necessary to
do this.
5.2
PINT: Phone IP iNTerworking services
PINT defines a protocol for invoking certain telephone services from an IP network.
These services include placing basic calls, sending and receiving faxes, and receiving
content over the telephone. The protocol is specified as a set of enhancements and
additions to the SIP 2.0 and SDP 2.0 protocols.
The desire to invoke certain telephone call services from the Internet has been
identified by many different groups (users, public and private network operators, call
centre service providers, equipment vendors, etc.). The generic scenario is as follows
(when the invocation is successful):
1.
an IP host sends a request to a server on an IP network;
2.
the server relays the request into a telephone network;
3.
the telephone network performs the requested call service.
One example is a user sending a request to have a call placed to his/her telephone. It
may be that a customer wishes to get a call from the support department of some
business, or a user wishes to hear some remote automatic weather service via recorded
or synthesised speech. Within a local environment such a request might result in the
placement of a call between employees over the internal PBX.
The term “PINT Service” is used to denote such a complete transaction, starting with
the sending a request from an IP client and including the telephone call service.
(“PINT” is short for “Phone-IP Interworking Services”). A PINT service always
involves the placement of a call within some Telephone Network. The original
meaning of the acronym “PINT” was “PSTN-Internet Interworking”, but the term has
since been broadened to allow services which involve any type of circuit-switched
telephone system, not just the “Public” Switched Telephone System. Private PBXs,
cellular phone networks, and the ISDN can all be used to deliver PINT services. Also,
the request for services might come from within a private IP network that is
disconnected from the whole Internet, i.e. an Intranet.
There is some overlap between PINT service requests and third-party call control. The
requirements for the PINT protocol were deliberately restricted to providing the
ability to invoke a small number of fixed telephone call services. Great care has been
taken, however, to develop a protocol that fits into the emerging Internet Conference
Architecture, so that future extensions to PINT could develop along with Internet
Conferencing.
Within the Internet Conference Architecture, establishing media calls is done via a
combination of protocols. SIP is used to establish the association between the
participants within the call (this association between participants within the call is
called a “session”), and SDP is used to describe the media to be exchanged within the
session. The PINT protocol uses these two protocols, providing some extensions and
enhancements to enable SIP clients and servers to become PINT clients and servers.
The underlying model of Internet Conference sessions is unchanged. The PINT user
who wishes to invoke a service within the phone system uses SIP to invite a remote
PINT server into a session. (“The user places a SIP call”). The invitation contains an
 1999 EURESCOM Participants in Project P847-GI
page 15 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
SDP description of the media session that the user would like to take place, for
example, this might be a “sending a fax session” or a “telephone call session”, etc.
Acceptance of the invitation by the PINT server establishes a session between the
client and server, during which the requested media can be sent. In a PINT session the
media is transported over the phone system, while in a SIP session the media is
normally transported over an internet.
The particular requirements of PINT users lead to some new messages. For example,
the fact that a server accepts an invitation and a session is established is no guarantee
that the media will be successfully transported, neither in SIP nor in PINT. For
example, a PINT server may accept to send a fax to telephone B, but it may be that the
fax transmission fails after part of the fax is sent. Therefore, the PINT client needs to
be able to receive information about the status of the actual telephone call session that
was invoked as a result of the established PINT session. This requirement leads to a
new STATUS request and to some new Warning messages.
The relationship between PINT and SIP can be summarised as follows: The invitation
sequence (INVITE-OK-ACK) establishes an Internet Session between the PINT
server and client. The request contains a description of the “telephone network media
transport session” requested. The PINT server sends an OK to signal its agreement to
establish a PINT session with the client. The actual transportation of media over the
phone (a.k.a “the phone call”) might happen hours or days after the establishment of
the PINT call. Similarly, the phone call might complete long before any BYE is sent.
As long as no BYE is sent, then the PINT session exists, and the client may request
the STATUS of the session, or may even request to change a session parameter. Of
course, it may be impossible to change the session parameters (for example, the fax
may already have been totally or partially sent). The client sends a BYE to signal its
desire to end the PINT call. Once the BYE is acknowledged, there is no longer any
PINT association between the PINT client and server. A Warning: line is used within
the response to the BYE to indicate the status of the telephone-side media transport
session. Finally, at any point during the PINT session (and possibly even afterwards),
a client may send a STATUS message to the PINT server to retrieve information
about the telephone network session associated to the PINT request.
The enhancements and additions specified here are not intended to alter the behaviour
of baseline SIP or SDP in any way. The Milestone PINT services fit seamlessly into
the rest of the Internet Conference Architecture, and the PINT profile can be used to
extend the usual SIP/SDP services to the telephone world. This is a great added
benefit of using SIP/SDP as the protocol to invoke the PINT services. Apart from
integrating well into existing protocols and architectures, and the advantages of reuse,
this means that the protocol specified here can handle a rather wider class of call
services than just the Milestone services.
Some of the enhancements specified here (such as the use of multiparty MIME) make
sense in the context of a pure Internet Conference. The PINT profile has been
designed so that each enhancement is independent of any other. SIP transactions that
have nothing to do with telephone call services and telephone sessions should be able
to use these enhancements. It is possible that these will become part of future versions
of SIP and SDP.
page 16 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
5.3
Volume 2: Annex 1 - Assessment of TINA and the Internet
H.323
The H.323 standard provides a foundation for audio, video, and data communications
across IP-based networks, including the Internet. By complying with H.323,
multimedia products and applications from multiple vendors can interoperate,
allowing users to communicate without concern for compatibility. H.323 can be the
keystone for LAN-based products for consumer, business, entertainment, and
professional applications.
H.323 is an umbrella recommendation from the International Telecommunications
Union (ITU) that sets standards for multimedia communications over Local Area
Networks (LANs) that do not provide a guaranteed Quality of Service (QoS). These
networks dominate today’s corporate desktops and include packet-switched TCP/IP
and IPX over Ethernet, Fast Ethernet and Token Ring network technologies.
Therefore, the H.323 standards are important building blocks for a broad new range of
collaborative, LAN-based applications for multimedia communications. The H.323
specification was approved in 1996 by the ITU’s Study Group 15. The standard is
broad in scope and includes both stand-alone devices and embedded personal
computer technology as well as point-to-point and multipoint conferences. The
standard addresses call control, multimedia management, and bandwidth management
for point-to-point and multipoint conferences. H.323 also addresses interfaces
between LANs and other networks. H.323 is part of a larger series of communications
standards that enable videoconferencing across a range of networks. Known as
H.32X, this series includes H.320 and H.324, which address ISDN and PSTN
communications, respectively.
Why H.323 is important
The H.323 Recommendation is comprehensive, yet flexible, and includes
configurations for voice-only headsets, voice and video games, and full multimedia
videoconferencing stations, among others. H.323 applications are set to grow into the
mainstream market for several reasons.
 Codec Standards: H.323 establishes standards for compression and
decompression of audio and video data streams, ensuring that equipment from
different vendors will have some area of common support.
 Interoperability: Users want to conference without worrying about
compatibility at the receiving point. Besides ensuring that the receiver can
decompress the information, H.323 establishes methods for receiving clients to
communicate capabilities to the sender. The standard also establishes common
call setup and control protocols.
 Network Independence: H.323 is designed to run on top of common network
architectures. As network technology evolves, and as bandwidth-management
techniques improve, H.323-based solutions will be able to take advantage of
those enhanced capabilities.
 Platform and Application Independence: H.323 is not tied to any hardware or
operating system. H.323-compliant plat-forms will be available in many sizes and
shapes, including video-enabled personal computers, dedicated platforms, and
turnkey boxes.
 1999 EURESCOM Participants in Project P847-GI
page 17 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
 Multipoint Support: H.323 can support conferences of three or more endpoints
without requiring a specialized multipoint control unit. Multipoint capabilities
can be included in other components of an H.323 system.
 Bandwidth Management: Video and audio traffic is bandwidth-intensive and
could clog the corporate network. H.323 addresses this issue by providing
bandwidth management. Network managers can limit the number of
simultaneous H.323 connections within their network or the amount of bandwidth available to H.323 applications. These limits ensure that critical traffic will
not be disrupted.
 Multicast Support: H.323 supports multicast transport in multipoint
conferences. Multicast sends a single packet to a subset of destinations on the
network without replication. In contrast, unicast sends multiple point-to-point
transmissions, while broadcast sends to all destinations. In unicast or broadcast,
the network is used inefficiently as packets are replicated throughout the
network. Multicast transmission uses bandwidth more efficiently since all
stations in the multicast group read a single data stream.
 Flexibility: A H.323 conference can include end-points with different
capabilities. For example, a terminal with audio-only capabilities can participate
in a conference with terminals that have video and/or data capabilities.
Furthermore, an H.323 multimedia terminal can share the data portion of a
videoconference with a T.120 data-only terminal, while sharing voice, video, and
data with other H.323 terminals.
5.4
SGCP: Simple Gateway Control Protocol
This section describes an application programming interface (SGCI) and a
corresponding protocol (SGCP) for controlling Voice over IP (VoIP) Gateways from
external call control elements. The SGC assumes a call control architecture where the
call control “intelligence” is outside the gateways and handled by external call control
elements. The SGC assumes that these call controls, or call agents, will synchronize
themselves to send coherent commands to the gateways. The SGC does not provide
any mechanism for synchronizing these agents.
The SGCP assumes a connection model where the basic constructs are endpoints and
connections. Endpoints are sources or sinks of data and could be physical or virtual.
A physical endpoint is, for example, a trunk circuit. An example of a virtual endpoint
is an audio source in an audio-content server. Creation of physical endpoints requires
hardware installation, while creation of virtual endpoints can be done by software.
Connections may be either point to point or multipoint. A point to point connection is
an association between two endpoints with the purpose of transmitting data between
these endpoints. Once this association is established for both endpoints, data transfer
between these endpoints can take place. A multipoint connection is established by
connecting the end point to a multipoint session.
Relation with the H.323 standards
The SGCP is designed as an internal protocol within a distributed system that appears
to the outside as a single VoIP gateway. This system is composed of a call agent, that
may or may not be distributed over several computer platforms, and of a set of
gateways. In a typical configuration, this distributed gateway system will interface on
page 18 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
one side with one or several telephony switches, and on the other side with H.323
conformant systems, as indicated in the following table:
Functional
Plane
Phone switch
Terminating
Entity
H.323 conformant systems
Signaling
Plane
Signaling
exchanges
through
SS7/ISUP
Call agent
Signaling exchanges with the call agent
through H.225/RAS and H.225/Q.931.
Possible negotiation of logical channels and
transmission parameters through H.245 with
the call agent.
Internal
synchronization
through SGCP
Bearer
Data
Transport
Plane
Connection
through high
speed
trunk
groups
Telephony
gateways
Optional negotiation of logical channels and
transmission parameters through H.245
directly with the telephony gateway.
Transmission of VoIP data using RTP,
directly between the H.323 station and the
gateway.
In the SGCP model, the gateways focus on the audio signal translation function, while
the call agent handles the signaling functions. As a consequence, the call agent
implements the “signaling” layers of the H.323 standard, and presents itself as a
“Gatekeeper” to the H.323 systems. Calls are established using the “Gatekeeper
Routed” call model.
Relationships of SGCP with the IETF standards
While H.323 is the recognized standard for VoIP terminals, the IETF has also
produced standards for other types of multi-media applications. These other standards
include:

the Session Description Protocol (SDP), RFC 2327,

the Session Announcement Protocol (SAP),

the Session Initiation Protocol (SIP),

the Real Time Streaming Protocol (RTSP), RFC 2326.
The latter three standards are in fact alternative signaling standards that allow for the
transmission of a session description to an interested party. SAP is used by multicast
session managers to distribute a multicast session description to a large group of
recipients, SIP is used to invite an individual user to take part in a point-to-point or
unicast session, RTSP is used to interface a server that will provide real time data. In
all three cases, the session description is described according to SDP; when audio is
transmitted, it is transmitted through the Real-time Transport Protocol, RTP.
The distributed gateway systems and SGCP will enable telephony users to access
these sessions. The call agent will provide for signaling conversion, according to the
following table:
 1999 EURESCOM Participants in Project P847-GI
page 19 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
Functional
Plane
Phone switch
Terminating
Entity
IETF conforming systems
Signaling
Plane
Signaling
exchanges
through
SS7/ISUP
Call agent
Signaling exchanges with the call agent
through SAP, SIP or RTSP.
Negotiation of session description
parameters through SDP (telephony
gateway terminated but passed via the call
agent to and from the IETF conforming
system)
Internal
synchronization
through SGCP
Bearer Data
Transport
Plane
Connection
through high
speed trunk
groups
Telephony
gateways
Transmission of VoIP data using RTP,
directly between the remote system and the
gateway.
The SDP standard has a pivotal status in this architecture. SDP is also used to carry
session descriptions in SGCP.
5.5
IPDC: IP Device Control
The IPDC protocols are proposed as a protocol suite, components of which can be
used individually or together to perform connection control, media control, and
signaling transport for environments where the service control logic is separated from
the network access server.
The IPDC protocol suite operates between the Media Gateway Controller and the
Media Gateway. In terms of previous contributions to the experts of Questions 1314/16, the corresponding entities are the Call Control and Media Control portions of
the H.323 Gateway. The operation of IPDC in the service of H.323 is clarified in a
companion contribution entitled “IPDC Architectural Framework”.
A need has been identified for one or more protocols to control gateway devices
which sit at the boundary between the circuit-switched telephone network and the
internet and terminate circuit- switched trunks. Examples of such devices include
network access servers and voice-over-IP gateways. The need for a control protocol
separate from call signalling arises when the service control logic needed to process
calls lies partly or wholly outside the gateway devices.
Note that IPDC views the Media Gateway as an application which may control one or
more physical devices. In addition to its primary mandate, IPDC may be used to
control devices which do not meet the strict definition of Media Gateway such as
digital cross-connects and announcement servers.
IPDC builds on the base already provided by DIAMETER. DIAMETER has a number
of advantages as a starting point:
 built-in provision for control security
 facilities for starting up the control relation
page 20 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
 ready extensibility both in modular increments and at the atomic (individual
command and attribute) level.
Because DIAMETER is specifically written for the AAA (authentication,
authorization, accounting) application, IPDC uses DIAMETER ‘s syntactical
framework rather than DIAMETER itself. The IETF document looks very much like
the current DIAMETER Base document, but various changes to suit the IPDC
application environment have created a protocol which is interoperable with but not
identical with DIAMETER.
5.6
MGCP: Media Gateway Control Protocol
MGCP protocol is the result of the attempt to make SGCP and IPDC protocols to
converge in a unique protocol suite (draft 0.1 was issued on November 9 th). Therefore
it should supersede both. Draft 0.1 states: “ MGCP version 0.1 results from the fusion
of the SGCP and IPDC proposals”.
MGCP assumes a call control architecture where the call control “intelligence” is
outside the gateways and handled by external call control elements. A telephony
gateway is a network element that provides conversion between the audio signals
carried on telephone circuits and data packets carried over the Internet or over other
packet networks. Example of gateways are:
 Trunking gateways, that interface between the telephone network and a Voice
over IP network. Such gateways typically manage a large number of digital
circuits.
 Voice over ATM gateways, which operate much the same way as voice over IP
trunking gateways, except that they interface to an ATM network.
 Residential gateways, that provide a traditional analog (RJ11) interface to a
Voice over IP network. Examples of residential gate- ways include cable
modem/cable set-top boxes, xDSL devices, broadband wireless devices
 Access gateways, which provide a traditional analog (RJ11) or digital PBX
interface to a Voice over IP network. Examples of access gateways include
small-scale voice over IP gateways.
 Business gateways, that provide a traditional digital PBX interface or an
integrated “soft PBX” interface to a Voice over IP network.
 Network Access Servers, which can attach a “modem” to a telephone circuit and
provide data access to the Internet. In the future, the same gateways will combine
Voice over IP services and Network Access services.
 Circuit switches, or packet switches, which can offer a control interface to an
external call control element.
MGCP assumes a call control architecture where the call control “intelligence” is
outside the gateways and handled by external call control elements. The MGCP
assumes that these call control elements, or Call Agents, will synchronise with each
other to send coherent commands to the gateways under their control. MGCP does not
define a mechanism for synchronising Call Agents.
MGCP assumes a connection model where the basic constructs are endpoints and
connections. Endpoints are sources or sinks of data and could be physical or virtual.
Examples of physical endpoints are:
 1999 EURESCOM Participants in Project P847-GI
page 21 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
 An interface on a gateway that terminates a trunk connected to a PSTN switch
(e.g., Class 5, Class 4, etc.). A gateway that terminates trunks is called a trunk
gateway.
 An interface on a gateway that terminates an analog POTS connection to a
phone, key system, PBX, etc. A gateway that terminates residential POTS lines
(to phones) is called a residential gateway.
Connections may be either point to point or multipoint. A point to point connection is
an association between two endpoints with the purpose of transmitting data between
these endpoints. Once this association is established for both endpoints, data transfer
between these endpoints can take place. A multipoint connection is established by
connecting the endpoint to a multipoint session.
Connections can be established over several types of bearer networks:
 Transmission of audio packets using RTP and UDP over an IP network.
 Transmission of audio packets using AAL2, or another adaptation layer, over an
ATM network.
 Transmission of packets over an internal connection, for example the TDM
backplane or the interconnection bus of a gateway. This is used, in particular, for
“hairpin” connections, connections that terminate in a gateway but are
immediately rerouted over the tele- phone network.
For point-to-point connections the endpoints of a connection could be in separate
gateways or in the same gateway.
5.7
MGCP vs. IPDC and SGCP
Main characteristics of MGCP with respect to its predecessors are:
 It retains SGCP simplicity (text based protocol and transport over UDP)
 It relies on already established standards: IPSEC for security and SDP for
connection description
 It supports more functionalities:
 More types of networks are supported (SDP profile is set for ATM, NAS,
LAN and TCP/IP)
 It is extensible (this feature is mainly taken from IPDC)
 It supports management facilities such as Audit end points, Audit Connection
and Restart in progress (the latter comes from IPDC)
5.8
Real Time Transfer Protocol, RTP
The Real-time Transport Protocol (RTP) [RFC1889] provides end-to-end delivery
services for data with real-time characteristics, such as interactive audio and video.
Those services include payload type identification, sequence numbering,
timestamping and delivery monitoring. Applications typically run RTP on top of UDP
to make use of its multiplexing and checksum services; both protocols contribute parts
of the transport protocol functionality. However, RTP may be used with other suitable
page 22 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
underlying network or transport protocols. RTP supports data transfer to multiple
destinations using multicast distribution if provided by the underlying network.
Note that RTP itself does not provide any mechanism to ensure timely delivery or
provide other quality-of-service guarantees, but relies on lower-layer services to do
so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume
that the underlying network is reliable and delivers packets in sequence. The sequence
numbers included in RTP allow the receiver to reconstruct the sender's packet
sequence, but sequence numbers might also be used to determine the proper location
of a packet, for example in video decoding, without necessarily decoding packets in
sequence.
While RTP is primarily designed to satisfy the needs of multi- participant multimedia
conferences, it is not limited to that particular application. Storage of continuous data,
interactive distributed simulation, active badge, and control and measurement
applications may also find RTP applicable.
5.9
Resource Reservation Protocol (RSVP)
RSVP is a resource reservation setup protocol designed for an integrated services
Internet. The RSVP [RFC2205] protocol is used by a host to request specific QoS
from the network for particular application data streams or flows. RSVP is also used
by routers to deliver QoS requests to all nodes along the path(s) of the flows and to
establish and maintain state to provide the requested service. RSVP requests will
generally result in resources being reserved in each node along the data path.
RSVP requests resources for simplex flows, i.e., it requests resources in only one
direction. Therefore, RSVP treats a sender as logically distinct from a receiver,
although the same application process may act as both a sender and a receiver at the
same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport
protocol in the protocol stack. However, RSVP does not transport application data but
is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the
implementations of routing and management protocols, an implementation of RSVP
will typically execute in the background.
RSVP is not itself a routing protocol; RSVP is designed to operate with current and
future unicast and multicast routing protocols. An RSVP process consults the local
routing database(s) to obtain routes. In the multicast case, for example, a host sends
IGMP messages to join a multicast group and then sends RSVP messages to reserve
resources along the delivery path(s) of that group. Routing protocols determine where
packets get forwarded; RSVP is only concerned with the QoS of those packets that are
forwarded in accordance with routing.
In order to efficiently accommodate large groups, dynamic group membership, and
heterogeneous receiver requirements, RSVP makes receivers responsible for
requesting a specific QoS. A QoS request from a receiver host application is passed to
the local RSVP process. The RSVP protocol then carries the request to all the nodes
(routers and hosts) along the reverse data path(s) to the data source(s), but only as far
as the router where the receiver's data path joins the multicast distribution tree. As a
result, RSVP's reservation overhead is in general logarithmic rather than linear in the
number of receivers.
Quality of service is implemented for a particular data flow by mechanisms
collectively called "traffic control". These mechanisms include (1) a packet classifier,
 1999 EURESCOM Participants in Project P847-GI
page 23 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
(2) admission control, and (3) a "packet scheduler" or some other link-layerdependent mechanism to determine when particular packets are forwarded. The
"packet classifier" determines the QoS class (and perhaps the route) for each packet.
For each outgoing interface, the "packet scheduler" or other link-layer-dependent
mechanism achieves the promised QoS. Traffic control implements QoS service
models defined by the Integrated Services Working Group.
During reservation setup, an RSVP QoS request is passed to two local decision
modules, "admission control" and "policy control". Admission control determines
whether the node has sufficient available resources to supply the requested QoS.
Policy control determines whether the user has administrative permission to make the
reservation. If both checks succeed, parameters are set in the packet classifier and in
the link layer interface (e.g. in the packet scheduler) to obtain the desired QoS. If
either check fails, the RSVP program returns an error notification to the application
process that originated the request.
RSVP protocol mechanisms provide a general facility for creating and maintaining
distributed reservation state across a mesh of multicast or unicast delivery paths.
RSVP itself transfers and manipulates QoS and policy control parameters as opaque
data, passing them to the appropriate traffic control and policy control modules for
interpretation.
Since the membership of a large multicast group and the resulting multicast tree
topology are likely to change with time, the RSVP design assumes that state for RSVP
and traffic control state is to be built and destroyed incrementally in routers and hosts.
For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh
messages to maintain the state along the reserved path(s). In the absence of refresh
messages, the state automatically times out and is deleted.
In summary, RSVP has the following attributes:

RSVP makes resource reservations for both unicast and many-to-many multicast
applications, adapting dynamically to changing group membership as well as to
changing routes.

RSVP is simplex, i.e., it makes reservations for unidirectional data flows.

RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains
the resource reservation used for that flow.

RSVP maintains "soft" state in routers and hosts, providing graceful support for
dynamic membership changes and automatic adaptation to routing changes.

RSVP is not a routing protocol but depends upon present and future routing
protocols.

RSVP transports and maintains traffic control and policy control parameters that
are opaque to RSVP.

RSVP provides several reservation models or "styles" to fit a variety of
applications.

RSVP provides transparent operation through routers that do not support it.

RSVP supports both IPv4 and IPv6.
page 24 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
6
Volume 2: Annex 1 - Assessment of TINA and the Internet
Opportunities for TINA
In order to identify areas where TINA can provide solutions for Internet short
comings, it is necessary to assess whether TINA should be used as an alternative to
the Internet or complimentary to the Internet. In an ideal world the former could be
the case as TINA provides a global solution for telecommunications. However, we
live in the real world, and it is unlikely that any one technology or standard would
gain global acceptance and domination. The Internet is rapidly expanding faster than
any other communications infrastructure and is unlikely to be replaced anytime soon.
This is the world we live in and TINA has a lot to offer and therefore should be used
to compliment and improve the existing infrastructure. This section will identify
where TINA could be applied today independently or in conjunction with the IETF
standards process.
The TINA Network Resource Information Model (NRIM) can be successfully used
to model a network providers network. It is generally accepted that many IP carriers
will use ATM technology in their ATM backbone. The TINA NRIM is well suited for
modelling ATM networks and could be applied to this scenario. A management
system based on the NRIM is a flexible way of managing an ATM backbone by easily
being able to add and delete new network nodes to meet the continuously changing
network demands. This particularly useful for VPN service provisioning or offering
“leased line” services to customers. It is not intended for dynamic connection set-up
from a end users terminal, but for static configuration of a providers backbone. This
scenario has been effectively adopted by Sprint in the Integrated On Demand (ION)
solution.
With increased deregulation and convergence between the Internet and
Telecommunications for advanced networks there is a need for an environment which
supports online service creation which seamlessly interoperate across global
networks, can scale from hundreds to millions of subscribers, and enable network
providers, content providers and Internet developers to build new telecommunications
providers. The TINA Service Architecture is intended to achieve these ambitious
goals. The Service Architecture is an open platform for providers and developers.
TINA session concepts promote a service independent mechanism for uniform service
access and service management. The Internet uses protocols such as RADIUS to
perform authentication, however, service subscription is normally performed in an ad
hoc manner on a service by service basis. TINA ties these methods together to provide
a uniform access session which could be well suited for a Next Generation Internet.
Initiatives such as the AT&T GeoPlex and the Bridgewater WideSpan Intelligent
Network are addressing a similar problem domain and compliment TINA’s vision of
the future open services market.
One problem with the Internet is that many protocols have been developed for similar
problem domains. TINA could provide a layer of abstraction for users and providers
alike. This is depicted in Figure 1. For example, a voice over IP (VoIP) service could
be offered using TINA components which encapsulated the functionality offered by
protocols such as H.323 and SIP. This offers a generic “layer” which hides
heterogeneous underlying networks and protocols. This appears to be advantageous
from the operator’s point of view as only one breed of VoIP service needs to be
managed. From the network point of view, TINA could offer a uniform “network
API” which could be an extension of the normal BSD socket API. This offers a
possibility of providing enhanced QoS management supported by TINA. This concept
 1999 EURESCOM Participants in Project P847-GI
page 25 (27)
Volume 2: Annex 1 - Assessment of TINA and the Internet
Deliverable 2
has already been adopted by the Parlay Group which provides a common open
interface into any kind of telecommunications interface.
Figure 1: TINA abstract underlying complexity
Within the IETF, the PINT and NAVDEC groups are currently moving towards
defining interfaces and protocols using IDL. There is an opportunity for TINA to
“lend” a hand in this activity.
One area where the Internet is particularly strong is that there are many applications
on the market. However, there are few, if any, applications that benefit from TINA. It
has been shown that existing IP applications can be integrated into a TINA service
architecture framework. This could be a first step for a Retailer to extend its product
portfolio enabling management of service access, subscription and accounting.
In summary, the Internet is fast evolving, however, TINA still has a role to play in
providing a framework for the expected open service market.
page 26 (27)
 1999 EURESCOM Participants in Project P847-GI
Deliverable 2
Volume 2: Annex 1 - Assessment of TINA and the Internet
References
[D2Vol3]
“Assessment of TINA in the Real World”, P847-GI Vol3 of D2
[DC9-97]
“VPNs: Security With an Uncommon Touch,” Data Communications
International, Sept. 1997; http://www.data.com/lab_tests/vpn.html).
[DC3-98]
“Voice Over IP Services: The Sound Decision”, Data Communications
International,
March
1997;
http://www.data.com/roundups/decision.html
[DC8-98]
“VPNs: Safety First, But What About Speed?”, Data Communications
International, July 1998; http://www.data.com/lab_tests/first.html
[H.225]
ITU-T, Recommendation H.225 “Call Signaling Protocols and Media
Stream Packetisation for Packet Based Multimedia Communications
Systems.”
[H.245]
ITU-T, Recommendation H.245 “Line Transmission of Non-Telephone
Signals.”
[H.323]
ITU-T, Recommendation H.323 “Visual Telephone Systems and
Equipment for Local Area Networks which provide a non-guaranteed
Quality of Service.”
[HANDLEY1]
"SAP: Session Announcement Protocol", Handley, M., Work in
Progress.
[HANDLEY2]
"Session Initiation Protocol (SIP)", Handley, M., Schooler, E., and H.
Schulzrinne, Work in Progress.
[MSFT]
“Active Operations Support Systems And Opportunities”, Microsoft,
http://www.microsoft.com/isn/network/telecom/oss.asp
[RFC769]
RFC 768 “User Datagram Protocol, 1980
[RFC791]
RFC 791 “Internet Protocol”, 1981
[RFC793]
RFC 793 “Transmission Control Protocol”, 1981
[RFC821
[RFC821] “Simple Mail Transfer Protocol”, 1982
[RFC854]
RFC 854 “Telnet Protocol Specification”, 1983
[RFC959]
RFC 959 “File Transfer Protocol”, 1985
[RFC1157]
RFC 1157 “Simple Network Management Protocol”, 1990
[RFC1889]
RFC 1889 “Real Time Protocol”, 1996
[RFC1890]
RFC 1890 “RTP Profile for Audio and Video Conferences with
Minimal Control” 1996
[RFC2205]
RFC 2205 “Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification”, 1997
[RFC2326]
RFC 2326 “"Real Time Streaming Protocol (RTSP)” 1998
[RFC2235]
RFC 2235 “Hobbes’ Internet Timeline”, 1997
[RFC2327]
RFC 2327 “SDP: Session Description Protocol”, 1998
 1999 EURESCOM Participants in Project P847-GI
page 27 (27)