[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Response to your communication on GMPLS for Ethernet
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