draft-bidulock-sigtran-m2pa-ig-00

Network Working Group                                     Brian Bidulock
INTERNET-DRAFT                                       OpenSS7 Corporation

                                                           July 11, 2006
Expires in January 2007

              SS7 MTP2-User Peer-to-Peer Adaptation Layer
                          Implementer's Guide
                <draft-bidulock-sigtran-m2pa-ig-00.txt>

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that other
  groups may also distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other documents
  at any time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress".

    The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

    This Internet-Draft will expire in January 2007.

Copyright

    Copyright (C) The Internet Society (2006).

Abstract

    This Internet-Draft provides information for the Internet community
  on clarifications and interpretations of the text of the SS7 MTP2-User
  Peer-to-Peer Adaptation Layer [M2PA] based on working group comments
  and experience at interoperability events.  It also provides
  information on specification addendum and errata -- whether of an
  editorial or technical nature -- discovered to the date of this
  document.

B. Bidulock                    Version 0.0                        Page 1

Internet Draft                   M2PA-IG                   July 11, 2006

    This document is intended as a companion document to the M2PA RFC
  [M2PA] to be used in the implementation of M2PA to clarify the
  original M2PA document.

    This document updates RFC 4165 [M2PA] and text within this document
  supersedes the text found in RFC 4165 [M2PA].

Contents

    A complete table of contents, list of illustrations, list of tables
  and change history for this document appears at the end of the
  document.

1.  Introduction

    This document contains a compilation of all specification addenda
  and errata found up until the publishing of this document for SS7
  MTP2-User Peer-to-Peer Adaptation Layer, RFC 4165 [M2PA].  These
  addenda and errata may be of an editorial or technical nature.  This
  document may be thought of as a companion document to be used in the
  implementation of M2PA to clarify errata and provide addenda to the
  original M2PA document [M2PA].

    This document updates RFC 4165 [M2PA] and text within this document,
  where noted, supersedes the text found in RFC 4165 [M2PA].  Each error
  will be detailed within this document in the form of:

  +  The problem description.

  +  The text quoted from RFC 4165 [M2PA].

  +  The replacement text.

  +  A description of the solution.

1.1.  Conventions

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

2.  Errata, Addenda and Clarifications

2.1.  Initial Sequence Number

2.1.1.  Problem Statement

    Although it is described in the applicable MTP2 standard, some
  implementers have become confused over what the initial value of the
  FSN and BSN should be.

B. Bidulock                    Version 0.0                        Page 2

Internet Draft                   M2PA-IG                   July 11, 2006

2.1.2.  Text Changes

2.1.2.1.  Old Text (Section 4.1.3, Page 25)

  None.

2.1.2.2.  New Text (Section 4.1.3, Page 25, at end of page.)

  The value of the FSN in the first Non-Empty User Data message
  transmitted on an M2PA link after alignment is the same as that
  described in the applicable standard (e.g. Q.703, ANSI T1.111.3),
  typically zero (0).

2.1.3.  Solution Description

    The text change clarifies that the value of the initial sequence
  numbers is specified by the applicable standard and identifies that
  the value of the initial FSN is typically zero (0).

2.2.  BSN when FSN Out of Order

2.2.1.  Problem Statement

2.2.2.  Text Changes

2.2.2.1.  Old Text (Section 4.2.1, Page 30)

  If M2PA receives a User Data message with an FSN that is out of
  order, M2PA SHALL discard the message.

2.2.2.2.  New Text (Section 4.2.1, Page 30)

  In accordance with the applicable MTP2 standard, if M2PA receives a
  User Data message with an FSN that is out of order, M2PA SHALL
  discard the message.  Processing of the BSN in the discarded message
  is in accordance with the applicable MTP2 standard.

2.2.3.  Solution Description

    The text change identifies that this procedure is in accordance with
  the applicable MTP2 standard and does not change the way that messages
  received with FSN out of order are handled.

2.3.  LS Ready received during Proving

