Subject: [Sigtran] RE: [Sigtran] RE: [Sigtran] Re: [Sigtran] Re: [Sigtran] ×ª·¢: [Sigtran] Is M2UA less relevant?

From: Hecht Martin <[email-masked]>
Date: Wed, 12 May 2004 15:40:19 -0400

Brian,

What I was thinking concerning this issue was that the MTP-2 spec states
that unexpected signal units received in the Not Aligned (NA) state are
ignored.  So I figured that a Ready received in the NA state would be
ignored in M2PA also.  Thus, I've added a configuration item to allow Ready
to be accepted in the NA state and to go from this state to the In-Service
state directly.

Martin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, May 12, 2004 3:34 PM
To: Hecht Martin
Cc: 'Spencer Dawkins'; SIGTRAN Mailing List
Subject: Re: [Sigtran] RE: [Sigtran] Re: [Sigtran] Re: [Sigtran] ×ª·¢:
[Sigtran] Is M2UA less relevant?

Martin,

The M2PA spec says that "[t]he proving period MAY be omitted if this is
allowed by the applicable MTP2 standard (e.g. [Q.2140])."  That was the
intent
of including the "without Proving" test cases.  As to it being applied on
one
side and not on the other, I don't know of anything keeping the MTP2 receive
state machine in M2PA from adapting to the presence or absence of proving.
It
could certainly be a configuration option as to whether proving is to be
performed on the sending side.  The decision whether to perform proving or
not
is a complex one that depending on the characteristics of the underlying
netowrk.  Operators or other operational standards bodies will likely set
their own requirements in this regard.  I think that the test spec is
consistent with this.

If the WG (and Lyndon) are agreeable, I will prepare a draft of the test
spec
with change log removed and the ietf designation that could be reviewed for
advancing.

Other comments?

--brian

Hecht Martin wrote:
(Wed, 12 May 2004 14:19:31)
> Brian,
> 
> Thanks for the info.
> 
> Concerning test-05, I would like to see this become an official document.
It
> could then be used for conformance/acceptance testing at customer sites,
> similar to the Q.781 tests.  The scripts could be used on an INET, for
> example.  (I'm sure you thought of this.)
> 
> BTW, the two tests (and others):
> 
> 3.1.5.3.  Forward Direction without Proving
> 3.1.5.4.  Reverse Direction without Proving
> 
> seem to point out that one side could be setup to not do proving while the
> other does it.  In this case the links would not align (?). Is the
intention
> here to have this be a configurable parameter?  (I have made it
configurable
> in my implementation.)
> 
> Martin Hecht
> Signaling Core Group, Embedded Division
> Comverse, Inc
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2004 2:16 PM
> To: Hecht Martin
> Cc: 'Spencer Dawkins'; SIGTRAN Mailing List
> Subject: Re: [Sigtran] RE: [Sigtran] Re: [Sigtran] Re: [Sigtran] ×ª·¢:
> [Sigtran] Is M2UA less relevant?
> 
> 
> Martin,
> 
> AFAIK the last M2PA draft is in the RFC Editor's queue so there is
> little that we can do to push it faster.  The most recent draft is
> the final unless some typo is corrected at 48 hours.
> 
> OTOH, draft-bidulock-sigtran-m2pa-test-05 seems to have all issues
> resolved.  It would likely be useful to the industry to advance this
> test draft as an INFORMATIONAL RFC within the WG.  Comments?
> 
> --brian
> 
> Hecht Martin wrote:
> (Wed, 12 May 2004 13:06:38)
> > To all,
> > 
> > I started working with the Cisco ITP connecting via M2PA and discovered
> that
> > it only supports Draft 2 of the M2PA spec.  I contacted them and they
are
> > waiting for the RFC before they will upgrade their software.
> > 
> > Is it time to move on to the RFC with M2PA?
> > 
> > Martin Hecht
> > Signaling Core Group, Embedded Division
> > Comverse, Inc
> > 
> > 
> > -----Original Message-----
> > From: Spencer Dawkins [mailto:[email-masked]]
> > Sent: Tuesday, May 11, 2004 11:35 PM
> > To: SIGTRAN Mailing List
> > Subject: [Sigtran] Re: [Sigtran] Re: [Sigtran] ×ª·¢: [Sigtran] Is M2UA
> > less relevant?
> > 
> > 
> > Hi, Brian,
> > 
> > I promise not to read e-mail without caffeine for at least a week -
> > you're correct, I was thinking M2PA. To respond to the original
> > question (now that I'm focused back on the right protocol), no, we
> > haven't seen as many customer requests for M2UA as we have for M2PA.
> > 
> > Thanks,
> > 
> > Spencer
> > 
> > p.s. Isn't M2UA actually RFC 3331? There's obviously not enough
> > caffeine to go around ...
> > 
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "Spencer Dawkins" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Monday, May 10, 2004 9:42 AM
> > Subject: Re: [Sigtran] Re: [Sigtran] ×ª·¢: [Sigtran] Is M2UA less
> > relevant?
> > 
> > 
> > > Spencer,
> > >
> > > That might apply to M2PA, but not M2UA, which was an RFC (RFC 3332)
> > back
> > > in the fall of 2002.
> > >
> > > --brian
> > >
> > > Spencer Dawkins wrote:
> > (Mon, 10 May 2004 06:31:14)
> > > > Just a minor point - at least one test equipment vendor prefers
> > not to
> > > > support Internet Drafts, so it's difficult to judge the relevance
> > of
> > > > M2UA before it's available in RFC form.
> > > >
> > > > - I've asserted that Working Group Snapshots could be defined in
> > such
> > > > a way as to make pre-RFC support more attractive, but the IETF
> > isn't
> > > > headed that way now.
> > > >
> > > > - If the IETF returns Proposed Standard to its documented purpose
> > > > ("this specification is stable, and will not change gratuitously,
> > but
> > > > may change in the future for good reasons"), and publishes
> > protocols
> > > > like M2UA as Proposed Standards earlier in the process, this would
> > > > also be more attractive for test equipment vendors.
> > > >
> > > > Followups on this point are probably on-topic for newtrk and
> > off-topic
> > > > for sigtran, though.
> > > >
> > > > Spencer
> > > >
> > > > ----- Original Message ----- 
> > > > From: "FCG Jiang Hui" <[email-masked]>
> > > > To: <[email-masked]>
> > > > Sent: Monday, May 10, 2004 12:54 AM
> > > > Subject: [Sigtran] ×ª·¢: [Sigtran] Is M2UA less relevant?
> > > >
> > > > * The test facilities for M2UA are very little. For example INET
> > and
> > > > HAMMER co. don't support M2UA by now.
> > 
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > ______________________________________________________________________
> >   This email message has been scanned by PineApp Mail-Secure and has
been
> > found clean.
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> ______________________________________________________________________
>   This email message has been scanned by PineApp Mail-Secure and has been
> found clean.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has been
found clean.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 May 2004 14:07:24 -0600

Martin,

MTP-2 spec does not allow suppression of proving.  I suppose that in the NA
state, Ready is expected when proving is skipped.  I belive that the MTP-2
SDLs show having to accept at least one SIN or SIE before a FISU/MSU will be
accepted.  The possibility of suppression of proving would drop the need for
this SIN or SIE before FISU/MSU accepted (and I think obviate a timer?).  But
I believe the resulting receive state machine would work with both proving and
non-proving senders.

Indeed, skipping proving was intended for MTP3b, where it is a management
option whether to prove or not.  Unfortunately it is communicated end-to-end 
using SSCOP out of band management unitdata, of which M2PA has none.
Nevertheless, an MTP3b state machine should just as easily accept either case
on the receive side.

I did not include a test case for this, for obvious reasons.

--brian

Hecht Martin wrote:                                                                  (Wed, 12 May 2004 15:40:19)

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

---

From: Mike Shimony <[email-masked]>
Date: Fri, 14 May 2004 12:00:20 -0400

Hi,

I found a few mentions in the archive about the M2UA implementors guide, 
but nothing about when it may be available.  Is there an M2UA 
implementors guide in the works and if there is when might it be 
available?  Thanks.

Mike

-- 
Michael Shimony
Senior Software Engineer
Ulticom, Inc., 1020 Briggs Rd., Mt. Laurel, NJ 08054
856-787-2747

---

From: "Barry Nagelberg" <[email-masked]>
Date: Fri, 14 May 2004 12:37:40 -0400

Mike,

I was asked by Ken Morneault, on Dec. 3, 2003, to start compiling an M2UA
IG. The next day I sent out an email to the list asking for input. I haven't
received any replies :<(

Barry Nagelberg
Adax, Inc.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mike Shimony
> Sent: Friday, May 14, 2004 12:00 PM
> To: SIGTRAN Mailing List
> Subject: [Sigtran] Re: [Sigtran] Re: [Sigtran] RE: [Sigtran] Re:
> [Sigtran] Re: [Sigtran] ×ª·¢: [Sigtran] Is M2UA less relevant?
>
>
> Hi,
>