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

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Thu, 8 May 2003 09:50:07 +0200

Bidulock,

albeit it's marked "reserved" it's still "unallocated" from Q.704 point of view.

so the problem is still relevant and unsolved unless you point me to a special section in current Q.704 (not Q.2210) showing how to deal with these messages.

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Mittwoch, 7. Mai 2003 18:12
> An: Schwarzbauer Hanns Juergen
> Cc: 'Tom George'; SIGTRAN e-mail list
> Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> 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
> 
> On Wed, 07 May 2003, Schwarzbauer Hanns Juergen wrote:
> 
> > 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 ¦
> > > 
> 
> -- 
> 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: Thu, 8 May 2003 03:30:26 -0600

Schwarzbauer,

Reserved and unallocated are not the same thing.

Q.704 implementation guide references Q.2210 and T1.111.4 does describe
XCO/XCA.  M2PA references Q.2210 and T1.111.4 which is sufficient.

Where does ITU documents say what changeover message to use with Q.703
Annex A? (Answer: nowhere).

It is not the place of the M2PA specification to address any deficiencies
you might consider exists in Q.704.  M2PA references the appropriate
specifications and that is sufficient.

--brian

On Thu, 08 May 2003, Schwarzbauer Hanns Juergen wrote:

> so the problem is still relevant and unsolved unless you point me to a
> special section in current Q.704 (not Q.2210) showing how to deal with these
> messages.
> 
> greetings
> 
> HannsJuergen
> 
>