[no subject]

[owner-ccamp@ops.ietf.org]

by psg.com with esmtp (Exim 4.50 (FreeBSD))
id 1DiHhJ-0006va-RM
for ccamp@ops.ietf.org; Tue, 14 Jun 2005 20:07:46 +0000
Received: from vissersm.demon.nl ([83.160.252.43]:1597 helo=Maarten01)
by post-22.mail.nl.demon.net with esmtp (Exim 4.43)
id 1DiHB2-0007LY-LT; Tue, 14 Jun 2005 19:34:25 +0000
From: "Maarten Vissers" <maarten@maartenvissers.nl>
To: "'Adrian Farrel'" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>,
"'Varma, Eve L \(Eve\)'" <evarma@lucent.com>
Subject: Re: LCAS and GMPLS
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk

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 :=3D X2+1.

16) VC-n [ODUk] NCC modifies the two VCAT endpoint configurations
(X:=3DX+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