idnits 2.17.1 draft-suzuki-st2-over-atm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 1997) is 9692 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'M' on line 540 == Unused Reference: '1' is defined on line 1866, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1870, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1873, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1887, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1894, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1821 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1946 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 1483 (ref. '16') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1577 (ref. '17') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Muneyoshi Suzuki 3 INTERNET DRAFT NTT 4 Expires April 14, 1998 October 14, 1997 6 ST2+ over ATM 7 Protocol Specification - UNI 3.1 Version 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document specifies an ATM-based protocol for communication 31 between ST2+ agents. The ST2+ over ATM protocol supports the matching 32 of one hop in an ST2+ tree-structure stream with one ATM connection. 33 In this document, ATM is a subnet technology for the ST2+ stream. 35 The ST2+ over ATM protocol is designed to achieve resource- 36 reservation communications across ATM and non-ATM networks, to extend 37 the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ 38 signaling limitations. 40 The specifications of the ST2+ over ATM protocol consist of a 41 revision of RFC 1819 ST2+ and specifications of protocol interaction 42 between ST2+ and ATM on the user plane, management plane, and control 43 plane which correspond to the three planes of the B-ISDN protocol 44 reference model. 46 1. Introduction 48 1.1 Purpose of Document 50 The purpose of this document is to specify an ATM-based protocol for 51 communication between ST2+ agents. 53 The ST2+ over ATM protocol is designed to support the matching of one 54 hop in an ST2+ tree-structure stream with one ATM connection; it is 55 not designed to support an entire ST2+ tree-structure stream with a 56 point-to-multipoint ATM connection only. 58 Therefore, in this document, ATM is only a subnet technology for the 59 ST2+ stream. This specification is designed to enable resource- 60 reservation communications across ATM and non-ATM networks. 62 1.2 Features of ST2+ over ATM Protocol 64 o Enables resource-reservation communications across ATM and non-ATM 65 networks. 67 ATM native API supports resource-reservation communications only 68 within an ATM network; it cannot support interworking with non-ATM 69 networks. This is because 71 - ATM native API cannot connect terminals without an ATM interface. 73 - ATM native API does not support IP addressing and SAP (port) 74 addressing systems. 76 o Extends UNI 3.1/4.0 signaling functions. 78 ST2+ SCMP supports MTU-size negotiation at all hops in an ST2+ 79 tree-structure stream. UNI 3.1/4.0 supports only max CPCS_SDU 80 (i.e., MTU) negotiation with the called party of a point-to-point 81 call or with the first leaf of a point-to-multipoint call. 83 o Reduces UNI 4.0 LIJ signaling limitations. 85 The ST2+ over ATM protocol supports UNI 4.0 LIJ Call Identifier 86 notification from the root to the leaf by using an ST2+ SCMP 87 extension. LIJ Call Identifier discovery at the leaf is one of the 88 major unsolved problems of UNI 4.0, and the ST2+ over ATM protocol 89 provides a solution. 91 Note: The UNI 3.1 version of the ST2+ over ATM protocol does not 92 support the above feature. It will be supported by the UNI 3.1/4.0 93 version. 95 1.3 Goals and Non-goals of ST2+ over ATM Protocol 97 The ST2+ over ATM protocol is designed to achieve the following 98 goals. 100 o Specify protocol interaction between ST2+ [4] and ATM on the ATM 101 Forum Private UNI 3.1/4.0 (Sb point) [10, 11]. 103 Note: The UNI 3.1 version of the ST2+ over ATM protocol does not 104 support UNI 4.0. It will be supported by the UNI 3.1/4.0 version. 106 o Support ST2+ stream across ATM and non-ATM networks. 108 o Define one VC on the UNI corresponding to one ST2+ hop; this VC is 109 not shared with other ST2+ hops, and also this ST2+ hop is not 110 divided into multiple VCs. 112 o Support both SVC and PVC. 114 o Not require any ATM specification changes. 116 o Coexist with RFC 1483 [16] IPv4 encapsulation. 118 o Coexist with RFC 1577 [17] ATMarp. 120 o Coexist with RFC 1755 [18] ATM signaling for IPv4. 122 o Coexist with NHRP [19]. 124 Because ST2+ is independent of both routing and IP address resolution 125 protocols, the ST2+ over ATM protocol does not specify the following 126 protocols. 128 o IP-ATM address resolution protocol 130 o Routing protocol 132 Because the ST2+ over ATM protocol is specified for the UNI, it is 133 independent of: 135 o NNI protocol 137 o Router/switch architecture 139 2. Protocol Architecture 141 The ST2+ over ATM protocol specifies the interaction between ST2+ and 142 ATM on the user, management, and control planes, which correspond to 143 the three planes in ITU-T Recommendation I.321 B-ISDN Protocol 144 Reference Model [14]. 146 2.1 User Plane Architecture 148 The user plane specifies the rules for encapsulating the ST2+ Data 149 PDU into the AAL5 [15] PDU. An user plane protocol stack is shown in 150 Fig. 2.1. 152 +---------------------------------+ 153 | RFC 1819 ST2+ | 154 | (ST2+ Data) | 155 +---------------------------------+ Point of ST2+ over ATM 156 |/////////////////////////////////| <--- protocol specification of 157 +---------------------------------+ user plane 158 | | 159 | | 160 | I.363.5 | 161 | | 162 | AAL5 | 163 | | 164 | | 165 +---------------------------------+ 166 | I.361 ATM | 167 +---------------------------------+ 168 | PHY | 169 +----------------+----------------+ 170 | UNI 171 +--------||------- 173 Fig. 2.1: User plane protocol stack. 175 An example of interworking from an ATM network to an IEEE 802.X LAN 176 is shown in Fig. 2.2. 178 ST2+ ST2+ ST2+ 179 Origin ATM Cloud Intermediate Agent Target 180 +---------+ +---------+ 181 | AP |--------------------------------------------->| AP | 182 +---------+ +-------------------+ +---------+ 183 |ST2+ Data|------------------>| RFC 1819 ST2+ Data|----->|ST2+ Data| 184 +---------+ +---------+---------+ +---------+ 185 |I.363 AAL|------------------>|I.363 AAL| SNAP |----->| SNAP | 186 +---------+ +---------+ +---------+---------+ +---------+ 187 |I.361 ATM|--->|I.361 ATM|--->|I.361 ATM| LLC |----->| LLC | 188 +---------+ +---------+ +---------+---------+ +---------+ 189 | | | | | |IEEE802.X| |IEEE802.X| 190 | PHY |--->| PHY |--->| PHY | & 802.1p|----->| & 802.1p| 191 +---------+ +---------+ +---------+---------+ +---------+ 193 Fig. 2.2: Example of interworking from 194 an ATM network to an IEEE 802.X LAN. 196 The ATM cell supports priority indication using the CLP field; 197 indication is also supported by the ST2+ Data PDU by using the Pri 198 field. It may be feasible to map these fields to each other. The 199 ST2+ over ATM protocol specifies an optional function that maps the 200 Pri field in the ST header to the CLP field in the ATM cell. 201 However, implementors should note that current ATM standardization 202 tends not to support tagging. 204 2.2 Management Plane Architecture 206 The management plane specifies the Null FlowSpec, the Controlled-Load 207 Service [5] FlowSpec, and the Guaranteed Service [6] FlowSpec mapping 208 rules [8] for UNI 3.1 traffic management. A management plane 209 protocol stack is shown in Fig. 2.3. 211 +---------------------------------+ 212 | Null FlowSpec | 213 |Controlled-Load Service FlowSpec | 214 | Guaranteed Service FlowSpec | 215 +---------------------------------+ Point of ST2+ over ATM 216 |/////////////////////////////////| <--- protocol specification of 217 +---------------------------------+ management plane 218 | | 219 | UNI 3.1 | 220 | | 221 | | 222 | Traffic Management | 223 | | 224 | | 225 | VBR/UBR | 226 | | 227 +---------------------------------+ 229 Fig. 2.3: Management plane protocol stack. 231 Note: The UNI 3.1 version of the ST2+ over ATM protocol does not 232 support Guaranteed Services. It will be supported by the UNI 3.1/4.0 233 version. 235 The ST2+ over ATM protocol specifies the ST FlowSpec format for the 236 Integrated Services. Basically, FlowSpec parameter negotiation, 237 except for the MTU, is not supported. This is because, in the ST2+ 238 environment, negotiated FlowSpec parameters are not always unique to 239 each target. The current ATM standard does not support heterogeneous 240 QoS to receivers. 242 The ST2+ over ATM protocol supports FlowSpec changes by using the 243 CHANGE message (RFC 1819, Section 4.6.5) if the I-bit in the CHANGE 244 message is set to one and if the CHANGE message affects all targets 245 in the stream. This is because the UNI 3.1 does not support QoS 246 changes. The ST2+ over ATM protocol supports FlowSpec changes by 247 releasing old ATM connections and establishing new ones. 249 The ST2+ over ATM protocol does not support stream preemption (RFC 250 1819, Section 6.3). This is because the Integrated Services FlowSpec 251 does not support the concept of precedence. 253 It does not support the ST2+ FlowSpec (RFC 1819, Section 9.2). ST2+ 254 FlowSpec specifies useful services, but requires a datalink layer to 255 support heterogeneous QoS to receivers. The current ATM standard 256 does not support heterogeneous QoS to receivers. 258 2.3 Control Plane Architecture 260 The control plane specifies the relationship between ST2+ SCMP and 261 PVC management for ST2+ data and the protocol interaction between 262 ST2+ SCMP and UNI 3.1 signaling [10]. A control plane protocol stack 263 is shown in Fig. 2.4. 265 +---------------------------------+ 266 | RFC 1819 ST2+ | 267 | (ST2+ SCMP) | 268 +---------------------------------+ Point of ST2+ over ATM 269 |/////////////////////////////////| <--- protocol specification of 270 +----------------+----------------+ control plane 271 | IEEE 802 |UNI3.1 Signaling| 272 | SNAP +----------------+ 273 +----------------+ Q.2130 SSCF | 274 | ISO 8802-2 +----------------+ 275 | LLC Type1 | Q.2110 SSCOP | 276 +----------------+----------------+ 277 | I.363.5 AAL5 | 278 +---------------------------------+ 279 | I.361 ATM | 280 +---------------------------------+ 281 | PHY | 282 +----------------+----------------+ 283 | UNI 284 +--------||------- 286 Fig. 2.4: Control plane protocol stack. 288 The ST2+ SCMP PDU is mapped to the AAL5 PDU based on the RFC 1483 LLC 289 encapsulation format. The ST2+ over ATM protocol does not cover a VC 290 (SVC/PVC) that transfers ST2+ SCMP. VCs for IPv4 transfer may be used 291 for ST2+ SCMP transfer, and implementations may provide particular 292 VCs for ST2+ SCMP transfer. Selection of these VCs depends on the 293 implementation. 295 Implementors should note that when ST2+ data and SCMP belong to a 296 stream, the routing directions on the ST2+ layer must be the same. 297 Implementors should also note that ST2+ and IPv4 directions for 298 routing to the same IP destination address are not always the same. 300 The ST2+ over ATM protocol supports both SVC and PVC for ST2+ Data 301 PDU transfer. If SVC is used, the ST2+ and ATM layers establish a 302 connection sequentially by using respectively ST2+ SCMP and UNI 3.1 303 signaling. An example of ST2+ SCMP and UNI 3.1 signaling message 304 flows for establishing and releasing of ST2+ data connections is 305 shown in Fig. 2.5, where (S) means an ST2+ entity and (Q) means a UNI 306 3.1 signaling entity. 308 ATM SW ATM SW 309 +------------+ UNI +----+ NNI +----+ UNI +------------+ 310 ____|Intermediate|--||--| \/ |______| \/ |--||--|Intermediate|____ 311 | (Upstream) | | /\ | | /\ | |(Downstream)| 312 +------------+ +----+ +----+ +------------+ 313 SCMP 314 ------->(S)<------------------------------------------>(S)<------- 315 \ UNI Sig. UNI Sig. / 316 CONNECT | (Q)<--------->(Q)<-------->(Q)<--------->(Q) | 317 -------->| | 318 ACK <----|--------------------CONNECT------------------>| CONNECT 319 |<---------------------ACK---------------------|--------> 320 | |<--- ACK 321 | | ACCEPT 322 | |<-------- 323 |<-------------------ACCEPT--------------------|---> ACK 324 |----------------------ACK-------------------->| 325 | | 326 |->|----SETUP--->| | | | 327 | |<-CALL PROC--|----------->|----SETUP--->|->| 328 | | | |<----CONN----|<-| 329 ACCEPT | |<----CONN----|<-----------|--CONN ACK-->|->| 330 <--------|<-|--CONN ACK-->| | | | 331 ACK ---->| | 332 | | 333 -------\ |--------------------------------------------\ |-------\ 334 >| ST2+ Data >| > 335 -------/ |--------------------------------------------/ |-------/ 336 | | 337 DISCONN | | 338 -------->| | 339 ACK <----|-------------------DISCONNECT---------------->| 340 |<---------------------ACK---------------------| 341 | | 342 |->|---RELEASE-->| | | | 343 |<-|<--REL COMP--|----------->|---RELEASE-->|->| DISCONN 344 | | | |<--REL COMP--|<-|--------> 345 | |<--- ACK 347 Fig. 2.5: Example of ST2+ SCMP and UNI 3.1 signaling message flows. 349 UNI 3.1/4.0 specifies PVC, point-to-point SVC, and point-to- 350 multipoint SVC as VC styles. However, in actual ATM network 351 environments, especially public ATM WANs, only PVC and bi-directional 352 point-to-point SVC may be supported. To support the diverse VC 353 styles, the ST2+ over ATM protocol supports the following VC styles 354 for ST2+ Data PDU transfer. 356 o PVC 358 o Reuse of reverse channel of bi-directional point-to-point SVC that 359 is used by existing stream. 361 o Point-to-point SVC initiated from upstream side. 363 o Point-to-multipoint SVC initiated from upstream side. 365 o Point-to-point SVC initiated from downstream side. 367 o Point-to-multipoint SVC initiated from downstream side (LIJ). 369 Note: The UNI 3.1 version of the ST2+ over ATM protocol does not 370 support LIJ. LIJ will be supported by the UNI 3.1/4.0 version. 372 The second style is needed in environments supporting bi-directional 373 point-to-point SVC only. The selection of PVC and SVC styles in the 374 ST2+ agent is based on preconfigured implementation-dependent rules. 376 SVC supports both upstream and downstream call initiation styles. 377 Implementors should note that this is independent of the sender- 378 oriented and receiver-oriented ST2+ stream-building process (RFC 379 1819, Section 4.1.1). This is because the ST2+ over ATM protocol 380 specifies the process for establishing ST2+ data hops on the UNI, and 381 because the ST2+ stream building process belongs to another layer. 382 The SVC initiation side should be determined based on the operational 383 and billing policies between ST2+ agents; this is basically 384 independent of the sender-oriented and receiver-oriented ST2+ 385 stream-building process. 387 An example of ST2+ SCMP interworking is shown in Fig. 2.6. 389 _____ 390 / \ 391 (Origin ) 392 \ / 393 A ~~|~~ A 394 | = | UNI Signaling 395 | | | 396 | +-+-+ V 397 | | X | ATM SW 398 | +-+-+ A 399 SCMP | | | NNI Signaling 400 | +-+-+ V 401 | | X | ATM SW 402 | +-+-+ A 403 | | | 404 | = | UNI Signaling 405 V | V 406 +-----+------+ IEEE 802.X & 802.1p 407 | |<---------------------+ 408 |Intermediate|--------------------+ | 409 | |<-----------------+ | | 410 +------------+ L2 Signaling| | | 411 A | A | | | 412 | = | UNI Signaling | | | SCMP 413 | | | | | | 414 | +-+-+ V | | | 415 | | X | ATM SW V | | 416 | +-+-+ A +---+-|-+ 417 SCMP | | | NNI Signaling | \ /| | 418 | +-+-+ V | X | |LAN SW 419 | | X | ATM SW | / \| | 420 | +-+-+ A +---+-|-+ 421 | | | A | | 422 | = | UNI Signaling | | | 423 V __|__ V V_|_V 424 / \ / \ 425 (Target ) (Target ) 426 \ / \ / 427 ~~~~~ ~~~~~ 429 Fig. 2.6: Example of ST2+ SCMP interworking. 431 3. Revision of RFC 1819 ST2+ 433 To specify the ST2+ over ATM protocol, the functions in RFC 1819 ST2+ 434 must be extended to support ATM. However, it is difficult for the 435 current ATM standard to support part of the specifications in RFC 436 1819 ST2+. This section specifies the extended, restricted, 437 unsupported, and modified functions in RFC 1819 ST2+. Errata for RFC 438 1819 appears in Appendix A. 440 3.1 Extended Functions of RFC 1819 ST2+ 442 3.1.1 ST FlowSpec for Controlled-Load Service 444 The ST2+ over ATM protocol specifies the ST FlowSpec format for the 445 Integrated Services. Basically, FlowSpec parameter negotiation, 446 except for the MTU, is not supported. The ST2+ intermediate agent 447 and the target decide whether to accept or refuse the FlowSpec 448 parameters, except for the MTU. Therefore, each of the FlowSpec 449 parameter values other than MTU is the same at each target in the 450 stream. 452 The format of the ST FlowSpec for the Controlled-Load Service is 453 shown in Fig. 3.1. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | PCode = 1 | PBytes = 36 | ST FS Ver = 8 | 0(unused) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Ver=0 | 0(reserved) | Overall Length = 7 | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | SVC Number |0| 0(reserved) | SVC Length = 6 | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |Param Num = 127| Flags = 0 | Param Length = 5 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Token Bucket Size [b] (32-bit IEEE floating point number) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Peak Data Rate [p] (32-bit IEEE floating point number) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Minimum Policed Unit [m] | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Maximum Packet Size [M] | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Fig. 3.1: Format of ST FlowSpec for Controlled-Load Service. 479 The PCode field identifies common SCMP elements. The PCode value 480 for the ST2+ FlowSpec is 1. 482 The PBytes field for the Controlled-Load Service is 36 bytes. 484 The ST FS Ver (ST FlowSpec Version) field identifies the ST 485 FlowSpec version. The ST FlowSpec version number for the 486 Integrated Services is 8. 488 The Ver (Message Format Version) field identifies the Integrated 489 Services FlowSpec message format version. The current version is 490 zero. 492 The Overall Length field for the Controlled-Load Service is 7 493 words. 495 The SVC Number (Service ID Number) field identifies the Integrated 496 Services. If the Integrated Services FlowSpec appears in the 497 CONNECT or CHANGE message, the value of the SVC Number field is 1. 498 If it appears in the ACCEPT, NOTIFY, or STATUS-RESPONSE message, 499 the value of the SVC Number field is 5. 501 The SVC Length (Service-specific Data Length) field for the 502 Controlled-Load Service is 6 words. 504 The Param Num (Parameter Number) field is 127. 506 The Flags (Per-parameter Flags) field is zero. 508 The Param Length (Length of Per-parameter Data) field is 5 words. 510 Definitions of the Token Bucket Rate [r], the Token Bucket Size 511 [b], the Peak Data Rate [p], the Minimum Policed Unit [m], and the 512 Maximum Packet Size [M] fields are given in [5]. See section 5 of 513 [5] for details. 515 The ST2+ agent, that creates the FlowSpec element in the SCMP 516 message, must assign valid values to all fields. The other agents 517 must not modify any values in the element. 519 The MaxMsgSize field in the CONNECT message is assigned by the origin 520 or the intermediate agent acting as origin, and updated by each agent 521 based on the MTU value of the datalink layer. 523 The negotiated value of MaxMsgSize is set back to the origin or the 524 intermediate agent acting as origin using the [M] field and the 525 MaxMsgSize field in the ACCEPT message that corresponds to the 526 CONNECT message. 528 In the original definition of the Controlled-Load Service, the value 529 of the [m] field must be less than or equal to the value of the [M] 530 field. However, in the ST FlowSpec for the Controlled-Load Service, 531 if the value of the [m] field is more than that of the [M] field, the 532 value of the [m] field is regarded as the same value as the [M] 533 field, and must not generate an error. This is because there is a 534 possibility that the value of the [M] field in the ACCEPT message may 535 be decreased by negotiation. 537 In the ST2+ SCMP messages, the value of the [M] field must be equal 538 to or less than 65,535. In the ACCEPT message that responds to 539 CONNECT, or the NOTIFY message that contains the FlowSpec field, the 540 value of the [M] field must be equal to the MaxMsgSize field in the 541 message. If these values are not the same, FlowSpec is regarded as 542 an error. 544 If the ST2+ agent receives the CONNECT message that contains 545 unacceptable FlowSpec, the agent must generate a REFUSE message. 547 3.1.2 ST FlowSpec for Guaranteed Service 549 Note: The UNI 3.1 version of the ST2+ over ATM protocol does not 550 support Guaranteed Services. It will be supported by the UNI 3.1/4.0 551 version. 553 3.1.3 VC-type common SCMP element 555 The ST2+ over ATM protocol specifies an additional common SCMP 556 element that designates the VC type used to support the diverse VC 557 styles. The CONNECT and CHANGE messages that establish a hop with a 558 VC must contain a VC-type common SCMP element. This element is valid 559 between neighboring ST2+ agents, but must not propagate beyond the 560 previous-hop or next-hop ST2+ agent. 562 The format of the VC-type common SCMP element is shown in Fig. 3.2. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | PCode = 8 | PBytes = 20 | VCType | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | PVCIdentifer | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | 0(unused) | UniqueID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | OriginIPAddress | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | LIJCallIdentifer | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Fig. 3.2: Format of VC-type common SCMP element. 580 The PCode field identifies the common SCMP elements. The PCode 581 value for the VC type is 8. 583 The PBytes field for the VC type is 20 bytes. 585 The VCType field identifies the VC type. The correspondence 586 between the value in this field and the meaning is as follows: 588 0: ST2+ data stream uses a PVC. 590 1: ST2+ data stream uses the reverse channel of the bi- 591 directional point-to-point SVC used by the existing stream. 593 2: ST2+ data stream is established by a point-to-point SVC 594 initiated from the upstream side. 596 3: ST2+ data stream is established by a point-to-multipoint SVC 597 initiated from the upstream side. 599 4: ST2+ data stream is established by a point-to-point SVC 600 initiated from the downstream side. 602 5: ST2+ data stream is established by a point-to-multipoint SVC 603 initiated from the downstream side. 605 Note: The UNI 3.1 version of the ST2+ over ATM protocol does not 606 support VCType 5. It will be supported by the UNI 3.1/4.0 607 version. 609 The PVCIdentifer field identifies the PVC identifier uniquely 610 assigned between neighboring ST2+ agents. This field is valid only 611 when the VCType field is zero. 613 The UniqueID and OriginIPAddress fields identify the reverse 614 channel of the bi-directional point-to-point SVC that is used by 615 this SID. These fields are valid only when the VCType field is 1. 617 The LIJCallIdentifer field identifies the LIJ Call Identifier for 618 point-to-multipoint SVC. This field is valid only when the VCType 619 field is 5. 621 3.1.4 Reason Code 623 The extension of the Reason Code (RFC 1819, Section 10.5.3) to the 624 ST2+ over ATM protocol is shown below. 626 57 CantChange Partial changes not supported. 627 58 NoRecover Stream recovery not supported. 629 3.2 Restricted Functions of RFC 1819 ST2+ 631 3.2.1 FlowSpec changes 633 In the following case, the ST2+ over ATM protocol supports stream 634 FlowSpec changes by using the CHANGE message. 636 o The I-bit is set to 1 and the G-bit is set to 1. 638 In the following case, the CHANGE fails and a REFUSE message, with 639 the E and N-bits set to 1 and the ReasonCode set to CantChange, is 640 propagated upstream. 642 o The I and/or G-bits are set to zero. 644 3.3 Unsupported Functions of RFC 1819 ST2+ 646 3.3.1 ST2+ FlowSpec 648 The ST2+ over ATM protocol does not support the ST2+ FlowSpec (RFC 649 1819, Section 9.2). The ST2+ FlowSpec specifies useful services, but 650 requires the datalink layer to support heterogeneous QoS to 651 receivers. The current ATM standard does not support heterogeneous 652 QoS to receivers. 654 3.3.2 Stream preemption 656 The ST2+ over ATM protocol does not support stream preemption (RFC 657 1819, Section 6.3). This is because the Integrated Services FlowSpec 658 does not support the concept of precedence. 660 3.3.3 HELLO message 662 Implementations may not support the HELLO message (RFC 1819, Section 663 10.4.7) and thus ST2+ agent failure detection using the HELLO message 664 (RFC 1819, Section 6.1.2). This is because ATM has an adequate 665 failure detection mechanism, and the HELLO message is not sufficient 666 for detecting link failure in the ST2+ over ATM protocol, because the 667 ST2+ data and the ST2+ SCMP are forwarded through another VC. 669 3.3.4 Stream recovery 671 Implementors must select the NoRecover option of the CONNECT message 672 (RFC 1819, Section 4.4.1) with the S-bit set to 1. This is because 673 the descriptions of the stream recovery process in RFC 1819 (Sections 674 5.3.2, 6.2, and 6.2.1) are unclear and incomplete. It is thus 675 possible that if a link failure occurs and several ST2+ agents detect 676 it simultaneously, the recovery process may encounter problems. 678 The ST2+ over ATM protocol does not support stream recovery. If 679 recovery is needed, the application should support it. A CONNECT 680 message in which the NoRecover option is not selected will fail; a 681 REFUSE message in which the N-bit is set to 1 and the ReaseonCode is 682 set to NoRecover is then propagated upstream. 684 3.3.5 Subnet Resources Sharing 686 The ST2+ over ATM protocol does not support subnet resources sharing 687 (RFC 1819, Section 7.1.4). This is because ATM does not support the 688 concept of the MAC layer. 690 3.3.6 IP encapsulation of ST 692 The ST2+ over ATM protocol does not support IP encapsulation of ST 693 (RFC 1819, Section 8.7), because there is no need to implement IP 694 encapsulation in this protocol. 696 3.3.7 IP Multicasting 698 The ST2+ over ATM protocol does not support IP multicasting (RFC 699 1819, Section 8.8), because this protocol does not support IP 700 encapsulation of ST. 702 3.4 Modified Functions of RFC 1819 ST2+ 704 The ST2+ receiver-oriented stream creation procedure has some fatal 705 problems: the value of the LnkReferecnce field in the CONNECT message 706 that is a response to a JOIN message is not valid, ST2+ agent cannot 707 update the LnkReference field in the JOIN-REJECT message, and ST2+ 708 agent cannot deliver the JOIN-REJECT message to the target because 709 the JOIN-REJECT message does not contain a TargetList field. To 710 solve these problems, the ST2+ over ATM protocol modifies the ST2+ 711 protocol processing rules. 713 3.4.1 Modifications of Message Processing Rules 715 Modifications of the CONNECT, JOIN, and JOIN-REJECT message 716 processing rules in the ST2+ over ATM protocol are described in the 717 following. 719 o The target that creates a JOIN message assigns the same value as in 720 the Reference field to the LnkReference field. 722 o The agent that creates a CONNECT message as a response to a JOIN 723 message assigns the same value as in the LnkReference field in the 724 JOIN message to the LnkReference field. In other cases, the value 725 of the LnkReference field in a CONNECT message is zero. 727 o The agent that creates a JOIN-REJECT message assigns the same value 728 as in the LnkReference field in the JOIN message to the 729 LnkReference field. 731 o An intermediate agent must not modify the value of the LnkReference 732 field in the CONNECT, JOIN, or JOIN-REJECT message. Note that this 733 rule differs from the LnkReference field processing rule in the 734 ACCEPT and REFUSE messages. 736 3.4.2 Modified JOIN-REJECT Control Message 738 The modified JOIN-REJECT control message in the ST2+ over ATM 739 protocol is shown in Fig. 3.3 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | OpCode = 9 | 0 | TotalBytes | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Reference | LnkReference | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | SenderIPAddress | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Checksum | ReasonCode | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | GeneratorIPAddress | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 : TargetList : 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Fig. 3.3: JOIN-REJECT Control Message. 758 The TargetList is assigned the same TargetList in the JOIN message as 759 the one that corresponds to the JOIN-REJECT message. 761 4. Protocol Specification of the User Plane 763 This section specifies the AAL5 PDU encapusulation for the ST2+ Data 764 PDU. 766 4.1 Service Primitives Provided by User Plane 768 4.1.1 Overview of interactions 770 The ST2+ data layer entity on the user plane of the ST2+ over ATM 771 protocol provides the following services to the upper layer. 773 o st2p_unitdata.req 775 o st2p_unitdata.ind 777 4.1.1.1 St2p_unitdata.req 779 The st2p_unitdata.req primitive sends a request for an ST2+ Data PDU 780 transfer to the ST2+ data layer entity. The semantics of the 781 primitive are as follows: 783 st2p_unitdata.req ( 784 pri, 785 sid, 786 data 787 ) 789 The pri parameter specifies priority of ST2+ Data PDU. The sid 790 parameter specifies SID of ST2+ Data PDU. The data parameter 791 specifies ST2+ data to be transferred. 793 4.1.1.2 St2p_unitdata.ind 795 The st2p_unitdata.ind primitive indicates an ST2+ Data PDU delivery 796 from the ST2+ data layer entity. The semantics of the primitive are 797 as follows: 799 st2p_unitdata.ind ( 800 pri [optional], 801 sid, 802 data, 803 status [optional] 804 ) 806 The pri parameter indicates priority of ST2+ Data PDU, if AAL5 is 807 used for encapsulating the ST2+ Data PDU. The sid parameter 808 indicates SID of ST2+ Data PDU. The data parameter indicates 809 delivered ST2+ data. The status is an optional parameter that 810 indicates whether the delivered ST2+ data is corrupt or not. 812 4.2 Service Primitives Provided by AAL5 814 4.2.1 Requirements for AAL5 816 The requirements for the AAL5 layer on the ST2+ over ATM user plane 817 are as follows: 819 o The SSCS must be null. 821 o Implementations must use message-mode service. 823 Note: Selection of the corrupted SDU delivery option on the 824 receiver side depends on the implementation, so the receiver may or 825 may not be able to select this option. 827 4.2.2 Overview of Interactions 829 The AAL5 layer entity on the ST2+ over ATM user plane provides the 830 following services to the ST2+ data layer. 832 o AAL5_UNITDATA.req 834 o AAL5_UNITDATA.ind 836 4.2.2.1 AAL5_UNITDATA.req 838 The AAL5_UNITDATA.req primitive sends a request for an AAL5 data 839 (AAL5 CPCS_SDU) transfer from the ST2+ data layer entity to the AAL5 840 layer entity. The semantics of the primitive are as follows: 842 AAL5_UNITDATA.req ( 843 DATA, 844 CPCS_LP, 845 CPCS_UU 846 ) 848 The DATA parameter specifies the AAL5 data to be transferred. The 849 CPCS_LP parameter specifies the value of the CLP field in the ATM 850 cell. The CPCS_UU parameter specifies the user-to-user data to be 851 transferred. 853 4.2.2.2 AAL5_UNITDATA.ind 855 The AAL5_UNITDATA.ind indicates an AAL5 data (AAL5 CPCS_SDU) delivery 856 from the AAL5 layer entity to the ST2+ data layer entity. The 857 semantics of the primitive are as follows: 859 AAL5_UNITDATA.ind ( 860 DATA, 861 CPCS_LP, 862 CPCS_UU, 863 STATUS [optional] 864 ) 866 The DATA parameter indicates the delivered AAL5 data. The CPCS_LP 867 parameter indicates the value of the CLP field in the ATM cell. The 868 CPCS_UU parameter indicates the delivered user-to-user data. The 869 STATUS parameter indicates whether the delivered AAL5 data is corrupt 870 or not. The STATUS parameter is an optional parameter, and valid 871 only when the corrupted SDU delivery option is selected. 873 4.3 AAL5 Encapsulation for ST2+ Data PDU 875 4.3.1 Mapping from st2_unitdata.req to AAL5_UNITDATA.req 877 The ST2+ Data PDU is directly assigned to the DATA parameter in 878 AAL5_UNITDATA.req. That is, as shown in Fig. 4.1, the ST2+ Data PDU 879 is mapped to the payload of AAL5 CPCS_PDU. 881 +-------+---------------------------+ 882 | ST | ST2+ data | ST2+ 883 | header| | Data PDU 884 +-------+---------------------------+ 885 : : 886 : : 887 +---------------------------------------+--------+ 888 | CPCS_PDU |PAD|CPCS_PDU| AAL5 889 | payload | |trailer | CPCS_PDU 890 +---------------------------------------+--------+ 892 Fig. 4.1: Mapping of ST2+ data to AAL5 CPCS_PDU payload. 894 The value of CPCS_LP in AAL5_UNITDATA.req depends on the 895 implementation: 1 (low priority) or zero (high priority) may be 896 assigned permanently, or they may be assigned depending on the value 897 of pri in st2_unitdata.req. 899 The value of the CPCS_UU indication field in AAL5_UNITDATA.req is set 900 to zero. 902 4.3.2 Mapping from AAL5_UNITDATA.ind to st2p_unitdata.ind 904 The DATA parameter in AL5_UNITDATA.ind is directly assigned to the 905 ST2+ Data PDU. That is, the payload in AAL5 CPCS_PDU is mapped to 906 the ST2+ Data PDU. 908 If the value of STATUS in AAL5_UNITDATA.ind is valid, it is assigned 909 to the status in st2p_unitdata.ind. 911 4.3.3 Value of MTU 913 The value of MTU is Maximum CPCS_SDU size. 915 5. Protocol Specification of the Management Plane 917 The management plane specifies the Null FlowSpec, the Controlled-Load 918 Service FlowSpec, and the Guaranteed Service FlowSpec mapping rules 919 for UNI 3.1 traffic management. 921 5.1 Mapping of the Null FlowSpec 923 The Null FlowSpec is mapped to the UBR (VBR with the Best Effort 924 Indicator). 926 The value of the PCR (CLP=0+1) is shown in section 6.7.2. 928 5.2 Mapping of the Controlled-Load Service FlowSpec 930 The Controlled-Load FlowSpec is mapped to the VBR whose PCR 931 (CLP=0+1), SCR (CLP=0+1), and MBS (CLP=0+1) are specified. 933 The value of the PCR (CLP=0+1) is shown in section 6.7.2. 935 Let scr be the calculated value of the SCR (CLP=0+1). Based on the 936 value of the [r] field in the Controlled-Load FlowSpec, it is given 937 by: 938 scr = ([r] / 48) * S, 940 where S is the coefficient of segmentation, and in an implementation, 941 it must be configurable to any value between 1.0 and 56.0. The 942 recommended default value is 1.2. The value of the SCR (CLP=0+1) is 943 a minimum integer equal to or more than the calculated value of the 944 scr. 946 Let mbs be the calculated value of the MBS (CLP=0+1). Based on the 947 value of the [b] field in the Controlled-Load FlowSpec, it is given 948 by: 949 mbs = ([b] / 48) * S. 951 The value of the MBS (CLP=0+1) is a minimum integer equal to or more 952 than the calculated value of the mbs. 954 The values of the [p] and [m] fields in the Controlled-Load FlowSpec 955 are ignored. 957 5.3 Mapping of the Guaranteed Service FlowSpec 959 Note: The UNI 3.1 version of the ST2+ over ATM protocol does not 960 support Guaranteed Services. It will be supported by the UNI 3.1/4.0 961 version. 963 6. Protocol Specification of the Control Plane 965 This section specifies the relationship between ST2+ SCMP and PVC 966 management for ST2+ data, and the protocol interaction between ST2+ 967 SCMP and UNI 3.1 signaling. 969 6.1 AAL5 Encapsulation for ST2+ SCMP PDU 971 This subsection describes AAL5 PDU encapsulation for the ST2+ SCMP 972 PDU. AAL5 encapsulation based on RFC 1483 and on the RFC 1483 973 extension are specified. Selection of which one to use depends on 974 the implementation. 976 The ST2+ over ATM protocol does not cover a VC (SVC/PVC) that 977 transfers ST2+ SCMP. VCs for IPv4 transfer may be used for ST2+ SCMP 978 transfer, and implementations may provide particular VCs for ST2+ 979 SCMP transfer. Selection of these VCs depends on the implementation. 981 6.1.1 RFC 1483 base encapsulation 983 The RFC 1483 base encapsulation is shown in Fig. 6.1: the ST2+ SCMP 984 PDU with the RFC 1483 LLC encapsulation for routed protocol format is 985 mapped to the payload in AAL5 CPCS_PDU. Implementors should note 986 that this is not same as AAL5 encapsulation for the ST2+ Data PDU 987 (the LLC is required). 989 +------+----------------+ 990 | ST | ST2+ SCMP | ST2+ 991 |header| | SCMP PDU 992 +------+----------------+ 993 : : 994 +---+---+---+-----------------------+ 995 |LLC|OUI|PID| Information | IEEE 802 SNAP 996 | | | | | ISO 8802-2 LLC 997 +---+---+---+-----------------------+ 998 : : 999 +---------------------------------------+--------+ 1000 | CPCS_PDU |PAD|CPCS_PDU| AAL5 1001 | payload | |trailer | CPCS_PDU 1002 +---------------------------------------+--------+ 1004 Fig. 6.1: Mapping of ST2+ SCMP PDU to AAL5 CPCS_PDU payload. 1006 The value of the LLC is 0xAA-AA-03, the value of the OUI is 0x00-00- 1007 00, and the value of the PID is 0x08-00. The classification of the 1008 IPv4 and the ST2+ SCMP is determined by the IP version number, which 1009 is located in the first four bits of the IPv4 or ST headers. 1011 6.1.2 RFC 1483 extension base encapsulation 1013 The RFC 1483 extension base encapsulation is the same as for RFC 1483 1014 base encapsulation, except that the value of the OUI is 0x00-00-5E 1015 (IANA) and the value of the PID is 0xXX-XX (TBD). 1017 The RFC 1483 base encapsulation for the SCMP is ideal, but requires 1018 modifying the IPv4 processing in the driver software of the WS or PC. 1019 Therefore, the RFC 1483 base encapsulation may be difficult to 1020 implement. This encapsulation is designed to solve this problem. 1022 6.2 Service Primitives Provided by Control Plane 1024 RFC 1819 ST2+ does not specify SCMP state machines. And the ST2+ 1025 over ATM protocol does not correspond to SCMP state machines. 1026 Therefore, the control plane specification assumes the following. 1028 o The ST2+ agent has ST2+ SCMP layer entities that correspond to the 1029 next hops and the previous hop in the stream. 1031 o The SCMP layer entity terminates ACK, ERROR, and timeout processing 1032 and provides reliable SCMP delivery. 1034 o The origin consists of an upper layer entity, ST2+ SCMP layer 1035 entities for next hops, and a routing machine that delivers SCMP 1036 messages between these entities. 1038 o The intermediate agent consists of ST2+ SCMP layer entities for a 1039 previous hop and for next hops and a routing machine that delivers 1040 SCMP messages between these entities. 1042 o The target consists of an upper layer entity, an ST2+ SCMP layer 1043 entity for a previous hop, and a routing machine that delivers SCMP 1044 messages between these entities. 1046 At least, the ST2+ SCMP layer entity for the next hop provides the 1047 following services to the routing machine. 1049 o connect.req 1050 This primitive sends a request for a CONNECT message transfer to 1051 the ST2+ SCMP layer entity. 1053 o change.req 1054 This primitive sends a request for a CHANGE message transfer to the 1055 ST2+ SCMP layer entity. 1057 o accept.ind 1058 This primitive indicates an ACCEPT message delivery from the ST2+ 1059 SCMP layer entity. 1061 o disconnect.req 1062 This primitive sends a request for a DISCONNECT message transfer to 1063 the ST2+ SCMP layer entity. 1065 o refuse.ind 1066 This primitive indicates a REFUSE message delivery from the ST2+ 1067 SCMP layer entity, or indicates detection of an abnormal status 1068 such as an illegal message or timeout in the ST2+ SCMP layer 1069 entity. 1071 At least, the ST2+ SCMP layer entity for the previous hop provides 1072 the following services to the routing machine. 1074 o connect.ind 1075 This primitive indicates a CONNECT message delivery from the ST2+ 1076 SCMP layer entity. 1078 o change.ind 1079 This primitive indicates a CHANGE message delivery from the ST2+ 1080 SCMP layer entity. 1082 o accept.req 1083 This primitive sends a request for an ACCEPT message transfer to 1084 the ST2+ SCMP layer entity. 1086 o disconnect.ind 1087 This primitive indicates a DISCONNECT message delivery from the 1088 ST2+ SCMP layer entity, or indicates detection of an abnormal 1089 status such as an illegal message or timeout in the ST2+ SCMP layer 1090 entity. 1092 o refuse.req 1093 This primitive sends a request for a REFUSE message transfer to the 1094 ST2+ SCMP layer entity. 1096 6.3 Service Primitives Provided by UNI 3.1 Signaling 1098 The UNI 3.1 signaling layer entity on the ST2+ over ATM control plane 1099 provides the following services to the ST2+ SCMP layer entity. The 1100 ST2+ over ATM protocol does not specify the UNI 3.1 signaling state 1101 machines. These are defined in [10, 12, 13]. 1103 o setup.req 1104 This primitive sends a request for a SETUP message transfer from 1105 the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity. 1106 The ST2+ SCMP layer entity that sent this primitive receives an 1107 acknowledgment. If the setup succeeds the acknowledgment is a 1108 setup.conf primitive and if the setup fails it is a release.ind or 1109 release.conf primitive. 1111 o setup.conf 1112 This primitive indicates a CONNECT message delivery from the UNI 1113 3.1 signaling layer entity to the ST2+ SCMP layer entity. 1115 o setup.ind 1116 This primitive indicates a SETUP message delivery from the UNI 3.1 1117 signaling layer entity to the ST2+ SCMP layer entity. The ST2+ 1118 SCMP layer entity that received this primitive sends an 1119 acknowledgment. If the setup is accepted the acknowledgment is a 1120 setup.resp primitive and if the setup is rejected it is a 1121 release.resp primitive if the state of the UNI 3.1 signaling layer 1122 entity is U6; otherwise it is a release.req primitive. 1124 o setup.resp 1125 This primitive sends a request for a CONNECT message transfer from 1126 the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity. 1127 The ST2+ SCMP layer entity that sent this primitive receives an 1128 acknowledgment. If the setup is completed the acknowledgment is a 1129 setup-complete.ind primitive and if the setup fails it is a 1130 release.ind or release.conf primitive. 1132 o setup-complete.ind 1133 This primitive indicates a CONNECT ACKNOWLEDGE message delivery 1134 from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer 1135 entity. 1137 o release.req 1138 This primitive sends a request for a RELEASE message transfer from 1139 the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity. 1140 The ST2+ SCMP layer entity that sent this primitive receives an 1141 acknowledgment that is a release.conf primitive. 1143 o release.conf 1144 This primitive indicates a RELEASE COMPLETE message delivery, or 1145 indicates a RELEASE message delivery when the status of the UNI 3.1 1146 signaling layer entity is U11, or indicates detection of an 1147 abnormal status such as an illegal message or timeout in the UNI 1148 3.1 signaling layer entity, from the UNI 3.1 signaling layer entity 1149 to the ST2+ SCMP layer entity. 1151 o release.ind 1152 This primitive indicates a RELEASE message delivery from the UNI 1153 3.1 signaling layer entity to the ST2+ SCMP layer entity when the 1154 status of the UNI 3.1 signaling layer entity is other than U11. 1155 The ST2+ SCMP layer entity that received this primitive sends an 1156 acknowledgment that is a release.resp primitive. And this 1157 primitive also indicates detection of an abnormal status such as an 1158 illegal message or timeout in the UNI 3.1 signaling layer entity 1159 and then a REFUSE message is transferred. In this case, the ST2+ 1160 SCMP layer entity that received this primitive receives a 1161 release.conf primitive in succession. 1163 o release.resp 1164 This primitive sends a request for a RELEASE COMPLETE message 1165 transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling 1166 layer entity. 1168 o add-party.req 1169 This primitive sends a request for an ADD PARTY message transfer 1170 from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer 1171 entity. The ST2+ SCMP layer entity that sent this primitive 1172 receives an acknowledgment. If the setup is succeeds the 1173 acknowledgment is an add-party.conf primitive and if the setup 1174 fails it is a drop-party.conf primitive. 1176 o add-party.conf 1177 This primitive indicates an ADD PARTY ACKNOWLEDGE message delivery 1178 from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer 1179 entity. 1181 o drop-party.req 1182 This primitive sends a request for a DROP PARTY message transfer 1183 from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer 1184 entity. The ST2+ SCMP layer entity that sent this primitive 1185 receives an acknowledgment that is a drop-party.conf primitive. 1187 o drop-party.conf 1188 This primitive indicates an ADD PARTY REJECT message delivery, or 1189 indicates a DROP PARTY ACKNOWLEDGE message delivery, or indicates 1190 detection of an abnormal status such as an illegal message or 1191 timeout in the UNI 3.1 signaling layer entity, from the UNI 3.1 1192 signaling layer entity to the ST2+ SCMP layer entity. 1194 o drop-party.ind 1195 This primitive indicates a DROP PARTY message delivery from the UNI 1196 3.1 signaling layer entity to the ST2+ SCMP layer entity. The ST2+ 1197 SCMP layer entity that sent this primitive receives an 1198 acknowledgment that is a drop-party.resp primitive. 1200 o drop-party.resp 1201 This primitive sends a request for a DROP PARTY ACKNOWLEDGE message 1202 transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling 1203 layer entity. 1205 6.4 VC Style Selection Criteria 1207 The ST2+ over ATM protocol supports PVC, the reverse channel of bi- 1208 directional SVC, point-to-point SVC, and point-to-multipoint SVC for 1209 ST2+ Data PDU transfer. And SVC supports both upstream and 1210 downstream call initiation styles. 1212 A 32-bit PVC identifier that is unique between neighboring ST2+ 1213 agents is assigned to each PVC. And the reverse channel of the bi- 1214 directional point-to-point SVC used by the existing stream is 1215 identified by the SID of the stream that occupies the forward 1216 channel. 1218 When the ST2+ agent sets up a stream or changes QoS, the ST2+ agent 1219 must select one VC style from these SVC and PVC styles as a hop that 1220 is part of the stream. In the ST2+ over ATM protocol, VC style 1221 selection criteria depend on the implementation. 1223 This subsection describes examples of VC style selection criteria for 1224 the ST2+ over ATM protocol as a reference for implementors. Note 1225 that the following descriptions in this subsection are not part of 1226 the ST2+ over ATM protocol specification. 1228 6.4.1 Examples of PVC selection criteria 1230 At least, the ST2+ agent may have to manage the following information 1231 for each PVC that can be used by ST2+ Data PDU transfer. 1233 o PVC identifier 1235 o ATM interface identifier in the ST2+ agent 1237 o VPI/VCI 1239 o State of VC: e.g. enabled or disabled, occupied or vacant 1241 o QoS of VC 1243 o Nexthop IP address 1244 When a PVC is selected for a hop of a stream, at least confirmations, 1245 that is the state of the PVC is vacant and the next hop IP address 1246 and QoS are consistent with the requirements from the stream, may be 1247 needed. 1249 It is also feasible to introduce access lists to each PVC and to 1250 consider the access lists in the selection process. Examples of an 1251 access list are shown in the following. 1253 o Permit or deny use by a stream whose the previous hop is specified. 1255 o Permit or deny use by a stream whose the origin is specified. 1257 o Permit or deny use by a stream whose the SID is specified. 1259 o Permit or deny use by a stream whose the target is specified. 1261 o Permit or deny use by a stream whose the target and SAP are 1262 specified. 1264 o Any combination of the above. 1266 6.4.2 Examples of reverse channel of bi-directional SVC selection 1267 criteria 1269 At least, the ST2+ agent may have to manage the following information 1270 for each reverse channel of bi-directional SVCs. 1272 o SID of the stream that occupies the forward channel 1274 o ATM interface identifier in the ST2+ agent 1276 o VPI/VCI 1278 o State of the reverse channel in the VC: e.g. enabled or disabled, 1279 occupied or vacant 1281 o QoS of VC 1283 o Nexthop IP address 1285 When a reverse channel of the bi-directional point-to-point SVC used 1286 by the existing stream is selected for a hop of a stream, at least 1287 confirmations, that is the state of the channel is vacant and the 1288 next hop IP address and QoS are consistent with the requirements from 1289 the stream, may be needed. 1291 It is also feasible to introduce selection rules to the ST2+ agent. 1293 Examples of selection rule are shown in the following. 1295 o Permit reuse of the reverse channel by a stream whose the origin is 1296 one of targets in the stream that occupies the forward channel. 1298 o Permit reuse of the reverse channel by a stream whose one of 1299 targets is the origin in the stream that occupies the forward 1300 channel. 1302 o Permit reuse of the reverse channel by a stream whose the previous 1303 hop is one of the next hops in the stream that occupies the forward 1304 channel. 1306 o Any combination of the avobe. 1308 6.4.3 Examples of SVC selection criteria 1310 When an SVC is used for a hop of a stream, at first, the ST2+ agent 1311 must select point-to-point or point-to-multipoint SVC. Examples of 1312 this selection rule are shown in the following. 1314 o If the network supports only point-to-point SVC, select it. 1316 o If the network supports point-to-multipoint SVC, select it. 1318 If point-to-point SVC is selected, the ST2+ agent must select 1319 upstream or downstream call initiation style. Examples of this 1320 selection rule are shown in the following. 1322 o A VC for a stream whose previous hop is specified is initiated from 1323 upstream or downstream. 1325 o A VC for a stream whose next hop is specified is initiated from 1326 upstream or downstream. 1328 o A VC for a stream whose origin is specified is initiated from 1329 upstream or downstream. 1331 o A VC for a stream whose SID is specified is initiated from upstream 1332 or downstream. 1334 o A VC for a stream whose target is specified is initiated from 1335 upstream or downstream. 1337 o A VC for a stream whose target and SAP are specified is initiated 1338 from upstream or downstream. 1340 o Any combination of the above. 1342 6.5 VC Management 1344 This subsection specifies VC management in the ST2+ over ATM 1345 protocol. 1347 6.5.1 Outgoing call processing of SVC 1349 When outgoing call processing of the first leaf of a point-to- 1350 multipoint SVC or a point-to-point SVC is required inside the ST2+ 1351 SCMP layer entity, a setup.req primitive is sent to the UNI 3.1 1352 signaling layer entity. If the UNI 3.1 signaling layer entity 1353 responds with a setup.conf primitive, the call processing is assumed 1354 to have succeeded. If the UNI 3.1 signaling layer entity responds 1355 with anything other than this primitive, the processing rule is the 1356 same as the SVC disconnect processing that is shown in section 6.5.4 1357 and the outgoing call processing is assumed to have failed. 1359 When outgoing call processing of a later leaf of a point-to- 1360 multipoint SVC is required, an add-party.req primitive is sent to the 1361 UNI 3.1 signaling layer entity. If the UNI 3.1 signaling layer 1362 entity responds with an add-party.conf primitive, the call processing 1363 is assumed to have succeeded. If the UNI 3.1 signaling layer entity 1364 responds with anything other than this primitive, the processing rule 1365 is the same as the SVC disconnect processing that is shown in section 1366 6.5.4 and the outgoing call processing is assumed to have failed. 1368 6.5.2 Incoming call processing of SVC 1370 When an incoming call processing of SVC is required inside the ST2+ 1371 SCMP layer entity, it sets a watchdog timer. The time interval of 1372 the timer depends on the implementation. 1374 The ST2+ SCMP layer entity waits for a setup.ind primitive indication 1375 from the UNI 3.1 signaling layer entity. When this primitive is 1376 indicated and the parameters in it are acceptable, the ST2+ SCMP 1377 layer entity responds with a setup.resp primitive. If the parameters 1378 are not acceptable, the ST2+ SCMP layer entity stops the timer, and 1379 if the state of the UNI 3.1 signaling layer entity is U6, the entity 1380 responds with a release.resp primitive, and if the state is other 1381 than this, the entity responds with a release.req primitive, and then 1382 waits for a release.conf primitive response and the incoming call 1383 processing is assumed to have failed. 1385 If the ST2+ SCMP layer entity responds with a setup.resp primitive, 1386 then the entity waits for the next primitive indication, and when the 1387 next primitive is indicated, the ST2+ SCMP layer entity stops the 1388 timer. If a setup-complete.ind primitive is indicated, the incoming 1389 call processing is assumed to have succeeded. If the UNI 3.1 1390 signaling layer entity responds with anything other than this 1391 primitive or if the timer expires, the processing rule is the same as 1392 the SVC disconnect processing that is shown in section 6.5.4 and the 1393 incoming call processing is assumed to have failed. 1395 6.5.3 VC release processing inside ST2+ SCMP layer 1397 When a VC release is required inside an ST2+ SCMP layer entity, if 1398 the previous hop or next hop is connected with a PVC, the PVC state 1399 is set to vacant and the VC release processing is assumed to be 1400 completed. 1402 If the previous hop or next hop is connected with a point-to-point 1403 SVC whose reverse channel is occupied, the state of the channel in 1404 the VC is set to vacant, the SID information of the VC is updated, 1405 and the VC release processing is assumed to be completed. 1407 If the previous hop or next hop is connected with a point-to-point 1408 SVC whose reverse channel is vacant, if the previous hop is connected 1409 with a point-to-multipoint SVC, or if the next hop is connected with 1410 a point-to-multipoint SVC and the number of leaves is 1, then the 1411 ST2+ SCMP layer entity sends a release.req primitive to the UNI 3.1 1412 signaling layer entity, then waits for a release.conf primitive 1413 indication; when one is indicated, the VC release processing is 1414 assumed to be completed. 1416 If the next hop is connected with a point-to-multipoint SVC and the 1417 number of leaves is other than 1, the ST2+ SCMP layer entity sends a 1418 drop-party.req primitive to the UNI 3.1 signaling layer entity, then 1419 waits for a drop-party.conf primitive indication; when one is 1420 indicated, the VC release processing is assumed to be completed. 1422 6.5.4 VC disconnect processing from UNI 3.1 signaling layer 1424 If an ST2+ SCMP layer entity corresponds to a UNI 3.1 signaling layer 1425 entity, and if the ST2+ SCMP layer entity is sent a release.ind 1426 primitive from the UNI 3.1 signaling layer entity, whose cause is a 1427 delivery of a RELEASE message, the ST2+ SCMP layer entity responds 1428 with a release.resp primitive, and then the VC disconnect processing 1429 is assumed to be completed. If the ST2+ SCMP layer entity is sent a 1430 release.ind primitive, whose cause is other than the previous case, 1431 the ST2+ SCMP layer entity waits for a release.conf primitive 1432 response. When a release.conf primitive is indicated, the VC 1433 disconnect processing is assumed to be completed. 1435 Note that if next hops from ST2+ SCMP layer entities are connected 1436 with a point-to-multipoint SVC, the ST2+ SCMP layer entities to next 1437 hops correspond to a UNI 3.1 signaling layer entity. In this case, 1438 if the ST2+ SCMP layer entities are sent release.ind primitives from 1439 the UNI 3.1 signaling layer entity, whose cause is the delivery of a 1440 RELEASE message, one of the ST2+ SCMP layer entities responds with a 1441 release.resp primitive, and then the VC disconnect processing in the 1442 entities that are sent release.ind primitives are assumed to be 1443 completed. If the ST2+ SCMP layer entities are sent release.ind 1444 primitives, whose cause is other than the previous case, the ST2+ 1445 SCMP layer entities wait for release.conf primitives responses. When 1446 release.conf primitives are indicated, the VC disconnect processing 1447 in the entities that are indicated release.ind primitives are assumed 1448 to be completed. 1450 If the ST2+ SCMP layer entity is sent a drop-party.ind primitive from 1451 the UNI 3.1 signaling layer entity, the ST2+ SCMP layer entity 1452 responds with a drop-party.resp primitive, and then the VC disconnect 1453 processing is assumed to be completed. If the ST2+ SCMP layer entity 1454 is sent a drop-party.conf primitive, the VC disconnect processing is 1455 assumed to be completed. 1457 6.6 Additional SCMP Processing Rules 1459 This subsection specifies the additional SCMP processing rules that 1460 are defined in RFC 1819 ST2+ protocol specification. The following 1461 additional rules are applied when the previous hop or next hop is 1462 connected with an ATM connection in the ST2+ SCMP layer entity. 1464 6.6.1 Additional connect.req processing rules 1466 When a connect.req primitive is sent to the ST2+ SCMP layer entity 1467 for the next hop, the entity confirms whether or not the VC for the 1468 next hop exists. 1470 If it does, the entity forwards a CONNECT message that does not 1471 include a VC-type common SCMP element to the next hop. 1473 If it does not, the entity selects a VC style. If the result is a 1474 PVC or a reverse channel of a bi-directional point-to-point SVC used 1475 by an existing stream, the VC state is set to occupied. The entity 1476 forwards a CONNECT message with a VC-type common SCMP element that 1477 reflects the result of the selection to the next hop. 1479 6.6.2 Additional connect.ind processing rules 1481 The ST2+ SCMP layer entity for the previous hop confirms whether or 1482 not the CONNECT message includes a VC-type common SCMP element. 1484 If a VC-type common SCMP element is not included and the VC for the 1485 next hop exists, a connect.ind primitive is sent to the routing 1486 machine. If the VC for the next hop does not exist, a REFUSE message 1487 is forwarded to the previous hop. 1489 If a VC-type common SCMP element is included and a point-to-point 1490 SVC, whose calling party is the upstream or downstream, or a point- 1491 to-multipoint SVC is specified, a connect.ind primitive is sent to 1492 the routing machine. If a PVC or a reverse channel of a bi- 1493 directional point-to-point SVC used by an existing stream is 1494 specified and the specified VC exists, the VC state is set to 1495 occupied and a connect.ind primitive is sent to the routing machine. 1496 Otherwise, a REFUSE message is forwarded to the previous hop. 1498 6.6.3 Additional change.req processing rules 1500 When a change.req primitive is sent to the ST2+ SCMP layer entity for 1501 the next hop, the entity releases the VC whose process is shown in 1502 section 6.5.3. 1504 Then, the entity selects a VC style. If the result is a PVC or a 1505 reverse channel of a bi-directional point-to-point SVC used by an 1506 existing stream, the VC state is set to occupied. The entity 1507 forwards a CHANGE message with a VC-type common SCMP element that 1508 reflects the result of the selection to the next hop. 1510 6.6.4 Additional change.ind processing rules 1512 The ST2+ SCMP layer entity for the previous hop confirms whether the 1513 CHANGE message includes a VC-type common SCMP element. If a VC-type 1514 common SCMP element is not included, a REFUSE message is forwarded to 1515 the previous hop. 1517 If a VC-type common SCMP element is included, the entity releases the 1518 VC whose process is shown in section 6.5.3. If the element specifies 1519 a point-to-point SVC, whose calling party is the upstream or 1520 downstream, or a point-to-multipoint SVC, a change.ind primitive is 1521 sent to the routing machine. If a PVC or a reverse channel of a bi- 1522 directional point-to-point SVC used by an existing stream is 1523 specified and the specified VC exists, the VC state is set to 1524 occupied and a change.ind primitive is sent to the routing machine. 1525 Otherwise, a REFUSE message is forwarded to the previous hop. 1527 6.6.5 Additional accept.req processing rules 1529 When an accept.req primitive is sent to the ST2+ SCMP layer entity 1530 for the previous hop, the entity confirms the state of the UNI 3.1 1531 signaling layer entity. If the state of the entity is other than U0 1532 or U10, the accept.req primitive is queued and is processed after the 1533 state changes to U0 or U10. 1535 If the state of the entity is U0 or U10, the ST2+ SCMP layer entity 1536 confirms whether or not the VC for the previous hop exists. If it 1537 does, an ACCEPT message is forwarded to the previous hop. 1539 If it does not and the CONNECT or CHANGE message that corresponds to 1540 the accept.req primitive specified a point-to-point SVC whose calling 1541 party is the upstream or a point-to-multipoint SVC, then the entity 1542 processes an incoming call that is shown in section 6.5.2. If the 1543 incoming call processing succeeds, an ACCEPT message is forwarded to 1544 the previous hop. If the CONNECT or CHANGE message that corresponds 1545 to the accept.req primitive specified a point-to-point SVC whose 1546 calling party is downstream, the entity converts from the IP address 1547 of the previous hop to the ATM address, and then the entity processes 1548 an outgoing call that is shown in section 6.5.1. If the outgoing 1549 call processing succeeds, an ACCEPT message is forwarded to the 1550 previous hop. For cases other than those described above or if the 1551 incoming or outgoing call processing fails, a REFUSE message is 1552 forwarded to the previous hop and a disconnect.ind primitive is sent 1553 to the routing machine. 1555 6.6.6 Additional accept.ind processing rules 1557 When an ACCEPT message is processed in the ST2+ SCMP layer entity for 1558 the next hop, the entity confirms the state of the UNI 3.1 signaling 1559 layer entity. If the state of the entity is other than U0 or U10, 1560 the ACCEPT message is queued and is processed after the state changes 1561 to U0 or U10. 1563 If the state of the entity is U0 or U10, the ST2+ SCMP layer entity 1564 confirms whether or not the VC for the next hop exists. If it does, 1565 an accept.ind primitive is sent to the routing machine. 1567 If it does not and the CONNECT or CHANGE message that corresponds to 1568 the ACCEPT message specified a point-to-point SVC whose calling party 1569 is the upstream or a point-to-multipoint SVC, then the entity 1570 converts from the IP address of the next hop to the ATM address, and 1571 then the entity processes an outgoing call that is shown in section 1572 6.5.1. If the outgoing call processing succeeds, an accept.ind 1573 primitive is sent to the routing machine. If the CONNECT or CHANGE 1574 message that corresponds to the ACCEPT message specified a point-to- 1575 point SVC whose calling party is downstream, the entity processes an 1576 incoming call that is shown in section 6.5.2. If the incoming call 1577 processing succeeds, an accept.ind primitive is sent to the routing 1578 machine. For cases other than those described above or if the 1579 incoming or outgoing call processing fails, a refuse.ind primitive is 1580 sent to the routing machine and a DISCONNECT message is forwarded to 1581 the next hop. 1583 6.6.7 Additional disconnect.req processing rules 1585 At first, the ST2+ SCMP layer entity for the next hop forwards a 1586 DISCONNECT message to the next hop. 1588 And then, after the disconnect.req processing, if there are no more 1589 targets that are connected downstream of the entity and the entity is 1590 not waiting for an ACCEPT or REFUSE message response from targets, 1591 the entity releases the VC whose process is shown in section 6.5.3. 1593 6.6.8 Additional disconnect.ind processing rules 1595 AT first, after the disconnect.ind processing, if there are no more 1596 targets that are connected downstream of the ST2+ SCMP layer entity 1597 for the previous hop and the entity is not waiting for an ACCEPT or 1598 REFUSE message response from targets, the entity releases the VC 1599 whose process is shown in section 6.5.3. 1601 And then, the entity sends a disconnect.ind primitive to the routing 1602 machine. 1604 6.6.9 Additional refuse.req processing rules 1606 At first, the ST2+ SCMP layer entity for the previous hop forwards a 1607 REFUSE message to the previous hop. 1609 And then, after the refuse.req processing, if there are no more 1610 targets that are connected downstream of the entity and the entity is 1611 not waiting for an ACCEPT or REFUSE message response from targets, 1612 the entity releases the VC whose process is shown in section 6.5.3. 1614 6.6.10 Additional refuse.ind processing rules 1616 At first, after the refuse.ind processing, if there are no more 1617 targets that are connected downstream of the ST2+ SCMP layer entity 1618 for the next hop and the entity is not waiting for an ACCEPT or 1619 REFUSE message response from targets, the entity releases the VC 1620 whose process is shown in section 6.5.3. 1622 And then, the entity sends a refuse.ind primitive to the routing 1623 machine. 1625 6.6.11 SVC disconnect processing 1627 When the ST2+ SCMP layer entity for the previous hop is sent a SVC 1628 disconnect processing from the UNI 3.1 signaling layer entity and 1629 then the SVC disconnect processing is completed, the entity forwards 1630 a REFUSE message to the previous hop and sends a disconnect.ind 1631 primitive to the routing machine. 1633 When the ST2+ SCMP layer entity for the next hop is sent a SVC 1634 disconnect processing from the UNI 3.1 signaling layer entity and 1635 then the SVC disconnect processing is completed, the entity sends a 1636 refuse.ind primitive to the routing machine and forwards a DISCONNECT 1637 message to the previous hop. 1639 6.7 UNI 3.1 Signaling Information Element Coding Rules 1641 The ST2+ over ATM protocol does not specify the coding rules needed 1642 for the following information elements in UNI 3.1 signaling. The 1643 usages of these information elements are specified in [10]. 1645 o Protocol discriminator 1647 o Call reference 1649 o Message type 1651 o Message length 1653 o Call state 1655 o Called party number 1657 o Called party subaddress 1659 o Calling party number 1661 o Calling party subaddress 1663 o Cause 1665 o Connection identifier 1667 o Broadband repeat indicator 1668 o Restart indicator 1670 o Broadband sending complete 1672 o Transit network selection 1674 o Endpoint reference 1676 o Endpoint state 1678 6.7.1 ATM adaptation layer parameters coding 1680 The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must 1681 include an ATM adaptation layer parameters information element. The 1682 CONNECT message may or may not include this element. The coding 1683 rules for the fields are as follows. 1685 o The AAL Type is set to AAL5. 1687 o The value of the Forward maximum CPCS size field is set to the same 1688 as that of the MaxMsgSize field in the CONNECT SCMP message 1689 corresponding to the SETUP or ADD PARTY message. 1691 o If the VC is established as a point-to-point call, the value of the 1692 Backward maximum CPCS size field is set the same as that of the 1693 Forward maximum CPCS size field. If the VC is established as a 1694 point-to-multipoint call, the value of the Backward maximum CPCS 1695 size field is set to zero. 1697 o The SSCS type is set to null. 1699 6.7.2 ATM traffic descriptor coding 1701 If the Null FlowSpec is specified in the ST2+ over ATM protocol, the 1702 coding rules for the fields in the ATM traffic descriptor information 1703 element in the SETUP message are as follows. 1705 o The value of the Forward PCR (CLP=0+1) field depends on the 1706 specification of the ATM network. The Forward PCR (CLP=0+1) field 1707 in each ATM interface in an implementation must be configurable to 1708 any value between zero and 16,777,215. 1710 o If the VC is established as a point-to-point call, the value of the 1711 Backward PCR (CLP=0+1) field is set the same as that of the Forward 1712 PCR (CLP=0+1) field. If the VC is established as a point-to- 1713 multipoint call, the value of the Backward PCR (CLP=0+1) field is 1714 set to zero. 1716 o The Best effort indication must be present. 1718 If the Controlled-Load Service FlowSpec is specified, the coding 1719 rules for the fields are as follows. 1721 o The value of the Forward PCR (CLP=0+1) field depends on the 1722 specification of the ATM network. The Forward PCR (CLP=0+1) field 1723 in each ATM interface in an implementation must be configurable to 1724 any value between zero and 16,777,215. 1726 o If the VC is established as a point-to-point call, the value of the 1727 Backward PCR (CLP=0+1) field is set the same as that of the Forward 1728 PCR (CLP=0+1) field. If the VC is established as a point-to- 1729 multipoint call, the value of the Backward PCR (CLP=0+1) field is 1730 set to zero. 1732 o The method for calculating the Forward SCR (CLP=0+1) field is shown 1733 in section 5. 1735 o If the VC is established as a point-to-point call, the value of the 1736 Backward SCR (CLP=0+1) field is set the same as that of the Forward 1737 SCR (CLP=0+1) field. If the VC is established as a point-to- 1738 multipoint call, this field must not be present. 1740 o The method for calculating the Forward MBS (CLP=0+1) field is shown 1741 in section 5. 1743 o If the VC is established as a point-to-point call, the value of the 1744 Backward MBS (CLP=0+1) field is set the same as that of the Forward 1745 MBS (CLP=0+1) field. If the VC is established as a point-to- 1746 multipoint call, this field must not be present. 1748 o The Best effort indication, Tagging backward, and Tagging forward 1749 fields must not be present. 1751 6.7.3 Broadband bearer capability coding 1753 If the Null FlowSpec is specified in the ST2+ over ATM protocol, the 1754 coding rules for the fields in the Broadband bearer capability 1755 information element in the SETUP message are as follows. 1757 o The Bearer class depends on the specification of the ATM network. 1758 The Bearer class in each ATM interface in an implementation must be 1759 configurable as either BCOB-X or BCOB-C. BCOB-X is recommended as 1760 the default configuration. 1762 o The Traffic type and Timing requirements fields must not be 1763 present. 1765 o The Susceptibility to clipping field is set to not susceptible to 1766 clipping. 1768 o If the VC is established as a point-to-point call, the User plane 1769 connection configuration field is set to point-to-point, and if the 1770 VC is established as a point-to-multipoint call, it is set to 1771 point-to-multipoint. 1773 If the Controlled-Load Service FlowSpec is specified, the coding 1774 rules for the fields are as follows. 1776 o The Bearer class depends on the specification of the ATM network. 1777 The Bearer class in each ATM interface in an implementation must be 1778 configurable as either BCOB-X or BCOB-C. BCOB-X is recommended as 1779 the default configuration. 1781 o If the Bearer class is BCOB-X, the Traffic type and Timing 1782 requirements fields depend on the specification of the ATM network. 1783 The Traffic type and Timing requirements fields in each ATM 1784 interface in an implementation must be configurable as either no 1785 indication or VBR and Not required, respectively. No indication is 1786 recommended as the default configuration. If the Bearer class is 1787 BCOB-C, the Traffic type and Timing requirements fields must not be 1788 present. 1790 o The Susceptibility to clipping field depends on the specification 1791 of the ATM network. The Susceptibility to clipping field in each 1792 ATM interface in an implementation must be configurable as either 1793 not susceptible to clipping or susceptible to clipping. Not 1794 susceptible to clipping is recommended as the default 1795 configuration. 1797 o If the VC is established as a point-to-point call, the User plane 1798 connection configuration field is set to point-to-point, and if the 1799 VC is established as a point-to-multipoint call, it is set to 1800 point-to-multipoint. 1802 6.7.4 Broadband high layer information coding 1804 The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must 1805 include a Broadband high layer information information element. The 1806 coding rules for the fields are as follows. 1808 o The High layer information type is set to User specific. 1810 o The first 6 bytes in the High layer information field are set to 1811 the SID of the stream corresponding to the VC. 1813 6.7.5 Broadband low layer information coding 1815 The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must 1816 include a Broadband low layer information information element. The 1817 CONNECT message may or may not include this element. The coding 1818 rules for the fields are as follows. 1820 o The User information layer 3 protocol field is set to ISO/IEC TR 1821 9577. 1823 o The IPI field is set to IEEE 802.1 SNAP (0x80). 1825 o The OUI field is set to IANA (0x00-00-5E). 1827 o The PID field is set to ST2+ (TBD). 1829 6.7.6 QoS parameter coding 1831 If the Null FlowSpec is specified in the ST2+ over ATM protocol, the 1832 coding rules for the fields in the QoS parameter in the SETUP message 1833 are as follows. 1835 o The QoS class forward and QoS class backward fields are set to QoS 1836 class 0. 1838 If the Controlled-Load Service FlowSpec is specified, the coding 1839 rules for the fields are as follows. 1841 o The QoS class forward and QoS class backward fields depend on the 1842 specification of the ATM network. The QoS class forward and QoS 1843 class backward fields in each ATM interface in an implementation 1844 must be configurable as either QoS class 0 or QoS class 3. QoS 1845 class 0 is recommended as the default configuration. 1847 7. Security Considerations 1849 The ST2+ over ATM protocol modifies RFC 1819 ST2+ protocol, but 1850 basically these modifications are minimum extensions for ATM support 1851 and bug fixes, so they do not weaken the security of the ST2+ 1852 protocol. 1854 The ST2+ over ATM protocol specifies protocol interaction between 1855 ST2+ and UNI 3.1, and this does not weaken the security of the UNI 1856 3.1 protocol. 1858 In an ST2+ agent that processes an incoming call of SVC, if the 1859 incoming SETUP message contains the calling party number and if it is 1860 verified and passed by the ATM network or it is provided by the 1861 network, then it is feasible to use the calling party number for part 1862 of the calling party authentication to strengthen security. 1864 References 1866 [1] M. Borden, E. Crawley, B. Davie, and S. Batsell, "Integration 1867 of Real-time Services in an IP-ATM Network Architecture," RFC 1868 1821, August 1995. 1870 [2] S. Jackowski, "Native ATM Support for ST2+," RFC 1946, May 1871 1996. 1873 [3] S. Damaskos and A. Gavras, "Connection Oriented Protocols over 1874 ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, February 1875 1994. 1877 [4] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol 1878 Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819, 1879 August 1995. 1881 [5] J. Wroclawski, "Specification of the Controlled-Load Network 1882 Element Service," RFC 2211, September 1997. 1884 [6] S. Shenker, C. Partridge, and R. Guerin, "Specification of 1885 Guaranteed Quality of Service," RFC 2212, September 1997. 1887 [7] J. Wroclawski, "The Use of RSVP with IETF Integrated 1888 Services," RFC 2210, September 1997. 1890 [8] M. Garrett and M. Borden, "Interoperation of Controlled-Load 1891 Service and Guaranteed Service with ATM," Internet Draft, July 1892 1997, . 1894 [9] A. Ghanwani, J. W. Pace, and V. Srinivasan, "A Framework for 1895 Providing Integrated Services Over Shared and Switched LAN 1896 Technologies," Internet Draft, May 1997, . 1899 [10] The ATM Forum, "ATM User-Network Interface Specification 1900 Version 3.1," September 1994. 1902 [11] The ATM Forum, "ATM User-Network Interface (UNI) Signaling 1903 Specification Version 4.0," af-sig-0061.000, July 1996. 1905 [12] ITU-T, "Broadband Integrated Services Digital Network (B- 1906 ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User- 1907 Network Interface (UNI) Layer 3 Specification for Basic 1908 Call/Connection Control," ITU-T Recommendation Q.2931, September 1909 1995. 1911 [13] ITU-T, "Broadband Integrated Services Digital Network (B- 1912 ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User- 1913 Network Interface Layer 3 Specification for Point-to-Multipoint 1914 Call/Connection Control," ITU-T Recommendation Q.2971, October 1915 1995. 1917 [14] ITU-T, "B-ISDN Protocol Reference Model and its Application," 1918 CCITT Recommendation I.321, April 1991. 1920 [15] ITU-T, "B-ISDN ATM Adaptation Layer (AAL) type 5 1921 specification," Draft new ITU-T Recommendation I.363.5, September 1922 1995. 1924 [16] J. Heinanen, "Multiprotocol Encapsulation over ATM 1925 Adaptation Layer 5," RFC 1483, July 1993. 1927 [17] M. Laubach, "Classical IP and ARP over ATM," RFC 1577, 1928 January 1994. 1930 [18] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, and A. 1931 Malis, "ATM Signaling Support for IP over ATM," RFC 1755, February 1932 1995. 1934 [19] J. Luciani, D. Katz, D. Piscitello, and B. Cole, "NBMA Next 1935 Hop Resolution Protocol (NHRP)," Internet Draft, March 1997, 1936 . 1938 Acknowledgments 1940 ATM is a huge technology and without the help of many colleagues 1941 at NTT who are involved in ATM research and development, it would 1942 have been impossible for me to complete this protocol 1943 specification. I would like to thank Hideaki Arai of the NTT 1944 Network Strategy Planning Dept., Shin-ichi Kuribayashi of the NTT 1945 Business Communications Hqs., Naotaka Morita, Jun Aramomi, and 1946 Takumi Ohba of the NTT Network Service Systems Labs., and also 1947 Hisao Uose of the NTT Multimedia Networks Labs. for their valuable 1948 comments and discussions. 1950 And I would also like to especially thank Eric Crawley of 1951 Gigapacket Networks, John Wroclawski of MIT, Steven Jackowski of 1952 Net Manage, Louis Berger of FORE Systems, Steven Willis of Bay 1953 Networks, Greg Burch of Qosnetics, and Denis Gallant, James Watt, 1954 and Joel Halpern of Newbridge Networks for their valuable comments 1955 and suggestions. 1957 Also this specification is based on various discussions during NTT 1958 Multimedia Joint Project with NACSIS. I would like to thank 1959 Professor Shoichiro Asano of the National Center for Science 1960 Information Systems for his invaluable advice in this area. 1962 Author's Address 1964 Muneyoshi Suzuki 1965 NTT Multimedia Networks Laboratories 1966 3-9-11, Midori-cho 1967 Musashino-shi, Tokyo 180, Japan 1969 Phone: +81-422-59-2119 1970 Fax: +81-422-59-3203 1971 EMail: suzuki@nal.ecl.net 1973 Appendix A. RFC 1819 ST2+ Errata 1975 A.1 4.3 SCMP Reliability 1977 The following sentence in the second paragraph: 1979 < For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the 1981 should be changed to 1983 > For some SCMP messages (CONNECT, CHANGE, and JOIN) the 1985 A.2 4.4.4 User Data 1987 The following sentence: 1989 < option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and 1990 < REFUSE messages. The format of the UserData parameter is shown in 1992 should be changed to 1994 > option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, NOTIFY, 1995 > and REFUSE messages. The format of the UserData parameter is shown in 1997 A.3 5.3.2 Other Cases 1999 The following sentence: 2001 < CONNECT with a REFUSE message with the affected targets specified in 2002 < the TargetList and an appropriate ReasonCode (StreamExists). 2004 should be changed to 2006 > CONNECT with a REFUSE message with the affected targets specified in 2007 > the TargetList and an appropriate ReasonCode (TargetExists). 2009 A.4 5.5.1 Mismatched FlowSpecs 2011 The following sentence: 2013 < notifies the processing ST agent which should respond with ReasonCode 2014 < (FlowSpecMismatch). 2016 should be changed to 2018 > notifies the processing ST agent which should respond with a REFUSE 2019 > message with ReasonCode (FlowSpecMismatch). 2021 A.5 6.2.1 Problems in Stream Recovery 2023 The following sentence: 2025 < some time after a failure. As a result, the ST agent attempting the 2026 < recovery may receive ERROR messages for the new CONNECTs that are 2027 < ... 2028 < failure, and will interpret the new CONNECT as resulting from a 2029 < routing failure. It will respond with an ERROR message with the 2030 < appropriate ReasonCode (StreamExists). Since the timeout that the ST 2031 < ... 2032 < remnants of the broken stream will soon be torn down by a DISCONNECT 2033 < message. Therefore, the ST agent that receives the ERROR message with 2034 < ReasonCode (StreamExists) should retransmit the CONNECT message after 2036 should be changed to 2038 > some time after a failure. As a result, the ST agent attempting the 2039 > recovery may receive REFUSE messages for the new CONNECTs that are 2040 > ... 2041 > failure, and will interpret the new CONNECT as resulting from a 2042 > routing failure. It will respond with a REFUSE message with the 2043 > appropriate ReasonCode (TargetExists). Since the timeout that the ST 2044 > ... 2045 > remnants of the broken stream will soon be torn down by a DISCONNECT 2046 > message. Therefore, the ST agent that receives the REFUSE message with 2047 > ReasonCode (TargetExists) should retransmit the CONNECT message after 2049 A.6 6.3 Stream Preemption} 2051 The following sentence: 2053 < (least important) to 256 (most important). This value is 2055 should be changed to 2057 > (least important) to 255 (most important). This value is 2059 A.7 10.2 Control PDUs 2061 The following sentence: 2063 o Reference is a transaction number. Each sender of a request control 2070 > message assigns a Reference number to the message that is unique 2071 > with respect to the stream for messages generated by each agent. 2073 A.8 10.3.4 Origin 2075 The following: 2077 < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 < | PCode = 5 | PBytes | NextPcol |OriginSAPBytes | 2079 < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 should be changed to 2083 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 > | PCode = 4 | PBytes | NextPcol |OriginSAPBytes | 2085 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 A.9 10.4.1 ACCEPT 2089 The following sentence: 2091 o IPHops is the number of IP encapsulated hops traversed by the 2098 > stream. 2100 A.10 10.4.2 ACK 2102 The following: 2104 < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 < | OpCode = 2 | 0 | TotalBytes | 2106 < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 should be changed to 2110 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 > | OpCode = 2 | 0 | TotalBytes = 16 | 2112 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 A.11 10.4.3 CHANGE 2116 The following sentence: 2118 o I (bit 9) is used to indicate that the LRM is permitted to interrupt 2124 A.12 10.4.7 HELLO 2126 The following: 2128 < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 < | OpCode = 7 |R| 0 | TotalBytes | 2130 < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 should be changed to 2134 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 > | OpCode = 7 |R| 0 | TotalBytes = 20 | 2136 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 A.13 10.4.9 JOIN-REJECT 2140 The following sentence: 2142 o Reference contains a number assigned by the ST agent sending the 2148 > JOIN-REJECT for use in the acknowledging ACK. 2150 A.14 10.4.13 STATUS-RESPONSE 2152 The following sentence: 2154 < possibly Groups of the stream. It the full target list can not fit in 2156 should be changed to 2158 > possibly Groups of the stream. If the full target list can not fit in 2160 A.15 10.5.3 ReasonCode 2162 The following: 2164 < 32 PCodeUnknown Control PDU has a parameter with an invalid 2165 < PCode. 2167 should be removed because a common SCMP element with an unknown PCode 2168 is equivalent to the UserData (RFC 1819, Section 10.3.8).