Subject: Calls, Connections and VCAT...

From: Greg Bernstein <[email-masked]>
Date: Thu, 24 Jan 2008 09:49:39 -0800

Hello all, and Adrian and "GMPLS call" authors in particular.
I've been reviewing the requirements for VCAT/LCAS and potential 
additions, the definition of "call" from G.8081 (2004) and trying to 
reconcile these in an efficient manner so we can move forward with the 
GMPLS/VCAT draft.

Definitions from G.8081:
3.2.6 call: An association between endpoints that supports an instance 
of a service.
3.2.7 call control: Call control is a signalling association between one 
or more user applications
and the network to control the set-up, release, modification and 
maintenance of sets of connections.

Additional information from G.8080 (2006) section 5.1: "Additionally, 
call control is provided at
interlayer NCC boundaries."

 From these definitions it seems that the use of "call control" to 
coordinate an inverse multiplexing technology is actually recommended 
(since this is the domain boundary between to layers).

However in trying to use RFC4974 along with the additional requirements 
that have come up (and seem desired), I seem to have a problem when I 
want to utilize an existing connection with a new call. In RFC4974.

Section 5.2.2. It says: "The Connections (LSPs) associated with a Call 
need to carry a reference to the Call - the short Call ID.  A new field 
is added to the signaling protocol to identify an individual LSP with 
the Call to which it belongs." 

This is where the complications come in, since we cannot change 
"session"  information on an LSP and hence can't change the Call ID.  
But do we always need the call ID with the LSP?  In section 4.2 of 
RFC4974 the hierarchy of of calls, connections, tunnels and LSP is given 
and it seems that (Session, Tunnel ID,  LSP ID) can be used to uniquely 
identify the LSP too.

The feedback I received concerning VCAT signaling approaches included:
(a) support for Notify based mechanism
(b) strong opposition to the current multiple VCGs per call work around 
for "resource sharing"
(c) mild interest, but no proposals in something else entirely.

Hence at this stage and based on my reading of G.8080, G.8081, I'd like 
to try to fix the "call" approach. Other solution proposals are welcome, 
but I will not be actively pursuing them.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237