Subject: RE: draft-raggarwa-rsvpte-pw-01.txt

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Mar 2005 13:17:50 -0500

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, March 24, 2005 10:54 AM
> To: Nurit Sprecher
> Cc: pwe3; Stewart Bryant
> Subject: Re: [PWE3] draft-raggarwa-rsvpte-pw-01.txt 
> 
> 
> 
> Nurit> The  existing  two  protocols  ...  can  not  signal  
> explicit  route
> Nurit> information,    not   QoS   parameters,    not   
> Diffserv/Diffserv-TE
> Nurit> information, not traffic priorities, not requirements 
> for resiliency,
> Nurit> not  resource  classes,  no   crouchback  information, 
>  etc.  The  TE
> Nurit> information  must  be signaled  to  allow  the  S-PEs 
> to  select  the
> Nurit> appropriate Tunnel for the PWs. 
> 
> Nurit, first I  would like to thank you for making  a 
> technical argument. It
> almost seems out of place in this thread ;-(
> 
> If the only reason  for the PW setup protocol to signal  TE 
> parameters is so
> that  those  parameters  can  be  used to  select  the  
> appropriate  traffic
> engineered tunnel, then a very straightforward solution would be to: 
> 
> - use RSVP-TE to set up the tunnels
> 
> - add a TE parameter to LDP/L2TPv3. 
> 
> It doesn't seem to call for a new PW setup protocol.  
> 
> I am  still not seeing  that applying  TE to the  PWs is 
> anything  more than
> applying TE to the PSN tunnels.   True, a PW switching point 
> needs to choose
> the right  sort of tunnel, but today  PW endpoints need to  
> choose the right
> sort of tunnel, and making that choice is not really a 
> protocol issue. 
> 
> Someone mentioned CAC support as being a reason for requiring 
> a new PW setup
> protocol.  I  didn't quite follow that, because  it seems to 
> me  that PW CAC
> should be applied only  at the PW ingress.  Once data is  put 
> into the PW, I
> can see that the  PSN tunnels may need to apply CAC,  but 
> "admission" to the
> PW is already done. 
> 
> I have  the same  issue with regard  to QoS; it  seems to  me 
> that QoS  is a
> property of the PSN tunnels, not of the PW itself. 

There are various aspects to QoS and depending on the overall implementation some aspects may be more relevant than others.

The ultimate goal of QoS is to provide performance guarantees to end-user applications. In that sense, QoS applies to PWs.

To provide those performance guarantees, the operator needs to ensure that in some way the network meets certain requirements. In packet switched networks that means that the aggregation of multiple traffic flows should not affect the throughput and delay that is promised to a specific flow (I use the word "flow" loosely to denote some traffic aggregate). Fundamentally, there are two ways to do that:

a) Avoid congestion. This could require rate limiting at the edge of the network, but it would not require any additional QoS support in terms of classification/buffering/scheduling in the core of the network.

b) Through provisioning or signaling, make switches aware of a specific flow that requires QoS guarantees. In such a case, switches must be able to classify traffic so that they can distinguish the specific flow from the rest of the traffic. Through appropriate buffering and scheduling settings, switches would meet the QoS requirements of a specific flow. 

In case a) there are several ways to determine that there will be no congestion in the network. E.g.

1) An operator could use off-line tools

2) An edge node could use its knowledge of available bandwidth throughout the network to determine an explicit route that avoids congestion points

3) Through a signaling protocol, switches are made aware of new flows that require QoS. Each switch checks if there congestion could occur. If a switch determines there is sufficient margin to avoid congestion, it accepts the new flow. If not, it rejects it. Obviously, such a solution would require some form a crank-back in the signaling protocol, since otherwise flows might be needlessly rejected.

The distinction between a) and b) may seem over-simplistic. If so, it is because there is a recursiveness that complicates the issue. It is this recursiveness that is fundamental to the QoS discussion around PWs.

An example of recursiveness is VoIP. An operator could deploy DiffServ and allocate the EF class to VoIP traffic. The operator would reserve bandwidth for EF in each switch of the network. This is an example of mechanism b). However, for individual VoIP calls, an off-line tool could be used to determine if there is sufficient residual bandwidth *within* the EF class to terminate a new call. This would be an example of a1).

In the case of MS-PWs, there is a similar recursiveness. PW segments run over PSN tunnels. Assuming that QoS guarantees are given to these PSN tunnels, we still need to consider the various options for guaranteeing QoS for PWs within those PSN tunnels.

Option a) would assume that somehow it can be determined that the PSN tunnels are big enough to support a new PW. This could be through off-line tools (option a1) or through some form of CAC in the network. If the edge node has sufficient information regarding the end-to-end topology and available bandiwdth per PSN tunnel, CAC could take place at the edge. Intermediate nodes (S-PEs) would not have to consider QoS at all and therefore any QoS parameters carried in a MS-PW signalling protocol would be opaque to S-PEs (option a2). Alternatively, the knowledge about available bandwidth could be distributed throughout the network. In that case, S-PEs would need to consider the QoS parameters contained in MS-PW signaling messages to determine whether they can accept the new PW or not. If not, the signaling protocol must support crankback (option a3).

Option b) when applied to PWs means that S-PEs manage individual PWs. They must be configured (manually or through a signaling protocol) to recognize individual PWs and through buffering and scheduling settings assure that the QoS requirements for each PW are met.

Eric R. and Chris L. have indicates a preference for option a): do traffic engineering on PSN tunnels so that there is no need for QoS management of individual PWs. That may be the right approach, but it would be good to further examine which of the options 1), 2) or 3) would be most likely to be used.

Personally, I believe RSVP-TE is an appropriate choice for MH-PWs because it inherently supports all options mentioned above. LDP would require extensions and depending on the option chosen, these extensions might be more or less substantial. Himanshu stated (in bold letters) that QoS parameters are opaque. Well, they would be in options a1 and a2, but not in options a3 and b. 

That's all, for now.

Peter

> 
> You may wish to elaborate on the resiliency and crankback 
> requirements. 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>