A router is a device with almost mystical significance in networking today. As companies transition more to IP as their standard protocol, they view themselves as inevitably more dependent on routers.

Level 3 switch players have asserted that their products will eat routers in a few years. Virtual circuit vendors, particularly ATM vendors, have criticized the router and its connectionless network architecture as being out of touch with a business reality that demands service guarantees. Yet routers continue to be bought.

Ironically, routers are threatened. In fact, routing as we know it is threatened, along with the whole of Level 3 protocol handling. The culprit is an offspring of routing itself, promulgated at first by the king vendor in routers—Cisco. The culprit is MultiProtocol Label Switching, or MPLS. If you're a network manager today, you need to understand MPLS, and there's probably not a lot of good material available to help you.

For those not subscribers; we're sorry but this section is for subscribers only!

Recently, a new approach to IP voice standardization has emerged, and one aimed at the critical issue of how services would be coordinated and activated – the station and service signaling. Called the Session Initiation Protocol (SIP, pronounced like a small "sip" of a drink), this new concept has gotten some attention from service providers.

Competing standards have a way of suppressing a market. Are SIP and H.323 competing standards? What, if any, benefit would SIP provide? These are the questions we'll explore this month.

There are two levels at which SIP can be considered. The first is the context of IP telephony as an application in itself, meaning that the Internet would have to provide service features of the public phone system. The second is the context of an overarching multimedia call and conference environment specialized to the Internet. In both these contexts, we have to consider the role of H.323 and the ITU standards process.

H.323 was promulgated as a collaborative standard, in effect. It provides multimedia conferencing among a community of IP or other network users who were presumably electing to carry on their collaboration outside the realm of public telephony.

H.323 is not Internet/IP-specific, and so it doesn't (at the moment) deal extensively with the process of how H.323 collaborators find one another and how the service process is coordinated. The control mechanism of H.323 is fairly simplistic: H.245 facilities control and Q.931 call control.

If we view H.323 in the context of Internet collaboration or even Internet conversation, there would seem to be some elements that beg further definition. The process of creating conferences and joining them isn't particularly web-friendly, for example.

The situation in the specific use of IP voice services is pretty much unsatisfactory, period. While there are provisions in H.323 to support gateways between the data network collaborative community and outsiders linked via such things as public telephone services, these provisions are not necessarily designed for (or adequate for) the mission of supporting voice services over IP if there is no presumed H.323 collaborative context.

Voice over IP is a subset of multimedia collaboration in a technical sense, if one assumes the same application context for it as would prevail for multimedia H.323 conferences. If one assumes that the objective of voice over IP is to provide the Internet equivalent of public voice telephony, however, the application target gets broader, and diverges from the target for H.323. SIP is aimed at this new target.

To make the Internet work as a public phone network, we'd have to incorporate in the Internet a set of services roughly comparable to the services offered in the phone system under the general label of Local Access Special Services (LASS), and also the features of telephone systems on premises in call handling. None of these really exists in H.323, whose goals never included emulating phone networks.

One way that special services could be brought to the Internet would be to link outward into the public network via SS7 and draw these services from outside. This strategy is particularly attractive if we assume that the great majority of Internet activity in the voice area would be intimately linked with public telephony. For example, if dialing an 800 number from an IP phone would probably result in a linkage of the call to a real number in the public phone network, it makes little sense to duplicate the 800 number handling logic of the public network within the Internet.

