Guidelines for Handling Addressing Changes in the AMHS Network

Transcription

1 EUR AMHS Documentation AMHS Addressing Change Guidance Guidelines for Handling Addressing Changes in the AMHS Network Document Reference: Author: EUR AMHS Documentation, AMHS Addressing Change Guidance AFSG Operations Group Revision Number: Version 1.0 Date: 15/04/11 Filename: AMHS Addressing Change Guidance v1.0.doc

2 Document Control Log Edition Date Comments section/pages affected /10/2007 Creation of the document on base of AFSG/PG#29 WP03 and WP04 all /11/2007 Incorporation of editorial comments all /01/2008 Restructuring of the whole document all /02/2008 Renaming of file name, minor editorial changes, missing Figure 2 inserted 2.4.4, 4.8, Figure /03/2008 Editorial improvement after AFSG/PG#31 all /03/2008 Prepared for presentation at AFSG/ /02/2010 Review of the draft AMHS addressing change guidance and incorporation of derived operational procedures (AFSG/12 Task 12) /02/2010 Revised wording of scope and conclusion, refer to Doc 9880, First Edition, merge Chapter 3 and 4 all all /03/2011 Incorporation of comments by OG Chapters 1, /04/2011 Adopted version (AFSG/15) AMHS Addressing Change Guidance page 2 15/04/11

3 Executive Summary This document provides guidance to minimize as much as possible the potential operational impact of AMHS addressing changes on the exchanged traffic at the moment of the change. These guidelines base on the necessity to perform the AMHS addressing changes in a co-ordinated way. Conclusion: Compliance with the Short term Procedures for Global AMHS Address Coordination set in force by ICAO State Letter AN 7/ /34 from 14 April 2009 together with the AMC procedures led down in the ATS Messaging Management Manual and the consideration of the guidelines in chapter 3 of this document will ensure that a required AMHS addressing change will be performed with a minimum impact of the AMHS and s. Additional operational procedures should not be necessary. AMHS Addressing Change Guidance page 3 15/04/11

4 Table of contents 1 INTRODUCTION STRUCTURE OF THE DOCUMENT SCOPE OF THE DOCUMENT CONCLUSION OF THE DOCUMENT AMHS ADDRESSING CHANGES GENERAL ADDRESSING ERROR SITUATIONS POTENTIAL OPERATIONAL IMPACT OF ADDRESSING CHANGES GUIDELINES TO AVOID OPERATIONAL IMPACT WHEN PERFORMING AMHS ADDRESSING CHANGES GENERAL PRINCIPLE MITIGATION OF PROBLEMS DURING AFTN/AMHS ADDRESS CONVERSION X.400 ROUTING RELATED MEASURES General recommendations X.400 Routing for own local users (intra MD routing) X.400 Routing for users in other Management Domains (inter MD routing) GUIDELINE SUMMARY FURTHER MEASURES GLOBAL CO-ORDINATION CONCLUSION A ATTACHMENT A: VALIDATION OF THE ADDRESSING CHANGE GUIDELINES A.1 AN ANSP USING THE XF SCHEMA CHANGES THE PRMD VALUE A.1.1 Messages originated from users (direct or indirect) with new PRMD addressed to users (direct or indirect) A.1.2 Messages originated from users (direct or indirect) addressed to indirect users (with former addresses) A.1.3 Messages originated from users (direct or indirect) addressed to direct users (with former addresses) A.2 AN ANSP USING THE XF SCHEMA MIGRATES TO THE CAAS SCHEMA A.3 AN ANSP USING THE CAAS SCHEMA CHANGES THE PRMD VALUE A.3.1 Messages originated from users (direct or indirect) with new PRMD addressed to users (direct or indirect) A.3.2 Messages originated from users (direct or indirect) addressed to indirect users (with former addresses) A.3.3 Messages originated from users (direct or indirect) addressed to direct users (with former addresses) A.4 AN ANSP USING THE CAAS SCHEMA CHANGES THE MAPPING BETWEEN THE VALUES OF O AND OU1 ATTRIBUTES A.4.1 Messages originated from users (direct or indirect) with new PRMD addressed to users (direct or indirect) A.4.2 Messages originated from users (direct or indirect) addressed to indirect users (with former addresses) A.4.3 Messages originated from users (direct or indirect) addressed to direct users (with former addresses) AMHS Addressing Change Guidance page 4 15/04/11

