[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New Liaison Statement, "Call/Connection Separation in ASON and GMPLS"
- To: Greg Jones <greg.jones@itu.int>
- Subject: New Liaison Statement, "Call/Connection Separation in ASON and GMPLS"
- From: Adrian Farrel (IETF CCAMP WG) <adrian@olddog.co.uk>
- Date: Wed, 04 Apr 2007 07:14:53 -0400
- Cc: Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com>, Kam Lam <hklam@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>, Adrian Farrel <adrian@olddog.co.uk>, Deborah Brungard <dbrungard@att.com>, Adrian Farrel <adrian@olddog.co.uk>, Deborah Brungard <dbrungard@att.com>
- Reply-to: Adrian Farrel <adrian@olddog.co.uk>
Title: Call/Connection Separation in ASON and GMPLS
Submission Date: 2007-04-04
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=314
Please reply by 2007-05-11
From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk>
To: ITU-T Q14/15(Greg Jones <greg.jones@itu.int>)
Cc: Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com>
Kam Lam <hklam@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: For comment
Body: The CCAMP working group of the IETF thanks you for your liaison "Liaison
Statement to CCAMP responding to ccamp liaison of 21 February 2007"
(Q14/15-LS1-E) dated March 2007.
This liaison continues a discussion on the logical separation of calls and
connections. The substance of this conversation is as follows:
SG15 to CCAMP
COM15-LS126-E dated November 2006
2.0 Call/Connection architecture and realization approaches
Attachment 2 below provides further elaboration of application
scenarios that illustrate G.8080 call/connection control
component interactions. The G.8080 architecture may be
employed to support various call control realization
approaches. It should be noted that the architecture does not
dictate any particular implementation and we would request that
any solution not impose such limitations. We observe that
Section 3.2 of <draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt>
explicitly prohibits logical call/connection control
separation; i.e., call communications "piggy-backing" on
connection communications.
CCAMP to SG15
Dated 21st February 2007
Regarding your comments on 2.0
It is important to recognize that [this draft] introduces Call
mechanisms into GMPLS as a generic tool. As noted in Section 2,
while the mechanisms of this document meet the requirements in
RFC 4139, they are intended to have wider applicability than
ASON. RFC 4139 details the requirements for ASON.
The application of the GMPLS Call to the ASON architecture in
order to satisfy the requirements for conveying ASON Call
information across a GMPLS interface and for managing ASON
Calls at a GMPLS UNI or GMPLS ENNI will require a new
Applicability Draft.
Thus, section 3.2 of this document does not imply anything
about ASON, and certainly not that ASON requires full and
logical call/connection separation.
We understand that ASON Calls may be implemented through
full call/connection separation (as in G.7713.3) or
call/connection 'piggybacking' as in G.7713.2. Please
confirm that our interpretation of G.8080 and G.7713 is
correct.
SG15 to CCAMP
Q14/15-LS1-E dated March 2007
Regarding call and connection separation the liaison states:
"We understand that ASON Calls may be implemented
through full call/connection separation (as in G.7713.3) or
call/connection 'piggybacking' as in G.7713.2. Please
confirm that our interpretation of G.8080 and G.7713 is
correct." ASON requires full logical separation of the call
and connection which may be implemented with separate
or piggybacked call and connection signalling.
We would like to complete this discussion by reiterating that
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt defines mechanisms that
provide full and logical Call/Connection separation. Your initial
interpretation of section 3.2 of draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt
was incorrect and the text states now (and stated then) that "Full and
logical Call and Connection separation is required."
If you have any further concerns about how call and connection separation is
achieved in this work, please do not hesitate to contact us.
Best regards,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP working group
Attachment(s):
No document has been attached