Subject: Re: Cross-domain QoS setup

From: William Marshall <[email-masked]>
Date: Wed, 23 Feb 2000 00:23:52 -0500 (EST)

James M. Polk wrote:
> 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?

This is exactly the point.  In general there will be three (or more) service
providers involved in establishing the QoS, and their service level agreements
may be (and in some cases definitely are) different.  The router at the
edge of each service provider's network needs to convert the resource
reservation request into something that the next service provider is willing
to handle; in general this may not always be RSVP.  Depending on end-to-end
RSVP for a successful SIP connection would be an unfortunate dependency.

Bill Marshall
[email-masked]

-----original message-----
> 
> 
> 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?
> 
> At 10:10 AM 2/22/2000 -0600, Adam B. Roach wrote:
> >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
> >
> >
> 
> *************************************
> "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
> --=====================_2567198==_.ALT
> Content-Type: text/html; charset="us-ascii"
> 
> <html><div>Adam</div>
> <br>
> <div>I think I see a flaw in this suggestion, but I'm not sure:</div>
> <br>
> <div>What happens if you have, for example, Level 3's pure IP network
> between&nbsp; the Calling agent's Domain and the Called agents Domain?
> </div>
> <br>
> <div>Expanding on this, say I'm within my domain calling from my SIP IP
> Phone, Cisco.com,&nbsp; 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&amp;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?</div>
> <br>
> <div>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?</div>
> <br>
> <div>At 10:10 AM 2/22/2000 -0600, Adam B. Roach wrote:</div>
> <div>&gt;Since draft-ietf-mmusic-sdp-qos-00.txt expired in December, and
> is</div>
> <div>&gt;functionality we still need to standardize, it will (presumably)
> be </div>
> <div>&gt;reissued soon. Speaking on behalf of the PacketCable group, we
> have</div>
> <div>&gt;some suggestions of enhancements to the upcoming release of
> this</div>
> <div>&gt;document which would allow it to support a more robust network
> </div>
> <div>&gt;architecture.</div>
> <div>&gt;</div>
> <div>&gt;The current draft makes an assumption that end-to-end network
> </div>
> <div>&gt;resource reservation is controlled by a single entity. For
> calls</div>
> <div>&gt;being placed across adminstrative domains, however, this
> will</div>
> <div>&gt;not be the case. Under such circumstances, the reservation
> of</div>
> <div>&gt;resources needs a greater degree of coordination than is 
> </div>
> <div>&gt;currently provided in the draft.</div>
> <div>&gt;</div>
> <div>&gt;In particular, the calling user agent needs the ability
> to</div>
> <div>&gt;communicate to the called user agent that it has reserved
> </div>
> <div>&gt;the necessary resources on its end, and that alerting 
> may</div>
> <div>&gt;begin as soon as the called user agent has done the 
> same.</div>
> <div>&gt;</div>
> <div>&gt;Our proposed method of doing so is as follows:</div>
> <div>&gt;</div>
> <div>&gt;1) As in the current draft, the INVITE message contains</div>
> <div>&gt;&nbsp;&nbsp; a=qos:... lines to indicate the calling party's
> preferences</div>
> <div>&gt;&nbsp;&nbsp; for which streams have mandatory or optional
> reservation</div>
> <div>&gt;&nbsp;&nbsp; couplings associated with them.</div>
> <div>&gt;</div>
> <div>&gt;2) Similary, the 18x response contains a subset of the
> INVITE</div>
> <div>&gt;&nbsp;&nbsp; preconditions.</div>
> <div>&gt;</div>
> <div>&gt;3) The PRACK confirming the 18x will echo back the
> finally</div>
> <div>&gt;&nbsp;&nbsp; agreed-on preconditions. This will serve as a
> &quot;go ahead&quot;</div>
> <div>&gt;&nbsp;&nbsp; message to the called party to begin its actual
> resource</div>
> <div>&gt;&nbsp;&nbsp; reservation.</div>
> <div>&gt;</div>
> <div>&gt;4) After the calling side has procured reservations for
> the</div>
> <div>&gt;&nbsp;&nbsp; required resources, it sends an INFO message to the
> called</div>
> <div>&gt;&nbsp;&nbsp; party. This INFO message contains an SDP with a
> confirmation</div>
> <div>&gt;&nbsp;&nbsp; that the required streams have been reserved. For
> the purposes</div>
> <div>&gt;&nbsp;&nbsp; of this message, we add two values to the
> &quot;strength&quot; field</div>
> <div>&gt;&nbsp;&nbsp; in the current draft: &quot;reserved&quot; and
> &quot;resvfail&quot;. The presence</div>
> <div>&gt;&nbsp;&nbsp; of the &quot;resvfail&quot; token allows the called
> party to terminate</div>
> <div>&gt;&nbsp;&nbsp; the call with an error code (for mandatory streams)
> or to</div>
> <div>&gt;&nbsp;&nbsp; remove its local reservation (for optional
> streams).</div>
> <div>&gt;</div>
> <div>&gt;5) The 200 response to the INFO message similarly
> contains</div>
> <div>&gt;&nbsp;&nbsp; SDP indicating, on a per-stream basis, the status
> of</div>
> <div>&gt;&nbsp;&nbsp; its local reservations (allowing the calling party
> to</div>
> <div>&gt;&nbsp;&nbsp; remove reservations for optional streams which were
> not</div>
> <div>&gt;&nbsp;&nbsp; reserved on the terminating side).</div>
> <div>&gt;</div>
> <div>&gt;An example callflow follows (with unnecessary but present
> details, </div>
> <div>&gt;like tags and call-ids, removed). To prevent abiguity, I have
> inserted </div>
> <div>&gt;a &quot;Session&quot; header for all cases where SDP is present
> in a way that is </div>
> <div>&gt;not defined in the base specification and cannot be determined
> from</div>
> <div>&gt;context (e.g. the response to a QoS INFO message).</div>
> <div>&gt;</div>
> <div>&gt;--------------------</div>
> <div>&gt;UAC-&gt;UAS</div>
> <div>&gt;</div>
> <div>&gt;INVITE sip:[email-masked] SIP/2.0</div>
> <div>&gt;To: Adam Roach &lt;[email-masked]&gt;</div>
> <div>&gt;From: John Q. Public &lt;[email-masked]&gt;</div>
> <div>&gt;CSeq: 1 INVITE</div>
> <div>&gt;Content-Type: application/sdp</div>
> <div>&gt;</div>
> <div>&gt;v=0</div>
> <div>&gt;m=audio 48327 RTP/AVP 0</div>
> <div>&gt;a=qos:mandatory sendrecv</div>
> <div>&gt;m=video 10275 RTP/AVP 31</div>
> <div>&gt;a=qos:mandatory sendrecv</div>
> <div>&gt;--------------------</div>
> <div>&gt;UAS-&gt;UAC</div>
> <div>&gt;</div>
> <div>&gt;SIP/2.0 183 Preconditions</div>
> <div>&gt;To: Adam Roach &lt;[email-masked]&gt;</div>
> <div>&gt;From: John Q. Public &lt;[email-masked]&gt;</div>
> <div>&gt;CSeq: 1 INVITE</div>
> <div>&gt;Session: QoS</div>
> <div>&gt;Content-Type: application/sdp</div>
> <div>&gt;</div>
> <div>&gt;v=0</div>
> <div>&gt;m=audio 48327 RTP/AVP 0</div>
> <div>&gt;a=qos:mandatory sendrecv</div>
> <div>&gt;m=video 10275 RTP/AVP 31</div>
> <div>&gt;a=qos:optional sendrecv</div>
> <div>&gt;--------------------</div>
> <div>&gt;UAC-&gt;UAS</div>
> <div>&gt;</div>
> <div>&gt;PRACK sip:[email-masked] SIP/2.0</div>
> <div>&gt;To: Adam Roach &lt;[email-masked]&gt;</div>
> <div>&gt;From: John Q. Public &lt;[email-masked]&gt;</div>
> <div>&gt;CSeq: 2 PRACK</div>
> <div>&gt;Session: QoS</div>
> <div>&gt;Content-Type: application/sdp</div>
> <div>&gt;</div>
> <div>&gt;v=0</div>
> <div>&gt;m=audio 48327 RTP/AVP 0</div>
> <div>&gt;a=qos:mandatory sendrecv</div>
> <div>&gt;m=video 10275 RTP/AVP 31</div>
> <div>&gt;a=qos:optional sendrecv</div>
> <div>&gt;--------------------</div>
> <div>&gt;UAS-&gt;UAC</div>
> <div>&gt;</div>
> <div>&gt;SIP/2.0 200 OK</div>
> <div>&gt;To: Adam Roach &lt;[email-masked]&gt;</div>
> <div>&gt;From: John Q. Public &lt;[email-masked]&gt;</div>
> <div>&gt;CSeq: 2 PRACK</div>
> <div>&gt;Content-Length: 0</div>
> <div>&gt;--------------------</div>
> <div>&gt;Both parties perform resource reservation</div>
> <div>&gt;--------------------</div>
> <div>&gt;UAC-&gt;UAS</div>
> <div>&gt;</div>
> <div>&gt;INFO sip:[email-masked] SIP/2.0</div>
> <div>&gt;To: Adam Roach &lt;[email-masked]&gt;</div>
> <div>&gt;From: John Q. Public &lt;[email-masked]&gt;</div>
> <div>&gt;CSeq: 3 INFO</div>
> <div>&gt;Session: QoS</div>
> <div>&gt;Content-Type: application/sdp</div>
> <div>&gt;</div>
> <div>&gt;v=0</div>
> <div>&gt;m=audio 48327 RTP/AVP 0</div>
> <div>&gt;a=qos:reserved sendrecv</div>
> <div>&gt;m=video 10275 RTP/AVP 31</div>
> <div>&gt;a=qos:resvfail sendrecv</div>
> <div>&gt;--------------------</div>
> <div>&gt;UAS-&gt;UAC</div>
> <div>&gt;</div>
> <div>&gt;SIP/2.0 200 OK</div>
> <div>&gt;To: Adam Roach &lt;[email-masked]&gt;</div>
> <div>&gt;From: John Q. Public &lt;[email-masked]&gt;</div>
> <div>&gt;CSeq: 3 INFO</div>
> <div>&gt;Content-Type: application/sdp</div>
> <div>&gt;</div>
> <div>&gt;v=0</div>
> <div>&gt;m=audio 48327 RTP/AVP 0</div>
> <div>&gt;a=qos:reserved sendrecv</div>
> <div>&gt;m=video 10275 RTP/AVP 31</div>
> <div>&gt;a=qos:resvfail sendrecv</div>
> <div>&gt;--------------------</div>
> <div>&gt;The called party cancels the videostream reservation</div>
> <div>&gt;and begins alerting the called party.</div>
> <div>&gt;--------------------</div>
> <div>&gt;UAS-&gt;UAC</div>
> <div>&gt;</div>
> <div>&gt;SIP/2.0 180 Ringing</div>
> <div>&gt;To: Adam Roach &lt;[email-masked]&gt;</div>
> <div>&gt;From: John Q. Public &lt;[email-masked]&gt;</div>
> <div>&gt;CSeq: 1 INVITE</div>
> <div>&gt;Content-Length: 0</div>
> <div>&gt;--------------------</div>
> <div>&gt;</div>
> <div>&gt;-- </div>
> <div>&gt;Adam Roach, Ericsson Inc. |&nbsp; Ph: +1 972 583 7594 | 1010 E.
> Arapaho, MS L-04</div>
> <div>&gt;[email-masked]&nbsp;&nbsp; | Fax: +1 972 669 0154 |
> Richardson, TX 75081 USA</div>
> <div>&gt;</div>
> <div>&gt;</div>
> <br>
> 
> <div align="center">
> *************************************<br>
> &quot;At the end of the day... the most committed win!&quot;<br>
> <br>
> </div>
> James M. Polk<br>
> Sr. Product Manager, Multiservice Architecture and Standards<br>
> Enterprise Voice Business Unit<br>
> Cisco Systems<br>
> Dallas, Texas<br>
> w) 972.813.5208<br>
> f)&nbsp; 972.813.5280<br>
> <a href="http://www.cisco.com/" eudora="autourl">www.cisco.com</a></html>
> 
> --=====================_2567198==_.ALT--
> 
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Feb 2000 07:57:49 -0800 (PST)