5 References ICAO Documentation [1] ICAO Annex 10 Aeronautical Telecommunications, Volume II and Volume III [2] ICAO Document 9880, AN/466 Manual on Detailed Technical Specifications for the Aeronautical Telecommunication Network (ATN) using ISO/OSI Standards and Protocols, Part II Ground-Ground Applications Air Traffic Services Message Handling Services (ATSMHS), First Edition 2010 [3] ICAO EUR Doc 020, EUR AMHS Manual [4] ICAO EUR Doc 021, ATS Messaging Management Manual [5] ICAO State Letter - Management and update of air traffic services (ATS) message handling system (AMHS) address information, Ref.: AN 7/ /34 from 14 April 2009 Table of Figures FIGURE 1: COMMUNICATION SCENARIOS AMHS-AMHS AND AMHS-AFTN... 7 FIGURE 2: INFLUENCES OF ACTIVATION TIME AT TWO LOCATIONS FIGURE 3: INFLUENCES OF DIFFERENT ACTIVATION TIMES AT TWO LOCATIONS FIGURE 4: STEPS OF ADDRESSING CHANGES FIGURE 5: VALIDATION CONFIGURATION FIGURE 6: MESSAGE FLOW CASE 1.1: CHANGED PRMD, BUT HASN T MADE THE CHANGES YET FIGURE 7: MESSAGE FLOW CASE 1.2: OPPOSITE DIRECTION FOR INDIRECT USERS FIGURE 8: MESSAGE FLOW CASE 1.3: OPPOSITE DIRECTION FOR DIRECT USERS FIGURE 9: MESSAGE FLOW CASE FIGURE 10: MESSAGE FLOW CASE FIGURE 11: MESSAGE FLOW CASE FIGURE 12: MESSAGE FLOW CASE FIGURE 13: MESSAGE FLOW CASE FIGURE 14: MESSAGE FLOW CASE Index of Tables TABLE 1: GUIDELINE SUMMARY AMHS Addressing Change Guidance page 5 15/04/11

6 1 Introduction 1.1 Structure of the Document The AMHS Addressing Change Guidance consists of 3 Chapters and 1Attachment (4 cases): Chapter 1: Chapter 2: Chapter 3: Structure, scope and conclusion of the document. This Chapter analyses the potential impact of address changes. It describes the potential error situations and provides an analysis of the operational impact in case of addressing synchronisation problems. This Chapter includes the guidelines and validates the global ICAO co-ordination procedure. Attachment A: Validation of the guidelines 1.2 Scope of the Document The proposed guidelines are validated through an analysis of four types of address change This document provides guidance to minimize as much as possible the potential operational impact of AMHS addressing changes on the exchanged traffic at the moment of the change These guidelines base on the necessity to perform the AMHS addressing changes in a co-ordinated way. 1.3 Conclusion of the Document Compliance with the Short term Procedures for Global AMHS Address Coordination set in force by ICAO State Letter AN 7/ /34 from 14 April 2009 together with the AMC procedures led down in the ATS Messaging Management Manual and the consideration of the guidelines in chapter 3 of this document will ensure that a required AMHS addressing change will be performed with a minimum impact of the AMHS and s. Additional operational procedures should not be necessary. AMHS Addressing Change Guidance page 6 15/04/11

7 2 AMHS addressing changes 2.1 General Generally, an AMHS user generating messages has to address them in a correct way to the intended recipients Depending on his placement in the Network an AMHS user is either a or an (see Figure 1) Therefore: a) s have to know the O/R names of the recipients and enter this information into the AMHS message directly. b) s have to know the AFTN address of the recipients. It will be up to the AFTN/AMHS Gateway to convert these AFTN addresses into O/R names If the O/R names are not correct at the recipient side, the messages will not be delivered to the intended recipients, so Non Delivery Reports (NDR) will be generated. Figure 1: Communication scenarios AMHS-AMHS and AMHS-AFTN To avoid Non Delivery Reports (NDR) caused by not correct O/R addresses it would be necessary to analyse the reasons and to take actions to prevent such situations. 2.2 Addressing error situations There are three main causes for which an O/R name may be not correct at the recipient side: AMHS Addressing Change Guidance page 7 15/04/11

8 The O/R name used by the was not appropriate (e.g. the value of one of the fields address attributes was not the correct one). This problem could be occur due to different reasons: i. Typing error if the O/R name was entered directly by the. ii. Incorrect local directory contents at the originator side if the O/R name was selected from such a local directory The recipient O/R name generated by the AFTN/AMHS Gateway (from the AFTN address provided by the ) was not appropriate. This problem could be occur due to different reasons: i. Typing error or incorrect AFTN address entered by the that was anyway converted by the AFTN/AMHS Gateway into an O/R name. ii. Incorrect configuration of the AFTN/AMHS Gateway, so the O/R name resulting from the AFTN conversion was not appropriate The recipient O/R name generated (by the or by the AFTN/AMHS Gateway) was correct when it was generated, but it was not appropriate at the time the message was received at the recipient side. Such situation could occur every time if a change of O/R addresses was performed While the first two causes were influenced by individual faults of the user itself (direct or ) or configuration faults the third cause was created out of the influence and responsibility of the user as originator of the message for which a NDR could be received The reasons of address changes considered in this document are the following: Case 1. A State using the XF schema changes the PRMD value. Example: XX/ICAO/GERMANY (XF) XF: XX/ICAO/DFS (XF) Case 2. A State using the XF schema migrates to the CAAS schema. Example: XX/ICAO/DA (XF) XX/ICAO/DA/DAAA (CAAS) Case 3. A State using the CAAS schema changes the PRMD value. Example: XX/ICAO/GERMANY (CAAS) XF: XX/ICAO/DFS (CAAS) Case 4. A State using the CAAS schema changes the mapping between the values of O and OU1 attributes. Example: XX/ICAO/GERMANY/EDFF (CAAS) XX/ICAO/GERMANY/EDGG (CAAS) Case 5. The location indicator of the CN of the O/R address or the CN itself has changed. Example (1): XX/ICAO/GERMANY/EDGG/EDLL/EDLLZQZX (CAAS) XX/ICAO/GERMANY/EDGG/EDGG/EDGGZQZX (CAAS) AMHS Addressing Change Guidance page 8 15/04/11

9 Example (2): XX/ICAO/GERMANY/EDGG/EDDF/EDDFZTZA (CAAS) XX/ICAO/GERMANY/EDGG/EDDF/EDDFZAZD (CAAS) Case 6. The Nationality Letters of the State have changed. Example: XX/ICAO/AN (XF) XF: XX/ICAO/AU (XF) (different to Case 1 above all location indicators and therefore all AFTN addresses / CN of the State are affected) This document will focus on minimising of the operational impact as result of a synchronisation problem if the above addressing changes are performed. This does not mean that the other potential errors are unlikely to occur, but: a) A typing error is something that may not be avoided by procedures or other measures. As the recipient will be incorrect, it will be most likely impossible to deliver the message. b) Also if the content of local directories and AFTN/AMHS Gateway configuration was not checked prior to its usage in operations that means that the quality controls would fail and errors would be present there it would be impossible to deliver the message as well. 2.3 Potential operational impact of addressing changes The operational impact of addressing changes will differ depending on: the traffic patterns at the time the change is performed, and the timeframe required to make the change in all AMHS centres; The following example should be used to illustrate the influences and the relations causing the operational impact of an addressing change. Starting point: two AMHS systems A and B, with synchronised AFTN/AMHS Gateway addressing mapping tables, exchanging messages between them. One of the two systems (or both, it does not matter) has to implement a change in their addressing mapping tables In Figure 2 it was assumes that the activation of the changed addressing mapping tables will be performed exactly at the same moment (which will be impossible in practical terms). AMHS Addressing Change Guidance page 9 15/04/11

10 Activation of addressing changes To A TZ A t B TZ B t Activation of addressing changes To Figure 2: Influences of activation time at two locations Due to the network delay in the message exchange, the messages generated in A during TZ A will have the old configuration. When these messages arrive to B, B will reject them by generating NDRs for them. The same will apply for the messages generated in B during the TZ B interval It must be pointed out that in case of communication problems between A and B, e.g. messages being queued somewhere, the TZ A and TZ B periods would be longer. Then, a message generated prior to To, having been queued somewhere, and delivered after To, would be rejected by the destination and would generate an NDR Actually, the NDRs will impact the generated messages during TZ A or TZ B that have an address (originator or recipient) impacted by the change Figure 3 reflects the impact to the exchanged traffic if the change has not been activated exactly at the same time. Activation of addressing changes To A TZ A t B TZ B t Activation of addressing changes T1 Figure 3: Influences of different activation times at two locations So, it can be clearly seen that the non coordination of the change activation will, in general terms, increase the number of messages subject to rejection and NDR generation. AMHS Addressing Change Guidance page 10 15/04/11

11 2.3.9 Potential communication problems, resulting in messages being queued somewhere, would also increase the TZ A and TZ B periods. AMHS Addressing Change Guidance page 11 15/04/11

12 3 Guidelines to avoid operational impact when performing AMHS addressing changes 3.1 General principle A well-known principle in communications states: Be strict with what you transmit, be tolerant with what you receive If the rules regarding received traffic are implemented very strictly at the receiving system (system not tolerant), the chances increase to encounter the above mentioned synchronisation problems The application of a strict rule could eventually be accepted if the ones that would be penalised would be just the ones who do not follow it. But this is not the case here. The application of the strict rule would penalise end users (indirect AFTN user, UAs) that are relying on the services provided by other units. And even if all the parties would follow the rules strictly, the end users would be penalised anyway! Therefore, the general principle to be applied should be: Be tolerant in the handling of the O/R names in received messages. This has to be applied in the O/R name to AFTN conversion and in the X.400 Routing. Therefore, this will lead to postponing the rejection of an AMHS message at the last possible point. 3.2 Mitigation of problems during AFTN/AMHS address conversion To mitigate the consequences of the address conversion in the AFTN/AMHS Gateway the processing shall be performed in accordance with [2] This processing was incorporated in Doc 9880 by application of PDR M of Doc 9705 which changed the outcome of the re-conversion checking of the MTCU: In case of address re-conversion checking fails, the action to be performed by the MTCU should be: to transfer the converted message, and to log the address re-conversion error, and to report the error to a control position This allows now that the operational traffic exchange will continue uninterrupted (provided no further errors exist), so the end users would not be impacted and ensures that COM Centres Operators are notified of a discrepancy in the addressing conversion tables amongst the COM Centre(s) involved. The operators are now able to perform the coordination and configuration actions without a strict time constraint (because the traffic continues to be exchanged normally ). Actually, this information could be disregarded by the COM Centre Operators if they arrive near an AIRAC date and provided a loose co-ordination to handle such addressing changes is in place. AMHS Addressing Change Guidance page 12 15/04/11

13 3.2.4 The importance of extracting the AFTN address from the O/R address as indicated in [2] must be stressed. No further checks and actions other than the ones indicated should be done by the AMHS manufacturer s implementation (be tolerant). 3.3 X.400 Routing related measures General recommendations In order to allow addressing changes with minimum (or no) operational impact, the X.400 Routing shall also be considered, especially for the addressing changes listed in The general principle is: All X.400 addresses should be routable during the change process (the ones that are being used before the change and the ones that will be used after the change) The following sections distinguish between the X.400 Routing entries for local users (intra MD routing) and for external users (inter MD routing) X.400 Routing for own local users (intra MD routing) Depending on the configuration of a particular Management Domain, the X.400 Routing Table in the respective AMHS system should contain the following entries related to incoming traffic to be able to route information objects to its own local users: a) Management Domains with one single MTA, one MTCU and no UAs (no s) (regardless of whether they are using XF or CAAS addressing schema): i. Single entry with as few attributes as possible. The Country (XX) and ADMD (ICAO) attributes should be defined especially if they are strictly needed within the X.400 Routing Table. Actually, only the own PRMD attribute should be defined. The entry should not contain the Organisation attribute (CAAS). The entry should route to the AFTN/AMHS Gateway (MTCU) to reach all own " s". b) Management Domains with one single MTA, one MTCU and at least one UA (own s) (regardless of whether they are using XF or CAAS addressing schema) i. One entry per UA. Each entry should be fully qualified (i.e., complete O/R name of the UA). Each entry should route to the corresponding UA. ii. An entry with only the own PRMD attribute should be defined. Eventually, Country and ADMD attributes should be defined (see above). The entry should not contain the Organisation attribute. The entry should route to the AFTN/AMHS Gateway. Actually, this entry would be the default routing for recipients in the own Management Domain (own s) independent if there are any or not. c) Management Domains with multiple MTAs, s (via MTCU) and s (or not). (In this case the CAAS schema will be used.) i. Each MTA should contain entries with the own PRMD (eventually, also with Country and ADMD) and the Organisation attributes to ensure the routing to AMHS Addressing Change Guidance page 13 15/04/11

14 its 'own' (multiple-) MTAs within the MD (in principle, this should be provided for each MTA associated to an Organisation value). Each entry should route to the corresponding MTA. ii. In case there are one or several MTAs with s, the corresponding MTA should contain one entry per UA connected to it. The entry should be fully qualified (i.e., complete O/R name of the UA). Each entry should route to the corresponding UA. iii. Each MTA supporting an AFTN/AMHS Gateway (MTCU) should also contain an entry with only the own PRMD attribute defined. Eventually, Country and ADMD attributes should be defined (see above). The entry should not contain the Organisation attribute. The entry should route to the AFTN/AMHS Gateway associated to the MTA to reach the own " s" independent if there are any or not To ensure the routing of messages in case of an addressing changes without impacting the message exchange further entries, in addition to the previous ones, may be needed in a temporary manner (maintaining of "old" former routing entries for a period of time) The kind of the additional ( old remaining ) entries is depending on the type of addressing change. More details are provided in the attachment (see Attachment A: Validation of the addressing change guidelines) X.400 Routing for users in other Management Domains (inter MD routing) The entries in the X.400 Routing Table to route messages to other Management Domains should also be as generic as possible. In principle, only the PRMD is strictly needed. The Country (XX) and ADMD (ICAO) attributes should be defined especially if they are strictly needed within the X.400 Routing Table. The entries should not contain the Organisation attribute Other entries, in addition to the previous ones, may be needed in a temporary manner to allow handling address changes without impacting the message exchange (maintaining of "old" former external routing entries in intermediate MTAs). More details are provided in Attachment A In case of serving UAs from other Management Domains ( of another (not the own) Management Domain) by an own MTA, the entries should be fully qualified (i.e., complete O/R name of the UA). Each entry should route to the corresponding UA (external ). AMHS Addressing Change Guidance page 14 15/04/11

15 3.4 Guideline summary The different measures from the sections above can be summarised in the following table. Nb. related to Ref. Content of the Guideline G1 general Be tolerant in the handling of the O/R names in received messages. and postpone the rejection of an AMHS message at the latest possible moment. G2 G3 MTCU Address Conversion MTCU Address Conversion G4 X.400 Routing Table G5 X.400 Routing Table G6 X.400 Routing Table G7 X.400 Routing Table G8 X.400 Routing Table G9 X.400 Routing Table G10 X.400 Routing Table If the address re-conversion checking fails, the action should be: Transfer the converted message anyway, and log the error and report to a control position Extract the AFTN address from the O/R address no further checks than the ones indicated should be done in the MTCU by the AMHS manufacturers (be tolerant) , a) The own PRMD attribute routing entry should route to the AFTN/AMHS Gateway. (Management Domains with one single MTA and MTCU) , b) G4 and for each own UA one fully qualified entry (complete O/R name), should route to the corresponding UA. (Management Domains with one single MTA, MTCU and UAs) , c) G4, G5 and the own PRMD and Organisation attribute entries to reach the other MTAs in the own MD (Management Domains with multiple MTAs) Additional own temporary ( old ) PRMD entries (in addition to the previous ones) to ensure the handling of own changed addresses Other PRMD attribute routing entries to route messages to other Management Domains. (Normal inter Management Domain Routing) Additional temporary PRMD entries (in addition to the previous ones) to ensure the handling of address changes of other Management Domains and to route messages, Probes and Reports of them One fully qualified entry per UA (complete O/R name) to route to the corresponding UA. (For UAs of other Management Domains connected to own MTA) Table 1: Guideline summary AMHS Addressing Change Guidance page 15 15/04/11

