Subject: RE: LSP setup time and delay

From: Shahram Davari <[email-masked]>
Date: Fri, 18 Aug 2000 07:22:40 -0700

Vishal,

What you are describing is called "data driven label assignment". This is
explained in framework document, and requires L3 forwarding until the LSP is
setup. Due to its problems it has not been pursued further by MPLS WG
(however, some implementations exist). Control driven label assignment is
the one most of the people are working on.

Regards,
-Shahram

>-----Original Message-----
>From: Vishal M [mailto:[email-masked]]
>Sent: Friday, August 18, 2000 4:15 AM
>To: [email-masked]
>Subject: LSP setup time and delay
>
>
>
>Hello,
>
>Suppose an IP packet is to sent over a MPLS network.
>As I understand the protocol, different components at
>the ingres LSR (also called LER) interact in the 
>following way:
>
>1. MPLS Signaling Plane (CR-LDP/RSVP) queries the
>Routing Plane (IGP Extensions) to get the Explicit 
>Path to reach the destination (assuming nothing
>in the tables initially).
>
>2. Signaling Plane uses RSVP or CR-LDP to reserve
>resources along the explicit path. Label mapping
>is performed at the intermediatory LSRs.
>
>3. After the path is set up i.e. LSP is established 
>from the source to the destination, the incoming 
>packet is forwarded and the rest of the packets follow
>the same path.
>
>Questions:
>
>Q1. In the process mentioned above (and if it is the
>right sequence), there might be a noticable delay 
>between the time the packet arrived at LER and
>the time when the LSP is established and actual
>traffic starts flowing.
>
>This could lead to two problems:
>a. Delay at the LER. If we are dealing with mission 
>critical applications, is this delay acceptable ?
>b. Memory crunch at the LER (considering OC-192 i/f).
>
>We could have pre-configured tunnels or LSPs to 
>circumvent this problem. Are tunnels the way to go to
>resolve this ? Is there any other solution (assuming 
>this is really a problem !) ?
>
>Q2. I'm not very sure of the Step #3. Is the first 
>packet routed ?
>I mean, does the first packet go along with the
>Resource Resv request OR does it have to wait till the
>
>entire path is established ?
>
>I apologize if this is a very basic question, but
>I have trouble understanding this.
>
>Thanks,
>Vishal.
>
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Send instant messages & get email alerts with Yahoo! Messenger.
>http://im.yahoo.com/
>

---

From: [email-masked]
Date: Fri, 18 Aug 2000 10:48:33 -0400

Does this mean that there is no L3 forwarding between two LSRs (all traffic
is labeled)?

Shahram Davari <[email-masked]> on 08/18/2000 10:22:40 AM

 To:      "'Vishal M'" <[email-masked]>, [email-masked]  
                                                              
 cc:      (bcc: Tim Cook/Fort Lauderdale/ECI Telecom)         

 Subject: RE: LSP setup time and delay                        

Vishal,

explained in framework document, and requires L3 forwarding until the LSP
is

Regards,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 18 Aug 2000 08:28:32 -0700

Tim,

No. Control packets are L3 forwarded. Also in data driven method, the
packets are initially L3 forwarded and then switched to L2 forwarding when
LSP is setup.

-Shahram

>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, August 18, 2000 10:49 AM
>To: Shahram Davari
>Cc: 'Vishal M'; [email-masked]

---

From: "Metz, E.T." <[email-masked]>
Date: Fri, 18 Aug 2000 18:40:07 +0100

In addition: not *all* regular traffic is labeled *always*. This depends on
the application, and how the FECs are defined.

cheers,
	Eduard

> From: Shahram Davari [mailto:[email-masked]]
> Sent: vrijdag 18 augustus 2000 16:29
> To: [email-masked]'; Shahram Davari

---

From: Vishal M <[email-masked]>
Date: Fri, 18 Aug 2000 11:11:04 -0700 (PDT)

Hi Shahram,

Thanks for reply. Some more doubts:

1. If the LSP setup is not data-driven, how
   many LSPs are established on the ingress LSR (LER)
   when LER initializes ?

2. Wouldn't this lead to a lot of manual intervention
   in pre-establishing these LSPs ? 

3. What happens if LER gets an IP packet for which
   there is no pre-established LSP (and assuming
   that the IP packet belongs to a mission-critical
   application) ? 
   How do we ensure QoS in this case ? 
   
Thanks,
Vishal.

--- Shahram Davari <[email-masked]>
wrote:
> >Does this mean that there is no L3 forwarding
> between two LSRs 
> >(all traffic
> >is labeled)?
> >
> >
> >
> >
> >Shahram Davari <[email-masked]> on
> 08/18/2000 
> >10:22:40 AM
> >                                                   
>           
> >                                                   
>           
> >                                                   
>           
> >What you are describing is called "data driven
> label 
> >assignment". This is
> >explained in framework document, and requires L3
> forwarding 
> >until the LSP
> >is
> >(however, some implementations exist). Control
> driven label 
> >assignment is

---

From: Vishal M <[email-masked]>
Date: Fri, 18 Aug 2000 11:11:04 -0700 (PDT)

Hi Shahram,

   
Thanks,
Vishal.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 18 Aug 2000 11:47:32 -0700

Hi Vishal,

>Sent: Friday, August 18, 2000 2:11 PM
>To: Shahram Davari; [email-masked]'

It depends on the network policy and requests that are signaled. In many
cases (such as in a Diffserv network) you probably need at least one LSP per
egress LSR.

>   in pre-establishing these LSPs ?

Not really. You just need to specify the ingress LSR, the egress LSR, the
FEC and the required QoS (such as BW) for the required LSP, and the TE
software will find and establish the path for you. 
 
>   How do we ensure QoS in this case ? 

If after the packet classification it is found that the packet does not map
to any LSP, then this is up to the network policy, it may send it as L3
packet or may drop it. It is up to the network provider to assign all
required FECs to proper LSPs at the edge.

The best method is for the mission-critical application to signal its
required QoS. The network will use this information to establish the
required LSP. If such an LSP can't be found then the request will be
rejected. In other words admission control is the best method to make sure
that the mission-critical packets receive their required QoS.

Regards,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 21 Aug 2000 07:40:32 -0700

Hi Vishal,

>Sent: Saturday, August 19, 2000 4:20 AM
>To: Shahram Davari
>Cc: [email-masked]; [email-masked]
>Hi,
>Thanks for the clarifications. One more related
>question:
>
>In the MPLS network, the LSRs exchange the 
>OSPF TE LSAs containing bandwidth availability 
>information etc.
>
>Now if the resource avail changes and it calls for a 
>new TE LSP, would this change (i.e. new LSP 
>establishment) happen automatically or would it be
>data-driven. 
>

If the links characteristics (such as available BW) change and this change
is propagated via  OSPF, then there are two cases:

1) Already established LSPs: it is up to the network policy to decide
whether to re-route them to new path or to keep them as they are.
2) New LSPs: For new LSP requests the LER will use the latest LSA
information to compute the path.

>i.e. if the OSPF Routing Plane gets a new TE 
>LSA, it could handle it in following ways:
>
>a. Routing plane runs the SPF calculation
>   on receipt of every TE LSA and informs the MPLS 
>   Signalling Plane of this change.
>
>   If we follow (a), it could mean:
>   - more SPF calculations and more computation
>     overhead on the LSRs.

For a limited well known constraints, an LER could compute the best path
continuously, based on the latest LSA information. The result could be used
for new LSP requests or for re-routing the old LSPs. This technique is
called "off-line" computation, and as you said is computationally expensive,
because many of the computed routes won't be used at all, but the advantage
is that they are readily available with minimum delay. 

>
>b. Routing Plane waits for the Signaling
>   Plane to trigger a request for a new explicit 
>   path. Once requested, Routing Plane runs the
>   SPF algo, calculates new routes and gives it
>   back to the Signalling Plane. i.e. the SPF 
>   calculation is data-driven.
>
>   If we follow (b), it could lead to
>   - LSPs based on out-dated resource info
>   - delays (as mentioned in the original ques).

This method is called "on-line" computation and its problem is the delay as
you mentioned it (but not out-dated info). Its advantage is being
computationally cheaper.

>
>Which approach is preferred and why ?
>
>As far as I remember reading on this, approach (b) 
>is preferred. But, if that is correct, it contradicts
>with our current discussion (that LSP setup is _not_
>data-driven).

I think you are confusing a few things. There are two steps in TE:

1) Computing the path
2) Establishing the LSP

As I said we have two methods to compute the path: 

- on-line
- off-line

But we have 3 methods to establish the LSP:

- data driven: LSP setup is triggered by an arriving packet
- control driven: LSP setup is triggered by signaling requests
- topology/policy driven: LSP setup is triggered by network itself based on
some predefined rules. In this case the LSP is ready before any request or
packet arrives.

Which approach is preferred, depends on the network, the SLAs and the
policies involved. All these methods could be used to tailor it out to your
own situation.

Regards,
-Shahram
  
>
>Am I missing something...
>
>Could you please throw some pointers...
>
>Thanks,
>Vishal.
>
>PS: I apologize if you receive multiple copies
>of this mail. I sent this before, but didn't see
>this on the mailing list.
> 
>
>> >> No. Control packets are L3 forwarded. Also in
>> data
>> >> driven method, the
>> >> packets are initially L3 forwarded and then
>> switched
>> >> to L2 forwarding when
>> >> LSP is setup.
>> >> 
>> >> -Shahram
>> >> 
>> >> >setup. Due to its problems it has not been
>> pursued
>> >> further by MPLS WG
>> >> >>As I understand the protocol, different
>> components
>> >> at
>=== message truncated ===
>
>

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 21 Aug 2000 08:28:50 -0700 (PDT)

Hi,

>   - more SPF calculations and more computation

See section 5.6.4 of RFC 2702.

Especially:

   Stability is a major concern when re-optimization is permitted. To
   promote stability, an MPLS implementation should not be too reactive
   to the evolutionary dynamics of the network.

Kireeti.

---

From: Vishal M <[email-masked]>
Date: Fri, 18 Aug 2000 14:08:05 -0700 (PDT)

Thanks for the clarifications:

Which of these is preferred approach and why ?

Thanks,
Vishal.

---

From: Vishal M <[email-masked]>
Date: Fri, 18 Aug 2000 15:24:00 -0700 (PDT)

Hi Shahram,

Thanks for the clarifications. I've one more
question on a related issue:

Thanks,
Vishal.

---

From: Vishal M <[email-masked]>
Date: Sat, 19 Aug 2000 01:19:45 -0700 (PDT)

Hi,

Thanks,
Vishal.