idnits 2.17.1 draft-ietf-sigtran-sua-implementor-guide-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1333. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC3868], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 346: '... The SGP SHOULD respond to a DAUD me...' RFC 2119 keyword, line 364: '... The SGP SHOULD respond to a DAUD me...' RFC 2119 keyword, line 744: '...tion Addresses but MUST NOT mix Source...' RFC 2119 keyword, line 761: '...tion Addresses but MUST NOT mix Source...' RFC 2119 keyword, line 853: '...Error messages MUST NOT be generated i...' (14 more instances...) -- The abstract seems to indicate that this document updates RFC3868, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 892 has weird spacing: '...be used for t...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 10, 2006) is 6375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC3868' on line 1203 == Missing Reference: '1123' is mentioned on line 401, but not defined -- Looks like a reference, but probably isn't: 'RFC1035' on line 409 == Unused Reference: '2' is defined on line 1216, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Signalling Transport Working group L. Coene 3 Internet-Draft Siemens 4 Intended status: Informational J. Loughney 5 Expires: May 14, 2007 Nokia 6 November 10, 2006 8 SUA Implementor's guide 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 14, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document contains a compilation of all defects found up until 43 the publication date for SUA [RFC3868] [1]. These defects may be of 44 an editorial or technical nature. This document may be thought of as 45 a companion document to be used in the implementation of SUA to 46 clarify errors in the original SUA document. This document updates 47 RFC3868 and text within this document supersedes the text found in 48 RFC3868. 50 Table of Contents 52 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 54 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2 Correction to RFC3868 . . . . . . . . . . . . . . . . . . . . . 6 56 2.1 Routing context list in connectionless and 57 connectionoriented messages . . . . . . . . . . . . . . . . 6 58 2.1.1 Description of the problem . . . . . . . . . . . . . . 6 59 2.1.2 Text changes to the document . . . . . . . . . . . . . 6 60 2.1.3 Solution description . . . . . . . . . . . . . . . . . 6 61 2.2 Congestion level parameter value . . . . . . . . . . . . . 6 62 2.2.1 Description of the problem . . . . . . . . . . . . . . 6 63 2.2.2 Text changes to the document . . . . . . . . . . . . . 7 64 2.2.3 Solution description . . . . . . . . . . . . . . . . . 8 65 2.3 Segmentation parameter value . . . . . . . . . . . . . . . 8 66 2.3.1 Description of the problem . . . . . . . . . . . . . . 8 67 2.3.2 Text changes to the document . . . . . . . . . . . . . 8 68 2.3.3 Solution description . . . . . . . . . . . . . . . . . 9 69 2.4 DAUD response message ordering . . . . . . . . . . . . . . 9 70 2.4.1 Description of the problem . . . . . . . . . . . . . . 9 71 2.4.2 Text changes to the document . . . . . . . . . . . . . 9 72 2.4.3 Solution description . . . . . . . . . . . . . . . . . 10 73 2.5 Host name parameter . . . . . . . . . . . . . . . . . . . . 10 74 2.5.1 Description of the problem . . . . . . . . . . . . . . 10 75 2.5.2 Text changes to the document . . . . . . . . . . . . . 10 76 2.5.3 Solution description . . . . . . . . . . . . . . . . . 11 77 2.6 ASP routing context . . . . . . . . . . . . . . . . . . . . 11 78 2.6.1 Description of the problem . . . . . . . . . . . . . . 11 79 2.6.2 Text changes to the document . . . . . . . . . . . . . 11 80 2.6.3 Solution description . . . . . . . . . . . . . . . . . 11 81 2.7 Parameters should only occur once in a message . . . . . . 12 82 2.7.1 Description of the problem . . . . . . . . . . . . . . 12 83 2.7.2 Text changes to the document . . . . . . . . . . . . . 12 84 2.7.3 Solution description . . . . . . . . . . . . . . . . . 12 85 2.8 TID label parameter . . . . . . . . . . . . . . . . . . . . 12 86 2.8.1 Description of the problem . . . . . . . . . . . . . . 12 87 2.8.2 Text changes to the document . . . . . . . . . . . . . 13 88 2.8.3 Solution description . . . . . . . . . . . . . . . . . 14 89 2.9 DRM label parameter . . . . . . . . . . . . . . . . . . . . 14 90 2.9.1 Description of the problem . . . . . . . . . . . . . . 14 91 2.9.2 Text changes to the document . . . . . . . . . . . . . 14 92 2.9.3 Solution description . . . . . . . . . . . . . . . . . 15 93 2.10 Usage of the TID and DRN label . . . . . . . . . . . . . . 15 94 2.10.1 Description of the problem . . . . . . . . . . . . . . 15 95 2.10.2 Text changes to the document . . . . . . . . . . . . . 16 96 2.10.3 Solution description . . . . . . . . . . . . . . . . . 18 97 2.11 Address Range paramete . . . . . . . . . . . . . . . . . . 18 98 2.11.1 Description of the problem . . . . . . . . . . . . . . 18 99 2.11.2 Text changes to the document . . . . . . . . . . . . . 19 100 2.11.3 Solution description . . . . . . . . . . . . . . . . . 19 101 2.12 Interpretation of the mask parameter . . . . . . . . . . . 20 102 2.12.1 Description of the problem . . . . . . . . . . . . . . 20 103 2.12.2 Text changes to the document . . . . . . . . . . . . . 20 104 2.12.3 Solution description . . . . . . . . . . . . . . . . . 21 105 2.13 Reply on errors contained in a error message . . . . . . . 21 106 2.13.1 Description of the problem . . . . . . . . . . . . . . 21 107 2.13.2 Text changes to the document . . . . . . . . . . . . . 21 108 2.13.3 Solution description . . . . . . . . . . . . . . . . . 22 109 2.14 Use of stream 0 for SSNM messages . . . . . . . . . . . . . 22 110 2.14.1 Description of the problem . . . . . . . . . . . . . . 22 111 2.14.2 Text changes to the document . . . . . . . . . . . . . 22 112 2.14.3 Solution description . . . . . . . . . . . . . . . . . 23 113 2.15 Timer Ta does not exist . . . . . . . . . . . . . . . . . . 23 114 2.15.1 Description of the problem . . . . . . . . . . . . . . 23 115 2.15.2 Text changes to the document . . . . . . . . . . . . . 23 116 2.15.3 Solution description . . . . . . . . . . . . . . . . . 24 117 2.16 Error response on unsupported RKM messages . . . . . . . . 24 118 2.16.1 Description of the problem . . . . . . . . . . . . . . 24 119 2.16.2 Text changes to the document . . . . . . . . . . . . . 24 120 2.16.3 Solution description . . . . . . . . . . . . . . . . . 26 121 2.17 Filler/padding in Global title parameter . . . . . . . . . 26 122 2.17.1 Description of the problem . . . . . . . . . . . . . . 26 123 2.17.2 Text changes to the document . . . . . . . . . . . . . 27 124 2.17.3 Solution description . . . . . . . . . . . . . . . . . 28 125 2.18 Inclusion of routing context in the Routing key 126 parameter . . . . . . . . . . . . . . . . . . . . . . . . . 28 127 2.18.1 Description of the problem . . . . . . . . . . . . . . 28 128 2.18.2 Text changes to the document . . . . . . . . . . . . . 28 129 2.18.3 Solution description . . . . . . . . . . . . . . . . . 29 130 2.19 New registration status parameter value . . . . . . . . . . 29 131 2.19.1 Description of the problem . . . . . . . . . . . . . . 29 132 2.19.2 Text changes to the document . . . . . . . . . . . . . 30 133 2.19.3 Solution description . . . . . . . . . . . . . . . . . 31 134 3 Security considerations . . . . . . . . . . . . . . . . . . . . 32 135 4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 33 136 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 137 Appendix A Changes Control . . . . . . . . . . . . . . . . . . . 35 138 A.1 Changes from v00 to v01 . . . . . . . . . . . . . . . . . . 35 139 A.2 Changes from v01 to v02 . . . . . . . . . . . . . . . . . . 35 140 A.3 Changes from v02 to v03 . . . . . . . . . . . . . . . . . . 35 141 A.4 Changes from v03 to v04 . . . . . . . . . . . . . . . . . . 36 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 143 Intellectual Property and Copyright Statements . . . . . . . . . . 38 145 1 INTRODUCTION 147 This document contains a compilation of all defects found up until 148 the publication date for the SCCP User Adaptation Layer (SUA) 149 [RFC3868]. These defects may be of an editorial or technical nature. 150 This document may be thought of as a companion document to be used in 151 the implementation of SUA to clarify errors in the original SUA 152 document. This document updates RFC3868 and text within this 153 document, where noted, supersedes the text found in RFC3868. Each 154 error will be detailed within this document in the form of: 156 o The problem description, 158 o The text quoted from RFC3868, 160 o The replacement text, 162 o A description of the solution. 164 1.1 Terminology 166 The terms are commonly identified in related work SUA [RFC3868] [1]. 168 1.2 Conventions 169 2 Correction to RFC3868 171 2.1 Routing context list in connectionless and connectionoriented 172 messages 174 2.1.1 Description of the problem 176 The routing context parameter of a connectionless and 177 connectionoriented message can contain a list of routing contexts. 178 Normaly, the addressing info present in the message will yield only a 179 single routing context. A list of routing contexts is valid only for 180 SSNM, ASPTM and RKM messages 182 2.1.2 Text changes to the document 184 --------- 185 Old text: (Section 3.9.6) 186 --------- 188 The Routing Context parameter contains (a list of) 4-byte unsigned 189 integers indexing the Application Server traffic that the sending ASP 190 is configured/registered to receive. There is a one-to-one 191 relationship between an index entry and a Routing Key or AS Name. 193 --------- 194 New text: (Section 3.9.6) 195 --------- 197 The Routing Context parameter contains (a list of) 4-byte unsigned 198 integers indexing the Application Server traffic that the sending ASP 199 is configured/registered to receive. There is a one-to-one 200 relationship between an index entry and a Routing Key or AS Name. 202 A list of routing contexts is only valid for SSNM, ASPTM and RKM 203 messages. All other messages can contain only a single Routing 204 Context. 206 2.1.3 Solution description 208 Only 1 routing context value may be included in the routing context 209 parameter of a connectionless and connectionoriented message. 211 2.2 Congestion level parameter value 213 2.2.1 Description of the problem 215 The value of the congestion level is dependant on which info is 216 present in the SCON message. If the SCON only contains the affected 217 pointcode, then the congestion level has values ranging between 0 and 218 3. If affected pointcode and subsystemnumber is included in the SCON 219 message, then the value of the congestion level can be between 1 and 220 8. 222 2.2.2 Text changes to the document 224 --------- 225 Old text: (Section 3.10.24) 226 --------- 228 When the Congestion Level parameter is included in a SCON message 229 that corresponds to an N-PCSTATE primitive, the Congestion Level 230 field indicates the MTP congestion level experienced by the local or 231 affected signalling point as indicated by the Affected Point Code(s) 232 also in the SCON message. In this case, valid values for the 233 Congestion Level field are as follows: 235 0 No Congestion or Undefined 236 1 Congestion Level 1 237 2 Congestion Level 2 238 3 Congestion Level 3 240 When the Congestion Level parameter is included in a SCON messagethat 241 corresponds to an N-STATE primitive, the Congestion Level field 242 indicates the SCCP restricted importance level experienced by the 243 local or affected subsystem as indicated by the Affected Point Code 244 and Subsystem Number also in the SCON message. In this case, valid 245 values for the Congestion Level field range from 0 to 7, where 0 246 indicates the least congested and 7 indicates the most congested 247 subsystem. 249 --------- 250 New text: (Section 3.10.24) 251 --------- 253 2 different congestion levels ranges can be used accoring to ITU and 254 ANSI congestion control algorithms. 256 When the ANSI congestion control algorithm is used, the Congestion 257 Level field indicates the MTP congestion level as experienced by the 258 local or affected subsystem indicated by the Affected Point Code and 259 Subsystem Number. In this case, valid values for the Congestion 260 Level field range from 0 to 3, where 1 indicates the least congested 261 and 3 indicates the most congested condition. 263 0 No Congestion or Undefined 264 1 Congestion Level 1 265 2 Congestion Level 2 266 3 Congestion Level 3 268 When the ITU congestion control algorithm is used, the Congestion 269 Level field indicates the SCCP restricted importance level 270 experienced by the local or affected subsystem as indicated by the 271 Affected Point Code and Subsystem Number also in the SCON message. 272 In this case, valid values for the Congestion Level field range from 273 1 to 8, where 1 indicates the least congested and 8 indicates the 274 most congested condition. 276 2.2.3 Solution description 278 The ITU SCCP congestion control procedures are described in SCCP 279 procedures [Q.714] [4] paragraph 2.6. The ANSI SCCP congestion 280 control procedures are described in SCCP procedures [T1.112.4] [5] 281 paragraph 5.2.4. 283 The SCC message in SCCP takes the value range 1..8, so the 284 corresponding SCON should also be in that range. To indicate no 285 congestion, it is sufficient to send only a DAVA. 287 2.3 Segmentation parameter value 289 2.3.1 Description of the problem 291 The original sequence delivery option as original demanded(= before 292 the segementing) by the SCCP application is not preserved after 293 segmentation. The receiving SCCP application will always receive the 294 message with sequenced delivery option set to 1. 296 2.3.2 Text changes to the document 298 --------- 299 Old text: (Section 3.10.23) 300 --------- 302 The first/remaining segments field is formatted as follows: 304 o bit 8 (MSB) : indicates whether this is the first segment (1) or 305 not (0) 307 o bits 1-7: indicate the number of remaining segments, value between 308 0 and 15 310 --------- 311 New text: (Section 3.10.23) 312 --------- 314 The segmentation paramter consists of the following: 316 o bit 0: first/remaing segment bit: first = 1, remaining = 0 318 o bit 1: sequence delivery option as original demanded(= before the 319 segementing) by the SCCP application. class 0 = 0, class 1 = 1. 321 o bit 2-3: spare 323 o bit 4-7: number of remaining segments(4 bits, values 0 -15) 325 o bit 8-31:segmentation reference(3 byte integer) 327 2.3.3 Solution description 329 The segmentation parameter gets a extra bit(out of the spare bits 330 present) indicating the original requested sequence delivery option 331 as originally demanded by the sending SCCP application. 333 2.4 DAUD response message ordering 335 2.4.1 Description of the problem 337 Should a SCON be send before the DAVA or DRST or after? The SCON is 338 send first and DAVA/DRST after in M3UA. 340 2.4.2 Text changes to the document 342 --------- 343 Old text: (Section 4.5.3) 344 --------- 346 The SGP SHOULD respond to a DAUD message with the availability and 347 congestion status of the subsystem. The status of each SS7 348 destination or subsystem requested is indicated in a DUNA message (if 349 unavailable), a DAVA message (if available), or a DRST (if restricted 350 and the SGP supports this feature). If the SS7 destination or 351 subsystem is available and congested, the SGP responds with an SCON 352 message in addition to the DAVA message. If the SS7 destination or 353 subsystem is restricted and congested, the SGP responds with an SCON 354 message in addition to the DRST. If the SGP has no information on 355 the availability / congestion status of the SS7 destination or 356 subsystem, the SGP responds with a DUNA message, as it has no routing 357 information to allow it to route traffic to this destination or 358 subsystem. 360 --------- 361 New text: (Section 4.5.3) 362 --------- 364 The SGP SHOULD respond to a DAUD message with the availability and 365 congestion status of the subsystem. The status of each SS7 366 destination or subsystem requested is indicated in a DUNA message (if 367 unavailable), a DAVA message (if available), or a DRST (if restricted 368 and the SGP supports this feature). If the SS7 destination or 369 subsystem is available and congested, the SGP responds with an SCON 370 message and a DAVA message. If the SS7 destination or subsystem is 371 restricted and congested, the SGP responds with an SCON message and a 372 DRST. If the SGP has no information on the availability / congestion 373 status of the SS7 destination or subsystem, the SGP responds with a 374 DUNA message, as it has no routing information to allow it to route 375 traffic to this destination or subsystem. 377 2.4.3 Solution description 379 The DAVA/DUNA/DRST/SCON messages may be send in random order. 380 However if a SCON is send first and the destination is inaccessible, 381 the SCON will be dropped. So it might be better to send the DAVA 382 first followed by the SCON. 384 2.5 Host name parameter 386 2.5.1 Description of the problem 388 The hostname is actually a Fully Qualified Domain Name(FQDN) as 389 defined in RFC1983. The definition of the hostname(as found in 390 RFC1983) would only allow for a part of the FQDN and that does not 391 uniquely identify a endpoint. Also the encoding of the FQDN is not 392 clear. 394 2.5.2 Text changes to the document 396 --------- 397 Old text: (Section 3.10.2.7) 398 --------- 400 This field contains a host name in "host name syntax" per RFC 1123 401 Section 2.1 [1123]. The method for resolving the host name is out of 402 scope for this document. 404 --------- 405 New text: (Section 3.10.2.7) 406 --------- 408 This field contains a host name in "Fully Qualified Domain Name 409 syntax" per RFC 1035 section 3.1 [RFC1035] [3]. The method for 410 resolving the host name is out of scope for this document. 412 2.5.3 Solution description 414 The hostname is actually a Fully Qualified Domain Name(FQDN) which 415 should be encoded following the RFC1035 section 3.1 coding rules. 417 2.6 ASP routing context 419 2.6.1 Description of the problem 421 An ASP routes responses to the SGP that it received messages from; 422 within the routing context which it is currently active and receiving 423 traffic. 425 2.6.2 Text changes to the document 427 --------- 428 Old text: (Section 1.5.2) 429 --------- 431 An ASP routes responses to the SGP that it received messages from; 432 within the routing context which it is currently active and receiving 433 traffic. 435 --------- 436 New text: (Section 1.5.2) 437 --------- 439 An ASP routes responses to the SGP that it received messages from. 440 The reponse will utilize the routing context from the received 441 messages. 443 2.6.3 Solution description 445 a. A routing context is an integer which is significant only for a 446 given SGP-ASP pair. So it is circular logic to say that the ASP 447 should use the RC to select the SGP - an RC value is meaningful only 448 after the SGP has already assigned the RC for the the msg send to the 449 ASP. 451 b. An ASP can be active vis-a-vis an SGP for more than one RC - so 452 it is not meaningful to say that the ASP uses "the" RC for which it 453 is active. If the ASP response to a messages, it has to use the RC 454 of that received message in the reponse. 456 2.7 Parameters should only occur once in a message 458 2.7.1 Description of the problem 460 Parameters in SUA messages can be repeated as many times as possible. 461 This would lead to inconsistencies, such as 2 or more destination 462 addresses. 464 2.7.2 Text changes to the document 466 --------- 467 Old text: (Section x.x) 468 --------- 470 --------- 471 New text: (Section x.x) 472 --------- 474 2.7.3 Solution description 476 Unless explicitly stated or shown in a message format diagram, only 477 one parameter of the same type is allowed in a message. 479 2.8 TID label parameter 481 2.8.1 Description of the problem 483 The clarity of the definition of TID label parameters is unclear. 485 2.8.2 Text changes to the document 487 --------- 488 Old text: (Section 3.10.16) 489 --------- 490 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Tag = 0x0110 | Length = 8 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | start | end | label value | 495 +---------------+---------------+-------------------------------+ 497 The Start parameter is the start position of label, between 0 (LSB) 498 and 31 (MSB). 500 The End parameter is the end position of label, between 0 (LSB) and 501 31 (MSB). 503 Label value is a 16-bit integer, which is unique across an AS. 505 --------- 506 New text: (Section 3.10.16) 507 --------- 508 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Tag = 0x0110 | Length = 8 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | start | end | label value | 513 +---------------+---------------+-------------------------------+ 515 The Start parameter is the start position of label, between 0 (LSB) 516 and 31 (MSB). 518 The End parameter is the end position of label, between 0 (LSB) and 519 31 (MSB). 521 Label value is a 16-bit integer, which is unique across an AS. The 522 label value has to match the TCAP transaction ID between the start 523 and the end parameter(Logical AND operation). The rest of the TCAP 524 transaction ID between 0 and the begin parameter(if begin parameter 525 > 0) AND the end parameter(if end parameter value < 31) and 31 is 526 wildcarded. 527 An ASP that registers a label will be sent only those TID-bearing 528 messages that match its label. 529 An ASP that does not register a label may be sent any TID-bearing 530 message. 532 2.8.3 Solution description 534 The clarity of the definition of the TID and DRM label parameters is 535 improved by adding what should be wildcarded in the TID/DRM and how 536 to use the start and end field. It is assumed that these labels are 537 simple values(at a certain location) that are logical ANDed(taking 538 into account the start and end position where to apply) onto the 539 received TID or DRN. If the result of the AND operation exactly 540 matches the "Label" field, then the message is sent to the ASP that 541 registered for this label via the ASPAC msg. If a another ASP sends 542 a already used label then this ASPAC must be rejected. 544 2.9 DRM label parameter 546 2.9.1 Description of the problem 548 See problem description TID label parameter 550 2.9.2 Text changes to the document 552 --------- 553 Old text: (Section 3.10.15) 554 --------- 556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Tag = 0x010F | Length = 8 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | start | end | label value | 561 +---------------+---------------+-------------------------------+ 563 The Start parameter is the start position of label, between 0 (LSB) 564 and 23 (MSB). 566 The End parameter is the end position of label, between 0 (LSB) and 567 23 (MSB). 569 Label value is a 16-bit integer, which is unique across an AS. 571 --------- 572 New text: (Section 3.10.15) 573 --------- 575 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Tag = 0x010F | Length = 8 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | start | end | label value | 580 +---------------+---------------+-------------------------------+ 582 The Start parameter is the start position of label, between 0 (LSB) 583 and 23 (MSB). 585 The End parameter is the end position of label, between 0 (LSB) and 586 23 (MSB). 588 Label value is a 16-bit integer, which is unique across an AS. The 589 label value has to match the Destination Reference Number between 590 the start and the end parameter(Logical AND operation). The rest 591 of the DRN between 0 and the begin parameter(if begin parameter 592 > 0) AND the end parameter(if end parameter value < 31) and 31 is 593 wildcarded. 594 An ASP that registers a label will be sent only those DRN-bearing 595 messages that match its label. 596 An ASP that does not register a label may be sent any DRN-bearing 597 message. 599 2.9.3 Solution description 601 See solution description of the TID label parameter. 603 2.10 Usage of the TID and DRN label 605 2.10.1 Description of the problem 607 The use of the TID and DRM label parameters is unclear. 609 2.10.2 Text changes to the document 611 --------- 612 Old text: (Section 4.7.2.1) 613 --------- 615 After association setup and registration, an ASP normally goes active 616 for each AS it registered for. In the ASPAC message, the ASP 617 includes a TID and/or DRN Label Parameter, if applicable for the AS 618 in question. All the ASPs within the AS must specify a unique label 619 at a fixed position in the TID or DRN parameter. The same ASPAC 620 message is sent to each SG used for interworking with the SS7 621 network. 623 The SG builds, per RK, a list of ASPs that have registered for it. 624 The SG can now build up and update a distribution table for a certain 625 Routing Context, any time the association is (re-)established and the 626 ASP goes active. The SG has to perform some trivial plausibility 627 checks on the parameters: 629 - Start and End parameters values are between 0 and 31 for TID. 630 - Start and End parameters values are between 0 and 23 for DRN 631 - ... 632 - Start values are the same for each ASP within a RC 633 - End values are the same for each ASP within a RC 634 - TID and DRN Label values must be unique across the RC 636 If any of these checks fail, the SG refuses the ASPAC request, with 637 an error: Invalid loadsharing label . 639 --------- 640 New text: (Section 4.7.2.1) 641 --------- 642 After association setup and registration, an ASP normally goes active 643 for each AS it registered for. In the ASPAC message, the ASP can include 644 a TID and/or DRN Label Parameter, if applicable for the AS 645 in question. 647 If at least one of the ASPs within an AS specifies a label, then all the 648 ASPs within the AS must specify a unique label in the ASPAC's msg they 649 send. 651 Each of the ASPs within the AS must specify a unique label at a fixed 652 position in the TID or DRN parameter. The ASP must send the same ASPAC 653 to each SG it is attached to, for interworking with the SS7 network. 655 The SG builds, per RC, a list of ASPs that have registered for it. 656 The SG can now build up and update a distribution table for a certain 657 Routing Context, any time the association is (re-)established and the 658 ASP goes active. The SG has to perform some trivial plausibility 659 checks on the parameters: 661 - Start and End parameters values are between 0 and 31 for TID. 662 - Start and End parameters values are between 0 and 23 for DRN 663 - ... 664 - Start values are the same for each ASP within a RC 665 - End values are the same for each ASP within a RC 666 - TID and/or DRN Label values must be unique across the RC 668 If any of these checks fail, the SG refuses the ASPAC request, with 669 an error, "Invalid loadsharing label." 671 --------- 672 Old text: (Section 4.7.3.1) 673 --------- 675 Messages not containing a destination (or "responding") TID, i.e., 676 Query, Begin, Unidirectional, are loadshared among the available 677 ASPs. Any scheme permitting a fair load distribution among the ASPs 678 is allowed (e.g., round robin). 680 When a destination TID is present, the SG extracts the label and 681 selects the ASP that corresponds with it. 683 If an ASP is not available, the SG may generate (X)UDTS "routing 684 failure", if the return option is used. 686 --------- 687 New text: (Section 4.7.3.1) 688 --------- 690 Messages not containing a destination (or "responding") TID, i.e., 691 Query, Begin, Unidirectional, are loadshared among the available 692 ASPs. Any scheme permitting a fair load distribution among the ASPs 693 is allowed (e.g., round robin). 695 When a destination TID is present, the SG extracts the label and 696 if the result of the AND operation exactly matches the "Label" field, 697 then the message is sent to the ASP that registered for this label via the 698 ASPAC msg. 700 An ASP that registers a label will be sent only those TID-bearing 701 messages that match its label. 703 An ASP that does not register a label may be sent any TID-bearing 704 message. 706 If an ASP is not available, the SG may generate (X)UDTS "routing 707 failure", if the return option is used. 709 2.10.3 Solution description 711 Improving the clarity of the use of the TID and DRM label parameters: 713 If the result of the AND operation exactly matches the "Label" field, 714 then the message is sent to the ASP that registered for this label 715 via the ASPAC msg. 717 An ASP that registers a label will be sent only those TID-bearing 718 messages that match its label. An ASP that does not register a label 719 may be sent any TID-bearing message. 721 2.11 Address Range paramete 723 2.11.1 Description of the problem 725 It should explicitly state the order of the minimum and maximum 726 addresses in this parameter. The most logical order would probably 727 be first the min, followed by the max. 729 2.11.2 Text changes to the document 731 --------- 732 Old text: (Section 3.10.17) 733 --------- 735 Address field: 737 The Address field the following parameters: 739 Parameter 740 Source Address Optional *1 741 Destination Address Optional *1 743 Note 1: The Address field must contain pairs of Source Addresses 744 or pairs of Destination Addresses but MUST NOT mix Source 745 Addresses with Destination Addresses in the same Address 746 field. 748 --------- 749 New text: (Section 3.10.17) 750 --------- 752 Address field: 754 The Address field the following parameters: 756 Parameter 757 Source Address Optional *1 758 Destination Address Optional *1 760 Note 1: The Address field must contain pairs of Source Addresses 761 or pairs of Destination Addresses but MUST NOT mix Source 762 Addresses with Destination Addresses in the same Address 763 field. The minimum address must be first and the maximun 764 address must follow the minimum. 766 2.11.3 Solution description 768 State the order of the minimum and maximum addresses in this 769 parameter. The logical order is first the min, followed by the max. 771 2.12 Interpretation of the mask parameter 773 2.12.1 Description of the problem 775 The mask paramater in the DAUD, DAVA and DUNA SUA messages can be in 776 the range from 0 to 255 bits. This can go over the maximun pointcode 777 range of 24 bits. Also if a ASP request via DAUD with a mask 778 parameter of 24, the SG would need to return all pointcodes it know 779 in his network to the ASP. (Which could be a lot). 781 2.12.2 Text changes to the document 783 --------- 784 Old text: (Section 3.9.18) 785 --------- 787 Mask: 8-bits 789 The Mask parameter can be used to identify a contiguous range of 790 Affected Destination Point Codes, independent of the point code 791 format. Identifying a contiguous range of Affected PCs may be useful 792 when reception of an MTP3 management message or a linkset event 793 simultaneously affects the availability status of a series of 794 destinations at an SG. 796 The Mask parameter is an integer representing a bit mask that can be 797 applied to the related Affected PC field. The bit mask identifies 798 how many bits of the Affected PC field are significant and which are 799 effectively "wild-carded". For example, a mask of "8" indicates that 800 the last eight bits of the PC is "wild-carded". For an ANSI 24-bit 801 Affected PC, this is equivalent to signalling that all PCs in an ANSI 802 Cluster are unavailable. A mask of "3" indicates that the last three 803 bits of the PC is "wild-carded". For a 14-bit ITU Affected PC, this 804 is equivalent to signalling that an ITU Region is unavailable. 806 --------- 807 New text: (Section 3.9.18) 808 --------- 810 Mask: 8-bits 812 The Mask parameter can be used to identify a contiguous range of 813 Affected Destination Point Codes, independent of the point code 814 format. Identifying a contiguous range of Affected PCs may be useful 815 when reception of an MTP3 management message or a linkset event 816 simultaneously affects the availability status of a series of 817 destinations at an SG. 819 The Mask parameter is an integer representing a bit mask that can be 820 applied to the related Affected PC field. The bit mask identifies 821 how many bits of the Affected PC field are significant and which are 822 effectively "wild-carded". For example, a mask of "8" indicates that 823 the last eight bits of the PC is "wild-carded". For an ANSI 24-bit 824 Affected PC, this is equivalent to signalling that all PCs in an ANSI 825 Cluster are unavailable. A mask of "3" indicates that the last three 826 bits of the PC is "wild-carded". 828 The range of mask parameter is limited to 0-24 for ANSI networks and 829 is NOT used for ITU networks. 831 2.12.3 Solution description 833 The parameter is limited to 14 bits for ANSI networks and is NOT USED 834 in ITU networks. 836 2.13 Reply on errors contained in a error message 838 2.13.1 Description of the problem 840 If a error message arrives with a error in it, what should be send 841 out? Nothing in the RFC3868 describes this possibility. 843 2.13.2 Text changes to the document 845 --------- 846 Old text: (Section 3.7.1) 847 --------- 849 --------- 850 New text: (Section 3.7.1) 851 --------- 853 Error messages MUST NOT be generated in response to other Error messages. 855 2.13.3 Solution description 857 No error msg must be send back in response on a received error 858 message(containing a error). This would otherwise possibly lead to a 859 storm of exchange error messages. 861 2.14 Use of stream 0 for SSNM messages 863 2.14.1 Description of the problem 865 There seems to be some confusion in paragraph 4.5.1. First it is 866 mentioned NOT to use stream 0 but a few lines later you MUST use 867 stream 0 and that happen all in the same context of sending SSNM 868 messages(DAUD, DUNA, DAVA..). It also contradicts statements made in 869 paragraph 4.1.1. 871 2.14.2 Text changes to the document 873 --------- 874 Old text: (Section 4.5.1) 875 --------- 877 DUNA, DAVA, SCON, and DRST messages are sent sequentially and 878 processed at the receiver in the order sent. SCTP stream 0 SHOULD 879 NOT be used. The Unordered bit in the SCTP DATA chunk MAY be used 880 for the SCON message. 882 Sequencing is not required for the DUPU or DAUD messages, which MAY 883 be sent unordered. SCTP stream 0 is used, with optional use of the 884 Unordered bit in the SCTP DATA chunk. 886 --------- 887 New text: (Section 4.5.1) 888 --------- 890 DUNA, DAVA, SCON, and DRST messages are sent sequentially and 891 processed at the receiver in the order sent. The Unordered bit 892 in the SCTP DATA chunk MAY be used for the SCON message. 894 Sequencing is not required for the DUPU or DAUD messages, which MAY 895 be sent unordered. SCTP stream 0 is used, with optional use of the 896 Unordered bit in the SCTP DATA chunk. 898 2.14.3 Solution description 900 The SSNM messages should be send on stream 0 of the association. 902 2.15 Timer Ta does not exist 904 2.15.1 Description of the problem 906 Timer Ta is mentioned in paragraph 8 but nowhere specified. 908 2.15.2 Text changes to the document 910 --------- 911 Old text: (Section 8) 912 --------- 914 8. Timer Values 916 Ta 2 seconds 917 Tr 2 seconds 918 T(ack) 2 seconds 919 T(ias) Inactivity Send timer 7 minutes 920 T(iar) Inactivity Receive timer 15 minutes 921 T(beat) Heartbeat Timer 30 seconds 923 --------- 924 New text: (Section 8) 925 --------- 927 8. Timer Values 929 Tr 2 seconds 930 T(ack) 2 seconds 931 T(ias) Inactivity Send timer 7 minutes 932 T(iar) Inactivity Receive timer 15 minutes 933 T(beat) Heartbeat Timer 30 seconds 935 2.15.3 Solution description 937 Timer Ta is removed. 939 2.16 Error response on unsupported RKM messages 941 2.16.1 Description of the problem 943 If RKM messages are not supported by a implementation, a error 944 message is send back with error cause "unsupported message Type". We 945 should send back a error message with error cause "unsupported 946 message class" . 948 2.16.2 Text changes to the document 950 --------- 951 Old text: (Section 4.4.1) 952 --------- 953 If the SGP does not support the registration procedure, the SGP 954 returns an Error message to the ASP, with an error code of 955 "Unsupported Message Type". 957 --------- 958 New text: (Section 4.4.1) 959 --------- 960 If the SGP does not support the registration procedure, the SGP 961 returns an Error message to the ASP, with an error code of 962 "Unsupported Message Class". 964 --------- 965 Old text: (Section 4.4.1) 966 --------- 968 --------- 969 New text: (Section 4.4.1) 970 --------- 972 If the SGP determines that the requested RK partially, but not 973 exactly, matches an existing RK, and that an incoming signalling 974 message received at an SGP could possibly match both the requested and 975 the existing RK, the SGP returns a Registration Response message to 976 the ASP, with a Registration Status of "Error - "Cannot Support Unique 977 Routing. An incoming signalling message received at an SGP should not 978 match against more than one Routing Key. 980 If the SGP determines that the received RK was already registered, 981 fully and exactly, either statically or dynamically, by the sending 982 ASP, the SGP returns a Registration Response message to the ASP, 983 containing a Registration Result "Error - Routing Key Already 984 Registered ". This error applies whether the sending ASP/IPSP is in 985 ASP-ACTIVE or ASP-INACTIVE for the corresponding AS. For this error 986 code, the RC field in the Registration Response message MUST be 987 populated with the actual value of RC in SGP corresponding to the 988 specified RK in the Registration Request message. 990 If an SGP determines that a received Routing Key does not currently 991 exist, and the SGP supports dynamic configuration but requires that 992 the Routing Key first be manually provisioned at the SGP, the SGP 993 returns a Registration Response message to the ASP, containing a 994 Registration Result "Error - Routing Key not Currently Provisioned. 996 --------- 997 Old text: (Section 4.4.1) 998 --------- 999 An ASP MAY modify an existing Routing Key by including a Routing 1000 Context parameter in the REG REQ. If the SGP determines that the 1001 Routing Context applies to an existing Routing Key, the SG MAY adjust 1002 the existing Routing Key to match the new information provided in the 1003 Routing Key parameter. A Registration Response "Routing Key Change 1004 Refused" is returned if the SGP does not accept the modification of 1005 the Routing Key. 1007 --------- 1008 New text: (Section 4.4.1) 1009 --------- 1011 An ASP MAY request modification of an existing Routing Key by 1012 including a Routing Context parameter in a Registration Request 1013 message. Upon receipt of a Registration Request message containing a 1014 Routing Context, if the SGP determines that the Routing Context 1015 applies to an existing Routing Key, the SGP MAY adjust the existing 1016 Routing Key to match the new information provided in the Routing Key 1017 parameter. A Registration Response "ERR ? Routing Key Change Refused" 1018 is returned if the SGP does not support this re-registration procedure 1019 or RC does not exist. Otherwise, a Registration Response "Successfully 1020 Registered" is returned. 1022 2.16.3 Solution description 1024 Send back a error message with "unsupported message class". If >RKM 1025 messages are not supported, the implementation actually rejects a 1026 whole class of messages, not just a single one. Other error messages 1027 are send back depending on the partial or complete match of the 1028 Routing key with the provisioned data. 1030 2.17 Filler/padding in Global title parameter 1032 2.17.1 Description of the problem 1034 The global title digits part of the global title parameter contains 1035 filler bytes. They should be called pading bytes so that they are 1036 not included in the calculation of the length of the global title 1037 parameter. 1039 2.17.2 Text changes to the document 1041 --------- 1042 Old text: (Section 3.10.2.3) 1043 --------- 1044 Global Title: 1046 Octets contain a number of address signals and possibly filler as 1047 shown: 1049 0 1 2 3 1050 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 |2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.| 1053 | sig. | sig. | sig. | sig. | sig. | sig. | sig. | sig. | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | ............. |filler |N addr.| filler | 1056 | |if req | sig. | | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 All filler bits SHOULD be set to 0. 1061 --------- 1062 New text: (Section 3.10.2.3) 1063 --------- 1064 Global Title: 1066 Octets contain a number of address signals and possibly filler and 1067 padding as shown: 1069 0 1 2 3 1070 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 |2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.| 1073 | sig. | sig. | sig. | sig. | sig. | sig. | sig. | sig. | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | ............. |filler |N addr.| padding | 1076 | |if req | sig. | | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 All filler and padding bits SHOULD be set to 0. 1081 2.17.3 Solution description 1083 Insert padding into definition of the global title parameter. 1085 2.18 Inclusion of routing context in the Routing key parameter 1087 2.18.1 Description of the problem 1089 The Routing conext is missing from the Routing key parameter of the 1090 REG message, so leading to a inconsistency with section 4.4.1 where 1091 it is mentioned that the RC has to be present in order to change the 1092 registration data of a certain RC. If the RC is not present, then 1093 the registration data can not be identified and changed. 1095 2.18.2 Text changes to the document 1097 --------- 1098 Old text: (Section 3.10.14) 1099 --------- 1100 The Key field contains the following parameters: 1102 Parameter 1103 Traffic Mode Type Optional 1104 Network Appearance Optional *1 1105 Source Address Optional 1106 Destination Address Optional 1107 Address Range Optional 1109 Note 1: The Network Appearance parameter must be included in the 1110 Routing Key when the ASP is able to register in multiple 1111 SS7 Network contexts 1113 --------- 1114 New text: (Section 3.10.14) 1115 --------- 1116 The Key field contains the following parameters: 1118 Parameter 1119 Traffic Mode Type Optional 1120 Network Appearance Optional *1 1121 Source Address Optional 1122 Destination Address Optional 1123 Address Range Optional 1124 Routing Context Optional *2 1126 Note 1: The Network Appearance parameter must be included in the 1127 Routing Key when the ASP is able to register in multiple 1128 SS7 Network contexts. 1130 Note 2: The Routing Context parameter is included in the Routing 1131 Key when the ASP wishes to alter an existing Routing Key 1132 which corresponds to the indicated Routing Context. The 1133 Routing Context parameter MUST only occur once in the Key 1134 parameters. 1136 2.18.3 Solution description 1138 Include the routing context parameter in the routing key parameter. 1139 And keep the text of section 4.4.1. 1141 2.19 New registration status parameter value 1143 2.19.1 Description of the problem 1145 A new registartion status parameter value is required in case that a 1146 routing key chnage is refused. 1148 2.19.2 Text changes to the document 1150 --------- 1151 Old text: (Section 3.9.22) 1152 --------- 1153 Registration Status: 32-bits (unsigned integer) 1155 The Registration Status field indicates the success or the reason 1156 for failure of a registration request. 1158 Its values may be: 1159 0 Successfully Registered 1160 1 Error - Unknown 1161 2 Error - Invalid Destination Address 1162 3 Error - Invalid Network Appearance 1163 4 Error - Invalid Routing Key 1164 5 Error - Permission Denied 1165 6 Error - Cannot Support Unique Routing 1166 7 Error - Routing Key not Currently Provisioned 1167 8 Error - Insufficient Resources 1168 9 Error - Unsupported RK parameter Field 1169 10 Error - Unsupported/Invalid Traffic Mode Type 1170 11 Error - Routing Key Change Refused 1172 --------- 1173 New text: (Section 3.9.22) 1174 --------- 1175 Registration Status: 32-bits (unsigned integer) 1177 The Registration Status field indicates the success or the reason 1178 for failure of a registration request. 1180 Its values may be: 1181 0 Successfully Registered 1182 1 Error - Unknown 1183 2 Error - Invalid Destination Address 1184 3 Error - Invalid Network Appearance 1185 4 Error - Invalid Routing Key 1186 5 Error - Permission Denied 1187 6 Error - Cannot Support Unique Routing 1188 7 Error - Routing Key not Currently Provisioned 1189 8 Error - Insufficient Resources 1190 9 Error - Unsupported RK parameter Field 1191 10 Error - Unsupported/Invalid Traffic Mode Type 1192 11 Error - Routing Key Change Refused 1193 12 Error - Routing Key already registered 1195 2.19.3 Solution description 1197 Add new Registration response "Error - Routing key already 1198 registered". 1200 3 Security considerations 1202 No new treats have been identified besides the already known in SUA 1203 [RFC3868] [1]. 1205 4 Acknowledgments 1207 The authors wish to thank B. Nagelberg, B. Bidulock, T. Asveren, S. 1208 Karl, K. Morneault and many others for their invaluable comments. 1210 5. References 1212 [1] Loughney, J., Sidebottom, G., Verwimp, G., Coene, L., Keller, 1213 J., and B. Bidulock, "Signalling Connection Control Part User 1214 Adaptation Layer (SUA)", RFC 3868, October 2004. 1216 [2] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. 1218 [3] Mockapetris, P., "Domain names - Implementation and 1219 Specification", RFC 1035, November 1987. 1221 [4] ITU, "Q.714 : SCCP procedures", Q. 714, July 1997. 1223 [5] ANSI, "T1.112.4 : SCCP procedures", T. 1.112.4, December 1993. 1225 Appendix A Changes Control 1227 A.1 Changes from v00 to v01 1229 - Change of boilerplate 1231 - Typos. 1233 - Paragraph 2.6 ASP routing context: replacement text for section 1234 1.5.2 1236 - Paragraph 2.10 Usage of TID and DRM label parameter: text 1237 clarification for solution description 1239 - Paragraph 2.8 Use of ANSI intermediate signaling network 1240 identification (ISNI) parameter: Removed, no text proposed. 1242 A.2 Changes from v01 to v02 1244 - Typos. 1246 - Paragraph 2.17 Filler/padding in Global title parameter: new 1248 - Paragraph 2.18 Inclusion of routing context in the Routing key 1249 parameter: new 1251 - Paragraph 2.8 TID label parameter:Changed: Another attempt at 1252 clarifying what a SG could be doing with TID label. 1254 - Paragraph 2.9 DRM label parameter:Changed: Another attempt at 1255 clarifying what a SG could be doing with DRM label. 1257 - Paragraph 2.10 Usage of TID and DRM label parameter:Changed: 1258 Another attempt at clarifying what a SG could be doing with TID and 1259 DRM labels. 1261 - 1263 A.3 Changes from v02 to v03 1265 - Typos. 1267 - Paragraph 2.16:Error response on unsupported RKM messages: Changed 1269 - Paragraph 2.19:New registration status parameter value: New 1271 A.4 Changes from v03 to v04 1273 - None. 1275 Authors' Addresses 1277 Lode Coene 1278 Siemens 1279 Atealaan 32 1280 Herentals 2200 1281 Belgium 1283 Phone: +32-14-252081 1284 Email: lode.coene@siemens.com 1286 John Loughney 1287 Nokia 1288 Itdmerenkatu 11-13 1289 Espoo 00180 1290 Finland 1292 Phone: +358 50 483 6242 1293 Email: john.loughney@nokia.com 1295 Full Copyright Statement 1297 Copyright (C) The Internet Society (2006). 1299 This document is subject to the rights, licenses and restrictions 1300 contained in BCP 78, and except as set forth therein, the authors 1301 retain all their rights. 1303 This document and the information contained herein are provided on an 1304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1311 Intellectual Property 1313 The IETF takes no position regarding the validity or scope of any 1314 Intellectual Property Rights or other rights that might be claimed to 1315 pertain to the implementation or use of the technology described in 1316 this document or the extent to which any license under such rights 1317 might or might not be available; nor does it represent that it has 1318 made any independent effort to identify any such rights. Information 1319 on the procedures with respect to rights in RFC documents can be 1320 found in BCP 78 and BCP 79. 1322 Copies of IPR disclosures made to the IETF Secretariat and any 1323 assurances of licenses to be made available, or the result of an 1324 attempt made to obtain a general license or permission for the use of 1325 such proprietary rights by implementers or users of this 1326 specification can be obtained from the IETF on-line IPR repository at 1327 http://www.ietf.org/ipr. 1329 The IETF invites any interested party to bring to its attention any 1330 copyrights, patents or patent applications, or other proprietary 1331 rights that may cover technology that may be required to implement 1332 this standard. Please address the information to the IETF at 1333 ietf-ipr@ietf.org. 1335 Acknowledgment 1337 Funding for the RFC Editor function is provided by the IETF 1338 Administrative Support Activity (IASA).