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

Versions: 00 01

   Internet Engineering Task Force                             G. Gross
   INTERNET DRAFT                                     Intel Corporation
   draft-gross-sipaq-00.txt
   November, 2000                                          H. Sinnreich
   Expires: May 2001                                         D. Rawlins
   SIP Working Group                                       MCI WorldCom

                                                              S. Thomas
                                                             TransNexus


            QoS and AAA Usage with SIP Based IP Communications


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

   This document specifies the architecture, protocols and messages for
   SIP based IP communications between Internet domains in support of
   QoS and AAA. Detailed message flows and message contents are
   discussed and specified. AAA requirements including inter-domain and
   user authorization in mobile and non-mobile environments are
   addressed. A solution is proposed where session setup and teardown
   are linked with QoS and AAA signaling using AAA policy servers and
   clearinghouses.












Gross et al.               Expires May 2001                   [Page 1]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Table of Contents..................................................2
   1. Introduction....................................................3
   2. Terminology.....................................................3
   3. Overview........................................................4
   4. Authorization and Authentication................................6
   4.1. Inter-domain..................................................7
   4.2. Application Level and Pre-call Mobility.......................9
   5. Message Contents...............................................12
   5.1. SIP Proxy to APS (Originating Domain)........................12
   5.2. APS to CH (from Originating Domain)..........................12
   5.3. CH to APS (to Originating Domain)............................13
   5.4. APS to SIP Proxy (Originating Domain)........................13
   5.5. SIP Proxy to SIP Proxy (Originating to Terminating Domain)...13
   5.6. SIP Proxy to APS (Terminating Domain)........................13
   6. Protocol Support...............................................13
   7. Messaging Overview.............................................14
   7.1. Originating Domain Contacts Clearinghouse....................15
   7.2. Terminating Domain Contacts Clearinghouse....................19
   8. Accounting, Charging and Billing...............................19
   9. Security Considerations........................................20
   10. Acknowledgments...............................................20
   11. References....................................................20
   12. Author's Address..............................................21
   13. Full Copyright Statement......................................22


























Gross et al.               Expires May 2001                   [Page 2]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


1. Introduction

   Commercial grade IP communications may require voice and other media
   transport of equal or higher quality than present 3.1 kHz circuit
   switched voice. Conversely, lower media quality may be acceptable in
   cases where other service advantages exist, similar to wireless
   audio/video streaming.

   We focus here on those circumstances where voice and other media
   quality are important and require end-to-end network resources for
   QoS with larger bandwidth and/or lower delay. Dynamic setup of end-
   to-end network resources for QoS requires highly scalable mechanisms
   to authenticate, authorize and account (AAA) for network resources
   across the Internet. This must be able to happen between a very
   large number of independent and various access domains that may have
   no business or trust relationship with each other, or may not even
   know of each other's existence before initiating end-to-end
   communications.

   The term IP communications is used here for a large class of new
   communications enabled by IP and the Internet such as presence,
   instant text, voice or multimedia conferences, the integration of
   messaging and real time communications, the integration of
   communications in productivity software, with transactions, games,
   entertainment and other. Not all IP communication services can be
   extended to other networks, such as PSTN, ISDN, H.323, BICC or the
   so-called "softswitch" networks that use MEGACO or similar master-
   slave signaling protocols.

   AAA services are important because QoS and IP to PLMN and PSTN
   termination through gateways are services that are billable.
   Unauthorized users should be prevented from using these services and
   service providers should be able to appropriately bill authorized
   users.

   This document specifies the architecture, protocols and messages for
   SIP based IP communications between Internet domains in support of
   QoS and AAA [1]. It builds on information presented in [2] and [3].
   This document discusses AAA requirements including inter-domain and
   user authorization in mobile and non-mobile environments. One AAA
   solution is proposed. The developments in this document assume 2
   party call control only. The term originator implies a user who
   initiates and participates in the IP communication session.

2. Terminology

   This section defines terms used throughout this document. Some of
   these terms may have other meanings outside the context of this
   work. Their outside meanings are not guaranteed to coincide with the
   definitions given here.

   APS: AAA and Policy Server. The APS acts as a policy decision point,
        PDP, for network usage related policies, including IP telephony

Gross et al.               Expires May 2001                   [Page 3]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


        and QoS requests such as bandwidth reservation. The APS acts on
        service requests, such as SIP INVITEs for calls requiring QoS
        and possibly outsources requests to other PDPs, such as a DIR,
        ADB, or CH. The APS renders a decision and may then apply
        policy to network elements.

   CH:  Clearinghouse. The CH authorizes inter-domain calls with QoS
        and collects usage reports for settlement between service
        providers.

   DIR: Directory. The DIR is the source for end user names and their
        services. A DIR has the list of all individual users and some
        attributes that the APS may use as criteria for policy
        decisions on an individual basis.

   ADB: Accounts Database. The ADB is part of the "back office" of the
        service provider. The ADB contains a list of all corporate
        accounts and the respective service level specifications that
        apply at the edges of their networks. It may have classes of
        policies or customized policies for various corporate accounts.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [4].

3. Overview

   The components involved in AAA and QoS enabled IP communication
   sessions are shown in Figure 1. SP represents a SIP Proxy. The
   clearinghouse (CH) exists outside the access domains and is
   responsible for providing inter-domain AAA services. In some cases a
   customer APS may exist outside the access domain. One such case may
   be where the customer has his or her own corporate domain with a
   corresponding corporate APS.

   Routers internal to the domain are labeled "R" and the edge router
   is labeled "ER". The media agent, "MA", is the application that
   sends/receives telephony/multimedia session data. The ER may be
   responsible for aggregating RSVP flows into appropriate Diffserv
   classes.

   All developments discussed in this document apply using SIP for
   setting up IP communications. Other signaling means such as H.323,
   MEGACO or related protocols, may have a different structure in the
   dependency between signaling, QoS setup and AAA and are therefore
   not the object of this draft.

   The SIP User Agent, SIP UA, acts as client and server on behalf of
   the user. If an IP phone originated the session, the SIP UA resides
   on the IP phone. If the signal entering the access domain came
   directly from a gateway, the SIP UA may reside in the access domain,
   as shown in the figure. In any case, the specific details of this
   configuration are not relevant to the development in this document.

