Subject: Re: [Tsvwg] RSVP proxy approaches

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 19 Jun 2007 17:21:49 +0200

Chris and all,

I'm started editing rsvp-proxy-approaches to reflect all discussed  
changes.

Regarding the input below, I would propose that we incorporate it as  
a new section under Appendix A (eg "A.5 RSVP-based Voice/Video CAC in  
IPsec environments"). This seems reasonable since:
	* Appendix A is dedicated to describing use cases for the RSVP Proxy  
approaches described in the main sections of the I-D .
	* the fundamental approach used in this scenario is already  
described in the main sections of the I-D. The text below focuses on  
some details specific to when the approach is used in the presence of  
IPsec.

Does that work?

Thanks

Francois

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

> 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: "Christou, Christos" <[email-masked]>
Date: Tue, 19 Jun 2007 14:40:04 -0400

Francois,
 
Yes, I do think this works.
 
Thanks,
 
Chris

________________________________

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2007 11:22 AM
To: Christou, Christos
Cc: Francois Le Faucheur IMAP; [email-masked]
Subject: Re: [Tsvwg] RSVP proxy approaches

Chris and all, 

Regarding the input below, I would propose that we incorporate it as a
new section under Appendix A (eg "A.5 RSVP-based Voice/Video CAC in
IPsec environments"). This seems reasonable since:
* Appendix A is dedicated to describing use cases for the RSVP Proxy
approaches described in the main sections of the I-D .
* the fundamental approach used in this scenario is already described in
the main sections of the I-D. The text below focuses on some details
specific to when the approach is used in the presence of IPsec. 

Does that work?

Thanks

Francois

	
	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  |

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

	 

	 

	|---|

	|---|

	***

	*r*   Regular RSVP router

	***

	<***> media flow

	 

	/ \   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