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