[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                     MMUSIC WG
Internet Draft                            J.Rosenberg,H.Schulzrinne,S.Donovan
draft-ietf-mmusic-sdp-qos-00.txt   Bell Laboratories,Columbia U.,MCI Worldcom
June 19, 1999
Expires: December 1999


      Establishing QoS and Security Preconditions for SDP Sessions

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract



1 Introduction

   This document discusses how network QoS and security establishment
   can be made a precondition to sessions described by SDP [1]. These



J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 1]


Internet Draft                  SDP QoS                    June 19, 1999


   preconditions require that the participant reserve network resources
   (or establish a secure media channel) before continuing with the
   session. We do not define new QoS reservation or security mechanisms;
   these pre-conditions simply require a participant to use existing
   resource reservation and security mechanisms before beginning the
   session.

   In the case of SIP [2], this effectively means that the "phone won't
   ring" until the preconditions are met. These preconditions are
   described by new SDP parameters, defined in this document. The
   parameters can mandate end-to-end QoS reservations based on RSVP [3]
   or any other end-to-end reservation mechanism (such as YESSIR [4]),
   and security based on IPSEC [5]. The preconditions can be defined
   independently for each media stream.

   To achieve the result of "not having the phone ring" until resources
   have been reserved, some have proposed adding QoS functions to
   application level signaling devices [6]. We do not take this
   approach. Rather, we feel that the QoS architecture of the Internet
   separates QoS signaling from application level signaling. Application
   layer devices (such as web proxies and SIP servers) are not well
   suited for participation in network admission control or QoS
   management, as this is fundamentally a network layer issue,
   independent of any particular application. In addition, since
   application devices like SIP servers are almost never on the "bearer
   path" (i.e., the network path the RTP [7] takes), and since the RTP
   path and signaling paths can be completely different (even traversing
   different autonomous systems), these application servers are
   generally not capable of managing QoS for the media. Keeping QoS out
   of application signaling also means that there can be a single
   infrastructure for QoS across all applications. This eliminates
   duplication of functionality, reducing management and equipment
   costs. It also means that new applications, with their own unique QoS
   requirements, can be easily supported.

   This loose coupling works very well for a wide range of applications.
   For example, in an interactive game, one can establish the game using
   an application signaling protocol, and then later on use RSVP to
   reserve network resources. The separation is also effective for
   applications which have no explicit signaling . However, certain
   applications may require tighter coupling. In the case of Internet
   telephony, the following is an important requirement:


        When A calls B, B's phone should not ring unless resouces
        have been reserved from A to B, and B to A.

   This could be achieved without coupling if A knew B's address, port,



J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 2]


Internet Draft                  SDP QoS                    June 19, 1999


   and codecs before the telephony signaling took place. However, since
   telephony signaling is used largely to obtain this information in the
   first place, the coupling cannot be avoided.

   A similar model exists for security. Rather than inventing new
   security mechanisms for each new application, common security tools
   (such as IPSEC) can be used across all applications. As with QoS, a
   means in application level protocols is needed to indicate that a
   security association is needed for the application to execute.

   To solve both of these problems, we propose an extension to SDP which
   allows indication of pre-conditions for sessions. These preconditions
   indicate that participation in the session should not proceed until
   the preconditions are met. The preconditions we define are (1)
   success of end-to-end resource reservation, and (2) success of end-
   to-end security establishment. We chose to implement these extensions
   in SDP, rather than SIP [2] or SAP [8], since they are fundamentally
   a media session issue. SIP is session agnostic; information about
   codecs, ports, and RTP [7] are outside the scope of SIP. Since it is
   the media sessions that the reservations and security refer to, SDP
   is the appropriate venue for the extensions. Furthermore, placement
   of the extensions in SDP rather than SIP or SAP allows specification
   of preconditions for individual media streams. For example, a
   multimedia lecture might require reservation for the audio, but not
   the video (which is less important).

   Our extensions are completely backwards compatible. If a recipient
   does not understand them, normal SIP or SAP processing will occur, at
   no penalty of call setup latency.

   Others have proposed defining new SIP headers (such as pre-RING) to
   convey to the remote party that QoS establishment is required,
   followed by a re-INVITE (with ringing) to actually initiate the
   session (thus there is a double INVITE to actually initiate the
   session) [9]. Other mechanisms exist as well. A separate draft
   addresses the differences in these approaches.

