RFC3346 日本語訳
3346 Applicability Statement for Traffic Engineering with MPLS. J.Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S.Lai. August 2002. (Format: TXT=33754 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Boyle
Request for Comments: 3346 PD Nets
Category: Informational V. Gill
AOL Time Warner, Inc.
A. Hannan
RoutingLoop
D. Cooper
Global Crossing
D. Awduche
Movaz Networks
B. Christian
Worldcom
W.S. Lai
AT&T
August 2002
Network Working Group J. Boyle Request for Comments: 3346 PD Nets Category: Informational V. Gill AOL Time Warner, Inc. A. Hannan RoutingLoop D. Cooper Global Crossing D. Awduche Movaz Networks B. Christian Worldcom W.S. Lai AT&T August 2002
Applicability Statement for Traffic Engineering with MPLS
Applicability Statement for Traffic Engineering with MPLS
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 Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Abstract
This document describes the applicability of Multiprotocol Label Switching (MPLS) to traffic engineering in IP networks. Special considerations for deployment of MPLS for traffic engineering in operational contexts are discussed and the limitations of the MPLS approach to traffic engineering are highlighted.
This document describes the applicability of Multiprotocol Label Switching (MPLS) to traffic engineering in IP networks. Special considerations for deployment of MPLS for traffic engineering in operational contexts are discussed and the limitations of the MPLS approach to traffic engineering are highlighted.
Boyle, et al. Informational [Page 1] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 1] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Table of Contents
Table of Contents
1. Introduction....................................................2 2. Technical Overview of ISP Traffic Engineering...................3 3. Applicability of Internet Traffic Engineering...................4 3.1 Avoidance of Congested Resources................................4 3.2 Resource Utilization in Network Topologies with Parallel Links..5 3.3 Implementing Routing Policies using Affinities..................5 3.4 Re-optimization After Restoration...............................6 4. Implementation Considerations...................................6 4.1 Architectural and Operational Considerations....................6 4.2 Network Management Aspects......................................7 4.3 Capacity Engineering Aspects....................................8 4.4 Network Measurement Aspects.....................................8 5. Limitations.....................................................9 6. Conclusion.....................................................11 7. Security Considerations........................................11 8. References.....................................................11 9. Acknowledgments................................................12 10. Authors' Addresses.............................................13 11. Full Copyright Statement.......................................14
1. Introduction....................................................2 2. Technical Overview of ISP Traffic Engineering...................3 3. Applicability of Internet Traffic Engineering...................4 3.1 Avoidance of Congested Resources................................4 3.2 Resource Utilization in Network Topologies with Parallel Links..5 3.3 Implementing Routing Policies using Affinities..................5 3.4 Re-optimization After Restoration...............................6 4. Implementation Considerations...................................6 4.1 Architectural and Operational Considerations....................6 4.2 Network Management Aspects......................................7 4.3 Capacity Engineering Aspects....................................8 4.4 Network Measurement Aspects.....................................8 5. Limitations.....................................................9 6. Conclusion.....................................................11 7. Security Considerations........................................11 8. References.....................................................11 9. Acknowledgments................................................12 10. Authors' Addresses.............................................13 11. Full Copyright Statement.......................................14
1. Introduction
1. Introduction
It is generally acknowledged that one of the most significant initial applications of Multiprotocol Label Switching (MPLS) is traffic engineering (TE) [1][2] in IP networks. A significant community of IP service providers have found that traffic engineering of their networks can have tactical and strategic value [2, 3, 4]. To support the traffic engineering application, extensions have been specified for Interior Gateway Protocols (IGP) IS-IS [5] and OSPF [6], and to signaling protocols RSVP [7] and LDP [8]. The extensions for IS-IS, OSPF, and RSVP have all been developed and deployed in large scale in many networks consisting of multi-vendor equipment.
It is generally acknowledged that one of the most significant initial applications of Multiprotocol Label Switching (MPLS) is traffic engineering (TE) [1][2] in IP networks. A significant community of IP service providers have found that traffic engineering of their networks can have tactical and strategic value [2, 3, 4]. To support the traffic engineering application, extensions have been specified for Interior Gateway Protocols (IGP) IS-IS [5] and OSPF [6], and to signaling protocols RSVP [7] and LDP [8]. The extensions for IS-IS, OSPF, and RSVP have all been developed and deployed in large scale in many networks consisting of multi-vendor equipment.
This document discusses the applicability of TE to Internet service provider networks, focusing on the MPLS-based approach. It augments the existing protocol applicability statements and, in particular, relates to the operational applicability of RSVP-TE [9]. Special considerations for deployment of MPLS in operational contexts are discussed and the limitations of this approach to traffic engineering are highlighted.
This document discusses the applicability of TE to Internet service provider networks, focusing on the MPLS-based approach. It augments the existing protocol applicability statements and, in particular, relates to the operational applicability of RSVP-TE [9]. Special considerations for deployment of MPLS in operational contexts are discussed and the limitations of this approach to traffic engineering are highlighted.
Boyle, et al. Informational [Page 2] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 2] RFC 3346 Applicability Statement for Traffic Engineering August 2002
2. Technical Overview of ISP Traffic Engineering
2. Technical Overview of ISP Traffic Engineering
Traffic engineering (TE) is generally concerned with the performance optimization of operational networks [2]. In contemporary practice, TE means mapping IP traffic flows onto the existing physical network topology in the most effective way to accomplish desired operational objectives. Techniques currently used to accomplish this include, but are not limited to:
Traffic engineering (TE) is generally concerned with the performance optimization of operational networks [2]. In contemporary practice, TE means mapping IP traffic flows onto the existing physical network topology in the most effective way to accomplish desired operational objectives. Techniques currently used to accomplish this include, but are not limited to:
1. Manipulation of IGP cost (metrics)
2. Explicit routing using constrained virtual-circuit
switching techniques such as ATM or Frame Relay SPVCs
3. Explicit routing using constrained path setup techniques
such as MPLS
1. Manipulation of IGP cost (metrics) 2. Explicit routing using constrained virtual-circuit switching techniques such as ATM or Frame Relay SPVCs 3. Explicit routing using constrained path setup techniques such as MPLS
This document is concerned primarily with MPLS techniques. Specifically, it deals with the ability to use paths other than the shortest paths selected by the IGP to achieve a more balanced network utilization, e.g., by moving traffic away from IGP-selected shortest paths onto alternate paths to avoid congestion in the network. This can be achieved by using explicitly signaled LSP-tunnels. The explicit routes to be used may be computed offline and subsequently downloaded and configured on the routers using an appropriate mechanism. Alternatively, the desired characteristics of an LSP (such as endpoints, bandwidth, affinities) may be configured on a router, which will then use an appropriate algorithm to compute a path through the network satisfying the desired characteristics, subject to various types of constraints. Generally, the characteristics associated with LSPs may include:
This document is concerned primarily with MPLS techniques. Specifically, it deals with the ability to use paths other than the shortest paths selected by the IGP to achieve a more balanced network utilization, e.g., by moving traffic away from IGP-selected shortest paths onto alternate paths to avoid congestion in the network. This can be achieved by using explicitly signaled LSP-tunnels. The explicit routes to be used may be computed offline and subsequently downloaded and configured on the routers using an appropriate mechanism. Alternatively, the desired characteristics of an LSP (such as endpoints, bandwidth, affinities) may be configured on a router, which will then use an appropriate algorithm to compute a path through the network satisfying the desired characteristics, subject to various types of constraints. Generally, the characteristics associated with LSPs may include:
o Ingress and egress nodes
o Bandwidth required
o Priority
o Nodes to include or exclude in the path
o Affinities to include or exclude in the path
o Resilience requirements
o Ingress and egress nodes o Bandwidth required o Priority o Nodes to include or exclude in the path o Affinities to include or exclude in the path o Resilience requirements
Affinities are arbitrary, provider-assigned, attributes applied to links and carried in the TE extensions for the IGPs. Affinities impose a class structure on links, which allow different links to be logically grouped together. They can be used to implement various types of policies, or route preferences that allow the inclusion or exclusion of groups of links from the path of LSPs. Affinities are unique to MPLS and the original requirement for them was documented in [2].
Affinities are arbitrary, provider-assigned, attributes applied to links and carried in the TE extensions for the IGPs. Affinities impose a class structure on links, which allow different links to be logically grouped together. They can be used to implement various types of policies, or route preferences that allow the inclusion or exclusion of groups of links from the path of LSPs. Affinities are unique to MPLS and the original requirement for them was documented in [2].
Boyle, et al. Informational [Page 3] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 3] RFC 3346 Applicability Statement for Traffic Engineering August 2002
3. Applicability of Internet Traffic Engineering
3. Applicability of Internet Traffic Engineering
As mentioned in [2] and [7], traffic engineering with MPLS is appropriate to establish and maintain explicitly routed paths in an IP network for effective traffic placement. LSP-tunnels can be used to forward subsets of traffic through paths that are independent of routes computed by conventional IGP Shortest Path First (SPF) algorithms. This gives network operators significant flexibility in controlling the paths of traffic flows across their networks and allows policies to be implemented that can result in the performance optimization of networks. Examples of scenarios where MPLS-based TE capabilities are applicable in service provider environments are given below. The applicability of MPLS is certainly not restricted to these scenarios.
As mentioned in [2] and [7], traffic engineering with MPLS is appropriate to establish and maintain explicitly routed paths in an IP network for effective traffic placement. LSP-tunnels can be used to forward subsets of traffic through paths that are independent of routes computed by conventional IGP Shortest Path First (SPF) algorithms. This gives network operators significant flexibility in controlling the paths of traffic flows across their networks and allows policies to be implemented that can result in the performance optimization of networks. Examples of scenarios where MPLS-based TE capabilities are applicable in service provider environments are given below. The applicability of MPLS is certainly not restricted to these scenarios.
3.1 Avoidance of Congested Resources
3.1 Avoidance of Congested Resources
In order to lower the utilization of congested link(s), an operator may utilize TE methods to route a subset of traffic away from those links onto less congested topological elements. These types of techniques are viable when segments of the network are congested while other parts are underutilized.
In order to lower the utilization of congested link(s), an operator may utilize TE methods to route a subset of traffic away from those links onto less congested topological elements. These types of techniques are viable when segments of the network are congested while other parts are underutilized.
Operators who do not make extensive use of LSP-tunnels may adopt a tactical approach to MPLS TE in which they create LSP-tunnels only when necessary to address specific congestion problems. For example, an LSP can be created between two nodes (source and destination) that are known to contribute traffic to a congested network element, and explicitly route the LSP through a separate path to divert some traffic away from the congestion. On the other hand, operators who make extensive use of LSP-tunnels, either for measurement or automated traffic control, may decide to explicitly route a subset of the LSPs that traverse the point of congestion onto alternate paths. This can be employed to respond quickly when the bandwidth parameter associated with the LSPs does not accurately represent the actual traffic carried by the LSPs, and the operator determines that changing the bandwidth parameter values might not be effective in addressing the issue or may not have lasting impact.
Operators who do not make extensive use of LSP-tunnels may adopt a tactical approach to MPLS TE in which they create LSP-tunnels only when necessary to address specific congestion problems. For example, an LSP can be created between two nodes (source and destination) that are known to contribute traffic to a congested network element, and explicitly route the LSP through a separate path to divert some traffic away from the congestion. On the other hand, operators who make extensive use of LSP-tunnels, either for measurement or automated traffic control, may decide to explicitly route a subset of the LSPs that traverse the point of congestion onto alternate paths. This can be employed to respond quickly when the bandwidth parameter associated with the LSPs does not accurately represent the actual traffic carried by the LSPs, and the operator determines that changing the bandwidth parameter values might not be effective in addressing the issue or may not have lasting impact.
There are other approaches that measure traffic workloads on LSPs and utilize these empirical statistics to configure various characteristics of LSPs. These approaches, for example, can utilize the derived statistics to configure explicit routes for LSPs (also known as offline TE [10]). They can also utilize the statistics to set the values of various LSP attributes such as bandwidths, priority, and affinities (online TE). All of these approaches can be used both tactically and strategically to react to periods of congestion in a network. Congestion may occur as a result of many
There are other approaches that measure traffic workloads on LSPs and utilize these empirical statistics to configure various characteristics of LSPs. These approaches, for example, can utilize the derived statistics to configure explicit routes for LSPs (also known as offline TE [10]). They can also utilize the statistics to set the values of various LSP attributes such as bandwidths, priority, and affinities (online TE). All of these approaches can be used both tactically and strategically to react to periods of congestion in a network. Congestion may occur as a result of many
Boyle, et al. Informational [Page 4] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 4] RFC 3346 Applicability Statement for Traffic Engineering August 2002
factors: equipment or facility failure, longer than expected provisioning cycles for new circuits, and unexpected surges in traffic demand.
factors: equipment or facility failure, longer than expected provisioning cycles for new circuits, and unexpected surges in traffic demand.
3.2 Resource Utilization in Network Topologies with Parallel Links
3.2 Resource Utilization in Network Topologies with Parallel Links
In practice, many service provider networks contain multiple parallel links between nodes. An example is transoceanic connectivity which is often provisioned as numerous low-capacity circuits, such as NxDS-3 (N parallel DS-3 circuits) and NxSTM-1 (N parallel STM-1 circuits). Parallel circuits also occur quite often in bandwidth- constrained cities. MPLS TE methods can be applied to effectively distribute the aggregate traffic workload across these parallel circuits.
In practice, many service provider networks contain multiple parallel links between nodes. An example is transoceanic connectivity which is often provisioned as numerous low-capacity circuits, such as NxDS-3 (N parallel DS-3 circuits) and NxSTM-1 (N parallel STM-1 circuits). Parallel circuits also occur quite often in bandwidth- constrained cities. MPLS TE methods can be applied to effectively distribute the aggregate traffic workload across these parallel circuits.
MPLS-based approaches commonly used in practice to deal with parallel links include using LSP bandwidth parameters to control the proportion of demand traversing each link, explicitly configuring routes for LSP-tunnels to distribute them across the parallel links, and using affinities to map different LSPs onto different links. These types of solutions are also applicable in networks with parallel and replicated topologies, such as an NxOC-3/12/48 topology.
MPLS-based approaches commonly used in practice to deal with parallel links include using LSP bandwidth parameters to control the proportion of demand traversing each link, explicitly configuring routes for LSP-tunnels to distribute them across the parallel links, and using affinities to map different LSPs onto different links. These types of solutions are also applicable in networks with parallel and replicated topologies, such as an NxOC-3/12/48 topology.
3.3 Implementing Routing Policies using Affinities
3.3 Implementing Routing Policies using Affinities
It is sometimes desirable to restrict certain types of traffic to certain types of links, or to explicitly exclude certain types of links in the paths for some types of traffic. This might be needed to accomplish some business policy or network engineering objectives. MPLS resource affinities provide a powerful mechanism to implement these types of objectives.
It is sometimes desirable to restrict certain types of traffic to certain types of links, or to explicitly exclude certain types of links in the paths for some types of traffic. This might be needed to accomplish some business policy or network engineering objectives. MPLS resource affinities provide a powerful mechanism to implement these types of objectives.
As a concrete example, suppose a global service provider has a flat (non-hierarchical) IGP. MPLS TE affinities can be used to explicitly keep continental traffic (traffic originating and terminating within a continent) from traversing transoceanic resources.
As a concrete example, suppose a global service provider has a flat (non-hierarchical) IGP. MPLS TE affinities can be used to explicitly keep continental traffic (traffic originating and terminating within a continent) from traversing transoceanic resources.
Another example of using MPLS TE affinities to exclude certain traffic from a subset of circuits might be to keep inter-regional LSPs off of circuits that are reserved for intra-regional traffic.
Another example of using MPLS TE affinities to exclude certain traffic from a subset of circuits might be to keep inter-regional LSPs off of circuits that are reserved for intra-regional traffic.
Still another example is the situation in a heterogeneous network consisting of links with different capacities, e.g., OC-12, OC-48, and OC-192. In such networks, affinities can be used to force some types of traffic to only traverse links with a given capacity, e.g. OC-48.
Still another example is the situation in a heterogeneous network consisting of links with different capacities, e.g., OC-12, OC-48, and OC-192. In such networks, affinities can be used to force some types of traffic to only traverse links with a given capacity, e.g. OC-48.
Boyle, et al. Informational [Page 5] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 5] RFC 3346 Applicability Statement for Traffic Engineering August 2002
3.4 Re-optimization After Restoration
3.4 Re-optimization After Restoration
After the occurrence of a network failure, it may be desirable to calculate a new set paths for LSPs to optimizes performance over the residual topology. This re-optimization is complementary to the fast-reroute operation used to reduce packet losses during routing transients under network restoration. Traffic protection can also be accomplished by associating a primary LSP with a set of secondary LSPs, hot-standby LSPs, or a combination thereof [11].
After the occurrence of a network failure, it may be desirable to calculate a new set paths for LSPs to optimizes performance over the residual topology. This re-optimization is complementary to the fast-reroute operation used to reduce packet losses during routing transients under network restoration. Traffic protection can also be accomplished by associating a primary LSP with a set of secondary LSPs, hot-standby LSPs, or a combination thereof [11].
4. Implementation Considerations
4. Implementation Considerations
4.1 Architectural and Operational Considerations
4.1 Architectural and Operational Considerations
When deploying TE solutions in a service provider environment, the impact of administrative policies and the selection of nodes that will serve as endpoints for LSP-tunnels should be carefully considered. As noted in [9], when devising a virtual topology for LSP-tunnels, special consideration should be given to the tradeoff between the operational complexity associated with a large number of LSP-tunnels and the control granularity that large numbers of LSP- tunnels allow. In other words, a large number of LSP-tunnels allow greater control over the distribution of traffic across the network, but increases network operational complexity. In large networks, it may be advisable to start with a simple LSP-tunnel virtual topology and then introduce additional complexity based on observed or anticipated traffic flow patterns [9].
When deploying TE solutions in a service provider environment, the impact of administrative policies and the selection of nodes that will serve as endpoints for LSP-tunnels should be carefully considered. As noted in [9], when devising a virtual topology for LSP-tunnels, special consideration should be given to the tradeoff between the operational complexity associated with a large number of LSP-tunnels and the control granularity that large numbers of LSP- tunnels allow. In other words, a large number of LSP-tunnels allow greater control over the distribution of traffic across the network, but increases network operational complexity. In large networks, it may be advisable to start with a simple LSP-tunnel virtual topology and then introduce additional complexity based on observed or anticipated traffic flow patterns [9].
Administrative policies should guide the amount of bandwidth to be allocated to an LSP. One may choose to set the bandwidth of a particular LSP to a statistic of the measured observed utilization over an interval of time, e.g., peak rate, or a particular percentile or quartile of the observed utilization. Sufficient over- subscription (of LSPs) or under-reporting bandwidth on the physical links should be used to account for flows that exceed their normal limits on an event-driven basis. Flows should be monitored for trends that indicate when the bandwidth parameter of an LSP should be resized. Flows should be monitored constantly to detect unusual variance from expected levels. If an unpoliced flow greatly exceeds its assigned bandwidth, action should be taken to determine the root cause and remedy the problem. Traffic policing is an option that may be applied to deal with congestion problems, especially when some flows exceed their bandwidth parameters and interfere with other compliant flows. However, it is usually more prudent to apply policing actions at the edge of the network rather than within the core, unless under exceptional circumstances.
Administrative policies should guide the amount of bandwidth to be allocated to an LSP. One may choose to set the bandwidth of a particular LSP to a statistic of the measured observed utilization over an interval of time, e.g., peak rate, or a particular percentile or quartile of the observed utilization. Sufficient over- subscription (of LSPs) or under-reporting bandwidth on the physical links should be used to account for flows that exceed their normal limits on an event-driven basis. Flows should be monitored for trends that indicate when the bandwidth parameter of an LSP should be resized. Flows should be monitored constantly to detect unusual variance from expected levels. If an unpoliced flow greatly exceeds its assigned bandwidth, action should be taken to determine the root cause and remedy the problem. Traffic policing is an option that may be applied to deal with congestion problems, especially when some flows exceed their bandwidth parameters and interfere with other compliant flows. However, it is usually more prudent to apply policing actions at the edge of the network rather than within the core, unless under exceptional circumstances.
Boyle, et al. Informational [Page 6] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 6] RFC 3346 Applicability Statement for Traffic Engineering August 2002
When creating LSPs, a hierarchical network approach may be used to alleviate scalability problems associated with flat full mesh virtual topologies. In general, operational experience has shown that very large flows (between city pairs) are long-lived and have stable characteristics, while smaller flows (edge to edge) are more dynamic and have more fluctuating statistical characteristics. A hierarchical architecture can be devised consisting of core and edge networks in which the core is traffic engineered and serves as an aggregation and transit infrastructure for edge traffic.
When creating LSPs, a hierarchical network approach may be used to alleviate scalability problems associated with flat full mesh virtual topologies. In general, operational experience has shown that very large flows (between city pairs) are long-lived and have stable characteristics, while smaller flows (edge to edge) are more dynamic and have more fluctuating statistical characteristics. A hierarchical architecture can be devised consisting of core and edge networks in which the core is traffic engineered and serves as an aggregation and transit infrastructure for edge traffic.
However, over-aggregation of flows can result in a stream so large that it precludes the constraint-based routing algorithm from finding a feasible path through a network. Splitting a flow by using two or more parallel LSPs and distributing the traffic across the LSPs can solve this problem, at the expense of introducing more state in the network.
However, over-aggregation of flows can result in a stream so large that it precludes the constraint-based routing algorithm from finding a feasible path through a network. Splitting a flow by using two or more parallel LSPs and distributing the traffic across the LSPs can solve this problem, at the expense of introducing more state in the network.
Failure scenarios should also be addressed when splitting a stream of traffic over several links. It is of little value to establish a finely balanced set of flows over a set of links only to find that upon link failure the balance reacts poorly, or does not revert to the original situation upon restoration.
Failure scenarios should also be addressed when splitting a stream of traffic over several links. It is of little value to establish a finely balanced set of flows over a set of links only to find that upon link failure the balance reacts poorly, or does not revert to the original situation upon restoration.
4.2 Network Management Aspects
4.2 Network Management Aspects
Networks planning to deploy MPLS for traffic engineering must consider network management aspects, particularly performance and fault management [12]. With the deployment of MPLS in any infrastructure, some additional operational tasks are required, such as constant monitoring to ensure that the performance of the network is not impacted in the end-to-end delivery of traffic. In addition, traffic characteristics, such as latency across an LSP, may also need to be assessed on a regular basis to ensure that service-level guarantees are achieved.
Networks planning to deploy MPLS for traffic engineering must consider network management aspects, particularly performance and fault management [12]. With the deployment of MPLS in any infrastructure, some additional operational tasks are required, such as constant monitoring to ensure that the performance of the network is not impacted in the end-to-end delivery of traffic. In addition, traffic characteristics, such as latency across an LSP, may also need to be assessed on a regular basis to ensure that service-level guarantees are achieved.
Obtaining information on LSP behavior is critical in determining the stability of an MPLS network. When LSPs transition or path changes occur, packets may be dropped which impacts network performance. It should be the goal of any network deploying MPLS to minimize the volatility of LSPs and reduce the root causes that induce this instability. Unfortunately, there are very few, if any, NMS systems that are available at this time with the capability to provide the correct level of management support, particularly root cause analysis. Consequently, most early adopters of MPLS develop their own management systems in-house for the MPLS domain. The lack of availability of commercial network management systems that deal specifically with MPLS-related aspects is a significant impediment to the large-scale deployment of MPLS networks.
Obtaining information on LSP behavior is critical in determining the stability of an MPLS network. When LSPs transition or path changes occur, packets may be dropped which impacts network performance. It should be the goal of any network deploying MPLS to minimize the volatility of LSPs and reduce the root causes that induce this instability. Unfortunately, there are very few, if any, NMS systems that are available at this time with the capability to provide the correct level of management support, particularly root cause analysis. Consequently, most early adopters of MPLS develop their own management systems in-house for the MPLS domain. The lack of availability of commercial network management systems that deal specifically with MPLS-related aspects is a significant impediment to the large-scale deployment of MPLS networks.
Boyle, et al. Informational [Page 7] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 7] RFC 3346 Applicability Statement for Traffic Engineering August 2002
The performance of an MPLS network is also dependent on the configured values of bandwidth for each LSP. Since congestion is a common cause of performance degradation in operational networks, it is important to proactively avoid these situations. While MPLS was designed to minimize congestion on links by utilizing bandwidth reservations, it is still heavily reliant on user configurable data. If the LSP bandwidth value does not properly represent the traffic demand of that LSP, over-utilization may occur and cause significant congestion within the network. Therefore, it is important to develop, deploy, and maintain a good modeling tool for determining LSP bandwidth size. Lack of this capability may result in sub- optimal network performance.
The performance of an MPLS network is also dependent on the configured values of bandwidth for each LSP. Since congestion is a common cause of performance degradation in operational networks, it is important to proactively avoid these situations. While MPLS was designed to minimize congestion on links by utilizing bandwidth reservations, it is still heavily reliant on user configurable data. If the LSP bandwidth value does not properly represent the traffic demand of that LSP, over-utilization may occur and cause significant congestion within the network. Therefore, it is important to develop, deploy, and maintain a good modeling tool for determining LSP bandwidth size. Lack of this capability may result in sub- optimal network performance.
4.3 Capacity Engineering Aspects
4.3 Capacity Engineering Aspects
Traffic engineering has a goal of ensuring traffic performance objectives for different services. This requires that the different network elements be dimensioned properly to handle the expected load. More specifically, in mapping given user demands onto network resources, network dimensioning involves the sizing of the network elements, such as links, processors, and buffers, so that performance objectives can be met at minimum cost. Major inputs to the dimensioning process are cost models, characterization of user demands and specification of performance objectives.
Traffic engineering has a goal of ensuring traffic performance objectives for different services. This requires that the different network elements be dimensioned properly to handle the expected load. More specifically, in mapping given user demands onto network resources, network dimensioning involves the sizing of the network elements, such as links, processors, and buffers, so that performance objectives can be met at minimum cost. Major inputs to the dimensioning process are cost models, characterization of user demands and specification of performance objectives.
In using MPLS, dimensioning involves the assignment of resources such as bandwidth to a set of pre-selected LSPs for carrying traffic, and mapping the logical network of LSPs onto a physical network of links with capacity constraints. The dimensioning process also determines the link capacity parameters or thresholds associated with the use of some bandwidth reservation scheme for service protection. Service protection controls the QoS for certain service types by restricting access to bandwidth, or by giving priority access to one type of traffic over another. Such methods are essential, e.g., to prevent starvation of low-priority flows, to guarantee a minimum amount of resources for flows with expected short duration, to improve the acceptance probability for flows with high bandwidth requirements, or to maintain network stability by preventing performance degradation in case of a local overload.
In using MPLS, dimensioning involves the assignment of resources such as bandwidth to a set of pre-selected LSPs for carrying traffic, and mapping the logical network of LSPs onto a physical network of links with capacity constraints. The dimensioning process also determines the link capacity parameters or thresholds associated with the use of some bandwidth reservation scheme for service protection. Service protection controls the QoS for certain service types by restricting access to bandwidth, or by giving priority access to one type of traffic over another. Such methods are essential, e.g., to prevent starvation of low-priority flows, to guarantee a minimum amount of resources for flows with expected short duration, to improve the acceptance probability for flows with high bandwidth requirements, or to maintain network stability by preventing performance degradation in case of a local overload.
4.4 Network Measurement Aspects
4.4 Network Measurement Aspects
Network measurement entails robust statistics collection and systems development. Knowing *what* to do with these measurements is often where the secret-sauce is. Examples for different applications of measurements are described in [13]. For instance, to ensure that the QoS objectives have been met, performance measurements and performance monitoring are required so that real-time traffic control
Network measurement entails robust statistics collection and systems development. Knowing *what* to do with these measurements is often where the secret-sauce is. Examples for different applications of measurements are described in [13]. For instance, to ensure that the QoS objectives have been met, performance measurements and performance monitoring are required so that real-time traffic control
Boyle, et al. Informational [Page 8] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 8] RFC 3346 Applicability Statement for Traffic Engineering August 2002
actions, or policy-based actions, can be taken. Also, to characterize the traffic demands, traffic measurements are used to estimate the offered loads from different service classes and to provide forecasting of future demands for capacity planning purposes. Forecasting and planning may result in capacity augmentation or may lead to the introduction of new technology and architecture.
actions, or policy-based actions, can be taken. Also, to characterize the traffic demands, traffic measurements are used to estimate the offered loads from different service classes and to provide forecasting of future demands for capacity planning purposes. Forecasting and planning may result in capacity augmentation or may lead to the introduction of new technology and architecture.
To avoid QoS degradation at the packet level, measurement-based admission control can be employed by using online measurements of actual usage. This is a form of preventive control to ensure that the QoS requirements of different service classes can be met simultaneously, while maintaining network efficiency at a high level. However, it requires proper network dimensioning to keep the probability for the refusal of connection/flow requests sufficiently low.
To avoid QoS degradation at the packet level, measurement-based admission control can be employed by using online measurements of actual usage. This is a form of preventive control to ensure that the QoS requirements of different service classes can be met simultaneously, while maintaining network efficiency at a high level. However, it requires proper network dimensioning to keep the probability for the refusal of connection/flow requests sufficiently low.
5. Limitations
5. Limitations
Significant resources can be expended to gain a proper understanding of how MPLS works. Furthermore, significant engineering and testing resources may need to be invested to identify problems with vendor implementations of MPLS. Initial deployment of MPLS software and the configurations management aspects to support TE can consume significant engineering, operations, and system development resources. Developing automated systems to create router configurations for network elements can require significant software development and hardware resources. Getting to a point where configurations for routers are updated in an automated fashion can be a time consuming process. Tracking manual tweaks to router configurations, or problems associated with these can be an endless task. What this means is that much more is required in the form of various types of tools to simplify and automate the MPLS TE function.
Significant resources can be expended to gain a proper understanding of how MPLS works. Furthermore, significant engineering and testing resources may need to be invested to identify problems with vendor implementations of MPLS. Initial deployment of MPLS software and the configurations management aspects to support TE can consume significant engineering, operations, and system development resources. Developing automated systems to create router configurations for network elements can require significant software development and hardware resources. Getting to a point where configurations for routers are updated in an automated fashion can be a time consuming process. Tracking manual tweaks to router configurations, or problems associated with these can be an endless task. What this means is that much more is required in the form of various types of tools to simplify and automate the MPLS TE function.
Certain architectural choices can lead to operational, protocol, and router implementation scalability problems. This is especially true as the number of LSP-tunnels or router configuration data in a network increases, which can be exacerbated by designs incorporating full meshes, which create O(N^2) number of LSPs, where N is the number of network-edge nodes. In these cases, minimizing N through hierarchy, regionalization, or proper selection of tunnel termination points can affect the network's ability to scale. Loss of scale in this sense can be via protocol instability, inability to change network configurations to accommodate growth, inability for router implementations to be updated, hold or properly process configurations, or loss of ability to adequately manage the network.
Certain architectural choices can lead to operational, protocol, and router implementation scalability problems. This is especially true as the number of LSP-tunnels or router configuration data in a network increases, which can be exacerbated by designs incorporating full meshes, which create O(N^2) number of LSPs, where N is the number of network-edge nodes. In these cases, minimizing N through hierarchy, regionalization, or proper selection of tunnel termination points can affect the network's ability to scale. Loss of scale in this sense can be via protocol instability, inability to change network configurations to accommodate growth, inability for router implementations to be updated, hold or properly process configurations, or loss of ability to adequately manage the network.
Boyle, et al. Informational [Page 9] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Boyle, et al. Informational [Page 9] RFC 3346 Applicability Statement for Traffic Engineering August 2002
Although widely deployed, MPLS TE is a new technology when compared to the classic IP routing protocols such as IS-IS, OSPF, and BGP. MPLS TE also has more configuration and protocol options. As such, some implementations are not battle-hardened and automated testing of various configurations is difficult if not infeasible. Multi-vendor environments are beginning to appear, although additional effort is usually required to ensure full interoperability.
Although widely deployed, MPLS TE is a new technology when compared to the classic IP routing protocols such as IS-IS, OSPF, and BGP. MPLS TE also has more configuration and protocol options. As such, some implementations are not battle-hardened and automated testing of various configurations is difficult if not infeasible. Multi-vendor environments are beginning to appear, although additional effort is usually required to ensure full interoperability.
Common approaches to TE in service provider environments switch the forwarding paradigm from connectionless to connection oriented. Thus, operational analysis of the network may be complicated in some regards (and improved in others). Inconsistencies in forwarding state result in dropped packets whereas with connectionless methods the packet will either loop and drop, or be misdirected onto another branch in the routing tree.
サービスプロバイダー環境におけるTEへの一般的なアプローチはコネクションレスであるのから適応する接続に推進パラダイムを切り換えます。 したがって、ネットワークの演算子解析はある面では(そして、他のものでは、向上する)複雑であるかもしれません。 推進における矛盾が低下しているパケットに結果を述べますが、コネクションレスな方法で、パケットは、輪にして、低下するか、またはルーティング木の別のブランチに的外れになるでしょう。
Currently deployed MPLS TE approaches can be adversely affected by both internal and external router and link failures. This can create a mismatch between the signaled capacity and the traffic an LSP- tunnel carries.
現在配備されたMPLS TEアプローチは内部の、そして、外部のルータとリンクの故障の両方で悪影響を受けることができます。 これはLSPトンネルが運ぶ合図された容量と交通の間でミスマッチを作成できます。
Many routers in service provider environments are already under stress processing the software workload associated with running IGP, BGP, and IPC. Enabling TE in an MPLS environment involves adding traffic engineering databases and processes, adding additional information to be carried by the routing processes, and adding signaling state and processing to these network elements. Additional traffic measurements may also need to be supported. In some environments, this additional load may not be feasible.
サービスプロバイダー環境における多くのルータが既に圧力処理の走行IGPに関連しているソフトウェアワークロード、BGP、およびIPCであります。 ルーティング工程で運ばれるために追加情報を加えて、状態と処理にこれらのネットワーク要素まで合図しながら加えて、MPLS環境でTEを有効にするのは、交通工学データベースと過程を加えることを伴います。 また、追加トラフィック測定は、支持される必要があるかもしれません。 いくつかの環境で、この追加負荷は可能でないかもしれません。
MPLS in general and MPLS-TE in particular is not a panacea for lack of network capacity, or lack of proper capacity planning and provisioning in the network dimensioning process. MPLS-TE may cause network traffic to traverse greater distances or to take paths with more network elements, thereby incurring greater latency. Generally, this added inefficiency is done to prevent shortcomings in capacity planning or available resources path to avoid hot spots. The ability of TE to accommodate more traffic on a given topology can also be characterized as a short-term gain during periods of persistent traffic growth. These approaches cannot achieve impossible mappings of traffic onto topologies. Failure to properly capacity plan and execute will lead to congestion, no matter what technology aids are employed.
一般に、MPLSと特にMPLS-TEはネットワーク容量の不足、または適切なキャパシティプランニングの不足のための万能薬とネットワーク寸法決定の過程において食糧を供給することではありません。 MPLS-TEは、ネットワークトラフィックがより遠い距離を横断するか、または、より多くのネットワーク要素で経路を取ることを引き起こすかもしれません、その結果、よりすばらしい潜在を被ります。 一般に、これは、ホットスポットを避けるためにキャパシティプランニングか利用可能資源経路で短所を防ぐために非能率をすると言い足しました。 また、しつこい交通の成長の期間、短期キャピタルゲインとしてTEが与えられたトポロジーで、より多くの交通に対応する能力を特徴付けることができます。 これらのアプローチは交通の不可能なマッピングをtopologiesに実現できません。 失敗、適切に、どんな技術援助が採用していても、容量は、意志のリードを混雑に計画して、実行します。
Boyle, et al. Informational [Page 10] RFC 3346 Applicability Statement for Traffic Engineering August 2002
ボイル、他 交通工学2002年8月のための情報[10ページ]のRFC3346適用性証明
6. Conclusion
6. 結論
The applicability of traffic engineering in Internet service provider environments has been discussed in this document. The focus has been on the use of MPLS-based approaches to achieve traffic engineering in this context. The applicability of traffic engineering and associated management and deployment considerations have been described, and the limitations highlighted.
本書ではインターネット接続サービス業者環境における交通工学の適用性について議論しました。 このような関係においては交通工学を達成するために、MPLSベースのアプローチの使用には焦点がありました。 交通工学、関連管理、および展開問題の適用性は、説明されていて強調された制限です。
MPLS combines the ability to monitor point-to-point traffic statistics between two routers and the capability to control the forwarding paths of subsets of traffic through a given network topology. This makes traffic engineering with MPLS applicable and useful for improving network performance by effectively mapping traffic flows onto links within service provider networks. Tools that simplify and automate the MPLS TE functions and activation help to realize the full potential.
MPLSは2つのルータの間の二地点間交通統計をモニターする能力と与えられたネットワーク形態を通して交通の部分集合の推進経路を制御する能力を結合します。 これは事実上、サービスプロバイダーネットワークの中で交通の流れをリンクに写像するのによるネットワーク性能を向上させるのに適切で役に立つMPLSと共に交通工学になります。 MPLS TE機能と起動を簡素化して、自動化するツールは、最大限の可能性がわかるのを助けます。
7. Security Considerations
7. セキュリティ問題
This document does not introduce new security issues. When deployed in service provider networks, it is mandatory to ensure that only authorized entities are permitted to initiate establishment of LSP- tunnels.
このドキュメントは新しい安全保障問題を紹介しません。 サービスプロバイダーネットワークで配備されると、権限のある機関だけがLSPトンネルの設立を開始することが許可されているのを保証するのは義務的です。
8. References
8. 参照
1 Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture," RFC 3031, January 2001.
1 ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
2 Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus,
"Requirements for Traffic Engineering Over MPLS," RFC 2702,
September 1999.
2 AwducheとD.とマルコムとJ.とAgogbuaとJ.、オデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
3 X. Xiao, A. Hannan, B. Bailey, and L. Ni, "Traffic Engineering
with MPLS in the Internet," IEEE Network, March/April 2000.
3 IEEEは、X.Xiao、A.ハナン、B.べイリー、およびL.Ni、「MPLSがインターネットにある交通工学」とネットワークでつなぎます、2000年3月/4月。
4 V. Springer, C. Pierantozzi, and J. Boyle, "Level3 MPLS Protocol
Architecture," Work in Progress.
4 V.追出石、C.Pierantozzi、およびJ.ボイル、「Level3 MPLSプロトコル構造」は進行中で働いています。
5 T. Li, and H. Smit, "IS-IS Extensions for Traffic Engineering,"
Work in Progress.
工学を取引してください。5 T.李、およびH.スミット、「-、拡大、」 仕事進行中です。
6 D. Katz, D. Yeung, and K. Kompella, "Traffic Engineering
Extensions to OSPF," Work in Progress.
6 D.キャッツ、D.Yeung、およびK.Kompella、「OSPFへの交通工学拡大」が進行中で働いています。
Boyle, et al. Informational [Page 11] RFC 3346 Applicability Statement for Traffic Engineering August 2002
ボイル、他 交通工学2002年8月のための情報[11ページ]のRFC3346適用性証明
7 Awduche, D., Berger, L., Gan, D.H., Li, T., Srinivasan, V. and G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209,
December 2001.
7 Awduche、D.、バーガー、L.、ガン、D.H.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
8 Jamoussi, B. (Editor), "Constraint-Based LSP Setup using LDP," RFC
3212, January 2002.
8 Jamoussi、B.(エディタ)、「自由民主党を使用する規制ベースのLSPセットアップ」、RFC3212、2002年1月。
9 Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for
Extensions to RSVP for LSP-Tunnels," RFC 3210, December 2001.
9 AwducheとD.とハナンとA.とX.Xiao、「LSP-TunnelsのためのRSVPへの拡大のための適用性証明」、RFC3210、2001年12月。
10 Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao,
"Overview and Principles of Internet Traffic Engineering", RFC
3272, May 2002.
10 Awduche、D.、チウ、A.、Elwalid、A.、ウィジャヤ、I.、X.Xiao、および「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。
11 W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, T.
Griffin, E. Kern, and T. Reddington, "Network Hierarchy and
Multilayer Survivability," Work in Progress.
11 南西レイ、D.McDysan、J.ボイル、M.カールソン、R.Coltun、T.グリフィン、E.カーン、およびReddingtonと、「ネットワーク階層構造と多層の生存性」が中で働かせるT.は進歩をします。
12 D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE
Communications Magazine, December 1999.
12 D.Awducheと、「中のIPがネットワークでつなぐMPLSと交通工学」、IEEEコミュニケーション雑誌、12月1999
13 W.S. Lai, B. Christian, R.W. Tibbs, and S. Van den Berghe, "A
Framework for Internet Traffic Engineering Measurement," Work in
Progress.
13 Berghe、「インターネット交通工学測定のための枠組み」を南西レイ、B.クリスチャン、R.W.Tibbs、およびS.ヴァンは穴に追い込みます、ProgressのWork。
9. Acknowledgments
9. 承認
The effectiveness of the MPLS protocols for traffic engineering in service provider networks is in large part due to the experience gained and foresight given by network engineers and developers familiar with traffic engineering with ATM in these environments. In particular, the authors wish to acknowledge the authors of RFC 2702 for the clear articulation of the requirements, as well as the developers and testers of code in deployment today for keeping their focus.
サービスプロバイダーネットワークにおける交通工学のためのMPLSプロトコルの有効性は主に行われた経験とATMと共にこれらの環境で交通工学に詳しいネットワーク・デザイナーと開発者によって与えられた先見のためです。 特に、作者は要件のはっきりした発音のためにRFC2702の作者を承認したがっています、彼らの焦点を保つための今日の展開におけるコードの開発者とテスターと同様に。
Boyle, et al. Informational [Page 12] RFC 3346 Applicability Statement for Traffic Engineering August 2002
ボイル、他 交通工学2002年8月のための情報[12ページ]のRFC3346適用性証明
10. Authors' Addresses
10. 作者のアドレス
Jim Boyle Protocol Driven Networks Tel: +1 919-852-5160 EMail: jboyle@pdnets.com
ジム・ボイルは駆動ネットワークTel:について議定書の中で述べます。 +1 919-852-5160 メールしてください: jboyle@pdnets.com
Vijay Gill AOL Time Warner, Inc. 12100 Sunrise Valley Drive Reston, VA 20191 EMail: vijay@umbc.edu
レストン、ヴァージニア 20191がメールするビジェイエラAOLタイム・ワーナーInc.12100日の出のバレードライブ: vijay@umbc.edu
Alan Hannan RoutingLoop Intergalactic 112 Falkirk Court Sunnyvale, CA 94087, USA Tel: +1 408-666-2326 EMail: alan@routingloop.com
法廷サニーベル、カリフォルニア 94087、アランハナンRoutingLoop銀河間の112フォルカーク米国Tel: +1 408-666-2326 メールしてください: alan@routingloop.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089, USA Tel: +1 916-415-0437 EMail: dcooper@gblx.net
デーヴ・桶屋グローバルクロッシング960ハムリン法廷サニーベル、カリフォルニア 94089、米国Tel: +1 916-415-0437 メールしてください: dcooper@gblx.net
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive, Suite 615 McLean, VA 22102, USA Tel: +1 703-298-5291 EMail: awduche@movaz.com
ダニエルO.Awduche Movazは7926年のジョーンズ支店Drive、Suite615マクリーン、ヴァージニア 22102、米国Tel:をネットワークでつなぎます。 +1 703-298-5291 メールしてください: awduche@movaz.com
Blaine Christian Worldcom 22001 Loudoun County Parkway, Room D1-2-737 Ashburn, VA 20147, USA Tel: +1 703-886-4425 EMail: blaine@uu.net
ブレインクリスチャンのWorldcom22001LoudounカウンティーのParkway、D1-2-737 Ashburn、ヴァージニア 20147、Room米国Tel: +1 703-886-4425 メールしてください: blaine@uu.net
Wai Sum Lai AT&T 200 Laurel Avenue Middletown, NJ 07748, USA Tel: +1 732-420-3712 EMail: wlai@att.com
Wai合計レイAT&T200ローレルアベニューミドルタウン、ニュージャージー 07748、米国Tel: +1 732-420-3712 メールしてください: wlai@att.com
Boyle, et al. Informational [Page 13] RFC 3346 Applicability Statement for Traffic Engineering August 2002
ボイル、他 交通工学2002年8月のための情報[13ページ]のRFC3346適用性証明
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。
Boyle, et al. Informational [Page 14]
ボイル、他 情報[14ページ]
一覧
スポンサーリンク
