home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-03-25 | 52.8 KB | 1,624 lines |
-
-
- Network Working Group Muneyoshi Suzuki
- INTERNET DRAFT NTT
- Expires September 25, 1997 March 25, 1997
-
-
- ST2+ over ATM
- Protocol Specification - UNI 3.1 Version
- <draft-suzuki-st2-over-atm-01.txt>
-
- Status of this Memo
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- To learn the current status of any Internet-Draft, please check the
- "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-
- Abstract
-
- This document specifies an ATM-based protocol for communication
- between ST2+ agents. The ST2+ over ATM protocol supports the matching
- of one hop in an ST2+ tree-structure stream with one ATM connection.
- In this document, ATM is a subnet technology for the ST2+ stream.
-
- The ST2+ over ATM protocol is designed to achieve resource-
- reservation communications across ATM and non-ATM networks, to extend
- the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ
- signaling limitations.
-
- The specifications of the ST2+ over ATM protocol consist of a
- revision of RFC 1819 ST2+ and specifications of protocol interaction
- between ST2+ and ATM on the user plane, management plane, and control
- plane which correspond to the three planes of the B-ISDN protocol
- reference model.
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 1]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 1. Introduction
-
- 1.1 Purpose of Document
-
- The purpose of this document is to specify an ATM-based protocol for
- communication between ST2+ agents.
-
- The ST2+ over ATM protocol is designed to support the matching of one
- hop in an ST2+ tree-structure stream with one ATM connection; it is
- not designed to support an entire ST2+ tree-structure stream with a
- point-to-multipoint ATM connection only.
-
- Therefore, in this document, ATM is only a subnet technology for the
- ST2+ stream. This specification is designed to enable resource-
- reservation communications across ATM and non-ATM networks.
-
-
- 1.2 Features of ST2+ over ATM Protocol
-
- o Enables resource-reservation communications across ATM and non-ATM
- networks.
-
- ATM native API supports resource-reservation communications only
- within an ATM network; it cannot support interworking with non-ATM
- networks. This is because
-
- - ATM native API cannot connect terminals without an ATM interface.
-
- - ATM native API does not support IP addressing and SAP (port)
- addressing systems.
-
- o Extends UNI 3.1/4.0 signaling functions.
-
- ST2+ SCMP supports MTU-size negotiation at all hops in an ST2+
- tree-structure stream. UNI 3.1/4.0 supports only max CPCS_SDU
- (i.e., MTU) negotiation with the called party of a point-to-point
- call or with the first leaf of a point-to-multipoint call.
-
- o Reduces UNI 4.0 LIJ signaling limitations.
-
- The ST2+ over ATM protocol supports UNI 4.0 LIJ Call Identifier
- notification from the root to the leaf by using an ST2+ SCMP
- extension. LIJ Call Identifier discovery at the leaf is one of the
- major unsolved problems of UNI 4.0, and the ST2+ over ATM protocol
- provides a solution.
-
- Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
- support the above feature. It will be supported by the UNI 3.1/4.0
-
-
-
- Suzuki Expires September, 1997 [Page 2]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- version.
-
-
- 1.3 Goals and Non-goals of ST2+ over ATM Protocol
-
- The ST2+ over ATM protocol is designed to achieve the following
- goals.
-
- o Specify protocol interaction between ST2+ [4] and ATM on the ATM
- Forum Private UNI 3.1/4.0 (Sb point) [5].
-
- Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
- support UNI 4.0. It will be supported by the UNI 3.1/4.0 version.
-
- o Support ST2+ stream across ATM and non-ATM networks.
-
- o Define one VC on the UNI corresponding to one ST2+ hop; this VC is
- not shared with other ST2+ hops, and also this ST2+ hop is not
- divided into multiple VCs.
-
- o Support both SVC and PVC.
-
- o Not require any ATM specification changes.
-
- o Coexist with RFC 1483 [14] IPv4 encapsulation.
-
- o Coexist with RFC 1577 [15] ATMarp.
-
- o Coexist with RFC 1755 [16] ATM signaling for IPv4.
-
- o Coexist with NHRP [17].
-
- o Incorporate the I.371 [13] ITU-T new traffic control recommendation
- for ATM WAN connectivity.
-
- Because ST2+ is independent of both routing and IP address resolution
- protocols, the ST2+ over ATM protocol does not specify the following
- protocols.
-
- o IP-ATM address resolution protocol
-
- o Routing protocol
-
- Because the ST2+ over ATM protocol is specified for the UNI, it is
- independent of:
-
- o NNI protocol
-
-
-
-
- Suzuki Expires September, 1997 [Page 3]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- o Router/switch architecture
-
-
- 2. Protocol Architecture
-
- The ST2+ over ATM protocol specifies the interaction between ST2+ and
- ATM on the user, management, and control planes, which correspond to
- the three planes in ITU-T Recommendation I.321 B-ISDN Protocol
- Reference Model [10].
-
-
- 2.1 User Plane Architecture
-
- The user plane specifies the rules for encapsulating the ST2+ Data
- PDU into the AAL5 [12] or AAL1 [11] PDU. An user plane protocol stack
- is shown in Fig. 2.1.
-
- +---------------------------------+
- | RFC 1819 ST2+ |
- | (ST2+ Data) |
- +---------------------------------+ Point of ST2+ over ATM
- |/////////////////////////////////| <--- protocol specification of
- +----------------+----------------+ user plane
- | | |
- | | |
- | I.363.1 | I.363.5 |
- | | |
- | AAL1 | AAL5 |
- | | |
- | | |
- +----------------+----------------+
- | I.361 ATM |
- +---------------------------------+
- | PHY |
- +----------------+----------------+
- | UNI
- +--------||-------
-
- Fig. 2.1: User plane protocol stack.
-
- If AAL1 is used for encapsulating the ST2+ Data PDU, the 12 bytes ST
- header is not mapped to the AAL1 PDU, and the value of the Pri field
- in the ST2+ Data PDU header is lost.
-
- An example of interworking from an ATM network to an IEEE 802.X LAN
- is shown in Fig. 2.2.
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 4]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- ST2+ ST2+ ST2+
- Origin ATM Cloud Intermediate Agent Target
- +---------+ +---------+
- | AP |--------------------------------------------->| AP |
- +---------+ +-------------------+ +---------+
- |ST2+ Data|------------------>| RFC 1819 ST2+ Data|----->|ST2+ Data|
- +---------+ +---------+---------+ +---------+
- |I.363 AAL|------------------>|I.363 AAL| SNAP |----->| SNAP |
- +---------+ +---------+ +---------+---------+ +---------+
- |I.361 ATM|--->|I.361 ATM|--->|I.361 ATM| LLC |----->| LLC |
- +---------+ +---------+ +---------+---------+ +---------+
- | PHY |--->| PHY |--->| PHY |IEEE802.X|----->|IEEE802.X|
- +---------+ +---------+ +---------+---------+ +---------+
-
- Fig. 2.2: Example of interworking from
- an ATM network to an IEEE 802.X LAN.
-
- The ATM cell supports priority indication using the CLP field;
- indication is also supported by the ST2+ Data PDU by using the Pri
- field. It may be feasible to map these fields to each other. The
- ST2+ over ATM protocol specifies an optional function that maps the
- Pri field in the ST header to the CLP field in the ATM cell.
- However, implementors should note that current ATM standardization
- tends not to support tagging, and also that this optional function
- assumes the value of the Pri field can be obtained in the ATM
- network.
-
-
- 2.2 Management Plane Architecture
-
- The management plane specifies, or refers to a document that
- specifies, the Controlled-Load Service [6] FlowSpec and the
- Guaranteed Service [7] FlowSpec mapping rules for UNI 3.1 traffic
- management. A management plane protocol stack is shown in Fig. 2.3.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 5]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- +---------------------------------+
- |Controlled-Load Service FlowSpec |
- | Guaranteed Service FlowSpec |
- +---------------------------------+ Point of ST2+ over ATM
- |/////////////////////////////////| <--- protocol specification of
- +---------------------------------+ management plane
- | |
- | UNI 3.1/4.0 |
- | |
- | |
- | Traffic Management |
- | |
- | |
- | CBR/VBR/UBR |
- | |
- +---------------------------------+
- Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
- support UNI 4.0. It will be supported by the UNI 3.1/4.0 version.
-
- Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
- support Guaranteed Services. It will be supported by the UNI 3.1/4.0
- version.
-
- Fig. 2.3: Management plane protocol stack.
-
- The ST2+ over ATM protocol specifies the ST FlowSpec format for the
- Integrated Services. Basically, FlowSpec parameter negotiation,
- except for the MTU, is not supported. This is because, in the ST2+
- environment, negotiated FlowSpec parameters are not always unique to
- each target. The current ATM standard does not support heterogeneous
- QoS to receivers.
-
- The ST2+ over ATM protocol supports FlowSpec changes by using the
- CHANGE message (RFC 1819, Section 4.6.5) if the I-bit in the CHANGE
- message is set to one and if the CHANGE message affects all targets
- in the stream. This is because the current ATM standard does not
- support QoS changes. The ST2+ over ATM protocol supports FlowSpec
- changes by releasing old ATM connections and establishing new ones.
-
- The ST2+ over ATM protocol does not support stream preemption (RFC
- 1819, Section 6.3). This is because the Integrated Services FlowSpec
- does not support the concept of precedence.
-
- It does not support the ST2+ FlowSpec (RFC 1819, Section 9.2). ST2+
- FlowSpec specifies useful services, but requires a data link layer to
- support heterogeneous QoS to receivers. The current ATM standard
- does not support heterogeneous QoS to receivers.
-
-
-
-
- Suzuki Expires September, 1997 [Page 6]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 2.3 Control Plane Architecture
-
- The control plane specifies the relationship between ST2+ SCMP and
- PVC management for ST2+ data and the protocol interaction between
- ST2+ SCMP and Q.2931 UNI signaling [5, 9]. A control plane protocol
- stack is shown in Fig. 2.4.
-
- +---------------------------------+
- | RFC 1819 ST2+ |
- | (ST2+ SCMP) |
- +---------------------------------+ Point of ST2+ over ATM
- |/////////////////////////////////| <--- protocol specification of
- +----------------+----------------+ control plane
- | IEEE 802 |Q.2931 Signaling|
- | SNAP +----------------+
- +----------------+ Q.2130 SSCF |
- | ISO 8802-2 +----------------+
- | LLC Type1 | Q.2110 SSCOP |
- +----------------+----------------+
- | I.363.5 AAL5 |
- +---------------------------------+
- | I.361 ATM |
- +---------------------------------+
- | PHY |
- +----------------+----------------+
- | UNI
- +--------||-------
-
- Fig. 2.4: Control plane protocol stack.
-
- The ST2+ SCMP PDU is mapped to the AAL5 PDU based on the RFC 1483 LLC
- encapsulation format. The ST2+ over ATM protocol does not cover a VC
- (SVC/PVC) that transfers ST2+ SCMP. VCs for IPv4 transfer may be used
- for ST2+ SCMP transfer, and implementations may provide particular
- VCs for ST2+ SCMP transfer. Selection of these VCs depends on the
- implementation.
-
- Implementors should note that when ST2+ data and SCMP belong to a
- stream, the routing directions on the ST2+ layer must be the same.
- Implementors should also note that ST2+ and IPv4 directions for
- routing to the same IP destination address are not always the same.
-
- The ST2+ over ATM protocol supports both SVC and PVC for ST2+ Data
- PDU transfer. If SVC is used, the ST2+ and ATM layers establish a
- connection sequentially by using respectively ST2+ SCMP and Q.2931.
- An example of ST2+ SCMP and Q.2931 message flows for establishing and
- releasing of ST2+ data connections is shown in Fig. 2.5, where (S)
- means an ST2+ entity and (Q) means a Q.2931 entity.
-
-
-
- Suzuki Expires September, 1997 [Page 7]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- ATM SW ATM SW
- +------------+ UNI +----+ NNI +----+ UNI +------------+
- ____|Intermediate|--||--| \/ |______| \/ |--||--|Intermediate|____
- | (Upstream) | | /\ | | /\ | |(Downstream)|
- +------------+ +----+ +----+ +------------+
- SCMP
- ------->(S)<------------------------------------------>(S)<-------
- \ Q.2931 Q.2931 /
- CONNECT | (Q)<--------->(Q)<-------->(Q)<--------->(Q) |
- -------->| |
- ACK <----|--------------------CONNECT------------------>| CONNECT
- |<---------------------ACK---------------------|-------->
- | |<--- ACK
- | | ACCEPT
- | |<--------
- |<-------------------ACCEPT--------------------|---> ACK
- |----------------------ACK-------------------->|
- | |
- |->|----SETUP--->| | | |
- | |<-CALL PROC--|----------->|----SETUP--->|->|
- | | | |<----CONN----|<-|
- ACCEPT | |<----CONN----|<-----------|--CONN ACK-->|->|
- <--------|<-|--CONN ACK-->| | | |
- ACK ---->| |
- | |
- -------\ |--------------------------------------------\ |-------\
- >| ST2+ Data >| >
- -------/ |--------------------------------------------/ |-------/
- | |
- DISCONN | |
- -------->| |
- ACK <----|-------------------DISCONNECT---------------->|
- |<---------------------ACK---------------------|
- | |
- |->|---RELEASE-->| | | |
- |<-|<--REL COMP--|----------->|---RELEASE-->|->| DISCONN
- | | | |<--REL COMP--|<-|-------->
- | |<--- ACK
-
- Fig. 2.5: Example of ST2+ SCMP and Q.2931 message flows.
-
- UNI 3.1/4.0 specifies PVC, point-to-point SVC, and point-to-
- multipoint SVC as VC styles. However, in actual ATM network
- environments, especially public ATM WANs, only PVC and bi-directional
- point-to-point SVC may be supported. To support the diverse VC
- styles, the ST2+ over ATM protocol supports the following VC styles
- for ST2+ Data PDU transfer.
-
-
-
-
- Suzuki Expires September, 1997 [Page 8]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- o PVC
-
- o Reuse of reverse channel of bi-directional point-to-point SVC that
- is used by existing stream.
-
- o Point-to-point SVC initiated from upstream side.
-
- o Point-to-multipoint SVC initiated from upstream side.
-
- o Point-to-point SVC initiated from downstream side.
-
- o Point-to-multipoint SVC initiated from downstream side (LIJ).
-
- Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
- support LIJ. LIJ will be supported by the UNI 3.1/4.0 version.
-
- The second style is needed in environments supporting bi-directional
- point-to-point SVC only. The selection of PVC and SVC styles in the
- ST2+ agent is based on preconfigured implementation-dependent rules.
-
- SVC supports both upstream and downstream call initiation styles.
- Implementors should note that this is independent of the sender-
- oriented and receiver-oriented ST2+ stream-building process (RFC
- 1819, Section 4.1.1). This is because the ST2+ over ATM protocol
- specifies the process for establishing ST2+ data hops on the UNI, and
- because the ST2+ stream building process belongs to another layer.
- The SVC initiation side should be determined based on the operational
- and billing policies between ST2+ agents; this is basically
- independent of the sender-oriented and receiver-oriented ST2+
- stream-building process.
-
- An example of ST2+ SCMP interworking is shown in Fig. 2.6.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 9]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- _____
- / \
- (Origin )
- \ /
- A ~~|~~ A
- | = | UNI Signaling
- | | |
- | +-+-+ V
- | | X | ATM SW
- | +-+-+ A
- SCMP | | | NNI Signaling
- | +-+-+ V
- | | X | ATM SW
- | +-+-+ A
- | | |
- | = | UNI Signaling
- V | V
- +-----+------+ Non-ATM Link
- |Intermediate|--------------------+
- | Agent |<-----------------+ |
- +------------+ SCMP | |
- A | A | |
- | = | UNI Signaling | |
- | | | | |
- | +-+-+ V V_|__
- | | X | ATM SW / \
- | +-+-+ A (Target )
- SCMP | | | NNI Signaling \ /
- | +-+-+ V ~~~~~
- | | X | ATM SW
- | +-+-+ A
- | | |
- | = | UNI Signaling
- V __|__ V
- / \
- (Target )
- \ /
- ~~~~~
-
- Fig. 2.6: Example of ST2+ SCMP interworking.
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 10]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 3. Revision of RFC 1819 ST2+
-
- To specify the ST2+ over ATM protocol, the functions in RFC 1819 ST2+
- must be extended to support ATM. However, it is difficult for the
- current ATM standard to support part of the specifications in RFC
- 1819 ST2+. This section specifies the extended, restricted, and
- unsupported functions in RFC 1819 ST2+. Errata for RFC 1819 appears
- in Appendix A.
-
-
- 3.1 Extended Functions of RFC 1819 ST2+
-
- 3.1.1 ST FlowSpec for Controlled-Load Service
-
- The ST2+ over ATM protocol specifies the ST FlowSpec format for the
- Integrated Services. Basically, FlowSpec parameter negotiation,
- except for the MTU, is not supported. The ST2+ intermediate agent
- and the target decide whether to accept or refuse the FlowSpec
- parameters, except for the MTU. Therefore, each of the FlowSpec
- parameter values other than MTU is the same at each target in the
- stream.
-
- The format of the ST FlowSpec for the Controlled-Load Service is
- shown in Fig. 3.1.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | PCode = 1 | PBytes = 36 | ST FS Ver = 8 | 0(unused) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ver=0 | 0(reserved) | Overall Length = 7 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | SVC Number |0| 0(reserved) | SVC Length = 6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |Param Num = 127| Flags = 0 | Param Length = 5 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Token Bucket Rate [r] (32-bit IEEE floating point number) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Token Bucket Size [b] (32-bit IEEE floating point number) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Peak Data Rate [p] (32-bit IEEE floating point number) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Minimum Policed Unit [m] |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Maximum Packet Size [M] |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Fig. 3.1: Format of ST FlowSpec for Controlled-Load Service.
-
-
-
- Suzuki Expires September, 1997 [Page 11]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- The PCode field identifies common SCMP elements. The PCode value
- for the ST2+ FlowSpec is 1.
-
- The PBytes field for the Controlled-Load Service is 36 bytes.
-
- The ST FS Ver (ST FlowSpec Version) field identifies the ST
- FlowSpec version. The ST FlowSpec version number for the
- Integrated Services is 8.
-
- The Ver (Message Format Version) field identifies the Integrated
- Services FlowSpec message format version. The current version is
- zero.
-
- The Overall Length field for the Controlled-Load Service is 7
- words.
-
- The SVC Number (Service ID Number) field identifies the Integrated
- Services. If the Integrated Services FlowSpec appears in the
- CONNECT or the CHANGE message, the value of the SVC Number field is
- 1. If it appears in the ACCEPT, the NOTIFY, or the STATUS-RESPONSE
- message, the value of the SVC Number field is 5.
-
- The SVC Length (Service-specific Data Length) field for the
- Controlled-Load Service is 6 words.
-
- The Param Num (Parameter Number) field is 127.
-
- The Flags (Per-parameter Flags) field is zero.
-
- The Param Length (Length of Per-parameter Data) field is 5 words.
-
- Definitions of the Token Bucket Rate [r], the Token Bucket Size
- [b], the Peak Data Rate [p], the Minimum Policed Unit [m], and the
- Maximum Packet Size [M] fields are given in [6]. See section 5 of
- [6] for details.
-
- The ST2+ agent, that creates the FlowSpec element in the SCMP
- message, must assign valid values to all fields. The other agents
- must not modify any values in the element.
-
- The MaxMsgSize field in the CONNECT message is assigned by the origin
- or the intermediate agent acting as origin, and updated by each agent
- based on the MTU value of the datalink layer.
-
- The negotiated value of MaxMsgSize is set back to the origin or the
- intermediate agent acting as origin using the [M] field and the
- MaxMsgSize field in the ACCEPT message that corresponds to the
- CONNECT message.
-
-
-
- Suzuki Expires September, 1997 [Page 12]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- In the original definition of the Controlled-Load Service, the value
- of the [m] field must be less than or equal to the value of the [M]
- field. However, in the ST FlowSpec for the Controlled-Load Service,
- if the value of the [m] field is more than that of the [M] field, the
- value of the [m] field is regarded as the same value as the [M]
- field, and must not generate an error. This is because there is a
- possibility that the value of the [M] field in the ACCEPT message may
- be decreased by negotiation.
-
- In the ST2+ SCMP messages, the value of the [M] field must be equal
- to or less than 65,535. In the ACCEPT message that responds to
- CONNECT, or the NOTIFY message that contains the FlowSpec field, the
- value of the [M] field must be equal to the MaxMsgSize field in the
- message. If these values are not the same, FlowSpec is regarded as
- an error.
-
- If the ST2+ agent receives the CONNECT message that contains
- unacceptable FlowSpec, the agent must generate a REFUSE message.
-
- 3.1.2 ST FlowSpec for Guaranteed Service
-
- Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
- support Guaranteed Services. It will be supported by the UNI 3.1/4.0
- version.
-
- 3.1.3 VC-type common SCMP element
-
- The ST2+ over ATM protocol specifies an additional common SCMP
- element that designates the VC type used to support the diverse VC
- styles. The CONNECT and CHANGE messages that pass across UNIs must
- contain a VC-type common SCMP element. This element is valid between
- neighboring ST2+ agents, but must not propagate beyond the previous-
- hop or next-hop ST2+ agent.
-
- The format of the VC-type common SCMP element is shown in Fig. 3.2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 13]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | PCode = 8 | PBytes = 20 | VCType |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | PVCIdentifer |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 0(unused) | UniqueID |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | OriginIPAddress |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LIJCallIdentifer |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Fig. 3.2: Format of VC-type common SCMP element.
-
- The PCode field identifies the common SCMP elements. The PCode
- value for the VC type is 8.
-
- The PBytes field for the VC type is 20 bytes.
-
- The VCType field identifies the VC type. The correspondence
- between the value in this field and the meaning is as follows:
-
- 0: ST2+ data stream uses a PVC.
-
- 1: ST2+ data stream uses the reverse channel of the bi-
- directional point-to-point SVC used by the existing stream.
-
- 2: ST2+ data stream is established by a point-to-point SVC
- initiated from the upstream side.
-
- 3: ST2+ data stream is established by a point-to-multipoint SVC
- initiated from the upstream side.
-
- 4: ST2+ data stream is established by a point-to-point SVC
- initiated from the downstream side.
-
- 5: ST2+ data stream is established by a point-to-multipoint SVC
- initiated from the downstream side.
-
- Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
- support VCType 5. It will be supported by the UNI 3.1/4.0
- version.
-
- The PVCIdentifer field identifies the PVC identifier uniquely
- assigned between neighboring ST2+ agents. This field is valid only
- when the VCType field is zero.
-
-
-
- Suzuki Expires September, 1997 [Page 14]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- The UniqueID and OriginIPAddress fields identify the reverse
- channel of the bi-directional point-to-point SVC that is used by
- this SID. These fields are valid only when the VCType field is 1.
-
- The LIJCallIdentifer field identifies the LIJ Call Identifier for
- point-to-multipoint SVC. This field is valid only when the VCType
- field is 5.
-
- 3.1.4 Reason Code
-
- The extension of the Reason Code (RFC 1819, Section 10.5.3) to the
- ST2+ over ATM protocol is shown below.
-
- 57 CantChange Partial changes not supported.
- 58 NoRecover Stream recovery not supported.
-
-
- 3.2 Restricted Functions of RFC 1819 ST2+
-
- 3.2.1 Pri field in ST2+ Data PDU
-
- If AAL1 is used for encapsulating the ST2+ Data PDU, the value of the
- Pri field in the ST2+ Data PDU header is lost.
-
- 3.2.2 FlowSpec changes
-
- In the following cases, the ST2+ over ATM protocol supports stream
- FlowSpec changes by using the CHANGE message.
-
- o The I-bit is set to 1 and the G-bit is set to 1.
-
- o The I-bit is set to 1, the G-bit is set to zero, and the TargetList
- matches all downstream targets.
-
- In the following cases, the CHANGE fails and a REFUSE message, with
- the E and N-bits set to 1 and the ReasonCode set to CantChange, is
- propagated upstream.
-
- o The I-bit is set to zero.
-
- o The I-bit is set to 1, the G-bit is set to zero, and the TargetList
- does not match all downstream targets.
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 15]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 3.3 Unsupported Functions of RFC 1819 ST2+
-
- 3.3.1 ST2+ FlowSpec
-
- The ST2+ over ATM protocol does not support the ST2+ FlowSpec (RFC
- 1819, Section 9.2). The ST2+ FlowSpec specifies useful services, but
- requires the data link layer to support heterogeneous QoS to
- receivers. The current ATM standard does not support heterogeneous
- QoS to receivers.
-
- 3.3.2 Stream preemption
-
- The ST2+ over ATM protocol does not support stream preemption (RFC
- 1819, Section 6.3). This is because the Integrated Services FlowSpec
- does not support the concept of precedence.
-
- 3.3.3 HELLO message
-
- Implementations may not support the HELLO message (RFC 1819, Section
- 10.4.7) and thus ST2+ agent failure detection using the HELLO message
- (RFC 1819, Section 6.1.2). This is because ATM has an adequate
- failure detection mechanism, and the HELLO message is not sufficient
- for detecting link failure in the ST2+ over ATM protocol, because the
- ST2+ data and the ST2+ SCMP are forwarded through another VC.
-
- 3.3.4 Stream recovery
-
- Implementors must select the NoRecover option of the CONNECT message
- (RFC 1819, Section 4.4.1) with the S-bit set to 1. This is because
- the descriptions of the stream recovery process in RFC 1819 (Sections
- 5.3.2, 6.2, and 6.2.1) are unclear and incomplete. It is thus
- possible that if a link failure occurs and several ST2+ agents detect
- it simultaneously, the recovery process may encounter problems.
-
- The ST2+ over ATM protocol does not support stream recovery. If
- recovery is needed, the application should support it. A CONNECT
- message in which the NoRecover option is not selected will fail; a
- REFUSE message in which the N-bit is set to 1 and the ReaseonCode is
- set to NoRecover is then propagated upstream.
-
- 3.3.5 IP encapsulation of ST
-
- The ST2+ over ATM protocol does not support IP encapsulation of ST
- (RFC 1819, Section 8.7), because there is no need to implement IP
- encapsulation in this protocol.
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 16]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 3.3.6 IP Multicasting
-
- The ST2+ over ATM protocol does not support IP multicasting (RFC
- 1819, Section 8.8), because this protocol does not support IP
- encapsulation of ST.
-
-
- 4. Protocol Specification of the User Plane
-
- This section specifies the AAL5 [12] and AAL1 [11] PDU
- encapusulations for the ST2+ Data PDU. On the ST2+ over ATM user
- plane, AAL5 support is mandatory and AAL1 support is optional.
-
-
- 4.1 Service Primitives Provided by User Plane
-
- 4.1.1 Overview of interactions
-
- The ST2+ data layer entity on the user plane of the ST2+ over ATM
- protocol provides the following services to the upper layer.
-
- o st2p_unitdata.req
-
- o st2p_unitdata.ind
-
- 4.1.1.1 St2p_unitdata.req
-
- The st2p_unitdata.req primitive sends a request for an ST2+ Data PDU
- transfer to the ST2+ data layer entity. The semantics of the
- primitive are as follows:
-
- st2p_unitdata.req (
- pri,
- sid,
- data
- )
-
- The pri parameter specifies priority of ST2+ Data PDU. The sid
- parameter specifies SID of ST2+ Data PDU. The data parameter
- specifies ST2+ data to be transferred.
-
- 4.1.1.2 St2p_unitdata.ind
-
- The st2p_unitdata.ind primitive indicates an ST2+ Data PDU delivery
- from the ST2+ data layer entity. The semantics of the primitive are
- as follows:
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 17]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- st2p_unitdata.ind (
- pri [optional],
- sid,
- data,
- status [optional]
- )
-
-
- The pri parameter indicates priority of ST2+ Data PDU, if AAL5 is
- used for encapsulating the ST2+ Data PDU. The sid parameter
- indicates SID of ST2+ Data PDU. The data parameter indicates
- delivered ST2+ data. The status is an optional parameter that
- indicates whether the delivered ST2+ data is corrupt or not.
-
-
- 4.2 Service Primitives Provided by AAL5
-
- 4.2.1 Requirements for AAL5
-
- The requirements for the AAL5 layer on the ST2+ over ATM user plane
- are as follows:
-
- o The SSCS must be null.
-
- o Implementations must use message-mode service.
-
- Note: Selection of the corrupted SDU delivery option on the
- receiver side depends on the implementation, so the receiver may or
- may not be able to select this option.
-
- 4.2.2 Overview of Interactions
-
- The AAL5 layer entity on the ST2+ over ATM user plane provides the
- following services to the ST2+ data layer.
-
- o AAL5_UNITDATA.req
-
- o AAL5_UNITDATA.ind
-
- 4.2.2.1 AAL5_UNITDATA.req
-
- The AAL5_UNITDATA.req primitive sends a request for an AAL5 data
- (AAL5 CPCS_SDU) transfer from the ST2+ data layer entity to the AAL5
- layer entity. The semantics of the primitive are as follows:
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 18]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- AAL5_UNITDATA.req (
- DATA,
- CPCS_LP,
- CPCS_UU
- )
-
- The DATA parameter specifies the AAL5 data to be transferred. The
- CPCS_LP parameter specifies the value of the CLP field in the ATM
- cell. The CPCS_UU parameter specifies the user-to-user data to be
- transferred.
-
- 4.2.2.2 AAL5_UNITDATA.ind
-
- The AAL5_UNITDATA.ind indicates an AAL5 data (AAL5 CPCS_SDU) delivery
- from the AAL5 layer entity to the ST2+ data layer entity. The
- semantics of the primitive are as follows:
-
- AAL5_UNITDATA.ind (
- DATA,
- CPCS_LP,
- CPCS_UU,
- STATUS [optional]
- )
-
- The DATA parameter indicates the delivered AAL5 data. The CPCS_LP
- parameter indicates the value of the CLP field in the ATM cell. The
- CPCS_UU parameter indicates the delivered user-to-user data. The
- STATUS parameter indicates whether the delivered AAL5 data is corrupt
- or not. The STATUS parameter is an optional parameter, and valid
- only when the corrupted SDU delivery option is selected.
-
-
- 4.3 AAL5 Encapsulation for ST2+ Data PDU
-
- 4.3.1 Mapping from st2_unitdata.req to AAL5_UNITDATA.req
-
- The ST2+ Data PDU is directly assigned to the DATA parameter in
- AAL5_UNITDATA.req. That is, as shown in Fig. 4.1, the ST2+ Data PDU
- is mapped to the payload of AAL5 CPCS_PDU.
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 19]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- +-------+---------------------------+
- | ST | ST2+ data | ST2+
- | header| | Data PDU
- +-------+---------------------------+
- : :
- : :
- +---------------------------------------+--------+
- | CPCS_PDU |PAD|CPCS_PDU| AAL5
- | payload | |trailer | CPCS_PDU
- +---------------------------------------+--------+
-
- Fig. 4.1: Mapping of ST2+ data to AAL5 CPCS_PDU payload.
-
- The value of CPCS_LP in AAL5_UNITDATA.req depends on the
- implementation: 1 (low priority) or zero (high priority) may be
- assigned permanently, or they may be assigned depending on the value
- of pri in st2_unitdata.req.
-
- The value of the CPCS_UU indication field in AAL5_UNITDATA.req is set
- to zero.
-
- 4.3.2 Mapping from AAL5_UNITDATA.ind to st2p_unitdata.ind
-
- The DATA parameter in AL5_UNITDATA.ind is directly assigned to the
- ST2+ Data PDU. That is, the payload in AAL5 CPCS_PDU is mapped to
- the ST2+ Data PDU.
-
- If the value of STATUS in AAL5_UNITDATA.ind is valid, it is assigned
- to the status in st2p_unitdata.ind.
-
- 4.3.3 Value of MTU
-
- The value of MTU is Maximum CPCS_SDU size.
-
-
- 4.4 Service Primitives Provided by AAL1
-
- 4.4.1 Requirements for AAL1
-
- The requirements for the AAL1 layer on the ST2+ over ATM user plane
- are as follows:
-
- o The CS must support the synchronous circuit transport function
- described in ITU-T Recommendation I.231. The others CS functions
- need not be supported.
-
- o Structured data transfer and forward error correction need not be
- supported.
-
-
-
- Suzuki Expires September, 1997 [Page 20]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- o The CBR rate is N * 64 Kbit/s, where N is between 1 and 65,535.
-
- Note: It is recommended to support 1, 2, 3, 4, 5, 6, 8, 9, 10, 12,
- 15, 18, 20, 24, 30, 36, 40, 45, 60, 72, 90, 120, 180, and 360 as
- values of N.
-
- 4.4.2 Overview of interactions
-
- The AAL1 layer entity on the ST2+ over ATM user plane provides the
- following services to the ST2+ data layer.
-
- o AAL1_UNITDATA.req
-
- o AAL1_UNITDATA.ind
-
- 4.4.2.1 AAL1_UNITDATA.req
-
- The AAL1_UNITDATA.req primitive sends a request for an AAL1 data
- transfer from the ST2+ data layer entity to the AAL1 layer entity.
- The semantics of the primitive are as follows:
-
- AAL1_UNITDATA.req (
- DATA,
- CLP
- )
-
- The DATA parameter specifies the AAL1 data to be transferred. The
- CLP parameter specifies the value of the CLP field in the ATM cell.
-
- 4.4.2.2 AAL1_UNITDATA.ind
-
- The AAL1_UNITDATA.ind indicates an AAL1 Data delivery from the AAL1
- layer entity to the ST2+ data layer entity. The semantics of the
- primitive are as follows:
-
- AAL1_UNITDATA.ind (
- DATA,
- CLP,
- STATUS [optional]
- )
-
- The DATA parameter indicates the delivered AAL1 data. The CLP
- parameter indicates the value of the CLP field in the ATM cell. The
- STATUS parameter is an optional parameter that indicates whether the
- delivered AAL1 data is corrupt or not.
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 21]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 4.5 AAL1 Encapsulation for ST2+ Data PDU
-
- 4.5.1 Mapping from st2_unitdata.req to AAL1_UNITDATA.req
-
- The data in st2_unitdata.req is regarded as a sequential-byte stream;
- every 47 bytes of the data are assigned to the DATA parameter in
- AAL1_UNITDATA.req. That is, as shown in Fig. 4.2, every 47 bytes of
- the ST2+ data in the ST2+ Data PDU are continuously mapped to the
- payload of AAL1 SAR_PDU.
-
- Therefore, one st2_unitdata.req corresponds to one or more than one
- AAL1_UNITDATA.req, and one AAL1_UNITDATA.req may correspond to more
- than one st2p_unitdata.req.
-
- -------+ +-------+---------------------------+
- | | ST | ST2+ data | ST2+
- |..| header| | ...... Data PDU
- -------+ +-------+---------------------------+
- ///\\\\\\ /////////\\\\\\\\\\\\\\\\\\\\\
- // \\\\\\ ///////// \\\\\\\\\\\\\ \\\\\\\\
- / \\\\\\ ///////// \\\\\\\\\\\\\ \\\\\\\\
- \\\\\\ ///////// \\\\\\\\\\\\\
- \\\\\\///////// \\\\\\\\\\\\\
- +-------+-----------+ +-------+-----------+
- |SAR_PDU| SAR_PDU | |SAR_PDU| SAR_PDU | AAL1
- |header | payload |..|header | payload |...... SAR_PDU
- +-------+-----------+ +-------+-----------+
-
- Fig. 4.2: Mapping of ST2+ data to AAL1 SAR_PDU payload.
-
- The value of the CLP in AAL1_UNITDATA.req depends on the
- implementation: 1 (low priority) or zero (high priority) may be
- assigned permanently, or they may be assigned depending on the value
- of pri in st2_unitdata.req.
-
- 4.5.2 Mapping from AAL1_UNITDATA.ind to st2p_unitdata.ind
-
- The DATA parameter in AAL1_UNITDATA.ind is regarded as a sequential-
- byte stream. A certain number of bytes, where the number is equal to
- or less than the negotiated downstream MTU value, are assigned to the
- data in st2p_unitdata.ind. That is, as shown in Fig. 4.2, some bytes
- of the payload in AAL1 SAR_PDU are mapped to the ST2+ data in the
- ST2+ Data PDU.
-
- Therefore, one st2_unitdata.ind corresponds to one or more than one
- AAL1_UNITDATA.ind, and one AAL1_UNITDATA.ind may correspond to more
- than one st2p_unitdata.ind.
-
-
-
-
- Suzuki Expires September, 1997 [Page 22]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- An implementation-dependent value is assigned to pri in
- st2p_unitdata.ind.
-
- If the value of STATUS in AAL1_UNITDATA.ind is valid, it is assigned
- to the status in st2p_unitdata.ind.
-
- 4.5.3 Value of MTU
-
- Because AAL1 is not designed to directly support packet
- communications and thus has no MTU, the value of MTU is
- implementation-dependent and equal to or less than 65,535 bytes. The
- value of MTU may be determined by the rate of the VC, by the buffer
- length, or by the packet-processing rule.
-
-
- 5. Protocol Specification of the Management Plane
-
- TBD
-
- This section will be prepared based on the discussions of the ISSLL
- working group.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 23]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 6. Protocol Specification of the Control Plane
-
- This section specifies the relationship between ST2+ SCMP and PVC
- management for ST2+ data, and the protocol interaction between ST2+
- SCMP and Q.2931 UNI signaling [5, 9].
-
-
- 6.1 AAL5 Encapsulation for ST2+ SCMP PDU
-
- This subsection describes AAL5 PDU encapsulation for the ST2+ SCMP
- PDU. AAL5 encapsulation based on RFC 1483 and on the RFC 1483
- extension are specified. Selection of which one to use depends on
- the implementation.
-
- The ST2+ over ATM protocol does not cover a VC (SVC/PVC) that
- transfers ST2+ SCMP. VCs for IPv4 transfer may be used for ST2+ SCMP
- transfer, and implementations may provide particular VCs for ST2+
- SCMP transfer. Selection of these VCs depends on the implementation.
-
- 6.1.1 RFC 1483 base encapsulation
-
- The RFC 1483 base encapsulation is shown in Fig. 6.1: the ST2+ SCMP
- PDU with the RFC 1483 LLC encapsulation for routed protocol format is
- mapped to the payload in AAL5 CPCS_PDU. Implementors should note
- that this is not same as AAL5 encapsulation for the ST2+ Data PDU
- (the LLC is required).
-
- +------+----------------+
- | ST | ST2+ SCMP | ST2+
- |header| | SCMP PDU
- +------+----------------+
- : :
- +---+---+---+-----------------------+
- |LLC|OUI|PID| Information | IEEE 802 SNAP
- | | | | | ISO 8802-2 LLC
- +---+---+---+-----------------------+
- : :
- +---------------------------------------+--------+
- | CPCS_PDU |PAD|CPCS_PDU| AAL5
- | payload | |trailer | CPCS_PDU
- +---------------------------------------+--------+
-
- Fig. 6.1: Mapping of ST2+ SCMP PDU to AAL5 CPCS_PDU payload.
-
- The value of the LLC is 0xAA-AA-03, the value of the OUI is 0x00-00-
- 00, and the value of the PID is 0x08-00. The classification of the
- IPv4 and the ST2+ SCMP is determined by the IP version number, which
- is located in the first four bits of the IPv4 or ST headers.
-
-
-
- Suzuki Expires September, 1997 [Page 24]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- 6.1.2 RFC 1483 extension base encapsulation
-
- The RFC 1483 extension base encapsulation is the same as for RFC 1483
- base encapsulation, except that the value of the OUI is 0x00-00-5E
- (IANA) and the value of the PID is 0xXX-XX (TBD).
-
- The RFC 1483 base encapsulation for the SCMP is ideal, but requires
- modifying the IPv4 processing in the driver software of the WS or PC.
- Therefore, the RFC 1483 base encapsulation may be difficult to
- implement. This encapsulation is designed to solve this problem.
-
-
-
- The following subsections will be added in the next draft.
-
- 6.2 Service Primitives Provided by Control Plane
-
- 6.3 Service Primitives Provided by ST2+ SCMP
-
- 6.4 Service Primitives Provided by Q.2931
-
- 6.5 CONNECT Processing
-
- 6.6 CHANGE Processing
-
- 6.7 DISCONNECT Processing
-
- 6.8 REFUSE Processing
-
- 6.9 Q.2931 Information Element Coding
-
- 6.10 State Transit of ST2+ SCMP Entity
-
-
-
-
- 7. Security Considerations
-
- Security considerations are not discussed in this document.
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 25]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- References
-
- [1] M. Borden, E. Crawley, B. Davie, and S. Batsell, "Integration
- of Real-time Services in an IP-ATM Network Architecture," RFC
- 1821, August 1995.
-
- [2] S. Jackowski, "Native ATM Support for ST2+," RFC 1946, May
- 1996.
-
- [3] S. Damaskos and A. Gavras, "Connection Oriented Protocols over
- ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, February
- 1994.
-
- [4] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol
- Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819,
- August 1995.
-
- [5] The ATM Forum, "ATM User-Network Interface Specification
- Version 3.1," September 1994.
-
- [6] J. Wroclawski, "Specification of the Controlled-Load Network
- Element Service," Internet Draft, November 1996, <draft-ietf-
- intserv-ctrl-load-svc-04.txt>.
-
- [7] S. Shenker, C. Partridge, and R. Guerin, "Specification of
- Guaranteed Quality of Service," Internet Draft, February 1997,
- <draft-ietf-intserv-guaranteed-svc-07.txt>.
-
- [8] J. Wroclawski, "The Use of RSVP with IETF Integrated
- Services," Internet Draft, October 1996, <draft-ietf-intserv-
- rsvp-use-01.txt>.
-
- [9] ITU-T, "Broadband Integrated Services Digital Network (B-
- ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-
- Network Interface (UNI) Layer 3 Specification for Basic
- Call/Connection Control," ITU-T Recommendation Q.2931, September
- 1995.
-
- [10] ITU-T, "B-ISDN Protocol Reference Model and its Application,"
- CCITT Recommendation I.321, April 1991.
-
- [11] ITU-T, "B-ISDN ATM Adaptation Layer (AAL) specification,
- types 1 and 2," Draft new ITU-T Recommendation I.363.1, September
- 1995.
-
- [12] ITU-T, "B-ISDN ATM Adaptation Layer (AAL) type 5
- specification," Draft new ITU-T Recommendation I.363.5, September
- 1995.
-
-
-
- Suzuki Expires September, 1997 [Page 26]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- [13] ITU-T, "Traffic Control and Congestion Control in B-ISDN,"
- ITU-T Recommendation I.371, July 1995.
-
- [14] J. Heinanen, "Multiprotocol Encapsulation over ATM
- Adaptation Layer 5," RFC 1483, July 1993.
-
- [15] M. Laubach, "Classical IP and ARP over ATM," RFC 1577,
- January 1994.
-
- [16] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, and A.
- Malis, "ATM Signaling Support for IP over ATM," RFC 1755, February
- 1995.
-
- [17] J. Luciani, D. Katz, D. Piscitello, and B. Cole, "NBMA Next
- Hop Resolution Protocol (NHRP)," Internet Draft, March 1997,
- <draft-ietf-rolc-nhrp-11.txt>.
-
-
- Acknowledgments
-
- TBD
-
-
- Author's Address
-
- Muneyoshi Suzuki
- NTT Multimedia Networks Laboratories
- 3-9-11, Midori-cho
- Musashino-shi, Tokyo 180, Japan
-
- Phone: +81-422-59-2119
- Fax: +81-422-59-3203
- EMail: suzuki@nal.ecl.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 27]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- Appendix A. RFC 1819 ST2+ Errata
-
- A.1 4.3 SCMP Reliability
-
- The following sentence in the second paragraph:
-
- < For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the
-
- should be changed to
-
- > For some SCMP messages (CONNECT, CHANGE, and JOIN) the
-
- A.2 4.4.4 User Data
-
- The following:
-
- < option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and
- < REFUSE messages. The format of the UserData parameter is shown in
-
- should be changed to
-
- > option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, NOTIFY,
- > and REFUSE messages. The format of the UserData parameter is shown in
-
- A.3 5.5.1 Mismatched FlowSpecs
-
- The following sentence:
-
- < notifies the processing ST agent which should respond with ReasonCode
- < (FlowSpecMismatch).
-
- should be changed to
-
- > notifies the processing ST agent which should respond with a REFUSE
- > message with ReasonCode (FlowSpecMismatch).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 28]
-
- INTERNET DRAFT draft-suzuki-st2-over-atm-01.txt March, 1997
-
-
- A.4 10.2 Control PDUs
-
- The following:
-
- <o Reference is a transaction number. Each sender of a request control
- < message assigns a Reference number to the message that is unique
- < with respect to the stream.
-
- should be changed to
-
- >o Reference is a transaction number. Each sender of a request control
- > message assigns a Reference number to the message that is unique
- > with respect to the stream for messages generated by each agent.
-
- A.5 10.3.4 Origin
-
- The following:
-
- < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- < | PCode = 5 | PBytes | NextPcol |OriginSAPBytes |
- < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- should be changed to
-
- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- > | PCode = 4 | PBytes | NextPcol |OriginSAPBytes |
- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- A.6 10.5.3 ReasonCode
-
- The following:
-
- < 32 PCodeUnknown Control PDU has a parameter with an invalid
- < PCode.
-
- should be removed because a common SCMP element with an unknown PCode
- is equivalent to the UserData (RFC 1819, Section 10.3.8).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires September, 1997 [Page 29]
-
-