Subject: Response to your communication on GMPLS for Ethernet

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 15 Jun 2006 15:30:09 +0100

Dear Jim,

 Thank you for bringing the concerns of your technical committee with 
respect to the use of GMPLS to support Ethernet access to the attention of 
the CCAMP working group.

 We are happy to be consulted on this type of issue although we would like 
to point out the inherent inefficiencies of communicating like this. We feel 
it would be far smoother, more rapid, and more conducive for constructive 
dialogue if your members raised these types of question direct to the CCAMP 
mailing list. The CCAMP mailing list is open to everyone at no cost. 
Subscription details can be found at the CCAMP charter page: 
http://www.ietf.org/html.charters/ccamp-charter.html

> 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.

 When you say "forwarded into a specific SONET/SDH path" we presume that you 
mean "adapted into". In fact, at the Ethernet layer, the SONET/SDH path is 
simply providing a virtual Ethernet link, and it is at this layer that you 
wish to set up Ethernet switching. Your questions, we assume, apply to how 
to identify the switching quantity in an Ethernet switching network, and are 
not related to the adaptation mechanisms, although the adaptation function 
may also require to know how to identify the particular Ethernet flow within 
an Ethernet port.

> 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.

 FSC would, indeed, be incorrect. It is used for spatial switching.

 You are switching layer 2 packets. That means that the switching type must 
be L2SC. The fact that all layer two packets received on a port are switched 
in the same way is not material.

 May we draw your attention to 
draft-ietf-ccamp-ethernet-traffic-parameters-00.txt. We believe that this 
draft was mentioned during your meeting in the report on IETF activity, and 
it is particularly relevant to this question. It can be downloaded free of 
charge from 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt

You will observe in section  that the Sender_TSpec object includes a 
Switching Granularity field defined as follows:

     Switching Granularity (SG): 16 bits

 This field indicates the type of link that comprises the requested Ethernet 
LSP.

      The permitted Ethernet Link Type values:
           Value   Switching Granularity
           -----   ---------------------
           1       Ethernet Port
           2       Ethernet Frame

      Value 0 is reserved. Values 1 through 127 are assigned by IANA via
      IETF Standards Track RFC action.

      Values 128 through 255 are reserved for vendor specific usage.

> 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.

 You should note that labels are a local matter between neighbors. That is, 
and in particular, port identifiers may be local information shared between 
neighbors and does not need to have global scope.

> 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.

 If the port is identified as an IP numbered or unnumbered interface, then 
you are correct that using the port identifier as the label will duplicate 
the information carried in the RSVP_HOP object. Can you clarify why this 
duplication is a concern to you?

On the other hand, if multiple ports are assembled as a single interface, or 
if the ports are given a local, non-IP identification, there is a clear 
separation between the quantities.

> For case (b) above it seems logical that the Label reflect the affected
> VLAN tags.

 Indeed. The label always represents the switching quantity.

> 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.

 'Large number' and 'reasonable' are impossible for us to quantify without 
further discussion with you. It seems to us, however, that if the 
information needs to be known by both neighbors, there is little alternative 
to communicating the information between the neighbors. Whether this is done 
mainly through the management plane with a label identifying a preconfigured 
combination of VLAN identifiers (i.e. a MEF bundle), through the control 
plane using GMPLS link bundling, through the control plane using extended 
(concatenated) labels as in TDM virtual concatenation, or through dynamic 
control plan virtual concatenation techniques, is clearly an implementation 
choice and may be an appropriate work area for the OIF. We would certainly 
be interested to hear your conclusions.

> 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.

 Redundancy of information is not an issue, per se. In fact, since there is 
a possibility to require the use of different labels in each direction, the 
objects themselves are not redundant.

 The issue with the size of label is interesting. If there is a proposal to 
use labels so large than the inclusion of two of them in a signaling message 
is significant issue then we would strongly suggest that the label format is 
wrong. (Note that your requirement here is only to carry two labels, one in 
the Upstream Label object and one in the Label Set object.)

> 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.

 Assuming that 'reduce the number of labels' means 'reduce from two to one' 
we appreciate that there is a minor optimisation possible in this specific 
case, but suggest that it would be better to examine the underlying problem 
of label size since there will be cases of asymmetrical bidirectional LSPs 
where it is necessary to carry both labels.

 Hoping that this answers your questions.

 Best regards,
Adrian Farrel and Deborah Brungard
CCAMP co-chairs