datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

Liaison Statement: Reply to IETF CCAMP Liaison "GMPLS Calls"

Submission Date: 2007-06-26
From: ITU-T SG 15 (Greg Jones)
To: IETF CCAMP WG (adrian@olddog.co.uk, dbrungard@att.com)
Cc:rcallon@juniper.net
dward@cisco.com
sob@harvard.edu
ccamp@ops.ietf.org
sjtrowbridge@alcatel-lucent.com
yoichi.maeda@ntt-at.co.jp
greg.jones@itu.int
Response Contact: tsbsg15@itu.int
Technical Contact: hklam@alcatel-lucent.com
Purpose: For comment
Deadline: 2008-01-28 Action Taken
Attachments: Reply to IETF CCAMP Liaison "GMPLS Calls" - body text
Body:
We understand from your liaison that
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in support of Calls", is awaiting formal
publication by the RFC Editor, and that it is applicable to more than
just the ASON architecture.
There are a few comments we have on identifiers and addressing for
calls that arise from reading
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt.
1.	Call identifiers.  Please note that G.7713.x series has a call
identifier format.  For G.7713.2, this is described in RFC3474 and has
RSVP class num of 230.
2.	Specifying the destination of a call in ASON is done with a UNI
Transport Resource identifier (G.8080 section 10.2).  For G.7713.2,
this is described in RFC3476 as a Transport Network Address (TNA) and
has RSVP class num of 229.  We suggest that an equivalent should be
included in a future ASON applicability draft.
At the time of assignment, both of these class num values were in a
range with the semantics that “RSVP will silently ignore, but FORWARD
an object with a Class Number in this range that it does not
understand.�  Thus, usage of these would not pose problems for RSVP
instances that did not process calls.  Use of these objects has been
successfully implemented in OIF interoperability demonstrations.
An electronic copy of this liaison statement is available at: 
http://ties.itu.ch/ftp/public/itu-t/tsg15opticaltransport/COMMUNICATIONS/