Subject: RE: MPLS Trafficdriven

From: "Marinzulich, Matias" <[email-masked]>
Date: Wed, 25 Apr 2001 14:58:26 -0300

Hello all, as far I can see, all cell-mode MPLS implementations (that is,
MPLS network constructed with ATM switches) use 'on demand' label
allocation. Since you have a very small place for save the label, the
allocation and distribution must be highly conservative. For stay this
minimal, all LSP are created 'on demand' in this kind of networks.
In the other hand, MPLS networks based in routers can use 'on demand' or
unsolicited label distribution.

Matias.-

> -----Mensaje original-----
> De:	Ashwin Moranganti [SMTP:[email-masked]]
> Enviado el:	Miércoles, 25 de Abril de 2001 10:34 a.m.
> Para:	'MP LS'; [email-masked]; [email-masked]
> Asunto:	RE: MPLS Trafficdriven
> 
> I have seen this as one of the feature in Lucent's IP Navigator MPLS
> product. 
> The ports are configurable for this feature, and when a certain traffic
> flow is detected LSPs are signalled for and the data is transmitted and
> then LSPs are destroyed. Though this is not useful for all applications.
> The key here is the signalling rate. If the rate is satisfactory, it is
> useful for some applications
> 
> thankyou 
> Ashwin 
> 
> -----Original Message----- 
> From: MP LS [ <mailto:[email-masked]>] 
> Sent: Wednesday, April 25, 2001 8:29 AM 
> To: [email-masked]; [email-masked] 
> Subject: MPLS Trafficdriven 
> 
> 
> Hello all, 
> 
> I have a question. Is there any possibile way to create a fully dynamical 
> Traffic driven MPLS network. So that when any packet arives at an LSR it 
> will analyse the IP pakket ads a label in front of it with it combines to
> a 
> FEC and then just sent it to the Destination LSR?  Just till now i only 
> found that you have to ask for an LSP manualy and then the data can be 
> transported over it. 
> 
> I hope someone can make this clear for me. 
> 
> Kind regards, 
> 
> Niels Sitters 
> _________________________________________________________________________ 
> Get Your Private, Free E-mail from MSN Hotmail at
> <http://www.hotmail.com>. 
> 
> ------- 
> The MPLS-OPS Mailing List 
> Subscribe/Unsubscribe:  <http://www.mplsrc.com/mplsops.shtml> 
> Archive: <http://www.mplsrc.com/mpls-ops_archive.shtml> 
>

---

From: Geoff Bennett <[email-masked]>
Date: Wed, 25 Apr 2001 22:15:45 +0100

Hi Matias,

I have to disagree with your conclusion here.  There's no specific
relationship between ATM/MPLS implementations and a requirement to operate
with data-driven LSPs.

You may be confusing this with MPOA, which was always data-driven, but in
general was restricted to use in Enterprise networks due the the
scalability issues that these microflow setups created.

As you point out, the label size in the ATM encapsulation is smaller than
the shim header (16 bits vs 20 bits), but since labels only have local
scope (in this case the scope is the ends of the inter-LSR cable), then
there is no real issue about "label exhaustion".

Current MPLS implemetations can be:

a: Control Driven (ie. LSPs are established by routing protocol
information, and as a result cannot offer Traffic Engineering, but may be
able to support "assisted VPN" capability).

b: Manually established (this is the case for all current TE implementations)

c: (At some undetermined point in the future) may be automatically
established via policies and information generated by extended
(constraint-based) routing protocols (eg. ISIS-TE or OSPF-TE).

As far as I'm aware there are no data-driven implementations today for the
simple reason that they don't scale beyond "Enterprise" networks, and
because MPLS is actually intended to be a core SP technology.

It makes sense to pursue the idea of data driven LSP setup, but it's
essential to combine this approach with a flow aggregation mechanism if we
expect to deploy such a technology in "large networks" (eg. a Service
Provider).  In theory the Ingress LSR could be given the capability to
aggregate flows of information into a single LSP, but the details of how
this could be done are generally clouded in marketing smoke and mirrors
today.  The issue is that IPv4 lacks either a flow label (which IPv6 has),
or a session identifier (that ISO TP4 has) to provide an easy
classification mechanism.  The current "edge LSR" implementations are
handicapped by these limitations.  So how can they assign or aggregate
traffic?  They are normally limited to assignment on the basis of
destination IP address (essentially useless in most cases), or by the use
of the Port ID, or by some combination of these two.  In other words,
whatever criteria you can use to build a filter or ACL, you can use to
assign individual packets to an existing LSP (or as a trigger mechanism to
create a new LSP). 

Based on this "filter rule" limitation, the only application I can think of
that has both a well-known Port ID, and that I'd like to classify at the
Ingress LSR is Telnet (Port 23).  Obviously I'd like to give Telnet
priority as it's the major tool for network management, and these are the
packets I want to keep getting through in times of network congestion.

All the applications that really need to be classified (like VoIP with
H.323 for instance) use dynamic port numbers.  In fact there's nothing in
an individual H.323 packet that would allow you to build such a filter
rule.  The edge LER actually has to have quite a bit of protocol in it to
pick up packets like H.245, SIP, MGCP or whatever "flavour" of VoIP you're
using.

Cheers,
Geoff

At 14:58 25/04/01 -0300, Marinzulich, Matias wrote:
>> Asunto:	RE: MPLS Trafficdrive
>> 
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 
================================================================
Geoff Bennett                             								Tel: (33) 497 21 43 62
Director of Technology, OCTO               						Fax: (33) 497 21 43 50
Marconi
Gaia - Bat. E                           					email: [email-masked]
BP 123
06903 SOPHIA ANTIPOLIS
FRANCE
================================================================