2 Overview

   The general idea behind the extension is simple. We define two new
   SDP attributes, qos and security. The qos attribute indicates whether
   end-to-end resource reservation is optional or mandatory, and in
   which direction (send, recv, or sendrecv). When the attribute
   indicates mandatory, this means that the participant who has received
   the SDP MUST NOT proceed with participation in the session until
   resource reservation has completed in the direction indicated. In
   this case, "not proceeding" means that the participant behaves as if
   they had not received the SDP at all. If the attribute indicates that



J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 3]


Internet Draft                  SDP QoS                    June 19, 1999


   QoS for the stream is optional, then the participant SHOULD proceed
   normally with the session, but SHOULD reserve network resources in
   the direction indicated, if they are capable. Absence of the qos
   attribute means the participant MAY reserve resources for this
   stream, and SHOULD proceed normally with the session. This behavior
   is the normal behavior for SDP.

   Resource reservation takes place using whatever protocols each
   participant must use based on support by their ISP. If the ISP's of
   the various participants are using differing resource reservation
   protocols, translation is necessary, but this is done within the
   network, without knowledge of the participants.

   When the end-to-end reservation fails for a stream whose qos is
   mandatory, the behavior is dependent on the specific protocol which
   delivered the SDP. The sections which follow define these semantics
   for SIP and SAP.

   The direction attribute indicates which direction reservations should
   be reserved in. If send, it means reservations should be made in the
   direction of media flow from the session originator to participants.
   In recv, it means reservations should be made in the direction of
   media flow from participants to the session originator. In the case
   of sendrecv, it means both.

   In the case of security, the same attributes are defined -
   optional/mandatory, and send/recv/sendrecv. Their meaning is
   identical to the one above, except that a security association should
   be established in the given direction. The details of the security
   association are not signaled by SDP; these depend on the Security
   Policy Database of the participant.

3 Syntax

   The formatting of the qos attribute is described by the following
   BNF:


   qos-attribute = ``a=qos:'' strength-tag SP direction-tag
   strength-tag = (``mandatory'' |''optional'')
   direction-tag = (``send'' | ``recv'' | ``sendrecv'')



   and the security attribute:

   security-attribute = ``a=secure:'' SP strength-tag SP direction-tag




J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 4]


Internet Draft                  SDP QoS                    June 19, 1999


   The following example shows an SDP description carried in a SIP
   INVITE message from A to B:

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           m=audio 49170 RTP/AVP 0
           a=qos:mandatory recv
           m=video 51372 RTP/AVP 31
           a=secure:mandatory sendrecv
           m=application 32416 udp wb
           a=orient:portrait
           a=qos:optional sendrecv
           a=secure:optional sendrecv


   This SDP indicates that B should not continue its involvement in the
   session until resources for the audio are reserved from B to A, and a
   bi-directional security association is established for the video. B
   can join the sessions once these preconditions are met, but should
   reserve resources and establish a bidirection security association
   for the whiteboard.

4 Usage with SIP

4.1 Overview

   In the case of SIP, the caller prepares an SDP message body for the
   INVITE describing their desired QoS and security preconditions, and
   the desired directions. For SIP, send means the direction of media
   from originator (whichever entity created the SDP) to recipient
   (whichever entity received the SDP in a SIP message), and recv is
   from recipient to originator. In an INVITE, the UAC is the
   originator, and the UAS is the recipient. The roles are reversed in
   the response.

   If the recipient of the INVITE (UAS) is capable and willing to
   perform the coupling (by coupling, we mean making the security and
   QoS establishment a precondition to session participation), it MUST
   return either a 180 or 183 (hereby referred to as 180/3) response
   containing SDP, along with the qos attribute, for each coupled
   stream. This SDP MUST be a subset of the preconditions indicated in
   the INVITE. Unlike normal SIP processing, the UAS MUST NOT alert the



J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 5]


Internet Draft                  SDP QoS                    June 19, 1999


   called user at this point (unless the SDP in the 180/3 indicated no
   mandatory coupled streams).

   Table 1 illustrates the allowed values for the coupling tag in the
   180/3. Each row represents a value of the coupling in the INVITE, and
   each column the value in the 180/3. An entry of N/A means that this
   combination is not allowed. A value of A->B (B->A) implies that the
   coupling is for resources reserved (or security established) from A
   to B (B to A). A value of A<->B means that the coupling is for
   resource reservation or security establishment in both directions.
   The value in the response is the one used by both parties.


                        B: 180 or 183
              _______________________________________________
              A: INV         send       recv  sendrecv  none

_______________________________________________
              send           N/A        A->B    N/A      --
              recv           B->A       N/A     N/A      --
              sendrecv       A->B       B<-A   A<->B     --
              none            --         --      --      --



   Table 1: Allowed values of coupling


   Table 2 illustrates the allowed values for the strength tag in the
   request and response. A "Y" means the combination is allowed, and a
   "N" means it is not. The value in the response is the one used by
   both parties.


                           B: 180 or 183
                __________________________________________
                A: INV       mandatory     optional  none

__________________________________________
                mandatory        Y            Y       Y
                optional         N            Y       Y
                none             N            N        Y


   Table 2: Allowed values of strength parameter


   The 180/3 is received by the UAC. The UAC should treat a 180/3
   without SDP, or with SDP and without any qos parameters in any
   stream, as an indication that the callee is unable or unwilling to
   couple. As such, it should proceed with normal call setup procedures.
   If the 180/3 contained SDP with mandatory qos parameters, the UAC



J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 6]


Internet Draft                  SDP QoS                    June 19, 1999


   SHOULD NOT generate local ringback (in the case of 180), or play
   media from the remote party (in the case of 183) until the mandatory
   preconditions are met.

   Once preconditions are met, the UAS alerts the user, and the UAC
   either provides ringback (in the case that a 180 was received) or
   plays media from the remote party (in the case of 183), and the SIP
   transaction completes normally.

   Note that this extension requires usage of reliable provisional
   responses [10]. This is because the 180/3 contains SDP with
   information required for the caller to initiate reservations from it
   towards the callee.

4.2 Details for RSVP

   Assuming the callee has inserted the qos tag in the 180/3 and sent
   it, it should immediately start generating PATH messages for each
   stream it marked as send or sendrecv in the 180/3 (both mandatory and
   optional). When the RESV message for the stream arrives at the
   callee, the callee makes note of it. When RESV messages have arrived
   for all mandatory streams which the callee marked as send, and if the
   callee didn't mark any mandatory streams as sendrecv or recv, it
   alerts the user.

   When the caller receives the SDP in the 180/3, it immediately begins
   sending PATH messages for all streams marked as recv or sendrecv in
   the 180/3.

   The caller will begin to receive PATH messages from the callee for
   streams marked in the 180/3 as send or sendrecv. The caller SHOULD
   begin sending RESV messages for these streams. Reservation
   confirmations MUST be requested.

   The callee will begin to receive these PATH messages from the caller.
   It should send RESV messages for these streams. Reservation
   confirmations MUST be requested.

   The caller should either generate local ringback (in the case of 180)
   or media from streams it receives (in the case of 183) when the
   following conditions are met:

        o For all streams marked as mandatory recv in the 180/3, a RESV
          was received

        o For all streams marked as mandatory send in the 180/3, a
          reservation confirmation was received




J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 7]


Internet Draft                  SDP QoS                    June 19, 1999


        o For all streams marked as mandatory sendrecv, a RESV and
          reservation confirmation were received

   The callee should begin to generate local ringback once all the
   following conditions are met:

        o For all streams marked as mandatory recv in the 180/3, a
          reservation confirmation was received

        o For all streams marked as mandatory send in the 180/3, a RESV
          was received

        o For all streams marked as mandatory sendrecv, a RESV and a
          reservation confirmation were received

   These rules basically ensure that ringing occurs only after all
   required reservations have been made. In the case of bidirectional
   reservations, the call setup requires 3.5 RTT (as compared to 1.5
   without any preconditions).

4.2.1 Examples

   The basic message flow for a case where the caller marks a single
   audio stream as sendrecv, and the callee marks the 180/3 as sendrecv,
   is shown in Figure 1.



                A                             B

                ----------INV----------------->


                <------180 w/SDP---------------
                <.....PATH..B2A................

                ..........RESV.B2A............>
                ..........PATH.A2B............>

                <,,,,,,,,RESVCONF B2A,,,,,,,,,,
     LOCAL RB   <........RESV...A2B............

                ,,,,,,,,,,,,RESVCONF A2B,,,,,,>  RINGING

                <--------------- 200 OK--------

                --------------ACK ------------>




J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 8]


Internet Draft                  SDP QoS                    June 19, 1999


   In the next example, there is a bidirectional audio stream from A to
   B. However, the caller (A) adds the qos attribute, but indicates only
   recv coupling. This means audio flows in both directions, but the SIP
   and RSVP are tied together only for reservations from B to A. The
   call flow is:



                A                             B

                ----------INV----------------->


                <------180 w/SP----------------
                <.....PATH..B2A................

                ..........RESV.B2A............> RINGING
                ..........PATH.A2B............>

     LOCAL RB   <,,,,,,,,RESVCONF B2A,,,,,,,,,,
                <--------------- 200 OK--------

                <........RESV...A2B............
                ,,,,,,,,,,,,RESVCONF A2B,,,,,,>

                --------------ACK ------------>



   Note that in this example, the ringing at B occurs after the B to A
   reservation has completed. There is still an A to B reservation, but
   it takes place on slower time scales, and is not coupled to the SIP
   messaging. Similarly, A alerts the user with local ringback when the
   B to A confirmation has been received, but before the A to B
   reservation has been received.

   In the next example, the caller has a single bidirectional audio
   stream which it marks with sendrecv coupling. However, the called
   party (B) doesn't understand this attribute. So, its 180/3 contains
   no SDP. The caller realizes that the callee doesn't understand the
   coupling, and proceeds with normal setup. As such, it provides local
   ringback immediately. The call flow is thus:



                A                             B

                ----------INV-----------------> RINGING



J.Rosenberg,H.Schulzrinne,S.Donovan                           [Page 9]


Internet Draft                  SDP QoS                    June 19, 1999


     LOCAL RB   <------180 w/o SDP-------------
                <--------------- 200 OK--------

                --------------ACK ------------>



5 Usage with SAP

5.1 QoS Preconditions with RSVP

   In the case of send coupling, a session participant should not play
   out audio for a stream until resources have been reserved for it.
   Session senders SHOULD send PATH messages, and participants should
   send RESV messages for those streams. A participant should not play
   out audio until reservation confirmations are received. Thus, if a
   participant receives audio from a new source, it does not play that
   audio out until it has seen a PATH message, sent a reservation for
   it, and gotten a confirmation.

   In the case of receive coupling, a session participant should not
   actually send audio until it has gotten at least one reservation for
   that audio stream. A participant should therefore send PATH messages
   before sending media. In most cases, since reservations are shared, a
   sender will only see a single RESV message anyway.

   In the case of sendrecv coupling, a participant follows both
   procedures above.

5.2 Security Preconditions with IPSEC

   Since SAP is primarily used for announcing multicast sessions, and
   IPSEC does not currently support multicast, a SAP session originator
   MUST NOT mark any streams with security preconditions.

6 SIP Extensions

   There are two behaviors a UA might take when some of the mandatory
   pre-conditions fail. In the first case, the UA proceeds with the call
   anyway. In the second case, the UA attempts to terminate the call.
   Different applications will require differing behaviors. To support
   either, we define a new SIP header, called Failure-Conditions. This
   header contains a list of tokens, each of which indicates a normally
   non-fatal condition which MUST cause a failure for this request. As
   with other SIP headers containing lists of tokens, the header may
   appear multiple times in a message. The header is both a request
   header and response header. When used in a request, it indicates the
   server SHOULD return a 500 class response to the request, should any



J.Rosenberg,H.Schulzrinne,S.Donovan                          [Page 10]


Internet Draft                  SDP QoS                    June 19, 1999


   of the indicated conditions occur. When used in a response, it
   indicate that the client SHOULD send a BYE for this call, should any
   of the indicated conditions occur.

   The syntax for this header is:


   Failure-Conditions = ``Failure-Conditions'' ``:'' 1#fconditions
   fconditions = (``qos'' | ``security'' | token)



   When the value qos is present in a request, the UAS should respond
   with a 500 class message if any mandatory reservation fails. When the
   value qos is present in a response, the UAC should send a BYE for
   this call should any mandatory reservations fail. When the value
   security is present in a request, the UAS should respond with a 500
   class response if any mandatory security channel cannot be
   established. Similarly, if the the security value is present in a
   response, the UAC should send a BYE for this call should any
   mandatory security channels fail to be established.

   When a condition is not listed, the request should not fail (or a BYE
   should not be sent), if the condition was a mandatory condition, and
   it failed.

   The SIP extension SHOULD be used in conjunction with a Require
   header. This extension is named org.ietf.sip.fail.

   There may be other extensions and mechanisms for SIP that support the
   SDP mechanisms described here.

7 Open Issues

   There are many open issues:

        o The SIP rules assume unicast. What about multicast?

        o The SIP rules are only for the case of original INVITE. What
          about re-INVITEs? What about original INVITE's with no SDP at
          all, or SDP with no m lines?

        o How is changing of the qos and security attributes in re-
          INVITEs handled?

        o Are the SIP rules too complex? Should we eliminate the various
          send, recv, and sendrecv flavors, and make it "all or
          nothing"?



J.Rosenberg,H.Schulzrinne,S.Donovan                          [Page 11]


Internet Draft                  SDP QoS                    June 19, 1999


        o The mechanism works assuming that an end system application
          actually sees both reservations and reservation confirmations.
          Is this true? Do the APIs for RSVP allow an application to
          know when these have occurred?

        o What about usage of SDP with RTSP? Megaco?

        o More details on ipsec are needed.

        o How long should each party wait for reservations to succeed
          before giving up and aborting the call?

8 Acknowledgements

   The authors wish to thank Jonathan Lennox for his valuable comments
   on this proposal.

9 Authors Addresses


   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   Rm. 4C-526
   email: jdrosen@bell-labs.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu

   Steve Donovan
   MCI Worldcom
   1493/678
   901 International Parkway
   Richardson, Texas 75081
   email: steven.r.donovan@mci.com




10 Bibliography

   [1] M. Handley and V. Jacobson, "SDP: session description protocol,"
   Request for Comments (Proposed Standard) 2327, Internet Engineering



J.Rosenberg,H.Schulzrinne,S.Donovan                          [Page 12]


Internet Draft                  SDP QoS                    June 19, 1999


   Task Force, Apr.  1998.

   [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments (Proposed
   Standard) 2543, Internet Engineering Task Force, Mar. 1999.

   [3] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin,
   "Resource ReSerVation protocol (RSVP) -- version 1 functional
   specification," Request for Comments (Proposed Standard) 2205,
   Internet Engineering Task Force, Sept. 1997.

   [4] P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation
   mechanism for the Internet," (Cambridge, England), July 1998.  also
   IBM Research Technical Report TC20967.

   [5] S. Kent and R. Atkinson, "Security architecture for the internet
   protocol," Request for Comments (Proposed Standard) 2401, Internet
   Engineering Task Force, Nov. 1998.

   [6] P. Sijben and M. Buckley, "Establishing and controlling end-to-
   end qos in tiphon systems," (tiphon temporary document), ETSI Tiphon,
   May 1999.  13TD109.

   [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
   transport protocol for real-time applications," Request for Comments
   (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.

   [8] M. Handley, C. Perkins, and E. Whelan, "Session announcement
   protocol," Internet Draft, Internet Engineering Task Force, June
   1999.  Work in progress.

   [9] P. Goyal, A. Greenberg, C. Kalmanek, B. Marshall, P. Mishra, D.
   Nortz, and K. K. Ramakrishnan, "Integration of call signaling and
   resource management for ip telephony," vol. 13, May/June 1999.

   [10] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
   responses in SIP," Internet Draft, Internet Engineering Task Force,
   May 1999.  Work in progress.













J.Rosenberg,H.Schulzrinne,S.Donovan                          [Page 13]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/