16 3.5 Further measures In the frame of system procurement, it is advisable to foresee that the AMHS system manufacturers provide system facilities supporting AMHS system Operators in performing addressing changes, especially for: a) Handling of changes impacting s (UAs) This will require facilities like: redirection, forwarding, or other potential alternatives (possibility to configure in the X.400 Routing Tables multiple entries for a single direct user (UA)). b) Handling of AFTN loopbacks between the AFTN and the AFTN/AMHS gateway It is required to have this functionality available in an operationally acceptable way, i.e. by user interface being flexible enough. E.g., the COM Centre Operator wouldn't have to process such loopback messages one by one. c) Import function for 'csv' files provided by AMC It is required to have the ability to import into the local configuration of its AMHS system (and its UAs) the csv files provided by AMC and are valid from one AIRAC Date to the other (AMC Cycle). These are: 3.6 Global co-ordination i. the AMHS MD Register, [4] ( MD look-up Table, [2]) ii. the CAAS Table, [4] ( CAAS look-up Table, [2]) iii. the Addresses, [4] ( address look-up Table, [2]) iv. the Capabilities Management, [4]. The Capability Management could be used as a common "Telephone book" of all s if the CCC Operators enter their existing s in this table completely AMHS requires that configuration tables, especially the AFTN - AMHS conversion tables (required in the MTCU) be consistent worldwide. Failure to have consistent tables can have an impact on operational traffic rejection of messages by NDRs The necessity for a worldwide co-ordination process, in order to ensure proper operations of the AMHS network, has been well recognised Such consistency can be lost every time an addressing change has to be performed in an AMHS system The general stepwise approach to prepare and to implement an address change should be: a) Inform. Worldwide notification of the change. AMHS Addressing Change Guidance page 16 15/04/11

17 b) Prepare. Configuration of new X.400 Routing entries required for the change and the transition period, while the current entries are kept in all systems worldwide (if needed). c) Activate. Configuration and activation of the address changes in all systems worldwide. d) Clean up. Clean up of X.400 Routing entries in all systems worldwide (if needed) The previous steps can be represented in the following figure: Inform Prepare Activate Clean up t Figure 4: Steps of addressing changes This general approach led to a worldwide co-ordination procedure proposed by the EANPG for global consideration With ICAO State Letter [5] the Short term Procedures for Global AMHS Address Coordination were set in force. These procedures consist of: Procedure for major changes Procedure for minor changes Together with the AMC procedures in [6] ATS Messaging Management Manual the Short term Procedures for Global AMHS Address Coordination cover all steps of addressing changes shown in Figure Conclusion Compliance with ICAO State Letter [5] the Short term Procedures for Global AMHS Address Coordination together with the AMC procedures led down in [7] ATS Messaging Management Manual and the consideration of the guidelines in this chapter will ensure that a required AMHS addressing change will be performed with a minimum impact of the AMHS and s. Additional operational procedures are not necessary. AMHS Addressing Change Guidance page 17 15/04/11

18 A Attachment A: Validation of the addressing change guidelines (1) The validation will show, for several address change types, the impact the change would have on the traffic exchanged. (2) The validation will be done using the following configuration: Two MDs a) One with single MTA (with either XF or CAAS schema) b) The other one with multiple MTAs (so with CAAS schema) Each MD has and s (3) This configuration covers all potential message exchange cases that could be encountered in the AMHS network, even if some of them would not be very common (at least in the short and medium term). (4) The configuration is depicted in the following figure: A-D-1 B-D-1 BC-D-1 MTA BC MTA A MTA B BB-D-1 AFTN/AMHS Gateway AFTN/AMHS Gateway MTA BB A-I-1 B-I-1 AFTN/AMHS Gateway BB-I-1 Figure 5: Validation configuration AMHS Addressing Change Guidance page 18 15/04/11

19 (5) The following sections will analyse the impact of Domain and using non synchronised addressing information, due to a change implemented in one Domain, but not in the other. (6) The impact will be analysed for the following changes: 1. An ANSP using the XF schema changes the PRMD value. (A.1) 2. An ANSP using the XF schema migrates to the CAAS schema (A.2) a) without changing of the PRMD value b) changing of the PRMD value. 3. An ANSP using the CAAS schema changes the PRMD value. (A.3) 4. An ANSP using the CAAS schema changes the mapping between the values of O and OU1 attributes (A.4) (7) There are always at least two tables involved and eventually even three: a) Address look-up tables (MD Look-up Table and CAAS Look-up Table for the address translation in the MTCU b) X.400 Routing Table(s) in the MTA(s) c) the third could be: the Address books of the direct users A.1 An ANSP using the XF schema changes the PRMD value In this case, will change its PRMD. Let us assume the change has been implemented in, but not yet in. The impact for the different cases will be as follows: A.1.1 Messages originated from users (direct or indirect) with new PRMD addressed to users (direct or indirect) MTCU A MTA A MTA B MTCU B 1 PR temporary changed X.400 Routing Table of MTA A PR X.400 Routing Table of MTA B Figure 6: Message flow case 1.1: changed PRMD, but hasn t made the changes yet (1) The messages will be received and processed normally, even if has not applied the corresponding addressing changes (G4, G5, G6). (2) The operators in will be informed, through the control position, that messages for indirect users are being received "with incorrect originator" (G2/G3) ( s will receive the message with a wrong originator, but the Operator is not informed automatically.) (3) It may be needed that MTAs introduce, prior to the change activation in, an entry in their X.400 Routing Tables, to define the new PRMD value in order to prevent the direct rejection of messages by the MTAs themselves.(g9) (Especially to route Reports in general). AMHS Addressing Change Guidance page 19 15/04/11

20 A.1.2 Messages originated from users (direct or indirect) addressed to indirect users (with former addresses) MTCU A MTA A MTA B MTCU B temporary changed 1 PR X.400 Routing Tables PR Figure 7: Message flow case 1.2: opposite direction for indirect users (1) The X.400 Routing Table of should contain, for a temporary period, two entries to handle the incoming traffic: one with the new PRMD value and the other with the former PRMD value (G7). The entry with the former PRMD value has to be retained for the time needed to allow all AMHS systems worldwide to update their addressing. (2) The messages will be received and processed normally in. The operators in will be informed, through the control position, that messages are being received with incorrect addressing (G2/G3). A.1.3 Messages originated from users (direct or indirect) addressed to direct users (with former addresses) MTCU A MTA A MTA B MTCU B (1) b) i) temporary changed 1 PR X.400 Routing Tables PR Figure 8: Message flow case 1.3: opposite direction for s (1) Depending on the X.400 implementation, there are two possibilities: a) The X.400 implementation offers a mechanism to allow addressing an UA with different O/R names. This could be done, as e.g., with redirection, forwarding, or other potential alternatives (e.g. possibility to configure in the X.400 Routing Tables multiple entries for a single direct user (UA)). In such a case, will have to update the X.400 Routing Table for each UA in order to contain the new fully qualified O/R name of the UA. And at the same time, will have to configure, depending on the facility available, additional entries in the appropriate configuration tables (e.g. in a redirection table, or in a forwarding table) to allow messages addressed to the former addresses still be properly routed. The additional entries have to be kept for the time needed to allow all AMHS systems worldwide to update their addressing. In such a case, the messages will be received and processed normally in AMHS Addressing Change Guidance page 20 15/04/11

21 . The operators in will not be informed that messages are being received with incorrect addressing. b) The X.400 implementation does not allow addressing a UA with different O/R names. Due to the X.400 Routing configuration (G7), these messages will be sent by MTA A to the AFTN/AMHS gateway, which will convert them to AFTN messages 1. The operators in will be informed, through the control position, that messages are being received with incorrect addressing (G2/G3). In principle, the AFTN part should route them back to the AFTN/AMHS gateway. Depending on the implementation, these messages could be: (i) (ii) either routed back to the AFTN/AMHS gateway, where the recipient address will be converted to the appropriate O/R name, so that the messages are forwarded to MTA A, which would forward them to the. In this case, the messages would reach their intended recipient. or put in a special queue for operator intervention (because the AFTN part will detect a loop-back situation and will prevent it). A.2 An ANSP using the XF schema migrates to the CAAS schema (1) While performing this change, the ANSP has two choices: a) Keep the same PRMD as before; b) Use another PRMD. (2) If it is decided to use another PRMD ( (1) b) ), the impact of the change will be the same as the one described in a previous section (cf. A.1). (3) If it is decided to maintain the same PRMD ( (1) a) ): a) No temporary entries in X.400 Routing Tables will be needed in for traffic originated in and sent to recipients. b) No temporary entries in X.400 Routing Tables will be needed in for traffic originated in addressed to indirect users. c) The impact of the change will be the same as before for traffic originated in addressed to direct users (cf. A.1.3). A.3 An ANSP using the CAAS schema changes the PRMD value (1) Provided the ANSP performing the change has a single MTA in its Management Domain, the impact of the change will be strictly the same as the one described in An ANSP using the XF schema changes the PRMD value (it has to be considered that is the ANSP performing the change) (cf. A.1). (2) In case the ANSP performing the change has several MTAs in its Management Domain, the impact will be as follows: In this case, is the ANSP performing the change; we assume it has already been implemented in but not yet in. 1 But only, if the message meets all requirements to be converted into AFTN. Otherwise it will be rejected by means of a NDR. AMHS Addressing Change Guidance page 21 15/04/11

22 A.3.1 Messages originated from users (direct or indirect) with new PRMD addressed to users (direct or indirect) MTCU A MTA A MTA B MTCU B PR PR1 PR MTA BB X.400 Routing Tables temporary changed PR1 Figure 9: Message flow case 3.1 (1) The messages will be received and processed normally, even if has not applied the corresponding addressing changes. The operators in will be informed, through the control position, that messages for indirect users are being received with incorrect addressing (G2/G3). ( s will receive the message with a wrong originator, but the Operator is not informed automatically.) (2) It may be needed that the MTA has defined, prior to the change activation in, an entry in its X.400 Routing Tables to define the new PRMD value to prevent the messages being rejected directly by the MTA itself. (G9) (Especially to route Reports; similar case as described in A.1.1) A.3.2 Messages originated from users (direct or indirect) addressed to indirect users (with former addresses) MTCU A MTA A MTA B MTCU B PR PR1 PR MTA BB X.400 Routing Tables temporary changed PR1 Figure 10: Message flow case 3.2 (1) In this case, attention shall be paid to the fact that MTAs have X.400 Routing Tables that have to handle the intra-domain MTA routing. (2) The X.400 Routing Table of MTAs should contain, for a temporary period, additional entries to handle the incoming traffic: they shall keep the entries with the former PRMD value and new entries have to be added with the new PRMD value (G7). The entries with the former PRMD value have to be kept for the time needed to allow all AMHS systems worldwide to update their addressing. AMHS Addressing Change Guidance page 22 15/04/11

23 (3) The messages will then be received and processed normally in as before. The operators in will be informed, through the control position, that messages are being received with incorrect addressing (G2/G3). (Similar case as in A.1.2) A.3.3 Messages originated from users (direct or indirect) addressed to direct users (with former addresses) MTCU A MTA A MTA B MTCU B (3) b) i) PR PR1 PR MTA BB X.400 Routing Tables temporary changed PR1 Figure 11: Message flow case 3.3 (1) In this case, attention shall be paid to the fact that MTAs have X.400 Routing Tables that have to handle the intra-domain MTA routing. (2) In addition to duplication of entries in MTAs like before, for the purposes of intradomain MTA routing, additional entries in the X.400 Routing Table may also be needed in each MTA for the UAs managed by them (it has to be ensured that X.400 Routing in the MD B domain is ensured for former and new addresses). (3) Depending on the X.400 implementation, there are two possibilities: a) The X.400 implementation offers a mechanism to allow addressing a UA with different O/R names. This could be done, as e.g., with redirection, forwarding, or other potential alternatives (e.g. possibility to configure in the X.400 Routing Tables multiple entries for a single direct user (UA)). In such a case, the MTA hosting the UA (MTA B, MTA BB, MTA BC) will have to update the X.400 Routing Table for the UA in order to contain the new fully qualified O/R name of the UA. At the same time, such MTAs (MTA B, MTA BB, MTA BC) 2 will have to configure, depending on the facility available, additional entries in the appropriate configuration tables (e.g. in a redirection table, or in a forwarding table) to allow messages addressed to the former addresses to still be properly routed. The additional entries have to be kept for the time needed to allow all AMHS systems worldwide to update their addressing. In such a case, the messages will be received and processed normally in. The operators in will not be informed that messages are being received with incorrect addressing. b) If the MTA hosts an AFTN/AMHS gateway, the X.400 Routing configuration of that MTA will have these messages sent to the AFTN/AMHS gateway (provided the former default routing entry is kept in a temporary manner) (G7). If the 2 There can be, depending on the available facilities, several possibilities: In case of redirection or forwarding, such entries might be configured in MTA B instead of MTA BB and MTA BC. This option would require less temporary X400 routing entries to be defined in MTA B. AMHS Addressing Change Guidance page 23 15/04/11

24 MTA does not contain an AFTN/AMHS gateway, the incoming messages addressed to the former addresses will be rejected by the MTA (with the generation of the corresponding NDR) 3. Regarding the messages that could have been sent to the AFTN/AMHS gateways, these message could be: (i) (ii) either routed back to the AFTN/AMHS gateway, where the recipient addresses will be converted to the appropriate O/R name, so the messages are forwarded to the MTA, which would forward them to the s. In this case, the messages would reach their intended recipients. or put in a special queue for operator intervention (because the AFTN part will detect a loopback situation and will prevent it). A.4 An ANSP using the CAAS schema changes the mapping between the values of O and OU1 attributes (1) This case presents quite a large number of different sub-cases due to different combinations that can happen between: a) Management Domain architectures: single MTA or multiple MTAs; and if multiple MTAs, single or several AFTN/AMHS gateways b) and indirect users c) Type of change: Addition of new O value(s) while keeping the previous ones Change existing O values by new ones Keep existing O values and change mapping of O OU1 values Combinations between the above. (2) It is therefore impossible to analyse all the different combinations, especially in the case of Management Domains with multiple MTAs. (3) However, it can be expected that the impact of such a change would not be very different from what is described in the previous case ( An ANSP using the CAAS schema changes the PRMD value ). (4) If the ANSP has a single MTA (the most common case), regardless of the type of change performed, the impact will be as follows: In this case, is the ANSP performing the change; we assume it has already been implemented in but not yet in. 3 This rejection could be avoided by configuring in the MTA with international connectivity (MTA B in the figure) an entry in its X400 routing table to have all traffic addressed to the former PRMD being routed to a MTA with AFTN/AMHS gateway. AMHS Addressing Change Guidance page 24 15/04/11

