126 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT deployed, and on which network and hardware vendors can design their components. Their choice is distilled primarily from the collective consideration of the require - ments and the changing nature of the Internet as it relates to large service providers. In most cases, however, the adoption of such principles becomes the decision of the cor - poration undertaking the design of the IP Service Platform. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. C HAPTER 5 Cloud Architecture and Interconnections In order to realize the vision of moving some applications into the network, where they can provide better service at lower cost, we need to reengineer the network slightly. This chapter describes how to evolve the network through service - oriented clouds, and to interconnect these to create a flexible network fabric. This builds upon legacy net - works, commercially available IP networking products and standards - driven proto - cols. Such tools are one element in the design of appropriate redundancy, specific interconnections and the trade - offs between centralization or distribution. The result - ing networking middleware readily satisfies the complex and changing operational requirements for capacity, throughput and reliability. This achieves low cost through use of “off the shelf” general - purpose computers. As part of the network reengineering, clouds will tend to rely upon optional distrib - uted network elements (DNE). These unify a wide range of network elements through a single virtual network connection and APIs, as presented later in Section 5.5. Consider the example of VPN services superimposed upon lower - level capabilities through plat - form - based software. This leverages the underlying network capabilities, while drawing upon higher - level VPN techniques of tunneling and secure routing. This could secure IP routes through L2TP or IPSec for one user, MPLS for another, and custom encryp - tion for yet another. Network elements should exhibit a predictable and stable behavior that is largely immune to changes in configurations or components. Middleware achieves this through a uniform set of open APIs that satisfy detailed functional requirements irre - spective of specific configuration. This is fundamental, particularly given the recogni - tion that networks – and the Internet in particular – are fluid, “moving targets” that defy any purportedly “optimal” configuration. The middleware itself caters to a busi - ness - oriented service model supporting flexible provider roles. This service model accommodates the changing definitions of providers and infrastructure. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 128 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT This entire section presents a concrete discussion of hardware and software that accomplish these goals. The current chapter begins with the architectural description of general architecture comprising an internal backbone network with externally fac - ing SNodes (service nodes). The SNodes provide services near the network edge, where computing engines can serve the locally attached networks, thus attenuating the increased backbone traffic. Scalability relies on nearly stateless protocols and intelli - gent network interactions. The chapter proceeds through a sequence of increasingly powerful systems – starting with a small cloud built from three computers, which supports the full middleware capabilities and the APIs. This configuration adeptly supports community - scale SNodes, and is also suitable for service development. The small cloud can evolve to support a wider range of services by joining a larger network comprised of multido - main clouds (Section 5.6). Cloud capacity and reliability can be increased by adding processing power – either through more engines, or faster multiprocessors. These larger clouds leverage the “elastic capacity” designed into the middleware though tech - niques such as caching and load balancing. These techniques support smooth evolu - tion into a substantially larger cloud by adding gates, disks and internal networking. This evolutionary path eventually leverages hundreds of computers, fault - tolerant components, optimized router networks and long - distance backbones. It supports nationally deployed services. These retain the same software and data stores as the smaller systems. Such capabilities enable fully reliable eCommerce and other essential services. These services are reliably exported to other clouds without modification. This model com - bines multiple autonomous clouds and draws upon middleware capabilities of interna - tionalization. Each cloud supports a domain composed hierarchically of accounts, users and services. Intercloud trust relationships extend privileges to specific accounts or users from other clouds. Multiple fully autonomous clouds thereby interoperate and provide mobility of services and users. The chapter also discusses a novel distributed cloud utilizing the public Internet for the cloud interconnections. We conclude with a discussion of Internet routing as it affects middleware. 5.1 Cloud Architecture All clouds share the prototypical architecture of an edge gateway enforcing a security perimeter, thereby protecting core services and network - switched traffic. The gateway supports intelligent services through service - hosting and network intelligence such as routing and protocol mediation. The core services include databases that contain both dynamic and persistent object - oriented information. The gateway and core are logical TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. C LOUD A RCHITECTURE 129 entities that may be deployed in multiple components or distributed configurations as required. 5.1.1 Applications, Kernels and Switches A cloud functionally consists of three major layers: application layer, kernel layer and switch layer. Each layer controls traffic according to the authentication and encryption policy The traffic is either encrypted/decrypted and passed through a given layer, or it is redirected to a higher layer. Application Layer The application layer supports registration, authentication, encryption/ decryption, etc. This layer replicates the data and functions in order to effi - ciently control traffic on all three layers. The application layer also provides fine - grain access control mechanisms. Communication through the secu - rity perimeter is regulated at multiple granularities. The kernel layer is mainly responsible for the routing and coarse - grain access control through the support of firewalls, such as packet filters. The switch layer supports physical transport and encryption/decryption functions are performed by specially designed hardware devices, such as ATM switches. The application layer provides all needed data for the switch layer and prepares the switch layer to work at high speed. The main task of the switch layer is to support high - speed communication and real - time applications that need high bandwidth, such as telephony, video con - ferencing, and the like. Kernel Layer Switch Layer 5.1.2 Points of Presence (POPs) and System Operation Centers (SOCs) The physical architecture of a cloud is structured to concentrate most of the service logic as a distributed environment at the edges of the managed network. At the edges, physical Points - of - Presence (POPs) aggregate traffic from hosts and other networks, and send it into the cloud through a Service POP (SPOP), as shown in Figure 5 - 1. POP POPs are the physical points of presence that aggregate traffic from a vari - ety of hosts and networks into the cloud. This consists of IP traffic ingress from LANs and WANs; terminating PPP connections from modems over PSTN; or terminating voice and FAX traffic from a POTS line. All traffic becomes IP based once it passes into the physical POP. SPOPs are the Service POPs that implement middleware layer service logic. In addition to other functionalities, SPOPs act as gateways to the backbone SPOP TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 130 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT Figure 5 - 1: Points of Presence and Operating Centers Located at Network Edge of high bandwidth/low latency IP transport to other SPOPs and POPs, as shown in Figure 5 - 1. SOC System Operating Centers (SOCs) are SPOPs dedicated to the system mon - itoring and management purposes of the cloud. SOCs may, or may not, have POPs connected directly to them as traffic to the SOCs must flow exclusively through the backbone. An SPOP can be provisioned in a number of different ways depending on the capacity and throughput of its connections. For small to medium throughputs and a limited number of users accessing the cloud through this SPOP, the platform’s service logic sys - tems can be placed on a single (possibly a multiprocessor) machine. Here, the edge gateway implements functions such as routing and firewall as well as the service func - tions such as usage recording and access control. A single SPOP constructed with cur - rent technology can provide all service logic and network functions for several thousand users. For a much larger workload and a greater number of active users and services, the SPOP can be provisioned as a group of distributed network elements in which high - speed smart switches support the network functions. The service functions utilize a cluster of edge gateways that offload the router/switch functions to a distributed net - work element (DNE, see Section 5.5.2). These two configurations are shown in Figure 5 - 2, where SPOP #1 supports large user bases through replicated processing and a distributed network element (DNE), and SPOP #2 is a single node. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. C LOUD A RCHITECTURE 131 The SPOPs actively support the conventional end points – users and servers – thereby enabling their active participation in the cloud’s service logic and networking. These end points must support IP - based communication and an active control channel to an edge gateway in an SPOP. The channel enables and controls the managed interactions between the peer and the cloud. A peer may, for example, ensure nonrepudiation of action as well as interact with active directories. Figure 5 - 2: Interconnected SPOPs Using DNE and Full Gates (non - DNE). Peers interact securely with other peers through the SPOPs of their cloud, as well as with other clouds with established peering agreements. Mandatory encryption pro - tects the authentication and control functions, and optional encryption protects other interactions when deemed necessary, For example, a user who desires Internet access, would first establish an authenticated connection to the cloud through an SPOE The user could then access other SPOPs, including the Internet - connected POPs. 5.1.3 Gates, Cores, and Stores The overall networking middleware architecture is organized upon three types of the logical function: gates, cores, and stores. These form the basic elements of the distrib - uted system, and can be combined into points of presence, or POPs, as shown in Figure 5 - 3. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 132 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT Gates The gateway is composed of one or more gates. These form a security perimeter protecting the system and its users from intrusion or improper use of resources. The perimeter builds upon a dynamic rules - based firewall that blocks unauthorized traffic, removes fraudulent packets, and identi - fies legitimate traffic. All authenticated data transmissions traverse the firewall and become subject to the security infrastructure. Figure 5 - 3: Large Cloud Showing Gates, DNEs, Stores, and Core The gates support both the packet routing function, and also a service logic function. The gates enforce authentication, advanced security ser - vices, access control, resource usage tracking, caching, and international - ization. Gates provide protocol mediation and service as needed. The routing functions enable connections by external networks, thereby supporting communications with the core servers and other external net - works. These networks connect clients, servers, stores and POPs residing outside of the firewall, as well as noncompliant legacy and enterprise net - works. The gateways are constructed from one or more gate machines. Section 5.5.2 ”Distributed Network Element Integrates Gate with Network Elements” describes the architecture that distinguishes these to roles. Core The Core maintains distributed information, thus supporting highly responsive and reliable operations. Distributed algorithms are used to maintain a consistent system state, thereby providing a degree of “loca - tional independence”. The core server maintains dynamic service - specific and connection - specific information on both ,authenticated and nonau - TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. C LOUD A RCHITECTURE 133 thenticated entities. It manages local caches, providing minimal latency delay. Global correctness is preserved through locking and hashing algo - rithms. Dedicated hardware supports this repository of global information, which can be deployed on one or several machines, either at a single loca - tion or distributed through networking. The Core contains both dynamic data and persistent information. Dynamic data is rapidly changing as it reflects the state of all cloud - sup - ported connections. It includes substantial authentication data necessary for strong authentication of user sessions. Maintaining global correctness for all of this data exceeds the capabilities of commercially available LDAP servers, yet is nevertheless essential for active directories and closely tied access control and usage recording. Resolving the problem through highly optimized code, the system caches the relevant state upon establishment of a secure session, and the state is maintained for the duration of the user’s connection to the network. The Core also maintains persistent information about accounts (users and services), recent usage records, and stored cryptographic credentials: • Registration database. This associates a uniquely numbered billable entity with each individual account, user or service. Data for the billable entity includes the user’s name, address, point of contact, and other pertinent account information Usage Database. Operating as a nonrepudiation service, the usage database retains the details of an account’s resource usage • Authentication base. Secure services and transport utilize crypto - graphic keys, X.509 certificates, passwords and associated informa - tion. These are retained in a structured authentication base and are protected by the security perimeter • Store A store implements services dealing with maintenance, provisioning, and daily use of the system. This includes white and yellow pages directory functions, customer care, billing, e - mail, voice mail, and paging messaging. It also covers such related databases as customer contact and tracking, archival usage records, billing histories, and historical network logs. 5.1.4 POP Based Authentication and Aggregation The combination of gates, cores and stores forms the POP, which provides an access point and service point, as shown previously in Figure 5 - 3. This provides multiple gran - ularities of network connectivity and authentication services. The finest granularity is an individual subscriber. The individual subscriber registers an identity with the cloud TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 134 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT and then authenticates directly to the cloud for access to both subscriber - hosted ser - vices and cloud - supported services. At a coarser grain, the POP supports externally hosted aggregation services typically operated by an aggregation provider. The provider is a corporate entity, whereas the services are the “electronic commodity” available through the provider. The aggrega - tion service combines the traffic of many subscribers. Aggregation services are config - urable through the aggregation provider, an entity that operates a pool of modems or LAN connections and provides value - added services to its subscribers. The provider registers subscribers, accepts responsibility for their activities, and supports an authentication method. Standard authentication support includes RADIUS, NAT - based Web - browser access, and Microsoft internetworking. The aggregation server passes the composite traffic to the POP, where the users receive services in accordance with access permissions of the aggregation provider. Aggregation by Internet Service Providers (ISPs) supports public use of cloud services, for example through bulk sale of services. The SPOP allows administration as well as “branding” of an ISP’s service. A corporate enterprise, by way of contrast, receives spe - cialized and private aggregation. The enterprise augments existing corporate services through cloud - managed services available to authorized employees. Attractive ele - ments of these models include the preservation and extension of existing logon identi - ties and their associated business relationships. In summary, the POP interacts closely with cloud security structure. Consider the example of a dial - up service building upon the RADIUS authentication server common to corporate and public networks. These servers may authenticate their users with the RADIUS server and proxy software of the cloud, thereby leveraging the provider’s exist - ing infrastructure. This specifically includes RADIUS as an authentication mechanism to obtain cloud access, and also RADIUS authentication as a supported cloud service provided to other authentication platforms. Both of these leverage the existing infra - structure to support rapid construction of scalable and reliable services. 5.2 Small Cloud – Development and Providers A small cloud (see Figure 5 - 4) supports the complete functionality of a smart network, including routing, authentication, access control and proxies. When such a cloud is connected to the backbone network, we call it a service node (SNode). SNode users may obtain membership in supported services, security protection, and other essential services. The architecture is suitable for small - scale (entry - level) providers of either networks or consumer services, and it provides a scalable approach for services devel - opment. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. S MALL C LOUD: D EVELOPMENT AND P ROVIDERS 135 Within this small SNode, all secure information resides on a single core server (labelled coredb in the figure). Essential cloud services run on the storel machine and pro - vide web server, mail and key applications. This cloud shows one external gate (gate2 . vanecek. com) connecting the “insecure” internet with the cloud and ser - vices. The gate supports all standard services, including authentication, access control, and submission or retrieval of usage information. The gate supports Internet stan - dards including routing and DNS. Figure 5 - 4: Single - Gate Cloud with Centralized Store The reader will notice special “virtual IP address” named cloudvip.This protects the internal cloud address, insulates the users from the internal network dependencies and variabilities of a distributed network, and also provides a means by which the cloud can provide subscriber - specific services. The cloudvip name is advertised by the domain name service (DNS) running on the gate. The gates determine the services that will be provided to all internally - bound connections. The gate may route the con - nection to a cloud component, and may also proxy the connection when appropriate. Protection of the cloud’s internal addresses is not inappropriate. A user should never directly address core services. The core is only addressable from inside the cloud, where it provides service to cloud components and systems management. This mecha - nism not only protects the core, but permits resolution of cloudvip to different addresses in a multiple - gate environment, and is one means of load balancing. The small cloud of Figure 5 - 4 can grow by adding more gates, stores, or network adapt - ers. Figure 5 - 5 shows an SNode with three edge connections. This leads incrementally to the construction of larger service nodes. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... basic middleware runs unaltered on clouds of different sizes Software-based services retain the same API interfaces The platform middleware supports these APIs through large-scale versions of the underlying components, as well as through platform-managed extensions These extensions augment and combine components through middleware techniques described in Chapter 9 Figure 5-6: Logical View of a Large Middleware. .. as discussed in Chapter 9 Transport Integration of IP Multicast and tunneling protocols with the cloud middleware functions This improves scalability and supports virtual private network functions with efficient network-level technologies TEAM LinG - Live, Informative, Non-cost and Genuine! 143 144 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT 5.5.2.3 DNE Behavior The SNodes obtain DNE services... networks A Service POP (SPOP) extends the POP through a gateway TEAM LinG - Live, Informative, Non-cost and Genuine! 146 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT Figure 5-10: Networks Scale with Multiple Autonomous Domains function to the backbone network, as well as middleware layer service logic The SPOP gateway includes routers and switches; highly efficient SPOPs utilize a distributed... and access control mechanisms One benefit of this is a single-sign-on (SSO) capability SSO addresses many TEAM LinG - Live, Informative, Non-cost and Genuine! 154 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT Figure 6-1: Architecture of Middleware System Security common security concerns, ranging from such practical issues as user convenience to evaluation of security threats: TEAM LinG - Live,... pathologies This is quite important in the design and development of reliable systems The relatively large error rate and the unpredictable error model guarantee an effective “stress test” of the network middleware The actual test environment presents fault scenarios not found in simulated testing Although network engineers frequently use fault simulators (such as the TAS®) to understand system behavior... characteristics of the path It is very difficult in standard IP to make the association between data flows and the application to which they belong TEAM LinG - Live, Informative, Non-cost and Genuine! 140 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT This gives rise to one of the most difficult aspects of implementing an end-to-end resource allocation policy in a network environment To run properly,... controlled via either a custom protocol, or a standard protocol The DNE adapts to standard switch protocols including Virtual Switch Interface (VSI) and TEAM LinG - Live, Informative, Non-cost and Genuine! 142 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT Figure 5-8: Distributed Network Element (DNE) General Switch Management Protocol (GSMP, RFC-2297) It interacts, for example, with Cabletron’s Smart Switched...136 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT Figure 5-5: Small SNode Composed of Three Gates and One Core 5.3 Large Service Node Cloud, the SNode The SNode architecture scales to very large sizes... extensions augment and combine components through middleware techniques described in Chapter 9 Figure 5-6: Logical View of a Large Middleware Service Node 5.4 Distributed Network Cloud (GuNet) The networking middleware also runs on a rather surprising configuration utilizing the public Internet as the connection between the gate and core components Known as GuNet, the gates are geographically distributed at... perimeter through a dynamic rules-based firewall, authentication mechanisms and the optional DNE The gate provides access-controlled routing at the kernel layer At the application layer, the gate executes middleware service logic Global system information resides within the security perimeter, through the logical core This including dynamic tables and persistent databases; in particular the domain database . LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. C HAPTER 5 Cloud Architecture. LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 128 M IDDLEWARE N ETWORKS: