summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1946.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1946.txt')
-rw-r--r--doc/rfc/rfc1946.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc1946.txt b/doc/rfc/rfc1946.txt
new file mode 100644
index 0000000..bd7914e
--- /dev/null
+++ b/doc/rfc/rfc1946.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group S. Jackowski
+Request for Comments: 1946 NetManage Incorporated
+Category: Informational May 1996
+
+
+ Native ATM Support for ST2+
+
+Status of This Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ As the demand for networked realtime services grows, so does the need
+ for shared networks to provide deterministic delivery services. Such
+ deterministic delivery services demand that both the source
+ application and the network infrastructure have capabilities to
+ request, setup, and enforce the delivery of the data. Collectively
+ these services are referred to as bandwidth reservation and Quality
+ of Service (QoS).
+
+ The IETF is currently working on an integrated services model to
+ support realtime services on the Internet The IETF has not yet
+ focused on the integration of ATM and its inherent QoS and bandwidth
+ allocation mechanisms for delivery of realtime traffic over shared
+ wires. (ATM hardware and interfaces provide the network
+ infrastructure for the determinitic data delivery, however the host
+ resident protocol stacks and applications need more attention.)
+
+ Current IETF efforts underway in the IP over ATM (ipatm) working
+ group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As
+ such, RFC 1577 and the ATM Forum's Lan Emulation do not provide
+ direct QoS and bandwidth allocation capabilities to network
+ applications. Without providing a mapping of reservations-style QoS
+ to ATM signalling, ATM will remain a 'wire' rather than a shared
+ media infrastructure component.
+
+ This memo describes a working implementation which enables
+ applications to directly invoke ATM services in the following
+ environments:
+
+ - ATM to internet,
+ - internet to ATM, and
+ - internet to internet across ATM.
+
+
+
+
+
+Jackowski Informational [Page 1]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+Table of Contents
+
+ 1.0 Introduction...............................................2
+ 2.0 ST-2 and ST-2+.............................................5
+ 3.0 Implementation Issues for Reservations over ATM............6
+ 3.1 Addressing.................................................6
+ 3.2 Changes to Bandwidth and QoS...............................6
+ 3.3 Multicasting...............................................7
+ 3.4 Receiver Initiated JOIN Requests to Multicast Groups.......8
+ 3.5 Computation of QoS Parameters..............................8
+ 3.6 Use of HELLOs..............................................9
+ 4.0 Reservation Signalling with ATM............................9
+ 4.1 Embedded Reservation Signalling within Q.2931.............10
+ 4.2 In-Band Reservation Signalling............................11
+ 4.3 Dedicated Virtual Circuits for Reservation Signalling.....12
+ 4.4 Reservation Signalling via IP over ATM or LAN Emulation...13
+ 4.5 Summary of Reservation Signalling Options.................14
+ 5.0 Mapping Reservation QoS to ATM QoS........................15
+ 5.1 CPCS-SDU Size Computation.................................16
+ 5.2 PCR Computation...........................................17
+ 5.3 Maximum End to End Transit Delay..........................17
+ 5.4 Maximum Bit Error Rate....................................18
+ 5.5 Accumulated Mean Delay....................................18
+ 5.6 Accumulated Delay Variance (jitter).......................18
+ 6.0 Data Stream Transmission..................................18
+ 7.0 Implementation Considerations and Conclusions.............19
+ 8.0 Security Considerations...................................20
+ 9.0 References................................................20
+ 10.0 Author's Address..........................................21
+
+1.0 Introduction
+
+ The ATM Forum and the IETF seem to approach ATM networking
+ differently.
+
+ The ATM forum appeaars to believe that host systems require no
+ protocols beyond OSI layer 2 to deal with ATM. They define a layer 2
+ API and Q.2931 signaling for all new applications.
+
+ LAN Emulation, a mechanism to make the ATM interface appear to be a
+ LAN/internet, is intended to support 'legacy' network applications.
+ LAN emulation does not provide applications any visibility of the ATM
+ features, nor does it provide a mechanism to allow applications to
+ request specific ATM services. With LAN Emulation, application
+ traffic shares virtual circuits with no policing or guarantees of
+ service. LAN Emulation simply extends LAN characteristics to ATM.
+
+
+
+
+
+Jackowski Informational [Page 2]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ Thus far, the IETF, through RFC 1577[1] treats an ATM network as a
+ wire. The ipatm working group has explicitly left issues of specific
+ QoS handling out of their specifications and working documents.
+ Current approaches do not give the application access to individual
+ virtualcircuits and their associated guaranteed bandwidth and QoS.
+ Instead, all IP traffic between two hosts shares virtual circuits
+ with no granularity assigned to application-specific traffic or QoS
+ requirements.
+
+ Thus, neither LAN Emulation nor RFC 1577 (IP over ATM) uses the
+ features of ATM that make it a unique and desirable technology. RFC
+ 1821 (Integration of Realtime Services in an IP-ATM Network
+ Architecture) [2] raises many of the issues associated with current
+ IETF efforts towards integrating ATM into the Internet, but it does
+ not propose any solutions.
+
+ This document offers a framework for provision of native ATM
+ circuits for applications which require bandwidth guarantees and QoS.
+ It identifies the requirements of a native ATM protocol which is
+ complementary to standard IP and describes one working
+ implementation.
+
+ This document recognizes the fact that it is critical that such a
+ native ATM protocol is consistent in the four topologies described
+ in [2]:
+
+ * Communication across an ATM-only network between two hosts
+ directly connected to the ATM network,
+ * Communication between ATM connected hosts which involves some
+ non-ATM subnets,
+ * Communication between a host on a non-ATM subnet and a host
+ directly connected to ATM,
+ * Communication between two hosts, neither of which has a direct
+ ATM connection, but which may make use of one or more ATM
+ networks for some part of the path.
+
+ That is, to the host systems, the underlying type of network remains
+ transparent even when QoS is involved in internet, ATM, and mixed
+ networking environments. To make this consistency possible, the
+ 'native ATM' protocol must also be:
+
+ * Multicast capable, to optimize transmission overhead and
+ support ATM multipoint facilities,
+ * Routable, to enable transmissions across subnets and
+ internets,
+ * QoS knowledgeable, to take advantage of ATM QoS facilities,
+ * Capable of Bandwidth/QoS Reservation to allocate proper
+ facilities for application traffic as it travels across
+
+
+
+Jackowski Informational [Page 3]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ different types of networks: to effectively extend virtual
+ circuits across internets, and
+ * Capable of policing to ensure proper packet scheduling
+ behavior and to protect guaranteed services at merge points.
+
+ Clearly the protocol should support reservations. Reservation
+ protocols enable creation of 'virtual circuits' with guaranteed
+ bandwidth and QoS on the LAN or internet, and simultaneously can act
+ as signaling mechanisms to routers or ATM interfaces to request
+ provisioning of circuits. Use of a reservation protocol makes
+ characteristics of mixed networks (LANs, internet, ATM, ISDN)
+ transparent to the host systems. That is, a reservation will allow
+ the host or router to provision ATM circuits which match the
+ reservation, but in mixed networks, will allow routers and host to
+ provide bandwidth reservation and QoS across the non-ATM interfaces
+ as well. Effectively, the reservation maps ATM virtual circuits to
+ reservations on subnets and internets.
+
+ This creates a consistent End-to-End, QoS-guaranteed service for
+ mixed network topologies.
+
+ While it is beyond the scope of this document, the same requirements
+ apply to mixed ISDN networks and are currently being explored by the
+ ITU for their H.323, H.223, and T.123 standards.
+
+ Arguably, the reservation protocol that provides this end-to-end
+ guaranteed service should be connection-oriented to facilitate
+ mapping of real connections (ATM or ISDN) with virtual connections on
+ the LAN/internet. [2] points out the shortcomings of IP and RSVP [3]
+ in the ATM environment. Most notable among these are the difficulty
+ of mapping connectionless traffic to ATM connections, the constant
+ softstate refreshes of RSVP (and merging of RESV messages), the
+ receiver orientation of RSVP, and the dependence on IP multicast.
+
+ [6] is an excellent document that proposes solutions to many of the
+ issues raised in [2], but the solutions recommend modifications to
+ the current RSVP and ATM implementations. Recently, issues of
+ incompatibility with the current IP over ATM model, VC explosions due
+ to use of multicast groups and VC explosions due to features
+ associated with heterogeneous receivers suggest that the current
+ version of RSVP may be inappropriate for ATM implementations.
+
+ Since ATM is connection-oriented, hard state, and origin-oriented for
+ transmission, signaling, and multicast, and is bandwidth and QoS
+ knowledgeable, perhaps the simplest and most elegant approach to a
+ native protocol for ATM would include a protocol that shares these
+ characteristics.
+
+
+
+
+Jackowski Informational [Page 4]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ In surveying protocols described in IETF RFCs and Internet Drafts,
+ only two seem to meet these requirements: Experimental Internet
+ Stream Protocol: Version 2 (RFC 1190) [4] and Internet STream
+ Protocol Version 2+ (RFC 1819) [5]; ST2 and ST2+ respectively.
+
+2.0 ST2 and ST2+
+
+ Both ST2 and ST2+ have been given the Internet Protocol Version 5
+ (IPv5) designation. In fact, ST2+ is an updated version of ST2.
+ Both protocols are origin-oriented reservation and multicast
+ protocols that provide bandwidth and QoS guarantees through
+ internets. Unlike IPv4 or IPv6, ST2 and ST2+ are connection-
+ oriented, subscribing to the philosophy that once a connection is
+ established, protocol and routing overhead can be substantially
+ reduced. This carries forward to QoS and Bandwidth Reservation as
+ well, simplifying the implementation of QoS guarantees. THESE
+ PROTOCOLS WERE INTENDED TO COMPLEMENT STANDARD CONNECTIONLESS IP,
+ RECOGNIZING THAT WHILE MOST INTERNET TRAFFIC BENEFITS FROM
+ CONNECTIONLESS NETWORKING, PERFORMANCE AND QoS GUARANTEES COULD BE
+ ACHIEVED MOST EASILY WITH INTERNET CONNECTIONS.
+
+ Both ST2 and ST2+ really consist of two protocols: SCMP and ST. SCMP
+ is analogous to ICMP in that it is the control and signaling
+ protocol, while ST is the low-overhead streaming protocol. ST-2
+ uses standard IP addresses during connection setup, but then reduces
+ header overhead by including a stream identifier in each data packet.
+
+ ST2+ includes simplification of many of the original ST2 features as
+ well as clarification of the ST2 specification. Among these
+ simplifications and clarifications are:
+
+ 1) Much simpler connection setup.
+ 2) Flow Specification independence and consolidation of experimental
+ Flow Specifications.
+ 3) Clarification on the implementation of Groups of Streams.
+ 4) Clarification of leaf-initiated JOINs in multicast trees (several
+ ST2 implementations had done this).
+
+ While there continues to be a dramatic increase in the use of ST2
+ for videoconferencing, video on demand, telemetry applications and
+ networked virtual reality, ST2+ has no commercial implementations
+ and is not yet supported by any router vendors. This is because ST2+
+ was released as an RFC late in the summer of 1995. It is expected
+ that several implementations will appear over the coming months. As
+ such, the approach described in this document applies to both
+ protocols, and, in fact, would be valid for any other similar
+ protocol used to establish 'native' ATM circuits. Since ST2 and ST2+
+ are so similar, this document will refer to 'the ST2 protocols'
+
+
+
+Jackowski Informational [Page 5]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ generically in describing an implementation approach to both. Where
+ particular features of ST2+ are required or affect implementation,
+ 'ST2+ ' will be used specifically.
+
+3.0 Implementation Issues for Reservations over ATM
+
+ As described above, ST is a connection-oriented, hard state, origin-
+ oriented multicast protocol and thus maps fairly well to ATM.
+ However, ST-2 has several features that may be difficult to support
+ in the current version of ATM signaling with Q.2931 and UNI 3.1.
+ Among these are:
+
+ 1) Addressing.
+ 2) Changes to Bandwidth and QoS.
+ 3) Multicasting.
+ 4) Receiver initiated JOINs to multicast groups.
+ 5) Computation of certain QoS parameters.
+ 6) Use of HELLOs.
+
+ The degree of difficulty in supporting these functions is dependent
+ on the signaling mechanism chosen. See Section 4 for descriptions of
+ possible signaling approaches and their respective impact on the
+ features listed above.
+
+3.1 Addressing
+
+ Of course mapping an Internet address to ATM address is always
+ problematic. It would be possible to set up a well known ARP server
+ to resolve the IP addresses of targets. However, the widespread
+ deployment of IP over ATM and LAN emulation in host-based ATM
+ drivers, and the assumption that most host systems will be running
+ some IP applications that do not need specific QoS and bandwidth
+ provisioning, suggests that use of ARP facilities provided by IP
+ over ATM and LAN Emulation is the most obvious choice for address
+ resolution.
+
+ It should be noted that ATMARP returns the ATM address. For some
+ implementations (particularly kernel-based protocols), an NSAP
+ address is also required. Since these addresses are often difficult
+ to get from the ATM network itself in advance of the connection, it
+ may be necessary to invoke out-of-band signaling mechanisms to pass
+ this address, or it may be better to create an NSAP address server.
+
+3.2 Changes to Bandwidth and QoS
+
+ Both ST-2 and ST-2+ allow the origin to dynamically change the QoS
+ and Bandwidth of a particular stream. At this time Q.2931 and UNI
+ 3.1 do not support this feature. Until this capability is available,
+
+
+
+Jackowski Informational [Page 6]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ full support of the SCMP CHANGE message for dedicated ATM circuits
+ (one reservation = one ATM circuit) can only be implemented by
+ tearing down the existing VC for a stream and establishing a new one
+ if efficient use of ATM resources are to be preserved.
+
+ Of course, the CHANGE message can simply be passed across the ATM
+ virtual circuit to the hosts or routers. This would allow the hosts
+ to relax resource requirements locally, and permit routers to relax
+ access to downstream circuits, but the ATM VC itself, would still
+ retain excessive bandwidth.
+
+ In addition, if the implementation allows sharing of virtual circuits
+ by multiple streams, the bandwidth/QoS of individual streams within
+ the VC can be CHANGEd.
+
+3.3 Multicasting
+
+ ST-2 and ST-2+ support origin-oriented multicasting. That is, the
+ origin of a stream explicitly specifies the addresses of the targets
+ it wants involved in the connection. In addition, the origin can Add
+ or drop targets as desired. Aside from receiver-initiated JOINs
+ (discussed in section 3.4), there is a one to one mapping between
+ ST-2 multicast and ATM multipoint connections. Origin-initiated
+ additions can be accomplished through an ADDPARTY, and drops can be
+ done through DROPPARTY.
+
+ A key goal in implementation of a native ATM protocol is to ensure
+ consistent implementation for unicast and multicast data transfers.
+ One difficulty in doing this with ATM Virtual Circuits is the fact
+ that point-to-point circuits are duplex, while multipoint circuits
+ are simplex. This means that for multicast connections to be mapped
+ to multipoint ATM Virtual Circuits, any two-way, end-to-end signaling
+ must be done out of band. An alternative is to let the local
+ reservation agent act as a split/merge point for the connection by
+ establishing point-to-point Virtual Circuits for each member of the
+ multicast group directly connected to the ATM network. For multicast
+ group members not directly connected to the ATM network, traffic can
+ be multicast to the router connected at the edge across a single
+ virtual circuit associated with the reservation.
+
+ Section 4 describes alternative mechanisms for implementing
+ signaling.
+
+ Included in each discussion is the optimal means for mapping
+ multicast to ATM point-to-point or multipoint circuits.
+
+ Note that the fact that ST-2 does not rely on IP multicast is a
+ strong advantage in implementation of a native protocol for ATM. The
+
+
+
+Jackowski Informational [Page 7]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ one-to-one mapping of ST-2 multicast connections to ATM multipoint
+ virtual circuits minimizes the number of circuits required to support
+ large multicast groups.
+
+3.4 Receiver Initiated JOINs to Multicast Groups
+
+ ST-2+ provides an in-band mechanism to permit receivers to join an
+ existing stream. Based on an origin-established authorization level,
+ the JOIN can be refused immediately, can be allowed with notification
+ of the origin, or can be allowed without notifying the origin. This
+ capability is made available through a new SCMP JOIN message. If the
+ receiver knows the IP address of the origin and the Stream ID, he can
+ join the stream if authorized to do so.
+
+ Note that since the JOIN flows from the receiver to the origin, there
+ will be issues in trying to support this feature with Q.2931 and UNI
+ 3.1. The JOIN may have to be sent out of band depending on the
+ signaling mechanism chosen (section 4) because of the uni-directional
+ flow for point to multipoint ATM connections. This is supposed to
+ change with availability of UNI 4.0.
+
+ ST-2 did not support receiver initiated JOINs (unlike ST-2+).
+ However, most implementations created an out-of-band, or SCMP
+ extension to support this facility. Again, depending on the SCMP
+ signaling mechanism chosen, this feature may be difficult to support.
+
+3.5 Computation of QoS Parameters
+
+ The recommended flow specifications (flowspecs) for ST-2 and ST-2+
+ include parameters that are not currently available to ATM virtual
+ circuits through Q.2931 and UNI 3.1. The mapping of packet rate to
+ cell rate, packet delay to cell delay, and other translatable QoS
+ parameters is described in section 5. However, the ST-2 flowspecs
+ also include parameters like accumulated end-to-end delay and
+ accumulated jitter. These parameters assume that the SCMP messages
+ follow the same path as the data. Depending on the signaling
+ mechanism chosen, this may not be true with ATM and thus certain QoS
+ parameters may be rendered useless.
+
+ It should also be noted that since ST-2 connections are simplex, all
+ QoS parameters are specified separately for each direction of data
+ transfer. Thus two connections and two QoS negotiations are required
+ for a duplex connection. To take advantage of the full duplex nature
+ of point-to-point ATM connections, special multiplexing of ST
+ connections would be required by ST-2 agents.
+
+
+
+
+
+
+Jackowski Informational [Page 8]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+3.6 Use of HELLOs
+
+ Both ST-2 and ST-2+ support HELLO messages. HELLOs are intended to
+ assure that the neighboring agent is alive. Failure to respond to a
+ HELLO indicates that the connection is down and that the reservation
+ for that particular link should be freed.
+
+ While the ATM network will notify an ST-2 agent if the network
+ connection is down, there is still the possibility that the
+ connection is intact but that the ST-2 agent itself is down.
+ Knowledge of the neighboring agent's status is increasingly important
+ when multiple ST-2 connections share virtual circuits, when the
+ neighboring agents are routers, and when there are multiple dedicated
+ virtual circuits between agents.
+
+ As such, HELLO is a desirable feature. Note that some signaling
+ schemes (section 4), provide less than optimal support for HELLO.
+
+4.0 Reservation Signaling with ATM
+
+ Use of Permanent Virtual Circuits (PVCs) for reservation signaling
+ presents no problem for ST-2, ST-2+, or RSVP. Each circuit is
+ considered to be a dedicated link to the next hop. If the PVCs are
+ to be shared, reservation protocols can divide and regulate the
+ bandwidth just as they would with any other link type.
+
+ Where ATM connections become more interesting is when the ATM network
+ takes on the role of an extended LAN or internet. To do this,
+ Switched Virtual Circuits are used to establish dynamic connections
+ to various endpoints and routers. The ITU-TS Q.2931 SETUP message is
+ used to request a connection from the network with specific bandwidth
+ and QoS requirements, and a CONNECT message is received by the origin
+ to indicate that connection establishment is complete.
+
+ For IP over ATM and LAN Emulation, SVCs are established between
+ endpoints and data traffic for a given destination shares the SVCs.
+ There is no mechanism to allow specific QoS guarantees for the
+ traffic, nor is there a mechanism to set up virtual circuits with
+ specific bandwidth and QoS for a particular type of traffic. This is
+ what reservation protocols will attempt to do. The goal is to use
+ reservations to request establishment of individual virtual circuits
+ with matching bandwidth and QoS for each reservation. This will
+ guarantee the requirements of the application while taking full
+ advantage of the ATM network's capabilities.
+
+ There are four possible mechanisms to perform reservation signaling
+ over ATM:
+
+
+
+
+Jackowski Informational [Page 9]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ 1) Embedding reservation signaling equivalents within the ATM Q.2931
+ controls.
+ 2) Signaling in-band with the data.
+ 3) Signaling over dedicated signaling VCs.
+ 4) Implicitly sharing existing VCs for IP over ATM or LAN Emulation.
+
+ Note that ATM circuits are not necessarily reliable. As such, the
+ reliability mechanisms provided by SCMP must be maintained to assure
+ delivery of all reservation signaling messages.
+
+4.1 Embedded Reservation Signaling Equivalents within ATM Q.2931
+ Controls
+
+ The basic idea in embedding reservation signaling within the ATM
+ controls is to use the Q.2931 SETUP and CONNECT messages to establish
+ both reservations and dedicated data paths (virtual circuits) across
+ the ATM network. This eliminates the need for dedicated signaling
+ channels, in-band signaling, or out of band mechanisms to communicate
+ between endpoints. Since SETUP and CONNECT include bandwidth and QoS
+ information, the basic concept is sound. In fact, this approach will
+ speed network connection by preventing multiple passes at
+ establishing a reservation and associated connection. This normally
+ results from the fact that most higher layer protocols (network and
+ transport) first require a link to signal their connection
+ requirements. As such, with ATM, the ATM virtual circuit must be
+ established before the network and/or transport protocols can do
+ their own signaling.
+
+ Embedded reservation signaling allows the reservation information to
+ be carried in the SETUP and CONNECT messages, allowing the
+ reservation protocol to do its signaling simultaneously with the ATM
+ signaling.
+
+ [7] describes a clever way of combining the reservation signaling
+ with the ATM control plane signaling for ST-2. This 'simultaneous
+ connection establishment' process will optimize the establishment of
+ circuits and minimize connection setup time while simultaneously
+ eliminating unnecessary network layer signaling in ST-2. To be
+ effective, [7] requires enhancements to Q.2931 signaling and to the
+ ST-2 protocol implementations. In addition, it currently only
+ applies to point-to-point connections and will not work with
+ multipoint largely due to the simplex nature of multipoint
+ communication in current ATM implementations.
+
+ Implementation of multicast for Embedded Reservation Signaling is
+ done as described above: the reservation agent at the edge of the ATM
+ network must create point-to-point virtual circuits for each target
+ that is directly connected to the ATM network, and for each router
+
+
+
+Jackowski Informational [Page 10]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ that supports downstream targets. This ensures two-way signaling
+ between targets and the origin.
+
+ Signaling itself is quite simple:
+
+ CONNECT maps directly to one or more (multicast) Q.2931
+ SETUPs and CONNECTs.
+ ACCEPT maps directly to Q.2931 CONNECTACK.
+ CHANGE/CHANGE REQUEST are not supported.
+ DISCONNECT maps directly to Q.2931 RELEASE.
+ HELLOs are not needed.
+
+ Unfortunately, the flowspec in the reservation protocol CONNECT
+ message cannot be passed across the ATM network in the signaling
+ messages and thus must be regenerated by the receiving agent.
+
+ In addition, User Data, which can be sent in most SCMP messages
+ cannot be supported without substantial changes to current Q.2931
+ signaling.
+
+ One of the additional complexities with embedding the reservation
+ signaling occurs in heterogeneous networks. Since ATM signaling only
+ operates point to point across the ATM network itself, if the
+ endpoints reside on other types of networks or subnets, the routers
+ at the edge of the ATM networks must generate and regenerate
+ endpoint-based signaling messages on behalf of the host reservation
+ agents. In particular, CONNECT and ACCEPT messages and their
+ associated flowspecs must be regenerated. Refer to Section 5 for
+ details on the QoS mappings and on which QoS parameters can be
+ recreated for the generated flowspecs.
+
+ This approach is worth revisiting as an optimal signaling method in
+ pure ATM network environments once ATM signaling capabilities expand.
+
+ However, for heterogeneous networks, other signaling mechanisms may
+ be more appropriate.
+
+4.2 In-Band Reservation Signaling
+
+ In-Band Reservation Signaling is the easiest signaling mechanism to
+ implement. When the applications requests a reservation, the
+ reservation agent simply sets up ATM virtual circuits to the
+ endpoints with the QoS specified in the CONNECT request. When
+ ACCEPTed, all subsequent data transmissions proceed on the virtual
+ circuits.
+
+ Once again, to support multicast, the reservation agent must create
+ individual point-to-point virtual circuits to the targets which are
+
+
+
+Jackowski Informational [Page 11]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ directly connected to the ATM network, as well as to routers which
+ can access downstream targets.
+
+ Since signaling is done in-band, all reservation signaling messages
+ can be passed between agents. However, some minimal additional
+ bandwidth must be allocated in the Q.2931 SETUP to allow for the
+ signaling messages themselves.
+
+ Note that the primary disadvantage to In-Band Reservation Signaling
+ is the fact that it does not make use of the multipoint capabilities
+ of ATM and will thus overreserve ATM network bandwidth and create a
+ larger than necessary number of virtual circuits.
+
+4.3 Dedicated Reservation Signaling Virtual Circuits
+
+ One mechanism that can be used to take advantage of the full data
+ transmission capabilities of ATM networks is to use Dedicated Virtual
+ Circuits for reservation signaling. This guarantees a two-way
+ signaling pipe between the endpoints in a connection while enabling
+ the data transmission to take advantage of the multipoint
+ capabilities of ATM. Data and Signaling are done over separate
+ virtual circuits.
+
+ When an application requests a reservation, the reservation agent
+ reviews the list of targets in the CONNECT request. For any targets
+ which have no current signaling virtual circuits established, the
+ agent establishes UBR (unspecified bit rate) virtual circuits and
+ forwards the CONNECT message to the targets over these virtual
+ circuits. ATMARP is used to resolve any endpoint addresses. For any
+ targets for which there already exist signaling virtual circuits, the
+ agent simply forwards the CONNECT message over the existing virtual
+ circuit.
+
+ Once an ACCEPT message is received, the agent issues a Q.2931 SETUP
+ to the associated target. Upon receipt of a CONNECTACK, data can
+ begin to flow. As additional ACCEPTs are received, the Q.2931
+ ADDPARTY message is used to add a target to the multicast and
+ multipoint connection. Depending on the cause of any ADDPARTY
+ failure, the agent may attempt to establish a dedicated point-to-
+ point virtual circuit to complete the multicast group.
+
+ DISCONNECT requests result in Q.2931 DROPPARTY messages and will
+ cause a member to be dropped from a multicast and multipoint
+ connection. When all targets are dropped from a multipoint
+ connection, a RELEASE can be issued to take down the virtual circuit.
+
+ Signaling virtual circuits are shared among reservations while data
+ circuits are dedicated to a particular reservation. Once all
+
+
+
+Jackowski Informational [Page 12]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ reservations to a given endpoint are terminated, the signaling
+ virtual circuit to that endpoint can be RELEASEd.
+
+ Note that this approach would allow the NSAP address to be passed as
+ user data in the ACCEPT message to enable a kernel-based reservation
+ protocol to establish the dedicated data circuit. In addition,
+ because the connectivity to the endpoint is identical to that of the
+ data circuit, this approach assures the fact that accumulated
+ information in the flowspecs retains it validity.
+
+4.4 Reservation Signaling via IP over ATM or LAN Emulation
+
+ As described in the previous section, it would be possible to set up
+ unique SVCs for SCMP signaling, however, since the streaming,
+ connection-oriented data transport offered by ST-2 is intended to be
+ complementary to IP and other connectionless protocol
+ implementations, it would be simpler and more elegant to simply use
+ classical IP over ATM (RFC 1577) mechanisms, or to use LAN Emulation.
+ The widespread deployment of IP over ATM and LAN emulation in host-
+ based ATM drivers, and the assumption that most host systems will be
+ running applications that do not need specific QoS and bandwidth
+ provisioning, makes this the most straightforward (if not performance
+ optimal) solution for signaling. Once an end-to-end acceptance of a
+ reservation request is completed via normal LAN or IP transmission,
+ then a unique direct virtual circuit can be established for each data
+ flow.
+
+ If LAN Emulation is used, as long as the ST-2 implementation allows
+ for different paths for SCMP and data, there would be no changes to
+ the signaling mechanisms employed by the reservation agent.
+
+ For IP over ATM, all SCMP messages would be encapsulated in IP as
+ described in both RFC 1190 and RFC 1819. This is required because
+ current ATM drivers will not accept Ipv5 packets, and most drivers do
+ not provide direct access to the shared signaling virtual circuits
+ used for IP.
+
+ In either case, LAN Emulation or IP over ATM, the reservation agent
+ would handle SCMP messages as it normally does. However, once the
+ first ACCEPT is received for a reservation request, a dedicated
+ virtual circuit is established for the data flow. Subsequent ACCEPTs
+ will result in the use of ADDPARTY to add multicast targets to the
+ multipoint virtual circuit. In fact, processing of
+ multipoint/multicast is identical to that described in section 4.3.
+
+ Once again, the use of an out-of-band signaling mechanism makes it
+ possible to carry the NSAP address of the target in the ACCEPT
+ message.
+
+
+
+Jackowski Informational [Page 13]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ One potential drawback to using LAN Emulation or SCMP messages
+ encapsulated in IP over ATM, is the fact that there is no guarantee
+ that the connectivity achieved to reach the target via signaling has
+ any relationship to the data path. This means that accumulated
+ values in the flowspec may be rendered useless.
+
+ In addition, it is possible that the targets will actually reside
+ outside the ATM network. That is, there may be no direct ATM access
+ to the Targets and it may be difficult to identify ATM addresses of
+ the associated ATM connected routers. This approach will involve
+ some additional complexity in routing to the targets. However, since
+ ST-2 is intended to run with IP, if ATM vendors would accept IPv5
+ packets or would allow direct access to the IP over ATM signaling
+ virtual circuits, this approach would be optimal in minimizing the
+ number of virtual circuits required.
+
+4.5 Summary of Reservation Signaling Approaches
+
+ Embedded Reservation Signaling (section 4.1) is ideal for homogeneous
+ ATM connections, but requires extensions to existing ATM signaling
+ to support multipoint connections. In-Band Reservation Signaling
+ (section 4.2) is the easiest to implement, but cannot employ
+ multipoint connections either.
+
+ Perhaps the simplest way to do this is similar to what is suggested
+ in [6]: separate the reservation signaling from the actual data
+ flows, mapping the data flows directly to ATM circuits while doing
+ the signaling separately.
+
+ While there is significant complexity in doing this for IP traffic
+ and RSVP, the ST2 protocols lend themselves to this quite well. In
+ fact, because SCMP reservation signaling results in streaming,
+ multicast connections, the 'Shortcut' mechanism described in [6],
+ which can bypass routers where direct ATM connections are possible,
+ is automatically available to ST2 streams.
+
+ Using Reservation Signaling over LAN Emulation or IP over ATM
+ (section 4.4) is one multipoint-capable approach to implement in
+ hosts since most ATM drivers shipping today provide both IP over ATM
+ and LAN Emulation, as well as associated address resolution
+ mechanisms. However, it is not complete in its ability to accurately
+ depict flowspec parameters or to resolve host ATM addresses. In
+ addition, to be optimal, ATM vendors would either have to support
+ IPv5 in their drivers or allow direct access to the IP signaling
+ virtual circuits. Thus the current ideal approach to implementation
+ of the ST2 protocols over ATM is to use shared Dedicated Reservation
+ Signaling Virtual Circuits (section 4.3) for signaling of
+ reservations, and then to establish appropriate multipoint ATM
+
+
+
+Jackowski Informational [Page 14]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ virtual circuits for the data flows.
+
+5.0 Mapping of Reservation QoS to ATM QoS
+
+ QoS negotiation in ST-2 (and ST-2+) is done via a two-way
+ negotiation.
+
+ The origin proposes a QoS for the connection in a Flow Specification
+ (Flowspec) associated with the CONNECT message. Most of the
+ network-significant QoS parameters in the Flowspec include both a
+ minimum and a desired value. Each ST agent along the path to the
+ Target validates its ability to provide the specified QoS (at least
+ the minimum value for each), updates certain values in the Flowspec,
+ and propagates the CONNECT until it reaches the Target. The Target
+ can either ACCEPT the Flowspec or REFUSE it if it cannot meet at
+ least the minimum QoS requirements. Negotiation takes place as part
+ of the process in that the Target can specify changes to the desired
+ QoS values as long as the new value meets at least the minimum
+ requirements specified by the Origin system. In addition, both the
+ Target and the Origin can assess actual network performance by
+ reviewing the values that are accumulated along the path.
+
+ The primary Reservation QoS parameters that impact an ATM network
+ are:
+
+ST-2 (RFC 1190) ST-2+ (RFC 1819)
+
+Desired PDU Bytes, Desired Message Size,
+Limit on PDU Bytes (minimum). Limit on Message Size.
+
+Desired PDU Rate, Desired Rate,
+Limit on PDU Rate (minimum). Limit on Rate.
+Minimum Transmission Rate in Bytes.
+
+Limit on Delay (maximum). Desired Delay,
+ Limit on Delay.
+Maximum Bit Error Rate.
+
+Accumulated Delay.
+Accumulated Delay Variance (Jitter).
+
+Q.2931 ATM signaling offers the following QoS parameters:
+
+- Cumulative Transit Delay,
+- Maximum End to End Transit Delay.
+
+- Forward Peak Cell Rate (PCR),
+- Backward Peak Cell Rate (PCR).
+
+
+
+Jackowski Informational [Page 15]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+- Forward Maximum CPCS-SDU size,
+- Backward Maximum CPCS-SDU size.
+
+- Forward QoS Class,
+- Backward QoS Class.
+
+- B-LLI (one byte user protocol information).
+
+ As previously noted, reservation protocols (ST and RSVP) make QoS
+ reservations in one direction only. Thus, depending on the type of
+ signaling used (see Section 4), the 'Backward' ATM parameters may not
+ be useful. In particular, if Multipoint ATM connections are used to
+ map multicast reservations, these parameters are not available.
+
+ However, it would be possible to implement a multiplexing scheme to
+ enable reservations to share bi-directional point-to-point ATM
+ connections if the reservation agent creates a split/merge point at
+ the ATM boundary and sets up only point-to-point VC connections to
+ targets.
+
+ The CPCS-SDU parameters are AAL Parameters which are used by the AAL
+ entity to break packets into cells. As such, these parameters are
+ not modified by the network and could conceivably be used for
+ additional end-to-end signaling, along with the B-LLI.
+
+ Finally, QoS Class is somewhat limited in its use and implementation.
+ While IP over ATM recommends use of Class 0 (Unspecified QoS), this
+ is not sufficient for guaranteed connections. Instead, Class 1 with
+ CLP=0 will provide at least minimum QoS services for the traffic.
+
+5.1 CPCS-SDU Size Computation
+
+ The CPCS-SDU size computation is the easiest QoS mapping. Since ST-2
+ does not require a Service Specific Convergence Sublayer (SSCS), if
+ AAL 5 is used, the ST packet size plus 8 bytes (for the AAL 5
+ Trailer) will be the CPCS-SDU size. Note that the ST-2 packet size
+ also includes an 8-byte header for ST-2. Thus the CPCS-SDU size is:
+
+ CPCS-SDUsize = PDUbytes + 8 + 8.
+
+ For ST-2+, the header is larger than for ST-2, so the CPCS-SDU size
+ is:
+
+ CPCS-SDUsize = PDUbytes + 12 + 8.
+
+
+
+
+
+
+
+Jackowski Informational [Page 16]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+5.2 PCR Computation
+
+ The Peak Cell Rate (PCR) computation is only slightly more complex.
+ The PCR will be the peak packet rate divided by the ATM payload size.
+
+ Since PDU rates in ST-2 are specified in tenths of packets per
+ second, AAL 5 requires an 8 byte trailer, and the ATM payload size is
+ 48 bytes, the computation for PCR proceeds as follows:
+
+ The requested maximum byte transmission rate for ST-2 is:
+
+ PDUbytes * PDUrate * 10.
+
+ Accounting for the AAL 5 and ST headers, the maximum byte rate
+ is:
+
+ Bytes per second = (PDUbytes + 8 + 8) * PDUrate * 10.
+
+ Translating into cells and eliminating the possibility of a
+ fractional PDU:
+
+ PCR = ((PDUbytes + 8 + 8 + 48) / 48) * PDUrate * 10.
+
+ For ST-2+, not only is the header size 12 bytes, but the Rate is in
+ messages per second, not tenths of packets per second. Thus, the PCR
+ for ST-2+ is:
+
+ PCR = ((PDUbytes + 12 + 8 + 48) / 48) * PDUrate.
+
+5.3 Maximum End to End Transit Delay.
+
+ The End to End Transit Delay is a little more complex. The
+ requested end to end delay must account for not only the PDU size as
+ requested by the user, but the additional 8-byte AAL 5 header as
+ well. The translation of the user-requested LimitOn Delay is
+ preserved as long as the delay computation is based on the CPCS-SDU
+ size instead of the PDU size.
+
+ In addition to the end to end delay introduced by the ATM network,
+ there is additional delay created by the fragmentation of packets.
+ Reassembly of these packets can only be accomplished at the rate at
+ which they are received. The time (in milliseconds) required to
+ receive a cell (inter-cell arrival time) is:
+
+ T = 1000 / PCR.
+
+
+
+
+
+
+Jackowski Informational [Page 17]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ The number of cells in a CPCS-SDU is:
+
+ C = (CPCS-SDUsize + 48) / 48.
+
+ Thus the delay for a packet is:
+
+ LimitonDelay = (C - 1) * T + MaxCellTransitDelay.
+
+ Therefore, the requested Maximum End to End Transit delay is:
+
+ MaxCellTransitDelay = Limiton Delay - (C-1) * T.
+
+5.4 Maximum Bit Error Rate
+
+ Q.2931 signaling does not offer the ability to directly specify the
+ requested bit error rate or a corresponding cell error rate.
+ Instead, this service is supposed to be offered through selection of
+ QoS class.
+
+ Since these classes have few actual implementations, at this time,
+ there is no effective mapping for bit error rate.
+
+5.5 Accumulated Mean Delay
+
+ ST allows accumulation of the Mean Delay generated by each ST agent
+ node and intervening circuits. With an ATM circuit each agent should
+ factor in the overhead of the ATM connection. The delay associated
+ with the ATM circuit is reflected in the Q.2931 CONNECT message as
+ the Cummulative Transit Delay. Since this is a cell-based
+ computation, the delay experienced for an ST packet, including the
+ CPCS-SDU header and ST header is, as computed in Section 5.3:
+
+ Delay = (C - 1) * T + CummulativeTransit Delay.
+
+5.6 Accumulated Delay Variance (Jitter)
+
+ Cell Delay Variance is not currently available as a Q.2931 parameter.
+
+ Thus, we can assume that the reassembly of cells into packets will
+ be consistent, since the cell transmission rate should be constant
+ for each packet. As such, except as noted by the specific ATM
+ service, the ST agent should use its standard mechanisms for tracking
+ packet arrival times and use this for Accumulated Delay Variance.
+
+6.0 Data Stream Transmission
+
+ Once virtual circuits for data transmission are established though
+ one of the mechanisms described in section 4, the ST data must be
+
+
+
+Jackowski Informational [Page 18]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+ transmitted over the connection. RFC 1483 describes mechanisms for
+ encapsulating packet transmissions over AAL5. While the LLC
+ encapsulation could be used, it is not necessary. If it is used, the
+ computations in section 5 should be redone to include the LLC headers
+ in addition to the AAL5 trailer currently used. These new values
+ should be substituted for the QoS values in the SETUP message.
+
+ Instead, ST data packets can be encapsulated in standard AAL5 format
+ with an 8 byte trailer and sent directly over the data virtual
+ circuit. The mechanisms for computing the QoS values in the SETUP
+ message are described in section 5.
+
+7.0 Implementation Experience and Conclusions
+
+ All of the signaling mechanisms described in Section 4 were
+ implemented and tested in a mixed ATM network/routed LAN environment.
+
+ Initially it appeared that the best approach was to do signaling via
+ IP over ATM or LANE. However, because it required IP encapsulation
+ of the SCMP packets (for IP over ATM), and because some applications
+ use the accumulated values in the flowspecs (which are not guaranteed
+ to be accurate in LANE and IP/ATM), using virtual circuits dedicated
+ to SCMP signaling turned out to be the best implementation for
+ taking full advantage of the ATM features.
+
+ Also, the issue of mapping ATM address to E.164 NSAP addresses was
+ resolved through an external signaling mechanism (the User Data field
+ of the ST-2 CONNECT and ACCEPT messages). It appears that ATM
+ vendors need to implement a consistent addressing mechanism
+ throughout their interfaces.
+
+ From a performance point of view, using ST over ATM provided more
+ than triple the performance of raw IP. The differences became
+ increasingly clear as more simultaneous applications were run. This
+ resulted in dedicated virtual circuits for the ST traffic while the
+ IP traffic suffered (saw inconsistent performance) over shared
+ circuits. Even more dramatic were results in mixed network
+ environments where all traffic shared the same LAN/router
+ connections, and, when both IP and ST traffic was sent, the ST
+ traffic maintained its quality while the IP traffic saw increasing
+ variation in performance.
+
+ Clearly, using a connection-oriented, origin-oriented reservation
+ protocol to provide consistent end-to-end guaranteed QoS and
+ bandwidth in mixed ATM/internet environments is not only feasible, it
+ results in dramatic performance and quality improvements for
+ transmission of realtime traffic.
+
+
+
+
+Jackowski Informational [Page 19]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+8.0 Security Considerations
+
+ This memo raises no security considerations. However, with their
+ connection-oriented and origin controlled natures, ST-2 and ST-2+
+ lend themselves to better internet security. Discussion of this is
+ beyond the scope of this document.
+
+9.0 References
+
+ [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett
+ Packard Laboratories, December, 1993.
+
+ [2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
+ of Real-time Services in an IP-ATM network Architecture", RFC
+ 1821, August 1995.
+
+ [3] Braden, R., Zhang, L., Estrin, D., Herzog, S., and S. Jamin,
+ "Resource ReSerVation Protocol (RSVP Version 1 Functional
+ Specification", Work in Progress, November 1995.
+
+ [4] Topolcic, C., "Experimental Internet Stream Protocol: Version 2
+ (ST-II)", RFC 1190, October 1990.
+
+ [5] DelGrossi, L., and L. Berger, "Internet STream Protocol Version
+ 2+", RFC 1819, July 1995.
+
+ [6] V. Firoiu, R. Guerin, D. Kandlur, A. Birman "Provisioning of
+ RSVP-based Services over a Large ATM Network', IBM T.J. Watson
+ Research Center, October 1995.
+
+ [7] S. Damaskos, A. Anastassios Gavras, "Connection Oriented
+ Protocols over ATM: A Case Study", German National Research
+ Corporation for Mathematics and Data Processing (GMD) and
+ Research Centre for Open Communications Systems (FOKUS), February
+ 1994.
+
+ [8] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
+ Layer 5", RFC 1483, July 1993.
+
+ [9] M. Graf, T. Kober, H. Stuttgen, "ST-II over ATM Implementation
+ Issues", IBM European Networking Center, October 1995.
+
+
+
+
+
+
+
+
+
+
+Jackowski Informational [Page 20]
+
+RFC 1946 Native ATM Support for ST2+ May 1996
+
+
+10.0 Author's Address
+
+ Steve Jackowski
+ NetManage Incorporated
+ 269 Mt. Hermon Road, Suite 201
+ Scotts Valley, Ca 95066
+
+ Phone: (408) 439-6834
+ Fax: (408) 438-5115
+ EMail: Stevej@NetManage.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jackowski Informational [Page 21]
+