RFC2382 日本語訳
2382 A Framework for Integrated Services and RSVP over ATM. E.Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. August 1998. (Format: TXT=73865 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Crawley, Editor
Request for Comments: 2382 Argon Networks
Category: Informational L. Berger
Fore Systems
S. Berson
ISI
F. Baker
Cisco Systems
M. Borden
Bay Networks
J. Krawczyk
ArrowPoint Communications
August 1998
Network Working Group E. Crawley, Editor Request for Comments: 2382 Argon Networks Category: Informational L. Berger Fore Systems S. Berson ISI F. Baker Cisco Systems M. Borden Bay Networks J. Krawczyk ArrowPoint Communications August 1998
A Framework for Integrated Services and RSVP over ATM
A Framework for Integrated Services and RSVP over ATM
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 (1998). All Rights Reserved.
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
Abstract
This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group.
This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group.
1. Introduction
1. Introduction
The Internet currently has one class of service normally referred to as "best effort." This service is typified by first-come, first- serve scheduling at each hop in the network. Best effort service has worked well for electronic mail, World Wide Web (WWW) access, file transfer (e.g. ftp), etc. For real-time traffic such as voice and video, the current Internet has performed well only across unloaded portions of the network. In order to provide quality real-time traffic, new classes of service and a QoS signalling protocol are
The Internet currently has one class of service normally referred to as "best effort." This service is typified by first-come, first- serve scheduling at each hop in the network. Best effort service has worked well for electronic mail, World Wide Web (WWW) access, file transfer (e.g. ftp), etc. For real-time traffic such as voice and video, the current Internet has performed well only across unloaded portions of the network. In order to provide quality real-time traffic, new classes of service and a QoS signalling protocol are
Crawley, et. al. Informational [Page 1] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 1] RFC 2382 Integrated Services and RSVP over ATM August 1998
being introduced in the Internet [1,6,7], while retaining the existing best effort service. The QoS signalling protocol is RSVP [1], the Resource ReSerVation Protocol and the service models
being introduced in the Internet [1,6,7], while retaining the existing best effort service. The QoS signalling protocol is RSVP [1], the Resource ReSerVation Protocol and the service models
One of the important features of ATM technology is the ability to request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). An additional feature of ATM technology is the ability to request point-to-multipoint VCs with a specified QoS. Point-to-multipoint VCs allows leaf nodes to be added and removed from the VC dynamically and so provides a mechanism for supporting IP multicast. It is only natural that RSVP and the Internet Integrated Services (IIS) model would like to utilize the QoS properties of any underlying link layer including ATM, and this memo concentrates on ATM.
One of the important features of ATM technology is the ability to request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). An additional feature of ATM technology is the ability to request point-to-multipoint VCs with a specified QoS. Point-to-multipoint VCs allows leaf nodes to be added and removed from the VC dynamically and so provides a mechanism for supporting IP multicast. It is only natural that RSVP and the Internet Integrated Services (IIS) model would like to utilize the QoS properties of any underlying link layer including ATM, and this memo concentrates on ATM.
Classical IP over ATM [10] has solved part of this problem, supporting IP unicast best effort traffic over ATM. Classical IP over ATM is based on a Logical IP Subnetwork (LIS), which is a separately administered IP subnetwork. Hosts within an LIS communicate using the ATM network, while hosts from different subnets communicate only by going through an IP router (even though it may be possible to open a direct VC between the two hosts over the ATM network). Classical IP over ATM provides an Address Resolution Protocol (ATMARP) for ATM edge devices to resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (i.e. hosts or routers), a single VC is created on demand and shared for all traffic between the two devices. A second part of the RSVP and IIS over ATM problem, IP multicast, is being solved with MARS [5], the Multicast Address Resolution Server.
Classical IP over ATM [10] has solved part of this problem, supporting IP unicast best effort traffic over ATM. Classical IP over ATM is based on a Logical IP Subnetwork (LIS), which is a separately administered IP subnetwork. Hosts within an LIS communicate using the ATM network, while hosts from different subnets communicate only by going through an IP router (even though it may be possible to open a direct VC between the two hosts over the ATM network). Classical IP over ATM provides an Address Resolution Protocol (ATMARP) for ATM edge devices to resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (i.e. hosts or routers), a single VC is created on demand and shared for all traffic between the two devices. A second part of the RSVP and IIS over ATM problem, IP multicast, is being solved with MARS [5], the Multicast Address Resolution Server.
MARS compliments ATMARP by allowing an IP address to resolve into a list of native ATM addresses, rather than just a single address.
MARS compliments ATMARP by allowing an IP address to resolve into a list of native ATM addresses, rather than just a single address.
The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over ATM (MPOA) [18] also address the support of IP best effort traffic over ATM through similar means.
The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over ATM (MPOA) [18] also address the support of IP best effort traffic over ATM through similar means.
A key remaining issue for IP in an ATM environment is the integration of RSVP signalling and ATM signalling in support of the Internet Integrated Services (IIS) model. There are two main areas involved in supporting the IIS model, QoS translation and VC management. QoS translation concerns mapping a QoS from the IIS model to a proper ATM QoS, while VC management concentrates on how many VCs are needed and which traffic flows are routed over which VCs.
A key remaining issue for IP in an ATM environment is the integration of RSVP signalling and ATM signalling in support of the Internet Integrated Services (IIS) model. There are two main areas involved in supporting the IIS model, QoS translation and VC management. QoS translation concerns mapping a QoS from the IIS model to a proper ATM QoS, while VC management concentrates on how many VCs are needed and which traffic flows are routed over which VCs.
Crawley, et. al. Informational [Page 2] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 2] RFC 2382 Integrated Services and RSVP over ATM August 1998
1.1 Structure and Related Documents
1.1 Structure and Related Documents
This document provides a guide to the issues for IIS over ATM. It is intended to frame the problems that are to be addressed in further documents. In this document, the modes and models for RSVP operation over ATM will be discussed followed by a discussion of management of ATM VCs for RSVP data and control. Lastly, the topic of encapsulations will be discussed in relation to the models presented.
This document provides a guide to the issues for IIS over ATM. It is intended to frame the problems that are to be addressed in further documents. In this document, the modes and models for RSVP operation over ATM will be discussed followed by a discussion of management of ATM VCs for RSVP data and control. Lastly, the topic of encapsulations will be discussed in relation to the models presented.
This document is part of a group of documents from the ISATM subgroup of the ISSLL working group related to the operation of IntServ and RSVP over ATM. [14] discusses the mapping of the IntServ models for Controlled Load and Guaranteed Service to ATM. [15 and 16] discuss detailed implementation requirements and guidelines for RSVP over ATM, respectively. While these documents may not address all the issues raised in this document, they should provide enough information for development of solutions for IntServ and RSVP over ATM.
This document is part of a group of documents from the ISATM subgroup of the ISSLL working group related to the operation of IntServ and RSVP over ATM. [14] discusses the mapping of the IntServ models for Controlled Load and Guaranteed Service to ATM. [15 and 16] discuss detailed implementation requirements and guidelines for RSVP over ATM, respectively. While these documents may not address all the issues raised in this document, they should provide enough information for development of solutions for IntServ and RSVP over ATM.
1.2 Terms
1.2 Terms
Several term used in this document are used in many contexts, often with different meaning. These terms are used in this document with the following meaning:
Several term used in this document are used in many contexts, often with different meaning. These terms are used in this document with the following meaning:
- Sender is used in this document to mean the ingress point to the
ATM network or "cloud".
- Receiver is used in this document to refer to the egress point from
the ATM network or "cloud".
- Reservation is used in this document to refer to an RSVP initiated
request for resources. RSVP initiates requests for resources based
on RESV message processing. RESV messages that simply refresh state
do not trigger resource requests. Resource requests may be made
based on RSVP sessions and RSVP reservation styles. RSVP styles
dictate whether the reserved resources are used by one sender or
shared by multiple senders. See [1] for details of each. Each new
request is referred to in this document as an RSVP reservation, or
simply reservation.
- Flow is used to refer to the data traffic associated with a
particular reservation. The specific meaning of flow is RSVP style
dependent. For shared style reservations, there is one flow per
session. For distinct style reservations, there is one flow per
sender (per session).
- Sender is used in this document to mean the ingress point to the ATM network or "cloud". - Receiver is used in this document to refer to the egress point from the ATM network or "cloud". - Reservation is used in this document to refer to an RSVP initiated request for resources. RSVP initiates requests for resources based on RESV message processing. RESV messages that simply refresh state do not trigger resource requests. Resource requests may be made based on RSVP sessions and RSVP reservation styles. RSVP styles dictate whether the reserved resources are used by one sender or shared by multiple senders. See [1] for details of each. Each new request is referred to in this document as an RSVP reservation, or simply reservation. - Flow is used to refer to the data traffic associated with a particular reservation. The specific meaning of flow is RSVP style dependent. For shared style reservations, there is one flow per session. For distinct style reservations, there is one flow per sender (per session).
2. Issues Regarding the Operation of RSVP and IntServ over ATM
2. Issues Regarding the Operation of RSVP and IntServ over ATM
The issues related to RSVP and IntServ over ATM fall into several general classes:
The issues related to RSVP and IntServ over ATM fall into several general classes:
Crawley, et. al. Informational [Page 3] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 3] RFC 2382 Integrated Services and RSVP over ATM August 1998
- How to make RSVP run over ATM now and in the future
- When to set up a virtual circuit (VC) for a specific Quality of
Service (QoS) related to RSVP
- How to map the IntServ models to ATM QoS models
- How to know that an ATM network is providing the QoS necessary for
a flow
- How to handle the many-to-many connectionless features of IP
multicast and RSVP in the one-to-many connection-oriented world of
ATM
- How to make RSVP run over ATM now and in the future - When to set up a virtual circuit (VC) for a specific Quality of Service (QoS) related to RSVP - How to map the IntServ models to ATM QoS models - How to know that an ATM network is providing the QoS necessary for a flow - How to handle the many-to-many connectionless features of IP multicast and RSVP in the one-to-many connection-oriented world of ATM
2.1 Modes/Models for RSVP and IntServ over ATM
2.1 Modes/Models for RSVP and IntServ over ATM
[3] Discusses several different models for running IP over ATM networks. [17, 18, and 20] also provide models for IP in ATM environments. Any one of these models would work as long as the RSVP control packets (IP protocol 46) and data packets can follow the same IP path through the network. It is important that the RSVP PATH messages follow the same IP path as the data such that appropriate PATH state may be installed in the routers along the path. For an ATM subnetwork, this means the ingress and egress points must be the same in both directions for the RSVP control and data messages. Note that the RSVP protocol does not require symmetric routing. The PATH state installed by RSVP allows the RESV messages to "retrace" the hops that the PATH message crossed. Within each of the models for IP over ATM, there are decisions about using different types of data distribution in ATM as well as different connection initiation. The following sections look at some of the different ways QoS connections can be set up for RSVP.
[3] Discusses several different models for running IP over ATM networks. [17, 18, and 20] also provide models for IP in ATM environments. Any one of these models would work as long as the RSVP control packets (IP protocol 46) and data packets can follow the same IP path through the network. It is important that the RSVP PATH messages follow the same IP path as the data such that appropriate PATH state may be installed in the routers along the path. For an ATM subnetwork, this means the ingress and egress points must be the same in both directions for the RSVP control and data messages. Note that the RSVP protocol does not require symmetric routing. The PATH state installed by RSVP allows the RESV messages to "retrace" the hops that the PATH message crossed. Within each of the models for IP over ATM, there are decisions about using different types of data distribution in ATM as well as different connection initiation. The following sections look at some of the different ways QoS connections can be set up for RSVP.
2.1.1 UNI 3.x and 4.0
2.1.1 UNI 3.x and 4.0
In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9] and 4.0 specification, both permanent and switched virtual circuits (PVC and SVC) may be established with a specified service category (CBR, VBR, and UBR for UNI 3.x and VBR-rt and ABR for 4.0) and specific traffic descriptors in point-to-point and point-to- multipoint configurations. Additional QoS parameters are not available in UNI 3.x and those that are available are vendor- specific. Consequently, the level of QoS control available in standard UNI 3.x networks is somewhat limited. However, using these building blocks, it is possible to use RSVP and the IntServ models. ATM 4.0 with the Traffic Management (TM) 4.0 specification [21] allows much greater control of QoS. [14] provides the details of mapping the IntServ models to UNI 3.x and 4.0 service categories and traffic parameters.
In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9] and 4.0 specification, both permanent and switched virtual circuits (PVC and SVC) may be established with a specified service category (CBR, VBR, and UBR for UNI 3.x and VBR-rt and ABR for 4.0) and specific traffic descriptors in point-to-point and point-to- multipoint configurations. Additional QoS parameters are not available in UNI 3.x and those that are available are vendor- specific. Consequently, the level of QoS control available in standard UNI 3.x networks is somewhat limited. However, using these building blocks, it is possible to use RSVP and the IntServ models. ATM 4.0 with the Traffic Management (TM) 4.0 specification [21] allows much greater control of QoS. [14] provides the details of mapping the IntServ models to UNI 3.x and 4.0 service categories and traffic parameters.
Crawley, et. al. Informational [Page 4] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 4] RFC 2382 Integrated Services and RSVP over ATM August 1998
2.1.1.1 Permanent Virtual Circuits (PVCs)
2.1.1.1 Permanent Virtual Circuits (PVCs)
PVCs emulate dedicated point-to-point lines in a network, so the operation of RSVP can be identical to the operation over any point- to-point network. The QoS of the PVC must be consistent and equivalent to the type of traffic and service model used. The devices on either end of the PVC have to provide traffic control services in order to multiplex multiple flows over the same PVC. With PVCs, there is no issue of when or how long it takes to set up VCs, since they are made in advance but the resources of the PVC are limited to what has been pre-allocated. PVCs that are not fully utilized can tie up ATM network resources that could be used for SVCs.
PVCs emulate dedicated point-to-point lines in a network, so the operation of RSVP can be identical to the operation over any point- to-point network. The QoS of the PVC must be consistent and equivalent to the type of traffic and service model used. The devices on either end of the PVC have to provide traffic control services in order to multiplex multiple flows over the same PVC. With PVCs, there is no issue of when or how long it takes to set up VCs, since they are made in advance but the resources of the PVC are limited to what has been pre-allocated. PVCs that are not fully utilized can tie up ATM network resources that could be used for SVCs.
An additional issue for using PVCs is one of network engineering. Frequently, multiple PVCs are set up such that if all the PVCs were running at full capacity, the link would be over-subscribed. This frequently used "statistical multiplexing gain" makes providing IIS over PVCs very difficult and unreliable. Any application of IIS over PVCs has to be assured that the PVCs are able to receive all the requested QoS.
An additional issue for using PVCs is one of network engineering. Frequently, multiple PVCs are set up such that if all the PVCs were running at full capacity, the link would be over-subscribed. This frequently used "statistical multiplexing gain" makes providing IIS over PVCs very difficult and unreliable. Any application of IIS over PVCs has to be assured that the PVCs are able to receive all the requested QoS.
2.1.1.2 Switched Virtual Circuits (SVCs)
2.1.1.2 Switched Virtual Circuits (SVCs)
SVCs allow paths in the ATM network to be set up "on demand". This allows flexibility in the use of RSVP over ATM along with some complexity. Parallel VCs can be set up to allow best-effort and better service class paths through the network, as shown in Figure 1. The cost and time to set up SVCs can impact their use. For example, it may be better to initially route QoS traffic over existing VCs until a SVC with the desired QoS can be set up for the flow. Scaling issues can come into play if a single RSVP flow is used per VC, as will be discussed in Section 4.3.1.1. The number of VCs in any ATM device may also be limited so the number of RSVP flows that can be supported by a device can be strictly limited to the number of VCs available, if we assume one flow per VC. Section 4 discusses the topic of VC management for RSVP in greater detail.
SVCs allow paths in the ATM network to be set up "on demand". This allows flexibility in the use of RSVP over ATM along with some complexity. Parallel VCs can be set up to allow best-effort and better service class paths through the network, as shown in Figure 1. The cost and time to set up SVCs can impact their use. For example, it may be better to initially route QoS traffic over existing VCs until a SVC with the desired QoS can be set up for the flow. Scaling issues can come into play if a single RSVP flow is used per VC, as will be discussed in Section 4.3.1.1. The number of VCs in any ATM device may also be limited so the number of RSVP flows that can be supported by a device can be strictly limited to the number of VCs available, if we assume one flow per VC. Section 4 discusses the topic of VC management for RSVP in greater detail.
Crawley, et. al. Informational [Page 5] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 5] RFC 2382 Integrated Services and RSVP over ATM August 1998
Data Flow ==========>
Data Flow ==========>
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS VCs
/\
||
VC ||
Initiator
+-----+ | | --------------> +----+ | Src | --------------> | R1 | | *| --------------> +----+ +-----+ QoS VCs /\ || VC || Initiator
Figure 1: Data Flow VC Initiation
Figure 1: Data Flow VC Initiation
While RSVP is receiver oriented, ATM is sender oriented. This might seem like a problem but the sender or ingress point receives RSVP RESV messages and can determine whether a new VC has to be set up to the destination or egress point.
While RSVP is receiver oriented, ATM is sender oriented. This might seem like a problem but the sender or ingress point receives RSVP RESV messages and can determine whether a new VC has to be set up to the destination or egress point.
2.1.1.3 Point to MultiPoint
2.1.1.3 Point to MultiPoint
In order to provide QoS for IP multicast, an important feature of RSVP, data flows must be distributed to multiple destinations from a given source. Point-to-multipoint VCs provide such a mechanism. It is important to map the actions of IP multicasting and RSVP (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop party functions for ATM. Point-to-multipoint VCs as defined in UNI 3.x and UNI 4.0 have a single service class for all destinations. This is contrary to the RSVP "heterogeneous receiver" concept. It is possible to set up a different VC to each receiver requesting a different QoS, as shown in Figure 2. This again can run into scaling and resource problems when managing multiple VCs on the same interface to different destinations.
In order to provide QoS for IP multicast, an important feature of RSVP, data flows must be distributed to multiple destinations from a given source. Point-to-multipoint VCs provide such a mechanism. It is important to map the actions of IP multicasting and RSVP (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop party functions for ATM. Point-to-multipoint VCs as defined in UNI 3.x and UNI 4.0 have a single service class for all destinations. This is contrary to the RSVP "heterogeneous receiver" concept. It is possible to set up a different VC to each receiver requesting a different QoS, as shown in Figure 2. This again can run into scaling and resource problems when managing multiple VCs on the same interface to different destinations.
Crawley, et. al. Informational [Page 6] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 6] RFC 2382 Integrated Services and RSVP over ATM August 1998
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Multicast
Group
+----+ +------> | R1 | | +----+ | | +----+ +-----+ -----+ +--> | R2 | | | ---------+ +----+ Receiver Request Types: | Src | ----> QoS 1 and QoS 2 | | .........+ +----+ ....> Best-Effort +-----+ .....+ +..> | R3 | : +----+ /\ : || : +----+ || +......> | R4 | || +----+ Single IP Multicast Group
Figure 2: Types of Multicast Receivers
Figure 2: Types of Multicast Receivers
RSVP sends messages both up and down the multicast distribution tree. In the case of a large ATM cloud, this could result in a RSVP message implosion at an ATM ingress point with many receivers.
RSVP sends messages both up and down the multicast distribution tree. In the case of a large ATM cloud, this could result in a RSVP message implosion at an ATM ingress point with many receivers.
ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf Initiated Join (LIJ) capability. LIJ allows an ATM end point to join into an existing point-to-multipoint VC without necessarily contacting the source of the VC. This can reduce the burden on the ATM source point for setting up new branches and more closely matches the receiver-based model of RSVP and IP multicast. However, many of the same scaling issues exist and the new branches added to a point- to-multipoint VC must use the same QoS as existing branches.
ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf Initiated Join (LIJ) capability. LIJ allows an ATM end point to join into an existing point-to-multipoint VC without necessarily contacting the source of the VC. This can reduce the burden on the ATM source point for setting up new branches and more closely matches the receiver-based model of RSVP and IP multicast. However, many of the same scaling issues exist and the new branches added to a point- to-multipoint VC must use the same QoS as existing branches.
2.1.1.4 Multicast Servers
2.1.1.4 Multicast Servers
IP-over-ATM has the concept of a multicast server or reflector that can accept cells from multiple senders and send them via a point-to- multipoint VC to a set of receivers. This moves the VC scaling issues noted previously for point-to-multipoint VCs to the multicast server. Additionally, the multicast server will need to know how to interpret RSVP packets or receive instruction from another node so it will be able to provide VCs of the appropriate QoS for the RSVP flows.
IP-over-ATM has the concept of a multicast server or reflector that can accept cells from multiple senders and send them via a point-to- multipoint VC to a set of receivers. This moves the VC scaling issues noted previously for point-to-multipoint VCs to the multicast server. Additionally, the multicast server will need to know how to interpret RSVP packets or receive instruction from another node so it will be able to provide VCs of the appropriate QoS for the RSVP flows.
Crawley, et. al. Informational [Page 7] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 7] RFC 2382 Integrated Services and RSVP over ATM August 1998
2.1.2 Hop-by-Hop vs. Short Cut
2.1.2 Hop-by-Hop vs. Short Cut
If the ATM "cloud" is made up a number of logical IP subnets (LISs), then it is possible to use "short cuts" from a node on one LIS directly to a node on another LIS, avoiding router hops between the LISs. NHRP [4], is one mechanism for determining the ATM address of the egress point on the ATM network given a destination IP address. It is a topic for further study to determine if significant benefit is achieved from short cut routes vs. the extra state required.
If the ATM "cloud" is made up a number of logical IP subnets (LISs), then it is possible to use "short cuts" from a node on one LIS directly to a node on another LIS, avoiding router hops between the LISs. NHRP [4], is one mechanism for determining the ATM address of the egress point on the ATM network given a destination IP address. It is a topic for further study to determine if significant benefit is achieved from short cut routes vs. the extra state required.
2.1.3 Future Models
2.1.3 Future Models
ATM is constantly evolving. If we assume that RSVP and IntServ applications are going to be wide-spread, it makes sense to consider changes to ATM that would improve the operation of RSVP and IntServ over ATM. Similarly, the RSVP protocol and IntServ models will continue to evolve and changes that affect them should also be considered. The following are a few ideas that have been discussed that would make the integration of the IntServ models and RSVP easier or more complete. They are presented here to encourage continued development and discussion of ideas that can help aid in the integration of RSVP, IntServ, and ATM.
ATM is constantly evolving. If we assume that RSVP and IntServ applications are going to be wide-spread, it makes sense to consider changes to ATM that would improve the operation of RSVP and IntServ over ATM. Similarly, the RSVP protocol and IntServ models will continue to evolve and changes that affect them should also be considered. The following are a few ideas that have been discussed that would make the integration of the IntServ models and RSVP easier or more complete. They are presented here to encourage continued development and discussion of ideas that can help aid in the integration of RSVP, IntServ, and ATM.
2.1.3.1 Heterogeneous Point-to-MultiPoint
2.1.3.1 Heterogeneous Point-to-MultiPoint
The IntServ models and RSVP support the idea of "heterogeneous receivers"; e.g., not all receivers of a particular multicast flow are required to ask for the same QoS from the network, as shown in Figure 2.
The IntServ models and RSVP support the idea of "heterogeneous receivers"; e.g., not all receivers of a particular multicast flow are required to ask for the same QoS from the network, as shown in Figure 2.
The most important scenario that can utilize this feature occurs when some receivers in an RSVP session ask for a specific QoS while others receive the flow with a best-effort service. In some cases where there are multiple senders on a shared-reservation flow (e.g., an audio conference), an individual receiver only needs to reserve enough resources to receive one sender at a time. However, other receivers may elect to reserve more resources, perhaps to allow for some amount of "over-speaking" or in order to record the conference (post processing during playback can separate the senders by their source addresses).
The most important scenario that can utilize this feature occurs when some receivers in an RSVP session ask for a specific QoS while others receive the flow with a best-effort service. In some cases where there are multiple senders on a shared-reservation flow (e.g., an audio conference), an individual receiver only needs to reserve enough resources to receive one sender at a time. However, other receivers may elect to reserve more resources, perhaps to allow for some amount of "over-speaking" or in order to record the conference (post processing during playback can separate the senders by their source addresses).
In order to prevent denial-of-service attacks via reservations, the service models do not allow the service elements to simply drop non- conforming packets. For example, Controlled Load service model [7] assigns non-conformant packets to best-effort status (which may result in packet drops if there is congestion).
In order to prevent denial-of-service attacks via reservations, the service models do not allow the service elements to simply drop non- conforming packets. For example, Controlled Load service model [7] assigns non-conformant packets to best-effort status (which may result in packet drops if there is congestion).
Crawley, et. al. Informational [Page 8] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 8] RFC 2382 Integrated Services and RSVP over ATM August 1998
Emulating these behaviors over an ATM network is problematic and needs to be studied. If a single maximum QoS is used over a point- to-multipoint VC, resources could be wasted if cells are sent over certain links where the reassembled packets will eventually be dropped. In addition, the "maximum QoS" may actually cause a degradation in service to the best-effort branches.
Emulating these behaviors over an ATM network is problematic and needs to be studied. If a single maximum QoS is used over a point- to-multipoint VC, resources could be wasted if cells are sent over certain links where the reassembled packets will eventually be dropped. In addition, the "maximum QoS" may actually cause a degradation in service to the best-effort branches.
The term "variegated VC" has been coined to describe a point-to- multipoint VC that allows a different QoS on each branch. This approach seems to match the spirit of the Integrated Service and RSVP models, but some thought has to be put into the cell drop strategy when traversing from a "bigger" branch to a "smaller" one. The "best-effort for non-conforming packets" behavior must also be retained. Early Packet Discard (EPD) schemes must be used so that all the cells for a given packet can be discarded at the same time rather than discarding only a few cells from several packets making all the packets useless to the receivers.
The term "variegated VC" has been coined to describe a point-to- multipoint VC that allows a different QoS on each branch. This approach seems to match the spirit of the Integrated Service and RSVP models, but some thought has to be put into the cell drop strategy when traversing from a "bigger" branch to a "smaller" one. The "best-effort for non-conforming packets" behavior must also be retained. Early Packet Discard (EPD) schemes must be used so that all the cells for a given packet can be discarded at the same time rather than discarding only a few cells from several packets making all the packets useless to the receivers.
2.1.3.2 Lightweight Signalling
2.1.3.2 Lightweight Signalling
Q.2931 signalling is very complete and carries with it a significant burden for signalling in all possible public and private connections. It might be worth investigating a lighter weight signalling mechanism for faster connection setup in private networks.
Q.2931 signalling is very complete and carries with it a significant burden for signalling in all possible public and private connections. It might be worth investigating a lighter weight signalling mechanism for faster connection setup in private networks.
2.1.3.3 QoS Renegotiation
2.1.3.3 QoS Renegotiation
Another change that would help RSVP over ATM is the ability to request a different QoS for an active VC. This would eliminate the need to setup and tear down VCs as the QoS changed. RSVP allows receivers to change their reservations and senders to change their traffic descriptors dynamically. This, along with the merging of reservations, can create a situation where the QoS needs of a VC can change. Allowing changes to the QoS of an existing VC would allow these features to work without creating a new VC. In the ITU-T ATM specifications [24,25], some cell rates can be renegotiated or changed. Specifically, the Peak Cell Rate (PCR) of an existing VC can be changed and, in some cases, QoS parameters may be renegotiated during the call setup phase. It is unclear if this is sufficient for the QoS renegotiation needs of the IntServ models.
Another change that would help RSVP over ATM is the ability to request a different QoS for an active VC. This would eliminate the need to setup and tear down VCs as the QoS changed. RSVP allows receivers to change their reservations and senders to change their traffic descriptors dynamically. This, along with the merging of reservations, can create a situation where the QoS needs of a VC can change. Allowing changes to the QoS of an existing VC would allow these features to work without creating a new VC. In the ITU-T ATM specifications [24,25], some cell rates can be renegotiated or changed. Specifically, the Peak Cell Rate (PCR) of an existing VC can be changed and, in some cases, QoS parameters may be renegotiated during the call setup phase. It is unclear if this is sufficient for the QoS renegotiation needs of the IntServ models.
2.1.3.4 Group Addressing
2.1.3.4 Group Addressing
The model of one-to-many communications provided by point-to- multipoint VCs does not really match the many-to-many communications provided by IP multicasting. A scaleable mapping from IP multicast addresses to an ATM "group address" can address this problem.
The model of one-to-many communications provided by point-to- multipoint VCs does not really match the many-to-many communications provided by IP multicasting. A scaleable mapping from IP multicast addresses to an ATM "group address" can address this problem.
Crawley, et. al. Informational [Page 9] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 9] RFC 2382 Integrated Services and RSVP over ATM August 1998
2.1.3.5 Label Switching
2.1.3.5 Label Switching
The MultiProtocol Label Switching (MPLS) working group is discussing methods for optimizing the use of ATM and other switched networks for IP by encapsulating the data with a header that is used by the interior switches to achieve faster forwarding lookups. [22] discusses a framework for this work. It is unclear how this work will affect IntServ and RSVP over label switched networks but there may be some interactions.
The MultiProtocol Label Switching (MPLS) working group is discussing methods for optimizing the use of ATM and other switched networks for IP by encapsulating the data with a header that is used by the interior switches to achieve faster forwarding lookups. [22] discusses a framework for this work. It is unclear how this work will affect IntServ and RSVP over label switched networks but there may be some interactions.
2.1.4 QoS Routing
2.1.4 QoS Routing
RSVP is explicitly not a routing protocol. However, since it conveys QoS information, it may prove to be a valuable input to a routing protocol that can make path determinations based on QoS and network load information. In other words, instead of asking for just the IP next hop for a given destination address, it might be worthwhile for RSVP to provide information on the QoS needs of the flow if routing has the ability to use this information in order to determine a route. Other forms of QoS routing have existed in the past such as using the IP TOS and Precedence bits to select a path through the network. Some have discussed using these same bits to select one of a set of parallel ATM VCs as a form of QoS routing. ATM routing has also considered the problem of QoS routing through the Private Network-to-Network Interface (PNNI) [26] routing protocol for routing ATM VCs on a path that can support their needs. The work in this area is just starting and there are numerous issues to consider. [23], as part of the work of the QoSR working group frame the issues for QoS Routing in the Internet.
RSVP is explicitly not a routing protocol. However, since it conveys QoS information, it may prove to be a valuable input to a routing protocol that can make path determinations based on QoS and network load information. In other words, instead of asking for just the IP next hop for a given destination address, it might be worthwhile for RSVP to provide information on the QoS needs of the flow if routing has the ability to use this information in order to determine a route. Other forms of QoS routing have existed in the past such as using the IP TOS and Precedence bits to select a path through the network. Some have discussed using these same bits to select one of a set of parallel ATM VCs as a form of QoS routing. ATM routing has also considered the problem of QoS routing through the Private Network-to-Network Interface (PNNI) [26] routing protocol for routing ATM VCs on a path that can support their needs. The work in this area is just starting and there are numerous issues to consider. [23], as part of the work of the QoSR working group frame the issues for QoS Routing in the Internet.
2.2 Reliance on Unicast and Multicast Routing
2.2 Reliance on Unicast and Multicast Routing
RSVP was designed to support both unicast and IP multicast applications. This means that RSVP needs to work closely with multicast and unicast routing. Unicast routing over ATM has been addressed [10] and [11]. MARS [5] provides multicast address resolution for IP over ATM networks, an important part of the solution for multicast but still relies on multicast routing protocols to connect multicast senders and receivers on different subnets.
RSVP was designed to support both unicast and IP multicast applications. This means that RSVP needs to work closely with multicast and unicast routing. Unicast routing over ATM has been addressed [10] and [11]. MARS [5] provides multicast address resolution for IP over ATM networks, an important part of the solution for multicast but still relies on multicast routing protocols to connect multicast senders and receivers on different subnets.
2.3 Aggregation of Flows
2.3 Aggregation of Flows
Some of the scaling issues noted in previous sections can be addressed by aggregating several RSVP flows over a single VC if the destinations of the VC match for all the flows being aggregated. However, this causes considerable complexity in the management of VCs and in the scheduling of packets within each VC at the root point of
Some of the scaling issues noted in previous sections can be addressed by aggregating several RSVP flows over a single VC if the destinations of the VC match for all the flows being aggregated. However, this causes considerable complexity in the management of VCs and in the scheduling of packets within each VC at the root point of
Crawley, et. al. Informational [Page 10] RFC 2382 Integrated Services and RSVP over ATM August 1998
Crawley, et. al. Informational [Page 10] RFC 2382 Integrated Services and RSVP over ATM August 1998
the VC. Note that the rescheduling of flows within a VC is not possible in the switches in the core of the ATM network. Virtual Paths (VPs) can be used for aggregating multiple VCs. This topic is discussed in greater detail as it applies to multicast data distribution in section 4.2.3.4
VC。 VCの中の流れの時期変更がATMネットワークのコアのスイッチで可能でないことに注意してください。 複数のVCsに集めるのに、仮想のPaths(VPs)を使用できます。 セクション4.2.3でマルチキャスト情報配給に.4を適用するとき、詳細によりすばらしいこの話題について議論します。
2.4 Mapping QoS Parameters
2.4 QoSパラメタを写像すること。
The mapping of QoS parameters from the IntServ models to the ATM service classes is an important issue in making RSVP and IntServ work over ATM. [14] addresses these issues very completely for the Controlled Load and Guaranteed Service models. An additional issue is that while some guidelines can be developed for mapping the parameters of a given service model to the traffic descriptors of an ATM traffic class, implementation variables, policy, and cost factors can make strict mapping problematic. So, a set of workable mappings that can be applied to different network requirements and scenarios is needed as long as the mappings can satisfy the needs of the service model(s).
RSVPとIntServにATMの上で働かせることにおいてIntServモデルからATMサービスのクラスまでのQoSパラメタに関するマッピングは切迫した課題です。 [14]は非常に完全にControlled LoadとGuaranteed Serviceモデルのためにこれらの問題を記述します。 追加設定は実現変数、方針、およびコスト要因で厳しいマッピングがATM交通のクラスに関する交通記述子に与えられたサービスモデルのパラメタを写像するためにいくつかのガイドラインを開発できる間問題が多くなる場合があるということです。 それで、サービスモデルの需要を満たすことができる限り、異なったネットワーク要件とシナリオに適用できる1セットの実行可能なマッピングが必要です。
2.5 Directly Connected ATM Hosts
2.5 直接接続された気圧ホスト
It is obvious that the needs of hosts that are directly connected to ATM networks must be considered for RSVP and IntServ over ATM. Functionality for RSVP over ATM must not assume that an ATM host has all the functionality of a router, but such things as MARS and NHRP clients would be worthwhile features. A host must manage VCs just like any other ATM sender or receiver as described later in section 4.
RSVPとIntServのためにATMの上で直接ATMネットワークに接続されるホストの必要性を考えなければならないのは明白です。 ATMの上のRSVPのための機能性は、ATMホストにはルータのすべての機能性があると仮定してはいけませんが、火星とNHRPクライアントのようなものは価値がある特徴でしょう。 ホストはセクション4でまさしくいかなる他のATM送付者や受信機のようなVCsも後述のように管理しなければなりません。
2.6 Accounting and Policy Issues
2.6 会計と政策問題
Since RSVP and IntServ create classes of preferential service, some form of administrative control and/or cost allocation is needed to control access. There are certain types of policies specific to ATM and IP over ATM that need to be studied to determine how they interoperate with the IP and IntServ policies being developed. Typical IP policies would be that only certain users are allowed to make reservations. This policy would translate well to IP over ATM due to the similarity to the mechanisms used for Call Admission Control (CAC).
RSVPとIntServが優先のサービスのクラスを創設するので、何らかの形式の運営管理コントロール、そして/または、費用配分がアクセサリーを制御するのに必要です。 開発されていて、あるタイプの彼らがIPと共にどのように共同利用するかを決定するために研究される必要があるATMの上でATMとIPに特定の方針とIntServ方針があります。 典型的なIP方針は確信しているユーザだけが予約をすることができるということでしょう。 この方針はCall Admission Control(CAC)に使用されるメカニズムへの類似性のためATMの上でIPによく移すでしょう。
There may be a need for policies specific to IP over ATM. For example, since signalling costs in ATM are high relative to IP, an IP over ATM specific policy might restrict the ability to change the prevailing QoS in a VC. If VCs are relatively scarce, there also might be specific accounting costs in creating a new VC. The work so far has been preliminary, and much work remains to be done. The
ATMの上でIPに特定の方針の必要があるかもしれません。 例えば、ATMの合図コストがIPに比例して高いので、ATM特定保険証券の上のIPはVCで行き渡っているQoSを変える能力を制限するかもしれません。 また、VCsが比較的不十分であるなら、新しいVCを作成するのにおいて特定の会計コストがあるかもしれません。 今までのところの仕事は予備でした、そして、多くの仕事が、するために残っています。 The
Crawley, et. al. Informational [Page 11] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[11ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
policy mechanisms outlined in [12] and [13] provide the basic mechanisms for implementing policies for RSVP and IntServ over any media, not just ATM.
[12]と[13]に概説された方針メカニズムはRSVPとIntServのためにATMだけではなく、どんなメディアでも政策を実施するのに基本的機構を提供します。
3. Framework for IntServ and RSVP over ATM
3. 気圧でのIntServとRSVPのための枠組み
Now that we have defined some of the issues for IntServ and RSVP over ATM, we can formulate a framework for solutions. The problem breaks down to two very distinct areas; the mapping of IntServ models to ATM service categories and QoS parameters and the operation of RSVP over ATM.
IntServとRSVPのためにATMの上で問題のいくつかを定義したので、私たちは解決策のために枠組みを定式化できます。 問題は最小2つの非常に異なった領域を壊します。 IntServに関するマッピングはATMの上でATMサービスカテゴリ、QoSパラメタ、およびRSVPの操作にモデル化されます。
Mapping IntServ models to ATM service categories and QoS parameters is a matter of determining which categories can support the goals of the service models and matching up the parameters and variables between the IntServ description and the ATM description(s). Since ATM has such a wide variety of service categories and parameters, more than one ATM service category should be able to support each of the two IntServ models. This will provide a good bit of flexibility in configuration and deployment. [14] examines this topic completely.
ATMサービスカテゴリとQoSパラメタにIntServモデルを写像するのは、どのカテゴリがサービスモデルとパラメタと変数を合わせるというIntServ記述とATM記述の間の目標を支持できるかを決定する問題です。 ATMにはそのようなさまざまなサービスカテゴリとパラメタがあるので、1つ以上のATMサービスカテゴリが2人のIntServモデル各人をサポートできるべきです。 これは構成と展開における、柔軟性の良いビットを提供するでしょう。 [14]はこの話題を完全に調べます。
The operation of RSVP over ATM requires careful management of VCs in order to match the dynamics of the RSVP protocol. VCs need to be managed for both the RSVP QoS data and the RSVP signalling messages. The remainder of this document will discuss several approaches to managing VCs for RSVP and [15] and [16] discuss their application for implementations in term of interoperability requirement and implementation guidelines.
ATMの上のRSVPの操作は、RSVPプロトコルの力学を合わせるために慎重な管理にVCsを要求します。 VCsは、RSVP QoSデータとRSVP合図メッセージの両方のために管理される必要があります。 [16] このドキュメントの残りはRSVPと[15]のためにVCsを管理することへのいくつかのアプローチについて議論するでしょう、そして、彼らの相互運用性要件と実施要綱の用語による実現のアプリケーションについて議論してください。
4. RSVP VC Management
4. RSVP VC管理
This section provides more detail on the issues related to the management of SVCs for RSVP and IntServ.
このセクションはSVCsの管理に関連する問題に関するその他の詳細をRSVPとIntServに供給します。
4.1 VC Initiation
4.1 VC開始
As discussed in section 2.1.1.2, there is an apparent mismatch between RSVP and ATM. Specifically, RSVP control is receiver oriented and ATM control is sender oriented. This initially may seem like a major issue, but really is not. While RSVP reservation (RESV) requests are generated at the receiver, actual allocation of resources takes place at the subnet sender. For data flows, this means that subnet senders will establish all QoS VCs and the subnet receiver must be able to accept incoming QoS VCs, as illustrated in Figure 1. These restrictions are consistent with RSVP version 1 processing rules and allow senders to use different flow to VC mappings and even different QoS renegotiation techniques without
セクション2.1.1で.2について議論するとき、RSVPとATMの間には、見かけのミスマッチがあります。 明確に、RSVPコントロールは受信機指向しています、そして、ATMコントロールは適応する送付者です。 これは、初めは主要な問題のように見えるかもしれませんが、本当にありません。 RSVP条件(RESV)要求は受信機で発生しますが、リソースの実際の配分はサブネット送付者で行われます。 データフローに関しては、これは、サブネット送付者がすべてのQoS VCsを設立することを意味します、そして、サブネット受信機は入って来るQoS VCsを受け入れることができなければなりません、図1で例証されるように。 これらの制限は、RSVPバージョン1処理規則と一致していて、送付者をVCマッピングと異なったQoS renegotiationのテクニックさえへの異なった流れを使用する許容します。
Crawley, et. al. Informational [Page 12] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[12ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
interoperability problems.
相互運用性問題。
The use of the reverse path provided by point-to-point VCs by receivers is for further study. There are two related issues. The first is that use of the reverse path requires the VC initiator to set appropriate reverse path QoS parameters. The second issue is that reverse paths are not available with point-to-multipoint VCs, so reverse paths could only be used to support unicast RSVP reservations.
さらなる研究には受信機によってポイントツーポイントVCsによって提供された逆の経路の使用があります。 関連する2冊があります。 1番目は逆の経路の使用が、VC創始者が適切な逆の経路QoSパラメタを設定するのを必要とするということです。 第2刷は逆の経路がポイントツーマルチポイントVCsと共に利用可能でないということです、ユニキャストRSVPの予約を支持するのに経路を使用できただけであるようにとても逆です。
4.2 Data VC Management
4.2 データVC管理
Any RSVP over ATM implementation must map RSVP and RSVP associated data flows to ATM Virtual Circuits (VCs). LAN Emulation [17], Classical IP [10] and, more recently, NHRP [4] discuss mapping IP traffic onto ATM SVCs, but they only cover a single QoS class, i.e., best effort traffic. When QoS is introduced, VC mapping must be revisited. For RSVP controlled QoS flows, one issue is VCs to use for QoS data flows.
ATM実現の上のどんなRSVPもRSVPを写像しなければなりません、そして、RSVP関連データはATM Virtual Circuits(VCs)に注ぎます。 LAN Emulation[17]、Classical IP[10]、および、より最近NHRP[4]は、IP交通をATM SVCsに写像するのを議論しますが、彼らは1つのQoSのクラス(すなわち、ベストエフォート型交通)しかカバーしません。 QoSを導入するとき、VCマッピングを再訪させなければなりません。 RSVPに関しては、制御QoSは流れて、1冊はQoSにデータフローを使用するVCsです。
In the Classic IP over ATM and current NHRP models, a single point- to-point VC is used for all traffic between two ATM attached hosts (routers and end-stations). It is likely that such a single VC will not be adequate or optimal when supporting data flows with multiple .bp QoS types. RSVP's basic purpose is to install support for flows with multiple QoS types, so it is essential for any RSVP over ATM solution to address VC usage for QoS data flows, as shown in Figure 1.
ATMと現在のNHRPモデルの上のClassic IPでは、ポイントへの独身のポイントVCは添付のATMが接待する2(ルータと端ステーション)の間のすべての交通に使用されます。 添付資料が複数の.bp QoSタイプであふれるとき、そのような独身のVCが適切であるか、または最適でなくなるのは、ありそうです。 ATM解決策の上のどんなRSVPもQoSデータフローのためにVC用法を記述するのは、RSVPの基本的な目的が複数のQoSタイプに従った流れのサポートをインストールすることであるので、不可欠です、図1に示されるように。
RSVP reservation styles must also be taken into account in any VC usage strategy.
また、どんなVC用法戦略でもRSVP予約スタイルを考慮に入れなければなりません。
This section describes issues and methods for management of VCs associated with QoS data flows. When establishing and maintaining VCs, the subnet sender will need to deal with several complicating factors including multiple QoS reservations, requests for QoS changes, ATM short-cuts, and several multicast specific issues. The multicast specific issues result from the nature of ATM connections. The key multicast related issues are heterogeneity, data distribution, receiver transitions, and end-point identification.
このセクションはQoSデータフローに関連しているVCsの管理のための問題と方法を説明します。 VCsを設立して、維持するとき、サブネット送付者は、複数のQoSの予約、QoS変化を求める要求、ATMショートカット、およびいくつかのマルチキャストの特定の問題を含むいくつかの複雑にする要素に対処する必要があるでしょう。 マルチキャストの特定の問題はATM接続の本質から生じます。 主要なマルチキャスト関連する問題は、異種性と、情報配給と、受信機変遷と、エンドポイント識別です。
4.2.1 Reservation to VC Mapping
4.2.1 VCマッピングへの予約
There are various approaches available for mapping reservations on to VCs. A distinguishing attribute of all approaches is how reservations are combined on to individual VCs. When mapping reservations on to VCs, individual VCs can be used to support a single reservation, or reservation can be combined with others on to
予約をVCsに写像するのに利用可能な様々なアプローチがあります。 すべてのアプローチの区別属性は予約がどう個々のVCsに結合されるかということです。 いつまで予約をVCsに写像して、ただ一つの予約を支持するのに個々のVCsを使用できますか、または他のものがオンな状態で予約を結合できますか。
Crawley, et. al. Informational [Page 13] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[13ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
"aggregate" VCs. In the first case, each reservation will be supported by one or more VCs. Multicast reservation requests may translate into the setup of multiple VCs as is described in more detail in section 4.2.2. Unicast reservation requests will always translate into the setup of a single QoS VC. In both cases, each VC will only carry data associated with a single reservation. The greatest benefit if this approach is ease of implementation, but it comes at the cost of increased (VC) setup time and the consumption of greater number of VC and associated resources.
「集合」のVCs。 前者の場合、各予約は1VCsによって支持されるでしょう。 マルチキャスト予約の要請はそのままで複数のVCsのセットアップにさらに詳細にセクション4.2.2で説明されていた状態で翻訳されるかもしれません。 ユニキャスト予約の要請はいつも独身のQoS VCのセットアップに翻訳されるでしょう。 どちらの場合も、各VCはただ一つの予約に関連しているデータを運ぶだけでしょう。 これにアプローチするなら、最もすばらしい利益は実現の容易さですが、それは増加する(VC)準備時間の費用と、より大きい数のVCと関連リソースの消費で来ます。
When multiple reservations are combined onto a single VC, it is referred to as the "aggregation" model. With this model, large VCs could be set up between IP routers and hosts in an ATM network. These VCs could be managed much like IP Integrated Service (IIS) point-to- point links (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over multiple RSVP sessions might be multiplexed on the same VC. This approach has a number of advantages. First, there is typically no signalling latency as VCs would be in existence when the traffic started flowing, so no time is wasted in setting up VCs. Second, the heterogeneity problem (section 4.2.2) in full over ATM has been reduced to a solved problem. Finally, the dynamic QoS problem (section 4.2.7) for ATM has also been reduced to a solved problem.
複数の予約が独身のVCに結合されるとき、それは「集合」モデルと呼ばれます。 このモデルと共に、ATMネットワークのIPルータとホストの間で大きいVCsをセットアップできました。 IP Integrated Service(IIS)ポイントからポイントへのリンク(例えば、T-1、DS-3)が現在管理されるようにこれらのVCsに対処できました。 同じVCで複数のRSVPセッションの間の複数のソースからの交通を多重送信するかもしれません。 このアプローチには、多くの利点があります。 交通が流れ始めたとき、VCsは現存しているでしょう、したがって、まず最初に潜在が通常合図でないので、時間は全くVCsをセットアップする際に浪費されません。 2番目に、ATMの上の全部の異種性問題(セクション4.2.2)は解決している問題に減少しました。 また、最終的に、ATMのためのダイナミックなQoS問題(セクション4.2.7)は解決している問題に減少しました。
The aggregation model can be used with point-to-point and point-to- multipoint VCs. The problem with the aggregation model is that the choice of what QoS to use for the VCs may be difficult, without knowledge of the likely reservation types and sizes but is made easier since the VCs can be changed as needed.
ポイントツーポイントとポイントから多点へのVCsと共に集合モデルを使用できます。 VCsの使用へのQoSがそうすることの選択がありそうな予約タイプとサイズに関する知識なしで難しいということですが、必要に応じてVCsを変えることができるので、集合モデルに関する問題をより簡単にします。
4.2.2 Unicast Data VC Management
4.2.2 ユニキャストデータVC管理
Unicast data VC management is much simpler than multicast data VC management but there are still some similar issues. If one considers unicast to be a devolved case of multicast, then implementing the multicast solutions will cover unicast. However, some may want to consider unicast-only implementations. In these situations, the choice of using a single flow per VC or aggregation of flows onto a single VC remains but the problem of heterogeneity discussed in the following section is removed.
ユニキャストデータVC管理はマルチキャストデータVC管理よりはるかに簡単ですが、いくつかの同様の問題がまだあります。 人が、ユニキャストがマルチキャストの譲り渡されたケースであると考えると、マルチキャストソリューションを実現すると、ユニキャストはカバーされるでしょう。 しかしながら、或るものはユニキャストだけ実現を考えたがっているかもしれません。 これらの状況で、1VCあたり1回のただ一つの流れを使用することの選択か独身のVCへの流れの集合が残っていますが、以下のセクションで議論した異種性の問題を取り除きます。
4.2.3 Multicast Heterogeneity
4.2.3 マルチキャストの異種性
As mentioned in section 2.1.3.1 and shown in figure 2, multicast heterogeneity occurs when receivers request different qualities of service within a single session. This means that the amount of requested resources differs on a per next hop basis. A related type of heterogeneity occurs due to best-effort receivers. In any IP
受信機がただ一つのセッション以内に異なったサービスの品質を要求するとき、セクション2.1.3で.1について言及して、2が中で計算するのが示されて、マルチキャストの異種性は起こります。 これは、要求されたリソースの量が次のホップ基礎あたりのaについて異なる意見をもつことを意味します。 関連するタイプの異種性はベストエフォート型受信機のため起こります。 どんなIPでも
Crawley, et. al. Informational [Page 14] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[14ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
multicast group, it is possible that some receivers will request QoS (via RSVP) and some receivers will not. In shared media networks, like Ethernet, receivers that have not requested resources can typically be given identical service to those that have without complications. This is not the case with ATM. In ATM networks, any additional end-points of a VC must be explicitly added. There may be costs associated with adding the best-effort receiver, and there might not be adequate resources. An RSVP over ATM solution will need to support heterogeneous receivers even though ATM does not currently provide such support directly.
マルチキャストは分類されます、そして、いくつかの受信機がQoS(RSVPを通した)を要求するのが、可能であり、いくつかの受信機は可能にならないでしょう。 共有されたマスメディア網で、イーサネットのように、複雑さなしでそうしたそれらに対する同じサービスをリソースを要求していない受信機に通常与えることができます。 これはATMがあるそうではありません。 ATMネットワークで、明らかにVCのどんな追加エンドポイントも加えなければなりません。 ベストエフォート型受信機を加えると関連しているコストがあるかもしれません、そして、適切なリソースはないかもしれません。 ATM解決策の上のRSVPは、ATMが現在、直接そのようなサポートを提供しませんが、異種の受信機を支える必要があるでしょう。
RSVP heterogeneity is supported over ATM in the way RSVP reservations are mapped into ATM VCs. There are four alternative approaches this mapping. There are multiple models for supporting RSVP heterogeneity over ATM. Section 4.2.3.1 examines the multiple VCs per RSVP reservation (or full heterogeneity) model where a single reservation can be forwarded onto several VCs each with a different QoS. Section 4.2.3.2 presents a limited heterogeneity model where exactly one QoS VC is used along with a best effort VC. Section 4.2.3.3 examines the VC per RSVP reservation (or homogeneous) model, where each RSVP reservation is mapped to a single ATM VC. Section 4.2.3.4 describes the aggregation model allowing aggregation of multiple RSVP reservations into a single VC.
RSVPの異種性はATMの上でRSVPの予約がATM VCsに写像される方法で支持されます。 そこでは、4つの代替的アプローチが写像することでのこれですか? ATMの上でRSVPの異種性を支持するための複数のモデルがあります。 セクション4.2 .3 .1 複数の異なったQoSと共にそれぞれ数個のVCsにただ一つの予約を送ることができるRSVP条件(または、完全な異種性)モデルあたりのVCsを調べます。 セクション4.2 .3 .2 1QoS VCがベストエフォート型VCと共に使用される限られた異種性モデルを提示します。 セクション4.2 .3 .3 RSVPの予約であって(均質)のモデルあたりのVCを調べます。(そこでは、それぞれのRSVPの予約が独身のATM VCに写像されます)。 セクション4.2 .3 .4 複数のRSVPの予約の集合を独身のVCに許容する集合モデルについて説明します。
4.2.3.1 Full Heterogeneity Model
4.2.3.1 完全な異種性モデル
RSVP supports heterogeneous QoS, meaning that different receivers of the same multicast group can request a different QoS. But importantly, some receivers might have no reservation at all and want to receive the traffic on a best effort service basis. The IP model allows receivers to join a multicast group at any time on a best effort basis, and it is important that ATM as part of the Internet continue to provide this service. We define the "full heterogeneity" model as providing a separate VC for each distinct QoS for a multicast session including best effort and one or more qualities of service.
同じマルチキャストグループの異なった受信機が異なったQoSを要求できることを意味して、RSVPは異種のQoSを支持します。 しかし、いくつかの受信機が、重要に、予約を全く持たないで、ベストエフォート型調査基準価格における交通を受けたがっているかもしれません。 IPモデルは受信機をいつでもベストエフォート型ベースでマルチキャストグループに加わらせます、そして、インターネットの一部としてのATMが、このサービスを提供し続けているのは、重要です。 私たちはマルチキャストセッションのための包含ベストエフォート型のそれぞれの異なったQoSとサービスの1つ以上の品質に別々のVCを供給すると「完全な異種性」モデルを定義します。
Note that while full heterogeneity gives users exactly what they request, it requires more resources of the network than other possible approaches. The exact amount of bandwidth used for duplicate traffic depends on the network topology and group membership.
完全な異種性がまさに彼らが要求するものをユーザに与えますが、他の可能なアプローチよりネットワークに関するリソースを必要とすることに注意してください。 写し交通に使用される正確な量の帯域幅がネットワーク形態とグループ会員資格によります。
4.2.3.2 Limited Heterogeneity Model
4.2.3.2 株式会社異種性モデル
We define the "limited heterogeneity" model as the case where the receivers of a multicast session are limited to use either best effort service or a single alternate quality of service. The alternate QoS can be chosen either by higher level protocols or by
私たちはマルチキャストセッションの受信機がベストエフォート型サービスかただ一つの交互のサービスの質のどちらかを利用するために制限されるケースと「限られた異種性」モデルを定義します。 交互のQoSを選ぶことができます。
Crawley, et. al. Informational [Page 15] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[15ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
dynamic renegotiation of QoS as described below.
以下で説明されるとしてのQoSのダイナミックな再交渉。
In order to support limited heterogeneity, each ATM edge device participating in a session would need at most two VCs. One VC would be a point-to-multipoint best effort service VC and would serve all best effort service IP destinations for this RSVP session.
限られた異種性を支持するために、会議に参加するそれぞれのATMエッジデバイスは2VCsを高々必要とするでしょう。 1VCがポイントツーマルチポイントベストエフォート型のサービスVCであるだろう、このRSVPセッションのためにすべてのベストエフォート型サービスIPの目的地に役立つでしょう。
The other VC would be a point to multipoint VC with QoS and would serve all IP destinations for this RSVP session that have an RSVP reservation established.
もう片方のVCはQoSと多点VCへのポイントであるだろう、このRSVPセッションのためのRSVPの予約を確立する目的地にすべてのIPに役立つでしょう。
As with full heterogeneity, a disadvantage of the limited heterogeneity scheme is that each packet will need to be duplicated at the network layer and one copy sent into each of the 2 VCs. Again, the exact amount of excess traffic will depend on the network topology and group membership. If any of the existing QoS VC end- points cannot upgrade to the new QoS, then the new reservation fails though the resources exist for the new receiver.
完全な異種性のように、限られた異種性計画の不都合は各パケットが、ネットワーク層とそれぞれの2VCsに送られたコピー1部にコピーされる必要があるということです。 一方、正確な量の余分な交通がネットワーク形態とグループ会員資格によるでしょう。 QoS VC終わりが指す存在のどれかが新しいQoSにアップグレードできないなら、リソースは新しい受信機のために存在していますが、新しい予約は失敗します。
4.2.3.3 Homogeneous and Modified Homogeneous Models
4.2.3.3 均質の、そして、変更された均質モデル
We define the "homogeneous" model as the case where all receivers of a multicast session use a single quality of service VC. Best-effort receivers also use the single RSVP triggered QoS VC. The single VC can be a point-to-point or point-to-multipoint as appropriate. The QoS VC is sized to provide the maximum resources requested by all RSVP next- hops.
私たちはマルチキャストセッションのすべての受信機がサービスVCのただ一つの品質を使用するケースと「均質」のモデルを定義します。 また、ベストエフォート型受信機は独身のRSVPを使用します。QoS VCの引き金となりました。 独身のVCは適宜ポイントツーポイントかポイントツーマルチポイントであるかもしれません。 QoS VCは、次のRSVPが飛び越すすべてによって要求された最大のリソースを提供するために大きさで分けられます。
This model matches the way the current RSVP specification addresses heterogeneous requests. The current processing rules and traffic control interface describe a model where the largest requested reservation for a specific outgoing interface is used in resource allocation, and traffic is transmitted at the higher rate to all next-hops. This approach would be the simplest method for RSVP over ATM implementations.
このモデルは現在のRSVP仕様が異種の要求を記述する方法に合っています。 現在の処理規則とトラフィックコントロールインタフェースは特定の外向的なインタフェースの最も大きい要求された予約が資源配分に使用されて、交通が、より高い速度ですべての次のホップに伝えられるモデルについて説明します。 このアプローチはATM実現の上のRSVPのための最も簡単な方法でしょう。
While this approach is simple to implement, providing better than best-effort service may actually be the opposite of what the user desires. There may be charges incurred or resources that are wrongfully allocated. There are two specific problems. The first problem is that a user making a small or no reservation would share a QoS VC resources without making (and perhaps paying for) an RSVP reservation. The second problem is that a receiver may not receive any data. This may occur when there is insufficient resources to add a receiver. The rejected user would not be added to the single VC and it would not even receive traffic on a best effort basis.
このアプローチは実行するのが簡単である間、ベストエフォート型サービスよりよく提供するのが、実際にユーザが望んでいることの正反対であるかもしれません。 不法に割り当てられる被られた料金かリソースがあるかもしれません。 2つの特定の問題があります。そして、第1の問題が小さいかいいえ、予約をしているユーザが作成なしでQoS VCリソースを共有するだろうということである、(恐らく代価を払う、)、RSVPの予約。 2番目の問題は受信機が少しのデータも受け取らないかもしれないということです。 受信機を加えるために不十分なリソースがあるとき、これは起こるかもしれません。拒絶されたユーザは独身のVCに加えられないでしょう、そして、それはベストエフォート型ベースにおける交通を受けてさえいないでしょう。
Crawley, et. al. Informational [Page 16] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[16ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
Not sending data traffic to best-effort receivers because of another receiver's RSVP request is clearly unacceptable. The previously described limited heterogeneous model ensures that data is always sent to both QoS and best-effort receivers, but it does so by requiring replication of data at the sender in all cases. It is possible to extend the homogeneous model to both ensure that data is always sent to best-effort receivers and also to avoid replication in the normal case. This extension is to add special handling for the case where a best- effort receiver cannot be added to the QoS VC. In this case, a best effort VC can be established to any receivers that could not be added to the QoS VC. Only in this special error case would senders be required to replicate data. We define this approach as the "modified homogeneous" model.
受信機の別のものによるベストエフォート型受信機へのデータ通信量をRSVPが要求する送らないのは明確に容認できません。 以前に説明された限られた異種のモデルは、データがいつもQoSとベストエフォート型受信機の両方に送られるのを保証しますが、それは、送付者ですべての場合でデータの模写を必要とすることによって、そうします。 データがいつもベストエフォート型受信機に送られるのを保証して、また、正常な場合における模写を避けるために均質モデルを広げるのは可能です。 この拡大はQoS VCに加えることができない中で努力受信機最も良いケースのための特別な取り扱いを加えることです。 この場合、QoS VCに加えることができなかったどんな受信機にもベストエフォート型VCを設立できます。 この特別な誤り事件だけでは、送付者はデータを模写しなければならないでしょう。 私たちは「均質の状態で変更されて」モデルとこのアプローチを定義します。
4.2.3.4 Aggregation
4.2.3.4 集合
The last scheme is the multiple RSVP reservations per VC (or aggregation) model. With this model, large VCs could be set up between IP routers and hosts in an ATM network. These VCs could be managed much like IP Integrated Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over multiple RSVP sessions might be multiplexed on the same VC. This approach has a number of advantages. First, there is typically no signalling latency as VCs would be in existence when the traffic started flowing, so no time is wasted in setting up VCs. Second, the heterogeneity problem in full over ATM has been reduced to a solved problem. Finally, the dynamic QoS problem for ATM has also been reduced to a solved problem. This approach can be used with point-to-point and point-to-multipoint VCs. The problem with the aggregation approach is that the choice of what QoS to use for which of the VCs is difficult, but is made easier if the VCs can be changed as needed.
VC(または、集合)モデルあたり最後の計画は複数のRSVPの予約です。 このモデルと共に、ATMネットワークのIPルータとホストの間で大きいVCsをセットアップできました。 IP Integrated Service(IIS)ポイントツーポイント接続(例えば、T-1、DS-3)が現在管理されるようにこれらのVCsに対処できました。 同じVCで複数のRSVPセッションの間の複数のソースからの交通を多重送信するかもしれません。 このアプローチには、多くの利点があります。 交通が流れ始めたとき、VCsは現存しているでしょう、したがって、まず最初に潜在が通常合図でないので、時間は全くVCsをセットアップする際に浪費されません。 2番目に、ATMの上の全部の異種性問題は解決している問題に減少しました。 また、最終的に、ATMのためのダイナミックなQoS問題は解決している問題に減少しました。 ポイントツーポイントとポイントツーマルチポイントVCsと共にこのアプローチを使用できます。 集合アプローチに関する問題は必要に応じてVCsのどれを難しいのですが、VCsであるなら、より簡単にするか使用へのQoSがそうすることができることの選択を変えるということです。
4.2.4 Multicast End-Point Identification
4.2.4 マルチキャストエンドポイント識別
Implementations must be able to identify ATM end-points participating in an IP multicast group. The ATM end-points will be IP multicast receivers and/or next-hops. Both QoS and best-effort end-points must be identified. RSVP next-hop information will provide QoS end- points, but not best-effort end-points. Another issue is identifying end-points of multicast traffic handled by non-RSVP capable next- hops. In this case a PATH message travels through a non-RSVP egress router on the way to the next hop RSVP node. When the next hop RSVP node sends a RESV message it may arrive at the source over a different route than what the data is using. The source will get the RESV message, but will not know which egress router needs the QoS. For unicast sessions, there is no problem since the ATM end-point will be the IP next-hop router. Unfortunately, multicast routing may
実現はIPマルチキャストグループに参加するATMエンドポイントを特定できなければなりません。 ATMエンドポイントは、IPマルチキャスト受信機、そして/または、次のホップになるでしょう。 QoSとベストエフォート型エンドポイントの両方を特定しなければなりません。 RSVP次のホップ情報はベストエフォート型エンドポイントではなく、終わりのポイントをQoSに供給するでしょう。 別の問題は次の非RSVPできるホップによって扱われたマルチキャスト交通のエンドポイントを特定しています。 この場合、PATHメッセージは非RSVP出口ルータを通って次のホップRSVPノードへの途中に移動します。 次のホップRSVPノードがRESVメッセージを送るとき、それはデータが使用していることより異なったルートの上のソースに到着するかもしれません。 情報筋は、RESVメッセージを得ますが、どの出口ルータがQoSを必要とするかを知らないでしょう。 ユニキャストセッションの間、ATMエンドポイントがIP次のホップルータになるので、問題が全くありません。 残念ながら、マルチキャストルーティングはそうするかもしれません。
Crawley, et. al. Informational [Page 17] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[17ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
not be able to uniquely identify the IP next-hop router. So it is possible that a multicast end-point can not be identified.
唯一IP次のホップルータを特定できてください。 それで、マルチキャストエンドポイントを特定できないのは可能です。
In the most common case, MARS will be used to identify all end-points of a multicast group. In the router to router case, a multicast routing protocol may provide all next-hops for a particular multicast group. In either case, RSVP over ATM implementations must obtain a full list of end-points, both QoS and non-QoS, using the appropriate mechanisms. The full list can be compared against the RSVP identified end-points to determine the list of best-effort receivers. There is no straightforward solution to uniquely identifying end- points of multicast traffic handled by non-RSVP next hops. The preferred solution is to use multicast routing protocols that support unique end-point identification. In cases where such routing protocols are unavailable, all IP routers that will be used to support RSVP over ATM should support RSVP. To ensure proper behavior, implementations should, by default, only establish RSVP- initiated VCs to RSVP capable end-points.
最も一般的な場合では、火星は、マルチキャストグループのすべてのエンドポイントを特定するのに使用されるでしょう。 ルータケースへのルータでは、マルチキャストルーティング・プロトコルはすべての次のホップを特定のマルチキャストグループに提供するかもしれません。 どちらの場合ではも、ATM実現の上のRSVPはエンドポイントに関する完全リスト、QoSと非QoSの両方を入手しなければなりません、適切な手段を使用して。リストを決定する特定されたエンドポイントのRSVPのベストエフォート型受信機に対して完全リストは比較できます。 唯一次の非RSVPホップによって扱われた終わりのポイントのマルチキャスト交通を特定するどんな簡単な解決策もありません。 都合のよい解決策はユニークなエンドポイント識別を支持するマルチキャストルーティング・プロトコルを使用することです。 そのようなルーティング・プロトコルが入手できない場合では、ATMの上でRSVPを支持するのに使用されるすべてのIPルータがRSVPを支持するべきです。 適切な振舞いを確実にするために、実現はデフォルトでRSVPのできるエンドポイントにRSVPの開始しているVCsを設立するだけであるべきです。
4.2.5 Multicast Data Distribution
4.2.5 マルチキャスト情報配給
Two models are planned for IP multicast data distribution over ATM. In one model, senders establish point-to-multipoint VCs to all ATM attached destinations, and data is then sent over these VCs. This model is often called "multicast mesh" or "VC mesh" mode distribution. In the second model, senders send data over point-to- point VCs to a central point and the central point relays the data onto point-to-multipoint VCs that have been established to all receivers of the IP multicast group. This model is often referred to as "multicast server" mode distribution. RSVP over ATM solutions must ensure that IP multicast data is distributed with appropriate QoS.
2つのモデルがATMの上のIPマルチキャスト情報配給のために計画されています。 1つのモデルでは、送付者はすべてのATMの付属目的地にポイントツーマルチポイントVCsを設立します、そして、次に、これらのVCsの上にデータを送ります。 このモデルはしばしば「マルチキャストメッシュ」か「VCメッシュ」モード分配と呼ばれます。 第2代モデルでは、主要なポイントと主要なポイントへのポイントからポイントの上の送付者送信データVCsはIPマルチキャストグループのすべての受信機に設立されたポイントツーマルチポイントVCsにデータをリレーします。 このモデルはしばしば「マルチキャストサーバ」モード分配と呼ばれます。 ATM解決策の上のRSVPは、IPマルチキャストデータが適切なQoSと共に分配されるのを確実にしなければなりません。
In the Classical IP context, multicast server support is provided via MARS [5]. MARS does not currently provide a way to communicate QoS requirements to a MARS multicast server. Therefore, RSVP over ATM implementations must, by default, support "mesh-mode" distribution for RSVP controlled multicast flows. When using multicast servers that do not support QoS requests, a sender must set the service, not global, break bit(s).
Classical IP文脈に、火星[5]を通してマルチキャストサーバサポートを提供します。 火星は現在、火星マルチキャストサーバにQoS要件を伝える方法を提供しません。したがって、ATM実現の上のRSVPはデフォルトでRSVPのための分配が制御した「メッシュモード」マルチキャスト流れを支持しなければなりません。 QoS要求を支持しないマルチキャストサーバを使用するとき、送付者はグローバルな中断ビットではなく、サービスを設定しなければなりません。
4.2.6 Receiver Transitions
4.2.6 受信機変遷
When setting up a point-to-multipoint VCs for multicast RSVP sessions, there will be a time when some receivers have been added to a QoS VC and some have not. During such transition times it is possible to start sending data on the newly established VC. The issue is when to start send data on the new VC. If data is sent both on the new VC and the old VC, then data will be delivered with proper
マルチキャストRSVPセッションのためのそこのVCsがセットアップするポイントツーマルチポイントをセットアップするときにはいくつかの受信機がQoS VCに加えられて、何かが時間でないことの時間になってください。 そのようなトランジッションタイムの間、新設されたVCにデータを送り始めるのは可能です。 問題はいつ新しいVCに送信データを始めるかということです。 新しいVCと古いVCにデータを送ると、適切であると共にデータを送るでしょう。
Crawley, et. al. Informational [Page 18] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[18ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
QoS to some receivers and with the old QoS to all receivers. This means the QoS receivers can get duplicate data. If data is sent just on the new QoS VC, the receivers that have not yet been added will lose information. So, the issue comes down to whether to send to both the old and new VCs, or to send to just one of the VCs. In one case duplicate information will be received, in the other some information may not be received.
すべての受信機へのいくつかの受信機と古いQoSとQoS。 これは、QoS受信機が重複データを得ることができることを意味します。 まさしく新しいQoS VCにデータを送ると、まだ加えられていない受信機は情報を失うでしょう。 それで、問題は両方の古くて新しいVCsに発信するか、またはちょうどVCsの1つに発信するかまで来ます。 ある場合では、写し情報を受け取って、もう片方では、何らかの情報は受け取らないかもしれません。
This issue needs to be considered for three cases:
この問題は、3つのケースのために考えられる必要があります:
- When establishing the first QoS VC - When establishing a VC to support a QoS change - When adding a new end-point to an already established QoS VC
- QoS VC--1番目を設立するときには、QoSを支持するためにVCを設立するときには既に確立したQoS VCに新しいエンドポイントを加えるときには変化してください。
The first two cases are very similar. It both, it is possible to send data on the partially completed new VC, and the issue of duplicate versus lost information is the same. The last case is when an end-point must be added to an existing QoS VC. In this case the end-point must be both added to the QoS VC and dropped from a best- effort VC. The issue is which to do first. If the add is first requested, then the end-point may get duplicate information. If the drop is requested first, then the end-point may loose information.
最初の2つのケースが非常に同様です。 それ、ともに、部分的に完成した新しいVCにデータを送るのが可能であり、写し対無くなっている情報の問題は同じです。 最後のケースは既存のQoS VCにエンドポイントを加えなければならない時です。 この場合、エンドポイントはQoS VCに加えられて、最も良い努力から落とされた両方がVCであったならそうしなければなりません。 問題は最初にどれをするかということです。 1番目が要求されていて、次に、エンドポイントが写し情報を得るかもしれないと言い足してください。 低下が最初に要求されるなら、エンドポイントは情報を発射するかもしれません。
In order to ensure predictable behavior and delivery of data to all receivers, data can only be sent on a new VCs once all parties have been added. This will ensure that all data is only delivered once to all receivers. This approach does not quite apply for the last case. In the last case, the add operation should be completed first, then the drop operation. This means that receivers must be prepared to receive some duplicate packets at times of QoS setup.
データの予測できる振舞いと配送をすべての受信機に確実にするために、いったんすべてのパーティーを加えると、新しいVCsにデータを送ることができるだけです。 これは、すべてのデータが一度すべての受信機に渡されるだけであるのを確実にするでしょう。 このアプローチは全く最後のケースに申し込むというわけではありません。 最後の場合で言い足す、操作が完成した1番目、次に、低下操作であるべきであると言い足してください。 これは、時にはQoSセットアップについていくつかの写しパケットを受けるように受信機を準備しなければならないことを意味します。
4.2.7 Dynamic QoS
4.2.7 ダイナミックなQoS
RSVP provides dynamic quality of service (QoS) in that the resources that are requested may change at any time. There are several common reasons for a change of reservation QoS.
要求されているリソースがいつでも変化するかもしれないので、RSVPはダイナミックなサービスの質(QoS)を提供します。 予約QoSの変化のいくつかの一般的な理由があります。
1. An existing receiver can request a new larger (or smaller) QoS.
2. A sender may change its traffic specification (TSpec), which can
trigger a change in the reservation requests of the receivers.
3. A new sender can start sending to a multicast group with a larger
traffic specification than existing senders, triggering larger
reservations.
4. A new receiver can make a reservation that is larger than existing
reservations.
1. 既存の受信機は新しいより大きい(より小さい)QoSを要求できます。 2. 送付者は交通仕様(TSpec)を変えるかもしれません。(それは、受信機に関する予約の要請における変化の引き金となることができます)。 3. 新しい送付者は、既存の送付者より大きい交通仕様でマルチキャストグループに発信し始めることができます、さらに大きい予約の引き金となって。 4. 新しい受信機は既存の予約より大きい予約をすることができます。
Crawley, et. al. Informational [Page 19] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[19ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
If the limited heterogeneity model is being used and the merge node for the larger reservation is an ATM edge device, a new larger reservation must be set up across the ATM network. Since ATM service, as currently defined in UNI 3.x and UNI 4.0, does not allow renegotiating the QoS of a VC, dynamically changing the reservation means creating a new VC with the new QoS, and tearing down an established VC. Tearing down a VC and setting up a new VC in ATM are complex operations that involve a non-trivial amount of processing time, and may have a substantial latency. There are several options for dealing with this mismatch in service. A specific approach will need to be a part of any RSVP over ATM solution.
限られた異種性モデルが使用されていて、より大きい予約のためのマージノードがATMエッジデバイスであるなら、ATMネットワークの向こう側に新しいより大きい予約をセットアップしなければなりません。 現在UNI 3.xとUNI4.0で定義されるATMサービスでVCのQoSを再交渉しないので、ダイナミックに予約を変えるのは、新しいQoSと新しいVCを作成して、確立したVCを取りこわすことを意味します。 VCを取りこわして、ATMで新しいVCをセットアップするのは、重要な量の処理時間にかかわる複雑な操作であり、かなりの潜在を持っているかもしれません。 このミスマッチに対処するためのいくつかの使用中のオプションがあります。 特定のアプローチは、ATM解決策の上のどんなRSVPの一部であるも必要があるでしょう。
The default method for supporting changes in RSVP reservations is to attempt to replace an existing VC with a new appropriately sized VC. During setup of the replacement VC, the old VC must be left in place unmodified. The old VC is left unmodified to minimize interruption of QoS data delivery. Once the replacement VC is established, data transmission is shifted to the new VC, and the old VC is then closed. If setup of the replacement VC fails, then the old QoS VC should continue to be used. When the new reservation is greater than the old reservation, the reservation request should be answered with an error. When the new reservation is less than the old reservation, the request should be treated as if the modification was successful. While leaving the larger allocation in place is suboptimal, it maximizes delivery of service to the user. Implementations should retry replacing the too large VC after some appropriate elapsed time.
RSVPの予約における変化を支持するためのデフォルト方法は既存のVCを新しい適切に大きさで分けられたVCに取り替えるのを試みることです。 交換VCのセットアップの間、古いVCは適所から変更されていなく外されなければなりません。 古いVCはQoSデータ配送の中断を最小にするために変更されていないままにされます。 交換VCがいったん設立されると、データ伝送は新しいVCに移行します、そして、次に、古いVCは閉じられます。 交換VCのセットアップが失敗するなら、古いQoS VCは、使用され続けているはずです。 新しい予約が古い予約より大きいときに、予約の要請は誤りで答えられるべきです。 新しい予約が古い予約以下であるときに、まるで変更がうまくいくかのように要求は扱われるべきです。 適所により大きい配分を残すのは準最適ですが、それはユーザに対するサービスの配送を最大にします。 実現は、いくつかの適切な経過時間の後に大き過ぎるVCを取り替えながら、再試行されるべきです。
One additional issue is that only one QoS change can be processed at one time per reservation. If the (RSVP) requested QoS is changed while the first replacement VC is still being setup, then the replacement VC is released and the whole VC replacement process is restarted. To limit the number of changes and to avoid excessive signalling load, implementations may limit the number of changes that will be processed in a given period. One implementation approach would have each ATM edge device configured with a time parameter T (which can change over time) that gives the minimum amount of time the edge device will wait between successive changes of the QoS of a particular VC. Thus if the QoS of a VC is changed at time t, all messages that would change the QoS of that VC that arrive before time t+T would be queued. If several messages changing the QoS of a VC arrive during the interval, redundant messages can be discarded. At time t+T, the remaining change(s) of QoS, if any, can be executed. This timer approach would apply more generally to any network structure, and might be worthwhile to incorporate into RSVP.
1つの追加設定はひところ予約単位で1つのQoS変化しか処理できないということです。 最初の交換VCがまだセットアップである間、(RSVP)要求されたQoSを変えるなら、交換VCをリリースします、そして、全体のVC交換の過程を再開します。 変化の数を制限して、過度の合図負荷を避けるために、実現は与えられた時代に処理される変化の数を制限するかもしれません。 1つの実現アプローチで、エッジデバイスが特定のVCのQoSの連続した変化の間で待っている最小の時間を与える時間パラメタT(時間がたつにつれて、変化できます)でそれぞれのATMエッジデバイスを構成するでしょう。 したがって、時tにVCのQoSを変えるなら、時間t+Tの前に到着するそのVCのQoSを変えるすべてのメッセージを列に並ばせるでしょう。 VCのQoSを変えるいくつかのメッセージが間隔の間、到着するなら、余分なメッセージを捨てることができます。 時間t+Tでは、もしあればQoSの残っている変化を実行できます。 このタイマアプローチ、より一般に、どんなネットワーク構造にも申し込んで、RSVPに盛込むために価値があるかもしれません。
Crawley, et. al. Informational [Page 20] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[20ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
The sequence of events for a single VC would be
独身のVCのための出来事の系列はそうでしょう。
- Wait if timer is active - Establish VC with new QoS - Remap data traffic to new VC - Tear down old VC - Activate timer
- タイマがアクティブであるなら、待ってください--新しいQoSとVCを設立してください--新しいVCへのRemapデータ通信量--古いVCを取りこわしてください--タイマを動かしてください。
There is an interesting interaction between heterogeneous reservations and dynamic QoS. In the case where a RESV message is received from a new next-hop and the requested resources are larger than any existing reservation, both dynamic QoS and heterogeneity need to be addressed. A key issue is whether to first add the new next-hop or to change to the new QoS. This is a fairly straight forward special case. Since the older, smaller reservation does not support the new next-hop, the dynamic QoS process should be initiated first. Since the new QoS is only needed by the new next-hop, it should be the first end-point of the new VC. This way signalling is minimized when the setup to the new next-hop fails.
異種の予約とダイナミックなQoSとのおもしろい相互作用があります。 新しい次のホップからRESVメッセージを受け取って、要求されたリソースがどんな既存の予約よりも大きい場合では、ダイナミックなQoSと異種性の両方が、記述される必要があります。 主要な問題は最初に、新しい次のホップを加えるか、または新しいQoSに変化するということです。 これはかなりまっすぐな前進の特別なそうです。 より古くて、より小さい予約が新しい次のホップを支持しないので、ダイナミックなQoSの過程は最初に、着手されるべきです。 新しいQoSが新しい次のホップによって必要とされるだけであるので、それは新しいVCの最初のエンドポイントであるべきです。 このように、新しい次のホップへのセットアップが失敗すると、合図は最小にされます。
4.2.8 Short-Cuts
4.2.8 ショートカット
Short-cuts [4] allow ATM attached routers and hosts to directly establish point-to-point VCs across LIS boundaries, i.e., the VC end-points are on different IP subnets. The ability for short-cuts and RSVP to interoperate has been raised as a general question. An area of concern is the ability to handle asymmetric short-cuts. Specifically how RSVP can handle the case where a downstream short- cut may not have a matching upstream short-cut. In this case, PATH and RESV messages following different paths.
ショートカット[4]はLIS境界の向こう側に直接ポイントツーポイントVCsを証明するために添付のATMにルータとホストを許容します、すなわち、VCエンドポイントが異なったIPサブネットにあります。 ショートカットとRSVPが共同利用する能力は一般疑問として上げられました。 気になる所は非対称のショートカットを扱う能力です。 RSVPは明確に、どう、川下の短いカットが合っている上流のショートカットを持っていないかもしれないケースを扱うことができるか。 この場合PATHと異なった経路に続くRESVメッセージ。
Examination of RSVP shows that the protocol already includes mechanisms that will support short-cuts. The mechanism is the same one used to support RESV messages arriving at the wrong router and the wrong interface. The key aspect of this mechanism is RSVP only processing messages that arrive at the proper interface and RSVP forwarding of messages that arrive on the wrong interface. The proper interface is indicated in the NHOP object of the message. So, existing RSVP mechanisms will support asymmetric short-cuts. The short-cut model of VC establishment still poses several issues when running with RSVP. The major issues are dealing with established best-effort short-cuts, when to establish short-cuts, and QoS only short-cuts. These issues will need to be addressed by RSVP implementations.
RSVPの試験は、プロトコルが既にショートカットを支持するメカニズムを含むのを示します。 メカニズムは間違ったルータと間違ったインタフェースに到着するRESVメッセージを支持するのに使用される同じ1つです。 このメカニズムの特徴は間違ったインタフェースで到着するメッセージの適切なインタフェースとRSVP推進に到達するメッセージを処理するだけであるRSVPです。 適切なインタフェースはメッセージのNHOP物で示されます。 それで、既存のRSVPメカニズムは非対称のショートカットを支持するでしょう。 RSVPと共に走るとき、VC設立のショートカットモデルはまだいくつかの問題を引き起こしています。 大変な問題は短いカットであるだけであることで確立したベストエフォート型ショートカット、いつショートカットを確立するか、そして、およびQoSに対処しています。 これらの問題は、RSVP実現で記述される必要があるでしょう。
The key issue to be addressed by any RSVP over ATM solution is when to establish a short-cut for a QoS data flow. The default behavior is to simply follow best-effort traffic. When a short-cut has been
ATM解決策の上にどんなRSVPによっても記述されるべき主要な問題はQoSデータフローのためにいつショートカットを確立するかということです。 デフォルトの振舞いは単にベストエフォート型交通に続くことです。 ショートカットはいつですか。
Crawley, et. al. Informational [Page 21] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[21ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
established for best-effort traffic to a destination or next-hop, that same end-point should be used when setting up RSVP triggered VCs for QoS traffic to the same destination or next-hop. This will happen naturally when PATH messages are forwarded over the best-effort short-cut. Note that in this approach when best-effort short-cuts are never established, RSVP triggered QoS short-cuts will also never be established. More study is expected in this area.
RSVPにセットするのがVCsの引き金となったとき、目的地か次のホップへのベストエフォート型交通に設立されて、その同じエンドポイントは同じ目的地か次のホップへのQoS交通に使用されるべきです。 ベストエフォート型ショートカットについてPATHメッセージを転送するとき、これは自然に起こるでしょう。 ベストエフォート型ショートカットが決して確立されないときのこのアプローチでは、RSVPがショートカットが引き金となるQoSの引き金となったことに注意してください、そして、また、決して確証されないでください。 より多くの研究がこの領域で予想されます。
4.2.9 VC Teardown
4.2.9 VC分解
RSVP can identify from either explicit messages or timeouts when a data VC is no longer needed. Therefore, data VCs set up to support RSVP controlled flows should only be released at the direction of RSVP. VCs must not be timed out due to inactivity by either the VC initiator or the VC receiver. This conflicts with VCs timing out as described in RFC 1755 [11], section 3.4 on VC Teardown. RFC 1755 recommends tearing down a VC that is inactive for a certain length of time. Twenty minutes is recommended. This timeout is typically implemented at both the VC initiator and the VC receiver. Although, section 3.1 of the update to RFC 1755 [11] states that inactivity timers must not be used at the VC receiver.
RSVPは、明白なメッセージかタイムアウトのどちらかからデータVCがいつもう必要でないかを特定できます。 したがって、データVCsはセットアップします。制御されて、RSVPを支持するために、流れはRSVPの指示に基づきリリースされるだけであるべきです。 VCsは不活発による外でVC創始者かVC受信機のどちらかによって調節されてはいけません。これはRFC1755[11]の説明されるとしてのVCsタイミングと衝突します、VC Teardownの上のセクション3.4。 RFC1755は、ある長さの時に不活発なVCを取りこわすことを勧めます。 20分はお勧めです。 このタイムアウトがVC創始者とVC受信機の両方で通常実行される、RFC1755[11]へのアップデートのセクション3.1は、VC受信機で不活発タイマを使用してはいけないと述べます。
When this timeout occurs for an RSVP initiated VC, a valid VC with QoS will be torn down unexpectedly. While this behavior is acceptable for best-effort traffic, it is important that RSVP controlled VCs not be torn down. If there is no choice about the VC being torn down, the RSVP daemon must be notified, so a reservation failure message can be sent.
このタイムアウトがいつRSVPのために起こるかがVCを開始して、不意にQoSと有効なVCを取りこわすでしょう。 ベストエフォート型交通において、この振舞いは許容できますが、RSVPがVCsを制御したのは、重要です。取りこわされません。 取りこわされるVCに関する選択が全くなければ、RSVPデーモンに通知しなければならないので、予約失敗メッセージを送ることができます。
For VCs initiated at the request of RSVP, the configurable inactivity timer mentioned in [11] must be set to "infinite". Setting the inactivity timer value at the VC initiator should not be problematic since the proper value can be relayed internally at the originator. Setting the inactivity timer at the VC receiver is more difficult, and would require some mechanism to signal that an incoming VC was RSVP initiated. To avoid this complexity and to conform to [11] implementations must not use an inactivity timer to clear received connections.
RSVPの依頼で開始されたVCsにおいて、[11]で言及された構成可能な不活発タイマを「無限」に設定しなければなりません。 VC創始者における不活発タイマ価値を設定するのは、創始者で内部的に固有値をリレーできるので、問題が多いはずがありません。 VC受信機に不活発タイマを設定するのは、より難しく、入って来るVCが開始されたRSVPであったと合図するために何らかのメカニズムを必要とするでしょう。 この複雑さを避けて、実現が使用してはいけない[11]に従うために、きれいにする不活発タイマは接続を受けました。
4.3 RSVP Control Management
4.3 RSVPコントロール管理
One last important issue is providing a data path for the RSVP messages themselves. There are two main types of messages in RSVP, PATH and RESV. PATH messages are sent to unicast or multicast addresses, while RESV messages are sent only to unicast addresses. Other RSVP messages are handled similar to either PATH or RESV, although this might be more complicated for RERR messages. So ATM VCs used for RSVP signalling messages need to provide both unicast
最後の1つの切迫した課題がRSVPメッセージ自体にデータ経路を提供しています。 2つの主なタイプに関するメッセージがRSVP、PATH、およびRESVにあります。 ユニキャストかマルチキャストアドレスにPATHメッセージを送りますが、RESVメッセージをユニキャストアドレスだけに送ります。 これはRERRメッセージのためにさらに複雑にされるかもしれませんが、他のRSVPメッセージはPATHかRESVのどちらかと同様の状態で扱われます。 RSVP合図メッセージに使用されるATM VCsが、ユニキャストを両方に提供する必要があるので
Crawley, et. al. Informational [Page 22] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[22ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
and multicast functionality. There are several different approaches for how to assign VCs to use for RSVP signalling messages.
そして、マルチキャストの機能性。 RSVPに合図メッセージを使用するためにどうVCsを割り当てるかためにはいくつかの異なるアプローチがあります。
The main approaches are:
主なアプローチは以下の通りです。
- use same VC as data
- single VC per session
- single point-to-multipoint VC multiplexed among sessions
- multiple point-to-point VCs multiplexed among sessions
- データと同じVCを使用してください--1セッションあたりの独身のVC--セッションのときに多重送信されたただ一つのポイントツーマルチポイントVC--複数のポイントツーポイントVCsはセッションのときに多重送信しました。
There are several different issues that affect the choice of how to assign VCs for RSVP signalling. One issue is the number of additional VCs needed for RSVP signalling. Related to this issue is the degree of multiplexing on the RSVP VCs. In general more multiplexing means fewer VCs. An additional issue is the latency in dynamically setting up new RSVP signalling VCs. A final issue is complexity of implementation. The remainder of this section discusses the issues and tradeoffs among these different approaches and suggests guidelines for when to use which alternative.
RSVP合図のためにどうVCsを割り当てるかの選択に影響するいくつかの別問題があります。 1冊はRSVP合図に必要である追加VCsの数です。 この問題に関連されるのは、RSVP VCsで多重送信する度です。 一般に、より少ない手段VCsをさらに多重送信します。 追加設定はダイナミックに新しいRSVP合図VCsをセットアップすることにおいて潜在です。 最終的な問題は実現の複雑さです。 このセクションの残りは、これらの異なるアプローチの中で問題と見返りについて議論して、いつどの代替手段を使用したらよいか間、ガイドラインを示します。
4.3.1 Mixed data and control traffic
4.3.1 Mixedデータとコントロール交通
In this scheme RSVP signalling messages are sent on the same VCs as is the data traffic. The main advantage of this scheme is that no additional VCs are needed beyond what is needed for the data traffic. An additional advantage is that there is no ATM signalling latency for PATH messages (which follow the same routing as the data messages). However there can be a major problem when data traffic on a VC is nonconforming. With nonconforming traffic, RSVP signalling messages may be dropped. While RSVP is resilient to a moderate level of dropped messages, excessive drops would lead to repeated tearing down and re-establishing of QoS VCs, a very undesirable behavior for ATM. Due to these problems, this may not be a good choice for providing RSVP signalling messages, even though the number of VCs needed for this scheme is minimized. One variation of this scheme is to use the best effort data path for signalling traffic. In this scheme, there is no issue with nonconforming traffic, but there is an issue with congestion in the ATM network. RSVP provides some resiliency to message loss due to congestion, but RSVP control messages should be offered a preferred class of service. A related variation of this scheme that is hopeful but requires further study is to have a packet scheduling algorithm (before entering the ATM network) that gives priority to the RSVP signalling traffic. This can be difficult to do at the IP layer.
この計画RSVPでは、データ通信量のように合図メッセージを同じVCsに送ります。 この計画の主な利点はどんな追加VCsもデータ通信量に必要であるものを超えて必要でないということです。 追加利点はPATHメッセージ(データメッセージと同じルーティングに従う)のために潜在に合図するATMが全くないということです。 しかしながら、VCにおけるデータ通信量が「非-従」っているとき、大した問題があることができます。 交通を「非-従」わせるのに、RSVP合図メッセージは落とされるかもしれません。 RSVPは適度のレベルの低下しているメッセージに弾力がある間、過度の低下がQoS VCs、ATMには、全く望ましくない振舞いの繰り返された裂け目と復職に通じるでしょう。 これらの問題のために、これは合図メッセージをRSVPに供給するための良い選択でないかもしれません、この計画に必要であるVCsの数が最小にされますが。 この計画の1回の変化は合図交通にベストエフォート型データ経路を使用することです。 この計画には、交通を「非-従」わせる問題が全くありませんが、ATMネットワークに混雑には問題があります。 RSVPは混雑によるメッセージの損失に何らかの弾性を提供しますが、都合のよいクラスのサービスをRSVPコントロールメッセージに提供するべきです。 希望に満ちていますが、さらなる研究を必要とするこの計画の関連する変化はRSVP合図交通を最優先させるパケットスケジューリングアルゴリズム(ATMネットワークに入る前の)を持つことです。 これはIP層でするのが難しい場合があります。
Crawley, et. al. Informational [Page 23] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[23ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
4.3.1.1 Single RSVP VC per RSVP Reservation
4.3.1.1 RSVP予約あたりの独身のRSVP VC
In this scheme, there is a parallel RSVP signalling VC for each RSVP reservation. This scheme results in twice the number of VCs, but means that RSVP signalling messages have the advantage of a separate VC. This separate VC means that RSVP signalling messages have their own traffic contract and compliant signalling messages are not subject to dropping due to other noncompliant traffic (such as can happen with the scheme in section 4.3.1). The advantage of this scheme is its simplicity - whenever a data VC is created, a separate RSVP signalling VC is created. The disadvantage of the extra VC is that extra ATM signalling needs to be done. Additionally, this scheme requires twice the minimum number of VCs and also additional latency, but is quite simple.
この計画には、それぞれのRSVPの予約のためにVCに合図する平行なRSVPがあります。 この計画は、VCsの数の2倍をもたらしますが、RSVP合図メッセージには別々のVCの利点があることを意味します。 この別々のVCは、RSVP合図メッセージにはメッセージを条件としていない他の不従順な交通(セクション4.3.1における計画で起こることができる)のため低下するそれら自身の交通契約と言いなりになっている合図があることを意味します。 この計画の利点は簡単さです--データVCが作成されるときはいつも、別々のRSVP合図VCは作成されます。 余分なVCの難点は余分なATM合図が、する必要があるということです。 さらに、この計画は、二度VCsの最小の数を必要として、また、追加潜在を必要としますが、かなり簡単です。
4.3.1.2 Multiplexed point-to-multipoint RSVP VCs
4.3.1.2 多重送信されたポイントツーマルチポイントRSVP VCs
In this scheme, there is a single point-to-multipoint RSVP signalling VC for each unique ingress router and unique set of egress routers. This scheme allows multiplexing of RSVP signalling traffic that shares the same ingress router and the same egress routers. This can save on the number of VCs, by multiplexing, but there are problems when the destinations of the multiplexed point-to-multipoint VCs are changing. Several alternatives exist in these cases, that have applicability in different situations. First, when the egress routers change, the ingress router can check if it already has a point-to- multipoint RSVP signalling VC for the new list of egress routers. If the RSVP signalling VC already exists, then the RSVP signalling traffic can be switched to this existing VC. If no such VC exists, one approach would be to create a new VC with the new list of egress routers. Other approaches include modifying the existing VC to add an egress router or using a separate new VC for the new egress routers. When a destination drops out of a group, an alternative would be to keep sending to the existing VC even though some traffic is wasted. The number of VCs used in this scheme is a function of traffic patterns across the ATM network, but is always less than the number used with the Single RSVP VC per data VC. In addition, existing best effort data VCs could be used for RSVP signalling. Reusing best effort VCs saves on the number of VCs at the cost of higher probability of RSVP signalling packet loss. One possible place where this scheme will work well is in the core of the network where there is the most opportunity to take advantage of the savings due to multiplexing. The exact savings depend on the patterns of traffic and the topology of the ATM network.
この計画には、それぞれのユニークなイングレスルータとユニークなセットの出口ルータのためにVCに合図するただ一つのポイントツーマルチポイントRSVPがあります。 この計画は同じイングレスルータと同じ出口ルータを共有されるRSVP合図交通のマルチプレクシングに許容します。 これはVCsの数でマルチプレクシングで節約されることができますが、多重送信されたポイントツーマルチポイントVCsの目的地が変化するとき、問題があります。 それには、いくつかの選択肢がこれらの場合で存在していて、異なった状況における適用性があります。 まず最初に、出口ルータが変化すると、イングレスルータは、ポイントから多点へのRSVPが出口ルータの新しいリストのためにそれで既にVCに合図するかどうかチェックできます。 RSVP合図VCが既に存在しているなら、RSVP合図交通をこの既存のVCに切り換えることができます。 どれかそのようなVCが存在していないなら、1つのアプローチは出口ルータの新しいリストで新しいVCを作成するだろうことです。 他のアプローチは、出口ルータを加えるように既存のVCを変更するか、または新しい出口ルータに別々の新しいVCを使用するのを含んでいます。 目的地がグループを落第すると、代替手段は何らかの交通が無駄ですが、既存のVCに発信し続けるだろうことです。 この計画に使用されるVCsの数は、ATMネットワークの向こう側のトラフィック・パターンの機能ですが、数がSingle RSVP VCと共にデータ単位でVCを使用したよりいつも少ないです。 さらに、RSVP合図に既存のベストエフォート型データVCsを使用できました。 ベストエフォート型VCsを再利用するのはVCsの数でRSVPがパケット損失に合図するというより高い確率の費用で節約されます。 この計画がうまくいく1つの可能な場所がマルチプレクシングのため貯蓄を利用する最も多くの機会があるネットワークのコアにあります。 正確な貯蓄はATMネットワークの交通とトポロジーのパターンによります。
Crawley, et. al. Informational [Page 24] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[24ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
4.3.1.3 Multiplexed point-to-point RSVP VCs
4.3.1.3 多重送信されたポイントツーポイントRSVP VCs
In this scheme, multiple point-to-point RSVP signalling VCs are used for a single point-to-multipoint data VC. This scheme allows multiplexing of RSVP signalling traffic but requires the same traffic to be sent on each of several VCs. This scheme is quite flexible and allows a large amount of multiplexing.
この計画では、複数のポイントツーポイントRSVP合図VCsはただ一つのポイントツーマルチポイントデータVCに使用されます。 この計画は、RSVP合図交通を多重送信するのを許容しますが、同じ交通がそれぞれの数個のVCsに送られるのを必要とします。 この計画は、かなりフレキシブルであり、多量のマルチプレクシングを許容します。
Since point-to-point VCs can set up a reverse channel at the same time as setting up the forward channel, this scheme could save substantially on signalling cost. In addition, signalling traffic could share existing best effort VCs. Sharing existing best effort VCs reduces the total number of VCs needed, but might cause signalling traffic drops if there is congestion in the ATM network. This point-to-point scheme would work well in the core of the network where there is much opportunity for multiplexing. Also in the core of the network, RSVP VCs can stay permanently established either as Permanent Virtual Circuits (PVCs) or as long lived Switched Virtual Circuits (SVCs). The number of VCs in this scheme will depend on traffic patterns, but in the core of a network would be approximately n(n-1)/2 where n is the number of IP nodes in the network. In the core of the network, this will typically be small compared to the total number of VCs.
順方向通信路をセットアップすることと同時にポイントツーポイントVCsが逆のチャンネルをセットアップできるので、この計画は合図費用で実質的に節約されることができました。 さらに、合図交通は既存のベストエフォート型VCsを共有するかもしれません。 既存のベストエフォート型VCsを共有すると、必要であるVCsの総数が減少しますが、ATMネットワークに混雑があれば、合図交通低下は引き起こされるかもしれません。 この二地点間計画はマルチプレクシングの多くの機会があるネットワークのコアでうまくいくでしょう。 ネットワークのコアにも、RSVP VCsは永久にPermanent Virtual Circuits(PVCs)として設立されたか、または長いとして送られたSwitched Virtual Circuits(SVCs)に滞在できます。 この計画における、VCsの数は、トラフィック・パターンによりますが、nがネットワークで、IPノードの数であるところのネットワークのコアのn(n-1)/2でしょう。 ネットワークのコアでは、VCsの総数と比べて、これは通常小さくなるでしょう。
4.3.2 QoS for RSVP VCs
4.3.2 RSVP VCsのためのQoS
There is an issue of what QoS, if any, to assign to the RSVP signalling VCs. For other RSVP VC schemes, a QoS (possibly best effort) will be needed. What QoS to use partially depends on the expected level of multiplexing that is being done on the VCs, and the expected reliability of best effort VCs. Since RSVP signalling is infrequent (typically every 30 seconds), only a relatively small QoS should be needed. This is important since using a larger QoS risks the VC setup being rejected for lack of resources. Falling back to best effort when a QoS call is rejected is possible, but if the ATM net is congested, there will likely be problems with RSVP packet loss on the best effort VC also. Additional experimentation is needed in this area.
合図VCsをRSVPに割り当てるために、どんなQoSの問題がもしあればあるか。 他のRSVP VC計画において、QoS(ことによるとベストエフォート型の)が必要でしょう。 使用へのQoSがそれを多重送信しながら予想水準に部分的に依存することは、VCsでして、ベストエフォート型VCsの期待される信頼度です。 RSVP合図が(通常30秒毎)単位で珍しいので、比較的小さいQoSだけが必要であるべきです。 VCがセットアップするより大きいQoS危険を使用して以来、これは、財源不足で拒絶されながら、重要です。 QoS呼び出しが拒絶されるときベストエフォート型へ後ろへ下がるのは可能ですが、ATMネットが混雑していると、RSVPパケット損失に関する問題がベストエフォート型VCにもおそらくあるでしょう。 追加実験がこの領域で必要です。
5. Encapsulation
5. カプセル化
Since RSVP is a signalling protocol used to control flows of IP data packets, encapsulation for both RSVP packets and associated IP data packets must be defined. The methods for transmitting IP packets over ATM (Classical IP over ATM[10], LANE[17], and MPOA[18]) are all based on the encapsulations defined in RFC1483 [19]. RFC1483 specifies two encapsulations, LLC Encapsulation and VC-based multiplexing. The former allows multiple protocols to be encapsulated over the same VC
RSVPがIPデータ・パケットの流れを制御するのに使用される合図プロトコルであるので、RSVPパケットと関連IPデータ・パケットの両方のためのカプセル化を定義しなければなりません。 IPパケットをATMの上に伝えるための方法、(ATM[10]の上の古典的なIP、レイン[17]、およびMPOA[18])はRFC1483[19]で定義されたカプセル化にすべて基づいています。 RFC1483は2つのカプセル化、LLC Encapsulation、およびVCベースのマルチプレクシングを指定します。 前者は、複数のプロトコルが同じVCの上に要約されるのを許容します。
Crawley, et. al. Informational [Page 25] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[25ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
and the latter requires different VCs for different protocols.
そして、後者は異なったプロトコルのために異なったVCsを必要とします。
For the purposes of RSVP over ATM, any encapsulation can be used as long as the VCs are managed in accordance to the methods outlined in Section 4. Obviously, running multiple protocol data streams over the same VC with LLC encapsulation can cause the same problems as running multiple flows over the same VC.
ATMの上のRSVPの目的のために、VCsが一致でセクション4に概説された方法に管理される限り、どんなカプセル化も使用できます。 明らかに、同じVCの上でLLCカプセル化で複数のプロトコルデータ・ストリームを走らせると、同じVCの上で複数の流れを走らせるのと同じ問題は引き起こされる場合があります。
While none of the transmission methods directly address the issue of QoS, RFC1755 [11] does suggest some common values for VC setup for best-effort traffic. [14] discusses the relationship of the RFC1755 setup parameters and those needed to support IntServ flows in greater detail.
透過法のいずれも直接QoSの問題を記述していない間、RFC1755[11]はベストエフォート型交通のためのVCセットアップのためにいくつかの共通の価値観を勧めます。 [14]はセットアップパラメタとものが詳細によりすばらしいIntServ流れを支持する必要があったRFC1755の関係について議論します。
6. Security Considerations
6. セキュリティ問題
The same considerations stated in [1] and [11] apply to this document. There are no additional security issues raised in this document.
[1]と[11]に述べられた同じ問題はこのドキュメントに適用されます。 本書では提起された追加担保問題が全くありません。
7. References
7. 参照
[1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2209, September 1997.
[1] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2209、1997年9月。
[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
of Realtime Services in an IP-ATM Network Architecture", RFC
1821, August 1995.
[2]ボーデン、M.、クローリー、E.、デイビー、B.、およびS.Batsell、「IP-気圧ネットワークアーキテクチャにおけるリアルタイムでサービスの統合」、RFC1821(1995年8月)。
[3] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework
Document", RFC 1932, April 1996.
[3] コール、R.、シュル、D.、およびC.Villamizar、「気圧でのIP:」 「枠組みのドキュメント」、RFC1932、1996年4月。
[4] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332,
April 1998.
[4] Luciani、J.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNBMAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC 2022, November 1996.
[5] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[6] Shenker, S., and C. Partridge, "Specification of Guaranteed
Quality of Service", RFC 2212, September 1997.
1997年9月の[6] Shenker、S.とC.ヤマウズラ、「保証されたサービスの質の仕様」RFC2212。
[7] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[7]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[8] ATM Forum. ATM User-Network Interface Specification Version 3.0.
Prentice Hall, September 1993.
[8] 気圧フォーラム。 気圧ユーザネットワーク・インターフェース仕様バージョン3.0。 1993年9月の新米のホール。
Crawley, et. al. Informational [Page 26] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[26ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
[9] ATM Forum. ATM User Network Interface (UNI) Specification Version
3.1. Prentice Hall, June 1995.
[9] 気圧フォーラム。 気圧ユーザネットワーク・インターフェース(UNI)仕様バージョン3.1。 1995年6月の新米のホール。
[10] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April
1998.
[10]Laubachと、M.と、「気圧での古典的なIPとARP」、RFC2225、4月1998日
[11] Perez, M., Mankin, A., Hoffman, E., Grossman, G., and A. Malis,
"ATM Signalling Support for IP over ATM", RFC 1755, February
1995.
[11] ペレス、M.、マンキン、A.、ホフマン、E.、グロースマン、G.、およびA.Malis、「気圧でのIPの気圧合図サポート」、RFC1755(1995年2月)。
[12] Herzog, S., "RSVP Extensions for Policy Control", Work in
Progress.
[12] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」が進行中で働いています。
[13] Herzog, S., "Local Policy Modules (LPM): Policy Control for
RSVP", Work in Progress.
[13] ハーツォグ、S.、「ローカルの方針モジュール(LPM):」 「RSVPのための方針コントロール」、進行中の仕事。
[14] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
and Guaranteed Service with ATM", RFC 2381, August 1998.
[14]ボーデン、M.、およびM.ギャレット、「気圧との制御負荷の、そして、保証されたサービスのInteroperation」、RFC2381、1998年8月。
[15] Berger, L., "RSVP over ATM Implementation Requirements", RFC
2380, August 1998.
[15] バーガー、L.、「気圧実現要件の上のRSVP」、RFC2380、1998年8月。
[16] Berger, L., "RSVP over ATM Implementation Guidelines", RFC 2379,
August 1998.
[16] バーガー、1998年8月、L.、「気圧実施要綱の上のRSVP」RFC2379。
[17] ATM Forum Technical Committee. LAN Emulation over ATM, Version
1.0 Specification, af-lane-0021.000, January 1995.
[17] 気圧フォーラム専門委員会。 ATMの上のLAN Emulation、バージョン1.0Specification、af車線0021.000、1995年1月。
[18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95-
0824r9, September 1996.
[18] 気圧フォーラム専門委員会。 MPOA、af-95- 0824r9のための1996年9月の基線Text。
[19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993.
[19] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[20] ATM Forum Technical Committee. LAN Emulation over ATM Version 2
- LUNI Specification, December 1996.
[20] 気圧フォーラム専門委員会。 気圧バージョン2の上のLANエミュレーション--1996年12月のルーニ仕様。
[21] ATM Forum Technical Committee. Traffic Management Specification
v4.0, af-tm-0056.000, April 1996.
[21] 気圧フォーラム専門委員会。 交通Management Specification v4.0、af-tm-0056.000、1996年4月。
[22] Callon, R., et al., "A Framework for Multiprotocol Label
Switching, Work in Progress.
[22]Callon、R.、他、「Multiprotocolラベルの切り換え、処理中の作業のための枠組み。」
[23] Rajagopalan, B., Nair, R., Sandick, H., and E. Crawley, "A
Framework for QoS-based Routing in the Internet", RFC 2386,
August 1998.
[23]Rajagopalan、B.、ナイア、R.、Sandick、H.、およびE.クローリー、「インターネットのQoSベースのルート設定のための枠組み」、RFC2386(1998年8月)。
Crawley, et. al. Informational [Page 27] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[27ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
[24] ITU-T. Digital Subscriber Signaling System No. 2-Connection
modification: Peak cell rate modification by the connection
owner, ITU-T Recommendation Q.2963.1, July 1996.
[24] ITU-T。 デジタルSubscriber Signaling SystemのNo.の2接続の変更: 1996年7月に接続所有者(ITU-T Recommendation Q.2963.1)によるセルレート変更に最大限にしてください。
[25] ITU-T. Digital Subscriber Signaling System No. 2-Connection
characteristics negotiation during call/connection establishment
phase, ITU-T Recommendation Q.2962, July 1996.
[25] ITU-T。 1996年7月の呼び出し/接続確立段階、ITU-T Recommendation Q.2962の間のNo.の2接続のデジタルSubscriber Signaling System特性の交渉。
[26] ATM Forum Technical Committee. Private Network-Network Interface
Specification v1.0 (PNNI), March 1996.
[26] 気圧フォーラム専門委員会。 1996年3月の個人的なNetwork-ネットワークInterface Specification v1.0(PNNI)。
8. Authors' Addresses
8. 作者のアドレス
Eric S. Crawley Argon Networks 25 Porter Road Littleton, Ma 01460
ポーターRoadリトルトン、エリックS.クローリーアルゴンネットワーク25マ01460
Phone: +1 978 486-0665 EMail: esc@argon.com
以下に電話をしてください。 +1 978 486-0665 メールしてください: esc@argon.com
Lou Berger FORE Systems 6905 Rockledge Drive Suite 800 Bethesda, MD 20817
ベセスダ、ルウバーガー前面のシステム6905RockledgeドライブSuite800MD 20817
Phone: +1 301 571-2534 EMail: lberger@fore.com
以下に電話をしてください。 +1 301 571-2534 メールしてください: lberger@fore.com
Steven Berson USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
スティーブンBerson USC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: +1 310 822-1511 EMail: berson@isi.edu
以下に電話をしてください。 +1 310 822-1511 メールしてください: berson@isi.edu
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111
フレッドベイカーシスコシステムズ519のLado Driveサンタバーバラ、カリフォルニア 93111
Phone: +1 805 681-0115 EMail: fred@cisco.com
以下に電話をしてください。 +1 805 681-0115 メールしてください: fred@cisco.com
Crawley, et. al. Informational [Page 28] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[28ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
Marty Borden Bay Networks 125 Nagog Park Acton, MA 01720
マーティボーデンベイネットワークス125Nagog Parkアクトン、MA 01720
Phone: +1 978 266-1011 EMail: mborden@baynetworks.com
以下に電話をしてください。 +1 978 266-1011 メールしてください: mborden@baynetworks.com
John J. Krawczyk ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886
ジョンJ.Krawczyk ArrowPointコミュニケーション235リトルトンRoadウェストフォード、マサチューセッツ 01886
Phone: +1 978 692-5875 EMail: jj@arrowpoint.com
以下に電話をしてください。 +1 978 692-5875 メールしてください: jj@arrowpoint.com
Crawley, et. al. Informational [Page 29] RFC 2382 Integrated Services and RSVP over ATM August 1998
etクローリー、アル。 情報[29ページ]のRFC2382は気圧1998年8月の間、サービスとRSVPを統合しました。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Crawley, et. al. Informational [Page 30]
etクローリー、アル。 情報[30ページ]
一覧
スポンサーリンク
