`
`TIMO IY RAMTEKE
`
`TIIT
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 1 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`i11277y)
`
`aBS)
`
`NETWORKS
`whslr)
`Timothy Ramteke
`
`bsrsnh notsborotibaseigsoeM
`oDnobauborg
`IO ctor svo
`
`boregwrofto 9Xleoihar.dguorti
`
`X-Pa062e-EL-0 M82I
`
`***
`
`Paramount
`
`sogailt lloaotar
`Prentice Hall Career and Technology
`tatl-stinet
`Englewood Cliffs, New Jersey 07632
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 2 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`Library ofCongressCataloging-in-Publication Data
`
`Ramteke, Tiimothy.
`Networks / Timothy Ramteke.
`cm.
`p.
`Includes bibliographical
`ISBN 0-13-958059-X
`1. Telecommunication.
`TKS101.R36 1994
`004.6--dc 20
`
`references and index.
`
`I. Title.
`Computer networks.
`93-41893
`
`CIP
`
`Acquisitions Editor: Holly Hodder
`Editorial Assistant: Melissa Stefens
`Marketing Manager: Ramona Baran
`Managing Editors/production: Mary Carnis and Patrick Walsh
`Director of ProductionServices: David Riccardi
`Production Coordinator: Ilene Levy Sanford
`Cover Design: Laura lerardi
`Cover Photo: courtesy of Charles Becker ©1992
`
`© 1994 by Prentice Hall Career and Technology
`Prentice-Hall, Inc.
`A Paramount Communications Company
`Englewood Cliffs, New Jersey 07632
`
`tediously, every effort was made to ensure the integrity of this text, the publisher
`Although,
`assumes no responsibility for errors, or for damages incurred from using its information.
`
`All rights reserved. No part of this book may be
`reproduced, in any form or by any means,
`without permission in writing from the publisher.
`
`Printed in the United States of America
`10
`9
`8
`7
`6
`5
`4
`3
`2
`1
`
`ISBN 0- 13-958059-X
`
`Prentice-Hall International (UK) Limited, London
`Prentice-Hall of Australia Pty. Limited, Sydney
`Prentice-Hall Canada Inc., Toronto
`Prentice-Hall Hispanoamericana, S.A., Mexico
`Prentice-HallofIndiaPrivateLimited,New DelhiDE
`Prentice-Hall ofJapan, Inc., Tokyo
`Simon & Schuster Asia Pte. Ltd., Singapore
`Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro
`
`atla
`boonalena
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 3 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`1
`10
`22
`42
`
`58
`74
`88
`118
`142
`164
`191
`
`213
`245
`267
`292
`
`325
`359
`384
`430
`
`Overview
`
`PARTI:FUNDAMENTALS
`Welcome to Telecommunications
`Network Architectures and OSI
`Analog and Digital Signals
`Transmission Systems
`
`1.
`2.
`3.
`4.
`
`PART II: VOICENETWORKING
`
`5.
`6.
`7.
`
`Signaling
`Switching
`The Public Switched Telephone Network
`Private Switching Networks
`Voice Processing and Call Distribution
`.
`10. TI Networking
`11. Virtual Networks
`
`89
`
`PART III: WIDEAREANETWORKS
`
`12. SNA
`13. X.25 and Packet Switched Networks
`14.
`Signaling System 7
`15.
`ISDN and SONET
`
`PART IV:LANSandINTERNETWORKING
`
`LANS
`16.
`17. NetWare
`18.
`Interconnecting LANS
`19.
`TCP/IP
`iv
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 4 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`Contents
`
`PARTI:FUNDAMENTALS
`
`1
`
`10
`
`1222339IWJNTł0
`
`S0WTa
`
`TAR2 3HTL 22
`
`811 OW3040Xke L8
`
`42
`
`1. Welcome to Telecommunications
`1.l HISTORICAL SURVEY 1
`1.2 HANDLING OF CALLS 3
`1.3 STANDARDS
`6
`2. Network Architectures and OSI
`2.1 WHAT IS A NETWORK?
`10
`2.2 WHY NETWORK?
`11
`2.3 NETVWORK ARCHITECTURES 11
`2.4 OSI 15
`3. Analog and Digital Signals
`3.1 DC CIRCUITS 22
`3.2 ANALOG SIGNALS 25
`3.3 MULTIPLEXING 29
`3.4 POWER 30
`3.5 CODING AND ADDRESSING 33
`3.6 SYNCHRONIZATION 34
`3.7 INFORMATION ENCODING 36
`4. Transmission Systems
`4.1 INTRODUCTION 42
`4.2 TWISTED PAIR 42
`4.3 COAX 43
`44 FIBER 44
`4.5 SHORT-HAUL SOLUTIONS 47
`4.6 SATELLITES 48
`4.7 PREMISES DISTRIBUTION S1
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 5 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`4.8 TRUNK TYPES 52
`4.9 DIGITAL CARRIERSYSTEMS 54
`4.10 LONG DISTANCE SERVICES 55
`
`PARTII:VOICENETWORKING
`
`5. Signaling
`5.1 WHAT IS SIGNALING? 58
`5.2 STEPS TAKEN IN PLACING A CALL 58
`5.3 TYPES OF SIGNALING FORMATS 60
`5.4 SIGNALING DELAYS AND INTEROFFICE SIGNALING 60
`5.5 KINDS OF ADDRESS SIGNALING 62
`5.6 SIGNALING TYPES PROVIDING SUPERVISION 64
`5.7 DIGITAL CARRIERSYSTEMS 68
`5.8 SIGNALING INTERFACES 69
`6. Switching
`6.1 BASIC SWITCHING 74
`6.2 METHODS OF CONTROL 77
`6.3 DIGITAL SWITCHING 80
`6.4 ADVANCED SWITCHING CONCEPTS 83
`7. The Public Switched Telephone Network
`7.1 BACKGROUND 88
`7.2 THE LOCAL TELEPHONE NETWORK 90
`7.3 CELLULAR MOBILE TELEPHONE SYSTEM 94
`7.4 DIGITAL WIRELESSSYSTEMS 100
`7.5 THE AT&T NETWORK 107
`7.6 THE MCI NETWORK 111
`7.7 THE SPRINTNETWORK l13
`7.8 COMPETITIVE ACCESSPROVIDERS (CAPS) l14
`8. Private Switching Networks
`8.1BACKGROUND 18
`8.2 CENTREX 118
`8.3 KEY SYSTEMS 123
`8.4 OTHER SMALL VOICE SYSTEMS 126
`8.5 EXAMPLES OF PBX FEATURES 126
`8.6 THE AT&T DEFINITY 127
`8.7 TANDEM TIE-LINE NETWORKS 134
`8.8 PRIVATE NETWORKS 134
`8.9 ARS (AUTOMATIC ROUTE SELECTION) 136
`8.10 NETWORK ROUTING 138
`
`58
`
`74
`
`20920MA 8
`
`23TD3HDAA001Y120S
`
`118
`
`vi
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 6 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`AIARO S1
`10349A8.51
`
`9. Voice Processing and Call Distribution
`9.1 INTRODUCTION 142
`9.2 METHODS OF PROVIDING SPEECH 143
`9.3 AUDIOTEXT INFORMATION SYSTEMS/PROGRAMS 144
`9.4 VOICE RECOGNITION 145
`9.5 VOICE MAIL
`147
`9.6 AUTOMATED ATTENDANTS (AAs) 148
`9.7 INTRODUCTION TO CALL DISTRIBUTION SYSTEMS 151
`9.8 OUTBOUND TELEMARKETING 154
`9.9 WHYACDS? 154
`9.10 GATES 155
`9.11 THE TIME LINE 156
`9.12 ACD FEATURES 157
`759YT T8AI8.E1
`9.13 ACD NETWORKING 158
`9.14 HOST INTERACTIVE VOICE RESPONSE (HIVR) SYSTEMS 160
`A8TM 0LEL
`Ite2paiiosol64
`10. TI Networking
`10.1 BACKGROUND 164
`10.2 ADVANTAGES 164
`10.3 TI SIGNAL TRANSMISSION 168
`10.4 FRAMING TYPES 170
`10.5 NETWORK INTERFACING 175
`10.6 TI SWITCHING 176
`10.7 NETWORK DESIGN CASE STUDY 182
`1. VirtualNetworks
`che l1.lINTRODUCTION19]
`11.2 ADVANTAGES OF VN 193
`11.3 TYPES OF ACCESS 195
`11.4 TYPES OF CALLS 199
`11.5 FEATURES 201
`11.6 CARRIER PROFILES 204
`11.7 SWITCHED DIGITAL SERVICES 207
`
`8S4UA 8191
`
`32.OTADVUMUODIEZI
`
`PART II: WIDEAREANETWORKS
`
`12. SNA
`12.1 THE SNA ENVIRONMENT 213
`12.2 SNA HARDWARE 215
`12.3 NAUS AND SESSIONS 218
`12.4 SNA ARCHITECTURE 223
`12.5 SDLC 225
`
`8S&200HTEM
`
`OAO
`
`213
`
`vii
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 7 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`12.6 THE PATH CONTROL LAYER 230
`12.7 CHAINING, PACING, AND SEGMENTING 233
`40200A
`12.8 APPC OR LU 6.2 235
`12.9 APPN 241
`AMoy2245
`13. X.25 and Packet Switched Networks
`13.1 DEVELOPMENT 245
`13.2 PURPOSE 246
`13.3 DIAL-UP LINES, LEASED LINES, AND PACKET NETWORKS 247
`13.4 PUBLIC DATA NETWORKS (PDNS) 249
`13.5 THE OPERATION OF A PACKET SWITCHED NETWORK 250
`13.6 LAP/B: THE DATA LINK LAYER OF X.25 253
`13.7 THE X.25 PACKET LAYER 254
`13.8 PACKET TYPES 256
`13.9 X.25 FEATURES AND FACILITIES 260
`13.10 INTERCONNECTING X.25 WITH IBM'S NETWORKS 261
`14. Signaling System 7
`14.1 INTRODUCTION 267
`14.2 TOPOLOGY 269
`14.3 SS7 PROTOCOL ARCHITECTURE 272
`14.4 SIGNALING UNITS 273
`14.5 MTP LEVEL-3 277
`14.6 SCCP 279
`14.7 TCAP 280
`14.8 ISUP 283
`15. ISDN and SONET
`15.1 INTRODUCTION AND BENEFITS 292
`15.2 DEFINITIONS 293
`15.3 TELECOMMUNICATIONS SERVICES 296
`15.4 PHYSICAL LAYER OF BRI 299
`15.5 THE PHYSICAL LAYER OF PRI 310
`15.6 THE DATA LINK LAYER 311
`15.7 THE NETWORK LAYER 314
`15.8 SONET 314
`
`267
`
`0245OVIMH0
`ONOHDILWZ
`
`cel23D022
`02395H0 23
`
`PART IV:LANSandINTERNETWORKING
`
`Sio2232Mb
`
`325
`
`16. LANS
`16.1 INTRODUCTION 325
`16.2 TOPOLOGIES 326
`16.3 ACCESS METHODS 328
`
`viii
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 8 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`18.
`
`16.4 SOFTWARE BASICS 330
`16.5 ETHERNET 337
`16.6 TOKEN-RING NETWORKS 344
`16.7 FDDI 352
`17. Net Ware
`17.1 SESSION MANAGEMENT 359
`17.2 SECURITY 364
`17.3 THE SYSCON UTILITY 370
`17.4 PRINTING ISSUES 374
`17.5 ESTABLISHING THE USER ENVIRONMENT 378
`Interconnecting LANS
`18.1 INTERNETWORKING DEVICES 384
`18.2 BRIDGES 389
`18.3 ROUTING PROTOCOLS 397
`184 ROUTER CONFIGURATION 407
`18.5 FAST PACKET TECHNOLOGIES 410
`18.6 FRAME RELAY 410
`18.7 SMDS 415
`18.8 ATM 419
`19. TCP/IP
`19.1 TCP/IP ARCHITECTURE 430
`19.2 UNIX 436
`19.3 APPLICATION SERVICES 440
`19.4 IP ADDRESSING 444
`19.5 EXPLORING THE EXISTING NETWORK 450
`19.6 INSTALLING A NEW SUBNET 455
`19.7 DOMAIN NAME SERVICE 459
`
`359
`
`384
`
`430
`
`ix
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 9 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`sda
`aialeotfl
`
`pilotpilotpilot
`
`Inter
`Flags
`l00
`UH
`le0
`UGHD
`le0
`UGHD
`I ontis 1el
`le0
`U
`eib alu le0
`U
`
`the first 3 octets are masked for the subnet and the
`hex. Also, notice for le0 and lel,
`last octet for the host number. The broadcast address matches correctly with how the
`subnet mask is set up, as was explained using Figure 19.10.
`If the subnet mask is set
`incorrectly,
`then a host may be able to communicate with
`hosts on its own subnet and with remote hosts, but not with hosts on other local subnets.
`on
`Shortly, we'll see how to configure a subnet mask.
`-0gitee19.5.3RoutingTables
`o
`The next thing we want to see is pilot's current routing tables. This is done using
`the netstat command with the -r option for routing. Again, let us seethe display using
`both the host and network names and their numeric addresses.
`netstat -ro
`Routing tables
`Destination
`owod Gateway
`localhost
`Localhost
`igor.rutgers.edu
`nb-gw.rutgers. edu
`lil-gw.rutgers.edu
`okapi.rutgers.edu
`default
`broad-18-0.rutgers.
`82012530iBROAD-7-0-RUTGERS.E
`Jolioo babb ởnetstat -nr
`Routing tables
`Inter
`Destination
`eiti 63 127.0.0.1
`Gateway
`127.0.0.1
`lo0
`128.6.13.26
`128.6.7.1
`le0
`128.6.11.3
`128.6.7.5
`le0
`default
`128.6.7.38
`le0
`128.6.18.0
`128.6. 18.38
`le1
`128.6.7.0
`128.6. 7.38
`le0
`Again,
`the order of the entries in these two displays is the same. From their last
`columns, we recognize our three familiar interfaces: lo0, le0, and le1. The destinations
`for the last two routes are 128.6.18.0 and 128.6.7.0. They both end with a ".0," sothese
`are routes to subnets and not to individual hosts.
`If a destination ends with a non-zero
`number,
`then it
`typically specifies a route to a host. This can also be seen by noticing
`that the H(Host) flag is set for host routes and not for subnet routes.
`As we have seen before, the last two entries are the routes to two subnets to which
`is directly connected. These entries state that
`the gateway to either of these
`pilot
`subnets is pilot. In onecase it is the le l
`interface (128.6.18.38) and in the othercase,
`it is the le0 interface (128.6.7.38). Apparently, all routes are up and running, since the
`U(Up) flag is set for them all.
`The loopback interface provides a route to the local host and it is always in the
`routing table. The default route specifies to which gateway packets must be sent if the
`route is not found in the table. This entry helps the table from becoming too long. So,
`for instance,
`if we want to send data to NIC.DDN.MIL
`(192.112.36.5), which is not
`listed in the table,
`then the data packet
`is sent
`to the default gateway to route the
`packets.
`452
`
`TCP/IP
`
`Flag
`UH
`UGHD
`UGHD
`
`UUU
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 10 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`Lastly, we come across two routes, one to iigor and one to okapi. Both of these
`u
`oL 2iroutes use remote gateways,
`that
`is, gateways connected to other subnets. This is
`indicated by the G flag being set for them. In the first case, the remote gateway which
`0k o provides access to igor is called nb-gw and in the second case, the remote gateway
`which provides access to okapi is called lil-gw. These routes also have their D flags set,
`u n meaningthattheserouteswereaddeddue to ICMPredirects.SeeSection19.1.4.
`From the display of netstat -nr, we see that the address for nb-gw is 128.6.7.1 and
`dt
`tht for lil-gw is128.6.7.5.Thismeansthatboth ofthesegatewaysareonthe128.6.7.0
`2
`subnet,which is connected to le0 of pilot. Now ourupdated network map looks like that
`shown in Figure 19.12.
`
`llso yeb
`
`d bas
`a0iaciteh
`19.5.4 Tracing Routes
`How do we know if igor and okapi are directly on the other sides of nb-gw and
`lil-gw or if there are other gateways in between them? This can be easily answered by
`using the traceroute command as shown. Let's first do a traceroute to igor.
`%traceroute igor
`(128.6. 13.26), 30 hops max,
`traceroute to
`igor.rutgers.edu
`40 byte packets
`4ms 2ms 2ms
`1.
`nb-gw.rutgers.
`edu
`(128.6.7.1)
`monster.rutgers.edu
`2.
`(128.6. 4.3) 2ms 2ms 2ms
`3.
`igor.rutgers.edu
`(128.6.13. 26) 3ms 2ms 2ms
`What
`is happening here is that pilot
`is sending 40 byte UDP packets to the
`destination specified in traceroute. The packets are sent with an illegal port number of
`33434. The first UDP packet is sent with the TTL (Time To Live) field set to 1. The
`TTL field is part of
`the IP datagram header as seen in Figure 19.1. When the first
`gateway along the route to igor gets this packet, it decrements the TTL by 1 and cannot
`forward the packet to its destination. See Figure 19.13(a). It sends an ICMP message
`back to the source, stating that the time to live for that UDP packet has exceeded.
`
`plinius
`
`hardees
`
`igor
`
`(128.6.13.26) ?
`lil-gw
`
`okapi
`nb-gw
`
`(128.6.11.3) ?
`waller
`
`128.6.18.45
`
`128.6.18.2
`
`pilot
`
`128.6.7.5
`
`128.6.7.1
`
`Subnet: 128.6.18.0
`Interface: le0
`Lotn Interface: le1
`Figure 19,12 Discovering the existence of igor and okapi. We would
`like to know how many hops they are away from pilot.
`0TTCP/IP
`
`Subnet: 128.6.7.0
`
`453
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 11 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`Pilot will notice who sent the ICMP message from its IP datagram source
`address. In this case, it is nb-gw. Pilot will also measure the time it took for this round
`trip transmission of packets to occur. This procedure with the TTL set to 1 is repeated
`three times and the time is measured each time. In our display,
`these times were 4ms,
`2ms, and 2ms.
`Now in Figure 19.13(b), pilot will performthesameprocedure,but this timewith
`the TTL field set to 2. nb-gw decrements TTL by 1 and routes the packet to monster.
`monster, however, decrements the TTL to 0 and can't
`forward the packets any further.
`So it sends an ICMP time-exceeded message back to pilot. Now pilot knows the
`gateway for the second hop and its round trip delay.
`Finally,
`in Figure 19.13(c), pilot sends out UDP packets with a TTL of 3 and this
`time doesn't
`receive a time-exceeded message, because it
`reaches its destination
`address. However,
`instead,
`it sends a port-unreachable message. Pilot knows it has
`reached the final destination. The port number in the UDP packet was set on purpose
`to an illegal number so as to induce this ICMP message. Notice,
`that each of the three
`UDP packets sent with a TTL of 2 took 2ms each and the ones sent with a TTL of 3 took
`3ms, 2ms, and 2ms.
`Now we know that to get to igor, there exists one other gateway called monster.
`Similarly, when we do a traceroute to okapi, we come across another gateway called
`
`pilot
`
`nb-gw
`
`monster
`
`igor
`
`UDP TTL=0
`TimeExceeded
`
`UDPTTL=1
`ICMP
`UDPTTL=2>
`UDP TL=1
`
`UDP TTL =0
`ICMPTimeExceeded
`
`(a)
`
`(b)
`
`(c)
`
`UDPTTL=3>
`UDP TTL=2
`
`UDP[|TTL=1
`
`UDP TIL =0
`HICMP PortUnreachable
`Figure 19.13 When doing a traceroute to anaddress, pilot will repeatedly
`send UDP packets, increasing the TTL (Time To Live) by one, until
`it
`receives a port unreachable message back.
`
`454
`
`TCP/IP
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 12 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`let us use the
`
`lil-gw and okapi. This time,
`waks-gw, which is a gateway between
`numeric address of okapi to do the following traceroute:
`8traceroute 128.6.11.3
`(128.6.11.3), 30 hops max,
`traceroute to 128. 6.11.3
`40 byte packets
`1lil-gw.rutgers.edu
`(128.6.7.5)
`9ms 2ms 2ms
`waks-gw.rutgers.edu
`(128.6.12.3)
`5ms 3ms 3ms
`2
`(128.6.11.3
`3ms 3ms 4ms
`okapi.rutgers.edu
`3
`Datagrams travel different
`routes and independently from each other, so the
`times shown in the traceroute displays may not always seem consistent. Now, compil-
`ing all the information from our traceroutes, our new network map is as seen in Figure
`19.14.
`
`a
`rins.st.ryukoku.ac.jp,
`Figure 19.15(a) shows a more interesting traceroute to
`host located in Japan. The -jp designates the address as being in Japan. Many of the
`gateways along the route are named using the cities where they are located.
`It is easy
`to see, for instance,
`that the route goes through Chicago, San Francisco and Hawaii,
`before reaching the last three gateways in Japan. Also, notice the significant
`jumps in
`times when reaching the first gateway in Hawaii or in Japan. Depending on the delays
`associated with links,
`these measured times can vary.
`Figure 19.15(b) shows an unsuccessful
`traceroute. Here, a set of three asterisks
`is shown after
`ru-alternet-gw,
`indicating that the problem lies between that point and
`en the next. The asterisks are repeated up to 30 times.
`ne
`eA better way to check to see if a host is up and running is to simply do a ping.
`It does not use up network
`bandwidth as much as traceroute does. Here's an example,
`where a ping is done two times to a host in Australia, using 56 bytes of data:
`%ping -s
`csuvax1.murdoch.edu.
`au 56 2
`PING csuvax1.murdoch.edu.
`au
`(134.115.4.1)
`64 bytes
`from csuvax1.murdoch.
`edu. au
`icmp_seg=0.
`time= 3299 ms
`(134.115.4.1):
`64 bytes from csuvaxl. murdoch.edu.au
`icmp_
`seq=1.time
`= 2975 ms
`loss
`2 packets
`transmitted,
`2 packets
`received,
`0% packet
`Obviously, if pings aredone for all possibleaddressesonsubnet 128.6.12.0, then
`we could find out all the hosts connected on the other side of
`lil-gw and could extend
`the network map beyond what is shown in Figure 19.14. Similarly, other subnets could
`be explored, but your network administrator could just as easily provide you with a
`network map for your installation and prevent you from using up network bandwidth.
`19.6INSTALLING A NEW SUBNET
`19.6.1 Configuring the Interfaces
`Let us now expand our network by adding a new subnet labeled 128.6.101.0. On
`this subnet, we need to adda workstation called pascal (128.6.101.2) and interconnect
`
`:
`
`TCP/IP
`
`455
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 13 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`okapi
`
`128.6.11.3
`
`waks-gw
`
`monster
`
`igor
`
`plinius
`
`hardees
`
`128.6.18.45
`
`128.6.18.2
`
`le1
`Interface:
`(128.6.18.38)
`bis
`pilot
`
`Subnet: 128.6.18.0
`
`128.6.12.3
`
`128.6.4.3 18.6.13.26
`
`lil-gw
`
`nb-gw
`
`waller
`
`128.6.7.5
`
`128.6.7.1
`
`128.6.7.41
`
`le0
`KInterface:
`Po(128.6.7.38)
`
`Subnet: 128.6.7.0
`
`3 st Figure 19,14 Adding more gateways and interfaces to our network.
`
`ailasl
`%traceroute rins.st.ryukoku.ac.jpe
`tis a traceroute to rins.st.ryukoku.ac.jp (133.83.1.1), 30hops max, 40byte packets
`1 lil-gw(128.6.18.30)3ms 2ms 2 msa
`sslt doil di
`2
`ru-alternet-gw (128.6.21.8)
`2 ms 3 ms 2 ms
`3 Washington.DC.ALTER.NET
`(137.39.18.1)
`11 ms 9 ms 10 ms
`bns 12og 24 ENSS136.t3.NSF.NET(192.41.177.253)14ms 12ms 12ms
`5
`t3-1.Washington-DC-cnss58.t3.ans.net
`(140.222.58.2)
`14 ms 13 ms 16 ms
`ania kob xl 6 t3-3.Washington-DC-cnss56.t3.ans.net(140.222.56.4) 17 ms 13 ms 16 ms
`7
`t3-0.New-York-cnss32.t3.ans.net
`(140.222.32.1)
`18 ms 20 ms 19 ms
`8
`t3-1.Cleveland-cnss40.t3.ans.net
`(140.222.40.2)
`34 ms 34 ms 41 ms
`9
`t3-2.Chicago-cnss24.t3.ans.net
`(140.222.24.3) 44 ms 46 ms 40 ms
`10
`t3-1.San-Francisco-cnss8.t3.ans.net
`(140.222.8.2) 83 ms 83 ms 80 ms
`11
`t3-0.San-Francisco-cnss9.t3.ans.net
`(140.222.9.1)
`81 ms 85 ms 84 ms
`12 t3-0.enss144.t3.ans.net
`(140.222.144.1) 83 ms 83 ms 84 ms
`13 ARC2.NSN.NASA.GOV
`(192.52.195.11)
`93 ms 96 ms 87 ms
`14 imp.Hawai.Net
`(132.160.249.1)
`141 ms 141 ms 148 ms
`15 menehune.Hawaii.Net
`(132.160.1.1) 138 ms 146 ms 144 ms
`16 132.160.251.2 (132.160.251.2) 257 ms 409 ms 392 ms
`d17 jp-gate.wide.ad.jp(133.4.1.1) 392ms 341 ms 251 ms
`2c
`18 wnoc-kyo. wide.ad.jp (133.4.7.2) 336 ms 351 ms 331 ms
`U019 rins.st.ryukoku.ac.jp(133.83.1.1)355ms 373ms 484ms
`a
`bis
`bic
`biuodas
`%traceroute rins.st.ryukoku.ac.jp
`traceroute to rins.st.ryukoku.ac.jp (133.83.1.1), 30hops max, 40byte packets
`dsbiwbtsdu lil-qw (128.6.18.30) 3 ms 2 ms 2 ms
`2
`ru-alternet-gw (128.6.21.8)
`2 ms 3 ms 2 ms
`*
`
`**
`
`34
`
`30 *
`*
`*
`nO.0.10là.8kbsooi uor
`isonnoeiai
`beadS
`
`456
`
`Figure 19.15 (a) Doing a traceroute to a host in Japan. (b) An
`unsuccessful traceroute.
`
`0 TCP/IP
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 14 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`these
`to subnet 128.6.18.0 using the gateway called ada. See Figure 19.16 for
`it
`addresses given to us by our network administrator. First, let us configure the interfaces
`for pascal, then for ada.
`On pascal's /etc/rc.boot file used for booting up purposes, we add these lines:
`(The slash is the continuation character for extending a command over multiple lines.)
`ifconfig
`lo0 127.0.0.1
`ua
`ifconfig
`le0 128.6.101.2 netmask 255.255.255.0\
`broadcast 128.6.101.255
`This way, every time pascal
`is booted up, the loopback interface and the le0
`interface is properly
`configured. Subnetting is done on the last octet boundary, as
`before, as seen by the subnet mask and the broadcast address. Notice that
`for all
`interfaces on a subnet,
`the netmask and broadcast addresses must be the same.
`Iffor
`somereasonweneedtodisablethele0interface fromthenetwork, we could
`enter:
`
`vowl
`
`#ifconfig le0 down
`And to bring it back up, we would enter:
`#ifconfig le0 128.6.101.2 up
`Likewise, for ada's bootup file, we would addthese lines:o
`ifconfig lo0127.0.0.1s
`ifconfig le0 128.6.101.3netmask255.255.255.0broadcast l
`128.6.101.255
`ifconfig le1 128.6.18.30netmask255.255.255.0broadcast l
`128.6.18.255
`19.6.2 Configuring Static Routing
`After executing these ifconfig statements, our routing tables on pascal look like:
`%netstat -nr
`Routing tables
`Destination
`127.0.0.1
`128.6.101.0
`
`Gateway
`127.0.01
`128.6.101.2
`
`Flags
`UH
`U
`
`Interface
`lo0
`cbR le0
`
`128.6.101.3 (le0).
`New subnet:
`128.6.101.0
`
`*****
`
`ada
`
`128.6.18.30 (le1)
`128.6.18.38 (le1)
`
`128.6.101.2 (le0)
`
`pilot
`
`Subnet:
`128.6.7.0
`
`457
`
`OSubnet: 128.6.18.0
`Figure 19.16 Adding a new subnet (128.6.101.0).
`
`pascal
`
`ibsoa
`
`TCP/IP
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 15 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`8
`Tol olCNotice, since only the router to its own subnet is given, pascal can't get to pilot
`a5ssiyet.
`2S0i sds dping pilot
`(aanilslotli Sendto: Network is unreachable
`To add an explicit route to pilot
`from pascal, we could do the following:
`#route add
`128.6.18.38
`128.6.101.3 1
`This would add 128.6.18.38 to pascal's routing table, making 128.6.101.3 the le0
`interface on ada as the gateway. The 128.6. 101.3 must be a gateway on the same subnet
`that pascal
`is on. Such a gateway must be one hop away. The 1 at the end of the line
`states that the metric for the number of hops is 1, since the gateway is one hop away.
`However, why only add a host
`route? Let us,
`instead, add a subnet
`route of
`128.6.18.0. This will give pascalaccessto not only pilot but also to all the hosts on that
`subnet.
`#route delete 128.6.18.38
`128.6.18.0128.6.101.31 t b
`#route add
`The route delete command will delete the route to pilot and the route add will add
`a route to subnet 128.6.18.0. Now, let us go even a step further and make ada the default
`gateway for all other routes. This is done by entering:
`#route -n add default
`128.6.101.3
`DE add net default: gateway 128.6.101.3
`So now pascal's routing tables should look like:
`#netstat -rn
`l00
`127.0.0.1
`127.0.0.1
`UH
`default
`128.6.101.3
`le0
`UG
`0ii ootlss128.6.101.0O
`128.6.101.2a0b
`le0
`U
`The following command will make pilot the default gateway for ada:
`#route -n add default
`128.6.18.38 1
`So ada's routing tables will be:
`#netstat -rn
`127.0.0.1
`127.0.0.1
`default
`128.6.18.38
`128.6.101.3
`128.6. 101.0
`128.6.18.0
`128.6.18.30
`andue
`0.13219.6.3 Configuring DynamicRouting
`Instead of configuring ada for static routing, a better choice would be to
`configure it
`for dynamic routing. This means having the gateway run a routing
`protocol.
`In our case, since we are only connecting two subnets, RIP would be
`sufficient.
`If on the other hand, we were interconnecting to a different domain, then we
`
`1
`
`UH
`UG
`
`UU
`
`0
`
`8S
`
`lo0
`le1
`le0lel
`
`458
`
`TCP/IP
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 16 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`
`
`might want to run EGP or BGP, as well. The routing daemon used to run RIP is called
`routed and a daemon used to run RIP, Hello, EGP, and BGP is called gated (Gateway
`Routing Daemon).
`To run routed, simply enter:
`#routed
`look in the/etc/gateways file
`When starting routed from the setup file, routed will
`to see if any routes are predefined. On ada, we may want to specify the default
`route
`in this file as follow:
`net 0.0.0.0 gateway 128.6.18.38 metric 1 active
`Here, the net
`identifies this address as a network address.
`If it were an address
`to ahost, then the line would begin with the keyword host. A network address of 0.0.0.0
`denotes the default
`route. The address following the keyword gateway specifies
`128.6.18.38 as the gateway for that route. The metric of 1 indicates the number of hops
`to the destination and active means that RIP may update this route if necessary.
`If
`update messages are not received for the allotted time frame, then RIP may delete it,
`as well.
`It alsomneansthat this gateway may send update messages to others. A passive
`route, on the other hand, makes the designated route a static route which can't be
`updated or deleted by RIP.
`19.7DOMAIN NAME SERVICE
`19.7.1 Purpose and Operation
`So far we have been using host names and addresses interchangeably. However,
`we have not mentioned how a name is converted to its IP address, which must be done
`in order to generate a datagram. For example, in Figure 19.15 when we asked pilot
`to
`do a traceroute to rins.st.ryukoku. ac.jp, how did it find its IP address to be 133.83.1.1?
`This is done by a service called DNS (Domain Name Service).
`It allows people to use
`host names which are easier to remember than IP addresses. It is the responsibility of
`DNS to convert a name into its correct
`IP address.
`The way DNS handles this is by using a distributed database containing host
`names and addresses information, organized hierarchically. See Figure 19.17. At the
`top of the hierarchy is one root domain. This domain is served by a set ofnamne servers
`which store information only for the top level domain servers. Examples of top level
`domains are net, mil, etc. The servers in the top level domains,
`in turn, only have
`information about the servers in the second level domains and so on. Each server stores
`information about the servers that are in the domain below it. This makes it unneces-
`sary to maintain one large file that contains the names and addresses of all the million
`or so hosts on the Internet.
`Now, if a local server, for example pilot.njin.net, wants to find the address of the
`host, rins.st.ryukoku.ac.jp, it will first look in its cache (or memory). If it isn't there,
`then it will search for the address of a server of one of the subdomains in the given host
`name. If none of these addresses is found in the cache, it will query a root domain
`server, which will give the address of a server in the jp domain. This server will do the
`
`TCP/IP
`
`459
`
`Hewlett Packard Enterprise Co. Ex. 1027, Page 17 of 17
`Hewlett Packard Enterprise Co. v. Intellectual Ventures II LLC
`IPR2021-01378
`
`