Liaison statement
In answer to your questions 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 | 2007-08-24 |
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> David Ward <dward@cisco.com> Scott Bradner <sob@hardward.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 |
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 raised 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 encoded and 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, Connection 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. We may consider that the Call message (i.e. the Notify message) uses IP addressing to achieve delivery, but may carry transparent information on behalf of its client application (i.e. the Call Controller). Such information is not used in the propagation or delivery of the message, but may be used freely by the application for any purpose. WHen this is the case in IETF protocols, the payload is often presented as a fully transparent object. In some cases, however, commonly applicable (that is, applicable to multiple different applications) objects may be defined with encoding rules. We expect that a generic end-point identifier object will be defined for inclusion in GMPLS Call messages 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, Deborah Brungard and Adrian Farrel Co-Chairs, IETF CCAMP Working Group |