RFC4958 日本語訳
4958 A Framework for Supporting Emergency Telecommunications Services(ETS) within a Single Administrative Domain. K. Carlberg. July 2007. (Format: TXT=44008 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Carlberg Request for Comments: 4958 G11 Category: Informational July 2007
Network Working Group K. Carlberg Request for Comments: 4958 G11 Category: Informational July 2007
A Framework for Supporting Emergency Telecommunications Services (ETS)
within a Single Administrative Domain
A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
Abstract
Abstract
This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented.
This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented.
Carlberg Informational [Page 1] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 1] RFC 4958 ETS Single Domain Framework July 2007
Table of Contents
Table of Contents
1. Introduction ....................................................3
1.1. Differences between Single and Inter-Domain ................3
2. Common Practice: Provisioning ...................................4
3. Objective .......................................................5
3.1. Scenarios ..................................................5
4. Topic Areas .....................................................6
4.1. MPLS .......................................................6
4.2. RSVP .......................................................7
4.2.1. Relation to ETS .....................................8
4.3. Policy .....................................................8
4.4. Subnetwork Technologies ....................................9
4.4.1. IEEE 802.1 VLANs ....................................9
4.4.2. IEEE 802.11e QoS ...................................10
4.4.3. Cable Networks .....................................10
4.5. Multicast .................................................11
4.5.1. IP Layer ...........................................12
4.5.2. IEEE 802.1d MAC Bridges ............................12
4.6. Discovery .................................................13
4.7. Differentiated Services (Diffserv) ........................14
5. Security Considerations ........................................14
6. Summary Comments ...............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative Reference .......................................15
8.2. Informative References ....................................15
1. Introduction ....................................................3 1.1. Differences between Single and Inter-Domain ................3 2. Common Practice: Provisioning ...................................4 3. Objective .......................................................5 3.1. Scenarios ..................................................5 4. Topic Areas .....................................................6 4.1. MPLS .......................................................6 4.2. RSVP .......................................................7 4.2.1. Relation to ETS .....................................8 4.3. Policy .....................................................8 4.4. Subnetwork Technologies ....................................9 4.4.1. IEEE 802.1 VLANs ....................................9 4.4.2. IEEE 802.11e QoS ...................................10 4.4.3. Cable Networks .....................................10 4.5. Multicast .................................................11 4.5.1. IP Layer ...........................................12 4.5.2. IEEE 802.1d MAC Bridges ............................12 4.6. Discovery .................................................13 4.7. Differentiated Services (Diffserv) ........................14 5. Security Considerations ........................................14 6. Summary Comments ...............................................15 7. Acknowledgements ...............................................15 8. References .....................................................15 8.1. Normative Reference .......................................15 8.2. Informative References ....................................15
Carlberg Informational [Page 2] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 2] RFC 4958 ETS Single Domain Framework July 2007
1. Introduction
1. Introduction
This document presents a framework for supporting Emergency Telecommunications Services (ETS) within the scope of a single administrative domain. This narrow scope provides a reference point for considering protocols that could be deployed to support ETS. [rfc4375] is a complementary effort that articulates requirements for a single administrative domain and defines it as "collection of resources under the control of a single administrative authority". We use this other effort as both a starting point and guide for this document.
This document presents a framework for supporting Emergency Telecommunications Services (ETS) within the scope of a single administrative domain. This narrow scope provides a reference point for considering protocols that could be deployed to support ETS. [rfc4375] is a complementary effort that articulates requirements for a single administrative domain and defines it as "collection of resources under the control of a single administrative authority". We use this other effort as both a starting point and guide for this document.
A different example of a framework document for ETS is [rfc4190], which focused on support for ETS within IP telephony. In this case, the focal point was a particular application whose flows could span multiple autonomous domains. Even though this document uses a somewhat more constrained perspective than [rfc4190], we can still expect some measure of overlap in the areas that are discussed.
A different example of a framework document for ETS is [rfc4190], which focused on support for ETS within IP telephony. In this case, the focal point was a particular application whose flows could span multiple autonomous domains. Even though this document uses a somewhat more constrained perspective than [rfc4190], we can still expect some measure of overlap in the areas that are discussed.
1.1. Differences between Single and Inter-Domain
1.1. Differences between Single and Inter-Domain
The progression of our work in the following sections is helped by stating some key differences between the single and inter-domain cases. From a general perspective, one can start by observing the following.
The progression of our work in the following sections is helped by stating some key differences between the single and inter-domain cases. From a general perspective, one can start by observing the following.
a) Congruent with physical topology of resources, each domain is
an authority zone, and there is currently no scalable way to
transfer authority between zones.
a) Congruent with physical topology of resources, each domain is an authority zone, and there is currently no scalable way to transfer authority between zones.
b) Each authority zone is under separate management.
b) Each authority zone is under separate management.
c) Authority zones are run by competitors; this acts as further
deterrent to transferring authority.
c) Authority zones are run by competitors; this acts as further deterrent to transferring authority.
As a result of the initial statements in (a) through (c) above, additional observations can be made that distinguish the single and inter-domain cases, as follows.
As a result of the initial statements in (a) through (c) above, additional observations can be made that distinguish the single and inter-domain cases, as follows.
d) Different policies might be implemented in different
administrative domains.
d) Different policies might be implemented in different administrative domains.
e) There is an absence of any practical method for ingress nodes
of a transit domain to authenticate all of the IP network layer
packets that have labels indicating a preference or importance.
e) There is an absence of any practical method for ingress nodes of a transit domain to authenticate all of the IP network layer packets that have labels indicating a preference or importance.
Carlberg Informational [Page 3] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 3] RFC 4958 ETS Single Domain Framework July 2007
f) Given item (d) above, all current inter-domain QoS mechanisms
at the network level generally create easily exploited and
significantly painful Denial of Service (DoS) / Distributed
Denial of Service (DDoS) attack vectors on the network.
f) Given item (d) above, all current inter-domain QoS mechanisms at the network level generally create easily exploited and significantly painful Denial of Service (DoS) / Distributed Denial of Service (DDoS) attack vectors on the network.
g) A single administrative domain can deploy various mechanisms
(e.g., access control lists) into each and every edge device
(e.g., ethernet switch or router) to ensure that only
authorized end-users (or layer 2 interfaces) are able to emit
frames/packets with non-default QoS labels into the network.
This is not feasible in the inter-domain case because the
inter-domain link contains aggregated flows. In addition, the
dissemination of access control lists at the network level is
not scalable in the inter-domain case.
g) A single administrative domain can deploy various mechanisms (e.g., access control lists) into each and every edge device (e.g., ethernet switch or router) to ensure that only authorized end-users (or layer 2 interfaces) are able to emit frames/packets with non-default QoS labels into the network. This is not feasible in the inter-domain case because the inter-domain link contains aggregated flows. In addition, the dissemination of access control lists at the network level is not scalable in the inter-domain case.
h) A single domain can deploy mechanisms into the edge devices to
enforce its domain-wide policies -- without having to trust any
third party to configure things correctly. This is not
possible in the inter-domain case.
h) A single domain can deploy mechanisms into the edge devices to enforce its domain-wide policies -- without having to trust any third party to configure things correctly. This is not possible in the inter-domain case.
While the above is not an all-inclusive set of differences, it does provide some rationale why one may wish to focus efforts in the more constrained scenario of a single administrative domain.
While the above is not an all-inclusive set of differences, it does provide some rationale why one may wish to focus efforts in the more constrained scenario of a single administrative domain.
2. Common Practice: Provisioning
2. Common Practice: Provisioning
The IEPREP working group and mailing list have had extensive discussions about over-provisioning. Many of these exchanges have debated the need for QoS mechanisms versus over-provisioning of links.
The IEPREP working group and mailing list have had extensive discussions about over-provisioning. Many of these exchanges have debated the need for QoS mechanisms versus over-provisioning of links.
In reality, most IP network links are provisioned with a percentage of excess capacity beyond that of the average load. The 'shared' resource model together with TCP's congestion avoidance algorithms helps compensate for those cases where spikes or bursts of traffic are experienced by the network.
In reality, most IP network links are provisioned with a percentage of excess capacity beyond that of the average load. The 'shared' resource model together with TCP's congestion avoidance algorithms helps compensate for those cases where spikes or bursts of traffic are experienced by the network.
The thrust of the debate within the IEPREP working group is whether it is always better to over-provision links to such a degree that spikes in load can still be supported with no loss due to congestion. Advocates of this position point to many ISPs in the US that take this approach instead of using QoS mechanisms to honor agreements with their peers or customers. These advocates point to cost effectiveness in comparison to complexity and security issues associated with other approaches.
The thrust of the debate within the IEPREP working group is whether it is always better to over-provision links to such a degree that spikes in load can still be supported with no loss due to congestion. Advocates of this position point to many ISPs in the US that take this approach instead of using QoS mechanisms to honor agreements with their peers or customers. These advocates point to cost effectiveness in comparison to complexity and security issues associated with other approaches.
Carlberg Informational [Page 4] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 4] RFC 4958 ETS Single Domain Framework July 2007
Proponents of QoS mechanisms argue that the relatively low cost of bandwidth enjoyed in the US (particularly, by large ISPs) is not necessarily available throughout the world. Beyond the subject of cost, some domains are comprised of physical networks that support wide disparity in bandwidth capacity -- e.g., attachment points connected to high capacity fiber and lower capacity wireless links.
Proponents of QoS mechanisms argue that the relatively low cost of bandwidth enjoyed in the US (particularly, by large ISPs) is not necessarily available throughout the world. Beyond the subject of cost, some domains are comprised of physical networks that support wide disparity in bandwidth capacity -- e.g., attachment points connected to high capacity fiber and lower capacity wireless links.
This document does not advocate one of these positions over the other. The author does advocate that network administrators/operators should perform a cost analysis between over-provisioning for spikes versus QoS mechanisms as applied within a domain and its access link to another domain (e.g., a customer and its ISP). This analysis, in addition to examining policies and requirements of the administrative domain, should be the key to deciding how (or if) ETS should be supported within the domain.
This document does not advocate one of these positions over the other. The author does advocate that network administrators/operators should perform a cost analysis between over-provisioning for spikes versus QoS mechanisms as applied within a domain and its access link to another domain (e.g., a customer and its ISP). This analysis, in addition to examining policies and requirements of the administrative domain, should be the key to deciding how (or if) ETS should be supported within the domain.
If the decision is to rely on over-provisioning, then some of the following sections will have little to no bearing on how ETS is supported within a domain. The exception would be labeling mechanisms used to convey information to other communication architectures (e.g., SIP-to-SS7/ISUP gateways).
If the decision is to rely on over-provisioning, then some of the following sections will have little to no bearing on how ETS is supported within a domain. The exception would be labeling mechanisms used to convey information to other communication architectures (e.g., SIP-to-SS7/ISUP gateways).
3. Objective
3. Objective
The primary objective is to provide a target measure of service within a domain for flows that have been labeled for ETS. This level may be better than best effort, the best available service that the network (or parts thereof) can offer, or a specific percentage of resource set aside for ETS. [rfc4375] presents a set of requirements in trying to achieve this objective.
The primary objective is to provide a target measure of service within a domain for flows that have been labeled for ETS. This level may be better than best effort, the best available service that the network (or parts thereof) can offer, or a specific percentage of resource set aside for ETS. [rfc4375] presents a set of requirements in trying to achieve this objective.
This framework document uses [rfc4375] as a reference point in discussing existing areas of engineering work or protocols that can play a role in supporting ETS within a domain. Discussion of these areas and protocols are not to be confused with expectations that they exist within a given domain. Rather, the subjects discussed in Section 4 below are ones that are recognized as candidates that can exist and could be used to facilitate ETS users or data flows.
This framework document uses [rfc4375] as a reference point in discussing existing areas of engineering work or protocols that can play a role in supporting ETS within a domain. Discussion of these areas and protocols are not to be confused with expectations that they exist within a given domain. Rather, the subjects discussed in Section 4 below are ones that are recognized as candidates that can exist and could be used to facilitate ETS users or data flows.
3.1. Scenarios
3.1. Scenarios
One of the topics of discussion on the IEPREP mailing list and in the working group meetings is the operating environment of the ETS user. Many variations can be dreamed of with respect to underlying network technologies and applications. Instead of getting lost in hundreds of potential scenarios, we attempt to abstract the scenarios into two simple case examples.
One of the topics of discussion on the IEPREP mailing list and in the working group meetings is the operating environment of the ETS user. Many variations can be dreamed of with respect to underlying network technologies and applications. Instead of getting lost in hundreds of potential scenarios, we attempt to abstract the scenarios into two simple case examples.
Carlberg Informational [Page 5] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 5] RFC 4958 ETS Single Domain Framework July 2007
(a) A user in their home network attempts to use or leverage any
ETS capability within the domain.
(a) A user in their home network attempts to use or leverage any ETS capability within the domain.
(b) A user visits a foreign network and attempts to use or
leverage any ETS capability within the domain.
(b) A user visits a foreign network and attempts to use or leverage any ETS capability within the domain.
We borrow the terms "home" and "foreign" network from that used in Mobile IP [rfc3344]. Case (a) is considered the normal and vastly most prevalent scenario in today's Internet. Case (b) above may simply be supported by the Dynamic Host Configuration Protocol (DHCP) [rfc2131], or a static set of addresses, that are assigned to 'visitors' of the network. This effort is predominantly operational in nature and heavily reliant on the management and security policies of that network.
We borrow the terms "home" and "foreign" network from that used in Mobile IP [rfc3344]. Case (a) is considered the normal and vastly most prevalent scenario in today's Internet. Case (b) above may simply be supported by the Dynamic Host Configuration Protocol (DHCP) [rfc2131], or a static set of addresses, that are assigned to 'visitors' of the network. This effort is predominantly operational in nature and heavily reliant on the management and security policies of that network.
A more ambitious way of supporting the mobile user is through the use of the Mobile IP (MIP) protocol. MIP offers a measure of application-transparent mobility as a mobile host moves from one subnetwork to another while keeping the same stable IP address registered at a global anchor point. However, this feature may not always be available or in use. In any case, where it is in use, at least some of the packets destined to and from the mobile host go through the home network.
A more ambitious way of supporting the mobile user is through the use of the Mobile IP (MIP) protocol. MIP offers a measure of application-transparent mobility as a mobile host moves from one subnetwork to another while keeping the same stable IP address registered at a global anchor point. However, this feature may not always be available or in use. In any case, where it is in use, at least some of the packets destined to and from the mobile host go through the home network.
4. Topic Areas
4. Topic Areas
The topic areas presented below are not presented in any particular order or along any specific layering model. They represent capabilities that may be found within an administrative domain. Many are topics of on-going work within the IETF.
The topic areas presented below are not presented in any particular order or along any specific layering model. They represent capabilities that may be found within an administrative domain. Many are topics of on-going work within the IETF.
It must be stressed that readers of this document should not expect any of the following to exist within a domain for ETS users. In many cases, while some of the following areas have been standardized and in wide use for several years, others have seen very limited deployment.
It must be stressed that readers of this document should not expect any of the following to exist within a domain for ETS users. In many cases, while some of the following areas have been standardized and in wide use for several years, others have seen very limited deployment.
4.1. MPLS
4.1. MPLS
Multiprotocol Label Switching (MPLS) is generally the first protocol that comes to mind when the subject of traffic engineering is brought up. MPLS signaling produces Labeled Switched Paths (LSPs) through a network of Label Switch Routers [rfc3031]. When traffic reaches the ingress boundary of an MPLS domain (which may or may not be congruent with an administrative domain), the packets are classified, labeled, scheduled, and forwarded along an LSP.
Multiprotocol Label Switching (MPLS) is generally the first protocol that comes to mind when the subject of traffic engineering is brought up. MPLS signaling produces Labeled Switched Paths (LSPs) through a network of Label Switch Routers [rfc3031]. When traffic reaches the ingress boundary of an MPLS domain (which may or may not be congruent with an administrative domain), the packets are classified, labeled, scheduled, and forwarded along an LSP.
Carlberg Informational [Page 6] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 6] RFC 4958 ETS Single Domain Framework July 2007
[rfc3270] describes how MPLS can be used to support Differentiated Services. The RFC discusses the use of the 3-bit EXP (experimental) field to convey the Per Hop Behavior (PHB) to be applied to the packet. As we shall see in later sections, this 3-bit field can be mapped to fields in several other protocols.
[rfc3270] describes how MPLS can be used to support Differentiated Services. The RFC discusses the use of the 3-bit EXP (experimental) field to convey the Per Hop Behavior (PHB) to be applied to the packet. As we shall see in later sections, this 3-bit field can be mapped to fields in several other protocols.
The inherent features of classification, scheduling, and labeling are viewed as symbiotic, and therefore, they are often integrated with other protocols and architectures. Examples of this include RSVP and Differentiated Services. Below, we discuss several instances where a given protocol specification or mechanism has been known to be complemented with MPLS. This includes the potential labels that may be associated with ETS. However, we stress that MPLS is only one of several approaches to support traffic engineering. In addition, the complexity of the MPLS protocol and architecture may make it suited only for large domains.
The inherent features of classification, scheduling, and labeling are viewed as symbiotic, and therefore, they are often integrated with other protocols and architectures. Examples of this include RSVP and Differentiated Services. Below, we discuss several instances where a given protocol specification or mechanism has been known to be complemented with MPLS. This includes the potential labels that may be associated with ETS. However, we stress that MPLS is only one of several approaches to support traffic engineering. In addition, the complexity of the MPLS protocol and architecture may make it suited only for large domains.
4.2. RSVP
4.2. RSVP
The original design of RSVP, together with the Integrated Services model, was one of an end-to-end signaling capability to set up a path of reserved resources that spanned networks and administrative domains [rfc2205]. Currently, RSVP has not been widely deployed by network administrators for QoS across domains. Today's limited deployment by network administrators has been mostly constrained to boundaries within a domain, and commonly in conjunction with MPLS signaling. Early deployments of RSVP ran into unanticipated scaling issues; it is not entirely clear how scalable an RSVP approach would be across the Internet.
The original design of RSVP, together with the Integrated Services model, was one of an end-to-end signaling capability to set up a path of reserved resources that spanned networks and administrative domains [rfc2205]. Currently, RSVP has not been widely deployed by network administrators for QoS across domains. Today's limited deployment by network administrators has been mostly constrained to boundaries within a domain, and commonly in conjunction with MPLS signaling. Early deployments of RSVP ran into unanticipated scaling issues; it is not entirely clear how scalable an RSVP approach would be across the Internet.
[rfc3209] is one example of how RSVP has evolved to complement efforts that are scoped to operate within a domain. In this case, extensions to RSVP are defined that allow it to establish intra- domain Labeled Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS).
[rfc3209] is one example of how RSVP has evolved to complement efforts that are scoped to operate within a domain. In this case, extensions to RSVP are defined that allow it to establish intra- domain Labeled Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS).
[rfc2750] specifies extensions to RSVP so that it can support generic policy-based admission control. This standard goes beyond the support of the POLICY_DATA object stipulated in [rfc3209], by defining the means of control and enforcement of access and usage policies. While the standard does not advocate a particular policy architecture, the IETF has defined one that can complement [rfc2750] -- we expand on this in Section 4.3 below.
[rfc2750] specifies extensions to RSVP so that it can support generic policy-based admission control. This standard goes beyond the support of the POLICY_DATA object stipulated in [rfc3209], by defining the means of control and enforcement of access and usage policies. While the standard does not advocate a particular policy architecture, the IETF has defined one that can complement [rfc2750] -- we expand on this in Section 4.3 below.
Carlberg Informational [Page 7] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 7] RFC 4958 ETS Single Domain Framework July 2007
4.2.1. Relation to ETS
4.2.1. Relation to ETS
The ability to reserve resources correlates to an ability to provide preferential service for specifically classified traffic -- the classification being a tuple of 1 or more fields which may or may not include an ETS specific label. In cases where a tuple includes a label that has been defined for ETS usage, the reservation helps ensure that an emergency-related flow will be forwarded towards its destination. Within the scope of this document, this means that RSVP would be used to facilitate the forwarding of traffic within a domain.
The ability to reserve resources correlates to an ability to provide preferential service for specifically classified traffic -- the classification being a tuple of 1 or more fields which may or may not include an ETS specific label. In cases where a tuple includes a label that has been defined for ETS usage, the reservation helps ensure that an emergency-related flow will be forwarded towards its destination. Within the scope of this document, this means that RSVP would be used to facilitate the forwarding of traffic within a domain.
We note that this places an importance on defining a label and an associated field that can be set and/or examined by RSVP-capable nodes.
We note that this places an importance on defining a label and an associated field that can be set and/or examined by RSVP-capable nodes.
Another important observation is that major vendor routers currently constrain their examination of fields for classification to the network and transport layers. This means that application layer labels will mostly likely be ignored by routers/switches.
Another important observation is that major vendor routers currently constrain their examination of fields for classification to the network and transport layers. This means that application layer labels will mostly likely be ignored by routers/switches.
4.3. Policy
4.3. Policy
The Common Open Policy Service (COPS) protocol [rfc2748] was defined to provide policy control over QoS signaling protocols, such as RSVP. COPS is based on a query/response model in which Policy Enforcement Points (PEPs) interact with Policy Decision Points (i.e., policy servers) to exchange policy information. COPS provides application- level security and can operate over IPsec or TLS. COPS is also a stateful protocol that supports a push model. This means that servers can download new policies or alter existing ones to known clients.
The Common Open Policy Service (COPS) protocol [rfc2748] was defined to provide policy control over QoS signaling protocols, such as RSVP. COPS is based on a query/response model in which Policy Enforcement Points (PEPs) interact with Policy Decision Points (i.e., policy servers) to exchange policy information. COPS provides application- level security and can operate over IPsec or TLS. COPS is also a stateful protocol that supports a push model. This means that servers can download new policies or alter existing ones to known clients.
[rfc2749] articulates the usage of COPS with RSVP. It specifies COPS client types, context objects, and decision objects. Thus, when an RSVP reservation is received by a PEP, the PEP decides whether to accept or reject it based on policy. This policy information can be stored a priori to the reception of the RSVP PATH message, or it can be retrieved on an on-demand basis. A similar course of action could be applied in cases where ETS-labeled control flows are received by the PEP. This of course would require an associated (and new) set of documents that first articulates types of ETS signaling and then specifies its usage with COPS.
[rfc2749] articulates the usage of COPS with RSVP. It specifies COPS client types, context objects, and decision objects. Thus, when an RSVP reservation is received by a PEP, the PEP decides whether to accept or reject it based on policy. This policy information can be stored a priori to the reception of the RSVP PATH message, or it can be retrieved on an on-demand basis. A similar course of action could be applied in cases where ETS-labeled control flows are received by the PEP. This of course would require an associated (and new) set of documents that first articulates types of ETS signaling and then specifies its usage with COPS.
A complementary document to the COPS protocols is COPS Usage for Policy Provisioning (COPS-PR) [rfc3084].
A complementary document to the COPS protocols is COPS Usage for Policy Provisioning (COPS-PR) [rfc3084].
Carlberg Informational [Page 8] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 8] RFC 4958 ETS Single Domain Framework July 2007
As a side note, the current lack of deployment by network administrators of RSVP has also played at least an indirect role in the subsequent lack of implementation and deployment of COPS-PR. [rfc3535] is an output from the IAB Network Management Workshop in which the topic of COPS and its current state of deployment was discussed. At the time of that workshop in 2002, COPS-PR was considered a technology/architecture that did not fully meet the needs of network operators. It should also be noted that at the 60th IETF meeting held in San Diego in 2004, COPS was discussed as a candidate protocol that should be declared as historic because of lack of use and concerns about its design. In the future, an altered design of COPS may emerge that addresses the concern of operators, but speculation on that or other possibilities is beyond the scope of this document.
As a side note, the current lack of deployment by network administrators of RSVP has also played at least an indirect role in the subsequent lack of implementation and deployment of COPS-PR. [rfc3535] is an output from the IAB Network Management Workshop in which the topic of COPS and its current state of deployment was discussed. At the time of that workshop in 2002, COPS-PR was considered a technology/architecture that did not fully meet the needs of network operators. It should also be noted that at the 60th IETF meeting held in San Diego in 2004, COPS was discussed as a candidate protocol that should be declared as historic because of lack of use and concerns about its design. In the future, an altered design of COPS may emerge that addresses the concern of operators, but speculation on that or other possibilities is beyond the scope of this document.
4.4. Subnetwork Technologies
4.4. Subnetwork Technologies
This is a generalization of work that is considered "under" IP and for the most part outside of the IETF standards body. We discuss some specific topics here because there is a relationship between them and IP in the sense that each physical network interacts at its edge with IP.
This is a generalization of work that is considered "under" IP and for the most part outside of the IETF standards body. We discuss some specific topics here because there is a relationship between them and IP in the sense that each physical network interacts at its edge with IP.
4.4.1. IEEE 802.1 VLANs
4.4.1. IEEE 802.1 VLANs
The IEEE 802.1q standard defined a tag appended to a Media Access Controller (MAC) frame for support of layer 2 Virtual Local Area Networks (VLANs). This tag has two parts: a VLAN identifier (12 bits) and a Prioritization field of 3 bits. A subsequent standard, IEEE 802.1p, later incorporated into a revision of IEEE 802.1d, defined the Prioritization field of this new tag [iso15802]. It consists of 8 levels of priority, with the highest priority being a value of 7. Vendors may choose a queue per priority codepoint, or aggregate several codepoints to a single queue.
The IEEE 802.1q standard defined a tag appended to a Media Access Controller (MAC) frame for support of layer 2 Virtual Local Area Networks (VLANs). This tag has two parts: a VLAN identifier (12 bits) and a Prioritization field of 3 bits. A subsequent standard, IEEE 802.1p, later incorporated into a revision of IEEE 802.1d, defined the Prioritization field of this new tag [iso15802]. It consists of 8 levels of priority, with the highest priority being a value of 7. Vendors may choose a queue per priority codepoint, or aggregate several codepoints to a single queue.
The 3-bit Prioritization field can be easily mapped to the old ToS field of the upper-layer IP header. In turn, these bits can also be mapped to a subset of differentiated codepoints. Bits in the IP header that could be used to support ETS (e.g., specific Diffserv codepoints) can in turn be mapped to the Prioritization bits of 802.1p. This mapping could be accomplished in a one-to-one manner between the 802.1p field and the IP ToS bits, or in an aggregate manner if one considers the entire Diffserv field in the IP header. In either case, because of the scarcity of bits, ETS users should expect that their traffic will be combined or aggregated with the same level of priority as some other types of "important" traffic. In other words, given the existing 3-bit Priority Field for 802.1p, there will not be an exclusive bit value reserved for ETS traffic.
The 3-bit Prioritization field can be easily mapped to the old ToS field of the upper-layer IP header. In turn, these bits can also be mapped to a subset of differentiated codepoints. Bits in the IP header that could be used to support ETS (e.g., specific Diffserv codepoints) can in turn be mapped to the Prioritization bits of 802.1p. This mapping could be accomplished in a one-to-one manner between the 802.1p field and the IP ToS bits, or in an aggregate manner if one considers the entire Diffserv field in the IP header. In either case, because of the scarcity of bits, ETS users should expect that their traffic will be combined or aggregated with the same level of priority as some other types of "important" traffic. In other words, given the existing 3-bit Priority Field for 802.1p, there will not be an exclusive bit value reserved for ETS traffic.
Carlberg Informational [Page 9] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 9] RFC 4958 ETS Single Domain Framework July 2007
Certain vendors are currently providing mappings between the 802.1p field and the ToS bits. This is in addition to integrating the signaling of RSVP with the low-level inband signaling offered in the Priority field of 802.1p.
Certain vendors are currently providing mappings between the 802.1p field and the ToS bits. This is in addition to integrating the signaling of RSVP with the low-level inband signaling offered in the Priority field of 802.1p.
It is important to note that the 802.1p standard does not specify the correlation of a layer 2 codepoint to a physical network bandwidth reservation. Instead, this standard provides what has been termed as "best effort QoS". The value of the 802.1p Priority codepoints is realized at the edges: either as the MAC payload is passed to upper layers (like IP), or as it is bridged to other physical networks like Frame Relay. Either of these actions help provide an intra-domain wide propagation of a labeled flow for both layer 2 and layer 3 flows.
It is important to note that the 802.1p standard does not specify the correlation of a layer 2 codepoint to a physical network bandwidth reservation. Instead, this standard provides what has been termed as "best effort QoS". The value of the 802.1p Priority codepoints is realized at the edges: either as the MAC payload is passed to upper layers (like IP), or as it is bridged to other physical networks like Frame Relay. Either of these actions help provide an intra-domain wide propagation of a labeled flow for both layer 2 and layer 3 flows.
4.4.2. IEEE 802.11e QoS
4.4.2. IEEE 802.11e QoS
The 802.11e standard is a proposed enhancement that specifies mechanisms to provide QoS to the 802.11 family of protocols for wireless LANs.
The 802.11e standard is a proposed enhancement that specifies mechanisms to provide QoS to the 802.11 family of protocols for wireless LANs.
Previously, 802.11 had two modes of operation. One was Distributed Coordination Function (DCF) , which is based on the classic collision detection schema of "listen before sending". A second optional mode is the Point Coordination Function (PCF). The modes splits access time into contention-free and contention-active periods -- transmitting data during the former.
Previously, 802.11 had two modes of operation. One was Distributed Coordination Function (DCF) , which is based on the classic collision detection schema of "listen before sending". A second optional mode is the Point Coordination Function (PCF). The modes splits access time into contention-free and contention-active periods -- transmitting data during the former.
The 802.11e standard enhances DCF by adding support for 8 different traffic categories or classifications. Each higher category waits a little less time than the next lower one before it sends its data.
The 802.11e standard enhances DCF by adding support for 8 different traffic categories or classifications. Each higher category waits a little less time than the next lower one before it sends its data.
In the case of PCF, a Hybrid Coordination Function has been added that polls stations during contention-free time slots and grants them a specific start time and maximum duration for transmission. This second mode is more complex than enhanced DCF, but the QoS can be more finely tuned to offer specific bandwidth and jitter control. It must be noted that neither enhancement offers a guarantee of service.
In the case of PCF, a Hybrid Coordination Function has been added that polls stations during contention-free time slots and grants them a specific start time and maximum duration for transmission. This second mode is more complex than enhanced DCF, but the QoS can be more finely tuned to offer specific bandwidth and jitter control. It must be noted that neither enhancement offers a guarantee of service.
4.4.3. Cable Networks
4.4.3. Cable Networks
The Data Over Cable Service Interface Specification (DOCSIS) is a standard used to facilitate the communication and interaction of the cable subnetwork with upper-layer IP networks [docsis]. Cable subnetworks tend to be asynchronous in terms of data load capacity: typically, 27 M downstream, and anywhere from 320 kb to 10 M upstream (i.e., in the direction of the user towards the Internet).
The Data Over Cable Service Interface Specification (DOCSIS) is a standard used to facilitate the communication and interaction of the cable subnetwork with upper-layer IP networks [docsis]. Cable subnetworks tend to be asynchronous in terms of data load capacity: typically, 27 M downstream, and anywhere from 320 kb to 10 M upstream (i.e., in the direction of the user towards the Internet).
Carlberg Informational [Page 10] RFC 4958 ETS Single Domain Framework July 2007
Carlberg Informational [Page 10] RFC 4958 ETS Single Domain Framework July 2007
The evolution of the DOCSIS specification, from 1.0 to 1.1, brought about changes to support a service other than best effort. One of the changes was indirectly added when the 802.1d protocol added the Priority field, which was incorporated within the DOCSIS 1.1 specification. Another change was the ability to perform packet fragmentation of large packets so that Priority-marked packets (i.e., packets marked with non-best effort labels) can be multiplexed in between the fragmented larger packet.
The evolution of the DOCSIS specification, from 1.0 to 1.1, brought about changes to support a service other than best effort. One of the changes was indirectly added when the 802.1d protocol added the Priority field, which was incorporated within the DOCSIS 1.1 specification. Another change was the ability to perform packet fragmentation of large packets so that Priority-marked packets (i.e., packets marked with non-best effort labels) can be multiplexed in between the fragmented larger packet.
It's important to note that the DOCSIS specifications do not specify how vendors implement classification, policing, and scheduling of traffic. Hence, operators must rely on mechanisms in Cable Modem Termination Systems (CMTS) and edge routers to leverage indirectly or directly the added specifications of DOCSIS 1.1. As in the case of 802.1p, ETS-labeled traffic would most likely be aggregated with other types of traffic, which implies that an exclusive bit (or set of bits) will not be reserved for ETS users. Policies and other managed configurations will determine the form of the service experienced by ETS labeled traffic.
DOCSIS仕様がベンダーがどうトラフィックの分類、取り締まり、およびスケジューリングを実装するかを指定しないことに注意するのは重要です。 したがって、オペレータは間接的か直接DOCSIS1.1の付記された仕様を利用するCable Modem Termination Systems(CMTS)と縁のルータでメカニズムを当てにしなければなりません。 802.1pに関するケースのように、ETSによってラベルされたトラフィックはたぶん他のタイプのトラフィックで集められるでしょう。(それは、唯一のビット(または、ビットのセット)がETSユーザのために予約されないのを含意します)。 方針と他の管理された構成はトラフィックとラベルされたETSによって経験されたサービスのフォームを決定するでしょう。
Traffic engineering and management of ETS labeled flows, including its classification and scheduling at the edges of the DOCSIS cloud, could be accomplished in several ways. A simple schema could be based on non-FIFO queuing mechanisms like class-based weighted fair queuing (or combinations and derivations thereof). The addition of active queue management like Random Early Detection could provide simple mechanisms for dealing with bursty traffic contributing to congestion. A more elaborate scheme for traffic engineering would include the use of MPLS. However, the complexity of MPLS should be taken into consideration before its deployment in networks.
いくつかの方法でDOCSIS雲の縁にその分類とスケジューリングを含む流れとラベルされたETSの交通工学と管理を実行できました。 簡単な図式は、クラスベースの均等化キューイング(または、組み合わせとそれの派生)のようなメカニズムを列に並ばせながら、非先入れ先出し法に基づくことができました。 Random Early Detectionのような活発な待ち行列管理の参加は混雑に貢献するburstyトラフィックに対処するのに簡単なメカニズムを提供するかもしれません。 交通工学の、より精巧な体系はMPLSの使用を含んでいるでしょう。 しかしながら、MPLSの複雑さは展開の前にネットワークで考慮に入れられるべきです。
4.5. Multicast
4.5. マルチキャスト
Network layer multicast has existed for quite a few years. Efforts such as the Mbone (multicast backbone) have provided a form of tunneled multicast that spans domains, but the routing hierarchy of the Mbone can be considered flat and non-congruent with unicast routing. Efforts like the Multicast Source Discovery Protocol [rfc3618] together with the Protocol Independent Multicast - Sparse Mode (PIM-SM) have been used by a small subset of Internet Service Providers to provide forms of inter-domain multicast [rfc4601]. However, network layer multicast has not been accepted as a common production level service by a vast majority of ISPs.
ネットワーク層マルチキャストはかなり多くの数年間存在しています。 Mbone(マルチキャストバックボーン)などの取り組みはドメインにかかるトンネルを堀られたマルチキャストのフォームを提供しましたが、ユニキャストルーティングについて平坦であって、非一致しているとMboneのルーティング階層構造を考えることができます。 プロトコル無党派Multicastに伴うMulticast Sourceディスカバリープロトコル[rfc3618]のような取り組み--まばらなMode(PIM-SM)はインターネットサービスプロバイダの小さい部分集合によって使用されて、相互ドメインマルチキャスト[rfc4601]のフォームを提供しました。 しかしながら、ネットワーク層マルチキャストは生産の一般的なレベルサービスとしてISPのかなりの大部分によって認められていません。
In contrast, intra-domain multicast in domains has gained more acceptance as an additional network service. Multicast can produce denial-of-service attacks using the any sender model, with the problem made more acute with flood and prune algorithms. Source-
対照的に、ドメインのイントラドメインマルチキャストは追加ネットワーク・サービスとして、より多くの承認を獲得しました。 マルチキャストは、洪水とプルーンのアルゴリズムソースをもってどんな送付者モデルでも、より鋭いのを問題が作られている状態で使用することでサービス不能攻撃を起こすことができます。
Carlberg Informational [Page 11] RFC 4958 ETS Single Domain Framework July 2007
ドメインフレームワーク2007年7月の独身のCarlbergの情報[11ページ]のRFC4958ETS
specific multicast [rfc3569], together with access control lists of who is allowed to be a sender, reduces the potential and scope of such attacks.
特定のマルチキャスト[rfc3569]はだれが送付者であることが許容されているかに関するアクセスコントロールリストと共にそのような攻撃の可能性と範囲を減少させます。
4.5.1. IP Layer
4.5.1. IP層
The value of IP multicast is its efficient use of resources in sending the same datagram to multiple receivers. An extensive discussion on the strengths of and concerns about multicast is outside the scope of this document. However, one can argue that multicast can very naturally complement the push-to-talk feature of land mobile radio (LMR) networks.
IPマルチキャストの値は同じデータグラムを複数の受信機に送ることにおいてリソースの効率的な使用です。 このドキュメントの範囲の外にマルチキャストに関する強さと心配についての大規模な議論があります。 しかしながら、1つは、マルチキャストが非常に自然に陸の移動無線(LMR)ネットワークのプッシュから話への機能の補足となることができると主張できます。
Push-to-talk is a form of group communication where every user in the "talk group" can participate in the same conversation. LMR is the type of network used by First Responders (e.g., police, firemen, and medical personnel) that are involved in emergencies. Currently, certain vendors and providers are offering push-to-talk service to the general public in addition to First Responders. Some of these systems are operated over IP networks or are interfaced with IP networks to extend the set of users that can communicate with each other. We can consider at least a subset of these systems as either closed IP networks, or domains, since they do not act as transits to other parts of the Internet.
プッシュから話は「話のグループ」におけるすべてのユーザが同じ会話に参加できるグループコミュニケーションのフォームです。 LMRは非常時にかかわるFirst Responders(例えば、警察、消防士、および医療関係者)によって使用されたネットワークのタイプです。 現在、あるベンダーとプロバイダーはFirst Respondersに加えて一般に対するプッシュから話へのサービスを提供しています。 これらのいくつかのシステムが、IPネットワークの上で操作されるか、または互いにコミュニケートできるユーザのセットを広げるためにIPネットワークに連結されます。 私たちは、少なくともこれらのシステムの部分集合が閉じているIPネットワークかドメインのどちらかであるとみなすことができます、トランジットとしてインターネットの他の地域に機能しないので。
The potential integration of LMR talk groups with IP multicast is an open issue. LMR talk groups are established in a static manner with man-in-the-loop participation in their establishment and teardown. The seamless integration of these talk groups with multicast group addresses is a feature that has not been discussed in open forums.
IPマルチキャストがあるLMR話のグループの潜在的統合は未解決の問題です。 LMR話のグループはそれらの設立と分解への輪の男性参加で静的な方法で設立されます。 マルチキャストグループアドレスによるこれらの話のグループのシームレス統合はオープン・フォーラムで議論していない特徴です。
4.5.2. IEEE 802.1d MAC Bridges
4.5.2. IEEE 802.1d MACブリッジ
The IEEE 802.1d standard specifies fields and capabilities for a number of features. In Section 4.3.2 above, we discussed its use for defining a Prioritization field. The 802.1d standard also covers the topic of filtering MAC layer multicast frames.
IEEE 802.1d規格は多くの特徴に分野と能力を指定します。 セクション4.3.2では、上では、私たちがPrioritization分野を定義する使用について議論しました。 また、802.1d規格はフィルタリングMAC層のマルチキャストフレームの話題をカバーしています。
One of the concerns about multicast is that broadcast storms can arise and generate a denial of service against other users/nodes. Some administrators purposely filter out multicast frames in cases where the subnetwork resource is relatively small (e.g., 802.11 networks). Operational considerations with respect to ETS may wish to consider doing this on an as-needed basis, balancing the conditions of the network with the perceived need for multicast. In cases where filtering out multicast can be activated dynamically, COPS may be a good means of providing consistent domain-wide policy control.
マルチキャストに関する心配の1つはブロードキャスト・ストームが起こって、他のユーザ/ノードに対してサービスの否定を生成することができるということです。 管理者の中にはサブネットワークリソースが比較的小さい場合(例えば、802.11のネットワーク)でマルチキャストフレームをわざわざ無視する人もいます。 ETSに関する操作上の問題が、これをするのがオンであると考えたがっているかもしれない、必要に応じて、基礎、マルチキャストの知覚された必要性とネットワークの状態のバランスをとっています。 ダイナミックにマルチキャストを無視するのを動かすことができる場合では、COPSは一貫したドメイン全体の方針コントロールを提供する良い手段であるかもしれません。
Carlberg Informational [Page 12] RFC 4958 ETS Single Domain Framework July 2007
ドメインフレームワーク2007年7月の独身のCarlbergの情報[12ページ]のRFC4958ETS
4.6. Discovery
4.6. 発見
If a service is being offered to explicitly support ETS, then it would seem reasonable that discovery of the service may be of benefit. For example, if a domain has a subset of servers that recognize ETS-labeled traffic, then dynamic discovery of where these servers are (or even if they exist) would be more beneficial than relying on statically configured information.
明らかにETSをサポートするためにサービスを提供しているなら、サービスの発見が有益であるかもしれないことは妥当に思えるでしょう。 例えば、ドメインにETSによってラベルされたトラフィックを認識するサーバの部分集合があるなら、これらのサーバがある(存在していても)ところに関する当時のダイナミックな発見は静的に構成された情報を当てにするより有益でしょう。
The Service Location Protocol (SLP) [rfc2608] is designed to provide information about the existence, location, and configuration of networked services. In many cases, the name of the host supporting the desired service is needed to be known a priori in order for users to access it. SLP eliminates this requirement by using a descriptive model that identifies the service. Based on this description, SLP then resolves the network address of the service and returns this information to the requester. An interesting design element of SLP is that it assumes that the protocol is run over a collection of nodes that are under the control of a single administrative authority. This model follows the scope of this framework document. However, the scope of SLP may be better suited for parts of an enterprise network versus an entire domain.
Service Locationプロトコル(SLP)[rfc2608]は、ネットワークでつながれたサービスの存在、位置、および構成の情報を提供するように設計されています。 多くの場合、必要なサービスをサポートするホストの名前が、ユーザがそれにアクセスするように先験的に知られているのに必要です。 SLPは、サービスを特定する記述的モデルを使用することによって、この要件を排除します。 この記述に基づいて、SLPは次に、サービスのネットワーク・アドレスを決議して、この情報をリクエスタに返します。 SLPのおもしろいデザイン要素はプロトコルがただ一つの職務権限のコントロールの下にあるノードの収集の上に実行されると仮定するということです。 このモデルはこのフレームワークドキュメントの範囲の後をつけます。 しかしながら、SLPの範囲は企業網対全体のドメインの部分に合うほうがよいです。
Anycasting [rfc1546] is another means of discovering nodes that support a given service. Interdomain anycast addresses, propagated by BGP, represent anycast in a wide scope and have been used by multiple root servers for a while. Anycast can also be realized in a more constrained and limited scope (i.e., solely within a domain or subnet), and as in the case of multicast, it may not be supported.
Anycasting[rfc1546]は与えられたサービスを支えるノードを発見する別の手段です。 BGPによって伝播されたInterdomain anycastアドレスは、広範囲にanycastを表して、しばらく、複数のルートサーバーによって使用されています。 また、より強制的で限られた範囲(すなわち、唯一ドメインかサブネットの中の)、マルチキャストの場合では、それがサポートされないとき、Anycastを実感できます。
[rfc4291] covers the topic of anycast addresses for IPv6. Unlike SLP, users/applications must know the anycast address associated with the target service. In addition, responses to multiple requests to the anycast address may come from different servers. Lack of response (not due to connectivity problems) correlates to the discovery that a target service is not available. Detailed tradeoffs between this approach and SLP are outside the scope of this framework document.
[rfc4291]はIPv6のためのanycastアドレスの話題をカバーしています。 SLPと異なって、ユーザ/アプリケーションは目標サービスに関連しているanycastアドレスを知らなければなりません。 さらに、anycastアドレスへの複数の要求への応答は異なったサーバから来るかもしれません。 無反応(接続性問題への支払われるべきものでない)は目標サービスが利用可能でないという発見に関連します。 このフレームワークドキュメントの範囲の外にこのアプローチとSLPの間の詳細な見返りがあります。
The Dynamic Delegation Discovery System (DDDS) is used to implement a binding of strings to data in order to support dynamically configured delegation systems [rfc3401]. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. The potential then exists that a client could specify a set of known tags (e.g., RetrieveMail:Pop3) that would identify/discover the appropriate server with which it can communicate.
Dynamic DelegationディスカバリーSystem(DDDS)は、構成された委譲システムが[rfc3401]であるとダイナミックにサポートするためにストリングの結合をデータに実装するのに使用されます。 DDDSは、DDDS Databaseの中に末期的状態に達するまで繰り返しにストリング変換規則を適用することによって保存されたデータに何らかのユニークなストリングを写像することによって、機能します。 次に、潜在的は存在しています。クライアントはそれが交信できる適切なサーバを特定するか、または発見する1セットの知られているタグ(例えば、RetrieveMail: Pop3)を指定できました。
Carlberg Informational [Page 13] RFC 4958 ETS Single Domain Framework July 2007
ドメインフレームワーク2007年7月の独身のCarlbergの情報[13ページ]のRFC4958ETS
4.7. Differentiated Services (Diffserv)
4.7. 差別化されたサービス(Diffserv)
There are a number of examples where Diffserv [rfc2474] has been deployed strictly within a domain, with no extension of service to neighboring domains. Various reasons exist for Diffserv not being widely deployed in an inter-domain context, including ones rooted in the complexity and problems in supporting the security requirements for Diffserv codepoints. An extensive discussion on Diffserv deployment is outside the scope of this document.
多くの例がDiffserv[rfc2474]がドメインの中で厳密に配布されたところにあります、隣接しているドメインに対するサービスの拡大なしで。 様々な理由は相互ドメイン文脈で広く配布されないDiffservのために存在しています、セキュリティがDiffserv codepointsのための要件であるとサポートする際に複雑さと問題で根づいているものを含んでいて。 このドキュメントの範囲の外にDiffserv展開についての大規模な議論があります。
[Baker] presents common examples of various codepoints used for well-known applications. The document does not recommend these associations as being standard or fixed. Rather, the examples in [Baker] provide a reference point for known deployments that can act as a guide for other network administrators.
[ベイカー]はよく知られるアプリケーションに使用される様々なcodepointsの一般的な例を提示します。 ドキュメントは標準か修理されているとしてこれらの協会を推薦しません。 むしろ、[ベイカー]の例は他のネットワーク管理者のために案内役を務めることができる知られている展開に基準点を提供します。
An argument can be made that Diffserv, with its existing codepoint specifications of Assured Forwarding (AF) and Expedited Forwarding (EF), goes beyond what would be needed to support ETS within a domain. By this we mean that the complexity in terms of maintenance and support of AF or EF may exceed or cause undue burden on the management resources of a domain. Given this possibility, users or network administrators may wish to determine if various queuing mechanisms, like class-based weighted fair queuing, is sufficient to support ETS flows through a domain. Note, as we stated earlier in Section 2, over-provisioning is another option to consider. We assume that if the reader is considering something like Diffserv, then it has been determined that over-provisioning is not a viable option given their individual needs or capabilities.
DiffservがAssured Forwarding(AF)とExpedited Forwarding(EF)の既存のcodepoint仕様でドメインの中でETSをサポートするのに必要であるものを越えるという主張をすることができます。 これで、私たちは、AFかEFのメインテナンスとサポートによる複雑さがドメインに関する経営資源の不当な負担を超えているか、または引き起こすかもしれないと言っています。 様々な列を作りメカニズムを管理者が確認したがっているかもしれないこの可能性、ユーザまたはネットワークに考えて、クラスベースの荷重しているフェアのように、列を作りは、ドメインを通してETSが流れであるとサポートするために十分です。 私たちが、より早くセクション2に述べたように、考えるために食糧を供給し過ぎるのが別のオプションであることに注意してください。 私たちは、読者がDiffservのように考えているなら彼らの個々の必要性か能力を考えて、食糧を供給し過ぎるのが実行可能なオプションでないことを決定したと思います。
5. Security Considerations
5. セキュリティ問題
Services used to offer better or best available service for a particular set of users (in the case of this document, ETS users) are prime targets for security attacks or simple misuse. Hence, administrators that choose to incorporate additional protocols/services to support ETS are strongly encouraged to consider new policies to address the added potential of security attacks. These policies, and any additional security measures, should be considered independent of any mechanism or equipment that restricts access to the administrative domain.
特定のセットのユーザ(このドキュメントの場合におけるETSユーザ)のために、より良いか最も良い利用可能なサービスを提供するのにおいて中古のサービスはセキュリティー攻撃か簡単な誤用のための主要な目標です。 したがって、ETSをサポートするために追加議定書/サービスを取り入れるのを選ぶ管理者が、新しい政策がセキュリティー攻撃の加えられた可能性を扱うと考えるよう強く奨励されます。 これらの方針、およびどんな追加セキュリティ対策もアクセスを管理ドメインに制限するどんなメカニズムや設備の如何にかかわらず考えられるべきです。
Determining how authorization is accomplished is an open issue. Many times the choice is a function of the service that is deployed. One example is source addresses in an access list permitting senders to the multicast group (as described in Section 4.5). Within a single domain environment, cases can be found where network administrators tend to find this approach acceptable. However, other services may
承認がどのように優れているかを決定するのは、未解決の問題です。 選択の多くの倍は配布されるサービスの機能です。 1つの例がマルチキャストグループに送付者を可能にするアクセスリストのソースアドレス(セクション4.5で説明されるように)です。 単一領域環境の中では、ネットワーク管理者が、このアプローチが許容できるのがわかる傾向があるところでケースを見つけることができます。 しかしながら、他のサービスはそうするかもしれません。
Carlberg Informational [Page 14] RFC 4958 ETS Single Domain Framework July 2007
ドメインフレームワーク2007年7月の独身のCarlbergの情報[14ページ]のRFC4958ETS
require more stringent measures that employ detailed credentials, and possibly multiple levels of access and authentication. Ease of use, deployment, scalability, and susceptibility to security breach all play a role in determining authorization schemas. The potential is that accomplishing this for only a single domain may be easier than at the inter-domain scope, if only in terms of scalability and trust.
詳細な資格証明書、およびことによると複数のレベルのアクセスと認証を使うより厳しい測定を必要としてください。 機密保護違反への使いやすさ、展開、スケーラビリティ、および敏感さは承認schemasを決定することにおける役割をすべて果たします。 可能性は単一領域だけにこれを達成するのが相互ドメイン範囲より簡単であるかもしれないということです、スケーラビリティと信頼だけに関して。
6. Summary Comments
6. 概要コメント
This document has presented a number of protocols and complementary technologies that can be used to support ETS users. Their selection is dictated by the fact that all or significant portions of the protocols can be operated and controlled within a single administrative domain. It is this reason why other protocols, like those under current development in the Next Steps in Signaling (NSIS) working group, have not been discussed.
このドキュメントはETSがユーザであるとサポートするのに使用できる多くのプロトコルと補足的な技術を提示しました。 ただ一つの管理ドメインの中でプロトコルのすべてか重要な部分を操作して、制御できるという事実によって彼らの選択は書き取られます。 それはSignaling(NSIS)ワーキンググループにおけるNext Stepsでの現在の開発でのそれらのように他のプロトコルについて議論していないこの理由です。
By listing a variety of efforts in this document, we avoid taking on the role of "king maker" and at the same time indirectly point out that a variety of solutions exist in support of ETS. These solutions may involve QoS, traffic engineering, or simply protection against detrimental conditions (e.g., spikes in traffic load). Again, the choice is up to the reader.
本書ではさまざまな取り組みを記載することによって、私たちは、「メーカー王」の役割を引き受けるのを避けて、同時に、さまざまなソリューションがETSを支持して存在すると間接的に指摘します。 これらのソリューションは有害な状況(例えば、トラヒック負荷におけるスパイク)に対するQoS、交通工学、または単に保護にかかわるかもしれません。 一方、選択は読者次第です。
7. Acknowledgements
7. 承認
Thanks to Ran Atkinson, Scott Bradner, Jon Peterson, and Kimberly King for comments and suggestions on this document.
このドキュメントの上にコメントと提案のためのRanアトキンソン、スコット・ブラドナー、ジョン・ピーターソン、およびキンバリー・キングをありがとうございます。
8. References
8. 参照
8.1. Normative Reference
8.1. 引用規格
[rfc4375] Carlberg, K., "Emergency Telecommunications Services (ETS)
Requirements for a Single Administrative Domain", RFC
4375, January 2006.
[rfc4375] Carlberg、K.、「ただ一つの管理ドメインのための非常時の遠距離通信サービス(ETS)要件」、RFC4375、2006年1月。
8.2. Informative References
8.2. 有益な参照
[Baker] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, August
2006.
2006年8月の[ベイカー]BabiarzとJ.とチェン、K.とF.ベイカー、「DiffServサービスのクラスのための構成ガイドライン」RFC4594。
[docsis] "Data-Over-Cable Service Interface Specifications: Cable
Modem to Customer Premise Equipment Interface
Specification SP-CMCI-I07-020301", DOCSIS, March 2002,
http://www.cablemodem.com.
[docsis] 「データ過剰ケーブルサービスは仕様を連結します」。 「顧客前提設備インターフェース仕様SP-CMCI-I07-020301へのケーブルモデム」、DOCSIS、2002年3月、 http://www.cablemodem.com 。
Carlberg Informational [Page 15] RFC 4958 ETS Single Domain Framework July 2007
ドメインフレームワーク2007年7月の独身のCarlbergの情報[15ページ]のRFC4958ETS
[iso15802] "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"
[iso15802] 「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク(一般的な仕様)は3を分けます」。 メディアアクセスは(MAC)ブリッジを制御します: 改正。 これはISO/IEC10038の改正です: 1993 802.1j-1992と802.6k-1992。 「P802.11c、P802.1p、およびP802.12e.を組み込みます」 「ISO/IEC15802-3: 1998」
[rfc1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[rfc1546] ヤマウズラとC.とメンデス、T.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[rfc2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[rfc2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[rfc2205]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[rfc2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[rfc2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[rfc2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[rfc2608] GuttmanとE.とパーキンスとC.とVeizades、J.とM.日、「サービス位置のプロトコル、バージョン2インチ、RFC2608、1999年6月。」
[rfc2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
R., and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[rfc2748]ダラム、D.(エド)、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[rfc2749] Herzog, S., Ed., Boyle, J., Cohen, R., Durham, D., Rajan,
R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
January 2000.
[rfc2749]ハーツォグ、S.(エド)とボイルとJ.とコーエンとR.とダラムとD.とRajan、R.とA.Sastry、「RSVPのためのCOPS用法」RFC2749(2000年1月)。
[rfc2750] Herzog, S., "RSVP Extensions for Policy Control", RFC
2750, January 2000.
[rfc2750] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
[rfc3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[rfc3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、2001年1月。
[rfc3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[rfc3270]Le Faucheur(F.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「差別化されたサービスのマルチプロトコルラベルの切り換え(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
Carlberg Informational [Page 16] RFC 4958 ETS Single Domain Framework July 2007
ドメインフレームワーク2007年7月の独身のCarlbergの情報[16ページ]のRFC4958ETS
[rfc3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[rfc3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[rfc3344] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[rfc3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC
3084, March 2001.
[rfc3084]チェン(K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ハーツォグ、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス)は、「方針の食糧を供給する(PRを獲得している)用法を獲得します」、RFC3084、2001年3月。
[rfc3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401 October 2002.
[rfc3401]食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、RFC3401 2002年10月。
[rfc3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003.
[rfc3535]Schoenwaelder(J.、「2002IABネットワークマネージメントワークショップの概要」、RFC3535)は2003がそうするかもしれません。
[rfc3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[rfc3569] Bhattacharyya、S.、エド、「ソース特有のマルチキャスト(SSM)の概要」、RFC3569、7月2003日
[rfc3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, October 2003.
[rfc3618]フェナー、B.、エド、D.マイヤー、エド、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618、10月2003日
[rfc4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005.
[rfc4190] Carlberg、K.、ブラウン、I.、およびC.あごひげ、「IP電話で非常時のテレコムサービス(ETS)をサポートするためのフレームワーク」、RFC4190(2005年11月)。
[rfc4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[rfc4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[rfc4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[rfc4601] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
Author's Address
作者のアドレス
Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA
ケン・Carlberg G11 123aベルサイユ円のMDボルチモア(米国)
EMail: carlberg@g11.org.uk
メール: carlberg@g11.org.uk
Carlberg Informational [Page 17] RFC 4958 ETS Single Domain Framework July 2007
ドメインフレームワーク2007年7月の独身のCarlbergの情報[17ページ]のRFC4958ETS
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Carlberg Informational [Page 18]
Carlberg情報です。[18ページ]
一覧
スポンサーリンク
