throbber
NETWORKS
`
`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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket