Subject: AW: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Wed, 7 May 2003 10:32:31 +0200

Bidulock, Tom

The latest Q.704 implementor's guide states the following regarding the code point for XCO and XCA:

"NOTE 1 - Values marked 1) and 2)* are reserved (codes used in Q.2210 for extended changeover order (XCO) and extended changeover acknowledgement (XCA) respectively)."

Their inclusion aims in preventing re-using of these codepoint for other purposes than those foreseen in Q.2210.
No implementation of Q.704 is in turn obliged to handle these codes!

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Mittwoch, 7. Mai 2003 10:00
> An: Schwarzbauer Hanns Juergen
> Cc: 'Tom George'; SIGTRAN e-mail list
> Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> Schwarzbauer,
> 
> XCO/XCA are not unallocated H1 codes.  See Study Group 11 R 137
> (Q.704 Implementors' Guide).  Any MTP implementation which does not
> follow R 137 will have additional implementation errors as it makes
> a number of other corrections to the Q.704 (07/96) document.
> 
> Under the ITU process of making corrections in Implementor's Guides
> (a method followed by this WG as well), they are indeed part of Q.704.
> 
> In fact these H1 codes are reserved for SAAL links.  This is the same
> as ANSI T1.111.4.
> 
> M2PA has more than sufficient reference and need no speak to MTP
> implementation deficiencies which are clearly outside the scope of
> M2PA.
> 
> --brian
> 
> On Wed, 07 May 2003, Schwarzbauer Hanns Juergen wrote:
> 
> > Tom,
> > 
> > I know that the Ho code is identical, because the H0 code 
> identifies the message group (section 15.3 of Q.704)
> > But if you look at Tabel 1/Q.704 you will find none of the 
> extended change-over messages there. 
> > Furthermore Q.701 specifies the following regarding 
> unallocated H0/H1 codes
> > 
> > 6.1.2	Messages containing an unallocated H0/H1 code
> > When messages containing an unallocated H0/H1 code are 
> received at the appropriate functional block within the MTP, 
> they are discarded. There should be no impact on any protocol 
> and, if required, a report should be made to management.
> > 
> > In consequence any MTP implementation according Q.704 
> (that's the vast majority) is allowed to legally discard XCO 
> and XCA messages. 
> > That's the point I want be explicitly mentionned in the I-D.
> > 
> > greetings
> > 
> > HannsJuergen
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Tom George [mailto:[email-masked]]
> > > Gesendet: Dienstag, 6. Mai 2003 21:35
> > > An: SIGTRAN e-mail list
> > > Betreff: Re: AW: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> > > 
> > > 
> > > Hanns,
> > > 
> > > In Q.2210 clause 9.8.1, the XCO/XCA message has the same 
> heading code
> > > (H0) as the Q.704 changeover message. If I understand it 
> > > correctly, the
> > > point of this is to make the MTP3 and MTP3b work 
> together. So it looks
> > > to me like this problem is solved at the MTP3 level.
> > > 
> > > Of course, the links have to be set up so that in changing 
> > > over from the
> > > M2PA link to a traditional TDM link, you don't overwhelm the 
> > > traditional
> > > link. But as far as exchanging the sequence numbers in 
> the changeover
> > > messages, it looks to me like it will work.
> > > 
> > > Let me know if I am missing something. 
> > > 
> > > tomG.
> > > 
> > > Schwarzbauer Hanns Juergen wrote:
> > >   [...]
> > > > > >
> > > > > > Comment on section 1.6.1
> > > > > >
> > > > > > As M2PA requires the usage of XCO and XCA based on MTP3b
> > > > > [Q.2210] caution
> > > > > > has to be taken in case of changeover between M2PA and
> > > > > conventional MTP2
> > > > > > links. Sending these messages back to the TDM based SS7
> > > > > network must be
> > > > > > prohibited as long as no MTP3b functionality supported
> > > > > (nevertheless I doubt
> > > > > > that it will be supported in the future) .
> > > > >
> > > > > What caution?  Q.704 has no problems changing over 
> > > between MTP3b and
> > > > > convetional links.  The extended changeover procedure 
> > > (larger sequence
> > > > > numbers) only applies to the link from which traffic is being
> > > > > diverted and
> > > > > there is no difficulty in changing over between MTP3b and
> > > > > conventional links.
> > > > > In the same manner there is no difficultin in changing over
> > > > > between M2PA
> > > > > and conventional links.
> > > > 
> > > > [HJS] disagree, read Q.2210
> > >   [...]
> > > 
> > > -- 
> > > * Tom George       PB7-24001 (near B-21)      
> > > [email-masked]  *
> > > * 972-519-3168   Intranet:  
> > http://www.ssd.usa.alcatel.com/~tgeorge/  *
> > * Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, 
> Texas 75075  *
> > * I actively disclaim speaking for Alcatel USA, Inc. I do 
> not purport *
> > * to advertise or represent its position,  operations, or 
> activities. *
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 May 2003 10:11:30 -0600

Schwarzbauer,

But it also makes them "reserved" codes and not "unallocated" codes so the
reaction to "unallocated" codes that you claim will cause problems is no
longer appropriate.

--brian

---

From: Tom George <[email-masked]>
Date: Wed, 07 May 2003 18:06:53 -0500

In any event, it looks to me like the draft gives enough of a warning
about the XCO/XCA messages. 

In 1.6.1:

Because M2PA uses larger sequence numbers than MTP2, ***the MTP3
Changeover procedure MUST use the Extended Changeover Order and
Extended Changeover Acknowledgment messages*** described in [Q.2210] and
[T1.111].

In 4.2.3:

M2PA's Sequence Numbers are 24 bits long.  MTP2's Forward and Backward
Sequence Numbers are only seven bits long.  ***Hence it is necessary for
MTP3 to accommodate the larger sequence numbers.*** This is done through
the use of the Extended Changeover Order (XCO) and Extended Changeover
Acknowledgement (XCA) messages instead of the Changeover Order (COO)
and Changeover Acknowledgement (COA) messages. The XCO and XCA
messages are specified in [Q.2210] section 9.8.1 and T1.111.4
[T1.111], section 15.4. Only the XCO and XCA messages from [Q.2210] or
[T1.111] are required. The BSN is placed in the XCO/XCA message as
explained in [Q.2210] and [T1.111].

What else would I need to say?

tomG.

  [...]

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 May 2003 17:20:10 -0600

Tom,

I think you have said quite enough.  Q.703 Annex A has 12-bit sequence
number.  No mention is made of the fact that Q.703 Annex A links require
XCO/XCA for changeover in GB, anywhere!  Yet, low-speed COO/COA (7-bit
FSNC field) are obviously unusable for Q.703 Annex A operation.

M2PA is already far better specified thatn Q.703 Annex A in this regard
with ample references.  Don't change a thing. :)

--brian