Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt

[[e-mail]]

When being made aware of this draft, I couldn't help to remember the large 
amount of correspondence we had in 2001 on 
draft-mannie-ccamp-gmpls-lbm-tdm (GMPLS LSP Bandwidth Modification (LBM) for SONET/SDH). Refer to http://ops.ietf.org/lists/ccamp/ccamp.2001/.

Virtual concatenation's first application was to get around the problem 
SDH networks at that moment had to transport VC-4-4c signals that the ATM 
people were using in their STM-4 (OC-12) interfaces. The first generation 
SDH/SONET HO networks supported VC-4 and STS-1/STS-3c connections, and 
were not capable to support VC-4-Xc. With many 2nd generation SDH networks 
around these days that support VC-4-Xc (X=4,16,64) the original need is 
not so recognised anylonger. 

Today virtual concatenation (VC-n-Xv, n=4,3,12,11) is associated with a 
finer connection bandwidth granularity in the SDH transport networks. This 
is most important today for the Ethernet and SAN private line services. 
Soon after this etherent private line application was identified, people 
started to consider the development of a means to hitless 
increase/decrease the EPL's connection bandwidth. LCAS was born... and 
once under development it became obvious that LCAS could do more than just 
hitless inc/dec of connection bandwidth... i.e. it could bring 
survivability to the EPL, such that the connection could still be alive 
when a subset of the VC-n connections failed (but with reduced bandwidth).

So today it is assumed that an EPL connection gets at least 50% of its 
VC-n's routed via one route and the other 50% via an other - diverse - 
route.

Example:

==> Call Request for EPL of 10 Mbit/s, 
    with survivable bandwidth of 60%

==> EPL ingress/egress ports on the network
    support VC-12 based VCAT with Xmax = 10.

==> Network Call Controller (NCC) or NMS concludes
    that a VC-12-6v is required, of which 3 VC-12s
    are routed between X and Y via via nodes A-B-C-D
    (route 1) an the other 3 VC-12s are routed via
    E-F-G (route 2).

==> NCC (?) or NMS configures both X and Y 
    endpoints for VC-12-6v (refer to 10.1/G.806 (01/2004)
    and 12.5.3/G.783 (01/2004) for details). The LCAS processes
    at X and Y are now waiting for the 6 VC-12 endpoints to
    clear their Signal Fail condition. Once SF clears after 
    VC-12 connection is setup, LCAS will kick in and will
    coordinate between X and Y the moment that the 
    VC-12 paylaod bandwidth will be taken into service 
    in the EPL connection.

==> NCC (?) or NMS will configure the ETH
    traffic conditioning function (refer to G.8010) with
    the appropriate parameters; e.g. bandwidth of 10M.

==> Connection Controller creates two groups of 3 VC-12
    connections (trails) between X and Y.

==> if EPL bandwidth is to be increased at a later time
    to e.g. 16 Mbit/s with 60% survivability, then a
    VC-12-10v would be required of which 5 VC-12's should
    go via route 1 and the other 5 via route 2.

==> the NCC (?) or NMS configures the
    two X and Y endpoints of the EPL for VC-12-10v
    and orders the Connection controller to extend
    the two groups of 3 VC-12 connections to two
    groups of 5 VC-12 connections.

==> also the ETH traffic conditioning function is to
    be reconfigured; now it should allow 16M.

==> once one fo the 4 additional VC-12 connections is setup,
    the LCAS processes in the two endpoitns X and Y will add the
    its associated paylaod bandwidth to the EPL bandwidth.

Summary: The creation or modification of an EPL requires
to configure the atomic functions (see G.783/G.806) in 
the "EPL ports" at the two endpoints and typically the setup 
of two or more groups of diversely routed VC-n connections (trails).

You state:
> My point in the draft is to enough apply the advantages
> of the GMPLS signaling protocol in order to simplify
> the LCAS operations.

I hope it has become clear that LCAS operation is independent
of GMPLS signalling protocol and GMPLS can't simplify it.
LCAS is a data plane protocol which informs a receiver (sink)
about the exact bit position when it should start (or stop)
reading bits from the payload of a VC-n signal. As such it 
synchronises a receiver with its upstream transmitter.

Note: LCAS only works when there is a bidirectional connection 
present. Nevertheless, LCAS takes the payload bandwidth 
of a VC-n for each direction independent into service. 



It will be common that two EPL ports have different XMT 
(see 10.1/G.806) values; e.g. one port has 10 VC-12 
termination functions, whereas the other port has 
15 VC-12 termination functions. This is independent of
LCAS, it is VCAT related. 

VCAT ports may appear in different architectures: 
A) a dedicated group of XMT VC-n termination functions per port
B) a shared group of N VC-n termination functions for M ports;
   N <= XMT_1 + XMT_2 + .. + XMT_M

If two ports X and Y are to be connected, four situations are possible:
1) X: A-type port with XMT=i,
   Y: A-type port with XMT=j
2) X: A-Type port with XMT=i
   Y: B-type port with XMT_Y=j and N = ...
3) X: B-type port with XMT_X=i and N = ...
   Y: A-Type port with XMT=j
4) X: B-type port with XMT_X=i and N = ...
   Y: B-type port with XMT_Y=j and N = ...

If i and j are not equal then a VCAT connection setup
is limited to min(i,j).

If i and j are equal and one or both ports are B-type ports,
then a VCAT connection adjustment (bandwidth increase)
may fail if all N VC-n termination functions are already
in use by the M ports. I.e. N < XMT_1 + .. + XMT_M.

For the case there is no higher authority that is aware of the
particular XMT and N values of the two ports, or if this
information isn't shared after a VCAT connection is
created, then a request to increase the bandwidth of the
VCAT connection may fail under the above conditions.
But again, this has nothing to do with LCAS.

Up to so far.

Regards,
Maarten
PS. Appendix VII/G.806 01/2004 provides "Examples for the operation 
of the processes within LCAS-capable adaptation functions". Reading
is recommended.

---------------------------------------------------------------------
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
Mobile: [phone]
Email:[e-mail]




[e-mail]
Sent by: [e-mail]
26-02-2004 04:51

 
        To:     [e-mail], [e-mail]
        cc: 
        Subject:        [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt


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.