Network Working Group Malleswar Kalla INTERNET-DRAFT Selvam Rengasami Telcordia Technologies Ken Morneault Cisco Systems Greg Sidebottom Nortel Networks Expires in six months Oct 1999 ISDN Q.921-User Adaptation Layer Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http//www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http//www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Simple Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. Kalla, Rengasami, Morneault, & Sidebottom [Page 1] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 TABLE OF CONTENTS 1. Introduction.....................................................2 1.1 Scope.........................................................2 1.2 Terminology...................................................3 1.3 Signaling Transport Architecture..............................3 1.4 Services Provided by the IUA Layer............................4 1.5 Functions Implemented by the IUA Layer........................6 1.6 Definition of IUA Boundaries..................................7 2. Protocol Elements................................................7 2.1 Common Message Header.........................................7 2.2 IUA Message Header............................................8 2.3 Description of Messages.......................................9 3. Procedures......................................................13 3.1 Procedures to Support Service in Section 1.4.1...............13 3.2 Procedures to Support Service in Section 1.4.2...............14 3.3 Procedures to Support Service in Section 1.4.3...............14 4. Examples.........................................................18 4.1 Establishment of associations between SG and MGC examples.....18 4.2 Q.921/Q.931 primitives backhaul Examples......................19 4.3 Layer Management Communication Examples.......................20 5. Security........................................................20 6. Acknowledgements................................................20 7. References......................................................20 8. Author's Addresses..............................................21 1. Introduction In this document, the term Q.921 user refers to an upper layer which uses the services of Q.921, not the user side of ISDN interface. Examples of the upper layer would be Q.931 and QSIG. This section describes the need for ISDN Q.921 User Adaptation (IUA) layer protocol as well as how this protocol shall be implemented. 1.1 Scope There is a need for Switched Circuit Network (SCN) signaling protocol delivery from an ISDN Signaling Gateway (SG) to a Media Gateway Controller (MGC). The delivery mechanism should meet the following criteria * Support for transport of the Q.921 / Q.931 boundary primitives * Support for communication between Layer Management modules on SG and MGC * Support for management of active associations between SG and MGC This draft supports both ISDN Primary Rate Access (PRA) as well as Basic Rate Access (BRA) including the support for both point-to-point mode and point-to-multipoint modes of communication. QSIG adaptation layer requirements do not differ from Q.931 adaptation layer, hence the procedures described in this draft are also applicable to QSIG Kalla, Rengasami, Morneault, & Sidebottom [Page 2] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 adaptation layer. For simplicity, only Q.931 will be mentioned in the rest of this document. 1.2 Terminology Interface - For the purposes of this document an interface supports the relevant ISDN signalling channel. This signalling channel may be a 16 kbps D channel for an ISDN BRA as well as 64 kbps primary or backup D channel for an ISDN PRA. For QSIG, the signalling channel is a Qc channel. Q.921-User - Any protocol normally using the services of the ISDN Q.921 (e.g., Q.931, QSIG, etc.). Backhaul - A SG terminates the lower layers of an SCN protocol and backhauls the other layer to MGC for call processing. For the purposes of this draft the SG terminates Q.921 and backhauls Q.931 to MGC. Association - An association refers to a SCTP association. The association will provide the transport for the delivery of Q.921-User protocol data units and IUA adaptation layer peer messages. Stream - A stream refers to a SCTP stream. For the purposes of this document, a stream will be mapped to an ISDN signalling channel. Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the Q.931 and call processing for D channels terminated by the Signaling Gateways. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary, à). Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances. Application Server Process Path (ASP Path or just Path) - A Path to a remote Application Server Process instance. A Path maps 1:1 to an SCTP association. Fail-over - The capability to re-route signalling traffic as required between related ASPs in the event of failure or unavailability of the currently used ASP (e.g. from primary MGC to back-up MGC). Fail-over also applies upon the return to service of a previously unavailable process. 1.3 Signaling Transport Architecture The architecture that has been defined [5] for SCN signaling transport over IP uses multiple components, including an IP transport protocol, a signaling common transport protocol and an adaptation module to support the functions expected by a particular SCN signaling protocol from its underlying protocol layer. This document defines an adaptation module that is suitable for the transport of ISDN Q.921 User (Q.931). Kalla, Rengasami, Morneault, & Sidebottom [Page 3] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 In a Signaling Gateway, it is expected that the ISDN signaling is received over a standard ISDN network termination. The SG then provides interworking of transport functions with IP Signaling Transport, in order to transport the Q.931 signaling messages to the MGC where the peer Q.931 protocol layer exists, as shown below ****** ISDN ****** IP ******* * EP *---------------* SG *--------------* MGC * ****** ****** ******* +-----+ +-----+ |Q.931| |Q.931| +-----+ +----------+ +-----+ | | | | IUA| | IUA | | | | +----+ +-----+ |Q.921| |Q.921|SCTP| |SCTP | | | | +----+ +-----+ | | | |UDP | | UDP | | | | +----+ +-----+ | | | | IP + | IP | +-----+ +-----+----+ +-----+ EP - ISDN End Point SCTP - Simple Control Transmission Protocol (Refer to [3]) IUA - ISDN User Adaptation Layer Protocol 1.3.1 UDP port A request will be made to IANA to assign a UDP port for IUA. 1.4 Services Provided by the IUA Layer 1.4.1 Support for transport of Q.921/Q.931 boundary primitives In the backhaul scenario, the Q.921/Q.931 boundary primitives are exposed. IUA layer needs to support all of the primitives of this boundary to successfully backhaul Q.931. This includes the following primitives [1] DL-ESTABLISH The DL-ESTABLISH primitives are used to request, indicate and confirm the outcome of the procedures for establishing multiple frame operation. DL-RELEASE DL-RELEASE primitives are used to request, indicate, and confirm the outcome of the procedures for terminating a previously established multiple frame operation, or for reporting an unsuccessful establishment attempt. Kalla, Rengasami, Morneault, & Sidebottom [Page 4] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 DL-DATA The DL-DATA primitives are used to request and indicate SDUs containing Q.931 PDUs which are to be transmitted, or have been received, by the Q.921 layer using the acknowledged information transfer service. DL-UNIT DATA The DL-UNIT DATA primitives are used to request and indicate SDUs containing Q.931 PDUs which are to be transmitted, by the Q.921 layer using the unacknowledged information transfer service. 1.4.2 Support for communication between Layer Management modules on SG and MGC It is envisioned that the IUA layer needs to provide some services that will facilitate communication between Layer Management modules on the SG and MGC. These primitives are pointed out in [2], which are shown below MIUA-TEI STATUS The MIUA-TEI STATUS primitives are used to request, confirm and indicate the status (in service/out of service) of a TEI. To facilitate reporting of errors that arise because of backhauling Q.931 scenario, the following primitive is defined M-ERROR The M-ERROR primitive is used to indicate an error with a received IUA message (e.g., interface identifier value is not known to the SG). 1.4.3 Support for management of active associations between SG and MGC The IUA layer on the SG keeps the state of various ASPs it is associated with. A set of primitives between IUA layer and the Layer Management are defined below to help the Layer Management manage the association(s) between SG and MGC. The IUA layer can be instructed by the Layer Management to establish SCTP association to a peer IUA node. This can be achieved using the following primitive M-SCTP ESTABLISH The M-SCTP ESTABLISH primitives are used to request, indicate, and confirm the establishment of SCTP association to a peer IUA node. The IUA layer may also need to inform the status of the SCTP associations to the Layer Management. This can be achieved using the following primitive Kalla, Rengasami, Morneault, & Sidebottom [Page 5] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 M-SCTP STATUS The M-SCTP STATUS primitives are used to request and indicate the status of the underlying SCTP association(s). The Layer Management may need to inform the IUA layer of a user status (i.e., failure, active, etc.), so that messages can be exchanged between IUA layer peers to stop traffic to the local IUA user. This can be achieved using the following primitive. M-ASP STATUS The M-ASP STATUS primitives are used to request and indicate the status of the Application Server Process. 1.5 Functions Implemented by the IUA Layer 1.5.1 Mapping The IUA layer must maintain a map of the Interface ID to a physical interface on the Signaling Gateway. A physical interface would be a T1 line, E1 line, etc. In addition, for a given interface the SG must be able to identify the associated signalling channel. 1.5.2 Status of ASPs The IUA layer on the SG must maintain the state of various ASPs it is associated with. The state of an ASP changes because of reception of peer-to-peer messages or reception of indications from the local SCTP association. ASP state transition procedures are described in section 3.3.1. 1.5.3 SCTP Stream Management SCTP allows a user specified number of streams to be opened during the initialization. It is the responsibility of the IUA layer to ensure proper management of these streams. Because of the unidirectional nature of streams, IUA layers are not aware of the stream information from the peer IUA layers. For the purposes of this draft, it is assumed that a separate stream will be used for each D channel. 1.5.4 Seamless Network Management Interworking The IUA layer on the SG should pass an indication of unavailability of the IUA-User (Q.931) to the local Layer Management, if the currently active ASP moves from the ACTIVE state. The Layer Management could instruct Q.921 to take some action, if it deems appropriate. 1.5.5 Management Inhibit/Uninhibit Local Management may wish to stop traffic across an SCTP association in order to temporarily remove the association from service or to perform testing and maintenance activity. The function could Kalla, Rengasami, Morneault, & Sidebottom [Page 6] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 optionally be used to manage the start of traffic on to a newly available SCTP association. 1.6 Definition of IUA Boundaries 1.6.1 Definition of IUA/Q.921 boundary DL-ESTABLISH DL-RELEASE DL-DATA DL-UNIT DATA 1.6.2 Definition of IUA/Q.931 boundary DL-ESTABLISH DL-RELEASE DL-DATA DL-UNIT DATA 1.6.3 Definition of SCTP/IUA Boundary The upper layer primitives provided by SCTP are available in Reference [3] section 9. 1.6.4 Definition of IUA/Layer-Management Boundary M-ERROR M-SCTP ESTABLISH M-SCTP STATUS M-ASP STATUS MIUA-TEI STATUS 2. Protocol Elements This section describes the format of various messages used in this protocol. 2.1 Common Message Header The protocol messages for Q.921 User Adaptation require a message header which contains the adaptation layer version, the message type, and message length. All types of messages contain this header. This message header is common among all SCN signaling protocol adaptation layers. 0 7 8 15 16 31 +---------------+---------------+ | Vers | Spare | Msg Type | +---------------+---------------+ | Message Length | +-------------------------------+ Figure 1 Common Header Format Kalla, Rengasami, Morneault, & Sidebottom [Page 7] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 2.1.1 Version The version field (vers) contains the version of the IUA adaptation layer. The supported versions are 01 Release 1.0 protocol 2.1.2 Message Types The following list contains the message names for the defined messages. Q.921/Q.931 Boundary Primitives Transport (QAUP) Messages Data Request Message 0501 Data Indication Message 0502 Unit Data Request Message 0503 Unit Data Indication Message 0504 Establish Request 0505 Establish Confirm 0506 Establish Indication 0507 Release Request 0508 Release Confirm 0509 Release Indication 0510 Application Server Process Maintenance (ASPM) messages ASP Up 0301 ASP Down 0302 ASP Active 0401 ASP Inactive 0402 Management (MGMT) Messages Error Indication 0000 TEI Status Request 0101 TEI Status Confirm 0102 TEI Status Indication 0103 2.1.3 Message Length The Message length defines the length of the message in octets, not including the common Message header. 2.2 IUA Message Header In addition to the common message header, there will be a specific message header for QAUP and TEI related MGMT messages. The IUA message header will immediately follow the common message header in these messages. This message header will contain the Interface Identifier and Data Link Connection Identifier(DLCI). The Interface Identifier identifies Kalla, Rengasami, Morneault, & Sidebottom [Page 8] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 the physical interface terminating the signalling channel at the SG for which the signaling messages are sent/received. The interface identifier follows the same endpoint naming scheme provided in MGCP [4]. The length field indicates the end of the string. For example, if a Signaling Gateway terminates a T1 and the D channel is on timeslot 24, the interface id could be the following t1/24@sgw1.example.net The use of wildcards is not acceptable. Ed's Note: The Interface Identifier string should be padded to 32-bit boundaries. 0 7 8 15 16 31 +---------------+---------------+ | Tag (0x1) | Length | +-------------------------------+ | Interface Identifier | +-------------------------------+ | DLCI | Spare | +-------------------------------+ Figure 2 IUA Message Header The DLCI format is shown below in Figure 3. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | SPR | SAPI | +-----------------------------------------------+ | 1 | TEI | +-----------------------------------------------+ Figure 3 DLCI Format SPR Spare, 2nd bit in octet 1 SAPI Service Access Point Identifier, 3rd thru 8th bits in octet 1 TEI Terminal Endpoint Identifier, 2nd thru 8th bits in octet 2 The DLCI field (including the SAPI and TEI) is coded in accordance with Q.921. 2.3 Description of Messages 2.3.1 Establish Messages (Request, Confirm, Indication) The Establish Messages are used to establish a data link on the signalling channel or to confirm that a data link on the signalling channel has been established. Kalla, Rengasami, Morneault, & Sidebottom [Page 9] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 The Establish messages contain the common message header followed by IUA message header. It does not contain any additional parameters. 2.3.2 Release Messages (Request, Indication, Confirmation) The Release Request message is used to release the data link on the signalling channel. The Release Confirm and Indication messages are used to indicate that the data link on the signalling channel has been released. The Release messages contain the common message header followed by IUA message header. The Release confirm message is in response to a Release Request message and it does not contain any additional parameters. The Release Request and Indication messages contain the following parameters REASON 0 15 16 31 +---------------+---------------+ | Reason | +---------------+---------------+ The valid values for Reason are shown in the following table. Define Value Description RELEASE_MGMT 0x0 Management layer generated release. RELEASE_PHYS 0x1 Physical layer alarm generated release. RELEASE_DM 0x2 Specific to a request. Indicates Layer 2 should release and deny all requests from far end to establish a data link on the signalling channel (i.e. if SABME is received send a DM) RELEASE_OTHER 0x3 Other reasons Note Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid reason codes for a Release Request message. 2.3.3 Data Messages (Request, Indication) The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to acknowledged information transfer service. The Data messages contain the common message header followed by IUA message header. The Data message contains the following parameters PROTOCOL DATA 0 15 16 31 +---------------+---------------+ ... | Protocol Data | ... +---------------+---------------+ Kalla, Rengasami, Morneault, & Sidebottom [Page 10] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 The protocol data contains upper layer signalling message e.g. Q.931, QSIG. 2.3.4 Unit Data Messages (Request, Indication) The Unit Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to unacknowledged information transfer service. The Unit Data messages contain the common message header followed by IUA message header. The Unit Data message contains the following parameters PROTOCOL DATA 0 15 16 31 +---------------+---------------+ ... | Protocol Data | ... +---------------+---------------+ 2.3.5 ASP Messages (Up, Down, Active, Inactive) The ASP messages are exchanged between IUA layer peers to notify the state of the Application Server Process. The ASP messages contain the common message header and the following optional parameters Adaptation Layer Identifier SCN Protocol Identifier Info String The Adaptation Layer Identifier is a string that identifies the adaptation layer. This string must be set to "IUA". The Protocol Identifier field contains the identity of the specific SCN signaling protocol being transported. The Protocol ID defines the protocol type, variant, and version, and thereby specifies the components and encoding of the PROTOCOL DATA field. The Protocol Identifier also defines what SCN protocol message components are included in the PROTOCOL DATA field. (Ed's Note Need encoding of mime-type value or OID or fixed string/integer that will be administered outside of this document (IANA). Also, perhaps bring in text from Christian's mime document - See "draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP media type defined according to the rules defined in RFC 2048.) Info String field can be used for implementation specific diagnostic information. Kalla, Rengasami, Morneault, & Sidebottom [Page 11] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 The format for the ASP messages is as follows 0 15 16 31 +---------------+---------------+ | Tag (0x2) | Length | +---------------+---------------+ | Adaptation Layer Identifier | +---------------+---------------+ | Tag (0x3) | Length | +---------------+---------------+ | SCN Protocol Identifier | +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | Info String | +---------------+---------------+ Ed's Note Strings are padded to 32-bit boundaries. The length field indicates the end of the string. 2.3.6 TEI Status Messages (Request, Confirm and Indication) The TEI Status messages are exchanged between IUA layer peers to request, confirm and indicate the status of a particular TEI. The TEI Status messages contain the common message header followed by IUA message header. The TEI Status Request message does not contain any additonal parameters. The TEI Status Indication, and Confirm messages contain the following parameters STATUS 0 7 15 16 31 +---------------+---------------+ | Status | +-------------------------------+ The valid values for Status are shown in the following table. Define Value Description IN_SERVICE 0x0 TEI is in service OUT_OF_SERVICE 0x1 TEI is out of service Kalla, Rengasami, Morneault, & Sidebottom [Page 12] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 2.3.7 Error Message (Indication) The Error Message is used to indicate any errors occured because of the backhaul architecture. The Error messages contain the common message header followed by IUA message header. The Error Message contains the following parameters REASON OTHER INFORMATION 0 15 16 31 +---------------+---------------+ | Reason | +---------------+---------------+ | Other Information | +---------------+---------------+ The valid values for Reason are shown in the following table. Define Value Description INVALID_TEI 0x0 Invalid TEI INVALID_IFID 0x1 Invalid interface ID UNDEFINED_MSG 0x2 An unexpected message was received VERSION_ERR 0x3 The IUA layers are of different version INVALID_STID 0x4 Invalid SCTP stream identifier INVALID_SCNV 0x5 Invalid SCN version INVALID_ALI 0x6 Invalid Adaptation Layer Identifier Other Information field can contain diagnostic information related to the error. It can contain a copy of the received message that resulted in the error. 3.0 Procedures The IUA layers needs to respond to various primitives it receives from other layers as well as messages it receives from the peer-to-peer messages. This section describes various procedures involved in response to these events. 3.1 Procedures to support service in section 1.4.1 These procedures achieve the IUA layer's "Transport of Q.921/Q.931 boundary" service. 3.1.1 Q.921 or Q.931 primitives procedures On receiving these primitives from the local layer, the IUA layer will send the corresponding QAUP message (Data, Unit Data, Establish, Release) to its peer. While doing so, the IUA layer needs to fill various fields of the common and specific headers correctly. In Kalla, Rengasami, Morneault, & Sidebottom [Page 13] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 addition the message needs to be sent on the SCTP stream that corresponds to the D channel. 3.1.2 QAUP message procedures On receiving QAUP messages from a peer IUA layer, the IUA layer on an SG or MGC needs to invoke the corresponding layer primitives (DL-ESTABLISH, DL-DATA, DL-UNIT DATA, DL-RELEASE) to the local Q.921 or Q.931 layer. 3.2 Procedures to support service in section 1.4.2 These procedures achieve the IUA layer's "Support for Communication between Layer Managements" service. 3.2.1 Layer Management primitives procedures On receiving these primitives from the local layer, the IUA layer will send the corresponding MGMT message (TEI Status, Error) to its peer. While doing so, the IUA layer needs to fill various fields of the common and specific headers correctly. 3.2.2 MGMT message procedures On receiving MGMT messages the IUA layer needs to invoke the corresponding Layer Management primitives (MIUA-TEI STATUS, M-ERROR) to the local layer management. 3.3 Procedures to support service in section 1.4.3 These procedures achieve the IUA layer's "Support for management of active associations between SG and MGC" service. 3.3.1 State Maintenance The IUA layer on the SG needs to maintain the states of each ASP as well as the state of the AS. 3.3.1.1 ASP States The state of the each ASP is maintained in the IUA layer on the SG. The state of an ASP changes due to events. The events include * Reception of messages from peer IUA layer * Reception of indications from SCTP layer The possible states of an ASP are ASP-DOWN Application Server Process is unavailable. Initially all ASPs will be in this state. ASP-UP Application Server Process is available but application traffic is stopped. Kalla, Rengasami, Morneault, & Sidebottom [Page 14] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 ASP-ACTIVE Application Server Process is available and application traffic is active. At most one ASP per AS can be in the active state. Figure 4 ASP State Transition Diagram +-------------+ |-------->| | | | ASP-ACTIVE | | | | | | | | +-------------+ | ^ | | ASP | | ASP | Active | | Inactive | | v | +-------------+ | | | ASP Down / | | | SCTP CDI | | ASP-UP | | | | | | | | +-------------+ | ^ | | ASP | | ASP Down / | Up | | SCTP CDI | | v | +-------------+ | | | |-------->| | | ASP-DOWN | | | | | +-------------+ SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper Layer Protocol (IUA) on an SG. SCTP will send this indication when it detects the loss of connectivity to ASP's SCTP layer. 3.3.1.2 AS States The state of the AS is maintained in the IUA layer on the SG. The state of an AS changes due to events. These events include * ASP state transitions * Recovery timer triggers The possible states of an AS are AS-DOWN Application Server is unavailable. This state implies that all ASPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state. AS-UP One or more ASPs are in the ASP-UP state. Kalla, Rengasami, Morneault, & Sidebottom [Page 15] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 AS-ACTIVE Application Server is available and application traffic is active. This state implies that one ASP is in the ASP-ACTIVE state. AS-PENDING Currently Active ASP became inactive or SCTP association with it is lost. A Recovery timer will be started and in coming SCN messages will be queued by the SG. If an ASP becomes Active before the recovery timer expires, AS will move to AS-ACTIVE state and all the queued messages will be sent to the active ASP. If the recovery timer expires before an ASP becomes active, SG stops queuing messages and discards all queued messages. AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. Ed's Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN states, the Layer Management on MG may take appropriate SCN notification actions. Figure 5 AS State Transition Diagram +----------+ one ASP trans ACTIVE +-------------+ | |------------------------>| | | AS-UP | | AS-ACTIVE | | | | | | |< -| | +----------+ \ / +-------------+ ^ | \ Tr Trigger / ^ | | | \ at least one / | | | | \ ASP in UP / | | | | \ / | | | | \ / | | | | \ /---/ | | one ASP | | \ / one ASP | | ACTIVE ASP trans | | all ASP \-/----\ trans | | trans to UP or to UP | | trans to / \ ACTIVE | | ACTIVE ASP | | DOWN / \ | | SCTP CDI | | / \ | | | | / \ | | | | /all ASP \ | | | v / trans to \ | v +----------+ / DOWN \ +-------------+ | |<--/ -| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<------------------------| | +----------+ Tr Trigger no ASP +-------------+ in UP state or prev ACTIVE ASP trans to DOWN state Tr = Recovery Timer Trigger Kalla, Rengasami, Morneault, & Sidebottom [Page 16] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 3.3.2 ASP procedures for primitives 3.3.2.1 MGC Procedures When the IUA layer on a MGC receives M-SCTP ESTABLISH primitive, the IUA layer will try to establish an SCTP association with the SG. Or alternatively, if SG establishes the SCTP association first, the IUA layer will receive a SCTP Communication Up indication. The IUA layer will invoke the primitive M-SCTP ESTABLISH (confirm or indication) to the layer management. The IUA layer will then find out the state of its user from the Layer Management using the primitive M-ASP STATUS. The IUA layer will convey the status of the Q.931 layer to its peer IUA layer using the ASP (Up/Down/Active/Inactive) message. The IUA layer on MGC will eventually receive the acknowledgement of the ASP message from its peer IUA layer on SG, which it notifies to the Layer Management. If the IUA layer receives a SCTP-Communication Down indication from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP STATUS primitive. The Layer Management may try to reestablish the SCTP association using M-SCTP ESTABLISH primitive. 3.3.2.2 SG Procedures The SG MUST receive Establish message from the IUA layer on the MGC, before it will try to establish the data link on the signalling channel or respond to the Q.921 peer entity requesting establishment of a data link on the signalling channel. Ed's Note Procedures to prevent Q.921 from establishing a data link on the signalling channel (in response to peer requests) are still under investigation. When the IUA layer on a SG receives M-SCTP ESTABLISH primitive, the IUA layer will try to establish an SCTP association with the MGC. Or alternatively, if MGC establishes the SCTP association first, the IUA layer will receive a SCTP Communication Up indication. The IUA layer will invoke the primitive M-SCTP ESTABLISH (confirm or indication) to the layer management and change the state of that ASP to ASP-UP. If AS is in state AS-DOWN, it will move to AS-UP state. If the IUA layer receives a SCTP-Communication Down indication from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP STATUS primitive and change the state of that ASP to ASP-DOWN. If the AS is in state AS-UP and this ASP is the only one UP at that time, the AS state will move to AS-DOWN. If the AS is in state AS-ACTIVE and the ASP that moved to ASP-DOWN state is the active ASP, then AS will move to AS-PENDING state. The IUA layer on SG shall start the recovery timer and follow procedures described for AS-PENDING state in section 3.3.1.2. The IUA layer may optionally send ASP Down messages to all ASPs in the UP state to inform the failure of the primary ASP. The Layer Management may try to reestablish the SCTP association using M-SCTP ESTABLISH primitive on receiving the M-SCTP STATUS primitive from IUA. If the SCTP association(s) comes up the SG should wait for MGC to send ESTABLISH message before initiating procedures for establishing the Q.921 data link(s). Kalla, Rengasami, Morneault, & Sidebottom [Page 17] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 3.3.3 ASP procedures for peer-to-peer messages 3.3.3.1 MGC procedures On receiving ASP Down message from the IUA layer on SG, the IUA layer on MGC learns that the primary ASP is down for that SG. So, the IUA layer invokes the primitive M-ASP STATUS to the layer management. The Layer Management may choose to become the active ASP, in which case it will invoke the primitive M-ASP STATUS (with status equal to "ACTIVE"). The IUA layer will then inform the peer IUA layer on SG that it will be taking over using the ASP Active message. 3.3.3.2 SG procedures On receiving any ASP message from the IUA layer on the MGC, the IUA layer on SG MUST respond with the same ASP message to acknowledge it. Reception of the ASP Down message from the peer shall be treated similar to reception of SCTP-Communication Down indication from the lower layer (section 3.3.2.2). On receiving ASP Up message, it should mark the state of that ASP as ASP-UP and inform the status of the ASP to Layer Management using the M-ASP STATUS primitive. The state transition of the ASP to ASP-UP will result in AS state transition to AS-UP, only if the AS was in the AS-DOWN state. On receiving the ASP Active message the IUA layer shall change the state of that ASP to ASP-ACTIVE if the earlier state is ASP-UP. The IUA layer shall inform the Layer Management of the new status of the ASP. The state of AS will move to AS-ACTIVE. On receiving the ASP Inactive message, the IUA layer should change the state to UP, if the earlier state is ASP-ACTIVE, and inform Layer Management. The state of the AS shall be changed to AS-PENDING and IUA shall follow the procedures described for this scenario in section 3.3.2.2. 4. Examples 4.1 Establishment of associations between SG and MGC examples An example of the message flows for establishing active associations between SG and MGC is shown below. SG ASP1 <----------- ASP Up ASP Up ----------> (ACK) <----------- ASP Active ASP Active ----------> (ACK) Kalla, Rengasami, Morneault, & Sidebottom [Page 18] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 An example of message flows for establishment of associations with two ASPs and the message flows for take-over of the primary (ASP1) by the secondary (ASP2). SG ASP1 ASP2 <----------- ASP Up ASP Up ----------> (ACK) <------------------------------ ASP Up ASP Up ------------------------------> (ACK) <----------- ASP Active ASP Active ----------> (ACK) ... <----------- ASP Inactive ASP Inactive ----------> (ACK) (this message is optional) ASP Inactive ------------------------------> <------------------------------ ASP Active ASP Active ------------------------------> (ACK) 4.2 Q.921/Q.931 primitives backhaul Examples An example of the message flows for establishing a data link on a signalling channel, passing PDUs and releasing a data link on a signalling channel is shown below. An active association between MGC and SG is established (section 4.1) prior to the following message flows. SG MGC <----------- Establish Request Establish Response ----------> <----------- Data Request Data Indication -----------> <----------- Data Request Data Indication -----------> <----------- Data Request <----------- Data Request Data Indication -----------> <----------- Release Request (RELEASE_MGMT) Release Confirm ----------> Kalla, Rengasami, Morneault, & Sidebottom [Page 19] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 An example of the message flows for a failed attempt to establish a data link on the signalling channel is shown below. In this case, the gateway has a problem with its physical connection (e.g. Red Alarm), so it cannot establish a data link on the signalling channel. SG MGC <----------- Establish Request (ESTABLISH_START) Release Indication ----------> (RELEASE_PHYS) 4.3 Layer Management Communication Examples An example of the message flows for communication between Layer Management modules between SG and MGC is shown below. An active association between MGC and SG is established (section 4.1) prior to the following message flows. SG MGC <----------- Data Request Error ----------> (INVALID_TEI) <----------- TEI Status TEI Status ----------> 5.0 Security SCN adaptation layers rely on SCTP to provide security. 6.0 Acknowledgements The authors would like to thank Ming-te Chao, Keith Drage, and many others for their valuable comments and suggestions. 7.0 References [1] ITU-T Recommendation Q.920, 'Digital Subscriber Signalling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General Aspects' [2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a Voice over Packet Network' [3] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt, Octtember 1999 [4] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp-v1-03.txt, August 1999 Kalla, Rengasami, Morneault, & Sidebottom [Page 20] Internet Draft ISDN Q.921 User Adaptation Layer Oct 1999 [5] Framework Architecture for Signaling Transport, draft-ietf-sigtran-framework-arch-03.txt, June 1999 8.0 Author's Addresses Malleswar Kalla Tel +1-973-829-5212 Telcordia Technologies EMail kalla@research.telcordia.com MCC 1J211R 445 South Street Morristown, NJ 07960 USA Selvam Rengasami Tel +1-732-758-5260 Telcordia Technologies EMail srengasa@telcordia.com NVC-2Z439 331 Newman Springs Rd Red Bank, NJ 07701 USA Ken Morneault Tel +1-703-484-3323 Cisco Systems Inc. EMail kmorneau@cisco.com 13615 Dulles Technology Drive Herndon, VA. 20171 USA Greg Sidebottom Tel +1-613-763-7305 Nortel Networks EMail gregside@nortelnetworks.com 3685 Richmond Rd, Nepean, Ontario Canada K2H5B7