This article is the third in a three part series describing Next Generation Networks (NGNs). It identifies the effects and impacts that NGN technologies will have on users, network service providers, and the communications industry in general. It also highlights the issues for integration of voice and data on enterprise networks. The effects and impacts outlined herein are derived from the characteristics of packet-based networks that were outlined in the first article, and the associated macro-level disruptive paradigms presented in the second article.
1. Internet as the NGN: Technological Impact and Effects
The following three major technological paradigms (1-3) concerning the adoption of IP-technology as the basis for the NGN were illustrated in Part 2:
The net effect of these paradigms is the overwhelming dominance of a single protocol, the Internet Protocol (IP) and its related architecture, to provide the universal end-to-end connectivity.1 All the necessary infrastructural support is in place to ensure its ubiquity and deployment. The key effects and impacts are summarized below.
2. Effects and Impacts on Service Provision
The following three major technological paradigms (4-6) concerning the service provision aspects for the NGN were illustrated in Part 2:
Various effects and impacts of these paradigms are summarized below.
3. Effects and Impacts on Broadband
In part 2, two paradigms for broadband access were developed: 1) Equal Service Access Architecture and 2) Bottlenecked Service Access Architecture.
Various effects and impacts of these are outlined below.
4. Enterprise Network Aspects
This section discusses the introduction of voice services into an IP-based enterprise network, the main challenge in realizing a Next Generation Network.
4.1 General Considerations
The controlled environment of corporate enterprise network provides an ideal environment for the implementation of a converged (NGN) network solution.
Corporations will be able to move a large part of service intelligence into the desk top and away from the external network. For example, there is no need for centrex services for the provision of campus and in-building telephony. Every PC can be equipped with telephone service capabilities to form a "distributed" PBX-like system, even to the extent of eliminating need for any form of separate centralized PBX hardware. There are several related consequences.
Firstly, enterprise-wide software standardization and rationalization can be achieved, since all service provision can be under the control of the enterprise network manager(s). The desk top (fixed or mobile) can be controlled through the distribution of corporately supplied software.
Secondly, reliance on external service providers can be reduced. Many services can be implemented in-house, and not subject to third-party effects. This does not obviate the need for good in-house management of such service facilities, however. Enterprises may still choose, of course, to outsource service provision even with the NGN-based decentralized model.
Thirdly, the wide-area network requirements can be reduced to transport provision. This could take the form of buying IP services, or simply raw transport and deploying corporately-owned IP routers. The relative economics will depend on the geography, the amount of traffic and the degree of connectivity and redundancy (of paths) required.
There is no technical reason to maintain more than a single IP-based Wide Area Network (WAN) for corporate voice and data applications. Access to the PSTN will, of course, still be required and will be achieved by suitable voice gateway platforms.
Many case studies indicate considerable savings can be made from adopting a single integrated (NGN) approach in equivalent green-field situations. However, levering legacy investment may preclude a big-bang implementation strategy. Even in this case integrated trunking and IP gateways can be used to affect a single IP corporate backbone for all applications, resulting in savings from the reductions in WAN requirements.
Moreover, theoretical savings can be lost in practice, since many the practical problems associated with a single network can result in the need for back-up solutions.
Appropriate QoS, in terms of minimum and stable transit delay of less than 100 ms (with jitter less than 40 ms) is essential for real time voice applications. The anarchic nature of IP and Ethernet packet networks makes this a considerable challenge.
The PSTN (and ISDN) were designed to very high standards of performance and reliability. Numerous ITU-T Recommendations ensure end-to-end performance, adequate quality of service (QoS), availability, congestion avoidance, protection under failure, etc. for voice telephony services. As a result, telecommunications equipment has, traditionally, been purpose-built with "five nines;" i.e., 99.999% figures being the norm.
The Internet, on the other hand, originally took a different approach and used off-the-shelf computer equipment. Its reliability was based on a survivability approach, where failure was taken for granted. The result was a "graceful degradation" kind of service. Dynamic routing, coupled with priority and mesh connectivity, was designed to get messages from source to intended destination if at all possible, within a relatively generous time limit,3 and no matter how convoluted the route to be taken. The context for this approach was a military one, one in which a certain percentage of network nodes and links are expected to be destroyed under battle situations. The term "best effort" service is derived from this approach.
Over time the Internet has changed.4 Dynamic routing and mesh connectivity has largely given way to semi-static routing, and the original "type of service" approach has been abandoned. On the plus side, routing configuration has become highly automated, and some quality of service "hooks" have been added to assist the provision of better than best-effort service for real time traffic. However, none of this has been standardized in the context of an end-to-end, multi-domain operational environment. Nevertheless, an Enterprise network could establish its own "standards" within the context of its own, known, predictable and controllable environment. QoS could be achieved either by sufficient over-provisioning or by creating corporate standards for the use of differentiated services (diff-serv) for example.
Although diff-serv facilitates distinction between "service classes," it does not define specific classes, and its scope is limited to adjacent routers. However, in a corporate environment, corporate-wide standards could be defined, particularly for voice traffic and operated over the entire corporate network.
In any case, the means and expertise for measuring and monitoring performance of an enterprise network will be a vital and necessary component of any corporate network. The necessity for this cannot be overstressed. What cannot be measured cannot be improved.
Another difficulty is the need to operate under power-failure conditions. It is essential that phones continue to function when the building power fails. For this reason all Ethernet based equipment should be equipped with the ability to distribute line power to all connected IP telephones.
Vulnerability is also a cause for concern. The paths used for control signalling (for call set-up, routing control, disconnection, etc.) in traditional telecommunications systems are separated and isolated from the paths over which data is transferred. This makes hacking into a PSTN-like control system almost impossible. Similar considerations apply to network management, where in many cases separate networks have been used. An IP-based solution is very different, in providing a just single fabric over which all traffic must pass. This makes IP-based systems more vulnerable to the efforts of malicious attackers.
4.2 Integration of Telephony with Data
The Ethernet LAN infrastructure can also be used to support all applications for in-building and campus situations. IP backbones can also support voice traffic.
Note: the decision whether, or not, to have voice traffic share the same Ethernet as the data traffic needs to be made. Since most Category 5 wiring systems provide multiple pairs to the desktop this should not pose any significant problems. If a single Ethernet is used, dropped packets arising from packet collisions may adversely impact voice quality.
Similarly, a single IP backbone can support all applications. However, voice traffic may require special IP "trunks" to be used and selected by appropriate routing mechanisms.
However, the integration of telephony into a single structure is not altogether straight forward, with several alternative solutions being available.
4.2.1 PBX-based Solutions: LAN-based IP PBXs can take on the role previously assumed by circuit switched PBXs for corporate telephony.
Most traditional manufacturers of circuit-switched PBXs are making IP-based solutions available. Their established market gives them considerable leverage. Providing adequate quality of service is a challenge for them if a single shared LAN is under consideration. A dedicated LAN may be a better option, providing a environment where control can be exerted over IP-telephones. However, PBX solutions may well be proprietary in nature, creating a lock-in situation to a particular manufacturer.
However, a degree of control is possible in some PBX solutions. For example, access to backbone network resources can be controlled to maintain adequate QoS for voice, since the PBX can select specific network resources. "Dial-tone for new calls can be refused, in order to maintain adequate QoS for existing call sessions.
The use of such a locally-centralized PBX may permit access to both IP network trunking and traditional TDM based trunking, creating a sort of hybrid arrangement. In such a case, under failure or overload conditions, voice traffic can be diverted from one to the other, or shared.
Line powering for IP-phones, and back-up power is more likely to be available with PBX based solutions.
4.2.2 PC-based Solutions: PC can be equipped a microphone and speakers (or earphones) and with the necessary software can easily be used for voice sessions between end users.
However, QoS and reliability are major concerns with this solution. A characteristic of this solution is that there is no "network-based" awareness of the end user activity. Thus, end-to-end QoS and reliability are major concerns with this solution. On the one hand, users are under no control with respect to the establishment of calls. On the other hand, they have no guarantees either with respect to obtaining adequate QoS for the duration of the session. The network itself could become inadequate for voice calls under some circumstances, and will be unable to exert any control over the user terminal. User terminals could still indicate QoS requirements at the transport level.
Supplier lock-in may also be a factor, since the role of PC operating systems and PC application software such will increasingly dominate the terminal equipment market, market already dominated by a single company.
There are systems which control "calls" over Ethernet LANs for example. These, however, require a degree of centralized control, and "well-behaved" subservient, controllable LAN stations. WAN resources can then be managed by restricting access to trunking. However, this also requires telephone service "gatekeepers" to be interposed between the LAN and the WAN and the use of specific LAN station management protocols and procedures. A dedicated LAN for voice may also be part of such a solution.
Since there is no physical telephone device as such, line powering, and back-up power is unlikely to be available. Portables may be able to continue under their own battery power for a while.
4.2.3 Router-based Solutions: The router market is very specialized, with only a handful of major manufacturers. Their established markets can be leveraged to accommodate Voice over IP (VoIP) solutions. In particular, the QoS required for voice can be easily integrated into a router's routing capabilities.
Greater control can be exerted in order to both ensure QoS and to control access to network resources to prevent degradation of QoS.
However, QoS and reliability may still remain as concerns when measured against traditional telecommunications standards.
4.2.4 IP Centrex: IP Centrex is another solution, with a variety of configurations. The solution is based around having a remote carrier-based telephone server, off-site, with a similar logical topology to that of PSTN centrex. This server can act as a front end5 to traditional class 5 circuit switch or interconnect with an IP network. Various "access" arrangements are possible. For example, a campus router could "gather" all local IP traffic and use a broadband pipe to access the IP centrex server. Teleworkers could use DSL to access the IP centrex server. More information on various configurations can found at www.ip-centrex.org.
This solution may provide a lower-risk solution for entry in the NGN world of integrating data and voice on IP fabrics.
4.2.5 Gateways: Gateways will still be required to interconnect with public facilities. However, the location and number of such gateways can be controlled by the enterprise as a whole. For example, even telephony traffic destined for a public network can be "kept" on the enterprise network for the longest path to reduce public charges. Far-end breakout (public by-pass) can be more economical than near-end breakout.
Gateways can also serve as back-up in case under overflow or fail-over situations. However, this implies that the single IP-based solution is not viable on its own. This may negate some of the costs savings that may have been calculated and assumed in the original business case for integration. However, a hybrid mix of both IP-based and PSTN based facilities may still be worthwhile given the essential nature of reliable voice applications.
4.2.6 Protocols for VoIP: Two different families of standards have been specified for voice over IP (VoIP) operation.
One set originated from the ITU-T under the umbrella recommendation H.323, for "Packet based multi-media communications systems".
The other set was developed by the IETF as RFC 3261 for the "Session Initiation Protocol" (SIP),
Although products are available for both solutions, the trend seems to be towards SIP and away from H.323, now that the 3G mobile wireless community has chosen SIP. To some, H.323 holds an advantage for accommodating and managing advanced conferencing and multi-media applications but is generally accepted to be much more complicated than SIP based solutions.
SIP is modular in that it can use any media transport, and it makes use of the SDP (Session Description Protocol) to determine the media capabilities of endpoints attempting to connect. For example, a VoIP phone could call a video phone, and the two devices could communicate based on the audio capabilities common to both.
A detailed comparison between H.323 and SIP is outside the scope of this article, but the following points may be of general interest when considering corporate network deployment:
However, with enhancements under way and the choice by the 3G wireless community, SIP is almost certain match and overtake the capabilities of H.323, and to prevail in the long run. At this time most suppliers of VoIP equipment can supply either SIP or H.323 based products. However, there may be interoperability problems between different manufacturers of H.323, because of its complexity and options.
Interworking between H.323 and SIP is also possible. If interconnection between different enterprise networks is required, complex interworking arrangements may be necessary if different choices have been made.
Additionally, it worth mentioning that it is possible to have a single call control system to manage media gateways using either H.323 or SIP transport schemes. A joint ITU-IETF specification for "media gateway controllers" has been developed, see ITU-T Recommendation H.248 for "Gateway Control Protocol", which this permits call control components to be physically separated from the data plane (voice transport) components.
4.2.7 Voice Encoders/Decoders (codecs): The choice of voice codecs is also an important issue, the trade-off being bandwidth versus delay. Reducing the amount of bandwidth required is possible, but only at the expense of increasing the delay time (due to the compression functions).
For example, G.711 is the standard codec used for 64 kbit/s encoders. G.729 based codecs reduce bandwidth requirements to 8 kbit/s, but at up to five times the transit delay. Most systems suppress packet generation during the (frequent) periods of silence, which can result in significant bandwidth savings of 30 -50%. In interworking cases, there may be four (or more) codecs in the chain, increasing the end-to-end delay.
Dynamic negotiation of type of codec to be used is also possible, but somewhat complicated.
4.2.8 Addressing and Numbering: For the short term, NGNs will need gateways to the extant PSTN. This means that some form of mapping between telephone numbering used on the PSTN and the IP-based addressing system will be necessary. Although phones on the NGN will have IP addresses, they will also need a pseudo telephone-like number, in order that external users on the PSTN may "dial-up" those phones located on the corporate NGN. ENUM, that name coined by the IETF, provides a DNS-based directory solution for translating telephone numbers into IP addresses. The allocation of numbers and method of access from the PSTN to a gateway for PSTN-originated calls needs careful consideration.
Even with the DNS directory solution, the implementation is not entirely straightforward. Suppose, for example, a user on the PSTN wishes to access user on the enterprise network. How will the PSTN recognize that the specified telephone number is not on the PSTN? Clearly, the number cannot simply be routed across the NGN on the basis that the number that was dialed is on the PSTN. Instead a gateway to the enterprise NGN must first be found. Two solutions are possible.
The first solution requires involvement of the PSTN provider(s). If the PSTN is to route the call to a gateway rather than to another PSTN end user, then it must be able to recognize that there is something special about this particular number. It could be that the numbers are drawn from a different number range than those for PSTN. For example, the "area" code 878 has been temporarily allocated by the ITU-T for ENUM trials. All PSTN incumbents have to be able to handle thus new code. However, this is not the end of the problem, since there may be many gateways between the PSTN and a given enterprise network, whose respective geographical coverages have considerable overlap. It also requires that the PSTN itself has ENUM capabilities and some way of coupling the traditional telephone number servers to ENUM servers. In the case that the corporate NGN and the PSTN cover the same large geographical area, should calls travel for the maximum distance on the NGN or the PSTN? Clearly, there are conflicting commercial interests at stake here. However, since computing the longest path across the PSTN requires knowledge of the geography of the corporate network, it is likely that PSTN provider would opt for "near end" breakout and simply hand off the call to the nearest PSTN/IP gateway to the caller. With this solution numbers for IP phones have to be drawn from a unique world-wide number space, subject to the control (and price) of registration authorities.
An alternative solution is to make all arrangements transparent to an incumbent's PSTN. Admittedly this requires two stage dialing, in which the PSTN user first "dials" a corporate gateway (say a corporate 800 number) and after some handshake the user "dials" another ENUM-like number which corresponds to the IP phone on the corporate network. In this case ENUM is implemented by the corporate network, and the ENUM-like numbers can be assigned by the corporation without any need to apply to incumbent carriers or national regulatory authorities for number allocation.
Trial implementations of ENUM, using 878, are being established in some countries by various carriers.
4.2.9 Network Design Considerations: Any enterprise considering the integration of voice and data services needs to consider how its existing network will be affected. The existing voice and data networks both need critical examination and audit, firstly to gather traffic statistics to assess existing traffic, and secondly to appropriately dimension the new integrated network. An excellent introduction to network considerations can be found in reference [7].
4.3 General Considerations
The PSTN has a hierarchical topological structure, comprising local, long distance, and international segments. Both the technical and commercial arrangements are based on this structure.
The extant PSTN has much to commend it. It works well, and provides a number of capabilities which have become an essential part of a societal infrastructure. It would be hard to imagine life without such things as:
An Internet based enterprise system could provide the same services or superior ones.
In the public domain there is no overwhelming political or commercial imperative to drive the transition. Currently, in the public domain, although prices have fallen dramatically, the PSTN still charges more for long distance calls than for local calls. Local calls are free, in some sense, being covered in a basic monthly price.
At first glance, the Internet appears to be attractive for long distance telephone service, since it does not currently make any distinction with respect to distance for charging purposes. If the current Internet charging policy were to continue then even long distance phone calls could be covered in a flat fee.
Some experts believe, however, that a distinction will have to be made between real-time-critical data (e.g. voice), and non-real-time-critical data (e.g. e-mail, web-surfing, etc). Special engineering arrangements may need be applied to ensure sufficient resource allocation for real-time-critical data. Different classes of QoS are envisaged.
This implies that the transfer of real-time-critical data will have to be charged a premium over non-real-time-critical data. The big question is will such premium services still be cheaper than using the PSTN? There is a school of thought that considers the true engineering costs of providing a given QoS is the same irrespective of whether TDM or packet techniques are used.6 Market pricing, of course, is not the same as true cost. Anyway, the point to be made is that all things being equal, there may not be a strong enough economic case for migrating all telephony to the Internet. Similar economic considerations may apply to enterprise networks.
The need for gateways in the long term is unclear. However, it is unlikely that all vestiges of the PSTN will be eliminated from the entire world any time soon, and gateways are inevitable for the foreseeable future if world-wide telephony is required by the enterprise in question. Therefore, the address/numbering interworking problem is one that needs to be taken very seriously by enterprise network operators right from the start.
5. Final Remarks
The author has found that the impacts of packet networks are not generally well understood by upper management in many organizations. There are things that NGNs can do that previous networks could not. Similarly, there are things that previous networks could do that NGNs cannot.
Aside from the findings already made previously, one theme that recurs, over and over, is the lack of an adequate technical framework on which to base system architectures. Both public and private organizations need to understand the impacts of emerging NGN technologies.
The situation is close to, and analogous with other utilities where the delivery system is an area of concern separate from the commodity being delivered. The gas, electricity, and railway industry sectors are already based on this principle.
Enterprise Networks stand to gain from NGN technology, by converging all applications on to a single packet-based infrastructure. Unlike public operators, who will try to protect existing revenue streams, the network consolidation inherent in an NGN can significantly reduce networking costs of corporations. The controlled environment of a corporate network will facilitate such NGN implementations, more easily than in the public domain. Telephony gateways will be required between the private and public domains.
However, installing a voice telephony system is more complicated than operating a best-effort data network, and should not be undertaken lightly. A great deal of expertise is required in the deign, selection and operation of such networks.
It is essential to capture the nature of the separation between service and network, as a basis for technical understanding, deployment and policy pertaining NGNs. Terms such as "internet", "telecommunications", etc., need to be universally understood and applied, and be consistent and precise in their scope and extent. Vague/loose usage of these terms will lead to flawed understanding and deployment of NGN technologies. Terms like "broadcast" and "telephone service" apply to the Internet but perhaps in different ways than before. The requirements for provision of emergency services, lawful interception, etc., have to be re-interpreted if these services are to apply to converged NGN networks.
Alignment of policy and regulation to the new technology is essential, and consequently many countries in Europe and Asia are moving in this direction (see references [9] and [10]), the situation in the USA remains unclear (see reference [8] and [11]).
We can conclude that converged networks (NGN) are now practical and will have considerable cost savings in markets driven by true costs. Migration is evident in the private network (enterprise) environment. Politics and protectionism will be primary factors influencing NGN deployment in the public domain.
6. Footnotes
1. I.e., at layer 3, the network layer, as defined in the Open Systems Interconnection (OSI) 7-layer Reference Model, X.200/IS 7498 (reference [2]), and involving a universal addressing scheme.
2. According to the networking market research firm Dell'Oro Group, Cisco held 84.4 percent of the worldwide router market in the fourth quarter of 2002, up from 82.7 percent in the third quarter, while Juniper's share fell to 8.5 percent compared with 11 percent in the third quarter of 2002. Cisco held 69 percent of the market for core routers that provide the backbone for the Internet and long-haul telecommunications networks, in the fourth quarter, up from 65 percent in the third quarter. Juniper's share of the core router market slipped to 27 percent from 32 percent in the third quarter and 34 percent in fourth-quarter.
3. Generous in relation to today's requirements of real-time voice traffic.
4. New requirements and changes to satisfy them are under study, see reference [4]. Part I of this report provided an insight into the work under way in this regard.
5. Which may, or, may not be co-located with class 5 switch.
6. To be fair, it should also be pointed out that another school of thought considers QoS differentiation unnecessary, given the massive amounts of bandwidth available from optical systems, and the expectation that processing speed and memory capabilities will continue to increase.
7. References
1. Developing a Next-Generation Internet Architecture, Robert Braden, David Clark, Scott Shenker, and John Wroclawski, July 15, 2000, www.isi.edu/newarch.
2. ITU-T Recommendation X.200 (aka ISO/IEC 7498-1), Open Systems Interconnection - Basic Reference Model.
3. Telecommunications Security; Lawful Interception (LI); Issues on IP interception, ETSI TR 101 944.
4. Architectural Principles of the Internet, IPAM Tutorial, Bob Braden, March 12, 2002, http://www.isi.edu/newarch.
5. RFC 2101, IPv4 Address Behaviour Today.
6. RFC 2775, Internet Transparency.
7. VOIP Tips from the Trenches, Kenneth Percy and Michael Homer, Network World, 27 January 2003.
8. Potential Relevance to the United States of the European Union's Newly adopted Regulatory Framework for Telecommunications, Federal Communications Commission, Office of Plans and Policy, Paper No. 36, July 2002.
9. Frequently asked questions on the regulation of Voice over Internet Protocol, OFTEL 2 April 2002.
10. Green Paper on the Convergence of the Telecommunications, Media and Information Technology Sectors, European Commission Brussels.
11. Challenges of Convergence, J. Scott Marcus, Senior Advisor of Internet Technology, FCC.
About the Author
Keith G Knightson has been involved in data communications for more than 25 years, and has worked for British
Telecom and Nortel Networks. He has operated a consulting company since 1995 concentrating on network architectures
and next generation networks. He may be contacted at kgk@rogers.com.
|
The ABCs of LDAP: How to Install, Run, and Administer LDAP Services is for network and systems administrators who want to begin using LDAP more extensively. It delivers the theoretical background needed to understand how these servers work, resulting in clear, concise examples of implementations in both commercial and OpenLDAP environments. Topics include major LDAP APIs, such as PHP, Perl, and Java, as well as distributed command line tools. The book covers ways to integrate LDAP into existing systems, and provides hands-on examples within working implementations. | ||||
|
Server Disk Management in a Windows Environment explains the basic elements of disks and disk architectures, and explores how to successfully manage and maintain functionality within a Windows environment. The author focuses on critical issues that are often ignored by other books on this subject, issues including disk quotas, fragmentation, optimization, hard drive reliability, asset management, software deployment, and system forensics.
|
Wireless Sensor Networks: Architectures and Protocols describes how to build these networks, from the layers of the communication protocol through the design of network nodes. The book summarizes the multiple applications of wireless sensor networks, then discusses network device design and the requirements that foster the successful performance of these applications. The book discusses factors affecting network design, including the partitioning of node functions into integrated circuits, low power system design, power sources, and the interaction between antenna selection and product design. It presents design techniques that improve electromagnetic compatibility and reduce damage from electrostatic discharge. |
Filled with contributions from international experts, the
Wireless Internet Handbook: Technologies, Standards, and Applications describes basic concepts,
current developments, and future trends in designing modern architectures. |
|