Networking Objectives Part 5

SMK N 1 GEMPOL : Networking Objectives Part 5

Layer 5
Layer 5 is not used in every protocol. It is where instructions for pacing and load balancing of different clients will occur, as well as where sessions are established. As I mentioned previously, the TCP protocol handles session establishment at Layer 4, and the UDP protocol doesn’t really have sessions at all.

To make matters more confusing, the TCP/IP telnet and FTP protocols, for example, tend to handle the session maintenance as Layer 7 application data, without a separate Session Management layer. These protocols use Layer 4 to make the connection and then handle elements such as username and password verification as application information.

Some protocols such as SNA can use a real Session Layer that operates independently from the Transport Layer. This ability to separate the layers, to run the same Session Layer protocol over a number of possible Transport Layers, or to build applications that have different options for session control, is what makes it a distinct layer.

Layer 6
The Presentation Layer, Layer 6, is also not universally used. In some cases, a data stream between two devices may be encrypted, and this is commonly handled at Layer 6. But encryption can also be done in some systems at Layer 2, which is generally more secure and where it can be combined with data compression.

One common usae of Layer 6 is in an FTP file transfer. It is possible to have the protocol interpret the data as either 7-bit or 8-bit characters. Similarly, some terminalemulation systems use ASCII characters, while others use EBCDIC encoding for the data in the application payload of the packet. Again, this is a Layer 6 concept, but it might not be implemented as a distinct part of the application protocol. In many cases, conversions like these are actually made by the application and then inserted directly into Layer 4 packets. That is to say, a lot of what people tend to think of as Layer 6 concepts are not really distinct protocols. Rather, they are implementation options that are applied at Layers 4 and 7.

Layer 7
And, finally, Layer 7 is called the Application Layer. This is where the contents of your email message or database query live. The Application Layer is really the point of having a network in the first place. The network needs to get information efficiently from one place to another. The Application Layer contains that information.

Maybe it needs to be chopped up into several packets, maybe it needs to be translated into some sort of special encoding scheme, encrypted and forwarded through 17 different types of boxes before it reaches the destination. But ultimately the information gets there. This information belongs to Layer 7.

»

Networking Objectives Part 4

SMK N 1 GEMPOL : Networking Objectives Part 4

Layer 3

The Network Layer includes the IP part of TCP/IP. This is where the IP address lives. The Network Layer specifies how to get from one data-link region to another. This is called routing. See the next section on “Routing Versus Bridging” for a more detailed description of what routing means.

There are several other Network Layer protocols besides IP. One of the most popular for LANs is called IPX, which forms the basis of the Novell Netware NOS (Network Operating System). However, IPX can also be used by other systems including Microsoft Windows and Linux.

As an aside on the subject of the OSI model, it is quite common to use both IP and IPX simultaneously on the same network, over the same physical-layer equipment. But what’s particularly interesting is that they don’t have to use the same Data Link Layer protocol for their framing. Usually IP packets are framed using the Ethernet II data link layer. Meanwhile, IPX usually uses IEEE 802.2 with 802.3 Ethernet framing.There are several subtle differences between Ethernet II and 802.2, and it would certainly not be possible to run an IP network using both simultaneously on the same segment. But it is quite common to configure all of the devices on the network to expect their IP frames in one format and IPX in a different format.

Layer 4
At Layer 4, things become still more abstract. The IP protocol has two main transport- layer extensions, called TCP and UDP. TCP, or Transmission Control Protocol, is a connection-oriented protocol. This means that it forms end-to-end sessions between two devices. It then takes care of maintaining this session, keeping packets in order and resending them if they get lost in the network. For this reason, TCP is not useful for one-to-many or many-to-many communication. But it is perfect for building applications that require a user to log in and maintain a connection of any kind. A TCP session has to begin with a session negotiation that sets up a number of communications parameters such as packet size. At the end, it has to be torn down again. UDP, or User Datagram Protocol, is connectionless. It is used for applications that just send one packet at a time without requiring a response. It is also used by applications that want to maintain their own connection, rather than using TCP. This can be useful if a server needs to support a large number of clients because maintaining connections with TCP can be resource-intensive on the server. In effect, each UDP packet is a complete session. UDP is also useful for multicast type applications or for applications where the data is time sensitive, so retransmitting a packet is worse than dropping it.

TCP, being a connection-oriented protocol, is inherently reliable. It ensures that all data sent from one end to the other gets to its destination intact and in the right order. UDP, on the other hand, is inherently unreliable. This doesn’t mean it’s bad; it just means that the application has to make sure that it has received all of the data it needs. The other important thing that happens at Layer 4 is the differentiation between different application streams. In both TCP and UDP (as well as in IPX/SPX at the same layer) there is a concept called a port. This is really nothing more than a number. But it is a number that represents an application. For an application to work, there has to be not only something to send information, but also something on the other end to listen. So a server will typically have a program running that listens for incoming packets on a particular port (that is, packets that have the appropriate number in the port-number part of the packet).

The network also cares about port numbers because it is an easy way to differentiate between different applications. The port number can be used to set priorities so that important applications can pass through the network more easily. Or the network can reject packets based on port number (usually for security reasons, but sometimes just to clean up artificially for ill-behaved application chatter).

»

WAN Optimization White lists and Blacklists

SMK NEGERI 1 GEMPOL : WAN Optimization White lists and Blacklists

I've been working on a survey of best practices for acquiring WAN optimization solutions; it'll appear as a Burton Group paper and also be used as the basis for a talk at the upcoming Burton Group Catalyst Conference on July 27-31 in San Diego. It's been fun to talk to folks about what worked and what didn't work in their efforts to bring WAN optimization technology into their enterprises.

The papers and speech won't be out for another month or so, but meanwhile there's a very important point about this technology that I want to get out here: Yes, optimization is a fantastic way of saving money and creating really happy customers at the same time, but it doesn't work flawlessly for all applications.

The advanced dictionary-based compression component seems to be foolproof; it works and saves you, oh, 50% and up of your bandwidth at the same time that it usually makes a major improvement in performance that'll have the users loving you. So networking organizations that are primarily concerned with saving bandwidth expense and that dread having to work with users or application developers will usually choose optimization devices that are almost purely compression-based, and that don't fiddle much, or at all, with the protocols. They'll get a lot of performance improvement also -- especially if the same files are sent back-and-forth across the network with minor changes, or if they contain internal duplications, or if there's a lot of commonality among files -- and they'll never break an application, no matter how badly it's programmed.

But some enterprises really need the massive performance improvements that WAN optimization can provide for some common situations, such as access to remote fileshares using the Microsoft CIFS or Unix NFS protocols, or applications using SQL queries, or web browsers, or email. For those situations, fiddling with ("accelerating" or "spoofing") the underlying TCP, file, and application protocols can create simply unbelievable improvements in the performance seen by end users. But when the WAN optimization device starts interacting with protocols, some applications will break. It's almost never the optimization device's fault, because the optimizer engineers are experts in the protocols and carefully design their devices to squeeze every bit out of them without violating the protocol standards. But a surprising number of enterprise programmers don't know those standards very well.

The result is that protocol acceleration typically works flawlessly for broadly-used applications, such as access to remote fileshares by Excel, or use of web browsers, or SharePoint. But weird, custom-built client-server applications with embedded TCP socket calls that were built by overworked programmers under horrible deadline pressure who have no previous experience with TCP or other protocols? Well, that explains the "your accelerator broke my application" telephone calls. Truth is, the application was already broken, but its failures were usually rather rare and were attributed to "cosmic rays" or similar nonsense. When the optimizer starts really exercising the protocol, however, the breaks in the protocol become more obvious, and the irate telephone calls start.

And that brings me to the point of this blog entry: most enterprises quickly find that whitelists are wonderful tools for managing WAN optimization. They use whitelists to tell the optimizers which applications should be given protocol acceleration in addition to advanced compression. Applications that aren't on the whitelist are compressed, but their protocols are passed through the optimzers unchanged. At initial rollout, the network organization puts broadly-used applications, such as Excel, Internet Explorer and SharePoint, on the whitelist. Then, as time goes by, additional applications can be tested and added to the whitelist. By using whitelists, all of those weird applications that you didn't even know existed will not get into trouble. (By the way, organizations that try blacklists usually find that they have dozens, or hundreds, of applications that they didn't know about and that have mistakes in their use of TCP or other protocols. They find that out as a result of enraged telephone calls from the applications' users. Use whitelists instead.)

Some WAN optimization vendors have extensive deep packet inspection systems that can help in creating whitelists, but that's not truly necessary in all cases. Just filtering by IP address, hostname, or similar simple mechanisms may be all that you need.

So: don't fear optimization! You can save buckets of money and make your customers happy at the same time! But use whitelists when you do that rollout

»

Networking Objectives Part 3

SMK N 1 GEMPOL : Networking Objectives Part 3
Layer 1

The Physical Layer is at the bottom. This includes the parts of the network that you can see, such as cables, patch panels, jacks, and optical fibers. Specifications for the Physical Layer have to do with the differences between categories of cables, the wavelength properties of optical fibers, the length restrictions, and electrical specifications. This is extremely important stuff, but most network designers only think about it briefly when they do the cable plant. Other physical-layer issues, such as laser intensity, wavelength characteristics, attenuation, and so on, are important to engineers who design the equipment and cables. But for the network design they appear only in decisions to match the specifications of different pieces of hardware and cabling.

Layer 2
The Data Link Layer is where things start to get a bit more abstract, so some examples might help. This layer is where the difference between Ethernet, Fast Ethernet, and Token Ring exists. It includes all of the specifications about how to build a packet. It describes how the different nodes on this network avoid contention using collisions or token passing or perhaps some other algorithm. For broadcast media (as opposed to point-to-point media where you know that if you send out a packet, it can only be received by one other device), it defines how to actually specify for which device or devices the packet is destined.
Before going on, let me point out the ways that these first two layers are both connected and separable. For example, you have a certain physical layer, such as Category 5 twisted pair cabling. Then, when you decide to run Ethernet over this physical medium, you are constrained to use a particular type of signaling that works with this medium. It is called 10BaseT. There are other types of Ethernet signaling, such as 10Base2. In this case, though, you would have to use coaxial cable designed to have 50 Ω (ohm) characteristic impedance. But, over this twisted pair cabling, you could just as easily run Token Ring. Or, if you are working with Token Ring, you could choose instead to use Type 3 shielded cabling.
The point is that Ethernet means a particular way of forming packets and a particular way of avoiding contention (collisions). It can run over many different types of physical media. Going up the protocol stack, the same is true at each layer. You can run TCP/IP over Ethernet, or over Token Ring, ATM, or FDDI, or over point-topoint circuits of various descriptions. At each layer there is a set of specifications on how to get to the layer below. You can think of this specification as being the line between the layers of the stack. So the line between the Physical Layer and the Data Link Layer includes 10BaseT, 100BaseFx, and so forth. Strictly speaking, these distinctions are described in sublayers of the standard OSI model. The IEEE provides detailed specifications of these protocols..

»

Astra Group Commemorates National Education Day and Inaugurates Astra

Astra Group Commemorates National Education Day and
Inaugurates Astra - Michael D. Ruslim Education Foundation

JAKARTA (May 18, 2010): Today, PT Astra International Tbk ("Astra") commemorated the National Education Day at Taman Mini Indonesia Indah ("TMII") Jakarta and at the same time officially announced the name change of Astra Bina Pendidikan Foundation (YABP) to Astra - Michael D. Ruslim Education Foundation (YPA-MDR).

The event saw the attendance of the country´s Deputy Minister of Education Fasli Jalal; representative of North Jakarta Mayor Bambang Sugiyono together with officials of Provincial Executive Council (Muspida) and Sub-District Executive Council (Muspika) of Tanjung Priok; representative of Bogor Regent Rachmat Yasin plus Muspika and Muspida officials of Leuwiliang; Boards of Commissioners, Directors, and Executives of Astra Group companies; principals and teachers of Astra-supervised schools; recipients of Astra scholarships; as well as winners of National Education Day competitions. A series of Astra´s Corporate Social Responsibility ("CSR") achievements in education sector were also presented at the event.

As a socially responsible public company that upholds its corporate philosophy Catur Dharma, Astra treats education as the top priority in its CSR programs. Astra is actively involved in education sector, taking part in fulfilling one of the nation´s dreams of independence: "to educate the nation."
Astra´s initiatives in education sector all these years have been implemented through its subsidiaries and its five education foundations. All the initiatives are long term programs, such as:

1. Toyota-Astra Foundation (YTA), founded in 1974 with focus in scholarship provision for students at all levels of study (from elementary school to university), provision of mock-ups and cultural assistance;
2. Astra Bina Ilmu Foundation (YABI), established in 1995, running Astra Manufacturing Polytechnic ("Polman Astra") - offering subsidized diploma program and scholarships to outstanding students;
3. Astra Honda Motor Foundation (YAHM), set up in 1995, providing local content education to Technical High School/Vocational High School students, mock-ups/engines and scholarships;
4. Astra Bina Pendidikan Foundation (YABP), came to existence in 2005, active in educational program development in less privileged or disadvantaged areas, currently has a number of public schools under its supervision: 5 SDNs (elementary schools) and 2 SMPNs (junior high schools) in Leuwiliang, Bogor; 6 SDNs and 1 SMPN in Gunung Kidul and 3 SDNs in Bantul with various national accreditations;
5. Karya Bakti United Tractors Foundation (YKBUT), set up in 2008, active in supplying subsidized mechanics and operators, engaged in collaboration with 100 Vocational High Schools (SMKs) across Indonesia.

Astra Bina Pendidikan Foundation (YABP) which has been renowned for its extensive role in providing assistance to schools in disadvantaged areas, today officially bears a new name "Astra - Michael D. Ruslim Education Foundation". The new name is meant as a tribute to the late Michael D. Ruslim who was well known for his profound concern for Astra´s CSR activities in education sector during his term of office as Astra President Director and who always attended inauguration ceremonies of Astra education projects in all corners of the country.

The development of Astra´s particular CSR program in education sector has been in line with the concept of Millennium Development Goals (MDGs), which puts emphasis on Achieving Primary Education and Developing Education Projects that are integrated in three aspects: Software (development of education modules, learning models, curriculum, and soft skills); Brainware (provision of scholarships for students from elementary to tertiary levels as well as for teachers and lecturers, plus enhancement of teacher competence and school management), and Hardware (construction or renovation of school buildings and provision of education facilities such as laboratories).

The different CSR programs carried out by Astra Group are based on a Triple Bottom Line approach, namely balancing between economic growth (profit), environment (planet), and society (people). Each of the Group´s subsidiaries is required to balance these three elements. "Basically, wherever Astra companies or branches exist, they have to offer added value to the surrounding communities and environment. This concept is consistent with Astra´s philosophy - To Become an Asset to the Nation, and Astra´s corporate aim - To Prosper with the Nation," revealed Astra President Director Prijono Sugiarto.

Astra Group also conducted numerous activities during the commemoration of the National Education Day 2010, among others:

1. Symbolic presentation of scholarships to teachers as well as students of elementary, junior high, and high school levels by Astra (1000 students), United Tractors (406 students), YTA (1320 students), and YABP (37 teachers);
2. Symbolic handover of computer donation (50 computers) to elementary, secondary, and high schools in North Jakarta;
3. Presentation of renovation assistance for 2 Early Childhood Education (PAUD) facilities in North Jakarta;
4. Presentation of 1 Mobile Learning Unit by PT Toyota Astra Motor;
5. Symbolic handover of 54 Honda motorcycles by PT Astra Honda Motor;
6. Inauguration of Daihatsu Mobile Library Unit by PT Astra Daihatsu Motor;
7. Presentation of prizes to winners of Astra Photo Competition 2010 with the theme, "The Portrait of Optimism towards Education in Indonesia" for Public and Journalist categories;

In addition, a string of competitions were launched on the occasion such as Kite Painting competition (for elementary school students), Mural Painting competition (for high school students), Traditional Dance competition (for elementary school students), and Modern Dance competition (for high school students).

The National Education Day was also simultaneously commemorated by all Astra subsidiaries and their branches across Indonesia ("Astra Group") with a variety of educational programs involving their surrounding communities.

Jakarta, 18 May 2010

Arief Istanto
Chief of Corporate Communications

»

Networking Objectives Part 2

SMK N 1 GEMPOL : Networking Objectives Part 2

OSI Protocol Stack Model

No book on networking would be complete without discussing the Open System Interconnection (OSI) model. This book is more interested in the lower layers of the protocol stack. One of the central goals of network design is to build reliable networks for applications to use.So a good design starts at the bottom of the stack, letting the upper layers ride peacefully on a stable architecture. Software people take a completely different view of the network. They tend to be most concerned about the upper layers, from Layer 7 down to about Layer 4 or 5. Network designers are most concerned with Layers 1 through 4 or 5. Software people don’t care much about cabling, as long as it doesn’t lose their data. Network designers don’t care much about the data segment of a packet, as long as the packet meets the standard specifications. This fact alone explains much of my bias in focusing on the lower parts of the stack. There are excellent books on network programming that talk in detail about the upper layers of the stack. That is largely beyond the scope of this book, however.

The Seven Layers

The OSI model is a useful way of thinking about networking. It’s important not to confuse it with reality, of course. The most commonly used networking protocols, such as TCP/IP, don’t completely match the model. But it is still a useful model.

Table 1-1 shows this simple model in its usual form.

»

Networking Objectives Part 1

SMK N 1 GEMPOL : Networking Objectives Part 1

The American architect Louis Henry Sullivan described his design philosophy with the simple statement “form follows function.” By this credo he meant that a structure’s physical layout and design should reflect as precisely as possible how this structure will be used. Every door and window is where it is for a reason.

He was talking about building skyscrapers, but this philosophy is perhaps even more
useful for network design. Where building designs often include purely esthetic features to make them more beautiful to look at, every element of a good network design should serve some well-defined purpose. There are no gargoyles or frescos in
a well-designed network.

The location and configuration of every piece of equipment and every protocol must
be carefully optimized to create a network that fulfills the ultimate purposes for which it was designed. Any sense of esthetics in network design comes from its simplicity and reliability. The network is most beautiful when it is invisible to the end user.

So the task of designing a network begins with a thorough study of the required functions. And the form will follow from these business requirements.

Business Requirements
This is the single most important question to answer when starting a network design: why do you want to build a network? It sounds a little silly, but frequently people seem confused about this point. Often they start building a network for some completely valid and useful reason and then get bogged down in technical details that have little or nothing to do with the real objectives. It is important to always keep these real objectives in mind throughout the process of designing, implementing, and operating a network.

Too often people build networks based on technological, rather than business, considerations. Even if the resulting network fulfills business requirements, it will usually be much more expensive to implement than is necessary.

If you are building a network for somebody else, then they must have some reason why they want this done. Make sure you understand what the real reasons are. Too often user specifications are made in terms of technology. Technology has very little to do with business requirements. They may say that they need a Frame Relay WAN, or that they need switched 100Mbps Ethernet to every desk. You wanted them to tell you why they needed these things. They told you they needed a solution, but they didn’t tell you what problem you were solving.

It’s true that they may have the best solution, but even that is hard to know without understanding the problem. I will call these underlying reasons for building the network “business requirements.” But I want to use a very loose definition for the word “business.” There are many reasons for building a network, and only some of them have anything to do with business in the narrow sense of the word. Networks can be built for academic reasons, or research, or for government. There are networks in arts organizations and charities. Some networks have been built to allow a group of friends to play computer games. And there are networks that were built just because the builders wanted to try out some cool new technology, but this can probably be included in the education category.

What’s important is that there is always a good reason to justify spending the money. And once the money is spent, it’s important to make sure that the result actually satisfies those requirements. Networks cost money to build, and large networks cost large amounts of money.

So the first step in any network design is always to sit down and list the requirements. If one of the requirements is to save money by allowing people to do some task faster and more efficiently, then it is critical to understand how much money is saved.

Money is one of the most important design constraints on any network. Money forms the upper limit to what can be accomplished, balancing against the “as fast as possible” requirement pushing up from below. How much money do they expect the network to save them? How much money do they expect it will make for them? If you spend more money building this network than it’s going to save (or make) for the organization, then it has failed to meet this critical business objective. Perhaps neither of these questions is directly relevant. But in that case, somebody is still paying the bill, so how much money are they willing to spend?

Geography is the second major requirement to understand. Where are the users?
Where are the services they want to access? How are the users organized geographically?
By geography I mean physical location on whatever scale is relevant. This book’s primary focus is on Local Area Network (LAN) design, so I will generally assume that most of the users are in the same building or in connected building complexes. But if there are remote users, then this must be identified at the start as well. This could quite easily spawn a second project to build a Wide Area Network (WAN), a remote-access solution, or perhaps a Metropolitan Area Network (MAN). However, these sorts of designs are beyond the scope of this book. One of the keys to understanding the local area geography is establishing how the users are grouped. Do people in the same area all work with the same resources? Do they need access to the same servers? Are the users of some resources scattered throughout the building? The answers to these questions will help to define the Virtual LAN (VLAN) architecture. If everybody in each area is part of a self-contained work group, then the network could be built with only enough bandwidth between groups to support whatever small amounts of interaction they have. But, at the opposite extreme, there are organizations in which all communication is to a centralized group of resources with little or no communication within a user area. Of course, in most real organizations, there is most likely a mixture of these extremes with some common resources, some local resources, and some group-to-group traffic.

Installed Base
The next major business requirement to determine is the installed base. What technology exists today? Why does it need to be changed? How much of the existing infrastructure must remain? It would be extremely unusual to find a completely new organization that is very large, has no existing technology today, and needs it tomorrow. Even if you did find one, chances are that the problem of implementing this new technology has been broken down among various groups. So the new network design will need to fit in with whatever the other groups need for their servers and applications. Installed base can cause several different types of constraints. There are geographical constraints, such as the location and accessibility of the computer rooms and LAN rooms. There may be existing legacy network technology that has to be supported. Or it may be too difficult, inconvenient, or expensive to replace the existing cable plant or other existing services. Constraints from an existing installed base of equipment can be among the most difficult and frustrating parts of a network design, so it is critical to establish them as thoroughly and as early as possible.

Now that you understand what you’re connecting and to where, you need to figure out how much traffic to expect. This will give the bandwidth requirements. Unfortunately, this often winds up being pure guesswork. But if you can establish that there are 50 users in the accounting department who each use an average of 10kbps in their connections to the mainframe throughout the day, plus one big file transfer at 5:00 P.M., then you have some very useful information. If you know further that this file transfer is 5 gigabytes and it has to be completed by 5:30, then you have another excellent constraint. The idea is to get as much information as possible about all of the major traffic patterns and how much volume they involve. What are the expected average rates at the peak periods of the day (which is usually the start and end of the day for most 9–5 type operations)? Are there standard file transfers? If so, how big are they, and how quickly must they complete? Try to get this sort of information for each geographical area because it will tell you not only how to size the trunks, but also how to interconnect the areas most effectively.

In the end it is a good idea to allow for a large amount of growth. Only once have I seen a network where the customer insisted that it would get smaller over time. And even that one got larger before it got smaller. Always assume growth. If possible, try to obtain business-related growth projections. There may be plans to expand a particular department and eliminate another. Knowing this ahead of time will allow the designer to make important money-saving decisions.

Last among the top-level business requirements is security. What are the security requirements? This is even important in networks that are not connected to anything else, like the Internet or other shared networks. For example, in many organizations the servers in the Payroll Department are considered sensitive, and access is restricted. In investment banks, there may be regulations that require the trading groups to be separate from corporate financing groups. The regulatory organizations tend to get annoyed when people make money on stock markets using secret insider information.

The relationship between security and geography requirements may make it necessary to implement special encryption or firewall measures, so these have to be understood before a single piece of equipment is ordered.

Philosophical and Policy Requirements
Besides the business requirements, there could be philosophical requirements. There may be a corporate philosophy that dictates that all servers must be in a central computer room. Not all organizations require this, but many do. It makes server maintenance and backups much easier if this is the case. But it also dictates that the network must be able to carry all of the traffic to and from remote user areas. There may be a corporate philosophy that, to facilitate moves, adds, and changes, any PC can be picked up and moved anywhere else and not require reconfiguration.

Some organizations insist that all user files be stored on a file server so that they can be backed up. Make sure that you have a complete list of all such philosophical requirements, as well as the business requirements, before starting.

»