> RSVP for a successful SIP connection would be an unfortunate dependency.

I think that this is somewhat speculative at this
point because backbone providers up until recently
haven't had a business case to provide
differential treatment of EF traffic, say, through
their network. If there's a business case for RSVP
and a solution that will scale to their network,
I'm sure there will be providers who offer it.

But I'm not even sure that it is the case that the
backbone provider even needs to participate in
RSVP in the "normal" case (other than carrying the
datagram over their network). Suppose we have the
following network:

UAC->[cloud]->Border<==>Border->[BB cloud]->Border<==>Border->[cloud]->UAC

Further, suppose that there is a SLA across the
backbone cloud which gives 20% EF traffic
guarantees. In this case, the backbone provider's
border router (or any for that matter) does not
need to participate in RSVP because the border
router at the access network will do the flow
admission control at its backbone border router.
The BB router's job is to traffic shape the SLA,
but it needs to do that anyway. The access
network's border router needs to make certain that
the admission control operation takes into account
the SLA with the backbone operator, which it needs
to do anyway as well.

It's even better with aggregated RSVP since it
allows multiple levels of aggregation: between the
access router and the border router, flows could
be aggregated to relieve the micro flow load at
the border router. Since aggregated RSVP "tunnels"
the "end to end" RSVP requests to the next
aggregation point, we can use the same technique
to tunnel the RSVP request across the backbone so
that it doesn't matter whether the BB provider
does or does not allow/act on RSVP in their
network -- it will be transparent to them (and in
fact, the RSVP requests should use integrity
objects to disallow unauthorized use).

I believe this extends to the general case where
you have more than one BB provider too: so long as
the intermediate providers honor the SLA that the
initial BB provider sold to the access provider,
all is well. There doesn't need to be any
admission control in center because the admission
control was done at the choke point. I believe
this also extends to non-static SLA's as well if
we want to use RSVP in the core: with the use of
RSVP and COPS at the access provider's border,
large(r) pipes can be created which so long as
they can be billed correctly would provide a
dynamic SLA capability too which doesn't even
exist today that I'm aware of.

All in all, RSVP+Policy+Aggregation gives a lot of
flexibility.

		Mike