Введение_Цель, RFC, rfc, Rfc, RFC-, rfc-, Rfc-
8 Ancillary Functions
Certain functions are required by ST host and intermediate agent
implementations. Such functions are described in this section.
8.1 Stream ID Generation
The stream ID, or SID, is composed of 16-bit unique identifier and
the stream origin's 32-bit IP address. Stream IDs must be globally
unique. The specific definition and format of the 16 -bit field is
left to the implementor. This field is expected to have only local
significance.
An ST implementation has to provide a stream ID generator facility,
so that an application or higher layer protocol can obtain a unique
IDs from the ST layer. This is a mechanism for the application to
request the allocation of stream ID that is independent of the
request to create a stream. The Stream ID is used by the application
or higher layer protocol when creating the streams.
For instance, the following two functions could be made available:
o AllocateStreamID() -> result, StreamID
o ReleaseStreamID(StreamID) -> result
An implementation may also provide a StreamID deletion function.
8.2 Group Name Generator
GroupName generation is similar to Stream ID generation. The
GroupName includes a 16-bit unique identifier, a 32-bit creation
timestamp, and a 32-bit IP address. Group names are globally unique.
A GroupName includes the creator's IP address, so this reduces a
global uniqueness problem to a simple local problem. The specific
definitions and formats of the 16-bit field and the 32-bit creation
timestamp are left to the implementor. These fields must be locally
unique, and only have local significance.
An ST implementation has to provide a group name generator facility,
so that an application or higher layer protocol can obtain a unique
GroupName from the ST layer. This is a mechanism for the application
Delgrossi & Berger, Editors Experimental [Page 66]
RFC 1819 ST2+ Protocol Specification August 1995
to request the allocation of a GroupName that is independent of the
request to create a stream. The GroupName is used by the application
or higher layer protocol when creating the streams that are to be
part of the group.
For instance, the following two functions could be made available:
o AllocateGroupName() -> result, GroupName
o ReleaseGroupName(GroupName) -> result
An implementation may also provide a GroupName deletion function.
8.3 Checksum Computation
The standard Internet checksum algorithm is used for ST: "The
checksum field is the 16-bit one's complement of the one's complement
sum of all 16-bit words in the header. For purposes of computing the
checksum, the value of the checksum field is zero (0)." See
[RFC1071], [RFC1141], and [RFC791] for suggestions for efficient
checksum algorithms.
8.4 Neighbor ST Agent Identification and Information Collection
The STATUS message can be used to collect information about neighbor
ST agents, streams the neighbor supports, and specific targets of
streams the neighbor supports. An agent receiving a STATUS message
provides the requested information via a STATUS-RESPONSE message.
The STATUS message can be used to collect different information from
a neighbor. It can be used to:
o identify ST capable neighbors. If an ST agent wishes to check if
a neighbor is ST capable, it should generate a STATUS message with
an SID which has all its fields set to zero. An agent receiving a
STATUS message with such SID should answer with a STATUS-RESPONSE
containing the same SID, and no other stream information. The
receiving ST agent must answer as soon as possible to aid in Round
Trip Time estimation, see Section 8.5;
o obtain information on a particular stream. If an ST agent wishes to
check a neighbor's general information related to a specific
stream, it should generate a STATUS message containing the stream's
SID. An ST agent receiving such a message, will first check to see
if the stream is known. If not known, the receiving ST agent sends a
STATUS-RESPONSE containing the same SID, and no other stream
information. If the stream is known, the receiving ST agent sends a
STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group
Delgrossi & Berger, Editors Experimental [Page 67]
RFC 1819 ST2+ Protocol Specification August 1995
membership (if any), and as many targets as can be included in a
single message as limited by MTU, see Section 5.1.2. Note that all
targets may not be included in a response to a request for general
stream information. If information on a specific target in a stream
is desired, the mechanism described next should be used.
o obtain information on particular targets in a stream. If an ST agent
wishes to check a neighbor's information related to one or more
specific targets of a specific stream, it should generate a STATUS
message containing the stream's SID and a TargetList parameter
listing the relevant targets. An ST agent receiving such a message,
will first check to see if the stream and target are known. If the
stream is not known, the agent follows the process described above.
If both the stream and targets are known, the agent responds with
STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group
membership (if any), and the requested targets that are known. If
the stream is known but the target is not, the agent responds with a
STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group
membership (if any), but no targets.
The specific formats for STATUS and STATUS-RESPONSE messages are
defined in Section 10.4.12 and Section 10.4.13.
8.5 Round Trip Time Estimation
SCMP is made reliable through use of retransmission when an expected
acknowledgment is not received in a timely manner. Timeout and
retransmission algorithms are implementation dependent and are
outside the scope of this document. However, it must be reasonable
enough not to cause excessive retransmission of SCMP messages while
maintaining the robustness of the protocol. Algorithms on this
subject are described in [WoHD95], [Jaco88], [KaPa87].
Most existing algorithms are based on an estimation of the Round Trip
Time (RTT) between two hosts. With SCMP, if an ST agent wishes to
have an estimate of the RTT to and from a neighbor, it should
generate a STATUS message with an SID which has all its fields set to
zero. An ST agent receiving a STATUS message with such SID should
answer as rapidly as possible with a STATUS-RESPONSE message
containing the same SID, and no other stream information. The time
interval between the send and receive operations can be used as an
estimate of the RTT to and from the neighbor.
8.6 Network MTU Discovery
At connection setup, the application at the origin asks the local ST
agent to create streams with certain QoS requirements. The local ST
agent fills out its network MTU value in the MaxMsgSize parameter in
Delgrossi & Berger, Editors Experimental [Page 68]
RFC 1819 ST2+ Protocol Specification August 1995
the CONNECT message and forwards it to the next-hop ST agents. Each
ST agent in the path checks to see if it's network MTU is smaller
than the one specified in the CONNECT message and, if it is, the ST
agent updates the MaxMsgSize in the CONNECT message to it's network
MTU. If the target application decides to accept the stream, the ST
agent at the target copies the MTU value in the CONNECT message to
the MaxMsgSize field in the ACCEPT message and sends it back to the
application at the origin. The MaxMsgSize field in the ACCEPT message
is the minimum MTU of the intervening networks to that target. If the
application has multiple targets then the minimum MTU of the stream
is the smallest MaxMsgSize received from all the ACCEPT messages. It
is the responsibility of the application to segment its PDUs
according to the minimum MaxMsgSize of the stream since no data
fragmentation is supported during the data transfer phase. If a
particular target's MaxMsgSize is unacceptable to an application, it
may disconnect the target from the stream and assume that the target
cannot be supported. When evaluating a particular target's
MaxMsgSize, the application or the application interface will need to
take into account the size of the ST data header.
8.7 IP Encapsulation of ST
ST packets may be encapsulated in IP to allow them to pass through
routers that don't support the ST Protocol. Of course, ST resource
management is precluded over such a path, and packet overhead is
increased by encapsulation, but if the performance is reasonably
predictable this may be better than not communicating at all.
IP-encapsulated ST packets begin with a normal IP header. Most fields
of the IP header should be filled in according to the same rules that
apply to any other IP packet. Three fields of special interest are:
o Protocol is 5, see [RFC1700], to indicate an ST packet is enclosed,
as opposed to TCP or UDP, for example.
o Destination Address is that of the next-hop ST agent. This may or
may not be the target of the ST stream. There may be an intermediate
ST agent to which the packet should be routed to take advantage of
service guarantees on the path past that agent. Such an intermediate
agent would not be on a directly-connected network (or else IP
encapsulation wouldn't be needed), so it would probably not be
listed in the normal routing table. Additional routing mechanisms,
not defined here, will be required to learn about such agents.
o Type-of-Service may be set to an appropriate value for the service
being requested, see [RFC1700]. This feature is not implemented
uniformly in the Internet, so its use can't be precisely defined
here.
Delgrossi & Berger, Editors Experimental [Page 69]
RFC 1819 ST2+ Protocol Specification August 1995
IP encapsulation adds little difficulty for the ST agent that
receives the packet. However, when IP encapsulation is performed it
must be done in both directions. To process the encapsulated IP
message, the ST agents simply remove the IP header and proceed with
ST header as usual.
The more difficult part is during setup, when the ST agent must
decide whether or not to encapsulate. If the next-hop ST agent is on
a remote network and the route to that network is through a router
that supports IP but not ST, then encapsulation is required. The
routing function provides ST agents with the route and capability
information needed to support encapsulation.
On forwarding, the (mostly constant) IP Header must be inserted and
the IP checksum appropriately updated.
Applications are informed about the number of IP hops traversed on
the path to each target. The IPHops field of the CONNECT message, see
Section 10.4.4, carries the number of traversed IP hops to the target
application. The field is incremented by each ST agent when IP
encapsulation will be used to reach the next-hop ST agent. The number
of IP hops traversed is returned to the origin in the IPHops field of
the ACCEPT message, Section 10.4.1.
When using IP Encapsulation, the MaxMsgSize field will not reflect
the MTU of the IP encapsulated segments. This means that IP
fragmentation and reassembly may be needed in the IP cloud to support
a message of MaxMsgSize. IP fragmentation can only occur when the MTU
of the IP cloud, less IP header length, is the smallest MTU in a
stream's network path.
8.8 IP Multicasting
If an ST agent must use IP encapsulation to reach multiple next-hops
toward different targets, then either the packet must be replicated
for transmission to each next-hop, or IP multicasting may be used if
it is implemented in the next-hop ST agents and in the intervening IP
routers.
When the stream is established, the collection of next-hop ST agents
must be set up as an IP multicast group. The ST agent must allocate
an appropriate IP multicast address (see Section 10.3.3) and fill
that address in the IPMulticastAddress field of the CONNECT message.
The IP multicast address in the CONNECT message is used to inform the
next-hop ST agents that they should join the multicast group to
receive subsequent PDUs. Obviously, the CONNECT message itself must
be sent using unicast. The next-hop ST agents must be able to receive
on the specified multicast address in order to accept the connection.
Delgrossi & Berger, Editors Experimental [Page 70]
RFC 1819 ST2+ Protocol Specification August 1995
If the next-hop ST agent can not receive on the specified multicast
address, it sends a REFUSE message with ReasonCode (BadMcastAddress).
Upon receiving the REFUSE, the upstream agent can choose to retry
with a different multicast address. Alternatively, it can choose to
lose the efficiency of multicast and use unicast delivery.
The following permanent IP multicast addresses have been assigned to
ST:
224.0.0.7 All ST routers (intermediate agents)
224.0.0.8 All ST hosts (agents)
In addition, a block of transient IP multicast addresses, 224.1.0.0 -
224.1.255.255, has been allocated for ST multicast groups. For
instance, the following two functions could be made available:
o AllocateMcastAddr() -> result, McastAddr
o ListenMcastAddr(McastAddr) -> result
o ReleaseMcastAddr(McastAddr) -> result
