The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE: MPLS Trafficdriven
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: >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:amoranganti@appiancom.com] >> Enviado el: Miércoles, 25 de Abril de 2001 10:34 a.m. >> Para: 'MP LS'; MPLS@uu.net; mpls-ops@mplsrc.com >> Asunto: RE: MPLS Trafficdrive >> >> 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:stagempls@hotmail.com>] >> Sent: Wednesday, April 25, 2001 8:29 AM >> To: MPLS@uu.net; mpls-ops@mplsrc.com >> 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> >> > >------- >The MPLS-OPS Mailing List >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: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|