Subject: RE: [Sipping] SUMMARY: Trunk groups in R-URI

From: Michael Hammer <[email-masked]>
Date: Mon, 09 Sep 2002 16:09:37 -0400

Jon,

The problem with your point number two is that, to date, the discussion has 
suggested that the TG usage would occur ONLY within the domain of a single 
administration.

Mike

At 02:58 PM 9/5/2002 -0500, Peterson, Jon wrote:

>Notes (on format standardization) inline.
>
>Jon Peterson
>NeuStar, Inc.
>
> > -----Original Message-----
> > From: Vijay K. Gurbani [mailto:[email-masked]]
> > Sent: Thursday, September 05, 2002 8:00 AM
> > To: Peterson, Jon
> > Cc: SIPPING LIST; Cullen Jennings; Adam Roach
> > Subject: Re: [Sipping] SUMMARY: Trunk groups in R-URI
> >
> >
>[snip]
> > > in the absence of any actually standard practices
> > > for TG formats that we would like to represent in SIP (that might
> > > populate the IANA registry mentioned below), there probably isn't any
> > > reason to go forward with this work.
> >
> > I am afraid I disagree.  Without some standardized manner of carrying
> > trunk groups, a proxy from vendor A will not be able to inter-operate
> > with gateways from vendors B, C, and D.  Currently, each gateway has
> > its own manner of representing trunk groups -- some want them in the
> > user portion of a R-URI, others want them as URI parameters; some want
> > the name of the parameter to be 'tg', others want it to be
> > 'trunk_group' -- it is a mess.
> >
>
>Well, to be clear, I'm not saying that we need to invent some format for
>TGs, install it in the draft and insist that it be used - we shouldn't be
>kingmakers, and there are plenty of existing TG formats. First and foremost
>I think the draft needs to provide a way for trunk group formats to be
>standardized.
>
>Two points about your argument above:
>
>-  Just agreeing that 'tg' belongs in the tel URL of the Request-URI,
>instead of belonging in some header, isn't going to suddenly make proxy A's
>use of TGs interoperable with the use of TGs envisioned by gateway vendor B
>if they don't agree on what the TG means - that was the point I was trying
>to make. They would only interoperate if the trunk group identifier itself
>were just an opaque string with no semantics (so that a proxy consults a big
>table mapping disparate values like '0000001' and 'freds-trunk' to
>destinations when it makes routing decisions). However, there are also ways
>in which trunk group identifiers could be formatted in which the semantics
>of the identifier contribute to the routing decision. For example, there is
>at least one CLLI-based trunk identification format in use today, and CLLIs
>contain legible geographic information that could even be parsed by a proxy
>server and used to make a routing decision. If a proxy server just wants to
>know whether it should relay this message to a proxy on the east coast or
>the west coast, the geographic information could be used if the proxy
>understood the TG format, and it would not require the TG to have some huge
>table of mappings that treats every TG as a separate entry. So in other
>words, we should not make architectural decision at this stage that assume
>TGs must be opaque identifiers. And without understanding the format of the
>information in a trunk group identifier, it is still not clear to me that a
>given proxy vendor would be able to interoperate with a gateway made by some
>other vendor.
>
>- If trunk groups have totally opaque and non-standard identifiers (like,
>say, '23'), then there is a relatively high probability of collision between
>how TGs are identified by different providers. In the SIPPING WG, we
>generally do not assume that SIP signaling is ever restricted to some
>intradomain environment (like a 'Trust Domain'). SIP signaling part of the
>open Internet, and we should assume that message with a 'tg' value populated
>by one provider could wander into someone else's network. We should take
>steps to avoid any confusion that might arise because of this.
>
>At a minimum, I think there needs to be a way to describe the format that is
>being used for a trunk group identifier, and descriptions of the format need
>to be standardized. If we have TG identifiers along the lines of:
>
>tg=format-value
>
>then the 'format' description can be registered with IANA. That way we will
>minimize possible namespace collisions. It would be easy to understand that
>the following were diffferent TGs:
>
>tg=WCOMFMT-23
>tg=ATTFMT-23
>
>Now, the draft that defines the 'tg' parameter doesn't need to completely
>populate this IANA registry, but I think it should pre-provision that
>registry with at least one TG format value that is believed to be of value,
>if for no other reason than to provide an example of how TG formats should
>be registered.
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Al Varney <[email-masked]>
Date: Mon, 09 Sep 2002 16:53:33 -0500

At 04:09 PM 9/9/02 -0400, Michael Hammer wrote:
>Jon,
>
>The problem with your point number two is that, to date, the discussion 
>has suggested that the TG usage would occur ONLY within the domain of a 
>single administration.

>Mike

Mike,
   My prior "history" message on this topic probably failed to clarify 
that, in current circuit switched networks, TG numbers are almost 
exclusively used within a single administrative domain.  ITU-T and ANSI T1 
committees, nonetheless, have standardized parameters in ISUP, BICC and 
AIN/TCAP that carry those numbers -- even though they are unlikely to cross 
administrative domains.

   It would seem that the current effort to introduce "tg=" into SIP 
springs at least partially from the same reasoning that caused TGs to be 
added to the AIN protocol -- control of a switching point by a remote 
"routing control" node.  At least that's how the proxy-to-ISUP-gateway 
usage appears to me.

   I don't know if the standardization of intra-domain parameters is an 
issue for IETF.  If so, there must at least be some standardized means of 
extending protocols for such private parameters.  Maybe "tg=" falls in that 
category?

Al Varney

---

From: Michael Hammer <[email-masked]>
Date: Tue, 10 Sep 2002 11:26:41 -0400

Al,

Do you have an ITU reference on the naming convention for the BICC ITG 
parameter?

Second, and a subtle distinction, I took such a parameter to be a reference 
or alias for the real trunk group number used on any given switch.  Akin to 
how we number our highways in some areas.  US Route 50 may be Lee Jackson 
Highway in part of Virginia, turns into Arlington Blvd in another part of 
VA, maps to something else when running through the District of Columbia, 
and could be yet something else as it crosses Maryland.  De-referencing 
identifies the local street for each segment (hop).

It might be useful to disassociate this value from the TDM-oriented, 
hop-by-hop link-oriented trunk group identity and generalize it to a route 
identity that could have applicability even when used in gateways between 
pure IP-based voice domains.  I thought someone had mentioned this earlier.

Sidenote:  If one views call control protocols to be horizontal interfaces 
and media gateway control protocols to be vertical interfaces, I guess SIP 
really is a "trapezoid" if you want it to do both call control and device 
(trunk group) control.

Mike

At 04:53 PM 9/9/2002 -0500, Al Varney wrote:
> exclusively used within a single administrative domain.  ITU-T and ANSI 
> T1 committees, nonetheless, have standardized parameters in ISUP, BICC 
> and AIN/TCAP that carry those numbers -- even though they are unlikely to 
> cross administrative domains.
>
> extending protocols for such private parameters.  Maybe "tg=" falls in 
> that category?
>
>Al Varney
>