popular egress points. An edge device that initiates VC setup
generally needs to have some way to propose initial value for CDV and
CTD, even if they are changed by negotiation; so by positing such a
table, we are not creating any new design burden. Cached information
can be updated when VCs are successfully established, and to the
extent that IP-layer reservations can wait for VCs to complete, the
values can be refined through iterated negotiation.
Both GS and CLS REQUIRE that losses of packets due to congestion be
minimized, so that the loss rate is approximately the same as for an
unloaded network. The characteristic loss behavior of the physical
medium not due to congestion (e.g., bit errors or fading on wireless
channels) determines the order of the permitted packet loss rate.
The ingress edge device MUST choose a value of CLR that provides the
appropriate IP-level packet loss rate. The CLR value may be uniform
over all egress points in the ATM network, or may differ, e.g., when
wireless or satellite ATM links are in some paths. The determination
of CLR MUST account for the effects of packet size distribution and
ATM Frame Discard mode (which can change the effective packet loss
rate by orders of magnitude [22]).
The ingress router will also tabulate values for the Minimum Path
Latency (MPL) and estimated queueing delays (D_ATM) for each egress
point. The latter will be used as part of the Adspec "D" parameter
for GS, but its use here applies to CLS as well (when the VC setup
includes delay parameters). MPL represents all constant (non-
congestion related) delays, including propagation delay. D_ATM
accounts for the variable component of delays in the ATM network.
(It may depend on non-signalled parameters such as CDVT.) Given
these quantities, a new VC can be set up with delay-related QoS
parameters given by
CDV = D_ATM
CTD = D_ATM + MPL.
(CDV and CTD may be adjusted (increased) by the slack term in GS, see
Section 3.3 below.)
It is interesting (and perhaps unfortunate) to note that in a typical
GS/rtVBR service, the delay bound advertised can contain two
components of b/R instead of one. Consider the simple case where SCR
= R is the rate allocated to the flow in both IP routers and ATM
switches along the path, and the buffer allocation is MBS = b.
Parekh's theory [23], which is the basis of the GS delay formula [8]
states that the b/R delay term occurs only once, because once a burst
of size b has been served by a congested node at rate R, the packets
will not arrive at a subsequent node as a single burst. However, we
can't tell a priori if this bottleneck will occur in the ATM network
or elsewhere in the IP network, so the declaration of CDV SHOULD
account for it (i.e., CDV >= b/R). Once CDV is set, the ATM network
can impose this delay, whether or not the traffic arrives in a burst.
Since the delay b/R can also occur elsewhere, it cannot be removed
from the first term of the GS delay formula. The ATM b/R delay
component appears in the third term of the GS delay formula, D_tot.
See Section 3.3 below for more on GS Adspec parameters. This effect
may be mitigated when the ATM network employs more efficient
statistical resource allocation schemes.
2.7 Additional Parameters -- Frame Discard Mode
TM/UNI 4.0 allows the user to choose a mode where the ATM network is
aware, for the purpose of congestion management, of PDUs larger than
an ATM cell (i.e., AAL PDUs that correspond in our context to IP
packets). This facilitates implementation of algorithms such as
partial packet discard, where a dropped cell causes subsequent cells
in the same AAL-5 PDU to be dropped as well. Several other
applicable buffer management schemes have been proposed [22, 24].
Frame discard can improve the efficiency and performance of end-to-
end protocols such as TCP, since the remaining cells of a damaged PDU
are generally useless to the receiver. For IP over ATM, Frame
Discard MUST always be indicated, if available.
3.0 Additional IP-Integrated Services Protocol Features
3.1 Path Characterization Parameters for IP Integrated Services with ATM
This section discusses the setting of General Characterization
Parameters (GCPs) at an ATM egress edge router. GCPs are signalled
from IP source to IP destination, and modified by intermediate nodes
using the Adspec portion of PATH messages in rsvp. The GS-specific
Adspec parameters are discussed below in Section 3.3. These
parameters are denoted as <x,y> where x is the service and y is the
parameter number. Service number 1 indicates default or general
parameter values. Please refer to [25] for definitions and details.
The IS break bit <1,2> MUST, of course, be left alone by
implementations following these guidelines (as they are presumably
IS-aware). Similarly, the router MUST always increment IS_HOPS
<1,4>. The GS and CLS service-specific break bits, <2,2> and <5,2>
respectively, MUST be set if the support of the service is
inadequate. In general GS is adequately supported by CBR (BCOB-A)
and rtVBR service categories, and not adequately supported by UBR,
ABR and nrtVBR because delays are not controlled. CLS may be
adequately supported by all service categories except UBR (or Best
Effort in UNI 3.x). See Sections 5, 6 for further discussion.
For GS, the ATM network MUST meet the delay performance advertised
through the Adspec parameters, MPL, C, and D. If it cannot
predictably meet these requirements, the GS break bit MUST be set.
Similarly both break bits MUST be set if reservations are honored,
but sufficient resources to avoid congestion loss are not allocated
in practice. If the service break bits are not set, then the
corresponding service hop counters, <2,4>, <5,4>, MUST be
incremented.
The Available Path Bandwidth (APB) parameters <x,6> indicate the
minimum physical bottleneck rate along the path. This may be
discoverable in an ATM network as the negotiated PCR value for any
UBR VC along the same path. This value MUST be corrected for AAL,
ATM and physical-layer headers, as necessary, to reflect the
effective IP datagram bandwidth. With ATM, it is possible that there
is some policy limitation on the value of PCR, below the physical
link bottleneck. In this case, the advertised value of APB (in
general, and for each service if the values of APB signalled are
service specific) MUST reflect this limit, since excess traffic
beyond this rate will be dropped. (Note that there is no tagging of
traffic in excess of PCR for TM/UNI 4.0.) These values SHOULD
generally be cached by the ingress router for the set of egress
routers with which it typically needs to establish VCs. The APB
parameters are only adjusted down, to reflect the minimum as the
composed value.
In the case of a multipoint VC, several parameters can be different
for each egress point, e.g., because the characteristics of the
physical links of the VC branches differ. When this occurs, the IWF
at the egress routers MUST correct these values in PATH messages as
they exit the ATM network. (We use the word "correct" because the
ingress router SHOULD set the parameters to a value that is
appropriate for the largest number of branches, or a value that would
do the least harm if the egress routers failed to correct such
parameters for each branch.) This is the only case where the egress
router needs to operate on rsvp control messages. (A similar
correction MUST be implemented for any non-rsvp set-up mechanism).
The parameters for which such correction is REQUIRED are the
Available Path Bandwidth (APB), the Minimum Path Latency (MPL), the
Path MTU (although for ATM/AAL-5 this may typically be constant), and
the ATM-specific components of the GS Adspec parameters C_ATM and
D_ATM.
The ingress router table SHOULD store values for the ATM-network MPL
<x,7> for the various egress points. The composed values <x,8> are
formed by addition and forwarded along the path. In the cases where
ATM routing chooses different paths, depending on the service
category, for VCs to a given egress point, the table will generally
reflect different values for each service. If the ATM network is
very large and complex, it may become difficult to predict the routes
that VCs will take once they are set up. This could be a significant
source of misconfiguration, resulting in discrepancies between GS
delay advertisements and actual results. The RSpec Slack term may be
useful in mitigating this problem.
AAL-5 will support any message size up to 65,535 bytes, so setting
the AAL SDU to the receiver TSpec M parameter value (plus 8 bytes for
the LLC/SNAP header) will generally not be an issue. In the PATH
Adspec, however, the PATH_MTU parameter <x,10> for each service
SHOULD be set to 9188 bytes, which is the default MTU for AAL-5 [19].
3.2 Handling of Excess Traffic
For IP Integrated Services, network elements will transport traffic
in excess of the TSpec parameters whenever physical resources
(bandwidth, buffers and processing) are available. (In CLS a
"network element MUST attempt to forward the excess traffic on a
best-effort basis" under certain conditions; and in GS a traffic
policers "SHOULD relegate non-conforming datagrams to best effort".)
While excess traffic SHOULD be supported on a best effort basis, it
MUST NOT interfere with the QoS (delay and loss) of conforming CLS
and GS traffic, nor with normal service of non-reserved best effort
traffic.
There are several solutions with ATM: the most attractive is to use a
VBR service category (with an appropriate conformance definition) and
tag excess traffic as low priority using the CLP bit. This avoids
reordering of the flow, but necessitates careful design of the egress
router scheduler. To avoid reordering, the excess traffic can be
queued with conforming traffic. A threshold SHOULD be used to ensure
that conforming traffic is not unnecessarily delayed by the excess.
Also, for GS, the extra delay that would be incurred due to excess
traffic in the queue ahead of conforming packets would have to be
accurately reflected in the delay advertisement. Note that the
ingress router SHOULD tag all cells of each non-conforming packet,
rather than letting the ATM network apply tagging due to ATM-level
non-conformance.
There is no requirement in ATM standards that tagged cells, marked
either by the user or by policing, be transported if possible.
Therefore, the operator of an edge router supporting IP-IS SHOULD
ascertain the actual behavior of the ATM equipment in the path, which
may span multiple administrative domains in the ATM network. If
tagged cells are simply dropped at some point, regardless of load,
then the operator may consider setting the break bit, at least for
CLS service.
The other solutions generally involve a separate VC to carry the
excess. A distinct VC can be set up for each VC supporting a GS or
CLS flow, or, if many flows are aggregated into a single QoS VC, then
another VC can handle the excess traffic for that set of flows. A VC
can be set up to handle all excess traffic from the ingress router to
the egress point. Since the QoS of the excess traffic is not
particularly constrained, the design is quite flexible. However,
using a separate VC may cause misordering of packets within a flow.
The service category for the excess-traffic VC may typically be UBR
or ABR, although one could use CBR or nrtVBR if the excess traffic
were predictable enough to know what rate to allocate. (This
wouldn't normally be expected for excess traffic, though.)
Whether a separate VC is used may be influenced by the design of the
router scheduler. The CLS spec suggests two possible
implementations: one where excess traffic shares the Best Effort
class scheduler allocation, but at lower priority than other best
effort traffic. The other, where a separate allocation is made. The
first would allow excess traffic to use the same VC as normal best
effort traffic, and the second would suggest a separate VC.
TM/UNI 4.0. does not support tagging of traffic in excess of PCR.
Although UNI 3.x does have a separate PCR parameter for CLP=0 cells
only, we do not recommend using this feature for reasons of
interoperability with TM/UNI 4.0 equipment. This restricts CBR VCs
to use solutions other than tagging. The value of PCR can be set
higher than necessary for conformant traffic, in an effort to support
excess traffic on the same VC. In some cases this may be a viable
solution, such as when there is little additional cost imposed for a
high PCR. If PCR can be set as high as APB, then the excess traffic
is fully accommodated.
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term
The Adspec is used by the Guaranteed Service to allow a receiver to
calculate the worst-case delay associated with a GS flow. Three
quantities, C, D, and MPL, are accumulated (by simple addition of
components corresponding to each network element) in the PATH message
from source to receiver. The resulting delay values can be different
for each unique receiver. The maximum delay is computed as
delay <= b_r/R + C_TOT/R + D_TOT + MPL
The Minimum Path Latency (MPL) includes propagation delay, while
b_r/R accounts for bursts due to the source and C and D include other
queueing, scheduling and serialization delays. (We neglect the
effect of maximum packet size and peak rate here; see the GS
specification [8] for a more detailed equation.) The service rate
requested by the receiver, R, can be greater than the TSpec rate,
r_r, resulting in lower delay. The burst size, b_r, is the leaky
bucket parameter from the receiver TSpec.
The values of C and D that a router advertises depend on both the
router packet scheduler and the characteristics of the subnet
attached to the router. Each router (or the source host) takes
responsibility for its downstream subnet in its advertisement. For
example, if the subnet is a simple point-to-point link, the subnet-
specific parts of C and D need to account for the link transmission
rate and MTU. An ATM subnet is generally more complex.
For this discussion, we consider only the ATM subnet-specific
components, denoted C_ATM and D_ATM. The ATM network can be
represented as a "pure delay" element, where the variable queueing
delay, given by CVD is captured in D_ATM, and C_ATM is set to zero.
It is possible to use C_ATM only when the ATM service rate equals R.
This may be the case, for example with a CBR VC with PCR = R.
Usually it will be simpler to just advertise the total delay
variation (CDV) in D_ATM.
As discussed in Section 2.6, the edge router keeps a table with
values of MPL and D_ATM for each egress router it needs to share VCs
with. The value of D_ATM contributes to the D parameter advertised
by the edge router, and SHOULD accurately reflect the CDV that the
router will get in a VC when it is set up. Factors that affect CDV,
such as statistical multiplexing in the ATM network, SHOULD be taken
into account when compiling data for the router's table. In case of
uncertainty, D_ATM can be set to an upper bound. When an RESV
message arrives, causing a VC to be set up, the requested values for
CTD and CDV can be relaxed using the slack term in the receiver
RSpec:
CTD = D_ATM + MPL + S_ATM
CDV = D_ATM + S_ATM.
The term S_ATM is the portion of the slack term applied to the ATM
portion of the path. Recall that the slack term [8] is positive when
the receiver can afford more delay than that computed from the
Adspec. The ATM edge device may take part (or all) of the slack
term, S. The distribution of delay slack among the nodes and subnets
is network specific.
Note that with multipoint VCs the egress edge router may need to
correct advertised values of C and D. See discussion in Section 3.1.
4.0 Miscellaneous Items
4.1 Units Conversion
All rates and token bucket depth parameters that are mapped from IP-
level parameters to ATM parameters MUST be corrected for the effects
of added headers and the segmentation of packets into cells. At the
IP layer, token bucket depths and rates are measured in bytes and
bytes/sec, respectively, whereas for ATM, they are measured in cells
and cells/sec.
Each IP Packet is wrapped into an AAL-5 PDU, having a number of
additional header bytes (8 for LLC/SNAP and perhaps others, e.g. 12
for MPOA, etc.), and an 8-byte AAL-5 trailer. The AAL-5 PDU is then
segmented into multiple ATM cells, each having a 5-byte cell header
followed by a 48-byte cell payload. The number of cells used to
carry an IP packet with
B = number of IP-packet Bytes,
H = number of AAL-5 header bytes (LLC/SNAP etc.)
C = number of cells,
is roughly
C = B/48,
and more precisely
C = floor[(H + B + 8 + 47)/48]
where floor[] is rounds down to the nearest integer. The '8'
accounts for the AAL-5 trailer and the '47' accounts for the last
cell which may be only partially filled.
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service
This section describes how to create ATM VCs appropriately matched
for Guaranteed Service. The key points are that real-time timing is
REQUIRED, that the data flow may have a variable rate, and that
demotion of non-conforming traffic to best effort is REQUIRED to be
in agreement with the definition of GS. For this reason, we prefer
an rtVBR service in which tagging is supported. Another good match
is to use CBR with special handling of any non-conforming traffic,
e.g., through another VC, since a CBR VC will not accommodate traffic
in excess of PCR.
Note, these encodings assume point to multipoint connections, where
the backward channel is not used. If the IP session is unicast only,
then a point-to-point VC may be used and the IWF may make use of the
backward channel, with QoS parameters set appropriately for the
service provided.
We provide a mapping for all combinations of IP service and ATM
service category, and comments indicating whether or not each
combination meets the requirements of the IP-IS service.
5.1 Encoding GS Using Real-Time VBR (ATM Forum TM/UNI 4.0)
RtVBR with conformance definition VBR.3 [6] MEETS the requirements of
GS.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
Forward SCR CLP=0 Note 1
Backward SCR CLP=0 0
Forward MBS (CLP=0) Note 1
Backward MBS (CLP=0) 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 9 (Real time VBR) Note 3
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 1 Note 5
QoS Class Backward 1 Note 5
Extended QoS Parameters Note 6
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTD
Note 1: See discussion in Section 2.5.1.
Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is chosen the ATC field MUST be absent.
Note 3: The ATC value 19 is not used. The value 19 implies that the
CLR objective applies to the aggregate CLP=0+1 stream and
that does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
SHOULD be specified. For BE VCs, it can be left
unspecified, allowing the VC to be shared by multiple
protocols, following RFC1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6.
5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0)
A CBR VC MEETS the requirements of GS. The main advantage of this is
that CBR is widely supported; the disadvantage is that data flows
might not fill the pipe (utilization loss) and there is no tagging
option available. Excess traffic MUST be handled using a separate
VC.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 0 (Tagging not requested)
Tagging Backward bit 0 (Tagging not requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 5 (CBR) Note 3
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 1 Note 5
QoS Class Backward 1 Note 5
Extended QoS Parameters Note 6
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTD
Note 1: See discussion in Section 2.5.1.
Note 2: Value 1 (BCOB-A) can also be used.
If Bearer Class A is chosen the ATC field MUST be absent.
Note 3: The ATC value 7 is not used. The value 7 implies CLR
objective applies to the aggregate CLP=0+1 stream and that
does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
SHOULD be specified. For BE VCs, it can be left
unspecified, allowing the VC to be shared by multiple
protocols, following RFC1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6.
5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
NrtVBR does not provide delay guarantees and is NOT RECOMMENDED for
GS. If GS/nrtVBR is used and network utilization is low, the delay
may be `reasonable', but will not be controlled. The encoding of GS
with nrtVBR is the same as that for CLS using nrtVBR. See Section
6.1 below.
5.4 Encoding GS Using ABR (ATM Forum TM/UNI 4.0)
GS using ABR is a very unlikely combination, and DOES NOT meet the
service requirements of GS. The objective of the ABR service is to
provide "low" loss rates. The delay objectives for ABR SHOULD be
expected to be very loose. If ABR were used for GS, the VC
parameters would follow as for CLS over ABR. See Section 6.2.
5.5 Encoding GS Using UBR (ATM Forum TM/UNI 4.0)
The UBR service is the lowest common denominator of the services. It
cannot provide delay or loss guarantees, and therefore DOES NOT meet
the requirements of GS. However if it is used for GS, it will be
encoded in the same way as Best Effort over UBR, with the exception
that the Forward PCR would be determined from the peak rate of the
receiver TSpec. See Section 7.1.
5.6 Encoding GS Using ATM Forum UNI 3.0/3.1 Specifications
It is not recommended to support GS using UNI 3.x VBR mode because
the BCOB-C Bearer Class does not represent real-time behavior. Also,
Appendix F of the UNI 3.1 specification precludes the specification
of traffic type "VBR" with the timing requirement "End to End timing
Required" in conjunction with Bearer Class X.
A CBR VC MEETS the requirements of GS. The following table specifies
the support of GS using CBR.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Mode 1 (Message mode) Note 1
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0 Note 2
Backward PCR CLP=0 0
Forward PCR CLP=0+1 Note 2
Backward PCR CLP=0+1 0
BE indicator NOT included
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 3
Traffic Type 001 (Constant Bit Rate)
Timing Requirements 01 (Timing Required)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class Note 5
QoS Class Forward 1
QoS Class Backward 1
Note 1: Only included for UNI 3.0.
Note 2: See discussion in Section 2.5.1. PCR CLP=0 SHOULD be set
identical to PCR CLP=0+1. Although this could potentially
allow a CBR VC to carry excess traffic as tagged cells, it
is not recommended since it is not supported in UNI 4.0
Note 3: Value 1 (BCOB-A) can also be used. If BCOB-A is used Traffic
Type and Timing Requirements fields are not included.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
SHOULD be specified. For BE VCs, it can be left
unspecified, allowing the VC to be shared by multiple
protocols, following RFC1755.
Note 5: QoS Parameters are implied by the QoS Class.
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service
This section describes how to create ATM VCs appropriately matched
for Controlled Load Service. CLS traffic is partly delay tolerant
and has variable rate. NrtVBR and ABR (TM/UNI 4.0 only) are the best
choices for supporting CLS.
Note, these encodings assume point to multipoint connections where
the backward channel is not used. If the IP session is unicast only,
then a point-to-point VC may be used and the IWF may make use of the
backward channel, with QoS parameters set appropriately for the
service provided.
We provide a mapping for all combinations of IP service and ATM
service category, and comments indicating whether or not each
combination meets the requirements of the IP-IS service.
6.1 Encoding CLS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
NrtVBR MEETS the requirements for CLS.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
Forward SCR CLP=0 Note 1
Backward SCR CLP=0 0
Forward MBS (CLP=0) Note 1
Backward MBS (CLP=0) 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 10 (Non-real time VBR) Note 3
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 3 Note 5
QoS Class Backward 3 Note 5
Extended QoS Parameters Note 6
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTD
Note 1: See discussion in Section 2.5.2.
Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is used, the ATC field MUST be absent.
Note 3: The ATC value 11 is not used. The value 11 implies CLR
objective applies to the aggregate CLP=0+1 stream and
that does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD
be specified. For BE VCs, it can be left unspecified, allowing
the VC to be shared by multiple protocols, following RFC1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6.
6.2 Encoding CLS Using ABR (ATM Forum TM/UNI 4.0)
ABR MEETS the requirements for CLS when MCR is set to the CLS TSpec
rate.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
Forward MCR CLP=0+1 Note 1
Backward MCR CLP=0+1 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 0 (Tagging not requested)
Tagging Backward bit 0 (Tagging not requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 12 (ABR)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 00 (Point-to-Point)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 3
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 0 Note 4
QoS Class Backward 0 Note 4
Extended QoS Parameters Note 5
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTD
ABR Setup Parameters Note 6
ABR Additional Parameters Note 6
Note 1: See discussion in Section 2.5.2.
Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is chosen the ATC field MUST be absent.
Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol
SHOULD be specified. For BE VCs, it can be left
unspecified, allowing the VC to be shared by multiple
protocols, following RFC1755.
Note 4: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 5: See discussion in Section 2.6.
Note 6: The ABR-specific parameters are beyond the scope of this
document. These generally depend on local implementation
and not on values mapped from IP level service parameters
(except for MCR). See [6, 11] for further information.
6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0)
Although CBR does not explicitly take into account the variable rate
of source data, it may be convenient to use ATM connectivity between
edge routers to provide a simple "pipe" service, as a leased line
replacement. Since no tagging option is available with CBR, excess
traffic MUST be handled using a separate VC. Under this condition,
CBR MEETS the requirements of CLS.
To use CBR for CLS, the same encoding for GS over CBR (Section 5.2)
would be used. See discussion in Section 2.5.2.
6.4 Encoding CLS Using Real-Time VBR (ATM Forum TM/UNI 4.0)
The encoding of CLS using rtVBR implies a hard limit on the end-to-
end delay in the ATM network. This creates more complexity in the VC
setup than the CLS service requires, and is therefore not a preferred
combination, although it DOES MEET the requirements of CLS.
If rtVBR is used to encode CLS, then the encoding is essentially the
same as that for GS. See discussions in Section 5.1 and Section
2.5.2.
6.5 Encoding CLS Using UBR (ATM Forum TM/UNI 4.0)
This encoding gives no QoS guarantees and DOES NOT MEET the
requirements of CLS. If used, it is coded in the same way as for BE
over UBR (Section 7.1), except that the PCR would be determined from
the peak rate of the receiver TSpec.
6.6 Encoding CLS Using ATM Forum UNI 3.0/3.1 Specifications
This encoding is equivalent to the nrtVBR service category. It MEETS
the requirements of CLS.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Mode 1 (Message mode) Note 1
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 2
Backward PCR CLP=0+1 0
Forward SCR CLP=0 Note 2
Backward SCR CLP=0 0
Forward MBS (CLP=0) Note 2
Backward MBS (CLP=0) 0
BE indicator NOT included
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 3
Traffic Type 010 (Variable Bit Rate)
Timing Requirements 00 (No Indication)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 3 Note 5
QoS Class Backward 3 Note 5
Note 1: Only included for UNI 3.0.
Note 2: See discussion in Section 2.5.2.
Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic
Type and Timing Requirements fields are not included.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
SHOULD be specified. For BE VCs, it can be left
unspecified, allowing the VC to be shared by multiple
protocols, following RFC1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. QoS
Parameters are implied by the QoS Class.
7.0 Summary of ATM VC Setup Parameters for Best Effort Service
This section is provided for completeness only. The IETF ION working
group documents on ATM signalling support for IP over ATM [10, 11]
provide definitive specifications for Best Effort IP service over
ATM.
The best-matched ATM service category to IP Best Effort is UBR. We
provide the setup details for this case below. The BE service does
not involve reservation of resources. ABR and nrtVBR are also well
suited to BE service. See discussion in Section 2.1.3.
Note, VCs supporting best effort service are usually point to point,
rather than point to multipoint, and the backward channels of VCs are
used. In cases where VCs are set up to support best effort multicast
sessions, multipoint VCs can be used and the backward channels would
be not have resources reserved. Related situations include transport
of excess traffic on IP-multicast QoS sessions, or to support the
subset of multicast end systems that have not made rsvp reservations.
See the discussion on VC management in [12].
7.1 Encoding Best Effort Service Using UBR (ATM Forum TM/UNI 4.0)
AAL
Type 5
Forward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5)
Backward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5)
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
BE indicator included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 10 (Non-real time VBR)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2) Note 3
QoS Class
QoS Class Forward 0
QoS Class Backward 0
Note 1: See discussion in Section 2.5.3.
Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is used, the ATC field MUST be absent
Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD
be specified. For BE VCs, it can be left unspecified, allowing
the VC to be shared by multiple protocols, following RFC1755.
8.0 Security Considerations
IP Integrated Services (including rsvp) and ATM are both complex
resource reservation protocols, and SHOULD be expected to have
complex feature interactions.
Differences in IP and ATM billing styles could cause unforeseen
problems since RESV messages can set up VCs. For example, an end-
user paying a flat rate for (non-rsvp aware) internet service may
send an rsvp RESV message that encounters a (perhaps distant) ATM
network with a usage-sensitive billing model. Insufficient
authentication could result in services being accidentally billed to
an innocent third party, intentional theft of service, or malicious
denial of service attacks where high volumes of reservations consume
transport or processing resources at the edge devices.
The difference in styles of handling excess traffic could result in
denial of service attacks where the ATM network uses transport
resources (bandwidth, buffers) or connection processing resources
(switch processor cycles) in an attempt to accommodate excess traffic
that was admitted by the internet service.
Problems associated with translation of resource reservations at edge
devices are probably more complex and susceptible to abuse when the
IP-ATM edge is also an administrative boundary between service
providers. Note also that administrative boundaries can exist within
the ATM cloud, i.e., the ingress and egress edge devices are operated
by different service providers.
Note, the ATM Forum Security Working Group is currently defining
ATM-level security features such as data encryption and signalling
authentication. See also the security issues raised in the rsvp
specification [3].
9.0 Acknowledgements
The authors received much useful input from the members of the ISSLL
working group. In particular, thanks to Drew Perkins and Jon Bennett
of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha Ramesh
of Bellcore.
Appendix 1 Abbreviations
AAL ATM Adaptation Layer
ABR Available Bit Rate
APB Available Path Bandwidth (int-serv GCP)
ATC ATM Transfer Capability
ATM Asynchronous Transfer Mode
B-LLI Broadband Low Layer Information
BCOB Broadband Connection-Oriented Bearer Capability
BCOB-{A,C,X} Bearer Class A, C, or X
BE Best Effort
BT Burst Tolerance
CBR Constant Bit Rate
CDV Cell Delay Variation
CDVT Cell Delay Variation Tolerance
CLP Cell Loss Priority (bit)
CLR Cell Loss Ratio
CLS Controlled Load Service
CPCS Common Part Convergence Sublayer
CTD Cell Transfer Delay
EOM End of Message
GCP General Characterization Parameter
GCRA Generic Cell Rate Algorithm
GS Guaranteed Service
IE Information Element
IETF Internet Engineering Task Force
ION IP Over Non-broadcast multiple access networks
IP Internet Protocol
IPI Initial Protocol Identifier
IS Integrated Services
ISSLL Integrated Services over Specific Link Layers
ITU International Telecommunication Union
IWF Interworking Function
LIJ Leaf Initiated Join
LLC Logical Link Control
MBS Maximum Burst Size
MCR Minimum Cell Rate
MPL Minimum Path Latency
MTU Maximum Transfer Unit
nrtVBR Non-real-time VBR
PCR Peak Cell Rate
PDU Protocol Data Unit
PVC Permanent Virtual Connection
QoS Quality of Service
RESV Reservation Message (of rsvp protocol)
RFCRequest for Comments
RSVP Resource Reservation Protocol
RSpec Reservation Specification
rtVBR Real-time VBR
SCR Sustainable Cell Rate
SDU Service Data Unit
SNAP Subnetwork Attachment Point
SSCS Service-Specific Convergence Sub-layer
SVC Switched Virtual Connection
TCP Transport Control Protocol
TM Traffic Management
TSpec Traffic Specification
UBR Unspecified Bit Rate
UNI User-Network Interface
UPC Usage Parameter Control (ATM traffic policing function)
VBR Variable Bit Rate
VC (ATM) Virtual Connection
REFERENCES
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[2] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC1633, June 1994.
[3] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) - Version 1 Functional
Specification", RFC2205, September 1997.
[4] The ATM Forum, "ATM User-Network Interface Specification,
Version 3.0", Prentice Hall, Englewood Cliffs NJ, 1993.
[5] The ATM Forum, "ATM User-Network Interface Specification,
Version 3.1", Prentice Hall, Upper Saddle River NJ, 1995.
[6] The ATM Forum, "ATM User-Network Interface (UNI) Signalling
Specification, Version 4.0", July 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps.
[7] The ATM Forum, "ATM Traffic Management Specification, Version
4.0", April 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps.
[8] M. W. Garrett, "A Service Architecture for ATM: From
Applications to Scheduling", IEEE Network Mag., Vol. 10, No. 3,
pp. 6-14, May 1996.
[9] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC2212, September 1997.
[10] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC2211, September 1997.
[11] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and
A. Malis, "ATM Signaling Support for IP over ATM", RFC1755,
February 1995.
[12] Maher, M., "ATM Signalling Support for IP over ATM - UNI
Signalling 4.0 Update", RFC2331, April 1998.
[13] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
J. Krawczyk, "A Framework for Integrated Services and RSVP over
ATM", RFC2382, August 1998.
[14] Berger, L., "RSVP over ATM Implementation Requirements", RFC
2380, August 1998.
[15] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24,
RFC2379, August 1998.
[16] Shenker, S., and J. Wroclawski, "Network Element Service
Specification Template", RFC2216, September 1997.
[17] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC2210, September 1997.
[18] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
of Real-time Services in an IP-ATM Network Architecture", RFC
1821, August 1995.
[19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, July 1993.
[20] Laubach, M., "Classical IP and ARP over ATM", RFC1577, January
1994.
[21] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer
performance", International Telecommunication Union, Geneva,
October 1996.
[22] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM
Networks", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp.
633-41, May 1995.
[23] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing
Approach to Flow Control in Integrated Services Networks: The
Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2,
pp. 137-150, April 1994.
[24] S. Floyd, V. Jacobson, "Link-sharing and Resource Management
Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3,
No. 4, August 1995.
[25] S. Shenker and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC2215,
September 1997.
Authors' Addresses
Mark W. Garrett
Bellcore
445 South Street
Morristown, NJ 07960
USA
Phone: +1 201 829-4439
EMail: mwg@bellcore.com
Marty Borden
Bay Networks
42 Nagog Park
Acton MA, 01720
USA
Phone: +1 508 266-1011
EMail: mborden@baynetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.