RE: QoS considerations

[Black_David@emc.com]

>   My concern with using RFC2983 when it comes to typical VPN and
end-to-end
> deployments is that I'm really not clear what a host/gateway is supposed
to
> do to signal the desired QoS. Specifically, when the boxes are customer
> located rather than located at the ISP (a la PPVPN).
> 
>   My understand of DiffServ is that DSCPs are really enterprise specific.
> So, there really isn't anything I can put in my packets to get the
resulting
> PHB that I want. My opinion is that the only useful model is therefore
> RFC2998.
> 
>   This essentially says to use RSVP to signal the QoS for the resulting 
> ESP packets that are generated. This signal travels to the first edge
routing 
> of the diffserv cloud [called the "diffedge" device in 2998] (and I would
> imagine no further), causing the edge router of the ISP to enact some
> admission control based upon (dest, proto, SPI#) [see RFC2207]. 
>   The packet is then admited to the proper diffserv queue and has the
> appropriate DSCP stamped on it.

This causes the ISP's edge router to have to classify traffic based on SPI#.
That's an example of microflow classification, and a rather unusual one.
An alternative model would be to apply the DSCPs that the ISP is expecting
at the customer's VPN gateway that is facing the ISP; the ISP then
classifies traffic based on DSCP and conducts admission control on the
basis of that classification.

Both solutions require the signaling to pass from the VPN gateway to the
ISP, and are subject to failure if it doesn't (e.g., something in between
discards RSVP traffic or decides to rewrite the DSCPs because it can).

If IPsec is running end-to-end, so the IPsec implementations are on
hosts attached to a customer network rather than on an ISP-facing
VPN gateway, things get more complicated, and RFC 2998 is certainly
one approach to a solution.  Another is to use whatever's appropriate
for the customer network and have an ISP-facing device reclassify the
traffic and apply the DSCPs as appropriate for the customer's policy for
usage of the ISP.  This can be made to work even if the customer network
is based on IP precedence, as there are multiple possible DSCPs for
each IP Precedence level - these would have meaning for the ISP-facing
traffic reclassifier even if the customer's routers ignored them -
see Section 4.2 of RFC 2474 for more details.

>   One concern is when/if we define an attribute to describe the desired
QoS
> on the SA bundle-pair being created is that the two ends may in fact have
to
> use different (locally configured) mechanisms.

Yes ... and you thought security policy was complicated ;-).

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------