As per Relevance of the word mappings, we have this rfc below:
Network Working Group M.
Request for Comments: 2815
Category: Standards Track A.
Extreme
E.
Unisphere
J.
MIT
May 2000
Integrated Service Mappings on IEEE 802
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes mappings of IETF Integrated Services
LANs built from IEEE 802 network segments which may be
by IEEE 802.1D MAC Bridges (switches). It describes
mappings for supporting Controlled Load and Guaranteed Service
the inherent capabilities of relevant IEEE 802 technologies and,
particular, 802.1D-1998 queuing features in switches
These mappings are one component of the Integrated Services over
802 LANs framework
Seaman, et al. Standards Track [Page 1]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
Table of
1 Introduction ............................................... 2
2 Flow Identification and Traffic Class Selection ............ 3
3 Choosing a flow's IEEE 802 user_priority class ............. 5
3.1 Context of admission control and delay bounds ............ 6
3.2 Default service mappings ................................. 7
3.3 Discussion ............................................... 9
4 Computation of integrated services characterization
by IEEE 802 devices .....................................10
4.1 General characterization parameters ......................10
4.2 Parameters to implement Guaranteed Service ...............11
4.3 Parameters to implement Controlled Load ..................11
4.4 Parameters to implement Best Effort ......................12
5 Merging of RSVP/SBM objects ................................12
6 Applicability of these service mappings ....................13
7 References .................................................14
8 Security Considerations ....................................15
9 Acknowledgments ............................................15
10 Authors' Addresses ........................................16
11 Full Copyright Statement ..................................17
1.
The IEEE 802.1 Interworking Task Group has developed a set
enhancements to the basic MAC Service provided in Bridged Local
Networks (a.k.a. "switched LANs"). As a supplement to the
IEEE MAC Bridges standard, IEEE 802.1D-1990 [802.1D-ORIG],
updated IEEE 802.1D-1998 [802.1D] proposes differential traffic
queuing in switches. The IEEE 802.1Q specification [802.1Q]
the capabilities of Ethernet/802.3 media to carry a traffic
indicator, or "user_priority" field, within data frames
The availability of this differential traffic queuing, together
additional mechanisms to provide admission control and signaling
allows IEEE 802 networks to support a close approximation of the
Integrated Services capabilities [CL][GS]. This document
methods for mapping the service classes and parameters of the
model into IEEE 802.1D network parameters. A companion
[SBM] describes a signaling protocol for use with these mappings.
is recommended that readers be familiar with the overall framework
which these mappings and signaling protocol are expected to be used
this framework is described fully in [IS802FRAME].
Within this document, Section 2 describes the method by which
systems and routers bordering the IEEE Layer-2 cloud learn
traffic class should be used for each data flow's packets. Section 3
describes the approach recommended to map IP-level traffic flows
Seaman, et al. Standards Track [Page 2]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
IEEE traffic classes within the Layer 2 network. Section 4
the computation of Characterization Parameters by the layer 2
network. The remaining sections discuss some particular issues
the use of the RSVP/SBM signaling protocols, and describe
applicability of all of the above to different layer 2
topologies
2. Flow Identification and Traffic Class
One model for supporting integrated services over specific
layers treats layer-2 devices very much as a special case of routers
In this model, switches and other devices along the data path
packet handling decisions based on the RSVP flow and
specifications, and use these specifications to classify
corresponding data packets. The specifications could either be
directly, or could be used indirectly by mapping each RSVP
onto a layer-2 construct such as an ATM virtual circuit
This approach is inappropriate for use in the IEEE 802 environment
Filtering to the per-flow level becomes expensive with
switch speed; devices with such filtering capabilities are likely
have a very similar implementation complexity to IP routers, and
not make use of simpler mechanisms such as 802.1D user priority
The Integrated Services over IEEE 802 LANs framework [IS802FRAME]
this document use an "aggregated flow" approach based on use
layer-2 traffic classes. In this model, each arriving flow
assigned to one of the available classes for the duration of the
and traverses the 802 cloud in this class. Traffic flows
similar service are grouped together into a single class, while
system's admission control and class selection rules ensure that
service requirements for flows in each of the classes are met.
many situations this is a viable intermediate point between no
control and full router-type integrated services. The approach
work effectively even with switches implementing only the
differential traffic classification capability specified in
802.1D model. In the aggregated flow model, traffic arriving at
boundary of a layer-2 cloud is tagged by the boundary device (
host or border router) with an appropriate traffic class,
as an 802.1D "user_priority" value. Two fundamental questions
"who determines the correspondence between IP-level traffic flows
link-level classes?" and "how is this correspondence conveyed to
boundary devices that must mark the data frames?"
One approach to answering these questions would be for the
of the classes to be universally defined. This document would
standardize the meanings of a set of classes; e.g., 1 = best effort
2 = 100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1
Seaman, et al. Standards Track [Page 3]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
peak delay target, etc. The meanings of these universally
classes could then be encoded directly in end stations, and
flow-to-class mappings computed directly in these devices
This universal definition approach would be simple to implement,
is too rigid to map the wide range of possible user requirements
the limited number of available 802.1D classes. The model
in [IS802FRAME] uses a more flexible mapping: clients ask "
network" which user_priority traffic class to use for a given
flow, as categorized by its flow-spec and layer-2 endpoints.
network provides a value back to the requester that is
considering the current network topology, load conditions,
admitted flows, etc. The task of configuring switches with
mapping (e.g., through network management, a switch-switch
or via some network-wide QoS-mapping directory service) is an
of magnitude less complex than performing the same function in
stations. Also, when new services (or other network reconfigurations
are added to such a network, the network elements will typically
the ones to be upgraded with new queuing algorithms etc. and can
provided with new mappings at this time
In the current model it is assumed that all data packets of a
are assigned to the same traffic class for the duration of the flow
the characteristics of the MAC service, as defined by Clause 6
[802.1D], then ensure the ordering of the data packets of the
between adjacent Layer 3 routers. This is usually desirable to
potential re-ordering problems as discussed in [IS802FRAME] and [CL].
Note that there are some scenarios where it might be desirable
send conforming data traffic in one traffic class and non-
traffic for the same flow in a different, lower traffic class: such
division into separate traffic classes is for future study. When
new session or "flow" requiring QoS support is created, a client
ask "the network" which traffic class (IEEE 802 user_priority) to
for a given traffic flow, so that it can label the packets of
flow as it places them into the network. A request/response
is needed between client and network to return this information.
request can be piggy-backed onto an admission control request and
response can be piggy-backed onto an admission
acknowledgment. This "one pass" assignment has the benefit
completing the admission control transaction in a timely way
reducing the exposure to changing conditions that could occur
clients cached the knowledge for extensive periods. A set
extensions to the RSVP protocol for communicating this
have been defined [SBM].
The network (i.e., the first network element encountered
from the client) must then answer the following questions
Seaman, et al. Standards Track [Page 4]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
1. Which of the available traffic classes would be appropriate
this flow
In general, a newly arriving flow might be assigned to a
of classes. For example, if 10ms of delay is acceptable,
flow could potentially be assigned to either a 10ms delay
or a 1ms delay class. This packing problem is quite difficult
solve if the target parameters of the classes are allowed
change dynamically as flows arrive and depart. It is
simple if the target parameters of each class is held fixed,
the class table is simply searched to find a class
for the arriving flow. This document adopts the
approach
2. Of the appropriate traffic classes, which if any have
capacity available to accept the new flow
This is the admission control problem. It is necessary
compare the level of traffic currently assigned to each
with the available level of network resources (bandwidth
buffers, etc), to ensure that adding the new flow to the
will not cause the class's performance to go below its
values. This problem is compounded because in a priority
system adding traffic to a higher-priority class can affect
performance of lower-priority classes. The admission
algorithm for a system using the default 802 priority
must be reasonably sophisticated to provide acceptable results
If an acceptable class is found, the network returns the
user_priority value to the client
Note that the client may be an end station, a router at the edge
the layer 2 network, or a first switch acting as a proxy for a
that does not participate in these protocols for whatever reason
Note also that a device e.g., a server or router may choose
implement both the "client" as well as the "network" portion of
model so that it can select its own user_priority values. Such
implementation would generally be discouraged unless the device has
close tie-in with the network topology and resource
policies. It may, however, work acceptably in cases where there
known over-provisioning of resources
3. Choosing a flow's IEEE 802 user_priority
This section describes the method by which IP-level flows are
into appropriate IEEE user_priority classes. The IP-level
considered are Best Effort, Controlled Load, and Guaranteed Service
Seaman, et al. Standards Track [Page 5]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
The major issue is that admission control requests and
requirements are specified in terms of a multidimensional vector
parameters e.g., bandwidth, delay, jitter, service class.
multidimensional space must be mapped onto a set of traffic
whose default behavior in L2 switches is unidimensional (i.e.,
priority default queuing). This priority queuing alone can
only relative ordering between traffic classes. It can
enforce an absolute (quantifiable) delay bound for a traffic class
nor can it discriminate amongst Int-Serv flows within the
in a traffic class. Therefore, it cannot provide the absolute
of packet loss and delay required for individual Int-Serv flows
To provide absolute control of loss and delay three things
occur
(1) The amount of bandwidth available to the QoS-controlled
must be known, and the number of flows admitted to the
(allowed to use the bandwidth) must be limited
(2) A traffic scheduling mechanism is needed to give
service to flows with lower delay targets
(3) Some mechanism must ensure that best-effort flows and
controlled flows that are exceeding their Tspecs do not
the quality of service delivered to in-Tspec QoS
flows. This mechanism could be part of the traffic scheduler,
it could be a separate policing mechanism
For IEEE 802 networks, the first function (admission control)
provided by a Subnet Bandwidth Manager, as discussed below. We
the link-level user_priority mechanism at each switch and bridge
implement the second function (preferential service to flows
lower delay targets). Because a simple priority scheduler
provide policing (function three), policing for IEEE networks
generally implemented at the edge of the network by a layer-3 device
When this policing is performed only at the edges of the network
is of necessity approximate. This issue is discussed further
[IS802FRAME].
3.1. Context of admission control and delay
As described above, it is the combination of priority-
scheduling and admission control that creates quantified
bounds. Thus, any attempt to quantify the delay bounds expected by
given traffic class has to made in the context of the
control elements. Section 6 of the framework [IS802FRAME]
for two different models of admission control - centralized
distributed Bandwidth Allocators
Seaman, et al. Standards Track [Page 6]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
It is important to note that in this approach it is the
control algorithm that determines which of the Int-Serv services
being offered. Given a set of priority classes with delay targets,
relatively simple admission control algorithm can place flows
classes so that the bandwidth and delay behavior experienced by
flow corresponds to the requirements of the Controlled-Load service
but cannot offer the higher assurance of the Guaranteed service.
offer the Guaranteed service, the admission control algorithm must
much more stringent in its allocation of resources, and must
compute the C and D error terms required of this service
A delay bound can only be realized at the admission control
itself so any delay numbers attached to a traffic class represent
delay that a single element can allow for. That element
represent a whole L2 domain or just a single L2 segment
With either admission control model, the delay bound has no
outside of a L2 domain. The only requirement is that it be
by all Bandwidth Allocators in the L2 domain and, for example,
exported as C and D terms to L3 devices implementing the
Service. Thus, the end-to-end delay experienced by a flow can
be characterized by summing along the path using the usual
mechanisms
3.2. Default service
Table 1 presents the default mapping from delay targets to IEEE 802.1
user_priority classes. However, these mappings must be viewed
defaults, and must be changeable
In order to simplify the task of changing mappings, this
table is held by *switches* (and routers if desired) but
not by end-station hosts. It is a read-write table. The
proposed below are defaults and can be overridden by
control so long as all switches agree to some extent (the
level of agreement requires further analysis).
In future networks this mapping table might be adjusted
and without human intervention. It is possible that some form
network-wide lookup service could be implemented that
requests from clients e.g., traffic_class = getQoSbyName("H.323
video") and notified switches of what traffic categories they
likely to encounter and how to allocate those requests into
classes. Alternatively, the network's admission control
might directly adjust the mapping table to maximize the
of network resources. Such mechanisms are for further study
Seaman, et al. Standards Track [Page 7]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
The delay bounds numbers proposed in Table 1 are for per-
Allocator element delay targets and are derived from a
analysis of the needs of typical delay-sensitive applications e.g.,
voice, video. See Annex H of [802.1D] for further discussion of
selection of these values. Although these values appear to
the needs of current video and voice technology, it should be
that there is no requirement to adhere to these values and
dependence of IEEE 802.1 on these values
user_priority
0 Default, assumed to be Best
1 reserved, "less than" Best
2
3
4 Delay Sensitive, no
5 Delay Sensitive, 100ms
6 Delay Sensitive, 10ms
7 Network
Table 1 - Example user_priority to service
Note: These mappings are believed to be useful defaults
further implementation and usage experience is required.
mappings may be refined in future editions of this document
With this example set of mappings, delay-sensitive,
controlled traffic flows are mapped to user_priority values
ascending order of their delay bound requirement. Note that
bounds are targets only - see [IS802FRAME] for a discussion of
effects of other non-conformant flows on delay bounds of other flows
Only by applying admission control to higher-priority classes can
promises be made to lower-priority classes
This set of mappings also leaves several classes as reserved
future definition
Note: this mapping does not dictate what mechanisms or
a network element (e.g., an Ethernet switch) must perform
implement these mappings: this is an implementation choice
does not matter so long as the requirements for the
service model are met
Note: these mappings apply primarily to networks constructed
devices that implement the priority-scheduling behavior defined
the default in 802.1D. Some devices may implement more
scheduling behaviors not based only on priority. In
circumstance these mappings might still be used, but other,
Seaman, et al. Standards Track [Page 8]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
specialized mappings may be more appropriate
3.3.
The recommendation of classes 4, 5 and 6 for Delay Sensitive
Admission Controlled flows is somewhat arbitrary; any classes
priorities greater than that assigned to Best Effort can be used
Those proposed here have the advantage that, for transit
802.1D switches with only two-level strict priority queuing,
delay-sensitive traffic gets "high priority" treatment (the 802.1
default split is 0-3 and 4-7 for a device with 2 queues).
The choice of the delay bound targets is tuned to an average
application mix, and might be retuned by a network manager facing
widely different mix of user needs. The choice is potentially
significant: wise choice can lead to a much more efficient
of resources as well as greater (though still not very good
isolation between flows
Placing Network Control traffic at class 7 is necessary to
important traffic such as route updates and network management
Unfortunately, placing this traffic higher in the user_
ordering causes it to have a direct effect on the ability of
to provide assurances to QoS controlled application traffic
Therefore, an estimate of the amount of Network Control traffic
be made by any device that is performing admission control (e.g.,
SBMs). This would be in terms of the parameters that are
taken into account by the admission control algorithm. This
should be used in the admission control decisions for the
classes (the estimate is likely to be a configuration parameter
SBMs).
A traffic class such as class 1 for "less than best effort" might
useful for devices that wish to dynamically "penalty tag" all of
data of flows that are presently exceeding their allocation or Tspec
This provides a way to isolate flows that are exceeding their
limits from flows that are not, to avoid reducing the QoS
to flows that are within their contract. Data from such tagged
might also be preferentially discarded by an overloaded
device
A somewhat simpler approach would be to tag only the portion of
flow's packets that actually exceed the Tspec at any given instant
low priority. However, it is often considered to be a bad idea
treat flows in this way as it will likely cause significant re
ordering of the flow's packets, which is not desirable. Note that
default 802.1D treatment of user_priorities 1 and 2 is "less than
the default class 0.
Seaman, et al. Standards Track [Page 9]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
4. Computation of integrated services characterization parameters
IEEE 802
The integrated service model requires that each network element
supports integrated services compute and make available
"characterization parameters" describing the element's behavior
These parameters may be either generally applicable or specific to
particular QoS control service. These parameters may be computed
calculation, measurement, or estimation. When a network
cannot compute its own parameters (for example, a simple link),
assume that the device sending onto or receiving data from the
will compute the link's parameters as well as it's own. The
of calculation of these parameters may not be very critical; in
cases loose estimates are all that is required to provide a
service. This is important in the IEEE 802 case, where it will
virtually impossible to compute parameters accurately for
topologies and switch technologies. Indeed, it is an assumption
the use of this model by relatively simple switches (see [IS802FRAME
for a discussion of the different types of switch functionality
might be expected) that they merely provide values to describe
device and admit flows conservatively. The discussion below
a general outline for the computation of these parameters, and
out some cases where the parameters must be computed accurately
Further specification of how to export these parameters is
further study
4.1. General characterization
There are some general parameters [GENCHAR] that a device will
to use and/or supply for all service types
* Ingress
* Egress links and their MTUs, framing overheads and minimum
sizes (see media-specific information presented above).
* Available path bandwidth: updated hop-by-hop by any device
the path of the flow
* Minimum
Of these parameters, the MTU and minimum packet size information
be reported accurately. Also, the "break bits" must be set correctly
both the overall bit that indicates the existence of QoS
support and the individual bits that specify support for a
scheduling service. The available bandwidth should be reported
accurately as possible, but very loose estimates are acceptable.
minimum latency parameter should be determined and reported
Seaman, et al. Standards Track [Page 10]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
accurately as possible if the element offers Guaranteed service,
may be loosely estimated or reported as zero if the element
only Controlled-Load service
4.2. Parameters to implement Guaranteed
A network element supporting the Guaranteed Service [GS] must be
to determine the following parameters
* Constant delay bound through this device (in addition to any
provided by "minimum latency" above) and up to the receiver at
next network element for the packets of this flow if it were to
admitted. This includes any access latency bound to the
link as well as propagation delay across that link. This value
advertised as the 'C' parameter of the Guaranteed Service
* Rate-proportional delay bound through this device and up to
receiver at the next network element for the packets of this
if it were to be admitted. This value is advertised as the 'D
parameter of the Guaranteed Service
* Receive resources that would need to be associated with this
(e.g., buffering, bandwidth) if it were to be admitted and
suffer packet loss if it kept within its supplied Tspec/Rspec
These values are used by the admission control algorithm to
whether a new flow can be accepted by the device
* Transmit resources that would need to be associated with this
(e.g., buffering, bandwidth, constant- and rate-proportional
bounds) if it were to be admitted. These values are used by
admission control algorithm to decide whether a new flow can
accepted by the device
The exported characterization parameters for this service should
reported as accurately as possible. If estimations or
are used, they should err in whatever direction causes the user
receive better performance than requested. For example, the C and
error terms should overestimate delay, rather than underestimate it
4.3. Parameters to implement Controlled
A network element implementing the Controlled Load service [CL]
be able to determine the following
* Receive resources that would need to be associated with this
(e.g., buffering) if it were to be admitted. These values are
by the admission control algorithm to decide whether a new
can be accepted by the device
Seaman, et al. Standards Track [Page 11]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
* Transmit resources that would need to be associated with this
(e.g., buffering) if it were to be admitted. These values are
by the admission control algorithm to decide whether a new
can be accepted by the device
The Controlled Load service does not export any service-
characterization parameters. Internal resource allocation
should ensure that the service quality remains high when
the statistical aggregation of Controlled Load flows into 802
classes
4.4. Parameters to implement Best
For a network element that implements only best effort service
are no explicit parameters that need to be characterized. Note
an integrated services aware network element that implements
best effort service will set the "break bit" described
[RSVPINTSERV].
5. Merging of RSVP/SBM
Where reservations that use the SBM protocol's TCLASS object [SBM
need to be merged, an algorithm needs to be defined that
consistent with the mappings to individual user_priority values
use in the Layer-2 cloud. A merged reservation must receive at
as good a service as the best of the component reservations
There is no single merging rule that can prevent all of the
side-effects
* If a merger were to demote the existing branch of the flow into
higher-delay traffic class then this is a denial of service to
existing flow which would likely receive worse service
before
* If a merger were to promote the existing branch of the flow into
new, lower-delay, traffic class, this might then suffer
admission control failures or may cost more in some sense than
already-admitted flow. This can also be considered as a denial
of-service attack
* Promotion of the new branch may lead to rejection of the
because it has been re-assigned to a traffic class that has
enough resources to accommodate it
Therefore, such a merger is declared to be illegal and the usual
admission control failure rules are applied. Traffic class
is performed based on the TSpec information. When the first RESV
Seaman, et al. Standards Track [Page 12]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
a flow arrives, a traffic class is chosen based on the request,
SBM TCLASS object is inserted into the message and admission
for that traffic class is done by the SBM. Reservation succeeds
fails as usual
When a second RESV for the same flow arrives at a different
point of the Layer-2 cloud the process starts to repeat.
the SBM-augmented RESV may hit a switch with an existing
in place for the flow i.e., an L2 branch point for the flow. If so
the traffic class chosen for the second reservation is
against the first. If they are the same, the RESV requests are
and passed on towards the sender(s).
If the second TCLASS would have been different, an RSVP/SBM
error is returned to the Layer-3 device that launched the second
request into the Layer-2 cloud. This device will then pass on
ResvErr to the original requester according to RSVP rules.
processing rules are specified in [SBM].
6. Applicability of these service
Switches using layer-2-only standards (e.g., 802.1D-1990, 802.1D
1998) need to inter-operate with routers and layer-3 switches.
deployment of such 802.1D-1998 switches will occur in a number
roles in the network: "desktop switches" provide dedicated 10/100
Mbps links to end stations and high speed core switches often act
central campus switching points for layer-3 devices. Layer-2
will have to operate in all of the following scenarios
* every device along a network path is layer-3 capable and
into the full data
* only the edge devices are pure layer-2
* every alternate device lacks layer-3
* most devices lack layer-3 functionality except for some
control points such as router firewalls, for example
Where int-serv flows pass through equipment which does not
Integrated Services or 802.1D traffic management and which
all packets through the same queuing and overload-dropping paths
it is obvious that some of a flow's desired service
become more difficult to support. In particular, the
integrated service classes studied here, Controlled Load
Guaranteed Service, both assume that flows will be policed
kept "insulated" from misbehaving other flows or from best
traffic during their passage through the network. This cannot
Seaman, et al. Standards Track [Page 13]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
done within an IEEE 802 network using devices with the
user_priority function; in this case policing must be
at the network edges
In addition, in order to provide a Guaranteed Service, *all
switching elements along the path must participate in
treatment for packets in such flows: where there is a "break"
guaranteed service, all bets are off. Thus, a network path
includes even a single switch transmitting onto a shared or half
duplex LAN segment is unlikely to be able to provide a very
approximation to Guaranteed Service. For Controlled Load service
the requirements on the switches and link types are less
although it is still necessary to provide differential queuing
buffering in switches for CL flows over best effort in order
approximate CL service. Note that users receive indication of
breaks in the path through the "break bits" described in
[RSVPINTSERV]. These bits must be correctly set when IEEE 802
devices that cannot provide a specific service exist in a network
Other approaches might be to pass more information
switches about the capabilities of their neighbours and to
around non-QoS-capable switches: such methods are for
study. And of course the easiest solution of all is to
links and switches to higher capacities
7.
[802.1D-ORIG] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993
[802.1D] "Information technology - Telecommunications
information exchange between systems - Local
metropolitan area networks - Common specifications -
Part 3: Media Access Control (MAC) Bridges: Revision
This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
and 802.6k-1992. It incorporates P802.11c, P802.1p
P802.12e." ISO/IEC 15802-3:1998"
[INTSERV] Braden, R., Clark, D. and S. Shenker, "
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S
Jamin, "Resource Reservation Protocol (RSVP) -
1 Functional Specification", RFC 2205, September 1997.
[CL] Wroclawski, J., "Specification of the Controlled-
Network Element Service", RFC 2211, September 1997.
Seaman, et al. Standards Track [Page 14]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
[GS] Schenker, S., Partridge, C. and R. Guerin
"Specification of Guaranteed Quality of Service",
2212 September 1997.
[802.1Q] ANSI/IEEE Standard 802.1Q-1998, "IEEE Standards
Local and Metropolitan Area Networks: Virtual
Local Area Networks", 1998.
[GENCHAR] Shenker, S., and J. Wroclawski, "
Characterization Parameters for Integrated
Network Elements", RFC 2215, September 1997.
[IS802FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A.
M. Seaman, "A Framework for Providing
Services Over Shared and Switched LAN Technologies",
RFC 2816, May 2000.
[SBM] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M
Speer, "SBM (Subnet Bandwidth Manager): A Protocol
Admission Control over IEEE 802-style Networks",
2814, May 2000.
[RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF
Services", RFC 2210, September 1997.
[PROCESS] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
8. Security
Any use of QoS requires examination of security
because it leaves the possibility open for denial of service or
of service attacks. This document introduces no new security
on top of those discussed in the companion ISSLL
[IS802FRAME] and [SBM]. Any use of these service mappings
that all requests for service are authenticated appropriately
9.
This document draws heavily on the work of the ISSLL WG of the
and the IEEE P802.1 Interworking Task Group
Seaman, et al. Standards Track [Page 15]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
10. Authors'
Mick
480 S. California
Palo Alto, CA 94306
Email: mick@telseon.
Andrew
Extreme
3585 Monroe St
Santa Clara, CA 95051
Phone: +1 408 579 2821
EMail: andrew@extremenetworks.
Eric
Unisphere
5 Carlisle Rd
Westford, MA 01886
Phone: +1 978 692 1999
Email: esc@unispheresolutions.
John
MIT Laboratory for Computer
545 Technology Sq
Cambridge, MA 02139
Phone: +1 617 253 7885
EMail: jtw@lcs.mit.
Seaman, et al. Standards Track [Page 16]
RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Seaman, et al. Standards Track [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
