Lecture Notes Telcom 2000

Telcom 2000 Protocols and Architecture

• Standards reduce complexity • Protocol functions

m Segmentation and reassembly

m Encapsulation

m Connection control

m Ordered delivery

m Flow control

m Error control

m Addressing

m Multiplexing

m Transmission Services

Martin B.H. Weiss Internetworking - 1 University of Pittsburgh

Telcom 2000 Segmentation and Reassembly

• May be required to deal with heterogeneity in underlying layers • Block sizes may differ for different optimization reasons

Martin B.H. Weiss Internetworking - 2 University of Pittsburgh

Telcom 2000 Encapsulation

PDU (N+1)th layer PDU

SAP Nth layer SAP

PCI PDU PCI PDU

PDU (N-1)th layer PDU

Martin B.H. Weiss Internetworking - 3 University of Pittsburgh

Telcom 2000 Connection Control

• Connection Setup • Information Transfer • Connection termination • Connectionless vs. Connection-oriented

Martin B.H. Weiss Internetworking - 4 University of Pittsburgh

Telcom 2000 Addressing

• Network address should not be dependent on the physical location of the node • Network address should not contain specific routing information • Addressing level (Global/Local)

Martin B.H. Weiss Internetworking - 5 University of Pittsburgh

Telcom 2000 Multiplexing

Data Data Stream Stream

Data Connection Data Stream Stream

Data Data Stream Stream Upward Multiplexing

Connection

Data Connection Data Stream Stream Connection

Downward Multiplexing

Martin B.H. Weiss Internetworking - 6 University of Pittsburgh

Telcom 2000 TCP/IP Protocol Suite

• Application layer • Host-to-host (Transport) layer • Internet layer • Network access layer • Physical layer

Martin B.H. Weiss Internetworking - 7 University of Pittsburgh

Telcom 2000 TCP/IP Protocol Suite

User Data Application Byte Stream

TCP TCP Header Segment

IP IP Header Datagram

Network Network Header Packet

Martin B.H. Weiss Internetworking - 8 University of Pittsburgh

Telcom 2000 TCP/IP Protocol Suite

MIME

BGP FTP HTTP SMTP Telnet SNMP

TCP UDP

OSPF ICMP

Martin B.H. Weiss Internetworking - 9 University of Pittsburgh

Telcom 2000 Internetworking

• Interconnection of networks

m Routers

m Gateways • Terms

m Subnetworks

m End systems

m Intermediate systems

Martin B.H. Weiss Internetworking - 10 University of Pittsburgh

Telcom 2000

Internetwork Architecture

AAA AAAA AAAA AAAA AAAA AAAA

AAA AAAA AAAA AAAA AAAA AAAAAAAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AA AAAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA A AA AAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAAAA AAAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA Internet

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAA AAAAAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAA AAAAAAA AAAA

AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAA AAAAAAA

AAAAAAA AAAAAAA AAAA AAAA AA

AAAAAA A AAAA AAAA AA

AAAAAAA AAAA AAAA AA

AAAA AAAA AAAA AAAA AAAA AA AAAA

AAAA AAAA AAAA AAAA

Martin B.H. Weiss Internetworking - 11 University of Pittsburgh

Telcom 2000 Internetworking in OSI

ES 1 ES 2 Application Application

Presentation Presentation

Session Session

Transport Transport IS 1 IS 2 IS 3 Relay Relay Relay Network Network

Link Link

Physical Physical

Martin B.H. Weiss Internetworking - 12 University of Pittsburgh

Telcom 2000 Internetworking Issues

• Transparency

m User (Transport Protocol) should be unaware of an Internet

m Remote station should appear to be on the same network • Network service

m LAN’s typically provide connectionless network service (CLNS)

m WAN’s typically provide connection-oriented network service (CONS)

Martin B.H. Weiss Internetworking - 13 University of Pittsburgh

Telcom 2000 Internetworking Issues

• Naming and addressing

m Network Service Access Point (NSAP) addresses must be clobally unique

m Network Point of Attachment (NPA) address

m Addresses may have variable structure between LAN and WAN • Routing

m Get packet from one NSAP to another

m May need to navigate across several intermediate systems

Martin B.H. Weiss Internetworking - 14 University of Pittsburgh

Telcom 2000 Internetworking Issues

• Quality of service

m Defines the service level expected by a network service user

m Sample parameters

q Transit delay

q Security

q Cost

q Error probability

q Priority

Martin B.H. Weiss Internetworking - 15 University of Pittsburgh

Telcom 2000 Internetworking Issues

• Packet Size

m May vary across subnetworks

m Packet size is selected to optimize transmission due to

q Bit Error Rate: Higher BER => Smaller Packets

q Transit Delay: Larger Packets => Higher Transit Delay

q Buffer Size: Smaller Packets => Smaller Required Buffer Size

q Processing Overhead: Numerous Smaller Packets => Higher Overhead

m An IS may fragment a packet

q Break it into smaller packets

q Fragments are reassembled either at next IS or at ES • Intranet fragmentation • Internet fragmentation

Martin B.H. Weiss Internetworking - 16 University of Pittsburgh

Telcom 2000 Internetworking Issues

• Flow Control

m Control packet transmission rate

m Needed to guarantee transmission if

q Destination ES has limited buffers

q Different transmission rates exist on transmission path • Congestion control • Error reporting

Martin B.H. Weiss Internetworking - 17 University of Pittsburgh

Telcom 2000 Structure of the Network Layer

• End systems must run the same network layer protocol • Subnetworks may be using several differnet network layers • Therefore, we need a more detailed structure for the network layer • Problems

m How do protocol translations take place across different subnetworks?

m How are consistent network services provided?

Martin B.H. Weiss Internetworking - 18 University of Pittsburgh

Telcom 2000 Structure of the Network Layer

NSAP NSAP Trans- Trans- port port Routing & Relaying SNICP SNICP SNICP

SNDCP SNDCP SNDCP SNDCP

SNDAP SNDAP SNDAP SNDAP

Link Link

Physical Physical

Intermediate System

Martin B.H. Weiss Internetworking - 19 University of Pittsburgh

Telcom 2000 Subnet Independent Convergence Protocol (SNICP)

• Provides interface to network user • Performs routing and relaying functions • Independent of subnetwork • Network protocol of the End Systems

Martin B.H. Weiss Internetworking - 20 University of Pittsburgh

Telcom 2000 Subnet Dependent Access Protocol (SNDAP)

• Associated with specific subnet in the internet • Network protocol of the subnets • Defined by standards

m DOD Internet Protocol (IP)

m OSI IP

m X.25

Martin B.H. Weiss Internetworking - 21 University of Pittsburgh

Telcom 2000 Subnet Dependent Convergence Protocol (SNDCP)

• Handles differences among SNDAP’s • Maps functions and services across subnetworks • Unique for each pair of SNICP’s and SNDAP’s

Martin B.H. Weiss Internetworking - 22 University of Pittsburgh

Telcom 2000 Example: Ethernet Cards and Device Drivers

NSAP Socket Number (Port) Trans- port TCP/IP Software SNICP

SNDCP

SNDAP Device Driver (ODI/NDIS) Link Ethernet Physical Card

Martin B.H. Weiss Internetworking - 23 University of Pittsburgh

Telcom 2000 Internet Protocol Standards

• DOD Internet Protocol

m Developed by the US Department of Defense

m Supported the DARPANET project

m Part of the TCP/IP protocol suite • ISO-IP

m Developed in the OSI standards committees

m Based on the experience of IP community

Martin B.H. Weiss Internetworking - 24 University of Pittsburgh

Telcom 2000 General IP Issues

• Connectionless network protocol • Designed with internetworking in mind • Supports complex internets • Core IP functions

m Support fragmentation and reassembly

m Routing

m Error reporting

Martin B.H. Weiss Internetworking - 25 University of Pittsburgh

Telcom 2000 IP Address Structure (v. 4)

Class A 0 netid hostid

Class B 10 netid hostid

Class C 110 netid hostid

Subnet Addressing Internet-wide netid hostid

Modified Class B 10 netid subnetid hostid

Martin B.H. Weiss Internetworking - 26 University of Pittsburgh

Telcom 2000 IP Addressing

• Dotted decimal notation

m 130.49.192.187 (lobster.lis.pitt.edu)

m 10000010 00110001 11000000 10111011 • This is a Class B address (first bits Are 10)

m The netid is 130.49

m The subnetid is 192

m The hostid is 187 • This address is globally unique

m netid’s are dispensed by the Network Information Center (NIC)

m subnetid’s are dispensed by CIS at Pitt (in this case)

m hostid’s are dipsensed by SLIS labs (in this case)

m In some cases, CIS dispenses hostid’s as well Martin B.H. Weiss Internetworking - 27 University of Pittsburgh

Telcom 2000 Addressing Conventions

• In General

m A field containing all 0’s refers to “This”

m A field containing all 1’s refers to “All” • Network address

m An address where the hostid is All 0’s

m Refers to the network in general • Broadcast Address

m An address where the hostid is all 1’s

m All hosts respond to a broadcast message

Martin B.H. Weiss Internetworking - 28 University of Pittsburgh

Telcom 2000 Subnet Address Masks

• Boundary between subnetid and hostid can vary • It consists of a 32 bit word that is ANDed to the address • The result of the operation is the network address without the hostid • Example

m Subnet address mask for lobster.lis.pitt.edu

m 11111111 11111111 11111111 00000000

m Or, 255.255.255.0 in dotted decimal notation

Martin B.H. Weiss Internetworking - 29 University of Pittsburgh

Telcom 2000 IP Datagram Structure (v. 4)

Version Hdr. Len. Type of Service D = Don’t Fragment Total Length M = More Fragments D M Fragment Offset Fragment Offset = Datagram Position Time to Live Protocol Within a Fragmented Message Header Length = Number of 32 bit Header Checksum Words in Header, Including Source Address (NSAP) Options Source Address (NSAP) Protocol = Identifies Upper Layer Destination Address (NSAP) Protocol Using Datagram Destination Address (NSAP) Options = Support Funtions Such As Debugging, Error Reporting, Options (Variable) Route Redirection, etc. Must Be Even 32 bit Words Data (<= 65 536 bytes) Time to Live = Time Remaining in Lifetime of Datagram. This Is Decremented By Each IS By Integer Numbers of Seconds

Martin B.H. Weiss Internetworking - 30 University of Pittsburgh

Telcom 2000 Internal Organization of IP

NSAP

Datagram Datagram Fragmentation Reassembly SNICP Sublayer Forwarding and Reception Procedures

Routing Table IP NPA Routing SNDCP Sublayer Procedure

Network-Specific, eg. LLC, LAP-D Interface SNDAP Sublayer

Martin B.H. Weiss Internetworking - 31 University of Pittsburgh

Telcom 2000 Practical Issues

• How do hosts find each other on the network?

m Need physical address

m What is the relationship between physical addresses and IP addresses?

q Ethernet Addresses are 48 bits

q Internet Addresses are 32 bits

q Want to be Able to Add Machines without Recompiling Code • Solution

m Leave address resolution to the network

m Each machine has a (IP, NPA) pair

m Broadcast address resolution packet using the Address Resolution Protocol (ARP)

Martin B.H. Weiss Internetworking - 32 University of Pittsburgh

Telcom 2000 ARP Message Format

Hardware Type Protocol Type Hardware Addr. Len IP Address Length Operation: Operation 1 = ARP Request 2 = ARP Response Sender Hardware Address 3 = RARP Request 4 = RARP Response

Sender IP Address

Target Hardware Address

Target IP Address

Martin B.H. Weiss Internetworking - 33 University of Pittsburgh

Telcom 2000 New Hosts/Diskless Hosts

• Need to acquire an IP address • Use a Reverse Address Resolution Protocol (RARP) • Allows a host to find its IP and NPA • Important for diskless workstations • Implies the need for a RARP server

Martin B.H. Weiss Internetworking - 34 University of Pittsburgh

Telcom 2000 Expansion to Multiple Networks

• Need to find (IP,NPA) pairs across networks

m Build Routing Tables in hosts and gateways

m Identify locations of (IP,NPA) pairs

m Build routing tables by observing ARP packets • Need to route packets within subnetworks

m How do routers know where to send packets?

q Need a mechanism for routers to communicate

q Use Interior Gateway Protocol (IGP)

m Routers only need to know the structure of the network

q Routers do not need complete network routing tables

q Routers base their routing decisions on network addresses, not host addresses

Martin B.H. Weiss Internetworking - 35 University of Pittsburgh

Telcom 2000 Expansion to Multiple Networks

• Examples of IGP’s:

m Routing Information Protocol (RIP)

m Open Shortest Path First (OSPF)

m IS-to-IS • Need to route packets between subnetworks

m Use Exterior Gateway Protocols (EGP)

m Examples

q Exterior Gateway Protocol (EGP)

q IS-to-IS • Need to map names Into addresses

m Humans use names (eg. lobster.lis.pitt.edu)

m Machines use IP addresses

m A Name Server maps these two address forms

Martin B.H. Weiss Internetworking - 36 University of Pittsburgh

Telcom 2000 Structure of Internet Routing

• Autonomous systems

m Each network of an Internet

m Defined by separate administrative control

m Routing within AS’s is handled separately

m Use Interior Gateway Protocols (IGP’s)

m IGP’s can be proprietary • Core networks

m Networks interconnecting AS’s

m “Backbone” network

m Use External Gateway Protocols (EGP’s)

m An EGP must be standard

Martin B.H. Weiss Internetworking - 37 University of Pittsburgh

Telcom 2000 IP Routing Algorithm

• Extract destination IP address (ID) and compute destination network (IN)

•If IN matches a direct-connected network address

m Resolve ID to a NPA m Send packet to NPA

• Else if ID is a host-specific route, route datagram as specified by Host

• Else if IN appears in the routing table, route datagram as specified in the routing table • Else If a default route has been specified, route datagram to the default router • Else none of these apply, declare a routing error

Martin B.H. Weiss Internetworking - 38 University of Pittsburgh

Telcom 2000 Controlling an Internet

• Use the Internet Control Message Protocol (ICMP) • ICMP functions

m Communicate errors back to host

q Destination unreachable

q Other failures

q Datagram error

q Detecting excessively long routes (Time exceeded) m Testing destination reachability and status (Echo)

m Datagram flow control (Source Quench)

m Route change requests (Redirect)

m Clock synchronization and transit time estimation

m Obtain information

q NPA

q Subnet mask

Martin B.H. Weiss Internetworking - 39 University of Pittsburgh

Telcom 2000

Structure of the Privatized Internet

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA

Internet AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA

ISP AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA

Backbone AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA

Provider AAA

AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA

AAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA

AAAAAA

AAAAAA AA

AAAA NAP/CIX

AAAAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA Internet

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA Backbone ISP

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA Provider

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

Martin B.H. Weiss Internetworking - 40 University of Pittsburgh

Telcom 2000 Structure of an ISP

To Internet

M Backbone

AA AAAA AAAA AAAA

AA AAAA AAAA

AAAA Provider AA AAAA AAAA AAAA

AA AAAA AAAA AAAA

AA AAAA AAAA AAAA AAAAAAAA

AA AAAA AAAA AAAA AAAAAAA

Modem Terminal A R

AA AAAA AAAA AAAA AAAAAAAA

AA AAAA AAAA AAAA AAAAAAA

Dialup Pool Server A

AA AAAA AAAA AAAA AAAAAAAA

AA AAAA AAAA

AAAAPSTN

AA AAAA AAAA

Lines AAAA

AA AAAA AAAA AAAA

AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA Internal

AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA LAN Server

AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

M AAAA

AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

AAAA AAAA AAAA AAAA AAAA

AAAAAAA

AAAAAA

A Server

AAAAAA

A R

AAAAAAA

Leased Lines

Martin B.H. Weiss Internetworking - 41 University of Pittsburgh

Telcom 2000 Problems with IPv4

• Address exhaustion • Heterogeneity of user needs • Security • Difficulty in supporting multiple service providers

Martin B.H. Weiss Internetworking - 42 University of Pittsburgh

Telcom 2000 Interim Solution to Address Problem: CIDR

• Classless Internet Domain Routing (CIDR) is a temporary solution to the address exhaustion problem only • Allows aggregation of Class C addresses to minimize the impact on the Internet backbone routers

m July 1988 - 173 routes advertised

m December 1992 - 8561 routes advertised • CIDR strategy

m Assign blocks of Class C addresses to service providers

m Advertise routes for that block of addresses only, not for each Class C address in the block

m Users of the service provider are given subsets of that block

Martin B.H. Weiss Internetworking - 43 University of Pittsburgh

Telcom 2000 Permanent Solution: IP Version 6

• Motivated by pending exhaustion of IP addresses • Additional features added

m Security

m Traffic support

m Routing flexibility

Martin B.H. Weiss Internetworking - 44 University of Pittsburgh

Telcom 2000 IPv6 Packet

Octets IPv6 header 40 Hop by hop options header variable

Routing header variable Frag. header 8 Authent. header variable Encaps. Sec. variable Payload header Dest. options variable header Dest. options variable header 20 This contains all possible TCP Header extension headers. All IP App. Data variable datagrams need not support each header. Martin B.H. Weiss Internetworking - 45 University of Pittsburgh

Telcom 2000 IPv6 Header

Version Priority Flow Label Payload Length Next Header Hop Limit

Source Address

Destination Address

Martin B.H. Weiss Internetworking - 46 University of Pittsburgh

Telcom 2000 IPv6 Header

• Priority

m Relative to other datagrams from the same source

m Separates “congestion controlled” and “non- congestion controlled” traffic

m Controlled traffic is lower priority (0-7) than non- controlled traffic (8-15) • Flow label