Gross et al.               Expires May 2001                   [Page 4]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000



   The large box in Figure 1 is labeled as an ISP. In general, it may
   be an enterprise domain. Additionally, an enterprise domain may
   outsource SIP services to an ISP. In that case, both domains may be
   shown in the figure. For simplicity, Figure 1 is shown with a single
   domain.

             +-----------------------------------------+
             |  ISP                                    |
             |            +-----+   +-----+            |
             |            | DIR |   | ADB |            |
             |            +-----+   +-----+            |
             |                 |     |                 |
             |                 |     |                 |
    +-----+  |                +-------+                |   +----+
    |Cstmr|  |                |       |----------------+---| CH |
    | APS |--+----------------|  APS  |                |   +----+
    +-----+  |                |       |------------+   |
             |                +-------+            |   |
             |  +--------+     |    /              |   |
    +-----+  |  | SIP UA |     |    /              |   |
    | IP  |--+--|        |     |    /              |   |
    |Phone|  |  | +----+ |  +----+  /              |   | Signaling
    | or  |  |  | |SIP |-+--| SP |--+--------------+---+-------------
    |Gtwy |  |  | |    | |  +----+  /              |   |
    +-----+  |  | +----+ |          /              |   |
             |  |        |          /              |   |
             |  | +----+ |        +---+         +----+ | Session data
             |  | | MA |-+--------| R |---------| ER |-+-------------
             |  | +----+ |        +---+         +----+ |
             |  +--------+                             |
             +-----------------------------------------+

   Figure 1: Components to Support Inter-domain AAA QoS Services

   The SIP proxy acts as a policy enforcement point, PEP, for IP
   communication sessions that use SIP. An extension to COPS has been
   defined that outlines the syntax and semantics of COPS messages and
   COPS objects for use with SIP [5]. The APS is the corresponding
   policy decision point, PDP, for SIP sessions. The APS also interacts
   with the DIR, ADB, customer APS and CH for information on which to
   base a service usage decision. If QoS is requested and granted, the
   APS may also interact with applicable network device(s) to aid in
   QoS setup.

   Clearinghouses are used to provide scalable, inter-domain AAA
   services. One or more clearinghouses may be involved in an IP
   communications session. Network devices along the session data path
   use one or more QoS mechanisms to provide a user specified level of
   service. RSVP [6] may be one such QoS mechanism in access networks
   and Diffserv [7] may be a QoS mechanism in the transit network.



Gross et al.               Expires May 2001                   [Page 5]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   Internal routers may or may not participate in bandwidth
   reservation. If it can be assumed that internal routers are not
   bottlenecks and will always have sufficient resources to handle
   requests without reservations, message exchanges with the APS may be
   eliminated. In this case, the slanted line connecting the APS with R
   in Figure 1 may be ignored.

4. Authorization and Authentication

   Proper authorization and authentication may be accomplished in a
   variety of ways. In pursuit of the most suitable technique, various
   factors must be considered. These factors include:

   1) minimizing call setup time
   2) minimizing the time and occurrences that authorization
      tokens/messages are placed on the wire
   3) minimizing implementation complexity
   4) optimization of business relationship models (use of
      clearinghouses as opposed to many bi-lateral agreements).

   With these factors in mind, this document discusses some of the
   requirements of authorization and authentication and suggests one
   technique as a solution.

   Requirements of authorization and authentication include:

   1) user authorization
   2) inter-domain authorization

   In this document, user authorization is taken for granted when the
   session originator is in his/her home domain. This scenario is
   discussed in the first sub-section below. When the session
   originator roams into a foreign domain, or another party
   participating in the session roams into a foreign domain (called
   party), user authorization is necessary. Foreign domains are
   referred to as local domains in this document because they are local
   to the roaming user. This scenario is considered in the second sub-
   section below.

   While roaming, user registration is assumed to occur before an IP
   communication session is initiated [8]. During the user registration
   process, relevant information is exchanged between the roaming user
   and the local domain. This information includes the roaming users
   home domain. The registration process may use the AAA infrastructure
   described in this document. Further details concerning user
   registration are out of the scope of this document.

   The solution suggested within this document to handle AAA
   requirements in QoS enabled IP communication sessions is with the
   use of one or more authorization tokens and clearinghouses. This
   solution makes every attempt to address the factors listed
   previously to provide the most suitable solution.


Gross et al.               Expires May 2001                   [Page 6]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   Although accounting is not discussed in this section, it is an
   implied necessity. IP communication sessions must trigger the
   submission of usage indications or reports after session completion.
   This facilitates correct accounting.

4.1. Inter-domain

   Assume Domain 1, D1, and Domain 2, D2, register with Clearinghouse x
   (CHx). The necessary security infrastructure is put in place between
   CHx and D1 and CHx and D2. The security infrastructure must support
   authentication and authorization services. In some situations it may
   also be important to support a non-repudiation service to prevent
   the false denial of IP communication services.

   Such an infrastructure can be supplied in the form of a public key
   infrastructure, PKI, based system or a symmetric key based system
   such as Kerberos. This infrastructure must be operational before the
   services of CHx are available. If a PKI based system is used D1 may
   register with CHx, and in the process exchange public key
   certificates with CHx. CHx may then use the certificate from D1 to
   authenticate that any message received from D1 actually came from
   D1. Analogously, D1 may use the certificate from CHx to authenticate
   that any message received from CHx actually came from CHx. This can
   be facilitated by the built in security functionality of OSP [9].

   Authentication of the SIP proxy and all end users within a domain is
   the responsibility of the domain administrator. Maintenance of
   intra-domain security is required because CHx only authenticates D1
   as a whole through the APS. Intra-domain authentication of users
   requires another level of authentication not discussed in this
   section. This level of authentication is an especially important
   consideration for roaming users.

   When an end host caller from D1, EH1, calls an end host callee in
   D2, EH2, the APS in D1, APS1, requests an authorization token from
   CHx to verify that an appropriate business relationship exists with
   D2. This development is illustrated in Figure 2. The figure only
   illustrates messaging that includes the authorization token.

   If authorization is granted, CHx replies with an authorization token
   to APS1. This token carries sufficient authentication information so
   that D2 (and possibly CHx) can later verify that it was created by
   CHx (or possibly another trusted CH) and not by a fraudulent source.
   This is in addition to the digital signatures contained in the
   messages exchanged between CHx and APS1 used to authenticate
   individual messages.

   The APS1 may now authorize the call to the SIP proxy of D1, SP1.
   APS1 may store the session source, destination, and media
   information to aid in QoS setup. SP1 embeds the authorization token
   in the SIP INVITE messages and forwards it to the SIP proxy of D2,
   SP2.


