| draft-george-sigtran-m2pa-interop-00 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-george-sigtran-m2pa-interop-00.txt.
Network Working Group Tom George
INTERNET-DRAFT Monique Bernard
Jeff Copley
Wayne Davis
Cliff Thomas
Alcatel
Expires May 2002 November 9, 2001
M2PA Interoperability Test Results and Issues
<draft-george-sigtran-m2pa-interop-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. 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.
To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document captures problems and issues discovered on the SIGTRAN
mailing list and at M2PA Interoperability Tests. This document will be
updated after each interoperability test to include any new
issues. Two basic sets of problems are identified by this draft: (1)
issues that need to be addressed in the next revision of the M2PA
draft, and (2) issues that were found that are strictly implementation
problems.
TABLE OF CONTENTS
1. Introduction.............................................
2. Specification Issues ....................................
2.1 SCTP Acknowledgement .................................
2.2 Link Status Out of Service Message ...................
2.3 Aborting an Association for Performance ..............
2.4 Aborting an Association for MTP3 Stop ................
2.5 Failing a Link .......................................
2.6 Order of Transmission ................................
2.7 Local Processor Outage and Link Status Ready .........
2.8 Proper Stream for Proving Data Messages ..............
2.9 Tuning SCTP Parameters ...............................
2.10 M2PA Keep Alive Message ..............................
2.11 Emergency Changeover for Japanese SS7 ................
2.12 Eliminate Client/Server Distinction ..................
2.13 Resolving Normal and Emergency Proving ...............
2.14 Need Reference for Busy ..............................
2.15 Processor Outage and Busy in Various States ..........
3. Implementation Issues ...................................
3.1 None ..................................................
4. Acknowledgements.........................................
5. Authors Addresses........................................
6. References...............................................
1. Introduction
This document captures problems and issues discovered on the SIGTRAN
email list and at M2PA Interoperability Tests. This document will be
updated after each interoperability test to include any new issues.
Two categories of problems will be identified in this draft:
(1) issues that need to be addressed in the next revision of the
M2PA draft.
(2) issues that were found that are strictly implementation
problems.
This document is intended to provoke discussion of M2PA issues with
the goal of improving the protocol.
Section 2 of this document details specification issues that need to
be addressed in the next revision of the M2PA draft. Section 3 details
implemenation problems with the current version of the M2PA
draft. Both sections will use the following format for each issue:
Problem/Issue: A summary description of the problem/issue.
Description: A detailed description of the problem.
Advice/Solution: A synopsis of the solution that needs to be applied
to the specification or implementation.
Found at: The bakeoff that this issue arose at or when on the
mailing list the issue was raised.
2. Specification Issues
This section captures issues that need to be addressed in the next
revision of the M2PA draft. Each problem is described, along with a
suggested action to resolve the problem. All changes here are
suggestions that are subject to full working group review.
2.1 SCTP Acknowledgement
Problem/Issue:
SCTP acknowledges messages independent of delivery to upper
layer. This can result in message loss during Processor Outage or Busy
condition.
Description:
In MTP2, detection of LPO (or Busy) causes the MTP2 layer to stop
acknowledgement of incoming messages immediately. This forces the
sending MTP to keep these messages in case they are needed for
changeover.
In M2PA/SCTP, there is no mechanism for immediately stopping
acknowledgement of incoming messages. If M2PA detects LPO, it informs
the peer, who then stops transmitting. While the Link Status Processor
Outage messages traverses the link, numerous messages could be sent to
the SCTP receive queue at the LPO end. These messages are removed from
the sending SCTP's transmit queue. In the event of a failure at the
receiver requiring a changeover, these messages would be lost.
Several possible solutions have been suggested for this problem:
(1) M2PA ABORTs the association when it detects Local Processor
Outage.
(2) M2PA tells SCTP to set its a_rwnd = 0 when it detects Local
Processor Outage or Busy.
(3) SCTP sends a "GAP ACK with no gap": SCTP acknowledges received data
chunks immediately but doesn't advance the cumulative TSN until
M2PA tells it to. This may result in the first GAP ACK block
starting immediately after the Cumulative TSN (GAP ack block start
= 0).
(4) M2PA level ack - SCTP does not ack a message until M2PA gives
permission.
(5) M2PA sequence numbers and queues - M2PA would have its own set of
sequence numbers for the User Data messages. These messages would
be acked at the M2PA level. M2PA would retain a sent message until
it received acknowledgement from the receiving M2PA. The M2PA
sequence numbers would be used for retrieval during changeover.
Some comments about these possible solutions:
Idea (1) is suitable for dealing with Local Processor Outage. It is
not a good way to handle a Busy condition. If this is used for LPO,
another method (such as 2) would be needed for Busy.
It is not clear if (2) prevents packet loss effectively. Some
clarification from the TSV Working Group is needed.
A problem with (2) is that it stops Link Status as well as User Data
messages. This would be bad for M2PA, since the M2PA peers would not
be able to communicate status changes.
Idea (3) appears to be the best choice from a technical point of
view. The sender would retain a copy of the message until the
cumulative TSN Ack is received. This would prevent message
loss. Before using this idea, though, it should be discussed on the
TSVWG mail list to make sure that it is compatible with the SCTP RFC.
Idea (4) could cause problems with SCTP parameters. SCTP expects
acknowledgement within certain time limits. Introducing a delay to
receive approval from an upper layer could cause unnecessary
retransmissions or even association loss.
Idea (5) fixes the problem. It requires no changes to the SCTP
protocol. But it would be a big change to the m2PA protocol.
Advice/Solution:
Seek clarification on (2) and (3) in TSVWG.
Found at:
This problem has been discussed on the SIGTRAN e-mail list. See the
following threads:
"SCTP socket API and M2PA changeover" - beginning 10/30/01
"M2PA: Acknowledgement Problem" - beginning 05/25/01
The problem was discussed at the 1st M2PA Interoperability Test.
2.2 Link Status Out of Service Message
Problem/Issue:
There is no Link Status Out of Service message.
Description:
If M2PA keeps an association up when the link is out of service, there
should be a Link Status Out of Service message. M2PA could then inform
its peer that it is in the Out of Service state.
Advice/Solution:
Add another value to the list in 2.2.2 Link Status.
Add advice on when to send the message.
Found at:
This was suggested on the SIGTRAN e-mail list.
2.3 Aborting an Association for Performance
Problem/Issue:
The M2PA draft does not give clear advice on when to abort an
association because of poor association performance.
Description:
The M2PA draft suggests that M2PA should abort an association when its
performance is unsatisfactory. However, there are no firm guidelines
for deciding if the association performance is unsatisfactory.
It should be possible to set SCTP parameters so that SCTP monitors its
own performance and decides if the association should be terminated.
Advice/Solution:
Remove text from 4.1.6 Error Monitoring recommending that M2PA ABORT
an association for performance reasons.
Remove references to this in several places in the draft.
Found at:
This was discussed at the 1st 1st M2PA Interoperability Test.
2.4 Aborting an Association for MTP3 Stop
Problem/Issue:
The M2PA draft does not give clear advice on when to abort an
association because of an MTP3 Stop command.
Description:
The M2PA draft [M2PAv3] recommends that M2PA not ABORT an association
during the alignment procedure. If M2PA receives MTP3 Stop during
alignment, M2PA should leave the association up and return to the Out
of Service state.
Furthermore, the draft states that M2PA should ABORT the association
if MTP3 Stop is received while the link is In Service. This was
thought to be necessary to stop SCTP transmission and do data
retrieval for changeover.
However, M2PA should be able to leave the association up even when it
receives the MTP3 Stop command. Some care has to be taken to make sure
that User Data messages are not transmitted while the link is out of
service.
The association should be aborted when:
a. SCTP aborts the association (Communication Lost).
b. Layer Management aborts the association (e.g., to re-initialize
SCTP parameters).
There is no need for M2PA to abort the association.
Advice/Solution:
Remove text from 4.1.6 Error Monitoring recommending that M2PA ABORT
an association for performance reasons.
Remove references to this in several places in the draft.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.5 Failing a Link
Problem/Issue:
When should the link be failed?
Description:
This is related to the questions about aborting the association and
the Link Status OOS message.
Advice/Solution:
Since the link should have an OOS state and the association should not
be aborted for MTP3 Stop or association performance, M2PA should only
fail the link when:
a. MTP3 Stop
b. SCTP Communication Lost
c. M2PA receives Link Status OOS
In none of these cases should M2PA ABORT the association.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.6 Order of Transmission
Problem/Issue:
There has been some confusion about the transmission order of the MTP3
message within the M2PA packet.
Description:
M2PA draft 3 contains some explanation of this, but it needs to be
more explicit.
Octets given from MTP3 to M2PA should be transmitted in the same order
as specified in the SS7 standards.
Advice/Solution:
Add more sample fields to the example picture at the end of 2.2.1.
Reverse the order of the bits in the Spare/PRI octet.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.7 Local Processor Outage and Link Status Ready
Problem/Issue:
If M2PA receives a Local Processor Outage (LPO) while it is sending
Link Status Ready messages, what should it do?
Description:
The philosophy here is to continue the alignment/proving procedure so
that the link is ready for service. So M2PA should continue sending
its Link Status Ready messages periodically.
However, M2PA should not allow the peer to begin sending User Data
messages if it has an LPO. So M2PA should also send the Link Status
Processor Outage message periodically.
Advice/Solution:
Clarify this in the M2PA section on Alignment.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.8 Proper Stream for Proving Data Messages
Problem/Issue:
On which stream should Proving Data messages be sent?
Description:
A problem can arise from sending Proving Data messages on the Data
stream, as is required by M2PA draft 3. The Proving Data messages
cause the Stream Sequence Number (SSN) on the Data Stream to be
incremented. This could cause problems verifying which SSN belongs to
which message.
Advice/Solution:
Send the Proving Data on the Status stream.
This eliminates the need for separate Link Status Proving and Proving
Data messages. Only the Link Status message is needed. An option can
be allowed to add bytes to the Link Status message.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.9 Tuning SCTP Parameters
Problem/Issue:
M2PA needs values for SCTP parameters different from the values
recommended in the SCTP RFC.
Description:
Some of the SCTP parameter values recommended in [RFC2960] would be
unsuitable for SS7 use. SS7 needs to detect failure conditions
quickly.
Advice/Solution:
There should be some discussion of these values on the SIGTRAN
list. The values should be documented in an applicability statement.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.10 M2PA Keep Alive Message
Problem/Issue:
Does M2PA need a Keep Alive message?
Description:
There is a concern that there may be a conflict between these two
goals:
a. Making SCTP parameters tight enough that M2PA is informed of
association failure in a timely manner, and
b. Not making SCTP parameters so tight that they abort an
association because of brief glitches in the IP network.
A Keep Alive message between M2PA peers was suggested to avoid this
problem. M2PA would periodically send an unordered Keep Alive message
on the Status stream. If M2PA did not receive a Keep Alive message
from its peer for a certain time period, it would fail the link.
Advice/Solution:
If SCTP parameters can be set to monitor association performance
adequately, then a Keep Alive message would not be necessary. This
issue is shelved until the issue with the SCTP parameters is resolved.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.11 Emergency Changeover for Japanese SS7
Problem/Issue:
There is a requirement in Japanese SS7 that MTP be able to retrieve
all messages (unsent and unacked) for changeover.
Description:
This was omitted from [M2PAv3] inadvertently.
Advice/Solution:
Add this option to 4.2.6.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.12 Eliminate Client/Server Distinction
Problem/Issue:
The distinction between Client and Server, even for initiating an
association, may not be necessary. A Client and Server were designated
in [M2PAv3] to prevent duplicate associations from being created.
Description:
If both ends of the link know the source and destination IP address
and port number, then SCTP will prevent the duplicate associations
from being created.
It is necessary that the SCTP at (at least) one of the endpoints be
listening on the port that the other end is attempting to begin the
association with. In practice, this would probably mean that at least
one end's SCTP would be listening on the M2PA registered port.
Advice/Solution:
Remove the Client/Server distinction and replace it with advice about
beginning the association.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.13 Resolving Normal and Emergency Proving
Problem/Issue:
How should M2PA proceed if one end wants to do Emergency Proving and
the other wants to do Normal Proving?
Description:
The two endpoints need to agree on which time will be used for the
proving period. For example, what should happen when one M2PA begins
Normal proving, and then its peer begins Emergency proving?
This is addressed in the MTP specifications. Emergency proving takes
precedence over Normal.
In the example, the end doing Normal proving would adjust its timer to
the Emergency value, but continue sending Normal proving messages.
Advice/Solution:
Clarify this in the M2PA draft.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.14 Need Reference for Busy
Problem/Issue:
The M2PA draft 4.1.5 "Level 2 Flow Control" does not refer to a
specific section of [RFC2960].
Description:
Congestion control is described in section 7 of [RFC2960].
Advice/Solution:
Refer to section 7 of [RFC2960].
Found at:
This was discussed at the 1st M2PA Interoperability Test.
2.15 Processor Outage and Busy in Various States
Problem/Issue:
Can Link Status Processor Outage and Busy be received in all states?
Is the behavior the same in all cases?
Description:
The M2PA draft states requirements for Processor Outage and Busy
without mentioning anything about the M2PA state. It is possible that
the behavior may be different in some states.
Advice/Solution:
Some investigation is needed to see how Processor Outage and Busy are
treated differently in various states.
Found at:
This was discussed at the 1st M2PA Interoperability Test.
3. Implementation Issues
This section presents implementation issues discovered at various
interoperability tests. These issues do NOT require or indicate
changes needed to the M2PA draft. Instead, these issues provide
guidance to future implementors and provide input to applicability
documents where appropriate.
3.1 None
4. Acknowledgements
The authors would like to thank the following people for their
participation in the 1st M2PA Interoperability Test (October 29 -
November 1, 2001 at Alcatel in Plano):
Avi Chibotaro (Airslide Systems)
Ronen Katav (Airslide Systems)
Billy Chang (Catapult Communications)
Loren Chao (Catapult Communications)
Richard Mott (Catapult Communications)
Vijay Patel (Catapult Communications)
Ron Spiker (Catapult Communications)
Julien Dauverd (Cisco Systems)
Wayne Taylor (Cisco Systems)
Alex Katchourine (Inet)
Ushit Kumar (Inet)
Steve Tsao (Inet)
Brian Bidulock (OpenSS7)
Andrew Bidulock (OpenSS7)
Heinz Prantner (RadiSys)
Deepa Tonse (RadiSys)
Cheryl Baringer (Alcatel)
Robert Shull (Alcatel)
Lydia Huang (Alcatel)
Sandeep Dilwali
5. Authors Addresses
Tom George
Alcatel USA, Inc.
1000 Coit Road
Plano, TX 75075
USA
EMail: Tom.George@alcatel.com
Tel: +1-972-519-3168
Monique Bernard
Alcatel USA, Inc.
1000 Coit Road
Plano, TX 75075
USA
EMail: Monique.Bernard@alcatel.com
Tel: +1-972-519-3775
Jeff Copley
Alcatel USA, Inc.
1000 Coit Road
Plano, TX 75075
USA
EMail: Jeff.Copley@alcatel.com
Tel: +1-972-519-3758
Wayne Davis
Alcatel USA, Inc.
1000 Coit Road
Plano, TX 75075
USA
EMail: Wayne.Davis@alcatel.com
Tel: +1-972-477-8395
Cliff Thomas
Alcatel USA, Inc.
1000 Coit Road
Plano, TX 75075
USA
EMail: Cliff.Thomas@alcatel.com
Tel: +1-972-477-7015
6. References
[RFC2960] - Stewart, R.,Xie Q., et. al. - "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[M2PAv3] - George, Tom, et. al. - "SS7 MTP2-User Peer-to-Peer
Adaptation Layer", draft-ietf-sigtran-m2pa-03a.txt, July 20, 2001.
This Internet Draft expires May 2002.
|
Documentation