diff options
Diffstat (limited to 'doc/rfc/rfc2383.txt')
| -rw-r--r-- | doc/rfc/rfc2383.txt | 2803 |
1 files changed, 2803 insertions, 0 deletions
diff --git a/doc/rfc/rfc2383.txt b/doc/rfc/rfc2383.txt new file mode 100644 index 0000000..1a162a4 --- /dev/null +++ b/doc/rfc/rfc2383.txt @@ -0,0 +1,2803 @@ + + + + + + +Network Working Group M. Suzuki +Request for Comments: 2383 NTT +Category: Informational August 1998 + + + ST2+ over ATM + Protocol Specification - UNI 3.1 Version + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +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. + +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. + + + + +Suzuki Informational [Page 1] + +RFC 2383 ST2+ over ATM August 1998 + + + 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 + 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) [10, 11]. + + 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. + + + + +Suzuki Informational [Page 2] + +RFC 2383 ST2+ over ATM August 1998 + + + 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 [16] IPv4 encapsulation. + + o Coexist with RFC 1577 [17] ATMarp. + + o Coexist with RFC 1755 [18] ATM signaling for IPv4. + + o Coexist with NHRP [19]. + + 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 + + o Router/switch architecture + + + + + + + + + + + + + + + + + + + +Suzuki Informational [Page 3] + +RFC 2383 ST2+ over ATM August 1998 + + +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 [14]. + +2.1 User Plane Architecture + + The user plane specifies the rules for encapsulating the ST2+ Data + PDU into the AAL5 [15] 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.5 | + | | + | AAL5 | + | | + | | + +---------------------------------+ + | I.361 ATM | + +---------------------------------+ + | PHY | + +----------------+----------------+ + | UNI + +--------||------- + + Fig. 2.1: User plane protocol stack. + + + + + + + + + + + + + + + + +Suzuki Informational [Page 4] + +RFC 2383 ST2+ over ATM August 1998 + + + An example of interworking from an ATM network to an IEEE 802.X LAN + is shown in Fig. 2.2. + + 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 | + +---------+ +---------+ +---------+---------+ +---------+ + | | | | | |IEEE802.X| |IEEE802.X| + | PHY |--->| PHY |--->| PHY | & 802.1p|----->| & 802.1p| + +---------+ +---------+ +---------+---------+ +---------+ + + 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. + + + + + + + + + + + + + + + + + + + + + + + +Suzuki Informational [Page 5] + +RFC 2383 ST2+ over ATM August 1998 + + +2.2 Management Plane Architecture + + The management plane specifies the Null FlowSpec, the Controlled-Load + Service [5] FlowSpec, and the Guaranteed Service [6] FlowSpec mapping + rules [8] for UNI 3.1 traffic management. A management plane + protocol stack is shown in Fig. 2.3. + + +---------------------------------+ + | Null FlowSpec | + |Controlled-Load Service FlowSpec | + | Guaranteed Service FlowSpec | + +---------------------------------+ Point of ST2+ over ATM + |/////////////////////////////////| <--- protocol specification of + +---------------------------------+ management plane + | | + | UNI 3.1 | + | | + | | + | Traffic Management | + | | + | | + | VBR/UBR | + | | + +---------------------------------+ + + Fig. 2.3: Management plane protocol stack. + + 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. + + 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 UNI 3.1 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. + + + +Suzuki Informational [Page 6] + +RFC 2383 ST2+ over ATM August 1998 + + + It does not support the ST2+ FlowSpec (RFC 1819, Section 9.2). ST2+ + FlowSpec specifies useful services, but requires a datalink layer to + support heterogeneous QoS to receivers. The current ATM standard + does not support heterogeneous QoS to receivers. + +2.3 Control Plane Architecture + + The control plane specifies the rules for encapsulating the ST2+ SCMP + PDU into the AAL5 [15] PDU, the relationship between ST2+ SCMP and + PVC management for ST2+ data, and the protocol interaction between + ST2+ SCMP and UNI 3.1 signaling [10]. 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 | |UNI3.1 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+ 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. + + + + + + +Suzuki Informational [Page 7] + +RFC 2383 ST2+ over ATM August 1998 + + + 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 UNI 3.1 + signaling. An example of ST2+ SCMP and UNI 3.1 signaling 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 UNI + 3.1 signaling entity. + + ATM SW ATM SW + +------------+ UNI +----+ NNI +----+ UNI +------------+ + ____|Intermediate|--||--| \/ |______| \/ |--||--|Intermediate|____ + | (Upstream) | | /\ | | /\ | |(Downstream)| + +------------+ +----+ +----+ +------------+ + SCMP + ------->(S)<------------------------------------------>(S)<------- + \ UNI Sig. UNI Sig. / + 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 UNI 3.1 signaling message flows. + + + +Suzuki Informational [Page 8] + +RFC 2383 ST2+ over ATM August 1998 + + + 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. + + 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. + + + + + + + + + + + + + + +Suzuki Informational [Page 9] + +RFC 2383 ST2+ over ATM August 1998 + + + An example of ST2+ SCMP interworking is shown in Fig. 2.6. + + _____ + / \ + (Origin ) + \ / + A ~~|~~ A + | = | UNI Signaling + | | | + | +-+-+ V + | | X | ATM SW + | +-+-+ A + SCMP | | | NNI Signaling + | +-+-+ V + | | X | ATM SW + | +-+-+ A + | | | + | = | UNI Signaling + V | V + +-----+------+ IEEE 802.X & 802.1p + | |<---------------------+ + |Intermediate|--------------------+ | + | |<-----------------+ | | + +------------+ L2 Signaling| | | + A | A | | | + | = | UNI Signaling | | | SCMP + | | | | | | + | +-+-+ V | | | + | | X | ATM SW V | | + | +-+-+ A +---+-|-+ + SCMP | | | NNI Signaling | \ /| | + | +-+-+ V | X | |LAN SW + | | X | ATM SW | / \| | + | +-+-+ A +---+-|-+ + | | | A | | + | = | UNI Signaling | | | + V __|__ V V_|_V + / \ / \ + (Target ) (Target ) + \ / \ / + ~~~~~ ~~~~~ + + Fig. 2.6: Example of ST2+ SCMP interworking. + + + + + + + + +Suzuki Informational [Page 10] + +RFC 2383 ST2+ over ATM August 1998 + + +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, + unsupported, and modified 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 Informational [Page 11] + +RFC 2383 ST2+ over ATM August 1998 + + + 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 CHANGE message, the value of the SVC Number field is 1. + If it appears in the ACCEPT, NOTIFY, or 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 [5]. See section 5 of + [5] 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 Informational [Page 12] + +RFC 2383 ST2+ over ATM August 1998 + + + 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 establish a hop with a + VC 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. + + + + + + + + + + + + + + + + + + +Suzuki Informational [Page 13] + +RFC 2383 ST2+ over ATM August 1998 + + + The format of the VC-type common SCMP element is shown in Fig. 3.2. + + 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. + + + + + +Suzuki Informational [Page 14] + +RFC 2383 ST2+ over ATM August 1998 + + + The PVCIdentifer field identifies the PVC identifier uniquely + assigned between neighboring ST2+ agents. This field is valid only + when the VCType field is zero. + + 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 FlowSpec changes + + In the following case, 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. + + In the following case, 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 and/or G-bits are set to zero. + +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 datalink layer to support heterogeneous QoS to + receivers. The current ATM standard does not support heterogeneous + QoS to receivers. + + + + + + + +Suzuki Informational [Page 15] + +RFC 2383 ST2+ over ATM August 1998 + + +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 Subnet Resources Sharing + + The ST2+ over ATM protocol does not support subnet resources sharing + (RFC 1819, Section 7.1.4). This is because ATM does not support the + concept of the MAC layer. + +3.3.6 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. + +3.3.7 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. + + + + +Suzuki Informational [Page 16] + +RFC 2383 ST2+ over ATM August 1998 + + +3.4 Modified Functions of RFC 1819 ST2+ + + The ST2+ receiver-oriented stream creation procedure has some fatal + problems: the value of the LnkReferecnce field in the CONNECT message + that is a response to a JOIN message is not valid, ST2+ agent cannot + update the LnkReference field in the JOIN-REJECT message, and ST2+ + agent cannot deliver the JOIN-REJECT message to the target because + the JOIN-REJECT message does not contain a TargetList field. To + solve these problems, the ST2+ over ATM protocol modifies the ST2+ + protocol processing rules. + +3.4.1 Modifications of Message Processing Rules + + Modifications of the CONNECT, JOIN, and JOIN-REJECT message + processing rules in the ST2+ over ATM protocol are described in the + following. + + o The target that creates a JOIN message assigns the same value as in + the Reference field to the LnkReference field. + + o The agent that creates a CONNECT message as a response to a JOIN + message assigns the same value as in the LnkReference field in the + JOIN message to the LnkReference field. In other cases, the value + of the LnkReference field in a CONNECT message is zero. + + o The agent that creates a JOIN-REJECT message assigns the same value + as in the LnkReference field in the JOIN message to the + LnkReference field. + + o An intermediate agent must not modify the value of the LnkReference + field in the CONNECT, JOIN, or JOIN-REJECT message. Note that this + rule differs from the LnkReference field processing rule in the + ACCEPT and REFUSE messages. + + + + + + + + + + + + + + + + + + +Suzuki Informational [Page 17] + +RFC 2383 ST2+ over ATM August 1998 + + +3.4.2 Modified JOIN-REJECT Control Message + + The modified JOIN-REJECT control message in the ST2+ over ATM + protocol is shown in Fig. 3.3 + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OpCode = 9 | 0 | TotalBytes | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reference | LnkReference | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SenderIPAddress | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | ReasonCode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | GeneratorIPAddress | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : TargetList : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fig. 3.3: JOIN-REJECT Control Message. + + The TargetList is assigned the same TargetList in the JOIN message as + the one that corresponds to the JOIN-REJECT message. + +4. Protocol Specification of the User Plane + + This section specifies the AAL5 PDU encapusulation for the ST2+ Data + PDU. + +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: + + + + +Suzuki Informational [Page 18] + +RFC 2383 ST2+ over ATM August 1998 + + + 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: + + 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. + + + +Suzuki Informational [Page 19] + +RFC 2383 ST2+ over ATM August 1998 + + + 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: + + 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 Informational [Page 20] + +RFC 2383 ST2+ over ATM August 1998 + + + +-------+---------------------------+ + | 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. + +5. Protocol Specification of the Management Plane + + The management plane specifies the Null FlowSpec, the Controlled-Load + Service FlowSpec, and the Guaranteed Service FlowSpec mapping rules + for UNI 3.1 traffic management. + +5.1 Mapping of the Null FlowSpec + + The Null FlowSpec is mapped to the UBR (VBR with the Best Effort + Indicator). + + The value of the PCR (CLP=0+1) is shown in section 6.7.2. + + + + + +Suzuki Informational [Page 21] + +RFC 2383 ST2+ over ATM August 1998 + + +5.2 Mapping of the Controlled-Load Service FlowSpec + + The Controlled-Load FlowSpec is mapped to the VBR whose PCR + (CLP=0+1), SCR (CLP=0+1), and MBS (CLP=0+1) are specified. + + The value of the PCR (CLP=0+1) is shown in section 6.7.2. + + Let scr be the calculated value of the SCR (CLP=0+1). Based on the + value of the [r] field in the Controlled-Load FlowSpec, it is given + by: + scr = ([r] / 48) * S, + + where S is the coefficient of segmentation, and in an implementation, + it must be configurable to any value between 1.0 and 56.0. The + recommended default value is 1.2. The value of the SCR (CLP=0+1) is + a minimum integer equal to or more than the calculated value of the + scr. + + Let mbs be the calculated value of the MBS (CLP=0+1). Based on the + value of the [b] field in the Controlled-Load FlowSpec, it is given + by: + mbs = ([b] / 48) * S. + + The value of the MBS (CLP=0+1) is a minimum integer equal to or more + than the calculated value of the mbs. + + The values of the [p] and [m] fields in the Controlled-Load FlowSpec + are ignored. + +5.3 Mapping of the Guaranteed Service FlowSpec + + 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. + +6. Protocol Specification of the Control Plane + + This section specifies the rules for encapsulating the ST2+ SCMP PDU + into the AAL5 PDU, the relationship between ST2+ SCMP and PVC + management for ST2+ data, and the protocol interaction between ST2+ + SCMP and UNI 3.1 signaling. + +6.1 AAL5 Encapsulation for ST2+ SCMP PDU + + This subsection describes AAL5 PDU encapsulation for the ST2+ SCMP + PDU. ST2+ Data PDU compatible encapsulation, AAL5 encapsulation + based on RFC 1483, and on the RFC 1483 extension are specified. + Selection of which one to use depends on the implementation. + + + +Suzuki Informational [Page 22] + +RFC 2383 ST2+ over ATM August 1998 + + + 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 ST2+ Data PDU compatible encapsulation + + The ST2+ Data PDU compatible encapsulation is shown in Fig. 6.1: the + ST2+ SCMP PDU is mapped to the payload of AAL5 CPCS_PDU. + Implementors should note that this encapsulation is not applicable + when the ST2+ SCMP PDU is multiplexed with other protocols. + + +-------+---------------------------+ + | ST | ST2+ SCMP | ST2+ + | header| | SCMP PDU + +-------+---------------------------+ + : : + : : + +---------------------------------------+--------+ + | CPCS_PDU |PAD|CPCS_PDU| AAL5 + | payload | |trailer | CPCS_PDU + +---------------------------------------+--------+ + + Fig. 6.1: ST2+ Data PDU conpatible encapsulation. + +6.1.2 RFC 1483 base encapsulation + + The RFC 1483 base encapsulation is shown in Fig. 6.2: the ST2+ SCMP + PDU with the RFC 1483 LLC encapsulation for routed protocol format is + mapped to the payload in AAL5 CPCS_PDU. + + +------+----------------+ + | 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.2: RFC 1483 base encapsulation. + + + + +Suzuki Informational [Page 23] + +RFC 2383 ST2+ over ATM August 1998 + + + 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. + +6.1.3 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. + +6.2 Service Primitives Provided by Control Plane + + RFC 1819 ST2+ does not specify SCMP state machines. And the ST2+ + over ATM protocol does not correspond to SCMP state machines. + Therefore, the control plane specification assumes the following. + + o The ST2+ agent has ST2+ SCMP layer entities that correspond to the + next hops and the previous hop in the stream. + + o The SCMP layer entity terminates ACK, ERROR, and timeout processing + and provides reliable SCMP delivery. + + o The origin consists of an upper layer entity, ST2+ SCMP layer + entities for next hops, and a routing machine that delivers SCMP + messages between these entities. + + o The intermediate agent consists of ST2+ SCMP layer entities for a + previous hop and for next hops and a routing machine that delivers + SCMP messages between these entities. + + o The target consists of an upper layer entity, an ST2+ SCMP layer + entity for a previous hop, and a routing machine that delivers SCMP + messages between these entities. + + At least, the ST2+ SCMP layer entity for the next hop provides the + following services to the routing machine. + + o connect.req + This primitive sends a request for a CONNECT message transfer to + the ST2+ SCMP layer entity. + + + + + +Suzuki Informational [Page 24] + +RFC 2383 ST2+ over ATM August 1998 + + + o change.req + This primitive sends a request for a CHANGE message transfer to the + ST2+ SCMP layer entity. + + o accept.ind + This primitive indicates an ACCEPT message delivery from the ST2+ + SCMP layer entity. + + o disconnect.req + This primitive sends a request for a DISCONNECT message transfer to + the ST2+ SCMP layer entity. + + o refuse.ind + This primitive indicates a REFUSE message delivery from the ST2+ + SCMP layer entity, or indicates detection of an abnormal status + such as an illegal message or timeout in the ST2+ SCMP layer + entity. + + At least, the ST2+ SCMP layer entity for the previous hop provides + the following services to the routing machine. + + o connect.ind + This primitive indicates a CONNECT message delivery from the ST2+ + SCMP layer entity. + + o change.ind + This primitive indicates a CHANGE message delivery from the ST2+ + SCMP layer entity. + + o accept.req + This primitive sends a request for an ACCEPT message transfer to + the ST2+ SCMP layer entity. + + o disconnect.ind + This primitive indicates a DISCONNECT message delivery from the + ST2+ SCMP layer entity, or indicates detection of an abnormal + status such as an illegal message or timeout in the ST2+ SCMP layer + entity. + + o refuse.req + This primitive sends a request for a REFUSE message transfer to the + ST2+ SCMP layer entity. + +6.3 Service Primitives Provided by UNI 3.1 Signaling + + The UNI 3.1 signaling layer entity on the ST2+ over ATM control plane + provides the following services to the ST2+ SCMP layer entity. The + ST2+ over ATM protocol does not specify the UNI 3.1 signaling state + + + +Suzuki Informational [Page 25] + +RFC 2383 ST2+ over ATM August 1998 + + + machines. These are defined in [10, 12, 13]. + + o setup.req + This primitive sends a request for a SETUP message transfer from + the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity. + The ST2+ SCMP layer entity that sent this primitive receives an + acknowledgment. If the setup succeeds the acknowledgment is a + setup.conf primitive and if the setup fails it is a release.ind or + release.conf primitive. + + o setup.conf + This primitive indicates a CONNECT message delivery from the UNI + 3.1 signaling layer entity to the ST2+ SCMP layer entity. + + o setup.ind + This primitive indicates a SETUP message delivery from the UNI 3.1 + signaling layer entity to the ST2+ SCMP layer entity. The ST2+ + SCMP layer entity that received this primitive sends an + acknowledgment. If the setup is accepted the acknowledgment is a + setup.resp primitive and if the setup is rejected it is a + release.resp primitive if the state of the UNI 3.1 signaling layer + entity is U6; otherwise it is a release.req primitive. + + o setup.resp + This primitive sends a request for a CONNECT message transfer from + the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity. + The ST2+ SCMP layer entity that sent this primitive receives an + acknowledgment. If the setup is completed the acknowledgment is a + setup-complete.ind primitive and if the setup fails it is a + release.ind or release.conf primitive. + + o setup-complete.ind + This primitive indicates a CONNECT ACKNOWLEDGE message delivery + from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer + entity. + + o release.req + This primitive sends a request for a RELEASE message transfer from + the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity. + The ST2+ SCMP layer entity that sent this primitive receives an + acknowledgment that is a release.conf primitive. + + o release.conf + This primitive indicates a RELEASE COMPLETE message delivery, or + indicates a RELEASE message delivery when the status of the UNI 3.1 + signaling layer entity is U11, or indicates detection of an + abnormal status such as an illegal message or timeout in the UNI + 3.1 signaling layer entity, from the UNI 3.1 signaling layer entity + + + +Suzuki Informational [Page 26] + +RFC 2383 ST2+ over ATM August 1998 + + + to the ST2+ SCMP layer entity. + + o release.ind + This primitive indicates a RELEASE message delivery from the UNI + 3.1 signaling layer entity to the ST2+ SCMP layer entity when the + status of the UNI 3.1 signaling layer entity is other than U11. + The ST2+ SCMP layer entity that received this primitive sends an + acknowledgment that is a release.resp primitive. And this + primitive also indicates detection of an abnormal status such as an + illegal message or timeout in the UNI 3.1 signaling layer entity + and then a REFUSE message is transferred. In this case, the ST2+ + SCMP layer entity that received this primitive receives a + release.conf primitive in succession. + + o release.resp + This primitive sends a request for a RELEASE COMPLETE message + transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling + layer entity. + + o add-party.req + This primitive sends a request for an ADD PARTY message transfer + from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer + entity. The ST2+ SCMP layer entity that sent this primitive + receives an acknowledgment. If the setup is succeeds the + acknowledgment is an add-party.conf primitive and if the setup + fails it is a drop-party.conf primitive. + + o add-party.conf + This primitive indicates an ADD PARTY ACKNOWLEDGE message delivery + from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer + entity. + + o drop-party.req + This primitive sends a request for a DROP PARTY message transfer + from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer + entity. The ST2+ SCMP layer entity that sent this primitive + receives an acknowledgment that is a drop-party.conf primitive. + + o drop-party.conf + This primitive indicates an ADD PARTY REJECT message delivery, or + indicates a DROP PARTY ACKNOWLEDGE message delivery, or indicates + detection of an abnormal status such as an illegal message or + timeout in the UNI 3.1 signaling layer entity, from the UNI 3.1 + signaling layer entity to the ST2+ SCMP layer entity. + + o drop-party.ind + This primitive indicates a DROP PARTY message delivery from the UNI + 3.1 signaling layer entity to the ST2+ SCMP layer entity. The ST2+ + + + +Suzuki Informational [Page 27] + +RFC 2383 ST2+ over ATM August 1998 + + + SCMP layer entity that sent this primitive receives an + acknowledgment that is a drop-party.resp primitive. + + o drop-party.resp + This primitive sends a request for a DROP PARTY ACKNOWLEDGE message + transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling + layer entity. + +6.4 VC Style Selection Criteria + + The ST2+ over ATM protocol supports PVC, the reverse channel of bi- + directional SVC, point-to-point SVC, and point-to-multipoint SVC for + ST2+ Data PDU transfer. And SVC supports both upstream and + downstream call initiation styles. + + A 32-bit PVC identifier that is unique between neighboring ST2+ + agents is assigned to each PVC. And the reverse channel of the bi- + directional point-to-point SVC used by the existing stream is + identified by the SID of the stream that occupies the forward + channel. + + When the ST2+ agent sets up a stream or changes QoS, the ST2+ agent + must select one VC style from these SVC and PVC styles as a hop that + is part of the stream. In the ST2+ over ATM protocol, VC style + selection criteria depend on the implementation. + + This subsection describes examples of VC style selection criteria for + the ST2+ over ATM protocol as a reference for implementors. Note + that the following descriptions in this subsection are not part of + the ST2+ over ATM protocol specification. + +6.4.1 Examples of PVC selection criteria + + At least, the ST2+ agent may have to manage the following information + for each PVC that can be used by ST2+ Data PDU transfer. + + o PVC identifier + + o ATM interface identifier in the ST2+ agent + + o VPI/VCI + + o State of VC: e.g. enabled or disabled, occupied or vacant + + o QoS of VC + + o Nexthop IP address + + + + +Suzuki Informational [Page 28] + +RFC 2383 ST2+ over ATM August 1998 + + + When a PVC is selected for a hop of a stream, at least confirmations, + that is the state of the PVC is vacant and the next hop IP address + and QoS are consistent with the requirements from the stream, may be + needed. + + It is also feasible to introduce access lists to each PVC and to + consider the access lists in the selection process. Examples of an + access list are shown in the following. + + o Permit or deny use by a stream whose the previous hop is specified. + + o Permit or deny use by a stream whose the origin is specified. + + o Permit or deny use by a stream whose the SID is specified. + + o Permit or deny use by a stream whose the target is specified. + + o Permit or deny use by a stream whose the target and SAP are + specified. + + o Any combination of the above. + +6.4.2 Examples of reverse channel of bi-directional SVC selection + criteria + + At least, the ST2+ agent may have to manage the following information + for each reverse channel of bi-directional SVCs. + + o SID of the stream that occupies the forward channel + + o ATM interface identifier in the ST2+ agent + + o VPI/VCI + + o State of the reverse channel in the VC: e.g. enabled or disabled, + occupied or vacant + + o QoS of VC + + o Nexthop IP address + + When a reverse channel of the bi-directional point-to-point SVC used + by the existing stream is selected for a hop of a stream, at least + confirmations, that is the state of the channel is vacant and the + next hop IP address and QoS are consistent with the requirements from + the stream, may be needed. + + + + + +Suzuki Informational [Page 29] + +RFC 2383 ST2+ over ATM August 1998 + + + It is also feasible to introduce selection rules to the ST2+ agent. + Examples of selection rule are shown in the following. + + o Permit reuse of the reverse channel by a stream whose the origin is + one of targets in the stream that occupies the forward channel. + + o Permit reuse of the reverse channel by a stream whose one of + targets is the origin in the stream that occupies the forward + channel. + + o Permit reuse of the reverse channel by a stream whose the previous + hop is one of the next hops in the stream that occupies the forward + channel. + + o Any combination of the avobe. + +6.4.3 Examples of SVC selection criteria + + When an SVC is used for a hop of a stream, at first, the ST2+ agent + must select point-to-point or point-to-multipoint SVC. Examples of + this selection rule are shown in the following. + + o If the network supports only point-to-point SVC, select it. + + o If the network supports point-to-multipoint SVC, select it. + + If point-to-point SVC is selected, the ST2+ agent must select + upstream or downstream call initiation style. Examples of this + selection rule are shown in the following. + + o A VC for a stream whose previous hop is specified is initiated from + upstream or downstream. + + o A VC for a stream whose next hop is specified is initiated from + upstream or downstream. + + o A VC for a stream whose origin is specified is initiated from + upstream or downstream. + + o A VC for a stream whose SID is specified is initiated from upstream + or downstream. + + o A VC for a stream whose target is specified is initiated from + upstream or downstream. + + o A VC for a stream whose target and SAP are specified is initiated + from upstream or downstream. + + + + +Suzuki Informational [Page 30] + +RFC 2383 ST2+ over ATM August 1998 + + + o Any combination of the above. + +6.5 VC Management + + This subsection specifies VC management in the ST2+ over ATM + protocol. + +6.5.1 Outgoing call processing of SVC + + When outgoing call processing of the first leaf of a point-to- + multipoint SVC or a point-to-point SVC is required inside the ST2+ + SCMP layer entity, a setup.req primitive is sent to the UNI 3.1 + signaling layer entity. If the UNI 3.1 signaling layer entity + responds with a setup.conf primitive, the call processing is assumed + to have succeeded. If the UNI 3.1 signaling layer entity responds + with anything other than this primitive, the processing rule is the + same as the SVC disconnect processing that is shown in section 6.5.4 + and the outgoing call processing is assumed to have failed. + + When outgoing call processing of a later leaf of a point-to- + multipoint SVC is required, an add-party.req primitive is sent to the + UNI 3.1 signaling layer entity. If the UNI 3.1 signaling layer + entity responds with an add-party.conf primitive, the call processing + is assumed to have succeeded. If the UNI 3.1 signaling layer entity + responds with anything other than this primitive, the processing rule + is the same as the SVC disconnect processing that is shown in section + 6.5.4 and the outgoing call processing is assumed to have failed. + +6.5.2 Incoming call processing of SVC + + When an incoming call processing of SVC is required inside the ST2+ + SCMP layer entity, it sets a watchdog timer. The time interval of + the timer depends on the implementation. + + The ST2+ SCMP layer entity waits for a setup.ind primitive indication + from the UNI 3.1 signaling layer entity. When this primitive is + indicated and the parameters in it are acceptable, the ST2+ SCMP + layer entity responds with a setup.resp primitive. If the parameters + are not acceptable, the ST2+ SCMP layer entity stops the timer, and + if the state of the UNI 3.1 signaling layer entity is U6, the entity + responds with a release.resp primitive, and if the state is other + than this, the entity responds with a release.req primitive, and then + waits for a release.conf primitive response and the incoming call + processing is assumed to have failed. + + If the ST2+ SCMP layer entity responds with a setup.resp primitive, + then the entity waits for the next primitive indication, and when the + next primitive is indicated, the ST2+ SCMP layer entity stops the + + + +Suzuki Informational [Page 31] + +RFC 2383 ST2+ over ATM August 1998 + + + timer. If a setup-complete.ind primitive is indicated, the incoming + call processing is assumed to have succeeded. If the UNI 3.1 + signaling layer entity responds with anything other than this + primitive or if the timer expires, the processing rule is the same as + the SVC disconnect processing that is shown in section 6.5.4 and the + incoming call processing is assumed to have failed. + +6.5.3 VC release processing inside ST2+ SCMP layer + + When a VC release is required inside an ST2+ SCMP layer entity, if + the previous hop or next hop is connected with a PVC, the PVC state + is set to vacant and the VC release processing is assumed to be + completed. + + If the previous hop or next hop is connected with a point-to-point + SVC whose reverse channel is occupied, the state of the channel in + the VC is set to vacant, the SID information of the VC is updated, + and the VC release processing is assumed to be completed. + + If the previous hop or next hop is connected with a point-to-point + SVC whose reverse channel is vacant, if the previous hop is connected + with a point-to-multipoint SVC, or if the next hop is connected with + a point-to-multipoint SVC and the number of leaves is 1, then the + ST2+ SCMP layer entity sends a release.req primitive to the UNI 3.1 + signaling layer entity, then waits for a release.conf primitive + indication; when one is indicated, the VC release processing is + assumed to be completed. + + If the next hop is connected with a point-to-multipoint SVC and the + number of leaves is other than 1, the ST2+ SCMP layer entity sends a + drop-party.req primitive to the UNI 3.1 signaling layer entity, then + waits for a drop-party.conf primitive indication; when one is + indicated, the VC release processing is assumed to be completed. + +6.5.4 VC disconnect processing from UNI 3.1 signaling layer + + If an ST2+ SCMP layer entity corresponds to a UNI 3.1 signaling layer + entity, and if the ST2+ SCMP layer entity is sent a release.ind + primitive from the UNI 3.1 signaling layer entity, whose cause is a + delivery of a RELEASE message, the ST2+ SCMP layer entity responds + with a release.resp primitive, and then the VC disconnect processing + is assumed to be completed. If the ST2+ SCMP layer entity is sent a + release.ind primitive, whose cause is other than the previous case, + the ST2+ SCMP layer entity waits for a release.conf primitive + response. When a release.conf primitive is indicated, the VC + disconnect processing is assumed to be completed. + + + + + +Suzuki Informational [Page 32] + +RFC 2383 ST2+ over ATM August 1998 + + + Note that if next hops from ST2+ SCMP layer entities are connected + with a point-to-multipoint SVC, the ST2+ SCMP layer entities to next + hops correspond to a UNI 3.1 signaling layer entity. In this case, + if the ST2+ SCMP layer entities are sent release.ind primitives from + the UNI 3.1 signaling layer entity, whose cause is the delivery of a + RELEASE message, one of the ST2+ SCMP layer entities responds with a + release.resp primitive, and then the VC disconnect processing in the + entities that are sent release.ind primitives are assumed to be + completed. If the ST2+ SCMP layer entities are sent release.ind + primitives, whose cause is other than the previous case, the ST2+ + SCMP layer entities wait for release.conf primitives responses. When + release.conf primitives are indicated, the VC disconnect processing + in the entities that are indicated release.ind primitives are assumed + to be completed. + + If the ST2+ SCMP layer entity is sent a drop-party.ind primitive from + the UNI 3.1 signaling layer entity, the ST2+ SCMP layer entity + responds with a drop-party.resp primitive, and then the VC disconnect + processing is assumed to be completed. If the ST2+ SCMP layer entity + is sent a drop-party.conf primitive, the VC disconnect processing is + assumed to be completed. + +6.6 Additional SCMP Processing Rules + + This subsection specifies the additional SCMP processing rules that + are defined in RFC 1819 ST2+ protocol specification. The following + additional rules are applied when the previous hop or next hop is + connected with an ATM connection in the ST2+ SCMP layer entity. + +6.6.1 Additional connect.req processing rules + + When a connect.req primitive is sent to the ST2+ SCMP layer entity + for the next hop, the entity confirms whether or not the VC for the + next hop exists. + + If it does, the entity forwards a CONNECT message that does not + include a VC-type common SCMP element to the next hop. + + If it does not, the entity selects a VC style. If the result is a + PVC or a reverse channel of a bi-directional point-to-point SVC used + by an existing stream, the VC state is set to occupied. The entity + forwards a CONNECT message with a VC-type common SCMP element that + reflects the result of the selection to the next hop. + +6.6.2 Additional connect.ind processing rules + + The ST2+ SCMP layer entity for the previous hop confirms whether or + not the CONNECT message includes a VC-type common SCMP element. + + + +Suzuki Informational [Page 33] + +RFC 2383 ST2+ over ATM August 1998 + + + If a VC-type common SCMP element is not included and the VC for the + next hop exists, a connect.ind primitive is sent to the routing + machine. If the VC for the next hop does not exist, a REFUSE message + is forwarded to the previous hop. + + If a VC-type common SCMP element is included and a point-to-point + SVC, whose calling party is the upstream or downstream, or a point- + to-multipoint SVC is specified, a connect.ind primitive is sent to + the routing machine. If a PVC or a reverse channel of a bi- + directional point-to-point SVC used by an existing stream is + specified and the specified VC exists, the VC state is set to + occupied and a connect.ind primitive is sent to the routing machine. + Otherwise, a REFUSE message is forwarded to the previous hop. + +6.6.3 Additional change.req processing rules + + When a change.req primitive is sent to the ST2+ SCMP layer entity for + the next hop, the entity releases the VC whose process is shown in + section 6.5.3. + + Then, the entity selects a VC style. If the result is a PVC or a + reverse channel of a bi-directional point-to-point SVC used by an + existing stream, the VC state is set to occupied. The entity + forwards a CHANGE message with a VC-type common SCMP element that + reflects the result of the selection to the next hop. + +6.6.4 Additional change.ind processing rules + + The ST2+ SCMP layer entity for the previous hop confirms whether the + CHANGE message includes a VC-type common SCMP element. If a VC-type + common SCMP element is not included, a REFUSE message is forwarded to + the previous hop. + + If a VC-type common SCMP element is included, the entity releases the + VC whose process is shown in section 6.5.3. If the element specifies + a point-to-point SVC, whose calling party is the upstream or + downstream, or a point-to-multipoint SVC, a change.ind primitive is + sent to the routing machine. If a PVC or a reverse channel of a bi- + directional point-to-point SVC used by an existing stream is + specified and the specified VC exists, the VC state is set to + occupied and a change.ind primitive is sent to the routing machine. + Otherwise, a REFUSE message is forwarded to the previous hop. + +6.6.5 Additional accept.req processing rules + + When an accept.req primitive is sent to the ST2+ SCMP layer entity + for the previous hop, the entity confirms the state of the UNI 3.1 + signaling layer entity. If the state of the entity is other than U0 + + + +Suzuki Informational [Page 34] + +RFC 2383 ST2+ over ATM August 1998 + + + or U10, the accept.req primitive is queued and is processed after the + state changes to U0 or U10. + + If the state of the entity is U0 or U10, the ST2+ SCMP layer entity + confirms whether or not the VC for the previous hop exists. If it + does, an ACCEPT message is forwarded to the previous hop. + + If it does not and the CONNECT or CHANGE message that corresponds to + the accept.req primitive specified a point-to-point SVC whose calling + party is the upstream or a point-to-multipoint SVC, then the entity + processes an incoming call that is shown in section 6.5.2. If the + incoming call processing succeeds, an ACCEPT message is forwarded to + the previous hop. If the CONNECT or CHANGE message that corresponds + to the accept.req primitive specified a point-to-point SVC whose + calling party is downstream, the entity converts from the IP address + of the previous hop to the ATM address, and then the entity processes + an outgoing call that is shown in section 6.5.1. If the outgoing + call processing succeeds, an ACCEPT message is forwarded to the + previous hop. For cases other than those described above or if the + incoming or outgoing call processing fails, a REFUSE message is + forwarded to the previous hop and a disconnect.ind primitive is sent + to the routing machine. + +6.6.6 Additional accept.ind processing rules + + When an ACCEPT message is processed in the ST2+ SCMP layer entity for + the next hop, the entity confirms the state of the UNI 3.1 signaling + layer entity. If the state of the entity is other than U0 or U10, + the ACCEPT message is queued and is processed after the state changes + to U0 or U10. + + If the state of the entity is U0 or U10, the ST2+ SCMP layer entity + confirms whether or not the VC for the next hop exists. If it does, + an accept.ind primitive is sent to the routing machine. + + If it does not and the CONNECT or CHANGE message that corresponds to + the ACCEPT message specified a point-to-point SVC whose calling party + is the upstream or a point-to-multipoint SVC, then the entity + converts from the IP address of the next hop to the ATM address, and + then the entity processes an outgoing call that is shown in section + 6.5.1. If the outgoing call processing succeeds, an accept.ind + primitive is sent to the routing machine. If the CONNECT or CHANGE + message that corresponds to the ACCEPT message specified a point-to- + point SVC whose calling party is downstream, the entity processes an + incoming call that is shown in section 6.5.2. If the incoming call + processing succeeds, an accept.ind primitive is sent to the routing + machine. For cases other than those described above or if the + incoming or outgoing call processing fails, a refuse.ind primitive is + + + +Suzuki Informational [Page 35] + +RFC 2383 ST2+ over ATM August 1998 + + + sent to the routing machine and a DISCONNECT message is forwarded to + the next hop. + +6.6.7 Additional disconnect.req processing rules + + At first, the ST2+ SCMP layer entity for the next hop forwards a + DISCONNECT message to the next hop. + + And then, after the disconnect.req processing, if there are no more + targets that are connected downstream of the entity and the entity is + not waiting for an ACCEPT or REFUSE message response from targets, + the entity releases the VC whose process is shown in section 6.5.3. + +6.6.8 Additional disconnect.ind processing rules + + AT first, after the disconnect.ind processing, if there are no more + targets that are connected downstream of the ST2+ SCMP layer entity + for the previous hop and the entity is not waiting for an ACCEPT or + REFUSE message response from targets, the entity releases the VC + whose process is shown in section 6.5.3. + + And then, the entity sends a disconnect.ind primitive to the routing + machine. + +6.6.9 Additional refuse.req processing rules + + At first, the ST2+ SCMP layer entity for the previous hop forwards a + REFUSE message to the previous hop. + + And then, after the refuse.req processing, if there are no more + targets that are connected downstream of the entity and the entity is + not waiting for an ACCEPT or REFUSE message response from targets, + the entity releases the VC whose process is shown in section 6.5.3. + +6.6.10 Additional refuse.ind processing rules + + At first, after the refuse.ind processing, if there are no more + targets that are connected downstream of the ST2+ SCMP layer entity + for the next hop and the entity is not waiting for an ACCEPT or + REFUSE message response from targets, the entity releases the VC + whose process is shown in section 6.5.3. + + And then, the entity sends a refuse.ind primitive to the routing + machine. + + + + + + + +Suzuki Informational [Page 36] + +RFC 2383 ST2+ over ATM August 1998 + + +6.6.11 SVC disconnect processing + + When the ST2+ SCMP layer entity for the previous hop is sent a SVC + disconnect processing from the UNI 3.1 signaling layer entity and + then the SVC disconnect processing is completed, the entity forwards + a REFUSE message to the previous hop and sends a disconnect.ind + primitive to the routing machine. + + When the ST2+ SCMP layer entity for the next hop is sent a SVC + disconnect processing from the UNI 3.1 signaling layer entity and + then the SVC disconnect processing is completed, the entity sends a + refuse.ind primitive to the routing machine and forwards a DISCONNECT + message to the previous hop. + +6.7 UNI 3.1 Signaling Information Element Coding Rules + + The ST2+ over ATM protocol does not specify the coding rules needed + for the following information elements in UNI 3.1 signaling. The + usages of these information elements are specified in [10]. + + o Protocol discriminator + + o Call reference + + o Message type + + o Message length + + o Call state + + o Called party number + + o Called party subaddress + + o Calling party number + + o Calling party subaddress + + o Cause + + o Connection identifier + + o Broadband repeat indicator + + o Restart indicator + + o Broadband sending complete + + + + +Suzuki Informational [Page 37] + +RFC 2383 ST2+ over ATM August 1998 + + + o Transit network selection + + o Endpoint reference + + o Endpoint state + +6.7.1 ATM adaptation layer parameters coding + + The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must + include an ATM adaptation layer parameters information element. The + CONNECT message may or may not include this element. The coding + rules for the fields are as follows. + + o The AAL Type is set to AAL5. + + o The value of the Forward maximum CPCS size field is set to the same + as that of the MaxMsgSize field in the CONNECT SCMP message + corresponding to the SETUP or ADD PARTY message. + + o If the VC is established as a point-to-point call, the value of the + Backward maximum CPCS size field is set the same as that of the + Forward maximum CPCS size field. If the VC is established as a + point-to-multipoint call, the value of the Backward maximum CPCS + size field is set to zero. + + o The SSCS type is set to null. + +6.7.2 ATM traffic descriptor coding + + If the Null FlowSpec is specified in the ST2+ over ATM protocol, the + coding rules for the fields in the ATM traffic descriptor information + element in the SETUP message are as follows. + + o The value of the Forward PCR (CLP=0+1) field depends on the + specification of the ATM network. The Forward PCR (CLP=0+1) field + in each ATM interface in an implementation must be configurable to + any value between zero and 16,777,215. + + o If the VC is established as a point-to-point call, the value of the + Backward PCR (CLP=0+1) field is set the same as that of the Forward + PCR (CLP=0+1) field. If the VC is established as a point-to- + multipoint call, the value of the Backward PCR (CLP=0+1) field is + set to zero. + + o The Best effort indication must be present. + + If the Controlled-Load Service FlowSpec is specified, the coding + rules for the fields are as follows. + + + +Suzuki Informational [Page 38] + +RFC 2383 ST2+ over ATM August 1998 + + + o The value of the Forward PCR (CLP=0+1) field depends on the + specification of the ATM network. The Forward PCR (CLP=0+1) field + in each ATM interface in an implementation must be configurable to + any value between zero and 16,777,215. + + o If the VC is established as a point-to-point call, the value of the + Backward PCR (CLP=0+1) field is set the same as that of the Forward + PCR (CLP=0+1) field. If the VC is established as a point-to- + multipoint call, the value of the Backward PCR (CLP=0+1) field is + set to zero. + + o The method for calculating the Forward SCR (CLP=0+1) field is shown + in section 5. + + o If the VC is established as a point-to-point call, the value of the + Backward SCR (CLP=0+1) field is set the same as that of the Forward + SCR (CLP=0+1) field. If the VC is established as a point-to- + multipoint call, this field must not be present. + + o The method for calculating the Forward MBS (CLP=0+1) field is shown + in section 5. + + o If the VC is established as a point-to-point call, the value of the + Backward MBS (CLP=0+1) field is set the same as that of the Forward + MBS (CLP=0+1) field. If the VC is established as a point-to- + multipoint call, this field must not be present. + + o The Best effort indication, Tagging backward, and Tagging forward + fields must not be present. + +6.7.3 Broadband bearer capability coding + + If the Null FlowSpec is specified in the ST2+ over ATM protocol, the + coding rules for the fields in the Broadband bearer capability + information element in the SETUP message are as follows. + + o The Bearer class depends on the specification of the ATM network. + The Bearer class in each ATM interface in an implementation must be + configurable as either BCOB-X or BCOB-C. BCOB-X is recommended as + the default configuration. + + o The Traffic type and Timing requirements fields must not be + present. + + o The Susceptibility to clipping field is set to not susceptible to + clipping. + + + + + +Suzuki Informational [Page 39] + +RFC 2383 ST2+ over ATM August 1998 + + + o If the VC is established as a point-to-point call, the User plane + connection configuration field is set to point-to-point, and if the + VC is established as a point-to-multipoint call, it is set to + point-to-multipoint. + + If the Controlled-Load Service FlowSpec is specified, the coding + rules for the fields are as follows. + + o The Bearer class depends on the specification of the ATM network. + The Bearer class in each ATM interface in an implementation must be + configurable as either BCOB-X or BCOB-C. BCOB-X is recommended as + the default configuration. + + o If the Bearer class is BCOB-X, the Traffic type and Timing + requirements fields depend on the specification of the ATM network. + The Traffic type and Timing requirements fields in each ATM + interface in an implementation must be configurable as either no + indication or VBR and Not required, respectively. No indication is + recommended as the default configuration. If the Bearer class is + BCOB-C, the Traffic type and Timing requirements fields must not be + present. + + o The Susceptibility to clipping field depends on the specification + of the ATM network. The Susceptibility to clipping field in each + ATM interface in an implementation must be configurable as either + not susceptible to clipping or susceptible to clipping. Not + susceptible to clipping is recommended as the default + configuration. + + o If the VC is established as a point-to-point call, the User plane + connection configuration field is set to point-to-point, and if the + VC is established as a point-to-multipoint call, it is set to + point-to-multipoint. + +6.7.4 Broadband high layer information coding + + The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must + include a Broadband high layer information information element. The + coding rules for the fields are as follows. + + o The High layer information type is set to User specific. + + o The first 6 bytes in the High layer information field are set to + the SID of the stream corresponding to the VC. + + + + + + + +Suzuki Informational [Page 40] + +RFC 2383 ST2+ over ATM August 1998 + + +6.7.5 Broadband low layer information coding + + The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must + include a Broadband low layer information information element. The + CONNECT message may or may not include this element. The coding + rules for the fields are as follows. + + o The User information layer 3 protocol field is set to ISO/IEC TR + 9577. + + o The IPI field is set to IEEE 802.1 SNAP (0x80). + + o The OUI field is set to IANA (0x00-00-5E). + + o The PID field is set to ST2+ (TBD). + +6.7.6 QoS parameter coding + + If the Null FlowSpec is specified in the ST2+ over ATM protocol, the + coding rules for the fields in the QoS parameter in the SETUP message + are as follows. + + o The QoS class forward and QoS class backward fields are set to QoS + class 0. + + If the Controlled-Load Service FlowSpec is specified, the coding + rules for the fields are as follows. + + o The QoS class forward and QoS class backward fields depend on the + specification of the ATM network. The QoS class forward and QoS + class backward fields in each ATM interface in an implementation + must be configurable as either QoS class 0 or QoS class 3. QoS + class 0 is recommended as the default configuration. + +7. Security Considerations + + The ST2+ over ATM protocol modifies RFC 1819 ST2+ protocol, but + basically these modifications are minimum extensions for ATM support + and bug fixes, so they do not weaken the security of the ST2+ + protocol. + + The ST2+ over ATM protocol specifies protocol interaction between + ST2+ and UNI 3.1, and this does not weaken the security of the UNI + 3.1 protocol. + + In an ST2+ agent that processes an incoming call of SVC, if the + incoming SETUP message contains the calling party number and if it is + verified and passed by the ATM network or it is provided by the + + + +Suzuki Informational [Page 41] + +RFC 2383 ST2+ over ATM August 1998 + + + network, then it is feasible to use the calling party number for part + of the calling party authentication to strengthen security. + +References + + [1] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration + of Real-time Services in an IP-ATM Network Architecture", RFC + 1821, August 1995. + + [2] Jackowski, S., "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] Delgrossi, L., and L. Berger, Ed., "Internet Stream Protocol + Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, + August 1995. + + [5] Wroclawski, J., "Specification of the Controlled-Load Network + Element Service", RFC 2211, September 1997. + + [6] Shenker, S., Partridge, C., and R. Guerin, "Specification of + Guaranteed Quality of Service", RFC 2212, September 1997. + + [7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", + RFC 2210, September 1997. + + [8] Garrett, M., and M. Borden, "Interoperation of Controlled-Load + Service and Guaranteed Service with ATM", RFC 2381, August 1998. + + [9] Ghanwani, A., Pace, J., and V. Srinivasan, "A Framework for + Providing Integrated Services Over Shared and Switched LAN + Technologies", Work in Progress. + + [10] The ATM Forum, "ATM User-Network Interface Specification + Version 3.1", September 1994. + + [11] The ATM Forum, "ATM User-Network Interface (UNI) Signaling + Specification Version 4.0", af-sig-0061.000, July 1996. + + [12] 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. + + + + + + +Suzuki Informational [Page 42] + +RFC 2383 ST2+ over ATM August 1998 + + + [13] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)- + Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network + Interface Layer 3 Specification for Point-to-Multipoint + Call/Connection Control", ITU-T Recommendation Q.2971, October + 1995. + + [14] ITU-T, "B-ISDN Protocol Reference Model and its Application", + CCITT Recommendation I.321, April 1991. + + [15] ITU-T, "B-ISDN ATM Adaptation Layer (AAL) type 5 specification", + Draft new ITU-T Recommendation I.363.5, September 1995. + + [16] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation + Layer 5", RFC 1483, July 1993. + + [17] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, January + 1994. + + [18] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and + A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, + February 1995. + + [19] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next + Hop Resolution Protocol (NHRP)", RFC 2332, April 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Suzuki Informational [Page 43] + +RFC 2383 ST2+ over ATM August 1998 + + +Acknowledgments + + ATM is a huge technology and without the help of many colleagues at + NTT who are involved in ATM research and development, it would have + been impossible for me to complete this protocol specification. I + would like to thank Hideaki Arai and Naotaka Morita of the NTT + Network Strategy Planning Dept., Shin-ichi Kuribayashi, Jun Aramomi, + and Takumi Ohba of the NTT Network Service Systems Labs., and also + Hisao Uose and Yoshikazu Oda of the NTT Multimedia Networks Labs. + for their valuable comments and discussions. + + And I would also like to especially thank Eric Crawley of Gigapacket + Networks, John Wroclawski of MIT, Steven Jackowski of Net Manage, + Louis Berger of FORE Systems, Steven Willis of Bay Networks, Greg + Burch of Qosnetics, and Denis Gallant, James Watt, and Joel Halpern + of Newbridge Networks for their valuable comments and suggestions. + + Also this specification is based on various discussions during NTT + Multimedia Joint Project with NACSIS. I would like to thank + Professor Shoichiro Asano of the National Center for Science + Information Systems for his invaluable advice in this area. + +Author's Address + + Muneyoshi Suzuki + NTT Multimedia Networks Laboratories + 3-9-11, Midori-cho + Musashino-shi, Tokyo 180-8585, Japan + + Phone: +81-422-59-2119 + Fax: +81-422-59-2829 + EMail: suzuki@nal.ecl.net + + + + + + + + + + + + + + + + + + + +Suzuki Informational [Page 44] + +RFC 2383 ST2+ over ATM August 1998 + + +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 sentence: + +< 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.3.2 Other Cases + +The following sentence: + +< CONNECT with a REFUSE message with the affected targets specified in +< the TargetList and an appropriate ReasonCode (StreamExists). + +should be changed to + +> CONNECT with a REFUSE message with the affected targets specified in +> the TargetList and an appropriate ReasonCode (TargetExists). + +A.4 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 Informational [Page 45] + +RFC 2383 ST2+ over ATM August 1998 + + +A.5 6.2.1 Problems in Stream Recovery + +The following sentence: + +< some time after a failure. As a result, the ST agent attempting the +< recovery may receive ERROR messages for the new CONNECTs that are +< ... +< failure, and will interpret the new CONNECT as resulting from a +< routing failure. It will respond with an ERROR message with the +< appropriate ReasonCode (StreamExists). Since the timeout that the ST +< ... +< remnants of the broken stream will soon be torn down by a DISCONNECT +< message. Therefore, the ST agent that receives the ERROR message with +< ReasonCode (StreamExists) should retransmit the CONNECT message after + +should be changed to + +> some time after a failure. As a result, the ST agent attempting the +> recovery may receive REFUSE messages for the new CONNECTs that are +> ... +> failure, and will interpret the new CONNECT as resulting from a +> routing failure. It will respond with a REFUSE message with the +> appropriate ReasonCode (TargetExists). Since the timeout that the ST +> ... +> remnants of the broken stream will soon be torn down by a DISCONNECT +> message. Therefore, the ST agent that receives the REFUSE message with +> ReasonCode (TargetExists) should retransmit the CONNECT message after + +A.6 6.3 Stream Preemption} + +The following sentence: + +< (least important) to 256 (most important). This value is + +should be changed to + +> (least important) to 255 (most important). This value is + +A.7 10.2 Control PDUs + +The following sentence: + +<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 + + + + +Suzuki Informational [Page 46] + +RFC 2383 ST2+ over ATM August 1998 + + +>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.8 10.3.4 Origin + +The following: + +< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +< | PCode = 5 | PBytes | NextPcol |OriginSAPBytes | +< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +should be changed to + +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +> | PCode = 4 | PBytes | NextPcol |OriginSAPBytes | +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +A.9 10.4.1 ACCEPT + +The following sentence: + +<o IPHops is the number of IP encapsulated hops traversed by the +< stream. This field is set to zero by the origin, and is incremented +< at each IP encapsulating agent. + +should be changed to + +>o IPHops is the number of IP encapsulated hops traversed by the +> stream. + +A.10 10.4.2 ACK + +The following: + +< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +< | OpCode = 2 | 0 | TotalBytes | +< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +should be changed to + +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +> | OpCode = 2 | 0 | TotalBytes = 16 | +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Suzuki Informational [Page 47] + +RFC 2383 ST2+ over ATM August 1998 + + +A.11 10.4.3 CHANGE + +The following sentence: + +<o I (bit 7) is used to indicate that the LRM is permitted to interrupt + +should be changed to + +>o I (bit 9) is used to indicate that the LRM is permitted to interrupt + +A.12 10.4.7 HELLO + +The following: + +< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +< | OpCode = 7 |R| 0 | TotalBytes | +< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +should be changed to + +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +> | OpCode = 7 |R| 0 | TotalBytes = 20 | +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +A.13 10.4.9 JOIN-REJECT + +The following sentence: + +<o Reference contains a number assigned by the ST agent sending the +< REFUSE for use in the acknowledging ACK. + +should be changed to + +>o Reference contains a number assigned by the ST agent sending the +> JOIN-REJECT for use in the acknowledging ACK. + +A.14 10.4.13 STATUS-RESPONSE + +The following sentence: + +< possibly Groups of the stream. It the full target list can not fit in + +should be changed to + +> possibly Groups of the stream. If the full target list can not fit in + + + + + + +Suzuki Informational [Page 48] + +RFC 2383 ST2+ over ATM August 1998 + + +A.15 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 Informational [Page 49] + +RFC 2383 ST2+ over ATM August 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Suzuki Informational [Page 50] + |