Subject: Re: Question on achieveing Assured QoS using SIP/COPS

From: [email-masked]
Date: Fri, 25 Feb 2000 10:49:44 -0600

It is my understanding is that 'assured QoS' has nothing to do with the
authorisation for which COPS is used. Can you elaborate your question?

Burcak Beser
3Com Carrier Systems Group

Bryan Byerly <[email-masked]> on 02/25/2000 09:38:21 AM

To:   [email-masked], [email-masked]
cc:   [email-masked] (bcc: Burcak Beser/MW/US/3Com)

Subject:  Question on achieveing Assured QoS using SIP/COPS

Hi guys,

Assuming a goal of achieving "assured QoS" using generic SIP:
(In assured QoS,  the phone doesn't ring until resource allocation has
been confirmed
vs. enabled QoS, when the phone rings and can be answered before QoS is
established.
In fact, if resources are not available, the enabled QoS conversation
would continue
(without QoS)).

I understand that assured QoS can be achieved using the provisioned
(push) model of COPS.
(REQ, ...  DEC, RPT, ... DEC, RTP, ... DEC, RPT ...)
Some examples of proposed provisioned models (push model) which (can)
achieve assured QoS are:
a) DQoS (using Gate objects)
b) COPS-PR (using ASN.1 encoded objects),
... which ones am I leaving out?

However, I have not seen assured QoS achieved using the
outsourcing model (pull model) of COPS.
(REQ, DEC, RPT, .... REQ, DEC, RPT,  ... REQ, DEC, RPT, ...)

Is it even possible to achieve assured QoS using the outsourcing model
(pull model) of COPS?

If so, could someone please sketch a brief call flow for me of
how to achieve assured QoS using the outsourcing model of COPS?

Thanks for your help!

Bryan

Bryan J. Byerly
[email-masked]

---

From: Shai Herzog <[email-masked]>
Date: Sat, 26 Feb 2000 21:36:42 -0500

Bryan, Burcak

Let me make a few assumptions:

1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1)
2. We are looking per-call QoS
3. "Assured" means Resources are allocated before a ring (a ring requires
    QoS), and resources are committed after the other side picked up
    (call commences).

The DQoS is a bit of an odd-ball standard, since it mixes RSVP
and COPS-RSVP Push model (gate operations). But, we all know that
COPS-RSVP wasn't designed to be in a push model.

I think there is a "better" solution just by using RSVP to allocate,
open and close gates:

Stage 1 (in parallel)

MTA-->(NCD/DCS)-->CMS/PDP (CMS makes a gate decision, resources are allocated)
  |                /|\
   \                | COPS-RSVP (outsourcing)
    \               |
     \(RSVP 1)---->CMTS

Stage 2:

Phone ring, other side answer

MTA-->(RSVP 2)---->CMTS    (confirms the reservation)

-----
RSVP(1) only ask for authorization and allocation, no actual commitment
         of resources. Resources are still in solicited mode.
RSVP(2) Commits resources (goes into unsolicited mode).
The difference may be a flag (allocate only, or commit).

This way, the Outsourcing model is maintained in COPS-RSVP (and
we all breath easier ;-), and basically only one protocol is
used to authorize allocate and reserve resources, i.e., RSVP/COPS.

I believe this is the closest DQoS can get to be compliant with
the COPS-RSVP architecture.

Shai

>-----Original Message-----
>From: [email-masked]
>To: Bryan Byerly
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Sent: 02/25/2000 11:49 AM
>Subject: Re: Question on achieveing Assured QoS using SIP/COPS
>
>
>

__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006

---

From: [email-masked]
Date: Mon, 28 Feb 2000 14:31:17 -0600

Shai,

> 1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1)

I do not think that this is a PacketCable specific requirement. I believe that
Bryan set the objective very good:

'In assured QoS,  the phone doesn't ring until resource allocation has
been confirmed vs. enabled QoS, when the phone rings and can be answered before
QoS is established.'

I also believe that this will be vald for other applications as well. One that
comes to my mind immediately is Gaming applications.

Although DQoS uses COPS-push model for authorisation it is not a requirement of
the 'assured QoS'.

As you mention in your mail the 'assured QoS' is related with the QoS signalling
which can be achieved without any Authorisation (i.e. need for COPS protocol).

Related with the COPS-push or COPS-pull models it is very possible to model the
below architecture (Which was depicted in "draft-dcsgroup-sip-call-auth").

Client         CMTS      Call Server
|              |              |
| Invite       |              |    Invite
|---------------------------------->|------------------------>
|              |              | Client Authentication
|              |  Gate Setup  | and Call Authorisation
|              |<----------------|
|              |
|              | Gate-Setup includes an Authorised IP Flow
|              | profile and a GateID as a pointer
|              |
|              |
|              | 200OK [+GateID] | 200 OK
|<----------------------------------|<------------------------
|              |              |
| PATH [+GateID]    |
|---------------->|
|              | The PATH Message includes GateID which identifies
|              | Authorised IP flow profile. CMTS checks the
|              | committed profile against

Instead one can re-draw the above architecture as:

Client    CMTS      PDP       Call Server
|         |         |              |
| Invite  |         |              |     Invite
|---------------------------------------->|------------------->
|         |         |              | Client Authentication
|         |         |  Gate Setup  | and Call Authorisation
|         |         |<----------------|
|         |         |              |
|         |         | Auth. Token  |
|         |         |---------------->|
|         |         |
|         |         | Auth Token is used in PDP for Authorised Profile
|         |         | identification
|         |         |
|         |     200OK [+AuthToken]       |    200 OK
|<----------------------------------------|<-----------------------
|         |         |
| PATH [+AT]|       |
|---------->| REQ [+AT]  |
|         |---------->|
|         |         | PDP makes the decision using the RSVP profile and
|         | DEC          | Authorised profile
|         |<----------|
|         |         |
|         | PATH    |
|         |----------------------------------------------------->

The same messaging also applies for the RESV message.

As can be seen from above architectures the change from PUSH to PULL model can
be achieved without any change in the signalling model.

Right now I am working on the changes to "draft-dcsgroup-sip-call-auth" and
making the draft more oriented towards SIP than COPS. Until now I was thinking
that a COPS usage draft is not necessary but maybe I was mistaken.

If there is a need I can pull my notes regarding the scrapped parts of the "
draft-dcsgroup-sip-call-auth" draft and make an 'Application Authorisation per
Use' Architecture document, which would specify the means of application servers
giving the Authorised profile and pulling Authorisation Token from PDP in a
standard manner (which would be a PUSH model).

Burcak Beser
3Com Carrier Access Group

Shai Herzog <[email-masked]> on 02/26/2000 08:36:42 PM

To:   [email-masked], [email-masked], [email-masked]
cc:    (bcc: Burcak Beser/MW/US/3Com)

Subject:  Re: FW: Question on achieveing Assured QoS using SIP/COPS

Bryan, Burcak

Stage 1 (in parallel)

Stage 2:

-----

Shai