ATM networks - Departamento de Ingeniería Telemática

Switching: ATM
ATM and
Internetworking
José Félix Kukielka
David Larrabeiti
Piotr Pacyna
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Programme authors and contributors
Teaching material:
‹ David
‹
‹
‹
Larrabeiti López
José Félix Kukielka
Huw Oliver
Piotr Pacyna
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
2
Index
‹ Introduction
‹ Classical
‹ Next
IP over ATM
Hop Resolution Protocol (NHRP)
‹ Introduction
to Multiprotocol over ATM
(MPOA)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
3
Bibliography
‹ David
McDysan and Darren Spohn, ATM
Theory an Applications. McGraw Hill
™
Chapters 19 and 20
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
4
ATM and Internetworking
Introduction
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Protocols for Internetworking
Based on IP
Multiprotocol
over ATM
(MPOA)
LAN
Emulation
(LANE)
Classical
IP over
ATM
Next Hop
Resolution
Protocol
(NHRP)
IP
Multicast
over
ATM
Multiprotocol
Encapsulation
over ATM
(RFC 2684)
Proprietary methods:
- IP Switching
MultiProtocol
- Tag Switching
- Cell Switching Router Label Switching
- Aggregate Route(MPLS)
based IP Switching
(ARIS)
AAL5
ATM Layer
Physical Layers
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
6
IP Maximum Transfer Unit (MTU) over
AAL5
‹
Using AAL5 to transport IP datagrams:
™
™
™
™
‹
Sender: Establishes a PVC / SVC through an ATM network to a
destination host, specifying that the VC should use AAL5
Sender: Hands a complete datagram down to AAL5 for
transmission over the circuit
AAL5: Generates a trailer, divides the datagram in cells and
transfers the cells to the network
Receiver: AAL5 reassembles the datagram, uses the CRC of the
trailer to verify correctness and transfers the result to IP
AAL5 uses a length field of 16 bits
™
™
Possible to send 64 KByte in only one packet
However, TCP/IP restrict the maximum size of the datagram to
be send over an ATM network
9
™
RFC 1626: MTU of 9180 octets for ATM networks.
Thus: Datagrams larger than 9180 bytes are fragmented by IP
and transferred separately to AAL5
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
7
IP Maximum Transfer Unit (MTU) over
AAL5: Fragmentation
IP
IPdatagram
datagram>>9180
9180octets
octets
<= 9180
bytes
LLC/SNAP
Encapsulation
LLC / SNAP
header
...
Datagram <= 9180
AAL5
AAL5frame
frame<=
<=9188
9188bytes
bytes
Trailer
Trailer
AAL5
AAL5
...
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
8
Encapsulation of IP Datagrams in
ATM: Types and Multiplexing
‹
AAL5 frame: Protocol type not auto-identifiable
™
‹
‹
‹
No type field
Two possibilities to get to know the type of the
encapsulation protocol (cf. previous chapter)
™
VC multiplexing
™
LLC/SNAP Encapsulation
First method:
™
No need to add anything apart from the trailer
™
Many virtual circuits necessary (one for each protocol)
Second method:
™
All traffic sent over one VC
™
All protocols treated with the same priority / bandwidth
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
9
Encapsulation of IP Datagrams in
ATM: LLC/SNAP Encapsulation
IP datagram
≤ 9.180 octets
SNAP
LLC
PDU IP
DSAP
AA
SSAP
AA
LLC
LLC
DSAP
DSAP
SSAP
SSAP
SAP
SAP
Ctrl
03
OUI
00 00 00
Logical
Logical Link
Link Control
Control
Destination
Destination SAP
SAP
Source
Source SAP
SAP
Service
Service Access
Access Point
Point
PID Type
08 00
SNAP
SNAP
OUI
OUI
PID
PID
SubNetwork
SubNetwork Attachment
Attachment Point
Point
Organizationally
Organizationally Unique
Unique Identifier
Identifier
Protocol
Protocol ID
ID
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
10
ATM and Internetworking
Classical IP Over ATM - CLIP
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Resolving IP Addresses in ATM
Networks
‹
Need to resolve IP addresses to ATM addresses
™
‹
No static mapping possible because ATM
addresses (network addresses) are larger than IP
addresses
™
‹
‹
As for all kind of “link-layer” network
20 bytes vs. 4 bytes
Traditional ARP: Not usable because ATM does
not support broadcast
Two address mappings required:
™
On establishment of an SVC: IP address to ATM address
™
When sending datagrams for a VC: IP address to UNI
address (i.e. to VPI/VCI pair)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
12
CLIP: Classical IP over ATM
‹
‹
‹
‹
‹
RFC 2225: Specify Classical IP over ATM using
ATM as link-layer technology (layer 2)
ATM uses AAL5 to deliver IP datagrams
CLIP: Only valid for a restricted part of the
network, called LIS (Logical IP Subnetwork).
The proceedings described below apply for both,
PVCs and SVCs
In CLIP, final end hosts must own both:
™
One or more IP addresses
™
One or more ATM addresses
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
13
The Concept of
Logical IP Subnets (LIS)
‹
Logical IP Subnet (LIS): Group of hosts
™
™
Connected to the same physical ATM network
Sharing the same subnet prefix
9
‹
‹
Several LIS per physical ATM network possible
Each LIS: Forms a separate LAN
™
‹
Different from all other prefixes of other LIS
Members of a LIS:
9
Connected by virtual circuits
9
Exchange datagrams using LLC/SNAP encapsulation
9
Can select a standard MTU to be used for all VCs
Communication between two or more LIS:
™
Only possible through routers being member of several
subnets (no direct communication possible)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
14
Logical IP Subnets (LIS): Example
‹
‹
‹
Define LIS taking some
hosts connected to the
same ATM network.
Example: 8 hosts, one
ATM network, two LIS
LIS 1 (orange):
™
‹
C
D
H
Hosts A, C, D, E, F
ATM network
LIS 2 (violet):
™
‹
B
A
Hosts B, F, G, H
Host F: in LIS 1 and
LIS 2
™
G
F
E
Could be an IP router
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
15
Connection Management
‹
Problem in ATM networks
™
™
™
‹
Each host must maintain a table containing a mapping between
the open VCs and the IP destination addresses
On reception of a datagram: Consult that table to get the VC to
send the datagram to. If no entry, create a new VC
In large networks: Large table
Solution: LIS concept
™
Restricts the table size because of the restricted forwarding
9
™
™
‹
Comparable to a conventional LAN
Need only direct VCs to hosts in the same LIS
Connections to outside the LIS: Must go over a router
connected to the LIS
Creating LIS limits the number of open VCs per host
™
Saving cost in hardware and software
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
16
CLIP for PVCs: InARP
‹
PVC: Configured manually by the network administrator
™
™
No participation of ATM terminals
Problem: ATM terminals connected over a PVC have
insufficient knowledge on
9
¾
ATM / IP addresses of the terminal at the other end of the PVC
Inverse Address Resolution Protocol (InARP) (RFC 1293)
™
™
™
™
™
¾
Basic function: Learn the IP address of the router at the other
side of the PVC
Requirement: ATM terminal must know each of the configured
PVCs
To determine the IP / ATM addresses from a remote end: ATM
terminal must send an InARP Request with the field
OPERATION set to value 8
If a remote end receives an InARP Request: reply with a InARP
Reply with the field OPERATION set to 9.
InARP Request and Reply contain the IP / ATM addresses of the
sender
Remote ends learn the IP addresses / the ATM addresses
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
17
InARP: Example
PVC
PVC
InARP
Request
PVC
InARP
Reply
144.254.10.3
144.254.23.0
ATM network
144.254.10.1
InARP
Reply
PVC1 (VPI/VCI) = X/Y
PVC2 (VPI/VCI) = X/Z
144.254.10.3 NSAP1
144.254.67.0
InARP
Request
144.254.10.2
144.254.10.2 NSAP2
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
144.254.45.9
Switching, Chapter 13
18
InARP: Example 2
IP address B
VCCs
52 51
PVC ATM
network
VCCs
IP
address
A
VCCs
51
52
52
51
IP
address
C
1
2
InARP (A)
InARP Response (C)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
19
CLIP for SVCs: ATMARP
‹
RFC 2225: Specifies an automatic method for
address resolution for SVCs
™
™
Using an ATM address resolution protocol (ATMARP)
server
One logic ATMPARP server per LIS
9
™
One physical device can implement several logical
ATMARP servers
9
‹
Potential single point of failure
E.g. if participating in several LIS
Basic function of ATMARP server:
™
™
Resolve the mapping IP address – ATM address on
arrival of an ARP_REQUEST
For all IP stations within a LIS
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
20
ATMARP PDU
8
16
24
Hardware type
32
Protocol type
Type and length
of source ATM
number
Type and length
of source ATM
subaddress
Length of source
protocol address
Type and length
of target ATM
number
Source ATM number (q bytes)
Operation
Type and length
of target ATM
subaddress
Length of target
protocol address
Source ATM subaddress (r bytes)
Source protocol address (s bytes) (IP=4 bytes)
Target ATM number (x bytes)
Target ATM subaddress (y bytes)
Target protocol address (z bytes) (IP=4 bytes)
The operation type value (decimal):
ATMARP_Request = 1
ATMARP_Reply = 2
InATMARP_Request = 8
InATMARP_Reply = 9
ATMARP_NAK = 10
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
21
ATMARP - Initialization
1.
IP host: establishes an SVC with ATMARP server
™
2.
ATMARP server: determines the IP / ATM address of the IP
host:
™
™
3.
IP host transmits an ATMARP_Request with its own IP address
as target.
For multiple IP address hosts, one request per address.
ATMARP server: stores the mapping IP address – ATM
address for the node in its ATMARP table
™
™
™
4.
Hosts (ATMARP clients) need to obtain the ATM ATMARP
server address (either by manual configuration or by ILMI)
Assigning a time stamp to the entry
Host must refresh server ATMARP information with an
ATMARP_Request at least once every 15 minutes (verification
of activity)
If no response in 20 minutes: Server deletes table entry
IP / ATM interfaces: Have a VC for UNI ATM signaling
Each host in a LIS must establish a connection to the ATMARP server even
if the host does not need a translation service from the ATMARP server
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
22
ATMARP – Transfer (1)
1. Source device: Receives an IP packet to send
™ Send an ATMARP_request to the ATMARP server
2. ATMARP server: Send ATM address of the
destination in an ATMARP_repply message
3. Source device: Send an ATM SETUP message to
the ATM network
™ Result: use VC 5 at the source to the first ATM switch
4. ATM network: Forwards the SETUP message to
the final ATM destination address
™ Result: use VC 58 at the destination
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
23
Example: ATMARP – Transfer (1)
ATMARP server
ARP
reply (B at Y) 2
ARP
request (B)
IP address A
1
VCCs
ATM address X
51
3
5
SETUP to Y
VCCs
52 51
SVC ATM
network
4
IP address B
53
5
VCCs
ATM address Y
SETUP to Y using VCC=58
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
24
ATMARP – Transfer (2)
5.
Destination device: responds with a CONNECT
message and sends it to the ATM network
‹
6.
ATM network: forwards the CONNECT message
to the source device
‹
7.
Using VC 58 as determined previously
Result: VC 54 to be used for this connection
Result: Communication between source and
destination is realized over VC 54 at the source
and VC 58 at the destination.
CLIP releases the SVC automatically if there is no data
flowing on the connection for a certain time interval (usually
in the order of minutes)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
25
Example: ATMARP – Transfer (2)
ATMARP server
VCCs
52 51
IP address A
VCCs
ATM address X
SVC ATM
network
51
53
5
5
54
6
CONNECT to Y
using VCC 54
7
IP address B
VCCs
ATM address Y
5 58
CONNECT
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
26
Interconnection between LIS
‹
‹
‹
‹
Each LIS operates
independently of other LIS
even though they might
belong to the same ATM
network
RFC 2225: requires that any
packet with a destination
address outside the LIS of the
sending host or router must
be sent over an IP router
RFC 2225: specifies that the
implementations must support
LLC/SNAP encapsulation for
802.2
Maximum default MTU for IP
over ATM is 9180 octets.
™
Router IP 1
H
LIS-1
ATM
H
H
LIS-2
ATM
H
R
H
Router IP 2
Including the LLC/SNAP
header results in an MTU for
ATM AAL5 of 9188 octets.
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
R
H
LIS-3
ATM
H
H
R
Switching, Chapter 13
27
Interconnection of LIS: Example
ATMARP server
(LIS 1)
ATMARP server
(LIS 2)
ARP
Reply
ARP
Request
144.254.10.2
LIS 1
Transit
router
ARP
Request
LIS 2
ATM network
ARP
Reply
144.254.45.9
ATM A
IP dest. address = 144.254.45.9
Next hop = 144.254.10.2
ATM B
NSAP transit router
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
ATM B
Switching, Chapter 13
28
CLIP: Conclusions
Advantages:
‹ Very simple scheme
‹ No repeated requests for address translation
necessary because of the ATMARP cache
Disadvantages
‹ Lower performance and higher latency because of
the restriction that communication between
different LIS always has to go through an IP router
‹ No redundancy for ATMARP server
‹ Each terminal in a LIS need to be configured
manually with the ATM address of the ATMARP
server
™
Some vendors have added this address to the ILMI
procedure to enable true “plug and play” for ATM
adapters
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
29
ATM and Internetworking
Next Hop Resolution Protocol
(NHRP)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Motivation
‹
‹
Limitation of CLIP:
™
All communication between the machines in different LIS
must go through an intermediate transit router even
though the machines might be located in the same
physical ATM subnet
¾
Intermediate router might become a bottleneck
Interesting approach:
™
¾
Realize “short-cut” connections to avoid using the
intermediate router
Next Hop Resolution Protocol NHRP (RFC 2332)
™
Designed to implement the necessary mechanisms
9
IETF working group: “Routing over Large Clouds (RLC)”
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
31
NBMA and Administrative Domains
‹
NHRP: constructed starting from the CLIP model
™
™
‹
9
Consisting of nodes which can communicate directly with each
other
9
It is a network technology like ATM or Frame Relay, but
broadcast is not easy to implement
Instead of ATMARP servers, utilize Next-Hop Servers (NHS)
Architectural concept: Administrative domain (AD) (= LIS)
™
™
™
‹
Substituting the LIS concept by a “Non-Broadcast MultiAccess” (NBMA) network
Network area served by one NHS
Direct connections allowed within an AD
Direct connections between different ADs possible
9
But only over certain access points
9
Can be prohibited, for example, for security reasons
One NBMA network:
™
Can consist of one or several administrative domains
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
32
Next-Hop Servers (NHS)
‹
‹
‹
Replacement for ATMARP server
Implement the NHRP protocol
Maintain a “next-hop resolution” cache table
™
‹
Containing the relations between IP addresses and ATM
addresses for all nodes in an NBMA network
Each node of the NBMA network is configured
with its IP address and ATM address and the ATM
address of its NHS
™
Thus: It can register its own IP address and ATM address
in the NHS, which builds the next-hop resolution cache
from this information
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
33
Example: Architecture and NHRP
NHS 2
NHS 3
Next-hop server
(NHS 1)
Domain 3
NHRP
Registration
Request.
NHRP
Registration
Reply.
Domain 1
Domain 2
Non-Broadcast Multi-Access
(NBMA)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
34
NHRP Operation (1)
Situation: A node wants to send a packet over the NBMA
network
‹ For this purpose: Translation of the destination IP address to
an ATM address required
‹ Therefore, the node
‹
™
™
Sends an NHRP resolution request to the NHS, encapsulated
into an IP datagram
Two possibilities for the NHS:
9
The request address is served by the NHS
¾ Return an NHRP resolution reply containing the requested ATM
address
9
The destination is not served by the NHS
¾ Consults ithe NHS’s routing table to find the subsequent NHS in the
path to the destination
¾ Forward the request to that NHS
™
The procedure is repeated until the request reaches an NHS
being capable of doing the translation as the requested node is
within its served domain
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
35
NHRP Operation (2)
‹
The last NHS returns an NHRP resolution reply:
™
™
Containing the requested ATM address
Back to the original sender of the request
9
Which can then establish a direct connection with the
destination
‹
Important: The NHRP resolution reply has to take the same
path as the NHRP resolution request to include all involved
NHS on the way
™
™
So the intermediate NHS can deny direct connections if
necessary
And they can store the address translation in their cache
9
‹
To respond directly to further requests
Optional behavior while waiting for an NHRP reply:
™
™
Send packets over the default router
Problem: Out-of-order delivery of packets
9
Not specified sufficiently in the standard Æ not recommended
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
36
NHRP Operation: Example
NHRP
Resolution
Reply.
NHS server
(NHS 1)
NHRP
Resolution
Request.
NHRP
Resolution
Request.
NHS 2
NHRP
Resolution
Reply.
NHS 3
NHRP
Resolution
Request.
Default
router
Default
router
NHRP
Resolution
Reply.
159.23.171.6
Dest. address = 159.23.171.6
Non-Broadcast Multi-Access
(NBMA)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
37
ATM and Internetworking
MPOA (MultiProtocol Over ATM)
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Motivation
‹
A routed network model causes a high processing overhead
for the packets on each hop
™
Because the networks grow, the number of hops also grow
and, thus, also the packet processing in each node
9
‹
Further requirement:
™
¾
Increasing delays, i.e. lower performance
Multi-protocol networks (not restricted only to IP-based
networks)
MPOA specification of ATM Forum
™
Allows routed networks to benefit from the characteristics of
ATM networks
9
Lower latency (because of a direct virtual circuit connection,
which imposes almost no switching delay as opposed to delays
by IP route lookup etc.)
¾
Higher performance, higher scalability
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
39
MPOA: Características
‹
MPOA combines concepts from LANE, CLIP and
NHRP.
‹
MPOA uses NHRP
™
To allow direct connection between machines from the
same ATM swithching network
9
‹
Minimizing the use of routers. Traffic is sent over ATM
VCs: “Short-cut routing”.
Introduces the Virtual Router concept:
™
Physical separation of switching y packet forwarding.
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
40
Characteristics of MPOA
‹ Basically
the same characteristics than
NHRP + LANE:
™
™
Provide address translation of LANE
Plus direct connections over subnetwork
boundaries
9 Bypassing
‹ News
™
™
the routers (short-cut routing)
compared to NHRP + LANE:
Ability to handle multiple protocols
Possibility to provide MPOA routers:
9 Playing
the role of NHS
9 Participating
in IP routing
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
41
MPOA: Components
MPOA Server
MPOA Server
MPOA Server
LANE
LES
LECS
LANE
LECS
LES
BUS
BUS
MPOA client
MPOA client
MPOA client
MPOA client
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
MPOA client
Switching, Chapter 13
42
MPOA: Operation
‹ Basic
™
idea:
Detection by the MPOA client wether the data
stream towards a target is isolated or
continuous.
‹ Isolated
™
™
™
™
data stream
MPOA client detects IP message to a particular
destination.
Sends message to the BUS
BUS delivers to MPOA server
MPOA server routes it to destination through
the different LISs
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
43
MPOA: Operation
MPOA Server
MPOA Server
LANE
LES
LECS
LANE
LES
LIS
(CLIP)
BUS
MPOA Client
LECS
BUS
MPOA
Client
MPOA
Client
MPOA Client
MPOA Client
MAC MAC MAC
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
MAC MAC MAC
Switching, Chapter 13
44
MPOA: Operation
‹
Continuous data stream towards same destination
™
™
™
™
™
MPOA client sends MPOA resolution request to MPOA
server.
Two possibilities:
9 Server knows the mapping and answers with a MPOA
Resolution Reply
9 Server does not know the mapping. Sends an MPOA
Cache Imposition Request directed to another MPOA
server from his routing table (same mechanism as in
NHRP). Message propagates until the one that has the
mapping, responding with an MPOA Cache Imposition
Reply containing the destination ATM address
Answer travels back towards MPOA server that
originated the request
MPOA server sends MPOA Resolution Reply to MPOA
client with answer
MPOA client establishes a VC (short-cut) with destination
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
Switching, Chapter 13
45
MPOA: Operation
MPOA Server
MPOA Server
MPOA
LES
LECS
LANE
MPOA Server
MPOA Cache
Server
Imposition Reply
MPOA Cache
Imposition
MPOA Request
Resolution
Request.
MPOA Cache
Imposition Reply
MPOA Cache
Imposition
Request
LANE
LECS
LES
BUS
BUS
MPOA
Resolution
Reply.
MPOA Client
MPOA
Client
MPOA Client
MPOA Client
(c) Departamento de Ingeneria Telemática, Universidad Carlos III de Madrid
MPOA Client
Switching, Chapter 13
46