Framework for Session Set-up with Media Authorization
RFC 3521
|
Document |
Type |
|
RFC - Informational
(April 2003; No errata)
|
|
Authors |
|
Louis Hamer
,
Hugh Shieh
,
Bill Gage
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 3521 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Bert Wijnen
|
|
IESG note |
|
published as RFC3521
|
|
Send notices to |
|
(None)
|
Network Working Group L-N. Hamer
Request for Comments: 3521 B. Gage
Category: Informational Nortel Networks
H. Shieh
AT&T Wireless
April 2003
Framework for Session Set-up with Media Authorization
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Establishing multimedia streams must take into account requirements
for end-to-end QoS, authorization of network resource usage and
accurate accounting for resources used. During session set up,
policies may be enforced to ensure that the media streams being
requested lie within the bounds of the service profile established
for the requesting host. Similarly, when a host requests resources
to provide a certain QoS for a packet flow, policies may be enforced
to ensure that the required resources lie within the bounds of the
resource profile established for the requesting host.
To prevent fraud and to ensure accurate billing, this document
describes various scenarios and mechanisms that provide the linkage
required to verify that the resources being used to provide a
requested QoS are in-line with the media streams requested (and
authorized) for the session.
Hamer, et al. Informational [Page 1]
RFC 3521 Session Set-up with Media Authorization April 2003
Table of Contents
1. Introduction....................................................2
2. Conventions used in this document...............................3
3. Definition of terms.............................................4
4. The Coupled Model...............................................5
4.1 Coupled Model Message Flows...............................6
4.2 Coupled Model Authorization Token.........................8
4.3 Coupled Model Protocol Impacts............................8
5. The Associated Model <<using One Policy Server>>................8
5.1 Associated Model Message Flows
<<using One Policy Server>>...............................9
5.2 Associated Model Authorization Token
<<using One Policy Server>>..............................11
5.3 Associated Model Protocol Impacts
<<using One Policy Server>>..............................11
5.4 Associated Model Network Impacts
<<using One Policy Server>>..............................12
6. The Associated Model <<using Two Policy Servers>>..............12
6.1 Associated Model Message Flows
<<using Two Policy Servers>>.............................13
6.2 Associated Model Authorization Token
<<using Two Policy Servers>>.............................15
6.3 Associated Model Protocol Impacts
<<using Two Policy Servers>>.............................16
7. The Non-Associated Model........................................16
7.1 Non-Associated Model Message Flow........................17
7.2 Non-Associated Model Authorization Token.................19
7.3 Non-Associated Model Protocol Impacts....................19
8. Conclusions....................................................20
9. Security Considerations........................................21
10. Normative References...........................................22
11. Informative References.........................................23
12. Acknowledgments................................................23
13. Authors' Addresses.............................................24
14. Full Copyright Statement.......................................25
1. Introduction
Various mechanisms have been defined through which end hosts can use
a session management protocol (e.g., SIP [6]) to indicate that QoS
requirements must be met in order to successfully set up a session.
However, a separate protocol (e.g., RSVP [7]) is used to request the
resources required to meet the end-to-end QoS of the media stream.
To prevent fraud and to ensure accurate billing, some linkage is
Hamer, et al. Informational [Page 2]
RFC 3521 Session Set-up with Media Authorization April 2003
required to verify that the resources being used to provide the
requested QoS are in-line with the media streams requested (and
authorized) for the session.
This document describes such a linkage through use of a "token" that
Show full document text