Subject: Draft liaison response to ITU on GMPLS Calls

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Jan 2008 19:43:45 -0000

Hi,

We need to respond to a liaison from ITU-T Study Group 15 Question 14.
https://datatracker.ietf.org/liaison/369/

Please comment before Saturday February 1st so I can send this in time.

Thanks,
Adrian

====
To: ITU-T Q14/15
Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, CCAMP 
Mailing List
Subject: Respnse to Your Liaison on GMPLS Calls
In Response

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Jan 2008 20:10:53 -0000

Duh-oh!

Before Saturday February 2nd.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; <[email-masked]>; "Scott Bradner" 
<[email-masked]>; "Brungard, Deborah A, ALABS" <[email-masked]>
Sent: Tuesday, January 29, 2008 7:43 PM
Subject: Draft liaison response to ITU on GMPLS Calls

> Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, 
> CCAMP Mailing List
> 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.
>
> or delivery of the [call] message, but may be used [by call controllers] 
> to identify the destination UNI and hence [the destination] Network Call 
> 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.
>
> 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
> course, contribution-driven. We would welcome input from all sources 
> either through the CCAMP mailing list or through liaisons.
>
> Best regards,