Subject: VCAT draft liaison questions from the ITU-T -- draft response

From: Greg Bernstein <[email-masked]>
Date: Wed, 02 May 2007 15:45:34 -0700

Hi Adrian et. al. here is the list of questions from the ITU-T liason on 
the VCAT/LCAS draft, and my first attempt at answering some of them.

   1. Would CCAMP consider generalizing the draft so that it could be
      applied to any Inverse Multiplexing scheme? For example, if
      generalized, the method could be used to establish H.244, ML-PPP,
      ATM inverse mux, or BONDING connections.

** Generalizations would be considered if there is interest and within 
scope. Note that the other inverse multiplexing schemes listed are 
packet forms rather than circuit forms of inverse multiplexing and hence 
may have more configuration parameters than VCAT.

   2. Does the I-D describe VCAT call signalling?

** It currently uses a call mechanism to set up the multiple server 
connections used in a VCAT group (connection). However, a mechanism is 
under consideration and in the draft, for dealing with a call involving 
multiple VCAT groups. This was aimed at a particular application and may 
or may not be suitable for a general VCAT call (i.e., involving multiple 
VCAT layer connections).

   3. Does the I-D allow LSPs in a server layer to be set up without any
      prior knowledge of a possible VCAT layer, and then at a later
      point in time allow those LSPs to become available to a VCAT layer?

** Note that VCAT groups can only consist of a single server connection 
type and cannot be mixed, e.g., VC-3 and VC-4 components cannot both be 
in the same VCG. Currently there is a constraint that prevents 
reassigning an LSP to another “call” (in our case a VCAT group) after it 
has been assigned to a call (or no call). <Adrian, is this correct?>

   4. Does the I-D allow the association of a VCAT call to multiple
      server layer calls?

** This is not specifically addressed. Currently the draft address VCAT 
connections via a call mechanism consisting of multiple server layer 
connections.

   5. Does release of a VCAT call automatically imply release of the
      server layer call(s)? This is not required by G.8080 as layers are
      assumed to be independent.

** The release of a VCAT connection which consists of multiple server 
layer connections would imply the release of the server connections.

   6. Is VCAT layer addressing assumed to be the same as that of the
      server layer?

** Yes.

   7. Are the two VCAT layer Call Controllers assumed to have direct
      signalling connectivity?

** Yes.

   8. If multiple client layers are using the same VCAT layer as their
      server layer, how can the VCAT layer call be identified for use in
      the client layer signalling?

** Not sure what the intended application here. Please furnish an 
example scenario. Are you looking for some kind of call identifier?

   9. Have you considered using the ASON call id [RFC3474] at all layers
      to achieve separate call control of the VCAT and server layers?

** No. But, the solution offer in the draft is tentative and there are 
many folks from the OIF and ITU-T that have been made aware of the 
contents prior to publication. The editor would be happy to see suggestions.

  10. In the ASON architecture [G.8080], it is not assumed that a single
      signalling protocol is used in all domains. Even in the case the
      same protocol is used in all domains, the RSVP session changes
      between domains. Could you explain how the Notify mechanism used
      for call control would work across multiple domains where the RSVP
      session changes?

** No, this is more a call control question than a VCAT/LCAS question 
and is beyond the scope of the VCAT draft.

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