The CCAMP Working Group thanks you for your liaison of September 2007
(Q12-14 Interim meeting - LS 005).
Here are our responses to the issues in your liaison:
Per Question 1: We provide here further clarification regarding our
previous comment re protocol extensibility to encompass technologies
other than SONET/SDH. An example technology of interest to the
community was provided regarding the usage of virtually concatenated
ODUs for carriage of IEEE 802.3 HSSG proposed 100 Gbit/s over an
existing OTN infrastructure. How this is accomplished is not defined
at this time and might not be using VCAT. A technology neutral approach
(i.e., one not dependent upon VCAT over SONET/SDH-unique parameters)
would avoid the need for developing a series of specialized solutions.
Our response: As we noted previously, it is certainly our intention
that functionality and any protocol extensions that we develop should
be easily extensible to support other than SONET/SDH technology,
especially technologies covered by GMPLS (e.g. OTN). This is the basis
of GMPLS and GMPLS call functionality development. If you have
identified any specific concerns with the current approach, we would
appreciate your input.
Per Question 2: VCAT group signaling relates closely to multi-layer
call modeling, and it is our understanding that the draft is only
addressing the constituent server layer call. We plan to perform
further work to clarify the interlayer call relationship in terms of
the ASON multilayer "call supporting call construct".
Our response: Noted. We look forward to further communication from
Per Question 3: We agree that connections are not moved between
calls; the ASON "call supporting calls" construct is consistent with
not moving connections between calls. Rec. G.7041 and G.7042 are only
concerned with membership of the VCAT group, and not with the use of a
member that has been removed (it is assumed to simply go back into the
pool of resources, where it can be drawn upon for other purposes). Thus
G.7041 and G.7042 do not support the direct movement of a connection
from one VCAT group to another. Changing the association of a server
layer call/connection to a VCAT group does not necessarily result in
removal/deletion of that call/connection.
Our response: Noted.
Per Question 4: We appreciate your clarification of the use of a single
call. However we suggest that you do not preclude extension to use
multiple calls. This is useful for example in diverse routing
Our response: As noted in our previous liaison, the call construct as
proposed in this draft is used to coordinate the (single type) server
layer connections for the VCAT functionality. This does not preclude
use of RFC 4974 in support of G.8080 call functionality. To ensure that
we understand correctly your request, can you provide additional
information regarding using multiple calls in support of diverse
Per Question 5: We understand that this draft is only addressing the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.
Our response: As noted above, this is not precluded. We look forward to
future communication from you as you progress this work.
Per Question 6: We understand that GMPLS only supports the IP address
format, and that the actual addresses may be different in each layer.
We believe it would be useful to clarify the difference between
addresses used in regards to delivering messages to a control
component, and identifiers used for the forwarding plane resources
Our response: Please refer to RFC 4990. This draft does not modify
existing procedures. If you have any questions with regard to GMPLS
addressing, we welcome informal dialogue on the CCAMP exploder and, of
course, you may also ask via Liaison.
Per Question 7: Thank you for the clarification which confirms that
the VCAT layer Call Controllers are assumed to be adjacent from a
control plane perspective.
Our response: Noted. To ensure that we understand your comment on
"direct signalling connectivity" and "adjacent": to be precise, it is
assumed that the Call Controllers can exchange call control messages.
This does not require that they be adjacent.
Per Question 8: Thank you for the clarification.
Our response: Noted.
Per Question 9: Based upon your observation, we view that a protocol
independent definition of the call ID should be abstracted from
G.7713.2, where it is expressed in protocol specific terms; the most
appropriate Recommendation for this definition would be G.7713.
Our response: Thank you for the clarification. Please keep us informed
as you make this change.
Per Question 10: Your interpretation of G.8080 is correct regarding
E-NNI reference points and adjacent call controllers. There is no
reference to RSVP sessions in G.8080; it was used as an example of the
consequence of using different protocols in different domains. It is
our understanding from the discussions that concatenated GMPLS RSVP-TE
connections (homogenous signaling protocol) that are part of the same
end-to-end network connection do not need to change the session object,
and policy could be applied at a transit (inter-domain) hop. Please
confirm that our understanding is correct.
Our response: Your understanding is correct that even though one
session is used, policy may be applied by any processing node (call
controller) of the call message, and RFC4974 supports multiple call
managers along the path between ingress and egress. Please refer to RFC
4974. Note, the RSVP signaling protocol model allows for the
application of local policy by any processing node of the request
(regardless if a connection or call).
The latest version of this work can be found at:
A new version is expected relatively soon. The latest versions of all
CCAMP Internet-Drafts can always be found at the CCAMP charter page
We welcome any further comments.
Adrian Farrel and Deborah Brungard
IETF CCAMP working group co-chairs