📄 rfc1755.txt
字号:
If a call cannot be accepted, by the network or destination ATM end- point, a RELEASE COMPLETE is sent. At the destination ATM endpoint, the network offers the call using the SETUP message. If the destination endpoint is able to accept the call, it responds with a CONNECT message (which MAY be preceded by a CALL PROCEEDING); otherwise, it sends a RELEASE COMPLETE message. See Appendix A, Section 2 for guidance on the use of the CALL PROCEEDING message.Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 6] RFC 1755 ATM Signaling Support for IP over ATM February 1995 Call release can be initiated by either endpoint or (rarely) by the network. When an endpoint wishes to release a call, it sends a RELEASE message to the network. The network responds with a RELEASE COMPLETE message, frees up resources associated with the call, and initiates clearing toward the other endpoint. The network initiates clearing by sending a RELEASE message to the ATM endpoint, which reponds by sending a RELEASE COMPLETE message. Upon receipt of the RELEASE COMPLETE message, the network frees any resources associated with the call.5. Overview of Call Establishment Message Content Signaling messages are structured to contain mandatory and optional variable length information elements (IEs). IEs are further subdivided into octet groups, which in turn are divided into fields. IEs contain information related to the call, which is relevant to the network, the peer endpoint or both. Selection of optional IEs and the content of mandatory and optional IEs in a call establishment message determines the parties to and nature of the communication over the ATM connection. For example, the call establishment message for a call which will be used for constant bitrate video over AAL 1 will have different contents than a call which will be used for IP over AAL 5. A SETUP message which establishes an ATM connection to be used for IP and multiprotocol interconnection calls MUST contain the following IEs: AAL Parameters ATM Traffic Descriptor Broadband Bearer Capability Broadband Low Layer Information QoS Parameter Called Party Number Calling Party Number and MAY, under certain circumstance contain the following IEs: Calling Party Subaddress Called Party Subaddress Transit Network Selection In UNI 3.1, the AAL Parameters and the Broadband Low Layer Information IEs are optional in a SETUP message. However, in support of IP over ATM these two IEs MUST be included. Appendix A shows an example SETUP message coded in the manner indicated in this memo.Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 7] RFC 1755 ATM Signaling Support for IP over ATM February 19956. Information Elements with Endpoint to Endpoint Significance This section describes the coding of, and procedures surrounding, information elements in a SETUP message with significance only to the endpoints of an ATM call supporting IP.6.1. ATM Adaptation Layer Parameters The AAL Parameters IE (see section 5.4.5.5 and Annex F of [ATMF93]) carries information about the ATM Adaptation Layer (AAL) to be used on the connection. RFC 1483 specifies encapsulation of IP over AAL 5. Thus, AAL 5 MUST be indicated in the "AAL type" field. Coding and procedure related to the 'Forward and Backward Maximum CPCS-SDU Size' fields are discussed in [ATKI94]. Values may range from zero to 65,535. Although the default IP over AAL 5/ATM is 9188 bytes, endstations are encouraged to support MTU sizes up to and including 64k. Ordinarily, no Service Specific Convergence Sublayer (SSCS) will be used for multiprotocol interconnect over AAL5. Therefore, the SSCS 'type' field SHOULD be absent or, if present, coded to Null SSCS. Format and field values of AAL Parameters IE ---------------------------------------------------------- | aal_parameters | ---------------------------------------------------------- | aal_type 5 (AAL 5) | | fwd_max_sdu_size_identifier 140 | | fwd_max_sdu_size 65,535 (desired IP MTU) | | bkw_max_sdu_size_identifier 129 | | bkw_max_sdu_size 65,535 (desired IP MTU) | | sscs_type identifier 132 | | sscs_type 0 (null SSCS) | ----------------------------------------------------------6.2. Broadband Low Layer Information Selection of an encapsulation to support IP over an ATM VCC is done using the Broadband Low Layer Information (B-LLI) IE, along with the AAL Parameters IE, and the B-LLI negotiation procedure. RFC 1577 specifies LLC/SNAP as the default encapsulation. This encapsulation MUST be implemented by all endstations. LLC encapsulation MUST be signaled in the B-LLI as shown below. Signaling indication of other encapsulations is discussed in Appendix D, Section 4. Note that only LLC is indicated in the B-LLI. It is upPerez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 8] RFC 1755 ATM Signaling Support for IP over ATM February 1995 to the LLC layer to look into the encapsulation header of the packets following call setup. A B-LLI specifying both LLC and a layer_3_id SNAP layer is not recommended. If in those packets, the SNAP header indicates IP, it is the LLC layer's job to hand the packets up to IP. Format of B-LLI IE indicating LLC/SNAP encapsulation ---------------------------------------------------------- | bb_low_layer_information | ---------------------------------------------------------- | layer_2_id 2 | | user_information_layer 12 (lan_llc - ISO 8802/2) | ----------------------------------------------------------6.2.1. Framework for Protocol Layering The support of connectionless services from a connection oriented link layer exposes general problems of connection management, specifically the problems of connection acceptance, assignment of quality of service, and connection shutdown. For a connection to be associated with the correct protocol on the called host, it is necessary for information about one or more layers of protocol identification to be associated with a connection "management entity" or "endpoint". This association is what we call a binding in this memo. In this section we attempt to describe a framework for a usable binding or service architecture given the available IEs in the ATM call control messages. It is important to distinguish between two basic uses of protocol identification elements present in the UNI setup message. The first is the description of the protocol encapsulation that will be used on the data packet over the virtual connection, the second is the entity that will be responsible for managing the call. All protocols present in various IEs MUST be used to encapsulate the call, but the most specific, or highest, layer specified SHOULD manage the call. This defines a hierarchy of services and provides a framework for applications, including LLC and IP, to terminate calls. This hierarchy provides a clear mechanism for support of higher level protocol and application bindings, when their use and specification is defined in the appropriate standards bodies. In general, it would be desirable to allow data packets to be stored directly into an application's address space after connection is established. This is possible only if we have both encapsulation and managing entity indications in the signaling message.Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 9] RFC 1755 ATM Signaling Support for IP over ATM February 1995 The B-LLI is the only information element currently available in UNI 3.1 for designating protocol endpoints. It contains codepoints that describe layer 2 and layer 3 protocol entities associated with the call. There are other information elements under consideration in the ATM Forum and ITU, which could come to play a significant role in the description of application to connection binding, but their use is not yet defined, and they are not part of the framework described by RFC 1577. They include B-HLI, for containing information for a higher layer protocol, Network Layer Information (NLI) to contain information for the network layer, and UUI, which is meant to carry information for use by the top level application. The following figure shows a B-LLI that MAY be used for specifying in call setup that IP will manage the call and that this VC will be used only for IP traffic. Called parties MUST accept this B-LLI. The caller using VC MUST use LLC-SNAP encapsulation on all IP datagrams, despite the fact that the caller views the VC as dedicated to IP. The reason for this requirement is that while we require receivers to accept this form of call setup, they may choose whether or not to multiplex the call through LLC, in other words to ignore the Layer 3 information. This choice is dependent on the receiver's implementation's protocol architecture and is local to the receiver. Format of B-LLI IE indicating VC ownership by IP (NOTE: LLC/SNAP encapsulation is still used) ---------------------------------------------------------- | bb_low_layer_information | ---------------------------------------------------------- | layer_2_id 2 | | user_information_layer 12 (lan_llc - ISO 8802/2) | | layer_3_id 3 | | ISO/IEC TR 9577 IPI 204 (0xCC) | ---------------------------------------------------------- Null-encapsulated VCs are described in RFC 1483. Such a VC would result in the most direct form of binding a VC to IP. However, the method of signaling for this type of VC has not yet been integrated into the IP over ATM context. For completeness, we mention that the signaling would use a B-LLI containing the layer 3 identifier with the ISO/IEC TR-9577 protocol codepoint and omitting the layer 2 identifier [ATMF93]. Since no layer 2 is specified, frames produced by AAL processing would be given directly to IP. Processing of this B-LLI is not required at this time.Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 10] RFC 1755 ATM Signaling Support for IP over ATM February 19957. Information Elements with Significance to the ATM Network This section describes the coding of, and procedures surrounding, information elements with significance to the ATM network, as well as the endpoints of an ATM call supporting multiprotocol operation. The standards, implementation agreements, research and experience surrounding such issues as traffic management, quality of service and bearer service description are still evolving. Much of this material is cast to give the greatest possible latitude to ATM network implementation and service offerings. ATM endsystems need to match the traffic contract and bearer service they request from the network to the capabilities offered by the network. Therefore, this memo can only offer what, at the present time, are the most appropriate and efficient coding rules to follow for setting up IP and ATMARP VCCs. Future revisions of this memo may take advantage of ATM services and capabilities that are not yet available.7.1. ATM Traffic Descriptor The ATM traffic descriptor characterizes the ATM virtual connection in terms of peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst size. This information is used to allocate resources (e.g., bandwidth, buffering) in the network. In general, the ATM traffic descriptor for supporting multiprotocol interconnection over ATM will be driven by factors such as the capacity of the network, conformance definition supported by the network, performance of the ATM endsystem and (for public networks) cost of services. The most convenient model of IP behavior corresponds to the Best Effort Capability (see section 3.6.2.4 of [ATMF93]). If this capability is offered by the ATM network(s), it MAY be requested by including the Best Effort Indicator, the peak cell rate forward (CLP=0+1) and peak cell rate backward (CLP=0+1) fields in the ATM Traffic Descriptor IE. When the Best Effort Capability is used, no guarantees are provided by the network, and in fact, throughput may be zero at any time. This type of behavior is also described by RFC 1633 [BRAD94].Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 11] RFC 1755 ATM Signaling Support for IP over ATM February 1995 Format and field values of ATM Traffic Descriptor IE ---------------------------------------------------------- | traffic_descriptor | ---------------------------------------------------------- | fwd_peak_cell_rate_0+1_identifier 132 | | fwd_peak_cell_rate_0+1 (link rate) | | bkw_peak_cell_rate_0+1_identifier 133 | | bkw_peak_cell_rate_0+1 (link rate) | | best_effort_indication 190 | ---------------------------------------------------------- When the network does not support Best Effort Capability or more predictable ATM service is desired for IP, more specific traffic parameters MAY be specified and the Best Effort capability not used. Doing so includes use of two other traffic-related IEs and is 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).⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -