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

[Greg Bernstein <gregb@grotto-networking.com>]

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