RFC2815 日本語訳
2815 Integrated Service Mappings on IEEE 802 Networks. M. Seaman, A.Smith, E. Crawley, J. Wroclawski. May 2000. (Format: TXT=42403 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Seaman
Request for Comments: 2815 Telseon
Category: Standards Track A. Smith
Extreme Networks
E. Crawley
Unisphere Solutions
J. Wroclawski
MIT LCS
May 2000
Network Working Group M. Seaman Request for Comments: 2815 Telseon Category: Standards Track A. Smith Extreme Networks E. Crawley Unisphere Solutions J. Wroclawski MIT LCS May 2000
Integrated Service Mappings on IEEE 802 Networks
Integrated Service Mappings on IEEE 802 Networks
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Abstract
This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches.
This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches.
These mappings are one component of the Integrated Services over IEEE 802 LANs framework.
These mappings are one component of the Integrated Services over IEEE 802 LANs framework.
Seaman, et al. Standards Track [Page 1] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
Seaman, et al. Standards Track [Page 1] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
Table of Contents
Table of Contents
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 parameters
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 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 parameters 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. Introduction
1. Introduction
The IEEE 802.1 Interworking Task Group has developed a set of enhancements to the basic MAC Service provided in Bridged Local Area Networks (a.k.a. "switched LANs"). As a supplement to the original IEEE MAC Bridges standard, IEEE 802.1D-1990 [802.1D-ORIG], the updated IEEE 802.1D-1998 [802.1D] proposes differential traffic class queuing in switches. The IEEE 802.1Q specification [802.1Q] extends the capabilities of Ethernet/802.3 media to carry a traffic class indicator, or "user_priority" field, within data frames.
The IEEE 802.1 Interworking Task Group has developed a set of enhancements to the basic MAC Service provided in Bridged Local Area Networks (a.k.a. "switched LANs"). As a supplement to the original IEEE MAC Bridges standard, IEEE 802.1D-1990 [802.1D-ORIG], the updated IEEE 802.1D-1998 [802.1D] proposes differential traffic class queuing in switches. The IEEE 802.1Q specification [802.1Q] extends the capabilities of Ethernet/802.3 media to carry a traffic class indicator, or "user_priority" field, within data frames.
The availability of this differential traffic queuing, together with additional mechanisms to provide admission control and signaling, allows IEEE 802 networks to support a close approximation of the IETF Integrated Services capabilities [CL][GS]. This document describes methods for mapping the service classes and parameters of the IETF model into IEEE 802.1D network parameters. A companion document [SBM] describes a signaling protocol for use with these mappings. It is recommended that readers be familiar with the overall framework in which these mappings and signaling protocol are expected to be used; this framework is described fully in [IS802FRAME].
The availability of this differential traffic queuing, together with additional mechanisms to provide admission control and signaling, allows IEEE 802 networks to support a close approximation of the IETF Integrated Services capabilities [CL][GS]. This document describes methods for mapping the service classes and parameters of the IETF model into IEEE 802.1D network parameters. A companion document [SBM] describes a signaling protocol for use with these mappings. It is recommended that readers be familiar with the overall framework in 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 end systems and routers bordering the IEEE Layer-2 cloud learn what traffic class should be used for each data flow's packets. Section 3 describes the approach recommended to map IP-level traffic flows to
Within this document, Section 2 describes the method by which end systems and routers bordering the IEEE Layer-2 cloud learn what traffic class should be used for each data flow's packets. Section 3 describes the approach recommended to map IP-level traffic flows to
Seaman, et al. Standards Track [Page 2] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
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 describes the computation of Characterization Parameters by the layer 2 network. The remaining sections discuss some particular issues with the use of the RSVP/SBM signaling protocols, and describe the applicability of all of the above to different layer 2 network topologies.
IEEE traffic classes within the Layer 2 network. Section 4 describes the computation of Characterization Parameters by the layer 2 network. The remaining sections discuss some particular issues with the use of the RSVP/SBM signaling protocols, and describe the applicability of all of the above to different layer 2 network topologies.
2. Flow Identification and Traffic Class Selection
2. Flow Identification and Traffic Class Selection
One model for supporting integrated services over specific link layers treats layer-2 devices very much as a special case of routers. In this model, switches and other devices along the data path make packet handling decisions based on the RSVP flow and filter specifications, and use these specifications to classify the corresponding data packets. The specifications could either be used directly, or could be used indirectly by mapping each RSVP session onto a layer-2 construct such as an ATM virtual circuit.
One model for supporting integrated services over specific link layers treats layer-2 devices very much as a special case of routers. In this model, switches and other devices along the data path make packet handling decisions based on the RSVP flow and filter specifications, and use these specifications to classify the corresponding data packets. The specifications could either be used directly, or could be used indirectly by mapping each RSVP session 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 increasing switch speed; devices with such filtering capabilities are likely to have a very similar implementation complexity to IP routers, and may not make use of simpler mechanisms such as 802.1D user priority.
This approach is inappropriate for use in the IEEE 802 environment. Filtering to the per-flow level becomes expensive with increasing switch speed; devices with such filtering capabilities are likely to have a very similar implementation complexity to IP routers, and may not make use of simpler mechanisms such as 802.1D user priority.
The Integrated Services over IEEE 802 LANs framework [IS802FRAME] and this document use an "aggregated flow" approach based on use of layer-2 traffic classes. In this model, each arriving flow is assigned to one of the available classes for the duration of the flow and traverses the 802 cloud in this class. Traffic flows requiring similar service are grouped together into a single class, while the system's admission control and class selection rules ensure that the service requirements for flows in each of the classes are met. In many situations this is a viable intermediate point between no QoS control and full router-type integrated services. The approach can work effectively even with switches implementing only the simplest differential traffic classification capability specified in the 802.1D model. In the aggregated flow model, traffic arriving at the boundary of a layer-2 cloud is tagged by the boundary device (end host or border router) with an appropriate traffic class, represented as an 802.1D "user_priority" value. Two fundamental questions are "who determines the correspondence between IP-level traffic flows and link-level classes?" and "how is this correspondence conveyed to the boundary devices that must mark the data frames?"
The Integrated Services over IEEE 802 LANs framework [IS802FRAME] and this document use an "aggregated flow" approach based on use of layer-2 traffic classes. In this model, each arriving flow is assigned to one of the available classes for the duration of the flow and traverses the 802 cloud in this class. Traffic flows requiring similar service are grouped together into a single class, while the system's admission control and class selection rules ensure that the service requirements for flows in each of the classes are met. In many situations this is a viable intermediate point between no QoS control and full router-type integrated services. The approach can work effectively even with switches implementing only the simplest differential traffic classification capability specified in the 802.1D model. In the aggregated flow model, traffic arriving at the boundary of a layer-2 cloud is tagged by the boundary device (end host or border router) with an appropriate traffic class, represented as an 802.1D "user_priority" value. Two fundamental questions are "who determines the correspondence between IP-level traffic flows and link-level classes?" and "how is this correspondence conveyed to the boundary devices that must mark the data frames?"
One approach to answering these questions would be for the meanings of the classes to be universally defined. This document would then 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 ms
One approach to answering these questions would be for the meanings of the classes to be universally defined. This document would then 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 ms
Seaman, et al. Standards Track [Page 3] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
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 defined classes could then be encoded directly in end stations, and the flow-to-class mappings computed directly in these devices.
peak delay target, etc. The meanings of these universally defined classes could then be encoded directly in end stations, and the flow-to-class mappings computed directly in these devices.
This universal definition approach would be simple to implement, but is too rigid to map the wide range of possible user requirements onto the limited number of available 802.1D classes. The model described in [IS802FRAME] uses a more flexible mapping: clients ask "the network" which user_priority traffic class to use for a given traffic flow, as categorized by its flow-spec and layer-2 endpoints. The network provides a value back to the requester that is appropriate considering the current network topology, load conditions, other admitted flows, etc. The task of configuring switches with this mapping (e.g., through network management, a switch-switch protocol or via some network-wide QoS-mapping directory service) is an order of magnitude less complex than performing the same function in end stations. Also, when new services (or other network reconfigurations) are added to such a network, the network elements will typically be the ones to be upgraded with new queuing algorithms etc. and can be provided with new mappings at this time.
This universal definition approach would be simple to implement, but is too rigid to map the wide range of possible user requirements onto the limited number of available 802.1D classes. The model described in [IS802FRAME] uses a more flexible mapping: clients ask "the network" which user_priority traffic class to use for a given traffic flow, as categorized by its flow-spec and layer-2 endpoints. The network provides a value back to the requester that is appropriate considering the current network topology, load conditions, other admitted flows, etc. The task of configuring switches with this mapping (e.g., through network management, a switch-switch protocol or via some network-wide QoS-mapping directory service) is an order of magnitude less complex than performing the same function in end stations. Also, when new services (or other network reconfigurations) are added to such a network, the network elements will typically be the ones to be upgraded with new queuing algorithms etc. and can be provided with new mappings at this time.
In the current model it is assumed that all data packets of a flow are assigned to the same traffic class for the duration of the flow: the characteristics of the MAC service, as defined by Clause 6 of [802.1D], then ensure the ordering of the data packets of the flow between adjacent Layer 3 routers. This is usually desirable to avoid potential re-ordering problems as discussed in [IS802FRAME] and [CL]. Note that there are some scenarios where it might be desirable to send conforming data traffic in one traffic class and non-conforming traffic for the same flow in a different, lower traffic class: such a division into separate traffic classes is for future study. When a new session or "flow" requiring QoS support is created, a client must ask "the network" which traffic class (IEEE 802 user_priority) to use for a given traffic flow, so that it can label the packets of the flow as it places them into the network. A request/response protocol is needed between client and network to return this information. The request can be piggy-backed onto an admission control request and the response can be piggy-backed onto an admission control acknowledgment. This "one pass" assignment has the benefit of completing the admission control transaction in a timely way and reducing the exposure to changing conditions that could occur if clients cached the knowledge for extensive periods. A set of extensions to the RSVP protocol for communicating this information have been defined [SBM].
In the current model it is assumed that all data packets of a flow are assigned to the same traffic class for the duration of the flow: the characteristics of the MAC service, as defined by Clause 6 of [802.1D], then ensure the ordering of the data packets of the flow between adjacent Layer 3 routers. This is usually desirable to avoid potential re-ordering problems as discussed in [IS802FRAME] and [CL]. Note that there are some scenarios where it might be desirable to send conforming data traffic in one traffic class and non-conforming traffic for the same flow in a different, lower traffic class: such a division into separate traffic classes is for future study. When a new session or "flow" requiring QoS support is created, a client must ask "the network" which traffic class (IEEE 802 user_priority) to use for a given traffic flow, so that it can label the packets of the flow as it places them into the network. A request/response protocol is needed between client and network to return this information. The request can be piggy-backed onto an admission control request and the response can be piggy-backed onto an admission control acknowledgment. This "one pass" assignment has the benefit of completing the admission control transaction in a timely way and reducing the exposure to changing conditions that could occur if clients cached the knowledge for extensive periods. A set of extensions to the RSVP protocol for communicating this information have been defined [SBM].
The network (i.e., the first network element encountered downstream from the client) must then answer the following questions:
The network (i.e., the first network element encountered downstream 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
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 for
this flow?
1. Which of the available traffic classes would be appropriate for this flow?
In general, a newly arriving flow might be assigned to a number
of classes. For example, if 10ms of delay is acceptable, the
flow could potentially be assigned to either a 10ms delay class
or a 1ms delay class. This packing problem is quite difficult to
solve if the target parameters of the classes are allowed to
change dynamically as flows arrive and depart. It is quite
simple if the target parameters of each class is held fixed, and
the class table is simply searched to find a class appropriate
for the arriving flow. This document adopts the latter
approach.
In general, a newly arriving flow might be assigned to a number of classes. For example, if 10ms of delay is acceptable, the flow could potentially be assigned to either a 10ms delay class or a 1ms delay class. This packing problem is quite difficult to solve if the target parameters of the classes are allowed to change dynamically as flows arrive and depart. It is quite simple if the target parameters of each class is held fixed, and the class table is simply searched to find a class appropriate for the arriving flow. This document adopts the latter approach.
2. Of the appropriate traffic classes, which if any have enough
capacity available to accept the new flow?
2. Of the appropriate traffic classes, which if any have enough capacity available to accept the new flow?
This is the admission control problem. It is necessary to
compare the level of traffic currently assigned to each class
with the available level of network resources (bandwidth,
buffers, etc), to ensure that adding the new flow to the class
will not cause the class's performance to go below its target
values. This problem is compounded because in a priority queuing
system adding traffic to a higher-priority class can affect the
performance of lower-priority classes. The admission control
algorithm for a system using the default 802 priority behavior
must be reasonably sophisticated to provide acceptable results.
This is the admission control problem. It is necessary to compare the level of traffic currently assigned to each class with the available level of network resources (bandwidth, buffers, etc), to ensure that adding the new flow to the class will not cause the class's performance to go below its target values. This problem is compounded because in a priority queuing system adding traffic to a higher-priority class can affect the performance of lower-priority classes. The admission control algorithm for a system using the default 802 priority behavior must be reasonably sophisticated to provide acceptable results.
If an acceptable class is found, the network returns the chosen user_priority value to the client.
If an acceptable class is found, the network returns the chosen user_priority value to the client.
Note that the client may be an end station, a router at the edge of the layer 2 network, or a first switch acting as a proxy for a device that does not participate in these protocols for whatever reason. Note also that a device e.g., a server or router may choose to implement both the "client" as well as the "network" portion of this model so that it can select its own user_priority values. Such an implementation would generally be discouraged unless the device has a close tie-in with the network topology and resource allocation policies. It may, however, work acceptably in cases where there is known over-provisioning of resources.
Note that the client may be an end station, a router at the edge of the layer 2 network, or a first switch acting as a proxy for a device that does not participate in these protocols for whatever reason. Note also that a device e.g., a server or router may choose to implement both the "client" as well as the "network" portion of this model so that it can select its own user_priority values. Such an implementation would generally be discouraged unless the device has a close tie-in with the network topology and resource allocation policies. It may, however, work acceptably in cases where there is known over-provisioning of resources.
3. Choosing a flow's IEEE 802 user_priority class
3. Choosing a flow's IEEE 802 user_priority class
This section describes the method by which IP-level flows are mapped into appropriate IEEE user_priority classes. The IP-level services considered are Best Effort, Controlled Load, and Guaranteed Service.
This section describes the method by which IP-level flows are mapped into appropriate IEEE user_priority classes. The IP-level services 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
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 application requirements are specified in terms of a multidimensional vector of parameters e.g., bandwidth, delay, jitter, service class. This multidimensional space must be mapped onto a set of traffic classes whose default behavior in L2 switches is unidimensional (i.e., strict priority default queuing). This priority queuing alone can provide only relative ordering between traffic classes. It can neither enforce an absolute (quantifiable) delay bound for a traffic class, nor can it discriminate amongst Int-Serv flows within the aggregate in a traffic class. Therefore, it cannot provide the absolute control of packet loss and delay required for individual Int-Serv flows.
The major issue is that admission control requests and application requirements are specified in terms of a multidimensional vector of parameters e.g., bandwidth, delay, jitter, service class. This multidimensional space must be mapped onto a set of traffic classes whose default behavior in L2 switches is unidimensional (i.e., strict priority default queuing). This priority queuing alone can provide only relative ordering between traffic classes. It can neither enforce an absolute (quantifiable) delay bound for a traffic class, nor can it discriminate amongst Int-Serv flows within the aggregate in a traffic class. Therefore, it cannot provide the absolute control of packet loss and delay required for individual Int-Serv flows.
To provide absolute control of loss and delay three things must occur:
To provide absolute control of loss and delay three things must occur:
(1) The amount of bandwidth available to the QoS-controlled flows
must be known, and the number of flows admitted to the network
(allowed to use the bandwidth) must be limited.
(1) The amount of bandwidth available to the QoS-controlled flows must be known, and the number of flows admitted to the network (allowed to use the bandwidth) must be limited.
(2) A traffic scheduling mechanism is needed to give preferential
service to flows with lower delay targets.
(2) A traffic scheduling mechanism is needed to give preferential service to flows with lower delay targets.
(3) Some mechanism must ensure that best-effort flows and QoS
controlled flows that are exceeding their Tspecs do not damage
the quality of service delivered to in-Tspec QoS controlled
flows. This mechanism could be part of the traffic scheduler, or
it could be a separate policing mechanism.
(3) Some mechanism must ensure that best-effort flows and QoS controlled flows that are exceeding their Tspecs do not damage the quality of service delivered to in-Tspec QoS controlled flows. This mechanism could be part of the traffic scheduler, or it could be a separate policing mechanism.
For IEEE 802 networks, the first function (admission control) is provided by a Subnet Bandwidth Manager, as discussed below. We use the link-level user_priority mechanism at each switch and bridge to implement the second function (preferential service to flows with lower delay targets). Because a simple priority scheduler cannot provide policing (function three), policing for IEEE networks is 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 it is of necessity approximate. This issue is discussed further in [IS802FRAME].
For IEEE 802 networks, the first function (admission control) is provided by a Subnet Bandwidth Manager, as discussed below. We use the link-level user_priority mechanism at each switch and bridge to implement the second function (preferential service to flows with lower delay targets). Because a simple priority scheduler cannot provide policing (function three), policing for IEEE networks is 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 it is of necessity approximate. This issue is discussed further in [IS802FRAME].
3.1. Context of admission control and delay bounds
3.1. Context of admission control and delay bounds
As described above, it is the combination of priority-based scheduling and admission control that creates quantified delay bounds. Thus, any attempt to quantify the delay bounds expected by a given traffic class has to made in the context of the admission control elements. Section 6 of the framework [IS802FRAME] provides for two different models of admission control - centralized or distributed Bandwidth Allocators.
As described above, it is the combination of priority-based scheduling and admission control that creates quantified delay bounds. Thus, any attempt to quantify the delay bounds expected by a given traffic class has to made in the context of the admission control elements. Section 6 of the framework [IS802FRAME] provides for two different models of admission control - centralized or distributed Bandwidth Allocators.
Seaman, et al. Standards Track [Page 6] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
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 admission control algorithm that determines which of the Int-Serv services is being offered. Given a set of priority classes with delay targets, a relatively simple admission control algorithm can place flows into classes so that the bandwidth and delay behavior experienced by each flow corresponds to the requirements of the Controlled-Load service, but cannot offer the higher assurance of the Guaranteed service. To offer the Guaranteed service, the admission control algorithm must be much more stringent in its allocation of resources, and must also compute the C and D error terms required of this service.
It is important to note that in this approach it is the admission control algorithm that determines which of the Int-Serv services is being offered. Given a set of priority classes with delay targets, a relatively simple admission control algorithm can place flows into classes so that the bandwidth and delay behavior experienced by each flow corresponds to the requirements of the Controlled-Load service, but cannot offer the higher assurance of the Guaranteed service. To offer the Guaranteed service, the admission control algorithm must be much more stringent in its allocation of resources, and must also compute the C and D error terms required of this service.
A delay bound can only be realized at the admission control element itself so any delay numbers attached to a traffic class represent the delay that a single element can allow for. That element may represent a whole L2 domain or just a single L2 segment.
A delay bound can only be realized at the admission control element itself so any delay numbers attached to a traffic class represent the delay that a single element can allow for. That element may represent a whole L2 domain or just a single L2 segment.
With either admission control model, the delay bound has no scope outside of a L2 domain. The only requirement is that it be understood by all Bandwidth Allocators in the L2 domain and, for example, be exported as C and D terms to L3 devices implementing the Guaranteed Service. Thus, the end-to-end delay experienced by a flow can only be characterized by summing along the path using the usual RSVP mechanisms.
With either admission control model, the delay bound has no scope outside of a L2 domain. The only requirement is that it be understood by all Bandwidth Allocators in the L2 domain and, for example, be exported as C and D terms to L3 devices implementing the Guaranteed Service. Thus, the end-to-end delay experienced by a flow can only be characterized by summing along the path using the usual RSVP mechanisms.
3.2. Default service mappings
3.2. Default service mappings
Table 1 presents the default mapping from delay targets to IEEE 802.1 user_priority classes. However, these mappings must be viewed as defaults, and must be changeable.
Table 1 presents the default mapping from delay targets to IEEE 802.1 user_priority classes. However, these mappings must be viewed as defaults, and must be changeable.
In order to simplify the task of changing mappings, this mapping table is held by *switches* (and routers if desired) but generally not by end-station hosts. It is a read-write table. The values proposed below are defaults and can be overridden by management control so long as all switches agree to some extent (the required level of agreement requires further analysis).
In order to simplify the task of changing mappings, this mapping table is held by *switches* (and routers if desired) but generally not by end-station hosts. It is a read-write table. The values proposed below are defaults and can be overridden by management control so long as all switches agree to some extent (the required level of agreement requires further analysis).
In future networks this mapping table might be adjusted dynamically
and without human intervention. It is possible that some form of
network-wide lookup service could be implemented that serviced
requests from clients e.g., traffic_class = getQoSbyName("H.323
video") and notified switches of what traffic categories they were
likely to encounter and how to allocate those requests into traffic
classes. Alternatively, the network's admission control mechanisms
might directly adjust the mapping table to maximize the utilization
of network resources. Such mechanisms are for further study.
In future networks this mapping table might be adjusted dynamically and without human intervention. It is possible that some form of network-wide lookup service could be implemented that serviced requests from clients e.g., traffic_class = getQoSbyName("H.323 video") and notified switches of what traffic categories they were likely to encounter and how to allocate those requests into traffic classes. Alternatively, the network's admission control mechanisms might directly adjust the mapping table to maximize the utilization 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
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-Bandwidth Allocator element delay targets and are derived from a subjective analysis of the needs of typical delay-sensitive applications e.g., voice, video. See Annex H of [802.1D] for further discussion of the selection of these values. Although these values appear to address the needs of current video and voice technology, it should be noted that there is no requirement to adhere to these values and no dependence of IEEE 802.1 on these values.
The delay bounds numbers proposed in Table 1 are for per-Bandwidth Allocator element delay targets and are derived from a subjective analysis of the needs of typical delay-sensitive applications e.g., voice, video. See Annex H of [802.1D] for further discussion of the selection of these values. Although these values appear to address the needs of current video and voice technology, it should be noted that there is no requirement to adhere to these values and no dependence of IEEE 802.1 on these values.
user_priority Service
user_priority Service
0 Default, assumed to be Best Effort
1 reserved, "less than" Best Effort
2 reserved
3 reserved
4 Delay Sensitive, no bound
5 Delay Sensitive, 100ms bound
6 Delay Sensitive, 10ms bound
7 Network Control
0 Default, assumed to be Best Effort 1 reserved, "less than" Best Effort 2 reserved 3 reserved 4 Delay Sensitive, no bound 5 Delay Sensitive, 100ms bound 6 Delay Sensitive, 10ms bound 7 Network Control
Table 1 - Example user_priority to service mappings
Table 1 - Example user_priority to service mappings
Note: These mappings are believed to be useful defaults but
further implementation and usage experience is required. The
mappings may be refined in future editions of this document.
Note: These mappings are believed to be useful defaults but further implementation and usage experience is required. The mappings may be refined in future editions of this document.
With this example set of mappings, delay-sensitive, admission controlled traffic flows are mapped to user_priority values in ascending order of their delay bound requirement. Note that the bounds are targets only - see [IS802FRAME] for a discussion of the effects of other non-conformant flows on delay bounds of other flows. Only by applying admission control to higher-priority classes can any promises be made to lower-priority classes.
With this example set of mappings, delay-sensitive, admission controlled traffic flows are mapped to user_priority values in ascending order of their delay bound requirement. Note that the bounds are targets only - see [IS802FRAME] for a discussion of the effects of other non-conformant flows on delay bounds of other flows. Only by applying admission control to higher-priority classes can any promises be made to lower-priority classes.
This set of mappings also leaves several classes as reserved for future definition.
This set of mappings also leaves several classes as reserved for future definition.
Note: this mapping does not dictate what mechanisms or algorithms
a network element (e.g., an Ethernet switch) must perform to
implement these mappings: this is an implementation choice and
does not matter so long as the requirements for the particular
service model are met.
Note: this mapping does not dictate what mechanisms or algorithms a network element (e.g., an Ethernet switch) must perform to implement these mappings: this is an implementation choice and does not matter so long as the requirements for the particular service model are met.
Note: these mappings apply primarily to networks constructed from
devices that implement the priority-scheduling behavior defined as
the default in 802.1D. Some devices may implement more complex
scheduling behaviors not based only on priority. In that
circumstance these mappings might still be used, but other, more
Note: these mappings apply primarily to networks constructed from devices that implement the priority-scheduling behavior defined as the default in 802.1D. Some devices may implement more complex scheduling behaviors not based only on priority. In that circumstance these mappings might still be used, but other, more
Seaman, et al. Standards Track [Page 8] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
Seaman, et al. Standards Track [Page 8] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
specialized mappings may be more appropriate.
specialized mappings may be more appropriate.
3.3. Discussion
3.3. Discussion
The recommendation of classes 4, 5 and 6 for Delay Sensitive, Admission Controlled flows is somewhat arbitrary; any classes with priorities greater than that assigned to Best Effort can be used. Those proposed here have the advantage that, for transit through 802.1D switches with only two-level strict priority queuing, all delay-sensitive traffic gets "high priority" treatment (the 802.1D default split is 0-3 and 4-7 for a device with 2 queues).
The recommendation of classes 4, 5 and 6 for Delay Sensitive, Admission Controlled flows is somewhat arbitrary; any classes with priorities greater than that assigned to Best Effort can be used. Those proposed here have the advantage that, for transit through 802.1D switches with only two-level strict priority queuing, all delay-sensitive traffic gets "high priority" treatment (the 802.1D 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 expected application mix, and might be retuned by a network manager facing a widely different mix of user needs. The choice is potentially very significant: wise choice can lead to a much more efficient allocation of resources as well as greater (though still not very good) isolation between flows.
The choice of the delay bound targets is tuned to an average expected application mix, and might be retuned by a network manager facing a widely different mix of user needs. The choice is potentially very significant: wise choice can lead to a much more efficient allocation of resources as well as greater (though still not very good) isolation between flows.
Placing Network Control traffic at class 7 is necessary to protect important traffic such as route updates and network management. Unfortunately, placing this traffic higher in the user_priority ordering causes it to have a direct effect on the ability of devices to provide assurances to QoS controlled application traffic. Therefore, an estimate of the amount of Network Control traffic must be made by any device that is performing admission control (e.g., SBMs). This would be in terms of the parameters that are normally taken into account by the admission control algorithm. This estimate should be used in the admission control decisions for the lower classes (the estimate is likely to be a configuration parameter of SBMs).
Placing Network Control traffic at class 7 is necessary to protect important traffic such as route updates and network management. Unfortunately, placing this traffic higher in the user_priority ordering causes it to have a direct effect on the ability of devices to provide assurances to QoS controlled application traffic. Therefore, an estimate of the amount of Network Control traffic must be made by any device that is performing admission control (e.g., SBMs). This would be in terms of the parameters that are normally taken into account by the admission control algorithm. This estimate should be used in the admission control decisions for the lower classes (the estimate is likely to be a configuration parameter of SBMs).
A traffic class such as class 1 for "less than best effort" might be useful for devices that wish to dynamically "penalty tag" all of the data of flows that are presently exceeding their allocation or Tspec. This provides a way to isolate flows that are exceeding their service limits from flows that are not, to avoid reducing the QoS delivered to flows that are within their contract. Data from such tagged flows might also be preferentially discarded by an overloaded downstream device.
A traffic class such as class 1 for "less than best effort" might be useful for devices that wish to dynamically "penalty tag" all of the data of flows that are presently exceeding their allocation or Tspec. This provides a way to isolate flows that are exceeding their service limits from flows that are not, to avoid reducing the QoS delivered to flows that are within their contract. Data from such tagged flows might also be preferentially discarded by an overloaded downstream device.
A somewhat simpler approach would be to tag only the portion of a flow's packets that actually exceed the Tspec at any given instant as low priority. However, it is often considered to be a bad idea to treat flows in this way as it will likely cause significant re- ordering of the flow's packets, which is not desirable. Note that the default 802.1D treatment of user_priorities 1 and 2 is "less than" the default class 0.
A somewhat simpler approach would be to tag only the portion of a flow's packets that actually exceed the Tspec at any given instant as low priority. However, it is often considered to be a bad idea to treat flows in this way as it will likely cause significant re- ordering of the flow's packets, which is not desirable. Note that the 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
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[9ページ]。
4. Computation of integrated services characterization parameters by
IEEE 802 devices
4. IEEE802デバイスによる統合サービス特殊化パラメタの計算
The integrated service model requires that each network element that supports integrated services compute and make available certain "characterization parameters" describing the element's behavior. These parameters may be either generally applicable or specific to a particular QoS control service. These parameters may be computed by calculation, measurement, or estimation. When a network element cannot compute its own parameters (for example, a simple link), we assume that the device sending onto or receiving data from the link will compute the link's parameters as well as it's own. The accuracy of calculation of these parameters may not be very critical; in some cases loose estimates are all that is required to provide a useful service. This is important in the IEEE 802 case, where it will be virtually impossible to compute parameters accurately for certain topologies and switch technologies. Indeed, it is an assumption of the use of this model by relatively simple switches (see [IS802FRAME] for a discussion of the different types of switch functionality that might be expected) that they merely provide values to describe the device and admit flows conservatively. The discussion below presents a general outline for the computation of these parameters, and points out some cases where the parameters must be computed accurately. Further specification of how to export these parameters is for further study.
統合サービスモデルは、統合サービスをサポートするそれぞれのネットワーク要素が要素の振舞いについて説明しながら利用可能なある「特殊化パラメタ」を計算して、作るのを必要とします。 これらのパラメタは、特定のQoSコントロールサービスに一般に、適切であるか、または特定であるかもしれません。 これらのパラメタは計算、測定、または見積りで計算されるかもしれません。 ネットワーク要素がそれ自身のパラメタ(例えば、単リンク)を計算できないとき、私たちは、リンクからデータを発信するか、または受け取るデバイスがリンクのパラメタをそれが自己であるのと同じくらいよく計算すると思います。 これらのパラメタの計算精度はそれほど重要でないかもしれません。 いくつかの場合、ゆるい見積りは役に立つサービスを提供するのに必要であるすべてです。 これはIEEE802場合で重要です。そこでは、あるtopologiesとスイッチ技術のために正確にパラメタを計算するのが実際には不可能でしょう。 本当に、それは彼らがデバイスについて説明して、保守的に流れを認めるために単に値を提供するという比較的簡単なスイッチ(予想されるかもしれない異なったタイプのスイッチの機能性の議論に関して[IS802FRAME]を見る)によるこのモデルの使用の仮定です。 以下での議論は、これらのパラメタの計算のための概要を提示して、正確にパラメタを計算しなければならないいくつかのケースを指摘します。 さらなる研究にはどうこれらのパラメタをエクスポートするかに関するさらなる仕様があります。
4.1. General characterization parameters
4.1. 一般的性質パラメタ
There are some general parameters [GENCHAR] that a device will need to use and/or supply for all service types:
すべてのサービスタイプのためのデバイスが使用する必要があるいくつかの一般的指標[GENCHAR]、そして/または、供給があります:
* Ingress link
* イングレスリンク
* Egress links and their MTUs, framing overheads and minimum packet
sizes (see media-specific information presented above).
* 出口のリンク、それらのMTUs、縁どりオーバーヘッド、および最小のパケットサイズ(メディア特殊情報が上に提示されるのを見ます)。
* Available path bandwidth: updated hop-by-hop by any device along
the path of the flow.
* 利用可能な経路帯域幅: ホップごとに、流れの経路に沿ったどんなデバイスもアップデートします。
* Minimum latency
* 最小の潜在
Of these parameters, the MTU and minimum packet size information must be reported accurately. Also, the "break bits" must be set correctly, both the overall bit that indicates the existence of QoS control support and the individual bits that specify support for a particular scheduling service. The available bandwidth should be reported as accurately as possible, but very loose estimates are acceptable. The minimum latency parameter should be determined and reported as
これらのパラメタでは、正確にMTUと最小のパケットサイズ情報を報告しなければなりません。 また、「中断ビット」は正確に言えば、QoSコントロールサポートの存在を示す総合的なビットと指定する個々のビットの両方が特定のスケジューリングサービスのために支えるセットであるに違いありません。 利用可能な帯域幅は可能な、しかし、非常にゆるい見積りが許容できるのと同じくらい正確に報告されるべきです。 最小の潜在パラメタとして、決定して、報告されるべきです。
Seaman, et al. Standards Track [Page 10] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[10ページ]。
accurately as possible if the element offers Guaranteed service, but may be loosely estimated or reported as zero if the element offers only Controlled-Load service.
ゼロが要素であるならControlled-負荷サービスだけを提供するのが要素としてサービスをGuaranteedに提供しますが、緩く見積もられているか、または報告されるかもしれないのと正確同じくらい可能です。
4.2. Parameters to implement Guaranteed Service
4.2. Guaranteed Serviceを実装するパラメタ
A network element supporting the Guaranteed Service [GS] must be able to determine the following parameters:
Guaranteed Serviceが[GS]であるとサポートするネットワーク要素は以下のパラメタを決定できなければなりません:
* Constant delay bound through this device (in addition to any value
provided by "minimum latency" above) and up to the receiver at the
next network element for the packets of this flow if it were to be
admitted. This includes any access latency bound to the outgoing
link as well as propagation delay across that link. This value is
advertised as the 'C' parameter of the Guaranteed Service.
* それが認められるつもりであったなら、一定の遅れは次のネットワーク要素でこの流れのパケットでこのデバイス(「最小の潜在」によって上に提供されたどんな値に加えた)と受信機まで付きました。 これはそのリンクの向こう側の伝播遅延と同様に出発しているリンクまで縛られたどんなアクセス潜在も含んでいます。 Guaranteed Serviceの'C'パラメタとしてこの値の広告を出します。
* Rate-proportional delay bound through this device and up to the
receiver at the next network element for the packets of this flow
if it were to be admitted. This value is advertised as the 'D'
parameter of the Guaranteed Service.
* それが認められるつもりであったなら、レート比例している遅れは次のネットワーク要素でこの流れのパケットでこのデバイスと受信機まで付きました。 Guaranteed Serviceの'D'パラメタとしてこの値の広告を出します。
* Receive resources that would need to be associated with this flow
(e.g., buffering, bandwidth) if it were to be admitted and not
suffer packet loss if it kept within its supplied Tspec/Rspec.
These values are used by the admission control algorithm to decide
whether a new flow can be accepted by the device.
* 供給されたTspec/Rspecを制限したなら、認められて、パケット損失を受けないならこの流れ(例えば、バッファリング、帯域幅)に関連している必要があるリソースを受け取ってください。 これらの値は、デバイスで新しい流れを受け入れることができるかどうか決めるのに入場コントロールアルゴリズムで使用されます。
* Transmit resources that would need to be associated with this flow
(e.g., buffering, bandwidth, constant- and rate-proportional delay
bounds) if it were to be admitted. These values are used by the
admission control algorithm to decide whether a new flow can be
accepted by the device.
* それが認められることになっているならこの流れ(例えば、バッファリング、帯域幅、一定の、そして、レート比例している遅れはバウンドしている)に関連している必要があるリソースを伝えてください。 これらの値は、デバイスで新しい流れを受け入れることができるかどうか決めるのに入場コントロールアルゴリズムで使用されます。
The exported characterization parameters for this service should be reported as accurately as possible. If estimations or approximations are used, they should err in whatever direction causes the user to receive better performance than requested. For example, the C and D error terms should overestimate delay, rather than underestimate it.
このサービスのためのエクスポートしている特殊化パラメタはできるだけ正確に報告されるべきです。 見積りか近似が使用されているなら、それらはユーザが要求されているより良い性能を受け取るいかなる方向にも間違えるべきです。 例えば、CとD誤差項はそれを過小評価するよりむしろ遅れを過大評価するべきです。
4.3. Parameters to implement Controlled Load
4.3. Controlled Loadを実装するパラメタ
A network element implementing the Controlled Load service [CL] must be able to determine the following:
Controlled Loadがサービス[CL]であると実装するネットワーク要素は以下を決定できなければなりません:
* Receive resources that would need to be associated with this flow
(e.g., buffering) if it were to be admitted. These values are used
by the admission control algorithm to decide whether a new flow
can be accepted by the device.
* それが認められることになっているならこの流れ(例えば、バッファリング)に関連している必要があるリソースを受け取ってください。 これらの値は、デバイスで新しい流れを受け入れることができるかどうか決めるのに入場コントロールアルゴリズムで使用されます。
Seaman, et al. Standards Track [Page 11] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[11ページ]。
* Transmit resources that would need to be associated with this flow
(e.g., buffering) if it were to be admitted. These values are used
by the admission control algorithm to decide whether a new flow
can be accepted by the device.
* それが認められることになっているならこの流れ(例えば、バッファリング)に関連している必要があるリソースを伝えてください。 これらの値は、デバイスで新しい流れを受け入れることができるかどうか決めるのに入場コントロールアルゴリズムで使用されます。
The Controlled Load service does not export any service-specific characterization parameters. Internal resource allocation estimates should ensure that the service quality remains high when considering the statistical aggregation of Controlled Load flows into 802 traffic classes.
Controlled Loadサービスは、どんなサービス特有の特殊化もパラメタであるとエクスポートしません。 内部の資源配分見積りは、Controlled Loadの統計的な集合が802のトラフィックのクラスに流れると考えるとき、サービス品質が高いままで残っているのを確実にするべきです。
4.4. Parameters to implement Best Effort
4.4. Best Effortを実装するパラメタ
For a network element that implements only best effort service there are no explicit parameters that need to be characterized. Note that an integrated services aware network element that implements only best effort service will set the "break bit" described in [RSVPINTSERV].
ベストエフォート型サービスだけを実装するネットワーク要素のために、特徴付けられる必要があるどんな明白なパラメタもありません。 ベストエフォート型サービスだけを実装するネットワーク要素がそうするのを意識している統合サービスが[RSVPINTSERV]で説明された「中断ビット」を設定することに注意してください。
5. Merging of RSVP/SBM objects
5. RSVP/SBMオブジェクトの合併
Where reservations that use the SBM protocol's TCLASS object [SBM] need to be merged, an algorithm needs to be defined that is consistent with the mappings to individual user_priority values in use in the Layer-2 cloud. A merged reservation must receive at least as good a service as the best of the component reservations.
SBMプロトコルのTCLASSオブジェクト[SBM]を使用する予約が、合併される必要があるところでは、アルゴリズムは、定義されて、それがLayer-2雲で使用中の個々のユーザ_優先順位の値へのマッピングと一致しているということである必要があります。 合併している予約は少なくともコンポーネントの予約のベストと同じくらい良いサービスを受けなければなりません。
There is no single merging rule that can prevent all of the following side-effects:
以下の副作用のすべてを防ぐことができるどんなただ一つの合併している規則もありません:
* If a merger were to demote the existing branch of the flow into a
higher-delay traffic class then this is a denial of service to the
existing flow which would likely receive worse service than
before.
* 合併が、より高い遅れトラフィックのクラスへの流れの既存のブランチを格下げすることであったなら、これはおそらく以前より悪いサービスを受ける既存の流れに対するサービスの否定です。
* If a merger were to promote the existing branch of the flow into a
new, lower-delay, traffic class, this might then suffer either
admission control failures or may cost more in some sense than the
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 request
because it has been re-assigned to a traffic class that has not
enough resources to accommodate it.
* それがそれを収容できるくらいのどんなリソースも持っていないトラフィックのクラスに再選任されたので、新しいブランチの販売促進は要求の拒絶につながるかもしれません。
Therefore, such a merger is declared to be illegal and the usual SBM admission control failure rules are applied. Traffic class selection is performed based on the TSpec information. When the first RESV for
したがって、そのような合併が不法であると宣言されて、普通のSBM入場規制失敗規則は申し込まれます。 トラフィッククラス選択はTSpec情報に基づいて実行されます。 最初のRESVです。
Seaman, et al. Standards Track [Page 12] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[12ページ]。
a flow arrives, a traffic class is chosen based on the request, an SBM TCLASS object is inserted into the message and admission control for that traffic class is done by the SBM. Reservation succeeds or fails as usual.
流れは到着します、そして、トラフィックのクラスは要求に基づいて選ばれています、そして、SBM TCLASSオブジェクトはメッセージに挿入されます、そして、そのトラフィックのクラスのための入場コントロールがSBMによって行われます。 予約は、成功するか、またはいつものように失敗します。
When a second RESV for the same flow arrives at a different egress point of the Layer-2 cloud the process starts to repeat. Eventually the SBM-augmented RESV may hit a switch with an existing reservation 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 checked against the first. If they are the same, the RESV requests are merged and passed on towards the sender(s).
同じ流れのための第2のRESVがLayer-2雲の異なった出口ポイントに到着するとき、プロセスは繰り返し始めます。 結局、SBMによって増大させられたRESVは流れのために流れの適所にある既存の予約でスイッチにすなわち、L2ブランチポイント当るかもしれません。 そうだとすれば、2番目の予約に選ばれたトラフィックのクラスは1番目に対してチェックされます。 それらが同じであるなら、RESV要求は、送付者に向かって合併されていて、伝えられます。
If the second TCLASS would have been different, an RSVP/SBM ResvErr error is returned to the Layer-3 device that launched the second RESV request into the Layer-2 cloud. This device will then pass on the ResvErr to the original requester according to RSVP rules. Detailed processing rules are specified in [SBM].
第2TCLASSが異なっているなら、RSVP/SBM ResvErr誤りはRESVがLayer-2雲の中に要求する2番目を始めたLayer-3デバイスに返されます。 そして、RSVP規則に従って、このデバイスはオリジナルのリクエスタにResvErrを伝えるでしょう。 詳細な処理規則は[SBM]で指定されます。
6. Applicability of these service mappings
6. これらのサービス対応表の適用性
Switches using layer-2-only standards (e.g., 802.1D-1990, 802.1D- 1998) need to inter-operate with routers and layer-3 switches. Wide deployment of such 802.1D-1998 switches will occur in a number of roles in the network: "desktop switches" provide dedicated 10/100 Mbps links to end stations and high speed core switches often act as central campus switching points for layer-3 devices. Layer-2 devices will have to operate in all of the following scenarios:
層2だけの規格(例えば、802.1D-1990、802.1D1998)を使用するスイッチは、ルータと層-3個のスイッチで共同利用する必要があります。 そのような802.1D-1998スイッチの広い展開はネットワークにおける多くの役割で起こるでしょう: 「デスクトップスイッチ」はステーションを終わらせるために10/100個の専用Mbpsリンクを提供します、そして、中央のキャンパスの切り換えが層-3台のデバイスのために指すとき、高速コアスイッチはしばしば作動します。 層-2台のデバイスが以下のシナリオのすべてで作動しなければならないでしょう:
* every device along a network path is layer-3 capable and intrusive
into the full data stream
* ネットワーク経路に沿ったあらゆるデバイスが、完全なデータ・ストリームの中に層-3のできて貫入しています。
* only the edge devices are pure layer-2
* 唯一のエッジデバイスは純粋な層-2です。
* every alternate device lacks layer-3 functionality
* あらゆる代替装置が層-3の機能性を欠いています。
* most devices lack layer-3 functionality except for some key
control points such as router firewalls, for example.
* ほとんどのデバイスが例えば、ルータファイアウォールなどの主要ないくつかの制御点以外の層-3の機能性を欠いています。
Where int-serv flows pass through equipment which does not support
Integrated Services or 802.1D traffic management and which places
all packets through the same queuing and overload-dropping paths,
it is obvious that some of a flow's desired service parameters
become more difficult to support. In particular, the two
integrated service classes studied here, Controlled Load and
Guaranteed Service, both assume that flows will be policed and
kept "insulated" from misbehaving other flows or from best effort
traffic during their passage through the network. This cannot be
int-serv流れが同じ列を作りとオーバーロードを下げる経路を通してIntegrated Servicesか802.1Dに輸送管理をサポートするというわけではなくて、どの場所にすべてのパケットをサポートするというわけではない設備を通り抜けるところでは、流れの必要なサービスパラメタのいくつかがサポートするのが、より難しくなるのは、明白です。 ここで研究されたクラス、Controlled Load、およびGuaranteed Serviceがともに仮定する流れる2の統合サービスは、他のふらちな事をしている流れ、または、それらの通路の間のベストエフォート型トラフィックからネットワークまで「絶縁される」ように特に、取り締まられて、保たれるでしょう。 これはそうであるはずがありません。
Seaman, et al. Standards Track [Page 13] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[13ページ]。
done within an IEEE 802 network using devices with the default
user_priority function; in this case policing must be approximated
at the network edges.
IEEE802ネットワークの中でデフォルトユーザ_優先権機能があるデバイスを使用することでします。 この場合、ネットワーク縁で取り締まりに近似しなければなりません。
In addition, in order to provide a Guaranteed Service, *all*
switching elements along the path must participate in special
treatment for packets in such flows: where there is a "break" in
guaranteed service, all bets are off. Thus, a network path that
includes even a single switch transmitting onto a shared or half-
duplex LAN segment is unlikely to be able to provide a very good
approximation to Guaranteed Service. For Controlled Load service,
the requirements on the switches and link types are less stringent
although it is still necessary to provide differential queuing and
buffering in switches for CL flows over best effort in order to
approximate CL service. Note that users receive indication of such
breaks in the path through the "break bits" described in y
[RSVPINTSERV]. These bits must be correctly set when IEEE 802
devices that cannot provide a specific service exist in a network.
*さらに、Guaranteed Serviceを提供するために、経路に沿ったすべての*スイッチング素子がそのような流れでパケットに関する特別な処理に参加しなければなりません: 保証されたサービスにおける「中断」があるところでは、すべての賭けがオフです。 したがって、共有されたか半分重複のLANセグメントに送られる単一のスイッチさえ含んでいるネットワーク経路は非常に良い近似をGuaranteed Serviceに供給しそうであることができません。 Controlled Loadサービスにおいて、特異な列を作りを提供するのがまだ必要であり、CLのためのスイッチでのバッファリングはCLサービスに近似するためにベストエフォート型の上を流れますが、スイッチとリンク型に関する要件はそれほど厳しくはありません。 ユーザがy[RSVPINTSERV]で説明された「中断ビット」を通して経路のそのような中断のしるしを受けることに注意してください。 特定のサービスを提供できないIEEE802デバイスがネットワークで存在するとき、正しくこれらのビットを設定しなければなりません。
Other approaches might be to pass more information between
switches about the capabilities of their neighbours and to route
around non-QoS-capable switches: such methods are for further
study. And of course the easiest solution of all is to upgrade
links and switches to higher capacities.
他のアプローチは、彼らの隣人の能力に関してスイッチの間に詳しい情報を通過して、できる非QoSスイッチの周りで以下を発送することであるかもしれません。 さらなる研究にはそのようなメソッドがあります。 そして、もちろんすべての最も簡単なソリューションはリンクとスイッチをより高い能力にアップグレードさせることです。
7. References
7. 参照
[802.1D-ORIG] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993
[802.1D-ORIG]「MACブリッジ」、ISO/IEC10038、ANSI/IEEE Std 802.1D-1993
[802.1D] "Information technology - Telecommunications and
information exchange between systems - Local and
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 and
P802.12e." ISO/IEC 15802-3:1998"
[802.1D] 「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク(一般的な仕様)は3を分けます」。 メディアアクセスは(MAC)ブリッジを制御します: 改正。 これはISO/IEC10038の改正です: 1993 802.1j-1992と802.6k-1992。 「P802.11c、P802.1p、およびP802.12e.を組み込みます」 「ISO/IEC15802-3: 1998」
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[INTSERV] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Reservation Protocol (RSVP) - Version
1 Functional Specification", RFC 2205, September 1997.
[RSVP] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[CL] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[Cl] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
Seaman, et al. Standards Track [Page 14] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[14ページ]。
[GS] Schenker, S., Partridge, C. and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212 September 1997.
[GS] シェンカーとS.とヤマウズラとC.とR.ゲラン、「保証されたサービスの質の仕様」、RFC2212 1997年9月。
[802.1Q] ANSI/IEEE Standard 802.1Q-1998, "IEEE Standards for
Local and Metropolitan Area Networks: Virtual Bridged
Local Area Networks", 1998.
[802.1Q]ANSI/IEEEの標準の802.1Q-1998、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「仮想のブリッジしているローカル・エリア・ネットワーク」、1998。
[GENCHAR] Shenker, S., and J. Wroclawski, "General
Characterization Parameters for Integrated Service
Network Elements", RFC 2215, September 1997.
[GENCHAR] Shenker、S.、およびJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[IS802FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and
M. Seaman, "A Framework for Providing Integrated
Services Over Shared and Switched LAN Technologies",
RFC 2816, May 2000.
[IS802FRAME]Ghanwani、A.、失礼ですが、W.とSrinivasanとV.とスミスとA.とM.船員、「共有されて切り換えられたLAN技術の上に統合サービスを提供するためのフレームワーク」、RFC2816、2000年5月。
[SBM] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M.
Speer, "SBM (Subnet Bandwidth Manager): A Protocol for
Admission Control over IEEE 802-style Networks", RFC
2814, May 2000.
[SBM] Yavatkar、R.、ホフマン、D.、Bernet、Y.、ベイカー、F.、およびM.シュペーア、「SBM(サブネット帯域幅マネージャ):」 「IEEEの802スタイルのネットワークの入場コントロールのためのプロトコル」(RFC2814)は2000がそうするかもしれません。
[RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RSVPINTSERV] Wroclawski、J.、「IETF Integrated ServicesとのRSVPの使用」、RFC2210、1997年9月。
[PROCESS] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[処理します] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
8. Security Considerations
8. セキュリティ問題
Any use of QoS requires examination of security considerations because it leaves the possibility open for denial of service or theft of service attacks. This document introduces no new security issues on top of those discussed in the companion ISSLL documents [IS802FRAME] and [SBM]. Any use of these service mappings assumes that all requests for service are authenticated appropriately.
可能性をサービスの否定かサービス攻撃の窃盗において開いた状態でおくので、QoSのどんな使用もセキュリティ問題の試験を必要とします。 このドキュメントは仲間ISSLLドキュメント[IS802FRAME]と[SBM]で議論したものの上でどんな新しい安全保障問題も紹介しません。 これらのサービス対応表のどんな使用も、サービスを求めるすべての要求が適切に認証されると仮定します。
9. Acknowledgments
9. 承認
This document draws heavily on the work of the ISSLL WG of the IETF and the IEEE P802.1 Interworking Task Group.
このドキュメントは大いにIETFとIEEE P802.1 Interworking Task GroupのISSLL WGの仕事を利用します。
Seaman, et al. Standards Track [Page 15] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[15ページ]。
10. Authors' Addresses
10. 作者のアドレス
Mick Seaman Telseon 480 S. California Ave Palo Alto, CA 94306 USA
ミック船員Telseon480秒間カリフォルニアAveパロアルト、カリフォルニア94306米国
Email: mick@telseon.com
メール: mick@telseon.com
Andrew Smith Extreme Networks 3585 Monroe St. Santa Clara, CA 95051 USA
アンドリュー・スミスExtremeは3585モンロー通りカリフォルニア95051サンタクララ(米国)をネットワークでつなぎます。
Phone: +1 408 579 2821 EMail: andrew@extremenetworks.com
以下に電話をしてください。 +1 2821年の408 579メール: andrew@extremenetworks.com
Eric Crawley Unisphere Solutions 5 Carlisle Rd. Westford, MA 01886
エリッククローリーUnisphereソリューション5カーライル通り ウェストフォード、MA 01886
Phone: +1 978 692 1999 Email: esc@unispheresolutions.com
以下に電話をしてください。 +1 1999年の978 692メール: esc@unispheresolutions.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 USA
ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA02139米国
Phone: +1 617 253 7885 EMail: jtw@lcs.mit.edu
以下に電話をしてください。 +1 7885年の617 253メール: jtw@lcs.mit.edu
Seaman, et al. Standards Track [Page 16] RFC 2815 Int-Serv Mappings on IEEE 802 Networks May 2000
船員、他 規格は2000年5月にIEEE802ネットワークに関するRFC2815Int-Servマッピングを追跡します[16ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Seaman, et al. Standards Track [Page 17]
船員、他 標準化過程[17ページ]
一覧
スポンサーリンク
