|
Hi,
We have been copied on a liaison from ITU-T SG15 Q12 and Q14 to the OIF. The text is below. I will put a copy on the web at http://www.olddog.co.uk/ccamp.htm No action appears to be required from CCAMP at this stage. Thanks, Adrian ======= Source: ITU-T SG15 Q12, 14/15 Title: Response Liaison Statement to OIF on OIF Demo Finding To: Jim Jones, OIF Technical Committee Chair Cc: IETF CCAMP WG Co-chairs Approval:ITU-T SG15 Q14/15 Interim Meeting, Stuttgart (Germany), 18-22 July 2005 For: Action Deadline:14 November 2005 Contact:Hing-Kam Lam (hklam@lucent.com) Contact:Malcolm Betts (betts01@nortel.com) Thank you for sharing OIF UNI 2.0 work with SG15. For the Ethernet feature, we note the alignment with the Ethernet series Recommendations developed in SG15. We also appreciate the significant effort required to accomplish the recent OIF Interoperability Demo, and some of the issues that were identified in your liaison. As requested, please find our replies to the issues below. 1. Call identifier format sent by an originating UNI client. (Q14 only) Q14 agrees that the issue exists in G.7713.2 and accepts the OIF
recommendation to define that message for C-Type=0 in a future G.7713.2 update.
It should be noted that while G.7713.2 and RFC3474 already specify the use
C-type=0, a request to IANA for C-Type=0 was accidentally neglected when
processing RFC3474. This oversight needs to be resolved.
2. Use of the NVC field for VCAT connections (Q14 only) There are two issues that have to be considered in this question.
First, in what order the VCAT vs server layer calls are created, and second, if
the server connections should be co-routed or not.
When creating a VCAT call, the request could start from the client layer
which then results in the creation of server layer calls. In this case
when the server layer connections are created, it is known that they will
participate in a VCAT group (VCG). The opposite can also occur where there
are server layer connections are already in place and VCAT call obtains them for
the VCG. Here, no signalling in the server layer is needed for the server
layer calls. In the first case, setting the NVC field could be done in the
server layer calls as it is known that they will be part of a VCAT call.
In the second case, the original signalling used did not know that the call
would be part of a future VCAT call and hence the NVC field remains
zeroed. To accommodate the case where existing connections are added to a
VCG, it appears that the NVC field is not relevant.
In the SONET/SDH TSPEC where NVC is defined, the implied purpose is to
create LSP signalling state for single session that may have multiple SONET/SDH
connections that are in parallel. That is, when NVC is set to >1, the
expectation is that the connections are co-routed and they follow the same
link(s) and tandem switching points. To be able to use more available
bandwidth in the server layer, it is desirable to not limit the connections in a
VCG to be co-routed. In this scenario, each connection is separately
routed and a separate connection state is needed per connection. To
accommodate this degree of freedom, the NVC field itself does not appear to be
relevant to server layer signalling.
Regarding H4 byte usage, note that it is the VCAT function that uses this byte but only after the connection(s) is(are) created. So from a signalling point of view, the server layer has no need to be aware that the H4 byte is going to be used. Only the client layer (VCAT) needs to be aware and trigger the use of the H4 byte. 3. TSPEC format to be used for Ethernet connections (Q12 and Q14) Q14 and Q12 think that a new Ethernet Traffic Parameters TSPEC in RSVP-TE
is the best long-term solution for specifying Ethernet bandwidth service
parameters and will request that CCAMP considers the Q.8011/MEF.6 Ethernet
service parameters and construct a suitable TSPEC for it that can be used in the
UNI. We also suggest that the OIF similarly corresponds with
CCAMP.
An electronic copy of this liaison statement is available at: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html |