Gross et al.               Expires May 2001                   [Page 7]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   Upon reception of the INVITE message, SP2 contacts APS2, passing it
   the authorization token, to request local and inter-domain
   authorization to complete session setup. Because the authorization
   token contains self-authentication information, APS2 can
   authenticate that CHx has actually authorized the incoming call.
   This removes the requirement for APS2 to contact CHx.

                        (1)    +--------+
                       +-------|  CHx   |
                       |       +--------+
             Domain 1  |                            Domain 2
      +----------------+---+                 +--------------------+
      |                |   |                 |                    |
      |      (2) +------+  |                 |  +------+ (4)      |
      |     +----| APS1 |  |                 |  | APS2 |----+     |
      |     |    +------+  |    ---------    |  +------+    |     |
      |  +-----+    (3)    |   ( Transit )   |           +-----+  |
      |  | SP1 +-----------+---( Network )---+---------->+ SP2 |  |
      |  +-----+           |   (         )   |           +-----+  |
      |          +------+  |    ---------    |  +------+          |
      |          | ER1  |  |                 |  | ER2  |          |
      |          +------+  |                 |  +------+          |
      |  +-----+           |                 |           +-----+  |
      |  | EH1 |           |                 |           | EH2 |  |
      |  +-----+           |                 |           +-----+  |
      |                    |                 |                    |
      +--------------------+                 +--------------------+

     1) APS1 requests an auth token from CH, triggered by session
        setup request from EH1
     2) APS1 returns auth token to SP1 (SP1 embeds token in
        session signaling message)
     3) SP1 signals SP2 with embedded token
     4) SP2 sends auth token to APS2 for authorization and
        authentication
     5) auth token no longer used, may be destroyed

               Figure 2: Authorization Token Life Cycle

   After EH1 and EH2 have been notified that the IP communication
   session has been authorized, they may now proceed to reserve
   bandwidth using a mechanism such as RSVP. Bandwidth management
   services determine if the requested bandwidth is available over the
   specified path.

   The originating and terminating domains have now completed proper
   inter-domain authorization. If authorization was granted call setup
   can complete and data may be exchanged over the reserved path. In
   some models, pre-session establishment of QoS may be a requirement.
   In such cases, completion of session setup may only transpire if QoS
   has been established in the required direction(s) [2], [10]. In
   other models, establishment of QoS and the IP communication session
   may be decoupled, where each proceeds independently [2].

Gross et al.               Expires May 2001                   [Page 8]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000



4.2. Application Level and Pre-call Mobility

   Mobility of an end user demands additional infrastructure to
   authenticate and authorize the user while roaming. Three or more
   domains may be involved in the AAA and call setup process. The local
   domain may be defined as the domain that the user has roamed into.
   The home domain may be defined as the domain where the user
   maintains a user profile that contains, among other things, a list
   of services for that user. The called domain is the domain in which
   the called party is present. Note that in the general case, this may
   not be the called party's home domain. That is, the called party may
   also be roaming. An additional level of authorization and
   authentication would be necessary in this case. For simplicity, this
   document addresses the case where the called party is reached at his
   or her home domain.

   In general, authorization and authentication between domains is
   necessary because billable QoS services may be requested along a
   path between them. All carriers included in this path who transmit
   the session data and provide the requested QoS services will expect
   accounting and/or payment.

   However, there is a distinction between the end domains where per
   call accounting may be required and the transit networks that need
   not to be burdened with the knowledge or understanding of each
   individual qos flow. For scalability, the transit networks will
   group all qos flows in some Diffserv class of traffic. The
   discussion that follows applies only to the end domains where the
   calls originate and terminate.

   Accounting agreements can be encompassed in a business relationship
   with a clearinghouse. An authorization token can be used to verify
   the business relationship between the local domain and the
   clearinghouse and the called domain and the clearinghouse. These are
   the domains between which the session data will travel.

   A business relationship may also include roaming allowances and
   services. This implies that a user who roams into a foreign domain
   may proceed to use the IP communication services that he/she pays
   for and normally receives from his/her home domain. An authorization
   token can be used between the local and home domains to verify such
   a business relationship with a clearinghouse.

   Under the assumption that the caller pays for services, the local
   domain is obligated to pay for the bandwidth consumed by the session
   data between the local and called domains. The charges received by
   the local domain must propagate back to the home domain of the
   caller so that the call is ultimately accounted. The charges would
   likely appear on the caller's monthly statement. The use of
   authorization tokens to verify business agreements can provide the
   infrastructure to allow such transactions to be completed.


