4. Dealing with Failure of Call Establishment
In UNI 3.0 the there are certain cause values which are different
than UNI 3.1. Two relevant differences are the following:
'AAL Parameter Cannot Be Supported' is #93 (#78 in UNI 3.1), and
'User Cell Rate Unavailable' is #51 (#37 in UNI 3.1).
Appendix C.
Combinations of Traffic Related Parameters
tha MAY be supported in the SETUP message
|-----------------------------------------------------------------|
|Broadband Bearer |
|Capability |
|-----------------------------------------------------------------|
|Broadband Bearer |A,C| X |X |C | X |C| X |A,C| X | X |C| X |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Traffic Type | | | | | | | | | | | | |
|(CBR,VBR) | |CBR| & | |& | |& | |CBR|& |&| & |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Timing Required | | Y |&& | |&& | |&& | | Y |&& | |&& |
|-----------------------------------------------------------------|
|Traffic Descriptor |
|Parameter |
|-----------------------------------------------------------------|
|PCR (CLP=0) | S | S | S | | | | | | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|PCR (CLP=0+1) | S | S | S | S | S |S| S | S | S | S |S| S |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|SCR (CLP=0) | | | | | S |S| | | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|SCR (CLP=0+1) | | | | | | | S | S | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|MBS (CLP=0) | | | | | S |S| | | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|MBS (CLP=0+1) | | | | | | | S | S | | | | |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Best Effort | | | | | | | | | | |S| S |
|---------------------|---|---|---|---|---|-|---|---|---|---|-|---|
|Tagging |Y/N|Y/N|Y/N|Y/N|Y/N|N| N | N | N | N |N| N |
|-----------------------------------------------------------------|
|-----------------------------------------------------------------|
|QOS Classes | * | * | * | * | * |*| * | * | * | * |0| 0 |
|-----------------------------------------------------------------|
(Table 2 is a reproduction of Table F-1 of Appendix F in [ATMF 94].)
PCR = Peak Cell Rate, SCR = Sustainable Cell Rate,
MBS = Maximum Burst Size
Y = Yes, N = No, S = Specified
Y/N = either "Yes" or "No" is allowed
* = allowed QoS class values are a network option. Class 0 is
always supported for alignment with ITU-T
& = parameter is coded to either "no indication" or VBR or
octet 5a(Traffic Type/Timing Required) is absent; these three
codings are treated as equivalent
&& = parameter is coded to either "no indication" or "No" or
octet 5a(Traffic Type/Timing Required) is absent; these three
codings are treated as equivalent
A blank entry in the table indicates that the parameter is not
present.
Appendix D. Frame Relay Interworking
1. RFC1490 over FR-SSCS vs. RFC1483 over null-SSCS
Procedures for Frame Relay to ATM signaling interworking have not yet
been specified by ITU-T, the ATM Forum, or the Frame Relay Forum. If
an ATM endsystem wishes to use FR-SSCS, FR-SSCS and RFC1490
encapsulation must both be be specified in the SETUP message.
Nevertheless, since neither LLC encapsulation nor VC-multiplexing
will interoperate when used over FR-SSCS, these two encapsulations
cannot be negotiated as alternatives to RFC1490 encapsulation (see
Section 4, Encapsulation Negotiation).
In ATM environments the SSCS layer is part of the AAL functionality.
The SSCS serves to coordinate the needs of a protocol above with the
requirements of next lower layer, the Common Part Convergence
Sublayer (CPCS). For example, the UNI ATM signaling protocol runs on
top of a signaling SSCS which among other things provides an assured
transfer service for signaling messages. Since the SSCS is considered
part of the AAL, the SSCS type is specified as one of the parameters
in the AAL Parameters IE. To date there has not been an SSCS defined
for data transmission in ATM and this type field is usually set to
'null'.
The exception occurs when doing FR interworking where an ATM
endsystem may choose to use the FR-SSCS over AAL 5 in order to
communicate with a FR endsystem. In that case the SSCS type in the
AAL Parameters IE of the SETUP message is set to 'FR-SSCS'.
Also included in a SETUP message is an indication in the B-LLI IE of
the protocol layers to be used above the AAL. In particular, ATM
connections established to carry connectionless network interconnect
traffic require a layer above the AAL for multiplexing multiple
protocols over a single VC [HEIN 93]. As mentioned above, RFC1577
defines LLC as default multiplexing layer for IP over AAL5.
Specification of the SSCS restricts the encapsulation protocol used
over it, since RFC1483 (in addition to applicable ITU standards)
defines the use of RFC1490 encapsulation over the FR-SSCS, and LLC
or null encapsulation otherwise. The fact that it is not possible,
in the UNI 3.0 signaling specification, to negotiate between the FR-
SSCS and null-SSCS can result in interoperability restrictions
between stations that implement and wish to use the FR-SSCS and those
that do not, even though they both are using IP. The guidelines in
the following section were developed to decrease the chance that such
interoperability restrictions occur.
2. Scenarios for Interworking
The following discussion uses the terms "network interworking" and
"service interworking". "Network interworking" uses FR-SSCS over
AAL5 between the InterWorking Unit (IWU) and the ATM endsystem, and
the ATM endsystem is aware that the other endpoint is a FR/ATM
Network IWU. "Service interworking" aims to make the operation
transparent to the ATM endsystem by adding encapsulation translation
and other payload processing in the FR/ATM Service IWU to allow the
ATM endsystem to operate as if it were talking to another ATM
endsystem.
The most common scenario where FR-SSCS could be negotiated is between
an ATM endsystem and a FR/ATM network IWU to allow connectivity among
an ATM endsystem and a FR endsystem residing behind a FR/ATM network
IWU.
-------- --------
------- | | | | -------
| A | | FR/ATM | | ATM | | B |
| (FR) |----->| IWU |----->| switch |----->| (ATM) |
------- | | | | -------
-------- --------
| | | |
-----> --------------------->
FR call ATM call
A network IWU can place a call to an ATM host (on behalf of a FR
host) by signaling for FR-SSCS and assuming that the ATM endsystem
supports FR-SSCS. The B-LLI IE SHALL be encoded to indicate RFC1490
encapsulation and the SSCS type field of the AAL Parameters IE SHALL
be coded to indicate FR-SSCS. If the FR-SSCS negotiation fails
because the called ATM host does not support FR-SSCS, the IWU can
retry the call negotiating for LLC encapsulation or VC-multiplexing.
However, the IWU can only attempt the retry if it is able to do FR-
ATM service interworking. Such service interworking adds extra
processing overhead during the call.
The even more problematic case occurs when a call is requested in the
opposite direction, i.e. when an ATM host places a call to a host
residing behind an IWU.
-------- --------
------- | | | | -------
| B | | FR/ATM | | ATM | | A |
| (FR) |<-----| IWU |<-----| switch |<-----| (ATM) |
------- | | | | -------
-------- --------
| | | |
<----- <---------------------
FR call ATM call
Not knowing that the destination resides behind an IWU, the calling
host will negotiate for the default LLC encapsulation (possibly
requesting VC-multiplexing as an alternative). In this situation the
IWU can accept the call and do the necessary service interworking or
reject the call specifying 'AAL Parameters not supported'. If the IWU
rejects the call it risks the possibility that calling host does not
support FR-SSCS or simply does not retry and the call will never be
established.
3. Possible Alternatives
While Frame Relay interworking is possible, it is not possible to
negotiate FR-SSCS with LLC encapsulation or VC-multiplexing, which
decreases the chances of completing an ATM call. However,
interoperability can be increased using the following alternatives:
1. Maintaining external knowledge that a particular destination uses
FR-SSCS. This knowledge can be configured, or in the future added to
some network host database.
2. In the absence of such external knowledge, an ATM endsystem is
required to negotiate for the default LLC encapsulation (possibly
requesting VC-multiplexing as an alternative). There are three sub-
cases:
2a. The IWU supports service interworking and network interworking,
and prefers service interworking. The IWU simply accepts the call
using LLC encapsulation.
2b. The IWU supports service interworking and network interworking,
and prefers network interworking. The IWU simply accepts the call,
but attempts to open a parallel connection back to the original ATM
endsystem negotiating the FR-SSCS use. If the connection is
accepted, the IWU closes the service interworking connection.
2c. The IWU supports network interworking only. The IWU rejects the
call specifying 'AAL Parameters not supported', and then attempts to
open a connection back to the original ATM endsystem negotiating the
FR-SSCS use.
4. Encapsulation negotiation
The call/connection control signaling protocol includes a mechanism
to support negotiation of encapsulation for endsystems that support
more than one. This section describes the procedures for negotiation
of an encapsulation.
The B-LLI negotiation procedures (see Annex C of [ATMF93]) are
initiated by the calling ATM endsystem by including up to three
instances of the B-LLI IE in the SETUP message in descending order of
preference (following the rule for repeating IE in section 5.4.5.1 of
[ATMF93]).
The following is the list of the three possible combinations that B-
LLI IE instances MAY be included in the SETUP message. Each instance
is referred to by its encapsulation name as it appears in RFC1483,
and corresponding section labels from Appendix D of the ATM Forum UNI
3.0 specification.
a) LLC/SNAP encapsulation (D.3.1)
In this case, the calling ATM endsystem can only send and receive
packets preceded by an LLC/SNAP identification. This memo requires
that hosts and routers which are ATM endsystems implement LLC/SNAP
encapsulation.
b) VC-multiplexing (D.3.2) and LLC/SNAP (D.3.1)
The calling ATM endsystem prefers to use VC multiplexing, but is
willing to agree to use LLC/SNAP encapsulation instead, if the called
ATM endsytem only supports LLC/SNAP.
c) RFC1490 encapsulation (NLPID multiplexing) over FRSSCS
(D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS
type of AAL Parameters IE.)
The calling ATM endsystem can only send and receive packets using RFC
1490 encapsulation (NLPID multiplexing) over FRSSCS. Use of RFC1490
encapsulation presently cannot be negotiated as an alternative to LLC
encapsulation or VC-multiplexing. If the B-LLI IE is encoded to
indicate RFC1490 encapsulation, the SSCS type field of the AAL
Parameters IE SHALL coded to indicate FRSSCS. Note that the AAL
Parameters IE can not be coded to indicate both NULL and FR-SSCS and
neither LLC encapsulation nor VC-multiplexing will be interoperable
when used over FR-SSCS.
The called ATM endsystem SHALL select the encapsulation method it is
able to support from the B-LLI IE present in SETUP message. If it
supports more than one of the encapsulations indicated in the SETUP
message, it MUST select the one which appears first in the SETUP
message. The called ATM endsystem then includes the B-LLI IE content
corresponding to the selected encapsulation in the CONNECT message.
If the called endsystem does not support any encapsulation indicated
in the incoming SETUP message, it SHALL clear the call with cause
#88, incompatible destination. If the received SETUP message does
not include the B-LLI IE, the call SHALL be cleared with cause #21,
"call rejected", with diagnostics indicating rejection reason =
information element missing and the B-LLI IE identifier. As
described in Annex C of [ATMF93], if the calling ATM endpoint
receives a CONNECT message that does not contain a B-LLI IE, it SHALL
assume the encapsulation indicated in the first BLLI IE that it
included in the SETUP message.