Correspondence from OIF

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Please find below the text of a correspondence from the OIF. This will be
posted on the alternate CCAMP pages at http://www.olddog.co.uk/ccamp.htm

No response is required, but we should follow up with RFC3946-bis and
through the GELS BoF.

Cheers,
Adrian
===========
To: Adrian Farrel and Kireeti Kompella, IETF CCAMP WG Co-Chairs

From: Jim Jones, OIF TC Chair

Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors

Subject: Follow up questions concerning GMPLS parameters

Dear Adrian and Kireeti,

OIF very much appreciates your help with our questions concerning GMPLS
parameters in your response liaison of October 2005. After discussion of
your liaison letter, we had a number of follow-up questions (issues are
numbered as in our liaison of July 2005):

1. NCC and RCC field values for STS-3c/VC-4 connections

The revision to RFC 3946 proposed by CCAMP looks acceptable to us. We also
agree that the receiving entity should be liberal in what it accepts,
i.e., either 0 or 1 should be accepted at the receiver. We would ideally
prefer that a single value be identified as the "recommended" value to use
by the sender, to further remove any potential interoperability issue.

2. Setting of NVC for VCAT connections

It is our understanding from CCAMP's response that NVC is always >0 for
VCAT setup, e.g., if a single connection is being set up as part of a
larger VCAT connection, the value NVC=1 would be used in the PATH message.

We note that there may be more complex scenarios that need to be
considered, such as connections being set up initially without being part
of a VCAT group and subsequently being added to a VCAT group. An ITU-T
Liaison with related discussion has been received by us and was also
copied to CCAMP.

3. Length of the Switching Capability Descriptor

We appreciate the verification from CCAMP.

4. Use of ADMIN_STATUS in the PATH message

We appreciate CCAMP's advice.

5. Handling of multiple received ResvConf Request objects

It is our understanding from CCAMP's response that a ResvConf Request
object received in the Resv message should only trigger sending of the
ResvConf message if there is a change in the Resv message, i.e., it is not
a refresh message.

If in fact it is desirable to trigger a new ResvConf message without
making a change to an existing session and associated connection, we
believe that a possible mechanism for doing this is to first send a Resv
message removing the ResvConf Request object and then send a subsequent
Resv message with the ResvConf Request object reinserted, thus
differentiating the request from a refresh.

We also noted the advice that the ADMIN_STATUS object offers a reliable
mechanism as an alternative to ResvConf, however are unclear as to the
procedure for triggering ADMIN_STATUS, for example, to determine when the
originating endpoint is ready to receive signal during connection setup.

6. Symmetry of Refresh Reduction

We appreciate the clarification from CCAMP.

7. Sending of ACKs bundled with RSVP Hello

We appreciate the clarification from CCAMP. We did in fact mean
"piggybacking" of ACKs with the Hello message, which we now understand is
prohibited based on RFC 3209.

8. TSPEC format for Ethernet

We appreciate CCAMP's interest in OIF requirements for Ethernet connection
control. As a result of discussions within OIF and review of ITU-T G.8011
and MEF.6 and MEF.10, we have identified the following attributes as
requiring support in signaling to specify the Ethernet bandwidth profile
and request that CCAMP identify a mechanism for carrying this in the
protocol, e.g., a new Sender_Tspec/Flowspec format for Ethernet :

CIR (Committed Information Rate): Maximum rate required under normal
conditions, service level guaranteed.

CBS (Committed Burst Size): Limits the number of bytes for a burst while
conforming to CIR.

EIR (Excess Information Rate): Maximum rate required under burst
conditions, no guarantee of performance.

EBS (Excess Burst Size): Limits the number of bytes for a burst while
conforming to EIR.

CF (Coupling Flag) and CM (Colour Mode): Give a choice for different modes
of operation.

These are defined in the following references:


  1.. [1] Metro Ethernet Forum, MEF.10 - Ethernet Services Attributes
Phase 1, Nov. 2004


  2.. [2] ITU-T Recommendation G.8011/Y.1307 (2004), Am. 1 (2005),
"Ethernet Services Framework".

We would like to also bring to CCAMP's attention that MEF has defined as
set of TLVs for these attributes for use in their E-LMI (Ethernet Link
Management Interface) specification and these may be of use to CCAMP in
its work.

Best regards,

Jim Jones

OIF Technical Committee Chair