On 19 Jun 2007, at 20:40, Christou, Christos wrote:
Francois,
Yes, I do think this works.
Thanks,
Chris
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.
Below is the text I put together for the new Appendix A.5.
I added material to explain how this relates to [I-D.ietf-tsvwg-vpn-signaled-preemption].
If you want to send comments/suggestions by the end of today I could address those before posting.
Francois
A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways
[I-D.ietf-tsvwg-vpn-signaled-preemption] discusses how resource
reservation can be supported end-to-end in a nested VPN environment.
At each VPN level, VPN Routers behave as [RFC4301] security gateways
between a plaintext domain and a cyphertext domain. To achieve end-
to-end resource reservation, the VPN Routers process RSVP signaling
on the plaintext side, perform aggregation of plaintext reservations,
and maintain the corresponding aggregate RSVP reservations on the
cyphertext side. Each aggregate reservation is established on behalf
of multiple encrypted end-to-end sessions sharing the same ingress
and egress VPN Routers. These aggregate reservations can be as
specified in [RFC3175] or [RFC4860].
Section 3 of [I-D.ietf-tsvwg-vpn-signaled-preemption] discusses the
necessary data flows within a VPN Router to achieve the behavior
described in the previous paragraph. Two mechanisms are described to
achieve such data flows. Section 3.1 presents the case where the VPN
Router carries data across the cryptographic boundary. Section 3.2
discusses the case where the VPN router uses a Network-Guard.
Where such mechanisms are not supported by the VPN Routers, the
approach for end-to-end reservation presented in
[I-D.ietf-tsvwg-vpn-signaled-preemption] cannot be deployed. An
alternative approach to support resource reservations within the
cyphertext core is to use the "Application_Entity-Controlled Proxy"
approach (as defined in Section 4.5) in the following way:
o the RSVP Proxies are located inside the cyphertext domain and use
aggregate RSVP reservations,
o the Application Entity exchange application level signaling with
the end systems in the plaintext domain,
o the Application Entity controls the RSVP Proxies in the cyphertext
domain via an RSVP Proxy control interface
This is illustrated in Figure 17 in the case where the application is
SIP-based multimedia communications.
|-------| |-------|
|SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP |
/|Server/| |Server/|\
/ |Proxy | |Proxy | \
/ |-------| |-------| \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
|---| |------| |--------| *** *** |--------| |------| |---|
| S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R |
|---| | GW | | Sender | *** *** |Receiver| | GW | |---|
|------| | Proxy | | Proxy | |------|
|--------| |--------|
***PT*****> **********************CT****************> ****PT***>
=====> =====>
=====ARSVP======>
|----| RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|------|
|IPsec | IPsec gateway
| GW |
|------|
ARSVP Aggregate RSVP
***> media flow
==> segment of flow path protected by RSVP reservation
/ \ SIP signaling
^ Network management interface between SIP Server/Proxy
and IPsec device
// control interface between SIP Server/Proxy and ARSVP Proxy
PT Plaintext network
CT Cyphertext network
Figure 17: RSVP Proxies for Reservations in the Presence of IPsec
Gateways
Where the sender and receiver are RSVP capable, they may also use
RSVP signaling. This achieves resource reservation on the plaintext
segments of the end-to-end i.e. :
o from the sender to the ingress IPsec gateway and
o from the egress IPsec gateway to the receiver.
In this use case, because the VPN Routers do not support any RSVP
specific mechanism, the end-to-end RSVP signaling is effectively
hidden by the IPsec gateways on the cyphertext segment of the end-to-
end path.
As with the "Application_Entity-Controlled Proxy" approach (defined
in Section 4.5), the solution here for synchronizing RSVP signaling
with application-level signaling is to rely on an application-level
signaling device that controls an on-path RSVP Proxy function.
However, in the present use case, the RSVP Proxies are a component of
a cyphertext network where all user (bearer) traffic is IPsec
encrypted. This has a number of implications including the
following:
1. encrypted flows can not be identified in the cyphertext domain so
that network nodes can only classify traffic based on IP address
and DiffServ Code Points (DSCPs). As a result, only aggregate
RSVP reservations (such as those specified in [RFC3175] or
[RFC4860] ) can be used. This is similar to
[I-D.ietf-tsvwg-vpn-signaled-preemption].
2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be
used for aggregation of a given flow from sender to receiver
creates a number of challenges. Details on how this may be
achieved are beyond the scope of this document. We observe that,
as illustrated in Figure 17, this may be facilitated by a network
management interface between the application entity and the IPsec
gateways. For example, this interface may be used by the
application entity to obtain information about which IPsec
gateway is on the path of a given end-to-end flow. Then, the
application entity may maintain awareness of which RSVP Proxy is
on the cyphertext path between a given pair of IPsec gateways.
How such awareness is achieved is beyond the scope of this
document. We simply observe that such awareness can be easily
achieved through simple configuration in the particular case
where a single (physical or logical) Proxy device is fronting a
given IPsec gateway. We also observe that when awareness of the
RSVP Receiver Proxy for a particular egress IPsec gateway (or
end-to-end flow) is not available, the aggregate reservation may
be signaled by the RSVP Sender Proxy to the destination address
of the egress IPsec gateway and then proxied by the RSVP Receiver
Proxy.
Different flavors of operations are possible in terms of aggregate
reservation sizing. For example, the application entity can initiate
an aggregate reservation of fixed size a priori and then simply keep
count of the bandwidth used by sessions and reject sessions that
would result in excess usage of an aggregate reservation. The
application entity could also re-size the aggregate reservations on a
session by session basis. Alternatively, the application entity
could re-size the aggregate reservations in step increments typically
corresponding to the bandwidth requirement of multiple sessions.
RSS Feed