diff options
Diffstat (limited to 'doc/rfc/rfc1946.txt')
-rw-r--r-- | doc/rfc/rfc1946.txt | 1179 |
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] + |