Skip to main content

Liaison statement
Respnse to Your Liaison on GMPLS Calls

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-01
From Group ccamp
From Contact Adrian Farrel
To Group ITU-T-SG-15-Q14
To Contacts Greg Jones <greg.jones@itu.int>
Cc Kam Lam <hklam@alcatel-lucent.com>
Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com>
Ross Callon <rcallon@juniper.net>
Dave Ward <dward@cisco.com>
Scott Bradner <sob@harvard.edu>
CCAMP Mailing List <ccamp@ops.ietf.org>
Response Contact Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Technical Contact Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Purpose In response
Attachments (None)
Body
Thank you for your liaison to CCAMP on GMPLS Calls from your Stuttgart interim
meeting in September 2007.

In your liaison, you noted that the GMPLS call is assumed to be as general as
possible, and you asked what other call applications there may be in addition
to ASON and the CCAMP VCAT draft. At this moment, there are four applications
on which the CCAMP working group is working where GMPLS calls are applied. The
first two are ASON and VCAT as you note. The third is related to ASON and is
the multi-layer network. The fourth provides support for the MEF UNI in
coordination with the OIF. Other topics in the future might include OAM
coordination, billing, and client-facing port capability negotiation.

Your observations about how TNA information is not used in the propagation or
delivery of the [call] message, but may be used [by call controllers] to
identify the destination UNI and hence [the destination] Network Call
Controller agrees with our understanding and intentions. In practice, a large
range of information may be used by call controllers to route calls - that is,
to select a series of call controllers between call source and call destination
- although we would not wish to preclude source-routing of calls. It is our
intention that the generic call message should be capable of being extended to
carry any information required by any application of the call message.

In this light you ask for guidance on how to carry ASON call information across
a GMPLS network so that it can be reconstructed at ASON call boundaries, and
say that you support the resumption of work on a CCAMP I-D on ASON
applicability to address the above and would welcome the opportunity to
contribute through liaisons. We welcome your support and look forward to
working with you in this context. As above, we note that the GMPLS call message
(the Notify message) is not limited to the exchange of information between call
end points, but can also exchange information between transit call controllers
by forming call segments as described in section 7.3.1 of RFC 4974. Work on
carrying ASON call information within a GMPLS call message falls within the
CCAMP charter and we hope that interested parties will bring ideas forward
through the normal process which is, of course, contribution-driven. We would
welcome input from all sources either through the CCAMP mailing list or through
liaisons.

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP working group co-chairs