Gross et al.               Expires May 2001                   [Page 9]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   In most cases, SIP signaling sessions which involve mobile SIP
   terminals will be directed through the home domain of the mobile
   user in order to maintain home control. Home control is important
   for the execution of signaled services because the user then sees
   the same services irrespective of the network capabilities of the
   local domain he/she has roamed into. These services are contained in
   a user profile at the user's home domain.

   The authorization tokens obtained from one or more clearinghouses
   may be embedded in the SIP signaling during session establishment.
   The order in which tokens are obtained is not clear at this time.
   Also, the domain(s) that contact the clearinghouse(s) for
   authorization token requests is not clear at this time. Two possible
   scenarios are illustrated in Figures 3 and 4. We note that in each,
   options exist concerning clearinghouse contacts and messaging order.

   In Figure 3, session signaling (SIP INVITE message) arrives at the
   SIP proxy of the local domain (1). The SP, acting as a SIP PEP,
   makes a request to the APS, acting as a SIP PDP (2). The APS of the
   local domain contacts one or more clearinghouses seeking appropriate
   business relationships with the home and called domains (3, 4). If
   all three domains are registered with the same clearinghouse, only
   that clearinghouse need be contacted. The clearinghouses return one
   or more authorization tokens to the APS, which passes them back to
   the SP. The SP embeds the tokens within the SIP INVITE message and
   forwards it to the home domain of the caller (5).

            |  Local   | Clearing | Home Dom  |  Called  |
            |  Domain  |  House   |  of UA1   |  Domain  |
            +----------+----------+-----------+----------+
            |          |          |           |          |
            |  +----+  |3 +----+  |           |          |
            |  |APS |--+--|CHx |  |  +-----+  |  +----+  |
            |  |    |  |  +----+  |  | APS |  |  |APS |  |
            |  |    |  |          |  |     |  |  |    |  |
            |  |    |  |4 +----+  |  |     |  |  |    |  |
            |  |    |--+--|CHy |  |  +-----+  |  +----+  |
            |  +----+  |  +----+  |     |     |    |     |
            |    |     |          |     |     |    |     |
            |    |     |          |   6 |     |  8 |     |
            |  2 |     |          |     |     |    |     |
     +---+  |    |     |          |     |     |    |     |  +---+
     |SIP| 1|  +----+  |    5     |  +-----+  |7 +----+  |9 |SIP|
     |UA1|--+--| SP |--+----------+--| SP  |--+--| SP |--+--|UA2|
     +---+  |  +----+  |          |  +-----+  |  +----+  |  +---+
            |          |          |           |          |

         Figure 3: Scenario 1 - Session Setup with AAA Support

   The SP in the home domain contacts the APS using a PEP/PDP
   relationship (6). The SP or APS refer to the user profile to verify
   that the requested services allowed. The APS verifies the applicable
   authorization token and may make additional policy-based admission

Gross et al.               Expires May 2001                  [Page 10]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   decisions. The decision is passed back to the SP. The INVITE message
   is then forwarded to the SP of the called domain (7). The SP
   contacts the APS using a PEP/PDP relationship (8). The APS verifies
   the applicable authorization token and may make additional policy-
   based admission decisions. The decision is passed back to the SP.
   The SP finally forwards the INVITE message to the called user, SIP
   UA2 (9).

   In Figure 4, the messaging is different only in one way. The APS of
   the local domain contacts the APS of the home domain before any
   authorization tokens are obtained (3). The APS of the home domain
   checks the user's profile to authorize the use of services. If the
   home domain authorizes the session, the APS in the local domain
   receives a success reply and proceeds to obtain necessary
   authorization tokens as described for Figure 3.

            |  Local   | Clearing | Home Dom  |  Called  |
            |  Domain  |  House   |  of UA1   |  Domain  |
            +----------+----------+-----------+----------+
            |          |          |           |          |
            |  +----+  |4 +----+  |           |          |
            |  |APS |--+--|CHx |  |  +-----+  |  +----+  |
            |  |    |  |  +----+  |  | APS |  |  |APS |  |
            |  |    |  |    3     |  |     |  |  |    |  |
            |  |    |--+----------+--|     |  |  |    |  |
            |  |    |  |          |  |     |  |  |    |  |
            |  |    |  |5 +----+  |  |     |  |  |    |  |
            |  |    |--+--|CHy |  |  +-----+  |  +----+  |
            |  +----+  |  +----+  |     |     |    |     |
            |    |     |          |     |     |    |     |
            |    |     |          |   7 |     |  9 |     |
            |  2 |     |          |     |     |    |     |
     +---+  |    |     |          |     |     |    |     |  +---+
     |SIP| 1|  +----+  |    6     |  +-----+  |8 +----+  |10|SIP|
     |UA1|--+--| SP |--+----------+--| SP  |--+--| SP |--+--|UA2|
     +---+  |  +----+  |          |  +-----+  |  +----+  |  +---+
            |          |          |           |          |

         Figure 4: Scenario 2 - Session Setup with AAA Support

   The advantage of the scenario in Figure 4 is that the user's profile
   is checked before any authorization tokens are obtained. In this
   way, valuable airtime in the wireless case would not be wasted
   transporting authorization tokens if the user's profile did not
   allow the session to proceed. A disadvantage is that call setup time
   may be lengthened somewhat due to an extra inter-domain message
   exchange. Another disadvantage may be that a messaging protocol
   between APSs would have to be defined. COPS is one protocol that may
   be used for this interaction [11].

   The authorization tokens ensure that authentic, billable parties
   exist and that account, billing and charge settlement may be
   achieved in a previously agreed upon manner. For scalability,

Gross et al.               Expires May 2001                  [Page 11]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   business relationships between domains do not need to exist.
   Instead, business relationships with a clearinghouse can be used.

5. Message Contents

   This section defines the data content of messages passed between the
   SIP proxies, APS, and clearinghouse to provide QoS and AAA linkage
   with SIP for inter-domain IP communication sessions. The messaging
   discussed does not consider mobility. It considers an originating
   domain and a terminating domain, each containing a SIP UA, a SIP
   proxy, and an APS, similar to the illustration in Figure 2. If
   inter-domain authorization and gateway location services are not
   required, interaction with a CH and inclusion of an authorization
   token in all exchanges listed in this section can be ignored.

   A companion document defines a COPS extension for SIP that details
   the messaging and message contents between the SP and APS [5]. The
   current document merely discusses this messaging in general terms.
   Please refer to the referenced document for full details.

5.1. SIP Proxy to APS (Originating Domain)

   When a SIP proxy receives an INVITE, it sends to the APS source,
   destination, and possibly media information. The source and
   destination information may be used by the APS for intra-domain
   policy-based admission authorization. It must be sent to the CH for
   inter-domain authorization.

   The SIP call identifier (callID) can be used by the APS for intra-
   domain accounting. The callID must be sent to the CH in the
   authorization request message. The CH may use this identifier when
   generating an authorization token.

   If the INVITE contains a SDP attribute specifying bandwidth
   reservation [10], the APS may need to know the amount of bandwidth
   requested. The bandwidth is implied by the media description [12],
   [13]. Bandwidth information is necessary if the APS is charged with
   the responsibility of managing bandwidth allocation based on user
   and application information. For example, the APS may have a policy
   that allows user X to reserve 300 Kbps for multimedia sessions with
   users A through E and only 50 Kbps multimedia sessions with other
   users.

5.2. APS to CH (from Originating Domain)

   The information required by the CH for accurate AAA support may be
   CH dependent. It is expected that all CHs require knowledge of the
   source and destination domains for basic AAA purposes. The call
   identifier may be useful for authorization token generation.
   Bandwidth reservation amount may be required by a CH dependent on
   the specific business agreement with the domains. This quantity may
   be used as a basis for granting or denying authorization. If


Gross et al.               Expires May 2001                  [Page 12]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   bandwidth reservation amount is required, it must be put into a form
   agreed upon by the parties involved, such as Kbps.

5.3. CH to APS (to Originating Domain)

   The clearinghouse has the responsibility of making an authorization
   decision concerning IP communication between the specified source
   and destination domains. If gateway services are also requested, the
   decision may also be based upon available gateways and subsequent
   QoS or cost characteristics corresponding with that gateway. For
   example, the business relationship of the end domains with the
   clearinghouse may exclude IP communication sessions that incur costs
   above a specific limit. Costs may result from long distance charges
   over the PSTN or from bandwidth reservation over the IP network. The
   location of a gateway will likely affect one or both of these costs.

   The CH must return to the APS an authorization decision. If the
   request is granted, the CH must also return to the APS an
   authorization token. The authorization token is expected to contain
   authentication information so that both end point domains recognize
   it as coming from a trusted CH, as described in a previous section.
   A transaction identifier may be returned by the CH and subsequently
   used to correlate original authorization requests with usage
   indication reports generated after the session has completed.

5.4. APS to SIP Proxy (Originating Domain)

   The APS finally responds to the SIP proxy INVITE message with a
   status, indicating if the user is allowed to send the INVITE further
   along the SIP signaling chain. If the authorization is granted, the
   APS passes the authorization token it received from the CH to the
   SIP proxy. The SIP proxy includes this token inside the
   authorization token header field of the INVITE message [14].

5.5. SIP Proxy to SIP Proxy (Originating to Terminating Domain)

   The SIP proxy forwards the INVITE message containing the
   authorization token from the originating domain to the terminating
   domain in the manner defined by SIP.

5.6. SIP Proxy to APS (Terminating Domain)

   The APS in the terminating domain requires the same information as
   the APS in the originating domain on which to base an intra-domain
   authorization decision. Additionally, if the APS receives an
   authorization token, it performs an authentication check on it using
   the security infrastructure previously established with the CH. This
   action verifies that the authorization token is authentic and that
   the requested service has been authorized by a trusted source.

6. Protocol Support



Gross et al.               Expires May 2001                  [Page 13]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   The exchange of information between the APS and the SIP proxy may be
   handled using COPS. As mentioned previously, a new COPS extension
   for SIP is being developed concurrently with this work [5].
   Exchanges between the APS and the CH can be handled using OSP [9].
   OSP defines all messaging and message data field specifications that
   are outlined in this document. No additional protocol work is
   required for this exchange. Also, OSP has been embraced and is in
   use by a number of large industry participants.

7. Messaging Overview

   This section details the message exchange and message contents to
   initiate and terminate a SIP-based IP multimedia session. Mobility
   is not considered in this section. The caller and callee are both
   present and active at their respective home domains.

   It is assumed that the media will be transmitted and received from
   both ends and that bandwidth reservation requests are made in both
   directions using the SDP attributes discussed in [10]. In the first
   subsection the inter-domain authorization occurs at the originating
   domain. In the second subsection the inter-domain authorization
   occurs at the terminating domain.
   Descriptions of SIP messages, including requests and responses, are
   not discussed in this document. They are discussed in detail in [1].
   Descriptions of RSVP messages are not discussed in this document but
   are discussed in detail in [15]. It is assumed that edge routers are
   RSVP enabled PEPs. Furthermore, it is assumed that the edge routers
   interact with the APS as PDPs of their respective domains for
   policy-based management decisions concerning RSVP. Message exchanges
   of this nature are assumed implicit in this section and are not
   included in the messaging overview. Details concerning this message
   exchange are in [16].

   As discussed in [2], two QoS models may be defined for IP
   communication sessions. The QoS assured model is one in which the
   session and QoS signaling are coupled. In this case the session does
   not proceed until/unless QoS has been successfully established. The
   QoS enabled model decouples session and QoS signaling. In this case,
   the session setup may complete and session data may be exchanged
   even if QoS has not yet been, or never gets, established. The
   messaging discussed in this document only considers the QoS enabled
   model. The development in this section may be extended to work with
   the QoS enabled model with the inclusion of extra messages defined
   in [10] and [17].

   Since QoS assured is assumed in the session flow examples, the RSVP
   and SIP messaging are decoupled and may occur asynchronously. The
   SIP, COPS and OSP messages outlined in the call flow examples may
   therefore not necessarily be in chronological order with the RSVP
   messages.

   All components involved in message passing are illustrated in Figure
   1. Those in the originating domain are subscripted with "o" and

Gross et al.               Expires May 2001                  [Page 14]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   components in the terminating domain are subscripted with "t". The
   subscript "o/t" implies corresponding components in each domain. The
   protocol used for each exchange is indicated at each step. Each step
   also contains notes concerning the contents or special attributes of
   the message.

