Subject: RSVP on IP Phones

From: Dusan Sarvan <[email-masked]>
Date: Wed, 03 May 2000 12:27:41 +0200

Hi,

I will be really appreciated if someone can answer my
questions:

1. Since RSVP is pretty complex technology, implementing
RSVP on the end

devices such as an IP Phone makes this device pretty
complex and probably expensive.

Could you tell me please if RSVP is  in implementation
on IP phones and is it

implemented by some companies on IP phones?

2. Is it feasible some centralized device such as a Call
Manager to play RSVP on a behalf

of IP phones?

Thanks a lot in advance.

---

From: David Charlap <[email-masked]>
Date: Wed, 03 May 2000 10:32:57 -0400

Dusan Sarvan wrote:
> 
> I will be really appreciated if someone can answer my questions:
> 
> 1. Since RSVP is pretty complex technology, implementing RSVP on the
>    end devices such as an IP Phone makes this device pretty complex
>    and probably expensive.

IMO, RSVP on the end devices is much simpler to implement than on
transit routers.  Most of the complexities (like reservation merging,
and managing reservations from multiple sessions) don't apply to an end
device that will be acting as one sender and one recipient and will
probably not have any other RSVP-controlled data flows.

> Could you tell me please if RSVP is  in implementation on IP phones
> and is it implemented by some companies on IP phones?

I don'w know about this.

> 2. Is it feasible some centralized device such as a Call Manager to
> play RSVP on a behalf of IP phones?

It's certainly possible, but note:

- This call manager needs to know the QoS that the phone will use.  If
  it's not hard-coded then the phone needs to signal it.  If not using
  RSVP, then with something proprietary.  This signalling message will
  have to contain much of the same data that RSVP conveys, so you may
  not be saving very much.

- If the call manager has the QoS and other per-call parameters hard-
  coded (or possibly configured locally), then the connection to the
  phone becomes simpler, but it increases administrative overhead for
  the user - who now has to configure both the phone and the call
  manager.

- This call manager can't control QoS on the last-hop from itself to
  the phone.  Depending on the hardware, this may or may not be a
  problem.

-- David

---

From: Christian Kuhtz <[email-masked]>
Date: Wed, 03 May 2000 10:24:56 -0400

At 12:27 PM 5/3/00 +0200, Dusan Sarvan wrote:
>1. Since RSVP is pretty complex technology, implementing RSVP on the end
>devices such as an IP Phone makes this device pretty complex and probably 
>expensive.
>Could you tell me please if RSVP is  in implementation on IP phones and is it

I'm not aware of any.  Given the abundance of CPU horsepower (not counting 
DSP resources) in some of these devices, I don't necessarily see this the 
limitation at this point.

And you can source an IP stack capabable of supporting RSVP from various 
places.

>2. Is it feasible some centralized device such as a Call Manager to play 
>RSVP on a behalf
>of IP phones?

That could indeed be done.

However, the more important question is.. how is the network designed in 
which you plan to deploy this.  In my experience, while RSVP often times 
looks like a "clean approach" from an academic traffic mgmt approach, but 
operationally you got a whole 'nother set of headaches and there are other 
more practical ways of approaching this subject.

In scenarios where IP phones are generally stationary, you can "get away" 
with aggregate "reservations" for bandwidth.  The reasoning is like many 
other scenarios where you have to make a call as to whether you want to go 
with a dynamic or static mechanism.  While dynamic looks "cleaner", 
sometimes it buys you squat and makes it more difficult than it needs to 
be.  So, whether traffic mgmt task be accomplished by RSVP or some other 
means is another question.

I have yet to run into a case where I could justify introducing the 
complexity of RSVP, and its potential strain on resources in a service 
provider network.  RSVP on an extremely limited basis in an enterprise 
network has proven useful, although generally there too there are more cost 
effective approaches when you look at the big picture.

Cheers,
Chris

--
Christian Kuhtz                                     Architecture, BellSouth.net
<[email-masked]> -wk, <[email-masked]> -hm                       Atlanta, GA
                                                     "Speaking for myself 
only."

---

From: Duncan Thomson <[email-masked]>
Date: Wed, 03 May 2000 11:58:59 -0400

Dusan Sarvan wrote:

> 2. Is it feasible some centralized device such as a Call Manager to play RSVP on a behalf
> of IP phones?

No, not really.  If the device is centralized then there really is no way for it
to signal to the routers that are in the path between the phones to set up RSVP
for the phones.

Duncan Thomson

---

From: "Christian Kuhtz" <[email-masked]>
Date: Wed, 3 May 2000 15:41:41 -0400

> to signal to the routers that are in the path between the phones to

I think there's another conceivable variant in which RSVP might play in this
picture.

Often times, when deploy call mgrs, you usually don't deploy just one.  The
inter-call mangler communication is something you could reserve with RSVP if
you have a jungle of other devices out there.

Given that call mgrs are generally in close proximity to the phones they serve,
and call mgrs are usually a little further apart than the to the phones they
each serve, you may have more resource contention across such likely "backbone"
paths than from the phone to the call mgr.

Again, highly architecture dependant and one needs to know a lot more about the
big picture to be able to answer the original question appropriately.  There's
no general yes or no, although the general caveats for RSVP always apply.

Cheers,
Chris

--
Christian Kuhtz, Sr. Network Architect              Architecture, BellSouth.net
<[email-masked]> -wk, <[email-masked]> -hm                       Atlanta, GA
                                                    "Speaking for myself only."