Subject: Darft liaison #4 - GMPLS Calls

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 Aug 2007 14:24:26 +0100

Hi,

Comments on this draft liaison please.

It is in response to 
https://datatracker.ietf.org/documents/LIAISON/file450.doc

Plan to send it on 18th August, so comments before then.

Thanks,
Adrian and Deborah

==
To: ITU-T Q14/15
From: IETF CCAMP
In Response
Subject: In answer to your questions on GMPLS Calls

The CCAMP working group of the IETF thanks you for your continued 
correspondence on GMPLS Calls.

Please note that "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in 
Support of Calls" has now been published as RFC 4974 available from 
http://www.ietf.org/rfc/rfc4974.txt.

In your liaison 'Reply to IETF CCAMP Liaison "GMPLS Calls" produced at your 
June plenary in Geneva you raise two points.

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."

Thank you for this pointer. We are aware that a number of applications 
require different call identifier formats (or Long Form Call Identifiers in 
the language of RFC 4974). For this reason, RFC 4974 is careful to place no 
restrictions on the form of the call identifier, and we expect that ASON 
call identifiers can be carried in GMPLS Call messages.

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."

Thank you, again. We are also aware that a number of applications may need 
to exchange information transparently between call controllers. We agree 
that the end-point identifier is such a piece of information, and that the 
address family may be specific to the application that the call is 
supporting (in this case ASON). We expect that a generic end-point 
identifier object will be defined for inclusion in the GMPLS Call messages 
(with sub-types to indicate the address family) when the first application 
that needs them is documented.

Regards,
Deborah Brungard and Adrian Farrel
Co-Chairs, IETF CCAMP Working Group

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Aug 2007 16:04:02 +0100

Thanks for comments on and off the list.

Here is an update.

 It is in response to 

 Thanks,
Adrian and Deborah
 
==
To: ITU-T Q14/15
From: IETF CCAMP
In Response

Please note that "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions 
in Support of Calls" has now been published as RFC 4974 available from 
http://www.ietf.org/rfc/rfc4974.txt.

In your liaison 'Reply to IETF CCAMP Liaison "GMPLS Calls"' produced at 
your June plenary in Geneva you raise two points.

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."

Thank you for this pointer. We are aware that a number of applications 
require different call identifier formats (or Long Form Call Identifiers
in the language of RFC 4974). For this reason, RFC 4974 is careful to 
place no restrictions on the form of the call identifier, and we expect
that ASON call identifiers can be carried in GMPLS Call messages.

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."

Thank you, again. RFC 4974 (and, indeed, the whole of the GMPLS 
architecture) is predicated on the use of IP addresses, so that we
expect Call Controllers and connection end-points to be IP-addressable.
However, we understand that Call Controllers and their associated 
applications may wish to exchange transparent information (such as TNAs)
that is used in the context of those applications, for example to derive
IP addressing information and to identify resources or applications. In
view of this, we expect that a generic end-point identifier object will 
be defined for inclusion in the GMPLS Call messages (with sub-types to
indicate the address family) when the first application that needs them 
is documented. At the moment, it looks as though the first such 
application will be ASON, and we expect work to resume on the ASON
applicability draft in the latter part of this year.

Regards,