Subject: Re: LCAS and GMPLS

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 13 Jun 2005 20:13:36 +0200

Hi Adrian,
                  IMHO the requirement are two
1       identify a set of LSPs as part of the same service 
2       transport end2end the information that the LCAS protocol has to be 
enabled on tail end node 

Requirement 1 can be accomplished with Call_ID wile LCAS information can 
be encoded in the Profile field of the SENDER_TSPEC.

That is my view.

BR

Diego

Please respond to "Adrian Farrel" <[email-masked]>
To:     "Greg Bernstein <gregbern", "Diego Caviglia" <[email-masked]>
cc:     <[email-masked]>, "ccamp" <[email-masked]> 

Subject:        Re: LCAS and GMPLS

Hi,

In answer to Greg, I think this didn't go further because we are waiting
for a clarification of the requirements.

It sounds to me (from the proposed solutions!!!) that the requirements
placed on signaling may be quite light. But I would prefer to see a
statement of what these are before thinking too much about what the
solution might be.

Are LSPs modified through LCAS, or are LSPs added and deleted to support
modifications in the required service?

Thanks,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]>
To: "Greg Bernstein <gregbern" <[email-masked]>
Cc: <[email-masked]>; "ccamp" <[email-masked]>
Sent: Monday, June 13, 2005 5:20 AM
Subject: Re: LCAS and GMPLS

>
> Hi Greg,
>                the idea I've in mind in order to identify the various
VCAT
> LSPs that are part of the same VCAT group is usage of CALL_ID (class-num
> 230) object.  That is the Call_Id identifies the 'service' provided to
the
> customer that is in this case is a VCAT set of LSPs with LCAS.  Every
> member of the set id identified as usual.
>
> Call_Id is an ITU-T (G.7713.2) object that has been 'accepted' by IETF
with
> RFC 3474.
>
> BR
>
> Diego
>
>
>
> Greg Bernstein <[email-masked]> on 10/06/2005 17.37.00
>
> To:    Diego Caviglia <[email-masked]>, [email-masked]
> cc:
>
> Subject:    Re: LCAS and GMPLS
>
> Hi Diego et. al. agree that this is part of the
> important topic on control of VCAT groups but I can't
> remember why this didn't go further.  Is the
> identification of separately routed VCAT components
> resolved? I.e., those belonging to the same group but
> disjointly routed. (We needed an identifier for the
> VCAT group somewhere in the signaling message).
>
> Adrian or Lyndon do you recall?
>
> Greg B.
> --- Diego Caviglia <[email-masked]> wrote:
>
> > Hi all,
> >         I'd like to ask what is the statuts of the
> > interworking between
> > LCAS and GMPLS.  Surfing the net I've found a couple
> > of ID about that
> > subject (draft-kim-ccamp-intercaction-grsvpte-lcas
> > and
> > draft-mannie-ccamp-gmpls-tdm-lbm) but both of them
> > seems to be expired,
> > I've also found some interesting discussion on this
> > matter on the ccamp
> > mail archive.
> >
> > Is interwoking between LCAS and GMPLS outside the
> > scope of CCAMP?
> >
> > IMHO that is not and should be addressed.
> >
> > What is the feeling of the rest of the group?
> >
> > Best regards
> >
> > Diego
> >
> >
> >
> >
>
>
>
>
> __________________________________
> Discover Yahoo!
> Have fun online with music videos, cool games, IM and more. Check it
out!
> http://discover.yahoo.com/online.html
>
>
>
>
>
>
>
>
>

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 13 Jun 2005 15:54:24 -0700 (PDT)

Hi all, thanks for the update Diego and Adrian. Where
we stand seems to be:
(1) We've got an agreed method using the Call_ID to
identify (VC-3/VC-4) component belonging to a VCAT
group. In particular, the Call_ID along with source
and destination addresses uniquely identifies the VCAT
group in the network?
(2) I can use GMPLS to setup/tear down one or more
VCAT group components at a time. (we've had this for a
while).
(3) Once we set up via GMPLS a new component
(VC-3/VC-4) of a VCAT group we want LCAS to hitlessly
add the new component to the group.
(4) To remove (hitlessly) the component from the VCAT
group we need  LCAS to remove it before we actually
tear down the component connection via GMPLS.

