Subject: RE: FW: [Sigtran] M2PA Last Call Comment

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Mon, 14 Jul 2003 12:27:15 +0200

Bidulock,

your answer is confusing. why should one side of an M2PA link adhere to Q.2140 and the other o Q.703 proving procedures? 
You are still assuming a direct and tight coupling between the TDM and the IP side.
In turn the throughput of the M2PA link could NEVER exceed that of the corresponding TDM link: 64 kbit in case of Q.703 (excluding annex A for the moment). That's not what M2PA was designed for!

greetings

HannsJuergen

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 14, 2003 12:22 PM
> To: Schwarzbauer Hanns Juergen
> Cc: List: IETF sigtran (E-Mail)
> Subject: Re: FW: [Sigtran] M2PA Last Call Comment
> 
> 
> Schwarzbauer,
> 
> Huh?  In the diagram I gave, it is only an M2PA link.  One side is
> following Q.2140 state machine procedures, the other is following
> Q.703 state machine procedures.
> 
> This has nothing to do with MTP3.
> 
> --brian
> 
> Schwarzbauer Hanns Juergen wrote:                             
>                 (Mon, 14 Jul 2003 12:14:56)
> > Brian,
> > 
> > sorry, I can't agree. 
> > My example scenario contains two SS7 nodes, both having 
> only M2PA links
> > between them. I assume that this is still a valid scenario. 
>  Furthermore, if
> > you have an SS7 node with more than one TDM based SS7 link 
> feeding this M2PA
> > link, what are you going to to there.
> > 
> > We are again going to the discussion we had several weeks ago: 
> > 
> > is there an MTP Level 3 coupling the TDM links and the M2PA 
> links and my
> > answer is still YES. Having that in mind, proving on one 
> link is completely
> > independent from proving on another link. 
> > 
> > 
> > greetings
> > 
> > HannsJuergen
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Monday, July 14, 2003 11:40 AM
> > > To: Schwarzbauer Hanns Juergen
> > > Cc: List: IETF sigtran (E-Mail)
> > > Subject: Re: FW: [Sigtran] M2PA Last Call Comment
> > > 
> > > 
> > > Hanns Juergen,
> > > 
> > > Consider that one side follows Q.703 and requires proving 
> while the
> > > other side follows Q.2140 and foregoes proving.  The 
> following will
> > > occur:
> > > 
> > >     
> > > 
> ___________________________________________________________________
> > >    |                                                          
> > >          |
> > >    |                Q.2140                      Q.703         
> > >          |
> > >    |                                                          
> > >          |
> > >    |        OUT-OF-SERVICE  ----------------->                
> > >          |
> > >    |                        <-----------------  
> > > OUT-OF-SERVICE         |
> > >    |                :start                                    
> > >          |
> > >    |             ALIGNMENT  ----------------->                
> > >          |
> > >    |                                            :start        
> > >          |
> > >    |                        <-----------------  ALIGNMENT     
> > >          |
> > >    |                 READY  ----------------->                
> > >          |
> > >    |                        <-----------------  
> > > PROVING-NORMAL         |
> > >    |                              !                           
> > >          |
> > >    |                              !  T3         1.0 <= T3 <= 
> > > 1.5       |
> > >    |                              !                           
> > >          |
> > >    |                        <-----------------  
> > > OUT-OF-SERVICE         |
> > >    |                                                          
> > >          |
> > >    
> > > 
> |___________________________________________________________________|
> > > 
> > > Note that the Q.703 side must ignore the READY and await a
> > > PROVING-NORMAL or PROVING-EMERGENCY (See Q.781 test case 
> 2.3) and will
> > > time out (See Q.781 test case 1.3).
> > > 
> > > Therefore unless both sides follow the Q.2140 procedures 
> it will be
> > > impossible to forego proving and successfuly align the link.
> > > 
> > > The issue has little to do with MTP Level 3.  It is solely an 
> > > MTP Level
> > > 2 compatibility issue, speaks to interoperability, and the 
> > > keyword MUST
> > > should be used.  So,
> > > 
> > >   The proving period MAY be ommitted if this is allowed by the
> > >   applicable standard (e.g., [Q.2140]); however, the same 
> > > standard MUST
> > >   be followed on both sides of the M2PA link.
> > > 
> > > Does that clear things up for you?
> > > 
> > > --brian
> > > 
> > > Schwarzbauer Hanns Juergen wrote:                   (Mon, 14 
> > > Jul 2003 10:31:54)
> > > > resend, because "sigtran list" wasn't included
> > > > 
> > > > -----Original Message-----
> > > > From: Schwarzbauer Hanns Juergen 
> > > > Sent: Monday, July 14, 2003 8:46 AM
> > > > To: [email-masked]'
> > > > Subject: RE: [Sigtran] M2PA Last Call Comment
> > > > 
> > > > 
> > > > Brian,
> > > > 
> > > > I don't understand your second point. There is an MTP L3 
> > > between the TDM and
> > > > the IP side, so both sides are decoupled. Thus I can't 
> > > agree with this
> > > > point.
> > > > 
> > > > greetings
> > > > 
> > > > HannsJuergen
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Saturday, July 12, 2003 7:04 AM
> > > > > To: [email-masked]'
> > > > > Subject: [Sigtran] M2PA Last Call Comment
> > > > > 
> > > > > 
> > > > >   The proving period MAY be omitted if this is allowed by the 
> > > > > applicable
> > > > >   MTP2 standard (e. g., [Q.2210]).
> > > > > 
> > > > > The reference should be Q.2140.
> > > > > 
> > > > > It should also be noted that the same approach MUST be 
> > > > > followed on both sides
> > > > > the link.  Otherwise, one side following Q.703 will have T3 
> > > > > timer expire
> > > > > waiting for PROVING-NORMAL from the side foregoing proving.
> > > > > 
> > > > > --brian
> > > > > 
> > > > > -- 
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > > 
> > > > > _______________________________________________
> > > > > 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
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran