Subject: Re: M2PA changes for version 3

From: Patrick Lam <[email-masked]>
Date: Fri, 10 Aug 2001 13:55:51 -0700

Hi Tom:

After a quick look over v3, I have a few questions that need you to clarify:

1.  p.22, section 4.1.2 (MTP and SCTP Entities),
"Whenever the association is terminated, the client M2PA should
establish the association as soon as the termination procedure is
complete."

Why should we establish an association "as soon as" after it is terminated?

2.  p.28, section 4.1.3 (Link Alignment),
" .....    (d) M2PA has received a Link Status Ready OR User Data
       message from its peer."

Should the above sentence refer to "Link Status Ready"?  Or " Link Status Proving
Complete"?

3.  p.32, section 4.2.5 (MTP3 Signaling Link Congestion),
" ... For national networks with multiple
congestion threshold levels, M2PA shall notify MTP3 of the congestion
and discard status levels."

The above paragraph said that M2PA shall discard the status level.  But later on,
p.43, section 5.6 (MTP3 Signaling Link Congestion), the figure shows that M2PA has to
reply with the "level" indicated.

So, should M2PA discard the level or indicate it to MTP3?

Thanks very much in advance,

Patrick.

Tom George wrote:

> M2PA Changes for version 3
> 07/20/2001
>
> Here are the changes in draft-ietf-sigtran-m2pa-03.txt (M2PA version
> 3), and a list of open issues.
>
> If anyone wants to study the changes in detail, I have a "diff" file I
> can send.
>
> A short summary of the changes:
> -------------------------------
>
> 1. Proving procedure added to alignment. It includes normal and
>    emergency proving.
>
> 2. Changed header to the common header used by other adaptation
>    layers.
>
> 3. SCTP association is now created "early", rather than waiting for
>    MTP3 Start.
>
> 4. Added a section on version control.
>
> 5. Added extensibility text in section 7.2.
>
> 6. A lot of clarifying, rewording, and corrections.
>
> A more detailed list of changes:
> --------------------------------
>
> This is not a complete list of changes. I did not include minor
> rewording.
>
> 1.7.4 SCTP Stream Management: The new Proving Data messages are sent
> on the Data stream.
>
> 1.8.1 Definition of the M2PA / MTP Level 3 boundary: Added LPO and LPO
> Recovered to the list of primitives.
>
> 1.8.1 Definition of the M2PA / MTP Level 3 boundary: Emergency and
> Emergency Ceases are no longer ignored by M2PA.
>
> 1.9 Differences Between M2PA and M2UA: Added item (e) to the list of
> differences.
>
> 2.1 Common Message Header: Changed to the common message header.
>
> 2.1.2 Spare: Added a description of the Spare field.
>
> 2.1.3 Message Class: Added description of Message Class.
>
> 2.1.4 Message Type: Added Proving Data to list of Message Types.
>
> 2.1.4 Message Length: (oops, there are two section 2.1.4's) Message
> Length now INCLUDES the header.
>
> 2.2.1 User Data: Added some text to clarify the transmission order of
> the Data in the User Data message. This is similar to the wording in
> the M3UA draft.
>
> 2.2.2 Link Status: Changed the list of values, and added new ones.
>
> 2.2.3 Proving Data: Added the Proving Data message.
>
> 3.  M2PA Link State Control: Changed the state diagram section. Now
> there are 2 diagrams. One shows the states of the M2PA link. The other
> shows the states of M2PA's management of the association.
>
> 3.  M2PA Link State Control: Changed definition of AIP state.
>
> 3.  M2PA Link State Control: INS-LOCAL is replaced by ALIGNED READY.
>
> 3. Figure 6: various changes to the diagram
>
> 3. Figure 7: Added this new figure.
>
> 4.1.2 MTP and SCTP Entities: This information was in the Alignment
> section. I separated it into its own section.
>
> 4.1.2: Changed the procedure to recommend that the SCTP association be
> created early. M2PA does not have to wait for MTP3 Start.
>
> 4.1.2: Figure 10. Removed P2, since it is not used.
>
> 4.1.2: Table 3. Changed P2 to PW. There was no P2 in Figure 10.
>
> 4.1.2: Replaced "endpoint" with "IP address" in several places where
> it was more accurate.
>
> 4.1.3 Link Alignment: Changed this section significantly. Added a
> proving procedure. Added normal and emergency alignment.
>
> 4.1.3 Link Alignment: M2PA will attempt to complere alignment if there
> is a processor outage.
>
> 4.1.4 Processor Outage: Removed the statement about discarding
> messages.
>
> 4.1.4 Processor Outage: PO causes timer T6 to stop.
>
> 4.1.6 Error Monitoring: Added more criteria for evaluating link
> performance. Made this implementation dependent.
>
> 4.1.8 M2PA Version Control: Added this section. It is similar to
> wording in the UA drafts.
>
> 4.2.5 MTP3 Signaling Link Congestion: Corrected the information that
> is sent to MTP3.
>
> 4.2.6.1 Multiple User Data Streams and Changeover: Added this
> section. It explores the possibility of links with multiple streams.
>
> 5.1 Link Initialization (Alignment): Changed the diagram to reflect
> the new procedure.
>
> 7.2  M2PA Protocol Extensions: Added this section. It is similar to
> wording in the UA drafts.
>
> Mistakes I've already found:
> ----------------------------
>
> 2.1.4: Make the 2nd section 2.1.4 into 2.1.5.
>
> 2.2.2 Link Status: The phrase "Except as modified later in this
> section," should be deleted, since the format is not modified later.
>
> Text in the paragraph above Figure 10: Should say "IP addresses", not
> "endpoints".
>
> --
> * Tom George        972-519-3168         [email-masked]   *
> * PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
> * Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
> * I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
> * to advertise or represent its position,  operations, or activities. *
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 16:09:11 -0500

Patrick,

Please see comments below...

Patrick Lam wrote:                                        (Fri, 10 Aug 2001 13:55:51)
> Why should we establish an association "as soon as" after it is terminated?

Good point.  It would be proper for MTP mangement to follow whatever
signalling data link and signalling terminal allocation procedures
are appropriate for the environment.  Even the basic procedures stand-off
for an interval.  The MTP implementation should be permitted to take
actions which are consistent with such as those described in T1.111.4
Clause 12, or Q.704 Clause 12, even if only basic procedures are supported.
The M2PA draft should open the door to this implementation and should
not be dictating when restarting the association is attempted.  These
are MTP management functions outside the scope of M2PA.

> So, should M2PA discard the level or indicate it to MTP3?

Perhaps this should say "congestion- and discard-status levels."  It
is not intended to say to discard the status level.

--brian

> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Patrick Lam <[email-masked]>
Date: Mon, 13 Aug 2001 11:13:22 -0700

Tom:

> created early. M2PA does not have to wait for MTP3 Start.

Can you explain a little more here?  Do you mean that a SCTP association should be
started at M2PA initialization?  Should that association (so as the socket descriptor)
stay active until M2PA becomes inactive?

If the above is true, can we establish more than one association between two entities
at M2PA initialization?

Thanks a lot in advance,

Patrick.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 19:01:42 -0500

Patrick,

Short answer, initialize them whenever your implementation wants.

The long answer: when using SCTP to emulate the "wire" that an SS7 links
communicates over, just as in the MTP3b case where SSCOP/AAL5 is used to
emulate the "wire", the "wire" can theoretically exist any time before
communication is attempted on the connection and can theoretically cease
to exist any time after communication is no longer necessary on the
connection.

Because it takes time to establish and "train" an SCTP association, it
is presumed that it will be established some time before it is needed to
support an M2PA link, and that it will be not be shutdown if the
MTP3 can forsee that it may be necessary to use it again in the immediate
future.

Establishment of signalling data links (which SCTP is emulating) is an
MTP3 management procedure which is well documented.  If the Basic procedures
are used, the siganlling data links are established at configuration time,
rather than at link restoration time.  This may even be before the M2PA
subsystem is available on some implementations.

This is no different from the MTP3b case: AAL5 VCs are established
independent of the establishment of SCCOP connections.  The establishment of
VCs is a management function.  SSCOP has no mechanism for the establishment
of underlying VCs, just for initializing and syncing the SSCOP session on
an pre-existing channel.

What M2PA still lacks is an acknowledgement procedure (such as that provided
by SSCOP in MTP3b) which is independent of an underlying network
acknowledgement.  M2PA is permitting SCTP to acknowledge frames to its peer
which would not be acknowledged between SSCOP peers.  This is because SCTP
uses its acks to calculate RTTs, SSCOP does not.  SCTP is a network-level
ack, whereas, SSCOP is a user-level ack.

--brian

Patrick Lam wrote:                                        (Mon, 13 Aug 2001 11:13:22)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---