RSVP - WINSLab
Download
Report
Transcript RSVP - WINSLab
RSVP
Myungchul Kim
[email protected]
From Ch 12 of book “IPng and the TCP/IP protocols” by
Stephen A. Thomas, 1996, John Wiley & Sons.
• Resource Reservation Protocol (RSVP)
• RSVP operation
– Flows
• RSVP identifies a flows by its destination IP
address and a source IP address.
• RSVP does not understand the flowspec.
• RSVP supports both unicast and multicast
flows.
– Reservation
• receiver-initiated reservations.
• easily support a dynamic environment: join,
drop out.
• how does a receiver know to make a
reservation in the first place?
– Path messages
• make sure that resources are reserved along
the correct path.
• generated by a flow’s sender.
• travel in the same direction as the flow itself.
• at each hop, the router inserts its own IP
address as the message’s last hop.
– Merging reservation requests
– Reservation styles
• shared explicit reservation: an application
must explicitly identify every participating
sender.
• wildcard filter: an application shares a
resource without identifying every sender.
– RSVP and dynamic networks
• a soft state because both its paths and its
reservations are always considered tentative.
– RSVP message formats
• in the payload of IP datagrams
• type: Table 12.2
• fragmentation: message ID, fragment offset
and more fragments bits.
• RSVP and INTSERV
– RSVP: a signaling protocol, configure traffic
handling mechanisms in network devices.
– Integrated Services: a framework for providing
end-to-end services in the context of RSVP
– Integrated Services over Specific Link Layers
(issll) : define the underlying traffic handling
mechanisms that would offer QoS support on
different media.
– problems of RSVP and INTSERV
• RSVP were available only on certain UNIX.
• implemented on every network devices ->
not scalable
• no policy mechanisms in a secure manner.
• not on the non-multimedia mission-critical
applications.
– valuable components because
• RSVP in Windows 2000
• scalability <- disassociating RSVP from perflow traffic handling
• policy component
• non-multimedia applications
VoIP (SIP, H.323)
Myungchul Kim
[email protected]
By H.Schulzrinne, August 12, 20001
By H.Schulzrinne, August 12, 20001
• The Session Initiation Protocol: InternetCentric Signaling
– Henning Schulzrinne and Jonathan Rosenberg, The Session
Initiation Protocols, IEEE Comm., pp. 134-141, Oct. 2000.
– SIP
• Signaling protocol: RFC 2543 (March 1999)
• Initiates, modifies, and terminates network sessions
• Services such as VoIP including instant messaging,
event notification, distributed games
• Does not reserve resources or establish circuits in the
network
• RTP, RTSP(streaming), Media Gateway Control
Protocol, Megaco (H.248), Session Description
Protocol, Session Announcement Protocol, Telephony
Routing over IP (TRIP)
• Anything addressable by a host name can participate
in a SIP session
• Discovery of a user: personal mobility
• Could be though of as an application-layer anycast
• Ability to have users and administrators program
services
• www.cs.columbia.edu/sip
– Architecture: user agent, registrars, proxy, and
redirect servers.
– Signaling
• URI
• Figure (next slide)
• The path of the signaling messages may be
completely different from that of the media
exchanged between caller and callee.
• UDP
– SDP: a description format (what media streams
it wants to receive and its receive capabilities)
– SIP message format: textual encoding
• 838 –1240 bytes of SIP messages to set up a call
(800 bytes for H.323)
– Forking
• A server can send out two or more requests to
different destination
• Call forwarding to voice mail, automatic call
distribution, and user location
– Reliability
• UDP
• Clients retransmit INVITE requests until a provisional
response arrives, and servers retransmit responses
until confirmed by an ACK request.
– Security
• SIP inherits the basic and digest authentication
mechanisms from HTTP
– Expressing Caller Preferences
• Users register their terminal characteristics with the
local proxy
• Page 138, middle of the right column
– Quality of Service
• Using SIP to directly set
up resource
reservations is not
appropriate
• SIP can be used to
negotiate the use of
QoS mechanisms
• COMET
– Mobility
• Precall terminal mobility
• Mid-call mobility
– SIP and MGCP/MEGACO
• VoIP over IP Signaling: H.323 and Beyond
– Hong Liu and Petros Mouchtaris, Voice over IP Signaling, pp.
142-148, Oct. 2000.
– Introduction
• Precommercial (1980-1995), PC-centric (19951998), and carrier grade (1998 on)
• Previous limitation
– A gateway handles signaling conversion, call
control, and media transcoding
– No provision for SS& connectivity
– Call control: media gateway controller
– Media transformation: media gateway
– Media Gateway Control Protocol (MGCP)
– H.248 or Megaco, in June 2000
– H.323 Overview
Architecture
– Terminal
– Gatekeeper: address translation, access control,
bandwidth management, and locating GW
– Gateway
– Multipoint control unit: multipoint conference
• Signaling and control
– Registration Admission and Status (RAS)
– Q.931
– H.245: for connection control to negotiate media
processing control and used to exchange terminal
capability
– RTP
– H.323 Interworking with the PSTN
• H.323 TE to phone; phone to H.323 TE; and phone to
phone via intermediate H.323 networks
• GW
– PSTN interface
– VoIP interface
– Signaling conversion
– Media transformation
– Connection management
• Limitations of H.323
– Scalability: a few thousand
– ISDN trunks instead of SS7 connectivity
– Availability: no mechanism for failover
– User friendliness: two-stage dialing
• Separating the signaling and media transformation
functions would allow for more scalable GWs.
• Functional decomposition of H.323 GW
• Improvement of H.323
– Scalability
– SS7 connectivity
– Availability
– One-stage dialing
– H.323 and SIP
• SIP is much more light weight
• Call agents or soft switches that support H.323, SIP
and MGCP.