7.1. Originating Domain Contacts Clearinghouse

   The following discussion refers to Figures 5 and 6. The step numbers
   of Figure 5 are indicated as message labels in Figure 6. In step 1,
   the caller picks up the phone, requests a bandwidth reserved
   connection and dials a number. This causes the UAo to include
   appropriate SDP attributes in the SIP INVITE message indicating that
   QoS is being requested in both directions. The necessary information
   is passed from the SPo to APSo in step 2. APSo checks if local
   policy allows the call. This may include interaction with an
   external policy database, a DIR, an ADB, and/or another APS.

   If local policy authorizes the call, APSo sends the CH an
   authorization request for inter-domain authorization in step 3. The
   CH considers the source and destination information to determine if
   appropriate business relationships exist with the originating and
   terminating domains. Bandwidth and/or media information may also be
   used on which to base a decision. If authorization is granted, the
   CH generates an authorization token using the call identifier as
   well as other data. The CH sends the token to the APSo in step 4
   along with a status value indicating if authorization has been
   granted or not. The APSo passes this information on to the SPo in
   step 5.

   The SPo forwards the INVITE with the embedded authorization token
   down the SIP signaling chain in step 6 to SPt in the terminating
   domain. The SPt sends the necessary information to APSt in step 7.
   The APSt requests local authorization in a similar fashion as that
   described for the originating domain. The APSt then uses the
   authorization token and other message data to authenticate the token
   and determine if inter-domain authorization has been granted. In
   step 8 the APSt passes a status to the SPt indicating if the session
   has been authorized. If the call and all requested services are
   granted, the SPt forwards the INVITE on to the UAt in step 9.

   The UAt may then send the RSVP Path message to UAo in step 10 since
   it knows the source and destination addresses and ports and the
   traffic specifications. Note that in some cases, the SDP sent from
   UAt to UAo may contain multiple media formats, each having different
   bandwidth requirements. In this case, the UAo must make a final
   decision considering the choice of media formats. If the traffic
   specifications change, additional RSVP messages may be sent to
   update the network devices along the session data path.

   In steps 11 and 12 the UAt sends back a 180 (ringing) SIP response
   to SPo via SPt. In some cases, the UAt may send a 183 (session
   progress) SIP response followed by a 180 response. The 183 response

Gross et al.               Expires May 2001                  [Page 15]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   would follow the same path as the 180 response. For simplicity, only
   the 180 response is shown in the figures.

   1)   UAo   -->   SPo    (SIP)  INVITE; (SDP "a=qos:")
   2)   SPo   -->   APSo   (COPS) src, dest, media, callID
   3)   APSo  -->   CH     (OSP)  src, dest, callID
   4)   CH    -->   APSo   (OSP)  status, auth token
   5)   APSo  -->   SPo    (COPS) status, auth token
   6)   SPo   -->   SPt    (SIP)  INVITE, (SDP "a=qos:"), auth token
   7)   SPt   -->   APSt   (COPS) src, dest, media, callID, auth
                                    token
   8)   APSt  -->   SPt    (COPS) status
   9)   SPt   -->   UAt    (SIP)  INVITE
   10)  UAt   -->   R/ERt  (RSVP) Path
   11)  UAt   -->   SPt    (SIP)  180
   12)  SPt   -->   SPo    (SIP)  180
   13)  SPo   -->   APSo   (COPS) src, dest, media
   14)  APSo  -->   SPo    (COPS) status
   15)  SPo   -->   UAo    (SIP)  180
   16)  UAo   -->   R/ERo  (RSVP) Path
   17)  UAt   -->   R/ERt  (RSVP) Resv
   18)  UAo   -->   R/ERo  (RSVP) Resv
   19)  UAt   -->   SPo    (SIP)  200 OK via SPt (SDP (a=qos:))
   20)  SPo   -->   APSo   (COPS) src, dest, media
   21)  APSo  -->   SPo    (COPS) status
   22)  SPo   -->   UAo    (SIP)  200 OK (SDP (a=qos:))
   23)  UAo   -->   SPo    (SIP)  ACK
   24)  SPo   -->   APSo   (COPS) src, dest, media
   25)  APSo  -->   SPo    (COPS) status
   26)  SPo   -->   SPt    (SIP)  ACK
   27)  SPt   -->   APSt   (COPS) src, dest, media
   28)  APSt  -->   SPt    (COPS) status
   29)  SPt   -->   UAt    (SIP)  ACK

   30)  UAo   <->   UAt    (RTP)  session data exchanged

   31)  UAo   -->   SPo    (SIP)  BYE
   32)  SPo   -->   APSo   (COPS) RPT, DRQ
   33)  SPo   -->   SPt    (SIP)  BYE
   34)  SPt   -->   APSt   (COPS) RPT, DRQ
   35)  SPt   -->   UAt    (SIP)  BYE
   36)  UAo   -->   ERo    (RSVP) PathTear and ResvTear
   37)  UAt   -->   ERt    (RSVP) PathTear and ResvTear
   38)  APSo  -->   CH     (OSP)  usage report - session duration,
                                    bandwidth consumed, etc.
   39)  APSt  -->   CH     (OSP)  usage report - session duration,
                                    bandwidth consumed, etc.

                    Figure 5: Message Flow Details

   The SPo checks if the source, destination or media information are
   different from what was specified in the INVITE message. If so, SPo
   sends the information to APSo in step 13. APSo checks local policy

