📄 rfc1755.txt
字号:
discussed in the following paragraphs and sections.
The Traffic Descriptor IE is accompanied by the Broadband Bearer
Capability IE and the QoS Parameter IE. Together these define the
signaling view of ATM traffic management. In this memo, we present
an agreed-on, required subset of traffic management capabilities, as
specified by using the three IEs. The figure immediately below shows
the set of the allowable combinations of traffic parameters which all
IP over ATM endsystems MUST support in their ATM signaling. The
subset includes Best Effort in the form of a non-guaranteed bitrate
combination (the rightmost column of the table below); a type of
traffic description that is intended for ATM "pipes", for example
between two routers (the middle column); and a type of traffic
description that will allow initial use of token-bucket style
characterizations of the source, as presented in RFC 1363 [PART92]
and RFC 1633, for example (the leftmost column).
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 12]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
Combinations of Traffic Related Paramenters
that MUST be supported in the SETUP message
|---------------------------------|
|Broadband Bearer |
|Capability |
|---------------------------------|
|Broadband Bearer | C | X | X |
|---------------------|---|---|---|
|Traffic Type | | | |
|(CBR,VBR) | |CBR| & |
|---------------------|---|---|---|
|Timing Required | |YES| &&|
|---------------------------------|
|Traffic Descriptor |
|Parameter |
|---------------------------------|
|PCR (CLP=0) | | | |
|---------------------|---|---|---|
|PCR (CLP=0+1) | S | S | S |
|---------------------|---|---|---|
|SCR (CLP=0) | | | |
|---------------------|---|---|---|
|SCR (CLP=0+1) | S | | |
|---------------------|---|---|---|
|MBS (CLP=0) | | | |
|---------------------|---|---|---|
|MBS (CLP=0+1) | S | | |
|---------------------|---|---|---|
|Best Effort | | | S |
|---------------------|---|---|---|
|Tagging | NO| NO| NO|
|---------------------------------|
|---------------------------------|
|QOS Classes | 0 | 0 | 0 |
-----------------------------------
S = Specified
& = 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
is absent; these three codings are treated as equivalent
Use of other allowable combinations of traffic parameters listed in
the large table in Appendix C may work, since they are allowed by
[ATMF94], but this will depend on the the calling endsystem, the
network, and the called endsystem.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 13]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
If Best Effort service is not use, link rate SHOULD not be requested
as the peak cell rate. Without any knowledge of the application, it
is RECOMMENDED that a fraction, such as 1/10th, of the the link
bandwidth be requested.
[ATMF93] does not provide any capability for negotiation of the ATM
traffic descriptor paramenters. This means that:
a) the calling endsystem SHOULD have some prior knowledge as to
the traffic contract that will be acceptable to both the
called endsystem and the network.
b) if, in response to a SETUP message, a calling endsystem
receive a RELEASE COMPLETE message, or a CALL PROCEEDING
message followed by a RELEASE COMPLETE message, with cause
#37, User Cell Rate Unavailable, it MAY examine the
diagnostic field of the Cause IE and reattempt the call after
selecting smaller values for the parameter(s) indicated. If
the RELEASE COMPLETE or RELEASE message is received with cause
#73, Unsupported combination of traffic parameter, it MAY
try other combinations from table 5-7 and 5-8 of [ATMF93].
c) the called endsystem SHOULD examine the ATM traffic descriptor
IE in the SETUP message. If it is unable to process cells at
the Forward PCR indicated, it SHOULD clear the call with cause
#37, User Cell Rate Unavailable.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 14]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
7.2. Broadband Bearer Capability
Broadband Bearer Connection Oriented Service Type X (BCOB-X) or Type
C (BCOB-C) are both applicable for multiprotocol interconnection,
depending on the service(s) provided by the ATM network and the
capabilities (e.g., for traffic shaping) of the ATM endsystem. The
table in the previous section showed the use of BCOB-X and BCOB-C
with other parameters. The figure below shows format and field
values for a BCOB-X when the Traffic Descriptor IE indicates Best
Effort.
Format and field values of Broadband Bearer Capability IE
----------------------------------------------------------
| bb_bearer_capability |
----------------------------------------------------------
| spare 0 |
| bearer_class 16 (BCOC-X) |
| spare 0 |
| traffic_type 0 (no indication) |
| timing_reqs 0 (no indication) |
| susceptibility_to_clipping 0 (not suscept) |
| spare 0 |
| user_plane_configuration 0 (point_to_point) |
----------------------------------------------------------
IP over ATM signaling MUST permit BCOB-C and BCOB-X, in the
combinations shown in the previous section. It MAY also permit one
of the allowable combinations shown in Appendix C.
Currently, there is no capability for negotiation of the broadband
bearer capability. This means that:
a) the calling endsystem SHOULD have some prior knowledge as to
the broadband bearer capability that will be acceptable to
both the called endsystem and the network.
b) if, in response to a SETUP message, a calling endsystem
receives a RELEASE COMPLETE message, or a CALL PROCEEDING
message followed by a RELEASE COMPLETE message, with cause
#57, bearer capability not authorized or #58 bearer capability
not presently available, it MAY reattempt the call after
selecting another bearer capability.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 15]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
7.3. QoS Parameter
The Unspecified QoS class (Class 0) is the only QoS class that must
be supported by all networks and the only QoS class allowed when
using the Best Effort service. The Specified QoS Class for Connection
Oriented Data Transfer (Class 3) or the Specified QoS Class for
Connectionless Data Transfer (Class 4) may be applicable to
multiprotocol over ATM, but their use has to be negotiated with the
network provider. The combinations of QoS parameters with the ATM
Traffic Descriptor and the Broadband Bearer Capability are detailed
in the Traffic Descriptor section and in Appendix C.
Format and field values of QoS Parameters IE
----------------------------------------------------------
| qos_parameter |
----------------------------------------------------------
| qos_class_fwd 0 (class 0) |
| qos_class_bkw 0 (class 0) |
----------------------------------------------------------
[ATMF93] does not provide any capability for negotiation of Quality
of Service parameters. This means that:
a) the calling endsystem SHOULD have some prior knowledge as to
the QoS classes offered by the ATM network in conjunction with
the requested Broadband Bearer Service and Traffic Descriptor.
b) if, in response to a SETUP message, a calling endsystem
receives a RELEASE COMPLETE message, or a CALL PROCEEDING
message followed by a RELEASE COMPLETE message, with cause
#49, Quality of Service Unavailable, it MAY reattempt the call
after selecting another QoS class.
Note: The two-bit 'coding standard' field of the General Information
octet in the IE header, SHOULD be set to '00' now that the ITU-T has
standardized QoS class 0. Endsystems SHOULD treat either value ('11'
or '00') as requesting the ITU-T QoS class.
7.4. ATM Addressing Information
ATM addressing information is carried in the Called Party Number,
Calling Party Number, and, under certain circumstance, Called Party
Subaddress, and Calling Party Subaddress IE. Section 5.8 of [ATMF93]
provides the procedure for an ATM endsystem to learn its own ATM
address from the ATM network, for use in populating the Calling Party
Number IE. Section 5.4.5.14 [ATMF94] describes the syntax and
semantics of the calling party subaddress IE.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 16]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
RFC 1577 RECOMMENDS that a router be able to provide multiple LIS
support with a single physical ATM interface that may have one or
more individual ATM endsystem addresses. Use of the Selector field
in the NSAPAs and E.164 addresses (in the NSAP format) is identified
as a way to differentiate up to 256 different LISs for the same ESI.
Therefore, an IP router MAY associate the IP addresses of the various
LISs it supports with distinct ATM addresses differentiated only by
the SEL field. If an IP router does this association, then its
signaling entity MUST carry in the SETUP message the ATM addresses
corresponding to the particular IP entity requesting the call, and
the IP entity it is requesting a call to. These ATM addresses are
carried in the Calling and Called Party Number IEs respectively.
Native E.164 addresses do not support a SEL field. For IP routers
residing in a Public UNI where native E.164 addresses are used it is
RECOMMENDED that multiple E.164 addresses be used to support multiple
LISs. Note: multiple LIS support is the only recommended use of the
SEL field. Use of this field is not recommended for selection of
higher level applications.
Resolution of IP addresses to ATM addresses is required of hosts and
routers which are ATM endsystems that use ATM SVCs. RFC 1577 provides
a mechanism for doing IP to ATM address resolution in the classical
IP model.
Format and field values of Called and Calling Party Number IE
----------------------------------------------------------
| called_party_number |
----------------------------------------------------------
| type_of_number (international number / unknown) |
| addr_plan_ident (ISDN / ATM Endsystem Address) |
| addr_number (E.164 / ATM Endsystem Address) |
----------------------------------------------------------
----------------------------------------------------------
| calling_party_number |
----------------------------------------------------------
| type_of_number (international number / unknown) |
| addr_plan_ident (ISDN / ATM Endsystem Address) |
| presentation_indic (presentation allowed) |
| spare 0 |
| screening_indic (user provided verified & passed) |
| addr_number (E.164 / ATM Endsystem Address |
----------------------------------------------------------
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 17]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -