Liaison statement
GMPLS Signaling on VCAT/LCAS
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2008-02-29 |
From Group | ITU-T-SG-15 |
From Contact | Hiroshi Ota |
To Group | ccamp |
To Contacts | 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 |