Subject: Admission Control and Policing in CR-LDP

From: "Santosh Gupta" <[email-masked]>
Date: Sat, 4 Mar 2000 14:36:39 +0530

Hi
    How do I go about doing Admission Control and Policing in CR-LDP ? At present I am following draft-ietf-mpls-ldp-06 and draft-ietf-mpls-cr-ldp-03. Between 2 LERs in different MPLS domains it could be a simple TCP session to exchange labels and forward trafic. But how does one go about negotiating the traffic parameters ( receiving request ) when the traffic is coming from non MPLS domain into an MPLS domain.

Can anyone help me out with some references.
santosh

[email-masked]
http://members.tripod.com/~santoshg

---

From: "Philip Matthews" <[email-masked]>
Date: Mon, 06 Mar 2000 10:17:45 -0500

I understand your question to be:
How do I determine the traffic parameters
to use for my constraint-routed LSP?
(If I understand your question correctly,
then the fact that you are signalling with
CR-LDP is unimportant, the same question comes
up with RSVP)

The answer is typically related to how your box
knows to set up the LSP in the first case.
For example, your box might be configured to
set up an LSP for this non-MPLS traffic.
In this case, the traffic parameters would be
configured too.

Another possibility is that you are mapping
from non-MPLS traffic where your box has an
understanding what the traffic parameters for
that traffic might be. (For example, all the
traffic arrives over a T1 link) In this case, your box
can generate the traffic parameters automatically.

These are just two examples. Many others exist.

Hope this helps.

- Philip Matthews

---

From: "Santosh Gupta" <[email-masked]>
Date: Tue, 7 Mar 2000 18:35:49 +0530

Please see the comments inline.

----- Original Message -----
From: Philip Matthews <[email-masked]>
To: Santosh Gupta <[email-masked]>
Cc: mpls <[email-masked]>
Sent: Monday, March 06, 2000 8:47 PM
Subject: Re: Admission Control and Policing in CR-LDP

> In this case, the traffic parameters would be
Non - MPLS traffic can be Differentiated or Integrated. For the
Differentiated case, the box would know as to what parameters it should use
to form the LSP according to SLA. But for the Integrated signallling, it
should recv a request and then make the LSP.But there is no such feature in
LDP to receive such requests and handle them.

This feature is required if peer in the other domain is say RSVP aware. For
that the box should be able to receive requests and form the LSPs
accordingly. How does the LER in my domain handle such traffic and requests
?

I have a little confusion here . Are the terms differentiated and Integrated
Signalling specific to RSVP or they are genaral terms and they are to be
supported in all the protocols like RSVP/LDP. There is no such mention of
two different signalling in LDP drafts.

> These are just two examples. Many others exist.
Regards
Santosh

---

From: "Philip Matthews" <[email-masked]>
Date: Thu, 09 Mar 2000 06:55:53 -0500

Hi Santosh:

Sorry to be slow in responding.
See my embedded comments.

- Philip

Santosh Gupta wrote:
> accordingly. How does the LER in my domain handle such traffic and requests?
> 

Integrated Services is an approach to adding QoS capabilities to the
Internet.
Classical RSVP is a protocol that was developed to support Integrated
Services.

Differentiated Services is a different approach to adding QoS
capabilities to
the Internet. Diff-Serv does not have an associated signalling protocol.

RSVP was later extended to also do MPLS signalling. The extension is
called
RSVP-TE. 

LDP and CR-LDP are two other protocols for MPLS signalling. These
protocols
were developed expressly for MPLS signalling.

The QoS parameters in CR-LDP are modelled on QoS signalling for ATM,
rather than the intserv model. 

If I understand you correctly, then one way to do what you want to do is
to map an RSVP session into a LSP signalled using CR-LDP. In this case, 
you need to map the intserv QoS specification into the CR-LDP QoS
parameters.
Though I am not an expert in this area, I understand that it is possible
to do this. However, depending on how many flows you expect to handle,
you may find that this solution is not particularly scalable. 

- Philip