draft-ietf-sigtran-m3ua-implementors-guide-05.txt   draft-ietf-sigtran-m3ua-implementors-guide-06.txt 
Network Working Group Javier Pastor-Balbas Network Working Group Javier Pastor-Balbas
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: February 2004 Expires: April 2004
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
28 August, 2003 October, 2003
M3UA Implementor's Guide M3UA Implementor's Guide
<draft-ietf-sigtran-m3ua-implementors-guide-05.txt> <draft-ietf-sigtran-m3ua-implementors-guide-06.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 19 skipping to change at page 2, line 17
1. Introduction.......................................................3 1. Introduction.......................................................3
1.1 Abbreviations.....................................................3 1.1 Abbreviations.....................................................3
2. Conventions........................................................3 2. Conventions........................................................3
3. Corrections to RFC3332.............................................3 3. Corrections to RFC3332.............................................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 Scope of Network Appearance........................................7 3.4 Scope of Network Appearance........................................7
3.5 Conditional RC parameter...........................................9 3.5 Conditional RC parameter...........................................9
3.6 Receiving REG for a RK already registered.........................11 3.6 Receiving REG for a RK already registered.........................11
3.7 Dynamic Registration Support for Alias Point Code.................15 3.7 Dynamic Registration Support for Alias Point Code.................14
3.8 Auditing procedure and congestion state...........................15 3.8 Auditing procedure and congestion state...........................15
3.9 Response to an ASPIA message......................................18 3.9 Response to an ASPIA message......................................17
3.10 INFO and DIAG parameter length...................................19 3.10 INFO and DIAG parameter length...................................19
3.11 IPSP stuff.......................................................20 3.11 IPSP stuff.......................................................21
3.12 Messages and Streams.............................................27 3.12 Messages and Streams.............................................27
3.13 ASP Id for IPSP communication....................................28 3.13 ASP Id for IPSP communication....................................28
3.14 n+k redundancy...................................................29 3.14 n+k redundancy...................................................29
3.15 Multiple Parameters of the Same Type in a Message................34 3.15 Multiple Parameters of the Same Type in a Message................34
3.16 Registered Routing Key State After Unexpected ASP Up Message.....35 3.16 Registered Routing Key State After Unexpected ASP Up Message.....35
3.17 Location of Network Appearance...................................35 3.17 Location of Network Appearance...................................36
3.18 Determination of Congestion Abatement When ASP Sends SCON........37 3.18 Determination of Congestion Abatement When ASP Sends SCON........37
3.19 Removing CIC and SSN from RK.....................................38 3.19 Removing CIC and SSN from RK.....................................38
3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......44 3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45
3.21 NOTIFY messages are missing in Examples section..................46 3.21 NOTIFY messages are missing in Examples section..................47
3.22 Sending NTFY after sending ASP-INACTIVE-ACK......................55 3.22 Sending NTFY after sending ASP-UP-ACK............................56
4. Acknowledgements..................................................57 3.23 Re-registration after failure....................................57
5. Authors' Addresses................................................57 3.24 No Configured AS Error...........................................58
6. References........................................................57 3.25 NIF not available on SGP.........................................59
7. Changes Control...................................................57 3.26 Notify(ASP-Failure) usage clarification..........................60
7.1 Changes from v00 to v01...........................................57 3.27 Alignment of ASP Active message with ASP Inactive message........61
7.2 Changes from v01 to v02...........................................58 4. Acknowledgements..................................................63
7.3 Changes from v02 to v03...........................................58 5. Authors' Addresses................................................63
7.4 Changes from v03 to v04...........................................58 6. References........................................................64
7.5 Changes from v04 to v05...........................................59 7. Changes Control...................................................64
7.1 Changes from v00 to v01...........................................64
7.2 Changes from v01 to v02...........................................64
7.3 Changes from v02 to v03...........................................64
7.4 Changes from v03 to v04...........................................65
7.5 Changes from v04 to v05...........................................65
7.6 Changes from v05 to v06...........................................66
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
the publication date for the MTP3 User Adaptation Layer (M3UA) the publication date for the MTP3 User Adaptation Layer (M3UA)
[RFC3332]. These defects may be of an editorial or technical nature. [RFC3332]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be used in This document may be thought of as a companion document to be used in
the implementation of M3UA to clarify errors in the original M3UA the implementation of M3UA to clarify errors in the original M3UA
document. This document updates RFC3332 and text within this document. This document updates RFC3332 and text within this
document, where noted, supersedes the text found in RFC3332. Each document, where noted, supersedes the text found in RFC3332. Each
skipping to change at page 17, line 14 skipping to change at page 17, line 7
--------- ---------
5.4 Auditing examples 5.4 Auditing examples
5.4.1 SG State: Uncongested / Available 5.4.1 SG State: Uncongested / Available
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------ SCON(0) -------- | | <------ SCON(0) -------- |
| <------- DANA ---------- | | <------- DAVA ---------- |
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 ---------- |
5.4.3 SG state: Unknown / Available 5.4.3 SG state: Unknown / Available
skipping to change at page 18, line 28 skipping to change at page 18, line 22
| <---- ASPIA Ack ------- | | <---- ASPIA Ack ------- |
| -----DEREG REQ (RC1)---> | | -----DEREG REQ (RC1)---> |
| <----DEREG RSP (RC1)---- | | <----DEREG RSP (RC1)---- |
| -------ASPIA (RC1)-----> | | -------ASPIA (RC1)-----> |
What should SG do? What should SG do?
3.9.2 Text changes to the document 3.9.2 Text changes to the document
--------- ---------
Old text: (Section 4.5.3) Old text: (Section 4.3.4.4)
--------- ---------
When an ASP wishes to withdraw from receiving traffic within an AS, When an ASP wishes to withdraw from receiving traffic within an AS,
the ASP sends an ASP Inactive message to the SGP or IPSP. This the ASP sends an ASP Inactive message to the SGP or IPSP. This
action MAY be initiated at the ASP by an M-ASP_INACTIVE request action MAY be initiated at the ASP by an M-ASP_INACTIVE request
primitive from Layer Management or MAY be initiated automatically by primitive from Layer Management or MAY be initiated automatically by
an M3UA management function. In the case where an ASP is processing an M3UA management function. In the case where an ASP is processing
the traffic for more than one Application Server across a common SCTP the traffic for more than one Application Server across a common SCTP
association, the ASP Inactive message contains one or more Routing association, the ASP Inactive message contains one or more Routing
Contexts to indicate for which Application Servers the ASP Inactive Contexts to indicate for which Application Servers the ASP Inactive
message applies. message applies.
--------- ---------
New text: (Section 4.5.3) New text: (Section 4.3.4.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,
the ASP wants to initiate the process of activation, the ASP sends an or the ASP wants to initiate the process of deactivation, the ASP
ASP Inactive message to the SGP or IPSP. sends an 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) in the following
way:
- If the corresponding RK is registered (statically or - If the ASP Inactive message contains a RC parameter and the
dynamically), the peer should respond with an ASP Inactive Ack corresponding RK is defined (by either static configuration or
message. dynamic registration), the peer MUST respond with an ASP
- If the RK is not registered, or the RC information is not valid, Inactive Ack message.
the peer must respond with an ERROR message with Error Code =
"Invalid Routing Context". - If the ASP Inactive message contains a RC parameter that is not
- If the RC is missing and its specification is needed according defined (by either static configuration or dynamic
to the used configuration, the peer must respond with an ERROR registration), the peer MUST respond with an ERROR message with
message with Error Code = "No Configured AS for ASP". Error Code = "Invalid Routing Context".
- If the ASP Inactive message does not contain a RC parameter and
the RK is defined (by either static configuration or dynamic
registration), the peer must turn the ASP/IPSP to ASP-INACTIVE
state in all the ASes it serves and MUST respond with an ASP
Inactive Ack message.
- If the ASP Inactive message does not contain a RC parameter and
the RK is not defined (by either static configuration or dynamic
registration), the peer MUST respond with an ERROR 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.9.3 Solution description 3.9.3 Solution description
skipping to change at page 40, line 48 skipping to change at page 41, line 6
Congestion Indications 0x0205 Congestion Indications 0x0205
Concerned Destination 0x0206 Concerned Destination 0x0206
Routing Key 0x0207 Routing Key 0x0207
Registration Result 0x0208 Registration Result 0x0208
Deregistration Result 0x0209 Deregistration Result 0x0209
Local_Routing Key Identifier 0x020a Local_Routing Key Identifier 0x020a
Destination Point Code 0x020b Destination Point Code 0x020b
Service Indicators 0x020c Service Indicators 0x020c
Reserved 0x020d Reserved 0x020d
Originating Point Code List 0x020e Originating Point Code List 0x020e
Reserved 0x020f Protocol Reserved 0x020f
Data 0x0210 Protocol Data 0x0210
Reserved 0x0211 Reserved 0x0211
Registration Status 0x0212 Registration Status 0x0212
Deregistration Status 0x0213 Deregistration Status 0x0213
--------- ---------
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
| Traffic Mode Type (optional) | | Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code | | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) | | Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) | | Service Indicators (optional) |
skipping to change at page 55, line 39 skipping to change at page 56, line 5
|-------------------NOTIFY(AS-ACTIVE)-->| | |-------------------NOTIFY(AS-ACTIVE)-->| |
|---------------------------------------NOTIFY(AS-ACTIVE)-->| |---------------------------------------NOTIFY(AS-ACTIVE)-->|
| | | | | | | |
| | | | | | | |
3.21.3 Solution Description 3.21.3 Solution Description
By specifying all the mandatory NOTIFY messages in the drawing, we By specifying all the mandatory NOTIFY messages in the drawing, we
solve the problem. solve the problem.
3.22 Sending NTFY after sending ASP-INACTIVE-ACK 3.22 Sending NTFY after sending ASP-UP-ACK
3.22.1 Description of the problem 3.22.1 Description of the problem
When an ASP comes from ASP-DOWN to ASP-INACTIVE for a particular AS, When an ASP comes from ASP-DOWN to ASP-INACTIVE for a particular AS,
the ASP does not know anything about the state of the AS. the ASP does not know anything about the state of the AS.
3.22.2 Text changes to the document 3.22.2 Text changes to the document
--------- ---------
Old text: (Section 4.3.4.5) Old text: (Section 4.3.4.5)
skipping to change at page 56, line 38 skipping to change at page 56, line 45
appropriate Status Information and any ASP Identifier of the failed appropriate Status Information and any ASP Identifier of the failed
ASP. At the ASP, Layer Management is informed with an M-NOTIFY ASP. At the ASP, Layer Management is informed with an M-NOTIFY
indication primitive. The Notify message must be sent whether the AS indication primitive. The Notify message must be sent whether the AS
state change was a result of an ASP failure or reception of an ASP state change was a result of an ASP failure or reception of an ASP
State management (ASPSM) / ASP Traffic Management (ASPTM) message. State management (ASPSM) / ASP Traffic Management (ASPTM) message.
In the second case, the Notify message MUST be sent after any related 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 acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active
Ack, or ASP Inactive Ack). Ack, or ASP Inactive Ack).
When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular
AS, a Notify message SHOULD be sent, by the ASP-INACTIVE receptor, AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after
after sending the ASP-INACTIVE-ACK, in order to inform the ASP of the sending the ASP-UP-ACK, in order to inform the ASP of the current AS
current AS state. state.
3.22.3 Solution Description 3.22.3 Solution Description
By specifying how to update the AS state in an ASP when it moves from By specifying how to update the AS state in an ASP when it moves from
ASP-DOWN to ASP-INACTIVE, the problem is solved. ASP-DOWN to ASP-INACTIVE, the problem is solved.
3.23 Re-registration after failure
3.23.1 Description of the problem
Given the following scenario:
ASP SG
-------- ----------
REG REQ (RK1) --------->
<--------- REG RSP (success, rc=2)
[ASP goes down, then comes back up]
REG REQ (RK1) --------->
<--------- REG RSP (error - routing key
already reg, rc=2)
It is important to note that the REG RSP (error-routing key
already registered) MUST contain the Routing Context to ensure both
sides are in-sync.
3.23.2 Text changes to the document
---------
Old text: (Section 4.4.1)
---------
None.
---------
New text: (Section 4.4.1)
---------
If an SGP determines that a received Routing Key is already
registered, the SG returns a Registration Response message to the
ASP, containing a Registration Result "Error routing key already
registered" and also the RC value previously assigned.
3.23.3 Solution Description
By specifying that RC must be present in the response message when
the routing key is registered, the problem is solved.
3.24 No Configured AS Error
3.24.1 Description of the problem
During the third M3UA Plugtest there was a stated preference to allow
the SG to return Error ("no AS configured") in response to ASP Active
(RC) when RC is not configured.
3.24.2 Text changes to the document
---------
Old text: (Section 3.8.1)
---------
The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value.
For this error, the invalid Routing Context(s) MUST be included in
the Error message.
The "No Configured AS for ASP" error is sent if a message is received
from a peer without a Routing Context parameter and it is not known
by configuration data which Application Servers are referenced.
---------
New text: (Section 3.8.1)
---------
The "Invalid Routing Context" error is sent if a message, other than
ASP-Active, is received from a peer with an invalid Routing Context
value. The invalid Routing Context(s) MUST be included in the Error
message.
The "No Configured AS for ASP" error is sent if a message is received
from a peer without a Routing Context parameter and it is not known
by configuration data which Application Servers are referenced.
This error is also sent when an ASP-Active message is received with
an unconfigured RC and the invalid Routing Context(s) MUST be then
included in the Error message.
---------
Old text: (Section 4.3.4.3)
---------
Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts. The SGP or IPSP MUST send an
Error message ("Invalid Routing Context") for each Routing Context
value that the ASP cannot be successfully activated .
---------
New text: (Section 4.3.4.3)
---------
Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts. The SGP or IPSP MUST send an
Error message ("No Configured AS for ASP ") for each Routing Context
value that the ASP cannot be successfully activated .
3.24.3 Solution Description
Specifying how to use the specific error codes with the ASP-Active
message solves the problem.
3.25 NIF not available on SGP
3.25.1 Description of the problem
How to handle NIF Unavailable was removed from IGv05. There is
a suggestion that we specify how to handle this situation in the IG
3.25.2 Text changes to the document
---------
New text: (Section 4.7)
---------
IMPLEMENTATION NOTE: Although the NIF is decided to be an
implementation dependent function, here there are some guidelines
that may be useful to follow:
- If the SG (all the SGPs) is isolated from the NIF, then all the
users are isolated from the SS7 network. A DUNA(*) message may be
sent from the SGPs to all the ASPs.
- If only one SGP in the SG is isolated entirely from the NIF, the
SGP may abort its associations. An alternative would be for the SGP
to send ASP Down Ack.
- 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
may send DUNA messages for the affected SPC(es). This is the case
where an SGP can continue to service one or more active AS(es), but
due to a partial failure it is unable to service other(s) active
AS(es).
3.25.3 Solution Description
As it is agreed that the NIF is an implementation dependent function,
the new text can be included in an IMPLEMENTATION NOTE clause. The
text included is from the conclusions of the mailing list
discussions. In this way it is not normative text, but it may be used
as a guideline.
3.26 Notify(ASP-Failure) usage clarification
3.26.1 Description of the problem
Clarify text as to when Notify (ASP Failure) must be sent. Is it upon
failure (SCTP association fails) or any transition to ASP-DOWN state?
3.26.2 Text changes to the document
---------
Old text: (3.8.2)
---------
These notifications are not based on the SGP reporting the state
change of an ASP or AS. In the Insufficient ASP Resources case, the
SGP is indicating to an ASP_INACTIVE ASP in the AS that another ASP
is required to handle the load of the AS (Loadsharing or Broadcast
mode). For the Alternate ASP Active case, an ASP is informed when an
alternate ASP transitions to the ASP-ACTIVE state in Override mode.
The ASP Identifier (if available) of the Alternate ASP MUST be placed
in the message. For the ASP Failure case, the SGP is indicating to
ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN.
The ASP Identifier (if available) of the failed ASP MUST be placed in
the message.
---------
New text: (3.8.2)
---------
These notifications are not based on the SGP reporting the state
change of an ASP or AS.
- In the Insufficient ASP Resources case, the SGP is indicating to an
ASP_INACTIVE ASP in the AS that another ASP is required to handle
the load of the AS (Loadsharing or Broadcast mode).
- For the Alternate ASP Active case, an ASP is informed when an
alternate ASP transitions to the ASP-ACTIVE state in Override mode.
The ASP Identifier (if available) of the Alternate ASP MUST be
placed in the message.
- For the ASP Failure case, the SGP is indicating to ASP(s) in the AS
that one of the ASPs has failed. The ASP Identifier (if available)
of the failed ASP MUST be placed in the message.
3.26.3 Solution description
It has been changed the sentence "transitioned to ASP-DOWN" to
"failed" to stress that the ASP failure is the reason of this
notification.
3.27 Alignment of ASP Active message with ASP Inactive message
3.27.1 Description of the problem
It is suggested to align the wording in these two sections to avoid
misunderstandings and specify the response to these messages in all
cases.
3.27.2 Text changes to the document
---------
Old text: (Section 4.3.4.3)
---------
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 ASP is a member.
---------
New text: (Section 4.3.4.3)
---------
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 ASP is a member and move the ASP to
the ASP-ACTIVE state in all Application Servers.
---------
Old text: (Section 4.3.4.3)
---------
Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts. The SGP or IPSP MUST send an
Error message ("Invalid Routing Context") for each Routing Context
value that the ASP cannot be successfully activated .
In the case where an "out-of-the-blue" ASP Active message is received
(i.e., the ASP has not registered with the SG or the SG has no static
configuration data for the ASP), the message MAY be silently
discarded.
The SGP MUST send an ASP Active Ack message in response to a received
ASP Active message from the ASP, if the ASP is already marked in the
ASP-ACTIVE state at the SGP.
---------
New text: (Section 4.3.4.3)
---------
Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts.
The ASP Active message will be responded in the following way as a
function of the presence/need of the RC parameter:
- If the RC parameter is included in the ASP Active message and the
corresponding RK has been previously defined (by either static
configuration or dynamic registration), the peer node MUST respond
with an ASP Active Ack message if it is ready to handle traffic;
otherwise it will not respond (meaning that it is not ready to
become active). This is valid for either: ASP was in ASP-ACTIVE or
ASP-INACTIVE states.
- If the RC parameter is included in the ASP Active message and a
corresponding RK has not been previously defined (by either static
configuration or dynamic registration), the peer MUST respond with
an ERROR message with Error Code = "No configured AS for ASP".
- If the RC parameter is not included in the ASP Active message,
there are RKs defined (by either static configuration or dynamic
registration) and RC is not mandatory, the peer node SHOULD respond
with an ASP Active Ack message and activate all the RKs it has
defined for that specific ASP.
- If the RC parameter is not included in the ASP Active message,
there are RKs defined (by either static configuration or dynamic
registration) and RC is mandatory, the peer node MUST respond with
and ERROR message with the Error Code = "Missing Parameter".
- If the RC parameter is not included in the ASP Active message,
there are RKs defined (by either static configuration or dynamic
registration) and RC is not mandatory, the peer node MUST respond
with an ASP Active Ack message if it is ready to handle traffic;
otherwise it will not respond (meaning that it is not ready to
become active).
- If the RC parameter is not included in the ASP Active message and
there are no RKs defined, the peer node SHOULD respond with and
ERROR message with the Error Code = "No configured AS for ASP".
3.27.3 Solution Description
The text changes include similar wording in both sections.
4. Acknowledgements 4. Acknowledgements
The authors would like to thank Lyndon Ong, Tolga Asveren, Brian The authors would like to thank Lyndon Ong, Tolga Asveren, Brian
Bidulock, Umesh Vats, Barry Nagelberg, Samuel Dur D. Jeyaseelan, Bidulock, Umesh Vats, Barry Nagelberg, Samuel Dur D. Jeyaseelan,
Antonio Canete and many others for their valuable comments and Antonio Canete, Kamesh Kaul, Vivek Toky and many others for their
suggestions. valuable comments and suggestions.
5. Authors' Addresses 5. Authors' Addresses
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Espana S.A. Ericsson Espana S.A.
Via de los Poblados 13 Via de los Poblados 13
28033 Madrid 28033 Madrid
Spain Spain
Phone: +34-91-339-1397 Phone: +34-91-339-1397
skipping to change at page 60, line 4 skipping to change at page 66, line 8
- In section 3.18: Add Implementation note to regarding the timer - In section 3.18: Add Implementation note to regarding the timer
- In section 3.20: Add Implementation note to regarding the timer - In section 3.20: Add Implementation note to regarding the timer
- In section 3.21: Modify the example 5.2.3 to show the conclusions - In section 3.21: Modify the example 5.2.3 to show the conclusions
from section 3.14 in this IG. from section 3.14 in this IG.
- New section 3.22: Include the recommendation of sending NTFY - New section 3.22: Include the recommendation of sending NTFY
message after an ASP moves from ASP-DOWN to ASP-INACTIVE for a message after an ASP moves from ASP-DOWN to ASP-INACTIVE for a
particular AS to inform it of the current state of the AS. particular AS to inform it of the current state of the AS.
7.6 Changes from v05 to v06
- In section 3.9: reworked for clarification. All possible cases
included. Also the section where the changes are, has been
corrected.
- In section 3.22: typos corrected
- New section 3.27: Alignment of ASP Active message with ASP Inactive
message detailing what response to send in all possible cases.
Output from the plugtest:
- New section 3.23: For re-registration after failure the REG RSP
(error-routing key already registered) MUST contain the Routing
Context to ensure both sides are in-sync.
- New section 3.24: there is a stated preference to allow the SG to
return Error ("no AS configured") in response to ASP Active (RC)
when RC is not configured
- New section 3.25: NIF section removed with the change to version 4
is included again but as an implementation note instead of
normative text.
- New section 3.26: Clarifies the Notify(ASP-Failure) usage.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
 End of changes. 

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