Subject: [Tsvwg] RSVP proxy approaches

From: "Christou, Christos" <[email-masked]>
Date: Thu, 22 Mar 2007 19:41:49 -0400

All,
 
As Francois stated during the TSVWG meeting, below are inputs into the RSVP Proxy Approach draft.  

------------------------

This option is very similar to the "Application-Signaling-Triggered On-Path Proxy" approach mentioned in section 4.5.  As with that approach, the solution for synchronising RSVP signaling with application-level signaling is to rely on an application-level signaling device which controls an on-path RSVP Proxy function.  However, in this approach, the RSVP proxy device is a component of a Cipher Text network where all user (bearer) traffic is IPsec encrypted. Network nodes within the CT core can only classify traffic based on IP address and DiffServ Code Points (DSCPs).  As a result, only RSVP reservations based on "Generic Aggregate RSVP Reservations" can be used since it will allow resources to be reserved across a CT-based DiffServ network.  

There are a few important considerations for this solution due to the use of an ARSVP proxy within a CT core:

1) To understand which source/sender ARSVP proxy should initiate the reservation, the SIP server will need to be configured with the CT-side ARSVP proxy device that is fronting the source IPsec device.  To reduce complexity, only one ARSVP proxy node should be associated with any given IPsec device. 

2) To discover the address of the destination ARSVP proxy, the SIP server will need to maintain a network management interface to either the source IPsec device or a server managing that IPsec device.  Assuming a scenario where only one IPsec device is fronting an edge network, the SIP server will need to receive information from the source IPsec device regarding the destination IPsec device for the flow that the SIP session is signaling.

3) Once the SIP Server understands the source ARSVP proxy and the destination CT IPsec device address for a given call or calls, it will configure the source ARSVP proxy to initiate a reservation.  Since the originating SIP server will only have knowledge of the destination IPsec device address, it cannot configure the ARSVP reservation with the destination ARSVP proxy address.  Therefore, the destination ARSVP proxy will need to be configured to respond to the ARSVP signaling that is destined for the IPsec device's IP address.   

Due to the ability to reserve resources for aggregate flows, different configuration options are available.  For example, the SIP server can initiate an aggregate reservations a priori, keep count of the calls, and re-size the reservation if additional calls that are categorized using the same DSCP.  Alternatively, the reservation can be re-sized on a call by call basis.

                         |-------|             |-------|               

         ////////////////|SIP    |///////\\\\\\|SIP    |\\\\\\\\\\\\\\\             

        /              ^ |Server/|             |Server/| ^             \

       /              ^  |Proxy  |             |Proxy  |  ^             \           

      /              ^       ||                   ||       ^             \

     /              ^        ||                   ||        ^             \

   |---|    |------|    |---------|    ***    |---------|    |------|    |---|

   | E |----|IPSec |----|  ARSVP  |----*r*----|  ARSVP  |----|IPSec |----| E |

   |---|    |Device|    |  Proxy  |    ***    |  Proxy  |    |Device|    |---|

            |------|    |    +    |           |    +    |    |------|

                        | On Path |           | On Path |

                        | Entity  |           | Entity  |

                        |---------|           |---------|

     <*** PT ***><********************* CT *********************><*** PT ***>

                           <===========RSVP===========>

|---|

| E | End system (sender, or receiver, or both)

|---|

***

*r*   Regular RSVP router

***

<***> media flow

<==>  segment of flow path protected by RSVP reservation

/ \   SIP signaling

 ^    Network management interface between Application Level Signaling 

      device and IPSec device

||    control interface between Application Level Signaling device and ARSVP Proxy

PT    Plaintext Network

CT    Cyphertext Network

---

From: ken carlberg <[email-masked]>
Date: Fri, 23 Mar 2007 07:52:33 +0100

My apologies if I stick my foot in my mouth -- I haven't read the  
draft, yet -- but in reading the description below, some questions  
and assumptions pop up.  First, I assume that your design as a whole  
relies on (or limited to, depending on the point of view) statefull  
SIP proxies/servers.  Correct?

And along those lines, do you rely on softstate refresh in the  
message exchange between SIP Proxy<-->ARSVP proxy.  I ask out of a  
concern of what happens if either SIP proxy crashes or is partitioned  
away from the UA -- do we end up with indefinitely pinned RSVP  
reservations?

Also, do SIP server farms become problematic needs to be "configured  
with the CT-side ARSVP proxy device"?  Or is that configuration  
accomplished in some fashion through the SIP message exchange(s)?

-ken

On Mar 23, 2007, at 12:41 AM, Christou, Christos wrote:

> This option is very similar to the "Application-Signaling-Triggered  
> On-Path Proxy" approach mentioned in section 4.5.  As with that  
> approach, the solution for synchronising RSVP signaling with  
> application-level signaling is to rely on an application-level  
> signaling device which controls an on-path RSVP Proxy function.   
> However, in this approach, the RSVP proxy device is a component of  
> a Cipher Text network where all user (bearer) traffic is IPsec  
> encrypted. Network nodes within the CT core can only classify  
> traffic based on IP address and DiffServ Code Points (DSCPs).  As a  
> result, only RSVP reservations based on "Generic Aggregate RSVP  
> Reservations" can be used since it will allow resources to be  
> reserved across a CT-based DiffServ network.
>
>
> There are a few important considerations for this solution due to  
> the use of an ARSVP proxy within a CT core:
>
>
> 1) To understand which source/sender ARSVP proxy should initiate  
> the reservation, the SIP server will need to be configured with the  
> CT-side ARSVP proxy device that is fronting the source IPsec  
> device.  To reduce complexity, only one ARSVP proxy node should be  
> associated with any given IPsec device.
>
>
> 2) To discover the address of the destination ARSVP proxy, the SIP  
> server will need to maintain a network management interface to  
> either the source IPsec device or a server managing that IPsec  
> device.  Assuming a scenario where only one IPsec device is  
> fronting an edge network, the SIP server will need to receive  
> information from the source IPsec device regarding the destination  
> IPsec device for the flow that the SIP session is signaling.
>
>
> 3) Once the SIP Server understands the source ARSVP proxy and the  
> destination CT IPsec device address for a given call or calls, it  
> will configure the source ARSVP proxy to initiate a reservation.   
> Since the originating SIP server will only have knowledge of the  
> destination IPsec device address, it cannot configure the ARSVP  
> reservation with the destination ARSVP proxy address.  Therefore,  
> the destination ARSVP proxy will need to be configured to respond  
> to the ARSVP signaling that is destined for the IPsec device’s IP  
> address.
>
> Due to the ability to reserve resources for aggregate flows,  
> different configuration options are available.  For example, the  
> SIP server can initiate an aggregate reservations a priori, keep  
> count of the calls, and re-size the reservation if additional calls  
> that are categorized using the same DSCP.  Alternatively, the  
> reservation can be re-sized on a call by call basis.
>
>
>                          |-------|             |-------|
>
>        /              ^  |Proxy  |             |Proxy  |   
> ^             \
>       /              ^       ||                   ||        
> ^             \
>      /              ^        ||                   ||         
> ^             \

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 23 Mar 2007 09:58:03 +0100

Chris and all,

I agree it is a good idea to include discussions in <rsvp-proxy- 
approaches> about the impact of using IPsec in the relevant scenarios.

A comment below:

On 23 Mar 2007, at 00:41, Christou, Christos wrote:

> On-Path Proxy" approach mentioned in section 4.5.
Yes.
It occurred to me that this may also be applicable to the  
"application-signaling-triggered Off-Path Proxy" discussed in section  
4.6.

The picture would look very similar to the picture you proposed  
below; the only difference is that the "protocol" used between the  
SIP-Proxy and the RSVP Proxy is now "RSVP over GRE" (as discussed in  
section 4.6).

Do you agree?

I'll provide detailed comments on the text below later.

Thanks

Francois

> As with that approach, the solution for synchronising RSVP  
> signaling with application-level signaling is to rely on an  
> application-level signaling device which controls an on-path RSVP  
> Proxy function.  However, in this approach, the RSVP proxy device  
> is a component of a Cipher Text network where all user (bearer)  
> traffic is IPsec encrypted. Network nodes within the CT core can  
> only classify traffic based on IP address and DiffServ Code Points  
> (DSCPs).  As a result, only RSVP reservations based on "Generic  
> Aggregate RSVP Reservations" can be used since it will allow  
> resources to be reserved across a CT-based DiffServ network.
>
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 23 Mar 2007 10:04:07 +0100

Hi Ken,

On 23 Mar 2007, at 07:52, ken carlberg wrote:

> and assumptions pop up.  First, I assume that your design as a  
> whole relies on (or limited to, depending on the point of view)  
> statefull SIP proxies/servers.  Correct?
>
> concern of what happens if either SIP proxy crashes or is  
> partitioned away from the UA -- do we end up with indefinitely  
> pinned RSVP reservations?
>

I believe the "SIP_Proxy <--> ARSVP_Proxy" protocol could be either  
soft-state or hard state. If it is hard state, the crash of the SIP  
Proxy also results in all corresponding reservations being torn down.

Francois

---

From: ken carlberg <[email-masked]>
Date: Fri, 23 Mar 2007 10:54:46 +0100

Francois,

> Proxy also results in all corresponding reservations being torn down.

Sorry if I missed something, but I don't see how.  If the information  
exchange between SIP_Proxy and ARSVP_Proxy is hard state, then  
lacking any requirement of keepalives or refresh messages between the  
two entities (one of which is off path) means that we won't have a  
corresponding teardown or time out of the pinned up RSVP reservation  
by the ARSVP_Proxy without an explicit teardown from the SIP_proxy.   
And if the SIP_proxy crashes, it won't know that it had previous  
state between itself and the ARSVP_proxy to clean up

I just took a *very* quick peek at draft-ietf-tsvwg-rsvp-proxy- 
approaches-00.txt and I didn't see any any mention of refresh/ 
keepalive exchange between the application server/proxy and the RSVP  
proxy.  If I missed something, just point me to the section (or  
another draft) I need to read and I'll be quiet and rescind my  
concern :-)

-ken

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 23 Mar 2007 12:15:44 +0100

Hi Ken,

If you're protecting the hard state protocol over a reliable  
connection, then you don't have to refresh every individual states.  
Loss of the reliable connection (possibly with after attempts to re- 
establish) is used as the trigger to tear down all reservations. Sort  
of like MPLS LDP works over TCP, for example. LDP labels are  
advertised to a peer and they are not refreshed.

I am not saying it has to work that way, just that it can.  <draft- 
proxy-approaches> is not meant to specify which protocol should be  
used there. But perhaps we could use a very brief note summarizing  
that discussion.

Francois

On 23 Mar 2007, at 10:54, ken carlberg wrote:

>>> message exchange between SIP Proxy<-->ARSVP proxy.  I ask out of  
>>> a concern of what happens if either SIP proxy crashes or is  
>> I believe the "SIP_Proxy <--> ARSVP_Proxy" protocol could be  
>> either soft-state or hard state. If it is hard state, the crash of  
>> the SIP Proxy also results in all corresponding reservations being  
>> torn down.
>
> Sorry if I missed something, but I don't see how.  If the  
> information exchange between SIP_Proxy and ARSVP_Proxy is hard  
> state, then lacking any requirement of keepalives or refresh  
> messages between the two entities (one of which is off path) means  
> that we won't have a corresponding teardown or time out of the  
> pinned up RSVP reservation by the ARSVP_Proxy without an explicit  
> teardown from the SIP_proxy.  And if the SIP_proxy crashes, it  
> won't know that it had previous state between itself and the  
> ARSVP_proxy to clean up
>
> keepalive exchange between the application server/proxy and the  
> RSVP proxy.  If I missed something, just point me to the section  
> (or another draft) I need to read and I'll be quiet and rescind my  
> concern :-)
>
> -ken