idnits 2.17.1 draft-ietf-sigtran-v5ua-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The Link Status Indication Message is used by L1 FSM in the SG in response to a Link Status Start Reporting Message to indicate the status of the particular link. After a Link Status Start Reporting Message has been received by the L1 FSM, it SHALL automatically send a Link Status Indication Message every time the status of the particular link changes. It SHALL not stop this reporting until it receives a Link Status Stop Report Message from System Management. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: the SCTP Payload Protocol identifier value "6" SHOULD be included in each SCTP DATA chunk to indicate that the SCTP is carrying the V5UA protocol. The value "0" (unspecified) is also allowed but any other values MUST not be used. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a Data chunk. -- 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 (May 2003) is 7642 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) == Unused Reference: '4' is defined on line 953, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 957, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 961, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 976, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3057 (ref. '1') (Obsoleted by RFC 4233) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2223 (ref. '9') (Obsoleted by RFC 7322) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Weilandt 3 INTERNET DRAFT N. Khanchandani 4 S. Rao 5 Nortel Networks 7 Expires in six months May 2003 9 V5.2-User Adaptation Layer (V5UA) 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet- Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document defines a mechanism for backhauling of V5.2 messages 35 over IP using the Stream Control Transmission Protocol (SCTP). This 36 protocol may be used between a Signaling Gateway (SG) and a Media 37 Gateway controller (MGC). It is assumed that the SG receives V5.2 sig- 38 naling over a standard V5.2 interface. 40 This document builds on top of the ISDN User Adaptation Layer Protocol 41 (RFC 3057). It defines all necessary extensions to the IUA Protocol 42 needed for the V5UA protocol implementation. 44 Table of Contents 46 1. Introduction ................................................. 3 47 1.1. Scope .................................................... 3 48 1.2. Terminology .............................................. 3 49 1.3. V5.2 Overview ............................................ 5 50 1.4. Distribution of responsibilities between MGC and SG ...... 7 51 1.5. Client/Server Model ...................................... 7 52 1.6. Addition to boundary primitives .......................... 7 53 1.6.1. V5 specific boundary primitives ...................... 7 54 2. Conventions .................................................. 9 55 3. SCTP Stream Management ....................................... 9 56 4. Proposed V5.2 Backhaul Architecture .......................... 10 57 4.1. V5UA Message Header ...................................... 10 58 4.2. V5 Naming Conventions for Interface Identifier ........... 11 59 4.3. V5 Additions to IUA Boundary Primitives .................. 12 60 4.4. Link Status Messages ..................................... 13 61 4.5. Sa-Bit Messages .......................................... 15 62 4.6. Error Indication Message ................................. 16 63 5. Procedures ................................................... 17 64 5.1. V5 Layer 1 failure ....................................... 17 65 5.2. Loss of V5UA peer ........................................ 18 66 5.3. C-channel overload on SG ................................. 18 67 6. Examples ..................................................... 18 68 6.1. Link Identification Procedure (successful) ............... 18 69 7. Security Considerations ...................................... 20 70 8. IANA Considerations .......................................... 20 71 8.1. SCTP Payload Protocol Identifier ......................... 20 72 8.2. V5UA Port Number ......................................... 20 73 9. Acknowledgements ............................................. 20 74 10. References .................................................. 20 75 10.1. Normative References .................................... 20 76 10.2. Informative References .................................. 21 77 11. Author's Addresses .......................................... 21 78 1. Introduction 80 This document describes a method of implementing V5.2 backhaul messag- 81 ing over IP using a modified version of the ISDN User Adaptation Layer 82 Protocol (IUAP) [1]. V5UA builds on top of IUA, defining the necessary 83 extensions to IUA for a V5.2 implementation. 85 Since V5UA is meant to be an extension to IUAP, everything defined in 86 [1] is also valid for V5UA unless specified otherwise in this docu- 87 ment. 89 This document does not describe the V5 standard itself. The V5 proto- 90 col is defined by ETSI standards [2,3]. Any description of the V5 pro- 91 tocol in this document is meant to make the text easier to understand. 93 1.1. Scope 95 There is a need for Switched Circuit Network (SCN) signaling protocol 96 delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway Con- 97 troller (MGC), analogous to the implementation of the ISDN Q.921 User 98 Adaptation Layer (IUA) as described in [1]. 100 This draft supports analog telephone access, ISDN basic rate access 101 and ISDN Primary rate access over a V5.2 interface. 103 Since the V5.2 Layer 2, and especially Layer 3, differs from the Q.921 104 and Q.931 Adaptation layer, the IUA standard must be extended to ful- 105 fil the needs for supporting V5.2. 107 1.2. Terminology 109 Bearer Channel Connection (BCC) protocol - A protocol which allows the 110 Local Exchange (LE) to instruct the Access Network (AN) to allo- 111 cate bearer channels, either singly or in multiples, on demand. 113 Communication channel (C-channel) - A 64 kbit/s time slot on a V5.2 114 interface provisioned to carry communication paths. 116 Communication path (C-path) - Any one of the following information 117 types: 119 - The layer 2 data link carrying the Control protocol 121 - The layer 2 data link carrying the Link Control protocol 123 - The layer 2 data link carrying the PSTN signaling 125 - Each of the layer 2 data links carrying the protection protocol 127 - The layer 2 data link carrying the BCC protocol 128 - All the ISDN Ds-type data from one or more user ports 130 - All the ISDN p-type data from one or more user ports 132 - All the ISDN t-type data from one or more user ports 134 Note: This definition includes the possibility that there may be 135 more than one C-path of the same information type, each allocated 136 to a different logical C-channel. 138 Envelope Function Address (EFA) - 13 bit number, ranging from 0 to 139 8191 (decimal). An EFA uniquely identifies one of the five V5.2 140 protocols, or an ISDN agent attached to an AN. The following list 141 contains the possible values for the EFA: 143 Definition Value 144 ---------- ------ 145 ISDN_PROTOCOL 0 - 8175 146 PSTN_PROTOCOL 8176 147 CONTROL_PROTOCOL 8177 148 BCC_PROTOCOL 8178 149 PROT_PROTOCOL 8179 150 LINK_CONTROL_PROTOCOL 8180 151 RESERVED 8181 - 8191 153 Layer 1 Functional State Machine (L1 FSM) - Functional State Machine 154 in V5 System Management that tracks and controls the states of 155 the physical E1 links on the interface. 157 Logical Communication channel (Logical C-channel) - A group of one or 158 more C-paths, all of different types, but excluding the C-path 159 for the protection protocol. 161 Multi-link - A collection of more than one 2048 kbit/s link which 162 together make up a V5.2 interface. 164 Multi-Slot - A group of more than one 64kbit/s channels providing 8Khz 165 and time slot sequence integrity, generally used together within 166 an ISDN Primary Rate Access (ISDN-PRA) user port, in order to 167 supply a higher bit-rate service. 169 Physical Communication Channel (Physical C-channel) - A 64kbit/s time 170 slot on a V5.2 interface which has been assigned for carrying 171 logical C-channels. A physical C-channel may not be used for car- 172 rying bearer channels. 174 Primary Link - A 2048 kbit/s (E1) link in a multi-link V5.2 interface 175 whose physical C-channel in time slot 16 carries a C-path for the 176 protection protocol and, on V5.2 initialization, also the C-path 177 for the control protocol, link control protocol, and the BCC pro- 178 tocol. Other C-paths may also be carried in the time slot 16. 180 Secondary Link - A 2048 kbit/s (E1) link in a multi-link V5.2 inter- 181 face whose time slot 16 carries a C-path for the protection pro- 182 tocol, and, on V5.2 initialization, acts as the standby C-channel 183 for the control protocol, link control protocol, and BCC protocol 184 and any other C-paths initially carried in time slot 16 of the 185 primary link. 187 V5 Link - A 2048 kbits/s E1 (PCM30) link used on a V5 interface. A V5 188 interface may use up to 16 V5 links. 190 1.3. V5.2 Overview 192 V5.2 is an industry standard ETSI interface (reference ETS 300 347-1 193 [3]) defined between a Local Exchange (LE) and an Access Network (AN) 194 providing access to the following types: 196 - Analog telephone access 198 - ISDN Basic rate access 200 - ISDN Primary Rate access 202 - Other analog or digital accesses for semi-permanent connections 203 without associated outband signaling information 205 The original V5 specification (V5.1 [2]) uses 2048 kbps links in 206 a non-concentrating fashion. In contrast V5.2 may use up to 16 207 such interface links and supports concentration. 209 ---------- ---------- o--o 210 | | E1 | |------- / 211 | |--------------| | -- 212 | LE | E1 | AN | 213 | |--------------| | o--o 214 | | | |------- / 215 ---------- ---------- -- 217 The LE and AN are connected with up to 16 E1 (PCM30) links. Channels 218 16, 15 and 31 on any E1 link can be reserved for data communication 219 between LE and AN. The channels reserved for data are called 220 "Communication Channels" or "C-channels." 222 The C-channels are the physical media that exchange data between the 223 V5.2 protocol peer entities, as well as to transfer the ISDN BRI D- 224 channel messages between the terminals and the LE. A logical communi- 225 cation path between two peer entities for one protocol is called a 226 "C-path". 228 The signaling information in V5.2 are defined as: 230 - Analog signals are carried by means of the V5 PSTN protocol 231 (L3) 233 - ISDN/analog ports are controlled by the V5 Control protocol 234 (L3) 236 - ISDN protocol messages are mapped to LAPD frames, which are 237 carried by means of LAPV5-EF sublayer (L2) 239 - V5 protocol messages are mapped to LAPV5-DL frames, which are 240 carried by means of LAPV5-EF sublayer (L2) 242 In order to support more traffic and dynamic allocation of bearer 243 channels, the V5.2 protocol has several additions: 245 - A bearer channel connection protocol establishes and disestab- 246 lishes bearer connections on demand, as determined by the sig- 247 naling information, under the control of the Local Exchange. 249 - A link control protocol is defined for multi-link management to 250 control link identification, link blocking and link failure 251 conditions. 253 - A protection protocol, operating on two separate V5 data links 254 is defined to manage the protection switching of communication 255 channels in case of link failures. 257 The following protocols are defined for the various protocol layers: 259 Layer 2: 260 - LAPV5-EF 261 - LAPV5-DL 263 Layer 3: 264 - V5-Link Control 265 - V5-BCC 266 - V5-PSTN 267 - V5-Control 268 - V5-Protection 270 1.4. Distribution of responsibilities between MGC and SG 272 In the V5UA backhaul architectrue, the V5 protocol entities SHALL be 273 distributed over SG and MGC as shown below. 275 MGC SG 276 +------------+ +-------+-------+ 277 | Lnk Cntrl | | | | 278 +------------+ | | | 279 | Cntrl | | | | 280 +------------+ V5UA | | | V5 +------+ 281 | BCC | <--------> | LAPV5 | LAPV5 | <----> | AN | 282 +------------+ | -DL | -EF | +------+ 283 | PSTN | | | | 284 +------------+ | | | 285 | Protection | | | | 286 +------------+ +-------+-------+ 288 V5 System Management SHALL be located on the MGC. The V5 L1 Functional 289 State Machine (FSM) SHALL be located on the SG. 291 Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the 292 MGC. 294 1.5. Client/Server Model 296 The Client/Server Model for V5UA shall follow the model as defined for 297 IUAP. 299 The SCTP (and UDP/TCP) registered User Port Number Assignment for V5UA 300 is 5675. 302 1.6. Addition to boundary primitives 304 1.6.1. V5 specific boundary primitives 306 Extending IUAP to V5UA to support V5.2 backhaul requires the introduc- 307 tion of new boundary primitives for the Q.921/Q.931 boundary, in 308 accordance with the definitions in the V5 standards. 310 V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the 311 DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA primi- 312 tive is used for transport of both V5 Layer 3 messages and V5 ISDN 313 Layer 3 messages. The DL-UNIT DATA primitive is only used for V5 ISDN 314 messages and is used and defined as described for IUAP. 316 In the V5 standards, V5 system management is responsible for 317 establishing and releasing data links. Therefore, for V5UA the DL- 318 Establish and DL-Release primitives defined in IUAP are replaced by 319 new primitives between system management and the data link layer in 320 accordance with the definitions in [2]: 322 MDL-ESTABLISH 324 The MDL-Establish primitives are used to request, indicate and confirm 325 the outcome of the procedures for establishing multiple frame opera- 326 tion. 328 MDL-RELEASE 330 The MDL-Release primitive is used to indicate the outcome of the pro- 331 cedures for terminating multiple frame operation. 333 In contrast to ISDN, the V5 standards demand that V5.2 system manage- 334 ment interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (includ- 335 ing the L1 FSM) and parts of V5 system management are physically 336 separated in a V5 backhaul scenario, V5UA must support some services 337 for the communication between these two entities. Specifically, these 338 services include an indication of the status of a specific link, and 339 messages to support the link identification procedure defined by the 340 V5 standards. 342 The new primitive are defined as shown below: 344 MPH-LINK STATUS START REPORTING 346 The MPH-LINK STATUS START REPORTING primitive is used by V5 system 347 management to request that a link be brought into service for use in a 348 V5 interface. On reception of this message, the L1 FSM on the SG SHALL 349 start reporting the status of the V5 link to the MGC. This primitive 350 is used similar to the MPH-proceed primitive defined by V5.2, but it 351 has a more extended meaning than MPH-proceed. 353 MPH-LINK STATUS STOP REPORTING 355 The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system 356 management to request that a link is taken out of service on a V5 357 interface. On reception of this message L1 FSM on the SG SHALL stop 358 reporting the status of the V5 link to the GWC. This primitive is 359 used similar to the MPH-stop primitive defined by V5.2, but it has a 360 more extended meaning than MPH-stop. 362 MPH-LINK STATUS INDICATION 364 The MPH-LINK STATUS INDICATION primitive is used by L1 FSM on the Sig- 365 naling Gateway to report the status (operational/non-operational) of a 366 V5 link to V5 system management. This primitive is equivalent to the 367 MPH-AI and MPH-DI primitives in V5.2. 369 MPH-SA-BIT SET 371 The MPH-SA-BIT SET primitive is used by system management to request 372 that the L1 FSM in the SG sets or resets the value of a specified Sa 373 bit on the requested link. The SG uses it to report the successful 374 setting or resetting of this bit back to system management. For V5 375 this message is used for the V5 specific Link Identification procedure 376 to set/reset the value of the Sa7 bit, or to confirm the successful 377 setting of the Sa bit. The MPH-SA BIT SET REQUEST is equivalent to 378 the MPH-ID and MPH-NOR primitves in V5.2. 380 MPH-SA-BIT STATUS 382 The MPH-SA-BIT STATUS primitives are used by system management in the 383 MGC to request that the L1 FSM in the SG reports the status of a 384 specified Sa bit on the requested link. The SG uses it to report 385 (indicate) the status of this bit back to system management. For V5 386 these messages are used for the V5 specific Link identification pro- 387 cedure to request or report the status of the Sa7 bit. This is 388 equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2. 390 Due to the separation of V5 System Management and V5 Layer1/Layer2 in 391 the V5UA backhaul architecture, it may be necessary to report error 392 conditions of the SG's V5 stack to V5 System Management. For this 393 purpose, a new primitive is defined: 395 MDL-ERROR INDICATION 397 The MDL-ERROR INDICATION primitive is used to indicate an error condi- 398 tion to V5 System Management. The only valid reason for this primi- 399 tive is 'Overload', indicating an overload condition of the C-channel 400 on the SG. This reason is not defined in the V5/Q.921 standards. 402 2. Conventions 404 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 405 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they 406 appear in this document, are to be interpreted as describd in [8]. 408 3. SCTP Stream Management 410 A single SCTP stream SHOULD be used for grouping all of the following 411 protocols together: BCC, Link Control, Control and PSTN protocol on a 412 specific C-channel. A separate SCTP stream SHOULD be used for the 413 Protection protocol on a specific C-channel. One SCTP stream SHOULD be 414 used for all ISDN user ports on a specific C-channel. One single 415 stream SHOULD NOT be used to carry data of more than one C-channel. 417 In addition, one separate SCTP stream SHOULD be used for all MPH (link 418 related) messages. 420 4. Proposed V5.2 Backhaul Architecture 422 ****** V5.2 ****** IP ******* 423 * AN *---------------* SG *--------------* MGC * 424 ****** ****** ******* 426 +-----+ +-----+ 427 |V5.2 | (NIF) |V5.2 | 428 +-----+ +----------+ +-----+ 429 | | | |V5UA| |V5UA | 430 | | | +----+ +-----+ 431 |LAPV5| |LAPV5|SCTP| |SCTP | 432 | | | +----+ +-----+ 433 | | | | IP + | IP | 434 +-----+ +-----+----+ +-----+ 436 Figure 1 V5.2 Backhaul Architecture 438 AN - Access Network 439 NIF - Nodal Interworking Function 440 SCTP - Stream Control Transmission Protocol 442 4.1. V5UA Message Header 443 The original IUA message header must be modified for V5UA. The origi- 444 nal header for the integer formatted Interface Identifier is shown 445 below: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Tag (0x1) | Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Interface Identifier (integer) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Tag (0x5) | Length=8 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | DLCI | Spare | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 2 Original IUA Message Header 461 V5UA extends the IUA Message Header by including the Envelope Function 462 Address (EFA) in the Spare field. The V5UA format for the integer for- 463 matted Interface Identifier is shown below: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Tag (0x1) | Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Interface Identifier (integer) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Tag (0x5) | Length=8 | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | DLCI | EFA | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Figure 3 V5UA Message Header (Integer-based Interface identifier) 479 The EFA is defined by the V5 standard. It identifies a C-path, which 480 is a 13-bit number, ranging from 0 to 8191 (decimal). An EFA uniquely 481 identifies one of the five V5.2 protocols, or an ISDN agent attached 482 to an AN. The following list contains the possible values for the EFA 483 as defined by V5: 485 Definition Value 486 ---------- ------ 487 ISDN_PROTOCOL 0 - 8175 488 PSTN_PROTOCOL 8176 489 CONTROL_PROTOCOL 8177 490 BCC_PROTOCOL 8178 491 PROT_PROTOCOL 8179 492 LINK_CONTROL_PROTOCOL 8180 493 RESERVED 8181 - 8191 495 For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA 496 SHALL be set to ZERO and SHALL be ignored by the receiver. For all 497 other messages the DLCI SHALL be set as defined in the V5.2 standard 498 [2]. 500 The Interface Identifier SHALL follow the naming conventions for the 501 Interface Identifier as defined below. 503 4.2. V5 Naming Conventions for Interface Identifier 505 The V5 standard demands that V5 System Management keeps track of the 506 states of all links on a V5 interface. To perform tasks like protec- 507 tion switching and bearer channel allocation on the V5 links, it is 508 neccessary that system management has the full picture of the signal- 509 ing and bearer channels located on each link. 511 The IUA protocol identifies C-channels by endpoints without a defined 512 association with a specific link. Since no naming convention exists, 513 there is no guarantee that a C-channel is actually located at the link 514 it claims to be. Furthermore the V5 standard requires that the MGC 515 receives reports of the status of all links, and it defines a link 516 identification procedure to ensure that AN and LE are referencing the 517 same link when they address a link with a Link Control Protocol mes- 518 sage. 520 It would clearly be against the concept of V5.2 if there was no clear 521 association between E1 links and channels. To solve this problem a 522 naming convention MUST be used for V5UA. 524 The format of the integer formatted Interface Identifier is shown 525 below: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Link Identifier | Chnl ID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Link Identifier - Identifier for an E1 link on the SG (27 bits). MUST 534 be unique on the SG. This Link Identifier MUST match the Link 535 Identifier used in the Link Management Messages defined later in 536 this document. 538 Chnl ID - Channel Identifier (5 bits). This is equal to the time-slot 539 number of the addressed time slot. Possible values are 15, 16 and 540 31 representing the possible time slots for C-channels on a V5 541 interface. For Link Management Messages the Chnl ID MUST be set 542 to 0. All other values are reserved for future use. 544 If used, the text formatted interface identifier SHALL be coded as the 545 hex representation of the integer formatted interface identifier, 546 written as a variable length string. 548 4.3. V5 Additions to IUA Boundary Primitives 550 Some primitives for the V5 interface boundaries are similar to the 551 Q.921/Q.931 boundary primitive messages defined in IUA, but they need 552 to be handled in a different way. Therefore it is neccessary to dis- 553 tinguish between these two message types by means of the Message Class 554 parameter. 556 For all V5 interface boundary primitives, a new Message Class is 557 introduced: 559 9 V5 Boundary Primitives Transport 560 Messages (V5PTM) 562 Other valid message classes for V5UA, which are also used by IUA, are: 564 0 Management (MGMT) Message 565 3 ASP State Maintenance (ASPSM) Messages 566 4 ASP Traffic Maintenance (ASPTM) Messages 568 Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM mes- 569 sages are: 571 1 Data Request Message (MGC -> SG) 572 2 Data Indication Message (SG -> MGC) 573 3 Unit Data Request Message (MGC -> SG) 574 4 Unit Data Indication Message (SG -> MGC) 575 5 Establish Request (MGC -> SG) 576 6 Establish Confirm (SG -> MGC) 577 7 Establish Indication (SG -> MGC) 578 8 Release Request (MGC -> SG) 579 9 Release Confirm (SG -> MGC) 580 10 Release Indication (SG -> MGC) 582 All these messages are defined similarly to the QPTM messages. 584 In addition, new boundary primitive messages are defined: 586 11 Link Status Start Reporting (MGC -> SG) 587 12 Link Status Stop Reporting (MGC -> SG) 588 13 Link Status Indication (SG -> MGC) 589 14 Sa-Bit Set Request (MGC -> SG) 590 15 Sa-Bit Set Confirm (SG -> MGC) 591 16 Sa-Bit Status Request (MGC -> SG) 592 17 Sa-Bit Status Indication (SG -> MGC) 593 18 Error Indication (SG -> MGC) 595 4.4. Link Status Messages (Start Reporting, Stop Reporting, Indica- 596 tion) 598 The Link Status Messages are used between V5 System Management on the 599 MGC and the L1 FSM on the SG to track the status of a particular E1 600 link. This is required whether or not the E1 link carries C-channels. 602 All Link Status Messages contain the V5UA Message Header. The Link 603 Identifier portion of the Interface Identifier identifies the physical 604 link on the SG addressed by the message. For all link status messages, 605 the Chnl ID SHALL be set to '0' and SHALL be ignored by the receiver. 607 The integer value used for the Link Identifier is of local signifi- 608 cance only, and is coordinated between the SG and MGC. It MUST be 609 unique for every V5 link on the SG. 611 As defined by the V5 standards, V5 System Management must know the 612 status of the links on all active V5 interfaces. The Link Status 613 Start Reporting Message is used by V5 System Management on the MGC to 614 request that the L1 FSM on the SG starts reporting the status of a 615 particular link. 617 V5 system management SHALL send this Message on interface activation 618 for all links on the interface. The SG SHALL respond immediately to 619 this request with a Link Status Indication message, and it SHALL then 620 send a Link Status Indication message on all subsequent changes of the 621 link status. Since the SG has no other way to determine whether a link 622 is on an active interface or not, this message SHALL always be sent on 623 interface startup. 625 If the L1 FSM in the SG receives a Link Status Start Reporting Message 626 for a link that is already active (the link status is reported to Sys- 627 tem Management), the SG SHALL immediately report the actual status of 628 this link by sending a Link Status Indication Message. The SG SHALL 629 then proceed with the automatic link status reporting as described 630 above. 632 To stop this reporting of the status of a link, e.g. at interface 633 deactivation, System Management sends a Link Status Stop Reporting 634 Message to the L1 FSM. The SG will then immediately stop reporting the 635 status of the particular link and will assume the link to be out of 636 service. It MUST NOT respond in any way to this message. 638 Since there is no other way for the SG to know that an interface is 639 deactivated, this message SHALL be sent on interface deactivation for 640 all links on the interface. On reception of this message, the SG SHALL 641 take L2 down on this link. 643 If the L1 FSM in the SG receives a Link Status Stop Reporting Message 644 for a link that is not active (the link status is not reported to Sys- 645 tem Management), the SG SHALL ignore the message. 647 The Link Status Start/Stop Reporting Messages contain the common mes- 648 sage header followed by the V5UA message header. They do not contain 649 any additional parameters. 651 The Link Status Indication Message is used by L1 FSM in the SG in 652 response to a Link Status Start Reporting Message to indicate the 653 status of the particular link. After a Link Status Start Reporting 654 Message has been received by the L1 FSM, it SHALL automatically send a 655 Link Status Indication Message every time the status of the particular 656 link changes. It SHALL not stop this reporting until it receives a 657 Link Status Stop Report Message from System Management. 659 The Link Status Indication Message contains the common message header 660 followed by the V5UA message header. In addition it contains the fol- 661 lowing link status parameter: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Tag (0x11) | Length | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Link Status | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 The valid values for Link Status are shown in the following table: 673 Define Value Description 675 OPERATIONAL 0x0 Link operational 676 NON-OPERATIONAL 0x1 Link not operational 678 4.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request, 679 Status Indication) 681 The Sa-Bit Messages are used between V5 System Management in the MGC 682 and the L1 FSM in the SG to set and read the status of Sa bits on the 683 E1 links. For V5 it is only required to set and read the status of the 684 Sa7 bit that is used for the Link Identification procedure as 685 described by the V5 standards [3]. 687 All Sa-Bit Messages SHALL contain the V5UA message header. The Link 688 Identifier portion of the Interface Identifier identifies the physical 689 link on the SG addressed by the message. For all link status messages, 690 the Chnl ID SHALL be set to '0' and SHALL be ignored by the receiver. 692 The Link Identifier MUST be the same as used in the Interface Identif- 693 ier to identify on which link a C-channel is located. 695 The Sa-Bit Set Request message is used to set the value of the speci- 696 fied Sa-Bit on the defined link. The value of the Sa7 bit in normal 697 operation is ONE. For the Link Identification procedure, it is set to 698 ZERO. 700 The Sa-Bit Set Request message for the Sa7 bit with Bit Value ZERO 701 corresponds to the V5 defined primitive MPH-ID. The Sa-Bit Set Request 702 message for the Sa7 bit with Bit Value ONE corresponds to the V5 703 defined primitive MPH-NOR. 705 The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set Con- 706 firm message when the setting of the bit is complete. This message 707 does not correspond to a V5 defined primitive. 709 The Sa-Bit Status Request message is used by system management to 710 request the status of the specified Sa-Bit on the defined link from L1 711 FSM. The Sa-Bit Status Request message for the Sa7 bit corresponds to 712 the V5 defined primitive MPH-IDR. 714 L1 FSM answers the Sa-Bit Status request message by a Sa-Bit Status 715 Indication message in which the current setting of the bit will be 716 reported. The Sa-Bit Status Indication message for the Sa7 bit with 717 Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. The 718 Sa-Bit Status Indication message for the Sa7 bit with Bit Value ONE 719 corresponds to the V5 defined primitive MPH-Elg. 721 All Sa-Bit Messages contain the following additional parameter: 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Tag (0x12) | Length | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | BIT ID | Bit Value | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 The valid values for Bit Value are shown in the following table: 733 Define Value Description 735 ZERO 0x0 Bit value ZERO 736 ONE 0x1 Bit value ONE 738 The valid value for BIT ID is shown in the following table: 740 Define Value Description 742 Sa7 0x7 Addresses the Sa7 bit 744 There are no other valid values for V5UA. All other values are 745 reserved for future use. 747 For the Sa-Bit Status Request and Set Confirm messages, the BIT Value 748 SHALL be set to '0' by the sender and SHALL be ignored by the 749 receiver. 751 4.6. Error Indication Message 753 The Error Indication Message is used between the V5 stack on the SG 754 and the V5 System Management in the MGC to indicate an error condition 755 at the SG. 757 The only valid reason for the Error Indication Message is Overload. 758 The SG SHOULD issue such an Error Indication with reason Overload for 759 a C-channel if it is not able to process all Layer 3 messages on this 760 C-channel in a timely manner (overload condition of the C-channel). 762 The Error Indication message SHALL contain the V5UA message header. 764 The Interface Identifier indicates the affected C-channel. SAPI, TEI 765 and EFA SHALL be set to '0' and SHALL be ignored by the receiver. 767 The Error Indication message contains the following additional parame- 768 ter: 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Tag (0x13) | Length | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Error Reason | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 The valid values for Error Reason are shown in the following table: 780 Define Value Description 782 OVERLOAD 0x1 C-channel is in overload state 784 There are no other valid values for V5UA. All other values are 785 reserved for future use. 787 5. Procedures 789 5.1. V5 Layer 1 failure 791 The normal way to handle a V5 Layer 1 failure is described in the V5 792 standards[2,3] as follows: 794 - The L1 FSM detects the V5 Layer 1 failure. It reports this to 795 V5 System management by sending a MPH-DI primitive for the 796 affected link. 798 - V5 System management notifies V5 Layer 2 of the V5 Layer 1 799 outage by sending a MPH-Layer_1 Failure Ind primitive. 801 Since V5 Layer1/2 and V5 System Management are no longer co-located in 802 the backhaul architecture, it does not make sense to notify V5 Layer 2 803 about V5 Layer 1 failure via V5 system management. Instead V5 Layer 2 804 SHALL be notified directly by V5 Layer 1 on the SG. V5 Layer 1 SHALL 805 report the outage to V5 system management by sending a Link Status 806 Indication message with status NON-OPERATIONAL, corresponding to an 807 MPH-DI primitive as defined by the V5.2 standard. V5 system management 808 SHALL NOT send an MPH-Layer_1 Failure Ind primitive to V5 Layer 2 in 809 response to this message. 811 5.2. Loss of V5UA peer 813 If SCTP failure is detected or the heartbeat is lost, the following 814 procedure SHALL be performed: 816 When loss of V5UA peer is reported to the V5UA layer, the ASP SHALL 817 behave as if it had received a Link Status Indication (non- 818 operational) for all links on this SG. 820 The ASP SHALL attempt to reestablish the connection continuously. When 821 the connection is reestablished, the ASP SHALL send a Link Status 822 Start Reporting message to the SG for all links on active V5 inter- 823 faces on the SG. 825 An example for the message flow for reestablishment of the connection 826 is shown below for one active link on the SG: 828 ASP SG 830 | | 831 | -------- Link Status Start Reporting ---------> | 832 | | 833 | <------ Link Status Ind (operational) --------- | 834 | | 836 If the association can be reestablished before the V5UA layer is noti- 837 fied, communication SHALL proceed as usual and no other action SHALL 838 be taken by the ASP. 840 5.3. C-channel overload on SG 842 If the SG detects an overload condition on a C-channel, it SHOULD 843 indicate this by sending an Error Indication message, reason Overload 844 to the MGC. The MGC SHOULD then take appropriate actions to clear this 845 overload condition. 847 The SG SHALL resend the Error Indication message with reason Overload 848 as long as the overload condition persist. An interval of 120 seconds 849 for resend of this message is RECOMMENDED. 851 6. Examples 853 6.1. Link Identification Procedure (successful) 855 The Link Identification Procedures themselves are described by the 856 V5.2 standard [3]. 858 A message flow example for an LE initiated Link Identification 859 procedure over V5UA is shown below. An active association between ASP 860 and SG is established prior to the following message flows, and the V5 861 interface is already in service: 863 ASP SG 865 | | 866 | ------ Data Request (LnkCtrl: FE-IDReq) ------> | 867 | <-- Data Indication (LnkCtrl Ack: FE-IDReq) --- | 868 | | 869 | <---- Data Indication (LnkCtrl: FE-IDAck) ----- | 870 | ---- Data Request (LnkCtrl Ack: FE-IDAck) ----> | 871 | | 872 | ------ Sa-Bit Status Request ( Sa7 ) ---------> | 873 | <--- Sa-Bit Status Indication ( Sa7, ZERO ) --- | 874 | | 875 | ------- Data Request (LnkCtrl: FE-IDRel) -----> | 876 | <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- | 877 | | 879 The next example also shows a Link Identification procedure, but this 880 time initiated by the AN. Again the ASP association and the V5 inter- 881 face are already in service: 883 ASP SG 885 | | 886 | <---- Data Indication (LnkCtrl: FE-IDReq) ----- | 887 | -- Data Request (LnkCtrl Ack: FE-IDReq) ------> | 888 | | 889 | ---------- Sa-Bit Set Req ( Sa7, ZERO ) ------> | 890 | <--------- Sa-Bit Set Conf (Sa7) -------------- | 891 | | 892 | ------- Data Request (LnkCtrl: FE-IDAck) -----> | 893 | <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- | 894 | | 895 | <---- Data Indication (LnkCtrl: FE-IDRel) ----- | 896 | ---- Data Request (LnkCtrl Ack: FE-IDRel) ----> | 897 | | 898 | ------------ Sa-Bit Set Req ( Sa7, ONE ) -----> | 899 | <----------- Sa-Bit Set Conf (Sa 7) ----------- | 900 | | 902 7. Security Considerations 904 The security considerations discussed for the 'Security Considerations 905 for SIGTRAN Protocols' [7] document apply to this document. 907 8. IANA Considerations 909 8.1. SCTP Payload Protocol Identifiers 911 IANA has assigned a V5UA value for the Payload Protocol Identifier in 912 the SCTP DATA chunk. The following SCTP Payload Protocol identifier is 913 registered: 915 V5UA "6" 917 the SCTP Payload Protocol identifier value "6" SHOULD be included in 918 each SCTP DATA chunk to indicate that the SCTP is carrying the V5UA 919 protocol. The value "0" (unspecified) is also allowed but any other 920 values MUST not be used. This Payload Protocol Identifier is not 921 directly used by SCTP but MAY be used by certain network entities to 922 identify the type of information being carried in a Data chunk. 924 The User Adaptation peer MAY use the Payload Protocol Identifier as a 925 way of determining additional information about the data being 926 presented to it by SCTP. 928 8.2. V5UA Port Number 930 IANA has registered SCTP (and UDP/TCP) Port Number 5675 for V5UA. 932 9. Acknowledgements 934 The authors would like to thank Fahir Ergincan, Milos Pujic, Graeme 935 Currie, Berthold Jaekle, Ken Morneault and Lyndon Ong for their valu- 936 able comments and suggestions. 938 10. References 940 10.1. Normative References 942 [1] RFC 3057, "ISDN Q.921-User Adaptation Layer", K. Morneault, S. 943 Rengasami, M. Kalla, G. Sidebottom, February 2001 945 [2] ETSI EN 300 324-1 (1999): V interfaces at the digital Local 946 Exchange (LE); V5.1 interface for the support of Access Network 947 (AN); Part 1: V5.1 interface specification. 949 [3] ETSI EN 300 347-1 (1999): V interfaces at the digital Local 950 Exchange (LE); V5.2 interface for the support of Access Network 951 (AN); Part 1: V5.2 interface specification. 953 [4] ETSI ETS 300 125 (1991) : DSS1 protocol; User-Network interface 954 data link layer specification; (Standard is based on : ITU Q.920, 955 Q.921). 957 [5] ETSI ETS 300 166 (08/1993) : Transmission and Multiplexing; Phy- 958 sical and electrical characteristic of hierarchical digital 959 interfaces (Standard is based on G.703). 961 [6] ETSI ETS 300 167 (08/1993) : Transmission and Multiplexing; Func- 962 tional characteristic of 2048 kbits/s interfaces (Standard is 963 based on G.704, G.706). 965 [7] J. Loughney, M. Tuexen, J. Pastor-Balbas, 'Security Considera- 966 tions for SIGTRAN Protocols', Work in Progress. 968 10.2. Informative References 970 [7] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al, 971 October 2000 973 [8] RFC 2119, "Key words for use in RFCs to Indicate Requirement Lev- 974 els", S. Bradner, March 1997 976 [9] , "Instructions to Request 977 for Comments (RFC) Authors", J.Reynolds, R. Braden, April 2002 978 (Work in Progress) 980 11. Author's Addresses 982 Dr. Eva Weilandt Tel +49 7545 96 7267 983 Nortel Networks Germany Email eva.weilandt@nortelnetworks.com 984 88039 Friedrichshafen 985 Germany 987 Sanjay Rao Tel +1-919-991-2251 988 Nortel Networks Email rsanjay@nortelnetworks.com 989 35 Davis Drive 990 Research Triangle Park, NC 27709 991 USA 993 Neeraj Khanchandani Tel +1-919-991-2274 994 Nortel Networks Email neerajk@nortelnetworks.com 995 35 Davis Drive 996 Research Triangle Park, NC 27709 997 USA 998 This Draft Expires in 6 months from May 2003