📄 rfc1755.txt
字号:
Network Working Group M. Perez
Request for Comments: 1755 ISI
Category: Standards Track F. Liaw
FORE Systems, Inc.
A. Mankin
E. Hoffman
ISI
D. Grossman
Motorola Codex
A. Malis
Ascom Timeplex, Inc.
February 1995
ATM Signaling Support for IP over ATM
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo describes the ATM call control signaling exchanges needed
to support Classical IP over ATM implementations as described in RFC
1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services
as specified in the ATM Forum User-Network Interface (UNI)
Specification Version 3.1 [ATMF94]. IP over ATM implementations
utilize the services of local ATM signaling entities to establish and
release ATM connections. This memo should be used to define the
support required by IP over ATM implementations from their local ATM
signaling entities.
This document is an implementors guide intended to foster
interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It
applies to IP hosts and routers which are also ATM endsystems and
assumes ATM networks that completely implement the ATM Forum UNI
Specification Version 3.1. Unless explicitly stated, no distinction
is made between the Private and Public UNI.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 1]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has
been produced by the ATM Forum, largely for reasons of alignment with
Recommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are
several changes that make the two versions incompatible. A
description of how to support IP over ATM using UNI 3.0 is found in
Appendix B.
Table of Contents
1. Conventions ............................................... 3
2. Overview .................................................. 3
3. Use of Protocol Procedures ................................ 4
3.1 VC Establishment ..................................... 4
3.2 Multiprotocol Support on VCs ........................ 4
3.3 Support for Multiple VCs ............................. 5
3.4 VC Teardown........................................... 6
4. Overview of UNI Call Setup Signaling ...................... 6
5. Overview of Call Establishment Message Content ............ 7
6. Information Elements with Endpoint Significance ........... 8
6.1 ATM Adaptation Layer Parameters ...................... 8
6.2 Broadband Low Layer Information ..................... 8
6.2.1 Framework for Protocol Layering ............... 9
7. Information Elements with Significance to the ATM Network . 11
7.1 ATM Traffic Descriptor ............................... 11
7.2 Broadband Bearer Capability .......................... 15
7.3 QoS Parameter......................................... 16
7.4 ATM Addressing Information ........................... 16
8. Dealing with Failure of Call Establishment................. 18
9. Security Considerations .................................... 18
10. Open Issues ............................................... 19
11. Acknowledgements........................................... 19
12. References ................................................ 19
13. Authors' Addresses ........................................ 20
Appendix A Sample Signaling Messages ......................... 22
Appendix B IP over ATM using UNI 3.0 Signaling ............... 25
Appendix C Combinations of Traffic Related Parameters ........ 27
Appendix D Frame Relay Interworking .......................... 28
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 2]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
1. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- the item is an absolute requirement
of the specification.
o SHOULD or RECOMMEND -- this item SHOULD generally be followed for
all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and MAY be followed
or ignored according to the needs of the implementor.
2. Overview
In a Switched Virtual Connection (SVC) environment, ATM virtual
channel connections (VCCs) are dynamically established and released
as needed. This is accomplished using the ATM call/connection control
signaling protocol, which operates between ATM endsystems and the ATM
network. The signaling entities use the signaling protocol to
establish and release calls (association between ATM endpoints) and
connections (VCCs). Signaling procedures include the use of
addressing to locate ATM endpoints and allocation of resource in the
network for the connection. It also provides indication and
negotiation between ATM endpoints for selection of end-to-end
protocols and their parameters. This memo describes how the
signaling protocol is used in support of IP over ATM, and, in
particular, the information exchanged in the signaling protocol to
effect this support.
IP address to ATM address resolution and routing issues are not in
the scope of this memo, and are treated as part of IP in figure 1.
+--------------+ +------+ +----------+
| | | |<--->| IP / ARP |
| |<--->| This | | RFC 1577 |
| ATM | | Memo | +----------+
| signaling | | |<--->| RFC 1483 |
| | +------+ +----------+
| | -------------> | AAL 5 |
| | +----------+
| | -------------> | ATM |
+--------------+ +----------+
Figure 1.
Relationship of this memo to IP, RFC 1483,
ATM signaling, ATM and AAL5
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 3]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
3. Use of Protocol Procedures
The following requirements are motivated to provide implementation
guidelines on how multiple ATM connections between peer systems
SHOULD be managed, to prevent connection thrashing and related
problems.
3.1. VC Establishment
The owner of an existing VCC is defined to be the entity within the
ATM endsystem that establishes the connection. An ATM endsystem MAY
establish an ATM call when it has a datagram to send and either there
is no existing VCC that it can use for this purpose, it chooses not
to use an existing VCC, (e.g., for reasons of route optimization or
quality of service), or the VCC owner does not allow sharing.
To reduce the latency of the address resolution procedure at the
called station, the following procedure MAY be used:
If a VCC is established using the LLC/SNAP encapsulation, the calling
endstation of the VCC MAY send an InARP_REQUEST to the called
endstation after the connection is established (i.e. received a
CONNECT message) and before the calling endstation sends the first
data packet. In addition, the calling endstation MAY send its data
packets without waiting for the InARP_REPLY. An endstation MAY
respond, generate, and manage its ATMARP table according to the
procedures specified in RFC1293 [BRAD92], Section 7, "Protocol
Operation", during the life time of the VCC.
To avoid establishing multiple VCCs to the same endstation, a called
endstation MAY associate the calling party number in the SETUP
message with the established VCC. This VCC MAY be used to transmit
data packets destined to a endstation whose ATMARP resolution results
in an ATM address that is the same as the associated calling party
number. Sharing of VCCs is subject to the policies configured at the
endstation as described in section 4.3 of this recommendation.
3.2. Multiprotocol Support on VCs
When two ATM endsystems run multiple protocols, an ATM connection MAY
be shared among two or more datagram protocol entities, as long as
the VCC owner allows sharing and if the encapsulation allows proper
multiplexing and demultiplexing (i.e. the LLC/SNAP encapsulation).
This indication of sharing a VCC MAY be by configuration or via an
API. Similarly, the Internet layer supports multiplexing of multiple
end-to-end transport sessions. To properly detect idle connections
while sharing a VCC among more than one higher layer protocol
entities, the ATM endsystem MUST monitor the traffic at the lowest
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 4]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
multiplexing layer.
3.3. Support for Multiple VCs
An ATMARP server or client MAY establish an ATM call when it has a
datagram to send and either there is no existing VCC that it can use
for this purpose, it chooses not to use an existing VCC, or the owner
of the VCC does not allow sharing. Note that there might be VCCs to
the destination which are used for IP, but an ARP server might prefer
to use a separate VCC for ARP only. The ATMARP server or client MAY
maintain or release the call as specified in RFC 1577. However, if
the VCC is shared among several protocol entities, the ATMARP client
or server SHALL NOT disconnect the call as suggested in RFC 1577.
Systems MUST be able to support multiple connections between peer
systems (without regard to which peer system initiated each
connection). They MAY be configured to only allow one such
connection at a time.
If a receiver accepts more than one call from a single source, that
receiver MUST then accept incoming PDUs on the additional
connection(s), and MAY transmit on the additional connections.
Receivers SHOULD NOT accept the incoming call, only to close the
connection or ignore PDUs from the connection.
Because opening multiple connections is specifically allowed,
algorithms to prevent connection call collision, such as the one
found in section 8.4.3.5 of ISO/IEC 8473 [ISO8473], MUST NOT be
implemented.
While allowing multiple connections is specifically desired and
allowed, implementations MAY choose (by configuration) to permit only
a single connection to some destinations. Only in such a case, if a
colliding incoming call is received while a call request is pending,
the incoming call MUST be rejected. Note that this MAY result in a
failure to establish a connection. In such a case, each system MUST
wait at least a configurable collision retry time in the range 1 to
10 seconds before retrying. Systems MUST add a random increment,
with exponential backoff.
Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 5]
RFC 1755 ATM Signaling Support for IP over ATM February 1995
3.4. VC Teardown
Either endsystem MAY close a connection. If the connection is closed
or reset while a datagram is being transmitted, the datagram is lost.
Systems SHOULD be able to configure a minimum holding time for
connections to remain open as long as the endpoints are up. (Note
that holding time, the time the connection has been open, differs
from idle time.) A suggested default value for the minimum holding
time is 60 seconds.
Because some public networks MAY charge for connection holding time,
and connections MAY be a scarce resource in some networks or
endsystems, each system implementing a Public ATM UNI interface MUST
support the use of a configurable inactivity timer to clear
connections that are idle for some period of time. The timer's range
SHOULD include a range from a small number of minutes to "infinite".
A default value of 20 minutes is RECOMMENDED. Systems which only
implement a Private ATM UNI interface SHOULD support the inactivity
timer. If implemented, the inactivity timer MUST monitor traffic in
both directions of the connection.
4. Brief Overview of UNI Call Setup Signaling Procedures and Messages
This section provides a summary of point-to-point signaling
procedures. Readers are referred to [ATMF93].
UNI signaling messages used for point-to-point call/connection
control are the following:
Call Setup Call Release
---------- ------------
SETUP RELEASE
CALL PROCEEDING RELEASE COMPLETE
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -