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

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Mar 2005 14:25:03 -0500

Hi Himanshu,

I believe this is the second time that we disagree about the meaning of the word opaque. I thought that you meant that the intermediate nodes that process the LDP messages (i.e. the S-PEs) would not inspect and act upon the content of the QoS field. Apparently, that was not what you meant.

Thanks for your clarification.

Peter

> -----Original Message-----
> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Thursday, March 24, 2005 2:19 PM
> To: Busschbach, Peter B (Peter); [email-masked]; Nurit Sprecher
> Cc: pwe3; Stewart Bryant
> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt 
> 
> 
> 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
> > 
>