draft-ietf-sigtran-m3ua-implementors-guide-04.txt   draft-ietf-sigtran-m3ua-implementors-guide-05.txt 
Network Working Group Javier Pastor-Balbas Network Working Group Javier Pastor-Balbas
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: December 2003 Expires: February 2004
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
June, 2003 28 August, 2003
M3UA Implementor's Guide M3UA Implementor's Guide
<draft-ietf-sigtran-m3ua-implementors-guide-04.txt> <draft-ietf-sigtran-m3ua-implementors-guide-05.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 29 skipping to change at page 2, line 29
3.7 Dynamic Registration Support for Alias Point Code.................15 3.7 Dynamic Registration Support for Alias Point Code.................15
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......................................18
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.......................................................20
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...................................36 3.17 Location of Network Appearance...................................35
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......45 3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......44
3.21 NOTIFY messages are missing in Examples section..................46 3.21 NOTIFY messages are missing in Examples section..................46
4. Acknowledgements..................................................56 3.22 Sending NTFY after sending ASP-INACTIVE-ACK......................55
5. Authors' Addresses................................................56 4. Acknowledgements..................................................57
6. References........................................................56 5. Authors' Addresses................................................57
7. Changes Control...................................................56 6. References........................................................57
7.1 Changes from v00 to v01...........................................56 7. Changes Control...................................................57
7.2 Changes from v01 to v02...........................................57 7.1 Changes from v00 to v01...........................................57
7.3 Changes from v02 to v03...........................................57 7.2 Changes from v01 to v02...........................................58
7.3 Changes from v02 to v03...........................................58
7.4 Changes from v03 to v04...........................................58
7.5 Changes from v04 to v05...........................................59
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 14, line 18 skipping to change at page 14, line 18
2 Error - Invalid DPC 2 Error - Invalid DPC
3 Error - Invalid Network Appearance 3 Error - Invalid Network Appearance
4 Error - Invalid Routing Key 4 Error - Invalid Routing Key
5 Error - Permission Denied 5 Error - Permission Denied
6 Error - Cannot Support Unique Routing 6 Error - Cannot Support Unique Routing
7 Error - Routing Key not Currently Provisioned 7 Error - Routing Key not Currently Provisioned
8 Error - Insufficient Resources 8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field 9 Error - Unsupported RK parameter Field
10 Error - Unsupported/Invalid Traffic Handling Mode 10 Error - Unsupported/Invalid Traffic Handling Mode
11 Error - Routing Key Change Refused 11 Error - Routing Key Change Refused
12 Error - Routing Key Already Registered
--------- ---------
Old text: (Section 4.4.1) Old text: (Section 4.4.1)
--------- ---------
None. None.
-------- --------
New text: (Section 4.4.1) New text: (Section 4.4.1)
--------- ---------
If the SGP determines that the received RK was already registered, If the SGP determines that the received RK was already registered,
the SGP returns a Registration Response message to the ASP, the SGP returns a Registration Response message to the ASP,
containing a Registration Result "Error - Cannot Support Unique containing a Registration Result "Error - Routing Key Already
Routing". This error applies whether the Routing Key is Active or Registered ". This error applies whether the Routing Key is Active or
Inactive. Inactive.
An ASP MAY modify an existing Routing Key by including a Routing An ASP MAY modify an existing Routing Key by including a Routing
Context parameter in the REG REQ. If the SGP determines that the Context parameter in the REG REQ. If the SGP determines that the
Routing Context applies to an existing Routing Key, the SG MAY adjust Routing Context applies to an existing Routing Key, the SG MAY adjust
the existing Routing Key to match the new information provided in the the existing Routing Key to match the new information provided in the
Routing Key parameter. A Registration Response "ERR - Routing Key Routing Key parameter. A Registration Response "ERR - Routing Key
Change Refused" is returned if the SGP does not accept the Change Refused" is returned if the SGP does not accept the
modification of the Routing Key due to either it does not support the modification of the Routing Key due to either it does not support the
re-registration procedure or the specific RC does not exist. re-registration procedure or the specific RC does not exist.
skipping to change at page 17, line 4 skipping to change at page 17, line 5
--------- ---------
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 / Available
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------ SCON(0) -------- | | <------ SCON(0) -------- |
| <------- DUNA ---------- | | <------- DANA ---------- |
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
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------- DAVA ---------- | | <------- DAVA ---------- |
5.4.4 SG state: Uncongested / Unavailable 5.4.4 SG state: Unavailable
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------- DUNA ---------- | | <------- DUNA ---------- |
5.5 M3UA/MTP3-User Boundary Examples 5.5 M3UA/MTP3-User Boundary Examples
3.8.3 Solution description 3.8.3 Solution description
skipping to change at page 19, line 27 skipping to change at page 19, line 27
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
A more detailed specification of the messages to be sent upon the A more detailed specification of the messages to be sent upon the
reception of an ASPIA has been added to the Inactive Procedures reception of an ASPIA has been added to the Inactive Procedures
Section. Section. In response to the original question and according with the
new text, the SG should send Error("Invalid Routing Context").
3.10 INFO and DIAG parameter length 3.10 INFO and DIAG parameter length
3.10.1 Description of the problem 3.10.1 Description of the problem
At the second interop a question was raised about accepting a length At the second interop a question was raised about accepting a length
of 4 bytes for DIAG and INFO parameters. of 4 bytes for DIAG and INFO parameters.
3.10.2 Text changes to the document 3.10.2 Text changes to the document
skipping to change at page 31, line 43 skipping to change at page 31, line 45
directly upon the first successful REG REQ from an ASP. Another directly upon the first successful REG REQ from an ASP. Another
example is where the AS/ASP configuration data is not created until 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 first ASP successfully enters the ASP-ACTIVE state. In this case
the AS-ACTIVE state is entered directly. the AS-ACTIVE state is entered directly.
--------- ---------
New text: (Section 4.3.2) New text: (Section 4.3.2)
--------- ---------
AS-DOWN: The Application Server is unavailable. This state implies AS-DOWN: The Application Server is unavailable. This state implies
that the number of ASPs being in ASP-INACTIVE or ASP-ACTIVE is less that all the ASPs are in ASP-DOWN state. Initially the AS will be in
than "n". Initially the AS will be in this state. An Application this state. An Application Server is in the AS-DOWN state when it is
Server is in the AS-DOWN state when it is removed from a removed from a configuration.
configuration.
AS-INACTIVE: The Application Server is available but no application AS-INACTIVE: The Application Server is available but no application
traffic is active. This implies that there are at least n ASPs in traffic is active. One or more ASPs are in ASP-INACTIVE state and/or
either ASP-INACTIVE or ASP-ACTIVE but the total number of ASPs in the number of ASPs in ASP-ACTIVE state has not reached n. The
ASP-ACTIVE state has not reach n. The recovery timer T(r) is not recovery timer T(r) is not running or has expired.
running or has expired.
AS-ACTIVE: The Application Server is available and application AS-ACTIVE: The Application Server is available and application
traffic is active. The AS moves to this state after being in AS- traffic is active. The AS moves to this state after being in AS-
INACTIVE and getting n ASPs in ASP-ACTIVE state or, after reaching INACTIVE and getting n ASPs in ASP-ACTIVE state or, after reaching
AS-ACTIVE and keeping one or more ASPs in ASP-ACTIVE state. AS-ACTIVE and keeping one or more ASPs in ASP-ACTIVE state.
When it is considered that one ASP is enough to handle traffic When it is considered that one ASP is enough to handle traffic
(smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon (smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon
as the first ASP moves to the ASP-ACTIVE state. as the first ASP moves to the ASP-ACTIVE state.
AS-PENDING: The last active ASP has transitioned from ASP-ACTIVE to AS-PENDING: The last active ASP has transitioned from ASP-ACTIVE to
skipping to change at page 32, line 49 skipping to change at page 32, line 49
| | \ | | | | \ | |
DN2IA | | \ PN2AC | | DN2IA | | \ PN2AC | |
| v \ | v | v \ | v
+----------+ \ +-------------+ +----------+ \ +-------------+
| | ----------| | | | ----------| |
| AS-DOWN | | AS-PENDING | | AS-DOWN | | AS-PENDING |
| | PN2DN | (queueing) | | | PN2DN | (queueing) |
| |<----------------------------| | | |<----------------------------| |
+----------+ +-------------+ +----------+ +-------------+
DN2IA: One ASP moves to ASP-INACTIVE causing that n ASPs are in DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state.
either ASP-ACTIVE or ASP-INACTIVE states.
IA2DN: One ASP moves to ASP-DOWN causing that the number of ASPs in IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN causing that
either ASP-ACTIVE or ASP-INACTIVE drops below n. the all the ASPs are in ASP-DOWN state.
IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the
ASP-ACTIVE state to be n. ASP-ACTIVE state to be n.
In a special case of smooth start, this transition MAY be done when In a special case of smooth start, this transition MAY be done when
the first ASP moves to ASP-ACTIVE state. the first ASP moves to ASP-ACTIVE state.
AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP- AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-
DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1. DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1.
PN2AC: One ASP moves to ASP-ACTIVE. PN2AC: One ASP moves to ASP-ACTIVE.
PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE. PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE.
PN2DN: T(r) Expiry, the number of ASPs in ASP-INACTIVE state is less PN2DN: T(r) Expiry, all the ASPs are in ASP-DOWN state.
than n.
As "n" ASPs are needed to handle the maximum engineered load of the An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state
AS, an AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE during the start-up phase (except for smooth start). Once the traffic
state during the start-up phase (except for smooth start). Once the is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns
traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP to another state different to ASP-ACTIVE, avoiding unnecessary
turns to another state different to ASP-ACTIVE, avoiding unnecessary
traffic disturbances as long as there are ASPs available, in the traffic disturbances as long as there are ASPs available, in the
assumption that the system will not always be exposed to the maximum assumption that the system will not always be exposed to the maximum
load. load.
There are other cases where the AS/ASP configuration data is created There are other cases where the AS/ASP configuration data is created
dynamically. In those cases there would be differences in the state dynamically. In those cases there would be differences in the state
machine, especially at creation of the AS. For example, where the machine, especially at creation of the AS. For example, where the
AS/ASP configuration data is not created until Registration of the AS/ASP configuration data is not created until Registration of the
first ASP, the AS-INACTIVE state is entered directly upon the nth first ASP, the AS-INACTIVE state is entered directly upon the nth
successful REG REQ from an ASP belonging to that AS. Another example successful REG REQ from an ASP belonging to that AS. Another example
skipping to change at page 34, line 24 skipping to change at page 34, line 19
SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are
sufficient resources. sufficient resources.
3.14.3 Solution description 3.14.3 Solution description
The AS state machine reflects the state changes as a function of the The AS state machine reflects the state changes as a function of the
"n" number from the n+k redundancy configuration. This solution is "n" number from the n+k redundancy configuration. This solution is
compliance with the previous one: 1+0 model. The change from MAY to compliance with the previous one: 1+0 model. The change from MAY to
SHOULD NOT makes it recommendable to send traffic only when the SHOULD NOT makes it recommendable to send traffic only when the
require ASPs number are in ASP-ACTIVE state. require ASPs number are in ASP-ACTIVE state.
Also it is explicitely stated that "n" is seen as the "maximum
engineered load".
3.15 Multiple Parameters of the Same Type in a Message 3.15 Multiple Parameters of the Same Type in a Message
3.15.1 Description of the problem 3.15.1 Description of the problem
There was some confusion about whether or not multiple parameters There was some confusion about whether or not multiple parameters
of same type were allowed in a message. of same type were allowed in a message.
3.15.2 Text changes to the document 3.15.2 Text changes to the document
skipping to change at page 38, line 5 skipping to change at page 37, line 47
The SCON message can be sent from an SGP to all concerned ASPs to The SCON message can be sent from an SGP to all concerned ASPs to
indicate that an SG has determined that there is congestion in the indicate that an SG has determined that there is congestion in the
SS7 network to one or more destinations, or to an ASP in response to SS7 network to one or more destinations, or to an ASP in response to
a DATA or DAUD message as appropriate. For some MTP protocol a DATA or DAUD message as appropriate. For some MTP protocol
variants (e.g., ANSI MTP) the SCON message may be sent when the SS7 variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
congestion level changes. The SCON message MAY also be sent from the congestion level changes. The SCON message MAY also be sent from the
M3UA layer of an ASP to an M3UA peer indicating that the congestion M3UA layer of an ASP to an M3UA peer indicating that the congestion
level of the M3UA layer or the ASP has changed. level of the M3UA layer or the ASP has changed.
3.18.3 Solution Description IMPLEMENTATION NOTE: an M3UA node may maintain a timer to control
congestion notification validity, if desired. This timer will be
useful in those cases where the peer node fails to indicate
congestion abatement.
3.18.3 Solution Description
Clarify that the ASP needs to indicate when the congestion level has Clarify that the ASP needs to indicate when the congestion level has
changed (including abatement). Further, the ASP peer can maintain changed (including abatement). Further, the ASP peer can maintain
a timer, if desired, in case the ASP fails to indicate congestion a timer, if desired, in case the ASP fails to indicate congestion
abatement. abatement.
3.19 Removing CIC and SSN from RK 3.19 Removing CIC and SSN from RK
3.19.1 Description of the problem 3.19.1 Description of the problem
Use of SSN and CIC Routing Keys is inadequately defined in RFC3332 Use of SSN and CIC Routing Keys is inadequately defined in RFC3332
skipping to change at page 46, line 35 skipping to change at page 46, line 32
The ASP MAY choose to audit the availability of unavailable The ASP MAY choose to audit the availability of unavailable
destinations by sending DAUD messages. This would be for example the destinations by sending DAUD messages. This would be for example the
case when an AS becomes active at an ASP and does not have current case when an AS becomes active at an ASP and does not have current
destination statuses. If MTP restart is in progress at the SG, the destination statuses. If MTP restart is in progress at the SG, the
SGP returns a DUNA message for that destination, even if it received SGP returns a DUNA message for that destination, even if it received
an indication that the destination became available or restricted. an indication that the destination became available or restricted.
When an ASP becomes active for an AS and the SG is experiencing SS7 When an ASP becomes active for an AS and the SG is experiencing SS7
network isolation or is performing the MTP Restart procedure for the network isolation or is performing the MTP Restart procedure for the
AS, the SG SHOULD send a DUNA(*) to the newly active ASP to prevent AS, the SG MAY send a DUNA message for the concerned destinations to
the ASP from sending traffic. the newly active ASP to prevent the ASP from sending traffic.
In the IPSP case, MTP restart could be considered if the IPSP also In the IPSP case, MTP restart could be considered if the IPSP also
has connection to an SS7 network. [...] has connection to an SS7 network. [...]
3.20.3 Solution Description 3.20.3 Solution Description
By specifying how send SSNM messages in that scenario the problem is By specifying how send SSNM messages in that scenario the problem is
solved. solved.
3.21 NOTIFY messages are missing in Examples section 3.21 NOTIFY messages are missing in Examples section
skipping to change at page 55, line 23 skipping to change at page 55, line 21
--------- ---------
New text: (Section 5.2.3) New text: (Section 5.2.3)
--------- ---------
SGP ASP1 ASP2 ASP3 SGP ASP1 ASP2 ASP3
| | | | | | | |
|<----ASP Inact.----| | | |<----ASP Inact.----| | |
|---ASP Inact Ack-->| | | |---ASP Inact Ack-->| | |
| | | | | | | |
|-NTFY(AS-PENDING)->| | | |--NTFY(Ins. ASPs)->| | |
|-------------------NOTIFY(AS-PENDING)->| |
|---------------------------------------NOTIFY(AS-PENDING)->|
|---------------------------------------NOTIFY(Ins. ASPs)-->| |---------------------------------------NOTIFY(Ins. ASPs)-->|
| | | | | | | |
| | | | | | | |
|<----------------------------------------ASP Act (Ldshr)---| |<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->| |------------------------------------------ASP Act (Ack)--->|
| | | | | | | |
|-NTFY(AS-ACTIVE)-->| | | |-NTFY(AS-ACTIVE)-->| | |
|-------------------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.1 Description of the problem
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.
3.22.2 Text changes to the document
---------
Old text: (Section 4.3.4.5)
---------
A Notify message reflecting a change in the AS state MUST be sent to
all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed
ASP. At the ASP, 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 ASP 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).
---------
New text: (Section 4.3.4.5)
---------
A Notify message reflecting a change in the AS state MUST be sent to
all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed
ASP. At the ASP, 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 ASP 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).
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,
after sending the ASP-INACTIVE-ACK, in order to inform the ASP of the
current AS state.
3.22.3 Solution Description
By specifying how to update the AS state in an ASP when it moves from
ASP-DOWN to ASP-INACTIVE, the problem is solved.
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 and many others for their valuable comments and
suggestions. suggestions.
5. Authors' Addresses 5. Authors' Addresses
Javier Pastor-Balbas Javier Pastor-Balbas
skipping to change at page 58, line 4 skipping to change at page 59, line 4
informed decision on how to handle NIF isolation. informed decision on how to handle NIF isolation.
- Section 3.15 updated (now it is section 3.14) - Section 3.15 updated (now it is section 3.14)
- Current section 3.19 about removing CIC and SSN from the RK: - Current section 3.19 about removing CIC and SSN from the RK:
"Reserved 0x020f" Parameter Tag Code has been added (that was the "Reserved 0x020f" Parameter Tag Code has been added (that was the
CIC Code) CIC Code)
- New Section to fix lack of NOTIFY messages in Examples section. It - New Section to fix lack of NOTIFY messages in Examples section. It
is section 3.21. is section 3.21.
7.5 Changes from v04 to v05
- In section 3.8: Fix of example 5.4.1
- In section 3.9: Answer the problem in the Solution section in a
explicitly way
- In section 3.6: Add new error code that covers the case for Routing
Key already registered
- In section 3.14 the requirement to get "n" ASPs is only applicable
when the AS moves from AS-INACTIVE to AS-ACTIVE
- 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.21: Modify the example 5.2.3 to show the conclusions
from section 3.14 in this IG.
- New section 3.22: Include the recommendation of sending NTFY
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.
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/