Subject: Cross-domain QoS setup

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 22 Feb 2000 10:10:52 -0600 (CST)

Since draft-ietf-mmusic-sdp-qos-00.txt expired in December, and is
functionality we still need to standardize, it will (presumably) be 
reissued soon. Speaking on behalf of the PacketCable group, we have
some suggestions of enhancements to the upcoming release of this
document which would allow it to support a more robust network 
architecture.

The current draft makes an assumption that end-to-end network 
resource reservation is controlled by a single entity. For calls
being placed across adminstrative domains, however, this will
not be the case. Under such circumstances, the reservation of
resources needs a greater degree of coordination than is 
currently provided in the draft.

In particular, the calling user agent needs the ability to
communicate to the called user agent that it has reserved 
the necessary resources on its end, and that alerting may
begin as soon as the called user agent has done the same.

Our proposed method of doing so is as follows:

1) As in the current draft, the INVITE message contains
   a=qos:... lines to indicate the calling party's preferences
   for which streams have mandatory or optional reservation
   couplings associated with them.

2) Similary, the 18x response contains a subset of the INVITE
   preconditions.

3) The PRACK confirming the 18x will echo back the finally
   agreed-on preconditions. This will serve as a "go ahead"
   message to the called party to begin its actual resource
   reservation.

4) After the calling side has procured reservations for the
   required resources, it sends an INFO message to the called
   party. This INFO message contains an SDP with a confirmation
   that the required streams have been reserved. For the purposes
   of this message, we add two values to the "strength" field
   in the current draft: "reserved" and "resvfail". The presence
   of the "resvfail" token allows the called party to terminate
   the call with an error code (for mandatory streams) or to
   remove its local reservation (for optional streams).

5) The 200 response to the INFO message similarly contains
   SDP indicating, on a per-stream basis, the status of
   its local reservations (allowing the calling party to
   remove reservations for optional streams which were not
   reserved on the terminating side).

An example callflow follows (with unnecessary but present details, 
like tags and call-ids, removed). To prevent abiguity, I have inserted 
a "Session" header for all cases where SDP is present in a way that is 
not defined in the base specification and cannot be determined from
context (e.g. the response to a QoS INFO message).

--------------------
UAC->UAS

INVITE sip:[email-masked] SIP/2.0
To: Adam Roach <[email-masked]>
From: John Q. Public <[email-masked]>
CSeq: 1 INVITE
Content-Type: application/sdp

v=0
m=audio 48327 RTP/AVP 0
a=qos:mandatory sendrecv
m=video 10275 RTP/AVP 31
a=qos:mandatory sendrecv
--------------------
UAS->UAC

SIP/2.0 183 Preconditions
To: Adam Roach <[email-masked]>
From: John Q. Public <[email-masked]>
CSeq: 1 INVITE
Session: QoS
Content-Type: application/sdp

v=0
m=audio 48327 RTP/AVP 0
a=qos:mandatory sendrecv
m=video 10275 RTP/AVP 31
a=qos:optional sendrecv
--------------------
UAC->UAS

PRACK sip:[email-masked] SIP/2.0
To: Adam Roach <[email-masked]>
From: John Q. Public <[email-masked]>
CSeq: 2 PRACK
Session: QoS
Content-Type: application/sdp

v=0
m=audio 48327 RTP/AVP 0
a=qos:mandatory sendrecv
m=video 10275 RTP/AVP 31
a=qos:optional sendrecv
--------------------
UAS->UAC

SIP/2.0 200 OK
To: Adam Roach <[email-masked]>
From: John Q. Public <[email-masked]>
CSeq: 2 PRACK
Content-Length: 0
--------------------
Both parties perform resource reservation
--------------------
UAC->UAS

INFO sip:[email-masked] SIP/2.0
To: Adam Roach <[email-masked]>
From: John Q. Public <[email-masked]>
CSeq: 3 INFO
Session: QoS
Content-Type: application/sdp

v=0
m=audio 48327 RTP/AVP 0
a=qos:reserved sendrecv
m=video 10275 RTP/AVP 31
a=qos:resvfail sendrecv
--------------------
UAS->UAC

SIP/2.0 200 OK
To: Adam Roach <[email-masked]>
From: John Q. Public <[email-masked]>
CSeq: 3 INFO
Content-Type: application/sdp

v=0
m=audio 48327 RTP/AVP 0
a=qos:reserved sendrecv
m=video 10275 RTP/AVP 31
a=qos:resvfail sendrecv
--------------------
The called party cancels the videostream reservation
and begins alerting the called party.
--------------------
UAS->UAC

SIP/2.0 180 Ringing
To: Adam Roach <[email-masked]>
From: John Q. Public <[email-masked]>
CSeq: 1 INVITE
Content-Length: 0
--------------------

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Feb 2000 13:09:36 -0600

Adam

I think I see a flaw in this suggestion, but I'm not sure:

What happens if you have, for example, Level 3's pure IP network between  the
Calling agent's Domain and the Called agents Domain? 

Expanding on this, say I'm within my domain calling from my SIP IP Phone,
Cisco.com,  who has a direct IP connection into Level 3's IP Backbone (I don't
think we do -- but work within me here), but you are on a Cable Modem in the
AT&T Broadband Network in Dallas with VoIP enabled to your home; your example
seems to only allow for interaction between the calling and called domains,
does it matter than there will likely (more so in the future than now) be a
additional IP domain in the middle that could very well muck things up quite a
bit?

Further, if it does matter, what indication will both sides get if this middle
domain is the only one not to comply with the requested QoS settings?

>context (e.g. the response to a QoS INFO message).

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Feb 2000 18:01:10 -0500

> currently provided in the draft.

Not really. Resource reservation is under the "control" of all the
network elements along the path that perform some kind of admission
control and resource allocation. These elements will often belong to
different administrative domains. The draft makes no assumptions about
the number of providers along the reservation path, or anything like
that. It only ties resource reservation and signaling together at the
endpoints, dicatating a particular temporal sequence.

> begin as soon as the called user agent has done the same.

This is something different from what you are discussing above. It is,
in fact, covered in the draft. If A calls B, the RSVP RESV message from
A to B confirms resources are reserved from A to B, and the RESVCONF
from A to B confirms resource reservation from B to A. This allows B to
know whether resources are reserved in both directions. A mirror case
exists for A. 

The difficulty arises only with the segmented DQoS model in DCS, which
does not provide a way to confirm resource reservation (I think),
whereas RSVP does.

So, the question is this. We know we need a way for both parties to know
when resources are reserved in both directions. Is this a function that
belongs somewhere in SIP (through INFO, as you propose, or some other
means), or in a reservation protocol. The mechanism exists already now
in RSVP, but not in DQoS (DCS folks, please correct me if I am
mistaken). So, do we add it to SIP, in which case its not needed for
RSVP, or should it be added to DQoS, in which case the SIP operation is
independent of the underlying reservation mechanism?

I have argued that confirmation of resource reservation is rightly a job
for a resource reservation protocol. One of the things I like about SIP
is its separation from session level control and network layer issues,
such as resource reservation.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 22 Feb 2000 19:58:51 -0600

Detailed call flows addressing this issue are in
http://search.ietf.org/internet-drafts/draft-sinnreich-interdoma
in-sip-qos-osp-00.txt
in general agreement with Jonathan's position.
We hope to have a new version in time for the 47th IETF.

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On
>Behalf Of Jonathan
>Rosenberg
>Sent: Tuesday, February 22, 2000 5:01 PM
>To: Adam B. Roach
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: Cross-domain QoS setup
>
>
>
>
>"Adam B. Roach" wrote: