Title: Respnse to Your Liaison on GMPLS Calls
Submission Date: 2008-02-01
URL of the IETF Web page:
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=414
From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk>
To: ITU-T Q14/15(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>
Reponse 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
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 throu
gh liaisons.
Best regards,
Adrian Farrel and Deborah Brungard
CCAMP working group co-chairs
Attachment(s):
No document has been attached