draft-ietf-sigtran-m3ua-implementors-guide-00.txt   draft-ietf-sigtran-m3ua-implementors-guide-01.txt 
Network Working Group Javier Pastor Network Working Group Javier Pastor
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: September 2002 Expires: December 2002
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
March, 2002 June, 2002
M3UA ImplementorĘs Guide M3UA ImplementorĘs Guide
<draft-ietf-sigtran-m3ua-implementors-guide-00.txt> <draft-ietf-sigtran-m3ua-implementors-guide-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 9 skipping to change at page 2, line 9
editorial or technical nature. This document may be thought of as a editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of M3UA to companion document to be used in the implementation of M3UA to
clarify errors in the original M3UA document. This document updates clarify errors in the original M3UA document. This document updates
RFCxxxx and text within this document supersedes the text found in RFCxxxx and text within this document supersedes the text found in
RFCxxxx RFCxxxx
TABLE OF CONTENTS TABLE OF CONTENTS
1.Introduction........................................................3 1.Introduction........................................................3
2.Conventions.........................................................3 2.Conventions.........................................................3
3.Corrections to RFC-M3UA.............................................3 3.Corrections to RFC-M3UA.............................................3
3.1 Parameter Containing Subparameters with Padding Bytes..............3 3.1 Parameter Containing Subparameters with Padding Bytes.............3
3.2 Dynamic Registration Not Supported.................................4 3.2 Dynamic Registration Not Supported................................4
3.3 Contents of User Protocol Data.....................................6 3.3 Contents of User Protocol Data....................................6
3.4 NIF Not Available on SGP...........................................7 3.4 NIF Not Available on SGP..........................................7
3.4.1 Description of the problem.......................................7 3.5 Scope of Network Appearance.......................................8
3.4.2 Text changes to the document.....................................7 3.6 Semi-optional RC parameter........................................9
3.4.3 Solution description.............................................8 3.7 Receiving REG for a RK already registered........................12
3.5 Scope of Network Appearance........................................8 3.8 OPC list in the Registration Request Message.....................13
3.6 Semi-optional RC parameter.........................................9 3.9 Auditing procedure and congestion state..........................13
3.7 Receiving REG for a RK already registered.........................10 3.10 Response to an ASPIA message....................................16
3.8 OPC list in the Registration Request Message......................11 3.11 INFO and DIAG parameter length..................................17
3.9 Auditing procedure and congestion state...........................12 3.12 IPSP stuff......................................................18
3.10 Response to an ASPIA message.....................................14 3.13 Messages and Streams............................................24
3.11 INFO and DIAG parameter length...................................15 3.14 ASP Id for IPSP communication...................................24
4.Acknowledgements...................................................17 3.15 n+k redundancy..................................................26
5.Authors' Addresses.................................................17 4.Acknowledgements...................................................30
6.References.........................................................17 5.Authors' Addresses.................................................30
7.Changes Control....................................................18 6.References.........................................................31
7.Changes Control....................................................32
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
March 2002 for the MTP3 User Adaptation Layer (M3UA) [RFCxxxx]. These March 2002 for the MTP3 User Adaptation Layer (M3UA) [RFCxxxx]. These
defects may be of an editorial or technical nature. This document may defects may be of an editorial or technical nature. This document may
be thought of as a companion document to be used in the be thought of as a companion document to be used in the
implementation of M3UA to clarify errors in the original M3UA implementation of M3UA to clarify errors in the original M3UA
document. This document updates RFCxxxx and text within this document. This document updates RFCxxxx and text within this
document, where noted, supersedes the text found in RFCxxxx. Each document, where noted, supersedes the text found in RFCxxxx. Each
error will be detailed within this document in the form of: error will be detailed within this document in the form of:
skipping to change at page 7, line 37 skipping to change at page 7, line 37
The text is not clear about how the SGP/SG should handle the case of The text is not clear about how the SGP/SG should handle the case of
the NIF becoming unavailable on a SGP or all SGPs (SG). the NIF becoming unavailable on a SGP or all SGPs (SG).
3.4.2 Text changes to the document 3.4.2 Text changes to the document
--------- ---------
Old text: (None) Old text: (None)
--------- ---------
- None.
--------- ---------
New text: (Section 4.7) New text: (Section 4.7)
--------- ---------
If the SG (all the SGPs) is isolated from the NIF, then all the users If the SG (all the SGPs) is isolated from the NIF, then all the users
are isolated from the SS7 network. A DUNA(*) message MUST be sent. are isolated from the SS7 network. An ASP Inactive Ack message MUST
be sent from the SGPs to all the ASPs.
If only one SGP in the SG is isolated entirely from the NIF, the SGP If only one SGP in the SG is isolated entirely from the NIF, the SGP
SHOULD abort its associations. An alternative would be for the SGP to SHOULD abort its associations. An alternative would be for the SGP to
send ASP Down Ack. send ASP Down Ack.
If one or more SGP suffer a partial failure (where aborting the If one or more SGP suffer a partial failure (where aborting the
association(s) would cause all active AS(es) to fail), then the SGP association(s) would cause all active AS(es) to fail), then the SGP
MUST send ASP Inactive Acks for the affected AS(es). This is the MUST send ASP Inactive Ack messages for the affected AS(es). This is
case where an SGP can continue to service one or more active AS(es), the case where an SGP can continue to service one or more active
but due to a partial failure it is unable to service one or more AS(es), but due to a partial failure it is unable to service one or
active AS(es). more active AS(es).
3.4.3 Solution description 3.4.3 Solution description
The addition of this text specifies the SGP/SG behavoir for the The addition of this text specifies the SGP/SG behavoir for the
different scenarios of the NIF becoming unavailable on the SGP/SG. different scenarios of the NIF becoming unavailable on the SGP/SG.
3.5 Scope of Network Appearance 3.5 Scope of Network Appearance
3.5.1 Description of the problem 3.5.1 Description of the problem
skipping to change at page 10, line 35 skipping to change at page 10, line 35
3.3.1 Payload Data Message (DATA) 3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is The DATA message contains the SS7 MTP3-User protocol data, which is
an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
The DATA message contains the following variable length parameters: The DATA message contains the following variable length parameters:
Network Appearance Optional Network Appearance Optional
Routing Context Semi-Optional Routing Context Semi-Optional
Protocol Data Mandatory Protocol Data Mandatory
Correlation Id Optional Correlation Id Optional
---------
Old text: (Section 3.4.1)
---------
Routing Context Optional
---------
New text: (Section 3.4.1)
---------
Routing Context Semi-Optional
---------
Old text: (Section 3.4.2)
---------
Routing Context Optional
---------
New text: (Section 3.4.2)
---------
Routing Context Semi-Optional
---------
Old text: (Section 3.4.3)
---------
Routing Context Optional
---------
New text: (Section 3.4.3)
---------
Routing Context Semi-Optional
---------
Old text: (Section 3.4.4)
---------
Routing Context Optional
---------
New text: (Section 3.4.4)
---------
Routing Context Semi-Optional
---------
Old text: (Section 3.4.5)
---------
Routing Context Optional
---------
New text: (Section 3.4.5)
---------
Routing Context Semi-Optional
---------
Old text: (Section 3.4.6)
---------
Routing Context Optional
---------
New text: (Section 3.4.6)
---------
Routing Context Semi-Optional
3.6.3 Solution description 3.6.3 Solution description
Stating that the parameter is semi-optional, implies that it not Stating that the parameter is semi-optional, implies that it not
either optional or mandatory. In the parameter description the text either optional or mandatory. In the parameter description the text
explains when it is mandatory and when optional. explains when it is mandatory and when optional.
3.7 Receiving REG for a RK already registered 3.7 Receiving REG for a RK already registered
3.7.1 Description of the problem 3.7.1 Description of the problem
The RFC does not clearly specify what to do in this case. The RFC does not clearly specify what to do in this case.
3.7.2 Text changes to the document 3.7.2 Text changes to the document
--------- ---------
Old text: (Section 4.4.1) Old text: (Section 4.4.1)
--------- ---------
- None.
-------- --------
New text: (Section 4.4.1) New text: (Section 4.4.1)
--------- ---------
If the SG determines that the received RK was already registered, the If the SG determines that the received RK was already registered, the
SGP returns a Registration Response message to the ASP, containing a SGP returns a Registration Response message to the ASP, containing a
Registration Result "Error - Cannot Support Unique Routing". Registration Result "Error - Cannot Support Unique Routing".
3.7.3 Solution description 3.7.3 Solution description
skipping to change at page 13, line 21 skipping to change at page 15, line 4
Old text: (Section 5.4) Old text: (Section 5.4)
--------- ---------
5.4 M3UA/MTP3-User Boundary Examples 5.4 M3UA/MTP3-User Boundary Examples
--------- ---------
New text: (Section 5.4, 5.5) New text: (Section 5.4, 5.5)
--------- ---------
5.4 Auditing examples 5.4 Auditing examples
5.4.1 SG State: Uncongested / Unavailable 5.4.1 SG State: Uncongested / Unavailable
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------ SCON(0) -------- | | <------ SCON(0) -------- |
| <------- DAVA ---------- | | <------- DUNA ---------- |
5.4.2 SG state: Congested (Congestion Level=2) / Available 5.4.2 SG state: Congested (Congestion Level=2) / Available
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------ SCON(2) -------- | | <------ SCON(2) -------- |
| <------- DAVA ---------- | | <------- DAVA ---------- |
skipping to change at page 15, line 25 skipping to change at page 17, line 4
When an ASP wishes to withdraw from receiving traffic within an AS,or When an ASP wishes to withdraw from receiving traffic within an AS,or
the ASP wants to initiate the process of activation, the ASP sends an the ASP wants to initiate the process of activation, the ASP sends an
ASP Inactive message to the SGP or IPSP. ASP Inactive message to the SGP or IPSP.
An ASP Inactive message MUST be always responded by the peer An ASP Inactive message MUST be always responded by the peer
(although other messages may be sent in the middle): (although other messages may be sent in the middle):
- If the corresponding RK is registered (statically or - If the corresponding RK is registered (statically or
dynamically), the peer should respond with an ASP Inactive Ack dynamically), the peer should respond with an ASP Inactive Ack
message. message.
- If the RK is not registered, or the RC information is not valid, - If the RK is not registered, or the RC information is not valid,
the peer must respond with an ERROR message with Error Code = the peer must respond with an ERROR message with Error Code =
"Invalid Routing Context". "Invalid Routing Context".
- If the RC is missing and its specification is needed according - If the RC is missing and its specification is needed according
to the used configuration, the peer must respond with an ERROR to the used configuration, the peer must respond with an ERROR
message with Error Code = "Missing Parameter". message with Error Code = "No Configured AS for ASP".
The action of sending the ASP Inactive message MAY be initiated at The action of sending the ASP Inactive message MAY be initiated at
the ASP by an M-ASP_INACTIVE request primitive from Layer Management the ASP by an M-ASP_INACTIVE request primitive from Layer Management
or MAY be initiated automatically by an M3UA management function. In or MAY be initiated automatically by an M3UA management function. In
the case where an ASP is processing the traffic for more than one the case where an ASP is processing the traffic for more than one
Application Server across a common SCTP association, the ASP Inactive Application Server across a common SCTP association, the ASP Inactive
message contains one or more Routing Contexts to indicate for which message contains one or more Routing Contexts to indicate for which
Application Servers the ASP Inactive message applies. Application Servers the ASP Inactive message applies.
3.10.3 Solution description 3.10.3 Solution description
skipping to change at page 17, line 13 skipping to change at page 18, line 41
identification of the error condition. The Diagnostic information identification of the error condition. The Diagnostic information
SHOULD contain the offending message. A Diagnostic Information with a SHOULD contain the offending message. A Diagnostic Information with a
zero length parameter is not considered as an error (this means that zero length parameter is not considered as an error (this means that
the Length field in the TLV will be set to 4). the Length field in the TLV will be set to 4).
3.11.3 Solution description 3.11.3 Solution description
It has been explicitly included the fact that a parameter with legth It has been explicitly included the fact that a parameter with legth
zero is allowed. zero is allowed.
3.12 IPSP stuff
3.12.1 Description of the problem
At the 2nd M3UA Plugtest several concerns were raised about the non-
interoperability of the two different IPSP exchanges defined in M3UA.
3.12.2 Text changes to the document
---------
Old text: (Section 4.3.1)
---------
Figure 4: ASP State Transition Diagram, per AS
+--------------+
| |
+----------------------| ASP-ACTIVE |
| Other +-------| |
| ASP 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 |
| |
+--------------+
---------
New text: (Section 4.3.1)
---------
The figure below shows the transitions for the ASP and IPSP cases.
Figure 5: IPSP State Transition Diagram, per AS
+--------------+
| |
+----------------------| ASP-ACTIVE |
| Other +-------| |
| IPSP in AS | +--------------+
| Overrides | ^ |
| | ASPAC/ | | ASPIA/
| |[ASPAC-Ack]| | [ASPIA-Ack]
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| | |
| +--------------+
| ^ |
ASPDN/ | | | ASPDN /
[ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]
SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/
SCTP RI | | | SCTP RI
| | v
| +--------------+
| | |
+--------------------->| ASP-DOWN |
| |
+--------------+
The transitions in brackets are just valid for the IPSP communication
while the rest are valid for both ASPs and IPSPs.
---------
Old text: (Section 4.3.4.1.2)
---------
Alternatively, an interchange of ASP Up messages from each end can be
performed. This option follows the ASP state transition diagram. It
would need four messages for completion.
---------
New text: (Section 4.3.4.1.2)
---------
None.
---------
Old text: (Section 4.3.4.3.1)
---------
Alternatively, an interchange of ASP Active messages from each end
can be performed. This option follows the ASP state transition
diagram and gives the additional advantage of selecting a particular
AS to be activated from each end. It is especially useful when an
IPSP is serving more than one AS. It would need four messages for
completion.
---------
New text: (Section 4.3.4.3.1)
---------
None.
---------
Old text: (Section 4.3.4.4.1)
---------
Alternatively, an interchange of ASP Inactive messages from each end
can be performed. This option follows the ASP state transition
diagram and gives the additional advantage of selecting 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.
---------
New text: (Section 4.3.4.4.1)
---------
None.
---------
Old text: (Section 4.4.3)
---------
The Registration/Deregistration procedures work in the IPSP cases in
the same way as in AS-SG cases. An IPSP may register an RK in the
remote IPSP. An IPSP is responsible for deregistering the RKs that
it has registered.
---------
New text: (Section 4.4.3)
---------
The Registration/Deregistration procedures work in the IPSP cases in
the same way as in AS-SG cases. An IPSP may register an RK in the
remote IPSP. An IPSP is responsible for deregistering the RKs that
it has registered.
It MAY be used one common RK for both IPSP participating in the
communication using the Signaling Point Code granularity. It would
basically consist of <OPC,DPC>.
In the case of RC use, RCs SHOULD be previously agreed between both
peers.
---------
Old text: (Section 5.5)
---------
These scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection). 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(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context are previously agreed to be the same in both
directions.
5.5.2 Double exchange:
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
In this approach, only one single exchange of ASP Up message can be
considered as enough since the response by the other peer can be
considered as a notice that it is in ASP_UP state.
For the same reason, only one ASP Down message is needed since once
that an IPSP receives ASP_Down ack message it is itself considered as
being in the ASP_Down state and not allowed to receive ASPSM
messages.
---------
New text: (Section 5.5)
---------
This scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection). It is assumed that the SCTP association is already
set up.
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context are previously agreed to be the same in both
directions.
3.12.3 Solution description
All the references to the "double exchange" (a.k.a. symmetric IPSP
method) has been removed. Modifications in the ASP state machine has
been done to include the IPSP model.
3.13 Messages and Streams
3.13.1 Description of the problem
The relation between messages and what stream to use in order to send
them is diffuse and spread all along the document.
3.13.2 Text changes to the document
---------
Old text: (Section 1.4.7)
---------
None.
---------
New text: (Section 1.4.7)
---------
The following rules MUST to be followed (see section 3.1.2):
1. DATA is never sent on stream 0.
2. ASPSM, MGMT, RKM should be sent on stream 0 (Other than BEAT and
BEAT ACK)
3. SSNM , ASPTM , BEAT and BEAT ACK can be sent on any stream.
3.13.3 Solution description
A clear specification of how messages should be sent is included in
the corresponding section.
3.14 ASP Id for IPSP communication
3.14.1 Description of the problem
When using the IPSP communication it is no way of dynamically
exchange the ASP Identifier in both directions.
3.14.2 Text changes to the document
---------
Old text: (Section 3.5.2)
---------
The ASP Up Ack message contains the following parameters:
INFO String (optional)
The format for ASP Up Ack message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------
New text: (Section 3.5.2)
---------
The ASP Up Ack message contains the following parameters:
ASP Identifier Optional
INFO String Optional
The format for ASP Up Ack message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter is specially useful for IPSP
communication. In that case the IPSP answering the ASP Up message MAY
include its own ASP Identifier value. For AS-SG communication this
parameter MUST NOT be used.
3.14.3 Solution Description
By including the optional ASP Identifier in ASP Up message this can
be achieved. In the AS-SG communication this optional parameter is
not needed
3.15 n+k redundancy
3.15.1 Description of the problem
The n+k redundancy is explained as a general model to use but there
is no reference in the AS state and sometimes it is not clear when to
use it.
3.15.2 Text changes to the document
---------
Old text: (Section 4.3.2)
---------
AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs 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 ASPs are in the ASP-
INACTIVE state, but none in the ASP-ACTIVE state). The recovery
timer T(r) is not running or has expired.
AS-ACTIVE: The Application Server is available and application
traffic is active. This state implies that at least one ASP is in
the ASP-ACTIVE state.
AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-
DOWN and it was the last remaining active ASP in the AS. A recovery
timer T(r) SHOULD be started and all incoming signalling messages
SHOULD be queued by the SGP. If an ASP 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 ASP.
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no
alternative, the SGP may stops queuing messages and discards all
previously queued messages. The AS will move to the AS-INACTIVE state
if at least one ASP is in ASP-INACTIVE state, otherwise it will move
to AS-DOWN state.
Figure 5 shows an example AS state machine for the case where the
AS/ASP data is preconfigured. For other cases where the AS/ASP
configuration data is created dynamically, there would be differences
in the state machine, especially at creation of the AS.
Figure 5: AS State Transition Diagram
+----------+ one ASP trans to ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP 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 ASP +-------------+
in ASP-INACTIVE state)
Tr = Recovery Timer
For example, where the AS/ASP configuration data is not created until
Registration of the first ASP, the AS-INACTIVE state is entered
directly upon the first successful REG REQ from an ASP. Another
example is where the AS/ASP configuration data is not created until
the first ASP successfully enters the ASP-ACTIVE state. In this case
the AS-ACTIVE state is entered directly.
---------
New text: (Section 4.3.2)
---------
AS-DOWN: The Application Server is unavailable. This state implies
that the number of ASPs being in ASP-INACTIVE or ASP-DOWN is less
than "n". 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. This implies that there are at least n ASPs in
either ASP-INACTIVE or ASP-ACTIVE but the total number of ASPs in
ASP-ACTIVE state has not reach n. The recovery timer T(r) is not
running or has expired.
AS-ACTIVE: The Application Server is available and application
traffic is active. This state implies that at least n ASPs are in
the ASP-ACTIVE state.
AS-PENDING: An active ASP has transitioned from ASP-ACTIVE to ASP-
INACTIVE or ASP-DOWN and it was the number n active ASP in the AS. A
recovery timer T(r) SHOULD be started and all incoming signalling
messages SHOULD be queued by the SGP. If an ASP 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 ASP.
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no
alternative, the SGP may stops queuing messages and discards all
previously queued messages. The AS will move to the AS-INACTIVE state
if at least the number of ASPs in either ASP-INACTIVE or ASP-ACTIVE
sum n, otherwise it will move to AS-DOWN state.
Figure 5 shows an example AS state machine for the case where the
AS/ASP data is preconfigured and a n+k redundancy model.
Figure 5: AS State Transition Diagram
+----------+ IA2AC +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<----------- | |
+----------+ \ +-------------+
^ | \ ^ |
| | IA2DN \ PN2IA | | AC2PN
| | \ | |
DN2IA | | \ PN2AC | |
| v \ | v
+----------+ \ +-------------+
| | ----------| |
| AS-DOWN | | AS-PENDING |
| | PN2DN | (queueing) |
| |<----------------------------| |
+----------+ +-------------+
DN2IA: One ASP moves to ASP-INACTIVE causing that n ASPs are in
either ASP-ACTIVE or ASP-INACTIVE states.
IA2DN: One ASP moves to ASP-DOWN causing that the number of ASPs in
either ASP-ACTIVE or ASP-INACTIVE drops below n.
IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the
ASP-ACTIVE state to be n.
AC2PN: one ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-DOWN
states, causing the number of ASPs in ASP-ACTIVE drop below n.
PN2AC: One ASP moves to ASP-ACTIVE causing the number of ASPs in the
ASP-ACTIVE state to be n.
PN2IA: T(r) Expiry, n or more ASPs are in either ASP-INACTIVE or ASP-
ACTIVE state and number of ASPs in ASP-ACTIVE state is less than n.
PN2DN: T(r) Expiry, the number of ASPs in either ASP-INACTIVE or ASP-
ACTIVE state is less than n.
For other cases where the AS/ASP configuration data is created
dynamically, there would be differences in the state machine,
especially at creation of the AS. For example, where the AS/ASP
configuration data is not created until Registration of the first
ASP, the AS-INACTIVE state is entered directly upon the nth
successful REG REQ from an ASP belonging to that AS. Another example
is where the AS/ASP configuration data is not created until the nth
ASP successfully enters the ASP-ACTIVE state. In this latter case
the AS-ACTIVE state is entered directly.
---------
Old text: (Section 4.3.4.3, for both loadsharing and broadcast)
---------
An SGP or IPSP, upon reception of an ASP Active message for the first
ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
active ASP until it determines that there are sufficient resources to
handle the expected load (e.g., until there are "n" ASPs in state
ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold
the Notify (AS-ACTIVE) until there are sufficient resources.
---------
New text: (Section 4.3.4.3, for both loadsharing and broadcast)
---------
An SGP or IPSP, upon reception of an ASP Active message for the first
ASP in a Loadshare AS, SHOULD NOT direct traffic to a newly active
ASP until it determines that there are sufficient resources to handle
the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE
in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify
(AS-ACTIVE) until there are sufficient resources.
3.15.3 Solution description
The AS state machine reflects the state changes as a function of the
"n" number from the n+k redundancy configuration. This solution is
compliance with the previous one: 1+0 model. The change from MAY to
SHOULD NOT makes it recommendable to send traffic only when the
require ASPs number are in ASP-ACTIVE state.
4. Acknowledgements 4. Acknowledgements
- The authors would like to thank Lyndon Ong, Tolga Asveren, Brian
Bidulock, Umesh Vats, Barry Nagelberg and many others for their
valuable comments and suggestions.
5. Authors' Addresses 5. Authors' Addresses
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Espana S.A. Ericsson Espana S.A.
Ombu 3 Ombu 3
28045 Madrid 28045 Madrid
Spain Spain
Phone: +34-91-339-3819 Phone: +34-91-339-3819
skipping to change at page 17, line 36 skipping to change at page 31, line 4
Email: j.javier.pastor@ericsson.com Email: j.javier.pastor@ericsson.com
Ken Morneault Ken Morneault
Cisco Systems Inc. Cisco Systems Inc.
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Phone: +1-703-484-3323 Phone: +1-703-484-3323
EMail: kmorneau@cisco.com EMail: kmorneau@cisco.com
6. References 6. References
[M3UA] "MTP3 User Adaptation Layer" [M3UA] "MTP3 User Adaptation Layer"
7. Changes Control
7.1 Changes from v00 to v01
- Typos.
- Update all the RC references to show it is a semi-optional
parameter.
- DUNA(*) substituted for ASPIA-ACK when NIF is not available.
- New sections added:
- IPSP stuff
- Messages and Streams
- ASP Id for IPSP communication
- n+k redundancy
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 18, line 36 skipping to change at line 1421
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
7. Changes Control
TBD
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/