inline
^ ^
==============ooo====(.)v(.)====ooo=====
Javier Antich Romaguera
Network Consultant
---------------------------------------------------------------------------
TELINDUS
Pza. Ciudad de Viena, 6-2º
28040 Madrid
---------------------------------------------------------------------------
javier.antich@telindus.es
tel: +34 91 456 00 08
fax: +34 91 536 10 74
---------------------------------------------------------------------------
For more information about our products and services,
please visit our website http://www.telindus.com
---------------------------------------------------------------------------
Full connectivity & mobility
==================ooo0===0ooo========
> -----Mensaje original-----
> De: Bala Subrahmanyam Venkata [SMTP:bsubrahm@doradosoftware.com]
> Enviado el: martes 26 de junio de 2001 1:26
> Para: Javier Antich
> CC: juniper-nsp@puck.nether.net
> Asunto: RE: [j-nsp] Differentiating MPLS VPN
>
> Jjavier-
>
> To sum up what we have discussed so far:
>
> 1. Bandwidth reservations can be made during LSP setup. But these are used
> by the signaling protocols only during the control phase (or more
> correctly,
> by the control plane). During actual forwarding of data, these bandwidth
> reservations are irrelevant.
[Javier Antich] right.
> 2. To differenitate services by bandwidth at the ingress we need to do
> certain actions during forwarding. This inludes thigns like rate limiting
> a
> particular "flow".
[Javier Antich] right
> 3. Labels can be used to offer QoS (giving raise to "E-LSP"s ???). But
> there
> are not many vendors that use this and this also does not scale well for a
> VPN.
[Javier Antich] Probably. Not sure about the support of this
feature in other vendors.
> Based on these I assume the following actions are what happens in a
> typical
> SP's office:
>
> a) Create signaled LSPs with multiple bandwiths. This causes the signaling
> protocol to make reservations in the control plane. (I still don't
> understand why an SP would "reserve" some interfaces in his/her Core LSRs
> for x MB bandwidth if he/she knows for sure it may or may not be used !!)
[Javier Antich] If you make sure by mechanisms like rate-limiting
that the LSPs do not use more resources than those "reserved", and limit the
best-effort traffic, then you can be sure that the LSPs will receive the
bandwitdh requested. For example, Diff-Serv aware Traffic Engineering is
being developed. With this feature you can limit the % of bandwidth in each
link that will be used for, let us say, premium traffic (voice, low latency
traffic). If you are able to keep this kind of traffic below a certain %,
you will ensure a low latency. Then, with Diff-Serv aware Traffic
Engineering you can make your low latency traffic LSPs go through the paths
that have still bandwidth available for this kind of traffic. Then if you
police at the entry to limit the resources they use, and if you use
appropriate queuing algorithms for given higher priority to this traffic
(for example, Expedite Forwarding), you have in practice reserved bandwitdh
for that traffic and limited the latency.
> b) If a customer calls the SP and asks for a VPN, the SP can guarantee
> only
> BE (best effort)VPN.
[Javier Antich] It depends on how IP packets, and the MPLS packets
are marked by the SP before entering the core. The traffic does not need to
be only best-effort.
> c) If the customer insists of differentiating the VPNs by service (say the
> customer chooses to differentiate the VPNs by bandwidth) then the SP can
> rate-limit each site (during ingress into his/her Core) and mark/drop the
> packets based on the bandwith.
> If the SP uses a vendor that recognizes such "markings" made by the SP in
> the "Exp" field, then the SP is happy since in his/her Core, there might
> be
> devcies that can "see" this "exp" and offer differentiated treatment (may
> be
> thru schemes like priority queing or things like that).
[Javier Antich] In fact, a customer will use as much bandwitdh as
you let him. IMHO you must police to limit the resources he may use, and you
must also apply different priorities in the core depending on which kind of
customer it is.
In a any-to-any VPN like a MPLS-VPN I do not see how would a SP
apply per-VPN QoS mechanisms in the core to guarantee the traffic. I think
that would not scale (I even think that is not possible with the current IP
technology).
> Is this a correct scenario ?
>
>
> TIA
>
> bala
>
>
>
>
>
> > -----Original Message-----
> > From: Javier Antich [mailto:javier.antich@telindus.es]
> > Sent: Monday, June 25, 2001 12:54 AM
> > To: Bala Subrahmanyam Venkata
> > Cc: juniper-nsp@puck.nether.net
> > Subject: RE: [j-nsp] Differentiating MPLS VPN
> >
> >
> > >"Each LSP has a bandwidth value. This value is included in the sender's
> > >Tspec field
> > >in RSVP path setup messages....[snip]......A nonzero bandwidth requires
> > >transit routers
> > >to reserve capacity along the outbound links for the path. This is done
> > >using RSVP's
> > >reservation scheme. Any failure in bandwidth reservation (such
> > as failures
> > >at RSVP
> > >policy control or admission control) might cause the LSP setup to
> fail."
> >
> > >This does not seem to imply the "bandwidth" being a decremented scalar.
> > Does
> > >this happen during the RSVP-TE path setup
> >
> > In a few words, there is nothing in the Juniper (neither in Cisco) that
> > ensures that if you "reserve" 10 Mbps for an LSP by creating a Traffic
> > Engineered LSP using RSVP-TE you will get them, or even that prevents
> you
> > from using more. You need more things.
> >
> > Bala S Venkata]--->
> > What is the point in making reservations in the control plane that are
> not
> > satisifed during forwarding ? It looks to me that the reservation made
> in
> > the control plane
> > are not used at all...am I right ?
> >
> > Well, that is how it is actually done. They are reservations only in the
> > control plane. You are responsible of configuring the forwarding
> > plane (rate
> > limiting, queuing, ...) to make the LSPs you have set up receive
> > the service
> > (bandwitdh) you are asking for.
> >
> > [Bala S Venkata]--->
> > Which also seem to imply to me that the exp bits classification
> > is the only
> > "differentiation" that MPLS can offer ? And this is also not
> > something that
> > a service running on top of MPLS like the VPN can make use of directly ?
> >
> > Not only, it is supposed that labels could also be used to
> > differentiate for
> > QoS, but I think no vendor is using it yet. I do not think that
> > applying QoS
> > per-VPN scales well. You may apply different QoS mechanism for
> > the VPN sites
> > using rate limiting and then in the core apply differentiation
> > using the exp
> > bits, for Gold customers -> Gold VPNs, Silver, and so on.
> >
> > ^ ^
> > ==============ooo====(.)v(.)====ooo=====
> > Javier Antich Romaguera
> > Network Consultant
> > ------------------------------------------------------------------
> > ---------
> > TELINDUS
> > Pza. Ciudad de Viena, 6-2º
> > 28040 Madrid
> > ------------------------------------------------------------------
> > ---------
> > javier.antich@telindus.es
> > tel: +34 91 456 00 08
> > fax: +34 91 536 10 74
> > ------------------------------------------------------------------
> > ---------
> > For more information about our products and services,
> > please visit our website http://www.telindus.com
> > ------------------------------------------------------------------
> > ---------
> > Full connectivity & mobility
> > ==================ooo0===0ooo========
> >
> >
> >
> > > -----Mensaje original-----
> > > De: Bala Subrahmanyam Venkata [SMTP:bsubrahm@doradosoftware.com]
> > > Enviado el: viernes 22 de junio de 2001 19:16
> > > Para: Javier Antich
> > > CC: juniper-nsp@puck.nether.net
> > > Asunto: RE: [j-nsp] Differentiating MPLS VPN
> > >
> > > I removed sections answered already...questions inline.
> > >
> > > > > > >
> > > > > > [Javier Antich]
> > > > > > First of all I would say that there are no "real" bandwidth
> > > > > > reservations for LSPs unless you police at the entry point.
> > > > >
> > > > >
> > > > > [Bala S Venkata]--->
> > > > > So what happens when I create an LSP using the
> "label-switched-path"
> > > > > statement under the "[edit protocols mpls]" hierarchy in a
> > > > Juniper device
> > > > > ?
> > > > > I can specify a bandwidth for the LSP (in addition to my
> > primpary and
> > > > > secondary named paths) correct? What is this bandwidth ?
> > > > [Javier Antich] Is a scalar value that is decremented at
> each hop
> > > > of the LSP or RSVP-TE session in the admission process of the LSP
> > >
> > >
> > > [Bala S Venkata]--->
> > > That seems different (?) from what Juniper docs for MPLS apps
> > >
> >
> (http://www.juniper.net/techpubs/software/junos44/swconfig44-mpls-apps/htm
> > > l/
> > > mpls-signaled-config25.html#1014861) says. Quoting the specific
> section
> > > for
> > > "bandwidth" statement in the hierarchy "[edit protocols mpls
> > > label-switched-path lsp-path-name]"
> > >
> > >
> > > "Each LSP has a bandwidth value. This value is included in the
> sender's
> > > Tspec field
> > > in RSVP path setup messages....[snip]......A nonzero bandwidth
> requires
> > > transit routers
> > > to reserve capacity along the outbound links for the path. This is
> done
> > > using RSVP's
> > > reservation scheme. Any failure in bandwidth reservation (such
> > as failures
> > > at RSVP
> > > policy control or admission control) might cause the LSP setup to
> fail."
> > >
> > > This does not seem to imply the "bandwidth" being a decremented
> scalar.
> > > Does
> > > this happen during the RSVP-TE path setup ?
> > >
> > >
> > > >
> > > > > And I assume that when you say "police at the entry point" you
> > > > are talking
> > > > > about schemes like rate limiting or access control ? How can this
> > > > > guarantee
> > > > > a bandwidth for an LSP ?
> > > > [Javier Antich] I mean that the current implementations of
> Traffic
> > > > Engineering using
> > > > RSVP-TE only make reservations in the control plane, not in
> the
> > > > forwarding plane. That is, you can make a reservation of 1 Mbps
> > > > for one LSP
> > > > but there is no implicit mechanism that prevents you from sending 10
> > > Mbps
> > > > through the LSP unless you limit it at the ingress point. The only
> way
> > > to
> > > > guarantee bandwitdh is limiting the resources others can use.
> > > >
> > > >
> > >
> > >
> > > [Bala S Venkata]--->
> > > What is the point in making reservations in the control plane
> > that are not
> > > satisifed during forwarding ? It looks to me that the
> > reservation made in
> > > the control plane
> > > are not used at all...am I right ?
> > >
> > >
> > > > > > However, probably this does not scale too much. Well,
> > > maybe even
> > > > > > does not work (can someone test it?).
> > > > > > > Also what happens if PE3 and PE4 now decide to be part of that
> > > > > > VPN ? Do I
> > > > > > > need to do the same between all the PEs if I want to steer the
> > > > > > VPN traffic
> > > > > > > between them into one of the LSPs between them ??
> > > > > > >
> > > > > > [Javier Antich]
> > > > > > And what if there are lots of VPNs?? Probably it is not a
> > > good idea
> > > > > > to have per-VPN LSPs between PEs.
> > > > >
> > > > >
> > > > > [Bala S Venkata]--->
> > > > > How else do you think a Service Provider can offer
> > > > "differentiated" VPN ?
> > > > > Looke like he/she can use the LSP for that since LSPs seem to have
> > > that
> > > > > level of differentiation (in terms of say bandwidth..)
> > > > [Javier Antich] No they do not have it. In terms of QoS,
> packets
> > > > are not treated according to the LSP they belong to but according
> > > > to the CoS
> > > > field they carry (exp bits). Maybe new MPLS implementations
> > will do it.
> > >
> > >
> > > [Bala S Venkata]--->
> > > Which also seem to imply to me that the exp bits classification is the
> > > only
> > > "differentiation" that MPLS can offer ? And this is also not something
> > > that
> > > a service running on top of MPLS like the VPN can make use of directly
> ?
> > >
> > >
> > > TIA
> > >
> > > /bala
> > >
> >
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:39 EDT