25 A.4.1 Messages originated from users (direct or indirect) with new PRMD addressed to users (direct or indirect) MTCU A MTA A MTA B MTCU B PR PRMD=B PR/ O=BB1 MTA BB X.400 Routing Tables temporary changed PRMD=B/O=BB1 Figure 12: Message flow case 4.1 (1) The messages will be received and processed normally, even if has not applied the corresponding addressing changes. The operators in will be informed, through the control position, that messages for indirect users are being received with incorrect addressing. (G2/G3). (2) s will receive the message with a wrong originator, but the Operator is not informed automatically. (3) NDRs or RN will be routed correctly. A.4.2 Messages originated from users (direct or indirect) addressed to indirect users (with former addresses) MTCU A MTA A MTA B MTCU B PR PRMD=B PR/ O=BB1 MTA BB X.400 Routing Tables temporary changed PRMD=B/O=BB1 Figure 13: Message flow case 4.2 (1) If has no direct users, there should be no problem. The messages will then be received and processed normally in as before. The operators in will be informed, through the control position, that messages are being received with incorrect addressing (G2/G3). (2) If has direct users there should be no problem, as long as the change does not introduce any conflict between the direct and indirect user addresses (i.e., the former and new O/R names for the direct users in are not the equal to existing former or new O/R names for indirect users). If this is the case, the messages will then be received and processed AMHS Addressing Change Guidance page 25 15/04/11

26 normally in as before. The operators in will be informed, through the control position, that messages are being received with incorrect addressing (G2/G3). (3) If the change introduces a conflict between direct and indirect users (that means you cannot distinguish between direct and indirect user addresses by the new or changed O value) no measures can be taken to avoid NDRs. In limited cases you can define for "old" user O/R addresses a routing to the MTCU (G7/G9) so that the processing according to A.1.3/A.3.3 is initiated. A.4.3 Messages originated from users (direct or indirect) addressed to direct users (with former addresses) MTCU A MTA A MTA B MTCU B (2) b) i) PR PRMD=B PR/ O=BB1 MTA BB X.400 Routing Tables temporary changed PRMD=B/O=BB1 Figure 14: Message flow case 4.3 (1) It is assumed, as before, that the change does not introduce any conflict between the direct and indirect user addresses. (2) If this is the case, depending on the X.400 implementation, there are two possibilities: a) The X.400 implementation offers a mechanism to allow addressing a UA with different O/R names. This could be done, as e.g., with redirection, forwarding, or other potential alternatives (e.g. possibility to configure in the X.400 Routing Tables multiple entries for a single direct user (UA)). In such a case, the MTA hosting the UA (MTA B, MTA BC) will have to update the X.400 Routing Table for the UA in order to contain the new fully qualified O/R name of the UA. At the same time, such MTAs (MTA B, MTA BB, MTA BC) 4 will have to configure, depending on the facility available, additional entries in the appropriate configuration tables (e.g. in a redirection table, or in a forwarding table) to allow messages addressed to the former addresses to still be properly routed. The additional entries have to be kept for the time needed to allow all AMHS systems worldwide to update their addressing. In such a case, the messages will be received and processed normally in. The operators in will not be informed that messages are being received with incorrect addressing. b) The X.400 implementation does not allow to address a UA with different O/R names. Due to the X.400 Routing configuration, the message will be sent by the MD MTA to 4 There can be, depending on the available facilities, several possibilities: In case of redirection or forwarding, such entries might be configured in MTA B instead of MTA BB and MTA BC. This option would require less temporary X400 routing entries to be defined in MTA B. AMHS Addressing Change Guidance page 26 15/04/11

27 the AFTN/AMHS gateway (G7), which will convert to an AFTN message. The operators in will be informed, through the control position, that messages are being received with incorrect addressing (G2/G3). In principle, the AFTN part should route it back to the AFTN/AMHS gateway. Depending on the implementation, this message could be: (i) (ii) either routed back to the AFTN/AMHS gateway, where the recipient addresses will be converted to the appropriate O/R name, so the messages are forwarded to the MTA, which would forward them to the s. In this case, the messages would reach their intended recipients; or put in a special queue for operator intervention (because the AFTN part will detect a loop-back situation and will prevent it). (3) If the change introduces a conflict between direct and indirect users (that means you cannot distinguish between direct and indirect user addresses by the new or changed O value) no measures can be taken to avoid NDRs. In limited cases you can define for "old" user O/R addresses a routing to the MTCU (G7/G9), so that the processing according to A.1.3/A.3.3 is initiated. End of document AMHS Addressing Change Guidance page 27 15/04/11