Subject: Copy of a liaison from ITU-T SG15 to OIF

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Sep 2005 21:24:29 +0100

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 ([email-masked])
Contact:Malcolm Betts ([email-masked])
 
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:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html