Now the thing that seems a bit tricky to me about (3)
and (4) is that LCAS does things unidirectionally, in
the sense of adding/removing components, (not in the
sense of a protocol which has a handshake mechanism). 
All add or remove commands come from the source end
and since we generally setup/teardown bi-directional
connections that would leave us with a bit of
coordination.  Is this what you are thinking Diego?
LCAS experts chime in too :-)

Greg B.

--- Diego Caviglia <[email-masked]> wrote:

> > To:    Diego Caviglia
> <[email-masked]>, [email-masked]
> > cc:
> >
> > > subject
> (draft-kim-ccamp-intercaction-grsvpte-lcas
> > > and

__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Jun 2005 14:22:05 +0100

Hi Greg,

Let me come in a bit heavy here, please.

> and destination addresses uniquely identifies the VCAT

No. We do not have agreement on this.
We have a vague statement of requirements that a group of LSPs need to be
associated. Until we see the requirements fleshed out and written up it
would be wrong to pick one solution. For example, we have an Association
object that is part of mainstream GMPLS that could be used for this
purpose.

So, let's see the requirements written up, please.

> tear down the component connection via GMPLS.

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.

This sounds reasonable, but please write it up.

> LCAS experts chime in too :-)

Nothing to stop you having unidirectional LSPs if you need to support a
service that controls LSPs in a unidirectional way.

Cheers,
Adrian

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 14 Jun 2005 08:27:22 -0700 (PDT)

Hi Adrian, not heavy at all. This helps me see what's
up. Let me recast as informal requirements with
justification and of course a bit of solution
pondering.

(1) I (as an individual) really want to be able to use
GMPLS to set up disjointly routed components of a VCAT
group.  Why?  (a) To more be able to full "extract
bandwidth from a mesh" via inverse multiplexing. (b)
To provide for graceful degradation in the case of
failure, e.g., one of the disjointly routed components
fails.
--> I hear now that Call_ID isn't appropriate (thanks
Jonathan and Hi!), but that there is an Association
object (thanks Adrian) of some sort that might be
appropriate.

(2) LCAS can be used to add disjointly routed
components to a group in a hitless fashion after it
has been set up via GMPLS.  Initiation of the LCAS
"add" procedure requires some type of management
command. 
--> I'm not sure if I have a requirement here since I
could default my end system behavior to automatically
issue the "add" LCAS commands from both ends after the
GMPLS procedure completes.  Diego or Jonathan, are
their other situations where this wouldn't be
appropriate?

(3) LCAS can be used to delete disjointly routed
components in a hitless fashion prior to removal of
the component connection via GMPLS. Initiation of the
LCAS "delete" procedure requires some type of
management command. My requirement here would be to
have a way to communicate via the end systems that I'm
going to take down the connection and to have LCAS
first do its hitless deletion.  
--> Now at the end that initiating the removal of the
component alerting LCAS to "delete" shouldn't be a
problem. Its the far end we'd want to communicated
something to...  Now didn't we (way back) add
something to RSVP GMPLS extensions to kind of anounce
the release of the connection prior to tear down so
that we could turn off SONET/SDH alarms (and couldn't
we use that to trigger the "reverse LCAS delete").

So Adrian, it seems like LCAS isn't so much as a GMPLS
application but a helper application enabling the
hitless addition and deletion of VCAT components. 
Also we may be very close to having all the facilities
we need to automatically enable its "co-use" with
GMPLS. Hence we could be talking about an "Application
Note" rather than extension.  I need to review some of
the ITU VCAT management models to make sure I haven't
glossed over things too much.

Greg B.

---

From: [email-masked]
Date: Wed, 15 Jun 2005 11:08:08 +0200

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:[email-masked]