Network Working Group Javier Pastor INTERNET-DRAFT Ericsson Expires: November 2002 HannsJuergen Schwarzbauer Siemens May, 2002 IPSP Commmunication Description for M3UA Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document is a compilation of all the IPSP literature presented in the M3UA (MTP-3 User Adaptation Layer) RFC. It contains a description of IPSP commmunication showing the main concepts and procedures. Pastor, Schwarzbauer [Page 1] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 TABLE OF CONTENTS 1. Introduction.......................................................3 1.1 IPSP Definition....................................................3 1.2 Protocol Architecture..............................................3 1.3 Services Provided by the M3UA Layer................................4 1.4 Functional Areas...................................................5 1.5 Sample Configuration: SCCP Transport between IPSPs.................9 1.6 Definition of M3UA Boundaries......................................9 2. Conventions.......................................................10 3. M3UA Protocol Elements............................................10 4. Procedures.........................................................10 4.1 Procedures to Support the M3UA-User...............................10 4.2 Procedures to Support the Management of SCTP Associations.........12 4.3 AS and IPSP State Maintenance.....................................13 4.4 Routing Key Management Procedures [Optional]......................26 5. Examples of M3UA Procedures for IPSP...............................28 5.1 Establishment of Association and Traffic between IPSPs............29 5.2 IPSP Traffic Failover Examples....................................34 5.3 Normal Withdrawal of an IPSP from an Application Server and Teardown of an Association........................................35 5.4 M3UA/MTP3-User Boundary Examples for an IPSP.....................36 5.5 Complete examples for IPSP communication..........................37 6. Acknowledgements..................................................38 7. Authors' Addresses................................................38 8. References........................................................39 9. Open Issues........................................................39 Annex A: Example or RK use within IPSP communication..................39 Pastor, Schwarzbauer [Page 2] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 1. Introduction This draft is a compilation of all the IPSP literature presented in the M3UA RFC. Due to time shortages there were some cases where this specifications were mixed up with the SGP and ASP explanations and were hard to be extracted. No new features have been added, but just a copy/paste of the messages, procedures and examples texts extracted from the original document in order to assist in the IPSP concept understanding. The text is therefore almost the same as the one included in [M3UA- RFC]. Only light modifications have been done only when the understanding was difficult when including the "IPSP" word. Some general sections have also been included to make the document more consistent. This draft also intends to assist in finding the holes that this approach may include. This should help to complete the M3UAÆs implementorÆs guide and IPSP communication. The structure of this document is as follows: @ Extract of IPSP concepts from the Introduction section in [M3UA- RFC]. @ Extract of Procedures from [M3UA-RFC]. @ Examples from [M3UA-RFC] addapted to the IPSP communication. @ Open Issues to solve. @ An Annex with an example of RK management. 1.1 IPSP Definition IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node. A key point to understand the IPSP concept is said in [M3UA-RFC] section 4.3, when describing the procedures and is the following: "[...] only the SGP/ASP case is described but the SGP side of the procedures also apply to an IPSP sending traffic to an AS consisting of a set of remote IPSPs." 1.2 Protocol Architecture. The framework architecture that has been defined for SCN signalling transport over IP uses multiple components, including a common Pastor, Schwarzbauer [Page 3] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 signalling transport protocol and an adaptation module to support the services expected by a particular SCN signalling protocol from its underlying protocol layer. Within the framework architecture, this document defines an MTP3-User adaptation module suitable for supporting the transfer of messages of any protocol layer that is identified to the MTP Level 3 as an MTP User. The list of these protocol layers includes, but is not limited to, ISDN User Part (ISUP), Signalling Connection Control Part (SCCP), and Telephone User Part (TUP). TCAP or RANAP messages are transferred transparently by the M3UA protocol as SCCP payload, as they are SCCP-User protocols. It is recommended that M3UA use the services of the Stream Control Transmission Protocol (SCTP) as the underlying reliable common signalling transport protocol. This is to take advantage of various SCTP features such as: - Explicit packet-oriented delivery (not stream-oriented), - Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, - Optional multiplexing of user messages into SCTP datagrams, - Network-level fault tolerance through support of multi-homing at either or both ends of an association, - Resistance to flooding and masquerade attacks, and - Data segmentation to conform to discovered path MTU size. Under certain scenarios, such as back-to-back connections without redundancy requirements, the SCTP functions above might not be a requirement and TCP MAY be used as the underlying common transport protocol. 1.3 Services Provided by the M3UA Layer The M3UA Layer at an IPSP provides the equivalent set of primitives at its upper layer to the MTP3-Users as provided by the MTP Level 3 to its local MTP3-Users at an SS7 SEP. In IPSP communication the M3UA layer is used for point-to-point signalling between two IP Server Processes (IPSPs). In this case,the M3UA layer provides the same set of primitives and services at its Upper layer as the MTP3. The expected MTP3 services are not offered remotely from an SGP. The MTP3 services are provided but the procedures to support these services are a subset of the MTP3 procedures due to the simplified point-to-point nature of the IPSP to IPSP relationship. 1.3.1 Support for the Transport of MTP3-User Messages Pastor, Schwarzbauer [Page 4] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association between IPSPs. The M3UA layer does not impose a 272-octet signalling information field (SIF) length limit as specified by the SS7 MTP Level 2 protocol [7,8,9]. Larger information blocks can be accommodated directly by M3UA/SCTP, without the need for an upper layer segmentation / reassembly procedure as specified in recent SCCP or ISUP versions. 1.3.2 Native Management Functions The M3UA layer provides the capability to indicate errors associated with received M3UA messages and to notify, as appropriate, local management and/or the peer M3UA. 1.3.3 Support for the Management of SCTP Associations between IPSPs. The M3UA layer at the IPSP maintains the availability state of all configured remote IPSPs, to manage the SCTP Associations and the traffic between the M3UA peers. As well, the active/inactive and congestion state of remote IPSPs is maintained. The M3UA layer MAY be instructed by local management to establish an SCTP association to a peer M3UA node. This can be achieved using the M-SCTP_ESTABLISH primitives (See Section 1.6.3 in [M3UA-RFC] for a description of management primitives) to request, indicate and confirm the establishment of an SCTP association with a peer M3UA node. In order to avoid redundant SCTP associations between two M3UA peers, one side (client) SHOULD be designated to establish the SCTP association, or M3UA configuration information maintained to detect redundant associations (e.g., via knowledge of the expected local and remote SCTP endpoint addresses). Local management MAY request from the M3UA layer the status of the underlying SCTP associations using the M-SCTP_STATUS request and confirm primitives. Also, the M3UA MAY autonomously inform local management of the reason for the release of an SCTP association, determined either locally within the M3UA layer or by a primitive from the SCTP. Also the M3UA layer MAY inform the local management of the change in status of an IPSP or AS. This MAY be achieved using the M-ASP_STATUS request or M-AS_STATUS request primitives. 1.4 Functional Areas 1.4.1 Routing Contexts and Routing Keys 1.4.1.1 Overview Pastor, Schwarzbauer [Page 5] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 The distribution of SS7 messages between an IPSP within an Application Server and another IPSP within a remote Application Server is determined by the Routing Keys and their associated Routing Contexts. A Routing Key is essentially a set of SS7 parameters used to filter SS7 messages, whereas the Routing Context parameter is a 4- byte value (integer) that is associated to that Routing Key in a 1:1 relationship. The Routing Context therefore can be viewed as an index into a sending node's Message Distribution Table containing the Routing Key entries. Possible SS7 address/routing information that comprise a Routing Key entry includes, for example, the OPC, DPC, SIO found in the MTP3 routing label, or MTP3-User specific fields (such as the ISUP CIC, SCCP subsystem number). Some example Routing Keys are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the DPC/SSN combination. The particular information used to define an M3UA Routing Key is application and network dependent, and none of the above examples are mandated. An IPSP may be configured to process signalling traffic related to more than one Application Server, over a single SCTP Association. In ASP Active and ASP Inactive management messages, the signalling traffic to be started or stopped is discriminated by the Routing Context parameter. At an IPSP, the received Routing Context parameter uniquely identifies the range of signalling traffic associated with each Application Server that the IPSP is configured to receive. 1.4.1.2 Routing Key Limitations Routing Keys SHOULD be unique in the sense that each received SS7 signalling message SHOULD have a full or partial match to a single routing result. It is not necessary for the parameter range values within a particular Routing Key to be contiguous. For example, an AS could be configured to support call processing for multiple ranges of PSTN trunks that are not represented by contiguous CIC values. 1.4.1.3 Managing Routing Contexts and Routing Keys There are two ways to provision a Routing Key at an IPSP. A Routing Key may be configured statically using an implementation dependent management interface, or dynamically using the M3UA Routing Key registration procedure. When using a management interface to configure Routing Keys, the message distribution function within an IPSP is not limited to the set of parameters defined in this document. Other implementation dependent distribution algorithms may be used. Pastor, Schwarzbauer [Page 6] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 1.4.1.4 Message Distribution at the IPSP To direct messages received from the MTP3-User to the appropriate IP destination, an IPSP must perform a message distribution function using information from the received MTP3-User message. To support this message distribution, the IPSP might, for example, maintain the equivalent of a network address translation table, mapping incoming SS7 message information to an Application Server for a particular application and range of traffic. This could be accomplished by comparing elements of the incoming SS7 message to currently defined Routing Keys in the IPSP. These Routing Keys could in turn map directly to an Application Server that is enabled by one or more remote IPSPs. These remote IPSPs provide dynamic status information regarding their availability, traffic handling capability and congestion to the IPSP using various management messages defined in the M3UA protocol. The list of IPSPs in an AS is assumed to be dynamic, taking into account the availability, traffic handling capability and congestion status of the individual IPSPs in the list, as well as configuration changes and possible failover mechanisms. Normally, one or more IPSPs are active (i.e., currently processing traffic) in the AS but in certain failure and transition cases it is possible that there may be no active IPSP available. Broadcast, loadsharing and backup scenarios are supported. When there is no matching Routing Key entry for an incoming SS7 message from the local MTP3-User to M3UA, a default treatment MAY be specified. Possible solutions are to provide a default Application Server at the IPSP that directs all unallocated traffic to a (set of) default remote IPSP(s), or to drop the message and provide a notification to layer management. The treatment of unallocated traffic is implementation dependent. 1.4.2 SS7 and M3UA Interworking Since IPSPs use M3UA in a point-to-point fashion, there is no concept of routing of messages beyond the remote end. Therefore, SS7 and M3UA interworking is not necessary for this model. 1.4.3 Redundancy Models 1.4.3.1 Application Server Redundancy All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned Routing Key at an IPSP are mapped to an Application Server. Pastor, Schwarzbauer [Page 7] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 The Application Server is the set of all IPSPs associated with a specific Routing Key. Each IPSP in this set may be active, inactive or unavailable. Active IPSPs handle traffic; inactive IPSPs might be used when active IPSPs become unavailable. The failover model supports an "n+k" redundancy model, where "n" IPSPs is the minimum number of redundant IPSPs required to handle traffic and "k" IPSPs are available to take over for a failed or unavailable IPSP. A "1+1" active/backup redundancy is a subset of this model. A simplex "1+0" model is also supported as a subset, with no IPSP redundancy. 1.4.4 Flow Control Local Management at an IPSP may wish to stop traffic across an SCTP association to temporarily remove the association from service or to perform testing and maintenance activity. The function could optionally be used to control the start of traffic on to a newly available SCTP association. 1.4.5 Congestion Management The M3UA layer is informed of local and IP network congestion by means of an implementation-dependent function (e.g., an implementation-dependent indication from the SCTP of IP network congestion). At an IPSP, the M3UA layer indicates congestion to local MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3 procedures, to invoke appropriate upper layer responses. The M3UA layer at an IPSP MAY indicate local congestion to an M3UA peer with an SCON message. 1.4.6 SCTP Stream Mapping. The M3UA layer at IPSPs also supports the assignment of signalling traffic into streams within an SCTP association. Traffic that requires sequencing SHOULD be assigned to the same stream. To accomplish this, MTP3-User traffic may be assigned to individual streams based on, for example, the SLS value in the MTP3 Routing Label or the ISUP CIC assignment, subject of course to the maximum number of streams supported by the underlying SCTP association. 1.4.7 Client/Server Model In the case of IPSP to IPSP communication, the peer endpoints using Pastor, Schwarzbauer [Page 8] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 M3UA SHOULD be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations. The SCTP and TCP Registered User Port Number Assignment for M3UA is 2905. 1.5 Sample Configuration: SCCP Transport between IPSPs Figure 1 ******** IP ******** * IPSP *----------* IPSP * ******** ******** +------+ +------+ |SCCP- | |SCCP- | | User | | User | +------+ +------+ | SCCP | | SCCP | +------+ +------+ | M3UA | | M3UA | +------+ +------+ | SCTP | | SCTP | +------+ +------+ | IP | | IP | +------+ +------+ |________________| ---------------- This example shows an architecture where no Signalling Gateway is used. In this example, SCCP messages are exchanged directly between two IP- resident IPSPs with resident SCCP-User protocol instances, such as RANAP or TCAP. SS7 network interworking is not required, therefore there is no MTP3 network management status information for the SCCP and SCCP-User protocols to consider. Any MTP-PAUSE, MTP-RESUME or MTP-STATUS indications from the M3UA layer to the SCCP layer should consider the status of the SCTP Association and underlying IP network and any congestion information received from the remote site. 1.6 Definition of M3UA Boundaries As defined in [RFC-M3UA]. Pastor, Schwarzbauer [Page 9] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. M3UA Protocol Elements All the messages from [RFC-M3UA] MAY/SHOULD/MUST? be used with IPSP communication except DUNA, DAVA, DAUD and DRST. The description of the M3UA messages and parameters can be found on [RFC-M3UA]. 4. Procedures The M3UA layer needs to respond to various local primitives it receives from other layers as well as the messages that it receives from the peer M3UA layer. This section describes the M3UA procedures in response to these events. 4.1 Procedures to Support the M3UA-User 4.1.1 Receipt of Primitives from the M3UA-User On receiving an MTP-TRANSFER request primitive from an upper layer at an IPSP, the M3UA layer sends a corresponding DATA message (see Section 3 of [M3UA-RFC]) to its M3UA peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER indication primitive to the upper layer. The M3UA message distribution function (see Section 1.4.2.1 in [M3UA- RFC]) determines the Application Server (AS) based on comparing the information in the MTP-TRANSFER request primitive with a provisioned Routing Key. From the list of IPSPs within the AS table, a remote IPSP in the ASP- ACTIVE state is selected and a DATA message is constructed and issued on the corresponding SCTP association. If more than one IPSP is in the ASP-ACTIVE state (i.e., traffic is to be loadshared across more than one IPSP), one of the IPSP in the ASP_ACTIVE state is selected from the list. If the IPSPs are in Broadcast Mode, all active IPSPs will be selected and the message sent to each of the active IPSPs. The selection algorithm is implementation dependent but could, for example, be round robin or based on the SLS or ISUP CIC. The appropriate selection algorithm must be chosen carefully as it is Pastor, Schwarzbauer [Page 10] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 dependent on application assumptions and understanding of the degree of state coordination between the ASP_ACTIVE IPSPs in the AS. In addition, the message needs to be sent on the appropriate SCTP stream, again taking care to meet the message sequencing needs of the signalling application. DATA messages MUST be sent on an SCTP stream other than stream '0'. 4.1.2 Receipt of Primitives from the Layer Management On receiving primitives from the local Layer Management, the M3UA layer will take the requested action and provide an appropriate response primitive to Layer Management. An M-SCTP_ESTABLISH request primitive from Layer Management at an IPSP will initiate the establishment of an SCTP association. The M3UA layer will attempt to establish an SCTP association with the remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP layer. When an SCTP association has been successfully established, the SCTP will send an SCTP-COMMUNICATION_UP notification primitive to the local M3UA layer. At the IPSP that initiated the request, the M3UA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer Management when the association setup is complete. At the peer M3UA layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer Management upon successful completion of an incoming SCTP association setup. An M-SCTP_RELEASE request primitive from Layer Management initiates the teardown of an SCTP association. The M3UA layer accomplishes a graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN primitive to the SCTP layer. When the graceful shutdown of the SCTP association has been accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE notification primitive to the local M3UA layer. At the M3UA Layer that initiated the request, the M3UA layer will send an M- SCTP_RELEASE confirm primitive to Layer Management when the association shutdown is complete. At the peer M3UA Layer, an M- SCTP_RELEASE indication primitive is sent to Layer Management upon abort or successful shutdown of an SCTP association. An M-SCTP_STATUS request primitive supports a Layer Management query of the local status of a particular SCTP association. The M3UA layer simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS primitive to the SCTP layer. When the SCTP responds, the M3UA layer maps the association status information to an M-SCTP_STATUS confirm primitive. No peer protocol is invoked. Pastor, Schwarzbauer [Page 11] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings can be described for the various other SCTP Upper Layer primitives in RFC2960 [17] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS CHANGE. Alternatively, these SCTP Upper Layer primitives (and Status as well) can be considered for modelling purposes as a Layer Management interaction directly with the SCTP Layer. M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M3UA Notify or Error message respectively. These indications can also be generated based on local M3UA events. An M-ASP_STATUS request primitive supports a Layer Management query of the status of a particular local or remote IPSP. The M3UA layer responds with the status in an M-ASP_STATUS confirm primitive. No M3UA peer protocol is invoked. An M-AS_STATUS request supports a Layer Management query of the status of a particular AS. The M3UA responds with an M-AS_STATUS confirm primitive. No M3UA peer protocol is invoked. M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M- ASP_INACTIVE request primitives allow Layer Management at an IPSP to initiate state changes. Upon successful completion, a corresponding confirm primitive is provided by the M3UA layer to Layer Management. If an invocation is unsuccessful, an Error indication primitive is provided in the primitive. These requests result in outgoing ASP Up, ASP Down, ASP Active and ASP Inactive messages to the remote IPSP M3UA peer. 4.2 Procedures to Support the Management of SCTP Associations 4.2.1 Receipt of M3UA Peer Management Messages Upon successful state changes resulting from reception of ASP Up, ASP Down, ASP Active and ASP Inactive messages from a peer M3UA, the M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication primitives to the local Layer Management. M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M3UA Notify or Error message. These indications can also be generated based on local M3UA events. All non-Transfer and non-SSNM messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. ASPTM Pastor, Schwarzbauer [Page 12] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 messages MAY be sent on one of the streams used to carry the data traffic related to the Routing Context(s), to minimize possible message loss. BEAT and BEAT Ack messages MAY be sent using out-of- order delivery, and MAY be sent on any stream. 4.3 AS and IPSP State Maintenance The M3UA layer on the IPSP maintains the state of each remote IPSP, in each Application Server that the IPSP is configured to receive traffic, as input to the M3UA message distribution function. 4.3.1 IPSP States The state of each remote IPSP, in each AS that it is configured to operate, is maintained in the M3UA layer in the peer IPSP. The state of a particular IPSP in a particular AS changes due to events. The events include: * Reception of messages from the peer M3UA layer at the IPSP; * Reception of some messages from the peer M3UA layer at other IPSPs in the AS (e.g., ASP Active message indicating "Override"); * Reception of indications from the SCTP layer; or * Local Management intervention. The IPSP state transition diagram is shown in Figure 2. The possible states of an IPSP are: ASP-DOWN: The remote M3UA peer at the IPSP is unavailable and/or the related SCTP association is down. Initially all IPSPs will be in this state. An IPSP in this state SHOULD NOT be sent any M3UA messages, with the exception of Heartbeat, ASP Down Ack and Error messages. ASP-INACTIVE: The remote M3UA peer at the IPSP is available (and the related SCTP association is up) but application traffic is stopped. In this state the IPSP SHOULD NOT be sent any DATA or SSNM messages for the AS for which the ASP is inactive. ASP-ACTIVE: The remote M3UA peer at the IPSP is available and application traffic is active (for a particular Routing Context or set of Routing Contexts). SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M3UA) on an IPSP. The local SCTP layer will send this indication when it detects the loss of connectivity to the IPSPÆs peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST notification from the SCTP layer. Pastor, Schwarzbauer [Page 13] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 SCTP RI: The local SCTP layer's Restart indication to the upper layer protocol (M3UA) on an IPSP. The local SCTP will send this indication when it detects a restart from the IPSP's peer SCTP layer. Figure 2: IPSP State Transition Diagram, per AS +--------------+ | | +----------------------| ASP-ACTIVE | | Other +-------| | | IPSP in AS | +--------------+ | Overrides | ^ | | | ASP | | ASP | | Active | | Inactive | | | v | | +--------------+ | | | | | +------>| ASP-INACTIVE | | +--------------+ | ^ | ASP Down/ | ASP | | ASP Down / SCTP CDI/ | Up | | SCTP CDI/ SCTP RI | | v SCTP RI | +--------------+ | | | +--------------------->| ASP-DOWN | | | +--------------+ 4.3.2 AS States The state of the AS is maintained in the M3UA layer on the remote ASs. The state of an AS changes due to events. These events include: * IPSP state transitions * Recovery timer triggers The possible states of an AS are: AS-DOWN: The Application Server is unavailable. This state implies that all related IPSPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state. An Application Server is in the AS-DOWN state when it is removed from a configuration. AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related IPSPs are in the ASP- INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired. Pastor, Schwarzbauer [Page 14] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that at least one IPSP is in the ASP-ACTIVE state. AS-PENDING: An active IPSP has transitioned to ASP-INACTIVE or ASP- DOWN and it was the last remaining active IPSP in the AS. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the peer IPSP. If an IPSP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages will be sent to the IPSP. If T(r) expires before an IPSP becomes ASP-ACTIVE, and the peer IPSP has no alternative, the peerm IPSP may stops queuing messages and discards all previously queued messages. The AS will move to the AS- INACTIVE state if at least one IPSP is in ASP-INACTIVE state, otherwise it will move to AS-DOWN state. Figure 3 shows an example AS state machine for the case where the AS/IPSP data is preconfigured. For other cases where the AS/IPSP configuration data is created dynamically, there would be differences in the state machine, especially at creation of the AS. Figure 3: AS State Transition Diagram +----------+ one IPSP trans to ACTIVE +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<--- | | +----------+ \ +-------------+ ^ | \ Tr Expiry, ^ | | | \ at least one | | | | \ IPSP in ASP-INACTIVE | | | | \ | | | | \ | | | | \ | | one IPSP| | all IPSP \ one IPSP | | Last ACTIVE trans | | trans to \ trans to | | IPSP trans to to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE ASP- | | \ ACTIVE | | or ASP-DOWN INACTIVE| | \ | | (start Tr) | | \ | | | | \ | | | v \ | v +----------+ \ +-------------+ | | --| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<----------------------------| | +----------+ Tr Expiry and no IPSP +-------------+ in ASP-INACTIVE state) Pastor, Schwarzbauer [Page 15] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 Tr = Recovery Timer For example, where the AS/IPSP configuration data is not created until Registration of the first IPSP, the AS-INACTIVE state is entered directly upon the first successful REG REQ from an IPSP. Another example is where the AS/IPSP configuration data is not created until the first IPSP successfully enters the ASP-ACTIVE state. In this case the AS-ACTIVE state is entered directly. 4.3.3 M3UA Management Procedures for Primitives Before the establishment of an SCTP association the IPSP state at both IPSPs is assumed to be in the state ASP-DOWN. Once the SCTP association is established (see Section 4.2.1) and assuming that the local M3UA-User is ready, the local M3UA IPSP Maintenance (IPSPM) function will initiate the relevant procedures, using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey the IPSP state to the peer IPSP (see Section 4.3.4). If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the IPSP will be moved to ASP- DOWN. In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-establish the SCTP Association. This MAY be done by the M3UA layer automatically, or Layer Management MAY reestablish using the M- SCTP_ESTABLISH request primitive. In the case of an SCTP-RESTART indication at an IPSP, the IPSP is now considered by its M3UA peer to be in the ASP-DOWN state. The IPSP, if it is to recover, must begin any recovery with the ASP-Up procedure. 4.3.4 ASPM Procedures for Peer-to-Peer Messages 4.3.4.1 ASP Up Procedures After an IPSP has successfully established an SCTP association to a peer IPSP, the peer IPSP waits for the IPSP to send an ASP Up message, indicating that the IPSP M3UA peer is available. One IPSP is always the initiator of the ASP Up message. This action MAY be initiated at the IPSP by an M-ASP_UP request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. Pastor, Schwarzbauer [Page 16] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 When an ASP Up message is received at a peer IPSP and internally the remote IPSP is in the ASP-DOWN state and not considered locked out for local management reasons, the peer IPSP marks the remote IPSP in the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication primitive. If the peer IPSP is aware, via current configuration data, which Application Servers the IPSP is configured to operate in, the peer IPSP updates the IPSP state to ASP-INACTIVE in each AS that it is a member. Alternatively, the peer IPSP may move the IPSP into a pool of Inactive IPSPs available for future configuration within Application Server(s), determined in a subsequent Registration Request or ASP Active procedure. If the ASP Up message contains an ASP Identifier, the peer IPSP should save the ASP Identifier for that IPSP. The peer IPSP MUST send an ASP Up Ack message in response to a received ASP Up message even if the IPSP is already marked as ASP-INACTIVE at the peer IPSP. If for any local reason (e.g., management lockout) the peer IPSP cannot respond with an ASP Up Ack message, the peer IPSP responds to an ASP Up message with an Error message with reason "Refused - Management Blocking". At one IPSP, the ASP Up Ack message received is not acknowledged. Layer Management is informed with an M-ASP_UP confirm primitive. When one IPSP sends an ASP Up message it starts timer T(ack). If the IPSP does not receive a response to an ASP Up message within T(ack), the IPSP MAY restart T(ack) and resend ASP Up messages until it receives an ASP Up Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication. The IPSP must wait for the ASP Up Ack message before sending any other M3UA messages (e.g., ASP Active or REG REQ). If the peer IPSP receives any other M3UA messages before an ASP Up message is received (other than ASP Down - see Section 4.3.4.2), the peer IPSP MAY discard them. If an ASP Up message is received and internally the remote IPSP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message), and the remote IPSP state is changed to ASP-INACTIVE in all relevant Application Servers. If an ASP Up message is received and internally the remote IPSP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned and no further action is taken. Pastor, Schwarzbauer [Page 17] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 4.3.4.1.1 M3UA Version Control If an ASP Up message with an unsupported version is received, the receiving end responds with an Error message, indicating the version the receiving node supports and notifies Layer Management. This is useful when protocol version upgrades are being performed in a network. A node upgraded to a newer version should support the older versions used on other nodes it is communicating with. 4.3.4.1.2 Practical Considerations (ASP Up) To follow this process means an interchange of ASP Up messages from each end. Therefore four messages would be needed for completion. Another option is to consider a simple exchange. This is a simplification for the processed explained above. An IPSP may be considered in the ASP-INACTIVE state after an ASP Up or ASP Up Ack has been received from it. This option does not follow the ASP state transition diagram. The IPSP may inform Layer Management of the change in state of the remote IPSP using M-ASP_UP indication or confirmation primitives. If for any local reason (e.g., management lockout) an IPSP cannot respond to an ASP Up message with an ASP Up Ack message, it responds to an ASP Up message with an Error message with reason "Refused - Management Blocking" and leaves the remote IPSP in the ASP-DOWN state. 4.3.4.2 ASP-Down Procedures The IPSP will send an ASP Down message to a peer IPSP when the IPSP wishes to be removed from service in all Application Servers that it is a member and no longer receive any DATA, SSNM or ASPTM messages. This action MAY be initiated at the IPSP by an M-ASP_DOWN request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. Whether the IPSP is permanently removed from any AS is a function of configuration management. In the case where the IPSP previously used the Registration procedures (see Section 4.4.1) to register within Application Servers but has not deregistered from all of them prior to sending the ASP Down message, the peer IPSP MUST consider the ASP as Deregistered in all Application Servers that it is still a member. Upon the reception of ASP Down message by an IPSP from a peer IPSP, the IPSP marks the IPSP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the peer IPSP. Pastor, Schwarzbauer [Page 18] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 An IPSP MUST send an ASP Down Ack message in response to a received ASP Down message from the a peer IPSP even if the peer IPSP is already marked as ASP-DOWN at the IPSP. At an IPSP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with an M-ASP_DOWN confirm primitive. If an IPSP receives an ASP Down Ack without having sent an ASP Down message, the IPSP should now consider itself as in the ASP-DOWN state. If the IPSP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the IPSP should then initiate procedures to return itself to its previous state. When an IPSP sends an ASP Down message it starts timer T(ack). If the IPSP does not receive a response to an ASP Down message within T(ack), the IPSP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a negative indication. 4.3.4.2.1 Practical Considerations (ASP Down) To follow this process means an interchange of ASP Down messages from each end. Therefore four messages would be needed for completion. Another option is to consider a simple exchange. This is a simplification for the processed explained above An IPSP can be considered in the ASP-DOWN state after an ASP Down or ASP Down Ack has been received from it. This option does not follow the ASP state transition diagram. The IPSP may inform Layer Management of the change in state of the remote IPSP using M-ASP_DN indication or confirmation primitives. If for any local reason (e.g., management lockout) an IPSP cannot respond to an ASP Down message with an ASP Down Ack message, it responds to an ASP Down message with an Error message with reason "Refused - Management Blocking" and leaves the remote IPSP in the ASP-INACTIVE state. Pastor, Schwarzbauer [Page 19] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 4.3.4.3 ASP Active Procedures Anytime after the IPSP has received an ASP Up Ack message from the a peer IPSP, the IPSP MAY send an ASP Active message to the peer IPSP indicating that the IPSP is ready to start processing traffic. This action MAY be initiated at the IPSP by an M-ASP_ACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. In the case where an IPSP wishes to process the traffic for more than one Application Server across a common SCTP association, the ASP Active message(s) SHOULD contain a list of one or more Routing Contexts to indicate for which Application Servers the ASP Active message applies. It is not necessary for the IPSP to include all Routing Contexts of interest in a single ASP Active message, thus requesting to become active in all Routing Contexts at the same time. Multiple ASP Active messages MAY be used to activate within the Application Servers independently, or in sets. In the case where an ASP Active message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Server(s) the IPSP is a member. For the Application Servers that the IPSP can be successfully activated, the peer IPSP responds with one or more ASP Active Ack messages, including the associated Routing Context(s) and reflecting any Traffic Mode Type value present in the related ASP Active message. The Routing Context parameter MUST be included in the ASP Active Ack message(s) if the received ASP Active message contained any Routing Contexts. Depending on any Traffic Mode Type request in the ASP Active message, or local configuration data if there is no request, the peer IPSP moves the IPSP to the correct ASP traffic state within the associated Application Server(s). Layer Management is informed with an M-ASP_Active indication. If the peer IPSP receives any Data messages before an ASP Active message is received, the peer IPSP MAY discard them. By sending an ASP Active Ack message, the peer IPSP is now ready to receive and send traffic for the related Routing Context(s). The IPSP SHOULD NOT send Data or SSNM messages for the related Routing Context(s) before receiving an ASP Active Ack message from the peer IPSP, or it will risk message loss. Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Routing Contexts, allowing an IPSP to independently acknowledge the ASP Active message for different (sets of) Routing Contexts. An IPSP MUST send an Error message ("Invalid Routing Context") for each Routing Context value that the IPSP cannot be successfully activated. In the case where an "out-of-the-blue" ASP Active message is received (i.e., a peer IPSP has not registered with the IPSP or the IPSP has no static configuration data for the peer IPSP), the message MAY be silently discarded. Pastor, Schwarzbauer [Page 20] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 An IPSP MUST send an ASP Active Ack message in response to a received ASP Active message from a remote IPSP, if the remote IPSP is already marked in the ASP-ACTIVE state at the IPSP. At an IPSP, the ASP Active Ack message received is not acknowledged. Layer Management is informed with an M-ASP_ACTIVE confirm primitive. It is possible for the IPSP to receive Data message(s) before the ASP Active Ack message as the ASP Active Ack and Data messages from a remote IPSP may be sent on different SCTP streams. Message loss is possible as the IPSP does not consider itself in the ASP-ACTIVE state until reception of the ASP Active Ack message. When an IPSP sends an ASP Active message it starts timer T(ack). If the IPSP does not receive a response to an ASP Active message within T(ack), the IPSP MAY restart T(ack) and resend ASP Active messages until it receives an ASP Active Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Active messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M- ASP_ACTIVE confirm primitive carrying a negative indication. There are three modes of Application Server traffic handling in the IPSP M3UA layer: Override, Loadshare and Broadcast. When included, the Traffic Mode Type parameter in the ASP Active message indicates the traffic handling mode to be used in a particular Application Server. If an IPSP determines that the mode indicated in an ASP Active message is unsupported or incompatible with the mode currently configured for a peer IPSP, the IPSP responds with an Error message ("Unsupported / Invalid Traffic Handling Mode"). If the traffic handling mode of the Application Server is not already known via configuration data, then the traffic handling mode indicated in the first ASP Active message causing the transition of the Application Server state to AS-ACTIVE MAY be used to set the mode. In the case of an Override mode AS, reception of an ASP Active message at an IPSP causes the (re)direction of all traffic for the AS to the remote IPSP that sent the ASP Active message. Any previously active remote IPSP in the AS is now considered to be in state ASP- INACTIVE and SHOULD no longer receive traffic from the IPSP within the AS. The IPSP then MUST send a Notify message ("Alternate ASP_Active") to the previously active remote IPSP in the AS, and SHOULD stop traffic to/from that remote IPSP. The remote IPSP receiving this Notify MUST consider itself now in the ASP-INACTIVE state, if it is not already aware of this via inter-IPSP communication with the Overriding remote IPSP. In the case of a Loadshare mode AS, reception of an ASP Active message at an IPSP causes the direction of traffic to the remote IPSP sending the ASP Active message, in addition to all the other remote IPSPs that are currently active in the AS. The algorithm at the IPSP for loadsharing traffic within an AS to all the active remote IPSPs Pastor, Schwarzbauer [Page 21] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 is implementation dependent. The algorithm could, for example, be round-robin or based on information in the Data message (e.g., the SLS, SCCP SSN, ISUP CIC value). An IPSP, upon reception of an ASP Active message for the first remote IPSP in a Loadshare AS, MAY choose not to direct traffic to a newly active remote IPSP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" remote IPSPs in state ASP-ACTIVE in the AS). In this case, the IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. For the n+k redundancy case, IPSPs which are in that AS should coordinate among themselves the number of active IPSPs in the AS, and should start sending traffic only after n IPSPs are active. All IPSPs within a loadsharing mode AS must be able to process any Data message received for the AS, to accommodate any potential failover or rebalancing of the offered load. In the case of a Broadcast mode AS, reception of an ASP Active message at an IPSP causes the direction of traffic to the remote IPSP sending the ASP Active message, in addition to all the other remote IPSPs that are currently active in the AS. The algorithm at the IPSP for broadcasting traffic within an AS to all the active remote IPSPs is a simple broadcast algorithm, where every message is sent to each of the active remote IPSPs. An IPSP, upon reception of an ASP Active message for the first remote IPSP in a Broadcast AS, MAY choose not to direct traffic to a newly active remote IPSP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" IPSPs in state ASP-ACTIVE in the AS). In this case, the IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. For the n+k redundancy case, IPSPs which are in that AS should coordinate among themselves the number of active IPSPs in the AS, and should start sending traffic only after n IPSPs are active. Whenever an IPSP in a Broadcast mode AS becomes ASP-ACTIVE, the peer IPSP MUST tag the first DATA message broadcast in each traffic flow with a unique Correlation Id parameter. The purpose of this Id is to permit the newly active IPSP to synchronize its processing of traffic in each traffic flow with the other IPSPs in the broadcast group. 4.3.4.3.1 Practical Considerations (ASP Active) Either of the IPSPs can initiate communication. An interchange of ASP Active messages from each end is performed. This behavior gives the additional advantage of allowing the Pastor, Schwarzbauer [Page 22] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 selection of a particular AS to be activated from each end. It is especially useful when an IPSP is serving more than one AS. It will need four messages for completion. Alternatively a simplification of this process can also be implemented. When an IPSP receives an ASP Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE state. This option does not follow the IPSP state transition diagram. Only two messages will be needed for completion. 4.3.4.4 ASP Inactive Procedures When an IPSP wishes to withdraw from receiving traffic within an AS, the IPSP sends an ASP Inactive message to the peer IPSP. This action MAY be initiated at the IPSP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. In the case where an IPSP is processing the traffic for more than one Application Server across a common SCTP association, the ASP Inactive message contains one or more Routing Contexts to indicate for which Application Servers the ASP Inactive message applies. In the case where an ASP Inactive message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Servers the IPSP is a member and move the IPSP to the ASP-INACTIVE state in all Application Servers. In the case of an Override mode AS, where another IPSP has already taken over the traffic within the AS with an ASP Active ("Override") message, the IPSP that sends the ASP Inactive message is already considered by the peer IPSP to be in state ASP-INACTIVE. An ASP Inactive Ack message is sent to the IPSP, after ensuring that all traffic is stopped to the IPSP. In the case of a Loadshare mode AS, the IPSP moves the peer IPSP to the ASP-INACTIVE state and the AS traffic is reallocated across the remaining peer IPSPs in the state ASP-ACTIVE, as per the loadsharing algorithm currently used within the AS. A Notify message "Insufficient ASP resources active in AS") MAY be sent to all inactive remote IPSPs, if required. An ASP Inactive Ack message is sent to the remote IPSP after all traffic is halted and Layer Management is informed with an M-ASP_INACTIVE indication primitive. In the case of a Broadcast mode AS, the IPSP moves the remote IPSP to the ASP-INACTIVE state and the AS traffic is broadcast only to the remaining remote ASPs in the state ASP-ACTIVE within that AS. A Notify message ("Insufficient ASP resources active in AS") MAY be sent to all remote inactive IPSPs within the AS, if required. An ASP Inactive Ack message is sent to the remote IPSP after all traffic is halted and Layer Management is informed with an M-ASP_INACTIVE indication primitive. Pastor, Schwarzbauer [Page 23] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 Multiple ASP Inactive Ack messages MAY be used in response to an ASP Inactive message containing multiple Routing Contexts, allowing an IPSP to independently acknowledge for different (sets of) Routing Contexts upon the reception of ASP Inactive message with several RCs. The IPSP sends an Error message ("Invalid Routing Context") message for each invalid or unconfigured Routing Context value in a received ASP Inactive message. An IPSP MUST send an ASP Inactive Ack message in response to a received ASP Inactive message from a peer IPSP and the peer IPSP is already marked as ASP-INACTIVE at the IPSP. At an IPSP, the ASP Inactive Ack message received is not acknowledged. Layer Management is informed with an M-ASP_INACTIVE confirm primitive. If an IPSP receives an ASP Inactive Ack without having sent an ASP Inactive message, the IPSP should now consider itself as in the ASP- INACTIVE state. If the IPSP was previously in the ASP-ACTIVE state, the ASP should then initiate procedures to return itself to its previous state. When an IPSP sends an ASP Inactive message it starts timer T(ack). If the IPSP does not receive a response to an ASP Inactive message within T(ack), the IPSP MAY restart T(ack) and resend ASP Inactive messages until it receives an ASP Inactive Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in a M- ASP_Inactive confirm primitive carrying a negative indication. If when an IPSP sending an ASP Inactive message to a remote IPSP, no other remote IPSPs in the Application Server are in the state ASP- ACTIVE, the IPSP sending the ASP Inactive message MUST send a Notify message ("AS-Pending") to all of the remote IPSPs in the AS which are in the state ASP-INACTIVE. The IPSP SHOULD also start buffering the messages directed to that AS for T(r) seconds, after which messages MAY be discarded. T(r) is configurable by the network operator. If the IPSP receives an ASP Active message from a remote IPSP in the AS before expiry of T(r), the buffered traffic is directed to that remote IPSP and the timer is cancelled. If T(r) expires, the AS is moved to the AS-INACTIVE state. 4.3.4.4.1 Practical Considerations (ASP Inactive) An interchange of ASP Inactive messages from each end is performed. This option gives the additional advantage of allowing the selection of a particular AS to be deactivated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion. Pastor, Schwarzbauer [Page 24] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 A simplification can apply for some cases. An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive or ASP Inactive Ack message has been received from it. This option does not follow the IPSP state transition diagram. Only two messages will be needed for completion. 4.3.4.5 Notify Procedures A Notify message reflecting a change in the AS state MUST be sent to all peer IPSPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed IPSP. At the peer IPSP, Layer Management is informed with an M- NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an IPSP failure or reception of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). In the case where a Notify message("AS-PENDING") message is sent by a IPSP that now has no peer IPSPs active to service the traffic, or where a Notify ("Insufficient ASP/IPSP resources active in AS") message is sent in the Loadshare or Broadcast mode, the Notify message does not explicitly compel the peer IPSP(s) receiving the message to become active. The IPSPs remain in control of what (and when) traffic action is taken. In the case where a Notify message does not contain a Routing Context parameter, the receiver must know, via configuration data, of which Application Servers the IPSP is a member and take the appropriate action in each AS. 4.3.4.6 Heartbeat Procedures The optional Heartbeat procedures MAY be used when operating over transport layers that do not have their own heartbeat mechanism for detecting loss of the transport association (i.e., other than SCTP). Either M3UA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer T(beat). Upon receiving a Heartbeat message, the M3UA peer MUST respond with a Heartbeat Ack message. If no Heartbeat Ack message (or any other M3UA message) is received from the M3UA peer within 2*T(beat), the remote M3UA peer is considered unavailable. Transmission of Heartbeat messages is stopped and the signalling process SHOULD attempt to reestablish communication if it is configured as the client for the disconnected M3UA peer. Pastor, Schwarzbauer [Page 25] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 The Heartbeat message may optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Heartbeat Ack message. The sender, upon examining the contents of the returned Heartbeat Ack message, MAY choose to consider the remote M3UA peer as unavailable. The contents/format of the Heartbeat Data parameter is implementation-dependent and only of local interest to the original sender. The contents may be used, for example, to support a Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a timestamp mechanism (to evaluate delays). Note: Heartbeat related events are not shown in Figure 4 "IPSP state transition diagram". 4.4 Routing Key Management Procedures [Optional] 4.4.1 Registration An IPSP MAY dynamically register with a peer IPSP as an IPSP within an Application Server using the REG REQ message. A Routing Key parameter in the REG REQ message specifies the parameters associated with the Routing Key. The peer IPSP examines the contents of the received Routing Key parameter and compares it with the currently provisioned Routing Keys. If the received Routing Key matches an existing IPSP Routing Key entry at the peer IPSP, and the IPSP is not currently included in the list of IPSPs for the related Application Server, the peer IPSP MAY authorize the IPSP to be added to the AS. Or, if the Routing Key does not currently exist and the received Routing Key data is valid and unique, a peer IPSP supporting dynamic configuration MAY authorize the creation of a new Routing Key and related Application Server and add the IPSP to the new AS. In either case, the peer IPSP returns a Registration Response message to the IPSP, containing the same Local-RK-Identifier as provided in the initial request, and a Registration Result "Successfully Registered". A unique Routing Context value assigned to the peer IPSP Routing Key is included. The method of Routing Context value assignment at the peer IPSP is implementation dependent but must be guaranteed to be unique for each Application Server or Routing Key supported by the peer IPSP. If an IPSP does not support the registration procedure, upon a REG REQ message from a peer IPSP, the IPSP returns an Error message to the peer IPSP, with an error code of "Unsupported Message Type". If an IPSP determines that the received Routing Key data included in a REG REQ is invalid, or contains invalid parameter values, the peer IPSP returns a Registration Response message to the peer IPSP, containing a Registration Result "Error - Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network Appearance" as appropriate. Pastor, Schwarzbauer [Page 26] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 If an IPSP determines that a unique Routing Key cannot be created upon the reception of a REG REQ message, the IPSP returns a Registration Response message to the peer IPSP, with a Registration Status of "Error - "Cannot Support Unique Routing". An outcoming signalling message sent by the local application to a peer IPSP should not match against more than one Routing Key. If an IPSP does not authorize an otherwise valid registration request from a peer IPSP, the IPSP returns a REG RSP message to the peer IPSP containing the Registration Result "Error - Permission Denied". If an IPSP determines that a received Routing Key does not currently exist and the IPSP does not support dynamic configuration, the IPSP returns a Registration Response message to the peer IPSP, containing a Registration Result "Error - Routing Key not Currently Provisioned". If an IPSP determines that a received Routing Key does not currently exist and the IPSP supports dynamic configuration but does not have the capacity to add new Routing Key and Application Server entries, the IPSP returns a Registration Response message to the peer IPSP, containing a Registration Result "Error - Insufficient Resources". If an IPSP determines that one or more of the Routing Key parameters are not supported for the purpose of creating new Routing Key entries, the IPSP returns a Registration Response message to the remote IPSP, containing a Registration Result "Error - Unsupported RK parameter field". This result MAY be used if, for example, the IPSP does not support RK Circuit Range Lists in a Routing Key because the IPSP does not support ISUP traffic, or does not provide CIC range granularity. A Registration Response "Error - Unsupported Traffic Handling Mode" is returned if the Routing Key in the REG REQ contains an Traffic Handling Mode that is inconsistent with the presently configured mode for the matching Application Server. An IPSP MAY register multiple Routing Keys at once by including a number of Routing Key parameters in a single REG REQ message. The peer IPSP MAY respond to each registration request in a single REG RSP message, indicating the success or failure result for each Routing Key in a separate Registration Result parameter. Alternatively the peer IPSP MAY respond with multiple REG RSP messages, each with one or more Registration Result parameters. The IPSP uses the Local-RK-Identifier parameter to correlate the requests with the responses. Pastor, Schwarzbauer [Page 27] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 4.4.2 Deregistration An IPSP MAY dynamically deregister with a peer IPSP as an IPSP within an Application Server using the DEREG REQ message. A Routing Context parameter in the DEREG REQ message specifies which Routing Keys to deregister. An IPSP SHOULD move to the ASP-INACTIVE state for an Application Server before attempting to deregister the Routing Key (i.e., deregister after receiving an ASP Inactive Ack). Also, an IPSP SHOULD deregister from all Application Servers that it is a member before attempting to move to the ASP-Down state. The IPSP receiving the DEREG REQ message examines the contents of the received Routing Context parameter and validates that the peer IPSP is currently registered in the Application Server(s) related to the included Routing Context(s). If validated, the peer IPSP is deregistered as an IPSP in the related Application Server. The deregistration procedure does not necessarily imply the deletion of Routing Key and Application Server configuration data at the IPSP. Other IPSPs may continue to be associated with that Application Server, in which case the Routing Key data SHOULD NOT be deleted. If a Deregistration results in no more remote IPSPs registered in an Application Server, an IPSP MAY delete the Routing Key data. An IPSP acknowledges the deregistration request by returning a DEREG RSP message to the requesting IPSP. The result of the deregistration is found in the Deregistration Result parameter, indicating success or failure with cause. An IPSP MAY deregister multiple Routing Contexts at once by including a number of Routing Contexts in a single DEREG REQ message. The peer IPSP MAY respond to each deregistration request in a single DEREG RSP message, indicating the success or failure result for each Routing Context in a separate Deregistration Result parameter. 5. Examples of M3UA Procedures for IPSP The IPSPs are named as IPSP-X[Z][n] where: - X: the AS name, in this section it is represented by a capital letter. - Z: other optional AS names whenever the IPSP serve to more than one AS. - n: an optional number used when it is necessary to differenciate amongst several IPSPs that serve the same AS. The first section deals with the establishment of connections between IPSPs. It starts with the simple case of one IPSP per AS and with no registration. The optional registration procedure is added in the next example. In the third example the IPSP serves to more than one Pastor, Schwarzbauer [Page 28] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 AS. Next examples show the extension to configurations with two IPSPs per AS, using loadsharing and override traffic mode types. The last example extends the explanation to three IPSPs serving one AS with the loadsharing traffic mode type to complete the whole picture. In this example section only the messages regarding to one side are shown. Where the double exchange method is used to establish/withdraw the connection, the same messages and rules will apply to the other end. The second section shows failover examples for override and loadsharing traffic mode types. The third section explains the withdrawing of the communication for the simplest case shown in the first section. The extension to more complicated scenarios is easily inferred. As in section one, only the messages from one end are shown; to complete the double exchange method the same messages need to be exchanged from the other end. Finally, a complete example includig all the amin messages is shown for double and simple exchange methods using a very simple scenario. 5.1 Establishment of Association and Traffic between IPSPs These scenarios show the example M3UA message flows for the establishment of traffic between two IPSPs. In all cases it is assumed that the SCTP association is already set up. 5.1.1 Single IPSP in a remote Application Server ("1+0" sparing) These scenarios show the example M3UA message flows for the establishment of traffic between two IPSPs, where only one ASP/IPSP is configured within an AS/IPS (no backup). Pastor, Schwarzbauer [Page 29] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 5.1.1.1 Single IPSP in an Application Server ("1+0" sparing), No Registration IPSP-A IPSP-B | | |<-------------ASP Up------------| |-----------ASP Up Ack---------->| | | |<------- ASP Active(RCn)--------| RC: Routing Context |-----ASP Active Ack (RCn)------>| (optional) | | Note: If the ASP Active message contains an optional Routing Context parameter, The ASP Active message only applies for the specified RC value(s). For an unknown RC value, the IPSP-A responds with an Error message. 5.1.1.2 Single IPSP in remote Application Server ("1+0" sparing), Dynamic Registration This scenario is the same as for 5.1.1.1 but with the optional exchange of registration information. In this case the Registration is accepted by the IPSP. IPSP-A IPSP-B | | |<------------ASP Up-------------| |----------ASP Up Ack----------->| | | |<----REGISTER REQ(LRC-B,RK-B)---| LRC: Local Routing | | Context |----REGISTER RESP(LRC-B,RC-B)-->| RK: Routing Key | | RC: Routing Context | | |<------- ASP Active(RC-B)-------| |-----ASP Active Ack (RC-B)----->| | | Note: In the case of an unsuccessful registration attempt (e.g., invalid RK-B), the Register Response message will contain an unsuccessful indication and the IPSP will not subsequently send an ASP Active message. Pastor, Schwarzbauer [Page 30] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 5.1.1.3 Single remote IPSP in Multiple Application Servers (each with "1+0" sparing), Dynamic Registration (Case 1 - Multiple Registration Requests) IPSP-A IPSP-BC | | |<------------ASP Up-------------| |----------ASP Up Ack----------->| | | |<----REGISTER REQ(LRC-B,RK-B)---| LRC: Local Routing | | Context |----REGISTER RESP(LRC-B,RC-B)-->| RK: Routing Key | | RC: Routing Context | | |<------- ASP Active(RC-B)-------| |-----ASP Active Ack (RC-B)----->| | | | | |<----REGISTER REQ(LRC-C,RK-C)---| | | |----REGISTER RESP(LRC-C,RC-C)-->| | | | | |<------- ASP Active(RC-C)-------| |-----ASP Active Ack (RC-C)----->| | | Note: In the case of an unsuccessful registration attempt (e.g., invalid RK-C), the Register Response message will contain an unsuccessful indication and the IPSP will not subsequently send an ASP Active message. Each LRC/RK pair registration is considered independently. It is not necessary to follow a Registration Request/Response message pair with an ASP Active message before sending the next Registration Request. The ASP Active message can be sent at any time after the related successful registration. Pastor, Schwarzbauer [Page 31] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 5.1.1.4 Single IPSP in Multiple Application Servers (each with "1+0" sparing), Dynamic Registration (Case 2 - Single Registration Request) IPSP-A IPSP-BC | | |<------------ASP Up-------------| |----------ASP Up Ack----------->| | | |<---REGISTER REQ({LRC-B,RK-B},--| | {LRC-C,RK-C}) | | | |---REGISTER RESP({LRC-B,RC-B},->| | (LRC-C,RC-C}) | | | |<------- ASP Active(RC-B)-------| |-----ASP Active Ack (RC-B)----->| | | | | |<------- ASP Active(RC-C)-------| |-----ASP Active Ack (RC-C)----->| | | Note: In the case of an unsuccessful registration attempt (e.g., Invalid RK-C), the Register Response message will contain an unsuccessful indication and the IPSP will not subsequently send an ASP Active message. Each LRC/RK pair registration is considered independently. The ASP Active message can be sent at any time after the related successful registration, and may have more than one RC. 5.1.2 Two IPSPs in Application Server ("1+1" sparing) This scenario shows the example M3UA message flows for the establishment of traffic between an IPSP and two IPSPs in the same AS, where IPSP-B1 is configured to be in the ASP-ACTIVE state and IPSP-B2 is to be a "backup" in the event of communication failure or the withdrawal from service of IPSP1. IPSP2 may act as a hot, warm, or cold backup depending on the extent to which IPSP1 and IPSP2 share call/transaction state or can communicate call state under failure/withdrawal events. The example message flow is the same whether the ASP Active messages indicate "Override", "Loadshare" or "Broadcast" mode, although typically this example would use an Override mode. Pastor, Schwarzbauer [Page 32] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 IPSP-A IPSP-B1 IPSP-B2 | | | |<--------ASP Up----------| | |-------ASP Up Ack------->| | | | | |<-----------------------------ASP Up----------------| |-----------------------------ASP Up Ack------------>| | | | | | | |<-------ASP Active-------| | |------ASP Active Ack---->| | | | | 5.1.3 Two IPSPs in an Application Server ("1+1" sparing, loadsharing case) This scenario shows a similar case to Section 5.1.2 but where the two IPSPs are brought to the state ASP-ACTIVE and subsequently loadshare the traffic. In this case, one IPSP is sufficient to handle the total traffic load. IPSP-A IPSP-B1 IPSP-B2 | | | |<---------ASP Up---------| | |--------ASP Up Ack------>| | | | | |<------------------------------ASP Up---------------| |-----------------------------ASP Up Ack------------>| | | | | | | |<--ASP Active (Ldshr)----| | |-----ASP-Active Ack----->| | | | | |----------------------------NOTIFY (AS-ACTIVE------>| | | | |<----------------------------ASP Active (Ldshr)-----| |-------------------------------ASP Active Ack------>| | | | 5.1.4 Three IPSPs in an Application Server ("n+k" sparing, loadsharing case) This scenario shows the example M3UA message flows for the establishment of traffic between an IPSP and three IPSPs in the same AS, where two of the IPSPs are brought to the state ASP-ACTIVE and subsequently share the load. In this case, a minimum of two IPSPs are required to handle the total traffic load (2+1 sparing). Pastor, Schwarzbauer [Page 33] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 IPSP-A IPSP-B1 IPSP-B2 IPSP-B3 | | | | |<------ASP Up-------| | | |-----ASP Up Ack---->| | | | | | | |<--------------------------ASP Up-------| | |-------------------------ASP Up Ack---->| | | | | | |<---------------------------------------------ASP Up--------| |---------------------------------------------ASP Up Ack---->| | | | | | | | | |<--ASP Act (Ldshr)--| | | |----ASP Act Ack---->| | | | | | | |----------Notify (AS-ACTIVE)----------->| | |-----------------------Notify (AS-ACTIVE)------------------>| | | | | |<--------------------ASP Act. (Ldshr)---| | |-----------------------ASP Act Ack----->| | | | | | 5.2 IPSP Traffic Failover Examples 5.2.1 (1+1 Sparing, Withdrawal of IPSP, Backup Override) Following on from the example in Section 5.1.2, and IPSP-B1 withdraws from service: IPSP-A IPSP-B1 IPSP-B2 | | | |<-----ASP Inactive-------| | |----ASP Inactive Ack---->| | |------------------------NTFY(AS-Pending)----------->| | | | |<------------------------------ ASP Active----------| |------------------------------ASP Active Ack------->| | | Note: If the IPSP-A M3UA layer detects the loss of the M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., between IPSP-A and IPSP-B1) would not occur. 5.2.2 (1+1 Sparing, Backup Override) Following on from the example in Section 5.1.2, IPSP-B2 wishes to Override IPSP-B1 and take over the traffic: Pastor, Schwarzbauer [Page 34] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 IPSP-A IPSP-B1 IPSP-B2 | | | |<------------------------------ ASP Active----------| |-------------------------------ASP Active Ack------>| |----NTFY(Alt ASP-Act)--->| | | | 5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of IPSP) Following on from the example in Section 5.1.4, and IPSP-B1 withdraws from service: IPSP-A IPSP-B1 IPSP-B2 IPSP-B3 | | | | |<----ASP Inact.-----| | | |---ASP Inact Ack--->| | | | | | | |--------------------------------NTFY(Ins. IPSPs)----------->| | | | | |<-----------------------------------------ASP Act (Ldshr)---| |-------------------------------------------ASP Act (Ack)--->| | | | | For the Notify message to be sent, IPSP-A maintains knowledge of the minimum IPSP-A resources required (e.g., if the IPSP-A knows that "n+k" = "2+1" for a Loadshare AS and "n" currently equals "1"). Note: If IPSP-A detects loss of the IPSP-B1 M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., IPSP-A <û> IPSP-B1) would not occur. 5.3 Normal Withdrawal of an IPSP from an Application Server and Teardown of an Association An IPSP which is now confirmed in the state ASP-INACTIVE (i.e., the IPSP has received an ASP Inactive Ack message) may now proceed to the ASP-DOWN state, if it is to be removed from service. Following on from Section 5.2.1 or 5.2.3, where IPSP-B has moved to the "Inactive" state: IPSP-A IPSP-B | | |<-----ASP Inactive (RC-B)------| RC: Routing Context |----ASP Inactive Ack (RC-B)--->| | | |<-----DEREGISTER REQ(RC-B)-----| See Notes | | |--DEREGISTER RESP(LRC-B,RC-B)->| Pastor, Schwarzbauer [Page 35] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 | | | | | | |<-----------ASP Down-----------| |---------ASP Down Ack--------->| | | Note: The Deregistration procedure MUST be used if the IPSP-B previously used the Registration procedures for configuration within the Application Server. ASP Inactive and Deregister messages exchanges may contain multiple Routing Contexts. IPSP-B SHOULD be in the ASP-INACTIVE state and SHOULD have deregistered in all its Routing Contexts before attempting to move to the ASP-DOWN state. 5.4 M3UA/MTP3-User Boundary Examples for an IPSP This section describes the primitive mapping between the MTP3 User and the M3UA layer at an IPSP. 5.4.1 Support for MTP-TRANSFER Primitives at the IPSP When the MTP3-User on the IPSP has data to send to a remote MTP3- User, it uses the MTP-TRANSFER request primitive. The M3UA layer at the IPSP will do the following when it receives an MTP-TRANSFER request primitive from the M3UA user: - Determine the correct IPSP; - Determine the correct association to the chosen IPSP; - Determine the correct stream in the association (e.g., based on SLS); - Determine whether to complete the optional fields of the DATA message; - Map the MTP-TRANSFER request primitive into the Protocol Data field of a DATA message; - Send the DATA message to the remote M3UA peer at the remote IPSP, over the SCTP association. IPSP-A IPSP-B | | |<-----DATA Message-------|<--MTP-TRANSFER req. | | When the M3UA layer on the IPSP receives a DATA message from the M3UA peer at the remote IPSP, it will do the following: Pastor, Schwarzbauer [Page 36] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 - Evaluate the optional fields of the DATA message, if present; - Map the Protocol Data field of a DATA message into the MTP- TRANSFER indication primitive; - Pass the MTP-TRANSFER indication primitive to the user part. In case of multiple user parts, the optional fields of the Data message are used to determine the concerned user part. IPSP-A IPSP-B | | |------Data Message------>|-->MTP-Transfer ind. | | 5.5 Complete examples for IPSP communication. These scenarios show a basic example for IPSP communication for the three phases of the connection (establishment, data exchange, disconnection) using the simplest scenario. It is assumed that the SCTP association is already set up. Both single exchange and double exchange behavior are included for illustrative purposes. 5.5.1 Single exchange IPSP-A IPSP-B | | |-------------ASP Up------------>| |<----------ASP Up Ack-----------| | | |<------- ASP Active(RC-B)-------| RC: Routing Context |-----ASP Active Ack (RC-B)----->| (optional) | | | | |<========= DATA (RC-B) =======>| | | |<-----ASP Inactive (RC-B)-------| RC: Routing Context |----ASP Inactive Ack (RC-B)---->| (optional) | | |<-----------ASP Down------------| |---------ASP Down Ack---------->| | | Routing Context are previously agreed to be the same in both directions. 5.5.2 Double exchange Pastor, Schwarzbauer [Page 37] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 IPSP-A IPSP-B | | |<-------------ASP Up------------| |-----------ASP Up Ack---------->| | | |-------------ASP Up------------>| (optional) |<----------ASP Up Ack-----------| (optional) | | |<------- ASP Active(RC-B)-------| RC: Routing Context |-----ASP Active Ack (RC-B)----->| (optional) | | |------- ASP Active(RC-A)------->| RC: Routing Context |<-----ASP Active Ack (RC-A)-----| (optional) | | |<========= DATA (RC-A) ========| |========== DATA (RC-B) =======>| | | |<-----ASP Inactive (RC-B)-------| RC: Routing Context |----ASP Inactive Ack (RC-B)---->| | | |------ASP Inactive (RC-A)------>| RC: Routing Context |<----ASP Inactive Ack (RC-A)----| | | |<-----------ASP Down------------| |---------ASP Down Ack---------->| | | |------------ASP Down----------->| (optional) |<--------ASP Down Ack-----------| (optional) | | 6. Acknowledgements The authors would like to thank Ken Morneault, Lyndon Ong and Greg Sidebottom for their valuable comments. 7. Authors' Addresses Javier Pastor-Balbas Ericsson Espana S.A. Ombu 3 28045 Madrid Spain Phone: +34-91-339-3819 Email: j.javier.pastor@ericsson.com HannsJuergen Schwarzbauer SIEMENS AG Pastor, Schwarzbauer [Page 38] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 Hofmannstr. 51 81359 Munich Germany Phone: +49-89-722-24236 EMail: HannsJuergen.Schwarzbauer@icn.siemens.de 8. References [RFC-M3UA] "MTP3 User Adaptation Layer" 9. Open Issues This are the open issues that have been detected for the moment: @ Concept of "connection state" for double exchange. When the connection is ready to exchange DATA messages. Unidirectional connections allowed? Personal opinion: no. @ Compatibility of single exchange with double exchange Annex A: Example or RK use within IPSP communication AS3 wants to send traffic to AS1 and AS2. So, it needs two Routing Keys. AS1/AS2 needs to be able to send traffic back to AS3 so they need one Routing Key. AS1 AS2 AS3 +--------------+ +---------------+ +--------------+ | IPSP1 IPSP2 | | IPSP1 IPSP2 | | IPSP1 IPSP2 | +--------------+ +---------------+ +--------------+ | | | | | -------------------- | | | ---------------------------------------------- AS1: Routing Key 1 = AS3 AS2: Routing Key 1 = AS3 AS3: Routing Key 1 = AS1 Routing Key 2 = AS2 Note: lines show logical connections between ASes. Pastor, Schwarzbauer [Page 39] INTERNET-DRAFT M3UA IPSP Communication May 20, 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Pastor, Schwarzbauer [Page 40]