RE: [EFM] EFM Requirements
Carlos,
So, the only major new requirement I can extract from your message is that
perhaps 802.1 should look at extending the Traffic Class concept in
802.1D-1998 to handle VLANs as well i.e. classification into Traffic Classes
by means of VLAN-ID as well as by input port and/or by existing Traffic
Class.
Not clear from your message but you are also hinting that a "bandwidth
reservation" scheme might also be needed - are you thinking that something
more (or less?) than the per-session reservations described by
RFC2814/2815/2816 is needed? If you are talking about something simpler than
that e.g. per-VLAN bandwidth reservations, then there might be a case to be
made that 802.1D-1998 ought also to include definition of some additional
queuing and/or scheduling disciplines. Many L2 switches today offer such
additional capabilities - maybe take a look at
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt for a
QoS management model that is quite applicable to L2 switches as well as L3
ones.
"the space for VLAN tagging should be reserved in the base frame format"
comes automatically if 802.EFM adheres to the IEEE 802 architecture - there
is really no justification for invention of a new frame format here - use
802.1Q-1998. The VLAN-ID "tag size" is also one for 802.1 to consider.
These are all points that you should raise with 802.1 (perhaps in a Tech
Plenary with 802.3, once the EFM group has identified what it is that it
thinks is needed).
Andrew
-----Original Message-----
From: carlosal@xxxxxxxxxxxxxxxxxx [mailto:carlosal@xxxxxxxxxxxxxxxxxx]
Sent: Friday, August 24, 2001 5:36 AM
To: ah_smith@xxxxxxxxxxx
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] EFM Requirements
Andrew,
Sorry if my message was confusing; I believe that I've not made myself
clear. There are two separate issues on Mark's message:
1. In my understanding, Mark's message directly implied that Ethernet had
mechanisms to map L3 QoS requirements at L2. I gently just suggested
otherwise in my answer, as Ethernet has *no* such features. I took the care
to left open the possibility of issue no. 2, that is...
2. Mechanisms to map QoS on layer 2 may be important to keep some services,
specially voice, with the quality level required. We need just to make sure
that this can be done in a cost-effective and scalable way.
I agree that todays switches already do a nice job at this using L3
information. However, as a carrier, we have some reservations, for the
following reasons:
- We have to carry several different IP networks at the same time (for
VPNs, etc). L3-based systems may become cumbersome to maintain when you
have several VPNs, many of them using the same IP address range. Note that
this is different from the corporate network scenario, where all these
L2/L3 switches where originally used; there you have single IP address
range, making configuration much easier.
- To keep all these overlapping IP addresses separated at the Ethernet
level, we will have to resort to VLANs, for obvious reasons. VLANs are
relatively simple to implement, and may be used to help isolate QoS
enforcement policies. Bandwidth reservation could be handled at the VLAN
level; inside the VLAN, fine granularity QoS could be done using IP
information. This way, we would have some guarantee that misbehaved
applications which set QoS parameters too high inside one VLAN would not
interfere with the minimum bandwidth reserved for the others.
- Just to explore the alternatives, we know that it is possible to make
everything work over a pure IP network, using tunnels to provide a virtual
network topology (for instance, using MPLS). However, I don't think that
this makes sense. By their nature, these tunnels are point-to-point, and do
not provide an efficient framework for the delivery of point-to-multipoint
content using multicast. On the other hand, Ethernet already does that
nicely.
My take is that the EFM standard should have provisions for VLANs, that in
turn could optionally be used by vendors to implement bandwidth
reservation. A complete QoS implementation is not absolutely needed at this
level. This definition may be out of the 802.3ah scope. However, at least
the space for VLAN tagging should be reserved in the base frame format,
specially if there is any intention to improve on the limit of VLANs that
is imposed by the current tag size. Also, interoperability is an important
issue. If some EFM-compliant CPEs support VLANs, and others don't, then we
won't have true interoperability.
As for the other points that you stated, I agree with many of them. In
particular, the use of active switches has been historically the superior
approach in many cases, including Ethernet itself. However, there are so
many issues at stake that make the PON x P2P debate outcome very difficult
to predict.
Carlos Ribeiro
CTBC Telecom