[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
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: +31 65 141 8140
Email:Maarten.Vissers@alcatel.de
yhwkim@etri.re.kr
Sent by: owner-ccamp@ops.ietf.org
26-02-2004 04:51
To: gnewsome@ieee.org, ccamp@ops.ietf.org
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.