Subject: RE: [Sigtran] informal meeting notes

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 4 Dec 2002 15:41:14 -0800

Hi Folks,

Having received no comments on the notes, I need to raise
the issue of the GR303 UA document and ask if anyone has
a problem with making this a WG document, the authors have
requested this.

Thanks,

L. Ong

-----Original Message-----
From: Ong, Lyndon 
Sent: Wednesday, November 27, 2002 6:42 PM
To: [email-masked]'
Subject: [Sigtran] informal meeting notes

Hi Folks,

Hope all of the US list members are enjoying the Thanksgiving Holiday!

We did have an informal discussion at the Atlanta IETF meeting.  There were
approx.
a dozen people attending, and the following was discussed:

Everyone agreed that the first priority was completing the security
framework, to
remove the obstacle from finishing the other adaptation layers.  
NOTE: Our A-D heartily endorses this.

Beyond that, existing work includes completing the M2PA adaptation layer and
the Implementor's
Guides, plus any further MIBs.

A question came up as to the path forward on the Implementor's Guides.  My 
assumption is that these become supplementary RFCs to the associated 
adaptation layer RFC, unless it is felt that there is a need to rewrite the
original
RFC or we decide to reissue it when it goes from Proposed Standard to Draft
Standard.

It was generally agreed that it is desirable to get the IGs 
completed soon, if possible before the next meeting.  Again, 
however, the security work must be completed before these 
will be allowed to move forward in the IESG.

There was a proposal for a new adaptation layer, a variant of IUA for
GR303.  GR303 is a Telcordia specification that is used between remote
digital terminals and the central office in telephony networks.  The 
application would be if either the RDT or the central office becomes
IP-based and its counterpart is not.  There appeared to be support for
this, especially as the enhancements to IUA were very limited.

There was also discussion of a TUA (TCAP User Adaptation), as 3GPP II will
use
the high level applications (IS.41 and MAP) for mobility management but
will eliminate most of the SS7 functions.  This is kind of a gray area as
it becomes more and more IP and less and less SS7.  We need to
have further discussion on this and the level of interest.

Finally, there was a fair amount of interest in completing the definition of
how to use
M3UA between IPSPs or between SGs as this is an open area that we deferred
from
the original M3UA specification.

Generally I think all of the above can be accomplished within our
charter except possibly for the TUA, which is a fairly different adaptation
layer.  It's possible that this could be better done outside of the WG.
The proposed GR303 UA is also new, but looks like a pretty minor enhancement

to the existing IUA.  Scott, our A-D, generally concurs except with some
question on the nature of the IPSP-IPSP extensions required, and also
a reminder that security will need to be completed before anything else.

Cheers,

L. Ong

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Dec 2002 17:25:33 -0700

Lyndon,

Looking at draft-ranjith-sigtran-gr303ua-00.txt, it hardly looks
like it needs a separate UA.  Why cannot gr303 and v5ua be
collapsed into the same UA (as they are really just variants of
the same thing)?  Why does gr303ua take a different approach to
the header and reuse of existing Q.931 messages from that taken
by v5ua?  These two UAs need to be aligned anyway.

What is the direction here?  Are we to have a different UA for
everything conceived by the telecommunications industry to run
over LAPD?  How about BSSAP/DTAP for GSM (which runs over the
LAPD air command interace)?  Will we have a GSMUA too?

Do we really want to populate the message class with all these
many users of the LAPD interface?  Or should IUA really just be
a LAPD-UA that supports any of these users?  Does LAPD really
care what it is transporting?  Perhaps the mistake was making
reference to Q.921/Q.931 in the message class in the first
place.  Perhaps it should have just been a LAPD message class.
IUA should just transport LAPD user data and let the application
peers decide what is inside it (based on interface TEI and SAPI
as is normally done).

It strikes me that, aside from the name of the message class
(Q.921/Q.931) IUA has all that is required to support all of
these so-called UAs.  V5UA would like to invade the IUA header
with its own protocol discriminator, but there is no reason why
this protocol discriminator cannot be in the data payload
instead of in the IUA header.  LAPD does not concern itself with
V5 protocol discriminators.  The same is true for GR303.

It would be better to have all of these IUA extensions dropped
down to informational descriptions of how to use the IUA
protocol to support these non-Q.931 applications rather than
each one trying to bend what is basically LAPD to their whim.

So basically, no, I would not like to see GR303 as a WG item
until the scope and direction has been better defined.

--brian

Lyndon Ong wrote:                              (Wed, 04 Dec 2002 15:41:14)

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

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 4 Dec 2002 18:25:31 -0800 (PST)

Hi Lyndon,

Can I also make the same request for SG-SG draft
again?

   Tolga
> a reminder that security will need to be completed

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Ranjith Mukundan <[email-masked]>
Date: Thu, 05 Dec 2002 10:09:02 +0530

Brian,

v5 and gr303 are not 'variants of the samething'. gr303 layer 2 and TMC/CSC
part of gr303 layer3 can be thought of (but not exactly) as a subset of q.921
and q.931 respectively - the similarity stops there. the eoc portion of layer
3 is used for oamp and is a cmip based layer (but, of course the primitives
from lapd to eoc are the same as those between lapd and q.931.

v5 needs additional boundary primitves (pls refer to that draft) that is not
defined by gr303-core specs.

the sapi/tei combination that needs to be supported for gr303 is different
from those required by v5.

Except for their network fit, v5 & gr303 are fundamentally different
protocols.

Owing to this, at the AS the UA user is going to be (very) different for the
IUA extensions (v5ua, dua & gr303ua) and need to be differentiated at the
message class level (of course, there should also be a provision to differente
at the transport-layer/sctp based on the transport/sctp payload id as well). I
am not clear by what you mean by "take a different approach " - it'd be help
if you can cite specifics from the drafts. Beyond any doubt, one common
message class to handle v5, gr303, dpnss & dass2 and using the data payload to
differentiate between these exentension does not fundamentally reduce the
notion and the need for the different exetensions. Moreover, it's not that the
changes required by the extension UAs can be realized by 'invading' the IUA
header, there are other changes like the need to support additional SAPI/TEI
combinations, support of additional boundary primitives, need to explicitly
spell out and recommend the use of different SCTP stream IDs for EOC and
TMC/CSC etc.

But, yes from the UA boundary primitive perspective, they can be modelled
around the IUA as the boundary primitives are **more or less** the sam. Also
it is important to realize that GR303, V5, DPNSS and DASS2  - **DOES NOT USE
LAPD** per se, though they are derived from Q.921 spec, they are different
layer 2 protocols. For example, V5 layer 2 has three logical components on the
network side - LAPV5-EF, LAPV5-DL & LAPV mapping function (apart from AN/FR on
the user side). So your assumption that we are just trying to 'bend basically
what is LAPD' is flawed. Though collapsing v5ua and gr303ua is obviously not
appropriate, a better option would be to include the procedures for the IUA
extensions ( V5UA, DUA & GR303UA) into IUA-bis (RFC3057bis) to support v5,
gr303, dpnss & dass2 - but I am sure if we can afford such overheads at this
point in time because this work will mandate more effort from the SIGTRAN WG
perspective vis-a-vis following up these extensions independently.

Another important driver whilst deciding which UAs are required is
(business/industry) need based - not merely "whims" of the authors. BSSAP/DTAP
in 2.5G and 3G are basically MTP users - M3UA serves exactly that purpose to
backhaul that info. Prior to 2.5G - were BSSAP/DTAP is used over LAPD, a
deployment scenario to interface with a packet network is not envisaged and
may not have the business/industry need - if it does, we encourage you to
bring it to the table with good factual argument. The driver for developing
the IUA extensions has definitely not been a process of hunting around for all
DSS1, DSS2 derived protocols and make UAs for it - if that were the case, we
would perhaps have had 15+ extensions to IUA (including those that run over
X.2x based layer 2).

Also, as a point to note, am not sure if you'd be aware of some discussions
that took place when this WG started, where a common UA model was discussed (a
generic UA - one for ISDN & one for SS7), to have a generic UA and then define
variants around it (or something to that effect). This was concluded to be a
not-so-viable option.

Given the above, IMO, the way forward would be:

1- evolve a RFC3057bis to support gr303, v5, dpnss & dass2 OR
2- have them as separate IUA extensions.

I see 2 as the better way forward.

Cheers,
ranjith..

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Dec 2002 21:58:14 -0700

Ranjith,

You say they are different but they use the same primitives to LAPD.  So how
are they different then?  In the payload?  What does IUA care about the
payload?

What is the point of discriminating between Q.931 and V5 or GR303 messages
between two peers unless one expects them on the same association?  Why would
one mix these on the same association anyway?

Also, you say that V5 needs extra primitives to LAPD, but does DPNSS, DASS2,
GR303 or GSM air interface?  So, we have IUA and V5UA, is that any reason to
go forward with a bunch of other UAs that could simply reuse the IUA spec?
It certainly doesn't seem justified for GR303.

The GR303 draft only distinguishes from IUA at the message class.  So why does
it not just use RFC 3507?  Assign a new well-known port number for GR303 vs.
Q.921 if you really see a need to support multiple protocols between two hosts
and the hosts are incapable of otherwise distinguishing between the two
protocols.  But there appears no need for a different PPI or message class.

--brian

Ranjith Mukundan wrote:                        (Thu, 05 Dec 2002 10:09:02)

> **************************Disclaimer**************************************************    
>  
>  Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' 
> and 'confidential' and intended for use only by the individual or entity to which it is 
> addressed. You are notified that any use, copying or dissemination of the information 
> contained in the E-MAIL in any manner whatsoever is strictly prohibited.
> 
> ****************************************************************************************
> 
> 
>

---

From: Ranjith Mukundan <[email-masked]>
Date: Thu, 05 Dec 2002 12:10:36 +0530

Brian,

The primitives (DL-x) are the same, but some of the peer to peer layer 2 procedures are
different from LAPD (some timeouts etc) - of course, IUA should not be concerned about these
changes. The IUA-user being different, gives rise to a definite  need to diffentiate the
primitives using at least 2 additional message-class equivalent, in case of gr303 (one for
tmc/csc and one for eoc - as the two are othrogonal components of gr303 layer 3, one for call
processing and the other for oamp including path protection switching)- IF this were to be the
only difference, and assuming I get two well known ports assigned for gr303 (one for tmc/csc
and one for eoc), & despite the wierdness that it brings along from the implementation
perspective of gr303 layer 3, then, as you suggest, 2 different well known ports for GR303UA
alone would have sufficed - and get it documented appropriately somewhere in a IUA related
I-D.

However, that is not the case. The 2nd difference (non-payload) is the supported range of
SAPI/TEI (DLCI) values in GR303 - you might argue that this change is insignificant, but I
strongly endorse this explicit mention of the 'SHOULD' be supported range/values of SAPI/TEI
in GR303UA as it helps validate and handle error conditions certainly better.

The 3rd implicit difference is the 'recommended' need to map the 4 interface identifiers
(tmc/csc & eoc - backup & primary) to different SCTP stream IDs.

The fourth difference - a provision to differentiate this at the transport/sctp layer (using
the payload ID) too is essential owing to the two fundamentally different deployment scenaros
of IUA and GR303UA; GR303UA can be deployed between an IP-based CPE/IAD (RDT in gr303
parlance) and a Voice Gateway (SG) over packet network (refer scenario 2 in the draft) instead
of say, BLES (atm forum vmoa-0145) over ATM AAL2. Hence, the transport devices routing the IUA
messages and GR303UA messages might want to do something different  (iam not sure of what that
might be, at this point in time) based on the payload ID is a strong option/flexibility that
needs to present as, at the transport-control plane, the packet network between an SG and MGC
can mandate a different need from a packet network between a IP-based CPE and a VG. Now that
you brought this issue up, I think it would be a good idea to include pieces of this
justification in the next version of the draft.

The fifth difference, that is still not included in the I-D, is a possible need to introduce
one or more mgmt/status primitives  ( i ceratinly dont foresee more than 2 or 3) management
primitives to perform the layer 2 link management & status update*better*. Though, the
gr303-core does not explicilty define any primitives to this end for the traditional
deployement scenarios (where l2 and l3 was expected to be co-located), we see that there might
be a need to do this for packet network deployment and that this need is different from IUA
because, unlike in the case of IUA, GR303 layer 2, at a typical minimum would have 8 logical
links (8 DLCIs) active. But, this is something that we want to disscuss on the list and before
inclusion in the draft. In retrospect, I feel a clause should have been included in the
submitted draft to cite this potential need.

As for mixing q.931 and gr303ua on the same sctp association goes, as you have discerned, i
don't think one migh want to do this (though it can be done). But it is a reasonable option to
have mechanism to deal with this scenario.

Yes, DPNSS, DASS2 needs additional primitives (pls refer to the dua draft (.04) that is
already a WG id). As for GSM air interface, I am not too sure, I think need to take a look at
GSM8.56 & LAPDm related stuff. For GR303, see above.

Cheers,
ranjith..

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 00:50:56 -0700

Ranjith,

Ranjith Mukundan wrote:                                                            (Thu, 05 Dec 2002 12:10:36)
> in GR303UA as it helps validate and handle error conditions certainly better.

The range of SAPI/TEI values can be handled by IANA without need of an RFC.

> (tmc/csc & eoc - backup & primary) to different SCTP stream IDs.

Does not IUA already provide for mapping of interface identifiers to streams?
I though that was clearly diagrammed in RFC 2057...

> justification in the next version of the draft.

I don't see a need to run these over the same SCTP association, so I don't see
a need for a discriminator.
> submitted draft to cite this potential need.

Sounds like configuration management which is outside the scope of a UA.  That
is for the MIB and SNMP to deal with.

> have mechanism to deal with this scenario.

It is not reasonable when it should never occur and the easiest way around it
is to open one association for each instead of trying to run both over the
same association, which gains nothing.

> GSM8.56 & LAPDm related stuff. For GR303, see above.

The DLC status message could be handled by extending the existing IUA message
class instead of defining a new message class.

--brian

Please remove your disclaimer for IETF mailing lists as it is contrary to the
policy of the IETF.

---

From: Ranjith Mukundan <[email-masked]>
Date: Thu, 05 Dec 2002 14:56:13 +0530

brian,

in-line...
[ranjith]

> The range of SAPI/TEI values can be handled by IANA without need of an RFC.

[ranjith]
The valid values are local to gr303-core and already specified in the spec. gr303ua extension enforces carriage of
this valid range and hence these value does not mandate allocation by centralized authority like IANA. keeping
this non-extensible range outside the scope of gr303ua specification & within the purview of IANA will not be
conformant to the guidelines RFC 2434 (guidelines for writing an IANA considerations.....)

> I though that was clearly diagrammed in RFC 2057...

[ranjith]
3057 recommends mapping of an ISDN D channel to a stream ID. But this recommendation is not implicitly extensible
to gr303 eoc, gr303 csc and gr303 tmc (primary and secondary)

> a need for a discriminator.

[ranjith]
You cannot use the association ID to dertermine a transport-plane control behaviour of 'gr303ua-aware' transport
layer functional entities, in the network. A given sctp association ID will/can be reused to backhaul different
things at different points in time and it's uniqueness is not guranteed for gr303ua alone. Also, it's not mandated
that gr303ua SG/RDT/IAD always backhauls gr303 on a given association. I can just decide to shut-down and restart
the association to do something else like IUA at another point in time.

> is for the MIB and SNMP to deal with.

[ranjith]
No!...it's not some configuration/audit/provisioning info that any snmp manager would be interested. this is some
link process  specific mgmt info that would determine the behaviour of the layer 2-user. Also, as an example, RFC
2127 (ISDN MIB) and http://www.alternic.org/drafts/drafts-r-s/draft-ranjith-dpnss-mib-00.html (DPNSS MIB) is a
good reference for what the oamp parameters for ISDN like protocols look like.

> same association, which gains nothing.

[ranjith]
I am not aware/ can't think of a practical advantage either. But let us not rule that out altogether. If I am not
get into a not-so-relevant pedantic argument, I might want to argue that multiplexing on the same association
saves on some kernel resources vis-a-vis opening multiple association for each.

> class instead of defining a new message class.

[ranjith]
RFC3057bis could be one way out to re-look at the way in which we should define IUA extensions - personally, am
not inclined to go down that road. So it'd be good hear what others think about the re-looking at the way
extensions are defined.

> Please remove your disclaimer for IETF mailing lists as it is contrary to the

[ranjith]
Apologies. This is set by the mail-admin as a policy. I understand that it's not in line with the policy (but pls
bear with me). Rest assured, I'll talk to the admin/mgmt folks out here and prevent it from repeating - in a day
or two.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 03:04:53 -0700

Ranjith,

Ranjith Mukundan wrote:                          (Thu, 05 Dec 2002 14:56:13)
> 
>    [ranjith]
>    The  valid values are local to gr303-core and already specified in the
>    spec.  gr303ua  extension  enforces  carriage  of this valid range and
>    hence these value does not mandate allocation by centralized authority
>    like  IANA.  keeping  this  non-extensible  range outside the scope of
>    gr303ua  specification  &  within  the  purview  of  IANA  will not be

As they are SAPI/TEI codepoints to the DLCI field in IUA, they are smack
dab in the purvue of IANA.

>    [ranjith]
>    3057  recommends mapping of an ISDN D channel to a stream ID. But this
>    recommendation  is  not  implicitly extensible to gr303 eoc, gr303 csc
>    and gr303 tmc (primary and secondary)

NI-2 and NI-3 PRI also provides for primary and secondary interfaces.  Are you
saying that IUA cannot support NI-2?

>    [ranjith]
>    You  cannot  use  the  association  ID to dertermine a transport-plane
>    control   behaviour  of  'gr303ua-aware'  transport  layer  functional
>    entities,  in  the  network.  A  given sctp association ID will/can be
>    reused  to  backhaul  different things at different points in time and
>    it's  uniqueness  is  not  guranteed for gr303ua alone.

Uh, it is with an assigned port number...

>    Also, it's not mandated  that  gr303ua  SG/RDT/IAD  always backhauls
>    gr303 on a given association.   I   can  just  decide  to  shut-down  and
>    restart  the association to do something else like IUA at another point
>    in time.

Uh, not on an port number assigned to GR303...

>    [ranjith]
>    No!...it's  not  some  configuration/audit/provisioning  info that any
>    snmp  manager would be interested. this is some link process  specific
>    mgmt  info  that  would  determine  the behaviour of the layer 2-user.
>    Also, as an example, RFC 2127 (ISDN MIB) and
>    [1]http://www.alternic.org/drafts/drafts-r-s/draft-ranjith-dpnss-mib-0
>    0.html  (DPNSS  MIB)  is a good reference for what the oamp parameters
>    for ISDN like protocols look like.

What is it then?

>    [ranjith]
>    I  am  not aware/ can't think of a practical advantage either. But let
>    us   not   rule   that  out  altogether.  If  I  am  not  get  into  a
>    not-so-relevant   pedantic  argument,  I  might  want  to  argue  that
>    multiplexing  on  the  same association saves on some kernel resources
>    vis-a-vis opening multiple association for each.

The same argument would have telnet and ftp running on the same TCP
connection.

>    [ranjith]
>    RFC3057bis  could  be  one  way  out to re-look at the way in which we
>    should  define IUA extensions - personally, am not inclined to go down
>    that road. So it'd be good hear what others think about the re-looking
>    at the way extensions are defined.

You don't need a 'bis', just an extension.  But why not have one extension
RFC instead of 4 or 5?

--brian

---

From: Ranjith Mukundan <[email-masked]>
Date: Thu, 05 Dec 2002 16:27:14 +0530

Brian,

[ranjith]

OK. From the point of view of a generic DLCI field in the IUA and making those
assignments thru the IANA is a fair agrument. But we need to anyways define the
assignement policy somewhere (like what the valid values/ranges are for each IUA
extension) as IANA just assigns certain values based on specified guidelines. So I
dont see how it would matter if these guidelines are part of one RFC or in RFCs
that define these extensions.

> saying that IUA cannot support NI-2?

Yes in NFAS mode in PRI does support primary & back-up - and I wasn't impling that
it does not. What I meant was that there is no direct equivalent of tmc, csc and
eoc. There is some parlance of pri to CSC and to a lesser extent to tmc, but
definitely not to EOC. So what is implied for PRI d channel cannot be assumed to
be extensible to CSC, TMC and EOC.

> Uh, it is with an assigned port number...

[ranjith]
I missed the point that this had to do with with your earlier argument that we
could have different WNP for gr303. But as I said this would imply 3 WNPs for
gr303 (for differentiating tmc, csc and eoc layer 3 PDUs). Also, you are removing
any flexibililty of multiplexing the iua extensions over the same assosication.

> Uh, not on an port number assigned to GR303...

[ranjith]
Yes. OK. Pls refer previous comment.

> >    for ISDN like protocols look like.

[ranjith]
Good question. One example is to reset (as a result of a maintenance action) all
the 8 (or more)  links in one go, or a subset of the 8 links in one-go (with a
parameter to differentiate the latter operation from the former with in the same
primitive-type) AND to send the result of this execution back to ASP instance.
Indication of this result should again have the granularity (via some parameter in
the same primitive-type) to indicate the result of this execution
(success/failure) on a per link basis.

[ranjith]

The signaling applications like UAs (and of the entities running these
applications like SGs/MGCs) places a different requirement  on the transport layer
(sctp) vis-a-vis  from the requirement telnet /ftp (and the entities running these
like desktops) places on TCP  - precisely the point why we have come a long way
from the MDTP/TCP days to the current SCTP.

[ranjith]

That's fine by me. If all that we have discussed can be put in one document
spanning across v5, dpnss/dass2, & gr303 that should be fine. Exetensions have
been clubbed into one doc on other WGs - but the extensions in those cases have
had a higher degree of correlation than in the UA case.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 05:03:22 -0700

Ranjith,

Ranjith Mukundan wrote:                                                            (Thu, 05 Dec 2002 16:27:14)
> (success/failure) on a per link basis.

Can this not be accomplished with existing per-link reset? (Establish Req/Ind)
With the interface responsible for aggregating responses rather than the
protocol?

> from the MDTP/TCP days to the current SCTP.

Telnet and ftp also run on SCTP, but with WNP rather than PPI (all TCP WNP are
SCTP WNP).  So, wouldn't the same argument require a PPI for telnet and a PPI
for ftp (rather than just WNP as it is today)?.

> had a higher degree of correlation than in the UA case.

The high degree of correlation here is RFC 3057 itself.  None of these define
a new protocol, but make relatively minor modfications to RFC 3057.  One
document would mean that these little extensions at least exploit the
commonalities that they do have.  Existing drafts appear divergent where
commonalities exist making it a nightmare to update all the little extension
drafts if RFC 3057 should ever be upgraded (IG) or replaced.

--brian

---

From: Ranjith Mukundan <[email-masked]>
Date: Thu, 05 Dec 2002 18:21:14 +0530

Brian,

> With the interface responsible for aggregating responses rather than the

[ranjith]
Interface aggregating it is not as good an option (performance wise) as getting to do it in one-go and performing
actions (& rcving corresponding responses) via a single request/response/indication. I would not want to built
gr303ua specific intelligence outside the protocol at the cost of affecting interoperability. The primary driver
in case of IUA to have per link based resets is the fact that a typical minimal q.931 (pra) configuration would
just have on logical link process (or two in case of NFAS). Even in the case of DPNSS/DASS2 the layer 2 modelling
is slightly different - where each layer 3 session has an equivalent layer 2 link process (64 in case of DPNSS and
32 in case of DASS2). Though in gr303 we dont have a link process/logical channel for every layer 3 session, the
number of typical minimum link layer sessions is high enough to consider this 'group reset' option. I am 99%
convinced that we need it - for the remaining 1%,  I would like to put forth some use-cases and elicit response on
the list. And also pls note that, this is one of the 3-4 mtc/mgmt scenarios that I ve in mind currently.

> for ftp (rather than just WNP as it is today)?.

[ranjith]
Yes, if there is a need to multiplex telnet and ftp over the same tcp connection, then a ppi would be required -
but thats an hypothetical requriement as there is not practical requirement for it.

In case of signaling apps, the need to multiplex is far more practical than in the case of ftp or telnet. The
resources on a SG are far more at a premium to mandate multiplexing over the same sctp association, then with say
a PC running telnet or ftp over sctp.

> drafts if RFC 3057 should ever be upgraded (IG) or replaced.

Agreed.
But at this point, I dont want to single out gr303ua and keep it outside the purview of the sigtran wg - as I feel
it would do us more harm than good to get some quality focus on this rather useful UA - as it does have a strong
case for deployment. We have demo setup running for gr303ua. I shall include the gist of what was discussed here
and the additional management primitives info in .01 of the draft in the appropriate sections.

Hence I request that we make it a WG ID, discuss it over, and if we have consensus on merging into one extention
IUA - then be it, we'll go that way.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 06:17:49 -0700

Ranjith,

Ranjith Mukundan wrote:                                                          (Thu, 05 Dec 2002 18:21:14)
> Yes, if there is a need to multiplex telnet and ftp over the same tcp
> connection, then a ppi would be required - but thats an hypothetical
> requriement as there is not practical requirement for it.

Just as there is no practical requirement for Q.931 and GR303 on the same
association.

> 
> In case of signaling apps, the need to multiplex is far more practical than
> in the case of ftp or telnet. The resources on a SG are far more at a
> premium to mandate multiplexing over the same sctp association, then with
> say a PC running telnet or ftp over sctp.

I wouldn't say that it takes more resources for two SCTP associations, each
with one protocol, than it does for one association with two protocols
multiplexed.  Either SCTP maintains the differences or the ULP does.  Having
SCTP separate the two (in two associations) might even require less system
resources than one association (because the ULP has less efficient
structures and mechanisms visa vi memory management, caching, locking,
scheduling, queueing, IPC, ...).  So I surely don't see where any significant
gains can be obtained from multiplexing.

> But at this point, I dont want to single out gr303ua and keep it outside the
> purview of the sigtran wg - as I feel it would do us more harm than good to
> get some quality focus on this rather useful UA - as it does have a strong
> case for deployment. We have demo setup running for gr303ua. I shall include
> the gist of what was discussed here and the additional management primitives
> info in .01 of the draft in the appropriate sections.
> 
> Hence I request that we make it a WG ID, discuss it over, and if we have
> consensus on merging into one extention IUA - then be it, we'll go that way.
> 

I disagree with making it a WG item at this point in time because it is of the
nature of an extension draft.  (And one which does not appear to use the
existing RFC to the maximum extent possible.)

Far more pressing work (security, advancing M2PA, addressing deferred outstanding
issues in M3UA and SUA, particularly with regards to IP SP operation) deserves
IMO the focus of the working group in preference to an extension which is
currently outside the scope of the charter.

Also, I question the value of carrying such an access specific link layer protocol
over IP when other, more complete, access protocols exist: i.e. H.323, SIP,
even MEGACO with a GR303 package.

Others may have other opinions.

--brian

---

From: Ranjith Mukundan <[email-masked]>
Date: Thu, 05 Dec 2002 19:16:12 +0530

Brian,

> gains can be obtained from multiplexing.

[ranjith]
The resources in the kernel space is usually far more at a premium than the resources in the user space. Hence
multiple associations (for e.g., one each for iua, v5ua, dua and gr303ua) taxes the kernel more than it would
when running it over just one association. I am assuming SCTP running in the kernel space.

> existing RFC to the maximum extent possible.

> currently outside the scope of the charter.

[ranjith]
I completely disagree. It mandates inclusion in the scope of the charter!! v5ua, dua are all part of the
charter. Also, backhauling of ISDN based protocols over SCTP is as important as MxUA/PA etc. But yes security
should get a  higher priority than the rest. Those present in the informal meeting felt the same. So we would
like to hear from rest as well.

We don't want to see a iua-extension pardigm shift wrt GR303UA - and review it in a totally different light from
say V5UA or DUA - that's the only reasoning I can see in your observation that  "the existing RFC to the maximum
extent possible" is not being used.

> even MEGACO with a GR303 package.

[ranjith]
I dont see/understand the relevance of your observation. But gr303ua/sigtran alone would not suffice to support
gr303 over a packet network. MEGACO is requried to do the inband part. RTP NE (as part of RFC 2833bis) is
required to cater to IP based RDTs/IADs. These are cited in the draft as also in the presentation that was
circulated in the list. We working on the corresponding WGs for these.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 07:08:28 -0700

Ranjith,

Why was not GR-303 included in V5UA?  (See attached.)

Ranjith Mukundan wrote:                                                          (Thu, 05 Dec 2002 19:16:12)
> 
> We don't want to see a iua-extension pardigm shift wrt GR303UA - and review
> it in a totally different light from say V5UA or DUA - that's the only
> reasoning I can see in your observation that  "the existing RFC to the
> maximum extent possible" is not being used.
> 

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

Subject: Re: [Sigtran] Backhauling GR-303 signaling messages
From: Ken Morneault <[email-masked]>
To: Al Varney <[email-masked]>, [email-masked]
Date: Wed, 15 May 2002 08:11:03 -0400
List-Id: Signaling Transport <sigtran.ietf.org>

Al,

Thanks for your useful advice.  We'll definitely take it into consideration
when we finish the GR303 draft.

Regards,

Ken

At 12:26 PM 5/14/2002 -0500, Al Varney wrote:
>At 07:43 PM 5/14/02 +0530, Ranjith Mukundan wrote:
>>Ken and myself were in the process working on GR303UA extension to IUA for backhauling the
>>EOC and TMC/CSC messages from the SG to AS - I'll chk with Ken as to when this can be
>>submitted and revert to you.
>>
>>As for the inband part there are Megaco packages (like the advanced anlog lines package)
>>for transporting these events and signals (for LS, GS, LRB equivalent) - though I am not
>>convinced that these would suffice (so dont be surprised if you see a megaco-gr303 package)
>>soon.
>
>Ranjith & Ken,
>
>   Would it be more useful to extend/modify V5UA for GR303UA, rather than grafting it onto IUA?  While 303 message encoding is based on Q.931-style ISDN, the signals, events, maintenance aspects and explicit control of in-band connections might be a better fit with V5UA.
>
>   Also, unless you can find a switch that's actually implemented CSC messaging, you might want to reduce the effort by just marking CSC "for future study".  I believe CSC is considered incomplete even in the official GR-303-CORE requirements.  Leaving out CSC would also reduce much of the confusion introduced by mixing the TMC and CSC call models in a single IETF draft and standard.
>
>Al Varney
>
>
>

---

From: Ken Morneault <[email-masked]>
Date: Thu, 05 Dec 2002 09:32:40 -0500

From my point of view, we forgot Al's advice as we worked on the GR303UA
draft sporadically over many months in our spare time.  It is still good advice and I
don't have a problem working with the V5UA authors to combine the
two drafts.

Regards,

Ken

At 07:08 AM 12/5/2002 -0700, Brian F. G. Bidulock wrote:
>Return-Path: <[email-masked]>
>Received: from localhost (IDENT:brian@localhost [127.0.0.1])
>        by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id HAA05017
>        for <brian@localhost>; Wed, 15 May 2002 07:35:09 -0500
>Received: from mail.dallas.net
>        by localhost with POP3 (fetchmail-5.3.1)
>        for brian@localhost (single-drop); Wed, 15 May 2002 07:35:09 -0500 (CDT)
>Received: from optimus.ietf.org (ietf.org [132.151.1.19])
>        by dallas.net (8.12.2/8.12.2) with ESMTP id g4FCYDbB010665
>        for <[email-masked]>; Wed, 15 May 2002 07:34:13 -0500 (CDT)
>Received: from optimus.ietf.org (localhost [127.0.0.1])
>        by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09748;
>        Wed, 15 May 2002 08:30:05 -0400 (EDT)
>Received: from ietf.org (odin [132.151.1.176])
>        by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09704
>        for <[email-masked]>; Wed, 15 May 2002 08:29:57 -0400 (EDT)
>Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
>        by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29491
>        for <[email-masked]>; Wed, 15 May 2002 08:29:43 -0400 (EDT)
>Received: from cia.cisco.com (localhost [127.0.0.1])
>        by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4FCTox7009735;
>        Wed, 15 May 2002 08:29:51 -0400 (EDT)
>Received: from kmorneau-w2k.cisco.com (rtp-vpn1-465.cisco.com [10.82.225.209])
>        by cia.cisco.com (Mirapoint)
>        with ESMTP id AAV95992;
>        Wed, 15 May 2002 08:24:22 -0400 (EDT)
>Message-Id: <[email-masked]>
>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>In-Reply-To: <[email-masked].
> net>
>References: <[email-masked]>
> <[email-masked]>
> <[email-masked]>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Sender: [email-masked]
>Errors-To: [email-masked]
>X-Mailman-Version: 1.0
>Precedence: bulk
>X-BeenThere: [email-masked]
>X-Loop: [email-masked]
>X-Mozilla-Status: 0000
>X-Mozilla-Status2: 00000000
>
>
>
>Al,
>

---

From: Ranjith Mukundan <[email-masked]>
Date: Thu, 05 Dec 2002 20:10:36 +0530

Brian,

We missed that, as an oversight. If it is strongly felt that this should be combined with v5ua, we could coordinate with the v5ua author and submit an DLCua (or the kind).

Lyndon, pls suggest the way forward.

Thanks,
ranjith..

"Brian F. G. Bidulock" wrote:

>   ------------------------------------------------------------------------
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 08:03:29 -0700

Ken,

It might be a good idea, particularly as the gr303 draft has rather
blatant errors in it:  It describes the GR303 message header as the
same as the IUA header, but shows it as:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Tag (0x1)           |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Interface Identifier                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            DLCI               |              Spare            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 3 IUA Message Header

which is obviously incorrect as the IUA message header is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x1)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Interface Identifier (integer)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x5)           |             Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DLCI               |              Spare            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4 IUA Message Header (Integer-based Interface Identifier)

V5UA draft does not make this error.

--brian

Ken Morneault wrote:                                    (Thu, 05 Dec 2002 09:32:40)