Communication from OIF on GMPLS for Ethernet

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

Hi,

We have received a further communication from the OIF on the use of GMPLS to 
support Ethernet access.

Again, this communication requests a response, and the chairs will draft 
something with your contributions.

The full liaison can be seen at www.olddog.co.uk/incoming.htm

Thanks,
Adrian

To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
From: Jim Jones, OIF TC Chair
Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
Subject: Use of RSVP to support Ethernet Access

Dear Adrian and Deborah,

During our discussion of protocol requirements to support Ethernet services 
over optical networks, we identified some issues where application of the 
GMPLS specifications were not clear to us. We request CCAMP's views on the 
following issues:

1. Use of parameters to distinguish port-based vs. VLAN-tag-based forwarding 
of Ethernet frames

We have identified two variations on support of Ethernet services at the 
network access point:

a) in the first variation, received frames are forwarded into a specific 
SONET/SDH path based on the incoming port, without processing the header 
information in the Ethernet frame; and

b) in the second variation, received frames are forwarded into specific 
SONET/SDH paths based on header information, esp. the VLAN tag.

It is not fully clear to us how these are distinguished in GMPLS signaling, 
especially forwarding behavior (a) above. The closest match that was 
identified was to use the following approach:
- use the Switching Type value of "FSC" to indicate forwarding based on 
port; and
- use the Switching Type value of "L2SC" to indicate forwarding based on the 
L2 protocol header of received frames.

However, we feel that neither FSC nor L2SC exactly expresses behavior (a) 
above. In particular, "FSC" can also be interpreted as meaning that the 
signal received on the fiber is forwarded exactly as received, in its 
entirety, independent of the signal type (SONET, Ethernet, or other).

We request CCAMP comment on whether this approach is the correct 
interpretation of the specifications or if an alternative and/or 
supplemental mechanism should be considered.

2. Use of Label for these cases

In addition to the question on the use of Switching Capability, it was not 
clear what value should be used as the Generalized Label for these cases.

For case (a) above, our current assumption is that the Label reflects the 
affected port, however it was noted that this may duplicate information in 
the RSVP_HOP Interface Index sub-TLV.

For case (b) above it seems logical that the Label reflect the affected VLAN 
tags. We are investigating label formats to represent a list or range of 
VLAN identifiers, as used in MEF.11 bundling. In the case where a large 
number of non-consecutive VLAN identifiers is used for the same connection, 
we would like to keep the label to a reasonable size. In the case of 
bi-directional connections, the UPSTREAM_LABEL is used to indicate the 
connection is bi-directional. The LABEL_SET is then used if there is a need 
for the labels to be identical in both directions. In that case, there is a 
redundancy of labels. That is problematic with large label formats. We would 
appreciate your advice regarding the possibility to reduce the number of 
labels required in the case of bi-directional connections where the label is 
the same in both directions.

OIF requests CCAMP's comment on the use of Labels in these cases.

Best regards,
Jim Jones
OIF Technical Committee Chair