idnits 2.17.1 draft-bidulock-sigtran-m2pa-ig-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 356. 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 abstract seems to contain references ([M2PA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document updates RFC4165, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (August 2007) is 6098 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Brian Bidulock 3 INTERNET-DRAFT OpenSS7 Corporation 4 Intended status: PROPOSED STANDARD February 3, 2007 6 Expires in August 2007 8 SS7 MTP2-User Peer-to-Peer Adaptation Layer 9 Implementer's Guide 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware have 16 been or will be disclosed, and any of which he or she becomes aware 17 will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any 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 in August 2007. 36 Copyright 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This Internet-Draft provides information for the Internet community 43 on clarifications and interpretations of the text of the SS7 MTP2-User 44 Peer-to-Peer Adaptation Layer [M2PA] based on working group comments 45 and experience at interoperability events. It also provides 46 information on specification addendum and errata -- whether of an 47 editorial or technical nature -- discovered to the date of this 48 document. 50 This document is intended as a companion document to the M2PA RFC 51 [M2PA] to be used in the implementation of M2PA to clarify the 52 original M2PA document. 54 This document updates RFC 4165 [M2PA] and text within this document 55 supersedes the text found in RFC 4165 [M2PA]. 57 Contents 59 A complete table of contents, list of illustrations, list of tables 60 and change history for this document appears at the end of the 61 document. 63 1. Introduction 65 This document contains a compilation of all specification addenda 66 and errata found up until the publishing of this document for SS7 67 MTP2-User Peer-to-Peer Adaptation Layer, RFC 4165 [M2PA]. These 68 addenda and errata may be of an editorial or technical nature. This 69 document may be thought of as a companion document to be used in the 70 implementation of M2PA to clarify errata and provide addenda to the 71 original M2PA document [M2PA]. 73 This document updates RFC 4165 [M2PA] and text within this document, 74 where noted, supersedes the text found in RFC 4165 [M2PA]. Each error 75 will be detailed within this document in the form of: 77 + The problem description. 79 + The text quoted from RFC 4165 [M2PA]. 81 + The replacement text. 83 + A description of the solution. 85 1.1. Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Errata, Addenda and Clarifications 93 2.1. Initial Sequence Number 95 2.1.1. Problem Statement 97 Although it is described in the applicable MTP2 standard, some 98 implementers have become confused over what the initial value of the 99 FSN and BSN should be. 101 2.1.2. Text Changes 103 2.1.2.1. Old Text (Section 4.1.3, Page 25) 105 None. 107 2.1.2.2. New Text (Section 4.1.3, Page 25, at end of page.) 109 The value of the FSN in the first Non-Empty User Data message 110 transmitted on an M2PA link after alignment is the same as that 111 described in the applicable standard (e.g. Q.703, ANSI T1.111.3), 112 typically zero (0). 114 2.1.3. Solution Description 116 The text change clarifies that the value of the initial sequence 117 numbers is specified by the applicable standard and identifies that 118 the value of the initial FSN is typically zero (0). 120 2.2. BSN when FSN Out of Order 122 2.2.1. Problem Statement 124 2.2.2. Text Changes 126 2.2.2.1. Old Text (Section 4.2.1, Page 30) 128 If M2PA receives a User Data message with an FSN that is out of 129 order, M2PA SHALL discard the message. 131 2.2.2.2. New Text (Section 4.2.1, Page 30) 133 In accordance with the applicable MTP2 standard, if M2PA receives a 134 User Data message with an FSN that is out of order, M2PA SHALL 135 discard the message. Processing of the BSN in the discarded message 136 is in accordance with the applicable MTP2 standard. 138 2.2.3. Solution Description 140 The text change identifies that this procedure is in accordance with 141 the applicable MTP2 standard and does not change the way that messages 142 received with FSN out of order are handled. 144 2.3. LS Ready received during Proving 146 2.3.1. Problem Statement 148 If an implementation operates precisely as described in the MTP2 149 SDLs (e.g. Q.703/Clause 12) [Q.703] then such an M2PA link will fail 150 to align if an "LS Ready" message is received during the Proving 151 period and no additional "LS Ready" message is later received after 152 proving ends. 154 2.3.2. Text Changes 156 2.3.2.1. Old Text (Section 4.1.3, Page 25) 158 The Link Status Ready message replaces the FISU of MTP2 that is sent 159 at the end of the proving period. The Link Status Ready message is 160 used to verify that both ends have completed proving. When M2PA 161 starts timer T1, it SHALL send a Link Status Ready message to its 162 peer in the case where MTP2 would send a FISU after proving is 163 complete. If the Link Status Ready message is sent, then M2PA MAY 164 send additional Link Status Ready messages while timer T1 is running. 165 These Link Status Ready messages are sent on the Link Status stream. 167 In the case that MTP2 sends an MSU or SIPO message at the end of 168 proving, M2PA SHALL send (respectively) a User Data or Link Status 169 Processor Outage message. 171 2.3.2.2. New Text (Section 4.1.3, Page 25) 173 The Link Status Ready message replaces the FISU(s) of MTP2 sent at 174 the end of the proving period. The Link Status Ready message is used 175 to verify that both ends have completed proving. When M2PA starts 176 timer T1, it SHALL send a Link Status Ready message to its peer in 177 the case where MTP2 would send FISU(s) after proving is complete. If 178 the Link Status Ready message is sent, then M2PA MAY send additional 179 Link Status Ready messages while timer T1 is running. These Link 180 Status Ready messages are sent on the Link Status stream. 182 In the case that MTP2 sends an MSU or SIPO message at the end of 183 proving, M2PA SHALL send (respectively) a User Data or Link Status 184 Processor Outage message. 186 2.3.2.3. Old Text (Section 4, Page 19) 188 None. 190 2.3.2.4. New Text (Section 4, Page 19, 4th Paragraph) 192 As they contain errors that impede interoperability of M2PA 193 implementations, M2PA SHOULD NOT follow precisely in implementation 194 the SDLs described in Clause 12 of the applicable MTP2 standards. 196 2.3.3. Solution Description 198 The first text change more clearly identifies that the single 199 transmission of a "Link Status Ready" message replaces the possibly 200 multiple repeated FISU(s) sent at the end of the proving period in 201 MTP2. 203 It is not within the scope of the document to dictate 204 implementation; however, strictly following the SDLs of Q.703/Clause 205 12 [Q.703] or ANSI T1.111.3 [T1.111] will result in an implementation 206 that does not function in the second respect (MSU sent at the end of 207 proving), even though there is a test case for same in Q.781 [Q.781] 208 and M2PA validation tests [M2PATEST]. Anyone not heeding the the 209 statements at the beginning of Clause 12 in the MTP2 standards, and 210 using the SDLs directly for implementation might fail to create a 211 fully interoperable implementation. The second text change identifies 212 this interoperability concern. 214 Security Considerations 216 There are no security considerations for this draft. 218 IANA Considerations 220 There are no IANA considerations for this draft. 222 0. Change History 224 This section provides historical information on the changes made to 225 this draft. This section will be removed from the document when the 226 document is finalized. 228 0.1. Changes from Version 0.0 to Version 0.1 230 + updated boilerplate and to idnits-2.00.1. 231 + updated references, version numbers and dates. 233 0.0. Version 0.0 235 The initial version of this document representing the three items 236 from Jeffrey Craig's document upon which consensus could be reached. 238 0.0.0. Change Log 240 $Log: draft-bidulock-sigtran-m2pa-ig-01.me,v $ 241 Revision 0.9.2.1 2007/02/03 15:47:14 brian 242 - added new drafts 244 Revision 0.9.2.1 2006/07/11 22:56:23 brian 245 - initial version of M2PA IG replacement draft 247 Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels," BCP 14/RFC 2119, The Internet Society (March 251 1997). 253 [M2PA] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and 254 Morneault, K., "Signaling System 7 (SS7) Message Transfer Part 2 255 (MTP2)-User Peer-to-Peer Adaptation Layer (M2PA)," RFC 4165, The 256 Internet Society (September 2005). (Status: PROPOSED STANDARD) 257 259 Informative References 261 [Q.703] ITU, "Signalling System No. 7 -- Signalling Link," ITU-T 262 Recommendation Q.703, ITU-T Telecommunication Standardization 263 Sector of ITU, Geneva (March 1993). (Previously "CCITT 264 Recommendation") 266 [T1.111] ANSI, "Signalling System No. 7 -- Message Transfer Part," 267 ANSI T1.111, American National Standards Institute (1992). 269 [Q.781] ITU, "Signalling System No. 7 -- MTP Level 2 Test 270 Specification," ITU-T Recommendation Q.781, ITU-T 271 Telecommunication Standardization Sector of ITU, Geneva (March 272 1993). (Previously "CCITT Recommendation") 274 [M2PATEST] Bidulock, B., "SS7 MTP2-User Peer-to-Peer Adaptation Layer 275 -- Test Specifications," draft-bidulock-sigtran-m2pa-test-08.txt, 276 Internet Engineering Task Force -- Signalling Transport Working 277 Group (February 3, 2007). Work In Progress. 278 281 Acknowledgements 283 The author would like to thank Andrew Booth, Jeffrey Craig, Mark 284 Davidson, Mark Erickson, Tom George, Michael Tuexen, for their 285 valuable comments and suggestions. 287 Author's Addresses 289 Brian Bidulock 290 OpenSS7 Corporation 291 1469 Jeffreys Crescent 292 Edmonton, AB T6L 6T1 293 Canada 295 Phone: +1-780-490-1141 296 Email: bidulock@openss7.org 297 URL: http//www.openss7.org/ 299 This draft expires August 2007. 301 Table of Contents 303 Status of this Memo ............................................. 1 304 Copyright ....................................................... 1 305 Abstract ........................................................ 1 306 Contents ........................................................ 2 307 1 Introduction .................................................. 2 308 1.1 Conventions ................................................. 2 309 2 Errata, Addenda and Clarifications ............................ 2 310 2.1 Initial Sequence Number ..................................... 2 311 2.1.1 Problem Statement ......................................... 2 312 2.1.2 Text Changes .............................................. 3 313 2.1.3 Solution Description ...................................... 3 314 2.2 BSN when FSN Out of Order ................................... 3 315 2.2.1 Problem Statement ......................................... 3 316 2.2.2 Text Changes .............................................. 3 317 2.2.3 Solution Description ...................................... 3 318 2.3 LS Ready received during Proving ............................ 3 319 2.3.1 Problem Statement ......................................... 3 320 2.3.2 Text Changes .............................................. 4 321 2.3.3 Solution Description ...................................... 4 322 Security Considerations ......................................... 5 323 IANA Considerations ............................................. 5 324 0 Change History ................................................ 5 325 0.1 Changes from Version 0.0 to Version 0.1 ..................... 5 326 0.0 Version 0.0 ................................................. 5 327 0.0.0 Change Log ................................................ 5 328 Normative References ............................................ 6 329 Informative References .......................................... 6 330 Acknowledgements ................................................ 7 331 Author's Addresses .............................................. 7 332 Table of Contents ............................................... 8 334 Intellectual Property 336 The IETF takes no position regarding the validity or scope of any 337 Intellectual Property Rights or other rights that might be claimed to 338 pertain to the implementation or use of the technology described in 339 this document or the extent to which any license under such rights 340 might or might not be available; nor does it represent that it has 341 made any independent effort to identify any such rights. Information 342 on the procedures with respect to rights in RFC documents can be found 343 in BCP 78 and BCP 79. 345 Copies of IPR disclosures made to the IETF Secretariat and any 346 assurances of licenses to be made available, or the result of an 347 attempt made to obtain a general license or permission for the use of 348 such proprietary rights by implementers or users of this specification 349 can be obtained from the IETF on-line IPR repository at 350 http://www.ietf.org/ipr. 352 The IETF invites any interested party to bring to its attention any 353 copyrights, patents or patent applications, or other proprietary 354 rights that may cover technology that may be required to implement 355 this standard. Please address the information to the IETF at ietf- 356 ipr@ietf.org. 358 Disclaimer of Validity 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Full Copyright Statement 370 Copyright (C) The IETF Trust (2007). This document is subject to the 371 rights, licenses and restrictions contained in BCP 78, and except as 372 set forth therein, the authors retain all their rights. 374 Acknowledgement 376 Funding for the RFC Editor function is currently provided by the 377 Internet Society.