📄 rfc1190.txt
字号:
allocated depends on the details of the networks involved, and is not specified here. If an ST agent must send data across a network to a single next-hop ST agent, then only the point-to-point bandwidth needs to be reserved. If the agent must send data to multiple next- hop agents across one network and network layer multicasting is not available, then bandwidth must be reserved for all of them. This will allow the ST agent toCIP Working Group [Page 19]RFC 1190 Internet Stream Protocol October 1990 use replication to send a copy of the data packets to each next-hop agent. If multicast is supported, its use will decrease the effort that the ST agent must expend when forwarding packets and also reduces the bandwidth required since one copy can be received by all next-hop agents. However, the setup phase is more complicated. A network multicast address must be allocated that contains all those next-hop agents, the sender must have access to that address, the next-hop agents must be informed of the address so they can join the multicast group identified by it (see Section 4.2.2.7 (page 86)), and a common HID must be negotiated. The network should consider the bandwidth and multicast requirements to determine the amount of packet switch processing bandwidth and buffer space to reserve for the stream. In addition, the membership of a stream in a Group may affect the resources that have to be allocated; see Section 3.7.3 (page 56). Few networks in the Internet currently offer resource reservation, and none that we know of offer reservation of all the resources specified here. Only the Terrestrial Wideband Network (TWBNet) [7] and the Atlantic Satellite Network (SATNET) [9] offer(ed) bandwidth reservation. Multicasting is more widely supported. No network provides for the reservation of packet switch processing bandwidth or buffer space. We hope that future networks will be designed to better support protocols like ST. Effects similar to reservation of the necessary resources may be obtained even when the network cannot provide direct support for the reservation. Certainly if total reservations are a small fraction of the overall resources, such as packet switch processing bandwidth, buffer space, or network bandwidth, then the desired performance can be honored if the degree of confidence is consistent with the requirements as stated in the FlowSpec. Other solutions can be designed for specific networks. 3.1.4. Sending CONNECT Messages A VLId and a proposed HID must be selected for each next-hop agent. The control packets for the next-hop must carry the VLId in the SVLId field. The data packets transmitted in the stream to the next-hop must carry the HID in the ST Header. The ST agent sends a CONNECT message to each of the ST agents identified by the routing function. Each CONNECT message contains the VLId, the proposed HID (the HID Field option bitCIP Working Group [Page 20]RFC 1190 Internet Stream Protocol October 1990 must be set, see Section 3.6.1 (page 44)), an updated FlowSpec, and a TargetList. In general, the HID, FlowSpec, and TargetList will depend on both the next-hop and the intervening network. Each TargetList is a subset of the received (or original) TargetList, identifying the targets that are to be reached through the next-hop to which the CONNECT message is being sent. Note that a CONNECT message to a single next-hop might have to be fragmented into multiple CONNECTs if the single CONNECT is too large for the intervening network's MTU; fragmentation is performed by further dividing the TargetList. If multiple next-hops are to be reached through a network that supports network level multicast, a different CONNECT message must nevertheless be sent to each next-hop since each will have a different TargetList; see Section 4.2.3.5 (page 105). However, since an identical copy of each ensuing data packet will reach each member of the multicast group, all the CONNECT messages must propose the same HID. See Section 3.7.4 (page 58) for a detailed discussion on HID selection. In the example of Figure 2, the routing function might return that B is reachable via Agent 1 and C and D are reachable via Agent 2. Thus A would create two CONNECT messages, one each for Agents 1 and 2, as illustrated in Figure 5. Assuming that the proposed HIDs are available in the receiving agents, they would each send a responding HID-APPROVE back to Agent A. Application Agent A Agent 1 Agent 2 1.1. (open B,C,D) V 1.2. +-> (routing to B,C,D) V 1.3. +->(reserve resources from A to Agent 1) | V 1.4. | +-> CONNECT B --------->> | <RVLId=0><SVLId=4> | <Ref=10><HID=1200> V 1.5. +->(reserve resources from A to Agent 2) V 1.6. +-> CONNECT C,D ------------------>> <RVLId=0><SVLId=5> <Ref=15><HID=2400> Figure 5. Origin Sending CONNECT MessageCIP Working Group [Page 21]RFC 1190 Internet Stream Protocol October 1990 3.1.5. CONNECT Processing by an Intermediate Agent An ST agent receiving a CONNECT message should, assuming no errors, quickly select a VLId and respond to the previous-hop with either an ACK, a HID-REJECT, or a HID-APPROVE message, as is appropriate. This message must identify the CONNECT to which it corresponds by including the CONNECT's Reference number in its Reference field. Note that the VLId that this agent selects is placed in the SVLId of the response, and the previous-hop's VLId (which is contained in the SVLId of the CONNECT) is copied into the RVLId of the response. If the agent is not a target, it must then invoke the routing function, reserve resources, and send a CONNECT message(s) to its next-hop(s), as described in Sections 3.1.2-4 (pages 19- 20). Agent A Agent 1 Agent B [1.4] >>-> CONNECT B -------->+--+ <RVLId=0><SVLId=4> | V2.1. <Ref=10><HID=1200> | (routing to B) | V2.2. V +->(reserve resources from 1 to B)2.3. +<- HID-APPROVE <------+ V2.4. <RVLId=4><SVLId=14> +-> CONNECT B ---------->> <Ref=10><HID=1200> <RVLId=0><SVLId=15> <Ref=110><HID=3600> Agent A Agent 2 Agent C [1.6] >>-> CONNECT C,D ------>+-+ <RVLId=0><SVLId=5> | V2.5. <Ref=15><HID=2400> | (routing to C,D) | V2.6. V +-->(reserve resources from 2 to C)2.7. +<- HID-APPROVE <------+ | V2.8. <RVLId=5><SVLId=23> | +-> CONNECT C ---------->> <Ref=15><HID=2400> | <RVLId=0><SVLId=25> | <Ref=210><HID=4800> | | Agent D V2.9. +->(reserve resources from 2 to D) V2.10. +-> CONNECT D ---------->> <RVLId=0><SVLId=26> <Ref=215><HID=4800> Figure 6. CONNECT Processing by an Intermediate AgentCIP Working Group [Page 22]RFC 1190 Internet Stream Protocol October 1990 The resources listed as Desired in a received FlowSpec may not correspond to those actually reserved in either the ST agent itself or in the network(s) used to reach the next-hop agent(s). As long as the reserved resources are sufficient to meet the specified Limits, the copy of the FlowSpec sent to a next-hop must have the Desired resources updated to reflect the resources that were actually obtained. For example, the Desired bandwidth might be reduced because the network to the next-hop could not provide all of the desired bandwidth. Also, the delay and delay variance are appropriately increased, and the link MTU may require that the DesPDUBytes field be reduced. (The minimum requirements that the origin had entered into the FlowSpec Limits fields cannot be altered by the intermediate or target agents.) 3.1.6. Setup at the Targets An ST agent that is the target of a CONNECT, whether from an intermediate ST agent, or directly from the origin host ST agent, must respond first (assuming no errors) with either a HID-REJECT or HID-APPROVE. After inquiring from the specified application process whether or not it is willing to accept the connection, the agent must also respond with either an ACCEPT or a REFUSE. In particular, the application must be presented with parameters from the CONNECT, such as the Name, FlowSpec, Options, and Group, to be used as a basis for its decision. The application is identified by a combination of the NextPcol field and the SAP field in the (usually) single remaining Target of the TargetList. The contents of the SAP field may specify the "port" or other local identifier for use by the protocol layer above the host ST layer. Subsequently received data packets will carry a short hand identifier (the HID) that can be mapped into this information and be used for their delivery. The responses to the CONNECT message are sent to the previous- hop from which the CONNECT was received. An ACCEPT contains the Name of the stream and the updated FlowSpec. Note that the application might have reduced the desired level of service in the received FlowSpec before accepting it. The target must not send the ACCEPT until HID negotiation has been successfully completed. Since the ACCEPT or REFUSE message must be acknowledged by the previous-hop, it is assigned a new Reference number that will be returned in the ACK. The CONNECT to which the ACCEPT or REFUSE is a reply is identified by placing the CONNECT's Reference number in the LnkReference field of the ACCEPT or REFUSE.CIP Working Group [Page 23]RFC 1190 Internet Stream Protocol October 1990 Agent 1 Agent B Application B 3.1. (proc B listening) [2.4] >>-> CONNECT B ---------->+------------------+ <RVLId=0><SVLId=15> | | 3.2. <Ref=110><HID=3600> V (proc B accepts) 3.3. +<- HID-APPROVE <--------+ | <RVLId=15><SVLId=44> | <Ref=110><HID=3600> V 3.4. (wait until HID negotiated) <---+ V 3.5. <<--+<- ACCEPT B <-----------+ <RVLId=15><SVLId=44> <Ref=410><LnkRef=110> Agent 2 Agent C Application C 3.6. (proc C listening) [2.8] >>-> CONNECT C ---------->+------------------+ <RVLId=0><SVLId=25> | | 3.7. <Ref=210><HID=4800> V (proc C accepts) 3.8. +<- HID-APPROVE <--------+
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -