Subject: [IPTEL] draft meeting minutes

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 16:19:26 -0500

Folks,

Enclosed are the first draft of meeting minutes for the iptel group at 
IETF 52. Please let me know if there are any corrections or omissions. 
Thanks to Mary Barnes for taking notes.

-Jonathan R.

Minutes of the IPTEL WG meeting
IETF 52
December 2001
Salt Lake City, UT

Minutes taken by: Mary Barnes
Minutes prepared by: Jonathan Rosenberg

The IP Telephony (iptel) working group met for a single one-hour
session at IETF 52.

Agenda Bashing
--------------

First up was agenda bashing. The proposed agenda was:

Agenda Bash   [Rosenberg]              2m
CPL/TRIP Updates [Rosenberg]           5m
TRIP MIB [Walker]                      10m

Gateway Registration
    Scenarios: Internet2 [Schulzrinne]  5m
    Scenarios: Carrier [Peterson]       5m

    Requirements [Rosenberg]            20m

    Attributes [Bangalore]              10m

The agenda was agreed to.

CPL and TRIP Status (Rosenberg)
-------------------------------

Jonathan presented the status of CPL. -05 has been issued, finally
resolving the year-plus-long dispute with calsch on the level of
compliance to rfc2445. Finally, the agreement was to be fully
compliant. Performance and security issues were resolvable by doing
off-line expansion of recurrence rules. Other changes include the
addition of a language-switch and minor fixes. A new WGLC was issued,
ending 12/21/01. People were requested to send comments to the list
asap.

TRIP -09 approved as an RFC 9/13/01. Its getting close to top of
editors queue, maybe 3-4 weeks.

TRIP MIB Open Issues (Walker)
-----------------------------

Lots of comments on -00 (draft-ietf-iptel-trip-mib-00.txt). Most
related to SNMP types of things. There were a few open issues. The
main one was that one can't easily differentiate TRIBs (Adj-TRIB-IN,
Ext-TRIB,  Adj-TRIB-Out) in the MIB. Proposed solutions:
extrapolation, separate tables, bitfield (set).

* Extrapolation - this demands a lot of network manager
* Separate tables - TRIBs can appear in multiple tables
* Bitfield - seems preferable - appears as an extension of existing
mechanism which is a boolean

During the discussion, using a pointer was suggested.  The response
was that the editors understanding was that pointers don't work well
with SNMP. Consensus: bit field is agreed solution (no objections).

Other open issues:

o TripPeerRemotePort (added to peer index table) - issue is configured
versus learned - multiple servers can share the same IP address.  Had
been proposed to add a new field RemoteField, however, this has issues
with port. Proposed solution: new object (tripPeerLearned) to indicate
which is configured vs learned dynamically in protocol.

o Use of TimeInterval (SNMPv2-TC, hundredths of sec) for timers - MIB
uses Integer32 seconds.  Proposal to use text rather than integer for
this field. Proposed solution: seconds used by protocol, marginally
easier to configure.

o Oversights:
* Add tripRouteTypeTable to config table (similar to tripPeerRouteTypeTable)
* Add timestamp to route table, will also timestamp last change of peer 
state.

Conclusion: Will post above on mailing list and new draft will be
available soon.

Gateway Registration
---------------------

Precursor: Jonathan highlighted the issue of previous WGs that have
had multiple proposals for which there were lots of opinions.  This
ends up being time consuming as WG often has to backtrack.  A plea for
being open-minded and focus on progress. The approach we will take is
to first be sure we all are solving the same problem, since its not
clear we are. So, there will be presentations on scenarios that the
gateway registration is solving.

Scenarios: Internet2 (Schulzrinne)
++++++++++++++++++++++++++++++++++

Intradomain Gateway Discovery Requirements

Organizational assumptions:
Not a typical carrier setup
* Possibly "mutual aid"
* Loosely affiliated, with different administrators
o Different university campuses
o Different branches of enterprise

Example Diagram
* Magic in the middle to manage 2 networks

Jonathan asked whether the scenario was gateways as columbia, for
example, propagating their information to other university campuses so
that those gateways can be used as a communal resource? Henning
replied that this is yes, although it could be through an
intermediary, he is not proposing a mechanism in this slide.

Jonathan commented that it seemed like this was more like the old wide
area service discovery work that was done back when, and whilst its an
interesting problem [and indeed, part of Jonathan's PhD dissertation],
its not really the problem of this charter item, which is an element
in front of a farm of gateways managing the resources of those
gateways.

Henning continued with his presentation:

Dynamic configuration
* New gateways or gateway capacity changes
* For university

Policy changes
* New area codes
* Time of day, etc.

Coordination
* May have loose central administrator
* Avoid manual updates and configuration
* Reflect changes rapidly (minutes)

Status updates
* Want to have reasonably accurate picture
* But occasional failure+retry acceptable
* Charging not an issue

Additional considerations
* Multicast may be available
* Gateways are not competitors

Discussion: Is this what people had in mind for Gateway Registration 
Protocol?
Henning said that this may be a slightly different problem, thus perhaps a
different protocol may be applicable. Jonathan replied that this
doesn't seem to be intra-domain - it appears to be inter-domain. 
Columbia owns the policy.  From a carrier's perspective, the "Gateways 
are not competitors isn't applicable" and points to this being a 
different problem.  Thus, the requirements introduced by this scenario 
don't  seem to apply.

Henning replied that the requirements are looser, but that doesn't mean the
same protocol wouldn't apply.

Cullen Jennings asked whether this would be delivering availability
information. Henning responded yes.  Update frequency is a protocol
parameter that depends on the size of the network. A question was made
as to whether, in the model, you expect capacity updates to be sent to
all proxies out there?  If you expand connectivity, you don't want
this data to go to all servers.  Not scaleable. Henning replied that
you have the scalability problem regardless.  This solution (SLP)
might do better as it assumes multicast is available.

Another question was about the loosely maintained central admin point
- you need much more clear boundaries. Henning replied that it doesn't
matter where the information resides; it matters who controls the
information.  Separate administration from policy control.  The
gateway is the one with the ultimate decision.

Jonathan said that if you want the gateway to register with lots of
proxies, then you need multicast.  But, for a single service provider,
this is NOT a problem. Henning said that you can pick longer intervals
if there are lots of updates.  It's more of a protocol tuning issue as
to how many messages you can tolerate.  Unless protocol has a built in
restriction on message frequency.  Only really difference is per
message overhead (eg. TCP connection setup).  Not an issue. Jonathan
said that if you're concerned with lots of elements, then certainly
multicast is desireable. For a smaller amount of elements, TCP is
fine. Henning said that his proposal supports any mechanism. Jonathan
said that TRIP doesn't support UDP.  Thus, if you need lots of
updates, then you are adding an additional requirement. You've got to
limit scenarios and limit scope of solution.

Jonathan said that he doesn't think this is the problem that needs to
be solved.  This doesn't match the charter, although it is an
interesting problem.

Then, he posed the question to Group:  Is this a scenario that needs
to be taken into consideration? Dave Oran replied that this is an
interesting problem in the discovery domain and not in route
optimization.  Finding gateways is not a problem - among a set of
known gateways, which is the right one to use.  This is an example of
a service discovery problem.

Henning replied that there are some attributes independent of protocol
choice.

Conclusion: Agreement to hear the next scenario and then continue 
discussion.

Scenarios: Carrier (Peterson)
+++++++++++++++++++++++++++++

Jon Peterson put up a diagram of his Carrier architecture proposal
that was posted to IPTEL WG mailing list.

A type of architecture that he believes will exist (versus one he
believes is being deployed)

* Attributes:
1. Has a proxy server
2. Two types of resources - media gateway controllers and standalone
(dumb) gateways

* 2 points:
1. Large gateways that are dumb that have physical resources pointing
to elements in PSTN.
2. Gateways that terminate to VoIP.

Trunk groups are an important concept here, and represent the finest
degree of granularity for policy decisions. Trunk groups can span
physical gateways (typical carrier setup for reliability).

Comments on the model:

Brian Rosen: Mostly he likes.  It used to be that this was the
picture that everyone had in mind that were big carrier types.  Are
MGs fading away?  Always was the argument that you didn't want to put
so much into Gateways, thus the separation.  But, Moore's law makes
this less meaningful. So, perhaps the trend is to combine. Jon replied
that you still need signaling gateways to be separate, since you only
have a single point code.

Dave Oran said that he thinks that the MGC decomposition is
orthogonal.  When we talking about IPTEL GWs - MGC is the gateway.
Why does this decomposition impact the discussion? Dave also pointed
out that an element that's missing from the diagram - show prefixes
and trunk groups but don't show carriers.  Don't show TGs spanning
multiple MGCs.  Is that precluded?

Jon replied that his next slide deals with Dave's first point on why
the decomposition has an impact. As for the second point, in SS7, a
signaling switch is limited to a single point code.  Dave said that
everyone's gotten around that. There may be a case where TGs can't
span GWs, but this shouldn't be the model.  This is a low level point
that might lead people to the wrong conclusion.

Back to Jon's presentation. Why does the decomposition impact this?  It has
to do with attributes availability. An MGC advertises its GWs
availability, but smart GWs availability known directly.

o Route availability
  * Are all MGC routes for '+'? Why express preference?
  * Also other address families
o Trunk group availability
  * Trunks associated with physical interfaces
  * CSI states (blocked locally/remotely, idle, etc.)
  * Availability of routes predicted on trunk groups, but often not on
    a single GW

Jon said he really believes that trunk group availability vs. Gateway
availability is the true problem to solve.

Jonathan asked whether the group believes that this is the problem
that is being solved?

Discussion:

Dave Oran believes this is the problem.  Does have some concerns with
the attributes and hierarchy. Jon said he's just trying to describe
what needs to be done. Dave Oran responded that we need to work
through this.  He believes that this is the model - need to be able to
find routes to resources (described as a PSTN resource).

Jonathan added one caveat: believes that this is the problem we're
solving, but don't get consumed with large carrier model. We need to
worry about smaller gateways as well, were there are no trunk groups,
where the gateway itself, or routes, are the things to which
attributes are associated. However, we need to derive requirements
from this general problem.

Jonathan also pointed out that we're not solving SIP to H.323
problem.

Took a hum vote:  Is this the problem?
* Yes? Majority hum
* No?  No hums!

Further discussion:

Jon said that he believes this should always be about TGs - believes
should treat PRI as a trunk. Cullen asked whether there would ever be
more than one carrier on a single trunk? Jon said that there are a
number of carriers for virtually every trunk.  Due to EA. Dave Oran
responded that this has nothing to do with it, as the EA concept user
experience doesn't necessarily relate.  Take it to the list.

Jonathan stopped discussion at this point. Time had run out, and we
were not able to cover the last two agenda items:
* Requirements (Rosenberg)
* Attributes (Bangalore)

Conclusion/Actions:
* Agreement to use Jon Peterson's model as the basis for the problem
to be solved.
* Take further discussion of Jon's proposal to the list

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 31 Dec 2001 05:37:10 -0600

I wanted to speak a bit to the issue from the minutes below regarding the
ubiquitous availability of carriers through trunks in the PSTN, and the
relevance of the 'equal access' concept - especially since this a matter on
which Dave and I have differed for some time.

There are a number of ways (thanks to equal access provisions) that a user
can directly or indirectly select a carrier, for example:

- Having an entry in the LIDB for their address corresponding to the Carrier
Identification Code of their chosen carrier, so that inter-exchange calls
generated from their address always pick up this CIC (i.e. PIC LD).

- Using a dial-around (101+XXX+address) to override the default CIC for
their line.

- Dialing a freephone number whose SMS/800 dip returns a CIC code -
presumably once the call has been routed to the administrative domain of the
carrier, a further internal dip will be performed to translate the freephone
number into a geographic number.

Dave is certainly correct that a CIC does not necessarily correspond to some
physical network - that is, the concept of a 'carrier' chosen by a user is
largely a matter of who issues your bill, not what physical infrastructure
your call crosses. For example, there are resellers of long-distance service
whose CICs are really just aliases for the CIC of a major carrier. Large
carriers may own several CICs they use to target their services. It's
certainly not some kind of one-to-one mapping from CICs to physical
infrastructure.

HOWEVER, this doesn't mean that a decision isn't made, in some places in the
telephone network, about how a call is routed based on the CIC. In SS7, when
a CIC has been selected for a call, it is carried within the TNS or
(ANSIfied) CIC parameter of the Initial Address Message. The presence of
this parameter modifies how a call is routed through the telephone network,
especially at tandems.

So, to bring this matter back to trunk groups, one view might be that a
given trunk group may be considered to be a route to a CIC if, when an SS7
IAM message carrying this CIC is sent over the trunk group, this call will
(eventually) be routed to the administrative domain responsible for the CIC
(and presumably get delivered appropriately). One might contend, as an
opposing position, that only the carrier that owns the switch on the far
side of the trunk should be considered to be reachable through a trunk - but
I suspect that in an overflow situation most network would be content to
send calls for some other carrier through such a trunk group, even if it
introduced a middle-man network, complicating routing and potentially
settlement.

The correct position is probably somewhere in the middle. One or more CICs
may be 'preferred' for a particular trunk by some switch in the network,
largely because of who happens to own the equipment on the other side, but
in addition all CICs are usually 'available' through such trunks. Something
similar, I think, is true of E.164 numbers; certain ranges may be preferred
(due to settlement concerns) for particular trunk groups, but all number
ranges are usually available.

Finally, it's important to note that CICs are national in scope, and that
therefore trunk groups are most likely only routes to the set of CICs within
a particular nationality. There have been suggestions in the past that
identifiers for CICs in the gw reg mechanism should be concatenated with
some sort of country code to provide a scope of a CIC - I would agree that
this is probably necessary. Then we could refine our characterization of
trunk group CIC routes to one in which all carriers for a given nationality
could be 'available' through a trunk group.

Jon Peterson
NeuStar, Inc.