📄 rfc2383.txt
字号:
+---------------------------------+ | 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 19983. 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⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -