Re: Bandwidth modification in GMPLS

[Maarten Vissers <[e-mail]>]

Dimitri,

Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a
SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed...
this is under control of LCAS and may change with time...

When you set up the connection to transport the VC-4-4v signal via two routes
(A, B), two VC-4 termination points will be connected to the A route, two other
to the B route.
There are typically 7 VC-4 termination points per GbE port... let's refer to
those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1
.. G7.

Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
VC-4 SNPs.

	VC-4 with G1	via route A
	VC-4 with G2	via route A
	VC-4 with G3	via route B
	VC-4 with G4	via route B
	VC-4 with G5	not connected
	VC-4 with G6	not connected
	VC-4 with G7	not connected

Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
(SF) condition, then this trail will pass through the signal with SEQ ID=0. If
the second one is via G4, then this one passes through the signal with SEQ ID=1.
If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.

	VC-4 with G1	via route A		SEQ ID=3
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route B		SEQ ID=2
	VC-4 with G4	via route B		SEQ ID=1
	VC-4 with G5	not connected
	VC-4 with G6	not connected
	VC-4 with G7	not connected

When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. 

	VC-4 with G1	via route A		SEQ ID=3
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route B		SEQ ID=2
	VC-4 with G4	via route B		SEQ ID=1
	VC-4 with G5	via route A		SEQ ID=4
	VC-4 with G6	not connected
	VC-4 with G7	not connected

Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
of SEQ ID, only there will be an indication not to transmit over those VC-4
trails. If later on it is decided to continue over route A only, the SEQ IDs
are adapted as follows:

	VC-4 with G1	via route A		SEQ ID=1
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	not connected
	VC-4 with G4	not connected
	VC-4 with G5	via route A		SEQ ID=2
	VC-4 with G6	not connected
	VC-4 with G7	not connected 

If the demand for bandwidth doubles again, it is possible to add say three more
VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
those trails become available is G6, G3, G4 then the SEQ IDs will be:

	VC-4 with G1	via route A		SEQ ID=1
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route C		SEQ ID=4
	VC-4 with G4	via route C		SEQ ID=5
	VC-4 with G5	via route A		SEQ ID=2
	VC-4 with G6	via route C		SEQ ID=3
	VC-4 with G7	not connected 


Looking at the connection setup details, I do not setup a VC-4-2v via A and
another VC-4-2v via B initially... I do setup two groups of two VC-4
connections, which together support the  VC-4-4v trail; a VC-4-4v is not the
same as two times a VC-4-2v. The use of NVC parameter here seems as such not
appropriate. The only alternative present is the MT field. 

Alternative is to redefine NVC as "This field indicates the number of identical
co-routed connections that are requested for this LSP. These connections are all
of the same type."

	But if I assume for a moment an alternative example in which the
	virtual concatenated endpoints are outside of the network of 
	interest, then a UNI/E-NNI request using MT will result in the
	same connections being setup compared to such request using the
	modified NVC definition. What am I missing here?



The traffic parameters for these two group-connections supporting the VC-4-Xv
trail are thus:

initially:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
	route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]

after 5th VC-4 trail addition:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
	route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]

after route B connections being released:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]

after 4th, 5th, 6th connection being added via route C:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
	route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]

To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a
MODIFY message is required. In your LBM document you propose to signal the diff
value only, and consequently let the switch nodes compute the new total (i.e.
new = original + diff). It will work as well to signal the new value and let the
switch nodes compute the difference (i.e. diff = new - original). We need to
evaluate the pros/cons of both approaches before selecting one.

When the group-connection via route B is removed, this group-connection has to
be released. 

When the group-connection via route C is to be added, this group-connection has
to be setup.

In addition to these cases, the MODIFY message has to support also the decrease
case. E.g. assume that route A is more expensive than route C, then one would
obviously prefer to release a VC-4 connection via route A when the total
bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s.

after 3rd connection via route A is removed:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
	route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]

	VC-4 with G1	via route A		SEQ ID=1
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route C		SEQ ID=3
	VC-4 with G4	via route C		SEQ ID=4
	VC-4 with G5	not connected
	VC-4 with G6	via route C		SEQ ID=2
	VC-4 with G7	not connected 

When using a MODIFY message which includes the new traffic parameters (and not
the diff ones), the same MODIFY message can be used for addition and removal of
connections to/from the group. This looks like a pro for a MODIFY message
definition including the new traffic parameters.


One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a
single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to
SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to
request the setup of two 2-group-connections to SNPP "G1-G7" and let the local
switch node decide which specific SNPs will be allocated.
And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection,
and to add the 4/5/6th VC-4 connections via route C later on.

I hope this clarifies some of the capabilities of the control plane needs to
support when a group-connection is to be modified, and the operation of the SEQ
ID within virtual concatenation with LCAS.

Regards,

Maarten


Dimitri Papadimitriou wrote:
> 
> Maarten,
> 
> As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
> for bandwidth increase purpose since it is used for a different
> semantic.
> 
> 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
>    -gmpls-sonet-sdh-02.txt)
> 
> 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.
> 
> Regards,
> - dimitri.
> 
> Maarten Vissers wrote:
> >
> > Manoj,
> >
> > 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
> > connection.
> >
> > 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.
> >
> > Regards,
> >
> > Maarten
> >
> > 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 <[e-mail]>
> > > >To: manoj juneja <[e-mail]>
> > > >CC: [e-mail]
> > > >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