2.3.1.  Problem Statement

    If an implementation operates precisely as described in the MTP2
  SDLs (e.g.  Q.703/Clause 12) [Q.703] then such an M2PA link will fail
  to align if an "LS Ready" message is received during the Proving

B. Bidulock                    Version 0.0                        Page 3

Internet Draft                   M2PA-IG                   July 11, 2006

  period and no additional "LS Ready" message is later received after
  proving ends.

2.3.2.  Text Changes

2.3.2.1.  Old Text (Section 4.1.3, Page 25)

  The Link Status Ready message replaces the FISU of MTP2 that is sent
  at the end of the proving period.  The Link Status Ready message is
  used to verify that both ends have completed proving.  When M2PA
  starts timer T1, it SHALL send a Link Status Ready message to its
  peer in the case where MTP2 would send a FISU after proving is
  complete.  If the Link Status Ready message is sent, then M2PA MAY
  send additional Link Status Ready messages while timer T1 is running.
  These Link Status Ready messages are sent on the Link Status stream.

  In the case that MTP2 sends an MSU or SIPO message at the end of
  proving, M2PA SHALL send (respectively) a User Data or Link Status
  Processor Outage message.

2.3.2.2.  New Text (Section 4.1.3, Page 25)

  The Link Status Ready message replaces the FISU(s) of MTP2 sent at
  the end of the proving period.  The Link Status Ready message is used
  to verify that both ends have completed proving.  When M2PA starts
  timer T1, it SHALL send a Link Status Ready message to its peer in
  the case where MTP2 would send FISU(s) after proving is complete.  If
  the Link Status Ready message is sent, then M2PA MAY send additional
  Link Status Ready messages while timer T1 is running.  These Link
  Status Ready messages are sent on the Link Status stream.

  In the case that MTP2 sends an MSU or SIPO message at the end of
  proving, M2PA SHALL send (respectively) a User Data or Link Status
  Processor Outage message.

2.3.2.3.  Old Text (Section 4, Page 19)

  None.

2.3.2.4.  New Text (Section 4, Page 19, 4th Paragraph)

  As they contain errors that impede interoperability of M2PA
  implementations, M2PA SHOULD NOT follow precisely in implementation
  the SDLs described in Clause 12 of the applicable MTP2 standards.

2.3.3.  Solution Description

    The first text change more clearly identifies that the single
  transmission of a "Link Status Ready" message replaces the possibly
  multiple repeated FISU(s) sent at the end of the proving period in

B. Bidulock                    Version 0.0                        Page 4

Internet Draft                   M2PA-IG                   July 11, 2006

  MTP2.

    It is not within the scope of the document to dictate
  implementation; however, strictly following the SDLs of Q.703/Clause
  12 [Q.703] or ANSI T1.111.3 [T1.111] will result in an implementation
  that does not function in the second respect (MSU sent at the end of
  proving), even though there is a test case for same in Q.781 [Q.781]
  and M2PA validation tests [M2PATEST07].  Anyone not heeding the the
  statements at the beginning of Clause 12 in the MTP2 standards, and
  using the SDLs directly for implementation might fail to create a
  fully interoperable implementation.  The second text change identifies
  this interoperability concern.

Security Considerations

    There are no security considerations for this draft.

IANA Considerations

    There are no IANA considerations for this draft.

0.  Change History

    This section provides historical information on the changes made to
  this draft.  This section will be removed from the document when the
  document is finalized.

0.0.  Version 0.0

    The initial version of this document representing the three items
  from Jeffrey Craig's document upon which consensus could be reached.

0.0.0.  Change Log

    $Log: draft-bidulock-sigtran-m2pa-ig-00.me,v $
    Revision 0.9.2.1  2006/07/11 22:56:23  brian
    - initial version of M2PA IG replacement draft

B. Bidulock                    Version 0.0                        Page 5

Internet Draft                   M2PA-IG                   July 11, 2006

R.  References

