Subject: RE: PWE3 new WG items?

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 19 Feb 2004 11:41:20 -0800 (PST)

Hi Yongxin,

On Wed, 18 Feb 2004, Cui, Yongxin (Yongxin) wrote:

> Rahul,
>
> If the PW has the QoS requirement and needs to reserve resources inside
the PSN tunnel, can LDP help? In particular, when the PW is carrying ATM
traffic, how does the LDP with CR work?
>
> For example, I have a PSN tunnel with 10Mbps bandwidth configured.
Inside the tunnel, I have two PWs, each booking 2Mbps bandwidth.

It is possible to CAC the PW into the transport LSP. This is done at the
PEs and doesn't necessarily require PW QoS to be signaled. RSVP-TE is
being proposed as a means to signal the PW and the PW QoS when there is a
need to signal the PW QoS. LDP doesn't carry QoS information and CR-LDP
has been deprecated by the MPLS WG.

rahul

> Thanks,
>
> Yongxin
>
>
>
> -----Original Message-----
> From: Rahul Aggarwal [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 10:42 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [PWE3] PWE3 new WG items?
>
>
> Hi Ben,
>
> [snip]
>
> >
> > Therefore IMO the signalling of PW QoS has one of two solutions:
> >
> > 1) Add PW signalling to CR-LDP (although this would be the easiest
> > solution,
> CR-LDP has been deprecated).
>
> >
> > 2) Add PW signalling to RSVP-TE.
> >
>
> For the purpose of PW QoS, this is reasonable. Note that the MPLS WG has 2 defined mechanisms for transport LSP setup:
>   - LDP
>   - RSVP-TE
>
> Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the other hand is deemed easier to configure and manage when TE is not a requirement.
>
> There is no reason why PWE setup cannot follow a similar model:
>   - LDP for PW signaling without QoS
>   - RSVP-TE for PW signaling with QoS
>
> rahul
>
>
> > Neither of which require PW specific QoS signalling mechanism because
> > adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or
> > RSVP-TE) is not necessary IMO and would only lead to increased complexity/opex.
> >
> >
> > Ben
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Ping Pan <[email-masked]>
Date: Thu, 19 Feb 2004 11:56:19 -0800

Rahul,

This is what I have in mind for adding QoS during PW establishment phase:

                                 PW12           (PW12+PW32)
                                  |                  |
                                  |                  |
                   +-----+       \|/     +-----+     |
     +-----+       |     |---------------|     |    \|/   +-----+
     | CE1 |=======| PE1 |...............| PE2 |==========| CE2 |
     +-----+       |     |---------------|     |          +-----+
                   +-----+               +-----+
                                 PW32     | . |
                                  |       | . |
                                  |       | . |
                   +-----+       \|/      | . |
     +-----+       |     |----------------+ . |
     | CE3 |=======| PE3 |................... |
     +-----+       |     |--------------------+
                   +-----+

Both CE1 and CE3 communicate with CE2. A pseudo-wire, PW12, is 
established between PE1 and PE2 to transfer traffic between CE1 and CE2. 
Similarly, PW32 is to carry traffic between CE3 and CE2.

Note that the tunnels between PE's may be RSVP-TE-enabled with QoS etc. 
  To guarantee any service between two CE's, the access links between CE 
and PE have to have enough network resources to accommodate the "sum" of 
all pseudo-wire traffic going to a specific CE.  In the example, the 
link between PE2 and CE2 must be able to support the traffic from both 
PW12 and PW32.

As far as I know, there is no mechanism available today to convey 
pseudo-wire resource usage information between PE's. User packets may 
get dropped as a result.

Does it make sense now? :-)

Regards,

- Ping

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 19 Feb 2004 18:00:09 -0800 (PST)

Hi Ping,

> This is what I have in mind for adding QoS during PW establishment phase:

I think there is agreement that signaling PW QoS is useful and you
have given one example above. What I was saying was that RSVP-TE
for PW signaling with QoS information is one means of solving this
problem.

Thanks,
rahul

---

From: Ping Pan <[email-masked]>
Date: Thu, 19 Feb 2004 21:11:40 -0500 (EST)

> for PW signaling with QoS information is one means of solving this

Yeap! There are more ways than one to skin a cat.

Take care!

- Ping