Subject: Re: GLP, number portability and wireless subscribers

From: "Greg Zhang" <[email-masked]>
Date: Tue, 9 Mar 1999 13:55:49 -0800

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: Greg Zhang <[email-masked]>
Cc: [email-masked] <[email-masked]>; John Schnizlein
<[email-masked]>; David R. Oran <[email-masked]>; Matt Squire
<[email-masked]>; Scott Petrack <[email-masked]>;
Alok Mittal <[email-masked]>; iptel
<[email-masked]>
Date: Tuesday, March 09, 1999 1:08 PM
Subject: Re: GLP, number portability and wireless subscribers

Jonathan Rosenberg wrote:
>Greg Zhang wrote:
>>
>> One approach is to introduce hierarchy among the GLP speaking Internet
>> telephony gateways. Instead of having a flat network of gateways, a
>> hierarchy is built among the gateways. In a way that is similar to PNNI,
>> the gateways becomes members of a peer group (PG). A peer group
>> leader (PGL) is elected in a group. PGLs in one level becomes peers
>> on the next level. And the process of PGL election process repeats
>> on the new level. The hierarchy building is finished when all gateways
>> are tied into one peer group at the highest global level.
>
>The use of a hierarchical arrangement of LS's seems orthogonal to the
>scope issue. We would still need to specify the encoding of scopes,
>interpretation of scopes, and be able to configure LS's about whether to
>propagate routes with particular scopes or not.

I agree with the spirit of the above statement. However, if the scope can
be expressed in simply the number of level or a list of peer group ids
that a advertisement gets to propagate and aggregated to, we would
not need to administrate, propagate and manage a separate sets of
scope code throughout the network. We can then have a simple solution
that serves our needs. Each gateway receives its nodal hierarchy
information from the peer group leaders in the hierarchy.

In a sense, the administration/configuration of peer group ids and the
hierarchy becomes the administration and interpretation of the scope
ids.

As I mentioned earlier, a gateway can be made to belong to more than
one peer group on one particular level with some of its advertisement
goes to one peer group while others goes to another peer group. The
peer group list that is contained in the original advertisement determines
where the advertisement gets sent to. The list can contain both vertical
and lateral peer groups in the hierarchy.

>In a sense,
>the current model contains a two-level hierachy. How does expanding this
>hierarchy make the problem easier? It seems to complicate the protocol,
>if anything.

Adding more levels to the hierarchy provides better scalability by limiting
the synchronization of distributed caches or databases to a smaller
scope with fewer members on each level. By having one protocol with
multiple levels instead of two protocols one for intra domain, one for
inter domain lets you avoid having to develop two separate pieces of
protocols and code. And it makes the administration and maintenance
of the gateways a little easier by only requires the network administrator
to deal with one protocol for configuration and debug.

Having said that, the implementation of the protocol can be gradual.
In the first release, one can choose to only support the lowest level with
future releases supporting more or all levels. This allows us to have
something that is reflexible, capable of dealing with topological changes,
and is scalable to a certain degree up and running relatively quickly. We
can also learn from the experience when adding the support for the full
hierarchy.

I understand that the approach is somewhat different than the traditional
approach used in the TCP/IP world. I would appreciate it if it can
commented and debated on its merits in the group.

- Greg

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 1999 17:54:56 -0500

> to deal with one protocol for configuration and debug.

In the current model, synchronization of the databases occurs from a
point outward until an aggregation point, at which a route change is no
longer propagated. This effectively creates a hierarchy along the
boundaries of the addressing hierarchy. Of course, if the LS topology
doesn't follow the topology of the phone number allocations in the
gateways, aggregation will be more limited, and the system appears more
flat. However, a system with explicitly defined boundaries, as you
propose, will do no better in this scenario either. As such, I don't see
much advantage to explicitly defining hierarchies.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------