Received liaison on VCAT from ITU-T

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

The ITU-T SG15 has responded to our liaison on the VCAT/LCAS work. A 
response is requested by 15th September 2008.

The liaison also contains a short comment on our liaison about GMPLS calls.

You can see the liaison through the ccamp page www.olddog.co.uk/ccamp.htm

The text of the liaison is included below.

Adrian

===

Q14/15 thanks you for your liaison of 1st February 2008
(https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=415, which 
is TD515 (WP3/15)).

Here are our comments to the responses provided in your liaison:

a) Regarding your response to Question 1 on protocol extensibility to 
encompass technologies
other than SONET/SDH, we notice that the recent I-D 
(draft-ietf-ccamp-gmpls-vcat-lcas-
04.txt) limits the number of VCGs per call to one. We support this position 
and consider this
to be a VCAT call.

b) Regarding your response to Question 4 on multiple calls support, VCAT is 
viewed as a layer
of its own and has its own call controller. As per the interlayer 
architecture in G.8080
section 6.6, the VCAT call would be associated with a server layer call or 
calls, each of
which would have/own one or more server layer connections. It is these 
connections that
are part of the VCG. In retrospect, a single call is sufficient for diverse 
routing as it can hold
details of both connections so that they don't use the same resources.

An example where multiple server calls associated with one VCAT call would 
be useful is
when all VCAT connections are to be protected. Here, rather than one call 
maintain the
knowledge of all working/protection pairs, it is simpler to have multiple 
calls each of which
only maintains one working/protection pair. This is even more convenient 
when restoration
behavior is applied when the protection connection fails.

c) Regarding your response to Question 6 on IP address format in GMPLS, we 
suggest the I-D
clarifies that there are different name (or identifier) spaces even though 
they may all use the
same IP address format, e.g.

- Control component
 The identifiers used to identify the entities that perform the control 
plane
 functions, such as route computation, signaling, control plane message
 delivering, etc.

- Transport resource
 The identifiers used to identify transport resource when they are referred
 to in the control plane messages. Note that these identifiers may not be
 the same as those referred to in the management plane messages.

- SCN
 The addresses used to deliver control plane messages

Examples of a similar address format in use in two different name spaces can 
be seen in the
OSPF routing protocol, where router ID (control and transport link scope) 
and IP address
(used by the forwarder) do not have to be the same.

Regarding your liaison response on GMPLS Calls
(https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=414, which 
is TD516 (WP3/15)),
thank you for your response. We do not have any further reply at this time 
and appreciate the
invitation for future input to CCAMP.

An electronic copy of this liaison statement is available at:
ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html