Gross et al.               Expires May 2001                  [Page 16]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   and returns a status to SPo in step 14 indicating if the session is
   still allowed. If so, SPo sends the 180 response to UAo in step 15.

      +---+   +---+  +----+ +---+  +---+  +---+ +----+  +---+  +---+
      |SIP|   |SPo|  |APSo| |ERo|  |CH |  |ERt| |APSt|  |SPt|  |SIP|
      |UAo|   |   |  |    | |   |  |   |  |   | |    |  |   |  |UAt|
      +---+   +---+  +----+ +---+  +---+  +---+ +----+  +---+  +---+
        |       |      |      |      |      |      |      |      |
        |   1   |      |      |      |      |      |      |      |
        |------>|   2  |      |      |      |      |      |      |
        |       |----->|      3      |      |      |      |      |
        |       |      |------------>|      |      |      |      |
        |       |      |      4      |      |      |      |      |
        |       |   5  |<------------|      |      |      |      |
        |       |<-----|      |      |      |      |      |      |
        |       |      |      |      6      |      |      |      |
        |       |---------------------------------------->|      |
        |       |      |      |      |      |      |   7  |      |
        |       |      |      |      |      |      |<-----|      |
        |       |      |      |      |      |      |   8  |      |
        |       |      |      |      |      |      |----->|   9  |
        |       |      |      |      |      |      |      |----->|
        |       |      |      |      |      |      |  10  |      |
        |       |      |      |      |      |<-------------------|
        |       |      |      |      |      |      |      |  11  |
        |       |      |      |      12     |      |      |<-----|
        |       |<----------------------------------------|      |
        |       |  13  |      |      |      |      |      |      |
        |       |----->|      |      |      |      |      |      |
        |       |  14  |      |      |      |      |      |      |
        |   15  |<-----|      |      |      |      |      |      |
        |<------|      | 16   |      |      |      |      |      |
        |-------------------->|      |      |      |  17  |      |
        |       |  18  |      |      |      |<-------------------|
        |-------------------->|      | 19   |      |      |  19  |
        |       |<----------------------------------------|<-----|
        |       |  20  |      |      |      |      |      |      |
        |       |----->|      |      |      |      |      |      |
        |       |  21  |      |      |      |      |      |      |
        |   22  |<-----|      |      |      |      |      |      |
        |<------|      |      |      |      |      |      |      |
        |   23  |      |      |      |      |      |      |      |
        |------>|  24  |      |      |      |      |      |      |
        |       |----->|      |      |      |      |      |      |
        |       |  25  |      |      |      |      |      |      |
        |       |<-----|      |      26     |      |      |      |
        |       |---------------------------------------->|      |

                        Figure 6: Message Flow

   UAo may now send a RSVP Path message to UAt in step 16 since it
   knows the source and destination addresses and ports and the traffic


