Home > Articles > Networking

This chapter is from the book

This chapter is from the book

Operation of IS-IS for CLNS/CLNP

This section describes the operation of IS-IS. As mentioned earlier, IS-IS is used for routing CLNS/CLNP data, while Integrated IS-IS is used for routing IP. Integrated IS-IS is described in the next section.

OSI Addressing

OSI network layer addressing is done through NSAP addresses that identify any system in the OSI network. These OSI addresses are often simply referred as NSAPs.

NOTE

A variety of NSAP formats are used for different systems, and each OSI routing protocol uses a different representation of NSAP. NSAPs usually are represented in hexadecimal format with a variable length of up to 40 hex digits. NSAPs also are used in ATM. Later in this section, you will see the format interpreted by Cisco IOS Software.

The LSPs, hello PDUs, and other routing PDUs are OSI-format PDUs; therefore, every IS-IS router requires an OSI address even if it is routing only IP. IS-IS uses the OSI address in the LSPs to identify the router, build the topology table, and build the underlying IS-IS routing tree.

The NSAPs contain the following:

  • The OSI address of the device

  • The link to the higher-layer process

NOTE

The NSAP address can be thought of as the equivalent of a combination of IP address and upper-layer protocol in an IP header.

Dijkstra's algorithm, which is used for both IS-IS and OSPF, requires a point-to-point connection between devices. OSPF uses the router ID to represent each router for this connection, while IS-IS uses the NET (a subset of the NSAP discussed in the following section).

NSAP Address Structure

Cisco routers can route CLNS data that uses addressing conforming to the ISO 10589 standard. The NSAP structure is illustrated in Figure S-6.

Figure S-6Figure S-6 Structure of NSAP Addresses

An OSI NSAP address can be up to 20 octets long and consists of the following parts, as shown in Figure S-6:

  • The authority and format ID (AFI) specifies the format of the address and the authority that assigned that address. The AFI is 1 byte.

  • The interdomain ID (IDI) identifies this domain. The IDI can be up to 10 bytes.

  • The AFI and IDI together make up the interdomain part (IDP) of the NSAP address. This can loosely be equated to an IP classful major network.

  • The high-order domain-specific part (DSP) (HODSP) is used for subdividing the domain into areas. This can be considered loosely as the OSI equivalent of a subnet in IP.

  • The system ID identifies an individual OSI device (an ES or an IS). In OSI, a device has an address, just as it does in the DECnet protocol. This is different from IP, in which an interface has an address. OSI does not specify a fixed length for the system ID, but it does specify that it be consistent for all devices. Cisco IOS Software fixes the system ID as the 6 bytes preceding the 1-byte NSAP selector (NSEL).

    NOTE

    A Media Access Control (MAC) address is often used for the system ID.

  • The NSEL (also known as the N-selector, the service identifier or the process ID) identifies a process on the device. It is a loose equivalent of a port or socket in IP. The NSEL is 1 byte long. It is not used in routing decisions. When the NSEL is set to 00, the address identifies the device itself—its network level address. In this case, the NSAP is known as a network entity title (NET).

  • The HODSP, system ID, and NSEL together make up the domain-specific part (DSP) of the NSAP address.

IS-IS Versus ISO-IGRP NSAPs

IS-IS and ISO-IGRP interpret NSAPs differently, as shown in Figure S-7.

Figure S-7Figure S-7 How IS-IS and ISO-IGRP Interpret NSAP Addresses

IS-IS uses a two-layer architecture, joining the IDP and HODSP fields and treating them as its area address (Level 2), with the remaining system ID used for Level 1 routing. When used with IS-IS, therefore, the NSAP is divided into three parts, as shown in Figure S-7: 1 octet for NSEL, 6 octets for the system ID, and from 1 to 13 octets for the area address or area ID field. An NSAP has a variable length of 8 to 20 octets. It is usually longer than 8 bytes to permit some granularity in the allocation of areas.

NOTE

Figure S-7 shows field length in bytes (or octets), where the NSAP address usually is represented in hexadecimal. NSAP addresses, like ATM addresses, are 160 bits long:

ISO-IGRP routes are based on a three-level architecture: domain (using the AFI and IDI fields for Level 3), area (using the HODSP field for Level 2), and system ID (for Level 1). What IS-IS treats simply as the area ID, ISO-IGRP splits into a domain and an area. ISO-IGRP sets the 2 bytes to the left of the system ID as the area ID or area address field, allowing for a theoretical 65,535 areas in an ISO-IGRP network. Everything else (a maximum of 11 bytes) is treated as a domain ID. Therefore, the minimum length for an ISO-IGRP NSAP is 10 bytes (1-byte NSEL, 6-byte system ID, 2-byte area, and minimum 1-byte domain).

ISO-IGRP sends routing information based on domain (variable length), area (length fixed by the protocol at 2 bytes), and finally system ID (fixed at 6 bytes). The NSEL is not used by ISO-IGRP.

Network Entity Title

As discussed earlier, if the NSEL field is 00, the NSAP refers to the device itself—that is, it is the equivalent of the Layer 3 OSI address of that device.

This address with the NSEL set to 00 is known as the NET. The NET is used by routers to identify themselves in the LSPs. Therefore, it forms the basis for the OSI routing calculation.

NET Is NSAP with NSEL = 00

A key point is that an NSAP address in which the NSEL is set to 00 is called the NET.

NETs and NSAPs are specified in all hexadecimal digits and must start and end on a byte boundary.

Official NSAP prefixes are required for CLNS routing. Addresses starting with the value of 49 (AFI = 49) are considered to be private addresses (analogous to RFC 1918 for IP addresses). These addresses are routed by IS-IS; however, this group of addresses should not be advertised to other CLNS networks.

Addresses starting with AFI values 39 and 47 represent the ISO data country code and ISO international code designator, respectively.

As shown in Figure S-7 and the examples in the next section, the Cisco IOS Software IS-IS routing process interprets the NSAP address as follows (from the right, or least-significant digit, end):

  • The last byte is the NSEL field and must be specified as a single byte, with two hex digits, preceded by a period (.). In a NET, this N-selector field is set to (00).

  • The preceding 6 bytes (this length is fixed by Cisco IOS Software) are the system ID. It is customary to use either a MAC address from the router or (for Integrated IS-IS) an IP address (for example, the IP address of a loopback interface) as part of the system ID.

  • The IS-IS routing process of Cisco IOS Software treats the rest of the address as the area ID, or area address, as follows:

    • It is 1 to 13 bytes long.

    • Using a 1-byte field for area limits the scope for area definitions. Thus, the customary area ID consists of 3 bytes, with an AFI of 1 byte and 2 additional bytes for the area ID. For example, in the address 49.0001.0000.0c12.3456.00, the AFI is 49 and the additional 2 bytes are 0001, for an effective area ID of 49.0001.

    • Cisco IOS Software attempts to summarize the area ID as much as possible. For example, if an IS-IS network is organized with major areas subdivided into minor areas, and this is reflected in the area ID assignments, then:

      Between the minor areas, Cisco IOS Software will route based on the whole area ID.

      Between the major areas, Cisco IOS Software will summarize the area ID portion up to the major area boundary.

NSAP Examples

The following examples illustrate how an NSAP address is interpreted by IS-IS and ISO-IGRP.

The NSAP 49.0001.aaaa.bbbb.cccc.00 consists of the following:

  • For IS-IS:

    • Area = 49.0001

    • System ID = aaaa.bbbb.cccc

    • N-selector = 00

  • For ISO-IGRP:

    • Domain = 49

    • Area = 0001

    • System ID = aaaa.bbbb.cccc

    • N-selector = ignored by ISO-IGRP

The NSAP 39.0f01.0002.0000.0c00.1111.00 consists of the following:

  • For IS-IS:

    • Area = 39.0f01.0002

    • System ID = 0000.0c00.1111

    • N-selector = 00

  • For ISO-IGRP:

    • Domain = 39.0f01

    • Area = 0002

    • System ID = 0000.0c00.1111

    • N-selector = ignored by ISO-IGRP

Identifying Systems in IS-IS

In IS-IS, the area ID is associated with the IS-IS routing process; a router can be a member of only one Level 2 area. Recall from earlier in the chapter that a router can belong to only one area. The area ID or area address uniquely identifies the routing area, and the system ID identifies each node.

Restrictions on Areas and System IDs

Restrictions on areas and system IDs are as follows:

  • All routers in an area must use the same area address. Indeed, the shared area address actually defines the area.

  • An ES might be adjacent to a Level 1 router only if they both share a common area address. In other words, ESs recognize only ISs (and ESs on the same subnetwork) that share the same area address.

  • Area routing (Level 1) is based on system IDs. Therefore, each device (ES and IS) must have a unique system ID within the area, and all system IDs must be the same length. Cisco mandates a 6-byte system ID.

  • All Level 2 ISs come to know about all other ISs in the Level 2 backbone. Therefore, they, too, must have unique system IDs within the area.

System IDs

The system ID must be unique inside an area. As noted earlier, it is customary to use either a MAC address from the router or (particularly for Integrated IS-IS) to code the IP address (for example, of a loopback interface) into the system ID.

It is generally recommended that the system IDs remain unique across the domain; that, way there can never be a conflict at Level 1 or Level 2 if a device is moved into a different area, for example.

All the system IDs in a domain must be of equal length. This is an OSI directive; Cisco enforces this by fixing the length of the system ID at 6 bytes in all cases.

Subnetwork Point of Attachment and Circuits

Two other terms used in IS-IS are subnetwork point of attachment (SNPA) and circuit.

An SNPA is the point at which subnetwork services are provided. This is similar to the Layer 2 address corresponding to the Layer 3 (NET or NSAP) address. The SNPA is usually taken from the following:

  • The MAC address on a LAN interface.

  • The virtual circuit ID for X.25 or ATM.

  • The data-link connection identifier (DLCI) for Frame Relay.

  • For High-Level Data Link Control (HDLC) interfaces, the SNPA is simply HDLC.

A link is the path between two neighbor ISs and is defined as being "up" when communication is possible between the two neighbors' SNPAs.

A circuit is an interface; interfaces are uniquely identified by a Circuit ID. The router assigns a one octet Circuit ID to each interface on the router, as follows:

  • In the case of point-to-point interfaces, this is the sole identifier for the circuit—for example, 03.

  • In the case of LAN interfaces (and other broadcast multi-access interfaces), this circuit ID is tagged to the end of the system ID of the DIS to form a 7-byte LAN ID. An example is 1921.6811.1001.03, where 03 is the circuit ID.

Example of NET Addresses in IS-IS Network

Figure S-8 shows examples of the NETs for routers in an IS-IS domain. Observe the following in Figure S-8:

  • The 6-byte system IDs are unique across the network.

  • The 3-byte area IDs are common to areas and distinct between areas.

  • The 1-byte N-selectors are set to 00, indicating that these are NETs.

Figure S-8Figure S-8 NSAP Addresses in an IS-IS Network

IS-IS PDUs

The OSI stack defines a unit of data as a protocol data unit (PDU). A frame therefore is regarded by OSI as a data-link PDU, and a packet (or datagram, in the IP world) is regarded as a network PDU.

Three types of PDUs (with 802.2 Logical Link Control encapsulation) are shown in Figure S-9. As the figure shows, the IS-IS and ES-IS PDUs are encapsulated directly in a data-link PDU (there is no CLNP header and no IP header), while true CLNP (data) packets contain a full CLNP header between the data-link header and any higher-layer CLNS information.

Figure S-9Figure S-9 OSI Protocol Data Units

IS-IS and ES-IS PDUs contain multiple sets of variable-length fields, depending on the function of the PDU. Each field contains a type code, a length, and then the appropriate values—hence the abbreviation TLV, for Type, Length, Value fields—as shown in Figure S-9.

Four general types of packets exist, and each type can be Level 1 or Level 2:

  • LSP—Used to distribute link-state information

  • Hello PDU (ESH, ISH, IS-IS Hello [IIH])—Used to establish and maintain adjacencies

  • Partial sequence number PDU (PSNP)—Used to acknowledge and request link-state information

  • Complete sequence number PDU (CSNP)—Used to distribute a router's complete link-state database

LSPs and hello PDUs are detailed in the following sections; the use of PSNP and CSNP is described in the section, "Link-State Database Synchronization."

Link State Packets

This section describes the IS-IS LSPs.

Network Representation

In OSI, there are two main types of physical links:

  • Broadcast—Multiaccess media types that support addresses referring to groups of attached systems and are typically LANs.

  • Nonbroadcast—Media types that must address ESs individually and that are typically WAN links. These include point-to-point links, multipoint links, and dynamically established links.

Consequently, IS-IS supports only two media representations for its link states:

  • Broadcast for LANs

  • Point-to-point for all other media

    NOTE

    IS-IS has no concept of an NBMA network. It is recommended that point-to-point links (for example, subinterfaces) be used instead of NBMA networks such as native ATM, Frame Relay, or X.25.

LSP Contents

In IS-IS, a router describes itself with an LSP. The router's LSP contains the following:

  • An LSP header, describing these items:

    • The PDU type and length

    • The LSP ID and sequence number

    • The remaining lifetime for this LSP (used to age out LSPs)

  • Type Length Value (TLV) variable-length fields:

    • The router's neighbor ISs (used to build the map of the network)

    • The router's neighbor ESs

    • Authentication information (used to secure routing updates)

    • Attached IP subnets (optional for Integrated IS-IS)

The LSP sequence numbers enable receiving routers to ensure that they use only the latest LSPs in their route calculations, thus avoiding duplicate LSPs being entered in the topology tables.

When a router reloads, the sequence number is set initially to 1. The router might then receive its own old LSPs back from its neighbors (which has the last good sequence number before the router reloaded). It records this number and reissues its own LSPs with the next-highest sequence number.

The Remaining Lifetime field in the LSP is used by the LSP aging process to ensure that outdated and invalid LSPs are removed from the topology table after a suitable period. The LSP remaining lifetime counts down from 1200 seconds (20 minutes) to 0.

NOTE

IS-IS uses an LSP refresh interval of 15 minutes, as specified by ISO 10589. Each IS-IS router that originates an LSP is responsible for updating its entries using this timer. The Remaining Lifetime timer is how long an LSP is kept as valid in an IS-IS LSP database.

LAN Representation

Dijkstra's algorithm, used for IS-IS, requires a virtual router (pseudonode) for broadcast media to build a weighted directed graph of the shortest paths from a single source vertex to all other vertices.

For this reason, the DIS is elected to generate an LSP representing a virtual router connecting all attached routers to a star-shape topology. The DIS is shown in Figure S-10. The decision process for the election of the DIS is based first on the router with the highest configured priority and second on the router with the highest MAC address.

Figure S-10Figure S-10 IS-IS Designated Intermediate System Is Elected to Represent the LAN

In IS-IS, all routers on the LAN establish adjacencies with all other routers and with the DIS. Thus, if the DIS fails, another router can take over immediately with little or no impact on the topology of the network.

This is different from OSPF behavior. In OSPF, once the designated router (DR) and a backup DR (BDR) are elected, the other routers on the LAN establish adjacencies only with the DR and the BDR (the BDR is elected, and in the case of DR failure, is then promoted to the DR).

LSP Variables

IS-IS LSPs include specific information about the router's attachments. This information is included in multiple TLV fields in the main body of the LSP:

  • The links to neighbor routers (ISs), including the metrics of those interfaces

  • The links to neighbor ESs

    NOTE

    If Integrated IS-IS is operational, the attached IP subnets are described as ESs, using a special TLV specified for IP information.

