datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Liaison Statement: GMPLS Signaling on VCAT/LCAS

Submission Date: 2008-02-29
From: ITU-T SG 15 (Greg Jones)
To: IETF CCAMP WG (adrian@olddog.co.uk, dbrungard@att.com)
Cc:sob@harvard.edu
rcallon@juniper.net
dward@cisco.com
lberger@labn.net
ccamp@ops.ietf.org
yoichi.maeda@ntt-at.co.jp
sjtrowbridge@alcatel-lucent.com
Response Contact: tsbsg15@itu.int
Technical Contact: hklam@alcatel-lucent.com
Purpose: For action
Deadline: 2008-09-15 Action Taken
Attachments: LS222 - body text in pdf
Body:
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