draft-george-sigtran-m2pa-interop-00.txt

No7信令,我需要交换类似的代码, 请店长审核,谢谢了,急着交换,谢谢

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: [e-mail]
Tel: [phone]

Monique Bernard
Alcatel USA, Inc. 
1000 Coit Road          
Plano, TX 75075    
USA
EMail: [e-mail]
Tel: [phone]

Jeff Copley
Alcatel USA, Inc. 
1000 Coit Road          
Plano, TX 75075    
USA
EMail: [e-mail]
Tel: [phone]

Wayne Davis
Alcatel USA, Inc. 
1000 Coit Road          
Plano, TX 75075    
USA
EMail: [e-mail]
Tel: [phone]

Cliff Thomas
Alcatel USA, Inc. 
1000 Coit Road          
Plano, TX 75075    
USA
EMail: [e-mail]
Tel: [phone]


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.