m Used by the host to identify datagrams requiring special handling by the routers

m A “flow” is a sequence of packets from a destination to one or more sources

m Packets in the same “flow” are given the same flow label

m Attributes for a given flow must be negotiated outside of IP in advance of the flow Martin B.H. Weiss Internetworking - 47 University of Pittsburgh

Telcom 2000 IPv6 Header

• Next header

m Identifies the type of header immediately following the current one

m All headers in IPv6 have this field • Hop limit - number of hops remaining before the datagram is dropped

Martin B.H. Weiss Internetworking - 48 University of Pittsburgh

Telcom 2000 IPv6 Addresses

Global Unicast Address n m o 125-n-m-o-p 010 Registry ID Provider ID Subscriber ID Interface ID

Link Local Address 10 n 118-n 1111111010 0 Interface ID

Site Local Address 10 n m 118-n-m 1111111011 0 Subnet ID Interface ID

Embedded IPv4 Address 80 16 32 0 XXXX IPv4 Address

Martin B.H. Weiss Internetworking - 49 University of Pittsburgh

Telcom 2000 IPv6 Addressing

• Addressing provides for

m Registration authorities, who assign provider addresses

m Multiple providers, who assign the subscriber portion of the address • Notation

m Dotted decimal does not work well with the larger addresses

q Example of an address in dotted decimal:

q 105.220.136.100.255.255.255.255.0.0.18.128.140.10.255.255 m In colon hexadecimal notation:

q 69DC:8864:FFFF:FFFF:0:1280:8C0A:FFFF m Zero compression is used for additional shorthand:

q FF0C:0:0:0:0:0:0:B1 = FF0C::B1

Martin B.H. Weiss Internetworking - 50 University of Pittsburgh

Telcom 2000 ISO Addressing

NSAP Transport Session Presentation Address Selector Selector Selector

TSAP Address SSAP Address PSAP Address

• Uses an Service Access Point (SAP) concept • Selectors can exist above the network layer to identify entities within a particular end system

Martin B.H. Weiss Internetworking - 51 University of Pittsburgh

Telcom 2000 ISO Addressing

• Hierarchical • Several Addressing Domains are specified • Each domain is administered by an Addressing Authority • Addressing authorities may create Sub-Domains and further delegate addressing authority

Sub-Domain (D11)

Sub-Domain Domain 2 (D12) Domain 1 Domain 3 Global Network Addressing Domain (GNAD)

Martin B.H. Weiss Internetworking - 52 University of Pittsburgh

Telcom 2000 NSAP Address Structure

• NSAP must be globally unique • Must support subnetting

m Each country’s network is a subnet of the global network

m Countries may have multiple subnets

AFI IDI SI PA SEL

Initial Domain Part Domain Specific Part

Martin B.H. Weiss Internetworking - 53 University of Pittsburgh

Telcom 2000 Initial Domain Part

• Must be globally defined (Not directly administered by ISO) • Authority and Format Identifier (AFI)

m Identifies Authority responsible for issuing IDI’s

m Identifies format of IDI • Initial Domain Identifier (IDI)

m Specifies network addressing scheme of DSP

m Eg. X.121 for X.25 networks

Martin B.H. Weiss Internetworking - 54 University of Pittsburgh

Telcom 2000 Domain Specific Part (DSP)

• Hierarchical structure

m Format specified by authority defined in IDI

m May be decimal, binary, etc. • Subnet Identifier (SI) identifies subnetwork for destination and source • Point of Attachment (PA) identifies address within subnetwork • Selector (SEL) - Local address extension

Martin B.H. Weiss Internetworking - 55 University of Pittsburgh

Telcom 2000 Example of X.25 Address in ISO Format

Initial Domain Part Domain Specific Part

AFI IDI SI PA SEL

AAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAA

36 234219011212A Null

AAAAAAAAAAAAAAAAAAAAAAAAAAA

A AAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAA

X.121 Address Specified by (Up to 14 Decimal Digits) CCITT to Define X.121 Address in IDI

Martin B.H. Weiss Internetworking - 56 University of Pittsburgh

Telcom 2000 Conclusion of the Network Layer

• Many Rich Protocols Exist • Perform Network Functions for Users

m Routing

m Connection Maintenance (Where Appropriate)

m Accounting

m Transparency from Subnetwork Details

q Network Type

q Frame Size

q Network Speed • Important Network Layer Standards

m X.25

m Internet IP

m ISO IP

Martin B.H. Weiss Internetworking - 57 University of Pittsburgh