As the presumed level of voice activity on the Internet (or at least voice activity that mimicked the public network's features) increases, however, the chances that an "800 call" might both originate and terminate on the Internet increases. If there is a good chance such termination would occur, it now makes less than no sense to exit into the public network to decode the 800 number.

SIP is targeted at addressing this kind of issue, developing a protocol that would be a combination of the standard signaling of user telephony and elements of the SS7 or AIN signaling that would be used to coordinate special services.

SIP is being developed by the Multiparty Multimedia Session Control working group of the IETF, unfortunately called "MMUSIC" and this seemingly linked somehow with the rock business. SIP is both a competitor to H.323 and a potential element of it, depending on your point of view, and this doesn't make understanding it any easier.

SIP fits as an element in the overarching Internet multimedia conferencing environment that MMUSIC is toiling with. At the highest level of this architecture are the division of conference management and media agents/applications. These consume a secondary set of services that include conference setup and discovery, conference course control, and the applications themselves. They, in turn consume protocols for session management and initiation, resource reservation, conference control, and conference information transport.

In the MMUSIC model, H.323 is a form of tightly coupled conference control, though the ITU work in this area is literally in its infancy. SIP is an element in the session management and conference initiation process.

The assumption of the MMUSIC model is that a multicast or unicast conference is a conference nonetheless, and the same basic management model would apply to either. In this model, the conference is launched by somebody, and other parties are "invited" to join it. A multi-party conference is supported, presumably, by an IP multicast group. Invited parties with an interest join that group to participate.

The problem with this model (and the unicast model, which is a special situation where the "multicast group" is a single station with a single IP address) is that it's not clear how a potential recipient knows about the conferences available, how the multicast addresses get assigned without users stepping on another's addresses, etc. The solution would be to have some form of directory mechanism. Conferences are entered into a directory and assigned an address, and users would use this directory to locate the conferences and presumably join those they liked. If the conferences were extemporaneous, some mechanism for inviting users explicitly is required. In either case, we'd need to have a means of insuring that those who attended were really allowed to do so.

MMUSIC must deal with the questions of how real-time information is transported in a conference, how conference members can even know who's in a conference at any point in time, etc. This process is largely outside the scope of our inquiry here, because it doesn't deal with the activation of conference sessions, but the exchange of information once one is set up.

The activation process is a part of the MMUSIC conference control function. Conferences are generally classified as "light-weight" or "tightly coupled". Light-weight conferences are as structureless as conferences can be, with little more than a strategy for rendezvousing to establish one. Tightly coupled conferences have an explicit conference control mechanism.

This is where there is a kind of intersect between H.323 and SIP, because one of the strategies for conference control is good old H.245, and another is the T.124 sub-standard of T.120 that is a kind of kissing cousin of H.323 by inclusion/reference.

The final element of the high-level MMUSIC architecture is the process of conference discovery or rendezvous, and that is where the SIP protocol fits in. Conferences can be discovered via directory or invited. The former process uses the Session Announcement Protocol (SAP) the latter uses SIP.

In theory SAP could be used to help discover H.323 conferences, and this isn't an unreasonable application given the fact that H.323 is probably going to be used primarily in multiparty conferences that would be scheduled in advance to guarantee participant availability.

Even where advertisement of sessions is done, there may have to be a way to control the way that users are invited to join a session. In extemporaneous sessions, this becomes the primary conference discovery process. Where the "session" is a two-party relationship, it reduces to something like a call, and SIP is the proposed protocol to support it.

Within an IP network, a SIP environment consists of SIP servers and SIP clients (or user agents, if you like that terminology). Clients are divided, for now, into telephony clients that serve what are basic telephone applications, and conferencing clients that serve multimedia and multi-party conferences. The two client types could eventually become one, according to the drafts so far.

A SIP conference consists of an accepted INVITE (an ACKed INVITE), or more properly, a set of accepted INVITEs that covers at least a subset of the list of people who were INVITEd. In the simplest model of SIP, a SIP client INVITEs another SIP client to a two-party session. This process, assuming the clients know one another, doesn't involve servers at all.

What SIP servers do is facilitate conferences that involve more than one client, or provide facilities to locate INVITEes or redirect INVITE requests to other locations to handle mobile conferees. These functions provide many of the "phone-like" capabilities that IP telephony could call upon, completely outside the context of multimedia conferencing.

An INVITE contains a session description written in the format of the Session Description Protocol (SDP), and includes things like the media type used, time of conference, etc. In a two-party conference (a call), the INVITEd party can return an SDP message indicating what of the specified media it can accept. In a multicast conference, the INVITEd guests should not return an SDP message, because the conference has to work with a single media set.

The simplest mission of a SIP server is to locate an INVITEe who is not known by the source of the conference. The logical name of the INVITEe is processed by a location service function in the server to yield a real address. What happens then depends on the exact function of the SIP server.

In the case of a SIP proxy server, the server will respond to the INVITE by issuing its own INVITE to the real INVITEe as identified by location services. If the INVITEe ACKs the invitation, the proxy server ACKs the original INVITEr, and the session is connected. If not, the proxy server issues a BYE to the INVITEr, signaling the invitation is refused.

If the SIP server is a redirector, it simply redirects the original INVITE to the client identified by location services and gets out of the loop. Obviously this is a simpler function.

Location services are, obviously, a directory function. A SIP user can register with the service at one or more locations. When a location request for that user is received, the location services directory will return a list of the locations, and a SIP proxy server can try each before returning a BYE to the INVITEr. The redirector form of the SIP server would simply return the list to the INVITEr, who would have to do the multiple tries himself.

Users can REGISTER and UNREGISTER with location services to provide an idea of where they can be reached while "on the road" in the sense that they are not at their permanent address. Location services can also use LDAP or other procedures to attempt to locate users through directory functions. This "I'm here for now" method is supposed to age out after a period of time (one hour). The mobile REGISTER concept is designed for users who move often; the static location of a user is presumed to be available through directory means.

A SIP server can respond to a call with a class of response called a REDIRECTION. This would indicate that the INVITEd party can't be unambiguously reached at the normal location, and that some form of intervention is required. The reason for redirection may be that the party moved permanently or temporarily, or that there are multiple facilities or locations through which the party can be reached, and a selection is required.

Another service of a server (a proxy server, at least) is authentication. An INVITE may require that the INVITEr is authenticated by the network, and the proxy server can provide that facility. Servers can also provide information on alternate services, including instructions for a caller to use standard telephony, e-mail, or leave a voice mail message.

If the INVITEe is located, SIP provides call process signals just like a telephone system, including RINGING to indicate the INVITEe is located and is being alerted to the call. An "OK" progress signal indicates that the session has been initiated.

There are a number of SIP capabilities that are directly aimed at providing ISDN or AIN features in an Internet calling application. These include the ability to transfer and forward calls, the ability to "camp on" a busy station, explicit n-way conference and "meet-me" conferences, universal or personal number, abbreviated dialing, special billing (reverse charges, etc.), call waiting, etc.

The SIP features of the basic service and the ISDN/AIN equivalent capabilities can create something a lot like public telephony. There are even explicit ways of linking between the SIP world and the public telephony world. In all, SIP seems ideally suited for the linkage of Internet and public voice.

Is it?

The question of whether SIP will govern the interaction between public telephone networking and the Internet depends on a multitude of factors, many of which are highly judgmental in interpretation or assessment. So … we'll judge.

The first and foremost issue with SIP is the progress of the current NetMeeting or H.323-based collaboration. Things that accelerate the acceptance of that architecture will tend to commit more and more client systems to a non-SIP architecture, and that would eventually devalue SIP as a whole. The issue is particularly critical because carriers are in business to make money, and supporting a strategy that isn't generating any of it seems an unlikely move for them. There are about 30 million NetMeeting clients installed, though a minute fraction are in use. The number of SIP clients is insignificant.

Another factor is the international community. The IETF doesn't hold sway much in the international telephony world, and the ITU may elect to enhance H.323 and H.245 to support the essential features of call management that are now lacking, and presumably would help to promote SIP.

A final factor is the whole voice-over-Internet thing. Sure, there are Internet nerds who want to talk to everybody on the 'Net no matter how lousy it sounds, but most phone users expect something a tad better than CB radio performance. The context of multiparty collaboration tends to insulate users from the deficiencies of the Internet as a voice transport network because there aren't many quick changes in the identity of the talker. With normal phone-like conversations, the delay associated with Internet voice can be way beyond annoying.

Voice over IP may also suffer from big-time regulatory hurt. Internationally, the use of the Internet to transport voice calls can be considered a violation of telephony treaties, and thus something the source or destination country could suppress. In the US, there is a big question-mark on whether the ISPs should be paying access charges and universal service assessments under the Telecom Act. Assertions by the industry that they shouldn't on the grounds that they don't provide the basic services the Act focuses on weaken if voice-over-Internet gets to be a big issue. Face the ISPs with the option of paying access charges or not doing voice and everybody will shut up in a hurry.

In all, we believe that the expectation that SAP will sweep the world are premature (like most expectations in our age of inflated marketing claims and unrealistic forecasts). We'd expect to see some formal process to reconcile the goals of MMUSIC and the ITU before there were any real, widespread, deployment of SIP. We'd also expect this to be delayed by the overall issue of the Internet business model and the US regulatory process, something we've talked about many times (and touch on in the next section of this issue, in another context).

SIP, and the whole MMUSIC initiative, is a positive thing even if it's likely to be hailed prematurely as the advent of Internet telephony on a large scale. We should watch its progress carefully, but not be deluded by the howling of the usual mob. They've been wrong before in predicting other industry revolutions, and they're wrong about this one, too.

The issues associated with always-on Internet access have been a focus of both vendors and our past few issues. We've talked about the overall problems, and also about the strategies of cable modem advocates in presenting their own solution.

The archetypal rival of cable modem players are DSL players, of course. In the residential space, Digital Subscriber Loop technology was first proposed as a competitor to cable television in the program delivery sense. With the growth of the Internet, DSL is now targeted more at IP applications in home online service access, and to provisioning T1 and fractional T1 to business.

There are a variety of DSL technologies, all identified by sticking a few prefix letters on the "DSL" acronym. The collection of these technologies is normally called "xDSL", where the "x" represents any of these specialized prefixes. The contenders so far are:

• High-Speed DSL (HDSL), a technology using two copper pairs to provision T1 or fractional T1 without repeaters. Most of the T1 sold today is probably HDSL-provisioned.
• Single-pair DSL (SDSL), which is like HDSL but offers service on a single pair rather than two pairs.
• Asymmetric DSL (ADSL), which provides an unbalanced bandwidth distribution with the highest speed toward the user. This is a single-pair technology, and the one usually targeted at residential access. The high-speed side of ADSL can be as high as 6 or 8 Mbps, and the slower side from 16 to 640 kbps.
• ISDN-like DSL (IDSL), which is the plain vanilla ISDN Basic Rate connection (144 kbps, divided into two user channels of 64 kbps and one signaling channel of 16 kbps), used without the signaling. One or both user channels may be used, giving up to 128 kbps on a single pair.
• Very High Rate DSL (VDSL), a form of asymmetrical DSL that provides up to 52 Mbps on the high-speed direction and as much as about 2.5 Mbps on the slower side. This is being promoted primarily for HDTV applications.

The form of xDSL most often promoted for residential Internet access is ADSL, though it is not clear that there is any real justification for its deployment in this application. ADSL would offer the user very high download and Web-load rates, assuming that the rest of the Internet connection could keep up with the access, and assuming that the user could get the service at a price that could be paid. Whether these two things are likely will be covered later.

Like all forms of digital subscriber loop technology, ADSL is based on a modulation scheme impressed on the copper. There are two proposals for ADSL modulation:

• Carrierless Amplitude Phase Modulation (CAP). This is a version of the kind of modulation used in high-speed modems (Quadrature Amplitude Modulation, or QAM), but with the central or home frequency (carrier) suppressed.
• Discrete Multi-Tone Modulation (DMT). This is based on a set of distinct tones (like touch-tone) that are used to encode the digital data.

DMT is potentially faster and less noise-sensitive according to its proponents, but is likely to be both more expensive and less supported by current equipment.

Voice is impressed on the same copper in a non-interfering way, and a splitter pulls the voice off. The idea is to insure that voice transport would look a lot like it does today, with minimal risk that "lifeline" voice services would be impacted by a problem with the ADSL equipment, power, etc.

Whatever the modulation, ADSL is a loop connection between a subscriber ADSL modem and a Digital Subscriber Line Access Multiplexer (DSLAM). This device, serving multiple ADSL users, would split the POTS connection out at the central office side, and also provide a means of distributing the rest of the ADSL service envelope to the respective network service points (NSPs).

The CAP-versus-DMT debate in ADSL is the first point of vendor disagreement; the makeup of the home-to-DSLAM connection is the second. The camps are roughly divided into an "ATM" and "not-ATM" flavor.

The ATM-on-ADSL camp points out that there are a large variety of things that would represent useful services to a prospective ADSL user, and that ATM alone can promise to carry them all using a single service architecture. ATM handles asymmetry well; ATM VCs are essentially simplex in nature in any case. ATM's multiple classes of service adapt it to anything from digital isochronous delivery to best-efforts packet.

The "not-ATM" camp point out that ATM is a very costly solution, versatility notwithstanding. If the goal of ADSL is primarily to support data access of some sort, then the value of ATM is questionable. Some in this camp point out that the transitioning to HDTV, which requires far more digital bandwidth than ADSL could provide, would tend to force the largest isochronous application – entertainment video – to the VDSL level. This camp is essentially trying to pluck the low apple of application value.

The debate on ATM or not-ATM extends out of the loop packaging area and into the DSLAM and DSLAM-to-NSP relationship as well. If one makes the DSLAM a generalized local service multiplexer that can support any form of xDSL and supply information for any type of loop service, it starts to make sense to think of it (and its relationships with other network components in the carrier space) in terms of ATM.

Logic might be the place to appeal in deciding this issue, but since when was the marketplace ever logical? The truth is that the forces likely to influence the way ADSL enveloping is done are the politics of carrier procurement and the business model of the Internet.

Carrier procurement has traditionally been done in a world where accounting practices dictated a long write-down on equipment. No end user would ever write communications equipment down on a ten-year or more cycle, but that's routine in the carrier space.

The accounting issue is cost. If I buy something for a million bucks and write it down over five years (in a simple model) it generates an annual expense of $200,000. That expense becomes an element in the cost I have to recover for the services that something I bought is used to provide. Write the same thing down over 10 years and my cost is cut in half; use a 20-year write-down and my cost is a quarter of its former value. Assuming a static cost/price relationship, what model do you want your service based on?

The cost-management bias to adopt ATM-based ADSL will be strong in the carrier space, as Alcatel's activity already shows. But the other side of things is the pace of demand. If we were to see a huge increase in demand for residential Internet, and a promise that this application would represent a vastly greater revenue source than something like video-on-demand, then the carriers might decide to scrap conservatism and start raking in the bucks.

In the balance, we think this is an unlikely scenario, partly because of the aforementioned Internet business model. The next couple of years are going to present challenges for the ISPs, and during that period it would be difficult for them to increase network capacity to accommodate a significant number of high-speed, always-on ADSL users without a major capital building program they can't fund based on current revenues. Since the residential user wants ADSL only to the extent that they don't have to pay for it, that puts a crimp on the old ADSL market.

Without a credible explosion in IP demand at a good price level, the carriers would be stupid to push ADSL in a pure IP application context, ruling out video applications that generate billions for the cable television industry. They'd be particularly stupid given the fact that that same cable television industry is eyeing aspects of the common carrier service market (the Internet data part, in particular) with covetous eyes.

We deem it more likely that ATM will play a role in ADSL than that it will play a role in cable modems, in other words.

ATM to the home is even less likely to be directly consumable than ATM to the corporate desktop, so it's pretty clear that the ATM service connection couldn't be exposed to the subscriber. There, we need to have either an Ethernet LAN connection or some other new interface like the high-speed serial bus.

If we can't expose an ATM interface, then the idea of using something like ATM25 would be extraordinarily expensive; the ADSL access box would have to be an ATM LAN Emulation proxy client. That means that the IP packets would have to be presented in some other context. A similar objection, in our mind, applies to the use of RFC 1577; that only moves the proxy problem from Level 2 to Level 3.

One choice with less impact is to do a kind of "Ethernet-over-ATM" connection. This could, in theory, be done using standard RFC 1434 ATM encapsulation, but that would require reformatting the packets at the destination if they were to be used in a router. Another option is to encapsulate the packets in PPP, and simply transport PPP over ATM. We believe this will prevail, because it simplifies the design of the access box.

At the higher level, there's also the question of what relationship exists between the IP end-user interface, the DSLAM, and the IP network providing Internet access. If the ADSL architecture is to be truly universal and ISP-independent, it has to appear as a Level 2 path. This would mean that the DSLAM, user access device, and delivery system would have to appear to the ISP computer as a LAN. Presumably, then, the users of an ADSL system would be on the same subnetwork.

That raises security questions, of course. It is very doubtful that carriers at any level would deliver a service architecture that permitted homeowners to hack one another's files. What is likely to happen is that the DSLAMs will be set up to "eat" ARPs so the process of address resolution that is typically used on a LAN wouldn't work among the users of an ADSL system. That doesn't mean that these users wouldn't be able to communicate, only that they'd have to use some more secure (or at least secure-able) mechanism.

Keeping the stations on a DSLAM from ARPing one another is simply a matter of making each its own subnetwork, but that has implications in the size of the routing tables that support the DSLAM community. These could be overcome, of course, and this seems the most straightforward option – as a start. It would, at least, slave the access to another DSLAM station to the use of routing services, and permit the ISP to screen the flows to provide some central security.

Another option would be to incorporate some form of security firewall in the access device itself. Inevitably, vendors will offer secure ADSL access aids whether they are needed (or even useful) or not. The problem is that it isn't at all clear how all of the potentially destructive accesses could be separated from the uses the owner of the ADSL link wanted to enable.

We should point out that these problems are likely to occur on cable modems as well, but we believe they are more pressing in the xDSL space because the technology is more likely to be used to support what are essentially business applications – home and small offices, for example.

All of the technology issues of xDSL may be overshadowed by the business and political problems it poses. We've cited the problem with the Internet's business model a number of times already, here and elsewhere in these issues. The political problem merits some review.

The Telecommunications Act of 1996, in order to preserve competition, required that RBOCs who wanted to enter the regional toll market take steps to open their own local exchange market to competition. One of the steps mandated was to provide wholesale access to local exchange outside plant, including the copper loop.

In theory, an ISP or other provider could wholesale the copper from the RBOC and use it, via ADSL, to provision digital Internet access. In this case, the Internet provider would install the DLSAM and home access devices, and would trunk the Internet traffic out of the local offices to their own POP.

In practice, this kind of open access has proved elusive. The Telecom Act does not mandate competitive reform; it links it to RBOC or ILEC entry into the regional toll market. Thus, the RBOCs must file under Telecom '96 for relief from toll restrictions, and prove compliance with the competitive points of the Act in return. No filing, no competitive points. Furthermore, even if an RBOC files, they may not really comply. The interests of the RBOC are served by as marginal a level of compliance as possible, and there are many interpretations of the Act.

Just about every aspect of the Act has been challenged in court, and we haven't even gotten to the thorny questions of the terms under which a given piece of copper must be wholesaled, the price it commands, the access that must be provided to it in terms of co-location of the DSLAM, etc.

Where we stand now is that no incumbent LEC has received FCC approval to enter the toll market under the Act, and thus none is required to provide open access to their plant. About half the states have some form of PUC-based local exchange competitive inducements, but these are often more political carrots than real reforms.

The big problem with this situation is that while there is a regulatory dispute underway, there is little chance that the incumbent LECs will push to deploy DSL on a large scale. To do so sets the retail price and conditions associated with the service, and that would set wholesale terms by implication. Lacking retail service on a large scale, a considerable amount of foot-dragging could occur before wholesale access is real. Without wholesale access to copper, nobody other than the incumbent LEC can provide xDSL in any form.

All of this adds up to the fact that the wholesale deployment of ADSL-based Internet access is far more problematic than that of cable modem Internet access. The latter must contend with the business model of the Internet and the problem of increasing transport network performance. The former must contend with that, the inertia of the telco provisioning mindset, the higher cost of the likely ATM linkage, the politics…you get the picture.

There is a statutory review of the Act in 1999, and none of the various lobbying organizations who paid off their officials in 1995 and 1996 want to go though that cycle again. It is possible, even likely, that the players will fall into line and the incumbent LECs will at least start to secure FCC relief late this year, with most of them falling into line in 1999. The next step is the protracted regulatory and legal wrangling over the exact meaning of each of the competitive points the ILECs have to give up. That will probably take a couple of years to resolve, opening the door for full-scale ADSL or at least xDSL opportunity by about 2001.

If the Internet business model is fixed before that, the cable companies could secure a major windfall by scooping the xDSL market in providing always-on Internet. If not, we think the common carriers will win with xDSL, and they may do that eventually in any case.

In the next issue, we'll make good on a previous promise to look at the technical/business structure of the Internet itself – from peering politics to NAPs and MAEs. We had to wait on this one for some announcements to become public. We'll also be exploring some e-commerce and VPN issues. Finally, we'll have a tutorial on LDAP and its implications and uses.

Access the index of CIMI Corporation's recent newsletters.