The metrics of IS-IS links are associated with the outgoing interface toward the neighbor IS (router). Up to four metrics can be specified, as follows:

  • Default metric (required): cost—No automatic calculation of the metric for IS-IS takes place, compared to some routing protocols that calculate the link metric automatically based on bandwidth (OSPF) or bandwidth/delay (EIGRP). Using narrow metrics (the default), an interface cost is between 1 and 63 (a 6-bit metric value). All links use the metric of 10 by default. The total cost to a destination is the sum of the costs on all outgoing interfaces along a particular path from the source to the destination, and the least-cost paths are preferred.

  • Delay, expense, and error (optional)—These metrics are intended for use in type of service (ToS) routing. These could be used to calculate alternative routes referring to the DTR (delay, throughput, and reliability) bits in the IP ToS field.

    Extended Metric

    In IS-IS, using the old-style narrow cost metric discussed previously, the total path metric is limited to 1023 (the sum of all link metrics along a path between the calculating router and any other node or prefix). This small metric value proved insufficient for large networks and provided too little granularity for new features such as traffic engineering and other applications, especially with high-bandwidth links.

    Cisco IOS Software addresses this issue with the support of a 24-bit metric field, the so-called wide metric. Using the new metric style, link metrics now have a maximum value of 16,777,215 (224–1) with a total path metric of 4,294,967,295 (232–1).

    Running different metric styles within one network poses a serious problem: Link-state protocols calculate loop-free routes because all routers (within one area) calculate their routing tables based on the same link-state database. This principle is violated if some routers look at old-style (narrow) and some at new-style (wider) TLVs. However, if the same interface cost is used for both the old- and new-style metrics, the SPF computes a loop-free topology.

Hello Messages

IS-IS uses hello PDUs to establish adjacencies with other routers (ISs) and ESs. Hello PDUs carry information about the system, its parameters and capabilities.

IS-IS has three types of hello PDUs, as follows:

  • ESH, sent by an ES to an IS

  • ISH, sent by an IS to an ES

  • IIH, used between two ISs

The three types of hello PDUs are shown in Figure S-11.

Figure S-11Figure S-11 Three Types of IS-IS Hello PDUs

IS-IS Communication

ISs use IIHs to establish and maintain their neighbor relationships. When an adjacency is established, the ISs exchange link-state information using LSPs.

ISs also send out ISHs. ESs listen for these ISHs and randomly pick an IS (the one that sent the first ISH they hear) to forward all their packets to. Hence, OSI ESs require no configuration to forward packets to the rest of the network.

ISs (routers) listen to the ESHs and learn about all the ESs on a segment. ISs include this information in their LSPs.

For particular destinations, ISs might send redirect (RD) messages to ESs to provide them with an optimal route off the segment. This process is similar to IP Redirect.

Adjacencies

Separate adjacencies are established for Level 1 and Level 2. If two neighboring routers in the same area run both Level 1 and Level 2, they establish two adjacencies, one for each level. The Level 1 and Level 2 adjacencies are stored in separate Level 1 and Level 2 adjacency tables.

On LANs, the two adjacencies are established with specific Layer 1 and Layer 2 IIH PDUs. Routers on a LAN establish adjacencies with all other routers on the LAN and send LSPs to all routers on the LAN (unlike OSPF, in which routers establish adjacencies only with the designated router).

On point-to-point links, there is a common IIH format, part of which specifies whether the hello relates to Level 1, Level 2, or both.

By default, hello PDUs are sent every 10 seconds; the timeout to declare a neighbor down (that is, missing three hello packets) is 30 seconds. These timers are adjustable. (The commands to adjust the timers are not discussed in this book.)

LAN Adjacencies

IIH PDUs announce the area ID. Separate IIH packets announce the Level 1 and Level 2 neighbors. Adjacencies are established based on the area address announced in the incoming IIHs and the type of the router.

For example, in Figure S-12, routers from two different areas are connected to the same LAN. On this LAN, the following is true:

  • The routers from one area accept Level 1 IIH PDUs only from their own area and, therefore, establish adjacencies only with their own area routers.

  • The routers from a second area similarly accept Level 1 IIH PDUs only from their own area.

  • The Level 2 routers (or the Level 2 process within any Level 1–2 router) accept only Level 2 IIH PDUs and establish only Level 2 adjacencies.

Figure S-12Figure S-12 IS-IS Adjacencies Are Based on Area Address and Type of Router