R.1.  Normative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels," RFC 2119 - BCP 14, The Internet Society
      (March 1997).

  [M2PA]  George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and
      Morneault, K., "Signaling System 7 (SS7) Message Transfer Part 2
      (MTP2)-User Peer-to-Peer Adaptation Layer (M2PA)," RFC 4165,
      Internet Engineering Task Force - Signalling Transport Working
      Group (September 2005).

R.2.  Informative References

  [Q.703]  ITU, "Signalling System No. 7 - Signalling Link," ITU-T
      Recommendation Q.703, ITU-T Telecommunication Standardization
      Sector of ITU, Geneva (March 1993).  (Previously "CCITT
      Recommendation")

  [T1.111]  ANSI, "Signalling System No. 7 - Message Transfer Part,"
      ANSI T1.111, American National Standards Institue (1992).

  [Q.781]  ITU, "Signalling System No. 7 - MTP Level 2 Test
      Specification," ITU-T Recommendation Q.781, ITU-T
      Telecommunication Standardization Sector of ITU, Geneva (March
      1993).  (Previously "CCITT Recommendation")

  [M2PATEST07]  Bidulock, B., "SS7 MTP-User Peer-to-Peer Adaptation
      Layer Test Specifications (M2PA-TEST)," <draft-bidulock-sigtran-
      m2pa-test-07.txt>, Internet Engineering Task Force - Signalling
      Transport Working Group (June 18, 2006).  Work In Progress.

B. Bidulock                    Version 0.0                        Page 6

Internet Draft                   M2PA-IG                   July 11, 2006

Acknowledgements

    The author would like to thank Andrew Booth, Jeffrey Craig, Mark
  Davidson, Mark Erickson, Tom George, Michael Tuexen, for their
  valuable comments and suggestions.

Author's Addresses

  Brian Bidulock
  OpenSS7 Corporation
  1469 Jeffreys Crescent
  Edmonton, AB  T6L 6T1
  Canada

  Phone: +1-780-490-1141
  Email: [email protected]
  URL: http//www.openss7.org/

  This draft expires January 2007.

B. Bidulock                    Version 0.0                        Page 7

Internet Draft                   M2PA-IG                   July 11, 2006

                          Table of Contents

  Status of this Memo .............................................    1
  Copyright .......................................................    1
  Abstract ........................................................    1
  Contents ........................................................    2
  1 Introduction ..................................................    2
  1.1 Conventions .................................................    2
  2 Errata, Addenda and Clarifications ............................    2
  2.1 Initial Sequence Number .....................................    2
  2.1.1 Problem Statement .........................................    2
  2.1.2 Text Changes ..............................................    3
  2.1.3 Solution Description ......................................    3
  2.2 BSN when FSN Out of Order ...................................    3
  2.2.1 Problem Statement .........................................    3
  2.2.2 Text Changes ..............................................    3
  2.2.3 Solution Description ......................................    3
  2.3 LS Ready received during Proving ............................    3
  2.3.1 Problem Statement .........................................    3
  2.3.2 Text Changes ..............................................    4
  2.3.3 Solution Description ......................................    4
  Security Considerations .........................................    5
  IANA Considerations .............................................    5
  0 Change History ................................................    5
  0.0 Version 0.0 .................................................    5
  0.0.0 Change Log ................................................    5
  R References ....................................................    6
  R.1 Normative References ........................................    6
  R.2 Informative References ......................................    6
  Acknowledgements ................................................    7
  Author's Addresses ..............................................    7
  Table of Contents ...............................................    8

B. Bidulock                    Version 0.0                        Page 8

Internet Draft                   M2PA-IG                   July 11, 2006

Intellectual Property

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be found
  in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this specification
  can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at ietf-
  [email protected].

Disclaimer of Validity

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Full Copyright Statement

  Copyright (C) The Internet Society (2006).  This document is subject
  to the rights, licenses and restrictions contained in BCP 78, and
  except as set forth therein, the authors retain all their rights.

Acknowledgement

  Funding for the RFC Editor function is currently provided by the
  Internet Society.

B. Bidulock                    Version 0.0                        Page 9