[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LCAS and GMPLS

Adrian,

> So it seems to me that you have decided that LCAS is a GMPLS 
> application. That is, LCAS is an end-to-end protocol that triggers the 
> establishment of LSPs by making requests to GMPLS.

LCAS doesn't trigger any establishment of SDH VC-n or OTN ODUk. The 
decision
to create a VCAT group or to extend a VCAT group is made by a client 
layer's
Topology Manager (TM), e.g. an Ethernet layer network TM or IP layer 
network
TM, which needs an extra (ETH, IP) topological link to be established
between two of its switching nodes. Two cases now to consider:
1) ETH [IP] switching nodes have GFP/VCAT ports on the nodes
2) ETH [IP] swithcing nodes have Ethernet ports on the nodes, which are
connected to EoS ports on the next SDH/SONET/OTN equipment.

Case 2 is perhaps today the most common case, so let's focus on this case
and assume that two IP routers need an IP link between them. The steps 
that
follow the IP TM's decision are (using G.8080 terminology):

1) IP TM requests its ETH CCC to issue an ETH Virtual Connection (EVC) 
call
   request to the ETH NCC (in the local network). 
2) The ETH NCC forwards the request as an EVC connection request to the
   local ETH CC. 
3) This ETH CC notices that it can't complete the connection request in
   absence of sufficient ETH topology. 
4) ETH CC recognises that it can forward the connection request as an EVC
   call request to a third party network (transport network). 
5) So ETH CCC will issue an EVC call request to the network, where this
   request is received by the transport netowrk's ETH NCC. 
6) The ETH NCC is aware that the EVC connection point at the edges of the
   transport network are connected to (SDH, OTN) VCAT ports.
7) The EVC call request is converted into an VCAT call request send to the
   VC-n [ODUk] NCC, indicating the number of VC-n [ODUk] members it should
   have, the number of diverse routes to be supported (e.g. 2 diverse 
   routes, each route having half the number of VC-n [ODUk] members) and
   that LCAS is required.
8) The VC-n [ODUk] NCC receiving the request converts this into two VC-n
   [ODUk] group connection request and configures the two VCAT endpoints
   with the appropriate bandwidth to support (i.e. the value of X in the
   VC-n-Xv or ODUk-Xv) and enables LCAS.
9) The VC-n [ODUk] CC receives two connection requests to set up two 
groups
   (X1, X2) of VC-n [ODUk] network connections, the two groups must be
   diverse routed. As part of the connection setup, the VC-n [ODUk]
   termination functions must be configured (e.g. trace identifier 
values).
   The connection setup may arbitrarily pick any subset of the VC-n [ODUk]
   Termination Connection Points within the VCAT endpoint (much like
   selecting one or more link connections in a link) to be the endpoint
   of the X1 and X2 VC-n [ODUk] network connections. The two ends may 
   select different subsets (LCAS will deal with this).
10) As soon as one of the VC-n [ODUk] path termination functions indicate
   that the Trail Signal Fail (TSF) condition is cleared, LCAS will try to
   add this VC-n [ODUk] trail to the active group (initially zero active
   members are present). This part is outside the NMS/ASON/GMPLS 
   connection management control.
11) successfull connection set up is reported back to the call request
   originator (i.e. the IP TM), so that this new IP link can be taken
   into service.

Assume that at a later stage the IP TM decides to increase the IP link
bandwidth, then it will issue a call modification...
12) ETH CCC in local (i.e. IP) network will issue a call modification
    request (bandwdith from B1 to B2)
13) via local ETH NCC, ETH CC and ETH CCC this call modification request 
is
    forwarded to the transport network's ETH NCC.
14) ETH NCC converts this EVC call modification request into a VCAT call
    modification request (e.g. X+1 VC-n [ODUk] VCAT group)
15) VC-n [ODUk] NCC receives this VCAT call modification request and 
decides
    which of the two groups (X1, X2) to modify; e.g. X2 := X2+1.
16) VC-n [ODUk] NCC modifies the two VCAT endpoint configurations (X:=X+1)
17) VC-n [ODUk] CC receives a VC-n [ODUk] group conneciton modification
    request for X2 group (X2+1). It sets up the additional VC-n [ODUk].
18) As soon as the additional VC-n [ODUk] path termination function
    indicates TSF condition cleared, LCAS will try to add this VC-n [ODUk] 
to
    the active VCAT group.
19) successfull connection modification is reported back to the call 
request
    originator.

I hope the above clarifies who originates the request and the steps to
support the request.

Regards,
Maarten


More info on LCAS can be found in:
Next Generation SDH/SONET: Evolution or Revolution?
Huub van Helvoort
ISBN: 0-470-09120-7
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470091207,descCd-tableOfContents.html 




---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
VoIP: +49 711 821 43528
Mobile: +31 65 141 8140
Email:Maarten.Vissers@alcatel.de