WAN Adjacencies

On point-to-point links (that is, on a WAN), the IIH PDUs are common to both Level 1 and Level 2 but announce the level type and the area ID in the hellos. This is illustrated in Figure S-13.

Figure S-13Figure S-13 On a WAN, Area Address and Router Type Are Announced in a Common IIH PDU

As shown in Figure S-13, the following is true:

  • Level 1 routers in the same area (which includes links between Level 1–only and Level 1–2 routers) exchange IIH PDUs specifying Level 1 and establish a Level 1 adjacency.

  • Level 2 routers (in the same area or between areas, and including links between Level 2–only and Level 1–2 routers) exchange IIH PDUs specifying Level 2 and establish a Level 2 adjacency.

  • Two Level 1–2 routers in the same area establish both Level 1 and Level 2 adjacencies, and maintain these with a common IIH PDU specifying both the Level 1 and Level 2 information.

  • Two Level 1–2 routers in different areas establish only a Level 2 adjacency.

  • Two Level 1 routers that might be physically connected but are not in the same area (including a Level 1–only to a Level 1–2 router in a different Level 1 area) exchange Level 1 IIH PDUs but ignore these because the area IDs do not match. Therefore, they do not establish adjacency.

Level 2 Adjacencies

Figure S-14 shows examples of the following:

  • Level 1–only routers establishing Level 1 adjacencies

  • Level 2 routers establishing only Level 2 adjacencies (between areas)

  • Level 1–2 routers establishing both Level 1 and Level 2 adjacencies with their Level 1–2 neighbors in the same area

Figure S-14Figure S-14 Level 2 Adjacencies Must Be Continuous

NOTE

In OSPF, there is a backbone area; here there is a backbone path. The path of connected Level 2 routers is called the backbone. All individual areas and the backbone must be contiguous. Level 2 adjacency exists independent of the area and must be contiguous. In the example in Figure S-14, the backbone is maintained by routers B, C, D, G, and H. A backbone is a set of contiguous Level 1–2 and Level 2 routers.

Link-State Database Synchronization

IS-IS link-state database synchronization is accomplished using special PDUs: PSNPs and CSNPs. These special PDUs bear the generic name of sequence number PDUs (SNPs),

SNPs (PSNPs and CSNPs) ensure that LSPs are sent reliably. SNPs contain LSP descriptors—not the actual, detailed LSP information, but headers describing the LSPs.

PSNPs usually contain only one LSP descriptor block. They are used as follows:

  • To acknowledge receipt of an LSP

  • To request a complete LSP for an entry missing in the originating router's topology database

CSNPs are a list of the LSPs held by a router.

CSNPs are sent periodically on LANs. Receiving routers can compare the list of LSPs in the CSNP with their link-state database and request (with a PSNP) any missing LSPs.

CSNPs are sent on point-to-point links when the link comes active. In Cisco IOS Software, periodic CSNPs can be configured on point-to-point links.

Figure S-15 shows an example of link-state database synchronization on a point-to-point link. In this figure, the following is true:

  • A link fails.

  • The R2 router notices this failure and issues a new LSP noting the change.

  • The R1 router receives the LSP, stores it in its topology table, and sends a PSNP back to R2 to acknowledge receipt of the LSP.

Figure S-15Figure S-15 Link-State Database Synchronization on a Point-to-Point Link

On a LAN, the DIS periodically (every 10 seconds) sends CSNPs listing the LSPs that it holds in its link-state database. This is multicast to all IS-IS routers on the LAN.

Figure S-16 shows an example of link-state database synchronization on a LAN. In the example, the R2 router is the DIS. R2 sends a CSNP. The R1 router compares this list of LSPs with its topology table and realizes that it is missing one LSP. Therefore, it sends a PSNP to the DIS (R2) to request the missing LSP. The DIS reissues that LSP, and the R1 router acknowledges it with a PSNP (these last two steps are not shown in this figure but are similar to those in Figure S-15).

Figure S-16Figure S-16 Link-State Database Synchronization on a LAN

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020