transported over an IPv4 network, encapsulating the entire v6 packet
inside a v4 packet is an effective means to accomplish this task. In
this type of tunnel, the IPv6 packet is not read by any of the
routers while inside the IPv4 envelope. If the inner packet is RSVP
enabled, there must be an active configuration to ensure that all
relevant backbone nodes read the RSVP fields; [RFC2746] describes
this.
This is similar to how IPsec tunnels work. Encapsulating an RSVP
packet inside an encrypted packet for security purposes without
copying or conveying the RSVP indicators in the outside IP packet
header would make RSVP inoperable while in this form of a tunnel.
[RFC2207] describes how to modify an IPsec packet header to allow for
RSVP awareness by nodes that need to provide QoS for the flow or
flows inside a tunnel.
Other networks may simply choose to aggregate the reservations across
themselves as described in [RFC3175]. The problem with an individual
reservation architecture is that each flow requires a non-trivial
amount of message exchange, computation, and memory resources in each
router between each endpoint. Aggregation of flows reduces the
number of completely individual reservations into groups of
individual flows that can act as one for part or all of the journey
between end systems. Aggregates are not intended to be from the
first router to the last router within a flow, but to cover common
paths of a large number of individual flows.
Examples of aggregated data flows include streams of IP data that
traverse common ingress and egress points in a network and also
include tunnels of various kinds. MPLS LSPs, IPsec Security
Associations between VPN edge routers, IP/IP tunnels, and Generic
Routing Encapsulation (GRE) tunnels all fall into this general
category. The distinguishing factor is that the system injecting an
aggregate into the aggregated network sums the PATH and RESV
statistical information on the un-aggregated side and produces a
reservation for the tunnel on the aggregated side. If the bandwidth
for the tunnel cannot be expanded, RSVP leaves the existing
reservation in place and returns an error to the aggregator, which
can then apply a policy such as IEPS to determine which session to
refuse. In the data plane, the DSCP for the traffic must be copied
from the inner to the outer header, to preserve the PHB’s effect.
One concern with this approach is that this leaks information into
the aggregated zone concerning the number of active calls or the
bandwidth they consume. In fact, it does not, as the data itself is
identifiable by aggregator address, deaggregator address, and DSCP.
As such, even if it is not advertised, such information is
measurable.
2.3.4. Interaction with the Differentiated Services Architecture
In the PATH message, the DCLASS object described in [RFC2996] is used
to carry the determined DSCP for the precedence level of that call in
the stream. This is reflected back in the RESV message. The DSCP
will be determined from the authorized SIP message exchange between
end systems by using the R-P header. The DCLASS object permits both
bandwidth admission within a class and the building up of the various
rates or token buckets.
2.3.5. Admission Policy
RSVP’s basic admission policy, as defined, is to grant any user
bandwidth if there is bandwidth available within the current
configuration. In other words, if a new request arrives and the
difference between the configured upper bound and the currently
reserved bandwidth is sufficiently large, RSVP grants use of that
bandwidth. This basic policy may be augmented in various ways, such
as using a local or remote policy engine to apply AAA procedures and
further qualify the reservation.
2.3.5.1. Admission for Variable Rate Codecs
For certain applications, such as broadcast video using MPEG-1 or
voice without activity detection and using a constant bit rate codec
such as G.711, this basic policy is adequate apart from AAA. For
variable rate codecs, such as MPEG-4 or a voice codec with Voice
Activity Detection, however, this may be deemed too conservative. In
such cases, two basic types of statistical policy have been studied
and reported on in the literature: simple over-provisioning, and
approximation to ambient load.
Simple over-provisioning sets the bandwidth admission limit higher
than the desired load, on the assumption that a session that admits a
certain bandwidth will in fact use a fraction of the bandwidth. For
example, if MPEG-4 data streams are known to use data rates between
80 and 800 KBPS and there is no obvious reason that sessions would
synchronize (such as having commercial breaks on 15 minute
boundaries), one could imagine estimating that the average session
consumes 400 KBPS and treating an admission of 800 KBPS as actually
consuming half the amount.
One can also approximate to average load, which is perhaps a more
reliable procedure. In this case, one maintains a variable that
measures actual traffic through the admitted data’s queue,
approximating it using an exponentially weighted moving average.
When a new reservation request arrives, if the requested rate is less
than the difference between the configured upper bound and the
current value of the moving average, the reservation is accepted, and
the moving average is immediately increased by the amount of the
reservation to ensure that the bandwidth is not promised out to
several users simultaneously. In time, the moving average will decay
from this guard position to an estimate of true load, which may offer
a chance to another session to be reserved that would otherwise have
been refused.
Statistical reservation schemes such as these are overwhelmingly
dependent on the correctness of their configuration and its
appropriateness for the codecs in use. However, they offer the
opportunity to take advantage of statistical multiplexing gains that
might otherwise be missed.
2.3.5.2. Interaction with Complex Admission Policies, AAA, and
Preemption of Bandwidth
Policy is carried and applied as described in [RFC2753]. Figure 4,
below, is the basic conceptual model for policy decisions and
enforcement in an Integrated Services model. This model was created
to provide the ability to monitor and control reservation flows based
on user identify, specific traffic and security requirements, and
conditions that might change for various reasons, including a
reaction to a disaster or emergency event involving the network or
its users.
Network Node Policy server
______________
| ______ |
| | | | _____
| | PEP | | | |------------->
| |______|<---|---->| PDP |May use LDAP,SNMP,COPS...for accessing
| ^ | | | policy database, authentication, etc.
| | | |_____|------------->
| __v___ |
| | | | PDP = Policy Decision Point
| | LPDP | | PEP = Policy Enforcement Point
| |______| | LPDP = Local Policy Decision Point
|______________|
Figure 4: Conceptual Model for Policy Control of Routers
The Network Node represents a router in the network. The Policy
Server represents the point of admission and policy control by the
network operator. Policy Enforcement Point (PEP) (the router) is
where the policy action is carried out. Policy decisions can be
either locally present in the form of a Local Policy Decision Point
(LPDP), or in a separate server on the network called the Policy
Decision Point. The easier the instruction set of rules, the more
likely this set can reside in the LPDP for speed of access reasons.
The more complex the rule set, the more likely this is active on a
remote server. The PDP will use other protocols (LDAP, SNMP, etc.)
to request information (e.g., user authentication and authorization
for precedence level usage) to be used in creating the rule sets of
network components. This remote PDP should also be considered where
non-reactive policies are distributed out to the LPDPs.
Taking the above model as a framework, [RFC2750] extends RSVP’s
concept of a simple reservation to include policy controls, including
the concepts of Preemption [RFC3181] and Identity [RFC3182],
specifically speaking to the usage of policies that preempt calls
under the control of either a local or remote policy manager. The
policy manager assigns a precedence level to the admitted data flow.
If it admits a data flow that exceeds the available capacity of a
system, the expectation is that the RSVP-affected RSVP process will
tear down a session among the lowest precedence sessions it has
admitted. The RESV Error resulting from that will go to the receiver
of the data flow and be reported to the application (SIP or H.323).
That application is responsible for disconnecting its call, with a
reason code of "bandwidth preemption".
2.4. Authentication and Authorization of Calls Placed
It will be necessary, of course, to ensure that any policy is applied
to an authenticated user; the capabilities assigned to an
authenticated user may be considered authorized for use in the
network. For bandwidth admission, this will require the utilization
of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures will also
be needed.
2.5. Defined User Interface
The user interface -- the chimes and tones heard by the user --
should ideally remain the same as in the PSTN for those indications
that are still applicable to an IP network. There should be some new
effort generated to update the list of announcements sent to the user
that don’t necessarily apply. All indications to the user, of
course, depend on positive signals, not unreliable measures based on
changing measurements.
3. Security Considerations
This document outlines a networking capability composed entirely of
existing specifications. It has significant security issues, in the
sense that a failure of the various authentication or authorization
procedures can cause a fundamental breakdown in communications.
However, the issues are internal to the various component protocols
and are covered by their various security procedures.
4. Acknowledgements
This document was developed with the knowledge and input of many
people, far too numerous to be mentioned by name. However, key
contributors of thoughts include Francois Le Faucheur, Haluk
Keskiner, Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan,
and Tony De Simone. Pete Babendreier, Ken Carlberg, and Mike Pierce
provided useful reviews.
5. References
5.1. Normative References
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements
for Emergency Telecommunication Service (ETS)", RFC
3689, February 2004.
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony
Requirements for Emergency Telecommunication
Service (ETS)", RFC 3690, February 2004.
Integrated Services Architecture References
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an
Overview", RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2207] Berger, L. and T. O’Malley, "RSVP Extensions for
IPSEC Data Flows", RFC 2207, September 1997.
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S.,
O’Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
"Resource ReSerVation Protocol (RSVP) Version 1
Applicability Statement Some Guidelines on
Deployment", RFC 2208, September 1997.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January
2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
Framework for Policy-based Admission Control", RFC
2753, January 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F.,
Zhang, L., Speer, M., Braden, R., Davie, B.,
Wroclawski, J., and E. Felstaine, "A Framework for
Integrated Services Operation over Diffserv
Networks", RFC 2998, November 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
Moore, T., Herzog, S., and R. Hess, "Identity
Representation for RSVP", RFC 3182, October 2001.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session
Initiation Protocol (SIP)", RFC 3312, October 2002.
Differentiated Services Architecture References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E.,
Wang, Z., and W. Weiss, "An Architecture for
Differentiated Services", RFC 2475, December 1998.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
and D. Stiliadis, "An Expedited Forwarding PHB
(Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J.,
Chiu, A., Courtney, W., Davari, S., Firoiu, V.,
Kalmanek, C., and K. Ramakrishnan, "Supplemental
Information for the New Definition of the EF PHB
(Expedited Forwarding Per-Hop Behavior)", RFC 3247,
March 2002.
Session Initiation Protocol and Related References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session
Description Protocol", RFC 2327, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley,
M., and E. Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[RFC4411] Polk, J., "Extending the Session Initiation
Protocol (SIP) Reason Header for Preemption
Events", RFC 4411, February 2006.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications
Resource Priority for the Session Initiation
Protocol (SIP)", RFC 4412, February 2006.
5.2. Informative References
[ANSI.MLPP.Spec] American National Standards Institute,
"Telecommunications - Integrated Services Digital
Network (ISDN) - Multi-Level Precedence and
Preemption (MLPP) Service Capability", ANSI
T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Supp] American National Standards Institute, "MLPP
Service Domain Cause Value Changes", ANSI ANSI
T1.619a-1994 (R1999), 1990.
[G711.1] Viola Networks, "Netally VoIP Evaluator", January
2003, <http://www.brainworks.de/Site/hersteller/
viola_networks/Dokumente/Compr_Report_Sample.pdf>.
[G711.3] Nortel Networks, "Packet Loss and Packet Loss
Concealment", 2000, <http://www.nortelnetworks.com/
products/01/succession/es/collateral/
tb_pktloss.pdf>.
[ITU.ETS.E106] International Telecommunications Union,
"International Emergency Preference Scheme for
disaster relief operations (IEPS)", ITU-T
Recommendation E.106, October 2003.
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel
Precedence and Preemption Service (MLPP)", ITU-T
Recommendation I.255.3, 1990.
[Parekh1] Parekh, A. and R. Gallager, "A Generalized
Processor Sharing Approach to Flow Control in
Integrated Services Networks: The Multiple Node
Case", INFOCOM 1993: 521-530, 1993.
[Parekh2] Parekh, A. and R. Gallager, "A Generalized
Processor Sharing Approach to Flow Control in
Integrated Services Networks: The Single Node
Case", INFOCOM 1992: 915-924, 1992.
Appendix A. 2-Call Preemption Example Using RSVP
This appendix will present a more complete view of the interaction
among SIP, SDP, and RSVP. The bulk of the material is referenced
from [RFC2327], [RFC3312], [RFC4411], and [RFC4412]. There will be
some discussion on basic RSVP operations regarding reservation paths;
this will be mostly from [RFC2205].
SIP signaling occurs at the Application Layer, riding on a UDP/IP or
TCP/IP (including TLS/TCP/IP) transport that is bound by routing
protocols such as BGP and OSPF to determine the route the packets
traverse through a network between source and destination devices.
RSVP is riding on top of IP as well, which means RSVP is at the mercy
of the IP routing protocols to determine a path through the network
between endpoints. RSVP is not a routing protocol. In this
appendix, there will be an escalation of building blocks getting to
how the many layers are involved in SIP. QoS Preconditions require
successful RSVP signaling between endpoints prior to SIP successfully
acknowledging the setup of the session (for voice, video, or both).
Then we will present what occurs when a network overload occurs
(congestion), causing a SIP session to be preempted.
Three diagrams in this appendix show multiple views of the same
example of connectivity for discussion throughout this appendix. The
first diagram (Figure 5) is of many routers between many endpoints
(SIP user agents, or UAs). There are 4 UAs of interest; those are
for users Alice, Bob, Carol, and Dave. When a user (the human) of a
UA gets involved and must do something to a UA to progress a SIP
process, this will be explicitly mentioned to avoid confusion;
otherwise, when Alice is referred to, it means Alice’s UA (her
phone).
RSVP reserves bandwidth in one direction only (the direction of the
RESV message), as has been discussed, IP forwarding of packets are
dictated by the routing protocol for that portion of the
infrastructure from the point of view of where the packet is to go
next.
The RESV message traverses the routers in the reverse path taken by
the PATH message. The PATH message establishes a record of the route
taken through a network portion to the destination endpoint, but it
does not reserve resources (bandwidth). The RESV message back to the
original requester of the RSVP flow requests for the bandwidth
resources. This means the endpoint that initiates the RESV message
controls the parameters of the reservation. This document specifies
in the body text that the SIP initiator (the UAC) establishes the
parameters of the session in an INVITE message, and that the INVITE
recipient (the UAS) must follow the parameters established in that
INVITE message. One exception to this is which codec to use if the
UAC offered more than one to the UAS. This exception will be shown
when the INVITE message is discussed in detail later in the appendix.
If there was only one codec in the SDP of the INVITE message, the
parameters of the reservation will follow what the UAC requested
(specifically to include the Resource-Priority header namespace and
priority value).
Here is the first figure with the 4 UAs and a meshed routed
infrastructure between each. For simplicity of this explanation,