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

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 24 Mar 2005 14:18:30 -0500

Hi Peter,

You mis-understand my use of word OPAQUE.
I used the word OPAQUE to mean that underlying
LDP protocol does nothing with those parameter.
It simply passes on to the PW management entity
at the receiver (i.e. S-PEs in this example).
It is the PW managment entity that is doing the 
CAC (i.e. selecting the right TE Tunnel, etc at
each S-PE).
It is opaque to the LDP 'protocol' and requires 
no changes to how DU LM message is used and 
processed.

Note that I already mentioned that today's PW
mgmt entity already do CAC today for transport
TE tunnels for SS-PW.

regards,
himanshu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Busschbach, Peter B (Peter)
> Sent: Thursday, March 24, 2005 1:18 PM
> To: [email-masked]'; Nurit Sprecher
> Cc: pwe3; Stewart Bryant
> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt 
> 
> 
> 
> 
> > -----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
> > 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>