idnits 2.17.1
draft-hilt-sipping-policy-usecases-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 17.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 562.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 539.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 546.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 552.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 6, 2005) is 6892 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-03) exists of
draft-ietf-sipping-session-indep-policy-01
-- No information found for draft-ietf-sipping-session-spec-policy - is the
name correct?
Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING Working Group V. Hilt
3 Internet-Draft Bell Labs/Lucent Technologies
4 Expires: December 8, 2005 G. Camarillo
5 Ericsson
6 June 6, 2005
8 Use Cases for Session-Specific Session Initiation Protocol (SIP) Session
9 Policies
10 draft-hilt-sipping-policy-usecases-00
12 Status of this Memo
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on December 8, 2005.
37 Copyright Notice
39 Copyright (C) The Internet Society (2005).
41 Abstract
43 This draft describes use cases for session-specific Session
44 Initiation Protocol (SIP) sessions policies.
46 Table of Contents
48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
50 2.1 Media Intermediary . . . . . . . . . . . . . . . . . . . . 3
51 2.1.1 General Overview . . . . . . . . . . . . . . . . . . . 3
52 2.1.2 Traffic Monitoring . . . . . . . . . . . . . . . . . . 7
53 2.1.3 Enforcing SLA/Access Control . . . . . . . . . . . . . 7
54 2.1.4 Load Balancing and Traffic Shaping . . . . . . . . . . 7
55 2.1.5 QoS Marking . . . . . . . . . . . . . . . . . . . . . 8
56 2.1.6 NAT/Firewall Traversal . . . . . . . . . . . . . . . . 8
57 2.1.7 Media-level Topology Hiding . . . . . . . . . . . . . 8
58 2.1.8 IPv4/IPv6 Interworking . . . . . . . . . . . . . . . . 8
59 2.1.9 Media Encryption . . . . . . . . . . . . . . . . . . . 9
60 2.2 Limitations and Restrictions . . . . . . . . . . . . . . . 9
61 2.2.1 General Overview . . . . . . . . . . . . . . . . . . . 9
62 2.2.2 Limit Bandwidth . . . . . . . . . . . . . . . . . . . 10
63 2.2.3 Restrict Codec Usage . . . . . . . . . . . . . . . . . 11
64 2.2.4 Restrict Media Type Usage . . . . . . . . . . . . . . 11
65 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
67 5. Informative References . . . . . . . . . . . . . . . . . . . . 12
68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
69 Intellectual Property and Copyright Statements . . . . . . . . 14
71 1. Introduction
73 Some domains have policies in place, which impact the sessions
74 established using the Session Initiation Protocol (SIP) [3]. These
75 policies are often needed to support the network infrastructure or
76 for the execution of services. For example, wireless networks
77 usually have limited resources for media traffic. A wireless network
78 provider may want to restrict codec usage on the network to lower
79 rate codecs or disallow the use of high bandwidth media types such as
80 video.
82 Session policies provide a mechanism for a network domain to
83 communicate these policies to user agents. With session policies,
84 user agents know about the policies in the network and can adjust
85 their sessions so that they comply with these policies or simply
86 connect to a domain with less stringent policies.
88 There has been much discussion in the IETF about the most suitable
89 protocol for session-specific Session Initiation Protocol (SIP)
90 policies [2]. The goal of this draft is to describe common use cases
91 in which session-specific policies are expected to be used.
92 Particularly controversial in this discussion is the mechanism for
93 conveying session information from the user agent to the policy
94 server. This draft will therefore describe the session information a
95 policy server needs to know for each of the discussed use case
96 scenarios.
98 This document focuses on session-specific policies. In some of the
99 use cases it might also be possible to use session-independent
100 policies [1]. However, session-independent policies are outside of
101 the scope of this document and their use will not be discussed here.
103 2. Use Cases
105 Most of the use cases for session-specific policies are based on the
106 insertion of a media intermediary or the limitation of certain
107 aspects of a session. The two categories of use cases are discussed
108 separately in the sections below.
110 2.1 Media Intermediary
112 This section provides a general overview over the insertion of a
113 media intermediary with session policies. It then discusses use
114 cases that are based on intermediaries.
116 2.1.1 General Overview
118 In this scenario it is assumed that a UA A is located in a policy
119 enabled domain (see Figure 1), which has an outbound proxy (P A), a
120 policy server (PS A) and a media intermediary (M A). UA A places a
121 call to a UA in another domain (UA B).
123 +------+ +---------------+ +------+
124 | |<--------->| Proxy (P A) |<-------------------->| |
125 | | +---------------+ | |
126 | | +---------------+ | |
127 | | | Policy Server | | |
128 | UA A |<=========>| (PS A) | | UA B |
129 | | +---------------+ | |
130 | | +---------------+ | |
131 | (b)<*********| (M A) Media (a)<********************| |
132 | |*********>(c) Intermediary |********************>(d) |
133 +------+ +---------------+ +------+
135 --- SIP Signaling
136 === Policy Channel
137 *** Media
139 Figure 1
141 In step (1) in Figure 2 UA A sends out an INVITE and receives the
142 address of the policy server PS A in step (2). It discloses session
143 information (from the offer) to policy server PS A in step (3). The
144 information disclosed includes the IP address and port (b) UA A is
145 going to use for inbound streams.
147 The policy server uses this information to create an address binding
148 for inbound media streams on M A. The binding connects a port on M A
149 (port (a) in Figure 2) to the address and port provided by UA A (i.e.
150 port (b)). With this binding, M A forwards all incoming traffic on
151 port (a) to port (b) on UA A.
153 UA A must use the address of M A and port (a) in the offer (instead
154 of its own address and port). PS A therefore returns the policy
155 shown in Figure 3 to UA A in step (4). This policy contains the
156 address of M A (192.0.2.0) and port (a) (6000/6001). Using this
157 policy, UA A creates a new offer' and sends it to UA B in step (5).
158 UA B will now send its media to port (a) on M A. From there it will
159 be forwarded to port (a) on UA A. Thus, M A has been inserted into
160 the inbound media stream.
162 UA A receives an answer in step (6) and discloses the address of UA B
163 and port (d) (extracted from the answer) to the policy server PS A in
164 step (7). PS A sets up a second binding now for outbound streams on
165 the M A. This binding connects port (c) on M A to the address and
166 port that was in the answer (i.e. the address of UA B and port(d)).
168 The address of M A and port (c) is returned to UA A in a policy in
169 step (8). UA A applies this policy to the answer. Thus, UA A will
170 now send its outbound traffic to M A, which in turn forwards it to UA
171 B. M A has also been inserted into the outbound media stream.
173 Proxy P A stays in the signaling path and removes the address
174 bindings on M A when the session is terminated.
176 Media streams can be encrypted by the UAs. In many cases, media
177 intermediaries need to decrypt the encrypted streams. UA A may
178 therefore need to provide an intermediary with the encryption keys
179 for the current session.
181 Information the UA needs to disclose to the policy server on the
182 policy channel:
184 o offer: the UA discloses the IP addresses and ports of all media
185 streams in the offer. The UA may also need to disclose the
186 encryption keys used for the current session.
187 o answer: the UA discloses the IP addresses and ports of all media
188 streams in the answer. The UA may also need to disclose the
189 encryption keys used for the current session.
191 UA A P A UA B
192 | | |
193 | INVITE offer | |
194 |---------------->| | (1)
195 | 488 | |
196 | + Policy-Contact| |
197 |<----------------| | (2)
198 | ACK | |
199 |---------------->| PS A |
200 | PolicyChannel | |
201 | + InfoOffer | |
202 |------------------->| | (3)
203 | PolicyChannel | |
204 | + PolicyOffer | |
205 |<-------------------| | (4)
206 | INVITE offer' | INVITE offer' |
207 | + Policy-Id | |
208 |---------------->|---------------------------->| (5)
209 | | |
210 | OK answer | OK answer |
211 |<----------------|<----------------------------| (6)
212 | ACK |
213 |---------------------------------------------->|
214 | PolicyChannel | |
215 | + InfoAnswer | |
216 |------------------->| | (7)
217 | PolicyChannel | |
218 | + PolicyAnswer | |
219 |<-------------------| | (8)
220 | | |
222 Figure 2
224
225
226 192.0.2.0:6000
227 6001
228 none
229
230
232 Figure 3
234 In the above call flow, intermediaries are inserted by modifying the
235 address and ports of media streams. Other techniques for inserting a
236 media intermediary such as using IP tunneling or TURN are also
237 feasible but not discussed in this draft.
239 2.1.2 Traffic Monitoring
241 Traffic monitoring generally requires that an entity in the network
242 can examine the media packets of a flow. It may also require that
243 media streams can be associated with SIP sessions.
245 A media intermediary that has been inserted into a media stream as
246 described above can examine media packets as required. Media streams
247 can be associated with the session for which the policy was created.
249 2.1.3 Enforcing SLA/Access Control
251 It is often desirable to enforce policies on media streams, for
252 example, according to a Service Level Agreement (SLA). Enforcing
253 policies requires that a network entity can monitor traffic and, in
254 case policies are violated, block traffic as needed.
256 Traffic monitoring can be performed by a media intermediary. The
257 intermediary can also decide whether packets are compliant to a given
258 policy or not. It can block streams if policies are violated by
259 dropping the respective packets.
261 An intermediary can enforce many types of media-level policies. For
262 example, it can enforce limitations session aspects (e.g., codecs,
263 bandwidth, media types), ensure that the media streams correspond
264 with what has been announced in the session description and it can
265 reject traffic that is sent outside of a SIP session. The
266 intermediary can also terminate streams for other reasons, for
267 example, if the user runs out of credit.
269 2.1.4 Load Balancing and Traffic Shaping
271 Load balancing and traffic shaping typically requires that the
272 network can determine the route of media streams independent of the
273 path that would be chosen by IP routing. This type of route
274 selection can take multiple criteria into account such as current
275 traffic conditions or peering agreements. For example, a service
276 provide may be connected to another service provider through two
277 links and may want to selectively route calls over one or the other
278 link. In another example, a service provide wants to route traffic
279 through a domain that would otherwise not be traversed by the media
280 streams.
282 A media intermediary can perform traffic shaping and load balancing.
283 The intermediary receives packets from the UA and can determine the
284 next hop destination for these packets.
286 A service provider may have multiple media intermediaries at
287 strategic locations in the network. By selecting one of these
288 intermediaries for a session, it forces the corresponding media
289 streams to go through the chosen intermediary. This way, media
290 traffic can be directed through a specific link, to a certain part of
291 the network or through a certain domain. The routing decision is
292 made by simply including a specific intermediary into the path.
294 2.1.5 QoS Marking
296 Two approaches for QoS marking on media streams are feasible with
297 session policies:
299 o Hosted QoS marking: a media intermediary is inserted as described
300 above. The intermediary performs QoS marking.
301 o Endsystem-based QoS marking: the policy server returns a session
302 policy that contains the desired DSCP value (following the flow
303 described in Section 2.2). The endpoint itself performs QoS
304 marking using this DSCP value.
306 2.1.6 NAT/Firewall Traversal
308 NAT/firewall traversal requires that the NAT/firewall is inserted
309 into the media path. Each endpoint sends its traffic to the NAT/
310 firewall, which then forwards it to the destination on the other side
311 of the NAT/firewall as permitted by NAT/firewall policies.
313 An media intermediary that is inserted into the media path as
314 described above can act as NAT/firewall.
316 2.1.7 Media-level Topology Hiding
318 Topology hiding is mostly done at the signaling level. However,
319 media-level topology may be used to hide the addresses of media
320 endpoints inside the network.
322 A media intermediary inserted into streams as described above can
323 perform media-level topology hiding. Such a media intermediary will
324 usually act as RTP mixer/translator. It can remove all internal IP
325 addresses and possibly other sensitive information carried in RTCP
326 reports.
328 2.1.8 IPv4/IPv6 Interworking
330 IPv4/v6 translation on media streams can also be performed by a media
331 intermediary.
333 2.1.9 Media Encryption
335 A media intermediary can encrypt/decrypt media traffic before
336 forwarding it. Media encryption/decription requires that the
337 intermediary has the encryption keys for the current session.
339 Media intermediaries may also need to decrypt encrypted media streams
340 in order to perform other functionalities that require a deep
341 inspection of RTP packets.
343 2.2 Limitations and Restrictions
345 This section provides a general overview over the use of session
346 policies to restrict certain aspects of a session. It provides
347 example use cases for some of these policies.
349 2.2.1 General Overview
351 The scenario is similar to Figure 1 except that there is no media
352 intermediary (in a real architecture, it may still be present to
353 perform other functionalities such as policy enforcement).
355 Steps (1) to (3) in Figure 4 are the same as above (see Figure 2).
357 After receiving offer information in step (3), the policy server
358 determines whether a policy is needed or not. If a policy is needed,
359 it is returned to UA A in step (4) (see policy examples below). The
360 UA A creates a modified offer' according to the received policies
361 (step (5)) and completes the session setup in step (6).
363 Policies that define limitations or restrictions reduce available
364 choices for session parameters. These policies only need to be
365 applied to an offer because the answer can't extend the choices
366 available in an offer.
368 The policy server PS A can asynchronously update the policy provided
369 to UA A during session setup. For example, a policy server may whish
370 to disallow a codec that was allowed by the initial session policy.
371 In step (7) PS A sends an updated policy to UA A. This policy
372 requires a change in the current session. UA A therefore updates the
373 session by sending a re-INVITE with a modified offer in step (8).
375 The information the UA needs to disclose to the policy server depends
376 on the individual use case and are described below.
378 UA A P A UA B
379 | | |
380 | INVITE offer | |
381 |---------------->| | (1)
382 | 488 | |
383 | + Policy-Contact| |
384 |<----------------| | (2)
385 | ACK | |
386 |---------------->| PS A |
387 | PolicyChannel | |
388 | + InfoOffer | |
389 |------------------->| | (3)
390 | PolicyChannel | |
391 | + PolicyOffer | |
392 |<-------------------| | (4)
393 | INVITE offer' | INVITE offer' |
394 | + Policy-Id | |
395 |---------------->|---------------------------->| (5)
396 | | |
397 | OK answer | OK answer |
398 |<----------------|<----------------------------| (6)
399 | ACK |
400 |---------------------------------------------->|
401 | | |
402 | | |
403 | PolicyChannel | |
404 | + PolicyOffer" | |
405 |<-------------------| | (7)
406 | INVITE offer" | INVITE offer" |
407 | + Policy-Id | |
408 |---------------->|---------------------------->| (8)
409 | OK answer | OK answer |
410 |<----------------|<----------------------------|
411 | ACK |
412 |---------------------------------------------->|
413 | | |
415 Figure 4
417 2.2.2 Limit Bandwidth
419 In some environments there is only a limited bandwidth available to
420 each user agent (e.g. in a wireless network). Communicating
421 bandwidth limitations to the user agent enables the user agent to
422 make an informed decisions, for example, about the codecs or media
423 types to be used in a session.
425 The following example policy informs the UA of a 80 kbit/s bandwidth
426 limit. In the context of session-specific policies, this policy is
427 returned if the offer can result in a session that exceeds the
428 allowed maximum bandwidth. The offer' that is created based on this
429 policy should not contain choices that may exceed the maximum
430 bandwidth (e.g. it could consist of one audio stream and the codecs
431 G.711 and G.729).
433
434 80
435
437 Information the UA needs to disclose to the policy server about the
438 offer on the policy channel:
440 o The UA must disclose all aspects of a session that may affect the
441 media bandwidth used. These are typically the number of streams
442 together with the media type and the codecs available on a stream.
443 Alternatively, the UA can disclose a maximum bandwidth value.
445 2.2.3 Restrict Codec Usage
447 Networks may want to impose restrictions on the codecs that can be
448 used. With session-specific policies it is possible tell the UA that
449 some of the codecs in the offer are prohibited.
451 The following example policy informs the UA that the codecs G.729 and
452 G.723 are not allowed. Offer' should therefore not include G.729 and
453 G.723.
455
456
457 G729
458 G723
459
460
462 Information the UA needs to disclose to the policy server about the
463 offer on the policy channel:
465 o The UA must disclose all codecs it has included in the offer.
467 2.2.4 Restrict Media Type Usage
469 Similar to codecs, it is possible to restrict the use of media types
470 using session-specific policies.
472 The example policy below defines that audio is required, video is
473 allowed and all other media types are disallowed.
475
476
477 audio
478 video
479
480
482 Information the UA needs to disclose to the policy server about the
483 offer on the policy channel:
485 o The UA must disclose all media types it has included in the offer.
487 3. Security Considerations
489 This draft describes the use of mechanisms defined in other drafts
490 and does not introduce additional security issues.
492 4. IANA Considerations
494 This draft does not introduce new identifiers or namespaces.
496 5. Informative References
498 [1] Hilt, V., Camarillo, G., and J. Rosenberg, "Session-Independent
499 Session Initiation Protocol (SIP) Policies - Profile Data and
500 Mechanisms", draft-ietf-sipping-session-indep-policy-01 (work in
501 progress), October 2004.
503 [2] Hilt, V., Camarillo, G., and J. Rosenberg, "A Delivery Mechanism
504 for Session-Specific Session Initiation Protocol (SIP) Session
505 Policies", draft-ietf-sipping-session-spec-policy-03 (work in
506 progress), April 2005.
508 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
509 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
510 Session Initiation Protocol", RFC 3261, June 2002.
512 Authors' Addresses
514 Volker Hilt
515 Bell Labs/Lucent Technologies
516 101 Crawfords Corner Rd
517 Holmdel, NJ 07733
518 USA
520 Email: volkerh@bell-labs.com
522 Gonzalo Camarillo
523 Ericsson
524 Hirsalantie 11
525 Jorvas 02420
526 Finland
528 Email: Gonzalo.Camarillo@ericsson.com
530 Intellectual Property Statement
532 The IETF takes no position regarding the validity or scope of any
533 Intellectual Property Rights or other rights that might be claimed to
534 pertain to the implementation or use of the technology described in
535 this document or the extent to which any license under such rights
536 might or might not be available; nor does it represent that it has
537 made any independent effort to identify any such rights. Information
538 on the procedures with respect to rights in RFC documents can be
539 found in BCP 78 and BCP 79.
541 Copies of IPR disclosures made to the IETF Secretariat and any
542 assurances of licenses to be made available, or the result of an
543 attempt made to obtain a general license or permission for the use of
544 such proprietary rights by implementers or users of this
545 specification can be obtained from the IETF on-line IPR repository at
546 http://www.ietf.org/ipr.
548 The IETF invites any interested party to bring to its attention any
549 copyrights, patents or patent applications, or other proprietary
550 rights that may cover technology that may be required to implement
551 this standard. Please address the information to the IETF at
552 ietf-ipr@ietf.org.
554 Disclaimer of Validity
556 This document and the information contained herein are provided on an
557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
559 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
560 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
561 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
564 Copyright Statement
566 Copyright (C) The Internet Society (2005). This document is subject
567 to the rights, licenses and restrictions contained in BCP 78, and
568 except as set forth therein, the authors retain all their rights.
570 Acknowledgment
572 Funding for the RFC Editor function is currently provided by the
573 Internet Society.