[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bandwidth modification in GMPLS
As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
for bandwidth increase purpose since it is used for a different
SPEs/VCs can only be added at the end of an LSP. For instance,
when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is
numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the
sequence numbered from 0 to X+Y-1.
The number Y of SPEs/VCs to add is given by the following
equation: new NVC - old NVC. The first new SPE/VC will have a
sequence number equals to the sequence number of the previously
last VC + 1 (i.e. X).
In such a case (in your below example)
- Connection X - A - Y traffic parameters
* Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
* Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
The MT field in this picture is used in the following way (the
number Y of SPEs/VCs to add is given by the following equation:
(new NVC * new MT) - (old NVC * old MT) just notice that in most
cases new MT will be equal to old MT):
- 2 Connections X - A - Y traffic paramters
* Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
* Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0
Your second example is depicted in the section 5.2 of the
draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
of the multiplier (MT) in that context is not recommended.
Maarten Vissers wrote:
> There is a difference between
> 1) modifying the bandwidth of a connection and
> 2) replacing the connection by a different connection.
> Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4
> connection is a connection in a VC-4 network layer. These network layers are
> independent, and as such you can only replace a VC-3 connection by a VC-4
> connection by releasing the VC-3 connection and requesting to set up a VC-4
> Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT
> >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result.
> Example: Consider VC-4-Xv trail between nodes X and Y which
> supports an Ethernet link between these two nodes. When X is
> increased from 4 to 5, the Ethernet link bandwdith is increased
> from 600 Mb/s to 750 Mbit/s.
> Assume that the VC-4-Xv trail is supported via two diverse
> routes (X - A - Y and X - B - Y), each providing two VC-4
> connections. Then the bandwidth modification will increase
> the number of connections on one of the two routes; e.g. the
> route via A. The associated traffic parameters will be:
> - Connection X - A - Y traffic parameters
> * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0
> - Connection X - B - Y traffic parameters (unchanged)
> * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> What is needed is a MODIFY request which allows for an identified connection to
> modify the MT value.
> (*) Note that the parameter NVC is interpreted as to represent the number of
> components in a virtual concatenated signal connection... in this example NVC=4
> and grows to NVC=5. As the virtual concatenated signal is transported via two
> routes, each having half of the member connections, I have the impression that
> MT is the parameter to use.
> Or to turn this around and look at the source for the bandwidth modification
> first, we may assume that over the e.g. Ethernet UNI the call controller
> (G.8080) at the network side receives a request to increase the enthernet link
> from 600 to 750 Mbit/s. The call controller then decides to support this
> ehternet bandwidth modification request by means of a modification of the
> group-connection via route A... it then issues a connection modification request
> for this group-connection... etc.
> Add 1) True bandwidth modification of an individual connection is possible for
> e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS
> links (G.805) over which the connection is transported have spare capacity, the
> bandwidth of an individual VP, VC or LSP can be increased.
> manoj juneja wrote:
> > Hi All,
> > If the bandwidth modification is not supported by GMPLS then
> > it should be clearly mentioned in the drafts (at least the architecture
> > draft). Please see the attached mail for reference.
> > I am still not clear whether GMPLS supports SE-style of reservation.
> > My original question related to SE-style of reservation was and I didn't
> > get any reply on the mailing list :
> > " I have a doubt related to SE style of reservation in GMPLS. As
> > in RSVP-TE, multiple senders can share the reservation but they can be
> > assigned different labels to distinguish different senders from one
> > other.
> > In GMPLS, as the label itself is a resource on the link, it means that
> > if there are multiple senders in the same session sharing reservation,
> > they should be assigned the same label. They can't be assigned
> > different labels or is it that GMPLS does not support SE style of
> > reservation ?"
> > Please correct me if I am missing something.
> > Regards,
> > manoj.
> > >From: Maarten Vissers <email@example.com>
> > >To: manoj juneja <firstname.lastname@example.org>
> > >CC: email@example.com
> > >Subject: Re: Bandwidth modification in GMPLS
> > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > >
> > >Manoj,
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > > Is it possible to modify/increase the bandwidth of an existing
> > >GMPLS
> > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be
> > >possible to
> > > > increase the bandwidth to say VC-4 ?
> > >
> > >No, this is not possible.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > > >
> > > > Should the new request be considered independent of previous one ?
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
tel;home:+32 2 3434361
tel;work:+32 3 2408491
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM