RFC relevance of circuits

As per Relevance of the word circuits, we have this rfc below:

Network Working Group S.
Request for Comments: 1946 NetManage
Category: Informational May 1996

Native ATM Support for ST2+

Status of This

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

As the demand for networked realtime services grows, so does the
for shared networks to provide deterministic delivery services.
deterministic delivery services demand that both the
application and the network infrastructure have capabilities
request, setup, and enforce the delivery of the data.
these services are referred to as bandwidth reservation and
of Service (QoS).

The IETF is currently working on an integrated services model
support realtime services on the Internet The IETF has not
focused on the integration of ATM and its inherent QoS and
allocation mechanisms for delivery of realtime traffic over
wires. (ATM hardware and interfaces provide the
infrastructure for the determinitic data delivery, however the
resident protocol stacks and applications need more attention.)

Current IETF efforts underway in the IP over ATM (ipatm)
group rely on intserv, rsvp and ST2 to address QoS issues for ATM.
such, RFC 1577 and the ATM Forum's Lan Emulation do not
direct QoS and bandwidth allocation capabilities to
applications. Without providing a mapping of reservations-style
to ATM signalling, ATM will remain a 'wire' rather than a
media infrastructure component

This memo describes a working implementation which
applications to directly invoke ATM services in the
environments

- ATM to internet
- internet to ATM,
- internet to internet across ATM

Jackowski Informational [Page 1]

RFC 1946 Native ATM Support for ST2+ May 1996

Table of

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

The ATM Forum and the IETF seem to approach ATM
differently

The ATM forum appeaars to believe that host systems require
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
LAN/internet, is intended to support 'legacy' network applications
LAN emulation does not provide applications any visibility of the
features, nor does it provide a mechanism to allow applications
request specific ATM services. With LAN Emulation,
traffic shares virtual circuits with no policing or guarantees
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
wire. The ipatm working group has explicitly left issues of
QoS handling out of their specifications and working documents
Current approaches do not give the application access to
virtualcircuits and their associated guaranteed bandwidth and QoS
Instead, all IP traffic between two hosts shares virtual
with no granularity assigned to application-specific traffic or
requirements

Thus, neither LAN Emulation nor RFC 1577 (IP over ATM) uses
features of ATM that make it a unique and desirable technology.
1821 (Integration of Realtime Services in an IP-ATM
Architecture) [2] raises many of the issues associated with
IETF efforts towards integrating ATM into the Internet, but it
not propose any solutions

This document offers a framework for provision of native
circuits for applications which require bandwidth guarantees and QoS
It identifies the requirements of a native ATM protocol which
complementary to standard IP and describes one
implementation

This document recognizes the fact that it is critical that such
native ATM protocol is consistent in the four topologies
in [2]:

* Communication across an ATM-only network between two
directly connected to the ATM network
* Communication between ATM connected hosts which involves
non-ATM subnets
* Communication between a host on a non-ATM subnet and a
directly connected to ATM
* Communication between two hosts, neither of which has a
ATM connection, but which may make use of one or more
networks for some part of the path

That is, to the host systems, the underlying type of network
transparent even when QoS is involved in internet, ATM, and
networking environments. To make this consistency possible,
'native ATM' protocol must also be

* Multicast capable, to optimize transmission overhead
support ATM multipoint facilities
* Routable, to enable transmissions across subnets
internets
* QoS knowledgeable, to take advantage of ATM QoS facilities
* Capable of Bandwidth/QoS Reservation to allocate
facilities for application traffic as it travels

Jackowski Informational [Page 3]

RFC 1946 Native ATM Support for ST2+ May 1996

different types of networks: to effectively extend
circuits across internets,
* Capable of policing to ensure proper packet
behavior and to protect guaranteed services at merge points

Clearly the protocol should support reservations.
protocols enable creation of 'virtual circuits' with
bandwidth and QoS on the LAN or internet, and simultaneously can
as signaling mechanisms to routers or ATM interfaces to
provisioning of circuits. Use of a reservation protocol
characteristics of mixed networks (LANs, internet, ATM, ISDN
transparent to the host systems. That is, a reservation will
the host or router to provision ATM circuits which match
reservation, but in mixed networks, will allow routers and host
provide bandwidth reservation and QoS across the non-ATM
as well. Effectively, the reservation maps ATM virtual circuits
reservations on subnets and internets

This creates a consistent End-to-End, QoS-guaranteed service
mixed network topologies

While it is beyond the scope of this document, the same
apply to mixed ISDN networks and are currently being explored by
ITU for their H.323, H.223, and T.123 standards

Arguably, the reservation protocol that provides this end-to-
guaranteed service should be connection-oriented to
mapping of real connections (ATM or ISDN) with virtual connections
the LAN/internet. [2] points out the shortcomings of IP and RSVP [3]
in the ATM environment. Most notable among these are the
of mapping connectionless traffic to ATM connections, the
softstate refreshes of RSVP (and merging of RESV messages),
receiver orientation of RSVP, and the dependence on IP multicast

[6] is an excellent document that proposes solutions to many of
issues raised in [2], but the solutions recommend modifications
the current RSVP and ATM implementations. Recently, issues
incompatibility with the current IP over ATM model, VC explosions
to use of multicast groups and VC explosions due to
associated with heterogeneous receivers suggest that the
version of RSVP may be inappropriate for ATM implementations

Since ATM is connection-oriented, hard state, and origin-oriented
transmission, signaling, and multicast, and is bandwidth and
knowledgeable, perhaps the simplest and most elegant approach to
native protocol for ATM would include a protocol that shares
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
Stream Protocol: Version 2 (RFC 1190) [4] and Internet
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
protocols that provide bandwidth and QoS guarantees
internets. Unlike IPv4 or IPv6, ST2 and ST2+ are connection
oriented, subscribing to the philosophy that once a connection
established, protocol and routing overhead can be
reduced. This carries forward to QoS and Bandwidth Reservation
well, simplifying the implementation of QoS guarantees.
PROTOCOLS WERE INTENDED TO COMPLEMENT STANDARD CONNECTIONLESS IP
RECOGNIZING THAT WHILE MOST INTERNET TRAFFIC BENEFITS
CONNECTIONLESS NETWORKING, PERFORMANCE AND QoS GUARANTEES COULD
ACHIEVED MOST EASILY WITH INTERNET CONNECTIONS

Both ST2 and ST2+ really consist of two protocols: SCMP and ST.
is analogous to ICMP in that it is the control and
protocol, while ST is the low-overhead streaming protocol. ST-2
uses standard IP addresses during connection setup, but then
header overhead by including a stream identifier in each data packet

ST2+ includes simplification of many of the original ST2 features
well as clarification of the ST2 specification. Among
simplifications and clarifications are

1) Much simpler connection setup
2) Flow Specification independence and consolidation of
Flow Specifications
3) Clarification on the implementation of Groups of Streams
4) Clarification of leaf-initiated JOINs in multicast trees (
ST2 implementations had done this).

While there continues to be a dramatic increase in the use of ST
for videoconferencing, video on demand, telemetry applications
networked virtual reality, ST2+ has no commercial
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
that several implementations will appear over the coming months.
such, the approach described in this document applies to
protocols, and, in fact, would be valid for any other
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.
particular features of ST2+ are required or affect implementation
'ST2+ ' will be used specifically

3.0 Implementation Issues for Reservations over

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
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
on the signaling mechanism chosen. See Section 4 for descriptions
possible signaling approaches and their respective impact on
features listed above

3.1

Of course mapping an Internet address to ATM address is
problematic. It would be possible to set up a well known ARP
to resolve the IP addresses of targets. However, the
deployment of IP over ATM and LAN emulation in host-based
drivers, and the assumption that most host systems will be
some IP applications that do not need specific QoS and
provisioning, suggests that use of ARP facilities provided by
over ATM and LAN Emulation is the most obvious choice for
resolution

It should be noted that ATMARP returns the ATM address. For
implementations (particularly kernel-based protocols), an
address is also required. Since these addresses are often
to get from the ATM network itself in advance of the connection,
may be necessary to invoke out-of-band signaling mechanisms to
this address, or it may be better to create an NSAP address server

3.2 Changes to Bandwidth and

Both ST-2 and ST-2+ allow the origin to dynamically change the
and Bandwidth of a particular stream. At this time Q.2931 and
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
(one reservation = one ATM circuit) can only be implemented
tearing down the existing VC for a stream and establishing a new
if efficient use of ATM resources are to be preserved

Of course, the CHANGE message can simply be passed across the
virtual circuit to the hosts or routers. This would allow the
to relax resource requirements locally, and permit routers to
access to downstream circuits, but the ATM VC itself, would
retain excessive bandwidth

In addition, if the implementation allows sharing of virtual
by multiple streams, the bandwidth/QoS of individual streams
the VC can be CHANGEd

3.3

ST-2 and ST-2+ support origin-oriented multicasting. That is,
origin of a stream explicitly specifies the addresses of the
it wants involved in the connection. In addition, the origin can
or drop targets as desired. Aside from receiver-initiated
(discussed in section 3.4), there is a one to one mapping
ST-2 multicast and ATM multipoint connections. Origin-
additions can be accomplished through an ADDPARTY, and drops can
done through DROPPARTY

A key goal in implementation of a native ATM protocol is to
consistent implementation for unicast and multicast data transfers
One difficulty in doing this with ATM Virtual Circuits is the
that point-to-point circuits are duplex, while multipoint
are simplex. This means that for multicast connections to be
to multipoint ATM Virtual Circuits, any two-way, end-to-end
must be done out of band. An alternative is to let the
reservation agent act as a split/merge point for the connection
establishing point-to-point Virtual Circuits for each member of
multicast group directly connected to the ATM network. For
group members not directly connected to the ATM network, traffic
be multicast to the router connected at the edge across a
virtual circuit associated with the reservation

Section 4 describes alternative mechanisms for
signaling

Included in each discussion is the optimal means for
multicast to ATM point-to-point or multipoint circuits

Note that the fact that ST-2 does not rely on IP multicast is
strong advantage in implementation of a native protocol for ATM.

Jackowski Informational [Page 7]

RFC 1946 Native ATM Support for ST2+ May 1996

one-to-one mapping of ST-2 multicast connections to ATM
virtual circuits minimizes the number of circuits required to
large multicast groups

3.4 Receiver Initiated JOINs to Multicast

ST-2+ provides an in-band mechanism to permit receivers to join
existing stream. Based on an origin-established authorization level
the JOIN can be refused immediately, can be allowed with
of the origin, or can be allowed without notifying the origin.
capability is made available through a new SCMP JOIN message. If
receiver knows the IP address of the origin and the Stream ID, he
join the stream if authorized to do so

Note that since the JOIN flows from the receiver to the origin,
will be issues in trying to support this feature with Q.2931 and
3.1. The JOIN may have to be sent out of band depending on
signaling mechanism chosen (section 4) because of the uni-
flow for point to multipoint ATM connections. This is supposed
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
extension to support this facility. Again, depending on the
signaling mechanism chosen, this feature may be difficult to support

3.5 Computation of QoS

The recommended flow specifications (flowspecs) for ST-2 and ST-2+
include parameters that are not currently available to ATM
circuits through Q.2931 and UNI 3.1. The mapping of packet rate
cell rate, packet delay to cell delay, and other translatable
parameters is described in section 5. However, the ST-2
also include parameters like accumulated end-to-end delay
accumulated jitter. These parameters assume that the SCMP
follow the same path as the data. Depending on the
mechanism chosen, this may not be true with ATM and thus certain
parameters may be rendered useless

It should also be noted that since ST-2 connections are simplex,
QoS parameters are specified separately for each direction of
transfer. Thus two connections and two QoS negotiations are
for a duplex connection. To take advantage of the full duplex
of point-to-point ATM connections, special multiplexing of
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

Both ST-2 and ST-2+ support HELLO messages. HELLOs are intended
assure that the neighboring agent is alive. Failure to respond to
HELLO indicates that the connection is down and that the
for that particular link should be freed

While the ATM network will notify an ST-2 agent if the
connection is down, there is still the possibility that
connection is intact but that the ST-2 agent itself is down
Knowledge of the neighboring agent's status is increasingly
when multiple ST-2 connections share virtual circuits, when
neighboring agents are routers, and when there are multiple
virtual circuits between agents

As such, HELLO is a desirable feature. Note that some
schemes (section 4), provide less than optimal support for HELLO

4.0 Reservation Signaling with

Use of Permanent Virtual Circuits (PVCs) for reservation
presents no problem for ST-2, ST-2+, or RSVP. Each circuit
considered to be a dedicated link to the next hop. If the PVCs
to be shared, reservation protocols can divide and regulate
bandwidth just as they would with any other link type

Where ATM connections become more interesting is when the ATM
takes on the role of an extended LAN or internet. To do this
Switched Virtual Circuits are used to establish dynamic
to various endpoints and routers. The ITU-TS Q.2931 SETUP message
used to request a connection from the network with specific
and QoS requirements, and a CONNECT message is received by the
to indicate that connection establishment is complete

For IP over ATM and LAN Emulation, SVCs are established
endpoints and data traffic for a given destination shares the SVCs
There is no mechanism to allow specific QoS guarantees for
traffic, nor is there a mechanism to set up virtual circuits
specific bandwidth and QoS for a particular type of traffic. This
what reservation protocols will attempt to do. The goal is to
reservations to request establishment of individual virtual
with matching bandwidth and QoS for each reservation. This
guarantee the requirements of the application while taking
advantage of the ATM network's capabilities

There are four possible mechanisms to perform reservation
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,
reliability mechanisms provided by SCMP must be maintained to
delivery of all reservation signaling messages

4.1 Embedded Reservation Signaling Equivalents within ATM Q.2931

The basic idea in embedding reservation signaling within the
controls is to use the Q.2931 SETUP and CONNECT messages to
both reservations and dedicated data paths (virtual circuits)
the ATM network. This eliminates the need for dedicated
channels, in-band signaling, or out of band mechanisms to
between endpoints. Since SETUP and CONNECT include bandwidth and
information, the basic concept is sound. In fact, this approach
speed network connection by preventing multiple passes
establishing a reservation and associated connection. This
results from the fact that most higher layer protocols (network
transport) first require a link to signal their
requirements. As such, with ATM, the ATM virtual circuit must
established before the network and/or transport protocols can
their own signaling

Embedded reservation signaling allows the reservation information
be carried in the SETUP and CONNECT messages, allowing
reservation protocol to do its signaling simultaneously with the
signaling

[7] describes a clever way of combining the reservation
with the ATM control plane signaling for ST-2. This '
connection establishment' process will optimize the establishment
circuits and minimize connection setup time while
eliminating unnecessary network layer signaling in ST-2. To
effective, [7] requires enhancements to Q.2931 signaling and to
ST-2 protocol implementations. In addition, it currently
applies to point-to-point connections and will not work
multipoint largely due to the simplex nature of
communication in current ATM implementations

Implementation of multicast for Embedded Reservation Signaling
done as described above: the reservation agent at the edge of the
network must create point-to-point virtual circuits for each
that is directly connected to the ATM network, and for each

Jackowski Informational [Page 10]

RFC 1946 Native ATM Support for ST2+ May 1996

that supports downstream targets. This ensures two-way
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
message cannot be passed across the ATM network in the
messages and thus must be regenerated by the receiving agent

In addition, User Data, which can be sent in most SCMP
cannot be supported without substantial changes to current Q.2931
signaling

One of the additional complexities with embedding the
signaling occurs in heterogeneous networks. Since ATM signaling
operates point to point across the ATM network itself, if
endpoints reside on other types of networks or subnets, the
at the edge of the ATM networks must generate and
endpoint-based signaling messages on behalf of the host
agents. In particular, CONNECT and ACCEPT messages and
associated flowspecs must be regenerated. Refer to Section 5
details on the QoS mappings and on which QoS parameters can
recreated for the generated flowspecs

This approach is worth revisiting as an optimal signaling method
pure ATM network environments once ATM signaling capabilities expand

However, for heterogeneous networks, other signaling mechanisms
be more appropriate

4.2 In-Band Reservation

In-Band Reservation Signaling is the easiest signaling mechanism
implement. When the applications requests a reservation,
reservation agent simply sets up ATM virtual circuits to
endpoints with the QoS specified in the CONNECT request.
ACCEPTed, all subsequent data transmissions proceed on the
circuits

Once again, to support multicast, the reservation agent must
individual point-to-point virtual circuits to the targets which

Jackowski Informational [Page 11]

RFC 1946 Native ATM Support for ST2+ May 1996

directly connected to the ATM network, as well as to routers
can access downstream targets

Since signaling is done in-band, all reservation signaling
can be passed between agents. However, some minimal
bandwidth must be allocated in the Q.2931 SETUP to allow for
signaling messages themselves

Note that the primary disadvantage to In-Band Reservation
is the fact that it does not make use of the multipoint
of ATM and will thus overreserve ATM network bandwidth and create
larger than necessary number of virtual circuits

4.3 Dedicated Reservation Signaling Virtual

One mechanism that can be used to take advantage of the full
transmission capabilities of ATM networks is to use Dedicated
Circuits for reservation signaling. This guarantees a two-
signaling pipe between the endpoints in a connection while
the data transmission to take advantage of the
capabilities of ATM. Data and Signaling are done over
virtual circuits

When an application requests a reservation, the reservation
reviews the list of targets in the CONNECT request. For any
which have no current signaling virtual circuits established,
agent establishes UBR (unspecified bit rate) virtual circuits
forwards the CONNECT message to the targets over these
circuits. ATMARP is used to resolve any endpoint addresses. For
targets for which there already exist signaling virtual circuits,
agent simply forwards the CONNECT message over the existing
circuit

Once an ACCEPT message is received, the agent issues a Q.2931
to the associated target. Upon receipt of a CONNECTACK, data
begin to flow. As additional ACCEPTs are received, the Q.2931
ADDPARTY message is used to add a target to the multicast
multipoint connection. Depending on the cause of any
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
cause a member to be dropped from a multicast and
connection. When all targets are dropped from a
connection, a RELEASE can be issued to take down the virtual circuit

Signaling virtual circuits are shared among reservations while
circuits are dedicated to a particular reservation. Once

Jackowski Informational [Page 12]

RFC 1946 Native ATM Support for ST2+ May 1996

reservations to a given endpoint are terminated, the
virtual circuit to that endpoint can be RELEASEd

Note that this approach would allow the NSAP address to be passed
user data in the ACCEPT message to enable a kernel-based
protocol to establish the dedicated data circuit. In addition
because the connectivity to the endpoint is identical to that of
data circuit, this approach assures the fact that
information in the flowspecs retains it validity

4.4 Reservation Signaling via IP over ATM or LAN

As described in the previous section, it would be possible to set
unique SVCs for SCMP signaling, however, since the streaming
connection-oriented data transport offered by ST-2 is intended to
complementary to IP and other connectionless
implementations, it would be simpler and more elegant to simply
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
running applications that do not need specific QoS and
provisioning, makes this the most straightforward (if not
optimal) solution for signaling. Once an end-to-end acceptance of
reservation request is completed via normal LAN or IP transmission
then a unique direct virtual circuit can be established for each
flow

If LAN Emulation is used, as long as the ST-2 implementation
for different paths for SCMP and data, there would be no changes
the signaling mechanisms employed by the reservation agent

For IP over ATM, all SCMP messages would be encapsulated in IP
described in both RFC 1190 and RFC 1819. This is required
current ATM drivers will not accept Ipv5 packets, and most drivers
not provide direct access to the shared signaling virtual
used for IP

In either case, LAN Emulation or IP over ATM, the reservation
would handle SCMP messages as it normally does. However, once
first ACCEPT is received for a reservation request, a
virtual circuit is established for the data flow. Subsequent
will result in the use of ADDPARTY to add multicast targets to
multipoint virtual circuit. In fact, processing
multipoint/multicast is identical to that described in section 4.3.

Once again, the use of an out-of-band signaling mechanism makes
possible to carry the NSAP address of the target in the
message

Jackowski Informational [Page 13]

RFC 1946 Native ATM Support for ST2+ May 1996

One potential drawback to using LAN Emulation or SCMP
encapsulated in IP over ATM, is the fact that there is no
that the connectivity achieved to reach the target via signaling
any relationship to the data path. This means that
values in the flowspec may be rendered useless

In addition, it is possible that the targets will actually
outside the ATM network. That is, there may be no direct ATM
to the Targets and it may be difficult to identify ATM addresses
the associated ATM connected routers. This approach will
some additional complexity in routing to the targets. However,
ST-2 is intended to run with IP, if ATM vendors would accept IPv
packets or would allow direct access to the IP over ATM
virtual circuits, this approach would be optimal in minimizing
number of virtual circuits required

4.5 Summary of Reservation Signaling

Embedded Reservation Signaling (section 4.1) is ideal for
ATM connections, but requires extensions to existing ATM
to support multipoint connections. In-Band Reservation
(section 4.2) is the easiest to implement, but cannot
multipoint connections either

Perhaps the simplest way to do this is similar to what is
in [6]: separate the reservation signaling from the actual
flows, mapping the data flows directly to ATM circuits while
the signaling separately

While there is significant complexity in doing this for IP
and RSVP, the ST2 protocols lend themselves to this quite well.
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
(section 4.4) is one multipoint-capable approach to implement
hosts since most ATM drivers shipping today provide both IP over
and LAN Emulation, as well as associated address
mechanisms. However, it is not complete in its ability to
depict flowspec parameters or to resolve host ATM addresses.
addition, to be optimal, ATM vendors would either have to
IPv5 in their drivers or allow direct access to the IP
virtual circuits. Thus the current ideal approach to
of the ST2 protocols over ATM is to use shared Dedicated
Signaling Virtual Circuits (section 4.3) for signaling
reservations, and then to establish appropriate multipoint

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 negotiation in ST-2 (and ST-2+) is done via a two-
negotiation

The origin proposes a QoS for the connection in a Flow
(Flowspec) associated with the CONNECT message. Most of
network-significant QoS parameters in the Flowspec include both
minimum and a desired value. Each ST agent along the path to
Target validates its ability to provide the specified QoS (at
the minimum value for each), updates certain values in the Flowspec
and propagates the CONNECT until it reaches the Target. The
can either ACCEPT the Flowspec or REFUSE it if it cannot meet
least the minimum QoS requirements. Negotiation takes place as
of the process in that the Target can specify changes to the
QoS values as long as the new value meets at least the
requirements specified by the Origin system. In addition, both
Target and the Origin can assess actual network performance
reviewing the values that are accumulated along the path

The primary Reservation QoS parameters that impact an ATM
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
reservations in one direction only. Thus, depending on the type
signaling used (see Section 4), the 'Backward' ATM parameters may
be useful. In particular, if Multipoint ATM connections are used
map multicast reservations, these parameters are not available

However, it would be possible to implement a multiplexing scheme
enable reservations to share bi-directional point-to-point
connections if the reservation agent creates a split/merge point
the ATM boundary and sets up only point-to-point VC connections
targets

The CPCS-SDU parameters are AAL Parameters which are used by the
entity to break packets into cells. As such, these parameters
not modified by the network and could conceivably be used
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),
is not sufficient for guaranteed connections. Instead, Class 1
CLP=0 will provide at least minimum QoS services for the traffic

5.1 CPCS-SDU Size

The CPCS-SDU size computation is the easiest QoS mapping. Since ST-2
does not require a Service Specific Convergence Sublayer (SSCS),
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
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
is

CPCS-SDUsize = PDUbytes + 12 + 8.

Jackowski Informational [Page 16]

RFC 1946 Native ATM Support for ST2+ May 1996

5.2 PCR

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
second, AAL 5 requires an 8 byte trailer, and the ATM payload size
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
is

Bytes per second = (PDUbytes + 8 + 8) * PDUrate * 10.

Translating into cells and eliminating the possibility of
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
messages per second, not tenths of packets per second. Thus, the
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.
requested end to end delay must account for not only the PDU size
requested by the user, but the additional 8-byte AAL 5 header
well. The translation of the user-requested LimitOn Delay
preserved as long as the delay computation is based on the CPCS-
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
which they are received. The time (in milliseconds) required
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

Q.2931 signaling does not offer the ability to directly specify
requested bit error rate or a corresponding cell error rate
Instead, this service is supposed to be offered through selection
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

ST allows accumulation of the Mean Delay generated by each ST
node and intervening circuits. With an ATM circuit each agent
factor in the overhead of the ATM connection. The delay
with the ATM circuit is reflected in the Q.2931 CONNECT message
the Cummulative Transit Delay. Since this is a cell-
computation, the delay experienced for an ST packet, including
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
be consistent, since the cell transmission rate should be
for each packet. As such, except as noted by the specific
service, the ST agent should use its standard mechanisms for
packet arrival times and use this for Accumulated Delay Variance

6.0 Data Stream

Once virtual circuits for data transmission are established
one of the mechanisms described in section 4, the ST data must

Jackowski Informational [Page 18]

RFC 1946 Native ATM Support for ST2+ May 1996

transmitted over the connection. RFC 1483 describes mechanisms
encapsulating packet transmissions over AAL5. While the
encapsulation could be used, it is not necessary. If it is used,
computations in section 5 should be redone to include the LLC
in addition to the AAL5 trailer currently used. These new
should be substituted for the QoS values in the SETUP message

Instead, ST data packets can be encapsulated in standard AAL5
with an 8 byte trailer and sent directly over the data
circuit. The mechanisms for computing the QoS values in the
message are described in section 5.

7.0 Implementation Experience and

All of the signaling mechanisms described in Section 4
implemented and tested in a mixed ATM network/routed LAN environment

Initially it appeared that the best approach was to do signaling
IP over ATM or LANE. However, because it required IP
of the SCMP packets (for IP over ATM), and because some
use the accumulated values in the flowspecs (which are not
to be accurate in LANE and IP/ATM), using virtual circuits
to SCMP signaling turned out to be the best implementation
taking full advantage of the ATM features

Also, the issue of mapping ATM address to E.164 NSAP addresses
resolved through an external signaling mechanism (the User Data
of the ST-2 CONNECT and ACCEPT messages). It appears that
vendors need to implement a consistent addressing
throughout their interfaces

From a performance point of view, using ST over ATM provided
than triple the performance of raw IP. The differences
increasingly clear as more simultaneous applications were run.
resulted in dedicated virtual circuits for the ST traffic while
IP traffic suffered (saw inconsistent performance) over
circuits. Even more dramatic were results in mixed
environments where all traffic shared the same LAN/
connections, and, when both IP and ST traffic was sent, the
traffic maintained its quality while the IP traffic saw
variation in performance

Clearly, using a connection-oriented, origin-oriented
protocol to provide consistent end-to-end guaranteed QoS
bandwidth in mixed ATM/internet environments is not only feasible,
results in dramatic performance and quality improvements
transmission of realtime traffic

Jackowski Informational [Page 19]

RFC 1946 Native ATM Support for ST2+ May 1996

8.0 Security

This memo raises no security considerations. However, with
connection-oriented and origin controlled natures, ST-2 and ST-2+
lend themselves to better internet security. Discussion of this
beyond the scope of this document

9.0

[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Packard Laboratories, December, 1993.

[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "
of Real-time Services in an IP-ATM network Architecture",
1821, August 1995.

[3] Braden, R., Zhang, L., Estrin, D., Herzog, S., and S. Jamin
"Resource ReSerVation Protocol (RSVP Version 1
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
2+", RFC 1819, July 1995.

[6] V. Firoiu, R. Guerin, D. Kandlur, A. Birman "Provisioning
RSVP-based Services over a Large ATM Network', IBM T.J.
Research Center, October 1995.

[7] S. Damaskos, A. Anastassios Gavras, "Connection
Protocols over ATM: A Case Study", German National
Corporation for Mathematics and Data Processing (GMD)
Research Centre for Open Communications Systems (FOKUS),
1994.

[8] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993.

[9] M. Graf, T. Kober, H. Stuttgen, "ST-II over ATM
Issues", IBM European Networking Center, October 1995.

Jackowski Informational [Page 20]

RFC 1946 Native ATM Support for ST2+ May 1996

10.0 Author's

Steve
NetManage
269 Mt. Hermon Road, Suite 201
Scotts Valley, Ca 95066

Phone: (408) 439-6834
Fax: (408) 438-5115
EMail: Stevej@NetManage.

Jackowski Informational [Page 21]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX