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

[Maarten.Vissers@alcatel.de]

Young,

The management associated with the LCAS functionality is just a 
small part of the total management of a VCAT Termination Point. 
I believe that we should not tackle just a small piece of it
(LCAS), but take the whole on our plate.

Some considerations for you (and the other readers):

Let me start with a short intro before tackling the VCAT TP case.
I differentiate between 
- SubNetwork Connections (SNC) ("east-west") and 
- Network Connections (NC) ("north-south").

Subnetwork connections (SNC) in SDH/SONET - these days without 
any real deployment of TCM - are more or less pure bearer plane
connections without any dedicated connection monitoring.

SNCs in OTN in the future will be with ODUk TCM, and will be a 
combination of bearer plance connectivity and (nested) connection
monitoring (service provider (SP), network operators (NO1, NO2, 
NO3)) of which the latter requires configuration (via GMPLS) of the 
Termination Points providing the connection monitoring.

Network connections (NC) in SDH/SONET/OTN will always be a 
combination of bearer plane connectivity and connection 
monitoring (the trail end points) and thus requires configuration
of the Termination POints providing the connection monitoring.

Non-VCAT/LCAS example:
======================
A DS3 call request results as such in a STS-1/VC-3 Network Connection
request plus configuration of the two STS-1/VC-3 termination points
(expected trace ID, error thresholds, payload type, ...).

The STS-1/VC-3 termination points will be part of two STS-1/VC-3 Access 
Groups with say N and M members. The DS3 call translates as such
in a STS-1/VC-3 connection request between AG1 (N members) and AG2 
(M members). 

Like the LRM (link resource manager) there is an Access group Resource
Manager (ARM) for each AG. The connection request will result that 
ARM1 will select one STS-1/VC-3 termination point from AG1
and ARM2 will select one STS-1/VC-3 termination point from AG2 to be
the endpoints of the STS-1/VC-3 network connection. 

Once selected, the ARMs have to exchange termination point information,
including transmitted TTIs (=> becoming expected TTIs at other end), 
payload type, etc.

VCAT/LCAS example:
==================
With this model in mind, we can now have a look at the VCAT cases.
For VCAT we have to distinguish two cases:
1) shared set of K VC-n termination functions flexibily connected
   to L client ports (e.g. Ethernet), each with XMT=M 
   (or M1, M2, .., Ml); K <= M1 + M2 + .. + Ml.
2) dedicated set of M VC-n termination function per client port; 
   with L client ports there are L groups of M VC-n termination
   functions.

Ad 1) In this case the K VC-n termination functions belong to one
      Access Group with K SNPs and L APs, and the ARM will be 
      responsible to select a VC-n termination point (SNP) when a 
      VC-n network connection request is received. The ARM 
      furthermore has to configure the AG such that the selected
      SNP is connected to the appropriate AP. Furthermore, it has
      to configure the VC-n termination point with expected TTI, 
      LCAS: XPT, etc.
      Note - the AP may be fixed and part of the connection request;
      i.e. it may represent a physical interface port to the customer.
      But in case the VCAT port is connected to a bridge fabric
      (case of EVPLAN), then the ARM may initially also have to
      choose the AP (and thus bridge fabric port).

Ad 2) In this case there is an inner set of L Access Groups that each
      have M VC-n termination functions (and SNPs) and one AP. Those
      inner AGs are part of an outer AG that holds now these L
      inner AGs each representing a VCAT port. The ARM for this
      outer AG is responsible to select one of the L inner AGs
      when a new VC-n-Xv network connection is to be setup; e.g.
      when the VCAT port is a bridge fabric port. When the VCAT
      port is connected to e.g. a physical Ethernet interface,
      the AP may well be fixed and part of the connection request.
      In either case, the ARMs have to exchange configuration
      information including transmitted/expected TTI, LCAS: XPT, etc.

When there is a connection to be created between two physical ethernet
interfaces, the physical ports are fixed (cable connections) and the
VCAT information (e.g. value of XMT in port A and port Z) is known.
The min(XMT_A, XMT_Z) becomes a parameter of this connection and
is an upper limit of the bandwidth of the e.g. EPL.

When there is a connection to be created between e.g. two EoSDH
bridge ports (on request of the ETH topology manager), the request
may leave the choice of the AP to the ARMs (case of all ports are
equal). In this case the ARMs have to make such selection and
present this to the bridge to indicate the port that will be used for
this new (topo)link.


Now we can address the extension of an existing VCAT connection.
In this case there is a VCAT conneciton with XMT_A=a, XMT_Z=z and
XPT=p (p < a, p < z). 
[XMT is max number of VC-ns in the VCAT group, XPT is provisioned
number of VC-ns in the VCAT group]
A request to increase bandwidth result in an increase of p; 
e.g. p:=p+1 (add one VC-n).
The call controller will issue a VC-n network connection request 
for the VCAT connection between AP_A and AP_Z. ARM_A and ARM_Z will
be requested by their local connection controllers to provide a
SNP (VC-n term point) associated with AP_A [AP_Z] as endpoints
of the VC-n nework connection to be setup. With the handing over
of the specific SNP, the ARMs should also hand over the associated
configuration information of the termination point (including
transmittedTTI, LCAS: XPT=p+1, etc). This configuration information
is to be exchanged with the far end ARM to have both endpoint 
correctly configured.

Once this additional VC-n netowrk connection is created, the VC-n
termintion functions at both AGs are configured and can verify
if the connection setup is correctly performed; if not, there will
be a dTIM (trace mismatch) condition. This is sufficient for the
case 2 VCAT architecture (dedicated set of VC-n termination points
per port). For the case 1 VCAT architecture (shared set of K VC-n term
points for L ports), the AG may misconfigure the VC-n term point - AP
relationship. In this case the GID will be able to identify the
configuration problem.

So, it is a matter of defining the appropriate AGs and ARMs and to 
have ARMs (ARM_A, ARM_Z) exchange configuration information via GMPLS. 
For VCAT ARMs this includes the VCAT and LCAS configurations.

Regards,
Maarten







yhwkim@etri.re.kr
29-02-2004 10:12

 
        To:     Maarten VISSERS/DE/ALCATEL@ALCATEL
        cc:     ccamp@ops.ietf.org
        Subject:        [Re] Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt


Hi, 
Thank you for your detailed explanation. 
For your example of the call request for EPL of 10 M that I think is a 
uni-directional case, 
if a GMPLS signaling protocol is used, maybe two LSPs will be established 
with only uni-diretional connections 
because their paths are different each other. The case is not my hope. 
My intention is not to simplify the LCAS operation itself, but to simplify 
the initiation processes invoked by EMS/NMS systems. 
As indicated in G.7042, the operation of LCAS is uni-directional. This 
means that in order to bi-directionally add or remove members the 
procedure has to be repeated in the opposite direction.
If the two uni-directional(downstream and upstream) connections for a call 
request have the same route, 
EMS/NMS systems should invoke two times of the LCAS operations towards 
ingress and egress nodes. 
I want to reduce into only one time using a GMPLS signaling protocol. 
Thanks, 
Young.