Please, see in-line comments.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> All,
> My attention was drawn to
> draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the
> following comments.
> 1) It is not clear to me why there should be any interaction between
> connections being provided for the purpose of Virtual Concatenation
> (VCAT) and connections being used for any other purpose. The existence
> of VCAT is invisible within the network, and should also be invisible to
> the connection protocol.
> You are quite right when you point out that its perhaps a good idea to
> identically route each leg, and explicit routing seems to meet that
> need. However, when the goal of VCAT and LCAS is diversity and graceful
> degradation, identical routing of each leg is useless. In this case,
> there is no other solution than treating each leg as an independent
> connection request. That being the case, each leg should always be
> treated as an independent connection request, and there can be no single
> end to end session associated with that set of connections.
My draft does not handle VCAT at all. In reference, as described in G.7042, the goal (maybe use) of LCAS is to
to increase or decrease the capacity of a container that is transported in an SDH/OTN network using Virtual Concatenation..
I couldn't find a word in G.7042 that the goal of VCAT and LCAS is diversity and graceful and graceful degradation.
I think your goal of VCAT and LCAS may be a small usage example for diversity and graceful and graceful degradation,
but, it is not the goal of VCAT and LCAS. As most of people know, VCAT and LCAS are ones of key factors for EoS.
What do you think of the goal of EoS. I think VCAT and LCAS are factors for supporting the EoS.
> 2) The entity that actually controls LCAS is an application; in
> particular it is the application that takes the request for a particular
> capacity and translates that request in a set of connection requests. In
> ITU parlance, that is call processing. As you say, that application can
> run on either a network element or a Management System. As connections
> can be set up bi-directionally, bi-directional operation of the VCAT
> group is a function of call processing; not of the individual connection
> requests.
> 3) LCAS and VCAT groups provide a vivid illustration of the separation
> of call processing from connection signaling. As VCAT groups will be
> operated for many different purposes, including diverse routing for
> graceful degradation, it is not possible to burden the signaling
> protocol with LCAS management as there are many signaling sessions - one
> for each leg of the VCAT group.
> It therefore seems incorrect to consider adding VCAT/LCAS details into
> the connection protocol.
> Regards
> George
I think I couldn't still find the traditional or original separation of call processing and connection signaling in IETF.
In addition, there might be a complicated mechanism for the pure separation of call processing and connection.
For call processing, a signaling protocol has to identify the characteristics of end users which are calling and called parties.
However, there is no concept in the current signaling protocols.
If you insist upon it, I think that LCAS and RSVP-TE are protocols for connection control because these are run
on connection resources.
In any case, the separation of call processing and connection is out of scope in my draft.
My point in the draft is to enough apply the advantages of the GMPLS signaling protocol in order to simplify the LCAS operations.
I think whether my draft is valid or not depends on the possibility of bidirectionality on the same route.
I'm looking for supporters and also reviewing by myself for this part.
Also, I think my draft has in current no detail about LCAS/VCAT except for the information for LCAS operation indication
and response(a single bit representation for the indication and error codes for the response) in case of LCAS.
If you want other references for my draft, please see the following papers.
- Generic Framing Procedure (GFP): The Catalyst for Efficient Data over Transport, IEEE Comm. Mag. May 2002., pp 72 ~ pp79.
- Next Transport Service for Next-Generation SONET/SDH Systems, IEEE Comm. Mag. May 2002., pp 80 ~ pp87.