Information
RSVP aggregation [RFC3175] and NULL service type [RFC2997] can
provide such a feature.
5.4.3. State MUST Be Addressed Independent of Flow Identification
RSVP states are tied to the flows, thus this requirement is not
met.
5.4.4. Modification of Already Established State SHOULD Be
Seamless
Modifications of a reservation is possible with RSVP.
5.4.5. Grouping of Signaling for Several Micro-Flows MAY Be
Provided
Aggregated RSVP and RFC2961 allow this.
5.5. Performance
5.5.1. Scalability
RSVP scales linearly to the number of reservation states.
5.5.2. NSIS SHOULD Allow for Low Latency in Setup
Setting up an RSVP reservation takes one round-trip time and the
processing times are each RSVP router.
5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the
Signaling Protocol
The initial reservations messages can not be compressed, but the
refresh interval can be adjusted to consume less bandwidth, at
the expense of possible inefficient resource usage.
5.5.4. NSIS SHOULD Allow To Constrain Load on Devices
See discussions on RSVP performance (section 4).
5.5.5. NSIS SHOULD Target the Highest Possible Network
Utilization
This depends on the IntServ service types, Controlled Load can
provide better overall utilization than Guaranteed Service.
5.6. Flexibility
5.6.1. Flow Aggregation
Aggregated RSVP and RFC2961 allow this.
5.6.2. Flexibility in the Placement of the NSIS
Initiator/Responder
RSVP allows receiver as initiator of reservations.
5.6.3. Flexibility in the Initiation of State Change
RSVP receivers can initiate the state change during its
refreshment.
5.6.4. SHOULD Support Network-Initiated State Change
As RSVP supports hop-by-hop refreshment, this is made possible.
5.6.5. Uni / Bi-Directional State Setup
RSVP is only uni-directional.
5.7. Security
5.7.1. Authentication of Signaling Requests
Authentication is available in RSVP.
5.7.2. Request Authorization
Authorization with a PDP is possible in RSVP.
5.7.3. Integrity Protection
The INTEGRITY Object is available in RSVP.
5.7.4. Replay Protection
The INTEGRITY Object to replay protect the content of the
signaling messages between two RSVP nodes.
5.7.5. Hop-By-Hop Security
The RSVP security model works only hop-by-hop.
5.7.6. Identity Confidentiality and Network Topology Hiding
The INTEGRITY Object can be used for this purpose.
5.7.7. Denial-Of-Service Attacks
Challenging with RSVP.
5.7.8. Confidentiality of Signaling Messages
Not supported by RSVP.
5.7.9. Ownership of State
Challenging with RSVP.
5.8. Mobility
5.8.1. Allow Efficient Service Re-Establishment After Handover
Works for upstream but may not be achieved for the downstream
if mobility is not noticed at the cross-over router.
5.9. Interworking with Other Protocols and Techniques
5.9.1. MUST Interwork with IP Tunneling
RFC 2746 discusses these issues.
5.9.2. MUST NOT Constrain either to IPv4 or IPv6
RSVP supports both IP versions.
5.9.3. MUST Be Independent from Charging Model
RSVP does not discuss this.
5.9.4. SHOULD Provide Hooks for AAA Protocols
COPS and RSVP work together.
5.9.5. SHOULD Work with Seamless Handoff Protocols
Not supported by RSVP. Still, [RFC2205] suggests that route
changes should be indicated to the local RSVP daemon, which can
then initiate state refresh.
5.9.6. MUST Work with Traditional Routing
RSVP expects traditional routing.
5.10. Operational
5.10.1. Ability to Assign Transport Quality to Signaling Messages
This is a network design issue, but is possible with DiffServ.
5.10.2. Graceful Fail Over
RSVP supports this.
5.10.3. Graceful Handling of NSIS Entity Problems
RSVP itself does not supports this.
13. Normative References
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
14. Informative References
[3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service
(QoS) Concept and Architecture, Release 5, December
2002.
[BEBH96] Braden, R., Estrin, D., Berson, S., Herzog, and D.
Zappala, "The Design of the RSVP Protocol", ISI Final
Technical Report, July 1996.
[BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP
Proxy", Work in Progress, March 2002.
[BFM+96] A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma,
and H. Zhang, "The Tenet Real-Time Protocol Suite:
Design, Implementation, and Experiences", IEEE/ACM
Transactions on Networking, Volume 4, Issue 1,
February 1996, pp. 1-10.
[BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-
Based Aggregation Protocol for Inter-domain
Reservations", Journal of Communications and Networks,
Vol. 2, No. 2, June 2000, pp. 157-167.
[Bless02] R. Bless, "Dynamic Aggregation of Reservations for
Internet Services", Proceedings of the Tenth
International Conference on Telecommunication Systems
- Modeling and Analysis (ICTSM 10), Vol. 1, pp. 26-38,
October 3-6 2002, Monterey, California, available at
http://www.tm.uka.de/doc/2003/ictsm-daris-journal-
crc-web.pdf.
[Bless04] R. Bless, "Towards Scalable Management of QoS-based
End-to- End Services" (PDF), Proceedings of NOMS 2004
(IEEE/IFIP 2004 Network Operations and Management
Symposium), April 2004, Seoul, Korea.
[FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", Work in
Progress, January 2004.
[FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J.
Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple
Protocol for Resource Reservation in IP Networks",
IEEE RTAS, 1999.
[FNS02] G. Feher, K. Nemeth, and I. Cselenyi, "Performance
evaluation framework for IP resource reservation
signalling". Performance Evaluation 48 (2002), pp.
131-156.
[FJ02] P. Fransson and A. Jonsson, "The need for an
alternative to IPv4-options", in RVK (RadioVetenskap
och Kommunikation), Stockholm, Sweden, pp. 162-166,
June 2002.
[Fu02] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on
RSVP Regarding Multicast". Technical Report No. IFI-
TB-2002-001, ISSN 1611-1044, Institute for
Informatics, University of Goettingen, Oct 2002.
[H.245] ITU-T Recommendation H.245, Control Protocol for
Multimedia Communication, July 2000.
[H.323] ITU-T Recommendation H.323, Packet-based Multimedia
Communications Systems, Nov. 2000.
[JR03] Jukka Manner, Kimmo Raatikainen, "Localized QoS
Management for Multimedia Applications in Wireless
Access Networks". IASTED International Conference on
Internet and Multimedia Systems and Applications (IMSA
2003), August, 2003, pp. 193-200.
[Kars01] M. Karsten, "Experimental Extensions to RSVP -- Remote
Client and One-Pass Signalling". IWQoS 2001,
Karlsruhe, Germany, June 2001.
[KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz,
"Implementation and Evaluation of the KOM RSVP
Engine", IEEE Infocom 2001.
[LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A.
Campbell,"INSIGNIA: An IP-Based Quality of Service
Framework for Mobile Ad Hoc Networks". Journal of
Parallel and Distributed Computing (Academic Press),
Special issue on Wireless and Mobile Computing and
Communications, Vol. 60, Number 4, April, 2000, pp.
374-406.
[MA01] B. Moon, and H. Aghvami, "RSVP Extensions for Real-
Time Services in Wireless Mobile Networks". IEEE
Communications Magazine, December 2001, pp. 52-59.
[MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An
Architectural Comparison of ST-II and RSVP", Infocom
1994.
[MHS02] Y Miao, W. Hwang, and C. Shieh, "A transparent
deployment method of RSVP-aware applications on UNIX".
Computer Networks, 40 (2002), pp. 45-56.
[MSK+04] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
Raatikainen, "Localized RSVP", Work in Progress,
September 2004.
[OVERLAY] G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter,
"GMPLS UNI: RSVP Support for the Overlay Model", Work
in Progress, February 2004.
[PS97] P. Pan and H. Schulzrinne, "Staged refresh timers for
RSVP", Global Internet, Phoenix, Arizona, November
1997.
[PS98] P. Pan, and H. Schulzrinne, "YESSIR: A Simple
Reservation Mechanism for the Internet". Proceedings
of NOSSDAV, Cambridge, UK, July 1998.
[PS00] P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel
extension for IP option packet processing", Technical
Memorandum 10009669-02TM, Bell Labs, Lucent
Technologies, Murray Hill, NJ, June 2000.
[RFC1819] Delgrossi, L. and L. Berger, "Internet Stream Protocol
Version 2 (ST2) Protocol Specification - Version
ST2+", RFC 1819, August 1995.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2205] Braden, R., 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.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2379] Berger, L., "RSVP over ATM Implementation Guidelines",
BCP 24, RFC 2379, August 1998.
[RFC2380] Berger, L., "RSVP over ATM Implementation
Requirements", RFC 2380, August 1998.
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang,
"RSVP Diagnostic Messages", RFC 2745, January 2000.
[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.
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC
2750, January 2000.
[RFC2814] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and
M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol
for RSVP-based Admission Control over IEEE 802-style
networks", RFC 2814, May 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F., and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of
the Null Service Type", RFC 2997, 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.
[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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture
and framework", RFC 3303, August 2002.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
"Session Authorization Policy Element", RFC 3520,
April 2003.
[SGV02] R. Sofia, R. Guerin, and P. Veiga, "An Investigation
of Inter-Domain Control Aggregation Procedures",
International Conference on Networking Protocols, ICNP
2002, Paris, France, November 2002.
[SGV03] R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared-
segment Inter-domain Control Aggregation Protocol.
High Performance Switching and Routing, HPSR 2003,
Turin, Italy, June 2003.
[SGV03b] R. Sofia, R. Guerin, and P. Veiga. A Study of Over-
reservation for Inter-Domain Control Aggregation
Protocols. Technical report (short version under
submission), University of Pennsylvania, May 2003,
available at http://einstein.seas.upenn.edu/mnlab/
publications.html.
[TBA01] A. Talukdar, B. Badrinath, and A. Acharya, "MRSVP: A
Resource Reservation Protocol for an Integrated
Services Network with Mobile Hosts", Wireless
Networks, vol. 7, no. 1, pp. 5-19, 2001.
[Thom02] M. Thomas, "Analysis of Mobile IP and RSVP
Interactions", Work in Progress, October 2002.
[Tsch03] H. Tschofenig, "RSVP Security Properties", Work in
Progress, February 2004.
[ZDSZ93] L. Zhang, S. Deering, D. Estrin, and D. Zappala,
"RSVP: A New Resource Reservation Protocol", IEEE
Network, Volume 7, Pages 8-18, September 1993.
[URL1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
[URL2] OPENSIG http://comet.columbia.edu/opensig/
[URL3] SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/
siglite.html
Authors’ Addresses
Jukka Manner
Department of Computer Science
University of Helsinki
P.O. Box 68 (Gustav Hallstrominkatu 2b)
FIN-00014 HELSINKI
Finland
Phone: +358-9-191-51298
Fax: +358-9-191-51120
EMail: jmanner@cs.helsinki.fi
Xiaoming Fu
Institute for Informatics
Georg-August-University of Goettingen
Lotzestrasse 16-18
37083 Goettingen
Germany
Phone: +49-551-39-14411
Fax: +49-551-39-14403
EMail: fu@cs.uni-goettingen.de
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.