Gross et al.               Expires May 2001                  [Page 17]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   specifications. When RSVP Path messages arrive at UAo and UAt, they
   may send a RSVP Resv message as shown in steps 17 and 18.

      +---+   +---+  +----+ +---+  +---+  +---+ +----+  +---+  +---+
      |SIP|   |SPo|  |APSo| |ERo|  |CH |  |ERt| |APSt|  |SPt|  |SIP|
      |UAo|   |   |  |    | |   |  |   |  |   | |    |  |   |  |UAt|
      +---+   +---+  +----+ +---+  +---+  +---+ +----+  +---+  +---+
        |       |      |      |      |      |      |      |      |
        |       |      |      |      |      |      |  27  |      |
        |       |      |      |      |      |      |<-----|      |
        |       |      |      |      |      |      |  28  |      |
        |       |      |      |      |      |      |----->|  29  |
        |       |      |      |      30     |      |      |----->|
        |<------------------------------------------------------>|
        |   31  |      |      |      |      |      |      |      |
        |------>|  32  |      |      |      |      |      |      |
        |       |----->|      |      33     |      |      |      |
        |       |---------------------------------------->|      |
        |       |      |      |      |      |      |  34  |      |
        |       |      |      |      |      |      |<-----|  35  |
        |       |  36  |      |      |      |      |      |----->|
        |-------------------->|      |      |      |  37  |      |
        |       |      |      38     |      |<-------------------|
        |       |      |------------>|      39     |      |      |
        |       |      |      |      |<------------|      |      |

                    Figure 6 (cont'): Message Flow

   In step 19, UAt sends a final 200 (OK) response to SPo via SPt. If
   the source, destination or media information are different from what
   was specified previously, SPo sends a message to APSo in step 20.
   APSo checks local policy and returns a status to SPo in step 21
   indicating if the session is still allowed. If so, SPo sends the 200
   response to UAo in step 22.

   The UAo confirms reception of the 200 response and establishment of
   the session by sending a SIP ACK message to SPo in step 23. If the
   source, destination or media information are different from what was
   specified previously, SPo sends a message to APSo in step 24. APSo
   checks local policy and returns a status to SPo in step 25
   indicating if the session is still allowed. If so, SPo sends the ACK
   to SPt in step 26.

   If the source, destination or media information known by SPt are
   different from what was specified previously, SPt sends a message to
   APSo in step 27. APSt checks local policy and returns a status to
   SPt in step 28 indicating if the session is still allowed. If so,
   SPt sends the ACK to UAt in step 29.

   The session data is now exchanged via RTP, or some similar protocol,
   in step 30. The session ends for UAo when the SIP BYE message is
   sent to SPo in step 31. SPo sends a COPS report and deletes the COPS
   request state in APSo in step 32. The BYE message is simultaneously

Gross et al.               Expires May 2001                  [Page 18]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   forwarded to SPt in step 33. SPt sends a COPS report and deletes the
   COPS request state in APSt in step 34. The BYE message is sent to
   UAt in step 35.

   PathTear and ResvTear messages are sent from UAo and UAt upon call
   completion (from UAt when it receives the BYE message) in steps 36
   and 37. This triggers a COPS DRQ from ERo and ERt to APSo and APSt,
   respectively. These messages are not shown but implicitly implied.
   APSo and APSt may then perform necessary accounting/bookkeeping
   chores. Alternately, ResvErr messages may be sent by an APS under
   cancellation circumstances by APSo or APSt.

   The APSo and APSt send usage reports to the CH in steps 38 and 39 to
   indicate session duration, QoS services consumed such as bandwidth,
   and possibly other session details necessary for inter-domain
   accounting and settlement.

   Usage indication reports are sent to the CH in steps 30 and 31.
   Depending on the business agreement and the services used, this
   interaction may require contact between the SPo/t and the APSo/t.

   Other circumstances may cause the reservation in one or both
   directions to fail. In this case, ResvErr messages may be injected
   into the session data path. Upon reception of a PathErr or ResvErr
   message, an ERo/t would remove the corresponding state and notify
   APSo/t.

7.2. Terminating Domain Contacts Clearinghouse

   The caller may have a reason to allow the terminating domain to
   contact the CH for inter-domain authorization. For example, the
   caller may require that the callee make an unusually large bandwidth
   reservation for a critical IP communication exchange. The caller
   does not know the limits of services the callee is entitled to. In
   this case the caller may forego inter-domain authorization during
   call setup. Instead, the APSt, on behalf of the callee, receives the
   INVITE without a token, negotiates for an allowable level of
   service, then contacts the CH for an authorization request. The
   resulting authorization token is then placed inside the 200 response
   sent back to the caller. Such a scenario may only make sense if the
   CH requires bandwidth information (or other QOS service information
   such as latency or jitter) to make an authorization decision.

   The benefits of this are debatable. One advantage is that if
   successful negotiation is not possible, the call may be cancelled
   without contacting the CH, saving a message exchange. The message
   exchange scenario is similar to that of Figure 5 with minor changes.

8. Accounting, Charging and Billing

   We make a clear distinction between accounting, charging and billing
   and provide a summary, possibly incomplete description.


Gross et al.               Expires May 2001                  [Page 19]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   Accounting: The process of logging the usage of network resources,
   such as QoS or PSTN gateway service. The accounting data may or may
   not be used for usage charging, depending on the service model. This
   draft addresses accounting only and does not address charging and
   billing.

   Charging: Allocating the cost to various parties according to some
   business policies. Cost allocation may depend on such parameters as
   class of service, geographic locations, time of day, promotions,
   incentives for resellers and other. Examples of different business
   policies and classes of service are usage based charging and flat
   rate subscription rates.

   Billing: Informing various users of the charges and expected
   payments.

9. Security Considerations

   This document addresses some security issues concerning
   authentication of inter-domain business relationships. The protocols
   discussed in this work, SIP, COPS and OSP contain their own security
   mechanisms. Any security issues not addressed by SIP, COPS or OSP
   have not been considered in this work and are left as open issues.

10. Acknowledgments

   The authors would like to thank Russ Fenger, Arun Raghunath,
   Changwen Liu, Mark Grosen, Jeff Mark, Kalon Kelley and Dave Durham
   for insightful discussions and valuable contributions.

11. References

   [1] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
   "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [2] Sinnreich, H., Donovan, S., Rawlins, D., Thomas, S.,
   "Interdomain IP Communications with QoS, Authorization and Usage
   Reporting", Internet Draft, Internet Engineering Task Force,
   February 2000, Work in progress.

   [3] Sinnreich, H., Rawlins, D., Johnston, A., Donovan, S., Thomas,
   S., "AAA Usage for IP Telephony with QoS", Internet Draft, Internet
   Engineering Task Force, July 2000, Work in progress.

   [4] Bradner, S., "Key words for use in RFCs to indicate requirement
   levels", RFC 2119, March 1997.

   [5] Gross, G., Sinnreich, H., Rawlins, D., Thomas, S., "COPS Usage
   for SIP", Internet Draft, Internet Engineering Task Force, November
   2000, Work in progress.




Gross et al.               Expires May 2001                  [Page 20]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   [6] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
   "Resource ReSerVation Protocol (RSVP) û Functional Specification",
   RFC 2205, September 1997.

   [7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss,
   W., "An Architecture for Differentiated Services", RFC 2475,
   December 1998.

   [8] Schulzrinne, H., "SIP Registration", Internet Draft, Internet
   Engineering Task Force, October 2000, Work in progress.

   [9] European Telecommunications Standards Institute.
   "Telecommunications and Internet Protocol Harmonization Over
   Networks (TIPHON); Inter-domain pricing, authorization, and usage
   exchange". Technical Specification 101 321 version 1.4.2, December
   1998.

   [10] Marshall, W., et al. "Integration of Resource Management and
   SIP", Internet Draft, Internet Engineering Task Force, June 2000,
   Work in progress.

   [11] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A.
   Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748,
   January 2000.

   [12] Handley, M. and Jacobson, V., "SDP: Session Description
   Protocol", RFC 2327, April 1998.

   [13] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
   with Minimal Control", RFC 1890, January 1996.

   [14] Johnston, A., Rawlins, D., Sinnreich, H., Thomas, S., "OSP
   Authorization Token Header for SIP", Internet Draft, Internet
   Engineering Task Force, November 2000, Work in progress.

   [15] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
   "Resource ReSerVation Protocol (RSVP) û Functional Specification",
   RFC 2205, September 1997.

   [16] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.,
   Sastry, A., "COPS Usage for RSVP", RFC 2749, January 2000.

   [17] Rosenberg, J. and Schulzrinne, H., "Reliability of Provisional
   Responses in SIP", Internet Draft, Internet Engineering Task Force,
   June 2000, Work in progress.

12. Author's Address

      Gerhard Gross
      Intel Corporation
      MS JF3-206
      2111 NE 25th Ave.
      Hillsboro, OR 97124

Gross et al.               Expires May 2001                  [Page 21]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


      Phone: +1-503-264-6389
      Fax: +1-503-264-3483
      gerhard.gross@intel.com

      Diana Rawlins
      WorldCom
      901 International Parkway
      Richardson, Texas 75081
      USA
      diana.rawlins@wcom.com

      Henry Sinnreich
      WorldCom
      400 International Parkway
      Richardson, Texas 75081
      USA
      henry.sinnreich@wcom.com

      Stephen Thomas
      TransNexus, LLC
      430 Tenth Street NW
      Suite N-204
      Atlanta, GA 30318
      USA
      stephen.thomas@transnexus.com


13. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it maybe copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other then
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING
   TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON


Gross et al.               Expires May 2001                  [Page 22]


Internet Draft    QoS AAA SIP Based IP Communication     November 2000


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




















































Gross et al.               Expires May 2001                  [Page 23]


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