24.4.1999
Niclas Ek
Department of Electrical Engineering
Helsinki University of Technology
Niclas.Ek@iki.fi
Purpose of this research paper is to study use of protocols described in IEEE (Institute of Electrical and Electronics Engineers) standards 802.1P and 802.1Q as QoS (Quality of Service) protocols on MAC (Medium Access Control) level. First of all, both standards will be represented, as well as some other related standards as well as some proposals for standards. In this paper, a discussion of future of thise standards will be represented. As well will relations to other QoS, ToS (Type of Service) and CoS (Class of Service) standards. Some practical studies of several implementations of thise protocols will carried out in this paper.
1. Introduction
2. VLANs
3. QoS
6. Future of MAC level QoS protocols
7. References
8. Further Information
1. Introduction
This document specifies use of the IEEE standards 802.1P,Q as Quality of Service protocol on MAC level. Today´s Internet provides only Best Effort Service. Since ethernet is the most spread LAN access technology, importance of providing it a quality of service mechanism ought not to be neglected.
In future ethernet technology will be used as WAN technology, not only as LAN technology. Due to rapidly increasing use Internet throug Public Switched Telecommunication Network (PSTN), Telephone Companies are forced to implement IP-based networks as their PSTN backbones. A network like this whitout any Quality of Service mechanisms would be disastrous. Just imagine yourself trying to get an emergency call throug while others just surf the Internet.
First of all, relationships between IEEE standards 802.1p, 802.1D and 802.1Q have to clarified. IEEE standard 802.1p is a part of the IEEE standard 802.1D. The 802.1p standard covers traffic class expediting and dynamic multicast filtering part of media access control (MAC) bridges, which is known as the IEEE standard 802.1D. [1] IEEE standard 802.1Q is part of the IEEE standard 802.1D, defining an architecture for Virtual Bridged LANs and services provided in Virtual Bridged LANs.
Secondly, expression Quality of Service have to defined. According to the IEEE standard 802.1p, following parameters are essensial for providing QoS. [2]
Thise QoS parameters will be discussed in details in a later section.
Related standards, like RSVP, Differentiated Services and MPLS
will be studied. Emphasis will be paid for status of QoS
standards, status of appling thise standards in practice.
The strong and the weak points of thise standards will be
determinated. The future of providing QoS in switched
etherhets will be discussed.
2. VLANs
2.1 802.1Q
The IEEE 802.1Q standard defines an architecture for Virtual Bridged LANs, the services provided in Virtual Bridged LANs and the protocols and algorithms involved in the provision of those servises.[1]
No Quality of Service mechanisms are defined in this
standard, but an important requirement for providing
QoS is included in this standard, e.g. abitity to
regenerate user priority of received frames using
priority information contained in the frame and the
User Priority Regeneration Table for the reception
Port. [1]
2.2 802.1D
The updated IEEE 802.1D: ISO/IEC 15802-3 (MAC
Bridges) standard covers all parts of the Traffic
Class Expediting and Dynamic Multicast Filtering
described in the IEEE 802.1p standard. All parts
of the IEEE 802.1p standard are merged
with old versions of IEEE 802.1D standard. All QoS
issues will be discussed in IEEE 802.1p section.
2.3 802.1p
IEEE 802.1p standard, Traffic class expediting and dynamic multicast filtering. Descibes important methods for providing QoS at MAC level.
Service availability is measured as ratio between MAC service is unavailable and available. In order to increase service availability automatic reconfiguration of the Bridged Local Area Network ought to be adopted.
The Mac Service does not provide a guaranteed delivery of Service Data Units, but the probability is high. Frame loss might occur due to:
The MAC Service does not permit reordering frames with in the same user_priority for a source and destination address pair.
The MAC Service does not permit duplicating frames.
Frame transit delay is the elapsed time between an MA_UNITDATA.request and corresponding MA_UNITDATA.indication on a successfull transfer.
If the maximum deleys a frame has imposed by all the bridges in the Bridged Local Area Network exeeds the desired maximum frame lifetime, the frame ought to be discarded.
By using FCS calculations for each frame, the undetected frame error rate is very low.
The Maximum Service Data Unit Size is dependent on the access media used. A bridge between two LANs has the Maximum Service Data Unit Size of the that has the smaller one.
MAC Service counts user_priority as a QoS parameter.
The total throughput of a Bridged Loval Area Network can greater than one of its equivalet LANs.
ISO/IEC DIS 8802-12 priority value "normal" maps to user_priority 0 and value "high" maps to user_priority 4. On frame transmission User_priority values 0 through 3 map to "normal" and values 4 through 7 map to "high". access_priority values 0 through 3 map to
"normal" and access_priority values 4 through 7 map to "high".
Based on priority information contained in the
frame and the User Priority Regeneration Table
for the reception port user_priority will be
regenerated for each received frame. Each port
has its own User Priority Regeneration Table
and each table has eight entries, one for
every possible value of user_priority.
Mapping explaned in Table 1.
|
Regenerated User Priority |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Forwarding prosess may provide one or more transmission queues for each Bridge Port. It provides storage for queued frames, waits for a oppornity to submit these transmissions. Frames will be assigned to each queue according their user_priority.
The transmission order for a single swicth port is:
The default algorithm for frame selection for transmission:
|
|
|
|
|
|
|
|
|
Priority |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e, f and g |
|
e, f and g |
|
c and d e, f and g |
|
c and d e and f g |
|
c d e and f g |
|
c d e f g |
|
b c d e f g |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is not easy to find an ultimate definition for Quality of Service. Each service has its own definition for QoS and each service can be described by its QoS characteristics. Most of the QoS definitions available are ITU-T's standards for ISDN. For datacommunication network performance, QoS characteristics are bandwidth, delay, and reliability. QoS characteristics for performance include:
These as well as many other QoS characteristics could
be used to define services in the network. Wheter
thise are suitable for determinating QoS in some
network depends on the applications and the services
used in that network or networks. [3]
4. 802.1p and QoS
4.1 802.1p - a real QoS protocol?
IEEE 802.1p standard has a prioritation scheme, which is in fact quite good. Lower priority level packet are not sent, if there is pakets in queued in higher level queues.
IEEE 802.1p decibes no addmission control protocols. It would be possible to give Network Control priority to all packets and the network would be easily cognested. Even microsoft has found it out. But none of Microsofts operating systems denies it, that is, in Microsofts point of view, network interface card drivers duty. We can only hope, that network interface card manufacturers make good drivers. [13]
IEEE 802.1p standard itself does not limit the amount of resouces one application uses, but many implementations do. A mechanism to negotiate a guaranteed QoS for each appliation, end-to-end, according to the network policy maintained by local network administrators would be an improment with a high priority.
One major shortage, e.i. interoperability has been
fixed by the SBM RFC. This RFC deals how to deliver end-to-end
QoS to and from etnernet to other networks. The SBM RFC will
be discussed in more depth in section 4.3.
4.2 Standard is ready - how about implementations
The IEEE 802.1p standard has been ready for quite a while. In order to gain full end-to-end QoS all components involved have to implement this standard. Some hudge wendors, like Cisco Systems have not implemented it yet on pure L2 switches. [14]
A big player in desktop workstations software, Microsoft
has implemented IEEE 802.1p support only on Windows 98.
In future Windows 2000 it will be supported as well. [13]
Many other vendors do support IEEE 802.1p in variety of
products, it remains uncertain thise two major players will
loose their dominance due to this fact.
4.3 Subnet Bandwidth Manager (SBM)
In order to gain end-to-end QoS from ethernet to an other network-technology, we need to glue RSVP and IEEE 802.1p together.
SBM signaling scheme is used to convey 802.1p priorities between layer 2 switches. It will also map class of service between RSVP clients and RSVP-enabled nets.
SBM is a signaling protocol for RSVP-based admission
control over IEEE 802 networks, like ethernet. SBM is
a method for mapping an internet-level setup protocol
such as RSVP onto IEEE 802 networks. In particular, it
describes the operation of RSVP-enabled hosts/routers
and switches/bridges to support reservation of
LAN resources for RSVP-enabled data flows. [15]
5. Other QoS protocols
5.1 Integrated Serveces
The basic service class for todays Internet is Best Effort Service. Two additional service classes are introduced in the Integrated Services model [4]. These two new service classes are:
The Guaranteed Service class were intended for applications requiring a fixed delay. Implementing Guaranteed Service class is discussed in "Specifications of Guaranteed Quality of Service", RFC 2212.[5]
The Predictive Service class were intended for applications requiring prognosticative delay. Implementing Predictive Service class is discussed in "Specifications of the Controlled-Load Network Element Service", RFC 2211. [6]
The name of this QoS mechanism, Integrated Services, originates from the fact, that both Guaranteed and Predictive Services share the same link by scheme called controlled link-sharing.
Following four mechanims are required for implementing Integrated Services:
In order for an application requiring Guaranteed Service or Controlled-Load Service to gain QoS, it has to set up the path and reserve resources along it before transmitting any data. The decision whether the application will get resources it tried to reserve, belongs to the admission control routines. Every router along the path will put all received packets to specific queues according to Multi-Field classification performed by the classifier. In order meet required QoS state, the packet scheduler will schedule the packet consequently[4,5,6].
Resource ReSerVation Protocol (RSVP), will be discussed deeply in next section.
Some problems exists with Integrated Services model:
RSVP is a resource reservation setup protocol designed for Integrated Services model. RSVP protocol is used by a host to request specific quality of service from the network for particular application data stream or flow. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path of the flow and to establish and maintain state to provide the requested service.
As a result of a RSVP request will generally resources be reserved in each node along the data path.
RSVP request requests resources in only one direction. Due to that above fact, RSVP treats a sender separate from receiver, although the same application might be in both a sender and a receiver simultaneously.
RSVP is capable to operate on both IPv4 and IPv6. RSVP does not transport any application data, it is rather a control protocol, like ICMP, IGMP, or routing protocols. As well as other routing and management protocols, RSVP will be executed in background.
RSVP is not a routing protocol; RSVP was designed to operate with both unicast and multicast routing protocols. RSVP uses local routing database to obtain routes.
In order to obtain QoS on multicast, a host send IGMP message to join a multicast group and then send RSVP message to reserve resources along the path of that multicast group. Routing protocols determinate which route packets get thought and RSVP is merely concerned about the QoS of those packets.
Since most of the development work done around RSVP was completed before most other QoS standard were finished, some supplements have been made to the standard. These are still at RFC state.
In order to ensure the integrity of admission control mechanism, an ability to protect thise messages against corruption and spoofing have been added to RSVP.
This proposed scheme transmits an authenticating digest of the message, computed using a secret Authentication Key and a keyed-hash algorithm. This scheme provides protection against faking and message modification.
The integrity object of each RSVP message is tagged with a one-time sequence number. This allows receiver to identify playbacks and to prevent from replay attacks. This proposed mechanism does not ensure confidentiality, since messages are not crypted. Nevertheless this mechanism is allows exporting RSVP from most countries despite of wassenaar embargo on exports.
This message replay prevention algorithm is pretty straightforward. The sender generates packets with uniformly increasing sequence numbers and the receiver accepts only packets with increasing sequence number. In order to start this process, receiver handshakes with the sender to get an initial sequence number.
This proposed mechanism is independent of any specific cryptographic algorithm, but it describes the use of Keyed-Hashing for Message Authentication using HMAC-MD5. Some stronger hashes, such as HMAC-SHA1 might be used in future.
Many other extensions to the RSVP model exists, like
admission control for RSVP etc. The future of all
thise RSVP extensions is open, but RSVP v.1 not very
usefull standalone.
5.2 Differentiated Services
Since Integrated Services/RSVP has its weaknesses an alternative scheme is introduced. An IP header contains a TOS (Type of Service) field. Applications can set the value of this TOS field according to its requirements. Diffserv defines the layout for TOS field (DS field) and a basic set of rules for packet forwarding (Per-Hop Behavior, PHB).
Two new Service classes are introduced, Premiun Service for applications requiring low delay and low jitter. The second one is Assured Service class for applications requiring reliability than Best effort can offer.
diffserv model introduces a resource controller, Bandwidth Broker (BB), which decides behalf of every host the bandwidth. [10]
Security issues were raised by the introduction of
differentiated services, primarily the potential for
denial-of-service attacks, and the related potential
for theft of service by unauthorized traffic.
As well has differentiated services in the presence of
IPsec including its interaction with IPsec tunnel mode
and other tunnelling protocols. [9]
5.3 Multi-Protocol Label Switching (MPLS)
MPLS model integrates the label swapping forwarding paradigm with network layer routing. It is basically a forwarding scheme, that has developed from Cisco's Tag Swiching.
A router which is capable to do MPLS is called Label Switch Router (LSR). A LSR examines only labels of packets to be forwarded. Because this scheme is independent if underlaying protocols, it is called Multi-Protocol Label Switching.
A Label Distribution Protocol (LDP) is needed to distribute
labels in order to set up Label Switched Paths. Each MPLS
packet has a specific header, which contains 20-bit label,
8-bit TTL field, 3-bit Class of Service, 1-bit stack
indicator, next header type indicator and checksum. [11]
5.4 Constraint Based Routing
Constraint Based Routing has been developed out of QoS Routing. The main goals of Constraint Based Routing are:
In order to find such a route Constraint Based Routing
algorithm has to have knowledge of network topology,
QoS requirements of the flow, resources available at
the links and if any network policies exists.
6. Future of MAC level QoS protocols
Future of MAC level QoS protocols seems to be quite bright, since
ethernet-technology is making a break through in MAN and WAN networks.
Main reason for this is much cheaper and easier management if we
compare with traditional MAN and WAN technologies, like ATM, SDH or
Frame Relay. At the moment telephone companies are in middle of a
transition from traditonal Public Switched Telecommunication Network
to IP-technology based multiservice network. Todays implementations
use ATM-based technology as backbone, but in near future as point
of view backbones will be gigabit-ethernet. Whitout QoS at MAC level,
this trancition would not be able.
7. References
| [1] | Lidinsky, W.,IEEE Standard P802.1Q IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks, 30.7.1998 [defered 12.3.1999]
< http://grouper.ieee.org/groups/802/1/vlan.html> |
| [2] | Lidinsky, W.,IEEE Standard P802.1D Information tecnology - Telecommunications and information exchange between systems - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision, 24.11.1997 [defered 14.3.1999]
< ftp://p8021@p8021.hep.net/8021/p-drafts/> |
| [3] | McCabe, J., Network Quality of Service Characterization and Architecture, June 1997 [defered 15.4.1999]
< http://science.nas.nasa.gov/Groups/WAN/documents/services-white-paper.html> |
| [4] | Braden, R., Clark, D., Shenker, S. Request for Comments: 1633: Integrated Services in the Internet Architecture: an Overview, June 1994 [defered 19.4.1999]
< ftp://ftp.funet.fi/pub/standards/RFC/rfc1633.txt> |
| [5] | Shenker S., Partridge C., Guerin R., Request for Comments: 2212: Specification of Guaranteed Quality of Service, September 1997 [defered 23.4.1999]
< ftp://ftp.funet.fi/pub/standards/RFC/rfc2212.txt> |
| [6] | Wroclawski J., Request For Comments: 2211: Specification of the Controlled-Load Network Element Service, September 1997 [defered 23.4.1999]
< ftp://ftp.funet.fi/pub/standards/RFC/rfc2211.txt> |
| [7] | Braden R., Zhang L., Berson S., Herzog S., Jamin S., Request for Comments: 2205: Resource ReSerVation Protocol (RSVP), September 1997 [defered 24.4.1999]
< ftp://ftp.funet.fi/pub/standards/RFC/rfc2205.txt> |
| [8] | Baker F., Lindell B., Talwar B., RSVP Cryptographic Authentication, 6.3.1999 [defered 24.4.1999]
< http://www.isi.edu/rsvp/DOCUMENTS/draft-ietf-rsvp-md5-08.txt> |
| [9] | Nichols K., Blake S., Baker F., Black D., Request for Comments: 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998, [defered 24.4.1999] |
| [10] | Nichols K., Jacobson V., Zhang L., A Two-bit Differentiated Services Architecture for the Internet, April 1999, [defered 24.4.1999]
< ftp://ftp.ietf.org/internet-drafts/draft-nichols-diff-svc-arch-01.txt> |
| [11] | Callon R., Doolan P., Feldman N., Fredette A., Swallow G., Viswanathan A.,
A Framework for Multiprotocol Label Switching, 21.11.1997, [defered 23.4.1999]
< http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-02.txt> |
| [12] | Xiao X., Ni L., Internet QoS: the Big Picture, [defered 15.4.1999]
< http://www.cse.msu.edu/~xiaoxipe/papers/inet.qos.bigpicture.pdf> |
| [13] | N.N, QoS: Assigning Priority in IEEE 802-style Networks, 16.8.1998, [defered 15.4.1999]
< http://www.microsoft.com/hwdev/devdes/qos.htm> |
| [14] | N.N, Quality of Service (QoS) Fact Sheet,24.3.1999, [defered 15.4.1999]
< http://www.cisco.com/warp/public/cc/sol/mkt/ent/multi/dvvi4/qosfs_ds.htm> |
| [15] | Yavatkar R., Hoffman D., Bernet Y., Baker F., Speer M., SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks, November 1998, [defered 17.4.1999]
< ftp://ftp.ietf.org/internet-drafts/draft-ietf-issll-is802-sbm-07.txt> |