Liaison statement
GMPLS Signaling for VCAT/LCAS

The CCAMP Working Group thanks you for your liaison of
April this year (COM15-LS3-E) and for your interest in our
work to develop GMPLS signaling extensions for the control
of VCAT within TDM networks.

The latest version of this work can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-02.txt
We expect a revision relatively soon, so if the referenced
link fails, please also check at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03.txt

Here are our responses to the questions in your liaison.

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.

It is certainly our intention that any protocol extensions
that we develop should be easily extensible to other
technologies. But at the same time we have seen no
immediate interest from the community in applying GMPLS as
a control plane for any of the technologies that you list.
It would, of course, be a prerequisite of using GMPLS for
such an inverse multiplexing scheme, that GMPLS was also
used to build network connections (i.e. LSPs) for the
specific technology.

If you have a requirement to use GMPLS to control these
technologies, we would be interested to hear from you. In
the mean time, we note that the inverse multiplexing
schemes that you list are packet/cell forms rather than
circuit forms of inverse multiplexing and hence may have
different configuration parameters than VCAT.


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

The I-D uses GMPLS Calls (RFC 4974) to achieve VCAT group
signaling. The GMPLS Call is used to coordinate the setup
of multiple server connections (LSPs) used to form a VCAT
group (a connection in the VCAT layer).


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?

When a network connection is established at the request of
an operator or a management system, we have assumed that
there is some motivation, and that the motivation is
expressed in the call that coordinates the connection. In
RFC 4974, the nature of the call can be changed (as a
matter of call parameter exchange that is within the scope
of the call controller function, but the details of which,
except for the message exchange rules, are outside the
scope of the signaling protocol), but the connections
cannot be moved from one call to another.

Thus, LSPs that are set up in association with a specific
call can only be used as directed by the call controller
with responsibility for that call. If a call controller
decides to use the connections (LSPs) for VCAT one day and
for something else another day, that is entirely within its
remit. However, this assumes that the call controller can
suitably instruct and coordinate the necessary adaptation
functions at each end of the network connections. An
implementation might find it more convenient to release the
call (and the associated connections), before setting up a
new call and a new set of connections.

Note that we are considering mechanisms to allow LSPs to be
moved between VCAT Groups according to the requirements of
the network. Such schemes necessarily mean that there is
not always a 1:1 relationship between calls and VCAT groups
since it remains the case that connections cannot be moved
between calls. However, our understanding of G.707 and the
ability to move component trails (VCAT group members)
between VCAT groups while the trail is in service is
unclear, and we would welcome clarification of the
requirements before progressing this function further.


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

This is not specifically addressed. There is no hierarchy
of calls described in the draft. Instead, the draft
provides for a single call that is used to coordinate all
of the server layer connections that support the single
VCAT service. In practice, this may not represent
architectural purity, but we believe it is a protocol
implementation simplification consistent with the way that
VCAT is operated.

We 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.


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.

As noted for point 4, the VCAT layer call is not
specifically called out in the draft. You may consider that
the draft provides a mechanism for handling the (single
hop) VCAT call and the server layer call as a single item.
We would be interested to hear from you the operational
circumstances under which a single VCAT layer call might
give rise to multiple server layer calls.

The signaling of the release of a GMPLS Call is rejected if
connections are still in place (per RFC 4974 section 6.6.4)
which is consistent with the connections having been set up
under the instructions of the call controller and in
support of the call. Thus, operationally, the release of a
call will require the release of the associated
connections.

At this point it may be worth clarifying that a VCAT layer
connection is created under the control of a VCAT layer
call. The VCAT connection may require server layer
connections (indeed, this is always the case with VCAT) and
those connections need to be associated and controlled by a
call. it is this second type of call that we are we are
describing in this draft.

Thus, the release of a VCAT call would lead to the release
of the VCAT connection. The network policy may determine
whether to release the server layer call or not. If the
server layer call is released, the server layer connections
will also be released.


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

GMPLS only supports IP addressing. The link connections in
the VCAT layer created by/from network connections in the
server layer may be given different addresses from the
addresses used to represent the endpoints in the server
layer, or may use the same addresses.


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

Yes, adjacent call controllers in any layer are assumed to
be able to exchange call control messages without the
intervention of any proxy, agent, or extra-layer entity.


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?

How is this problem any different from any other n:1
client/server relationship? Please supply details of why
the fact that the server layer is a VCAT layer should make
this scenario any different.

Please also note that, as for point 5 above, the VCAT layer
call is not what is being addressed in this draft. We are
addressing the server layer call that coordinates the
server layer network connections that are used as VCAT
group members to construct a VCAT group that can be
presented as a link connection in the VCAT layer.


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

The format of the call ID is deliberately out of scope for
this work as we would not wish to control or enforce the
applicability of this work in any one environment. However,
RFC 4974 (as noted in a recent separate liaison from us on
GMPLS Calls) allows any format call ID to be encoded in
GMPLS calls. Thus, the ASON call id format described
informationally in RFC 3474 can be supported and used in an
ASON environment at the choice of the operator and/or the
implementer of the call controller.

Can you please confirm that the normative definition of the
ASON call ID is in G.7713.2? Other Recommendations (such as
G.7713.3) also appear to have call IDs defined, and we want
to make sure that we can reference a single, protocol-
independent definition of a call ID


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?

This question clearly has wider relevance than this VCAT
draft and should be seen in the context of RFC 4974, and
not in reference to this draft.

We note that G.8080 makes no assumptions about connection
signaling protocols in adjacent domains, but we believe
that the architecture does assume an E-NNI reference point
in association with one or more call controllers at such
domain interfaces. The E-NNI call controllers are
responsible for requesting the necessary network
connections in each domain and, where the E-NNI is
externalised, for requesting any inter-domain connections.

Call messages are exchanged between adjacent call
controllers and relate to the network connections
established at the request of those call controllers. When
two adjacent GMPLS domains support the same end-to-end
network connection, we do not recommend that the session
object be changed.

Please clarify where in G.8080 there is any reference to
RSVP sessions. There should be no such discussion of
protocol implementations in an architecture document.


We would welcome your opinions on these responses and the
direction of our work.

In your liaison you stated that you had the intention to
review the draft further at your June meeting. But in the
liaison from your June meeting (COM15-LS170-E) you say that
you deferred this review pending further revisions of the
I-D. This is quite reasonable, but we would nevertheless
welcome any further high-level comments that you may have.
We will notify you as this draft is updated.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs